ГЛАВА 5 – Intermediate Моделирование Data Vault

Вспомним про структуру Data Vault и ключевые термины

Этот раздел не является частью книги, он содержит краткую выдержку по структуре Data Vault (для того, чтобы освежить в памяти структуру DV и основные термины).

Структура Data Vault

• Raw Data Vault — это сырой слой данных, где хранятся исходные данные:
  • HUB — таблица, содержащая связку бизнес-ключа сущности и суррогатного ключа хранилища
  • LINK — таблица связей сущностей по суррогатным ключам
  • SAT — таблица атрибутов сущности
• Business Vault — содержит бизнес-правила и преобразования, применяемые к исходным данным:
  • SAL — таблицы унификации ключей сущности
  • PIT — таблица расчета полной истории сущности (опционально)
  • Bridge/Calculation tables — таблицы с любыми видами расчетов
• Information Mart / Data Mart — это аналитический слой данных. Он предназначен для построения отчётов и визуализации данных для пользователей.
• Генерация ключей
  • Sequence — надежно и синхронно
  • Hash — коллизии и ассинхрон (шанс коллизии у md5 50% на 2^64 записей). Используем hash, если у вас нет явных требований на 100% точность в DWH. А если они есть, переубеждаем тех, кто их поставил.

Пример связей между таблицами:

Презентация с конференции SmartData 2024 Data Vault.

Переводы 1-4 глав книги по Data Vault 2.0:

• Перевод 1 Главы — Введение в хранилища данных
• Перевод 2 Главы — Масштабируемая архитектура хранилища данных
• Перевод 3 Главы — Методология Data Vault 2.0
• Перевод 4 Главы — Моделирование Data Vault 2.0 — Что такое Hub / Link / Satellite?

Аннотация к главе 5

В этой главе рассматриваются более сложные сущности Data Vault. Они расширяют базовые сущности. Здесь будут затронуты различные специальные типы спутников (Satellite), включая:

• перегруженные спутники (Overloaded Satellites),
• мультиактивные спутники (Multi-Active Satellites),
• спутники отслеживания статуса (Status-Tracking Satellites),
• спутники актуальности (Effectivity Satellites),
• спутники отслеживания записей (Record Tracking Satellites) и
• вычисляемые спутники (Computed Satellites).

Также рассматриваются расширенные сущности связей, включая связи между связями (link-to-link), связи «same-as» (same-as links), иерархические связи, неисторические связи (nonhistorized links), недескриптивные связи, вычисляемые агрегатные связи и исследовательские связи.

Для каждой сущности связи будет объяснена техническая или бизнес-причина её добавления в Data Vault.

Ключевые слова:

• хранилище данных
• data vault
• спутники
• сущности связей
• моделирование данных

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

Применение хабов

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

Системы управления взаимоотношениями с клиентами (CRM) являются хорошими примерами таких операционных систем, которые являются основным источником всей информации, связанной с клиентами. Однако на практике бизнес-объекты, такие как клиенты, хранятся в нескольких операционных системах, например, в ритейл-базах данных, e-commerce приложениях, системах управления счетами и так далее. Предприятия пытаются консолидировать эту информацию с помощью концепции, называемой управлением мастер-данными (master data management).

На Рисунке 5.1 показано, что все данные, включая бизнес-ключи, сначала загружаются в слой Data Vault через staging-область. Консолидация происходит при обработке сложных бизнес-правил и построении витрин данных (information marts). Специалисты по хранилищам данных сталкиваются с множественными источниками для одного и того же бизнес-объекта.

Основная проблема при наличии нескольких источников заключается в том, что каждый из них имеет различные возможности по определению бизнес-объекта. Это связано с тем, что в момент создания этих систем в прошлом бизнес выдвигал к ним разные требования. В результате даже типы данных бизнес-ключей могут отличаться: в некоторых случаях буквенно-цифровой номер клиента (например, US4317 для клиента из США), определённый на уровне предприятия, не может быть использован в другой операционной системе, поскольку она не допускает буквенные символы в номере клиента. В таком случае бизнес будет полагаться на какие-либо маппинговые таблицы, которые отображают клиента US4317 из CRM-системы в клиента 132842 в e-commerce приложении.

Рисунок 5.1 Консолидация различных источников в хранилище данных

Поскольку такая ситуация встречается чаще всего, в Data Vault предусмотрено решение. Рекомендуемая практика — загружать все бизнес-ключи, независимо от их конкретного формата, в один общий хаб (в данном случае — хаб клиентов) и создавать специальную связь, называемую same-as link (SAL), чтобы указать бизнес-ключи, которые идентифицируют один и тот же бизнес-объект.

Консолидация бизнес-ключей

Business Vault представляет собой расширение Data Vault RAW и позволяет разработчикам хранилищ данных добавлять вычисляемые данные в слой Data Vault. В этой главе будут представлены вычисляемые агрегатные связи (computed aggregate links), исследовательские связи (exploration links) и вычисляемые спутники (computed satellites) в качестве примеров типов сущностей, входящих в состав Business Vault. Эти типы сущностей моделируются аналогично основным сущностям Data Vault, следуя концепциям моделирования Data Vault, особенно для связей и спутников.

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

Распространённый вариант использования — консолидация бизнес-ключей из различных источников, как показано в Таблицах 5.1 и 5.2 и на Рисунке 5.2.

Таблица 5.1 Хаб «Пассажир»

