Данный перевод выполнен с небольшими примечаниями. Используйте статью как ориентир, проверяя по каждой базе и каждому адаптеру возможность реализации. Особенно это касается партиций. Перевод выполнен 1 в 1 без удаления реплик автора.

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

Плюс в конце статьи еще есть подборка видео с YouTube на english.

Понимание инкрементальных стратегий dbt, часть 1/2

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

Используя инкрементальные модели, вы можете преобразовывать и добавлять в таблицы только недавние данные, значительно сокращая (в зависимости от размера таблицы) затраты на обработку и время выполнения. Однако, прежде чем углубляться в эту тему, вам нужно задать себе вопрос: действительно ли вам нужно использовать инкрементальные модели?

Инкрементальная материализация — это продвинутая и мощная функция dbt, но ее не нужно применять в каждой модели проекта. Есть несколько моментов, которые следует учитывать, чтобы не изменять конфигурацию модели и не добавлять множество условий Jinja без необходимости.

Стоит ли использовать инкрементальную модель?

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

Стратегия полного обновления (full refresh)

Полное обновление — это стандартный и наиболее распространенный процесс преобразования данных в вашем хранилище данных (DW). Если вы не укажете материализацию как инкрементальную, ваша таблица будет полностью пересоздана при каждом запуске.

Предположим, у нас есть исходная таблица с данными до 2022-02-02, и мы хотим обновить целевую таблицу, содержащую данные до 2022-01-04. При использовании стратегии полного обновления dbt сначала удалит текущую целевую таблицу (1), а затем создаст новую таблицу из преобразованных исходных данных (2).

Рисунок 1 — Пример полного обновления

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

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

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

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

С точки зрения низкой сложности и практического использования, полное обновление может быть полезным для быстрого предоставления целевой таблицы конечному пользователю, что позволяет создавать ценность как можно быстрее. Таким образом, конечный пользователь может проверить преобразование и дать обратную связь, попросив о изменениях или исправлениях. Кроме того, наличие преобразованной таблицы в продакшене дает аналитическому инженеру лучшее понимание базы данных: как часто обновляются данные и какой объем данных обрабатывается при каждом запуске. Эти аспекты важны для оптимизации модели.

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

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

Основные преимущества:

• Простота реализации
• Быстрое создание ценности
• Гарантия того, что все данные будут добавлены в целевую таблицу, независимо от правил обновления БД

Основные недостатки:

• Высокие затраты на обработку
• Длительное время обработки

Когда использовать:

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

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

Если вы новичок в dbt или плохо знаете команды dbt, ознакомьтесь с моей статьей о командах dbt: 17 dbt Commands You Should Start Using Today.

Инкрементальные модели

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

Чтобы dbt знал, какие данные являются недавними, в вашей таблице должен быть столбец одного из следующих типов: date, datetime, timestamp или int64. Модель будет использовать столбцы исходной и целевой таблиц для фильтрации данных, которые нужно преобразовать, добавить, обновить или удалить.

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

Также важно отметить, что ваша таблица будет обрабатываться инкрементально, если выполняются три условия:

1. целевая таблица уже существует в базе данных,
2. dbt не запускается в режиме полного обновления (вы не используете флаг --full-refresh), и
3. текущая модель настроена с materialized='incremental'.

dbt предлагает четыре типа инкрементальных стратегий:

• append
• merge
• delete+insert
• insert_overwrite

Доступность стратегии зависит от используемого адаптера. В документации dbt перечислены три адаптера и их соответствующие стратегии:

• Snowflake: merge (по умолчанию), delete+insert (опционально)
• BigQuery: merge (по умолчанию), insert_overwrite (опционально)
• Spark: append (по умолчанию), insert_overwrite (опционально), merge (опционально, только для Delta)

Давайте рассмотрим каждую из них.

Append

Стратегия append (добавление) очень проста: она просто берет выбранные записи и вставляет их в целевую таблицу. Она не может обновлять или удалять записи, только вставлять. Вы можете использовать эту стратегию только в том случае, если дубликаты не являются для вас проблемой. Append не заботится о дубликатах: она не проверяет, существует ли запись уже в целевой таблице, а просто вставляет дублированные записи.

Примечание от datatalks.ru: можно вставлять только новые строки, проверяя наличие в таблице. Но, возможно, в стандартных стратегиях appends в адаптерах не реализована проверка наличия строк. Или, например, отсутстует anti join и его можно реализовать, например, через LEFT JOIN с условием IS NULL.

Например, предположим, что у нас есть те же таблицы, что и в примере с полным обновлением. Если мы выберем записи за сегодня и вчера (1), допустим, сегодня 2022-02-02. Строки будут вставлены в целевую таблицу (2), и мы получим 2 дублированные строки.

Рисунок 2 — Пример Append

Ключевые моменты append:

Основные преимущества:

• Простота и понятность
• Низкие затраты на обработку, так как не требуется сканирование целевой таблицы
• Низкое время обработки

Основные недостатки:

• Невозможно обновлять или удалять строки, только вставлять
• Дубликаты! (примечание от datatalks.ru: нужно их обрабатывать с помощью Anti Join)

Когда использовать:

• Когда вы работаете с таблицами только для добавления записей (append-only)
• Когда вас не беспокоят дубликаты
• Когда требуется только добавление новых строк

Merge

Стратегия merge решает проблему дублированных записей. Она может обрабатывать дубликаты, если вы укажете уникальный ключ (который может состоять из одного или нескольких столбцов). Если уникальный ключ уже существует в целевой таблице, merge обновит запись, поэтому дубликатов не будет. Если записи не существуют, merge добавит их.

Чтобы проверить совпадение уникальных ключей в обеих таблицах, merge должен сканировать всю целевую таблицу, а также выбранную часть исходной таблицы. Это полное сканирование делает стратегию довольно затратной.

Если вы используете merge без указания уникального ключа, это фактически то же самое, что append. Однако, например, в BigQuery использование уникального ключа с merge является обязательным.

Рисунок 3 — Пример Merge

Вернемся к нашему примеру. Предположим, сегодня 2022-02-02, и мы хотим объединить записи за сегодня и вчера с помощью merge.

Dbt сначала получает выбранные записи, указанные в операторе where (1). Затем выполняет сканирование (2), и если записи существуют в целевой таблице, они обновляются; если их нет, они добавляются (3).

Чтобы повысить производительность merge и сократить затраты, целевую таблицу можно кластеризовать. Таким образом, не потребуется полное сканирование целевой таблицы.

Рисунок 4 — Пример кластеризации для Merge

Ключевые моменты merge:

Основные преимущества:

• Устраняет дубликаты
• Хорошо работает для небольших таблиц (менее нескольких миллионов строк)

Основные недостатки:

• Высокие затраты на обработку из-за необходимости полного сканирования целевой таблицы

Когда использовать:

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

Delete+Insert

Стратегия delete+insert очень похожа на merge, но вместо обновления существующих записей и добавления новых она удаляет существующие записи и вставляет как новые, так и уже существующие записи. Поскольку она удаляет существующие записи из целевой таблицы, дубликаты также отсутствуют.

Рисунок 5 — Пример стратегии Delete+insert

(Да, я знаю, что использую этот пример на протяжении всей статьи :), но, на мой взгляд, так легче объяснить.)

При использовании delete+insert dbt сначала получает выбранные записи (1), выполняет их сканирование и полное сканирование целевой таблицы для сравнения уникальных ключей (2). Затем удаляет (3) существующие записи и вставляет выбранные (4).

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

Insert Overwrite

Последняя инкрементальная стратегия, о которой я расскажу, — это insert overwrite. Эта стратегия решает проблему полного сканирования. Решение, используемое в insert overwrite, заключается в работе с разделами (partitions).

Разделение таблицы на части означает ее деление на сегменты. Для работы insert overwrite раздел может быть следующих типов:

• date,
• datetime, timestamp, (примечание от datatalks.ru: скорей всего нельзя, слишком много значений будет)
• int64.

А его гранулярность может быть по часу, дню, месяцу или году. Если вы используете int64, необходимо задать диапазон. Вы должны указать столбец, значения которого будут использоваться для формирования разделов, и в каждом разделе будут записи с одинаковым значением гранулярности.

Стратегия insert overwrite удаляет выбранные разделы из текущей целевой таблицы и вставляет в нее выбранные преобразованные разделы.

Рисунок 6 — Пример стратегии Insert Overwrite

В приведенном выше примере целевая таблица разделена по дням (для повышения производительности исходная таблица также может быть разделена). Необходимо указать, какие разделы будут заменены в целевой таблице, и они определяются параметром конфигурации под названием partitions (мы рассмотрим это подробнее в следующей статье). В этом примере мы хотим заменить разделы за сегодня и вчера, предположим, что сегодня 2022-02-02.

Мы можем использовать оператор where в модели, указав, что нас интересуют записи, даты которых входят в параметр partitions. Таким образом, будут выбраны записи за сегодня и вчера (1).

Затем в целевой таблице находятся и удаляются соответствующие разделы как часть оператора merge (2). Так как таблица разделена, полное сканирование не требуется. Это основное отличие между insert overwrite и merge, что значительно сокращает объем обрабатываемых данных.

Наконец, выбранные записи вставляются в целевую таблицу как часть оператора merge (3).

За исключением использования разделов, этот процесс похож на стратегию delete+insert. Однако стратегия delete+insert использует два отдельных оператора — delete и insert, а insert overwrite использует оператор merge с постоянным ложным предикатом.

Insert overwrite — это стратегия высокой сложности. Если ее неправильно настроить, она может приводить к дублированию данных. Например, представим таблицу сотрудников, и мы используем стратегию insert overwrite на основе столбца updated_at.

Рисунок 7 — Проблемы с Insert Overwrite

Если через месяц запись сотрудника 1 будет обновлена, эта запись снова будет вставлена в целевую таблицу. Периодическое полное обновление решает эту проблему, но если вы не можете ждать выполнения полного обновления, следует использовать другой столбец или рассмотреть стратегию merge.

Основные моменты Insert Overwrite:

Основные преимущества:

• Низкие затраты на обработку
• Низкое время обработки

Основные недостатки:

• Высокая сложность
• Может привести к дублированию данных, если неправильно настроено

Когда использовать:

• Когда вы работаете с большими динамическими наборами данных
• Когда затраты и время обработки становятся проблемой

Сравнение стратегий

Вот сравнение различных стратегий. Delete+insert не включена, так как я не нашел достаточно информации о ней. Более детальный бенчмарк инкрементальных стратегий вы можете найти по ссылке.

Рисунок 8 — Сравнение стратегий

Заключение

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

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

Надеюсь, вам понравилась эта статья! Лучший способ изучить что-то — попытаться объяснить это кому-то другому, и это то, что я пытаюсь сделать. Оставляйте комментарии, если у вас есть вопросы, предложения или даже исправления к тексту!

=== Конец перевода ===

Вторую статью можно почитать по ссылке (юзать сами знаете что): Understanding dbt Incremental Strategies part 2/2

Ознакомьтесь с официальной документацией по инкрементальным моделям:

• Configure incremental models
• About incremental strategy
• About microbatch incremental models

Дополнение к статье YouTube (как смотреть разберетесь, надеюсь)

Merge Tables With Incremental Models | dbt Tutorial

YouTube — dbt Tutorial: dbt incremental models in bigquery; MERGE vs. INSERT_OVERWRITE

Dbt Materializations — Incremental Snapshot | data build tool | Slowly Changing Dimension SCD Type 2

Incremental Models (Faisal El Shami)

Сообщение Понимание инкрементальных стратегий dbt, часть 1 появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

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

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

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

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

Понимание моделирования данных и нормализации критически важно для эффективного анализа данных. Без подходящей модели данных аналитикам может быть трудно получить доступ к данным и правильно их интерпретировать, что может привести к ошибочным выводам и неэффективным решениям. Кроме того, отсутствие нормализации может привести к аномалиям данных, несоответствиям и затруднениям в их агрегировании, что препятствует процессу анализа.

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

В дополнение к SQL, dbt играет центральную роль в этой истории, поднимая искусство моделирования данных на новый уровень. Он выступает в роли всеобъемлющей платформы для построения и оркестрации сложных конвейеров данных. В рамках этой платформы пользователи могут определять логику преобразования, применять важные бизнес-правила и создавать многократно используемые модульные компоненты кода, называемые моделями. Стоит отметить, что dbt выходит за рамки автономной функциональности: он легко интегрируется с системами контроля версий, упрощая совместную работу и обеспечивая последовательность, возможность аудита и лёгкую воспроизводимость моделей данных.

Ещё одним важным аспектом SQL и dbt в моделировании данных является их акцент на тестировании и документации, хотя с определёнными различиями, которые стоит уточнить. В контексте моделирования данных тестирование включает проверку точности, надёжности и соответствия модели данных бизнес-правилам. Хотя важно отметить, что возможности тестирования в dbt отличаются от традиционного юнит-тестирования в разработке программного обеспечения, они выполняют схожую цель. Вместо традиционных юнит-тестов dbt предлагает запросы валидации, которые сопоставимы с теми, что аналитики обычно запускают. Эти запросы проверки обеспечивают качество данных, их целостность и соответствие определённым правилам, создавая уверенность в результатах модели. Более того, dbt превосходит в документации, являясь ценным ресурсом как для аналитиков, так и для заинтересованных сторон. Эта документация упрощает понимание логики и предположений, лежащих в основе модели данных, что повышает прозрачность и способствует эффективному сотрудничеству.

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

Краткое введение в моделирование данных

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

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

Во время этого процесса сбора необходимо сосредоточиться на естественной коммуникации — письменном языке. Формулируя факты о бизнесе в однозначных предложениях, мы обеспечиваем точное отражение бизнеса, свободное от интерпретации. Разбиение сложных предложений на простые структуры с подлежащими, сказуемыми и прямыми дополнениями помогает лаконично зафиксировать реальности бизнеса.

Помимо этих ключевых практик, стоит отметить, что эксперты в данной области, такие как Лоуренс Корр в своей популярной книге Agile Data Warehouse Design (DecisionOne Press), рекомендуют использовать дополнительные техники, такие как визуализация на доске и обсуждение, на начальном этапе проектирования моделей данных. Эти стратегии могут привнести тонкость в процесс, позволяя более глубоко изучить требования бизнеса и гарантировать, что итоговые модели данных будут безупречно соответствовать целям и особенностям бизнеса.

После завершения этапа понимания мы переходим к трём базовым этапам моделирования базы данных:

• Концептуальная фаза
• Логическая фаза
• Физическая фаза

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

Концептуальная фаза моделирования

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

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

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

Затем проводится анализ и определение сущностей, что включает в себя идентификацию ключевых объектов или концепций, которые будут представлены в базе данных, и определение их атрибутов и отношений.

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

Эти проекты базы данных часто создаются с помощью диаграмм, текстовых описаний или других методов, которые фиксируют и эффективно передают дизайн и концепцию базы данных. Одним из самых распространённых инструментов для визуального представления концепций базы данных является диаграмма сущность-связь (ERD). Визуальные модели, созданные с использованием ERD, служат диаграммным представлением, которое эффективно описывает сущности для моделирования, их взаимосвязи и кардинальность этих взаимосвязей. Используя модель ERD, мы можем визуально описать структуру базы данных, включая сущности как основные компоненты, связи или ассоциации между сущностями, а также количество или степень этих взаимосвязей.

Давайте сделаем очень простой концептуальный дизайн базы данных. Представьте, что O’Reilly хочет отслеживать книги и авторов, которые были ранее опубликованы, а также даты выхода новых книг, которые ещё не изданы. Мы проводим серию интервью с менеджерами издательства и начинаем понимать, какие именно данные необходимо хранить в базе данных. Основная цель — определить задействованные сущности, их связи и атрибуты каждой сущности. Имейте в виду, что это упражнение является иллюстративным и намеренно упрощено.

Мы выделяем три разные сущности в этой подсистеме управления книгами:

Книга (Book)

Эта сущность представляет книгу, опубликованную O’Reilly. Атрибуты могут включать:

• book_id
• title
• publication_date
• ISBN
• price
• конкретную категорию.

Собеседники отметили, что в этой модели каждая книга может относиться только к одной категории.

Автор (Author)

Эта сущность представляет автора, который написал книги для O’Reilly.

Атрибуты могут включать:

• author_id
• author_name
• email
• bio.

Категория (Category)

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

• category_id (уникальный идентификатор)
• category_name.

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

Например:

• В отношении «один-к-одному» (one-to-one) можно рассматривать связь между сущностями «Книга» и «Автор», где каждая книга связана только с одним автором, и наоборот.
• В отношении «один-ко-многим» (one-to-many) можно рассматривать связь между сущностью «Категория» и «Книга», где каждая книга может относиться только к одной категории, но каждая категория может содержать несколько книг.
• В отношении «многие-к-одному» (many-to-one) можно рассматривать связь между сущностью «Издатель» и «Книга», где один издатель издаёт множество книг.
• В отношении «многие-ко-многим» (many-to-many) можно рассматривать связь между сущностью «Книга» и «Читатель», где множество читателей могут владеть множеством книг.

Продолжая наше упражнение, мы также определили две чёткие связи.

Связь «Книга-Категория»

Устанавливает связь между книгами и категориями. Одна книга может относиться к одной категории, а одна категория может включать несколько книг. Эта связь представлена как отношение «один-ко-многим».

Связь «Книга-Автор»

Устанавливает связь между книгами и авторами. Одна книга может иметь нескольких авторов, а один автор может писать несколько книг. Эта связь представлена как отношение «многие-ко-многим». Именно в рамках этой связи происходит публикация конкретной книги.

При определении связей часто используют названия, которые отражают реальное взаимодействие между сущностями. Например, вместо названия «Книга-Категория» можно использовать «Классифицирует» (Classifies), так как категория классифицирует книгу, а вместо «Книга-Автор» можно использовать «Публикует» (Publishes), так как автор публикует книги.

Теперь, когда у нас есть представление о сущностях, атрибутах и связях, у нас есть всё необходимое для проектирования базы данных с использованием диаграммы «сущность-связь» (ERD). Таким образом, мы можем визуально представить сущности, связи и их кардинальность, как показано на Рисунке 2-1.

Рисунок 2-1. Пример ERD для базы данных книг

Как мы можем наблюдать, сущности представлены в виде белых прямоугольных блоков и обозначают реальные объекты или концепции, такие как «Книга» или «Автор».

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

Атрибуты представлены в виде затенённых блоков и описывают свойства или характеристики сущности. Примером могут быть «Имя» или «Дата публикации». Кроме того, атрибуты можно классифицировать как ключевые атрибуты (подчёркнутые затенённые блоки), которые уникально идентифицируют сущность, или как неключевые атрибуты (неподчёркнутые затенённые блоки), которые предоставляют дополнительную информацию о сущности. Существуют и другие типы атрибутов при проектировании таких диаграмм, но мы ограничимся основами.

Другие компоненты в ERD включают кардинальность и ограничения участия. Кардинальность определяет количество экземпляров в связи, обычно обозначается символами, такими как 1, M или N, чтобы указать, является ли связь «один-к-одному» или «один-ко-многим». (N указывает на неопределённое количество связей.)

Логическая фаза моделирования

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

Эта фаза может быть разделена на два шага.

Сначала реструктуризация схемы «сущность-связь» фокусируется на оптимизации схемы на основе определённых критериев. Этот шаг не привязан к какой-либо конкретной логической модели.

На втором этапе оптимизированная ERD переводится в конкретную логическую модель.

Предположим, мы решили сопоставить ERD с реляционной моделью базы данных (что будет нашим случаем), в отличие от документационной или графовой базы данных. В этом случае каждая сущность из концептуального упражнения ERD представлена в виде таблицы. Атрибуты каждой сущности становятся столбцами соответствующей таблицы. Ограничение первичного ключа указывается для столбцов, являющихся первичными ключами каждой таблицы. Кроме того, связи «многие-ко-многим» представлены отдельными промежуточными таблицами, которые содержат внешние ключи, ссылающиеся на соответствующие сущности.

