ГЛАВА 2. Масштабируемая архитектура хранилища данных

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

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

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

• сложность данных (data complexity)
• сложность запросов (query complexity)
• задержка данных (data latency)
• хранилище данных (data warehouse)
• Data Vault
• архитектура данных (data architecture)

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

Этот подход противоположен стратегии «большого взрыва» (big-bang), при которой вся функциональность разрабатывается в одном крупном процессе и затем развертывается целиком.

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

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

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

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

РИСУНОК 2.1: Кошмар поддержки

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

Измерения масштабируемых архитектур хранилищ данных

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

Нагрузка (Workload)

Корпоративное хранилище данных (Enterprise Data Warehouse, EDW) является «безусловно самым крупным и вычислительно затратным бизнес-приложением» в типичном предприятии. Системы EDW состоят из огромных баз данных, содержащих исторические данные объёмом от нескольких гигабайт до терабайт.

Успешные системы EDW сталкиваются с двумя проблемами, связанными с нагрузкой на систему:

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

Для обеспечения требуемой производительности системы EDW реализуются на крупномасштабных параллельных вычислительных платформах, таких как среды массово-параллельной обработки (Massively Parallel Processing, MPP) или симметричной многопроцессорной обработки (Symmetric Multiprocessing, SMP), а также на кластерах и программном обеспечении для параллельных баз данных. Фактически, большинство средних и крупных хранилищ данных невозможно было бы реализовать без масштабных параллельных аппаратных решений и соответствующего программного обеспечения для параллельных баз данных.

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

Сложность данных (Data Complexity)

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

• Разнообразие данных (Variety of data): сегодня предприятия собирают не только традиционные мастер-данные или транзакционные данные (например, реляционные или мэйнфрейм-данные). Всё больше появляется полуструктурированных данных, таких как электронные письма, электронные формы, файлы HTML и XML, а также неструктурированных данных, включая коллекции документов, данные социальных сетей, изображения, видео и аудиофайлы. Ещё один тип данных — это данные, генерируемые сенсорами и машинами, которые могут требовать специальной обработки. Во многих случаях компании стремятся извлекать структурированную информацию из неструктурированных или полуструктурированных данных, чтобы повысить их бизнес-ценность. Хотя файлы могут иметь структуру, их содержимое может её не иметь. Например, невозможно найти лицо конкретного человека в видео без полной обработки всех кадров и создания метаданных, указывающих, где в содержимом появляются лица.
• Объём данных (Volume of data): скорость, с которой компании генерируют и накапливают новые данные, растёт. Примеры включают контент с веб-сайтов или социальных сетей, коллекции документов и электронных писем, данные веб-журналов и данные, генерируемые машинами. Рост объёмов данных приводит к созданию гораздо более крупных наборов данных, объём которых может достигать сотен терабайт, пета-байтов и даже превышать их.
• Скорость поступления данных (Velocity of data): увеличивается не только разнообразие и объём данных, но и скорость их создания. Один из примеров — финансовые данные с фондовых рынков, таких как биржи. Эти данные генерируются с очень высокой частотой и сразу анализируются для реагирования на изменения рынка. Другие примеры включают данные по транзакциям с банковскими картами для выявления мошенничества, а также данные с датчиков или камер видеонаблюдения (CCTV), которые используются для автоматического анализа видео и изображений в режиме реального времени или почти реального времени.
• Достоверность (надёжность) данных — Veracity (trustworthiness) of data: для уверенности в данных необходимо, чтобы они имели строгий контроль качества, прозрачную историю происхождения (data lineage) и надёжную интеграцию.

Сложность аналитики (Analytical Complexity)

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

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

• Для определения сегментации клиентов и их покупательского поведения бизнесу может потребоваться исторический анализ и отчётность по демографии клиентов и их транзакциям.
• Возможности кросс-продаж можно выявить с помощью анализа корзин покупок (market basket analysis), который показывает, какие товары продаются вместе.
• Для понимания поведения клиентов в онлайн-среде требуется анализ последовательности кликов (click-stream analysis). Это помогает предлагать клиентам дополнительные товары (up-sell) при посещении веб-сайта.

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

