Comments 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 без миграций схемы