Таблица 5.2 Same-as-Link для пассажира

Рисунок 5.2 Хаб со структурой Same-as-Link (SAL) для устранения дубликатов бизнес-ключей пассажиров

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

В этом примере исходная система Domestic Flight допускает (и использует) только числовые номера водительских удостоверений, в то время как система International Flight допускает буквенно-цифровые бизнес-ключи. Такая ситуация далека от идеальной, но часто возникает, когда две организации объединяются и продолжают использовать свои старые системы без должной интеграции.

Проблема решается путём добавления к хабу структуры Same-as-Link (SAL), которая указывает, какие номера клиентов соответствуют одному и тому же клиенту. Существует несколько способов вычислить записи для Same-as-Link, и они могут быть результатом алгоритмов дедупликации клиентов, как в данном примере. Соответствующая диаграмма «сущность-связь» (ER-диаграмма) представлена на Рисунке 5.3.

Рисунок 5.3 ER-диаграмма структуры Same-as-Link для устранения дубликатов бизнес-ключей пассажиров (физическая модель)

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

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

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

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

Когда данные трансформируются в Business Vault, всё ещё возможно объединить бизнес-ключи в одном бизнес-хабе, включая структуру Same-as-Link, как показано на Рисунке 5.3. На самом деле, Same-as-Link является сущностью Business Vault, при условии, что информация не извлекается напрямую из системы-источника, а поддерживается вручную или с помощью алгоритмов. Однако если бизнес-ключи объединяются в бизнес-хаб, они не должны пересекаться и должны идентифицировать только один бизнес-объект. Это соответствует стандарту Data Vault 2.0 и может быть достигнуто с помощью префиксов или постфиксов (или форматирующих элементов) для бизнес-ключей, которые не поступают из ведущей системы-источника.

Например, если ведущей системой является CRM-приложение и оно не предоставляет бизнес-ключ для конкретного бизнес-объекта, идентифицирующий бизнес-ключ берётся из вторичной системы-источника и загружается в бизнес-хаб. Примером такой вторичной системы может быть система тикетов (ticketing), где клиент был добавлен, но никогда не синхронизировался и не реплицировался в CRM-приложение. Чтобы указать на этот неидеальный случай и избежать путаницы, бизнес-ключ из ticketing-системы заключают в скобки, например, “(4711)”. Этот бизнес-ключ затем используется в аналитических отчётах, и бизнес-пользователю становится очевидно, что ключ не из CRM-системы и его там не найти. Также возможно добавлять к ключу имя системы-источника, например, “(TCK:4711)”, чтобы пользователь знал, откуда поступил данный ключ.

Запросы к таким двум таблицам в некоторых случаях могут быть довольно сложными. Кроме того, в большинстве случаев бизнесу требуется консолидированный вид клиентских номеров, а не сырые данные — за исключением случаев анализа качества данных. Поэтому целесообразно предоставить консолидированный список, получаемый в результате сложного запроса, в виде нового материализованного хаба. Этот хаб имеет ту же структуру, что и хаб в сыром Data Vault, но содержит другие данные. Таким образом, утверждение из начала этого раздела остаётся верным: в Business Vault нет специальной сущности типа «хаб». Однако логично создавать хабы Business Vault, чтобы предоставлять разные наборы бизнес-ключей и улучшать последующую выборку данных. В этом случае атрибут record source изменяется на “SYSTEM” или “SYS”, чтобы указать, что значение было сгенерировано системой хранилища данных.

Этот пример является типичным случаем, когда бизнес-правила применяются в Business Vault. Хотя бизнес-правила обычно реализуются при загрузке витрин данных, хорошей практикой является их реализация в Business Vault, если они используются более чем в 80% отчётов или если их выполнение требует значительных ресурсов. В данном случае «heavy lifting» означает долгие по времени или сложные бизнес-правила. Таким образом можно избежать повторной реализации бизнес-правил для каждой витрины данных. Это становится особенно важным в случае сложных и ресурсоёмких правил, которые используются в нескольких витринах.

Глава 6, Продвинутое моделирование Data Vault, рассматривает ещё две сущности Business Vault (таблицу PIT и таблицу bridge), которые используются для упрощения запросов к данным из сырого Data Vault и повышения производительности запросов. По этой причине они также называются query assistant tables (вспомогательные таблицы для запросов).

Применение связей (Link Applications)

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

Link-on-link

Один из часто задаваемых вопросов на этапе проектирования Data Vault — возможно ли создание связей, которые ссылаются на другие связи (так называемые структуры link-on-link).
Рассмотрим пример отклонения рейса в авиационной отрасли. Вместо того чтобы прибыть в исходный аэропорт, рейс перенаправляется из-за неблагоприятных погодных условий или инцидента, связанного с безопасностью. Первая идея по моделированию этой ситуации в Data Vault представлена на логической схеме на рисунке 5.4.

Рисунок 5.4 Логическая модель Data Vault с link-on-link структурой

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

Отклонение рейса моделируется как ещё одна связь — LinkDiversionFlight. Она ссылается на исходный рейс в LinkFlight и добавляет ссылку на новый аэропорт прибытия. Хотя эта модель выглядит достаточно эффективной, она вводит нежелательную зависимость между двумя связями. Такая зависимость плохо масштабируется и не обеспечивает должной производительности в условиях высоких объёмов и скоростей обработки данных (big data).