Сложность запросов (Query Complexity)

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

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

Многие RDBMS, такие как Microsoft SQL Server, оптимизированы для приложений хранилищ данных, например, с использованием эвристических методов для распознавания шаблонов запросов к звездной схеме, которые SQL-оптимизатор использует для повышения производительности запросов. Microsoft SQL Server также применяет продвинутые методы фильтрации для улучшения производительности запросов, используя такие функции, как оператор bitmap showplan. Однако некоторые из этих функций доступны только при соблюдении определённых правил при написании SQL-запросов (например, использовании условий equi-join только во внутренних соединениях (INNER JOIN)).

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

Доступность (Availability)

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

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

Кроме того, все крупные реляционные СУБД, включая Enterprise-версию Microsoft SQL Server 2014, предлагают множество функций, таких как партиционирование/сегментирование (partitioning) и снимки базы данных (snapshots), которые помогают соответствовать требованиям бизнес-пользователей по доступности. Ещё один вариант — создание фейловер-кластера (fail-over cluster), который обеспечивает резервный сервер в случае аварии.

Безопасность (Security)

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

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

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

Архитектура Data Vault 2.0

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

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

Другие модификации типовой архитектуры из Главы 1 включают:

• Зону стейджинга, которая не хранит исторические данные и не вносит никаких изменений в данные, за исключением проверки ожидаемого типа данных.
• Слой хранилища данных, смоделированный по методологии Data Vault.
• Один или несколько слоёв витрин информации (information mart), которые зависят от слоя хранилища данных.
• Опциональный Metrics Vault, который записывает и фиксирует информацию о времени выполнения.
• Опциональный Business Vault, предназначенный для хранения данных, к которым были применены бизнес-правила. В большинстве случаев бизнес-правила изменяют или трансформируют данные, превращая их в полезную информацию. Это ещё один вид витрины информации.
• Опциональный Operational Vault, который хранит данные, поступающие в хранилище из операционных систем.

Функциональность управляемой BI самообслуживания (Managed Self-Service BI), позволяющая бизнес-пользователям самостоятельно выполнять анализ данных без участия IT, включая возможность обратной записи информации в слой корпоративного хранилища данных.

Все опциональные Vault-ы – Metrics Vault, Business Vault и Operational Vault – являются частью Data Vault и интегрированы в слой хранилища данных.

Референсная архитектура Data Vault 2.0 представлена на Рисунке 2.2. Архитектура Data Vault

 

Архитектура Data Vault 2.0 основана на трёх уровнях:

• Зона стейджинга (staging area), собирающая сырой (raw) данные из источников.
• Слой корпоративного хранилища данных (enterprise data warehouse layer), смоделированный в соответствии с моделью Data Vault 2.0.
• Слой предоставления информации (information delivery layer), содержащий витрины информации (information marts), организованные в звёздные схемы (star schemas) и другие структуры.

Эта архитектура поддерживает пакетную загрузку (batch loading) из источников данных и загрузку в реальном времени (real-time loading) через шину корпоративных сервисов (ESB, Enterprise Service Bus) или другую сервис-ориентированную архитектуру (SOA, Service-Oriented Architecture).

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

Таким образом, NoSQL-база данных может использоваться как стейджинг и загружать данные в реляционный слой Data Vault. Однако возможно и двустороннее взаимодействие между NoSQL и Data Vault с использованием хэшированного бизнес-ключа (hashed business key). В этом случае система становится гибридным решением, а витрины информации получают данные из обеих сред.

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

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

В Data Vault проводится разграничение между жёсткими (hard) и мягкими (soft) бизнес-правилами. Этот вопрос рассмотрен в следующем разделе.

Определение бизнес-правил

В Data Vault 2.0 различают жёсткие (hard) и мягкие (soft) бизнес-правила.

В общем смысле, бизнес-правила модифицируют входящие данные для соответствия требованиям бизнеса.

Жёсткие (hard) бизнес-правила

Жёсткие бизнес-правила – это технические правила, обеспечивающие согласованность доменов данных (data type matching).

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

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

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

Другие примеры жёстких бизнес-правил:

