Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
А почему время в мл? Почему не в литрах? Или в килограммах? Или в Амперах?
мутный подход, завтра понадобится чуть больше джойнов и все посыпется.
размеры крошечные, обычный airflow + спарк в режиме local мне кажется надежней было бы
Изначальная идея dbt и есть в этом, чтобы крайне быстро реагировать на изменения в бизнес логике, чего не могут себе позволить airflow и spark на текущий момент. Лишний джоин аналитику добавить всегда проще, чем идти и изменять спарковский код в airfllow. + меньше затрат на инфру
dbt супортит спарк (+click connector) точно также как все остальное, точно так же все на SQL можно строить.
airflow это просто оркестратор, логика вся в dbt пайплайнах, джойн спарку в том же dbt аналитик должен описывать
Правильно ли я понимаю, что предложение состоит в том, чтобы поверх dbt навесить еще спарк и airflow? Если так, то это оверхед архитектура, которая не приносит очевидных плюсов, но принесет затраты на инфру + тайминг на новые реализации заметно вырастает. Непонятно где именно мы получим плюсы в надежность? На мой взгляд, дбт всецело закроет эту проблему
ну да, потому что airflow+dbt+spark гораздо проще, чем ваше нагромождение, которое совсем не факт, что завтра под нагрузкой продолжит работать (из-за джойнов в клике). airflow+dbt+spark же можно попросить поднять джуна и рассчитывать, что он часик-два посмотрит видосы и через часик-два поднимет. благо туториалов и видосов миллионы.
еще раз, когда вы произносите "airflow+dbt+spark", то джун сходу понимает всю архитектуру. а вот что там у вас, наверняка джун так просто не осилит. документации наверняка толком нет, кто там должен мониторить рефреши вьюшек, как наколхозжены нотификации, как перезапустить с нужного шага, там же тысячи вопросов будет.
плюсы в том, что схема рабочая и всем в индустрии знакомая и тот самый аналитик, без вас знает, что ему в dbt подправить надо, потому что он это делал на предыдущем месте.
Тут подчеркну, что в последнем абзаце вы сами подчеркиваете, что аналитик прекрасно знает, что ему в dbt надо править, то есть правка любого SQL не должна вызывать вопросов, то есть потенциально, это более легкий подход, чем лезть связку "airflow+dbt+spark" . Я полагаю, что вы сетуете на непрозрачность самого пайплайна, именно этот вопрос призван решить dbt (об этом упомянуто в статье).
Airflow в этой схеме фактически имеет смысл, когда появляются внешние интерфейсы, от которых зависят даги, по типу загрузка в API, запуск при появлении в Kafka, S3 и т.д., то есть я говорю о сложной оркестрации. Когда это имеет место быть, спору нет, airflow лучшее решение. Однако, пока главная цель, это протекания пайплайна в одной БД, не совсем понятно, зачем крутить дополнительный оркестратор.
Spark же фактически призван решить проблему не надежности, а проблему масштабируемости. Учитывая, тот рабочий объем, который указан в статье, это явно избыточное решение, поэтому я говорю о оверхеде. Оно приведет к замедлению процессов, не увеличив ни скорость, ни надежность.
Когда у вас данных терабайты в сутки, а ETL требует шаффла/оконных функций, я с вами полностью соглашусь. В данном примере это избыточно.
у вас какое-то неверное представление о dbt. dbt это и есть та абстракция, которая скроет движок под низом. ваш аналитик правит dbt пайплайны в уже настроенном проекте dbt, что там под низом один лишь клик или spark он скорее всего и вникать не будет.
локальный spark врятли что-то к масштабируемости даст, у него просто запас прочности на тему джойнов сильно выше, ну и может побогаче SQL синтаксис. при этом пристегнуть локальный спарк к dbt это просто папочку распаковать и переменные среды выставить.
что касается airflow то я тут сетаю на колхоз. если что-то упало airflow пришлет нотификацию, в человеческом виде отобразит, где упало, покажет ретраи, затраченное время. если там начнет тыкать джун, все будет запротоколировано, все что он там наделал.
а вам все это колхозить надо.
Не могу с вами согласится. Давайте по пунктам:
Spark в локали теряет всё, ради чего создан: нет распределённости, только оверхед сериализации + старт JVM. Для 3-5 млн записей в месяц — это spark не имеет смысла. CH такие объёмы прожует за миллисекунды.
Запас прочности по джоинам. Проблемы с джойнами в CH начинаются от десятков гигабайт. Хеш джойны в CH быстрее для таких объемов.
Побогаче синтаксис в спарк, тут в корне не согласен, возможно, вы имеете в виду df api, а не SQL, например, работа с массивами , приблеженными агрегатами, дата/времы CH полностью закрывает, spark по удобству рядом не стоял.
Насколько, я понял, ваше утверждение в том, что airflow позволит явно видеть ошибки в дагов. Тогда, первое, теряется основная функция самого airflow, это в первую оркестрация, а не мониторинг. То есть по логике, мы должны завести airflow, чтобы мониторить процесс, только airflow создавался изначально не для этой задачи, поэтому я говорю, что airflow имеет смысл для сложной оркестрации. Второе, вопросы мониторинга vies, все цело закроет system таблицы, выкинув их в Grafana, повесим alert. Все понятные exception, которые вы увидите в airflow, будут у вас на дашборде, так еще и нормальными алертами. Выходит, что если проблема мониторинга решена, то добавляя airflow мы получаем +3 компонента в архитектуру, ради функционала, который заменяется уже существующей графаной и 10 строками SQL.
Я все еще цепляюсь за время выполнения задач. Джун у вас за час поднимет dbt + CH, чтобы поднять airflow+spark+dbt и не сломать уйдет пол дня.
Подчеркну свою идею, для трансформации внутри одного CH, при объемах менее 1ГБ в день связка dbt + CH лучшее, что можно предпринять. В статье показ демонстрационный пример самого медальона построенного полностью на CH. Добавление Airflow, Spark преждевременная оптимизация и дорогая! Фактически только увеличит точки отказа без особого профита в надежности и скорости. При появлении внешних зависимостей - я полностью соглашусь с вами, а пока такое решение экскаватором картошку сажать.
Добавление нового поля от парсера не составляет проблем, но допустим все таки дроны полетели над 3м московским, при этом по любому в PSQL появятся новые хабы/справочники. В таком случае каков будет объем работ? Сколько на вскидку может занять проброс такой информации и подача итоговых данных на витрину?
Тут важен объем новых хабов и линков, фактически добавление сведется к прокидыванию хабов и линков через PeerDB в CH, и последующее их использование на сильвер и год уровнях. Таблица на PeerDВ прокидывается наилегчайшим способом, в районе 5-15 минут, если у вас готова архитектура. Корректировка views может занять более длительное время, зависит от того, нужны ли вам таблицы пред расчета. Если нет, то я полагаю это будет дополнительным джоином в готовые views или же написания новой. Если да, то важен аспект какой именно сложности пред расчет. Думаю по описанному объему работ, сможете оценить время выполнения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Medallion в ClickHouse: DWH без миграций схемы