Просто на сколько я понимаю сделать очень быстрые универсальные джойны крайне сложно. СОбственно, поэтому в КХ и добавлены словари.

Но если можно сделать гибридное DWH на КХ + универсальная релиционка для пролвинутой работы с таблицами атрибутов, которые в КХ загружаются в виде словарей — то почему бы так и не сделать.

Собственно, если у вас есть практический опыт именно с anchor моделированием, поясните, какие могут тут грабли быть?

грабли одни, зачем мне гибридное DWH?

грабли одни, зачем мне гибридное DWH?

Если вам нужно положить много данных в DWH и при этом хотите использовать современный гибкий подход к моделированию, то я ПРЕДПОЛАГАЮ, что вы можете это сделать объединив КХ с какой-нибудь реляционкой рядом. Данных в этой релиционке много быть не должно, она будет чисто под "справчники". Поэтому для этой цели можно использовать все что угодно, даже коммерческие базы от крупных вендоров — их бесплатные/дешевые редакции. Если вы наладите ETL для импорта данных в КХ, то направить часть данных в эту побочную базу проблемы не соствит — в отличие от КХ вокруг этих баз уже есть зрелая инфраструктура. В общем, пугать такое "гибридное" DWH должно только менеджеров (ну как же, две разные технологии, которые наверное будут враждовать друг с другом — ой, боюсь, боюсь). В общем это лишь мое ПРЕДПОЛОЖЕНИЕ, что таблицы фактов + словари в КХ с подсистемой хранения атрибутов в отдельной базе позволят воспользоваться преимуществами anchor уже сейчас. Если видите грабли в этом, поясните плиз.

вы мне сейчас предлагает усложнить ETL на пустом месте, я уж молчу про факт наличия допольнительного ПО/железа и его администрирования и поддержки

вы мне сейчас предлагает усложнить ETL на пустом месте, я уж молчу про факт наличия допольнительного ПО/железа и его администрирования и поддержки

как на пустом месте? польза очевидна — вы получите КХ c плюшками anchor'а

плюшки не очевидны на фоне затрат

я прикинул, что КХ c этой "левой" базой можно было бы положить на один сервер

я это учел

сам по себе ETL в КХ будет еще тот геморой ;)

это отдельный ETL-процесс

Привет. Мне кажется anchor выгоден там, где нет времени-возможности-сил поступающие данные по слоям раскладывать. У Авито все что приходит, они тут же юзают. То есть идея у него - легко грузить данные. Но вот "легко анализировать", это не про anchor :)

+ геморой сам по себе ETL для фомирования anchor сущностей — это геморой не зависит от выбора базы

в том же Авито мы их консультировали, под сотню джойнов в аналитических запросах

даже Вертике мало не казалось

Привет. Мне кажется anchor выгоден там, где нет времени-возможности-сил поступающие данные по слоям раскладывать. У Авито все что приходит, они тут же юзают. То есть идея у него - легко грузить данные. Но вот "легко анализировать", это не про anchor :)

Предположу, что у Авито мало сущностей :) Поэтому 6-я форма не приводит к хаоусу

Привет. Мне кажется anchor выгоден там, где нет времени-возможности-сил поступающие данные по слоям раскладывать. У Авито все что приходит, они тут же юзают. То есть идея у него - легко грузить данные. Но вот "легко анализировать", это не про anchor :)

Для анализа собираются витрины, нужны нормальные JOIN'ы и все

да там сплошные логи грузятся, да еще ЕТЛ на Питоне самописный

понятно им выгоднее получилось 6 форма

Предположу, что у Авито мало сущностей :) Поэтому 6-я форма не приводит к хаоусу

Если у Авито мало сущностей, мне интересно, у кого их много и что это за сущности?

а вы банк любой возьмите

а вы банк любой возьмите

я телеком беру

там каждая система источник десятки сущностей имеет

и источников тоже десятки

у нас в йоте более тысячи таблиц

исходные данные плюс витрины

и это даже мало, 70 тб ограничение, не влазит все, через хайв еще им жуем и выплеваем результаты

в телекоме если начать собирать ту же сетевую статистику для анализа работы сети сущностей тоже вполне себе на каждого вендора технологию

у меня на текущий момент 5 крупных биллингов, начиная от всякого древнего говна, заканчивая самописными, 2 крупных компании и десятки мелких, плюс агенты и аренда каналов

биллинг в йоте это маленькая часть от всех сущностей, "копейки" :)

а я и не спорю на эту тему

что вас смущает?

биллинг - компактый достаточно :)

биллинг - компактый достаточно :)

а вот тут могу поспорить

вот CRM, FM, PM, OMS/OFM, TT - там да