• Нормализация иерархических COBOL-копибуков из мэйнфреймов или XML-структур.
• Выделение системных колонок (например, вычисление технических идентификаторов).

Главное правило: Жёсткие бизнес-правила никогда не изменяют смысл входящих данных – они только определяют способ их хранения.

Мягкие (soft) бизнес-правила

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

Такие правила преобразуют данные или меняют их интерпретацию, например, изменяя уровень детализации (grain).

Примеры мягких бизнес-правил:

• Агрегация данных – например, группировка клиентов по уровню дохода, возрастным группам, сегментам.
• Консолидация данных – объединение данных из нескольких источников.
• Трансформация данных – изменение структуры данных для соответствия бизнес-требованиям.

Таким образом, мягкие бизнес-правила определяют, как данные агрегируются, объединяются и преобразуются, чтобы соответствовать аналитическим задачам бизнеса.

Применение бизнес-правил

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

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

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

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

Рисунок 2.3. Применение жёстких и мягких бизнес-правил в корпоративном хранилище данных Data Vault

Жёсткие бизнес-правила несут определённые риски для ETL-рутин.

---

ETL-рутины (или просто ETL-процессы) — это набор процедур или сценариев, используемых для извлечения (Extract), трансформации (Transform) и загрузки (Load) данных из различных источников в систему хранения данных, такую как хранилище данных (data warehouse) или базу данных.

---

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

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

Для этого необходимо разграничить применение жёстких и мягких бизнес-правил.

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

Это объясняется тем, что слой хранилища данных построен либо по модели звёздной схемы (Kimball), либо нормализован в третьей нормальной форме (3NF).

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

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

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

Проблема изменений бизнес-правил

Однако возникает проблема, если бизнес-правила изменяются.

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

Рассмотрим пример из авиационной отрасли.

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

Каждый номер содержит префикс, указывающий страну регистрации самолёта.

Например:

• Регистрационный номер «D-EBUT» указывает, что самолёт зарегистрирован в Германии (префикс «D»).
• В Германии такие номера являются «умными ключами» (smart keys) – этот концепт подробно рассматривается в Главе 4. Моделирование Data Vault.
• В случае немецкого самолёта «D-EBUT» второй символ номера указывает, что воздушное судно – одномоторное.

В США обычно используется префикс «N».

До 31 декабря 1948 года в США также существовал второй префикс, обозначавший категорию самолёта (см. Таблицу 2.1).

Таблица 2.1. Префиксы категорий самолётов в США до декабря 1948 года

Например, самолет с регистрационным номером N-X-211 зарегистрирован в экспериментальной категории.

Однако FAA решила прекратить использование второго префикса и теперь присваивает номера от 3 (N1A) до 6 символов (N99999), которые не несут никакого дополнительного смысла, за исключением первого префикса, указывающего на страну регистрации.

Фактически, вторая буква теперь всегда является числом от 1 до 9.

Теперь рассмотрим влияние этого изменения на хранилище данных.

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

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

Чтобы обновить бизнес-правило, наиболее простым подходом было бы введение новой категории («Неизвестная категория»), к которой будут отнесены самолеты, если второй символ их регистрационного номера находится в диапазоне от 1 до 9.

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

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

Таким образом, категоризация, приведенная в Таблице 2.1, становится устаревшей.

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

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

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

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

• Как обрабатывать исторические данные в нормализованном хранилище данных?
• Где хранить исторические данные для последующего анализа (если бизнесу это понадобится в будущем)?
• Как анализировать как исторические, так и современные самолеты (это бизнес-решение)?
• Будут ли существовать отдельные измерения (для исторической категории и современных категорий) в одной витрине данных, или потребуется создать отдельные витрины данных для исторических и современных самолетов?
• Какое значение по умолчанию использовать для исторической категории в современных самолетах?
• Какие значения по умолчанию использовать для современных категорий в отношении старых самолетов?

