#datadesign
WAP Pattern

Знаете ли вы, что такое WAP (Write - Audit - Publish. ) паттерн в дата инженерии? Скорее всего, многие из вас им уже пользуются! 🤔
Я объясню это на коленке, желающим детальных кишочек -> в ссылки снизу. 📌

Представим, я инженер в компании Colt 👍, и мы занимаемся доставкой еды. Моя зона ответственности - end-to-end решение для ежедневной отчетности в разрезе городов (прибыль, количество доставок, средний чек, среднее время доставки, ...).

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

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

Что же делать? Мы можем добавить тесты! 👍 Но возникает дилемма - скорость доставки vs качество. Если взять dbt как инструмент, то базовая имплементация тестов выглядит следующим образом -> прогнали модель, запустили тест над моделью, если тест упал, анализируем. Но если это уже презентационный слой, то конечные пользователи уже увидят эти данные. Мы можем настроить алертинг, но кто будет в него смотреть.👨‍🦳

Поэтому в случае критичных отчетов / дата продуктов, можно применить подход WAP.

- Write. Записываем данные в stage таблицу / объект
- Audit. Проверяем качество и полноту данных на уровне stage таблицы. Есть проблема -> автоматический алерт команде и on-call инженер с радостью разбирается 😮 (можно еще больше автоматизировать в случае повторяемых случаев, например сразу с ноги выбивать дверь к коллегам с источника писать письмо / заводить инцидент ).
- Publish. Если все тесты успешно прошли, кладем в Publish слой. Это можно делать как логически (синонимы, линки на файловой системы, переопределение view, alter/modify partition, ...) или физически (ETL).

Есть еще один use-case применения WAP паттерна. Далеко не все системы поддерживают ACID транзакции, а те, которые поддерживают, не всегда готовы часами ждать тяжелых расчетов. Для организации консистентности (ну или чаще уменьшения неконсистентного промежутка по времени) вы можете подготовить свои 20+ таблиц в стейдже, а потом переключить их одновременно в презентационном слое. 🍷

Недостатки? Данные будут устаревшие, поэтому нам надо быстро сообщить об этом пользователям, чтобы они не сообщили об этом нам!🙂

Кроме этого, далеко не всегда причина может быть устранена быстро, но что с этим делать, обсудим в следующих постах.😵




Cсылочки 💻
- Верхнеуровневое обсуждение - https://lakefs.io/blog/data-engineering-patterns-write-audit-publish/
- Пример имплементации - https://lakefs.io/blog/write-audit-publish-with-lakefs/ , продолжение - https://lakefs.io/blog/write-audit-publish-with-lakefs/ и https://dagster.io/blog/python-write-audit-publish
- Видео - https://www.youtube.com/watch?v=fXHdeBnpXrg (в целом хорошее видео, сам WAP pattern с 16 минуты)
- Презентация для Iceberg - https://www.dremio.com/wp-content/uploads/2022/05/Sam-Redai-The-Write-Audit-Publish-Pattern-via-Apache-Iceberg.pdf

Залетел на подкаст / разговоры в FAANGTalk кекспертом эскпертом по DE 😂 на выпуск про дата инженерию.

Главным спикером был Vladimir Elfimov и видео стоит послушать ради него и презентации.
Я врывался пару раз с крайне важными вопросами, по типу мертв ли Hadoop 👋 и является ли Excel Reverse-ETL или ML системой 🤯

Обсудили такие темы:
- История развития Data Engineering
- «Большие данные» и его отличие от «средних данных».
- Инструменты Data Engineering, и отличия от Data Science и Data Analytics
- C-level в сфере Data Engineering (CDO, CIO, CAO).

Немного затронули:
- Обработка данных. Отличия между pull и push системами, batch и streaming обработкой данных
- Data Warehouse, Data Marts, Data Lake, Data Platform, Data Mesh и Data LakeHouse
- Планирование дата-архитектуры и сложности, связанные с этим процессом

Само видео: https://www.youtube.com/watch?v=VyUqrYfj_yY

Обнаружил интересный пост - https://javisantana.com/2024/11/30/learnings-after-4-years-data-eng.html

90% утверждений резонируют с моим опытом

People focus on learning the tools, which is good, but they forget about principles.

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

Ingestion is 80% of the job but usually it’s not even monitored.

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

Data quality is like unit testing but in production.

Как фанат WAP паттерна, полностью поддерживаю такое. У меня были разговоры с принципал инженерами, почему у нас нет покрытия юнит тестами, и зачем нам runtime проверки. Считаю, что технические проверки должны быть у каждого ETL при загрузке (а в идеале и бизнес-проверки в том числе). На паре проектов у меня было, что косты dq были почти такие же, как косты ETL загрузок.