Чем больше подобных link-to-link структур необходимо обработать на уровне СУБД, тем более экспоненциальным становится объём работы для неё. Для обеспечения гибкости и масштабируемости с большими объёмами данных модель необходимо перепроектировать на раннем этапе.

Функциональность, необходимая бизнес-пользователю, поставляется итеративно в рамках отдельных спринтов. Цель — поставлять небольшие инкременты хранилища данных и внедрять эти изменения в продакшн по завершении каждого спринта. Проблема с link-to-link структурами в том, что изменение родительской связи (в данном случае LinkFlight) требует изменения всех зависимых дочерних связей (например, LinkDiversionFlight).

Такие каскадные изменения увеличивают время, необходимое на модификацию компонентов хранилища данных по запросу на изменение, и могут не позволить завершить внедрение запроса в рамках одного спринта. Следовательно, подобные связи следует избегать для сохранения гибкости команды ИТ. Рекомендуемая практика — отказаться от ссылок между связями и реализовать связи независимо (см. рисунок 5.5); в кругах моделирования данных это известно как денормализация.

Рисунок 5.5 Логическая модель с независимыми связями

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

Same-as Links (SAL)

Same-as-Link используются для указания на дублирующиеся бизнес-ключи внутри сущности хаба в Data Vault. Это необходимо в случаях, когда один и тот же бизнес-объект идентифицируется несколькими бизнес-ключами.

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

Таблица 5.3 Хаб клиентов (Customer Hub)

Хаб был загружен из нескольких источников, использующих разные форматы хранения номера клиента. В то время как CRM-система хранит клиентские номера как составной ключ (так называемый “smart-key”), интернет-магазин способен хранить только числовые значения для клиентских номеров. Поэтому бизнес предоставляет таблицу сопоставления между номерами клиентов в CRM-системе и системе интернет-магазина (таблица 5.4).

Таблица 5.4 Сопоставление клиентских номеров между системами-источниками

Имея таблицу соответствия клиентских номеров, можно создать структуру связи, изображённую на рисунке 5.6.

Рисунок 5.6 Физическая модель Same-as-Link для клиентов

Эта связь заполняется записями, подобными тем, что представлены в таблице 5.5.

Таблица 5.5 Same-as-Link для клиентских номеров

С точки зрения загрузки данных, хэш-ключи в столбце CustomerMasterHashKey должны формироваться на основе ключей из ведущей (master) системы — например, CRM. Это позволяет выполнять поиск клиентского номера из системы интернет-магазина (SHOP) путём выборки записи из таблицы Same-as-Link, где Customer1HashKey соответствует номеру из CRM. Таким образом обеспечивается консолидация клиентских идентификаторов при анализе данных.

Иерархические связи (Hierarchical Links)

Иерархические связи используются для моделирования отношений родитель-дочерний в Data Vault. Один из распространённых примеров — иерархия спецификаций (BOM, bill of materials), описывающая, из каких деталей состоит изделие. Например, самолёт состоит из компонентов, представленных на рисунке 5.7.

Рисунок 5.7 Части самолёта

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

Рисунок 5.8 Сечение турбореактивного двигателя

Рисунок 5.9 Структура спецификации (BOM)

Каждый элемент BOM имеет название, номер детали, количество, необходимое для сборки, и указание источника.

Модель Data Vault для представления такой иерархии приведена на рисунке 5.10.

Рисунок 5.10 Логическая модель иерархической связи

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

Таким образом, иерархическая связь — это просто применение стандартной связи (link) в Data Vault. Она не нарушает модель и не требует особых правил.

Неисторические связи (Nonhistorized Links)

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

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

Примеры:

• Транзакции продаж
• Поток данных с камер видеонаблюдения (CCTV)
• Сенсорные данные от IoT-устройств

Видео или изображения, поступающие в Data Vault, не будут обновляться — они просто фиксируются как есть. Поэтому термин «транзакционная» связь заменён на неисторическая.

Рисунок 5.11 Логическая модель неисторической связи

Символ аналогичен стандартной связи, за исключением индикатора рядом с иконкой, который ясно показывает, что это неисторическая связь. По историческим причинам индикатором служит буква T, как в слове transactional link (транзакционная связь). Обратите внимание, что невозможно добавлять спутники (satellites) к неисторическим связям в логической модели (хотя существуют варианты добавления спутников в физической реализации, как мы узнаем немного позже в этом разделе). Атрибуты, являющиеся частью транзакции, добавляются непосредственно в неисторическую связь.

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

Рисунок 5.12 Электронный счёт-фактура за авиаперелёт

Транзакция идентифицируется номером счёта-фактуры 0198536 и была выдана 21 января 2014 года. Также указана другая информация, такая как клиент и продавец. Обратите внимание, что невозможно обновить бронирование рейса. Если информация, предоставленная во время бронирования, неверна (например, указан неправильный аэропорт назначения), единственный способ изменить бронирование — заплатить сбор за изменение и приобрести новое бронирование. Старое бронирование будет аннулировано. Поэтому обновление старого счёта-фактуры невозможно без создания нового счёта.

Логическая модель Data Vault на рисунке 5.13 фиксирует транзакцию электронного счёта-фактуры.

Рисунок 5.13 Неисторическая связь (физическая реализация)

