Сколько инструментов ни добавляй, централизованная data-команда всё равно останется узким местом ⚡️

Вопрос: как реально сократить TTM — технологиями или перестройкой процессов?

▶️ Разбираемся в видео

🔑 Натуральный ключ vs Натуральный ключ + Код системы источника

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

Часто выбор сводится к двум вариантам – использовать только натуральный ключ или комбинировать его с кодом системы источника.
Давайте разберём плюсы и минусы каждого подхода.

1️⃣ Только натуральный ключ

Натуральный ключ – это уникальное поле или набор полей в таблице, которое естественным образом идентифицирует объект (номер паспорта, код продукта и т.д.).

На самом деле, самый правильный подход, ведь в таком случае значительно упрощается интеграция различных источников. Основные данные по клиенту хранятся в CRM, а его заказы в OMS. С одним натуральным ключом их легко соединить в DWH.

Есть только один момент – практически никогда вы не сможете определить такой натуральный ключ у объекта.
Что для клиента натуральный ключ? Номер паспорта? Он может меняться со временем и далеко не всегда вы такую информацию имеете. ФИО + дата рождения? Все равно остается риск коллизии, не учитывая что данные атрибуты могут (и будут) криво заполнены у некоторых клиентов.
ID клиента в CRM? Если у вас несколько Систем, в которых лежат клиенты, один ID может быть у нескольких клиентов. Получите дубли.

2️⃣ Натуральный ключ + Код системы источника

Код системы источника — это уникальный идентификатор, который обозначает конкретную систему или источник данных в DWH.

Здесь все просто. Берем ID из Системы и добавляем код системы конкатенацией.
В таком случае не будет дублей, и определить натуральный ключ у объекта весьма просто (в Системах практически всегда у каждого объекта есть ID).

Но в таком случае придется дополнительно маппить объекты, создавая золотую запись. Что на мой взгляд правильнее.

💡 Итог:
Если ваш DWH строится на данных из нескольких систем – комбинированный ключ почти всегда выигрывает. Но можно у разных объектов использовать разные подходы.

🍴 3 фишки dbt, о которых мало кто знает

dbt отлично подходит для трансформации данных, но помимо стандартных моделей и тестов есть менее очевидные, но очень полезные возможности. Вот три из них:

1️⃣ Exposures
Exposures позволяют документировать, как ваши модели используются внешними системами: дашбордами, ML-моделями или отчетами. Это помогает отслеживать влияние изменений в моделях и строить понятную data lineage.

exposures:
- name: monthly_sales_dashboard
type: dashboard
url: https://looker.company.com/dashboards/123
depends_on:
- ref('monthly_sales')

Явно указываем, что дашборд с помесячными продажами зависит от dbt модели monthly_sales

2️⃣ Hooks (pre-hook и post-hook)
Hooks в dbt позволяют запускать SQL или скрипты до или после выполнения модели. Это мощный инструмент автоматизации, который мало кто использует, но он очень полезен для:
- автоматической записи логов о выполнении модели
- обновления статистики
- очистки staging-таблиц или временных ресурсов
- выполнения любых операций, которые должны сопровождать модель, но не входят в её основной SQL-код.

Hooks задаются в dbt_project.yml или внутри отдельной модели через config.

{{ config(
post_hook="ANALYZE {{ this }}"
) }}

3️⃣ Тип модели: private, protected, public
В dbt можно помечать модели как private, protected или public.
- private — для внутренних промежуточных расчетов, которые никто напрямую не использует.
- protected — модели, которые можно использовать ограниченно, например внутри проекта.
- public — доступные для всех потребителей.

Это помогает грамотно управлять видимостью моделей, защищать критические промежуточные данные и упрощает работу команд

🌊 Типовые слои данных

Хранилище данных можно представить как слоенный пирог – каждый слой содержит определенные данные.

Вот самый распространенный вариант распределения данных:

🔹 RAW – «сырые» данные, загружаются из источников как есть, без очистки и трансформаций
🔹 ODS (Operational Data Store) – оперативное хранилище, где данные приводятся к единому формату и очищаются от очевидного «мусора»
🔹 DDS (Detail Data Store) – детальное хранилище, где данные нормализованы и связаны между собой. Это основа для аналитики
🔹 CDM (Common Data Mart) – общие витрины, агрегированные данные, которые часто используются при построении отчетов (пример: золотая запись клиента)
🔹 DM (Data Marts) – прикладные витрины для конкретных пользователей или задач (например, отчёты для маркетинга)

Параллельно часто используют метафору bronze / silver / golden слоёв:

🥉 Bronze ≈ RAW – сырые данные
🥈 Silver ≈ ODS/DDS – очищенные, обогащённые, готовые к использованию
🥇 Golden ≈ CDM/DM – финальные бизнес-витрины, где данные максимально близки к бизнес-логике