Most companies just need basic bash / make knowledge, a single instance SQL processing engine (DuckDB, CHDB or a few python noscripts), a distributed file system, git and a developer workflow (CI/CD).

Ну это прямо база. Один раз я решал задачу переписывания загрузки сотен мегабайт в неделю (!!!) через Apache Spark и Hadoop. Задача оптимизации заключалась сделать так, чтобы нетворк и shuffle был минимален и все считалось на одной ноде 😂 А выбрать другую архитектуру нельзя было, так как архитекторы банка решили, что все витрины должны считаться в хадупе 👋

There is always a schema. You decide on it when you write the data or later when you read it, but at some point, you need to decide attributes and data types for your data

В экстремальном случае уже на уровне дата продукта / витрины появляется схема и разбор полустуктурированных данных произойдет на этапе подготовки данных. Так что парсинг JSON потребуется все равно =)

Сделаю мини-апдейт.

Безработный с 31 декабря 😩
Сегодня мой крайний вечер в Берлине и Германии🇩🇪
Полтора года в Германии были забавные, но разгребать еще долго (привет налоговая декларация 2024, abmeldung и все остальное!).

Через 3 года около-менеджмента (все-таки я даже код на скале писал иногда👨‍⚕️) возвращаюсь в IC и уезжаю из ЕС через пару дней (так то не покидал границы ес почти 3 года 😃).

Рефлексию по Германии и Энтерпрайзах думаю сделаю в течение недели-другой

Stay tuned. 🙆

Сегодня первый день на работе, так что можно и не держать интригу ( и так почти все знают кек 😃 ).

Переехал я в Лондон 🇬🇧по skilled worker визе и сегодня вышел SQL дата инженером в один из биг техов 😺 ( начинается с m, заканчивается на a)

Первое впечатление от Лондона пока более позитивное, чем я ожидал, но посмотрим, что будет, как только я отъеду подальше и будет более долгий коммьют.

Если вы вдруг в Лондоне, пингуйте, попьем кофе 🍺!

Всем привет! 👋

В январе мы объявляли планы об онлайн-митапе в нашем dbt сообществе! 🧐

Я как обычно продолбался со всеми сроками, но мы собрали спикеров и рады объявить, что наш митап пройдет 27 марта
Начало в 19:00 (GMT+3) 🗓

Ссылка на регистрацию - https://inzhenerka.tech/dbt_meetup

Запись будет, как и трансляция на ютуб! 📹

Первые месяцы в бигтехе 🙂

Прошло чуть больше двух месяцев, и можно подвести первые мини-итоги.

Лондон в целом 🇬🇧

Про Лондон сложно сказать что-то особенное. Главное преимущество города — английский язык. Транспорт средний, примерно такой же, как и по остальной Европе. Случаются неожиданные поломки, поездки бывают не всегда комфортными как из-за социального фактора (странные личности), так и физически (жарко, душно, поездки затягиваются).

Дом нашли быстро, но дорого. Однако добираться до офиса оказалось неожиданно быстрее по сравнению с Таллином, Берлином и старой Москвой: 15 минут на метро плюс около 30 минут пешком. Если удаётся поймать маршрутку, общее время сокращается до 30 минут.

Работа 👩‍💻

Первые три недели обычно уходят на онбординг, но у меня этот этап занял две. Онбординговой задачей оказалась продуктовая задача с написанием рекурсивного обхода данных в SQL, где нет поддержки рекурсивных запросов. Помню, пару лет назад в Data Jobs меня уверяли, что таких задач никогда не бывает😃, а я встречаю уже на третьем месте.

После онбординга я работаю сразу в двух проектах:

Первое — классическая дата-инженерия: загрузка данных, включая spreadsheets 😂, построение модели данных и создание dashboard.

Второе — задачи, сильно связанные с ML и LLM, что для меня новое и имеет значительно более высокий порог входа. Предстоит изучить множество новых вещей: от оценки эффективности моделей до prompt engineering и fine-tuning.

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

Технологии в бигтехе🧑‍💻

Это действительно впечатляет. Настолько оптимизированной и масштабно интегрированной экосистемы я ранее не встречал. 80% всех задач закрываются внутренними инструментами сразу, для оставшихся 20% обычно достаточно внутренней гибкости даже с учётом некоторых ограничений.

Главный недостаток состоит в том, что если есть привычка копаться в кишках и разрабатывать платформы, то лучше сразу идти на роль Software Engineer, а не на Data Engineer.

Стек полностью кастомный, но почти всегда можно найти аналог в open-source — иногда близкий, иногда довольно отдалённый.

