#никчитает
Обзор на Analytics Engineering with SQL and dbt

Сегодня узнал о выходе книги Analytics Engineering в O'Reilly with SQL and dbt - https://www.oreilly.com/library/view/analytics-engineering-with/9781098142377/

Автор был бы не автором, если бы ее уже не прочитал =)

Пройдемся по главам

1. Analytics Engineering. Обзорная глава про историю, появление и кто такие эти analytics engineers. Корни AE, откуда взялся BI, как в Cloud Era появились решения, демократизирующие инструментарий. Рассказ про жизненный цикл дата аналитики (-> Определение проблемы -> Моделирование данных -> Внедрение данных и трансформация -> Хранение данных и структурирование -> Визуализация данных -> DQ, мониторинг, тестированик и документировние ).
Обсуждают роль и ответственность AE, базовое обсуждение Data mesh и Data product, переход от легаси BI/ETL систем (с visual-coding etl и процедурными расширениями) в modern data stack (с visual-coding etl и процедурными расширениями, прим. Nik 🙂)

2. Data Modeling. Глава про моделирование данных. КМД, ЛМД и ФМД, нормализацию (да-да, нормальные формы в 2к24 😂), базовое ведение в схему звезда/снежинка с упоминанием Кимбала и Инмона, и невнятный параграф про Data Vault 😡. Обсуждается переход от монолитного дата моделирования к модульному дата моделировани. В конце вводят Medallion Architecture Pattern. Последнее, это просто Bronze-Silver-Gold layers - https://www.databricks.com/glossary/medallion-architecture

3. SQL For Analytics. 🔥 Рассказывают про основы SQL с оконками, join как обычно через диграммы Венна 😺. Вторая часть - про SQL for Distributed Data Processing, используя DuckDB, Polaris, и FugueSQL 🤯 (новое для меня).

4. Data Transformation with dbt.😃 Основы dbt, причем показывают как запускать только для dbt cloud (никакой core настройки не описано).

5. Dbt Advanced Topics😃. Кратко обсуждают такие понятия, как материализация, jinja шаблоны, макросы, пакеты и semantic layer.

6. Building An End-to-End Analytics Engineering Use Case 👍. Показывают полноценное "end-to-end" решение от заливки сырых данных в BigQuery из MySQL до финальной витрины данных и ad-hoc аналитики. 😎Треть главы уделена тому, как делать архитектуру дата решения (как определяем бизнес-процесс, понимаем, какие данные нужны, моделируем). Сначала проектируем - потом кодим. 🔥

⚡️Книга оставила смешанное впечатление. В плюс занесу 1 и 6 главу. В главе 2 про дата моделирование получилась какая-то каша терминов, и я не увидел какой-то раскрытости. 3 глава представляет собой базовое введение в SQL, и добавление про DuckDB, которое дальше вообще никак не используется 4 и 5 главы про dbt, уступают dbt мануалам.
Из минусов таже отмечу отсутствие Further Reading или доп материалов.
Читая книгу, я словил дежавю, как будто это мини-курс Analytics Engineer (Аналитик DWH) на ОТУС времен 2022 годов. Разрозненный материал, с разными доменными примерами и технологиями от главы к главе, который надо собрать как-то у себя в голове.


🙆Оценка 3/5. Подойдет, как доп. материал к dbt курсам, если у вас есть подписка O'Reilly.

#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 чатах - шифрование и безопасность же!


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