ℹ️ Разница в том, что модель RAW-ODS-DDS-CDM-DM пришла из классических DWH, а bronze-silver-gold – это более «облачная» и современная интерпретация, часто используемая в дата-лейках и lakehouse-архитектурах.

💻 Обновление года – вышел PostgreSQL 18!

И нет, это не просто минорное обновление, а настоящий прорыв! Рассмотрим основные функции.

🔹 Асинхронный I/O
Чтение данных в PostgreSQL стал значительно быстрее за счет этого нововведения! Если не сильно вдаваться в технические подробности, при синхронном I/O операции чтения с диска являются блокирующими, что часто становится узким местом. Теперь в PostgreSQL операции ввода-вывода могут работать параллельно.

Заявлен прирост производительности в 2-3 раза!

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

Остальные фичи не так сенсационны, но тоже весьма интересны.

🔹 UUID версии 7
UUID – уникально сгенерированная строка вида 550e8400-e29b-41d4-a716-446655440000. Часто используются как уникальные ключи для таблиц.
В 7 версии были исправлены моменты с низкой эффективностью сортировки таких ключей и индексированием.

🔹 Эффективнее B-tree индексы
Заявлен серьезный прирост производительности при использовании многоколоночных B-tree индексов.

🔹 OAUTH 2.0
Теперь Postgres совместим с OAUTH 2.0

В общем, на нашей улице праздник. Любимый PostgreSQL стал еще эффективнее в части OLAP и, вероятно, сможет покрыть больше сценариев, связанных с аналитическими решениями.

🛢 Big data на самом деле не существует!

Решил вспомнить статью, которая вышла еще в далеком 2023-м, но которая актуальна и сейчас.

Главный посыл статьи:

Big data более не существует, а может никогда и не существовало. Большинство компаний имеют в своем хранилище менее 1TB данных и думают, что это много.

Автор, один из создателей Google BigQuery, утверждает: эпоха «больших данных» — это уже прошлое. Проблема давно не в объёмах данных, а в их эффективном использовании. Сегодня инфраструктура и технологии выросли настолько, что масштаб обработки уже не является главным препятствием.

Возможности аппаратного и программного обеспечения растут. Технологии все лучше обрабатывают данные, а аналитические базы данных становятся все быстрее.

❗А самое главное (с чем я на все 100 согласен) — большинство компаний попросту не имеет большого объема данных.

Крупные big tech компании вроде банков или маркетплейсов действительно ворочают десятками петабайт, но ведь эти компании составляют менее 1% от общего числа компаний, которые используют DWH. Чаще всего всего в DWH действительно менее 1 терабайта, с чем справится стандартный PostgreSQL без каких-либо проблем 💻

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

Еще часто компания страдает от того, что хранит устаревшие и ненужные данные, которые более никогда не будет использовать. А еще тащит эти детальные или устаревшие данные в BI, думая, что пользователи дашбордов будут их использовать.

Сплошь и рядом в аналитические кубы или BI с невероятным усердием запихиваются не агрегированные данные или данные десятилетней давности. А после того, как их запихнули, начинают пытаться оптимизировать, ведь они кубы стали гораздо медленнее работать.

Решение же лежит на поверхности — удалить ненужные данные!

🔹 В общем, с текущими технологиями можем обрабатывать действительно много данных, но чаще всего этого не требуется.

Лично мне кажется, что акцент нужно делать не на том, сколько данных и за какое время вы можете обработать. А на качестве этих данных. Гораздо важнее быть уверенным в своих данных, а не иметь большие объемы мусора.

Как Data Mesh помогает повысить производительность аналитики ❗

Data Mesh меняет сам подход к работе с данными: вместо одной централизованной команды — множество доменов, каждый из которых отвечает за свою часть данных и создает полноценные дата-продукты.

В видео — просто о том, как работает децентрализация, зачем нужны доменные команды и почему единая платформа — ключ к эффективности.

🌊 Data lineage в 2025: почему это must-have или как не превратить свой Data lake в Data swamp.

Если пару лет назад про data lineage говорили как про «приятный бонус» к стеку, то сейчас без него сложно представить нормальную работу data-инженеров.

ℹ️ Data lineage — это прослеживаемость данных: откуда они пришли, через какие трансформации прошли и в какие витрины/отчёты попали. Другими словами документация, которая показывает зависимости между таблицами.

И вот почему в 2025 он стал необходимостью:

🔹 Рост количества источников и таблиц
В 2020–2021 мы могли «на глаз» держать в голове, что тянется из CRM в витрины продаж. Сегодня же Kafka + десятки топиков, десятки джоб в Airflow, сотни моделей в dbt и десятки витрин. Без документации все превратится в болото.