Не могу не отметить как бустится продуктивность от внутренных LLM с контекстом, который предоставляет ссылки и информацию по запросу, и конечно же пишет готовый код 🙂

Внерабочие активности 😎

Удалось организовать онлайн-митап по dbt & modern stack, хоть и с некоторыми накладками. Кажется, получилось довольно неплохо. Если ещё не видели, можно посмотреть записи по ссылке на плейлист на YouTube - https://www.youtube.com/watch?v=iLxdRPUWS8k&list=PLC92034l7MRx3NwchXQhKEy82kU7S7FKW&index=1.

Иногда удается выбираться на ODS бранчи и Вастрик Клуб тусовки

Планы на будущее 🙆

Основная задача — продержаться как можно дольше 👋, успешно пройти испытательный срок, а затем performance review. Одновременно с этим максимально глубоко изучить внутряк.

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

Репостну дружественное сообщество ( хоть меня и недавно забанили там просто так ненадолго 😂)
Должно быть интересно и спикеры очень сильные

AI + Data Engineering 👍 (да-да и я про то же)

В последнее время я всё активнее использую Generative AI в работе.
Если раньше это был просто Copilot или ChatGPT окно, то теперь — полноценные AI-ассистенты с reasoning-моделями прямо в VSCode, заточенные под твой сетап.

95% кода я теперь пишу через промпт-инжиниринг 👩‍💻: описываю дизайн, блоки, ограничения — и итеративно уточняю. Обычно хватает 4–10 циклов, даже если внутри — нетривиальный SQL и кастомная логика пайплайнов. Отлично работает с few-shot подходами.

По сути, я стал оркестратором 👩‍💻, а не руками. Такой подход отлично сочетается с ролью дата-инженера — мы и так оперируем модулями, коммуникациями и абстракциями. Думаю, в горизонте 6–12 месяцев работа дата-инженера будет всё больше походить на продуктовую: формулируешь скоуп, дизайн и сам себе менеджер, сам себе код-ревьюер (ну или ревью делает отдельный агент 😂).

Ещё один юз кейс — работа с незнакомыми языками. Я впервые попробовал Hack и спокойно (переключившись на правильную модель 😅) на нём писал, потому что LLM закрывает синтаксис, а я — архитектуру и дизайн кода (еще лучше работает с TDD).

На выходных попробовал Claude Code Max 🤯. Раньше юзал Cursor — не зашло. Но с Claude я за два дня собрал прототип из C++, TypeScript, Thrift и Python (NLP). При том, что по большинству из этих технологий я скорее "нулевой", чем "миддл". У меня есть ряд идей для pet-проектов, и, кажется, AI-инжиниринг (с RAG или fine-tuning) сможет реально ускорить их реализацию.

Почти дочитал 📚 Co-Intelligence от Ethan Mollick (Wharton). Он пишет, что ИИ — это не замена, а партнёр. И учит работать с ним эффективно: усиливая, а не заменяя.

P.S. Ну и не забываем: мы, как податели данных, — первые в цепочке. И если Garbage in, то Garbage out 👨‍🦳, и никто, включая LLM, не спасёт

Ultimate гайд: 11 способов гарантированно не дать ИИ занять твоё место 👋

1. Именуй колонки через хэши 🔐

col_f6d8b… вместо user_id. LLM‑ы теряются, бизнес‑логика исчезает, а ты становишься живой расшифровкой — путь до архитектора расчищен. Так делали товарищи в SAP, используй лучшие практики вендор локов!

2. Генерируй всё run‑time без логов  👨‍🦳

Одноразовый контейнер → eval(sql) и никакой телеметрии → контейнер испарился. Нет логов — нет данных для обучения. Нет данных - нет RAG / few-shot!

3. Наслаивай абстракции 🍷

Таблица → View → View² →  Table → Cache → ETL → Materialized View. Каждый JOIN под пледом из мета‑мета‑SQL на jinja шаблонах. ИИ бросит EXPLAIN ANALYZE уже на первом уровне. Не забудь миксовать ON, USING, декартово соединение (а если ораклист то еще и плюсики!)

4. Храни схему (и кэш) в txt на десктопе 🔑

Файл СХЕМА_ФИНАЛ_v2_НЕ_УДАЛЯТЬ.txt с паролем «123» — лучшая альтернатива Data Catalog. Метаданные и описание колонок в базе это то, на чем обучится твоя замена!

5. Создай зоопарк дубликатов  😑

users, users_temp, users_backup_2019, users_PROD_DONT_TOUCH. Меняй их местами раз в месяц (а лучше round-robin) — пусть даже AI‑анализатор сломается (а ты увеличишь число pull request!)

