Построение архитектуры Medallion для данных Bluesky в формате JSON с помощью ClickHouse

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

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

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

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

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

Каждый уровень будет доступен для публичных запросов в нашей демо-среде на sql.clickhouse.com, где читатели смогут самостоятельно изучить и взаимодействовать с результатами. Мы даже подготовили несколько примерных аналитических запросов, чтобы вам было проще начать!

Что такое Bluesky?

Для тех, кто не так активен в социальных сетях, вы могли пропустить недавний взлёт популярности Bluesky, которая в настоящее время набирает почти миллион пользователей в день. Bluesky — это социальная сеть, похожая на X (бывший Twitter), но, в отличие от него, она полностью открыта и децентрализована!

Bluesky, построенная на AT Protocol (ATProto), представляет собой децентрализованную платформу социальных сетей, которая позволяет пользователям самостоятельно размещать свой контент. По умолчанию данные хранятся на Bluesky Personal Data Server (PDS), но пользователи могут выбирать — размещать эти серверы (и свой контент) у себя. Такой подход отражает возврат к принципам раннего Интернета, когда пользователи имели контроль над своим контентом и связями, вместо того чтобы зависеть от централизованных платформ, которые доминируют и владеют пользовательскими данными.

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

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

Чтение данных Bluesky

Чтобы загрузить данные из Bluesky, мы используем недавно выпущенный Jetstream API, который упрощает потребление событий Bluesky, предоставляя потоки, закодированные в формате JSON. В отличие от оригинального firehose, который требует обработки бинарных данных CBOR и файлов CAR, Jetstream снижает сложность, делая процесс доступным для разработчиков, работающих с приложениями в реальном времени. Этот API идеально соответствует нашему случаю использования, позволяя фильтровать и обрабатывать тысячи событий в секунду из постов Bluesky, одновременно решая распространённые проблемы, такие как повреждённые данные и высокий уровень дублирования.

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

Ссылка на полный bash-скрипт.

Вкратце, он выполняет следующее:

• Проверяет GCS bucket на наличие самого последнего файла .csv.gz, извлекает его временную метку (используемую как курсор) и применяет её для возобновления подписки Jetstream с нужной позиции. Это обеспечивает непрерывность данных и минимизирует дублирование.
• Инструмент websocat используется для подключения к Jetstream API, подписки на события и передачи JSON-потока для обработки. Параметр wantedCollections фильтрует нужные события, а cursor обеспечивает пошаговое (инкрементальное) получение данных, например:

websocat -Un --max-messages-rev $MAX_MESSAGES "$WS_URL/subscribe?wantedCollections=app.*&cursor=$cursor" > "$OUTPUT_FILE"

• Входящие данные JSON разбиваются на фрагменты по 500 000 строк, при этом каждый фрагмент представляет собой файл, где последняя временная метка используется в качестве идентификатора файла. Мы используем clickhouse-local для преобразования файла в CSV, затем сжимаем его в .gz и загружаем в GCS bucket с помощью gsutil.
• Скрипт выполняется внутри Docker-контейнера ClickHouse, который запускается каждые 3 минуты с помощью Google Cloud Run Job.

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

Выборка (sampling) данных

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

clickhouse-cloud :) SELECT count()
FROM gcs('https://storage.googleapis.com/pme-internal/bluesky/*.gz', '', '', 'CSVWithNames')

┌────count()─┐
│ 1484500000 │ -- 1.48 billion
└────────────┘

1 row in set. Elapsed: 72.396 sec. Processed 1.48 billion rows, 205.07 GB (20.51 million rows/s., 2.83 GB/s.)
Peak memory usage: 4.85 GiB.

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

SET allow_experimental_json_type = 1

SELECT data::'JSON' AS event
FROM gcs('https://storage.googleapis.com/pme-internal/bluesky/*.gz', '', '', 'CSVWithNames')
LIMIT 1
FORMAT PrettyJSONEachRow

{
  "account": {
    "active": true,
    "did": "did:plc:kjealuouxn3l6v4byxh2fhff",
    "seq": "706717212",
    "time": "2024-11-27T18:00:02.429Z"
  },
  "did": "did:plc:kjealuouxn3l6v4byxh2fhff",
  "kind": "account",
  "time_us": "1732730402720719"
}

1 row in set. Elapsed: 0.233 sec.

Хотя приведённый выше пример даёт некоторое представление о структуре событий, он не полностью отражает сложность, изменчивость и непоследовательность данных. Столбец kind в значительной степени определяет последующую структуру, при этом API передаёт три типа событий: commit, identity и account.

Краткое описание типов событий:

• commit — событие фиксации (commit) указывает на создание, обновление или удаление записи. Этот тип представляет большинство событий и включает посты, лайки и подписки.
• identity — обновление идентичности учётной записи.
• account — обновление состояния учётной записи.

Мы подробнее исследуем эти данные после их загрузки в бронзовый слой (Bronze layer).

Проблемы с данными Bluesky

Данные Bluesky, как они поступают через JetStream API, имеют ряд проблем, включая следующее:

• Повреждённый JSON (Malformed JSON) — время от времени встречаются некорректно сформированные JSON-события. Хотя они редки, такие записи могут нарушить обработку файла. Мы исключаем их с помощью функции isValidJSON, ограничивая загрузку в бронзовый слой (Bronze layer) только теми строками, для которых функция возвращает значение 1.
• Непоследовательная структура (Inconsistent structure) — хотя временная метка сбора данных (поле time_us) присутствует во всех событиях, путь JSON, содержащий время, когда событие произошло, зависит от типа события. Наш рабочий процесс должен извлекать единую согласованную временную метку, основываясь на этих условиях. Простой анализ показывает, что:
  • commit.record.createdAt можно использовать для событий типа commit;
  • identity.time — для событий identity;
  • account.time — для событий account.