Связь LinkInvoice фиксирует основную транзакцию с ссылкой на клиента, ссылкой на продавца и идентификатором транзакции InvoiceNumber. По определению, этот идентификатор транзакции добавляется непосредственно в неисторическую связь. Хэш-ключ неисторической связи создаётся из бизнес-ключей ссылочных хабов и идентификатора транзакции. Спутник SatInvoice содержит все описательные атрибуты, такие как Record Locator и дата выдачи счёта-фактуры (Invoice Issue Date). Обратите внимание, что дата выдачи счёта отличается от даты загрузки записи, и поэтому она должна быть добавлена в модель.

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

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

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

Рисунок 5.14 Альтернатива неисторической связи без спутника (физическая реализация)

Атрибуты InvoiceIssueDate и RecordLocator были перемещены из спутника в связь LinkInvoice. Спутник SatInvoice с рисунка 5.13 был полностью удалён, так как больше не требуется.

Этот вариант не рекомендуется, поскольку он изменяет архитектурный дизайн модели Data Vault путём внесения решений в процесс проектирования. Тем самым он увеличивает сложность модели и расходы на сопровождение. Кроме того, он усложняет автоматическую загрузку неисторических связей. Тем не менее, бывают случаи, когда второй вариант оправдан: если производительность имеет критическое значение, то есть требуется загрузка данных за миллисекунды или быстрее, может потребоваться смоделировать неисторическую связь, как показано на рисунке 5.14. Однако имейте в виду, что чрезмерная ширина таблицы связи может негативно повлиять на оптимизацию производительности. Если данные в одной строке становятся слишком широкими, это снижает количество записей на одну страницу базы данных (по крайней мере, в СУБД с построчной ориентацией, таких как Microsoft SQL Server). Физическая реализация может варьироваться в зависимости от выбранной платформы, и, как следствие, производительность загрузки и запросов к структуре связи может снижаться. Хотя это также может происходить и при использовании первого варианта, в нём можно распределить данные по нескольким спутникам, чтобы сохранить компактный размер строк.

Рисунок 5.15 показывает, что атрибуты транзакции распределены между спутниками. Оба спутника соответствуют определению неисторических спутников, изложенному в этом разделе. Перенос описательных данных из неисторической связи в зависимый спутник следует рассматривать, если количество фиксируемых атрибутов достаточно велико. Проблема в том, что Microsoft SQL Server хранит данные в файловых страницах размером 8 КБ, без возможности изменить этот параметр. Потенциальная ширина связи ограничена этим ограничением по размеру. По этой причине в структуру неисторической связи следует добавлять лишь ограниченное количество описательных полей для поддержания производительности.

Рисунок 5.15 Неисторическая связь с несколькими спутниками (физическая реализация)

Обратите внимание, что Data Vault 2.0 не зависит от используемой системы баз данных. Примеры в этой книге основаны на Microsoft SQL Server, но могут быть легко перенесены в другие системы баз данных.

Непояснённые связи (Nondescriptive Links)

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

На рисунке 5.16 низкоценная связь Interest соединяет хабы Customer и Offering без предоставления дополнительного контекста.

Рисунок 5.16 Low-value link — Низкоценная связь (логическая модель)

Непояснённые связи также используются для хранения одного состояния в многостадийной (multistate) или ролевой (role-playing) связи. Если мы расширим предыдущий пример, мы можем создать другую связь, чтобы смоделировать другое состояние — например, что клиент был выбран для маркетинговой кампании.

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

Рисунок 5.17 Multistate low-value link — Многостадийная низкоценная связь (логическая модель)

Вычисленные агрегатные связи (Computed Aggregate Links)

Этот тип связи Business Vault удаляет один хаб из связи и агрегирует данные по оставшимся отношениям. Например, рассмотрим модель Data Vault, показанную на рисунке 5.18.

Рисунок 5.18 Вычисленная агрегатная связь с вычисленным спутником (логическая модель)

Оригинальная связь LinkFlight соединяет три хаба: HubAirport, HubFlight и HubCarrier. Она обозначает рейс, запланированный авиаперевозчиком между двумя соединяющимися аэропортами с заданным номером рейса. Когда номер рейса удаляется из связи, новая связь LinkService теряет информацию о рейсе, потому что больше не содержит ссылки на HubFlight. Эта связь только указывает, какие перевозчики обслуживают какие аэропортовые соединения. Количество отдельных номеров рейсов агрегируется в атрибут FlightCount в спутнике SatService. И LinkService, и связанный спутник SatService не поступают из исходной системы. Вместо этого данные, хранящиеся в этих сущностях, рассчитываются на основе агрегатных функций.

Поскольку эти данные рассчитаны, а не являются «сырыми», вычисленные агрегатные связи являются частью Business Vault. Сущность не подлежит аудиту, но может быть воссоздана из исходных данных LinkFlight в любой момент времени. В этом смысле вычисленная агрегатная связь является вариантом использования таблицы-моста (bridge table).

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

Рисунок 5.19 Вычисленная агрегатная связь с вычисленным атрибутом в связи (логическая модель)

Эта опция доступна только в том случае, если вычисленная агрегатная связь является сущностью Business Vault, то есть сама связь рассчитывается из сырых данных с использованием бизнес-логики, например, оператора GROUP BY. Если данные связи вычисленной агрегатной связи поступают из исходной системы, сущность связи остаётся в Raw Data Vault (рисунок 5.20).

Рисунок 5.20 Агрегация, вычисленная на связи Raw Data Vault (логическая модель)