Переводя концептуальное упражнение ERD в логическую схему с использованием реляционной модели, мы создаём структурированное представление сущностей, их атрибутов и их связей. Эта логическая схема может стать основой для реализации базы данных в конкретной системе управления базами данных (DBMS), оставаясь независимой от какой-либо конкретной системы.

Чтобы выполнить этот перевод эффективно, применяются все шаги нормализации, но мы хотим поделиться эффективным алгоритмом:

1. Сущность E преобразуется в таблицу T.
2. Имя E становится именем T.
3. Первичный ключ E становится первичным ключом T.
4. Простые атрибуты E становятся простыми атрибутами T.

Что касается связей, можно выделить несколько шагов:

Связи N:1

В таблице T1 определяется внешний ключ, который ссылается на первичный ключ таблицы T2. Это устанавливает связь между двумя таблицами, указывая на отношение N:1. Атрибуты (Attrs), связанные с этой связью, отображаются и включаются в таблицу T1.

Связи N:N

Создаётся специальная таблица перекрёстных ссылок для представления связи REL. Первичный ключ REL определяется как комбинация первичных ключей обеих таблиц T1 и T2, которые выступают в роли внешних ключей в таблице перекрёстных ссылок. Атрибуты (Attrs), связанные с этой связью, отображаются и включаются в таблицу перекрёстных ссылок.

Теперь давайте применим эти правила к нашему предыдущему концептуальному модели; см. Рисунок 2-2.

Рисунок 2-2. Пример логической ERD для базы данных книг

В нашем примере мы имеем несколько сущностей, которые, как предполагает наш алгоритм, напрямую сопоставляются с таблицами. Это относится к «Авторам», «Книгам» и «Категории».
Мы определили отношение 1:N между «Книгами» и «Категорией», где одна книга принадлежит одной категории, но одна категория может содержать несколько книг. Для отображения этого отношения мы создаём внешний ключ в таблице «Книги», чтобы он ссылался на соответствующую категорию.

У нас также есть отношение N:N. В этом случае мы должны создать новую таблицу (таблицу перекрёстных ссылок), которая хранит это отношение. В нашем случае мы создаём таблицу «Publishes» (Публикации), для которой первичный ключ становится составным, объединяющим связанные сущности (ID книги и ID автора). Одновременно атрибуты связи становятся атрибутами этой таблицы перекрёстных ссылок.

Физическая фаза моделирования

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

Этот этап определяет структуры хранения, стратегии индексирования и типы данных для обеспечения эффективного хранения и извлечения данных. В то время как логическая модель сосредоточена на концептуальном представлении, физическая модель учитывает детали реализации, необходимые для оптимального управления данными.

В нашем случае мы продолжаем с предыдущей логической модели и предполагаем, что будем работать с MySQL. Пример 2-1 демонстрирует физическую модель базы данных для книг.

Пример 2-1. База данных для книг в физической модели

CREATE TABLE category (
	category_id INT PRIMARY KEY,
	category_name VARCHAR(255)
);

CREATE TABLE books (
	book_id INT PRIMARY KEY,
	ISBN VARCHAR(13),
	title VARCHAR(50),
	summary VARCHAR(255)
	FOREIGN KEY (category_id) REFERENCES category(category_id)
);

CREATE TABLE authors (
author_id INT PRIMARY KEY,
author_name VARCHAR(255),
date_birth DATETIME
);

CREATE TABLE publishes (
	book_id INT,
	author_id INT,
	publish_date DATE,
	planned_publish_date DATE
	FOREIGN KEY (book_id) REFERENCES books(book_id),
	FOREIGN KEY (author_id) REFERENCES author(author_id)
);

В Примере 2-1 мы создали четыре таблицы:

1. category (категории),
2. books (книги),
3. authors (авторы) и
4. publishes (публикации).

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

Например, в таблице category мы можем указать тип данных для столбца category_id как INT, что обеспечивает его пригодность для хранения целочисленных значений. Этот столбец также определяется как первичный ключ, так как он идентифицирует уникальные записи в таблице. Аналогично, столбец category_name может быть определён как VARCHAR(255) для размещения строк с переменной длиной, представляющих названия категорий.

В таблице books можно назначить соответствующие типы данных и длины для таких столбцов, как book_id (INT), ISBN (VARCHAR(13)), title (VARCHAR(50)) и summary (VARCHAR(255)). Кроме того, столбец category_id может быть настроен как внешний ключ, ссылающийся на столбец category_id в таблице category. Обратите внимание, что каждый ISBN-код состоит из строк длиной 13 символов, поэтому для хранения большего количества символов нет необходимости.

Аналогично, в таблице authors можно определить типы данных для столбцов author_id (INT), author_name (VARCHAR(255)) и date_birth (DATETIME), все они соответствуют ожидаемым типам значений.

В таблице publishes мы отмечаем, что установили ограничения внешнего ключа для создания связей между столбцом book_id в таблице books и столбцом author_id в таблице authors. При этом внешний ключ состоит из первичных ключей двух таблиц, которые он связывает.

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

Процесс нормализации данных

Техника нормализации данных состоит из нескольких шагов, каждый из которых направлен на организацию данных в логические и эффективные структуры. Пример 2-2 иллюстрирует таблицу books, содержащую несколько соответствующих атрибутов.

Пример 2-2. Таблица books для нормализации

CREATE TABLE books (
    book_id INT PRIMARY KEY,
    title VARCHAR(100),
    author VARCHAR(100),
    publication_year INT,
    genre VARCHAR(50)
);

Первым шагом нормализации, известным как первая нормальная форма (1NF), является устранение повторяющихся групп путём разбиения данных на более мелкие атомарные единицы. Мы создаём таблицу authors, включающую идентификатор автора и его имя. Таблица books теперь ссылается на идентификатор автора вместо того, чтобы многократно хранить полное имя, как показано в Примере 2-3.

Пример 2-3. Таблица books в 1NF

-- Table Authors
CREATE TABLE authors (
    author_id INT PRIMARY KEY,
    author_name VARCHAR(100)
);

-- Table Books
CREATE TABLE books (
    book_id INT PRIMARY KEY,
    title VARCHAR(100),
    publication_year INT,
    genre VARCHAR(50),
    author_id INT,
    FOREIGN KEY (author_id) REFERENCES authors(author_id)
);

Переходя ко второй нормальной форме (2NF), мы изучаем зависимости внутри данных. Мы замечаем, что год публикации функционально зависит от идентификатора книги, а жанр — от идентификатора автора.

Чтобы соответствовать 2NF, мы разделяем таблицу books на три таблицы:

• books, содержащую идентификатор книги и название.
• authors, содержащую идентификатор автора и его имя.
• bookDetails, хранящую идентификатор книги, год публикации и жанр.

Это гарантирует, что каждый столбец зависит исключительно от первичного ключа, как показано в Примере 2-4.

Пример 2-4. Таблица books во 2NF

-- Table Authors
CREATE TABLE authors (
    author_id INT PRIMARY KEY,
    author_name VARCHAR(100)
);

-- Table Books
CREATE TABLE books (
    book_id INT PRIMARY KEY,
    title VARCHAR(100)
);

-- Table book details
CREATE TABLE bookDetails (
    book_id INT PRIMARY KEY,
    author_id INT,
    genre VARCHAR(50),
    publication_year INT,
    FOREIGN KEY (author_id) REFERENCES authors(author_id)
);

Третья нормальная форма (3NF) сосредотачивается на устранении транзитивных зависимостей. Мы осознаём, что жанр можно вывести из идентификатора книги через таблицу bookDetails. Чтобы решить эту проблему, мы создаём новую таблицу genres с идентификатором жанра и его названием. Таблица bookDetails теперь ссылается на идентификатор жанра вместо того, чтобы напрямую хранить название жанра (Пример 2-5).

Пример 2-5. Таблица books в 3NF

CREATE TABLE authors (
    author_id INT PRIMARY KEY,
    author_name VARCHAR(100)
);

CREATE TABLE books (
    book_id INT PRIMARY KEY,
    title VARCHAR(100)
);

CREATE TABLE genres (
    genre_id INT PRIMARY KEY,
    genre_name VARCHAR(50)
);

CREATE TABLE bookDetails (
    book_id INT PRIMARY KEY,
    author_id INT,
    genre_id INT,
    publication_year INT,
    FOREIGN KEY (author_id) REFERENCES authors(author_id),
    FOREIGN KEY (genre_id) REFERENCES genres(genre_id)
);

Эти результирующие нормализованные структуры (3NF) часто используются в операционных системах, также известных как системы обработки транзакций в режиме онлайн (OLTP), которые разработаны для эффективной обработки и хранения транзакций, а также для извлечения данных о транзакциях, таких как заказы клиентов, банковские транзакции или расчёты заработной платы.

Важно отметить, что при необходимости можно применять дополнительные шаги нормализации, такие как четвёртая нормальная форма (4NF) и пятая нормальная форма (5NF), чтобы устранить сложные зависимости данных и обеспечить ещё более высокий уровень целостности данных.

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

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

Ещё одной причиной актуальности нормализации данных является повышение производительности. Такие нормализованные базы данных разрабатываются для эффективной обработки быстрых операций чтения и записи за счёт минимизации избыточности данных и установления чётко определённых взаимосвязей между таблицами, чтобы база данных могла справляться с большим количеством транзакций с молниеносной скоростью. Это особенно важно для транзакционных систем, где своевременное выполнение операций критически важно.

И, наконец, нормализованная база данных фокусируется на хранении только актуальных данных, чтобы база данных представляла наиболее актуальную информацию. В таблице, которая хранит информацию о клиентах, каждая запись всегда отражает текущие данные о клиенте, такие как имя, номер телефона и другая релевантная информация, что гарантирует точное представление текущего состояния дел.

Однако парадигма несколько отличается, когда речь идёт о проекте или системе аналитики. Часто пользователи хотят иметь возможность получать необходимые данные без необходимости выполнения множества соединений, что является естественным следствием процесса нормализации. В то время как система OLTP оптимизирована для операций записи, чтобы избежать увеличения задержки в таких живых системах, как веб-приложения, пользователи аналитических систем хотят оптимизации операций чтения, чтобы как можно быстрее получать аналитические данные.

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

Эти различия действительно критически важны для понимания, так как они лежат в основе различных требований к организации, хранению и использованию данных. Однако важно уточнить, что то, что мы только что изучили, относится главным образом к области нормализации для оптимизации производительности и соблюдения лучших практик в проектировании баз данных OLTP. Хотя эта основа ценна, она представляет собой лишь одну грань более широкой области аналитической инженерии.

Чтобы предоставить более чёткий план, давайте определим, что наше путешествие начинается с изучения базового типа моделирования данных, который составляет основу систем OLTP. После этого мы перейдём к обсуждению подходов к моделированию данных, оптимизированных для среды OLAP. Разграничивая эти аспекты, мы стремимся обеспечить всестороннее понимание обеих сторон моделирования данных, что подготовит нас к более глубокому изучению методов аналитической инженерии и их применения в последующих разделах.

Моделирование данных в разрезе измерений (Dimensional Data Modeling)

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

Одним из популярных подходов к моделированию данных является моделирование в разрезе измерений, которое ориентировано на создание моделей данных, поддерживающих аналитические и отчётные потребности. Этот подход особенно хорошо подходит для хранилищ данных и приложений бизнес-аналитики (BI). Он акцентирует внимание на создании моделей, состоящих из таблиц фактов, представляющих измеримые данные, и таблиц измерений, предоставляющих описательный контекст. Используя техники моделирования данных в разрезе измерений, такие как звёздная схема и схема снежинки, данные можно организовать так, чтобы упростить сложные запросы и обеспечить эффективный анализ данных.

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

Для понимания моделирования данных в разрезе измерений стоит отдать должное двум личностям, считающимся отцами хранилищ данных и этого подхода: Биллу Инмону и Ральфу Кимболлу. Они признаны пионерами в области корпоративного сбора информации, управления и аналитики для поддержки принятия решений.

Инмон против Кимболла: подходы к хранилищам данных

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

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

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

Их противоположные точки зрения приводят к различным техникам проектирования и стратегиям внедрения хранилищ данных.

Помимо различных подходов, Инмон и Кимболл предлагают отличающиеся методы структурирования данных в контексте хранилищ данных. Инмон выступает за использование реляционной модели (ERD), в частности, третьей нормальной формы (3NF), для корпоративного хранилища данных. В то время как подход Кимболла использует многомерную модель в измерительном хранилище данных с применением звёздных и снежиноковых схем.

Инмон утверждает, что структурирование данных в реляционной модели обеспечивает согласованность на уровне предприятия. Эта согласованность упрощает создание витрин данных на основе измерительной модели. С другой стороны, Кимболл считает, что организация данных в dimensional модели облегчает работу с информационной шиной, позволяя пользователям лучше понимать, анализировать, агрегировать данные и исследовать несоответствия. Более того, подход Кимболла позволяет аналитическим системам напрямую обращаться к данным. В отличие от этого, подход Инмона ограничивает аналитические системы в доступе к данным только через корпоративное хранилище данных, требуя взаимодействия с витринами данных для их извлечения.

Витрина данных — это конкретная часть хранилища данных, предназначенная для удовлетворения уникальных потребностей определённого отдела или бизнес-единицы.

Звёздная схема, снежинка и Data Vault

В следующих разделах мы углубимся в три техники моделирования: звёздную схему, снежинку и новую модель Data Vault. Data Vault, представленная Дэном Линстедтом в 2000 году, набирает популярность в последние годы. Эта модель следует более нормализованной структуре, которая не полностью совпадает с подходом Инмона, но является похожей.

Моделирование с использованием звёздной схемы

Звёздная схема является широко используемым подходом к моделированию в реляционных хранилищах данных, особенно для аналитики и составления отчётов. Этот подход включает классификацию таблиц как таблиц измерений (dimension tables) или таблиц фактов (fact tables) для эффективной организации и представления бизнес-единиц и связанных наблюдений или событий.

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

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

Гранулярность таблицы фактов определяется значениями в её ключевых столбцах измерений. Если, например, столбец Date в таблице фактов для целей продаж содержит значения, представляющие первый день каждого месяца, то гранулярность таблицы находится на уровне Месяц/Продукт. Это означает, что таблица фактов фиксирует данные о целях продаж на ежемесячном уровне, специфичном для каждого продукта.

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

Возвращаясь к нашей таблице книг, мы следуем шагам моделирования для разработки простой модели звёздной схемы. Первый шаг — это идентификация таблиц измерений. Для начала вспомним нашу базовую таблицу в Примере 2-6.

Пример 2-6. Базовая таблица для звёздной схемы

-- This is our base table
CREATE TABLE books (
    book_id INT PRIMARY KEY,
    title VARCHAR(100),
    author VARCHAR(100),
    publication_year INT,
    genre VARCHAR(50)
);

Мы должны определить все индивидуальные измерения (атрибуты, связанные с конкретной бизнес-сущностью) в таблице книг и создать отдельные таблицы измерений для каждого из них. В нашем примере, как и на этапе нормализации, мы определяем три сущности: книги, авторы и жанры. Посмотрим на физическую модель в Примере 2-7.

Пример 2-7. Таблицы измерений для звёздной схемы

-- Create the dimension tables
CREATE TABLE dimBooks (
    book_id INT PRIMARY KEY,
    title VARCHAR(100)
);

CREATE TABLE dimAuthors (
    author_id INT PRIMARY KEY,
    author VARCHAR(100)
);

CREATE TABLE dimGenres (
    genre_id INT PRIMARY KEY,
    genre VARCHAR(50)
);

Когда речь идёт о наименовании таблиц измерений, рекомендуется использовать описательные и интуитивно понятные названия, которые отражают представляемые сущности. Например, если у нас есть таблица измерений, представляющая книги, её можно назвать dimBook или просто books. Аналогично, для таблиц измерений, представляющих авторов, жанры или другие сущности, можно использовать такие названия, как dimAuthor или dimGenre.

Для таблиц фактов рекомендуется использовать названия, указывающие на измерения или события, которые фиксируются. Например, если у нас есть таблица фактов, записывающая данные о продажах книг, её можно назвать factBookSales или salesFact. Эти названия показывают, что таблица содержит данные, связанные с продажами книг.

Мы можем создать таблицу фактов под названием factBookPublish, как показано в Примере 2-8, для фиксации данных о публикации.

Пример 2-8. Таблица фактов для звёздной схемы

-- Create the fact table
CREATE TABLE factBookPublish (
    book_id INT,
    author_id INT,
    genre_id INT,
    publication_year INT,
    FOREIGN KEY (book_id) REFERENCES dimBooks (book_id),
    FOREIGN KEY (author_id) REFERENCES dimAuthors (author_id),
    FOREIGN KEY (genre_id) REFERENCES dimGenres (genre_id)
);

Этот код создаёт новую таблицу фактов factBookPublish с колонками, представляющими измерения или события, связанные с измерениями. В данном случае это только год публикации. Ограничения внешнего ключа устанавливают связи между таблицей фактов и таблицами измерений.

С моделью звёздной схемы, представляющей набор данных о книгах, у нас теперь есть прочная основа для проведения различных аналитических операций и получения ценных инсайтов. Размерная структура звёздной схемы позволяет эффективно и интуитивно выполнять запросы, исследуя данные с разных точек зрения. После завершения процесса моделирования мы должны получить модель, аналогичную Рисунку 2-3, которая напоминает звезду, отсюда и название — звёздная схема.

Рисунок 2-3. Модель звёздной схемы

Использование этой модели

Теперь мы можем легко анализировать публикации книг, применяя фильтры, такие как жанр, автор или год публикации. Например, можно быстро получить общее количество публикаций для определённого жанра. Соединяя таблицы измерений с таблицей фактов, как показано в Примере 2-9, мы можем без труда получать информацию о взаимосвязях между книгами, авторами, жанрами и продажами.

Пример 2-9. Извлечение данных из звёздной схемы

-- Example for retrieving the total publications for a specific genre.
SELECT 
    COALESCE(dg.genre, 'Not Available'), -- Or '-1'
    COUNT(*) AS total_publications
FROM factBookPublish bp
LEFT JOIN dimGenres dg ON dg.genre_id = bp.genre_id
GROUP BY g.genre;

Как видно, при объединении таблицы фактов с таблицей измерений был использован LEFT JOIN. Это достаточно распространённый подход, так как он гарантирует, что все записи из таблицы фактов будут включены в результат, независимо от того, существует ли соответствующая запись в таблице измерений.

Этот подход важен, поскольку учитывает возможность отсутствия соответствующих записей в каждой таблице измерений для каждой записи таблицы фактов. Используя LEFT JOIN, вы сохраняете все данные из таблицы фактов, одновременно дополняя их соответствующими атрибутами из таблицы измерений. Это позволяет выполнять анализ и агрегации на основе различных измерений и исследовать данные с разных точек зрения. Однако необходимо учитывать отсутствие соответствий, для чего часто используется оператор COALESCE, позволяющий установить значение по умолчанию, например, -1 или Not available.

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

Преимущества звёздной схемы

В целом, простота и денормализованная структура звёздной схемы делают её удобной для выполнения агрегаций и обобщений. С её помощью можно создавать различные отчёты, такие как анализ трендов продаж за период, самые популярные жанры или доходы по авторам. Также звёздная схема поддерживает операции детализации (drill-down) и свёртки (roll-up), что позволяет переходить к более детализированной информации или, наоборот, к более обобщённым данным для комплексного анализа.

Эта техника моделирования также отлично интегрируется с инструментами визуализации данных и платформами BI. Подключив модель к инструментам, таким как Tableau, Power BI или Looker, можно создавать наглядные дашборды и интерактивные отчёты. Такие ресурсы позволяют заинтересованным сторонам быстро извлекать инсайты и принимать решения на основе данных.

Уточнение модели

Однако стоит отметить, что предыдущий пример не полностью демонстрирует денормализацию, характерную для звёздных схем. Например, если ваш набор данных строго придерживается правила «один жанр на книгу», можно упростить модель, объединив информацию о жанрах непосредственно в единую таблицу dimBooks, что повысит уровень денормализации и упростит доступ к данным.