• Будущие или некорректные временные метки (Future or invalid timestamps) — некоторые события имеют временные метки из будущего. Например, при выборке событий на момент написания поста 42 тысячи commit-событий имели будущие значения времени. Ещё 4 миллиона commit-событий имели метки времени, относящиеся к периоду до запуска Bluesky как сервиса.
• Повторяющиеся структуры (Repeated structures) — встречаются случаи, когда JSON содержит глубоко рекурсивные структуры. Это приводит к появлению более 1800 уникальных JSON-путей, большинство из которых, вероятно, не имеют существенной ценности для анализа содержимого.
• Дубликаты (Duplicates) — несмотря на использование курсора для поддержания последовательности данных, JetStream API создаёт дубликаты (где содержимое идентично, за исключением временной метки сбора). Удивительно, но такие дубликаты могут появляться в широком диапазоне времени — в некоторых случаях с разницей до 24 часов. Важно отметить, что большинство дубликатов встречаются в интервале около 20 минут.

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

Тип данных JSON в ClickHouse

JSON играет ключевую роль в реализации архитектуры Medallion для данных Bluesky, позволяя системе хранить высокодинамичную и полуструктурированную информацию в бронзовом слое (Bronze layer). Новый тип данных JSON в ClickHouse, представленный в версии 24.8, решил ключевые проблемы, с которыми сталкивались предыдущие реализации.

В отличие от традиционных подходов, которые предполагают единственный тип для каждого JSON-пути (что часто приводит к принудительному приведению типов или их преобразованию), JSON-тип в ClickHouse хранит значения каждого уникального пути и типа в отдельных подколонках (sub-columns).

Такой подход обеспечивает эффективное хранение, сводит к минимуму лишние операции ввода-вывода (I/O) и избегает затрат на приведение типов во время выполнения запроса.

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

Кроме того, благодаря использованию смещений (offsets), ClickHouse гарантирует, что подколонки остаются плотными (dense) — то есть не хранят значения по умолчанию для отсутствующих JSON-путей. Такой подход максимизирует степень сжатия и дополнительно снижает нагрузку на I/O.

Также данный тип данных не страдает от проблемы “взрыва подколонок” (sub-column explosion), возникающей при большом количестве уникальных JSON-путей.
Это особенно важно для данных Bluesky, где при отсутствии фильтрации встречается более 1800 уникальных путей.
При этом это не мешает хранению всех этих путей — новые пути просто сохраняются в общей колонке данных, если превышен лимит (при этом статистика ускоряет выполнение запросов).

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

Бронзовый уровень для необработанных данных (Bronze, сырые данные)

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

Для преобразований мы рекомендуем ограничиться теми, которые можно реализовать с помощью материализованных колонок (Materialized columns), как показано ниже в нашей схеме бронзового слоя:

CREATE TABLE bluesky.bluesky_raw
(
  `data` JSON(SKIP `commit.record.reply.root.record`, SKIP `commit.record.value.value`),
  `_file` LowCardinality(String),
  `kind` LowCardinality(String) MATERIALIZED getSubcolumn(data, 'kind'),
  `scrape_ts` DateTime64(6) MATERIALIZED fromUnixTimestamp64Micro(CAST(getSubcolumn(data, 'time_us'), 'UInt64')),
  `bluesky_ts` DateTime64(6) MATERIALIZED multiIf(getSubcolumn(data, 'kind') = 'commit', parseDateTime64BestEffortOrZero(CAST(getSubcolumn(data, 'commit.record.createdAt'), 'String')), getSubcolumn(data, 'kind') = 'identity', parseDateTime64BestEffortOrZero(CAST(getSubcolumn(data, 'identity.time'), 'String')), getSubcolumn(data, 'kind') = 'account', parseDateTime64BestEffortOrZero(CAST(getSubcolumn(data, 'account.time'), 'String')), toDateTime64(0, 6)),
  `dedup_hash` String MATERIALIZED cityHash64(arrayFilter(p -> ((p.1) != 'time_us'), JSONExtractKeysAndValues(CAST(data, 'String'), 'String')))
)
ENGINE = ReplacingMergeTree
PRIMARY KEY (kind, bluesky_ts)
ORDER BY (kind, bluesky_ts, dedup_hash)

Некоторые важные замечания по этой схеме:

• Тип JSON — колонка data использует новый тип данных JSON и содержит всё событие целиком.
  Мы применяем оператор SKIP, чтобы исключить определённые пути JSON, которые, как показал анализ, были ответственны за повторяющиеся структуры, отмеченные ранее.
• Сохранение метаданных — колонка _file содержит ссылку на файл, из которого была загружена строка.
• Материализованные колонки (Materialized columns) — остальные колонки являются материализованными и вычисляются из колонки data во время вставки:
  • scrape_ts — время, когда событие было доставлено; извлекается из поля JSON time_us.
  • kind — тип события, как упоминалось ранее.
  • bluesky_ts — выполняет условную логику, извлекая временную метку события на основе значения kind; это решает проблему непоследовательной структуры и обеспечивает единый формат временных меток для всех событий.
  • dedup_hash — содержит хеш события.
• Для вычисления хеша создаётся массив всех JSON-путей и их значений, за исключением time_us (так как это поле отличается у дубликатов), с помощью функции JSONExtractKeysAndValues.
  Затем функция cityHash64 обрабатывает этот массив, создавая уникальный хеш события.