В архитектуре Data Vault 2.0 категоризация воздушного судна загружается в таблицу, называемую спутником (satellite), которая содержит описательные данные (базовые сущности моделирования Data Vault 2.0 подробно рассматриваются в главе 4). Когда логика в исходной системе изменяется – в данном случае формат N-Number – старый спутник закрывается (в него больше не загружаются новые данные). Все новые данные загружаются в новый спутник с обновленной структурой, соответствующей структуре исходных данных. В этом процессе бизнес-правила не применяются. Загружаются все данные.

Поскольку теперь существуют две таблицы – одна с историческими данными, а другая с новыми данными, – становится проще применять бизнес-правила при загрузке данных из Data Vault в информационный витринный слой (information mart). Также легко создать одну информационную витрину для анализа исторических, более старых воздушных судов, и другую – для анализа современных самолетов, построенных после 1948 года. Однако реальное преимущество разделения жестких (hard) и мягких (soft) правил становится очевидным при рассмотрении ETL-джобов, которые нужно адаптировать под новую категоризацию: никаких.

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

Слой промежуточного хранения (Staging Area Layer)

Слой промежуточного хранения используется при пакетной загрузке данных в хранилище данных. Его основная цель – максимально быстро извлечь исходные данные из исходной системы, чтобы уменьшить нагрузку на операционные системы. Кроме того, staging-слой позволяет выполнять SQL-запросы к исходным данным, что может быть невозможно при прямом доступе к плоским файлам, таким как CSV или Excel.

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

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

Промежуточный слой (staging area) состоит из таблиц, которые дублируют структуры исходной системы. Это включает в себя все таблицы и столбцы источника, включая первичные ключи. Однако индексы и внешние ключи, которые используются для обеспечения ссылочной целостности в исходной системе, не дублируются. Кроме того, все столбцы допускают значения NULL, поскольку мы хотим позволить хранилищу данных загружать необработанные данные из исходной системы, включая некорректные данные, которые могут присутствовать в источнике (особенно в плоских файлах). Единственные бизнес-правила, которые применяются к входящим данным, – так называемые жесткие бизнес-правила (hard business rules). Обычной практикой является сохранение оригинальных имен таблиц и столбцов из исходной системы, однако это не является обязательным.

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

• Порядковый номер (sequence number)
• Метку времени (timestamp)
• Источник записи (record source)
• Вычисления хеш-ключей для всех бизнес-ключей и их комбинаций

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

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

Подробное описание этих столбцов представлено в главе 4.

Слой хранилища данных (Data Warehouse Layer)

Второй слой в архитектуре Data Vault 2.0 – это хранилище данных, основное назначение которого – хранение всей исторической, изменяющейся во времени информации. Хранилище данных содержит необработанные данные, не модифицированные никакими бизнес-правилами, кроме жестких бизнес-правил. Таким образом, данные хранятся в той детализации (гранулярности), в которой они предоставляются исходными системами. Данные являются неизменяемыми (nonvolatile), и каждое изменение в исходной системе отслеживается структурой Data Vault. Данные из нескольких исходных систем, а также внутри одной исходной системы, интегрируются с использованием бизнес-ключей, которые обсуждаются в главе 4. В отличие от информационной витрины (information mart), где информация организована по предметным областям, данные в Data Vault структурированы по функциональному принципу.

При пакетной загрузке данные поступают из промежуточного слоя, а при загрузке в реальном времени данные поступают напрямую из корпоративной сервисной шины (Enterprise Service Bus, ESB) в хранилище данных. Однако, как уже упоминалось ранее, хранилище данных в режиме реального времени выходит за рамки данной книги. Мы рассматриваем загрузку операционных данных в главе 12, где описаны аналогичные шаблоны загрузки непосредственно в хранилище данных.

Слой хранилища данных смоделирован с использованием методологии Data Vault 2.0, которая рассматривается в главах 4–6. Этот слой часто называют слоем необработанных данных (Raw Data Vault), поскольку он содержит необработанные данные, смоделированные по принципам Data Vault 2.0.

Слой информационной витрины (Information Mart Layer)

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

