Как договориться о зарплате повыше, когда тебе уже сделали оффер 💵

Многие боятся торговаться 😱 Кажется, что компания сразу передумает и наймет кого-то другого. На самом деле, если вам уже прислали оффер, значит, вы им подходите, и они уже потратили кучу времени на собеседования. Им проще докинуть вам денег, чем начинать поиск заново.

Вот как я советую делать, чтобы получить условия получше 🍪:

1. Сначала узнайте реальные цифры 🔺
Поспрашивайте в чатах или у знакомых, сколько на самом деле платят в этой компании на вашей позиции. Нужно понимать их потолок, чтобы не просить невозможного, но и не скромничать.

2. Используйте запасной вариант 🤫
Самый рабочий способ, сказать, что у вас есть другое предложение, где платят больше. Даже если его нет прямо сейчас, ведите себя так, будто вы востребованы.

Что сказать HR 🧑‍💻:

«имя», привет! Спасибо за оффер, мне всё нравится по задачам, и я бы очень хотел работать именно у вас. Но у меня на руках есть оффер в X на N рублей. При этом ваша команда мне ближе по духу. Давайте подумаем, как нам сойтись по деньгам, чтобы я мог сразу выйти к вам и закрыть вопрос с поиском?

Вы не просто просите денег, а показываете, что вы ценный кадр. HR гораздо проще сходить к начальству и выбить для вас бюджет, если есть весомый повод 🗣

Кандидат отличный, хочет к нам, но его переманивают деньгами

В 80% случаев вам либо дадут всю сумму, либо предложат какой-то бонус или пересмотр зарплаты через пару месяцев. В любом случае, вы ничего не теряете. От офферов из-за вежливого торга не отказываются

Было полезно? Ставь 🔥

Раньше дата инженер просто перекладывал данные из одной папки в другую. Сейчас этого стало мало…

Раньше от нас ждали только работающие пайплайны. В 2026 году нужно понимать, как устроена вся платформа целиком 📚Где данные лежат, как они меняются и почему бизнес может им доверять. Специалист теперь должен быть более универсальным

Сейчас рынок требует понимания инструментов, которые актуальны и могут навести порядок в данных🌪

Собрал подборку, что надо знать, чтобы быть в тренде:

⏺Lakehouse и Apache Iceberg: С увеличением количества данных и требованиям к их консистентности такой вид хранилища становится все более предпочтительным.
⏺Trino: универсальный движок для подключения к разным бд.
⏺dbt: необходим, чтобы логика трансформаций была прозрачной и с тестами, а не превращалась в черный ящик.
⏺OpenMetadata: необходим, чтобы через месяц не гадать, откуда пришла эта таблица и кто её наполнил.
⏺Kubernetes: платформа на которой сейчас крутится почти всё - от Airflow до Spark.

Важный момент: Успешно растет тот, кто умеет собрать систему, которая не падает каждые пять минут и понятна всей команде ☝

Если хотите разобраться, какие именно инструменты учить на вашем уровне, чтобы не тратить время впустую: загляните в мой роудмап 📍. Там я подробно расписал стек под каждый грейд: от стажера до сеньора.

❗️Забирайте роудмап здесь: ЧИТАТЬ

Кстати, какой инструмент из списка вы уже используете, а какой кажется переоцененным? Пишите в комментариях, обсудим

Почему UPDATE в ClickHouse плохая идея 👎 (и чем его заменить)

⚠️полезно для собесов👇

Многие приходят в ClickHouse из классических баз типа Postgres и поэтому очень хочется написать привычный UPDATE. В ClickHouse это очень плохая идея! 🚮

ClickHouse - это OLAP. Он создан для быстрой записи и чтения миллиардов строк, а не для того, чтобы менять одну ячейку в середине таблицы.

Почему обычный UPDATE — это дорого?

Классические обновления в ClickHouse работают через мутации. Если упростить: база не меняет значение на месте, а переписывает целые куски данных (parts) на диске. Хотели поменять статус у пары юзеров - заставили сервер перелопатить гигабайты данных ☹️ Если таких апдейтов много, очередь мутаций забьет диск и база просто встанет.

