#вести_с_полей

Специализации в Data Engineering'e или что можно встретить в вакансиях 1/3

Вижу три роли, в которых можно развиваться в DE, не переходя в смежные роли вроде MLE или DataOps. В маленьких командах один человек может совмещать несколько, но при масштабировании компании обычно эти роли разделяют.

🔸 Собственно дата инженер (ETL Developer + Big Data)

Отвечает за загрузку источников в сырой слой хранилища. Работает с различными системами, например может требоваться опыт работы с Kafka, API, S3, SFTP, ODBC/JDBC, HDFS коннекторами. Приёмник -- одна-две системы, обычно Data Lake или Raw слой OLAP базы (н. Greenplum).

Основной инструмент -- ETL, обычно Spark, Flink и подобные. Оркестратор -- Airflow (в СНГ почти не видел конкурентов). Хорошая практика -- использовать data contracts через schema registry, потенциально с автоматизированной schema evolution.

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

Много пишет на Python и/или Scala, подключается по SSH к ВМ и заходит в контейнеры, много работает с Linux и его файловой системой. В бизнес-правила почти не погружается, цель -- перенести данные без потерь и простоев "как есть", максимум применяя `` hard rules ``.

Специализации в Data Engineering'e или что можно встретить в вакансиях 2/3

🔸 Бэкенд-разработчик с уклоном в data-направление (Backend Engineer + Big Data)

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

Такие разработчики пишут и/или настраивают инструменты self-service аналитики, чтобы сами аналитики могли строить типовые пайплайны, объединять таблицы в витрины данных, на их основе строить дашборды. И помогают в случаях, когда нужно написать кастомную загрузку.

Этот путь требует от компании больших вложений в обучение аналитиков и автоматизации контроля качества кода. В среднем у них меньше компетенций для написания production-ready запросов в big data среде, чем у дата инженеров, поэтому нужно аналитикам с этим помогать, "давая удочку".

Задачами могут быть: написание или доработка алгоритмически эффективных микросервисов под Docker/Kubernetes; форк и доработка open-source решения под конкретные задачи; помощь в отладке самых непонятных ошибок в Hadoop'е (Java Stack Trace). В качестве big data специфики может быть работа с OLAP БД и колоночными типами данных, упор на MPP системы и масштабирование под прокачивание через сервисы сотен и тысяч ГБ данных в день.

Специализации в Data Engineering'e или что можно встретить в вакансиях 3/3

🔸 Analytics Engineer (DWH Developer + Big Data)

У этой роли появилось своё название, по крайней мере "на западе", и в СНГ оно тоже постепенно приживается. Такой специалист занимается раскладыванием тех данных, которые загрузили DE в сырой слой, по следующим слоям в хранилище. Часто занимается витринами данных с большим количеством бизнес-логики и хорошо понимает, как спроектировать хранилище устойчивым и масштабируемым.

Такой специалист работает внутри одной-двух систем (например, подготавливая в Greenplum витрины для Clickhouse), и глубоко знает, как они работают под капотом. Также отлично разбирается в моделировании данных (Data Vault, Anchor Modelling, Kimball Star/Snowflake, Inmon 3NF ...). Больше других общается с бизнесом для выяснения требований и отвечает за качество данных, чтобы при изменениях логики отлавливать ошибки. Здесь уже можно встретить запросы по 50 CTE шагов на 100 строчек каждый для расчёта одной витрины для какой-нибудь регулятивной отчётности.

Инструменты -- OLAP хранилище, ELT вроде DBT, SQL + Jinja как языки автоматизации, Airflow как оркестратор (через `` cosmos `` или dbt-af), фреймворки качества данных вроде Great Expectations или Monte Carlo.

Задачами могут быть: протянуть новое поле из сырого слоя в витрины, пересчитать на сырых данных новую модель за прошлый период, оптимизировать расчёт витрин под конкретный дашборд, перенести витрину в быструю колоночную СУБД, написать регрессионные тесты для более уверенного внесения изменений.

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

Поэтому смотри на задачи и обязанности, обсуждай ожидания на собеседовании.

❕ Какие ещё выделишь направления в DE? Делись мыслями в комментах.

🎉 Результаты розыгрыша:

Победители:
1. Pavel (@PavelAnt11)
2. Evgeniy (@john_afv)

Проверить результаты

#видео #моксобес

Третий мок-собес на youtube вышел, смотрим
-> Ссылка на видео

Видео-половинка с разбором и обратной связью уже на бусти boosty.to/rzv_de

В этот раз пожёстче спросил по теории.

Взамен запрашиваю у тебя жёсткую обратную связь по тому, что стоит улучшить.
"Эммм" и "скажем" услышал, буду выкорчёвывать. Что ещё?

p.s. Ухожу в отпуск на 2 недели, не теряй

#видео #моксобес

Вернулся из отпуска не с пустыми руками. Четвёртый выпуск серии мок-собесов на youtube
-> Ссылка на видео