• ReplacingMergeTree — используется движок ReplacingMergeTree, который позволяет устранять дубликаты записей, имеющих одинаковые значения ключей сортировки (ORDER BY).
  Дедупликация выполняется асинхронно во время фоновых слияний, которые происходят в неопределённое время и не могут быть напрямую контролируемы — то есть дедупликация осуществляется постепенно (eventual deduplication).

В нашей схеме ключ ORDER BY включает kind и bluesky_ts, что:

• обеспечивает эффективное чтение;
• гарантирует высокую степень сжатия, группируя строки с похожими атрибутами.

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

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

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

Наш выбор обусловлен главным образом желанием минимизировать объём хранимых данных.

Загрузка данных из объектного хранилища (s3, object storage)

Как описано выше, наш конвейер загрузки данных (ingestion pipeline) использует инструмент websocat для потоковой передачи данных из JetStream API, сохраняя события в виде файлов .csv.gz в Google Cloud Storage (GCS).

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

• он позволяет воспроизводить данные (data replay),
• сохраняет оригинальную копию необработанных данных (raw data)
• и имитирует подход, который многие пользователи используют для загрузки данных из объектного хранилища.

Чтобы считать эти файлы из GCS в нашу таблицу бронзового слоя bluesky_raw, мы используем движок таблицы S3Queue (S3Queue table engine). Этот движок считывает данные из объектного хранилища, совместимого с S3, автоматически обрабатывает новые файлы по мере их добавления в бакет и вставляет их в указанную таблицу через материализованное представление (materialized view).

Создание этой таблицы требует небольшой DDL-команды:

CREATE TABLE bluesky.bluesky_queue
(
  `data` Nullable(String)
)
ENGINE = S3Queue('https://storage.googleapis.com/pme-internal/bluesky/*.gz', '', '', 'CSVWithNames')
SETTINGS mode = 'ordered', s3queue_buckets = 30, s3queue_processing_threads_num = 10;

Обратите внимание, что мы указываем GCS-бакет, содержащий сжатые (gzipped) файлы,
и определяем каждую строку как тип String с помощью объявления схемы.

Важно, что мы включаем «ordered mode» через настройку mode = 'ordered'. Это заставляет файлы обрабатываться в лексикографическом порядке, обеспечивая последовательную загрузку данных.

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

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

Наша среда sql.clickhouse.com, в которую мы загружаем данные, состоит из трёх узлов, каждый из которых имеет 60 виртуальных процессорных ядер (vCPUs).

Параметр s3queue_processing_threads_num задаёт количество потоков для обработки файлов на каждом сервере.

Кроме того, при использовании ordered mode вводится дополнительная настройка — s3queue_buckets. Как рекомендуется, мы устанавливаем её как произведение количества реплик (3) на количество потоков обработки (10).

Чтобы потреблять строки из этой очереди, необходимо присоединить инкрементальное материализованное представление (Incremental Materialized View). Это представление читает данные из очереди, выполняет SELECT-запрос над строками, а результат отправляется в таблицу бронзового слоя bluesky_raw.

CREATE MATERIALIZED VIEW bluesky.bluesky_mv TO bluesky.bluesky_raw
(
  `data` Nullable(String)
)
AS SELECT
  data,
  _file
FROM bluesky.bluesky_queue
WHERE isValidJSON(data) = 1

Обратите внимание, что мы выполняем базовую фильтрацию уже на этом уровне:
в таблицу бронзового слоя передаются только строки, где isValidJSON(data) = 1, то есть содержащие валидный JSON.

Также мы добавляем метаданные — колонку _file, чтобы иметь запись о том, из какого gzip-файла была загружена каждая строка.

Потоковая передача Bluesky напрямую в ClickHouse (Streaming)

Обратите внимание, что ClickHouse может напрямую выполнять потоковую загрузку данных с использованием JSON-форматов ввода, как недавно продемонстрировал наш технический директор (CTO) Алексей Миловидов.

Это можно реализовать, объединив тип данных JSON и формат ввода JSON.

Например:

websocat -n "wss://jetstream1.us-east.bsky.network/subscribe?wantedCollections=app.*" | pv -l | split -l 1000 --filter='clickhouse-client --host sql-clickhouse.clickhouse.com --secure --password "" --query "INSERT INTO bluesky.bluesky_raw (data) FORMAT JSONAsObject"'

ClickPipes в ClickHouse Cloud

Хотя механизм таблиц S3Queue позволяет нам выполнять потоковую передачу данных из объектного хранилища в ClickHouse, у него есть определённые ограничения. Помимо того, что он поддерживает только S3-совместимые хранилища, он обеспечивает семантику “по крайней мере один раз” (at-least-once).

Пользователи ClickHouse Cloud могут предпочесть использовать ClickPipes — управляемое решение для загрузки данных, которое обеспечивает семантику “ровно один раз” (exactly-once), поддерживает больше источников (например, Kafka) и разделяет ресурсы загрузки и ресурсы кластера.

Эта технология может быть использована для замены S3Queue в описанной выше архитектуре с минимальной настройкой через пошаговый мастер (guided wizard).

Запросы к бронзовому уровню

Хотя мы не рекомендуем предоставлять доступ к вашей таблице уровня Bronze конечным пользователям (downstream consumers), выбранный нами ключ сортировки (ordering key) позволяет эффективно исследовать данные, выявлять дополнительные проблемы с их качеством или, при необходимости, повторно воспроизводить данные через последующие уровни архитектуры.

Мы отмечали, что во время слияния (merge) движок ReplacingMergeTree определяет дубликаты строк, используя значения столбцов, указанных в ORDER BY, как уникальный идентификатор, и сохраняет только последнюю версию записи. Однако это обеспечивает лишь постепенную (eventual) корректность — то есть не гарантирует, что все дубликаты будут удалены, поэтому полагаться на это не стоит.

