Как я собрал эталонный Data Engineering проект: ClickHouse, Kafka, Spark, dbt, Airflow и Superset за одну команду

[ToxaBes]

Спасибо за статью! У вас получился хороший базовый пайплайн для работы с данными. Интересно будет прочитать продолжение.

[Ninil]

Почему именно Spark, а не ClickHouse SQL?

Вам не кажется, что это оверинжениринг и ваше обоснование неверное? Кликхаус изначально заточен на аналитические нагрузки и может горизонтально масштабироваться. Для Спарка же вам нужна отдельная инфраструктура и этого доп Косты, плюс вы гоняйте данные туда-сюда между двумя системами - в случае больших данных это дополнительные затраты на сеть как минимум (нередко это самая узкое место). Особенно забавно то, что в итоге все равно все ваши преобразования - это обычный SQL.

[GenomeDust]

Да, для текущих объёмов хватило бы и хранимой процедуры — тут вы правы. Spark тут скорее задел: отработать паттерн его применения в проде и развести ответственность по слоям. Если упростить: ClickHouse — для селектов и аналитики по тому, что в нём лежит; Spark — когда нужен тяжёлый ETL или произвольные трансформации перед загрузкой. Если же вопрос был в том, что вам в принципе ближе считать всё внутри БД — это резонная позиция, для такого профиля нагрузки она вполне рабочая.

[Ninil]

У вас про это в обосновании не написано. Кроме того, обоснование апеллирует к невалидному утверждению.

Ну и вообще, мешать в одном проекте clickhouse, spark и дбт - совсем не тянет на эталонный проект. Явный овер инжениринг. При этом обоснование его необходимости не приведено (но не спорю, что иногда оно может быть)

[GenomeDust]

Ну и вообще, мешать в одном проекте clickhouse, spark и дбт - совсем не тянет на эталонный проект.

Можете объяснить, почему? Я понимаю, что на текущих объемах спарк лишний, я согласен. Его смысл в том, чтобы покрыть актуальный стек в пет проекте. Но на реальныо больших объемах, вы тоже предлагаете все посчитать силами SQL?

[Ravius]

Разделяйте где проходят вычисления и хранение данных.

Классный набор инструментов, но для задачи (витрины?) - не нужно так много.

Клик умеет в материализованные таблицы, и в вашем кейсе клик всегда посчитает сам, без спарка. (У вас такой набор данных, что сколько бы тикеров вы не добавляли - SQL справится, а если не справится, то уже в вычислительная слое и вам нужно разные данные писать на разные шары клика. Т.е. другой уровень оптимизации. И спарк вам тут не поможет.

Спарк это про распределенные вычисления, а не нарезка по "дням".

Как набор инструментов - крутая статья, как финальное решение под конкретную задачу - нет. Тут нужно выкинуть половину и оставить сервис загрузки и клик, даже airflow выкинуть. Даже в прод-проде.

У вас 1 сервис встанет из-за соседней команды, и все, нет аналитики.

[Ninil]

В дополнении в пред комменаторию.

Перекрытие ролей:

• Spark — движок для распределённой обработки данных и трансформаций.

• dbt — тоже про трансформации данных, только декларативно через SQL.

• ClickHouse — аналитическая СУБД, которая сама умеет выполнять довольно тяжёлые трансформации.

В итоге возникает вопрос: где именно должна жить бизнес-логика? Через год никто не понимает, где искать ошибку.

Ну и подерживать такой зоопарк накладно. Все эти компоненты имеют разные модели эксплуатации: зависимости, мониторинг, деплой, права доступа, CI/CD и т.п.

[Zotann]

Да что за тупая нотация Bronze, Silver, Gold? Есть же общепринятые сокращения названия слоев данных ods, dds,raw и другие

[Ninil]

В целом согласен, но все же поправлю: Bronze это Stage, а ODS - это Operational Data Store - то есть силы для получения операционной отчётности(его в Медальонной Архитектуре вообще не заявлено), а не сырые данные

ПыСы тоже имею зуб на Датабрикс за то, что угоду маркетингу попали ребрендинг и присвоили себе “азбуку”

[BigD]

Чаще встречаю как раз металлы на просторах интернета.

[Ninil]

Потому что просторы интернета завалены говно-статьями с пересказом документации и прочих банальностей и нейрослопом от индусов, которые очень активно начали писать в последние несоклько лет. Даже знаю из первых рук зачем - качание собственного бренда, а иногда даже получение визы таланта США (реально знаю несколько кейсов). Ценность этих статей - ноль. Зато шум создают…