Проверь свою готовность к интервью на DE

Недавно выложил первое видео на 🌐про то, как рассказывать о своём опыте на собеседовании - если ещё не смотрели, держите ссылку.

Захотелось отдельно выложить популярные вопросы с собеседований по опыту для вашей тренировки

Можно попробовать на них ответить. Это отличная практика перед реальными интервью!

Готовы 🤨?

• Расскажите о системах, с которыми вы работали. Откуда поступали данные и куда они передавались? Какие инструменты использовались для этих операций?

• Имели ли вы опыт работы с Apache Kafka?

• Работали ли вы с S3 или аналогичными облачными хранилищами? Опишите ваш опыт.

• В каких форматах приходили данные?

• Какие были объёмы данных?

• Какие движки ClickHouse использовал?

• Какие у тебя были стриминг-потоки?

• Как оптимизировал Spark-джобы?

• Какие проблемы с производительностью возникали и как ты их решал?

Если сейчас на часть вопросов ответить сложно. Это нормально. Всё это можно быстро прокачать, разобрать инструменты и научиться уверенно отвечать на собеседовании.

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

Кстати, записал для вас вторую часть.Там как раз разбираю ответы на эти вопросы. Выйдет на следующей неделе!



На какой из этих вопросов вам сейчас сложнее всего ответить

Готовитесь к собеседованиям или уже активно ходите по ним? ⚠️🧑‍💻

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

Я записал второе видео, где в формате мок-интервью отвечаю на конкретные технические вопросы🤔Если вам не хватает своих кейсов или вы хотите звучать убедительнее - можете брать мои ответы и адаптировать их под себя.

Внутри разбор по этим пунктам:

⏺Опыт работы с Apache Kafka и стримингом.
⏺Работа с S3 и облачными хранилищами.
⏺Форматы и реальные объемы данных.
⏺Движки ClickHouse: что и когда использовать.
⏺Оптимизация Spark-джоб и решение проблем с производительностью.

Смотреть тут:
⛔️ YOUTUBE
📹 RUTUBE

Поддержите видео лайком и пишите в комментариях на какую тему снимать следующее видео! 🔽

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

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

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

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

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