Comments 18
Порядок букв в ETL не имеет никакого значения, да хоть TEL, это понятие виртуальное. Не обозначено главное преимущество DIY - независимость от вендора. Попробуйте прожить лет 8-10 с каким-нибудь вендором, раз десять перепишите всё с нуля, потому что что-то перестали поддерживать или чаще баги заставляют писать неоптимальные обходные пути. Поддержка вендора - это дорогущие консультанты, которые в большей массе могут лишь чесать языком.
ODI, Informatica PowerCenter - хлам, не тратьте время. Архитектура Data Vault - это когда продают технологию из другой области, где она себя хорошо показала, хочется ещё денег и продают в область хранилищ данных, потому что модно.
Может немного критический комментарий, но как есть, не всё так радужно с этими технологиями.
Data Vault это же только ДВХ, какая ещё "технология из другой области "?
Может быть биография автора этой технологии ответит на вопрос. Любая технология - это набор правил и инструментов для решения той или иной проблемы. Когда ключевыми целями хранения данных пренебрегают, то возникает вопрос, откуда вообще взялась эта технология, какую проблему она решала изначально?
Тут картинка, позволяющая понять смысл проблемы с дата волтом https://habr.com/ru/articles/505292/comments/#comment_21704338
Перечислены конкретный пункты https://habr.com/ru/articles/502968/comments/#comment_21683308
Полностью с Вами согласен по поводу особенностей и недостатков Data Vault. Все грамотно описано.
Но надо четко понимать, для чего нужен Data Vault:
Полное версионирование хранилища (отсюда выделение SAT как SCD машина). Т.е. возможность увидеть данные как они были N дней назад.
Динамическое развитие/изменение хранилища, добавление новых связей, работа по agile (представьте что вам надо в звезде Кимбала добавить измерение) (отсюда выделение связи в LINK)
И Data Vault используют если Вы готовы пожертвовать местом/удобством и скоростью работы хранилища ради двух вышеуказанных преимуществ.
И да, Data Vault ТРЕБУЕТ автоматического фреймворка, делать Data Vault руками - бред и самоубийство, я про это уже писал (https://habr.com/ru/companies/jetinfosystems/articles/721950/)
На нашем опыте, СТРОГО при наличии фреймворка, Data Vault дает преимущество по скорости развития хранилища (time2market) в 1.5-2 раза, с учетом наличии требования по версионированию данных.
Не делайте Data Vault если у Вас нет требования по версионированию и нет (не планируете создавать) автоматического фреймворка.
Шринкать модель ради версионирования ну такое себе. Как будто не существуюет других паттернов для обработки scd. Мне кажется люди изначально отошли от цели которая преследовалась в DV - ускорить обработку версионирования.
Тема была актуальная когда ничего кроме SMP на рынке то и не было и перестраивать историю было "медлоенно". В эпоху MPP рассуждать о том что ты выносишь историчные атрибуты в отдельные сателиты, да еще не дай бог нарезаешь сателиты по гранулярности изменения истории попахивает некомпетентностью.
Но чтобы как то оправдать DV стали придумывать некую "гибкость и универсальность" :). Правда такую гибкость все равно потом придется собирать в нормальную плоскую витрину тк пользователи отказываются с DV работать ручками. Но и тут адепты DV не подвели - разрабатывают кодогенераторы запросов в DV на основе метакаталога чтобы пользователям было удобно. Короче сектанты. Даже лечению не поддаются.
Если убрать эмоции, то я с Вами согласен:
DV имеет проблемы в MPP и на очень больших хранилищах (нужно прорабатывать партиционирование/шардирование, хотя есть реализации на том же GP, Яндекс регулярно докладывает)
DV требует материализации в плоские витрины (ну так это же не все хранилище а просто слой из которого собираются витрины)
DV пихают везде, не понимая его преимуществ и недостатков.
Итого, мое мнение: DV всем не нужен. Применяя DV, Вы должны понимать, что вы теряете, и что от этого получите. Самое смешное, но DV в последнее время требуют заказчики (им не нужно просто хранилище им подавай фреймворк), и их зачастую приходится отговаривать.
НО, там где он подходит, и заказчик готов платить за разработку фреймворка и за лишние вычислительные ресурсы, DV существенно сокращает time2market.
Привет Яндекса показывает не только про DV а еще и во многом про GP.
Если иметь на старте достаточно опыта и квалификации понимаешь что история не взлетаемая by design. Но все почему то любят ходить по граблям, а не смотреть как соседи уже лбы расшибли на этом.
Яндексу спасибо за то что честно рассказывают об "успехах".
Имхо, подавляющая часть потребностей версионирования решается банальным start date / end date, а не затеванием огорода с DV.
С возможностью быстро добавлять новые атрибуты чуть сложнее, но тоже все сложности DV того не стоят. Я скорее соглашусь на решение, где добавить колонку ничего не стоит (условные hbase, parquet) или исходную таблицу заменить view, а внутри сделать join исходной таблицы и таблицы с новыми атрибутами, чем обрекать себя на вечные страдания с DV.
Порядок букв важен ELT - это труба и трансформация на отдельном сервере, ET-L - нет. Архитектурно это разные паттерны.
Ну собственно говоря вендоры ушли (кроме Informatica), об этом в статье прямо говорится. Так что выбора особо то и нет.
При этом я по прежнему считаю, что архитектурно подход ODI на порядок лучше, чем все что я видел в области ETL/ELT-T. Если кто из росийских разработчиков повторит идею - будет крайне интересно. Там сумасшедшая скорость разработки, DYI рядом не валялся.
Преимущество или недостаток работы с вендорам можно отнести к холиварной теме и не хочу спорить.
Что касается DV прокомментировал ниже Ваш пост.
P.S. Я автор статьи.
Informatica конечно хлам. И всегда им была. А вот про ODI зря так. ODI наряду с SAS DI - самые крутые и чуть ли не единственные инструменты true ELT на рынке.
Ключевое тут что это именно инструменты - возможность рисовать диаграмму трансформации на основе которой выполняется metadata driven кодогенерация исполняемого кода. Есть те кто как раз 8-10 лет работает с этими инструментами и прекрасно уживается с ними как раз потому что сделано все по феншую а не как обычно делают с информатикой - запускают написанный руками код, максимум пробрасывая какие то параметры.
Никакой DIY не даст возможность отрисовки графа отдельного джоба без написания кода.
Именно поэтому Airflow не является ELT ELT инструментом, а всего лишь планировщик.
Про Data Vault аплодирую стоя :)
Я работаю с DV с 2011 года. Почему то всегда говорят о гибкости слоя хранения данных и забывают, что слой представления данных - витрину, которая в 99.9% звезда или снежинка тоже нужно перестраиввть и менять. Получается двойная или тройная работа. Просто хранить данные с историей ещё старик Инмон учил, в 3NF, Линстедт просто хотел хайпануть и заработать немного денег на своём консалтинг и мировых турне с курсами.
Data vault - это не архитектору хранилища, а модель данных в хранилище. Архитектора несколько другое.
Актуальные подходы к ETL. Или EL-T? Технологический разбор