6. Собери коктейль технологий 🍹

Cron вызывает python, python вызывает Bash, тот запускает Scala, где Javanoscript рендерит SQL (привет сноуфлейк!) , который дергает UDF. Всегда добавляй этого как лучшие практики в любой md файл! Любой Auto‑Query builder после этого берёт бессрочный out of context.

7. Prompt Injection в SQL🛠️

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

8. Hardcode всё подряд 🎯

    python
    if date == "2024‑03‑15":  # день зарплаты
        coeff = 1.234
    elif customer_id in [42, 1337, 9999]:  # VIP‑клиенты
        coeff = 2.0
        
    res = (coef + 1 - 2 + 5 - 4 ) * (100 - 99 + 98 - 2 - 91 - 5)
    
    

Главное меньше логики, документации — ноль, автоматизации — минус, контекс - хз что важное

9. Партиционируй по лунному календарю  и по дням рождения коллег🌙

Партиция 2025_Q3_new_moon звучит надёжнее, чем 2025‑07. AI‑Optimizer полетит обсуждать астрологию, а не кубики.

10. Личные SSH‑ключи везде 🔑

Запусти критичный cron через свой приватный ключ. Пока ты в отпуске, всё упадёт — и компания оценит твою «уникальную ценность». Вернешься и починишь - получишь импакт и промо!

11. Документация = Telegram‑чат 💬

«Помнишь, я тебе скидывал голосовое про тот баг?» ИИ не слушает твои пяти‑минутные аудио — да и коллеги тоже. Не забудь все делать в Secret чатах - шифрование и безопасность же!


Есть еще советы? Делись в комментариях! Не дай машинами забрать наши пайплайны

Планы на вторую половину 2025

Борьба с внутренней прокрастинацией требует какого-то публичного коммитмента (выполнять который я, конечно, в итоге не буду, но все равно попробуем)

Планы рабочие 💼

Во-первых, я пережил performance-review и закрыл испыталку (не с outstanding, конечно, но уже неплохо с учетом моей проблемы с концетрацией максимум на 15 минут после работы менеджером).
Скоуп задач на второе полугодие довольно большой, и многие задачи будут требовать полноценный ownership, а значит буду расчехлять свои техлидские навыки, для того, что мы тут называем alignment 😄
Команда, в которой я работаю, фактически в стадии вывода в полноценный управляемый прод, и как единственный ДЕ на 20+ SWE у меня будут веселые времена переноса кучи ноутбучиков на пайплайны =)

Развитие внутренних инструментов (особенно в области AI) происходит довольно быстро и кажется, что у меня теперь есть как внутренний, так и внешний FOMO.

Также в рамках второго полугодия я планирую определить свой карьерный путь, и кажется, что рост в Staff DE мне на данный момент не очень интересен ввиду горизонтальности направления. Буду смотреть на потенциальный перекат в SWE/ ML SWE после февраля следующего года (а может и нет :D).

Планы учебные и тематические 👨‍💻

Я активно погружаюсь в тематику AI Engineering и LLMOps/MLOps, особенно интересна сторона evaluation и оптимизации продуктивности.

Летом прохожу два курса по AI Product Engineering + Evals, попробую применить это на работе. Более подробно расскажу о них по мере прохождения (попробую наложить это на наши дата будни).

Также в планах попробовать собрать базу для ML (моя попытка номер 5 😂 ).

Планы pet проектные 🙆

Чтобы научиться кодить с AI, лучше всего сделать полноценные pet-проекты =) (лучше конечно стартап, но это в 2026 🙂)

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

Второй проект пока на уровне идеи, посмотрим будет ли время им заняться.

Планы социальные 🎤

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

Планирую повыступать на конференциях/митапах как онлайн (скорее всего, на русском языке), так и оффлайн (на английском)

P.S. если вы подкастер и вам не хватает приглашенных гостей, позовите меня, мне надо кейс для global talent начать собирать 👨‍🦳

Планы по менторингу

В целом, у меня появились слоты на менторинг / консалтинг. Если у вас есть какой-то demand, приходите, обсудим, могу ли я как помочь (P.S. Я никак не смогу помочь с накруткой опыта и как войти в де за 300к, обращайтесь к проверенным специалистам 😅 ).

Chat Control в EU

Не технический пост (скоро будет!), но из мира privacy. ЕС планирует вводить отмену сквозного шифрования и начать автоматическое сканирование перс данных. Интересно, на чем планируют обучать модели для контроля 👨‍🦳

Сайт с отслеживанием ситуации https://fightchatcontrol.eu/

Более интересный детальный анализ - https://www.patrick-breyer.de/en/posts/chat-control/