Будни дата инженера

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

Не все понимают чем занимается дата инженер. Сфера задач у DE обширная. В работе DE используется множество технологий: SQL, Python, Scala, PostgreSQL, Oracle, Greenplum, Airflow, Dagster, Hadoop, Spark, Trino, dbt, Informatica, NiFi, Kafka, Flink, Docker, Kubernetes, Linux и т. д. Кто-то много кодит и собирает реально сложные пайплайны, кто-то пишет несложные SQL-скрипты и автоматизирует готовый код от аналитиков. Кто-то плотно работает с инфраструктурой, настраивает кучу контейнеров в Docker и Kubernetes. Кто-то плотно работает с DWH, пишет большие процедуры, занимается сложным моделированием таблиц и оптимизацией.

На канале будет новая рубрика — «Будни дата-инженера».

В ней я буду конкретно рассказывать о своих текущих задачах: что нужно сделать, какими инструментами и как именно я это сделал. Сейчас я работаю на всех слоях хранилища данных и с большим количеством технологий - задачки разнообразные. Также буду писать о своём прошлом опыте: какие были задачки и какие инструменты использовал. Думаю, многим это будет интересно и полезно.

И напоминаю: предложка всегда открыта. Буду ждать истории от подписчиков DE. Рассказывайте о своих типичных и нетипичных задачах. Давайте развивать комьюнити.

На неделе расскажу о своей недавно выполненной задачке✍️ Если интересна новая рубрика, накидайте реакций. ⬇️

it пингвин | data engineer 🐧

тяжелая неделька 😱

Будни дата инженера

Итак, как я и обещал рассказываю про мою недавнюю задачу.

Если кратко она звучала так:
Забрать данные из Кафки ML и построить витрину в DWH.

Сначала расскажу о нашем DWH.
Я работаю дата инженером в одном большом ритейле. А точнее работаю в доставке и у нас свое отдельное хранилище данных.
DWH у нас построено на Greenplum-e. Модель данных в хранилище - Data Vault. Данные в Greenplum-e по таблицам грузятся при помощи DBT. Оркестратор для запуска dbt моделей и не только для dbt - всем известный Airflow. Источники данных для нашего DWH по сути - топики в кафке. Данные из бэка попадают в Кафку. И дальше начинается наша работа, работа дата инженеров. Мы вытягиваем данные из Кафки при помощи Nifi. И грузим json-ы из Nifi в сырой слой Greenplum-a. Есть еще несколько разных инструментов, но они для этого кейса не важны.

Теперь давайте подробнее расскажу в чем суть задачи.
Есть команда ML (Machine Learning).
Они разработали модель для планирования (или даже для рекомендации) смен для сборщиков в магазинах. Дальше будет рекомендательная модель и для курьеров.
И нам нужно забирать эти данные в наше хранилище. ML-щики будут эти данные отправлять для нас в определенный топик Кафки. В одном сообщении (одно сообщение - для одного магазина на каждый день) будет храниться много рекомендаций смен сотрудников. Атрибуты - дата генерации, на какую дату рекомендация, id сотрудника, id магазина, различные типы, номер смены, рекомендованное время работы, рекомендованное время для обеденного перерыва и тд
Также хорошие заказчики прислали нужный им вид таблицы - какие нужны поля, комментарии и что они там хотят видеть.

Выполняем задачу

Создаем задачу для команды Кафки, чтоб нам выдали креды для подключения к новой для нас Кафки ML.
Выдали креды. Создаем новый pipepline в Nifi. Подключаемся к нужным топикам ML. Настраиваем загрузку данных из Кафки в таблицу в Greenplum (в сыром слое). Таблицу только что сами в GP и создали. Данные буферизируются в Nifi и отправляются в GP каждые 10 минут или каждые 10000 сообщений. Также настроили обработку ошибок и кривых сообщений.