В этом случае агрегация, которая по-прежнему рассчитывается из других данных в исходной системе, сохраняется в вычисленных спутниках и прикрепляется к сырой связи. Такая ситуация может возникнуть, если сама связь доступна в исходной системе, но агрегация — нет. В этом случае агрегация основана на других сырых данных и прикрепляется к правильному уровню детализации, которым является LinkService в примере на рисунке 5.20. Таким образом, определяющей характеристикой обеих моделей является источник данных связи: поступают ли они из исходной системы или уже являются рассчитанными. В первом случае данные моделируются как сырая связь с прикреплённым вычисленным спутником, как на рисунке 5.20. Если связь уже рассчитана из сырых данных, например с помощью оператора GROUP BY, сущность связи становится частью Business Vault, как на рисунке 5.18.

Исследовательские связи (Exploration Links)

Исследовательские связи — это вычисленные связи, созданные исключительно по бизнес-причинам. Поэтому они являются частью Business Vault. Хотя связь между двумя хабами отсутствует в исходной системе, бизнес может принять решение создать исследовательскую связь для изучения данных (рисунок 5.21).

Рисунок 5.21 Исследовательские связи (логическая модель)

Три хаба (HubAirplane, HubEngine и HubManufacturer) на рисунке 5.21 соединены друг с другом двумя связями (LinkAirplanePart, LinkManufacturer). Бизнес может принять решение проанализировать связь между этими тремя хабами, добавив LinkAirplanePartsWithManufacturer, которая является денормализованной версией обеих связей. В других случаях бизнес может решить проанализировать связь между двумя хабами, которые соединены только косвенно — в данном случае HubAirplane и HubManufacturer. Получившаяся связь LinkAirplaneWithManufacturer предоставляет такую возможность, как показано на рисунке.

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

Причины создания исследовательских связей включают:

• Определение связей и динамических сетей между бизнес-сущностями (хабами), которых нет в исходной системе
• Представление связей, которые в противном случае были бы только косвенными
• Объединение связей между бизнес-объектами, если один из ссылаемых хабов содержит дублирующиеся записи (см. same-as link)
• Идентификация кластеров схожих записей внутри хабов (опять же, с использованием same-as links)
• Автоматическое выявление шаблонов, например при обнаружении мошенничества

Применение спутников (Satellite Applications)

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

Перегруженные спутники (Overloaded Satellites)

Мы рекомендовали в главе 4, «Моделирование Data Vault 2.0», чтобы для каждого источника данных использовался отдельный спутник, отслеживающий атрибуты из этого источника. В некоторых случаях реализационные специалисты Data Vault пытаются объединить данные из нескольких источников в один спутник. Хотя иногда для этого есть веские причины, такой подход также несёт в себе риски.

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

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

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

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

• Какую из исходных систем следует считать основной, если данные противоречат друг другу (как в таблице 5.6)?
• Есть ли строки, которые замещают другие строки?
• Какая из строк является самой актуальной?
• Первичным ключом этого спутника должна быть комбинация PassengerHashKey и LoadDate. Однако эта комбинация полей в данном спутнике не уникальна. Следует ли включить атрибут RecordSource в первичный ключ, чтобы сделать его допустимым?
• Если некоторые источники данных предоставляют значения NULL или вовсе не предоставляют значения для некоторых атрибутов, как нам с ними поступать?
• Следует ли объединять или сливать данные из источников при загрузке, или оставить их как есть?

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

Мультиактивные спутники (Multi-Active Satellites)

Мультиактивные спутники похожи на перегруженные спутники: они хранят несколько записей на один родительский ключ. Однако эти записи поступают не из разных источников, а из денормализованного источника данных, такого как COBOL copybooks или XML-файлы. Существует множество примеров допустимого использования. Например, у сотрудников может быть неограниченное количество телефонных номеров, как показано на рисунке 5.22.

Рисунок 5.22 Пример мультиактивного спутника

XML-файл слева на рисунке 5.22 представляет сотрудника с рядом телефонных номеров. Структура XML-файла преобразуется в сущность спутника Data Vault справа. Описательный атрибут (телефонный номер) — это атрибут PhoneNumber, который является единственным описательным атрибутом в этом примере. Единственное отличие от предложенной структуры в главе 4 — это PhoneSeq, номер последовательности, который представляет собой индекс, идентифицирующий телефонный номер в левой структуре. Полученные данные спутника представлены в таблице 5.7.

Таблица 5.7 Данные мультиактивного спутника

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

• EmployeeHashKey — хеш-ключу родительского элемента спутника;
• PhoneSeq — позиции телефонного номера в XML-файле;
• и LoadDate — метке времени первого появления данных в исходном файле.

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

Таблица 5.8 Данные мультиактивного спутника с изменённым порядком в источнике

Первые четыре записи (записи №1–4) представляют первый порядок в исходной системе, в то время как последние четыре записи (записи №7–10) представляют порядок тех же, неизменённых записей при второй загрузке пакета. Однако старые записи из первого пакета помечены как удалённые по значению LoadEndDate, которое в этих случаях не равно null (напомним, это означает, что они были заменены).

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

Таблица 5.9 Данные мультиактивного спутника с альтернативным атрибутом последовательности