Чтобы гарантировать корректные результаты, пользователям необходимо дополнять фоновое объединение (background merges) операцией удаления дубликатов во время выполнения запроса, что можно сделать с помощью оператора FINAL.
Однако это создаёт дополнительную нагрузку на ресурсы и негативно влияет на производительность запросов, что является ещё одной причиной, по которой мы не советуем предоставлять доступ к Bronze-таблицам потребителям данных.

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

Большинство данных представляют собой commit-события (commit events):

SELECT kind, formatReadableQuantity(count()) AS c
FROM bluesky_raw
GROUP BY kind
FORMAT PrettyCompactMonoBlock
┌─kind─────┬─c──────────────┐
│ commit   │ 614.55 million │
│ account  │ 1.72 million   │
│ identity │ 1.70 million   │
└──────────┴────────────────┘

3 rows in set. Elapsed: 0.124 sec. Processed 617.97 million rows, 617.97 MB (5.00 billion rows/s., 5.00 GB/s.)
Peak memory usage: 139.03 MiB.

Внутри этих commit-событий можно исследовать типы событий с помощью синтаксиса пути JSON (JSON path syntax):

SELECT
  data.commit.collection AS collection,
  count() AS c,
  uniq(data.did) AS users
FROM bluesky_raw
WHERE kind = 'commit'
GROUP BY ALL
ORDER BY c DESC
LIMIT 10
FORMAT PrettyCompactMonoBlock

┌─collection───────────────┬─────────c─┬───users─┐
│ app.bsky.feed.like       │ 705468149 │ 7106516 │
│ app.bsky.graph.follow    │ 406406091 │ 8629730 │
│ app.bsky.feed.post       │ 137946245 │ 4323265 │
│ app.bsky.feed.repost     │  90847077 │ 2811398 │
│ app.bsky.graph.block     │  25277808 │ 1523621 │
│ app.bsky.graph.listitem  │   8464006 │  166002 │
│ app.bsky.actor.profile   │   8168943 │ 4083558 │
│ app.bsky.graph.listblock │  643292   │  216695 │
│ app.bsky.feed.threadgate │  559504   │   94202 │
│ app.bsky.feed.postgate   │  275675   │   38790 │
└──────────────────────────┴───────────┴─────────┘

10 rows in set. Elapsed: 19.923 sec. Processed 1.38 billion rows, 122.00 GB (69.50 million rows/s., 6.12 GB/s.)
Peak memory usage: 1003.91 MiB.

Мы видим, что основная часть событий — это “лайки” и “подписки (follows)”, что вполне ожидаемо.

Серебряный уровень для очищенных данных (Silver Layer)

Слой Silver (Серебряный) представляет собой следующий этап в архитектуре Medallion, преобразуя сырые данные из слоя Bronze (Бронзового) в более согласованную и структурированную форму.

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

Мы знаем, что дубликаты событий имеют одинаковые значения bluesky_ts (и других столбцов), различаясь лишь по scrape_ts, причём последнее значение может быть значительно позже.
Однако ранее мы установили, что большинство дубликатов появляются в пределах 20 минут.
Чтобы гарантировать, что в золотой слой (Gold) не попадут дубликаты, мы вводим понятие конечного окна дедупликации (finite duplication window) в слое Silver.

События будут распределяться по этим окнам дедупликации, которые смещены относительно текущего времени на основе значения bluesky_ts.
Эти «окна» периодически сбрасываются (flushed) в слой Gold, с гарантией, что в каждое окно попадёт только одна копия события.

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

Как мы покажем далее, это можно эффективно реализовать в ClickHouse.

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

Анализ таблицы Bronze показывает, что:

• 90% событий имеют значение bluesky_ts, отличающееся от времени их поступления (извлечённого из имени файла в GCS) не более чем на 20 минут.
  Это возможно, если:
• Обработка 1 миллиона сообщений за один раз не вызывает значительных задержек;
• Время чтения и обработки через S3Queue также незначительно (это можно проверить через системные таблицы);
• Время, извлечённое из имени файла, близко к реальному времени загрузки, что подтверждается запросами к GCS.

Кроме того, более 94% событий имеют разницу между scrape_ts и bluesky_ts меньше 20 минут (в 90% случаев — даже менее 10 секунд).
Это означает, что значение scrape_ts также не отстаёт от времени поступления данных.

Понимая, что события обычно доставляются в течение 20 минут после их bluesky_ts, мы можем надёжно формировать окна дедупликации в слое Silver.
Для этого мы создаём раздел (partition) в ClickHouse для каждого 20-минутного интервала — таким образом, раздел фактически соответствует одному окну.

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

toStartOfInterval(bluesky_ts, toIntervalMinute(20))

Итоговая схема таблицы Silver выглядит следующим образом:

• Мы используем ReplacingMergeTree, но выполняем дедупликацию только внутри каждого раздела, то есть слияние происходит только в пределах окна.
• Для управления объёмом данных применяется TTL, который удаляет строки, старше 1440 секунд (24 часа).

Параметр ttl_only_drop_parts = 1 гарантирует, что части удаляются только тогда, когда все строки в них устарели.

CREATE TABLE bluesky.bluesky_dedup
(
  `data` JSON(SKIP `commit.record.reply.root.record`, SKIP `commit.record.value.value`),
  `kind` LowCardinality(String),
  `scrape_ts` DateTime64(6),
  `bluesky_ts` DateTime64(6),
  `dedup_hash` String
)
ENGINE = ReplacingMergeTree
PARTITION BY toStartOfInterval(bluesky_ts, toIntervalMinute(20))
ORDER BY dedup_hash
TTL toStartOfMinute(bluesky_ts) + toIntervalMinute(1440) SETTINGS ttl_only_drop_parts=1