Данные появились в GP - таблица stg_... Поля - дата, ид документа, само сообщение (json).
Сначала тестово написали парсер для json. И также при парсенге нужно генерить суррогатный ключ для каждой рекомендации для одного сотрудника. Ключ генерим из нескольких полей. Добавляем различные технические поля - даты, источник данных.
ГПТ очень помогает в таких задачах.
Распарсили json, обогатили данными из нашего dds слоя (присоединились к таблицам в нашем дата волте) и видим уже прототип витрины.

Теперь все наши скрипты оборачиваем в dbt модельки, настраиваем правильный конфиг для GP. Запускаем модельки "dbt run", видим данные в витрине.
Тестим запуски, пересчеты, проверяем корректность данных. Показываем витрину аналитику. Если есть замечания - исправляем.
Далее пушим наши изменения через git в прод. Подхватываем все наши новые файлы в проекте, делаем файл миграции для dbt. Ревьюер проверяет всю нашу разработку. Пока что мы еще молодые и зеленые в новой компании и не можем сами в прод мерджить. Запускаем миграцию в Airflow. Миграция отработала успешно.

Витрина на проде. Данные появились. Задачка закрыта. Приступаем к следующей. Задач много, а сроки как обычно горят😁

Я хоть и постарался подробно описать все. Но конечно же много деталей опустил. На каждом этапе было много нюансов - подключение к Кафке ML, работа с тестовыми топиками, написание SQL скриптов, создание витрины в обход слоя ддс, разработка на малом количестве данных, запуск миграции в аирфлоу и тд.

И еще можно обратить внимание, что я глубоко не вникал для чего нам эти данные и как они генерятся. Примерно понятно что там, но их ценность и как с ними будут работать - мне неинтересно. Может даже интересно, но вникать глубоко времени нет.

В следующем посте хочу кратко написать про перечисленные инструменты (для новичков). Будут краткие гптшные определения, чисто для удобства.

Дайте обратную связь плз, как вам формат? Какие есть вопросы по задачке?

it пингвин | data engineer 🐧

Куда зовут моих менти🤩

Краткие определения инструментов из поста.

Apache Kafka
Распределённая платформа потоковой передачи событий и логов, построенная как устойчивый commit‑log с горизонтальным масштабированием через партиции. Сообщения пишутся продюсерами в топики и читаются консюмерами в составе групп, что даёт параллелизм и балансировку; порядок гарантирован внутри партиции. Чаще всего применяется для интеграции сервисов, стриминга событий, CDC и построения event‑driven архитектур; не заменяет аналитическое хранилище и не предназначена для произвольных SQL‑запросов.

Apache NiFi
Платформа для построения конвейеров данных с визуальной оркестрацией. Умеет забирать/передавать данные между системами, трансформировать, буферизовать и отслеживать происхождение данных. Полезна там, где важно быстро собрать интеграцию «из коробки» без большого количества кода.

Greenplum
MPP‑СУБД для аналитики на основе PostgreSQL с архитектурой «координатор + сегменты», выполняющей запросы параллельно по распределённым данным. Поддерживает распределение по ключу, партиционирование, внешние таблицы и высокопроизводительные загрузки, а также append‑optimized (включая колоночный) сторедж для сканов и агрегатов. Сильна в сложном SQL и широких джойнах на больших объёмах; чувствительна к перекосам данных и не предназначена для OLTP с низкими задержками. Типичные практики — грамотный выбор ключей распределения/партиций, регулярный анализ статистик и контроль skew.

Data Vault
Методология моделирования DWH, разделяющая бизнес‑ключи (Hubs), связи (Links) и атрибуты/историю (Satellites) с жёсткими правилами ключей, источников и временных меток. Позволяет быстро добавлять источники и детально хранить историю, а также ускоряет выполнение запросов. Даёт масштабируемость и аудит, но увеличивает количество таблиц и сложность запросов, поэтому почти всегда дополняется витринами под потребителей.