Таблица показывает, что запись №2 была обновлена записью №5 во втором пакете. Запись №3 была удалена и больше не существует. Поэтому она получила конечную дату (end-dated) в спутнике. Обратите внимание, что описательный атрибут PhoneNumber дублируется в первичном ключе спутника (атрибут PhoneSeq), а не просто перемещается. Это упрощает понимание спутника для следующего пользователя, которому необходимо извлекать описательные атрибуты из спутника для бизнеса.

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

Спутники отслеживания статусов (Status Tracking Satellites)

Спутники отслеживания статусов используются для загрузки журналов аудита или данных из систем фиксации изменений (Change Data Capture, CDC). Эти методы отслеживают информацию об операциях CRUD (также SCRUD) в исходной системе. Информация должна предоставляться исходной системой и включает сведения о создании (C), чтении (R), обновлении (U), удалении (D) и поиске (S) данных в исходной системе. Часто эта информация сохраняется операционной системой каждый раз, когда пользователь выполняет одну из этих операций в приложении. Таблица 5.10 предоставляет пример такой SCRUD-таблицы. Это результат функции CDC и показывает все изменения в исходной таблице.

Таблица 5.10 Таблица фиксации изменений (CDC) для сотрудников

Сообщение Перевод 5 Главы — Intermediate Моделирование Data Vault появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Глава 1 «Введение в хранилища данных»

Аннотация

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

Ключевые слова

• данные
• хранилище данных
• большие данные
• системы поддержки принятия решений
• масштабируемость
• бизнес-аналитика

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

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

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

РИСУНОК 1.1 Иерархия информации

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

Примеры могут выражаться в виде утверждений, таких как «Рейс DL404 прибывает в 08:30 утра» или «LAX находится в Калифорнии, США». Такие факты сами по себе не несут внутреннего смысла, но могут быть легко зафиксированы, переданы и сохранены в электронном виде.

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

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

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

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

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

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

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

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

История хранилищ данных

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

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

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

Системы поддержки принятия решений

Для обеспечения быстрого доступа к информации, необходимой для процессов принятия решений, предприятия внедрили системы поддержки принятия решений (Decision Support Systems, DSS). Такие системы объединяют различные расширяемые и интерактивные ИТ-технологии и инструменты, которые помогают менеджерам в принятии решений путем обработки и анализа данных.

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

Для загрузки данных используются инструменты ETL (extract, transform, load — извлечение, преобразование, загрузка), предназначенные для извлечения, преобразования и загрузки данных из источников в целевые хранилища:

База данных аналитических моделей на Рисунке 1.2 наполняется процессом ETL данными из пяти источников. Затем данные агрегируются либо в процессе ETL (на этапе подготовки данных), либо при выполнении бизнес-пользователем запроса к базе данных. Бизнес-пользователи могут выполнять ad-hoc запросы и другие сложные аналитические запросы к базе данных аналитических моделей. В большинстве случаев данные уже подготовлены для их целей и содержат только релевантную информацию.

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

РИСУНОК 1.2 Система поддержки принятия решений

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

Системы хранилищ данных

Система хранилища данных (Data Warehouse, DWH) — это система поддержки принятия решений, основанная на данных. Она поддерживает процесс принятия решений на стратегическом уровне, а также операционные решения, например, аналитику в реальном времени для выявления мошенничества с кредитными картами или динамические рекомендации товаров и услуг.

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

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

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

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

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

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

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

Среда корпоративного хранилища данных

Корпоративные хранилища данных (Enterprise Data Warehouse, EDW) возникли из обычных хранилищ данных, описанных в предыдущем разделе. Вместо того чтобы сосредотачиваться на одной предметной области для анализа, корпоративное хранилище данных стремится представить все бизнес-данные организации и ее бизнес-правила. Данные в хранилище затем представляются таким образом, чтобы все необходимые предметные области были доступны для бизнес-пользователей.

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

Доступ

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

Несколько предметных областей

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

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

Единая версия истины

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

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

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

Единая версия фактов

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

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

Единая версия фактов также важна с точки зрения аудита и соответствия нормативным требованиям, что будет рассмотрено в разделе 1.2.10. Позже в этой книге мы узнаем, что EDW, основанные на Data Vault, предоставляют обе версии: и единую версию истины, и единую версию фактов.

Критическая важность для бизнеса

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

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

Масштабируемость

Масштабируемость — это способность архитектуры хранилища данных адаптироваться к увеличению объемов данных и росту количества пользовательских запросов, которые необходимо обрабатывать. Архитектура должна быть построена таким образом, чтобы поддерживать добавление новых данных — не только увеличивающихся объемов, но и более сложных данных. Если объем данных превышает возможности оборудования, должна быть возможность распределять хранилище данных между несколькими машинами и полностью использовать возможности добавленного оборудования. Этот концепт называется массово-параллельной обработкой (MPP, Massively Parallel Processing). Если архитектура не является масштабируемой, добавление нового оборудования либо не оказывает никакого эффекта, либо дает лишь минимальное улучшение после достижения определенного уровня расширения.

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

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

Большие данные (Big Data)

Big Data — это не просто «много данных» или «больше данных, чем я могу обработать». Мы определяем Big Data по трем характеристикам:

• Объем (Volume)
• Скорость (Velocity)
• Разнообразие (Variety)

Первая характеристика — это объем данных Volume. Часто под Big Data подразумевают значительно больший объем данных, чем тот, с которым пользователь привык работать. Однако это понятие субъективно: Big Data для одного человека или компании может означать 1 ГБ сырых данных, но это будет считаться малым объемом для того, кто загружает терабайты или даже петабайты данных.