Так как слишком большое количество разделов может привести к проблемам производительности и ошибкам вроде “Too many parts”, мы ограничиваем таблицу Silver только одними сутками данных (всего 72 окна по 20 минут). Старые данные автоматически удаляются с помощью правил TTL, сохраняя эффективность и стабильность системы.

Инкрементные материализованные представления для фильтрации

При применении фильтрации и правил дедупликации к данным уровня Bronze, пользователи часто сохраняют «негативные совпадения» (то есть записи, не прошедшие фильтры) в отдельной таблице — так называемой Dead-Letter таблице — для последующего анализа.

Так как мы планируем периодически отправлять свежие партиции из слоя Silver в слой Gold, нам нежелательно, чтобы события поступали слишком поздно.
По этой причине, а также чтобы продемонстрировать принцип “dead letter queue”, мы будем отправлять все события из слоя Bronze, у которых разница между scrape_ts и bluesky_ts превышает 20 минут, в очередь “dead letter”.

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

Для реализации этого подхода мы используем две инкрементные материализованные представления (incremental materialized views).
Каждое из них выполняет SELECT-запрос к строкам, вставленным в таблицу уровня Bronze (bluesky_raw), и отправляет результаты либо:

• в таблицу dead letter queue,
• либо в таблицу Silver (bluesky_dedup).

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

Представление для отправки строк в таблицу Silver:

CREATE MATERIALIZED VIEW bluesky.bluesky_dedup_mv TO bluesky.bluesky_dedup
(
	`data` JSON,
	`kind` LowCardinality(String),
	`scrape_ts` DateTime64(6),
	`bluesky_ts` DateTime64(6),
	`dedup_hash` String
)
AS SELECT
	data,
	kind,
	scrape_ts,
	bluesky_ts,
	dedup_hash
FROM bluesky.bluesky_raw
WHERE abs(timeDiff(scrape_ts, bluesky_ts)) < 1200

Схема таблицы Dead-Letter Queue и связанное с ней материализованное представление:

CREATE TABLE bluesky.bluesky_dlq
(
	`data` JSON(SKIP `commit.record.reply.root.record`, SKIP `commit.record.value.value`),
	`kind` LowCardinality(String),
	`scrape_ts` DateTime64(6),
	`bluesky_ts` DateTime64(6),
	`dedup_hash` String
)
ENGINE = MergeTree
ORDER BY (kind, scrape_ts)

CREATE MATERIALIZED VIEW bluesky.bluesky_dlq_mv TO bluesky.bluesky_dlq
(
	`data` JSON,
	`kind` LowCardinality(String),
	`scrape_ts` DateTime64(6),
	`bluesky_ts` DateTime64(6),
	`dedup_hash` String
)
AS SELECT
	data,
	kind,
	scrape_ts,
	bluesky_ts,
	dedup_hash
FROM bluesky.bluesky_raw
WHERE abs(timeDiff(scrape_ts, bluesky_ts)) >= 1200

Обратите внимание, что для очереди “dead letter” используется обычный движок MergeTree,
так как дедупликация здесь не требуется — эти данные предназначены для анализа проблем и диагностики, а не для основной аналитики.

Отправка данных на золотой уровень (Gold Layer)

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

Мы реализуем этот периодический перенос (flushing) с помощью Refreshable Materialized View.
Такие представления выполняются периодически по таблицам уровня Silver и позволяют выполнять сложные преобразования, включая денормализацию данных перед их записью в таблицы уровня Gold.

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

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

• Запрос выполняется периодически — в нашем случае каждые 20 минут, что смещает нагрузку с пользовательских запросов на уровень загрузки данных.
• Мы обрабатываем только один раздел за одно выполнение. Можно ограничить дедупликацию во время выполнения только этим разделом, установив параметр do_not_merge_across_partitions_select_final=1, что дополнительно оптимизирует запрос и снижает нагрузку.

Для этого требуется определить, какой именно раздел нужно перенести в Gold при каждом выполнении.
Эта логика показана на диаграмме выше, а в кратком виде выглядит так:

• Мы определяем последний раздел в таблице Silver bluesky_dedup с помощью служебного поля _partition_id.
  Из этого значения вычитаем 40 минут, получая раздел, который был создан два окна назад (X — 2) — называем его current_partition.
• В целевой таблице уровня Gold bluesky есть столбец _rmt_partition_id,
  заполняемый refreshable materialized view, где хранится, из какого раздела уровня Silver поступило каждое событие.
  Мы используем это поле, чтобы определить последний успешно перенесённый раздел, прибавляем 20 минут,
  получая раздел, который нужно обработать следующим — next_to_process.

Если next_to_process = 1200, это значит, что таблица bluesky пуста
(0 + 1200 секунд = 1200), и ещё не было ни одной передачи данных.
В этом случае мы используем current_partition и вставляем все события, где _partition_id = current_partition.

Если next_to_process > 1200, значит, переносы уже выполнялись.
Если current_partition >= next_to_process, то мы отстаём не менее чем на 40 минут (2 окна),
и используем значение next_to_process, вставляя все события, где _partition_id = next_to_process.
Если же current_partition < next_to_process, выполняется noop (ничего не происходит) — данные не переносятся.

Эта логика устойчива к сбоям, таким как пропуски выполнения каждые 20 минут, повторные запуски или задержки выполнения. В результате формируется Refreshable Materialized View, в SELECT-запросе которого инкапсулирована описанная выше логика.