dbt (data build tool)
Фреймворк «T в ELT», превращающий SQL‑модели в управляемый DAG трансформаций с материализациями, зависимостями, тестами качества и документацией. Поддерживает макросы на Jinja, инкрементальные загрузки, snapshots для SCD2, пакеты и генерацию сайта документации с линейджем. Интегрируется с большинством SQL‑движков, хранит всё как код и легко встраивается в CI/CD. Не занимается оркестрацией и загрузкой из внешних источников, концентрируясь на воспроизводимых трансформациях внутри хранилища.

Apache Airflow
Оркестратор рабочих процессов, описываемых как DAG с зависимостями, ретраями, SLA и мониторингом выполнения. Предлагает богатую экосистему операторов/сенсоров, обмен артефактами через XCom, группировку задач, а также различные исполнители (Local, Celery, Kubernetes) для масштабирования. Предназначен для пакетных и гибридных пайплайнов, где шаги разнородны (SQL, Python, bash) и важен контроль порядка и расписания. Не решает задачи стриминга, но может триггерить стриминговые джобы и управлять их жизненным циклом.

DWH (хранилище данных)
Централизованная аналитическая платформа, отделённая от транзакционных систем и предназначенная для согласованных метрик, истории и доступов. Обычно строится слоями: сырое (RAW/STG), согласованное ядро (Core/DDS) и витрины (Marts) под домены и продукты.

DDS
Согласованный детализированный слой между сырыми данными и витринами, где выравниваются идентификаторы, типы и бизнес‑правила. Может быть реализован как 3NF, Data Vault, Anchor и тд. Хранит историю изменений и служит стабильным источником для downstream‑моделей. В DDS устраняются дубликаты, приводятся справочники и формируются «золотые» сущности, на основе которых строятся витрины и модели.

Витрина данных (Data Mart)
Предметно‑ориентированный слой, оптимизированный под конкретного потребителя или набор метрик, обычно на базе звезды/снежинки или широких таблиц. Содержит только необходимые поля и агрегаты, обеспечивая стабильные определения метрик и быстрые запросы, часто с инкрементальными обновлениями. Изолирует сложность ядра и ускоряет разработку отчётов и дашбордов, при этом наследует качество и историю из согласованного слоя.

it пингвин | data engineer 🐧

Пятничная задачка

Давно не было задачек по SQL 🍴
Я люблю задачки с усложнениями и нашел у себя в заметках классный пример.

Итак:
Есть табличка (school) из двух столбцов - имя ученика (name) и оценка (mark) . В таблице имена могут повторяться как и оценки.

1)Задача: найдите имена и количество двоек у тех учеников, у которых больше 10 пятерок. Соответственно надо получить табличку с именем и количеством двоек.

2)Усложнение: решить задачу без подзапросов!

Необходимо написать два запроса.
Cвои решения прикреплю 🫡:
С подзапросом:

select name, count(mark) as cnt
from school
where mark = '2'
and name in (select name
from school
where mark ='5'
group by name
having count(mark) >10)
group by name

Без подзапроса:

select name, sum(case when mark = 2 then 1 else 0 end) as cnt
from school
group by name
having sum(case when mark = 5 then 1 else 0 end) >= 10

Присылайте решения (хотя бы 1 уровень нужно уметь решать) ⬇️


it пингвин | data engineer 🐧

Очередная испыталка пройдена ✅

На следующей недели сделаю пост о том, что для меня самое сложное в новой компании. Я работал в телекоме, банках и сейчас в ритейле, сравню их.
Времени сейчас мало, на работе завал 🥲

Насыпьте реакций плз, если интересно⬇️

Новая работа 👨‍💻

Итак, у меня закончилась испыталка в X5

Я работаю в отдельном от большого X5 хранилище. Технологий пока что не так много, но мы очень активно развиваемся.