а я написал количество компаний

умножайте

ну мы им биллинг весь грузим, через ОГГ с Оракла снимаем все изменения таблиц и один в один реплицируем в Вертику

и NRI

ну а чего умножать

но тут вот про Anchor - в таких вот ХД от него мне кажется вреда чем пользы больше

ну мы им биллинг весь грузим, через ОГГ с Оракла снимаем все изменения таблиц и один в один реплицируем в Вертику

вот я так же сейчас и делаю, сливаю все в staging Vertica, а дальше прохожусь ETL и формирую DWH

процентовка биллинговой информации в BI - далеко не самая большая

по жизни проблема - легко грузить или потом легко анализировать, что важнее :)

это еще если не учитывать, что могут слить netflow

или логи с платформы IPTV

и это все в Йоте грузится :)

но тут вот про Anchor - в таких вот ХД от него мне кажется вреда чем пользы больше

Это почему? Вы можете сразу описать и зафиксирвоать все сущности? Или вы собираетесь потом лезть и менять все в проде, чтобы потом узнать, а почему у меня что-то не рабоатет за DWH?

все до чего доступ есть

процентовка биллинговой информации в BI - далеко не самая большая

а вот это спорно

сразу описывать и фиксировать все сущности - не один год займет

сразу описывать и фиксировать все сущности - не один год займет

про что и речь

поэтому Anchor

Это почему? Вы можете сразу описать и зафиксирвоать все сущности? Или вы собираетесь потом лезть и менять все в проде, чтобы потом узнать, а почему у меня что-то не рабоатет за DWH?

да в любой системе сущности фиксированны так или иначе

ой ли

да в любой системе сущности фиксированны так или иначе

если бы

набор сущностей фиксирован

есть у меня не один пример, как эти самые сущности на ходу менялись

не всегда

набор их атрибутов плавает, в порядке вещей

какие проблемы то ?

пока другие ребята пытались модель данных описать

ну вот это все мое мнение из разряда "правильная архитектура"

набор сущностей фиксирован

я рад, что у вас в йоте отлично все фиксировано, а вот у нас все очень грустно и печально, до такой степени, что даже в рамках одного биллинга две разные услуги считаются в разных сущностях

из наших систем кусочек был не большой, конечно, но мы умудрились несколько технологически новых услуг запустить

пока все описывали

Подхождите спорить, фиксирован или не фиксирован набор сущностей — вопрос — о каких сущностях идет речь? Сущности из источников или сущностях DWH, которые мы из имеющихся источников сочиняем?

вот я о том же

в DWH сущности фиксированы

Только в нашем МРФ биллингов было штук 5 крупных

ну и мелочь

а источников в стайдж слой можно сколько угодно и как угодно добавлять

Вот Anchor он делает DWH устойчивым (гибким - гнется а не ломается) по отношению к каким изменениям?

причем во время описания модели вовсю лишние биллинги выпиливали

в DWH сущности фиксированы

Фиксированы до момента, пока соответсвуют описанию бизнес-логики, ну и добавление новых никто не отменял

Изменениям источников или наших хотелок по анализу?

он позволяет вместо того чтобы проанализировать и подумать, сразу все грузить, "а уж потом думать"

фактически это форма грузить все не ломая голову

Друзья, я прошу потихоньку сворачивать дискуссию про разные DWH и прочие способы хранить данные

зато потом ломать голову на сборке?

он позволяет вместо того чтобы проанализировать и подумать, сразу все грузить, "а уж потом думать"

не совсем, он позволяет грузить сущности и не думать о том, как они дальше взаимодействуют, ибо они выделены

Друзья, я прошу потихоньку сворачивать дискуссию про разные DWH и прочие способы хранить данные

+100

предлагаю эту тему вынести куда нибудь

Если хочется обсуждать дальше, сформируйте отдельный чат себе

в @dba_ru

В общем, по теме, мне интересно, будет ли CH нормально поддерживать JOIN'ы

Если интересно, то по совету коллек мы для нашего FM/PM зацепили из CH внешние словари из монги

в @dba_ru

там админы в основном

там админы в основном

fix it :)

доработка ETL была относительно простая

мужики, оконные функции и rank() будет/есть?

@the_real_jkee вы планируете опубликовать какой-нибудь roadmap или хотя бы список горячих фич над которыми вы работаете? конечно, без гарантий, все ж понимаем, но ориентиры хотелось бы видеть

https://events.yandex.ru/events/yagosti/21-november-2016/

Создатели системы ответят на вопросы, расскажут о последних изменениях и предстоящих обновлениях

трансляция/запись для замкадышей будет?

Планируем опубликовать, да