Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 13
Спасибо за статью! У вас получился хороший базовый пайплайн для работы с данными. Интересно будет прочитать продолжение.
Почему именно Spark, а не ClickHouse SQL?
Вам не кажется, что это оверинжениринг и ваше обоснование неверное? Кликхаус изначально заточен на аналитические нагрузки и может горизонтально масштабироваться. Для Спарка же вам нужна отдельная инфраструктура и этого доп Косты, плюс вы гоняйте данные туда-сюда между двумя системами - в случае больших данных это дополнительные затраты на сеть как минимум (нередко это самая узкое место). Особенно забавно то, что в итоге все равно все ваши преобразования - это обычный SQL.
Да, для текущих объёмов хватило бы и хранимой процедуры — тут вы правы. Spark тут скорее задел: отработать паттерн его применения в проде и развести ответственность по слоям. Если упростить: ClickHouse — для селектов и аналитики по тому, что в нём лежит; Spark — когда нужен тяжёлый ETL или произвольные трансформации перед загрузкой. Если же вопрос был в том, что вам в принципе ближе считать всё внутри БД — это резонная позиция, для такого профиля нагрузки она вполне рабочая.
У вас про это в обосновании не написано. Кроме того, обоснование апеллирует к невалидному утверждению.
Ну и вообще, мешать в одном проекте clickhouse, spark и дбт - совсем не тянет на эталонный проект. Явный овер инжениринг. При этом обоснование его необходимости не приведено (но не спорю, что иногда оно может быть)
Ну и вообще, мешать в одном проекте clickhouse, spark и дбт - совсем не тянет на эталонный проект.
Можете объяснить, почему? Я понимаю, что на текущих объемах спарк лишний, я согласен. Его смысл в том, чтобы покрыть актуальный стек в пет проекте. Но на реальныо больших объемах, вы тоже предлагаете все посчитать силами SQL?
Разделяйте где проходят вычисления и хранение данных.
Классный набор инструментов, но для задачи (витрины?) - не нужно так много.
Клик умеет в материализованные таблицы, и в вашем кейсе клик всегда посчитает сам, без спарка. (У вас такой набор данных, что сколько бы тикеров вы не добавляли - SQL справится, а если не справится, то уже в вычислительная слое и вам нужно разные данные писать на разные шары клика. Т.е. другой уровень оптимизации. И спарк вам тут не поможет.
Спарк это про распределенные вычисления, а не нарезка по "дням".
Как набор инструментов - крутая статья, как финальное решение под конкретную задачу - нет. Тут нужно выкинуть половину и оставить сервис загрузки и клик, даже airflow выкинуть. Даже в прод-проде.
У вас 1 сервис встанет из-за соседней команды, и все, нет аналитики.
В дополнении в пред комменаторию.
Перекрытие ролей:
Spark — движок для распределённой обработки данных и трансформаций.
dbt — тоже про трансформации данных, только декларативно через SQL.
ClickHouse — аналитическая СУБД, которая сама умеет выполнять довольно тяжёлые трансформации.
В итоге возникает вопрос: где именно должна жить бизнес-логика? Через год никто не понимает, где искать ошибку.
Ну и подерживать такой зоопарк накладно. Все эти компоненты имеют разные модели эксплуатации: зависимости, мониторинг, деплой, права доступа, CI/CD и т.п.
… Но на реальныо больших объемах, вы тоже предлагаете все посчитать силами SQL?
Что вы имеете в виду под “посчитать силами SQL”? SQL - это ЯЗЫК, а считает - ДВИЖОК. В вашем же примере ДБТ - это фреймворк который просто снижает накладные расходы (плюс ещё фишки) и упрощает работу с SQL и может потом этот SQL отравлять на разные execution engine. Или вы не понимаете то, что сами спроектировали?)
Да что за тупая нотация Bronze, Silver, Gold? Есть же общепринятые сокращения названия слоев данных ods, dds,raw и другие
В целом согласен, но все же поправлю: Bronze это Stage, а ODS - это Operational Data Store - то есть силы для получения операционной отчётности(его в Медальонной Архитектуре вообще не заявлено), а не сырые данные
ПыСы тоже имею зуб на Датабрикс за то, что угоду маркетингу попали ребрендинг и присвоили себе “азбуку”
Чаще встречаю как раз металлы на просторах интернета.
Потому что просторы интернета завалены говно-статьями с пересказом документации и прочих банальностей и нейрослопом от индусов, которые очень активно начали писать в последние несоклько лет. Даже знаю из первых рук зачем - качание собственного бренда, а иногда даже получение визы таланта США (реально знаю несколько кейсов). Ценность этих статей - ноль. Зато шум создают…
Стек выглядит как резюме, а не как задача: на 5 тикерах и минутках Spark с горизонтальным масштабированием реально считает то, что postgres вывезет на ноутбуке. Эталонный тут не проект, а демонстрация, что человек умеет всё это поднять одной командой — и это, кстати, отдельный навык.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я собрал эталонный Data Engineering проект: ClickHouse, Kafka, Spark, dbt, Airflow и Superset за одну команду