Если кратко, архитектура у нас сейчас такая:
Основной источник - наш бэк на MongoDB. С помощью самописного CDC инструмента пишутся данные в Кафку.
Стриминг - читаем из кафки и пишем в обычную Постгрю. Скоро будет Кликхаус.
Батчинг - Nifi читаем из Кафки, пишем Greenplum. Модель данных у нас Data Vault. Трансформации на DBT. DBT модельки (и не только) запускаются через Airflow.
Также есть Minio. Здесь чуть подробнее описал.

Планируем разворачивать модные Айсберги, Трино, duckdb, Spark Streaming/Flink и тп.

Я много с чем не работал вообще, или не так глубоко.
Был удивлен, что самая сложная "технология" для меня в новой компании - это Data Vault
Очень сложно и непривычно организованы таблицы. Проблематичны поиск данных, понимание как джоинить таблицы, построение dds, промежуточных моделек и тп.
С остальными технологиями полегче.

Что еще непривычно в новой компании - темп работы. Очень много разнообразных задач. Лид очень круто руководит процессом. Задачки сыпятся как конвейер - доделываешь задачи, на подходе сразу много новых.
Вроде как и не перерабатываю, но постоянно какой-то напряг. Не получается почилить как в банке. И начал прям заниматься за тайм менеджментом. Выбираю какие задачки в первую очередь делать, что можно делать параллельно. Декомпозирую задачи и связываю разные задачки. Опять же в банке у меня было совсем по-другому) Плюс так вышло, что на меня повесили достаточно сложный проект, за которым следили наши топы. И хорошо, что мне очень помогала коллега.

Но мне пока что этот высокий темп - нравится. Я вроде бы не говорил, но я получил несколько офферов. И выбирал между газпромбанком и х5. В гпб был жирнее оффер. Но мне уже надоела эта банковская бюрократия. Хотелось больше суеты 😁
Выбрал х5 и не жалею.

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

* как раз недавно прочитал репост у Lost in Data с канала This is Data.
Понравилась классная цитата

быть самым слабым в команде – не стыдно. Стыдно – застрять там, где ты не развиваешься.

Общение у нас строго деловое и чаще всего только по задачам. Никаких чатиков с мемами и котиками нет.
Я не говорю, что это круто, просто факт. Мне наверное даже не хватает таких чатиков)
Лид погружен в техническую часть, но сам мало что руками делает. Постоянно на созвонах, грамотно раздает все задачи, говорит что как лучше делать и нам, дата инженерам и заказчикам.

Основные заказчики для нас - всякие разные аналитики. И тоже хочу отметить работу с ними. Я плотно общался где - то с 4 аналитиками. И все были очень вайбовые.
Я могу написать аналитику много кода, технических штук - он мне говорит, добавь плз больше русских слов)
И наоборот аналитики мне объясняют всякие бизнесовые приколы, метрики и для чего им нужны новые данные/доработки.

Что еще из плюсов назвать. Работаю просто через впн, со своего пк, без всяких виртуалок. Выдали MacBook Pro 16 M2, вроде можно потом выцепить м4.
Можно договориться на удобное время работы. Коллеги живут в разных городах РФ. Один админ работает из Тайланда.

Надо что-нибудь назвать из минусов, а то выглядит как рекламная интеграция 😅

Погружение - не прям провели меня за ручку и все подробно описывали.
Документация не супер подробная, но у меня до сих руки не дошли до вики и я ее нормально не изучил.
Видосики, курсики внутри х5 - такое себе.
По самой работе, пока что все равно пишу в основном sql код. Хочется побольше питончика и инфраструктурных задач.

А так вроде бы все сказал. Кажется, что в этой компании я надолго.

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

Как вам обзорчик? Пишите свои мысли, где вы работаете, где вам нравится или нравилось раньше ⬇️

Закончил курс по DE от NewProLab


В начале декабря закончился курс. Кратко расскажу какие еще были лабы и дальше общее мнение по курсу.
Прошлый обзор лаб

