Москва: проверенные б/у ноутбуки с гарантией и проверкой перед оплатой
+7 906 722-94-45

Главная → Статьи → Слои хранилища данных: ODS, DWH и витрины

Слои хранилища данных: от сырых данных к витринам

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

Прямой ответ

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

Слой Содержание Задача
Сырой (raw, ODS) Данные в том виде, в каком получены Восстановимость и аудит
Интегрированный (DWH) Очищенные и согласованные данные Единая модель для всех потребителей
Витрины (marts) Данные под конкретную задачу Скорость и простота запросов

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

-- Сырой слой: данные как получены
CREATE TABLE raw.orders (
    payload      jsonb NOT NULL,
    received_at  timestamptz NOT NULL DEFAULT now(),
    source       text NOT NULL,
    batch_id     text NOT NULL
);

-- Интегрированный слой: единая модель
CREATE TABLE dwh.orders (
    order_id     bigint PRIMARY KEY,
    customer_id  bigint NOT NULL,
    amount_minor bigint NOT NULL,
    currency     char(3) NOT NULL,
    created_at   timestamptz NOT NULL,
    updated_at   timestamptz NOT NULL
);

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

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

Зачем разделять слои и когда это избыточно

Разделение слоёв решает три задачи, и каждая проверяется отдельно.

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

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

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

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

Три признака избыточного разделения.

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

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

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

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

Альтернативная схема разделения — медальонная архитектура с тремя уровнями обработки; о ней — в статье про medallion-архитектуру.

Практика: построение слоёв хранилища

1. Сохраняйте исходные данные без изменений. Сырой слой позволяет повторить преобразование после исправления ошибки.

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

3. Стройте витрину под конкретные запросы. Универсальная витрина не даёт выигрыша в скорости, поскольку не соответствует ни одному запросу.

4. Фиксируйте происхождение данных. Ссылка на источник и партию загрузки позволяет разобрать расхождение; о происхождении — в статье про lineage.

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

6. Оценивайте стоимость хранения каждого слоя. Срок хранения сырых данных определяется требованием к восстановимости.

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

Рекомендации:

  1. Различайте слой и физическое хранилище. Слои могут размещаться в одной базе в разных схемах либо в разных системах.
  2. Учитывайте задержку между слоями. Данные проходят слои последовательно, поэтому доступность витрины отстаёт от поступления в источник.
  3. Проверяйте, что каждый слой используется. Неиспользуемый слой занимает место и требует сопровождения без пользы.
  4. Документируйте назначение каждого слоя. Правило, какие преобразования выполняются на каком слое, фиксируется.
  5. Начинайте с минимального числа слоёв. Добавление слоя оправдано появлением потребности, а не заранее.

Практический сценарий: ошибка преобразования обнаружена через месяц

Контекст: показатель в отчёте оказался заниженным за период в месяц. Исправление потребовало пересчёта.

  1. Диагностика. Преобразование неправильно обрабатывало отменённые заказы: они включались в показатель. Ошибка обнаружена при сверке с учётной системой за прошедший период.
  2. Причина отсутствия быстрой корректировки. Промежуточные данные не сохранялись, поэтому пересчёт требовал повторного получения данных из источника за весь период. Источник хранил изменения только за две недели, поэтому часть периода восстановить не удалось.
  3. Действия. (а) Добавили сырой слой, сохраняющий полученные данные без изменений вместе с идентификатором партии; (б) вынесли преобразование в отдельный шаг, читающий сырой слой, чтобы повторное выполнение не требовало обращения к источнику; (в) установили срок хранения сырых данных, покрывающий период сверки; (г) добавили проверку согласованности с учётной системой как регулярный контроль; (д) выполнили пересчёт доступной части периода и зафиксировали расхождение за недоступную часть.
  4. Результат. Ошибка преобразования исправляется повторным выполнением по сырым данным без обращения к источнику.

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

FAQ

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

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

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

Где выполнять преобразования? В одном слое, чтобы правка показателя не требовала изменения в нескольких местах. Ответственность слоёв разделяется явно.

Источники: dbt, PostgreSQL views, Spark SQL data sources — ссылки в шапке.