Загрузка данных в режиме реального времени предъявляет особые требования, и, соответственно, определение Big Data в этом случае отличается от определения при загрузке данных ночными пакетами или в режиме, близком к реальному времени (near real-time, когда данные из операционных систем доступны в хранилище данных в течение, как правило, 15 минут).

Определение Big Data также зависит от доступного оборудования хранилища данных.

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

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

Третья характеристика — разнообразие Variety. Big Data часто не имеют единой структуры. Структура данных может изменяться со временем или вообще отсутствовать, как в случае неструктурированных данных (например, текстов, мультимедиа).

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

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

Поскольку объем доступных данных постоянно растет, архитектура хранилища данных должна не только масштабироваться (volume), но и эффективно обрабатывать скорость поступления данных (velocity) и их разнообразие (variety).

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

Это создает дополнительные проблемы для Big Data, поскольку данные постоянно поступают в сеть и выходят из нее. Чтобы их проанализировать, их необходимо собирать, объединять и агрегировать — в некоторых случаях в реальном времени.

Это повышает требования к архитектуре и планированию Big Data и подводит нас к вопросам производительности, которые рассматриваются в следующем разделе.

Проблемы производительности

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

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

Производительность систем хранилищ данных зависит от того, как система управления базами данных (СУБД) хранит данные на диске. Данные сохраняются в страницах фиксированного размера. Например, Microsoft SQL Server выделяет 8 КБ дискового пространства на каждую страницу. Каждая страница содержит несколько записей определенной таблицы. Чем шире таблица (чем больше у нее колонок), тем меньше строк может поместиться на одной странице.

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

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

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

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

• Параллелизацию загрузочных шаблонов – вместо последовательной загрузки таблиц по одной, загружается несколько таблиц одновременно.
• Распределение данных между несколькими узлами – используется в MPP-системах (массово-параллельная обработка), таких как NoSQL-базы данных.

Оба этих метода критически важны для Data Vault 2.0 и повлияли на изменения в моделировании Data Vault по сравнению с первой версией (Data Vault 1.0).

Сложность

Системы хранилищ данных часто сталкиваются с проблемами сложности из-за множества бизнес-требований. Технические сложности возникают в трех областях:

• Проблемы источников данных (sourcing issues).
• Проблемы трансформации данных (transformation issues).
• Проблемы загрузки в целевые системы (target issues).

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

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

• Ограниченная доступность систем-источников.
• Использование межсистемных объединений (joins), фильтрации или агрегации.
• Проблемы с индексами в исходных данных.
• Отсутствие ключей источника или даже полных наборов данных.
• Некачественные или вышедшие за допустимые пределы данные.
• Сложность структуры данных в системе-источнике.
• Нагрузка на CPU, RAM и диск в системе-источнике.
• Блокировки транзакционных записей.

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

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

• Очистка данных.
• Управление качеством данных и их согласование.
• Объединение (joins), консолидация, агрегация и фильтрация.
• Присвоение последовательностей, что часто препятствует параллельной обработке.
• Коррекция типов данных и обработка ошибок.
• Проблемы с сортировкой данных, такие как необходимость в больших кешах, частые переполнения диска и работа с большими ключами.
• Применение бизнес-правил непосредственно при трансформации данных.
• Множественные источники и целевые системы в одном потоке данных.
• Узкие места в трансформации (transformation bottlenecks).

Проблемы загрузки в целевые системы

Эти проблемы возникают при загрузке данных в хранилище и включают:

• Отсутствие оптимизации базы данных.
• Обновление индексов, что может приводить к взаимоблокировкам (deadlocks).
• Одновременное выполнение INSERT, UPDATE и DELETE в одном потоке данных, что замедляет обработку из-за необходимости соблюдать определенный порядок выполнения.
• Загрузка нескольких целевых систем одновременно.
• Широкие таблицы, как обсуждалось в разделе 1.2.8.
• Отсутствие контроля над разбиением данных (partitioning) в целевой системе.

Основная причина проблем

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

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

Аудит и соответствие требованиям

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

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

Однако Inmon приводит аргументы против добавления аудита в хранилище данных:

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

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

• Откуда был извлечен этот конкретный набор данных?
• Когда данные были извлечены?
• Какой процесс отвечал за извлечение данных?
• Где эти данные использовались?

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

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

Чтобы упростить аудит, процессы хранилища данных должны быть простыми и понятными.

Затраты

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

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

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

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

Основные факторы затрат

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

Основные затраты включают:

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

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

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

Снижение затрат за счет гибкости

Бизнес-требования не должны быть встроены в процесс загрузки хранилища данных, их следует переносить на уровень загрузки витрин данных (data marts) — ближе к конечным пользователям.

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

• Обеспечить гибкость команды,
• Контролировать затраты на поддержку и разработку (за счет авто-генерации),
• Быстрее реагировать на изменения бизнес-требований,
• Снизить стоимость производства витрин данных.

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

Другие бизнес-требования

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

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

В таких подходах обычно выделяют четыре фазы:

1. Определение требований к хранилищу данных.
2. Архитектурное планирование и проектирование хранилища данных.
3. Разработка хранилища данных.
4. Тестирование хранилища данных.

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