Лаба5: Сервис персонализации интернет-магазина

Загрузка данных в клик -> рассчитываем данные-> сохраняем в Redis c помощью Airflow и вспомогательных справочников в Postgres

По-моему это самая сложная лаба и больше половины студентов ее не решили. Самое сложное не поднять сервисы, связать все, скачать данные и тд. А написать несколько хитрых SQL запросов! Здесь нужна та самая рекурсия 🥲 Надо собрать многоуровненое дерево категорий и потом к нему обращаться. И дерево может быть с косяками, с несколькими родителями..
И до всего этого реально сложно догадаться. Какие-то около олимпиадные задачки. И честно именно это мне не очень понравилось. То есть я понимал, что нужно многоо времени потратить чтоб все сделать. А желания особого не было. Таких бизнесовых задач мне и на работе хватает, а на курсе я больше всего хотел потрогать инструменты.
Но опять же, кураторы и говорили что это сложная лаба. Там дальше еще и суперачивка.. Без подробностей, просто нужно еще более сложные sql запросы написать.
Я эти лабы выполнил😎 НО с хитростями💅 Чекер проверил данные, все сошлось. Но как я этого добился история умалчивает. Мне кажется я даже более сложную работу проделал, чем написать эти хитрые sql запросы. Наверное я эти лабы выполнял ~30 часов. Запомнится мне это надолго)
При решении этой лабы очень много работал с командной строкой, редисом, Аирфлоу.

Лаба6: Сам себе CI/CD

В лабе нужно было собрать свой Docker-образ Airflow с вашим DAG внутри (через Dockerfile: зависимости + копирование дага/конфигов), чтобы пайплайн был «запечён» в образ и версионировался вместе с ним.​
Потом - настроить GitHub Actions, чтобы автоматически билдить этот образ на GitHub и пушить в Docker Hub.​
Дальше - обновить docker-compose.yml, чтобы он тянул опубликованные образы, добавить README с инструкцией запуска/создания пользователей и выложить всё в приватный репозиторий, дав доступ ментору/координатору
В целом классная лаба.

Лаба7: Расчёт данных при помощи DBT

Нужно было установить dbt-core с адаптером для ClickHouse, инициализировать dbt‑проект и настроить подключение (profiles.yml/переменные окружения), чтобы dbt debug проходил успешно.​
Дальше - в ClickHouse создать таблицы, читающие CSV из S3, и через dbt выстроить преобразования по слоям RAW -> CORE -> DM (в RAW добавить служебные поля src и created_dttm, в CORE/DM сделать требуемые расчёты и витрины).
В конце - запустить dbt run с переменной run_date (чтобы она попала в витрины) и прогнать чекер, который сверяет результат по хэш-суммам целевых DM-таблиц.

Тоже классная лаба, давно хотел сам поднять дбт, но руки не доходили. Почему-то hash суммы не сходились и по итогу тоже долго просидел над sql запросом🤦‍♂️


Лаба8: Дашборд для e-commerce кликстрима

Это лаба по сути - дипломная работа. Нужно поделиться на команды, выбрать стек технологий, поднять всю инфру, построить dwh, обработку данных, должна быть историчность и возможность делать пересчет, построить графики в биайке и проанализировать данные, все опубликовать и описать в гите. Этот проект сделали 10 человек (4 команды). Они потом выступали с защитой. Ребята проделали реально большую работу.
Я к сожалению поздно спохватился, где-то за неделю до сдачи. Другие команды уже собрались почти за месяц до сдачи. В общем, я не нашел команду и эту лабу не сдал 🥺
Я сделал все лабы, с суперачивками и знал что уже получу красный диплом. Поэтому делать лабу в соло уже не хотел.