Моделирование с использованием снежинки

В схеме «Снежинка» (Snowflake Data Model) — модель данных более нормализована по сравнению со звёздной схемой. Она включает дополнительные уровни нормализации, разделяя таблицы измерений на несколько связанных таблиц. Это обеспечивает лучшую целостность данных и уменьшает избыточность.

Например, рассмотрим схему Снежинка для базы данных электронной коммерции. У нас есть таблица измерений customers, которая содержит информацию о клиентах, такую как идентификатор, имя и адрес. В схеме Снежинка эту таблицу можно разделить на несколько связанных таблиц.

Таблица customers может быть разделена на таблицу customers и отдельную таблицу addresses. Таблица customers будет содержать атрибуты, специфичные для клиента, такие как идентификатор и имя клиента. В то же время таблица addresses будет содержать информацию, связанную с адресами, например, идентификатор, улицу, город и почтовый индекс. Если несколько клиентов имеют один и тот же адрес, информацию об этом адресе нужно хранить только один раз в таблице addresses и связывать её с соответствующими клиентами.

Для извлечения данных из схемы Snowflake обычно требуется выполнить несколько соединений между связанными таблицами. Например, если нужно запросить имя клиента и адрес, необходимо объединить таблицы customers и addresses по идентификатору. Хотя Snowflake схема обеспечивает лучшую целостность данных, она также требует более сложных запросов из-за дополнительных связей.

Сравнение Star и Snowflake схем

И звёздная, и снежинка схемы являются распространёнными подходами к проектированию хранилищ данных. В звёздной схеме таблицы измерений денормализованы, то есть содержат избыточные данные. Это даёт преимущества в виде более простой реализации, эффективных запросов (из-за меньшего количества операций JOIN), но может потребовать больше места для хранения и усложнить обновление и устранение неполадок.

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

В зависимости от ваших потребностей можно использовать гибридные модели, в которых звёздная схема сочетается с нормализованными элементами для оптимизации. Например, для представления местоположения клиентов по всему миру в звёздной схеме можно создать единую таблицу измерений dimLocation, включающую все иерархии местоположений в денормализованной форме (Пример 2-10).

Пример 2-10. Измерение местоположения в звёздной схеме

CREATE TABLE dimLocation (
    locationID INT PRIMARY KEY,
    country VARCHAR(50),
    city VARCHAR(50),
    State VARCHAR(50)
);

А в snowflake схеме иерархия местоположений будет разделена на несколько таблиц (Пример 2-11).

Пример 2-11. Измерение местоположения в схеме Снежинка

CREATE TABLE dimLocation (
    locationID INT PRIMARY KEY,
    locationName VARCHAR(50),
    cityID INT
);

CREATE TABLE dimCity (
    cityID INT PRIMARY KEY,
    city VARCHAR(50),
    stateID INT
);

CREATE TABLE dimState (
    stateID INT PRIMARY KEY,
    state VARCHAR(50),
    countryID INT
);

CREATE TABLE dimCountry (
    countryID INT PRIMARY KEY,
    country VARCHAR(50)
);

В примере схемы Снежинка

Измерение местоположения разделено на четыре таблицы:

• dimLocation,
• dimCity,
• dimState и
• dimCountry.

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

Одним из ключевых моментов является то, что, несмотря на наличие четырёх таблиц для представления измерения местоположения, только таблица с наивысшим уровнем иерархии соединяется с таблицей фактов (или таблицами фактов) через свой первичный ключ. Все остальные уровни иерархии следуют цепочке от самого высокого уровня до наименьшей детализации.

На Рисунке 2-4 показана эта схема.

Моделирование с использованием Data Vault

Data Vault 2.0 — это подход к моделированию, который не относится к измерительному моделированию, но заслуживает упоминания. Его методология сочетает элементы трёхзвенной нормальной формы (3NF) и dimensional modeling для создания логической корпоративной базы данных (EDW). Data Vault разработан для работы с различными типами данных, включая структурированные, полуструктурированные и неструктурированные, предоставляя гибкие и масштабируемые шаблоны.

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

В деталях эта техника моделирования предоставляет масштабируемое и гибкое решение для хранилищ данных и аналитики. Data Vault разработан для обработки больших объёмов данных, частых изменений в бизнес-требованиях и эволюционирующих источников данных.

Модель Data Vault состоит из трёх основных компонентов:

• хабы (hubs),
• связи (links) и
• спутники (satellites).

Хабы (Hubs)

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

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

Связи (Links)

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

Спутники (Satellites)

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

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

Архитектура Data Vault способствует прослеживаемости, масштабируемости и аудируемости, предоставляя надёжную основу для интеграции данных, аналитики и управления данными. Используя хабы, связи и спутники, организации могут создавать Data Vault, который поддерживает их аналитические потребности, адаптируется к изменяющимся бизнес-требованиям и сохраняет надёжную историческую запись изменений данных.

Пример моделирования таблицы книг

Рассмотрим таблицу books и следуем трём этапам моделирования, чтобы разработать простую модель Data Vault.

Первый шаг — это идентификация бизнес-ключей и создание соответствующих хабов и спутников.

В данном случае у нас есть только одна бизнес-сущность, поэтому связи использоваться не будут. Пример 2-12 демонстрирует моделирование таблицы книг с использованием Data Vault 2.0.

Пример 2-12. Моделирование таблицы книг с использованием Data Vault 2.0

-- This is our base table
CREATE TABLE books (
    book_id INT PRIMARY KEY,
    title VARCHAR(100),
    author VARCHAR(100),
    publication_year INT,
    genre VARCHAR(50)
);

В моделировании Data Vault мы начинаем с идентификации бизнес-ключей, которые являются уникальными идентификаторами для каждой сущности. В данном случае первичный ключ таблицы books, book_id, служит бизнес-ключом.

Теперь мы можем приступить к моделированию и созданию нашей первой таблицы: таблицы хаба, которая хранит уникальные бизнес-ключи и соответствующие им хэш-ключи для обеспечения стабильности. Пример 2-13 показывает создание таблицы хаба.

Пример 2-13. Создание хаба

CREATE TABLE hubBooks (
    bookKey INT PRIMARY KEY,
    bookHashKey VARCHAR(50),
    Title VARCHAR(100)
);

В таблице хаба мы храним уникальный идентификатор для каждой книги в виде первичного ключа (bookKey) и хэш-ключа (bookHashKey) для обеспечения стабильности. Колонка Title содержит описательную информацию о книге.

Далее создаётся спутниковая таблица, представленная в Примере 2-14, которая фиксирует дополнительные детали о книгах и сохраняет историю изменений.

Пример 2-14. Создание спутника

CREATE TABLE satBooks (
    bookKey INT,
    loadDate DATETIME,
    author VARCHAR(100),
    publicationYear INT,
    genre VARCHAR(50),
    PRIMARY KEY (bookKey, loaddate),
    FOREIGN KEY (bookKey) REFERENCES hubBooks(bookKey)
);

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

В модели Data Vault могут быть и другие таблицы, такие как таблицы связей для представления отношений между сущностями или дополнительные спутники для фиксации исторических изменений в отдельных атрибутах.

Моделирование данных в монолитной архитектуре

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

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

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

• отсутствие контроля версий для скриптов;
• сложность управления зависимостями между представлениями (views);
• практика создания новых представлений или таблиц от исходных данных до финальных отчетов, что затрудняет повторное использование;
• несоответственное применение принципа идемпотентности для крупных таблиц, что иногда приводило к избыточности данных;
• сложные и трудоёмкие процессы обратной загрузки (backfills).

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

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

Риски, связанные с монолитными моделями данных, — это именно то, чего мы стараемся избежать при проектировании модели данных. Последнее, что нужно, — это тесно связанные модели данных, которые делают отладку и внесение изменений сложной задачей, так как каждое изменение потенциально может нарушить всю цепочку обработки данных. Отсутствие модульности затрудняет достижение гибкости, масштабируемости и поддерживаемости, которые необходимы в современном мире, ориентированном на данные.

Сложности монолитных моделей

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

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

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

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

Преимущества модульного подхода

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

Отход от монолитных структур позволяет организациям максимально эффективно использовать свои данные, стимулировать инновации и получать конкурентные преимущества в современном мире, основанном на данных.

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

Эта структура устраняет риск непреднамеренных изменений, влияющих на всю систему, и делает процесс внесения изменений и обновлений безопаснее. Тема модульности с использованием dbt будет более подробно рассмотрена в следующих подразделах, а в Главе 4 будет дано её детальное исследование.

Построение модульных моделей данных

Приведённый выше пример подчёркивает, насколько важны dbt и модульный подход к моделированию данных для улучшения процесса разработки. Однако почему это до сих пор не стало повсеместной практикой среди инженеров и учёных данных?

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

Преимущества модульного подхода

Улучшение управляемости

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

Поддержка командной работы

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

Повышение качества кода

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

Повторное использование кода

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

Организация и читаемость

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

Результат: надёжность и масштабируемость

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

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

Модульность в моделировании данных

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

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

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

В итоге основные принципы модульного моделирования данных можно сформулировать следующим образом:

Декомпозиция

Разделение модели данных на меньшие, более управляемые компоненты.

Абстракция

Сокрытие деталей реализации модели данных за интерфейсами.

Повторное использование

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

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

Другой вариант — использование dbt, который автоматизирует процесс создания модульной модели данных, предоставляя множество функций, поддерживающих принципы модульности.

• Декомпозиция: dbt позволяет разбивать модель данных на меньшие, повторно используемые компоненты, создавая макросы и модульные файлы моделей.
• Абстракция: dbt предоставляет простой и единообразный интерфейс для работы с источниками данных, скрывая детали реализации модели.
• Повторное использование: dbt позволяет определять и использовать общий код в различных моделях.
• Удобство сопровождения: dbt предоставляет возможности для тестирования и документирования моделей данных.
• Оптимизация производительности: dbt поддерживает тестирование различных стратегий материализации, позволяя настраивать производительность отдельных компонентов модели данных.

Возможные недостатки модульности

Несмотря на очевидные преимущества, модульность может иметь свои риски и недостатки:

• Оптимизация интегрированных систем: Интегрированные системы часто можно оптимизировать лучше, чем модульные, благодаря минимизации перемещения данных, снижению использования памяти и возможностям оптимизатора базы данных улучшать SQL на уровне базы данных. Например, создание таблиц из представлений может приводить к неоптимальным моделям.
• Увеличение количества объектов: Модульность создаёт больше файлов, что означает больше объектов для управления, сопровождения и, возможно, вывода из эксплуатации. Без зрелой стратегии управления данными это может привести к хаосу, связанному с множеством модульных, но неуправляемых таблиц, которые становится сложно поддерживать при возникновении проблем.

Реализация модульных моделей данных с помощью dbt

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

Здесь на помощь приходит мощный инструмент трансформации данных, такой как dbt. Совмещая принципы модульного моделирования с возможностями dbt, можно достичь нового уровня эффективности и масштабируемости в управлении данными.

Принятие модульного подхода даёт возможность каждому участнику — будь то производитель или потребитель данных — использовать результаты работы других, устраняя необходимость каждый раз начинать с исходных данных.

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

Как показано на Рисунке 2-5, использование базовых моделей данных в различных сценариях, вместо того чтобы каждый раз начинать с нуля, упрощает визуализацию DAG (ориентированного ациклического графа) при моделировании данных. Модульная многоуровневая структура делает понятной логику построения уровней моделей данных и их зависимости.

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

Рисунок 2-5. Модульность в dbt

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

Эти принципы можно применять к различным моделям в dbt, включая модели подготовки (staging models), промежуточные модели (intermediate models) и модели для визуализации данных (mart models), чтобы улучшить модульность и поддерживать хорошо структурированный DAG.

Начнём путь к использованию dbt для создания модульных моделей данных с понимания того, как dbt обеспечивает повторное использование моделей через синтаксис Jinja с использованием ссылки на модели: {{ ref() }}.

Ссылки на модели данных

Используя функции dbt, такие как ссылки на модели (model referencing) и синтаксис Jinja, инженеры данных и аналитики могут устанавливать чёткие зависимости между моделями, повышать повторное использование кода и обеспечивать согласованность и точность своих конвейеров обработки данных.

Jinja в данном контексте — это язык шаблонов, который позволяет выполнять динамические и программируемые преобразования в SQL-коде, предоставляя мощный инструмент для настройки и автоматизации преобразований данных.

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

Для того чтобы максимально использовать возможности dbt и обеспечить точное построение моделей, важно применять ссылки на модели с помощью синтаксиса {{ ref() }}. Используя этот способ, dbt может автоматически определять и устанавливать зависимости между моделями на основе вышестоящих таблиц. Это обеспечивает плавное и надёжное выполнение конвейера преобразования данных.

С другой стороны, синтаксис Jinja {{ source() }} следует использовать экономно, обычно ограничиваясь первоначальным выбором сырых данных из базы данных. Важно избегать прямых ссылок на таблицы, созданные не с помощью dbt, так как это может затруднить гибкость и модульность рабочего процесса dbt.

Вместо этого внимание должно быть сосредоточено на установлении связей между моделями с использованием синтаксиса Jinja {{ ref() }}, чтобы изменения в вышестоящих таблицах правильно распространялись вниз по потоку, поддерживая чёткий и последовательный процесс преобразования данных. Придерживаясь этих передовых практик, dbt позволяет эффективно управлять моделями и способствует масштабируемости и удобству сопровождения в аналитических рабочих процессах.

Пример: работа с ссылками на модели

Допустим, у нас есть две модели: orders и customers, где таблица orders содержит информацию о заказах клиентов, а таблица customers — данные о клиентах. Мы хотим выполнить объединение этих двух таблиц, чтобы обогатить данные заказов информацией о клиентах (Пример 2-15).

Пример 2-15. Ссылки на модели

-- In the orders.sql file
SELECT
    o.order_id,
    o.order_date,
    o.order_amount,
    c.customer_name,
    c.customer_email
FROM
    {{ ref('orders') }} AS o
JOIN
    {{ ref('customers') }} AS c
ON
    o.customer_id = c.customer_id


-- In the customers.sql file
-- customers.sql
SELECT
    customer_id,
    customer_name,
    customer_email
FROM
    raw_customers

Этот пример демонстрирует, как ссылаться на модели в SQL-запросе с использованием функции ref().

Сценарий включает два файла моделей: orders.sql и customers.sql.

В файле orders.sql записан оператор SELECT, чтобы извлечь информацию о заказах из модели orders. Выражение {{ ref('orders') }} создаёт ссылку на модель orders, позволяя запросу использовать данные, определённые в этой модели.

Запрос объединяет модель orders с моделью customers по столбцу customer_id, извлекая дополнительную информацию о клиентах, такую как имя и электронная почта.

В файле customers.sql

Оператор SELECT используется для извлечения информации о клиентах из таблицы raw_customers. Эта модель представляет необработанные данные о клиентах до выполнения каких-либо преобразований.

Этот механизм ссылок в dbt позволяет создавать модульные и взаимосвязанные модели, которые основываются друг на друге для получения значимых аналитических выводов и отчётов.

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

Преимущества структурированного подхода

Организация процесса преобразования данных в чёткие слои — от исходных данных до таблиц визуализации (mart tables) — приносит множество преимуществ. Это упрощает конвейер обработки данных, делая его более понятным и управляемым.

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

Слой промежуточных данных (Staging Data Models)

Слой промежуточных данных (или стейджинг) играет ключевую роль в моделировании данных, поскольку служит основой для модульного построения более сложных моделей данных. Каждая staging модель данных соответствует исходной таблице с отношением 1:1 к оригинальному источнику данных.

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

Допустимыми являются такие преобразования, как:

• Преобразование типов данных,
• Переименование столбцов,
• Простые вычисления (например, преобразование единиц измерения),
• Классификация с использованием условных операторов, таких как CASE WHEN.

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

Избежание сложных операций

Соединения (Joins): избегайте их на уровне staging, чтобы предотвратить избыточные или дублирующие вычисления. Соединения лучше выполнять на последующих слоях, где устанавливаются более сложные отношения.

Агрегации: их также следует избегать, так как они могут группировать данные и ограничивать доступ к ценным исходным данным.

Основная цель staging слоя — создать базовые строительные блоки для последующих моделей данных, предоставляя гибкость и масштабируемость для дальнейших преобразований.

Использование принципа DRY

Применение моделей staging данных в dbt позволяет использовать принцип «Don’t Repeat Yourself» (DRY) в коде. Следуя модульной и повторно используемой структуре dbt, мы стараемся переносить все преобразования, которые часто требуются для определённой модели, как можно ближе к источнику.

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

Пример промежуточной модели данных (staging data model)

Предположим, у нас есть исходная таблица под названием raw_books, содержащая необработанные данные о книгах. Мы хотим создать staging модель данных под названием stg_books, чтобы преобразовать и подготовить данные для дальнейшей обработки.

В нашем проекте dbt можно создать новый файл модели dbt под названием stg_books.sql и определить логику для создания модели подготовки, как показано в Примере 2-16.

Пример 2-16. Модель промежуточных данных (Staging model)

/* This should be file stg_books.sql, and it queries the raw table to create
the new model */
SELECT
    book_id,
    title,
    author,
    publication_year,
    genre
FROM
    raw_books

Модель промежуточных данных, например stg_books в данном примере, выбирает нужные столбцы из таблицы raw_books. Она может включать базовые преобразования, такие как переименование столбцов или преобразование типов данных.

Создание staging модели позволяет отделить начальное преобразование данных от последующей обработки. Это обеспечивает качество данных, их согласованность и соответствие стандартам перед дальнейшим использованием. Staging модели служат основой для создания более сложных моделей данных в промежуточных и итоговых слоях конвейера обработки данных. Они упрощают преобразования, сохраняют целостность данных и повышают повторяемость и модульность вашего проекта dbt.

Базовые модели данных (Base Data Models)

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

После создания staging моделей или базовых моделей другие модели в вашем проекте dbt могут ссылаться на них.

Изменение термина с base на staging модели в документации dbt отражает стремление не ограничиваться названием «base», которое подразумевает первый шаг в создании модели данных. Новая терминология обеспечивает большую гибкость в описании роли и цели этих моделей в рамках dbt.

Промежуточные/средние модели данных (Intermediate Data Models)

Промежуточный слой (intermediate layer) играет важную роль в моделировании данных, объединяя атомарные строительные блоки из слоя подготовки для создания более сложных и значимых моделей.

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

Чтобы сохранить разделение и оптимизировать производительность, рекомендуется хранить промежуточные модели в виде эфемерных моделей (ephemeral models). Эфемерные модели не создаются напрямую в базе данных или наборе данных, а их код вставляется в модели, которые ссылаются на них, как общее выражение таблицы (CTE — Common Table Expressions).

Иногда предпочтительнее материализовать их как представления (views). Однако стоит учитывать, что эфемерные модели невозможно выбрать напрямую, что затрудняет отладку. Кроме того, макросы, вызываемые через run-operation, не могут ссылаться на эфемерные модели.

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

Организация промежуточных моделей

Если вы решаете материализовать Intermediate модели как представления, полезно размещать их в пользовательской схеме за пределами основной схемы, указанной в вашем профиле dbt. Это помогает эффективно организовать модели и управлять правами доступа.

Основная цель Intermediate слоя — объединить различные сущности и упростить сложность итоговых моделей. Эти модели улучшают читаемость и гибкость общей структуры модели данных.

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

Эффективное использование промежуточного слоя

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

Предположим, у нас есть две модели подготовки данных, stg_books и stg_authors, представляющие данные о книгах и авторах соответственно. Теперь мы хотим создать промежуточную модель под названием int_book_authors, которая объединяет соответствующую информацию из обеих подготовительных моделей.

В нашем проекте dbt мы можем создать новый файл модели dbt под названием int_book_authors.sql, как показано в Примере 2-17, и определить логику для создания промежуточной модели.

Пример 2-17. Intermediate model

-- This should be file int_book_authors.sql
-- Reference the staging models
WITH
books AS (
    SELECT *
    FROM {{ ref('stg_books') }}
),
authors AS (
    SELECT *
    FROM {{ ref('stg_authors') }}
)
-- Combine the relevant information
SELECT
    b.book_id,
    b.title,
    a.author_id,
    a.author_name