CREATE MATERIALIZED VIEW bluesky.blue_sky_dedupe_rmv
REFRESH EVERY 20 MINUTE APPEND TO bluesky.bluesky
(
  `data` JSON(SKIP `commit.record.reply.root.record`, SKIP `commit.record.value.value`),
  `kind` LowCardinality(String),
  `bluesky_ts` DateTime64(6),
  `_rmt_partition_id` LowCardinality(String)
)
AS WITH
  (
          --step 1
        SELECT toUnixTimestamp(subtractMinutes(CAST(_partition_id, 'DateTime'), 40))
        FROM bluesky.bluesky_dedup
        GROUP BY _partition_id
        ORDER BY _partition_id DESC
        LIMIT 1
  ) AS current_partition,
  (
          --step 2
        SELECT toUnixTimestamp(addMinutes(CAST(max(partition_id), 'DateTime'), 20))
        FROM bluesky.latest_partition
  ) AS next_to_process
SELECT
  data,
  kind,
  bluesky_ts,
  _partition_id AS _rmt_partition_id
FROM bluesky.bluesky_dedup
FINAL
--step 3 & 4
WHERE _partition_id = CAST(if(next_to_process = 1200, current_partition, if(current_partition >= next_to_process, next_to_process, 0)), 'String')
SETTINGS do_not_merge_across_partitions_select_final = 1

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

Внимательный читатель заметит, что в шаге 2 и на диаграмме выше наш запрос использует таблицу latest_partition, а не обращается напрямую к _rmt_partition_id в таблице bluesky уровня Gold.
Эта таблица создаётся с помощью инкрементного материализованного представления (incremental materialized view) и служит оптимизацией, которая ускоряет определение следующего раздела для обработки.

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

CREATE MATERIALIZED VIEW bluesky.latest_partition_mv TO bluesky.latest_partition
(
	`partition_id` UInt32
)
AS SELECT max(CAST(_rmt_partition_id, 'UInt32')) AS partition_id
FROM bluesky.bluesky

CREATE TABLE bluesky.latest_partition
(
	`partition_id` SimpleAggregateFunction(max, UInt32)
)
ENGINE = AggregatingMergeTree
ORDER BY tuple()

Золотой уровень для анализа данных (Gold Layer для аналитики)

Указанное выше refreshable materialized view периодически отправляет данные в таблицу уровня Gold — bluesky.

Схема этой таблицы показана ниже:

CREATE TABLE bluesky.bluesky
(
	`data` JSON(SKIP `commit.record.reply.root.record`, SKIP `commit.record.value.value`),
	`kind` LowCardinality(String),
	`bluesky_ts` DateTime64(6),
	`_rmt_partition_id` LowCardinality(String)
)
ENGINE = MergeTree
PARTITION BY toStartOfInterval(bluesky_ts, toIntervalMonth(1))
ORDER BY (kind, bluesky_ts)

Поскольку данные полностью дедуплицированы до момента вставки, мы можем использовать стандартный MergeTree.

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

Таблица разделена по месяцам (partitioned by month) — в первую очередь для удобства управления данными, а также потому, что ожидается, что большинство запросов будут обращаться к самым последним данным.

Обратите внимание: хотя мы по-прежнему используем тип данных JSON на этом уровне,
возможно выполнение дополнительных трансформаций данных на этапе предыдущего
refreshable materialized view — например:

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

Материализованные представления для общих запросов (Для часто запрашиваемых метрик)

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

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

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

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

В качестве примера рассмотрим наш предыдущий запрос, который вычисляет наиболее распространённые типы commit-событий:

SELECT data.commit.collection AS collection, count() AS c, uniq(data.did) AS users
FROM bluesky
WHERE kind = 'commit'
GROUP BY ALL
ORDER BY c DESC
LIMIT 10

┌─collection───────────────┬─────────c─┬───users─┐
│ app.bsky.feed.like       │ 269979403 │ 5270604 │
│ app.bsky.graph.follow    │ 150891706 │ 5631987 │
│ app.bsky.feed.post       │  46886207 │ 3083647 │
│ app.bsky.feed.repost     │  33249341 │ 1956986 │
│ app.bsky.graph.block     │   9789707 │  993578 │
│ app.bsky.graph.listitem  │   3231676 │  102020 │
│ app.bsky.actor.profile   │   1731669 │ 1280895 │
│ app.bsky.graph.listblock │  263667   │  105310 │
│ app.bsky.feed.threadgate │  215715   │   49871 │
│ app.bsky.feed.postgate   │   99625   │   19960 │
└──────────────────────────┴───────────┴─────────┘

10 rows in set. Elapsed: 6.445 sec. Processed 516.53 million rows, 45.50 GB (80.15 million rows/s., 7.06 GB/s.)
Peak memory usage: 986.51 MiB.

Для 500 миллионов событий выполнение этого запроса занимает около 6 секунд.
Чтобы преобразовать его в инкрементное материализованное представление, необходимо подготовить таблицу, которая будет получать результаты инкрементной агрегации:

CREATE TABLE bluesky.top_post_types
(
  `collection` LowCardinality(String),
  `posts` SimpleAggregateFunction(sum, UInt64),
  `users` AggregateFunction(uniq, String)
)
ENGINE = AggregatingMergeTree
ORDER BY collection

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

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

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

CREATE MATERIALIZED VIEW top_post_types_mv TO top_posts_types
AS
SELECT data.commit.collection AS collection, count() AS posts,
  uniqState(CAST(data.did, 'String')) AS users
FROM bluesky
WHERE kind = 'commit'
GROUP BY ALL

When querying this table, we use the -Merge suffix to merge aggregation states.


SELECT collection,
       sum(posts) AS posts,
       uniqMerge(users) AS users
FROM top_post_types
GROUP BY collection
ORDER BY posts DESC
LIMIT 10