По итогу, да. Я получил Красный диплом. ХЗ зачем, сам себе поставил и задачу и хотел этого добиться. Хотя это вообще необязательно было. Какой-то синдром отличника 🤡 Вошел в топ 7. Как раз до первых ребят не хватило выполненной 8 лабы.
И половину лекций до сих пор я не посмотрел. Круто, что доступ к гиту и лекциям остается у нас. Я в спокойном темпе все посмотрю. Лекции мне прям нравились.

Продолжение ⬇️

Еще одна история о потери данных ✍️

Прилетела задача от аналитика - сделайте витрину, вот вам готовый запрос.
В запросе не очень сложный расчет, но там джоинится несколько больших витрин. А мы стараемся не создавать витрину из витрин.
Поэтому мне надо было повторить запрос аналитика, но из таблиц в ядре (слой dds). Тоже все это не очень сложно, переделал запрос, вроде сходится.

Подготовил тестовую витрину в песочке для аналитика, чтоб сверил данные из своего запроса. Все ок - сходится.
Сделал MR (merge request), внедрили обновление в прод. Смотрим данные в новой витрине, что-то не так.. Небольшой процент данных не сходится с данными из тестовых запросов..

И вот начинается суета на пару дней 😔 Снова проверяю запрос аналитика, мой запрос - сходится. Что-то с дбт..
Разбираюсь с дбт, что по итогу он генерит, как он создает темповые таблицы. Нахожу запросы, которые запускались прям в БД (это было не просто).
Запускаю запрос - тоже все ок. Но почему в базе данные другие🤔

Нашел ошибку в запросе аналитика и в моем. * Немного неправильная группировка. Думаем в этом косяк. Снова сверил запросы - все ок, одинаковый правильный результат.

Внедряем в прод - снова данные не сходятся))
Снова подозреваю дбт, что-то не то запускается. Позвал шарящего коллегу DE - теперь вместе не понимаем что за магия)) Мой запрос отрабатывает также как и аналитика. И данные верные. И тестовая витрина тоже с правильными данными.
Другой DE тоже не понял в чем косяк. Но предполагаем или косяк в моем запросе или в дбт. Самое главное мы не можем получить данные, которые прогружаются в базу.

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

case when code = 'x'
        then lag(case when code = 'xxx' then create_date end) 
            over(partition by yyy, date_trunc('day',dea.create_date) order by create_date)
        end as zzz

Я предложил проверить тайм зоны, но мы конечно же забили, подумали вряд ли в этом дело🥲

Далее подключилась еще коллега DE. Запускает запрос и сразу получает такие же данные как и в БД. То есть она одна видит косячные данные, а мы все нет)
Я подготовил маленький скриптик, который у нее запрос выдает несколько строк, а у нас у всех такой же запрос выдает 0 строк.
Уже очевидно, что-то с настройками наших IDE.

В общем, в чем проблема - у меня, аналитика и еще одного DE в настройках таймзоны было utc +3.
А у другого DE и главное в БД таймзона была просто utc (на 3 часа меньше чем мск).

И косяк вроде бы был как раз в sql кусочке, который я выше прикрепил. Если время около 12 ночи, то дата по-разному обрезается. Для нас было час ночи 29 декабря, а для БД это 28 декабря 22 часа. Или может еще дальше был косяк, там еще куча разных джоинов и фильтров с датами.
Поменял таймзону на соответствующую БД - все сошлось. Теперь я выполняю запросы и тоже вижу некорректные данные, как и в БД. Дальше уже было легко найти причину. Косяк есть и в запросе аналитика, как следствие и в моем. Все поправили. Новый MR, данные в проде сошлись 🎉

Сейчас кажется очевидной такая ошибка. Я и знал про настройки в БД, но не подумал что так может меняться результат.
Теперь у меня в датагрип таймзона utc +3, а в дбивере utc. Если что в двух местах чекну запросы. *Я знаю что таймзону можно в прям в запросе прописывать.

Мораль: всегда проверяйте настройки timezone в IDE перед дебагом дат. Это может сэкономить пару дней головной боли.