FROM
    books b
JOIN
    authors a ON b.author_id = a.author_id

В Примере 2-17 модель int_book_authors ссылается на модели подготовки данных stg_books и stg_authors, используя синтаксис {{ ref() }} Jinja. Это гарантирует, что dbt сможет правильно определить зависимости модели и построить промежуточную модель на основе вышестоящих таблиц.

Модели витрин данных (Mart Models)

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

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

Простота — ключ к моделям витрин, и следует избегать чрезмерного использования соединений (joins). Если в модели витрин требуется множество соединений, стоит пересмотреть дизайн и подумать о переструктурировании промежуточного слоя. Поддерживая относительную простоту моделей витрин, вы обеспечиваете эффективное выполнение запросов и сохраняете общую производительность конвейера обработки данных.

Рассмотрим пример витрины данных для анализа публикаций книг. У нас есть промежуточная модель int_book_authors, которая содержит необработанные данные о книгах, включая информацию об авторах каждой книги (Пример 2-18).

Пример 2-18. Модель витрины данных

-- This should be file mart_book_authors.sql
{{
    config(
        materialized='table',
        unique_key='author_id',
        sort='author_id'
    )
}}
WITH book_counts AS (
    SELECT
        author_id,
        COUNT(*) AS total_books
    FROM {{ ref('int_book_authors') }}
    GROUP BY author_id
)
SELECT
    author_id,
    total_books
FROM book_counts

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

Далее мы используем CTE под названием book_counts для агрегации данных о книгах. Мы выбираем столбец author_id и подсчитываем количество книг, связанных с каждым автором, из модели подготовки данных stg_books. В заключение, оператор SELECT извлекает агрегированные данные из CTE book_counts, возвращая author_id и соответствующее количество книг для каждого автора. Поскольку это материализованная таблица, модель может обновляться при необходимости, чтобы отразить изменения в исходных данных.

Тестирование моделей данных

Тестирование в dbt — важный аспект обеспечения точности и надёжности моделей данных и источников данных. dbt предоставляет комплексную структуру тестирования, позволяющую определять и выполнять тесты с использованием SQL-запросов. Эти тесты предназначены для выявления строк или записей, не соответствующих заданным критериям утверждений, а не для проверки корректности конкретных условий.

В dbt существует два основных типа тестов: единичные (singular) и общие (generic). Единичные тесты представляют собой специфические, целенаправленные тесты, написанные в виде SQL-запросов и хранящиеся в отдельных файлах SQL. Они позволяют проверять определённые аспекты ваших данных, такие как отсутствие NULL-значений в таблице фактов или валидацию определённых преобразований данных. Используя единичные тесты, можно задействовать мощь Jinja для динамического определения утверждений на основе данных и бизнес-требований.

Рассмотрим единичный тест в dbt, анализируя Пример 2-19.

Пример 2-19. Пример единичного теста в dbt

version: 2

models:
  - name: my_model
  tests:
    - not_null_columns:
      columns:
        - column1
        - column2

В этом примере мы определяем единичный тест под названием not_null_columns для модели dbt my_model. Этот тест проверяет, содержат ли определённые столбцы модели значения NULL. Параметр columns указывает столбцы для проверки на наличие NULL-значений. В данном случае указаны column1 и column2. Если какой-либо из этих столбцов содержит значения NULL, тест завершается с ошибкой.

С другой стороны, общие тесты (generic tests) более универсальны и могут быть применены к нескольким моделям или источникам данных. Они определяются в файлах проекта dbt с использованием специального синтаксиса. Эти тесты позволяют задавать более комплексные критерии проверки данных, такие как проверка консистентности данных между таблицами или обеспечение целостности определённых столбцов. Они обеспечивают гибкий и повторно используемый способ определения утверждений, которые могут быть применены ко всем моделям dbt. Общие тесты пишутся и хранятся в файлах YAML (.yml), что позволяет параметризовать запросы и легко использовать их в различных контекстах.

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

Рассмотрим один из таких общих тестов в Примере 2-20.

Пример 2-20. Пример общего теста в dbt

version: 2

tests:
  - name: non_negative_values
    severity: warn
    description: Check for non-negative values in specific columns
    columns:
      - column_name: amount
        assert_non_negative: {}
      - column_name: quantity
        assert_non_negative: {}

В этом примере общий тест определён под названием non_negative_values. Здесь указаны столбцы для проверки и критерии утверждения для каждого столбца. Тест проверяет, являются ли значения в столбцах amount и quantity неотрицательными. Общие тесты позволяют написать повторно используемую логику тестирования, которая может быть применена ко многим моделям в вашем проекте dbt.

Чтобы повторно использовать общий тест в нескольких моделях, мы можем ссылаться на него в разделе tests каждого отдельного YAML-файла модели, как показано в Примере 2-21.

Пример 2-21. Повторное использование общего теста

version: 2

models:
  - name: my_model
    columns:
      - column_name: amount
        tests: ["my_project.non_negative_values"]
      - column_name: quantity
        tests: ["my_project.non_negative_values"]

В этом примере определена модель my_model, а столбцы amount и quantity указаны с соответствующими тестами. Тесты ссылаются на общий тест non_negative_values из пространства имён my_project (предполагается, что my_project — это имя вашего проекта dbt).

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

Обратите внимание, что файл YAML для общего теста должен находиться в правильной директории в структуре вашего проекта dbt, и может понадобиться изменить ссылку на тест, чтобы она соответствовала пространству имён и структуре папок вашего проекта.

Генерация документации данных

Ещё одним важным компонентом правильного моделирования данных является документация. В частности, обеспечение того, чтобы все в вашей организации, включая бизнес-пользователей, могли легко понимать и получать доступ к метрикам, таким как ARR (ежегодный повторяющийся доход), NPS (индекс потребительской лояльности) или MAU (ежемесячное количество активных пользователей), является ключевым для принятия решений на основе данных.

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

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

Предположим, у нас есть проект dbt с моделью nps_metrics.sql, которая вычисляет индекс потребительской лояльности. Мы можем легко задокументировать эту метрику, используя комментарии внутри SQL-файла, дополненные синтаксисом Markdown, как показано в Примере 2-22.

/* nps_metrics.sql

-- This model calculates the Net Promoter Score (NPS)
for our product based on customer feedback.

Dependencies:
- This model relies on the "customer_feedback"
table in the "feedback" schema, which stores customer feedback data.
- It also depends on the "customer" table in the "users"
schema, containing customer information.

Calculation:
-- The NPS is calculated by categorizing customer
feedback from Promoters, Passives, and Detractors
based on their ratings.
-- Promoters: Customers with ratings of 9 or 10.
-- Passives: Customers with ratings of 7 or 8.
-- Detractors: Customers with ratings of 0 to 6.
-- The NPS is then derived by subtracting the percentage
of Detractors from the percentage of Promoters.
*/

-- SQL Query:
WITH feedback_summary AS (
    SELECT
        CASE
            WHEN feedback_rating >= 9 THEN 'Promoter'
            WHEN feedback_rating >= 7 THEN 'Passive'
            ELSE 'Detractor'
        END AS feedback_category
    FROM
        feedback.customer_feedback
    JOIN
        users.customer
    ON customer_feedback.customer_id = customer.customer_id
)
SELECT
    (COUNT(*) FILTER (WHERE feedback_category = 'Promoter')
    - COUNT(*) FILTER (WHERE feedback_category = 'Detractor')) AS nps
FROM
    feedback_summary;

В этом примере комментарии предоставляют важную информацию о метрике NPS. Они указывают зависимости модели nps_metrics, объясняют процесс расчёта и упоминают соответствующие таблицы, используемые в запросе.

После документирования модели мы можем сгенерировать документацию для нашего проекта dbt, используя интерфейс командной строки dbt (CLI) и выполнив следующую команду (Пример 2-23).

Пример 2-23. Генерация документации

dbt docs generate

Выполнение этой команды создаёт HTML-документацию для всего проекта dbt, включая задокументированную метрику NPS. Полученная документация может быть размещена и сделана доступной для пользователей в вашей организации, что позволит легко находить и понимать метрику NPS.

Отладка и оптимизация моделей данных

Ценное предложение по оптимизации производительности dbt заключается в тщательном анализе и оптимизации самих запросов. Один из подходов — использовать возможности планировщика запросов, например, планировщика PostgreSQL (Postgres). Понимание работы планировщика запросов помогает выявить возможные узкие места и неэффективности в выполнении запросов.

Другим эффективным методом оптимизации является деконструкция сложных запросов, разбивая их на более мелкие компоненты, такие как CTE (общие табличные выражения). В зависимости от сложности и природы операций, эти CTE затем могут быть преобразованы либо в представления (views), либо в таблицы (tables). Для каждой операции можно задать желаемый способ материализации с помощью блока config в dbt.

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

Реализация этих рекомендаций по оптимизации позволяет создать более эффективный и рациональный рабочий процесс в dbt. Оптимизация запросов и выбор подходящих стратегий материализации повышают производительность моделей dbt, улучшая обработку данных и обеспечивая более эффективные преобразования.

Рассмотрим сложный запрос в Примере 2-24.

SELECT 
    column1, 
    column2, 
    SUM(column3) AS total_sum
FROM table1
INNER JOIN table2 ON table1.id = table2.id
WHERE column4 = 'some_value'
GROUP BY column1, column2
HAVING total_sum > 1000

Этот запрос включает объединение таблиц, применение фильтров и выполнение агрегаций. Деконструируем его на несколько CTE перед созданием финальной модели (Пример 2-25).

Пример 2-25. Деконструкция сложного запроса 1

-- Deconstructing a complex query using CTEs for optimization
-- CTE 1: Joining required data
WITH join_query AS (
    SELECT table1.column1, table1.column2, table2.column3
    FROM table1
    INNER JOIN table2 ON table1.id = table2.id
)
-- CTE 2: Filtering rows
, filter_query AS (
    SELECT column1, column2, column3
    FROM join_query
    WHERE column4 = 'some_value'
)
-- CTE 3: Aggregating and filtering results
, aggregate_query AS (
    SELECT column1, column2, SUM(column3) AS total_sum
    FROM filter_query
    GROUP BY column1, column2
    HAVING total_sum > 1000
)
-- Final query to retrieve the optimized results, and this will be our model
SELECT *
FROM aggregate_query;

CTE join_query фокусируется на объединении необходимых таблиц, в то время как filter_query применяет условия фильтрации для сужения выборки строк. aggregate_query выполняет агрегацию и применяет финальное условие фильтрации.

Разбив сложный запрос на отдельные CTE, вы можете упростить и организовать логику для оптимизации выполнения. Такой подход улучшает читаемость, сопровождаемость и потенциально повышает производительность, так как СУБД может оптимизировать план выполнения для каждого CTE. Финальный запрос извлекает оптимизированные результаты, выбирая столбцы из CTE aggregate_query.

Процесс отладки материализованных моделей в dbt

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

Для упрощения отладки и проверки может потребоваться полное обновление всей таблицы, чтобы обработать её как нематериализованную. Это можно сделать с помощью команды dbt run --full-refresh, которая обновляет таблицу и запускает модель как при её первом выполнении.

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

Рассмотрим пример: у нас есть материализованная модель dbt, которая рассчитывает ежемесячную выручку на основе данных транзакций. Чтобы отладить и проверить эту модель, мы подозреваем, что значения, генерируемые материализованной моделью, могут не соответствовать ожидаемым результатам. Для устранения этой проблемы мы решаем полностью обновить таблицу, как если бы она не была инкрементальной. Используя команду dbt run --full-refresh, мы запускаем процесс, обновляющий всю таблицу и выполняющий модель с нуля.

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

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

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

Архитектура медальонов (Medallion Architecture Pattern)

Хранилища данных имеют богатую историю использования в системах поддержки принятия решений и бизнес-аналитике (BI), но ограничены в работе с неструктурированными, полуструктурированными и высокоразнообразными данными. В то же время озёра данных стали хранилищами для хранения данных в различных форматах, но им не хватает таких важных функций, как поддержка транзакций, обеспечение качества данных и консистентность.

Эти недостатки ограничивают их возможности и приводят к потере преимуществ, присущих хранилищам данных. Для удовлетворения современных потребностей компаний требуется гибкая и высокопроизводительная система, которая поддерживает разнообразные приложения для работы с данными, такие как аналитика SQL, мониторинг в реальном времени, анализ данных и машинное обучение. При этом современные достижения в области ИИ делают акцент на обработке широкого диапазона типов данных, включая полуструктурированные и неструктурированные данные, для которых традиционные хранилища данных не оптимизированы.

В результате организации часто используют несколько систем, включая озёра данных, хранилища данных и специализированные базы данных. Это создаёт сложность и задержки из-за перемещения и копирования данных между системами. Чтобы объединить эти традиционные системы и удовлетворить новые требования рынка, появился новый тип систем — lakehouse.

Lakehouse

Lakehouse сочетает преимущества озёр данных и хранилищ данных, реализуя структуры данных и функции управления, характерные для хранилищ, непосредственно на экономически эффективном облачном хранилище в открытых форматах, таких как Apache Delta Lake, Iceberg или Apache Hudi. Эти форматы имеют ряд преимуществ перед традиционными форматами файлов, такими как CSV и JSON.

• CSV: не поддерживает типизацию столбцов.
• JSON: предлагает гибкость структуры, но отличается непоследовательной типизацией.
• Parquet, Apache Avro, ORC: улучшают ситуацию, будучи колоночными и более строго типизированными, но не всегда соответствуют требованиям ACID (атомарность, согласованность, изолированность, долговечность).

Delta Lake, Iceberg и Hudi добавляют поддержку ACID и возможность служить двусторонними хранилищами данных, обеспечивая высокую пропускную способность модификаций и поддерживая большие объёмы аналитических запросов. Эти форматы особенно хорошо подходят для современных облачных систем обработки данных в отличие от Parquet, изначально разработанного для локальных систем на базе Hadoop.

Преимущества Lakehouse

1. Поддержка транзакций: одновременное чтение и запись данных.
2. Применение схем и управление: обеспечение согласованности данных.
3. Прямая поддержка BI-инструментов.
4. Разделение хранения и вычислений: масштабируемость.
5. Открытость: стандартизированные форматы хранения и API для эффективного доступа.
6. Поддержка различных типов данных: от структурированных до неструктурированных.
7. Совместимость с разными нагрузками: машинное обучение, аналитика SQL, наука о данных.
8. Возможности потоковой обработки: исключение необходимости в отдельных системах для приложений реального времени.

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

Архитектура медальонов

На фоне lakehouse и новых открытых форматов возникает архитектура медальонов. Это парадигма моделирования данных, стратегически структурирующая данные в среде lakehouse с целью улучшения их качества на каждом этапе обработки.

Архитектура обычно включает три уровня:

• бронзовый,
• серебряный и
• золотой,

каждый из которых символизирует возрастание степени обработки данных.

Бронзовый уровень (Bronze layer)

Бронзовый уровень служит начальной точкой для данных, поступающих из внешних систем-источников. Таблицы на этом уровне повторяют структуру таблиц системы-источника в их исходном виде, включая дополнительные столбцы метаданных для фиксации информации, такой как дата/время загрузки и идентификатор процесса. Этот уровень фокусируется на эффективном захвате изменений данных (CDC), обеспечении исторического архива исходных данных, сохранении происхождения данных, проведении аудитов и упрощении повторной обработки без необходимости повторного чтения данных из системы-источника.

Серебряный уровень (Silver layer)

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

Этот уровень служит универсальным источником для самостоятельной аналитики, предоставляя пользователям возможности для создания отчётов, проведения продвинутой аналитики и машинного обучения. Серебряный уровень часто принимает вид моделей данных в формате 3NF, звёздной схемы, Data Vault или снежинки. Как и в традиционных хранилищах данных, этот уровень является ценным ресурсом для всех, кто использует данные для реализации проектов и анализа, направленных на решение бизнес-задач.

Золотой уровень (Gold layer)

Золотой уровень предоставляет ценную информацию, необходимую для решения бизнес-задач. Он агрегирует данные из серебряного уровня и подготавливает их для инструментов BI, построения отчётов и приложений машинного обучения. Этот уровень обеспечивает надёжность, высокую производительность и поддержку транзакций ACID для озёр данных, объединяя потоковые и пакетные транзакции поверх облачных хранилищ данных.

Рисунок 2-6. Представление архитектуры медальонов и её связь с dbt

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

Дополнительные замечания

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

Роль аналитиков-инженеров

Понимание основ архитектуры медальонов и концепции озёр данных важно для аналитиков-инженеров, так как в некоторых случаях именно здесь они будут проводить значительное количество времени. Это может включать проектирование структур для одного из уровней архитектуры, использование интерфейсов, предоставляемых открытыми форматами, или написание скриптов трансформации (например, с помощью инструментов вроде dbt), чтобы обеспечить продвижение данных через уровни архитектуры.

Однако значение открытых форматов и озёр данных может варьироваться в зависимости от используемой архитектуры данных. Например, в архитектурах вроде Snowflake данные преимущественно загружаются в собственные таблицы, а не в открытые форматы вроде Iceberg. В таких случаях понимание архитектуры озёр данных будет скорее полезным дополнением, чем критической необходимостью для аналитической инженерии.

Итог

Моделирование данных значительно эволюционировало в области аналитики для удовлетворения разнообразных бизнес-запросов и требований к отчётности.

• Звёздная схема обеспечивает простой способ выполнения запросов, располагая центральную таблицу фактов вокруг таблиц измерений.
• Снежинка позволяет добиться более глубокой детализации, разделяя измерения.
• Data Vault акцентируется на гибкости, чтобы справляться с часто меняющимися источниками данных.

Новая архитектура медальонов объединяет все эти модели, формируя полный план для различных аналитических нужд.

Эти усовершенствования направлены на решение определённых аналитических задач, будь то повышение производительности звёздной и снежинки, или гибкость Data Vault. По мере усложнения требований аналитики становится всё более важным выбирать правильный подход к моделированию данных, чтобы не только сделать их доступными, но и обеспечить их осмысленность и полезность для анализа.

Аналитики-инженеры используют такие структуры, как звёздная схема, снежинка, Data Vault или медальоны, чтобы создавать и поддерживать устойчивые, масштабируемые и эффективные структуры данных. Их работа обеспечивает оптимальную организацию данных, делая их легко доступными и полезными для аналитиков и учёных. Создавая когерентные наборы данных из огромных потоков информации, аналитики-инженеры закладывают основу для точных инсайтов и обоснованного принятия решений.

Сообщение Перевод 2 главы «Моделирование данных для аналитики (dbt)» появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

История аналитики включает важные этапы и технологии, которые сформировали эту область в том виде, какой мы знаем сегодня. Всё началось с появления концепции хранилищ данных в 1980-х годах, что стало основой для организации и анализа бизнес-данных. Компьютерный учёный Билл Инмон считается одним из первых, кто заложил теоретические основы для хранилищ данных в своих публикациях 1980–1990-х годов.

Следующий этап развития пришёлся на 1996 год, когда Ральф Кимболл опубликовал свою знаковую работу The Data Warehouse Toolkit. Эта книга заложила фундамент для dimensional modeling (размерного моделирования), которое стало важным шагом вперёд в эволюции аналитики.

Совокупный вклад Инмона и Кимболла в конце XX века оказал значительное влияние на формирование подходов к хранилищам данных и аналитике.

В начале 2000-х годов такие технологические гиганты, как Google и Amazon, столкнулись с необходимостью обработки огромных объёмов данных. Это привело к созданию Google File System и Apache Hadoop, открывших эпоху Big Data Engineering. В этот период специалисты использовали Hadoop для работы с большими данными.

Появление публичных облачных платформ, таких как Amazon Web Services (AWS), революционизировало разработку и развертывание программного обеспечения и приложений для работы с данными. Одним из первых предложений AWS стал Amazon Redshift, представленный в 2012 году. Этот инструмент сочетал технологии OLAP (онлайн-аналитической обработки) с традиционными базами данных. В ранние годы Redshift требовал ручного управления такими задачами, как очистка (vacuuming) и масштабирование, для поддержания производительности.