Видео-половинка с разбором и обратной связью уже на бусти boosty.to/rzv_de
(скоро должна допроцесситься, прошлая часть тоже доедет сегодня-завтра)

В этот раз тоже пожёстче спросил по теории, и кандидат отлично сдержал удар.

Как и раньше, запрашиваю у тебя жёсткую обратную связь по тому, что стоит улучшить.

#термин_дня

Ещё немного про BI: Drill-Down с точки зрения DE

🔸 Дрилл-даун это элемент дашборда, который наравне с фильтрами добавляет ему интерактивности. Визуально это выглядит как перестраивание графиков по клику на одну из выбранных категорий, "проваливание" внутрь её.

🔸 Зачем нужен? Позволяет исследовать данные естественным для человека способом "от общего к частному", не создавая при этом много страниц или отдельных графиков на каждую фиксированную комбинацию измерений для группировки. Добавляет глубину, не усложняя интерфейс.

🔸 Напомню, что меры это числовые значения (факты), а измерения -- некоторые атрибуты этих фактов. У измерений может быть иерархия (по временным периодам, год-квартал-месяц, или по структуре отделений -- страна-регион-город-магазин). Со стороны запросов это можно описать как расчёт суммы, количества или среднего значения на основе фактов с группировкой по измерениям.

🔸 С технической стороны дрилл-даун можно представить как добавление в group by агрегирующего запроса всё нового уровня иерархии с каждым кликом "вглубь". А со стороны моделей это можно реализовать или через "снежинку" (измерения 1го уровня ссылаются через PK-FK на измерения 2го уровня и тд), или через One Big Table, указывая иерархию в BI-инструменте. Именно такой вариант часто используют в паре с Clickhouse, куда загружают таблицу, сформированную через join/union на основе центрального слоя под конкретный сценарий, а движок шустро пересчитывает агрегаты с каждым нажатием.

🔸 Покликай живой дашборд по ссылке, сразу станет яснее. Нажми на ссылку -- Interact, потом на Children - Toys или на соседние категории. https://zoomcharts.com/en/microsoft-power-bi-custom-visuals/dashboard-and-report-examples/view/christmas-gift-power-bi-sales-dashboard-by-prathamesh-sawant

#реклама

С улыбкой делюсь перспективным каналом по DE с тобой.
Вспомнил, с каким трепетом сам писал первые посты (кстати, рекомендую пролистать наверх тем, кто недавно на канале).

"""
✋🏻 Всем привет, меня зовут Дмитрий, я работаю дата инженером.

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

📝 Блог https://www.tgoop.com/kuzmin_dmitry91
"""

#вести_с_полей

Как DE может решать задачи CI/CD 1/3

🔸 Представь, что есть некоторый сервис интеграции с источниками данных, который можно конфигурировать через JSON по API. И ещё у сервиса есть визуальный интерфейс, через который эти конфиги можно задавать напрямую, в обход гита, что и делали последние несколько месяцев, потому что так быстрее.

🔸 Какие минусы у ручного подхода? Нет истории изменений, проверки перед применением очередной версии конфига, ещё и параметры подключения к сервисам (credentials) могут храниться в обычном текстовом виде. Безопасники не будут дружить с такими дата инженерами. И, если контур один, эти изменения применяются напрямую на проде, что редко добавляет стабильности работе системы.

🔸 Такие проблемы можно решить через CI/CD: CI -- непрерывная интеграция (continuous integration), CD -- непрерывная доставка (delivery) или развёртывание (deploy). Объединяет и упрощает совместные изменения в команде и унифицирует способ "применения" изменений на разных контурах (дев, тест, прод). Для дев/тест среды обычно есть тесты перед авто-развёртыванием, а для для прода часто выбирают Continuous Delivery -- подготовку поставки, которую можно развернуть по нажатию кнопки человеком. Например, через approve pull request'a.

Как DE может решать задачи CI/CD 2/3

🔸 Итак, реализация. В 90+% случаев это или Gitlab CI, или Github Workflows, или Atlassian Bamboo (в дополнение к bitbucket). Код workflow (или pipeline) задаётся в YAML файле, где определяются атомарные действия (шаги, степы) и группы шагов (джобы). Внутри обычно встретишь или много bash кода, или готовые "actions" из маркетплейса (примерно как операторы в airflow).

🔸 У каждого шага и джоба есть статус выполнения, input, output, к которым можно обращаться в других шагах и джобах. Можно вешать условия на выполнение -- например, делать деплой только после успешного выполнения всех тестов.

🔸 Также удобно выносить часть кода в переиспользуемые действия, обращаясь к ним как к степам из маркетплейса. И, что мне как питонисту близко, -- выносить код взаимодействия с сервисом в набор .py скриптов. Поэтому в дополнение к главному YAML может быть ещё директория в гите, где лежат тесты и код деплоя, общающиеся с сервисом через API. А workflow склеивает это воедино и задаёт логику перехода между шагами. И отчёты формирует для чтения статуса людьми.