10 rows in set. Elapsed: 0.042 sec.

Производительность запроса улучшилась более чем в 150 раз!

Ниже приведена финальная диаграмма архитектуры, показывающая все наши уровни:

Примеры запросов и визуализации на sql.clickhouse.com

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

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

SELECT event, hour_of_day, sum(count) as count
FROM bluesky.events_per_hour_of_day
WHERE event in ['post', 'repost', 'like']
GROUP BY event, hour_of_day
ORDER BY hour_of_day;

72 rows in set. Elapsed: 0.007 sec.

Запрос выполняется за 7 миллисекунд.

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

Ниже приведено соответствующее материализованное представление и целевая таблица, которая заполняется по мере вставки строк в gold-таблицу:

CREATE TABLE bluesky.events_per_hour_of_day
(
    event LowCardinality(String),
    hour_of_day UInt8,
    count SimpleAggregateFunction(sum, UInt64)
)
ENGINE = AggregatingMergeTree
ORDER BY (event, hour_of_day);


CREATE MATERIALIZED VIEW bluesky.events_per_hour_of_day_mv TO bluesky.events_per_hour_of_day
AS SELECT
    extract(data.commit.collection, '\\.([^.]+)

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

Некоторые примеры, с которых можно начать:

• Общее количество событий (Total events)
• Когда пользователи чаще всего используют Bluesky (When do people use BlueSky)
• Самые популярные типы событий (Top event types)
• Топ типов событий по количеству (Top event types by count)
• Топ типов событий по уникальным пользователям (Top event types by unique users)
• Самые залайканные посты (Most liked posts)
• Самые залайканные посты о ClickHouse (Most liked posts about ClickHouse)
• Самые часто reposted посты (Most reposted posts)
• Самые используемые языки (Most used languages)
• Самые залайканные пользователи (Most liked users)
• Самые часто reposted пользователи (Most reposted users)

Заключительные мысли

В этом блоге мы продемонстрировали полностью реализованную архитектуру Medallion, построенную исключительно на ClickHouse, показав, как его мощные возможности позволяют преобразовывать “сырые”, полуструктурированные данные в качественные, готовые к запросам наборы данных.

Через уровни Bronze, Silver и Gold мы решили типичные проблемы, такие как повреждённые данные (malformed data), несогласованность структуры и значительное количество дубликатов.
Благодаря использованию типа данных JSON в ClickHouse, нам удалось эффективно обрабатывать по своей природе полуструктурированные и динамичные данные, при этом сохраняя высокую производительность.

Хотя эта архитектура обеспечивает надёжный и гибкий рабочий процесс, она всё же вносит определённые задержки по мере перемещения данных между слоями.
В нашем решении “окна дедупликации” (deduplication windows) помогли минимизировать эти задержки, однако остаётся компромисс между скоростью доставки данных в реальном времени и качеством данных.
Поэтому архитектура Medallion особенно хорошо подходит для наборов данных с высокой степенью дублирования и менее критичными требованиями к мгновенной доступности данных.

) AS event,
    toHour(bluesky_ts) as hour_of_day,
    count() AS count
FROM bluesky.bluesky
WHERE (kind = 'commit')
GROUP BY event, hour_of_day;

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

Некоторые примеры, с которых можно начать:

• Общее количество событий (Total events)
• Когда пользователи чаще всего используют Bluesky (When do people use BlueSky)
• Самые популярные типы событий (Top event types)
• Топ типов событий по количеству (Top event types by count)
• Топ типов событий по уникальным пользователям (Top event types by unique users)
• Самые залайканные посты (Most liked posts)
• Самые залайканные посты о ClickHouse (Most liked posts about ClickHouse)
• Самые часто reposted посты (Most reposted posts)
• Самые используемые языки (Most used languages)
• Самые залайканные пользователи (Most liked users)
• Самые часто reposted пользователи (Most reposted users)

Заключительные мысли

В этом блоге мы продемонстрировали полностью реализованную архитектуру Medallion, построенную исключительно на ClickHouse, показав, как его мощные возможности позволяют преобразовывать “сырые”, полуструктурированные данные в качественные, готовые к запросам наборы данных.

Через уровни Bronze, Silver и Gold мы решили типичные проблемы, такие как повреждённые данные (malformed data), несогласованность структуры и значительное количество дубликатов.
Благодаря использованию типа данных JSON в ClickHouse, нам удалось эффективно обрабатывать по своей природе полуструктурированные и динамичные данные, при этом сохраняя высокую производительность.

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

В нашем решении “окна дедупликации” (deduplication windows) помогли минимизировать эти задержки, однако остаётся компромисс между скоростью доставки данных в реальном времени и качеством данных.

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

Сообщение Построение архитектуры Medallion для данных Bluesky в формате JSON с помощью ClickHouse появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Построение архитектуры Medallion с использованием ClickHouse

Крупномасштабная обработка данных требует эффективной структуризации, трансформации и анализа наборов данных. Архитектура Medallion — это шаблон проектирования рабочего процесса данных для организации и повышения их качества посредством поэтапных преобразований, который широко используется для управления сложными наборами данных. Обычно она реализуется с помощью инструментов, таких как Spark и Delta Lake, и позволяет систематически очищать «сырой», неструктурированный набор данных до состояния, пригодного для анализа и прикладных приложений.

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

Цель этого поста — показать, как три этапа архитектуры Medallion могут быть теоретически реализованы с помощью ClickHouse.

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

Что такое архитектура Medallion?