Со временем облачные технологии продолжили развиваться. Redshift, а также платформы, такие как Google BigQuery и Snowflake, упростили многие административные задачи, сохранив при этом свои основные преимущества. Это развитие подчёркивает непрерывные инновации в области облачной обработки данных.

Современный стек данных

Современный стек данных, включающий такие инструменты, как Apache Airflow, dbt и Looker, трансформировал рабочие процессы с данными. Эти изменения сделали термин «инженер больших данных» устаревшим, заменив его на более универсальную и широкую роль инженера данных (data engineer). Это изменение подчеркивалось в статье Максима Бошемена (Maxime Beauchemin), создателя Apache Superset и Apache Airflow, озаглавленной «The Rise of the Data Engineer». В статье он акцентировал внимание на возросшем значении инженеров данных в индустрии. Быстрое развитие инструментов изменило роли специалистов по данным: простые задачи стали стратегическими.

Сегодняшние инженеры данных выполняют разнообразные задачи, включая моделирование данных, обеспечение их качества, безопасность, управление данными, архитектурное проектирование и оркестрацию. Они всё чаще используют концепции и практики разработки ПО, такие как функциональная инженерия данных и декларативное программирование, для оптимизации своих рабочих процессов.

Основные языки для инженеров данных — это Python и SQL. Однако выбор языка программирования сильно зависит от задач и предпочтений проекта. Например, Java часто используется для работы с Apache Spark и Beam, Scala также популярна в этих экосистемах, а язык Go применяют в ряде других случаев. В крупных организациях нередко комбинируют Java и SQL для достижения оптимальных результатов.

Тенденции в индустрии

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

Цели главы

В этой главе мы познакомимся с инженерией аналитики и её ролью в процессе принятия решений на основе данных.

Мы обсудим:

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

Кроме того, мы изучим текущие тенденции и технологии, формирующие эту область, включая такие концепции, как data mesh. Также рассмотрим основные подходы к обработке данных: ELT (извлечение, загрузка, трансформация) и ETL (извлечение, трансформация, загрузка), а также используемые по всему миру методы моделирования данных.

Базы данных и их влияние на аналитику

В последние годы данные всё больше становятся ключевым активом компаний, стремящихся опережать конкурентов, улучшать внутренние процессы или лучше понимать своих клиентов. Однако с появлением новых инструментов, подходов и областей знаний, таких как Data Science и BI, стало сложнее охватить и понять весь ландшафт данных.

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

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

Роль баз данных

Усложнение бизнес-процессов привело к необходимости более сложных решений для принятия решений на основе данных. Одним из первых таких решений стала революция баз данных.

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

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

Хранилища данных и аналитика

Одним из самых распространённых способов использования баз данных в аналитике является методика хранилищ данных.

Хранилище данных — это централизованное хранилище, предназначенное для упрощения работы с данными. Данные поступают в хранилище из различных источников: транзакционных систем, внешних потоков данных и других баз данных. После этого данные очищаются, трансформируются и интегрируются в единую согласованную модель. Как правило, такая модель строится с использованием методик размерного моделирования, таких как звёздная схема или Data Vault.

Ещё одной важной областью использования баз данных является дата-майнинг. Дата-майнинг применяет статистические и машинные методы для выявления закономерностей и взаимосвязей в больших наборах данных. Это позволяет идентифицировать тренды, предсказывать поведение и выполнять другие прогнозы.

Технологии и языки для работы с базами данных

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

Инструменты для визуализации данных, такие как Tableau и Microsoft Power BI, которые легко интегрируются с базами данных, делают выводы аналитиков доступными и интуитивно понятными.

С развитием больших данных и ростом потребности в обработке огромных объёмов информации появились новые технологии баз данных, адаптированные к разнообразным задачам. Например, хранилища данных используются для агрегирования данных, дата-майнинг — для поиска скрытых закономерностей, а интеграция с BI-решениями позволяет анализировать данные в реальном времени.

Переход к аналитической инженерии

Однако подключение BI-инструментов напрямую к транзакционным базам данных (OLTP-репликам) имеет свои ограничения. Такой подход подходит для небольших наборов данных и простых запросов. Но с увеличением объёмов данных и усложнением аналитики возникают проблемы производительности и низкая скорость выполнения запросов.

Аналитическая инженерия решает эти проблемы. Аналитические инженеры оптимизируют потоки данных, трансформируют и агрегируют их для обеспечения готовности к аналитическим задачам. Они проектируют и поддерживают ETL-пайплайны, которые перемещают данные из различных источников в оптимизированные хранилища или озёра данных. Это позволяет организациям преодолеть ограничения OLTP-баз, обеспечивая быструю и эффективную аналитику с помощью инструментов, таких как Tableau.

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

Облачные вычисления и их влияние на аналитическую инженерию

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

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

Приспосабливаясь к этой меняющейся обстановке, компании всё больше акцентируют внимание на инновациях, дифференциации и устойчивости бизнес-моделей и стратегий. Для компаний, стремящихся к успеху в стремительно меняющемся мире, информационные технологии и системы предоставили отличные возможности для роста своих возможностей, помогая организациям преодолевать этот мир неопределённости и давления. Оптимизация операционных моделей стала срочной задачей, требующей пересмотра центров обработки данных и структуры ценообразования. Кроме того, предложения продуктов и услуг должны быть нацелены, в первую очередь, на простоту использования, снижение задержек, повышение безопасности, расширение диапазона инструментов в реальном времени, увеличение интеграции, повышение интеллектуальности, снижение необходимости написания кода и сокращение сроков выхода на рынок.

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

В отрасли практика создания, визуализации и анализа взаимосвязанных бизнес-данных в доступном формате обычно называется аналитикой данных. Исторически она также была известна как бизнес-аналитика (BI), и эти два термина тесно связаны. Хотя BI является подмножеством аналитики и ориентирована на принятие бизнес-решений, аналитика данных охватывает более широкий спектр, включая продуктовую аналитику, операционную аналитику и несколько других специализированных областей. Как BI, так и аналитика данных играют ключевую роль в предоставлении организациям конкурентных преимуществ за счёт анализа данных.

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

В результате решения на собственных серверах (on-premises), где инфраструктура для аналитики данных создаётся и управляется на территории компании, часто теряют свою привлекательность. Это особенно актуально для новичков в области аналитики, которые плохо знакомы с этим понятием. Как правило, on-premises решения требуют значительных вложений в оборудование, программное обеспечение и постоянное обслуживание. Они также менее гибкие и масштабируемые по сравнению с облачными решениями для аналитики данных.

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

Увеличивающееся распространение облачных вычислений в различных отраслях привело к тому, что такие компании, как Microsoft, Google и Amazon, разработали продвинутые инструменты для анализа данных и организации хранилищ данных. Эти инструменты созданы для работы в рамках парадигмы облачных вычислений и используют общие сетевые ресурсы для обеспечения более широкого доступа и упрощённого развертывания. Ярким примером этой тенденции является всеобъемлющая платформа аналитики данных от Microsoft — Microsoft Fabric.

Параллельно с этим dbt от компании dbt Labs, о котором подробно говорится далее в книге, выделяется как универсальный гибридный продукт. dbt, как и Hadoop, является решением с открытым исходным кодом, которое предоставляет пользователям возможность гибкого развертывания в соответствии с их конкретными потребностями — как в облаке, так и на локальной инфраструктуре. В своей облачной версии dbt легко интегрируется с ведущими облачными платформами, включая Microsoft Azure, Google Cloud Platform (GCP) и AWS. Благодаря своей открытости этот инструмент позволяет организациям настраивать развертывание в зависимости от уникальных требований и предпочтений инфраструктуры.

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

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

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

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

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

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

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

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

Поэтому можно справедливо сказать, что облачные вычисления стали ключевым компонентом как современных платформ данных, так и облачных платформ для аналитики и ИИ, которые ежедневно увеличиваются в объёме, способствуя изменению отрасли.

Цикл аналитики данных

Цикл аналитики данных представляет собой последовательность шагов, направленных на преобразование необработанных данных в ценные и удобные для восприятия данные-продукты. Эти продукты могут включать в себя хорошо организованные наборы данных, панели мониторинга, отчёты, API или даже веб-приложения. Иными словами, этот цикл описывает, как данные создаются, собираются, обрабатываются, используются и анализируются для достижения определённой цели или бизнес-результата.

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

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

Таким образом, цикл аналитики данных — это важная структура для понимания и описания этапов и процессов, связанных с созданием и поддержанием аналитических решений (рисунок 1-1). Этот концепт является фундаментальным в области науки о данных и аналитики, предоставляя структурированный подход к управлению различными задачами и действиями, необходимыми для создания эффективного аналитического решения.

Рисунок 1-1. Цикл аналитики данных

Цикл аналитики данных обычно включает следующие этапы

Определение проблемы

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

Моделирование данных

После определения бизнес-требований и оценки источников данных можно приступать к моделированию данных, выбирая метод, который лучше всего соответствует вашим потребностям. Это может быть модель «алмазной стратегии» (Strategy Diamond Model), звёздная схема, Data Vault или даже полностью денормализованный подход. Все эти концепции будут обсуждаться в главе 2.

Поглощение и трансформация данных

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

В зависимости от общей информационной архитектуры можно выбрать одну из стратегий:

• Schema-on-write — усилия сосредоточены на преобразовании необработанных данных непосредственно в соответствующие модели.
• Schema-on-read — данные загружаются и хранятся с минимальными преобразованиями, а основные трансформации выполняются на последующих уровнях платформы данных.

Хранение и структурирование данных

После проектирования (а возможно, и реализации) конвейеров данных необходимо выбрать форматы файлов и стратегии хранения. Это может быть простой формат, такой как Apache Parquet, или более продвинутые варианты, например Delta Lake или Apache Iceberg.

Также нужно решить, какие компоненты хранения использовать:

• Объектные хранилища в облаке, такие как Amazon Simple Storage Service (S3).
• Платформы, напоминающие хранилища данных, например Redshift, BigQuery или Snowflake.

Визуализация и анализ данных

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

Мониторинг качества данных, тестирование и документация

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

Включает в себя:

• Внедрение механизмов контроля качества, чтобы заинтересованные стороны могли доверять предоставляемым моделям данных.
• Документирование всех преобразований и их семантических значений.
• Гарантирование корректного тестирования на всех этапах передачи данных по конвейерам.

С использованием dbt многие из этих компонентов внедряются быстрее и эффективнее, поскольку они разрабатываются параллельно на протяжении всего цикла. Документирование, тестирование и обеспечение качества становятся повседневными задачами, выполняемыми одновременно. Эта тема будет подробно разобрана в главе 4.

Цикл аналитики данных — это ключевая концепция, которая позволяет организациям структурированно и последовательно подходить к процессам инженерии, анализа и науки о данных.

Следуя структурированному процессу, организации могут быть уверены, что они:

• Решают правильную задачу.
• Используют подходящие данные.
• Создают точные и надёжные продукты на основе данных.

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

Новая роль инженера аналитики

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

Недавно появившаяся категория специалистов, называемых инженерами аналитики (analytics engineers), играет ключевую роль в разработке и поддержании баз данных и конвейеров данных, что позволяет ученым данных и аналитикам сосредотачиваться на более сложных задачах. Инженеры аналитики отвечают за проектирование, создание и обслуживание архитектуры данных, которая помогает организациям превращать данные в ценные инсайты и принимать решения, основанные на данных.

Кроме того, переход от традиционных процессов ETL (Extract, Transform, Load) с жестко заданными схемами записи (schema-on-write) к процессу ELT (Extract, Load, Transform) с гибкими схемами чтения (schema-on-read) привел к тому, что данные теперь попадают в хранилища до их преобразования. Это создает возможности для аналитиков с глубокими техническими навыками, которые хорошо понимают бизнес и обладают способностями моделировать необработанные данные в чистые и четко определенные наборы данных — для инженеров аналитики.

Если бы такая комбинация навыков была востребована в эпоху традиционных хранилищ данных и ETL, она потребовала бы специалистов, одновременно обладающих знаниями в области программной инженерии и аналитики данных — таких найти было бы гораздо сложнее.

Роль инженера аналитики

Инженер аналитики играет роль моста между инженерами платформ данных, которые создают техническую инфраструктуру, и аналитиками данных, которые преобразуют данные в полезные продукты.

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

Эти специалисты обладают достаточной технической подготовкой, чтобы применять лучшие практики разработки программного обеспечения, такие как контроль версий и непрерывная интеграция/непрерывное развертывание (CI/CD). Однако они также должны уметь эффективно общаться с заинтересованными сторонами.

Аналогия с гражданским строительством

Инженеры платформ данных — это основа аналитического проекта. Они обеспечивают, чтобы инфраструктура была надежной, включая «системы водоснабжения, электроснабжения и фундамент». Они создают основу для всего последующего.

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

Аналитики данных — это дизайнеры интерьера. Они работают внутри уже построенных зданий, адаптируя их содержимое к потребностям пользователей, делая данные удобными и понятными для конечных потребителей.

Вместе эти роли работают над созданием целостной и функциональной аналитической среды.

Инженеры аналитики в жизненном цикле аналитики данных

Глядя на жизненный цикл аналитики данных, инженеры платформ данных создают платформы и загружают необработанные данные в корпоративные хранилища. С другой стороны, инженеры аналитики берут эти необработанные данные и преобразуют их так, чтобы они соответствовали аналитическим моделям данных, необходимым для поддержки принятия бизнес-решений.

Обязанности инженера аналитики

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

С учетом современных тенденций основными обязанностями инженеров аналитики являются:

• Проектирование и внедрение эффективных систем хранения и извлечения данных. Это предполагает работу с базами данных и технологиями хранения данных для создания моделей данных и структур, способных справляться с большими и сложными наборами данных.
• Создание и поддержка конвейеров данных. Они извлекают данные из различных источников, трансформируют их и загружают в центральное хранилище для анализа.

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

Ответственность в области производительности

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

Навыки и инструменты

Инженеры аналитики, как правило, владеют языками программирования и инструментами, такими как Python, R, SQL, и Spark, чтобы реализовывать конвейеры данных, модели данных и модели машинного обучения. Они также должны разбираться в облачных платформах, таких как AWS, GCP или Azure, для развертывания и масштабирования своих решений.

Основные обязанности инженера аналитики:

• Разрабатывать и внедрять системы хранения и извлечения данных, включая базы данных и хранилища, способные работать с большими и сложными наборами данных.
• Создавать и поддерживать конвейеры данных для извлечения, трансформации и загрузки данных из различных источников в центральное хранилище.
• Обеспечивать точность, полноту, согласованность и доступность данных посредством проверки качества данных, отслеживания их потоков и реализации мер безопасности.
• Использовать облачные платформы, такие как AWS, GCP, или Azure, для развертывания аналитических решений, оптимизации их масштабируемости, безопасности и стоимости.
• Оптимизировать производительность систем хранения и извлечения данных, конвейеров данных и моделей машинного обучения для обработки сложных объемов данных.
• Работать с учеными данных, чтобы понять их требования, выбирать и внедрять подходящие алгоритмы, а также следить за обучением и развертыванием моделей машинного обучения.
• Мониторить производительность моделей машинного обучения, устранять проблемы и оптимизировать их при необходимости.
• Следить за новыми технологиями и тенденциями в области инженерии данных, машинного обучения и аналитики.

Навыки и роль аналитического инженера

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

Обеспечение аналитики в Data Mesh

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

Преимущества Data Mesh

Data Mesh как архитектурный паттерн кардинально изменил взаимодействие аналитиков с инфраструктурой данных. Разделение монолитной архитектуры данных на независимые автономные сервисы позволяет командам решать проблемы масштабирования и управления более эффективно.

Масштабируемость и автономия. Разделение инфраструктуры на независимые части снижает риск дублирования данных и появления «смычек». Команды могут использовать инструменты и технологии, которые лучше подходят для их задач, оставаясь в рамках общих сервисов для управления жизненным циклом данных.

Управление разными типами данных. Data Mesh позволяет эффективно работать со структурированными, полуструктурированными и неструктурированными данными.

Улучшенное управление данными. Разделение архитектуры упрощает управление, повышая прозрачность и безопасность.

Роль инженера аналитики в Data Mesh

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

Основные задачи инженера аналитики в Data Mesh:

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

Продукты данных

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

Продукты данных должны обеспечивать доступность и повторное использование данных через API или другие методы.

Некоторые примеры продуктов данных включают:

• REST API, позволяющий пользователям запрашивать определённую бизнес-модель данных.
• Конвейер данных, который загружает и обрабатывает данные из различных источников.
• Озеро данных, которое хранит и управляет большими объёмами структурированных и неструктурированных данных.
• Инструмент визуализации данных, помогающий пользователям понимать и передавать аналитическую информацию.

Продукты данных также могут состоять из микросервисов. Это небольшие, независимые и узкоспециализированные сервисы, которые можно разрабатывать, развёртывать и масштабировать отдельно. К ним можно получить доступ через API, и они могут повторно использоваться в масштабе всей организации.

dbt как инструмент для реализации Data Mesh

dbt — это инструмент с открытым исходным кодом, который помогает инженерам данных, аналитикам данных и инженерам аналитики создавать Data Mesh, предоставляя возможность разрабатывать, тестировать и управлять сервисами данных. Он позволяет командам определять, тестировать и строить модели данных, а также создавать чёткие и хорошо определённые интерфейсы для этих моделей, чтобы другие команды и приложения могли легко их использовать.

Функциональные возможности dbt, поддерживающие создание Data Mesh:

Моделирование данных

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

Тестирование данных

dbt предоставляет фреймворк для тестирования, который позволяет командам проверять свои модели данных и удостоверяться в их точности и надёжности. Это помогает выявлять ошибки на ранних стадиях разработки и обеспечивает высокое качество сервисов данных.

Документирование данных

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

Отслеживание данных

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

Управление данными

Функционал управления данными позволяет внедрять политики управления данными, такие как контроль доступа, отслеживание lineage и проверка качества данных, что помогает обеспечить безопасность и высокое качество данных.

Хотя основное внимание в аналитической инженерии уделяется проектированию и реализации моделей данных, важно отметить, что возможности отслеживания данных и управления ими могут значительно повысить эффективность аналитических процессов. Эти возможности особенно полезны в случаях, когда модели данных должны отслеживать происхождение данных и соответствовать строгим политикам управления данными. Применение таких практик и моделей управления, включая подход Data Mesh, может варьироваться в зависимости от специфических потребностей и сложности среды данных. Многие успешные внедрения dbt начинаются с более простых моделей данных на основе схемы одной звезды и со временем могут перейти к изучению более сложных концепций, таких как Data Mesh, по мере роста потребностей в данных.

Суть аналитической инженерии

Преобразование данных — это процесс перевода данных из одного формата или структуры в другой, чтобы сделать их более полезными или подходящими для конкретного приложения или цели. Этот процесс необходим, поскольку позволяет организациям превращать необработанные, неструктурированные данные в ценные инсайты, которые могут влиять на бизнес-решения, улучшать операции и стимулировать рост.

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

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

dbt — это «гемба» для аналитиков и заинтересованных сторон бизнеса.

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

Гемба — это японский термин, означающий «реальное место». В корпоративном мире гемба относится к месту, где создаётся ценность.

В стратегии ETL преобразование данных обычно выполняется до загрузки данных в целевую систему, такую как хранилище данных или озеро данных. Данные извлекаются из различных источников, преобразуются для соответствия структуре и формату целевой системы, а затем загружаются в неё. Этот процесс обеспечивает согласованность и пригодность данных для использования в системах и приложениях.

Напротив, стратегия ELT представляет собой более современный и гибкий подход к обработке данных. В этой стратегии данные сначала извлекаются и загружаются в целевую систему, а затем подвергаются преобразованию. ELT предоставляет несколько преимуществ, включая повышенную гибкость и возможность поддержки более широкого спектра приложений, чем традиционная парадигма ETL. Одним из значительных преимуществ является его универсальность в проведении различных преобразований данных и предоставлении оперативных инсайтов непосредственно в целевой системе.

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

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

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

