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 преждевременная оптимизация и дорогая! Фактически только увеличит точки отказа без особого профита в надежности и скорости. При появлении внешних зависимостей - я полностью соглашусь с вами, а пока такое решение экскаватором картошку сажать.
Тут важен объем новых хабов и линков, фактически добавление сведется к прокидыванию хабов и линков через PeerDB в CH, и последующее их использование на сильвер и год уровнях. Таблица на PeerDВ прокидывается наилегчайшим способом, в районе 5-15 минут, если у вас готова архитектура. Корректировка views может занять более длительное время, зависит от того, нужны ли вам таблицы пред расчета. Если нет, то я полагаю это будет дополнительным джоином в готовые views или же написания новой. Если да, то важен аспект какой именно сложности пред расчет. Думаю по описанному объему работ, сможете оценить время выполнения.
Тут подчеркну, что в последнем абзаце вы сами подчеркиваете, что аналитик прекрасно знает, что ему в dbt надо править, то есть правка любого SQL не должна вызывать вопросов, то есть потенциально, это более легкий подход, чем лезть связку "airflow+dbt+spark" . Я полагаю, что вы сетуете на непрозрачность самого пайплайна, именно этот вопрос призван решить dbt (об этом упомянуто в статье).
Airflow в этой схеме фактически имеет смысл, когда появляются внешние интерфейсы, от которых зависят даги, по типу загрузка в API, запуск при появлении в Kafka, S3 и т.д., то есть я говорю о сложной оркестрации. Когда это имеет место быть, спору нет, airflow лучшее решение. Однако, пока главная цель, это протекания пайплайна в одной БД, не совсем понятно, зачем крутить дополнительный оркестратор.
Spark же фактически призван решить проблему не надежности, а проблему масштабируемости. Учитывая, тот рабочий объем, который указан в статье, это явно избыточное решение, поэтому я говорю о оверхеде. Оно приведет к замедлению процессов, не увеличив ни скорость, ни надежность.
Когда у вас данных терабайты в сутки, а ETL требует шаффла/оконных функций, я с вами полностью соглашусь. В данном примере это избыточно.
Правильно ли я понимаю, что предложение состоит в том, чтобы поверх dbt навесить еще спарк и airflow? Если так, то это оверхед архитектура, которая не приносит очевидных плюсов, но принесет затраты на инфру + тайминг на новые реализации заметно вырастает. Непонятно где именно мы получим плюсы в надежность? На мой взгляд, дбт всецело закроет эту проблему
Изначальная идея dbt и есть в этом, чтобы крайне быстро реагировать на изменения в бизнес логике, чего не могут себе позволить airflow и spark на текущий момент. Лишний джоин аналитику добавить всегда проще, чем идти и изменять спарковский код в airfllow. + меньше затрат на инфру
Не могу с вами согласится. Давайте по пунктам:
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 преждевременная оптимизация и дорогая! Фактически только увеличит точки отказа без особого профита в надежности и скорости. При появлении внешних зависимостей - я полностью соглашусь с вами, а пока такое решение экскаватором картошку сажать.
Тут важен объем новых хабов и линков, фактически добавление сведется к прокидыванию хабов и линков через PeerDB в CH, и последующее их использование на сильвер и год уровнях. Таблица на PeerDВ прокидывается наилегчайшим способом, в районе 5-15 минут, если у вас готова архитектура. Корректировка views может занять более длительное время, зависит от того, нужны ли вам таблицы пред расчета. Если нет, то я полагаю это будет дополнительным джоином в готовые views или же написания новой. Если да, то важен аспект какой именно сложности пред расчет. Думаю по описанному объему работ, сможете оценить время выполнения.
Тут подчеркну, что в последнем абзаце вы сами подчеркиваете, что аналитик прекрасно знает, что ему в dbt надо править, то есть правка любого SQL не должна вызывать вопросов, то есть потенциально, это более легкий подход, чем лезть связку "airflow+dbt+spark" . Я полагаю, что вы сетуете на непрозрачность самого пайплайна, именно этот вопрос призван решить dbt (об этом упомянуто в статье).
Airflow в этой схеме фактически имеет смысл, когда появляются внешние интерфейсы, от которых зависят даги, по типу загрузка в API, запуск при появлении в Kafka, S3 и т.д., то есть я говорю о сложной оркестрации. Когда это имеет место быть, спору нет, airflow лучшее решение. Однако, пока главная цель, это протекания пайплайна в одной БД, не совсем понятно, зачем крутить дополнительный оркестратор.
Spark же фактически призван решить проблему не надежности, а проблему масштабируемости. Учитывая, тот рабочий объем, который указан в статье, это явно избыточное решение, поэтому я говорю о оверхеде. Оно приведет к замедлению процессов, не увеличив ни скорость, ни надежность.
Когда у вас данных терабайты в сутки, а ETL требует шаффла/оконных функций, я с вами полностью соглашусь. В данном примере это избыточно.
Правильно ли я понимаю, что предложение состоит в том, чтобы поверх dbt навесить еще спарк и airflow? Если так, то это оверхед архитектура, которая не приносит очевидных плюсов, но принесет затраты на инфру + тайминг на новые реализации заметно вырастает. Непонятно где именно мы получим плюсы в надежность? На мой взгляд, дбт всецело закроет эту проблему
Изначальная идея dbt и есть в этом, чтобы крайне быстро реагировать на изменения в бизнес логике, чего не могут себе позволить airflow и spark на текущий момент. Лишний джоин аналитику добавить всегда проще, чем идти и изменять спарковский код в airfllow. + меньше затрат на инфру
Поправлено, кэп! Спасибо за внимательность!