Как делать правильно:

1️⃣ReplacingMergeTree для Upsert-сценариев.
Не обновляем старую строку, а вставляем новую версию. ClickHouse сам схлопнет их при фоновом мерже. Идеально для CDC-потоков и профилей пользователей. Да, в запросах может понадобиться FINAL, но это честная цена за производительность.

2️⃣Append-only для событий.
Если у заказа меняется статус (создан -> оплачен -> доставлен), не надо менять одну строку. Пишите историю событий. Текущее состояние вынимается через argMax за доли секунды.

3️⃣Агрегаты через Materialized Views.
Вместо того чтобы обновлять счетчик покупок, пишите сырые события, а суммы считайте через агрегирующие движки (AggregatingMergeTree).

4️⃣CollapsingMergeTree. Он работает через специальную колонку Sign: строка с Sign = 1 считается актуальным состоянием, а строка с Sign = -1 “отменяет” старую запись. При merge ClickHouse схлопывает такие пары строк с одинаковым ключом. Это полезно, когда у вас поток изменений устроен как добавить новое состояние и погасить старое, но для базового upsert чаще проще начать с ReplacingMergeTree.

Итог: ClickHouse любит не изменения старых строк, а правильную модель записи новых.

Было полезно, ставьте 🔥

Периодически спрашивают, где можно почитать отзывы о менторстве

Чтобы не искать, собрал всё в одном месте 👀

Там есть кейсы как ребят с опытом, так и тех, кто заходил в Data Engineering с нуля

🔗 ССЫЛКА НА КАНАЛ

Словари в ClickHouse: как ускорить аналитику и разгрузить базу

🖥 В ClickHouse есть полезный инструмент, о котором часто забывают - Dictionaries (словарь)

Если совсем просто:

Это маленький справочник, который хранится в памяти и помогает не делать JOIN для небольших таблиц. Вместо JOIN с маленькой справочной таблицей (например, users, country, user_id) вы просто используете `dictGet`, чтобы быстро подтянуть нужные значения: country, category, segment и так далее.

dictGet('users', 'country', user_id).

🤓Здесь:
users — имя словаря
country — имя колонки (атрибута), которую хочешь получить
user_id — ключ, по которому ищем (например, id пользователя)

Это часто работает быстрее, потому что:

⏺Данные уже подготовлены для быстрого поиска

⏺ClickHouse не тратит лишние ресурсы на большой JOIN там, где нужен только один атрибут

⏺В некоторых случаях может использоваться очень быстрый механизм join-подобного доступа.

Когда dictionaries особенно полезны:
✅Когда нужно обогатить события: например, подтянуть страну, сегмент или категорию товара

✅Когда справочник небольшой и часто используется

✅Когда нужен простой поиск по ключу, а не сложное соединение таблиц

Когда лучше не использовать:
❌Если вы часто фильтруете по значению из словаря, например WHERE dictGet(...) = 'DE'
В таких случаях лучше хранить нужное поле прямо в основной таблице

❌Если справочник очень большой и плохо помещается в память

❌Если нужна мгновенная синхронность с источником данных

📖Если хотите закрепить, советую прочитать эту статью

А вы пользовались словарями?

Код теперь за нас пишет нейронка. А дебажить кто будет?

Честно говоря, я уже не помню, когда последний раз писал даг с нуля своими руками… Теперь пользуюсь нашими друзьями ChatGPT( Claude и др) 🐶 Они набросают скелет и расставит операторы за вас за секунды!

Но в этом и ловушка. ИИ не несет ответственности за ваш прод 💻 Он не знает про лимиты ресурсов, не понимает логику logical_date и не видит, как два процесса в фоне убивают друг друга

Умение писать код сейчас базовый навык 🤍 Но именно умение видеть архитектурные ошибки и понимать, как всё работает под капотом делает вас дата инженером 👊

Подготовил 3 кейса на дебаг и отладку Airflow из реальной практики ❤️⚠️