Устаревшие процессы

Традиционно устаревшие процессы ETL (Extract, Transform, Load) были сложными, трудоёмкими и требовали специализированных навыков для разработки, внедрения и сопровождения. Они также обычно включали значительное количество ручного кодирования и манипуляций с данными, что делало их склонными к ошибкам и сложными для масштабирования.

Кроме того, такие процессы часто были негибкими и не могли адаптироваться к изменяющимся потребностям бизнеса или новым источникам данных. С ростом объёма, разнообразия и скорости данных устаревшие процессы ETL становятся всё менее эффективными и, как следствие, заменяются более современными и гибкими подходами, такими как ELT (Extract, Load, Transform).

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

Примером устаревшего процесса ETL может быть использование комбинации SQL-скриптов и языков программирования, таких как Java или C#, для извлечения данных из реляционной базы данных, преобразования данных с помощью программного языка и последующей загрузки преобразованных данных в хранилище данных. Другим примером является использование специализированных ETL-инструментов, таких как Oracle Data Integrator или IBM InfoSphere DataStage, для извлечения, преобразования и загрузки данных между системами. Эти устаревшие процессы ETL часто бывают сложными, трудными для сопровождения и масштабирования, и обычно требуют наличия выделенной команды разработчиков.

Использование SQL и хранимых процедур для ETL/ELT

Ранее в некоторых платформах данных для выполнения ETL использовались хранимые процедуры в системах управления реляционными базами данных (RDBMS), таких как SQL Server или Oracle.

Хранимые процедуры — это заранее подготовленный SQL-код, который можно сохранить в движке базы данных, чтобы этот код мог использоваться многократно. В зависимости от того, осуществляется ли ввод или вывод данных, скрипты выполняются либо в исходной, либо в целевой базе данных.

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

Пример 1-1. SQL-процедура для извлечения данных

CREATE PROCEDURE etl_example AS
BEGIN
    -- Extract data from the source table
    SELECT * 
    INTO #temp_table 
    FROM source_table;

    -- Transform data
    UPDATE #temp_table
    SET column1 = UPPER(column1),
    column2 = column2 * 2;

    -- Load data into the target table
    INSERT INTO target_table
    SELECT * 
    FROM #temp_table;
END