Изменения в существующих структурах не должны делать недействительными уже хранящиеся данные или используемые приложения. Одним из главных преимуществ гибких методов является способность быстро реагировать на изменения в бизнесе. Более подробно этот вопрос рассматривается в главе 3 — Методология Data Vault 2.0.

Инструменты для работы с данными

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

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

Примером является Microsoft SQL Server 2014, который содержит эти инструменты «из коробки».

Сохранение знаний в команде

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

Решения для этого включают:

• Хорошо документированную систему хранилища данных,
• Легко понятный дизайн,
• Использование BI-решений (бизнес-аналитики) от крупных вендоров.

Например, решения Microsoft широко известны в отрасли и поддерживаются другими вендорами и консалтинговыми компаниями.

Роль Data Vault 2.0

Все вышеперечисленное является основными компонентами Data Vault 2.0 и его инноваций.

DV2.0 охватывает Big Data, NoSQL, производительность, гибкость команд, сложность и множество других вопросов. Он определяет стандарты и передовые практики для моделирования, реализации, методологии и архитектуры хранилищ данных.

Введение в Data Vault 2.0

Data Vault представляет собой систему бизнес-аналитики. Полное название системы Data Vault — Common Foundational Warehouse Architecture. Эта система включает в себя различные аспекты, связанные с проектированием, реализацией и управлением хранилищем данных.

Исторический анализ Data Vault 1.0 показывает, что первая версия была сильно сосредоточена на моделировании (Data Vault Modeling), то есть физических и логических моделях, формирующих сырой корпоративный склад данных.

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

Эти компоненты:

• Data Vault 2.0 Modeling – Изменения модели для повышения производительности и масштабируемости.
• Data Vault 2.0 Methodology – Использование лучших практик Scrum и Agile.
• Data Vault 2.0 Architecture – Интеграция с NoSQL и Big Data-системами.
• Data Vault 2.0 Implementation – Автоматизация на основе шаблонов, генерация на уровне CMMI 5.

Каждый из этих компонентов играет ключевую роль в общем успехе проекта корпоративного хранилища данных. Они сочетаются с известными в отрасли и проверенными временем методами, включая CMMI (Capability Maturity Model Integration), Six Sigma, TQM (Total Quality Management) и PMP (Project Management Professional).

Основные особенности Data Vault 2.0

• Data Vault 2.0 Modeling теперь включает изменения, позволяющие моделям беспрепятственно работать с NoSQL и Big Data-системами.
• Data Vault 2.0 Methodology ориентирована на 2-3-недельные спринты с адаптациями и оптимизациями для повторяющихся задач хранилища данных.
• Data Vault 2.0 Architecture включает NoSQL, потоковую обработку данных в реальном времени и Big Data-системы, работающие с неструктурированными данными.
• Data Vault 2.0 Implementation делает акцент на автоматизацию и шаблонные методы для экономии времени, сокращения ошибок и повышения производительности команды, работающей с хранилищем данных.

Архитектура хранилища данных

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

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

Две типичные архитектуры таких хранилищ будут описаны в следующих разделах.

Типичная двухслойная архитектура

Кимбалл представил широко используемую двухслойную архитектуру.

В этой архитектуре, представленной на Рисунке 1.3, есть только два уровня, которые являются частью самой системы хранилища данных.

Этап загрузки данных

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

Основное назначение промежуточной области:

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

Промежуточная область необходима в случаях, когда:

• Трансформации сложны и не могут выполняться на лету.
• Данные поступают из нескольких источников в разное время.

Этап загрузки в хранилище данных

После загрузки в stage, Кимбалл предлагает перемещение данных в хранилище.
Это хранилище данных построено на основе размерной модели и состоит из витрин данных (data marts), представляющих бизнес-процессы.

Эти витрины объединяются с помощью конформных измерений (conformed dimensions).
Такой подход был впервые предложен Кимбаллом в 1996 году.

Размерная модель Dimensional Modeling

Размерная модель — это де-факто стандарт, который прост в использовании для бизнес-пользователей и аналитических инструментов, таких как OLAP.

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

Мы обсудим размерное моделирование в главе 7 – Dimensional Modeling.

Приложения для доступа к данным используют размерную модель, чтобы:

• Предоставлять пользователям информацию.
• Позволять проводить гибкий (ad-hoc) анализ.

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

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

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

Невозможно повторно использовать существующие ETL-пакеты.

Типичная трехслойная архитектура

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

Рисунок 1.4 Хранилище данных Инмона

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

Описание слоев трехслойной архитектуры

Промежуточная область (Stage Area)

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

Хранилище данных (Data Warehouse / ODS)

• Содержит сырые данные.
• Моделируется в третьей нормальной форме (3NF).
• Интегрирует все данные предприятия, но при этом сохраняет физические таблицы исходных систем.
• Функционирует аналогично большой операционной базе данных.

Размерная модель (Dimensional Model / Data Marts)

• Основана на нормализованных бизнес-данных.
• Бизнес-пользователи могут анализировать данные через предметно-ориентированные витрины данных (data marts).
• Похожая схема использовалась в двухслойной архитектуре.

Преимущества трехслойной архитектуры

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

Недостатки трехслойной архитектуры

• Усложнение построения хранилища данных. Требуется больше ресурсов и времени на обработку данных.
• Проблемы с изменением модели данных. Если многие витрины данных зависят от операционного хранилища (ODS), изменение модели данных может создать дополнительные сложности.

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

Сообщение Перевод 1 Главы — Введение в хранилища данных появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.