1) Про даты: почему datetime.now() - это мина замедленного действия

2) Про backfill: как одной кнопкой запустить 500 дагов и положить планировщик

3) Про конкурентность: почему данные дублируются при параллельных запусках

🎁Забирайте файл, пробуйте разобраться сами: ССЫЛКА

Как вам такой формат? Делать еще вам такие файлики с заданиями👇

Шпаргалка по собесам, которую не стыдно перечитать за день до

Прошёл через десятки интервью и как кандидат, и как тот, кто помогает с этим другим. Вот что реально работает:

👀 Тебя оценивают до первого вопроса
Свет, фон, ракурс камеры считывается за первые секунды. Свет перед лицом и камера чуть выше глаз. Минута настройки, которая меняет первое впечатление.

👀 Исследуй компанию глубже, чем остальные
Не просто почитай сайт. Найди технический блог, статьи на Habr от их инженеров. Упомяни это на собесе. Сразу видно человека, который хочет именно сюда, а не просто рассылает резюме всем подряд

📵 Резюме под каждую вакансию
Большинство отправляет одно резюме всем. Если в вакансии написано Spark и Airflow - эти слова должны быть в твоём резюме на видном месте. ATS-системы отсеивают кандидатов ещё до живого человека.

🔖Не рассказывай, а показывай стек
Работал с большими данными слышат все.

Попробуй иначе:
Собирал данные из ClickHouse и Kafka, строил пайплайны на Spark, оркестровал в Airflow, мониторил через Grafana
Интервьюер уже видит твой стек, без дополнительных вопросов.

✅Готовь истории, а не ответы
На расскажи про сложный кейс шпаргалка не поможет. Заранее вспомни 2-3 реальные ситуации: что была за задача, что пошло не так, как решил. Это универсальная заготовка под половину вопросов на любом собесе.

😅 Говори про ошибки
Вопрос про провалы будет точно. Расскажи, что упало, как починил и что изменил после. Именно так выглядит человек, которому можно доверять.

💵 Зарплата - называй цифру
Диапазон - приглашение торговаться вниз. Одна конкретная сумма, спокойный тон, без оправданий. Если давят - мои ожидания такие, готов обсуждать остальные условия)

❓Задавай вопросы сам/а
В конце собеса спроси что-то про команду или процессы:
— Как выглядит типичный пайплайн в вашей команде?

— Как устроен онбординг?

— Какие задачи будут первые три месяца?

Это показывает, что ты думаешь на перспективу. И выделяет тебя среди тех, кто просто отвечает на вопросы.

💬 После собеса напиши короткое сообщение
Просто: Спасибо за разговор, было интересно узнать про X. Пишут не многие. Уточняй сроки и не жди молча

В конце спроси: Когда примерно ждать обратную связь? Если в срок не ответили - напиши первым. Это не навязчивость, это нормальный контроль процесса.

🗂Записывай вопросы после каждого собеса
Завёл отдельный файл - записываешь всё, что спросили. Через 5-6 собесов у тебя будет личный банк реальных вопросов именно по твоему уровню и стеку. Это лучше любого списка из интернета.

Это база, но именно на ней чаще всего и спотыкаются😎

💾Сохрани себе - пригодится перед следующим собесом)

Что делать, если твой Spark-кластер из 200 воркеров работает как один 🐌

Запускаешь джобу на 200 воркеров, а вся нагрузка едет на одном узле, пока остальные 199 простаивают🥺

Это data skew - неравномерное распределение данных по партициям. Spark делит данные по ключу (обычно при join или groupBy), и если один ключ встречается в разы чаще остальных - весь воркер, который его обрабатывает, становится бутылочным горлышком. Время выполнения джобы определяет не средний воркер, а самый перегруженный.

Заметить просто: открой Spark UI - один или несколько тасков выполняются заметно дольше остальных, иногда доходит до OOM (out of memory) на конкретном экзекьюторе.

Что с этим делать 🤔

Adaptive Query Execution - начни отсюда ▶️

