Comments 13
По сути хорошая вводная статья, но глаз очень сильно режет слово "джобы" в каждом втором предложении ) Может всё таки назвать их задачами?
Действительно отличная вводная статья про dwh. Но от названия «создаем» все таки ожидается именно рассказ как создаем, а не набор пунктов «делайте как хорошо, не делайте как плохо».
Для систем -источников без человеческого фактора в информационных потоках может и взлетит.И главное не заменять прототипирование рабочим решением: переделка дорого будет стоить
Спасибо за статью! Наша команда из трех-четырех DE за пару лет пришла к очень похожим принципам.
Есть вопрос про launcher/исполнитель джобов. Из статьи получается, что метод переливки находится не в коде джобы, а является параметром launcher'а.
launcher.run_job(job_name='marts.crm_bill', method='increment')
Мы для себя решили, что метод тоже должен находиться в коде джобы для того, потому что запуски launcher'а не добавишь в Git и теряется информация для аудита, с тем ли методом была запущена джоба.
Вы как-то по-другому решаете эту проблему?
У нас расписание всегда запускается с method='increment'
А когда DE разрабатывает джобу ему доступны ещё "full" (полная перезагрузка) и "recreate" (пересоздание таргета).
А алгоритм загрузки определяется в теле джобы и зависит от основных двух параметров.
В примере:
"target_table_type": job_module.JobTargetTableType.MART,
"target_load_type": job_module.JobTargetTableLoadType.UPSERT_ROWS_BY_PK
Например при одном и том же алгоритме UPSERT_ROWS_BY_PK, аналитики для одних типов таблиц просят удалять данные удаленные из источника, а для других помечать как удаленные.
Т.е. как я предполагаю наши опции target_table_type и target_load_type играют ту же роль что у вас метод. И они также определяются в джобе.
Понятно ответил или я не очень понял вопрос?
"Инструменты, которые заменяют SQL рисованием: SAS Data Integration Studio,
Informatica, Pentaho — почти всегда плохо"
Генерация исполняемого кода на основе диаграммы, управляемой метаданными - это всегда не просто хорошо, а великолепно! Не только визуально видно диаграмму, но еще и метаданные все связаны, что позволяет автоматически построить lineage что как раз упрощает планирование и установку релизов.
Управляемая генерация (например SAS DI, Oracle DI) - это восхитительно. С помощью API или макроязыка можно любое извращение сделать в виде "кубика" с параметрами.
А вот ETL в виде запуска написанного кем то SQL кода - это плохо. Очень плохо.
Либо у вас нет положительного и правильного опыта использования пром инструментов, либо вы просто не достаточно опытны в этом плане.
Инструменты, которые заменяют SQL рисованием: SAS Data Integration Studio,
Informatica, Pentaho — почти всегда плохо:
Частично или полностью недоступен Git: сравнение, слияние, версионность джобов и т.д.Ограничения на автогенерацию.Вендор-лок.
не совсем
1) GIT - и да, и нет. Деплой джоба (сам исполняемый код) всегда можно помещать в гит и там смотреть что изменилось, но читабельность конечно уступает стандартному sql. Cмотреть, что изменилось в самой визуальной части джоба (квадратики) действительно невозможно гитом, но это невозможно будет и через рисование sql.
2) Автогенерить джобы сложнее - да, но ограничнений нет. Нужно копать в недокументированный код - сужает легкость порога вхождения
3) Да
При этом есть и плюсы:
1) Если переносить все на sql, то есть специфики, например, для постгреса важно запускать все в виде небольших иструкций, а не хранимых процедур. Чтобы это реализовать, нужно все равно делать обертку, и возможно писать свой ETL таким образом.
2) Возможности авто визуального восприятия и анализа зависимостей - тут действительно грубо говоря sql рисование, но должно быть продвинутым, чтобы отследить атрибутный маппинг нужно прямо заморочиться серьезно с рисованием, если рисовать его по фактической реализации, а не по документации.
Для небольшого проекта действительно не стоит брать SAS DIS и вендорные аналоги.
Для большого - нужно понимать сколько трудозатрат уйдет на создание своего аналога.
Из open source есть AirFlow, есть DBT. AirFlow не позволяет производить анализ, что и где используется - это просто набор скриптов исполняемых (хранимые процедуры, питон и тд)
Спасибо за развернутое мнение.
Я согласен что есть плюсы и минусы у обоих подходов.
Т.к. я писал рекомендации для маленьких проектов то, рекомендовал начать с sql.
На больших нужно считать деньги и риски, и энетрпрайс решение типа SAS DIS может быть предпочтительней т.к. там есть best bractice, много внедрений и меньше возможностей сделать всё очень плохо.
Благодарю за статью!
Пожалуйста, можете поделиться полезными ресурсами, книгами по этой теме(создание DWH)?
По data engineering курсов очень много, но именно по теме моделироования DWH нормальных курсов и книг на русском я не нашёл.
Можно начать с книги Building a Scalable Data Warehouse with Data Vault 2.0.
Как мне кажется когда сам изучаешь методологии Data Vault и Anchor modeling, то возникает куча вопросов. Как лучше смоделировать на своих данных? И спросить не у кого.
Поэтому чтобы научиться использовать эти методологии в бою, лучше поработать в большой компании где это всё описано и стандартизировано. Например, я работал в X5 и там очень круто сделана академия EDW где на рельных примерах разбирают все сущности Data Vault и расказывают о 100500 нюансах. Такой информации не найти в книгах.
Создаем аналитическое хранилище данных командой из 2-3 спецов