Информация в информационной витрине ориентирована на предметную область и может быть представлена в агрегированном виде, в плоской или широкой структуре, подготовлена для отчетности, иметь высокую индексацию, избыточность и быть очищенной по качеству. Она часто организована по схеме «звезда» (star schema) и служит основой как для реляционной отчетности, так и для многомерных OLAP-кубов. Поскольку конечный пользователь взаимодействует только с этим слоем хранилища данных, использование модели Data Vault в слое хранилища остается для него прозрачным. Если конечному пользователю требуется нормализованное хранилище данных в третьей нормальной форме, можно также предоставить информационную витрину, соответствующую этим требованиям.

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

Другими примерами информационных витрин являются Error Mart и Meta Mart. Они представляют собой центральные хранилища ошибок в хранилище данных и метаданных соответственно. Их отличие от стандартных информационных витрин заключается в том, что Error Mart и Meta Mart нельзя перестроить из Raw Data Vault или других источников данных. Однако они схожи с обычными витринами тем, что конечные пользователи, такие как администраторы, используют их для анализа ошибок в процессе загрузки данных, других проблем в хранилище данных или метаданных, которые хранятся для хранилища данных, его источников и преобразований, ведущих к информации, представленной в информационных витринах.

Глава 14, Загрузка размерной информационной витрины (Loading the Dimensional Information Mart), подробно рассматривает, как загружать информационные витрины для размерных OLAP-кубов из структур Data Vault 2.0 в хранилище данных.

Хранилище метрик (Metrics Vault)

Хотя три предыдущих слоя (промежуточный слой, слой хранилища данных и информационные витрины) являются обязательными в архитектуре Data Vault 2.0 (за исключением случаев реального времени, которые не рассматриваются в этой книге), Metrics Vault (описанный в этом разделе), Business Vault (раздел 2.2.7) и Operational Vault (раздел 2.2.8) являются дополнительными расширениями архитектуры Data Vault 2.0.

Metrics Vault используется для сбора и записи информации о времени выполнения, включая историю запусков, метрики процессов и технические метрики, такие как загрузка процессора (CPU load), использование оперативной памяти (RAM usage), метрики дискового ввода-вывода (disk I/O) и пропускная способность сети (network throughput).

Аналогично хранилищу данных, Metrics Vault моделируется по методологии Data Vault 2.0. Данные хранятся в необработанном формате, являются системно- или процесс-ориентированными и не подлежат аудиту. Хранилище может включать в себя технические метаданные и технические метрики ETL-джобов или окружения хранилища данных.

На основе Metrics Vault строится Metrics Mart, который предоставляет пользователям информацию о метриках производительности.

Глава 10, Управление метаданными (Metadata Management), содержит пример отслеживания аудиторской информации во время загрузки ETL и хранения этих данных в Metrics Vault.

Business Vault

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

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

На Рисунке 2.4 показано, что Business Vault располагается поверх корпоративного хранилища данных Data Vault. Это связано с тем, что Business Vault загружается перед загрузкой информационных витрин, облегчая этот процесс. Сложные бизнес-правила (мягкие правила, soft rules) получают данные как из Raw Data Vault, так и из сущностей Business Vault.

Рис. 2.4: Business Vault расположен внутри корпоративного хранилища данных Data Vault

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

Как и Metrics Vault, Business Vault не хранится в отдельном слое. Вместо этого он существует как расширение модели Data Vault внутри слоя хранилища данных. Глава 14, «Загрузка размерной информационной витрины» (Loading the Dimensional Information Mart), показывает, как использовать Business Vault для наполнения информационной витрины.

Operational Vault

Operational Vault — это расширение Data Vault, к которому могут обращаться операционные системы напрямую (Рисунок 2.5). В некоторых случаях такие системы могут либо извлекать данные из корпоративного хранилища данных, либо записывать их обратно.

Примеры таких систем включают системы управления мастер-данными (MDM), такие как Microsoft Master Data Services (MDS), или системы управления метаданными. В обоих случаях прямая работа на уровне хранилища данных, а не через информационную витрину или промежуточный слой, дает преимущества.

Другие примеры включают приложения для интеллектуального анализа данных (data mining), которые проводят анализ необработанных данных непосредственно в слое хранилища данных. Во многих случаях, когда подключаемому приложению требуется поддержка работы в реальном времени (как при чтении, так и при записи), прямой доступ к Operational Vault является наилучшим решением.