Эта хранимая процедура сначала использует оператор SELECT INTO для извлечения всех данных из исходной таблицы и сохранения их во временной таблице (#temp_table). Затем с помощью оператора UPDATE она изменяет значения в колонке column1, преобразуя их в верхний регистр, и удваивает значения в колонке column2. В заключение процедура использует оператор INSERT INTO для загрузки данных из #temp_table в target_table.

Не переживайте, если вы не знакомы с синтаксисом SQL. Глава 3 полностью посвящена основам работы с ним.

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

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

Использование ETL-инструментов

Как упоминалось ранее, ETL-инструменты — это программные приложения, которые ускоряют процесс создания конвейеров для загрузки и преобразования данных, предоставляя визуальный интерфейс, набор инструментов разработки (SDK) или программную библиотеку с готовым кодом и артефактами. Эти инструменты используются для извлечения, преобразования и загрузки данных из различных источников в целевые системы, такие как хранилища данных или озёра данных. Их часто применяют в организациях для автоматизации переноса данных из различных систем и баз данных в центральное хранилище или озеро данных, где эти данные могут быть проанализированы.

Airflow — это популярная платформа с открытым исходным кодом для управления и планирования данных в конвейерах. Разработанная Airbnb, она приобрела популярность в последние годы благодаря своей гибкости и масштабируемости. Airflow позволяет пользователям определять, планировать и мониторить конвейеры данных с использованием кода на Python, что упрощает создание таких конвейеров для инженеров данных и аналитиков.

Пример 1-2 демонстрирует простой DAG (направленный ациклический граф) в Airflow. DAG — это направленный граф без циклов.

Пример 1-2. DAG в Airflow

from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from datetime import datetime, timedelta

default_args = {
  'owner': 'me',
  'start_date': datetime(2022, 1, 1),
  'depends_on_past': False,
  'retries': 1,
  'retry_delay': timedelta(minutes=5),
}

dag = DAG(
  'simple_dag',
  default_args=default_args,
  schedule_interval=timedelta(hours=1),
)

task1 = BashOperator(
  task_id='print_date',
  bash_command='date',
  dag=dag,
)

task2 = BashOperator(
  task_id='sleep',
  bash_command='sleep 5',
  retries=3,
  dag=dag,
)

task1 >> task2

Этот код определяет DAG с именем simple_dag, который выполняется каждый час. Он включает две задачи: print_date и sleep. Первая задача выполняет команду date, которая выводит текущую дату и время. Вторая задача выполняет команду sleep 5, которая заставляет задачу «спать» в течение пяти секунд. Для второй задачи задано количество повторных попыток, равное 3. Если она завершится с ошибкой, Airflow предпримет три попытки выполнения перед тем, как прекратить попытки. Эти две задачи связаны оператором >>, что означает, что задача sleep зависит от успешного выполнения задачи print_date и будет выполнена только после её завершения.

Airflow — это продуктивный инструмент для планирования и управления ETL-конвейерами, но у него есть некоторые ограничения.

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

dbt может решить эти ограничения Airflow, предоставляя набор лучших практик и соглашений для преобразования данных, а также простой и понятный интерфейс для выполнения и управления этими процессами. dbt также можно интегрировать с Airflow, чтобы предложить полноценное ETL/ELT-решение, которое легко настроить и управлять, при этом обеспечивая высокую гибкость и контроль над конвейерами данных.

Революция dbt

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

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

Чтобы показать, насколько просто создать модель в dbt, можно представить задачу расчёта общего дохода компании путём суммирования доходов по каждому заказу. Такая модель может быть определена с помощью файла модели dbt, содержащего SQL-код расчёта и любые необходимые зависимости или параметры. Пример 1-3 демонстрирует, как может выглядеть такой файл модели.

Пример 1-3. Модель dbt

{{ config(materialized='table') }}

select
    sum(orders.revenue) as total_revenue
from {{ ref('orders') }} as orders

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

Ещё одно преимущество dbt заключается в том, что он обеспечивает более эффективное управление конвейером данных. Благодаря интеграции с инструментами оркестрации, такими как Airflow, Dagster, Prefect, а также продуктом dbt Cloud от dbt Labs, dbt помогает командам эффективно планировать, организовывать и отслеживать конвейеры данных. Это позволяет данным оставаться актуальными и точными. Синергия dbt и таких инструментов, как Airflow, обеспечивает непрерывное обновление данных и развертывание новой логики, аналогично практике CI/CD в разработке программного обеспечения. Интеграция гарантирует, что при появлении новых данных или обновлении преобразований конвейер данных будет оркестирован и выполнен эффективно, предоставляя надёжные и своевременные инсайты.

В целом dbt становится широко используемым инструментом для организаций, стремящихся улучшить свои аналитические возможности и оптимизировать конвейеры данных. Несмотря на то, что это относительно новая технология, её уже используют многие компании, и она считается ценным инструментом для специалистов по работе с данными. Глава 4 предоставит более детальное описание возможностей и особенностей dbt.

Резюме

За последние десятилетия область управления данными претерпела значительные изменения, переходя от структурированных методов хранения и доступа к данным, таких как хранимые процедуры на базе SQL, к более гибким и масштабируемым рабочим процессам. Эти современные рабочие процессы поддерживаются мощными инструментами, такими как Airflow и dbt. Airflow упрощает динамическую оркестрацию, а dbt поднимает код аналитики до уровня программного обеспечения промышленного качества, предлагая инновационные подходы к тестированию и преобразованию данных.

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

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

Глава 2 погрузится в тему моделирования данных и его ключевую роль в аналитической инженерии. В этой главе мы рассмотрели эволюцию управления данными, появление роли инженера-аналитика, концепции, такие как data mesh, и различия между стратегиями ELT и ETL. Этот разнообразный набор тем нацелен на предоставление всестороннего обзора ландшафта данных.

Сообщение Перевод Analytics Engineering with SQL and dbt. Глава 1 появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

В 2006 году британский математик и предприниматель в области анализа данных Клайв Хамби ввел фразу:

«Данные — это новая нефть»,

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

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

Именно это привлекает нас, авторов этой книги, в dbt. Одним из ключевых навыков любого специалиста по данным является умение писать SQL, и dbt делает этот навык центральным. Хотя dbt — относительно новый инструмент, для тех, кто уверенно работает с SQL, порог вхождения минимален. Эта глава является введением ко всей книге. Мы расскажем, что такое dbt, для кого он предназначен, как он вписывается в вашу систему работы с данными и многое другое. Также мы дадим обзор продукта и познакомим с основными терминами, которые будут использоваться далее.

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

Что такое dbt?

Простыми словами, dbt (Data Build Tool) — это инструмент для преобразования данных с открытым исходным кодом, который часто используется для моделирования данных в хранилищах. Он позволяет специалистам по данным, владеющим SQL, эффективнее обрабатывать данные в хранилищах. Более детально, это инструмент с фреймворком разработки, который сочетает модульный SQL и лучшие практики разработки ПО для ускорения, улучшения и повышения надежности процессов преобразования данных.

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

Важно понимать, что dbt — это только инструмент для преобразования данных. Он не занимается перемещением данных между системами. В рамках архитектур ETL (Extract-Transform-Load) или ELT (Extract-Load-Transform) dbt отвечает исключительно за этап преобразования. Для построения полноценного конвейера ETL/ELT потребуется комбинировать dbt с другими инструментами, такими как Fivetran, Airflow или Meltano.

Основные ограничения и особенности dbt:

• dbt не содержит механизмов для вычислений. Все вычисления выполняются с использованием ресурсов хранилища данных, к которому он подключается.
• Каждый создаваемый в dbt модуль (за исключением моделей на Python) является SQL-запросом. Даже если используются шаблоны Jinja, итоговый код всегда компилируется в SQL.
• dbt автоматически создает объекты базы данных (таблицы, представления и т. д.), избавляя вас от необходимости делать это вручную.

История создания dbt

dbt был создан в 2016 году компанией под названием Fishtown Analytics, которая в 2020 году была переименована в dbt Labs.

Fishtown Analytics, консалтинговая компания в области аналитики, расположенная в районе Фиштаун в Филадельфии, была основана с целью помощи компаниям с финансированием серий A и B в реализации продвинутой аналитики. Основной задачей компании было улучшение методов работы аналитиков данных. Основатели верили, что анализ данных должен напоминать подходы, применяемые в разработке программного обеспечения, и стремились найти подходящее решение. Поскольку в данной области существовал пробел, они создали dbt, чтобы восполнить его.

Интересно, что изначально dbt был открыт исходным решением, добавляющим базовые возможности трансформации в Stitch, но видение для этого инструмента оказалось значительно шире. Fishtown Analytics (до переименования) разработала платную версию инструмента под названием Sinter, которая предоставляла пользователям дополнительные возможности, включая планирование задач, ведение журналов, оповещения и многое другое. В 2019 году этот инструмент был переименован в dbt Cloud, и его функциональность значительно выросла, превратившись в то, чем он является сегодня.

Существуют две основные версии инструмента: dbt Core и dbt Cloud, которые подробно рассматриваются в этой книге.

Открытая версия, dbt Core, представляет собой кодовую базу, необходимую для работы с dbt. Для ее использования требуются собственные инструменты и инфраструктура, но сам код можно применять бесплатно, даже если другие элементы генерируют затраты. Если вы не используете dbt Core, а предпочитаете платную версию dbt Cloud, вы все равно получаете некоторую степень контроля над кодовой базой.

В dbt Cloud доступны макросы и другие функции, которые можно изменять, влияя на поведение инструмента по умолчанию. Однако вы не сможете изменять все, как это возможно в dbt Core. Некоторые элементы dbt Cloud, такие как интегрированная среда разработки (IDE), планирование задач, и управление заданиями, не являются открытыми. Эти аспекты рассматриваются кратко в этой главе и более подробно в главе 2.

Несколько важных аспектов dbt, которые необходимо понять на раннем этапе:

• dbt не обладает собственной вычислительной мощностью и использует мощности вашего хранилища данных.
• Каждая модель, за исключением Python-моделей, создаваемая в dbt, записывается как SQL-запрос SELECT и компилируется в SQL-код, даже если вы используете Jinja.
• dbt автоматически создает объекты базы данных (таблицы, представления и т.д.), устраняя необходимость в их предварительном создании.

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

Все запросы и преобразования dbt выполняются с использованием вычислительных мощностей вашего хранилища данных. Например, если вы используете AWS Redshift в качестве хранилища данных, dbt будет использовать вычислительный кластер AWS Redshift для создания моделей. У dbt нет собственной вычислительной инфраструктуры для обработки данных, и в обозримом будущем это вряд ли изменится.

Разработка и планирование заданий в dbt Cloud требует минимальных дополнительных вычислительных мощностей, которые включены в сервис, но это не касается вычислений в вашем хранилище. Если вы используете dbt Core, вам необходимо учесть этот аспект при проектировании своей инфраструктуры. Кроме того, dbt не может извлекать и загружать данные, поэтому данные должны быть доступны в системе, где выполняется их преобразование.

Во-вторых, каждая модель, созданная в dbt, компилируется в SQL-запрос, который затем выполняется в хранилище.

Исключением являются Python-модели, о которых мы подробно поговорим в главе 4. dbt добавляет Jinja в ваш SQL-код, что делает его более мощным и эффективным. Однако вся работа dbt в конечном итоге сводится к SQL-коду.

Важно понимать, что все модели в dbt пишутся в виде SQL-запросов SELECT.
Это может потребовать времени на привыкание, если вы привыкли использовать команды манипулирования данными (DML), такие как UPDATE, INSERT, MERGE или DELETE. Однако компилятор dbt автоматически добавляет необходимый шаблонный код DML или DDL (языка определения данных), чтобы управлять объектами базы данных.

Наконец, dbt берет на себя создание объектов базы данных в вашем хранилище.

Если вы ранее работали с хранилищами данных, вы, возможно, привыкли предварительно создавать схемы объектов перед их преобразованием, но теперь это больше не требуется. Хотя такая возможность существует, это считается плохой практикой. Мы рекомендуем использовать dbt для создания объектов. Вы можете управлять такими аспектами, как типы данных, через код с помощью команд, таких как CAST.

Инженер-аналитик

Если вы долго работаете с dbt, то неизбежно столкнетесь с термином «Инженер-аналитик» (Analytics Engineering). Это понятие было введено командой dbt для обозначения того, чем занимаются пользователи dbt. Инженеры-аналитики представляют собой сочетание традиционного инженера данных (Data Engineer) и аналитика данных (Data Analyst). Они предоставляют бизнес-пользователям доступ к обработанным и структурированным наборам данных, упрощая потребление данных.

Аналитики данных, как правило, сосредоточены на анализе данных, тогда как инженеры данных занимаются разработкой инфраструктуры, извлечением, загрузкой и преобразованием данных. С помощью dbt инженер-аналитик объединяет элементы обеих профессий, создавая мост между анализом данных и инженерией данных, используя навыки, в которых он чувствует себя уверенно.

Клэр Кэрролл написала статью на сайте dbt, где представила свое видение того, чем отличаются инженеры данных, аналитики данных и инженеры-аналитики.

Инженер данных (Data Engineer)

• Создание пользовательских интеграций данных.
• Управление оркестрацией всей конвейерной обработки данных.
• Разработка и развертывание конечных точек для моделей машинного обучения.
• Построение и поддержание платформы данных.
• Оптимизация производительности хранилищ данных.

Инженер-аналитик (Analytics Engineer)

• Предоставление чистых и преобразованных данных, готовых для анализа.
• Применение лучших практик разработки программного обеспечения к аналитическому коду (например, контроль версий, тестирование, CI/CD).
• Поддержка документации данных и определений.
• Обучение пользователей использованию инструментов визуализации данных.

Аналитик данных (Data Analyst)

• Глубокий анализ для ответа на специфические бизнес-вопросы.
• Работа с бизнес-пользователями для понимания их требований к данным.
• Разработка и развертывание конечных точек для моделей машинного обучения.
• Создание отчетов и информационных панелей.
• Разовый (ad-hoc) анализ данных.

Новая роль или хорошая маркетинговая стратегия?

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

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

Инженерия аналитики берет аспекты, традиционно связанные с обеими ролями, и объединяет их. Компании (особенно с небольшими командами) занимаются этим десятилетиями, но dbt предоставляет платформу, которая делает этот процесс более эффективным.

Мы не считаем это чем-то отрицательным. Новый титул получил огромную популярность, увеличил осведомленность о бренде и дал пользователям dbt возможность объединяться. Это здорово!

Почему dbt ориентирован на аналитиков данных

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

Мы полностью поддерживаем эту идею, но также хотим отметить, что dbt является отличным инструментом для инженеров данных. Однако это не всегда получает должное внимание с точки зрения маркетинга.

dbt как инструмент для инженеров данных

Скорее всего, причина кроется в финансовой модели, а не в удобстве использования продукта. dbt Labs зарабатывает на подписке на dbt Cloud. Большинство инженеров данных комфортно работают с dbt Core, который является бесплатным и с открытым исходным кодом (и многие его используют). В то же время аналитики данных, вероятно, менее заинтересованы в управлении развертыванием dbt Core.

Несмотря на это, мы видим здесь упущенные возможности. Оба автора этой книги больше относятся к инженерам данных, и dbt — один из наших любимых инструментов для создания продуктов данных. Даже учитывая нашу уверенность в использовании dbt Core, мы встречали множество инженеров данных, которым также нравится dbt Cloud из-за простоты развертывания.

Примечание: dbt — это не только инструмент для аналитиков данных, но и великолепный инструмент для инженеров данных.

Роль dbt в современной архитектуре данных

Прежде чем понять роль dbt, важно осознать значимость ELT (extract-load-transform, извлечение-загрузка-преобразование). Мы исключаем ETL (extract-transform-load, извлечение-преобразование-загрузка), поскольку большинство облачных архитектур не используют этот подход, хотя приведенные далее утверждения актуальны и для него. ELT стал популярным в проектировании хранилищ данных благодаря мощным современным аналитическим базам данных. Такие облачные хранилища данных, как Snowflake, Synapse, Databricks и BigQuery, обладают высокой скоростью, масштабируемостью и способны выполнять преобразования данных на уровне базы данных. Это особенно верно в контексте разделения хранения и вычислений, характерного для Snowflake и архитектуры Lakehouse.

Одной из главных причин популярности ELT в облачных сервисах является задержка в сети и время, необходимое для передачи данных. Хотя современные сетевые скорости высоки и продолжают расти, объемы данных также увеличиваются. Если вы работаете с большими объемами данных, передаваемых через Интернет, это все равно может занять значительное время. Поэтому важно загружать данные только один раз.

Для упрощения рассмотрим пример: предположим, у нас есть 10 таблиц общим объемом 100 ГБ, которые нужно передать с локального сервера базы данных в AWS S3. Это займет 5 часов. Если добавить преобразования в этот процесс (настройка ETL) и обнаружить ошибку, придется повторять весь процесс заново. Или, если спустя месяц изменятся требования к использованию этих данных, придется снова загружать данные, включая новый объем, накопленный за этот период. Если таких источников данных становится больше, вы быстро начнете тратить массу времени.

В случае загрузки сырых данных (ELT) данные загружаются только один раз. Да, вы фактически храните дополнительную копию исходных данных, и преобразование при загрузке могло бы уменьшить объем, но хранение в облаке настолько дешево, что для большинства это не проблема. Когда сырые данные уже загружены, работать с ними становится намного быстрее. Если допущена ошибка, вы легко можете ее исправить или даже начать все сначала, что экономит массу времени. Более того, при запуске новых проектов, которые также будут использовать эти данные, не придется снова их загружать, что сокращает общий объем хранения и время.

Примечание: dbt не ограничивается построением хранилища данных и может использоваться для поддержки других отчетных и аналитических рабочих процессов, где хранилище данных может быть не обязательно. Однако акцент в этой книге сделан именно на хранилищах данных.

Рассмотрим высокоуровневые шаги, связанные с архитектурой ELT в хранилище данных, и то, как dbt справляется с этим. На рисунке 1-2 представлена диаграмма типичных элементов, встречающихся в процессе создания хранилища данных. Независимо от того, используете ли вы dbt для преобразований, эти аспекты стоит учитывать при работе с любым выбранным инструментом.

Рисунок 1-2. Высокоуровневые этапы проектирования хранилища данных на основе ELT

1. Определение и настройка загрузчика данных

Первый шаг при создании ELT-хранилища данных — это выбор и настройка загрузчика данных. Загрузчик отвечает за разработку конвейеров загрузки данных из исходных систем в ваше хранилище. Этот инструмент может быть любым, который вы выберете. Как уже упоминалось, dbt используется исключительно для преобразования данных, поэтому эта часть процесса выходит за рамки его применения. Однако правильный выбор загрузчика данных — важный этап перед началом работы с dbt. Если вы не знаете, с чего начать, рекомендуется обратиться к поставщику вашего хранилища данных за рекомендациями. Некоторые инструменты загрузки данных отлично интегрируются с определенными платформами и предоставляют дополнительные преимущества, в то время как другие могут быть несовместимы.

Облачные провайдеры, такие как Azure, AWS и Google Cloud, предлагают собственные решения (например, Azure Data Factory, AWS Glue, Google Cloud Data Fusion), но не забывайте о сторонних инструментах, таких как Fivetran, которые предоставляют нативные коннекторы и значительно упрощают процесс загрузки данных. Главное — провести тщательный анализ, поскольку выбор инструмента может повлиять на успех проекта.

2. Загрузка необработанных данных

После настройки загрузчика данных следующим шагом будет загрузка сырых данных. Важно не изменять данные при загрузке, чтобы их можно было использовать для разных задач. Если вы допустите ошибку, можно будет легко исправить её без повторной загрузки данных. Куда именно загружать данные, зависит от вашей архитектуры: это может быть либо учетная запись для хранения данных (так называемое озеро данных), либо непосредственно хранилище данных.

Если вы используете dbt для преобразования данных, важно, чтобы сырые данные находились в той же системе, где будут производиться преобразования. Например, если данные сначала загружаются в озеро данных, а dbt нацелен на AWS Redshift, вам нужно будет предварительно загрузить данные в Redshift перед их использованием. Мы рекомендуем рассмотреть архитектуры озер и платформы вроде Snowflake, которые позволяют загружать данные напрямую с преимуществами разделения хранения и вычислений.

3. Снимок (snapshot) данных

После загрузки необработанных данных следующий шаг — создание их снимков (snapshot). Это не следует путать с функцией снимков в dbt. Цель этого шага — защитить необработанные данные от изменений, так как любая ошибка может привести к необходимости повторной загрузки или к потере исторических данных. Снимки создаются путем выборки нужных данных из сырых объектов/таблиц для дальнейшей работы.

Хранение и использование таких снимков (в виде таблиц, представлений, CTE и пр.) зависят от проектирования вашего хранилища. Мы рекомендуем на этом этапе сочетать снимки данных с начальными преобразованиями и загружать результат в промежуточные таблицы хранилища. Это позволяет использовать инкрементальную логику, чтобы обрабатывать только новые и измененные данные вместо полного набора. dbt делает этот процесс удобным, что подробно рассматривается в этой книге.

4. Преобразование данных в соответствии с моделью данных

На этом этапе данные нормализуются/денормализуются, очищаются и моделируются для аналитики, машинного обучения и других задач. Этот шаг включает преобразование данных из различных систем (например, транзакционных) в оптимизированный формат для отчетности и аналитики. Это основная задача dbt. Конкретные преобразования зависят от структуры вашей модели данных, о которой будет рассказано в следующем разделе главы.

5. Тестирование данных

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

6. Развертывание

Код не должен разрабатываться напрямую в производственной среде. Для безопасного и быстрого переноса протестированного кода между средами часто применяются DevOps-подходы, такие как CI/CD (непрерывная интеграция/развертывание). Например, Azure DevOps может использоваться в Azure, а dbt Cloud позволяет управлять этим процессом из одного инструмента. В десятой главе описано, как выполнять CI в dbt Cloud и GitHub Actions для пользователей dbt Core.

7. Документация

Документация часто игнорируется, но это ключевой аспект успешного проекта хранилища данных. dbt упрощает этот процесс: описания объектов добавляются в процессе разработки, и инструмент автоматически генерирует веб-документацию на основе метаданных. Это значительно сокращает время, затрачиваемое на обновление документации, о чем подробно рассказывается в девятой главе.

8. Использование инженерных практик

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

9. Подача данных конечным пользователям

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

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

Моделирование данных

dbt — это потрясающий инструмент, который значительно упрощает многие шаги по преобразованию данных. Однако, как и с любым инструментом разработки, если не подходить к его использованию стратегически, все может быстро превратиться в хаос. Если вы используете dbt для построения хранилища данных или конвейеров данных для совместного использования, важно тщательно продумать, как вы хотите моделировать свои данные. Даже отсутствие решения по этому вопросу является решением само по себе. Если dbt используется для того, чтобы аналитики могли более эффективно хранить и использовать код, все равно следует продумать такие аспекты, как структура проекта, соглашения об именах и т. д.

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

Важно: dbt нейтрален в вопросе моделирования данных, поэтому выбор подхода полностью за вами и должен соответствовать потребностям вашего бизнеса.

Прежде чем начать, определите, действительно ли вам нужно хранилище данных. В некоторых случаях оно может быть не нужно, поэтому важно обдумать это заранее. Вот несколько вопросов, ответив «да» на которые, вы можете понять, что хранилище данных вам все-таки нужно:

1. Необходимо ли иметь единую версию истины для ваших данных?
2. Будут ли различные отделы использовать эти данные?
3. Нужно ли анализировать данные из разных источников?
4. Требуется ли сохранять исторические данные и анализировать метрики на определенный момент времени?
5. Есть ли у вас большой объем данных, требующий преобразования?
6. Выполняете ли вы много сложных запросов на регулярной основе?

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

Частые ошибки при использовании dbt

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

Например:

• Дублирование работы.
• Создание нескольких версий данных (размывание истины).
• Неэффективные запросы.
• Сложности с передачей знаний новым членам команды.

Наличие стратегии и структуры — ключ к успешному использованию dbt. dbt — это отличный инструмент, но он не решает все проблемы сам по себе. Будь то хранилище данных или аналитическая система, важно тщательно продумать процесс разработки и подход к моделированию данных.

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

В этой книге мы не будем подробно разбирать выбор подхода, но приведем список наиболее распространенных методов моделирования данных:

• Data Vault: использует hubs (центры), links (ссылки) и satellites (спутники) для хранения данных.
• Dimensional Modeling: использует факты и измерения для хранения данных.
• Одна большая таблица (One Big Table): денормализованные данные, все значения хранятся в одной таблице.
• Реляционная модель (Relational): данные хранятся в нормализованном виде.
• Стандартные модели данных (Common Data Models): открытые и поддерживаемые сообществом модели, используемые в определенных отраслях.

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

Рекомендации авторов

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

Навыки, необходимые для работы с dbt

Перед тем как начать использовать dbt, важно понимать, какие навыки потребуются для работы с ним. При изучении любого нового инструмента важно оценить, насколько ваши текущие навыки подходят для работы с ним, и лучше, если это будет четко разъяснено.

dbt — это всего лишь структура, в которой вы работаете, и для успеха вам понадобятся дополнительные навыки. Хотя работа с dbt сама по себе является навыком, она включает в себя множество аспектов, которые составляют основу профессии аналитического инженера (Analytics Engineer). Хорошая новость заключается в том, что если вы уже работали с данными, то освоить dbt не составит труда. Среди аналогов на рынке, dbt — один из самых простых инструментов для изучения.

Ниже приведен список ключевых технических навыков, которые полезно иметь перед началом работы с dbt. Однако не все они равнозначны по важности, и многие из них можно освоить по мере работы:

• SQL (основной навык)
• Jinja (шаблонный язык для Python-разработчиков)
• YAML (конфигурационные и описательные файлы)
• Python (в зависимости от сценария использования)
• Моделирование данных
• Контроль версий (Source Control)

В следующих разделах описаны каждый из этих навыков и их роль в работе с dbt, а также оценка важности предварительного опыта по шкале от 1 до 5.

Навык #1: SQL

Основной навык, необходимый для эффективной работы с dbt, — это умение писать запросы на языке SQL (Structured Query Language). Для работы с dbt достаточно уметь писать простые запросы SELECT — это базовый уровень, который многие осваивают в начале изучения SQL.

Однако продвинутые знания SQL позволят вам быть более эффективным разработчиком. Простых SELECT-запросов может хватить на начальном этапе, но в дальнейшем вам, скорее всего, потребуется использовать более сложные запросы. Например, мы рекомендуем изучить CTE (Common Table Expressions) и оконные функции (Window Functions), чтобы повысить уровень владения SQL.

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

Примечание: Умение писать SELECT-запросы на SQL — основной технический навык, необходимый для начала работы с dbt. Остальные навыки можно развить со временем или они не критичны для большинства сценариев.

Оценка опыта: 4/5. dbt не требует продвинутых знаний SQL, но базовые знания обязательны. Если SQL — это что-то совершенно новое для вас, возможно, стоит рассмотреть другие инструменты.

Навык #2: Jinja

Следующий важный навык — это Jinja. Jinja — это шаблонный язык, используемый в Python, который позволяет выполнять сложные операции, трудновыполнимые только средствами SQL. Если вы ранее не работали с Python, Jinja может быть для вас новым инструментом.

Однако пугаться не стоит — основные команды Jinja легко изучить, и dbt хорошо адаптирован для новичков. Есть несколько ключевых команд Jinja, которые важно знать, а остальное можно освоить по мере работы.

В dbt Jinja помогает SQL-разработчикам создавать динамичные запросы. Мы посвятили изучению Jinja отдельную главу (глава 6). Хотя этот навык важен для полного использования возможностей dbt, вы можете успешно выполнять проекты, используя лишь базовые элементы Jinja.

Оценка опыта: 2/5. Опыт работы с Jinja или Python полезен, но не обязателен. Базовые команды легко освоить, а продвинутые возможности могут потребовать некоторого обучения.

Навык #3: YAML

Знание YAML полезно для работы с dbt, поскольку этот формат используется для описания конфигураций и свойств проекта. Опыт работы с YAML не является обязательным, но он поможет вам быстрее освоиться.

YAML отличается простотой и читаемостью, поэтому даже если вы никогда с ним не работали, вы сможете быстро его освоить. Мы рассмотрим основы YAML в этой книге, чтобы помочь вам начать.

Оценка опыта: 2/5. Опыт работы с YAML полезен, но базовые знания можно быстро получить даже без предварительного опыта.

Навык #4: Python

dbt в первую очередь ориентирован на SQL, но также поддерживает работу с Python. Это не обязательный навык для работы с dbt, но он может быть полезным в определенных сценариях.

Поддержка Python в dbt позволяет создавать пользовательские скрипты и плагины, которые дополняют возможности SQL. Однако dbt Labs уточняют, что Python не предназначен для замены SQL, а лишь закрывает его пробелы.

Мы не будем обучать Python в этой книге, но рассмотрим, как создавать модели Python в dbt и использовать их в некоторых сценариях (глава 4).

Оценка опыта: 1/5 для большинства пользователей. Если вы знаете, что вам потребуется Python, эта оценка будет выше.

Навык #5: Моделирование данных

Знание основ моделирования данных и наличие плана — важный навык для работы с dbt. Ранее в этой главе мы упоминали, что многие пользователи dbt пренебрегают этим аспектом, что может привести к проблемам.

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

Оценка опыта: 1/5, если в команде есть опытные специалисты. 4/5, если вы сами проектируете и внедряете модели.

Навык #6: Контроль версий (Source Control)

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

В dbt контроль версий используется для отслеживания изменений в моделях, данных, снимках (snapshots) и тестах. Это также позволяет откатывать изменения при необходимости.

Если вы используете dbt Cloud, подключение репозитория к проекту будет обязательным шагом.

Оценка опыта: 2/5. Базовые знания контроля версий полезны, и любой опыт в этой области легко переносится на работу с dbt.

Преимущества dbt

Рынок перенасыщен инструментами для управления данными и построения пайплайнов. Так чем же dbt выделяется среди остальных? dbt предлагает ряд преимуществ для задач трансформации данных по сравнению с другими инструментами. Вот некоторые из них, многие из которых мы уже упоминали в этой главе:

Специализация на трансформации данных и аналитике

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

Ориентирован на пользователей SQL

dbt разработан пользователями SQL для пользователей SQL. SQL — широко используемый и хорошо известный язык для работы с данными, что упрощает изучение и использование dbt аналитиками и инженерами данных, даже если они не знакомы с другими языками программирования.

Открытый код и активное сообщество

dbt — инструмент с открытым исходным кодом, за которым стоит сильное сообщество пользователей и разработчиков. Это упрощает поиск помощи и ресурсов для работы с инструментом. Slack-канал dbt, на наш взгляд, является одним из лучших в техническом сообществе.

Совместная работа

dbt предназначен для использования в командной среде и предоставляет функции, такие как контроль версий, документация и тестирование. Это упрощает эффективное взаимодействие аналитиков и инженеров данных в команде.

Гибкость

dbt может работать с различными источниками данных и целевыми базами данных, что делает его хорошим выбором для организаций, которым необходимо интегрировать данные из нескольких систем и источников.

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

Подключение к вашей базе данных

Как упоминалось ранее, dbt не имеет собственного вычислительного ядра и полагается на вычислительные мощности хранилища данных или базы данных, к которым он подключается. Если целевая платформа для dbt не настроена, вы не сможете выполнять никакие задачи. dbt можно настроить для работы с различными SQL-совместимыми базами данных, хранилищами данных, озерами данных, движками запросов и аналитическими платформами. Однако уровень поддержки зависит от конкретного подключения. Все подключения делятся на четыре категории: поддерживаемые dbt Labs, поддерживаемые поставщиками, поддерживаемые сообществом и ещё не реализованные. На рисунке 1-3 показаны текущие поддерживаемые соединители. Обратите внимание, что этот список может измениться, поэтому рекомендуется проверять официальную документацию dbt для получения актуальной информации.

1. Поддерживаемые dbt Labs

Эти адаптеры разрабатываются и поддерживаются dbt Labs и на данный момент являются единственными, которые поддерживаются в dbt Cloud. В текущий список входят: PostgreSQL, Redshift, Snowflake, BigQuery, Apache Spark, Starburst и Trino. Ожидается, что этот список будет расширяться. Если вы планируете использовать dbt Cloud и не видите свою платформу в списке официально поддерживаемых, мы рекомендуем проверить последнюю документацию dbt Labs или обратиться в службу поддержки, чтобы узнать, планируется ли добавление вашего инструмента.

2. Поддерживаемые поставщиками

Эти адаптеры разрабатываются и поддерживаются самими поставщиками продуктов, которые также предоставляют техническую поддержку. Как правило, это стабильные соединители с уже значительным количеством пользователей. Для их использования необходимо работать с dbt Core. На данный момент в этот список входят такие платформы, как: ClickHouse, Databricks, Cloudera Impala, Firebolt, Oracle, Trino, MindsDB, SingleStore, TiDB, Rockset, Starburst, Teradata и другие.

3. Поддерживаемые сообществом

Эти адаптеры создаются и поддерживаются участниками сообщества. Качество и стабильность таких адаптеров могут отличаться, поэтому настоятельно рекомендуется провести тестирование перед использованием их в рабочих процессах. Если вы столкнётесь с проблемами при работе с такими адаптерами, вы можете внести свой вклад, отправив pull request для исправления ошибок. Некоторые адаптеры, созданные сообществом, используются в производственных средах, но с ними следует быть осторожными, так как они могут устаревать или быть нестабильными.

Как только адаптеры, поддерживаемые сообществом, достигают высокого уровня качества, они могут пройти строгую проверку dbt. После этого им присваивается статус «проверенные dbt», что означает их готовность к использованию в производственной среде. Большинство таких адаптеров создаются и поддерживаются поставщиками, но это необязательно. Если вы хотите создать адаптер и получить его сертификацию, обратитесь к официальной документации dbt, где описан этот процесс.

4. Ещё не реализованные адаптеры

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

dbt Cloud vs. dbt Core

Существует два основных способа использования dbt: бесплатная версия с открытым исходным кодом под названием dbt Core и корпоративный продукт dbt Cloud.

dbt Core

dbt Core — это бесплатная версия с открытым исходным кодом, которую можно установить и запускать на собственном компьютере или сервере. Она поддерживает работу с большим количеством источников данных и целевых баз данных, предоставляя множество функций, оптимизированных для задач преобразования данных и аналитики.

Однако стоит отметить, что dbt Core не имеет собственных вычислительных ресурсов. Для планирования и выполнения задач dbt потребуется использовать сторонний сервис. Настройка dbt Core будет рассмотрена в главе 2. На рисунке 1-4 показан пример проекта dbt Core в популярной IDE Visual Studio Code (VS Code).

dbt Cloud

dbt Cloud — это платная облачная версия dbt, которая размещается и поддерживается командой dbt. Она предоставляет те же функции, что и dbt Core, но дополнительно включает несколько компонентов, которые упрощают использование:

• Браузерная IDE (с хостингом вычислительных мощностей)
• Планировщик задач (с хостингом вычислительных мощностей)
• Логирование и оповещения
• Интеграция с GitHub и GitLab
• Хостинг документации
• Только адаптеры, поддерживаемые dbt Labs

Ключевые отличия

Одним из главных отличий между dbt Core и dbt Cloud является способ их развертывания и использования:

• dbt Core устанавливается и запускается локально,
• dbt Cloud работает через веб-интерфейс.

Однако в dbt Cloud разрабатываются новые функции, которые позволят пользователям использовать собственную IDE, например, Visual Studio Code.

Хотя dbt Cloud проще в настройке и использовании, он может быть менее гибким в плане интеграции с другими инструментами или системами. Однако команда dbt Labs активно выпускает новые функции, чтобы улучшить возможности интеграции dbt Cloud с продуктами сторонних разработчиков.

Еще одно различие между dbt Core и dbt Cloud — это модель ценообразования.

• dbt Core является бесплатным продуктом с открытым исходным кодом.
• dbt Cloud — это платный сервис, стоимость которого зависит от числа пользователей.

Ожидается, что бесплатная версия с открытым исходным кодом будет поддерживаться и в будущем, однако ценовая модель dbt Cloud может измениться. Также стоит учитывать, что разрыв между функциональностью dbt Core и dbt Cloud, вероятно, будет увеличиваться, поскольку dbt Labs старается перевести больше пользователей на облачный продукт.

Как выбрать?

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

Структура проекта

Когда вы впервые создаете проект dbt, dbt автоматически генерирует стандартную структуру папок, основанную на их рекомендациях. Каждая из этих папок и файлов имеет свое определенное назначение. Вы можете изменить эту структуру, отредактировав файл dbt_project.yml, но мы настоятельно рекомендуем этого не делать, особенно если вы новичок. Большая часть документации dbt ориентирована на стандартную структуру, и её изменение может вызвать трудности при поиске помощи.

После создания проекта по умолчанию генерируются следующие папки. Каждая из них соответствует определенной функции dbt.

Эти функции мы рассмотрим в последующих разделах:

• analyses
• dbt_packages
• logs
• macros
• models
• seeds
• snapshots
• target
• tests

На рисунке 1-6 представлен пример проекта в dbt Cloud. Однако структура будет практически идентична, если вы используете dbt Core через предпочитаемую IDE, например, VS Code.
Общий обзор

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

Папка №1: Analyses

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

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

Папка №2: dbt_packages

Каждый проект dbt включает файл packages.yml, который используется для добавления других open-source проектов в ваш проект. Эти пакеты могут значительно облегчить вашу работу, позволяя использовать разработки других разработчиков вместо создания всего с нуля.

Это похоже на использование pip для установки пакетов в среде Python. Существуют пакеты, которые содержат макросы (функции) для упрощения сложных преобразований SQL, а также пакеты для определенных наборов данных, которые уже включают модели для работы с ними.

Папка dbt_packages — это место, где эти пакеты материализуются в вашем проекте. Чтобы подключить пакет, нужно добавить его в packages.yml, а затем выполнить команду dbt deps. После этого модели из подключенного пакета станут доступны в вашем проекте.

Мы подробно рассмотрим настройку пакетов в главе 6, но также будем упоминать важные пакеты на протяжении всей книги. Рекомендуем ознакомиться с доступными пакетами через GitHub, Slack-сообщество dbt или на hub.getdbt.com.

Папка №3: Logs

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

Если вы используете dbt Cloud, то, скорее всего, будете работать с результатами через встроенную IDE. Тем не менее, логи также сохраняются в этой папке.

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

Папка №4: Macros

Macros — это участки кода, которые можно повторно использовать в вашем проекте. Они аналогичны функциям в других языках программирования и пишутся с использованием Jinja. На самом деле, Jinja чаще всего используется именно в макросах. Поэтому темы Jinja и макросов объединены в одной главе, которая рассматривается в главе 6.

Папка №5: Models

Папка Models — основное место для выполнения преобразований данных в вашем проекте dbt. Это та часть, где вы будете проводить большую часть времени.

Внутри этой папки вы создаете файлы, содержащие логику для преобразования исходных данных в конечное состояние. Обычно в этой папке создаются несколько подпапок, например, для этапов подготовки (staging), витрин данных (marts) и промежуточных трансформаций (intermediate).

Стратегия организации этой папки важна для эффективной работы. В следующей главе мы обсудим рекомендуемую структуру, а в главе 4 углубимся в детали.

Папка №6: Seeds

Seed — это папка, где хранятся данные, которые загружаются в целевую базу данных перед выполнением моделей dbt.

Эти данные обычно используются для заполнения справочных таблиц или предоставления эталонной информации для аналитики. Они должны быть небольшими, статическими и редко изменяться. Например, файл CSV с кодами стран и их названиями можно хранить в этой папке.

Тема seed-файлов рассматривается подробно в главе 3.

Папка №7: Snapshots

Папка Snapshots предназначена для хранения снимков данных. Это единственный тип преобразований dbt, который выделен в отдельную папку.

Снимки — это копии данных из исходной базы данных на определенный момент времени. Они используются для отслеживания изменений данных и обеспечения актуальности моделей. Снимки напоминают медленно изменяющееся измерение второго типа (Type-2 Slowly Changing Dimension) с полями valid_from и valid_to, что позволяет сохранять историю записей.

Тема снимков рассматривается в главе 5.

Папка №8: Target

Target — это папка, которая выполняет несколько функций, но основные из них:

• Хранение файлов метаданных.
• Хранение скомпилированного SQL.

С каждым выполнением команды dbt создается один или несколько артефактов, которые сохраняются в этой папке. Эти артефакты включают файлы JSON:

• manifest.json: содержит метаданные о конфигурации dbt, связях узлов и документации. Этот файл генерируется dbt автоматически и используется для создания документации и сравнения состояния проекта.
• run_results.json: содержит результаты выполнения команд dbt. Часто используется для создания журналов в базе данных и мониторинга задач.
• catalog.json и index.html: используются для создания сайта документации.

Кроме этих файлов, в папке Target есть два подпапки:

• Compiled: хранит скомпилированные SQL-файлы, где Jinja-код заменен на «чистый» SQL. Эти файлы представляют собой SELECT-запросы без операций DDL или DML.
• Run: здесь хранятся SQL-запросы, отправляемые в платформу данных, включая весь необходимый DDL и DML для создания объектов базы данных.

Важно отметить, что папка Target не используется для хранения seed-данных или снимков. Она предназначена исключительно для хранения результатов выполнения моделей и скомпилированного SQL.

Папка №9: Tests

Папка Tests используется для хранения тестов. Файлы тестов содержат SQL-запросы, которые проверяют точность и целостность результатов ваших моделей.

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

Эта тема рассматривается в главе 8, где подробно описываются встроенные тесты, кастомные тесты и тесты, входящие в состав open-source пакетов dbt.

Поддерживаемые типы файлов

В предыдущем разделе мы обсудили стандартные папки, создаваемые dbt, но это лишь начало. Чтобы использовать dbt, необходимо создавать файлы в контексте этих папок. dbt поддерживает множество типов файлов, но наиболее распространённые из них:

.sql
Это наиболее распространённое расширение файлов, используемое для хранения SQL-скриптов.

.yml/.yaml
Используется для конфигурационных файлов в формате YAML. В dbt такие файлы определяют структуру вашей модели данных, а также зависимости и преобразования.

.csv
Используется для хранения данных в формате CSV (comma-separated values). dbt может использовать такие файлы как исходные данные (seed) для ваших моделей.

.py
Это расширение для Python-скриптов. dbt позволяет писать на Python для выполнения сложных преобразований данных или расширения функциональности dbt.

.md
Используется для файлов в формате Markdown. В dbt-репозиториях можно включать документацию, а Markdown — удобный формат для создания многоразовых текстовых блоков.

Это основные типы файлов, которые поддерживаются dbt на данный момент. В будущем могут появляться дополнительные возможности работы с другими форматами. Вы можете расширить функциональность dbt Core, написав собственный код или воспользовавшись сторонними библиотеками. Однако это потребует дополнительной настройки.

Для большинства пользователей достаточно будет создавать файлы с расширениями .sql и .yml.

Типы моделей

Работа с моделями в dbt — это основная часть вашего времени. Модели — это SQL-запросы, определённые в файлах с расширением .sql или модели на Python, которые выполняют преобразования данных.

В dbt есть четыре способа создания модели (материализации):

• Table
• View
• Ephemeral
• Incremental

1. Table

Таблицы — это объекты базы данных, в которых данные записываются на диск. Каждая команда dbt полностью пересоздаёт таблицу и перезагружает данные.

2. View

Представления (Views) — это объекты базы данных, которые хранят запрос. При каждом запросе к представлению выполняется SQL-код. Данные не переносятся и не записываются при использовании представлений, поэтому каждое выполнение кода требует пересчёта. В dbt представления являются настройкой по умолчанию.

Для таблиц и представлений объекты пересоздаются заново при каждом запуске dbt. Для представлений это не проблема, но для таблиц означает повторную загрузку всех данных.

3. Ephemeral

Эфемерные модели (Ephemeral) представляют собой CTE (Common Table Expressions). Они не сохраняются в базе данных и доступны только внутри dbt. Используйте их только при необходимости.

Совет: Освойте написание CTE, так как в dbt вы будете использовать их часто. Поскольку dbt позволяет писать только SELECT-запросы, вы не можете использовать временные таблицы или переменные таблиц.

4. Incremental

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

Важно: Хотя вы пишете только SELECT-запросы, dbt компилирует их в команды, необходимые для обновления данных (например, UPSERT или MERGE).

Рекомендации

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

dbt помогает работать проще, а затем развивать проект по мере необходимости.

Снепшоты (Snapshots)

Снепшоты в dbt — это особый тип объектов, который, однако, в некоторой степени схож с материализациями, рассмотренными ранее. Снепшоты материализуются в виде таблицы и применяются, когда требуется отслеживать изменения данных с течением времени. По сути, такие преобразования реализуют Type-2 медленно изменяющееся измерение (Slowly Changing Dimension, SCD).

Это означает, что при обнаружении изменений между исходными данными (source) и целевыми (target), в таблице создаётся новая строка вместо перезаписи существующего значения.

Как видно из структуры проекта, снепшоты хранятся отдельно от других объектов, поскольку обладают уникальными характеристиками. Похожим образом работают инкрементные модели, однако мы не рекомендуем начинать с них, если вы только осваиваете dbt. Использовать снепшоты следует по мере возникновения необходимости. В книге этой теме посвящена Глава 5, где она детально рассматривается.

Выполнение команд dbt

Создание моделей в dbt — это лишь первый шаг. Для их выполнения необходимо запускать команды dbt, которые выполняются через командную строку. Эти команды позволяют строить модели, запускать тесты, генерировать документацию и многое другое.

Ниже приведён обзор всех доступных команд, разделённых на:

• Команды, поддерживаемые как dbt Cloud, так и dbt Core.
• Команды, поддерживаемые только dbt Core.

На данный момент нет команд, поддерживаемых исключительно dbt Cloud.

Команды, поддерживаемые dbt Cloud и dbt Core

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

dbt build
Строит и деплоит модели для преобразования данных. При выполнении dbt build запускаются модели, тесты, снепшоты и загрузка исходных данных (seed) одной командой.

dbt deps
Загружает указанные версии пакетов из файла packages.yml.

dbt test
Выполняет тесты для проверки точности и надёжности моделей и данных. Тесты определяются в SQL-файлах, размещённых в папке test проекта.

dbt run-operation
Выполняет макрос.

dbt snapshot
Создаёт снепшот исходных данных. Эти данные позволяют dbt отслеживать изменения данных источника с течением времени и обеспечивать актуальность данных.

dbt seed
Загружает исходные данные (seed) в целевую базу данных. Seed-данные — это эталонные данные, загружаемые до построения моделей. Обычно используются для таблиц справочников или аналитических ссылок.

dbt show
Позволяет просмотреть результаты модели, теста, анализа или SQL-запроса непосредственно в терминале.

dbt source freshness
Проверяет актуальность исходных таблиц на основе настроек в файле sources.yml.

Команды dbt Core

Ниже приведён список команд, поддерживаемых исключительно в dbt Core:

dbt clean
Используется для очистки папки target и директории проекта dbt_project. Полезно для подготовки к новому сбору проекта с чистого листа.

dbt debug
Тестирует подключение к базе данных и предоставляет информацию для устранения неполадок.

dbt init
Инициализирует новый проект dbt в среде dbt Core.

dbt list
Показывает список всех ресурсов, определённых в вашем проекте.

dbt parse
Анализирует и проверяет содержимое проекта. Если в проекте есть ошибки синтаксиса, команда завершится с ошибкой.

dbt docs generate
Генерирует документацию для вашего dbt-проекта. Результат — набор HTML-файлов, содержащих информацию о моделях, включая их структуру, зависимости и исходные данные.

dbt docs serve
Локально запускает сервер документации и открывает сайт документации в вашем браузере.

Флаги команд dbt

Каждая команда dbt может быть модифицирована с помощью флагов (аргументов командной строки). Флаги позволяют изменять поведение команд в зависимости от ваших нужд. Например, команда dbt build, которая по умолчанию выполняет все преобразования, тесты и загрузки исходных данных, может быть настроена для выполнения только части этих задач.

Вот некоторые из флагов, используемых с командой dbt build:

--select
Запускает только определённые модели преобразования. После флага нужно указать имя модели. Этот флаг особенно мощный, так как позволяет фильтровать по имени пакета, модели, директории, пути, тегам, конфигурации, типу теста и имени теста.

--exclude
Исключает из выполнения указанные модели. Может использоваться совместно с флагом —select, чтобы построить все модели, кроме указанных.

--resource-type
Позволяет выбрать тип ресурса для выполнения.

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

--selector
Позволяет использовать заранее определённые селекторы ресурсов, сохранённые в YAML-файле.

Дополнительные флаги, которые не связаны с построением ресурсов:

--help
Показывает все доступные команды и аргументы. Полезно, если вы не помните доступные опции.

--vars
Передаёт переменные вашему проекту.

--full-refresh
Принудительно обновляет инкрементные модели. Удаляет существующие таблицы и создаёт их заново.

--fail-fast
Прерывает выполнение dbt, если хотя бы один ресурс не удаётся построить.

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

--target
Указывает целевое подключение к базе данных. Этот флаг используется только в развертываниях dbt Core.

Заключение

Флаги и команды dbt предоставляют широкие возможности для кастомизации и управления процессами в проекте. Чтобы узнать больше о возможностях каждой команды и флага, обратитесь к официальной документации dbt. В книге мы будем часто ссылаться на эти команды и использовать их с наиболее распространёнными опциями.

Чувствительность к регистру

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

Чувствительность в самом dbt

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

SELECT * FROM {{ ref(‘customers’) }};
SELECT * FROM {{ ref(‘Customers’) }};
SELECT * FROM {{ ref(‘cUsToMeRs’) }};

Чувствительность базы данных

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

Чувствительность YAML

Конфигурационные файлы dbt обычно пишутся в формате YAML (.yml), который тоже чувствителен к регистру. Это значит, что вы должны строго соблюдать регистр при написании ключей и значений в YAML-файлах, так как dbt не исправляет ошибки в регистре автоматически.

Чувствительность при выполнении команд dbt

При выполнении команд dbt через командную строку регистр также имеет значение, как и при обработке SQL-скриптов или YAML-файлов. Например:

Правильное написание команды:

dbt run

Неправильное написание команды:

dbt Run # Ошибка
dbt rUn # Ошибка

Все команды выполнения dbt должны быть написаны только в нижнем регистре.

Чувствительность аргументов флагов

Флаги команд dbt (например, --select) также чувствительны к регистру. Это значит, что при указании модели для выполнения вы должны использовать точное имя модели с правильным регистром, как оно указано в вашем проекте.

Пример:
Допустим, в вашем проекте есть модель под названием Customers. Если вы выполните команду:

dbt run --select Customers

То dbt выполнит преобразование для этой модели.

Если же вы введёте модель с неправильным регистром:

dbt run --select customers # Ошибка
dbt run --select CUSTOMERS # Ошибка

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

Полезный совет

Работа с чувствительностью к регистру в dbt может быть неудобной. Мы рекомендуем изначально предполагать, что всё в dbt чувствительно к регистру. Это избавит вас от лишних сложностей и ошибок в будущем.

Что такое YAML?

YAML играет важную роль в работе с dbt, и важно хорошо понимать этот формат. YAML (расшифровывается как YAML Ain’t Markup Language или Yet Another Markup Language, в зависимости от контекста) — это человекочитаемый язык сериализации данных, который часто используется для конфигурационных файлов. Он упрощает задачу по сравнению с более сложными форматами, такими как JSON или XML, благодаря своей простой структуре.

Множество современных инструментов используют YAML в своих фреймворках.

Рассмотрим преимущества YAML:

• Человекочитаемость.
• Однозначность.
• Переносимость между большинством языков программирования.
• Удобство для систем контроля версий.
• Строгие требования к синтаксису, обеспечивающие единообразие.
• Простой и чистый синтаксис.
• Быстрота внедрения.
• Безопасность, исключающая уязвимости, присутствующие в других языках.
• Простота в освоении.

В контексте dbt YAML используется для описания свойств и конфигураций.

Свойства описывают ресурсы проекта: их описания, тесты и источники.
Конфигурации указывают, как dbt строит ресурсы в хранилище данных (например, материализации, расположение объектов, теги).

Основы YAML

Если вы новичок в YAML, полезно понять фундаментальные концепции, такие как массивы и словари.

Массивы YAML

Массивы представляют собой список значений, сгруппированных под одним ключом. Каждый элемент массива начинается с дефиса (-) и пробела. Пример:

fruits:
— apple
— banana
— cherry

Словари YAML

Словари отображают пары ключ-значение и могут быть представлены двумя способами:

Блочное отображение (block mapping):
Ключи и значения разделяются двоеточием, а каждая пара пишется на новой строке:

database:
host: localhost
port: 5432
user: admin

Отображение в строке (flow mapping):
Ключи и значения разделяются запятыми, а пары заключаются в фигурные скобки:

database: {host: localhost, port: 5432, user: admin}

Для большинства YAML-файлов в dbt используется блочное отображение, так как оно считается стандартом для парсинга dbt.
Строгий синтаксис YAML

YAML очень строг к форматированию, что имеет как плюсы, так и минусы:

• Плюс: единый стиль написания упрощает совместную работу.
• Минус: даже небольшая ошибка (например, неправильный отступ) приведёт к сбою парсинга.

Поэтому важно быть внимательным к деталям при работе с YAML.

Роль YAML в dbt

YAML играет ключевую роль в настройке dbt-проектов. В dbt YAML-файлы делятся на два типа:

Конфигурационные файлы

Конфигурационные YAML-файлы управляют тем, как работает dbt.
Основной файл: dbt_project.yml. Этот файл автоматически создаётся при инициализации проекта dbt и располагается в корневой директории.

Он:

• Определяет структуры папок.
• Устанавливает типы материализаций.
• Указывает расположение объектов.
• Задаёт теги.

Вы не можете иметь более одного dbt_project.yml на проект. Если нужно изменить поведение dbt, это делается через этот файл.

Файлы свойств

Файлы свойств описывают различные ресурсы проекта, включая:

• Описания моделей.
• Тесты.
• Источники данных.
• Экспозиции.

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

Совет для новичков

Если вы никогда не работали с YAML, не переживайте — его легко освоить. Работа с YAML в dbt носит повторяющийся характер, так что вскоре вы приобретёте нужные навыки и уверенность. Если вы всё же столкнётесь с трудностями, обратитесь к онлайн-ресурсам и учебникам для более глубокого понимания.

Семантический слой

Семантический слой — это одна из наиболее обсуждаемых функций dbt, которая впервые стала доступна в публичной бета-версии в октябре 2022 года. Целью семантического слоя было дать командам возможность централизованно определять бизнес-метрики на уровне моделирования данных, чтобы они автоматически передавались в инструменты бизнес-аналитики, отчётности и управления данными. Эта идея соответствует современным трендам в отрасли.

Однако при выпуске первой версии семантического слоя возникли ограничения, которые затрудняли его использование:

• Отсутствие навигации по соединениям (join navigation).
• Ограниченная поддержка платформ данных.

В начале 2023 года dbt приобрела компанию Transform, основанную бывшими инженерами Airbnb, которых считают новаторами в области семантического слоя. Эта новость стала значительным шагом вперёд, поскольку Transform уже решила многие из тех сложных задач, которые стояли перед dbt. Сразу после приобретения началась работа над интеграцией решений Transform в функционал семантического слоя dbt, что привело к полной переработке исходной версии.

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

Подготовка к изучению книги

В оставшихся главах книги мы детально рассмотрим описанные компоненты. Для удобства обучения примеры кода будут размещены в открытом репозитории GitHub Apress:
https://github.com/apress/unlocking-dbt.

Наш проект подключён к экземпляру Snowflake, но вы можете использовать любую базу данных, поддерживаемую dbt. Примеры кода достаточно просты и требуют минимальных изменений при работе с другими платформами. Если вы хотите использовать Snowflake, вы можете зарегистрировать пробный аккаунт на сайте Snowflake.com. Альтернативно, проект можно настроить для работы с любым другим адаптером dbt.

Подход к обучению

Цель книги — дать читателю все необходимые знания для успешной работы с dbt. Мы понимаем, что сообщество dbt активно обсуждает различные подходы к его использованию. Эти дебаты часто касаются тем моделирования данных и других аспектов. Мы представляем примеры и рекомендации, основанные на нашем опыте, но это не означает, что это единственно верный путь. dbt — гибкий инструмент, который можно адаптировать под любые потребности.

Кроме того, мы намеренно исключили темы, связанные с продвинутыми сценариями использования, чтобы сделать книгу доступной даже для начинающих. Возможно, в будущем мы выпустим книгу, посвящённую более сложным аспектам работы с dbt.

Резюме

В этой главе мы познакомились с dbt и его ролью в аналитике данных и хранилищах данных. Мы узнали, что dbt — это инструмент с открытым исходным кодом для командной строки, который помогает аналитикам данных и инженерам автоматизировать процесс трансформации, моделирования и тестирования данных в хранилищах данных.

Ключевые возможности dbt:

• Использование SQL и Python для написания моделей трансформации данных.
• Проведение тестов для проверки качества и консистентности данных.
• Эффективность, надёжность и совместная работа благодаря применению лучших практик разработки ПО.

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

Сообщение Перевод главы «Введение в dbt» из книги Unlocking dbt появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.