(Ашан) Batch Data Platform для аналитики пользователей

Question 1

Какая была цель проекта?

Answer 1

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

Question 2

Кто были основные пользователи данных?

Answer 2

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

Question 3

Какие типы данных обрабатывались?

Answer 3

Обрабатывались данные о кликах пользователей, заказах, сессиях и профилях пользователей из PostgreSQL, внешних API и S3.

Question 4

Что за внешние API?

Answer 4

1) Партнёрские сервисы/поставщики данных: данные о промо-акциях, скидках, товарах.
2) Яндекс.Метрика

Question 5

А какие именно типы данных это были? Json, csv?

Answer 5

Из PostgreSQL данные забирались через Spark JDBC (spark.read.jdbc).
Из внешних API данные получали по HTTP в формате JSON, предварительно сохраняли в staging-слой, после чего обрабатывали в Spark.
Из S3 данные читались напрямую с помощью Spark DataFrame API.

Question 6

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

Answer 6

В среднем обрабатывалось несколько сотен гигабайт данных в день, общий объём хранилища — несколько терабайт.

Question 7

А куда пропападали данные? Если за несколько дней-недель уже получаются терабайты?

Answer 7

Сырые данные сохранялись в Data Lake в Parquet.
Для старых данных использовались retention-политики: часть архивировалась, часть удалялась по TTL, чтобы не разрасталось хранилище.
Агрегированные данные сохранялись в ClickHouse.

Question 8

А опиши весь пайплайн данных? Как выглядел high-level architecture пайплайна?

Answer 8

• Источники данных: PostgreSQL, внешние API, S3
• Обработка: Spark-задания для трансформации данных, оркестрированные Apache Airflow
• Хранилище: Data Lake на HDFS, аналитические таблицы и витрины в ClickHouse
• Потребление: BI-инструменты и дашборды для отчетности и аналитики

Question 9

Почему выбрали batch, а не streaming?

Answer 9

Выбрали batch-подход, потому что он упрощал архитектуру, был дешевле в поддержке, а бизнес-требования были ориентированы на ежедневную отчетность, а не на real-time сценарии.

Question 10

За какие части пайплайна ты отвечал лично?

Answer 10

Я отвечал за разработку и оптимизацию Spark задач на Python, создание и поддержку Data Lake и аналитических таблиц в ClickHouse, а также за построение пайплайнов в Apache Airflow для ежедневных batch-процессов. CI/CD сам не настраивал, но мой код проходил через CI/CD пайплайны.

Question 11

Как организовывалось CI/CD, кто этим занимался

Answer 11

CI/CD я не настраивал с нуля, но мой код проходил через пайплайны, и я понимал, как они работают.

Question 12

Чем еще занимался второй DE?

Answer 12

В принципе тем же, что и я без учета CI/CD

Question 13

Сколько человек было в команде?

Answer 13

В команде было 3 человека: 2 Data Engineer, 1 аналитик

Question 14

Был ли код-ревью? Кто утверждал архитектурные решения?

Answer 14

Да, был процесс код-ревью. Архитектурные решения обсуждались командой и утверждались старшим Data Engineer

Question 15

Старший DE не считался в команде?

Answer 15

Старший Data Engineer не входил в ядро команды разработки, но утверждал архитектурные решения, делал код-ревью и помогал с оптимизацией пайплайнов.

Question 16

Проект строился с нуля?

Answer 16

Большая часть платформы строилась с нуля: мы создавали Data Lake на HDFS, писали Spark ETL/ELT задачи и строили Airflow-пайплайны. Частично дорабатывались готовые аналитические таблицы ClickHouse

Question 17

Какие решения ты принимал сам, а какие — нет?

Answer 17

Я самостоятельно принимал решения по Spark-задачам, оптимизации, структуре Data Lake и логике Airflow-DAG’ов. Архитектурные решения, влияющие на весь пайплайн, обсуждались командой.

Question 18

Где все это было в gitlab?

Answer 18

Весь код хранился в GitLab, там же использовался встроенный CI/CD.

Question 19

Почему ушел с проекта?

Answer 19

Основные задачи проекта были выполнены: Data Lake был построен, ETL/ELT пайплайны настроены, аналитические витрины созданы. После этого потребность в дополнительной работе Data Engineer на проекте была минимальна

Question 20

Почему выбрали Spark, а не чистый Python / SQL?

Answer 20

Spark уже был стандартом в компании и хорошо подходил под объемы и HDFS.

Question 21

Как выбирал количество партиций?

Answer 21

• Основывался на количестве ядер кластера (обычно 2–4 партиции на ядро)
• Смотрел на размер данных (не более 128–256 MB на партицию для оптимальной обработки)
• Использовал repartition или coalesce при необходимости

Question 22

Хорошо, как ты выберешь количество партиций, если данных 100 гб?

Answer 22

«Я ориентируюсь на 100–200 МБ данных на одну партицию. Для 100 ГБ данных это примерно 800–1000 партиций. При этом учитываю количество ядер кластера и после записи проверяю размер файлов, чтобы не было слишком маленьких. При необходимости использую repartition() или coalesce() для оптимизации.»

Question 23