Архитектура Medallion — это широко используемый рабочий процесс обработки данных, который организует данные в многоуровневую структуру, где качество данных постепенно улучшается по мере их прохождения через этапы. Хотя она широко применяется в озёрах данных (data lake houses), эту архитектуру также можно использовать в режиме реального времени в хранилищах данных для обеспечения эффективного управления и трансформации данных.

Архитектура включает три слоя (или этапа), каждый из которых выполняет определённые задачи в процессе обработки данных:

Bronze слой

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

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

Silver слой

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

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

Gold слой

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

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

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

Архитектура Medallion с использованием ClickHouse

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

Bronze слой с использованием ClickHouse

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

Основные характеристики Bronze слоя при использовании ClickHouse.

Загрузка данных из источников

Данные могут загружаться в этот слой напрямую через клиенты, ELT-инструменты, такие как Fivetran, или потоки из Kafka с использованием ClickPipes или коннектора Kafka для ClickHouse. В ClickHouse Cloud доступны дополнительные возможности для построчного чтения данных из S3-хранилищ через S3Queue и ClickPipes, поддерживающих более 70 форматов данных (включая сжатые), таких как Parquet и форматы для озёр данных, например Iceberg. Подход с использованием S3 как зоны промежуточного хранения особенно часто применяется при обработке больших полуструктурированных данных с менее согласованной схемой.

Оптимизация для быстрой вставки

Bronze слой, как правило, реализуется с использованием MergeTree, который разработан для эффективной обработки быстрых вставок. Схема таблицы и ключ упорядочивания настраиваются для оптимизации операций вставки, а также для обеспечения высокой производительности чтения в случае необходимости повторной обработки данных (для Silver слоя) или их анализа на предмет проблем с качеством. Учитывая, что этот слой не предназначен для конечных потребителей, мы рекомендуем оптимизировать ключ упорядочивания для эффективного полного сканирования данных, например, использовать ключ, соответствующий порядку чтения — обычно по времени.

Поддержка полуструктурированных данных в формате JSON

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

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

Материализованные колонки для базовой обработки

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

Партиционирование и управление хранением данных

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

Silver слой с использованием ClickHouse

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

Инкрементальные материализованные представления

Silver слой, как правило, заполняется с использованием инкрементальных материализованных представлений, привязанных к таблицам Bronze слоя. Эти представления выполняют запросы на новых блоках данных, добавленных в Bronze слой, применяя фильтрацию, преобразования и нормализацию схемы перед записью результатов в таблицы Silver слоя для сохранения. Такие представления позволяют эффективно и непрерывно преобразовывать данные, а при использовании нескольких представлений пользователи могут создавать разные версии данных, каждая из которых предназначена для определённых таблиц Silver слоя с учётом конкретных задач. Кроме того, некорректные или необрабатываемые строки могут быть перенаправлены в очередь «мертвых писем» (dead letter queue) через отдельные материализованные представления, что позволяет их проверить и, возможно, восстановить, не засоряя основной набор данных.

Обработка дублирования и CDC

Для сценариев, требующих удаления дубликатов или обработки потоков Change Data Capture (CDC), можно использовать движок таблиц ReplacingMergeTree. Ключ упорядочивания этого движка используется для выполнения удаления дубликатов (с уникальными наборами значений, идентифицирующими строку), причём обновления обрабатываются как версионные вставки — это особенно полезно в сценариях CDC. Обратите внимание, что ReplacingMergeTree выполняет удаление дубликатов во время слияния данных, поэтому он обеспечивает только возможную согласованность, требуя использования оператора FINAL при запросах, чтобы гарантировать отсутствие дубликатов в результатах. В общем случае мы рекомендуем конечным приложениям осторожно обращаться к этому слою, так как использование FINAL может значительно увеличить время выполнения запросов.

Партиционирование и управление хранением данных

Аналогично Bronze слою, таблицы Silver слоя могут быть разделены на партиции для оптимизации производительности запросов и управления данными с использованием TTL. Партиционирование также может улучшить производительность при чтении из таблиц ReplacingMergeTree с использованием FINAL. Мы рекомендуем следовать лучшим практикам, таким как оптимизация операций слияния, чтобы поддерживать высокую производительность. Так как этот слой не является долгосрочным архивом и может не использоваться в качестве источника для последующих этапов, данные могут храниться в этом слое более короткий период, чем в Bronze и Gold слоях, с более короткими интервалами партиционирования.

Gold слой с использованием ClickHouse

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

Обновляемые материализованные представления

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

Проектирование таблиц для конечных приложений

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

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

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

Наше демонстрационное приложение ClickPy активно использует материализованные представления для предоставления возможностей визуализации и фильтрации данных по набору Python PYPI, содержащему триллион строк. Подробности доступны в репозитории ClickPy на GitHub.

Полная архитектура Medallion с использованием ClickHouse

Объединив все описанные выше этапы, мы получаем полную архитектуру Medallion, реализованную с помощью ClickHouse:

Эта архитектура Medallion, реализованная на основе ClickHouse, предлагает структурированный подход к управлению конвейерами данных через каскадные преобразования. Благодаря поддержке более чем 70 форматов файлов, сырые данные могут быть непосредственно загружены в Bronze слой с использованием функций s3Queue или ClickPipe (в ClickHouse Cloud), после чего они инкрементально очищаются и обогащаются в Silver слое, а затем подготавливаются в Gold слое для оптимального использования в приложениях и аналитике. Используя таблицы MergeTree ClickHouse, материализованные представления (инкрементальные/обновляемые) и поддержку различных форматов файлов, эта архитектура позволяет организовать процесс загрузки, преобразования и доставки данных без необходимости использования сторонних инструментов.

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

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

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

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

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

Заключительные мысли и вывод

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

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

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

Сообщение Создание архитектуры Medallion с помощью ClickHouse появились сначала на 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.