В Spark 3.x можно включить adaptive query execution со skew join handling прямо в конфиге. Spark сам на лету разобьёт перегруженные партиции. Закрывает большинство случаев без единой строчки кода.

Broadcast join, если одна таблица маленькая📊

Можно разослать маленький датасет на все экзекьюторы и обойтись без шаффла полностью. Часто проще и быстрее, чем что-либо солить.

Salting, если ничего не помогло🧂

Добавляешь к перегруженному ключу случайное число - соль. Один огромный партишн превращается в несколько поменьше. Для join большую таблицу солишь, а маленькую размножаешь под каждое значение соли. Это последний инструмент, не первый — усложняет код, и если есть способ попроще, лучше им и обойтись.

🔖полезно почитать дополнительно

Если было полезно, ставь 🔥

DE vs DS vs DA: чем отличаются и что выбрать

Давайте разберем чем одна профессия лучше другой 🤗

Кто чем занимается:

🏗 Data Engineer строит инфраструктуру для данных: пайплайны, хранилища, интеграции, качество и доставку данных. Результат виден чётко: пайплайн либо работает, либо нет.

💡Data Scientist ищет закономерности, проверяет гипотезы, строит модели и пытается понять, что скрыто в данных. Здесь много экспериментов, статистики и работы с неопределенностью.

🤔 Data Analyst помогает бизнесу принимать решения на основе данных: собирает отчеты, делает дашборды, анализирует метрики и объясняет, что стоит за изменениями в цифрах.

Где разница ощущается сильнее🤔

У DS результат часто зависит от вещей, которые не всегда можно контролировать: качество данных, сезонность, поведение пользователей, дрейф модели. В ноутбуке всё может выглядеть отлично, а в реальной среде модель уже ведет себя совсем иначе.

У DE результат более понятный и проверяемый: данные либо приехали вовремя, либо нет; пайплайн либо отработал, либо упал. У аналитика похожая логика - либо цифры актуальны и помогают принять решение, либо нет.

Про вход с нуля🤵‍♀️
В аналитике часто вход кажется самым простым: меньше математики, меньше тяжёлого кода, больше понятных бизнес-задач. Но из-за этого и конкуренция выше - туда приходит много людей после курсов и из смежных сфер.

Порог входа в DE ниже не потому, что профессия проще. На старте обычно достаточно SQL, Python и баз данных, а остальные инструменты осваиваются по мере работы.

В DS порог выше из-за статистики и математики: без этого сложно не только построить модель, но и понять, почему она работает именно так😔

Что выбрать:
Если нравится строить системы и видеть конкретный технический результат — Data Engineer

Если интересно работать с гипотезами, экспериментами и моделями — Data Science

Если хочется быть ближе к продукту и бизнес-решениям — Data Analyst

Все три направления востребованы. Но это разные типы работы, и лучше понять это заранее, чем потом долго переучиваться👆

Посмотрите побольше видосиков на эту тему, почитайте статьи, поспрашивайте людей из этих сфер, чтобы не потратить время на подготовку не в ту сторону.

🔖Записал для вас видео, где подробнее говорю на эту тему. Чем больше 🔥, тем быстрее выложу)

Новое видео на ютуб ⛔️

Бегом смотреть😆:
YOUTUBE
RUTUBE

P.s. лайки, комментарии и подписка очень мотивируют снимать дальше

🗂 Навигатор по техническим постам

Собрала все статьи канала в одном месте — сохраняйте, чтобы не потерять 👇

🧭 Старт в профессии
Как я стал дата-инженером

Как я получил оффер на Джуна в ML


⚙️ Основы Data Engineering
Что такое ETL и ELT?

OLTP и OLAP

Что такое оркестратор данных

Взрыв дублей при JOIN

Разный grain таблиц и как его фиксить

〰️ Базы данных и хранилища
Oracle

HDFS

Объектное хранилище (object storage/ S3)

Redis

Parquet и ORC


🏔 Data Lake / Lakehouse
Lake house
Data Vault и Anchor Modelling

