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

Этапы загрузки: Staging, Raw Vault, Business Vault

При работе с Data Vault процесс загрузки данных состоит из трёх ключевых этапов: Staging, Raw Vault, и Business Vault. Каждый этап имеет свою роль в обеспечении целостности, производительности и аналитической ценности данных.

1. Staging: Подготовительный этап

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

Характеристики:

  • Данные в Staging хранятся в неизменённом виде.
  • Нет долгосрочного хранения: данные обычно очищаются после обработки.
  • Используется для выполнения начальных проверок качества данных.

Типичные действия на этапе Staging:

  1. Извлечение данных: Получение данных из источников (файлы, базы данных, API).
  2. Стандартизация: Приведение форматов данных к единому виду (например, преобразование дат или кодировок).
  3. Проверка данных: Выявление отсутствующих, дублирующихся или некорректных значений.

Пример:
Источник передаёт данные о пассажирах:

PassengerID Name DateOfBirth SourceSystem LoadDate
C001 John Smith 1980-01-01 CRM 2025-01-01

2. Raw Vault: Хранилище данных в исходном виде

Цель:
Raw Vault – это центральное хранилище, в котором данные из источников сохраняются в неизменённой форме с добавлением ключей Data Vault и других технических атрибутов.

Характеристики:

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

Действия на этапе Raw Vault:

  1. Создание хабов: Генерация уникальных surrogate keys для бизнес-ключей.
  2. Создание линков: Определение связей между хабами.
  3. Создание сателлитов: Сохранение дополнительных атрибутов и исторических изменений.

Пример:
Загрузка пассажира в Hub_Passengers:

HubPassengerKey PassengerID LoadDate SourceSystem
1 C001 2025-01-01 CRM

Загрузка имени и даты рождения в Sat_PassengerDetails:

HubPassengerKey Name DateOfBirth LoadDate SourceSystem
1 John Smith 1980-01-01 2025-01-01 CRM

3. Business Vault: Хранилище данных для аналитики

Цель:
Business Vault расширяет Raw Vault, добавляя бизнес-логику, агрегаты и дополнительные расчёты, чтобы подготовить данные для аналитики.

Характеристики:

  • Данные обрабатываются и обогащаются на основе бизнес-правил.
  • Сохраняются все промежуточные результаты для прозрачности.
  • Поддерживается traceability (возможность отследить происхождение данных).

Действия на этапе Business Vault:

  1. Обогащение данных: Расчёт KPI, объединение данных из разных источников.
  2. Создание Point-in-Time таблиц: Упрощение доступа к данным на заданный момент времени.
  3. Агрегация: Построение мостовых таблиц или сателлитов с агрегированными значениями.

Пример:
Рассчитаем общее количество перелётов пассажира:

HubPassengerKey TotalFlights CalculationDate LoadDate
1 5 2025-01 2025-02-01

Преимущества трёхэтапной загрузки

  1. Гибкость:
    Чёткое разделение этапов позволяет адаптировать модель к изменениям источников или бизнес-требований.

  2. Целостность:
    История данных сохраняется на уровне Raw Vault, что исключает потерю информации.

  3. Прозрачность:
    Каждый этап предоставляет данные в формате, подходящем для своей цели:

    • Staging – для проверки и подготовки.
    • Raw Vault – для хранения и интеграции.
    • Business Vault – для аналитики и отчётов.

Заключение

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

Основные этапы процесса

1. Извлечение данных (Extract)

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

  • Цель: получить данные в максимально сыром виде, сохранив все атрибуты.
  • Пример инструментов: Apache NiFi, SSIS, Talend.

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

  • Извлекайте данные в исходной кодировке и формате.
  • Сохраняйте все первичные бизнес-ключи и технические атрибуты (например, метки времени).

2. Подготовка данных (Load/Transform)

Этот этап можно разделить на два подхода:

  1. ETL (Extract, Transform, Load):
    Данные сначала преобразуются, а затем загружаются в хранилище.

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

  2. ELT (Extract, Load, Transform):
    Данные загружаются в сыром виде в хранилище, а затем преобразуются с помощью SQL или инструментов обработки.

    • Подходит для больших объёмов данных и использования мощностей СУБД.
    • Пример инструментов: dbt, Snowflake, BigQuery.

Процесс загрузки данных в Data Vault:

  • Хабы (Hubs):
    Содержат уникальные бизнес-ключи и минимальный набор атрибутов (например, дату загрузки).
    • При загрузке проверяйте уникальность бизнес-ключа.
    • Генерируйте surrogate key для каждого нового бизнес-ключа.
  • Линки (Links):
    Описывают связи между хабами.
    • Проверяйте соответствие бизнес-ключей в связанных хабах.
    • Генерируйте уникальные surrogate keys для каждой новой связи.
  • Сателлиты (Satellites):
    Хранят атрибуты, связанные с хабами или линками.
    • Загрузка данных осуществляется по логике временной актуальности (Load Date и End Date).
    • Поддерживайте историю изменений для всех атрибутов.

Пример ETL-процесса для Data Vault

Исходные данные:

  • Источник 1 (CRM):
      CustomerID Name Email
      CUST001 John Doe This email address is being protected from spambots. You need JavaScript enabled to view it.
  • Источник 2 (Booking):
      BookingID CustomerID FlightID
      B001 CUST001 F123

Процесс:

  1. Хаб клиентов (Hub_Passengers):

    • Извлекается CustomerID.
    • Генерируется Surrogate Key для каждого нового уникального CustomerID.
    HubKey CustomerID LoadDate
    1 CUST001 2025-01-01

  2. Хаб рейсов (Hub_Flights):

    • Извлекается FlightID из системы бронирования.
    • Генерируется Surrogate Key для каждого уникального FlightID.
    HubKey FlightID LoadDate
    101 F123 2025-01-02

  3. Линк (Link_PassengerFlights):

    • Создаётся связь между CustomerID и FlightID через их surrogate keys.
    LinkKey HubPassengerKey HubFlightKey LoadDate
    1001 1 101 2025-01-02

  4. Сателлит клиента (Sat_PassengerDetails):

    • Загружаются атрибуты клиента (Name, Email).
    • Ведётся история изменений.
    HubPassengerKey Name Email LoadDate EndDate
    1 John Doe This email address is being protected from spambots. You need JavaScript enabled to view it. 2025-01-01 NULL

почему в Link_PassengerFlights нельзя использовать BookingID из Источника 2 (Booking)

Использование BookingID из источника данных в качестве ключа для связи в Link_PassengerFlights противоречит основным принципам Data Vault. Вот почему это не рекомендуется:

1. Недолговечность бизнес-ключей

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

  • Изменяться со временем (например, при миграции системы или изменении логики идентификации).
  • Быть удалены или модифицированы в исходной системе.

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

2. Возможные конфликты между источниками

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

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

В таких случаях связь на основе BookingID будет некорректной.

3. Принципы Data Vault: использование surrogate keys

Data Vault использует surrogate keys (замещающие ключи) для всех хабов и линков, чтобы:

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

В вашем примере для связи в Link_PassengerFlights используются surrogate keys:

  • HubPassengerKey (генерируется в Hub_Passengers).
  • HubFlightKey (генерируется в Hub_Flights).

4. Сохранение BookingID в сателлите

Хотя BookingID не используется для создания связи, его можно сохранить в сателлите, связанном с Link_PassengerFlights, например:

LinkKey BookingID LoadDate EndDate
1001 B001 2025-01-02 NULL

Это позволяет:

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

5. Масштабируемость и унификация модели

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

Резюме

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

Рекомендации для успешной загрузки

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

Заключение

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