Рис. 2.5: Operational Data Vault

По этой причине интеграция данных в реальном времени из сервис-ориентированной архитектуры (SOA) или корпоративной сервисной шины (ESB) выполняет запись данных непосредственно в Operational Vault. Хотя в начале этого раздела мы определили Operational Vault как расширение Data Vault, подключаемые приложения могут считывать данные напрямую из существующих структур Data Vault. Таким образом, структуры Data Vault в некоторой степени становятся структурами Operational Vault.

Управляемый самообслуживаемый BI (Managed Self-Service BI)

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

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

Подход, называемый самообслуживаемый BI (self-service BI), позволяет конечным пользователям полностью обходить IT из-за его низкой отзывчивости. В этом подходе бизнес-пользователи самостоятельно выполняют весь процесс извлечения данных из операционных систем, интеграции и консолидации сырых данных. Однако у такого подхода, в котором IT не участвует, есть множество проблем:

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

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

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

Неконсолидированные сырые данные: для анализа данных из нескольких источников зачастую требуется консолидация. Без нее результаты бизнес-анализа могут быть бессмысленными.

Нестандартизированные бизнес-правила: поскольку в self-service BI конечные пользователи работают только с сырыми данными, им приходится самостоятельно реализовывать все бизнес-правила, преобразующие данные в осмысленную информацию. Но кто проверит, соответствует ли эта реализация стандартам организации?

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

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

Чтобы преодолеть эти проблемы, стандарт Data Vault 2.0 позволяет опытным или продвинутым бизнес-пользователям самостоятельно выполнять задачи анализа данных на основе сырых данных из хранилища данных. Фактически, IT, использующее Data Vault 2.0, приветствует инициативу бизнес-пользователей по использованию данных, доступных в корпоративном хранилище данных (будь то Raw Data Vault или Business Vault) и применению собственных инструментов для преобразования данных в осмысленную информацию. Это связано с тем, что IT не может своевременно обеспечить требуемую функциональность. Вместо этого IT извлекает сырые данные из операционных систем или других источников и интегрирует их с использованием бизнес-ключа в Raw Data Vault. Кроме того, IT может создавать структуры Business Vault, чтобы предоставить консолидированное представление отдельных частей модели или предварительно вычислить ключевые показатели эффективности (KPI) для обеспечения их согласованности.

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

Этот подход называется управляемым самообслуживанием BI (managed self-service BI) и является частью стандарта Data Vault 2.0. В рамках этого подхода IT трансформируется в сервисную организацию, которая предоставляет power users доступ к нужным данным в требуемые сроки. Интеграция данных осуществляется по бизнес-ключу, а при необходимости пользователя данные могут быть консолидированы и проверены на качество. Процессы консолидации и проверки качества выполняются при загрузке данных в Business Vault, как будет показано далее в этой книге.

Кроме того, Business Vault реализует некоторые из важнейших бизнес-правил. Power users имеют прямой доступ как к Raw Data Vault, так и к Business Vault, и в зависимости от конкретной задачи могут выбирать либо сырые данные, либо консолидированные и очищенные данные. Более того, оба типа данных уже интегрированы, поэтому бизнес-пользователь может также объединять консолидированные данные с сырыми данными из конкретных исходных систем.

Эта книга продемонстрирует, что загрузка сырых данных в Raw Data Vault является очень простой задачей, включая интеграцию с использованием бизнес-ключей. Фактически, это можно выполнить в коротких итерациях спринтов, как будет объяснено в Главе 3, Методология Data Vault 2.0. Когда пользователи запрашивают дополнительные данные, которые отсутствуют в хранилище данных, возможно извлечь и интегрировать эти данные в Raw Data Vault, чтобы предоставить их power user для выполнения задачи в рамках управляемого самообслуживания BI (managed self-service BI).

Другие фичи (Other Features)

Архитектура Data Vault 2.0 предлагает дополнительные возможности для поддержки реального времени (RT) и околореального времени (NRT), неструктурированных данных и сред NoSQL. Однако описание этих возможностей выходит за рамки данной книги.

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