Apache Iceberg: зачем он нужен и почему вокруг него шум. Надежность и ACID в Data Lake.
Сравнение Delta Lake и Apache Iceberg.

🏠 ClickHouse
Click House

Click House (гранулы, ORDER BY и индексы)

Почему UPDATE в ClickHouse — это плохая идея

Dictionaries в ClickHouse: как ускорить аналитику


⚙️ Обработка больших данных
Map Reduce

Как кластеры делят ядра и гигабайты: управление ресурсами при обработке больших данных

Почему Spark вытеснил MapReduce

Spark за 2 минуты

Data Skew в Spark: что делать, eкогда один воркер перегружен. Разбор Spark UI, AQE и Salting.

🔄 Оркестрация и пайплайны
Airflow

3 практических кейса на дебаг Airflow.


💬 Стриминг и брокеры сообщений
Что такое брокеры сообщений

Kafka

Kafka vs Rabbit MQ

Apache Flink

Как устроен стриминг данных, и зачем он нужен

Debezium

Как работают CDC пайплайн


🧩 Query-движки
Trino

🏗 Архитектура и качество данных
Как собрать систему, которая не падает

Data Quality и контракты данных

Новая статья на VC!

Вспомните или узнаете про UPDATE в ClickHouse🏠

ССЫЛКА

P.S. буду благодарен за лайк и комментарий 😛

Рынок в Data Engineering, лето 2026??⚙️

Рынок изменился, и это факт. Но важно понимать: он не умер. За последние две недели 5 моих учеников уже получили офферы 👊, поэтому вакансии есть, но конкуренция стала заметно выше.

Если раньше для оффера на Junior/Middle позицию достаточно было знать теорию и пару инструментов, то в 2026 году требования взлетели. Сейчас на собеседованиях мало просто понимать технологии. От тебя ждут глубоких деталей и умения рассказать, как ты решал настоящие проблемы в продакшене.

Мое менторство — это не курс с лекциями, а полноценный цикл подготовки, где я делюсь своим опытом и ресурсами, чтобы сделать из тебя инженера, который не развалится под давлением на интервью.

Как мы будем идти к результату🥇🥇

Мы не просто учим теорию, мы строим твой профессиональный профиль шаг за шагом. 📍Сначала мы анализируем твой бэкграунд и составляем индивидуальный роудмап, отсекая лишнее и фокусируясь на том, что реально спрашивают. Если нужно, подтягиваем базу (SQL, Python, алгоритмы), а затем переходим к глубокой практике. Мы разбираем задачи в формате реальных интервью, работая с кейсами по Spark, Airflow и Kafka. Чтобы закрепить навыки, мы создаем пет проект.

Но мало уметь — нужно уметь продать. 📵 Поэтому основной упор мы делаем на этап упаковки и проработки легенды.

⭐️️️️️Ты получишь доступ к моей базе закрытых видео, где на примерах из реальных проектов показано применение инструментов в проде. Уже сейчас там есть подробные разборы по Iceberg, Spark, Greenplum и Kafka, и база активно пополняется. Это живой опыт бигтеха: как устроены данные, почему выбраны именно эти технологии и какие нюансы всплывают при их внедрении. Имея такие примеры перед глазами, подготовить свою легенду становится в разы проще.

Плюс к этому — доступ к базе из 25+ реальных собеседований, чтобы ты точно знал/а, какие каверзные вопросы тебя ждут.

Когда ты будешь готов/а, мы выходим на рынок. Я сопровождаю тебя на этапе откликов, мы анализируем каждый фидбек и докручиваем слабые места. После получения оффера (а мои ученики выходят на 250к–375к+) наша работа не заканчивается. 🫱‍🫲 Я остаюсь с тобой на испытательный срок (первые 3 месяца), помогая адаптироваться и решать первые рабочие задачи.

Комьюнити DE 👥

Попадая на менторство, ты становишься частью закрытого комьюнити. Ребята делятся рефералками в свои компании, скидывают сливы с актуальных собесов и проводят друг другу пробные интервью. Каждую пятницу устраиваем групповые созвоны, где обсуждаем как проходят собесы или подготовка.

