ДА против ДЕ Крайние два года замечаю, что между Дата Аналитиками и Дата Инженерами часто бывают какие-то разногласия. Сейчас объясню, что имею в виду. Когда я ходил по собесам в прошлом и этом году, я часто задавал вопрос: «А у вас Аналитики на чем пишут витрины для ДЕ?». И в Газпромбанке кстати мне ответили, что прям принципиально перекатили ДА на спарк апи. Чтобы просто не переписывать код. Например, нужно построить витрину данных. Чаще всего это просто SQL-код от аналитика. Но проблема в том, что это не всегда какой-то ANSI-стандартный SQL. Это может быть ClickHouse со специфичными джойнами, а может быть огромная портянка Spark SQL, которую потом нужно расшивать, переписывать на Spark API и ещё оптимизировать. Короче, ощущение такое, что почти всегда приходится переделывать вместо того, чтобы сразу писать на чём-то “готовом”. Теперь архитектурно. У нас есть Data Lake — озеро данных. Там лежат сырые данные, предподготовленные слои и сами витрины. А в ClickHouse уже просто переносятся копии. В таком случае аналитику, по идее, надо уметь писать либо на Spark SQL / Spark API, либо на Trino. Но вот вопрос: как много ДА реально умеют в Spark API? А если писать сразу под ClickHouse, то некоторые функции при переносе на Spark всё равно приходится переписывать и переделывать. Это лишняя работа. И вот что тогда делать? Например, просить ДА сразу писать либо на Spark SQL, либо на Trino. А уже агрегаты в ClickHouse строить исключительно поверх готовых витрин. Я ещё задавался вопросом: а зачем вообще нужен Trino, если можно просто дать аналитикам готовые Spark-ноутбуки с конфигами, и пусть запускают свои запросы? Но в чате CedrusData мне ответили, что Trino как раз и внедряют для ad hoc-аналитики. Чтобы ДА не занимали Spark-кластер, не жрали ресурсы и могли просто зайти в DBeaver, написать понятный SQL и быстро получить результат. Без постоянного запуска Spark-сессий и настройки конфигов. И что получается в итоге? Либо ДА учат Spark API — и тогда они уже почти ДЕ. Либо пишут на Trino и передают этот код дальше. Либо пишут на Spark SQL. Кстати, Spark тоже можно запускать через DBeaver, но, как я понимаю, там уже не будет тех же удобных федеративных запросов, да и с настройкой всё сложнее. Короче, это скорее дискуссия. Мне самому искренне интересно, зачем столько инструментов. Почему мы не можем договориться писать всё на чём-то одном? И ещё была мысль от @shustDE, что из ДА в ДЕ переучиться легче, чем из ДЕ в ДА. Именно потому, что в аналитике всё-таки нужно больше логического и продуктового мышления. ДЕ — это чаще технари, которые меньше погружаются в бизнес-логику и больше занимаются процессами, инфраструктурой и стабильностью пайплайнов. Что думаете?
ДА против ДЕ Крайние два года замечаю, что между Дата Аналитиками и Дата…
Источник
https://t.me/halltape_data/838Канал Я – Дата Инженер | Евгений Виндюков · опубликовано 16 мая 2026 г.
Из этого канала
- #839Ребзя, хочу показать, какая у нас красота творится на Буткемпе. Сегодня для…
Ребзя, хочу показать, какая у нас красота творится на Буткемпе. Сегодня для всех Буткемперов доделал очередную лекцию по S3 и форматам хранения данных, которую…
- #846"Дорогие друзья!!! 🎉 Совсем скоро проекту Roadmappers исполнится 1 год. Первого…
"Дорогие друзья!!! 🎉 Совсем скоро проекту Roadmappers исполнится 1 год. Первого июля будет ровно год с того момента, как мы начали рассказывать про технологии,…
- #847"Сегодня проводим ""Онбординг"". Расскажем, что вас ждём первого июля на…
"Сегодня проводим ""Онбординг"". Расскажем, что вас ждём первого июля на Буткемпике и то как будут проходить занятия на тестовом прогоне. Врямя: 20:00 по МСК.
- #837"🚀 Data Engineer за 2 месяца Не кликбейт. Мы реально сделали супер интенсив за…
"🚀 Data Engineer за 2 месяца Не кликбейт. Мы реально сделали супер интенсив за 2 месяца в DE. Это буквально копия вашей будущей работы.
- #836Dbeaver переспал с DataGrip, и у них родилось это Меня тошнит от Dbeaver с его…
Dbeaver переспал с DataGrip, и у них родилось это Меня тошнит от Dbeaver с его дизайном от 1993 года.