Как DE может решать задачи CI/CD 3/3

🔸 Первое время немного неуклюже выглядит интеграция python и bash. Для этого нужно пробрасывать параметры из workflow в python скрипт и передавать результат работы обратно, но GPT помогают с нюансами Bash, и со временем картинка выстраивается. Кстати, я недавно перешёл на Claude Sonet, пока нравится больше, чем Gemini. Приятно, этот инструмент становится привычным, и на дейликах разработчики больше не стесняются говорить о парной работе с таким помощником.

🔸 Немного про разделение ответственности. В компаниях, где я работал, обычно было так: девопсы поднимают сервисы в ВМ или в контейнерах, а как с ними будут работать DE -- дело последних. Например, пайплайн по перезапуску упавшего Airflow скорее напишет DevOps. Пайплайн по доставке дагов из гита и тесты для проверок кода скорее будут писать DE.

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

Разыгрываю мок-собес!

Разыгрываю одну запись тренировочного технического интервью (с выкладыванием на youtube), победителю нужно будет запланировать 1.5 часовой звонок в течение двух недель после окончания розыгрыша.
Начинаем сейчас, заканчиваем 2024-08-20 в 23:00 мск.

Примеры можно посмотреть здесь

Можно остаться анонимным(-ой), попросить изменить высоту голоса, внести помехи, закрыть имя и пр.

#видео #моксобес

Новое видео на канале -- пробую систем дизайн секцию технического интервью. Пока неказисто, но дорогу осилит идущий!

-> Ссылка на видео (youtube)
-> Ссылка на видео (vk video)

Видео записали вместе с @halltape_data, спасибо, Женя, за участие.

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

🎉 Результаты розыгрыша:

Победитель:
1. Anton (@imshenets)

Проверить результаты

#вести_с_полей

Настройка CDC на примере Kafka Connect, Debezium и Postgres 1/2

🔸 Итак, что такое CDC и зачем это надо.
Change data capture это технология захвата изменений данных с источника, для реляционных СУБД — обычно через лог базы данных. В таком случае таблица не блокируется, нагружается именно компонент, отвечающий за репликацию. В отличие от батч загрузок, которые запускаются по расписанию и теряют промежуточные изменения, CDC подтягивает все операции. Это и благо, если такая детализация нужна, и головная боль, если надо схлопывать эти изменения и сохранять только состояние, например, на закрытие операционного дня.

🔸 CDC создаёт поток изменений, который можно использовать для стриминговой загрузки. Но как связаны между собой Kafka Connect, Debezium и Kafka? Для ознакомления допустим, что Debezium CDC коннекторы используются как компоненты Kafka Connect для подключения к источникам. Для приёмников используются внутренние компоненты Kafka Connect (Sink). Данные между Debezium CDC и Kafka Connect Sink лежат в топиках кафки.

🔸 Как это может выглядеть на практике?
* Считаем, что сервисы уже развёрнуты и доступны по сети, и у тебя есть ко всему доступ и данные для входа (credentials). Плагины на Kafka Connect установлены для всех источников и приёмников, которые нам понадобятся.
* Создай слот репликации в базе, такой же как для обычных реплик.
* Подготовь конфигурацию для Кафка коннекта — о ней будет ниже.
* Отправь POST запрос на API endpoint сервиса Kafka Connect для публикации коннектора, где указываются конфиг и имя.
* Проверь статус самого коннектора через GET запрос или UI, он должен быть "up and running".
* Зайди через UI или CLI в список топиков, найди по topic.prefix и имени таблицы нужный, проверь что сообщения появились и в них содержатся данные из таблички.

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

Настройка CDC на примере Kafka Connect, Debezium и Postgres 2/2

🔸 Несколько важных параметров json конфига:
* name — имя коннектора, должно быть уникально в кластере
* connector.class — тип подключения, например io.debezium.connector.postgresql.PostgresConnector для загрузки данных ИЗ базы или io.confluent.connect.jdbc.JdbcSinkConnector для загрузки В базу
* database.[creds] — hostname, dbname, password, user, port, всё как обычно
* snapshot.mode — режим создания снимков; при первом запуске обычно выбирают initial, чтобы подтянуть историю, и потом факт загрузки истории фиксируется в кафке; never может пригодиться, если мы пересоздаём коннектор с другим именем, но тем же источником, чтобы не задублировать историю
* topic.prefix — буквально, префикс топика, которые будут созданы для каждой таблицы из table.include.list
* slot.name — имя слота репликации в базе, который нужно создать заранее

Также могут быть описаны трансформации данных, heartbeat таблица и топик для постоянной проверки статуса соединения, запросы кастомной инициализации соединения в бд и др.

#поразмыслим

С какими проблемами может столкнуться дата инженер, выполняя изменение схемы данных на проде (schema evolution)?

Как эти проблемы можно решить на проекте?

Ограничимся RDBMS MPP классом систем