А для тех, кто в Москве, у нас есть особый бонус — в это воскресенье мы проводим нашу первую живую встречу только для участников комьюнити. Будем знакомиться лично и общаться в неформальной обстановке 🙂

Условия участия🤝

✨Отзывы говорят сами за себя: прочитать реальные отзывы

Хочешь так же?
Пиши — проведём короткий бесплатный созвон, разберём твой бэкграунд и цели: @ampodvalniy 🔥

Если у тебя остались вопросы, задай их в комментах или напиши в личку!

13 параметров Spark, которые стоит знать перед собеседованием

Надеюсь все правильно ответили в предыдущем опросе, но в любом случае советую освежить память или узнать что-то новое🔥Перечислил самые популярные параметры Spark, которые реально встречается в конфигах и на проде

💦 Ресурсы

spark.executor.instances

  — сколько executors поднимется для приложения.

spark.executor.cores 

— сколько ядер выделяем на один executor.

spark.executor.memory

  — heap-память executor’а.

spark.executor.memoryOverhead

  — память вне heap: Python worker’ы, native memory, shuffle buffers и другие внехиповые расходы.

  spark.driver.memory /  spark.driver.cores  

— ресурсы драйвера.

😶‍🌫️Параллелизм

spark.default.parallelism 

— дефолтное число партиций для RDD-операций.

spark.sql.shuffle.partitions 

— число партиций после shuffle в Spark SQL.

spark.sql.files.maxPartitionBytes

  — максимальный размер данных на одну input partition при чтении файлов.

spark.sql.files.openCostInBytes  

— помогает Spark лучше группировать мелкие файлы при чтении.

🤩Оптимизация

spark.sql.adaptive.enabled

  — включает AQE: Spark может динамически менять число shuffle-партиций и улучшать план выполнения.

spark.sql.autoBroadcastJoinThreshold

  — порог, при котором Spark может выбрать Broadcast Join.

spark.dynamicAllocation.enabled

  — динамически увеличивает и уменьшает число executors.

spark.sql.adaptive.skewJoin.enabled

  — помогает бороться с data skew на join’ах.

Если коротко: на собесе важно не просто помнить названия, а понимать, за что отвечает каждый параметр — ресурсы, параллелизм, shuffle, память и join-стратегии

🐈Полезные статьи:

⏺Подбираем параметры сессии в Apache Spark

⏺Как правильно просить ресурсы и как понять, сколько нужно брать

⏺6 сегментов памяти Apache Spark и параметры их конфигурирования

Что спрашивают в Бигтехе: вопросы по Iceberg и Trino из закрытого канала

В вакансиях всё чаще мелькает связка Iceberg + Trino + S3. Тренд понятный: многие компании сейчас мигрируют с классических СУБД на объектные хранилища и ищут инженеров под эти задачи🚨

Если планируете выходить на рынок, к вопросам по этому стеку нужно быть готовыми. Собрал список того, что реально спрашивают на собесах — инсайды от ребят из нашего закрытого канала.

Некоторые вопросы требуют понимания того, как это работает в бою, поэтому если опыта нет — придется включать фантазию и строить гипотезы 😅 Попробуйте ответить на них, чтобы подсветить свои пробелы.

Для тех, кто совсем не в теме, сначала прочитайте базу:
🗻 Iceberg
🚀 Trino
📁 S3

Список вопросов с собеседований:
1. Зачем нужен Iceberg? В чем его реальные преимущества перед обычными Hive-таблицами?
2. Какие у формата есть минусы и «подводные камни»?
3. Обслуживание таблиц: Как следить за размерами файлов и как правильно делать компакцию (очистку мелких файлов)?
4. Логическая структура: Как выстраивали архитектуру хранилища? На какие слои делили данные?
5. Разделение ролей: Для каких задач использовали Trino, а для каких — Spark? По каким критериям разграничивали нагрузку?

Получилось ответить на всё или где-то поплыли❓Пишите в комментах, какие вопросы вызвали больше всего затыка — разберем🔥