Разница между repartition() и `coalesce()

Answer 23

• repartition(n) — всегда делает shuffle, создаёт n равномерно распределённых партиций
• coalesce(n) — минимизирует shuffle, уменьшает количество партиций, если нужно только сжать данные

Question 24

Какие форматы использовал (Parquet / ORC / CSV)?

Answer 24

В Data Lake использовался Parquet.
На этапе ingestion из API данные приходили в JSON.
CSV использовался редко — в основном для небольших внешних выгрузок или тестов.

Question 25

Почему Parquet лучше CSV?

Answer 25

Parquet хранит схему данных. Колоночный формат. Хорошее сжатие. Лучше работает со Spark, большими данными и аналитическими запросами csv - текстовый формат, плохо сжимается, не хранит схему, подходит для небольшого объема данных и тестов

Question 26

Как делал incremental загрузки?

Answer 26

Основная логика была incremental по updated_at. Late-arriving data анализировали и пришли к выводу, что их влияние на бизнес-метрики минимально, поэтому дополнительная переобработка не внедрялась.

Question 27

Сталкивались ли со schema evolution?

Answer 27

Такого не было, т.к. источники был стабильны. Но у нас было решение на этот счет, мы бы читали данные и добавляли бы новую колонку с null значениями, чтобы можно было работать со старыми данными.

Question 28

Какая была структура веток?

Answer 28

У нас использовался стандартный Git Flow: - `main` — стабильный продакшен-код - `develop` — интеграционная ветка - feature-ветки для разработки ETL и DAG - bugfix/hotfix ветки для исправлений Все изменения проходили код-ревью перед мержем."

Question 29

Писалась ли документация?

Answer 29

"Да, я писал техническую документацию по ETL, DAG и аналитическим таблицам. В документации описывались источники, шаги трансформаций, форматы данных и партиции. Это помогало команде и аналитикам быстро понимать пайплайны."

Question 30

А где писалась документация?

Answer 30

"Документация писалась прямо в GitLab рядом с кодом в Markdown, а для схем и общих описаний использовалась Confluence."

Question 31

Как происходило взаимодействие с пользователями данных?

Answer 31

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

Question 32

Как происходило взаимодействие, созвоны или специфические инструменты?

Answer 32

"Требования обсуждали на созвонах в Teams, оперативные вопросы решали в чатах, задачи фиксировались в Jira, а документация велась в Confluence и GitLab."

Question 33

Как было организовано удаление данных по TTL?

Answer 33

"TTL был реализован на нескольких уровнях. В **Data Lake на HDFS** использовались retention-политики: Airflow DAG-и периодически запускали Spark-задачи или shell-скрипты, которые удаляли или архивировали партиции старше заданного периода (например, по дате). В **ClickHouse** использовались встроенные TTL-механизмы таблиц MergeTree, которые автоматически удаляли или перемещали данные при мерджах. Таким образом, старые данные не накапливались и хранилище оставалось под контролем."

Question 34

Как часто запускался Dag под удаление?

Answer 34

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

Question 35

Почему не использовали стриминг сервисы (kafka, rabitmq)?

Answer 35

"Потому что проект был batch-ориентированным: ежедневная аналитика, без real-time требований. Kafka добавила бы сложности без реальной пользы.

Question 36

С какими ошибками и проблемами сталкивался?

Answer 36

Spark job-ы иногда выполнялись слишком долго. Приходилось думать над оптимизацией, бродкастить таблицы, экспериментировать с партицированием, а также настройками оптимизатора. Проблема была с недостопностью некоторых API, приходилось настраивать ретри механизмы.

Question 37

Что получали из API по яндекс.метрик?

Answer 37

Из Яндекс.Метрики мы забирали **агрегированную статистику по пользовательскому поведению** через Reporting API.

Question 38

Расскажи как проходил твой день?

Answer 38

Обычно с утра проверял, как отработали даги за ночь. Если были ошибки, разбирался, читал логи, ну и при необходимости даг перезапускал. Каждый день был дейлик, обсуждали, что сделали, что не сделали, что надо сделать. Ну а в основном занимался по основным задачам, строил пайплайн, разбирался с задачи Spark, ну и писал документацию к сделанному

Question 39

Какие были достижения?

Answer 39

Мои ключевые достижения: построил Data Lake с нуля, разработал и оптимизировал ETL-пайплайны на Spark, подготовил аналитические витрины в ClickHouse для BI, внедрил incremental загрузки и идемпотентность, а также создал документацию и стандарты для команды. Всё это позволило ускорить аналитику и повысить качество данных."

Question 40

Как писались даги?

Answer 40

DAG-и писались локально в Airflow (обычно через Docker Compose), что позволяло тестировать их в UI и проверять зависимости и структуру задач до деплоя в CI/CD.

Question 41

Как тестировались даги?

Answer 41

В CI/CD были реализованы unit-тесты, которые автоматически тестировали даги

Question 42

А что именно тестировалось?

Answer 42

В DAG-ах мы тестировали импорт, структуру графа, зависимости и базовые параметры.

Question 43

Что происходило при обнаружении ошибки в рабочем пайплайне?

Answer 43

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