🔹 Обслуживание
Без понимания что от чего зависит вы будете тратить много времени на impact-анализ. Как тратил я на заре своей карьеры, копаясь в десятках SQL-прототипах и вручную выписывая зависимости.

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

Мы свои трудозатраты снизили примерно на 20% с использованием data lineage.

Работа с данными все больше походит на разработку ПО: тесты, зависимости, Git, CI/CD. Это конечно все замечательно.
Те, кто продолжают жить по старинке попросту тратят гораздо больше сил и времени на стандартные процессы.

А вы у себя уже внедрили lineage?

Частые проблемы data mesh ⛔️

Вы, конечно, можете нарезать компанию на домены, красиво всё расписать по ролям…

А потом поймёте, что аналитиков не хватает, data-инженеров ещё меньше, а половина сотрудников не поняла, что вообще происходит.

Дальше будет классика жанра:
— сопротивление новым процессам
— «велосипеды» в каждом домене
— зоопарк технологий
— и повышенный порог входа, когда аналитик внезапно становится всем — от инженера до тестировщика

В общем, Data Mesh — штука хорошая, но только если вы готовы к человеческой стороне вопроса.

Как раз о ней — в новом видео 🎥

💻 Чем dbt лучше хранимых процедур?

Тут недавно вышла статья в блоге dbt – сравнение хранимых процедур и dbt. И мне она совершенно не понравилась. Тезисы выстроены для мало разбирающихся менеджеров:
- вы не внедрите AI в хранимки (а зачем?)
- кандидаты будут выбирать других работодателей ведь хранимки – это прошлый век
- хранимки – legacy (но не объясняется почему)

Хранимые процедуры – неотъемлемая часть любого среднестатистического хранилища данных. Раньше нельзя было представить себе DWH без «хранимок». Но они действительно постепенно уходят в прошлое. Я постараюсь получше и без маркетинговых уловок объяснить, почему dbt лучше «хранимок».

🔹 В dbt все DML операции спрятаны
В хранимой процедуре потребуется вручную прописывать логику INSERT, UPDATE, DELETE. В то время как в dbt из коробки доступны разные стратегии обновления, которые эту «обвязку» сделают за вас.

Да, в хранимых процедурах вы больше контролируете логику, зато с dbt вы гораздо меньше времени тратите на рутину. Ведь логика обновления данных у 90% объектов одинаковая – добавь новые данные (append), проставь новую версию.

Если вам требуется своя кастомная логика обновления – в dbt вы можете добавить свою стратегию обновления, написав ее в jinja.
Это кстати то, что мы сейчас делаем в нашем новом продукте dbtPro – добавляем множество своих стратегий обновления. А то в dbt их слишком уж мало.

🔹 Тяжело поддерживать
В статье об этом тоже говорится, единственный хороший тезис. Хранимые процедуры ой как сложно поддерживать. Особенно, если одна зависит от другой, а другая зависит от третьей. Чаще всего никакой документации к ним нет; сотрудники, которые их делали давно уволились; не дай бог, в процедуре обновляется сразу несколько таблиц. И вот вы сидите и тратите уйму времени, чтобы внести мизерное изменение в этот ворох.

Dbt гораздо прозрачнее в этом плане. Есть встроенный функционал документации, можно фиксировать зависимости, один файл dbt – одна таблица. А главное – только SELECT-запросы внутри файлов, а не ворох непонятных DML-операций.

🔹 Кросс-функциональность
Удивительно, что dbt в своей статье забыли упомянуть эту киллер-фичу – dbt умеет работать со множеством СУБД. И при переезде на новую, вам не потребуется переписывать ворох DML-операций на новый синтаксис.

Да, сами SQL-запросы возможно переписать потребуется, но их «обвязка» в виде вставок и обновлений данных – это dbt берет на себя.

🔹 Нет Git
Да, хранимки конечно можно сохранить в текстовый файл и залить в Git. Но в какой-то момент вы обновите в DWH хранимку и забудете скопировать исправления в файл и закомитить в Git. Любые дополнительные действия без проверки исполнения, в итоге забываются. И вы 100% получите рассинхрон Git с актуальной версией хранимки.

В dbt вся SQL логика изначально хранится в файле. И грех не комитить этот файл в Git.

🔹 Хранимые процедуры - сложно
Ну и конечно, главный минус хранимых процедуры – они сложны в реализации. Я не сомневаюсь, что вы, читатель, несомненно крутой SQL-специалист. Но помимо вас есть еще огромное количество аналитиков, 90% которых не сможет написать хранимую процедуру.

А вот какой-нибудь SELECT аналитик уже написать сможет.

Мое скромное мнение – хранимые процедуры проигрывают битву за DWH и постепенно будут заменены на dbt и подобные аналоги.