Кстати в нашем закрытом сообществе ребята постоянно делятся свежими собеседованиями)

Не забывай, что можешь записаться на первый бесплатный созвон для обсуждения деталей менторства и вашей текущей точки @ampodvalniy ⭐️

Зачем нужен dbt, если есть Spark и ClickHouse?

Многие до сих пор путают dbt (Data Build Tool) с вычислительными движками. Давайте сразу: dbt сам ничего не считает🚨

Он не заменяет Spark, Trino или ClickHouse. dbt — это инструмент для организации трансформаций внутри вашего хранилища🖥Он превращает разрозненные SQL-скрипты в полноценный инженерный проект с тестами, документацией и зависимостями.

В чем суть?

Без dbt вы сами следите за тем, в каком порядке запускать скрипты. С dbt вы просто описываете модели, а инструмент сам строит DAG.

Например:

stg_users → stg_orders → mart_sales

Зачем нужен dbt 🤔

dbt сам поймет, что витринаpark и ClickHoне соберется, пока не готовы стейджинги, и запустит всё в правильной последовательности.

Что он дает на практике:

✔️ Управление зависимостями: Автоматическое построение графа (DAG).
✔️ Тестирование: Можно из коробки проверять данные на NOT NULL, UNIQUE или проверять внешние ключи.
✔️ Документация: dbt сам генерирует описание моделей и связей между ними.
✔️ Версионирование: Весь ваш SQL живет в Git как код.

Кто тогда считает?

dbt - это мозг, а не мышцы. Он просто отправляет SQL-код в ваш вычислительный движок: Spark, Trino, ClickHouse или Postgres🖥 Именно они делают тяжелую работу (JOIN, GROUP BY), а dbt управляет этим процессом.

Итог: dbt приносит в мир аналитики лучшие практики разработки. Это мастхэв, если вы хотите строить поддерживаемые и надежные витрины, а не просто плодить горы SQL кода🔥

Почитать по теме:
🔗 DBT: трансформация данных без боли
🔗 DBT в продакшене

Flink vs Spark Streaming: что выбрать для Data Lakehouse

Если совсем просто, Flink и Spark Streaming - это инструменты, которые обрабатывают данные на лету➡️

То есть не ждут конца дня, чтобы всё пересчитать, а работают с событиями почти сразу, как только они появляются🌟

🐿Что делает Flink:

Flink нужен там, где данные идут непрерывным потоком: из Kafka, из логов, из CDC, из событий приложения.
Он умеет сразу принимать эти события, обрабатывать их и писать результат дальше, например, в Iceberg, Hudi или Delta Lake.

Проще говоря, Flink - это потоковый двигатель.
Он хорошо подходит для задач, где важна свежесть данных: почти мгновенные обновления, подсчёты по окнам времени, дедупликация, обработка изменений из баз.

Что делает Spark Streaming⭐

Spark Streaming тоже умеет работать с потоком данных, но его подход немного другой. Он исторически вырос из batch-мира, то есть из обработки больших пачек данных.

Поэтому поток он обрабатывает как маленькие батчи (микробатчами), небольшие порции данных, которые идут одна за другой.

Это нормально, если тебе не нужна супер-низкая задержка и если у команды уже вся архитектура построена на Spark.

В чём разница:

➖Flink - когда нужен настоящий live-streaming и минимальная задержка

➖Spark Streaming - когда потоковая обработка нужна, но ты уже живёшь в Spark-экосистеме и хочешь не менять стек

Где, что используют в Data Lakehouse 🟦

В Lakehouse-архитектуре обычно так:

⏺Flink — забирает события, обрабатывает их и пишет в таблицы lakehouse.
⏺Trino — потом читает эти таблицы через SQL.
⏺Spark — часто используют для тяжёлых batch-вычислений и больших пересчётов.

🤓Почитать дополнительно:

⏺Введение в Apache Flink: архитектура и основные концепции

⏺Стриминговые фреймворки: Apache Flink

Было полезно? Ставь 🔥