ГЛАВА 7. Многомерное моделирование (Dimensional Modeling)

Аннотация

Моделирование Data Vault не является заменой Dimensional Modeling, которое является отраслевым стандартом для определения витрины данных (уровня, используемого для предоставления данных конечному пользователю). Поскольку данная книга предназначена для охвата всего процесса построения хранилища данных от начала до конца, она также охватывает и Dimensional Modeling.

Первая часть этой главы сосредоточена на базовых сущностях Dimensional Modeling — фактовых сущностях и размерных сущностях.

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

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

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

• Dimension modeling (Многомерное моделирование)
• Fact Entities (Фактовые сущности)
• Техники проектирования
• Snowflake Schemas (Схема «Снежинка»)
• Star Schemas (Схема «Звезда»)

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

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

Ещё одна проблема заключается в том, что большинство фронтенд-инструментов, используемых бизнесом для анализа информации, предоставляемой хранилищем данных, не могут напрямую использовать структуры Data Vault. Например, построение OLAP-куба в Microsoft SQL Server Analysis Services (SSAS) лучше всего работает, если источник данных смоделирован в виде звёздной схемы, которая является реляционной версией Dimension модели.

Многомерное моделирование было представлено широкой аудитории в индустрии хранилищ данных Ральфом Кимбаллом в 1997 году. Однако он не был его изобретателем. Термины «размерности» и «факты», которые являются основными конструкциями в многомерном моделировании, восходят к 1960-м годам, когда проводился совместный исследовательский проект между Дартмутским университетом и General Mills. Первая размерная модель (dimension model) была представлена компаниями AC Nielsen и IRI для описания ранних многомерных витрин данных для данных о розничных продажах. Но именно серия книг Ральфа Кимбалла способствовала популяризации размерного/многомерного моделирования в индустрии хранилищ данных, и оно стало стандартом моделирования. В результате многомерное моделирование поддерживается многими фронтенд-инструментами сегодня. Поэтому оно хорошо известно и понятно конечным пользователям и является оптимальным выбором для моделирования информационных витрин, которые служат в качестве фронтенд-слоя.

Введение

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

• Как изменялась степень загрузки на определённых рейсах за последний финансовый год?
• Какова эффективность нашей бонусной программы для часто летающих пассажиров в отношении продаж?
• Кто наши часто летающие пассажиры? Каков их средний объём продаж?

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

По всем этим причинам имеет смысл организовать данные в слое информационных витрин (information mart) таким образом, чтобы бизнес-пользователи могли быстро агрегировать информацию, а не быстро её модифицировать. Именно поэтому размерная модель (dimensional model) проектируется с учётом того, как измеряются данные. Поскольку метрики (measurement) часто основаны на бизнес-процессе, сам бизнес-процесс должен быть центром моделирования. Кроме того, необходим контекст, чтобы придать метрикам смысл, например, чтобы упорядочить метрики по аэропортам, как показано в Таблице 7.1.

Таблица 7.1 Пропорция пассажиров, работников, посетителей и провожающих/встречающих в выбранных аэропортах (с использованием искусственных данных)

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

Эти две фундаментальные концепции — метрики (measurements) и контекст (context) — являются основой размерного моделирования.

Схема «Звезда» (Star Schemas)

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

Рисунок 7.1 Пример схемы «Звезда» для посещений аэропортов (физическая реализация)

Исходный рисунок (в плохом качестве)

Модель на Рисунке 7.1 представляет модель, лежащую в основе данных Таблицы 7.1. В центре модели находится таблица фактов, окружённая четырьмя таблицами измерений.

Основное отличие схемы «Звезда» на Рисунке 7.1 от нормализованной модели в третьей нормальной форме (3NF), которая часто используется в операционных системах, заключается в том, что размерная модель обычно использует денормализованные таблицы, особенно:

• Таблицы Фактов: таблица в центре этой схемы содержит метрики/меры/показатели бизнеса, которые в случае Рисунка 7.1 представляют собой транзакции полётов. Эти measurements, как правило, являются метриками, которые бизнес желает проанализировать.
• Таблицы Измерений: таблицы размерностей группируют факты по категориям и предоставляют дополнительные описательные атрибуты к этим категориям. Эти категории называются размерностями и помогают конечному пользователю ориентироваться в модели и выбирать только нужное подмножество данных для анализа.

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

Это связано с денормализацией, которая обычно происходит при преобразовании модели 3NF в размерную модель. Иерархии и справочники предобъединены, что требует от оптимизатора СУБД учитывать меньшее количество объединений и временных таблиц. Также становится проще агрегировать данные, поскольку все измерения уже содержатся в центральной таблице фактов. Некоторые редакции Microsoft SQL Server также поддерживают оптимизацию звёздного объединения (star join optimization), функцию, которая значительно сокращает объём данных, считываемых с диска для ответа на запросы.

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

Таблицы фактов (Fact Tables)

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

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

Рисунок 7.2 Таблица фактов для рейсов (физическая модель)

Таблица фактов содержит два разных типа столбцов:

• Во-первых, внешние ключи на таблицы измерений, которые рассматриваются в следующем разделе. Сюда входят все четыре ссылки, которые являются частью составного первичного ключа, а также TailNumberKey, CancelledKey и DivertedKey.
• Во-вторых, значения измерений, сами факты. Многие из них указывают продолжительность задержек, например, DepartureDelay, WeatherDelay или SecurityDelay. Другие показывают продолжительность подпроцессов, например, время руления при въезде и выезде, время в полёте и пройденное расстояние.

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

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

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

Гранулярность таблицы фактов (Grain of a Fact Table)

Количество ссылок на измерения в таблице фактов определяет уровень детализации таблицы фактов. Этот уровень детализации называется гранулярностью (Grain).

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

Такой подход называется свёрткой (roll-up) и используется для обобщения данных по подмножеству измерений факта (subset of fact dimensions). Однако, хранение таблиц фактов на самом низком уровне гранулярности не всегда осуществимо, если серверная инфраструктура не предоставляет достаточных ресурсов для хранения самого низкого уровня детализации. В этом случае предварительная агрегация данных до более высокого уровня детализации обеспечивает более быстрые ответы бизнес-пользователям при прямом запросе к таблицам фактов. Обратите внимание, что это утверждение уже не актуально при использовании многомерных OLAP-кубов, потому что они агрегируют данные внутри куба прозрачно для конечного пользователя.

Таблицы размерностей/измерений (Dimension Tables)

Измерения/Размерности/Dimensions (а значит, и реляционные таблицы размерностей) предоставляют контекст для фактов. Они очень важны для понимания хранилища данных. Без измерений (dimensions) невозможно было бы понять метрики, предоставляемые таблицей фактов, потому что все метки и прочая описательная информация берутся из таблиц измерений. Как уже объяснялось в предыдущем разделе, они также используются для определения, как факты будут агрегироваться (сворачиваться). Кроме того, они могут использоваться для фильтрации фактов в соответствии с записью dimension или одним из её описательных атрибутов. Также возможно сортировать агрегированные метрики по измерению или одному из её атрибутов. На рисунке 7.3 показан пример таблицы размерности.

Рисунок 7.3 Таблица измерений пассажиров (физическая модель)

В отличие от таблиц фактов, таблица измерения использует значение ключа PassengerKey в качестве первичного ключа таблицы. Это связано с тем, что этот ключ часто используется в таблице фактов, ссылающейся на таблицу измерения. Чтобы сократить объём необходимого хранилища и повысить производительность соединений, имеет смысл поступать именно так и избегать использования натурального ключа. В остальном этот ключ не имеет значения для бизнеса. В дополнение к этому техническому ключу Измерения (Dimensions) часто содержат бизнес-ключи, которые идентифицируют записи в таблице dimension. На рисунке 7.3 это атрибут PassportNumber. Записи часто представляют собой бизнес-объекты и изменения этих объектов в операционной системе. Хотя натуральный ключ для одного и того же бизнес-объекта остаётся неизменным, даже если описательные данные были изменены в операционной системе, ключ изменяется при каждом изменении данных. Этот эффект используется таблицей фактов для ссылки на версию данных, которая была активна в момент, когда произошло бизнес-событие. Хеш-ключ из модели Data Vault 2.0 используется в качестве ключа в многомерной модели. Это упрощает процесс загрузки и помогает виртуализировать информационные витрины.

Несмотря на ключи в таблице, таблица измерения содержит описательные данные, которые описывают dimension entry (сущность измерения). Очень часто таблицы размерностей состоят из множества описательных атрибутов. Их количество может достигать 50 или 100 столбцов. С другой стороны, такие таблицы часто не содержат большого количества строк. Существуют некоторые размерности, такие как размерность Passenger, представленная на рисунке 7.3, которые могут содержать много записей, но большинство измерений довольно малы, содержащие, возможно, не более сотни записей.

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

• Полностью аддитивные меры (Fully additive measures): полностью аддитивны в том смысле, что такие значения, как суммы и количества, могут быть просуммированы до допустимого общего значения.
• Полуаддитивные меры (Semi-additive measures): могут быть просуммированы по некоторым доступным размерностям, но не по всем.
• Неаддитивные меры (Nonadditive measures): не поддаются сложению.

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

Запросы к схемам «звезда»

Конечные пользователи, знакомые со схемами типа «звезда», часто следуют простой схеме при прямом запросе данных из размерной модели:

• Выбор необходимых фактов: сначала конечный пользователь решает, какие факты следует выбрать, определяя используемые таблицы фактов.
• Выбор необходимых измерений: добавляя размерности к запросу через соединения (join), конечные пользователи добавляют необходимый контекст.
• Ограничение области фактов: факты фильтруются в соответствии со значениями измерений (либо из таблицы фактов по ключам, либо из присоединённых размерностей).
• Агрегация фактов: исходные факты агрегируются с помощью агрегатных функций, таких как SUM() или COUNT().

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

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

SELECT
    OriginAirport.Code, AVG(DepartureDelay)
FROM 
    FactFlight
INNER JOIN
    DimAirport OriginAirport ON OriginAirport.AirportKey = FactFlight.OriginAirportKey
WHERE
    OriginAirport.State = 'CA'
GROUP BY
    OriginAirport.Code

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

• сначала для аэропорта отправления,
• затем для аэропорта назначения.

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

Оператор также показывает, как отдельные части SQL-оператора используются в запросах к Dimension модели:

• Оператор SELECT определяет меры и размерности, которые должны быть представлены конечному пользователю. Также указываются любые формулы, включая агрегатные функции, которые должны быть применены к результату.
• Оператор FROM определяет таблицу фактов, к которой выполняется запрос. Во многих случаях это только одна таблица фактов. Однако также возможно выполнение запроса к нескольким таблицам фактов.
• Оператор JOIN присоединяет контекст фактов к итоговому результату. Во многих случаях имеется несколько операторов JOIN, каждый из которых соединяет отдельную таблицу измерения.
• Оператор WHERE ограничивает область фактов, используемых в результирующем наборе. Во многих случаях доступны данные из дополнительных записей размерности (например, регионы продаж), которые не имеют отношения к выполняемой задаче. Поэтому конечные пользователи обычно ограничивают данные интересующими их записями размерностей.
• Оператор GROUP BY определяет, как данные группируются перед агрегацией и представлением конечному пользователю. Агрегация в операторе SELECT основана на этом GROUP BY. Таким образом, оператор GROUP BY используется для изменения гранулярности (grain) результата по сравнению с гранулярностью исходной таблицы фактов.

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

Несколько звёзд (Multiple Stars)

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

Согласованные размерности/измерения (Conformed Dimensions)

Согласованные измерения — это размерности, которые используются несколькими звёздами. Они применяются для сравнения мер из каждой схемы звезда. Повторное использование согласованных размерностей является очень распространённым для «поддержки подлинного анализа бизнес-процессов в разных областях». Это возможно только в том случае, если все схемы звезда, которые должны анализироваться в рамках такого сквозного анализа, используют одну и ту же таблицу измерений с точно такими же значениями ключей (первичными ключами). Использование хеш-ключей из модели Data Vault 2.0 упрощает соблюдение этого требования. Такой анализ называется drill-across и объединяет информацию из нескольких бизнес-процессов или событий. Только тогда становится возможным анализ данных из различных таблиц фактов с помощью согласованного измерения. На рисунке 7.4 приведён пример.

Рисунок 7.4 Две схемы звезда, соединённые согласованными измерениями (физический дизайн)

Исходная картинка:

В этом примере имеются две схемы звезда с их таблицами фактов в центре:
FactConnection слева и FactAirportVisit с рисунка 7.1 — справа. Каждая из них имеет ряд подключённых измерений. Обе используют две общие таблицы согласованных измерений — DimAirport и DimDate, которые показаны в центре схемы. Для поддержки сквозного анализа между FactConnection и FactAirportVisit крайне важно, чтобы обе согласованные размерности имели абсолютно одинаковую структуру и данные.

Чтобы поддерживать такие согласованные размерности, необходимо, чтобы любые изменения в согласованной размерности не нарушали работу одной из размерных звёзд, использующих эту размерность. Это может — и, скорее всего, произойдёт — на последующих спринтах проекта. Всякий раз при изменении структуры или содержания согласованной размерности необходимо пересмотреть влияние на каждую зависимую схему звезда и провести соответствующее тестирование. Поэтому использование согласованных размерностей влечёт за собой влияние изменений, которое может ограничить гибкость команды разработки. Этот избыточный объём сопровождения согласованных размерностей часто приводит к практике, при которой разработчики не изменяют существующие согласованные размерности, чтобы избежать тестирования. Вместо этого они создают новые дополнительные согласованные размерности, чтобы избежать затрат на переинжиниринг, что приводит к несогласованным размерностям. В других случаях они копируют структуру и данные существующих согласованных размерностей в новые схемы звезда и расширяют их новыми функциями, оставляя старую согласованную размерность без изменений (и, следовательно, без необходимости тестирования), снова добавляя несогласованные размерности. Мы называем эту практику «dimension-itis», что приводит к неконтролируемому количеству размерностей, которые вроде бы одинаковые, но… несогласованные.

Обратная практика — это добавление большего количества атрибутов и данных в существующие согласованные размерности, чтобы избежать создания новых. Этот подход применяется, когда разработчики хотят избежать создания новых согласованных размерностей из-за объёма необходимого тестирования существующих фактов и измерений. Конечный результат такого подхода — так называемая «деформированная» размерность (“deformed” dimension): такая размерность не может больше устойчиво изменяться из-за неясных и неконтролируемых изменений в структуре и сложных или запутанных зависимостей, и становится кошмаром с огромными затратами на переинжиниринг при необходимости изменений в будущем. Команды, создающие такие деформированные размерности, как правило, избегают их документирования, что создаёт дополнительные сложности для их преемников.

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

Проектирование измерений (Dimension Design)

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

Медленно изменяющиеся измерения (Slowly Changing Dimensions, SCD)

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

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

Slowly Changing Dimension Type 0 (Медленно изменяющееся измерение Типа 0) сохраняет исходные значения атрибутов измерения. Если в системе-источнике происходит изменение, значение в таблице измерений не изменяется. Хотя этот тип встречается реже, чем следующие три, он может использоваться для хранения исходного кредитного рейтинга клиента или любого другого первоначального значения.

Изменения в системе-источнике перезаписывают данные в Slowly Changing Dimension Type 1 (Медленно изменяющемся измерении Типа 1). Атрибут измерения всегда отражает наиболее актуальное значение. Следовательно, история не отслеживается. Если на этом атрибуте основана агрегация (например, в предложении GROUP BY оператора), результаты этих агрегаций будут меняться в зависимости от нового значения. В таблице 7.2 приведён пример SCD типа 1.

Таблица 7.2 Медленно изменяющаяся размерность типа 1

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

Вместо перезаписи существующих данных, изменения в системе-источнике добавляют новую строку в таблицу Slowly Changing Dimension Type 2 (Медленно изменяющееся измерение Типа 2). Используя такой подход, часто можно корректно отслеживать историю. Поэтому это является преобладающей техникой отслеживания истории в информационных витринах. Пример размерности типа 2 представлен в таблице 7.3.

Таблица 7.3. Медленно изменяющаяся размерность типа 2

Таблица (модифицирована из таблицы 7.2 и адаптирована для цели) показывает, как изменения отслеживаются в медленно изменяющейся размерности типа 2: каждая новая версия записи добавляется как дополнительная строка в таблицу размерности.

В этом примере Эми Миллер, с ключом 1b3ba82..., вышла замуж за Петера Хайнца, с ключом 28ab342..., и переехала к нему в Калифорнию. Поэтому её новая запись с ключом 444bbaa... отражает эти изменения. Старая запись остаётся нетронутой, чтобы сохранить историческую информацию. Старые факты продолжают использовать запись с ключом 1b3ba82..., но новые факты ссылаются на запись размерности с ключом 444bbaa....

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

Таблица 7.4. Медленно изменяющаяся размерность типа 3

Этот пример показывает, как бизнес отслеживает предыдущее состояние пассажира с помощью дополнительного столбца. Когда пассажир переезжает, как в случае с Эми Миллер (теперь Эми Хайнц) в записи с ключом 1b3ba82..., старый адрес перезаписывается, а атрибуты, которые должны быть исторически отслежены, копируются в дополнительные столбцы. В данном случае столбец Previous State обновляется, чтобы отразить предыдущее состояние пассажира.

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

Таблица 7.5. Медленно изменяющаяся размерность типа 3 с несколькими столбцами

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

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

• Slowly changing dimension type 4 (Медленно изменяющаяся размерность типа 4): этот тип выносит изменчивые атрибуты в отдельную мини-размерность.
• Slowly changing dimension type 5 (Медленно изменяющаяся размерность типа 5): гибрид типов 4 и 1 (4 + 1 = 5). Позволяет получить доступ к текущим атрибутам мини-размерности вместе с другими из основной размерности без связывания через таблицу фактов.
• Slowly changing dimension type 6 (Медленно изменяющаяся размерность типа 6): этот тип добавляет текущие атрибуты к размерности типа 2.
• Slowly changing dimension type 7 (Медленно изменяющаяся размерность типа 7): этот тип обеспечивает ту же функциональность, что и тип 6, но с использованием двух внешних ключей в таблице фактов: один ссылается на размерность типа 2 с отслеживаемыми атрибутами, а другой — на текущую строку.

Иерархии

Иерархии (Hierarchies) — ещё одна важная концепция в размерном моделировании. Они позволяют производить детализацию данных для более глубокого анализа. Рассмотрим следующий пример:
В Excel PivotTable представлена мировая выручка от пассажиров за несколько лет в виде общих значений (см. рисунок 7.5).

Рисунок 7.5 Выручка от пассажиров по годам и регионам

Столбцы на рисунке 7.5 показывают финансовые годы (FY) из размерности даты, доступные в сводной таблице. Строки отображают географические регионы из размерности географии. Кроме того, присутствуют общие итоги, показывающие совокупное значение для каждого столбца или строки. Например, выручка от пассажиров за финансовый год 2008 в Соединённых Штатах составила $19,471,989.04.

Географическая иерархия состоит из следующих уровней:

• Страна
• Штат/Провинция
• Город
• Почтовый индекс

Возможно выполнение детализации (drill-down) до любого уровня, который доступен в сводной таблице (которая основана на OLAP-кубе), но не глубже. Рисунок 7.6 показывает логическую модель, в которой представлена размерность географии с её иерархией.

Рисунок 7.6 Размерность географии (логическая модель)

Обозначения следуют методологии моделирования ADAPT (Application Design for Analytical Processing Technologies) для размерных баз данных. Эта методология часто используется в индустрии для моделирования и документирования размерных моделей. Первый элемент изображает саму размерность Geography. Размерность включает одну иерархию, также называемую Geography. Остальные элементы представляют собой отдельные уровни иерархии и должны следовать в указанном порядке. Мы будем использовать методологию моделирования ADAPT на протяжении всей книги.

Аналогично иерархии Geography, иерархия Fiscal Calendar состоит из нескольких уровней:

• Финансовый год
• Финансовое полугодие
• Финансовый квартал
• Месяц
• Дата

Эта иерархия очень распространена в системах хранилищ данных и часто используется конечными пользователями. Она использует другую дату начала года, что часто практикуется коммерческими организациями. Например, предприятия в сфере торговли часто начинают финансовый год не с 31 декабря. Это связано с большим числом возвратов после Рождества, совершаемых клиентами, недовольными подарками. Поскольку объём таких возвратов достаточно велик, он оказывает влияние на общую выручку за год. Однако в большинстве случаев возвраты происходят в январе следующего календарного года. Если компания закрывает отчётный год 31 декабря, возвраты будут отнесены к следующему финансовому периоду и исказят финансовые результаты. Поэтому такие компании часто выбирают другой месяц в качестве окончания финансового периода. Один из примеров — Best Buy, розничный продавец электроники в США. Финансовый год этой компании заканчивается 1 февраля. Рисунок 7.7 показывает логическую модель размерности Date.

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

Обратите внимание, что в размерности доступны две иерархии: Calendar и Fiscal Calendar. Обе имеют свои собственные уровни Год, Полугодие и Квартал, но разделяют уровни Месяц и Дата. Обе иерархии используют все атрибуты размерности, но организованы по-разному. В зависимости от потребностей бизнес-аналитика используется та или иная иерархия. Обе являются корректными; ценность каждой иерархии зависит от контекста бизнес-анализа.

Чтобы более подробно проанализировать информацию на рисунке 7.5, можно нажать знак «плюс» рядом с меткой строки и выполнить детализацию по иерархии географии, как показано на рисунке 7.8.

Рисунок 7.8 Выручка от пассажиров в Соединённых Штатах по годам

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

Рисунок 7.9 Выручка от пассажиров в штате Алабама по годам

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

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

Рисунок 7.10 Выручка от пассажиров в Алабаме по годам, в деталях

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

Рисунок 7.11 Размерность географии (физическая модель)

Каждый уровень иерархии основан на одном из физических атрибутов таблицы размерности. Связь между атрибутом и уровнем иерархии задаётся в Microsoft SQL Server Analysis Services. Аналогичные иерархии будут реализованы в этой главе при построении OLAP-куба и добавлении размерности даты как иерархии.

Дизайн «Снежинка» (Snowflake Design)

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

Рассмотрим пример корпоративных групп в авиационной индустрии и отдельных авиаперевозчиков. Каждая авиакомпания входит в состав более крупной группы, которая владеет этим перевозчиком. Например, United Continental Holdings, Inc. владеет как United Airlines, так и Continental Airlines, а также другими, более мелкими перевозчиками.

Если схема звезда должна отразить эту связь, обе размерности — DimGroup и DimCarrier — должны быть напрямую связаны с таблицей фактов, как показано на рисунке 7.12.

Рисунок 7.12 Схема звезда с таблицей фактов в центре и только напрямую связанными размерностями (физическая модель)

Этот пример повторяет представленный на рисунке 7.4. Однако он показывает только одну схему звезда. Обратите внимание на две размерности DimGroup и DimCarrier, которые независимо связаны с таблицей фактов. Тем не менее, между этими двумя размерностями существует неявная связь. Эта связь реализована в ETL-задании, которое загружает таблицу. ETL-задание гарантирует, что в таблицу фактов загружаются только допустимые комбинации CarrierKey и GroupKey. Модель не реализует никаких правил, которые препятствовали бы загрузке недопустимых комбинаций. С другой стороны, эта модель проста в использовании для бизнес-пользователей, потому что они могут напрямую соединять всю необходимую контекстную информацию. Именно поэтому схема звезда допускает только напрямую связанные таблицы измерений.

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

SELECT
    DimGroup.Name, AVG(DepDelay)
FROM 
    FactConnection
INNER JOIN
    DimGroup ON DimGroup.GroupKey = FactConnection.GroupKey
GROUP BY
    DimGroup.Name

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

Схема «снежинка», с другой стороны, допускает косвенные таблицы измерений. Это полезно, если необходимо явно смоделировать отношения между атрибутами измерений. Если бы модель на рисунке 7.12 была реализована как схема «снежинка», она выглядела бы примерно как на рисунке 7.13.

Рисунок 7.13 Схема снежинка с таблицей фактов в центре и косвенно связанными измерениями (физическая модель)

Как видно из диаграммы, термин «снежинка» происходит от внешнего вида модели. Таблицы измерений отходят от центральной таблицы фактов, подобно лучам снежинки. Вместо того чтобы напрямую ссылаться на DimGroup из FactConnection, группа ссылается косвенно через DimCarrier. GroupKey, который идентифицирует группу в таблице фактов, перемещён в DimCarrier. Чтобы вернуть среднюю задержку группы, как в предыдущем запросе, необходимо сначала соединить DimCarrier, а затем DimGroup.

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

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

Сообщение Перевод 7 Главы — Dimensional Modeling (Data Vault 2.0) появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Перевод 6 Главы — Продвинутое моделирование Data Vault 2.0 — Advanced Data Vault Modeling

Предыдущие переводы

Перевод книги «Building a Scalable Data Warehouse with Data Vault 2.0»

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

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

В этой главе рассматриваются два дополнительных аспекта моделирования Data Vault: вспомогательные таблицы для запросов и справочные таблицы. Вспомогательные таблицы для запросов (Query assistant tables) используются для снижения сложности запросов к Data Vault и повышения производительности. Рассматриваются два конкретных типа вспомогательных таблиц для запросов: point-in-time (PIT) таблицы и bridge таблицы. Также подробно рассматриваются справочные таблицы (reference tables), включая справочные таблицы без истории, справочные таблицы с историей и таблицы с кодами и описаниями.

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

• вспомогательные таблицы для запросов (Query assistant tables)
• справочные таблицы (reference tables)
• point-in-time
• bridge таблицы
• таблицы с описаниями (description tables)

Таблицы Point-In-Time и Bridge объединяет то, что их основное назначение — упростить выполнение запросов к данным из Data Vault, а значит, повысить производительность выполнения запросов. Это особенно важно при использовании виртуальных информационных витрин для предоставления данных бизнес-пользователям.

Таблицы Point-in-Time

Проблема, которая может возникнуть при выполнении запросов к данным из Raw Data Vault, возникает, когда у хаба или связи имеется несколько спутников (см. рисунок 6.1).

РИСУНОК 6.1 Хабы с несколькими спутниками и PIT-лента (логическая структура)

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

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

Таблицы 6.1, 6.2, 6.3 и 6.4 показывают представление данных об обновлениях хаба пассажира и связанных с ним спутников.

Все представленные таблицы со спутниками (satellites) относятся к типу Slowly Changing Dimension Type 2 (SCD Type 2).

Таблица 6.1 Данные хаба пассажиров

Таблица 6.2 Данные спутника с именем пассажира

Таблица 6.3 Спутник с данными о предпочитаемом блюде

Таблица 6.4 Спутник с адресными данными пассажира

Пример показывает двух пассажиров и изменения в их данных с течением времени. Например, Эми Миллер, вероятно, вышла замуж за мистера Фримана и впоследствии сменила имя на Эми Фриман (см. таблицу 6.2). Она также меняла предпочитаемое блюдо со временем — от вегетарианской еды к мясу и обратно к вегетарианской (см. таблицу 6.3). Оба пассажира переезжали (или, по крайней мере, указывали разные адреса) с течением времени (см. таблицу 6.4).

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

Кроме того, спутники не охватывают все изменения, происходящие в исходной системе. Вместо этого изменения или дельты, захватываемые спутниками, поступают с такой частотой, с какой их поставляют источники. Спутники отслеживают только те изменения, которые доставляются в хранилище данных. Если хранилищу данных необходимо сохранять все изменения, происходящие в исходной системе, то исходная система должна предоставлять журнал аудита, например, такой, какой создаётся Microsoft SQL Server 2014 с включённой функцией Change Data Capture (CDC).

Другой вариант — предоставить данные в режиме реального времени с использованием Enterprise Service Bus (ESB) или Message Queue (MQ). Если эти опции не используются, загружаются только те изменения, которые входят в выгрузки из источника. Например, если пакетная загрузка выполняется каждые шесть часов, то дельты в спутниках будут отслеживать запись такой, какой она была каждые шесть часов.

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

Для достижения этой цели требуется использование OUTER JOIN-запросов с обработкой сложных диапазонов времени. При наличии более трёх спутников на хабе или связи это становится сложно и медленно. Лучше использовать equal-join-запросы для извлечения данных из Raw Data Vault. Для этого в моделировании Data Vault используется специальный тип сущности: point-in-time таблицы (PIT) и набор фиктивных записей в спутниковых таблицах, привязанных к фиксированным первичным ключам.

Equal-join-запросы — это тип SQL-запросов, при которых объединение таблиц происходит по условию равенства значений в связанных столбцах. Чаще всего используются в операциях INNER JOIN, LEFT JOIN, и других видах JOIN, когда связываются строки из разных таблиц с одинаковыми значениями в указанных столбцах.

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

Структура таблицы Point-in-Time

Структура Point-In-Time — это вспомогательная структура для запросов, ориентированная на производительность запросов. Следует рассматривать структуру PIT как часть слоя Business Vault или информационной витрины. Таким образом, структура может быть изменена, чтобы включать вычисляемые столбцы при необходимости для достижения максимальной производительности запросов.

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

РИСУНОК 6.2 Физическая PIT-таблица для пассажира (физическая структура)

Каждая запись в таблице point-in-time идентифицируется хэш-ключом. Это хэш-значение может использоваться далее при загрузке Type 2 измерений информационной витрины. После заполнения PIT-таблицы из предыдущего примера данными она будет выглядеть, как таблица 6.5.

Таблица 6.5 Представление данных PIT-таблицы для пассажира

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

Кроме того, хэш-ключ копируется из спутника. В большинстве случаев это значение будет совпадать со значением хэш-ключа в идентифицирующем ключе (в этом примере — PassengerHashKey). Однако в некоторых случаях соответствующая запись в спутнике для заданной даты снимка отсутствует: либо бизнес-ключ не был известен исходной системе на момент указанной даты снимка, либо он был удалён из исходной системы. В PIT-таблице, показанной в таблице 6.5, это соответствует записи номер 1. В отличие от спутника, хранящего имена пассажиров, спутники Preferred Dish и Passenger Address не содержат записи на дату снимка 1995-01-01. Если исходная система не предоставляет соответствующую запись, PIT-таблица должна ссылаться на неизвестную запись. В моделировании Data Vault 2.0 такая запись называется ghost-записью. Эта запись должна быть добавлена в каждый спутник (таблица 6.6).

Таблица 6.6 Спутник с данными о пассажирах с использованием ghost-записи

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

Таблица 6.7 Представление данных PIT с ссылками на ghost-записи

NULL-значения из предыдущей версии этой PIT были заменены ссылками на ghost-запись в каждом спутнике. Обеспечив наличие ghost-записи в каждом спутнике, на который ссылается PIT-таблица, становится возможным использовать Equal-join вместо outer join при извлечении данных из неё. Поскольку ссылки на спутники в PIT-таблице больше не содержат значений NULL, их не нужно обрабатывать отдельно.

PIT-таблица не содержит других системно-сгенерированных атрибутов, таких как источник записи. Это связано с тем, что данные создаются системой и не имеют собственного источника записи или даты загрузки. Однако возможно добавление дополнительных вычисляемых атрибутов по необходимости. Например, можно добавить дату окончания загрузки, чтобы поддерживать запросы с использованием оператора BETWEEN. Другие атрибуты могут предоставлять агрегации или вычисления для дальнейшего повышения производительности запросов. Однако следует уделить особое внимание ширине PIT-таблицы. Если она станет слишком широкой, производительность снова снизится, и преимущество PIT-таблицы будет утрачено. Эта рекомендация особенно важна для Microsoft SQL Server 2014, поскольку он поддерживает только страницы базы данных размером 8 КБ. Если серверы баз данных поддерживают страницы размером более 32 КБ и соответствующий размер блока на уровне физического хранилища, это снижает указанную проблему.

Для поддержания высокой производительности PIT-таблиц есть две рекомендации. Первая — включить сжатие на уровне базы данных. Microsoft SQL Server поддерживает сжатие данных в таблицах базы данных.

Сжатие данных в таблице имеет несколько преимуществ:

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

Однако сжатие данных также требует больше ресурсов CPU для сжатия и распаковки данных.

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

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

Управляемое PIT-окно (PIT Window)

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

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

РИСУНОК 6.3 Управление PIT-окном

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

РИСУНОК 6.4 Снимки логарифмической PIT-таблицы

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

Bridge Tables

Существует ещё один тип вспомогательных таблиц для запросов в стандарте Data Vault 2.0 — bridge-таблица (соединительная таблица). Подобно PIT-таблицам, их цель — повысить производительность запросов к Raw Data Vault за счёт сокращения количества необходимых соединений (joins) в запросе.

Они также являются частью Business Vault, поскольку данные в bridge-таблицах создаются системой и не подлежат аудиту по этой причине. Bridge-таблицы следует создавать только в том случае, если запросы к Raw Data Vault испытывают проблемы с производительностью.

В отличие от PIT-таблиц, которые охватывают несколько спутников хаба или линка, bridge-таблица охватывает несколько хабов и линков. Таким образом, она схожа со специализированной link-таблицей. Она не содержит никакой информации из спутников, в основном потому, что ширина таблицы стала бы слишком большой. На рисунке 6.5 показана логическая модель bridge-таблицы в Data Vault 2.0.

РИСУНОК 6.5 Bridge-таблица для повышения производительности запросов к данным о пассажирах (логический дизайн)

В приведённом выше сценарии имеются данные о пассажирах, связанных с агентом по продажам через Booking-link. Спутники используются для большинства хабов и линков в этом примере. Bridge-таблица Passenger Bridge не охватывает Flight и Airline. Модель не показывает бизнес-ключи или другие атрибуты, являющиеся частью сущностей Data Vault. Bridge-таблица действует как более высокий уровень факт-таблицы без фактов (fact-less fact table) и содержит hash-ключи хабов и линков, которые она охватывает.

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

Bridge-таблицы не обязаны иметь ту же степень детализации (grain), что и link-таблицы, которые они охватывают. В таких случаях bridge-таблица может содержать агрегированные значения, которые добавляются в структуру и загружаются с помощью операторов GROUP BY. В результате bridge-таблица имеет более высокий уровень агрегации (grain), чем линк-таблицы, включённые в неё. Таким образом, bridge-таблица становится очень похожей на exploration link.

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

Структура Bridge-таблицы

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

РИСУНОК 6.6 Физический дизайн bridge-таблицы (физическая структура)

Каждая запись в bridge-таблице BrPassenger идентифицируется по hash-ключам ссылочных хабов и линков. Атрибут SnapshotDate показывает, когда отдельная запись была загружена в bridge-таблицу. В некоторых случаях SnapshotDate включается в состав первичного ключа, например, при создании факт-таблиц для отслеживания запасов: в таком случае запасы отслеживаются по продукту, магазину и дате.

Таблица 6.8 Информация из bridge-таблицы

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

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

Сравнение PIT-таблиц и bridge-таблиц

Хотя PIT-таблицы и bridge-таблицы служат одной цели — помогают выполнять запросы к Raw Data Vault, между ними есть различия. PIT-таблицы относятся только к одному хабу или линку. Они используются для создания снимка дат загрузки спутников. Для этого они сохраняют только hash-ключ хаба (или линка) и даты загрузки соответствующих спутников, а также дату снимка самой PIT-таблицы. Можно добавить дополнительные вычисляемые атрибуты, такие как бизнес-ключ хаба, что является распространённой практикой.

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

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

Справочные таблицы (Reference Tables)

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

Мы представили хаб в главе 4 как уникальный список бизнес-ключей, идентифицирующих объекты, которые используются в бизнесе. Однако в корпоративных данных существует больше ключей и кодов, которые не обязательно являются бизнес-ключами, поскольку они не ссылаются на бизнес-объекты. Например, ISO-коды стран, такие как USA для Соединённых Штатов или DEU для Германии — это коды, которые используются в бизнесе, но сами страны не рассматриваются как бизнес-объекты внутри организации. Вместо этого они используются как описательные справочные данные, обозначающие определённое состояние информации. В случае кодов стран ISO-код может описывать страну, где была совершена продажа. Это описание обычно включает официальное название страны и другую описательную информацию, такую как континент или столица. Часто эти справочные данные не контролируются организацией, а поддерживаются внешними структурами. С другой стороны, тот же самый код страны может быть бизнес-ключом в другой организации, например, в Организации Объединённых Наций (ООН).

Справочные данные не являются исключительно описательными. Они существуют в контексте другой информации. Информация о стране без контекста транзакции продажи не имеет ценности для бизнеса. Или перефразируя: какова ценность для бизнеса от неиспользуемого списка кодов стран с их официальными названиями? Нулевая. Но если код страны используется в других данных, таких как транзакции продаж, он предоставляет дополнительную описательную информацию, добавляющую ценность бизнесу. Однако они не считаются бизнес-ключами, так как не используются бизнес-объектами; следовательно, они обычно не включаются в структуры хабов.

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

Справочные таблицы без истории (No-History Reference Tables)

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

Типичные примеры включают:

• Коды и описания медицинских препаратов по рецепту
• Биржевые символы
• Коды медицинских диагнозов
• Коды и описания VIN-номеров (например, коды производителей)
• Календарные даты
• Календарное время
• Международные коды валют
• Сокращения кодов штатов США

Следует отметить, что всё зависит от конкретного проекта: например, в некоторых странах (в отличие от США) могут происходить частые изменения кодов медицинских диагнозов — по разным причинам.

Простая справочная таблица без истории не содержит полей begin-date и end-date, поскольку данные не меняются. Поэтому структура таблицы очень простая, как показано на рисунке 6.7.

РИСУНОК 6.7 Логическая модель справочной таблицы без истории для календаря

Эта логическая модель показывает справочную таблицу для хранения простого календаря в Business Vault. Данные идентифицируются по ключу Date, который представляет собой поле типа Date в базе данных. Другие атрибуты в этом примере — Year, Month и Day, которые хранят соответствующие целые числа. Day of Week — это текстовое представление дня недели, например, «Monday».

Нет необходимости хранить историю изменений, поскольку в большинстве бизнесов отслеживать это не требуется. Это не означает, что данные в этой структуре не могут меняться. Однако большинство изменений — это исправления ошибок или обновления, которые должны быть отражены во всех витринах данных, включая исторические данные. Примеры таких изменений включают переводы значения Day of Week или его сокращения. На рисунке 6.8 представлена ER-модель этой справочной таблицы.

РИСУНОК 6.8 Физическая модель справочной таблицы без истории для календаря

Описательный бизнес-ключ используется как первичный ключ таблицы. Причина этого — ключ используется в спутниках и сущностях Business Vault для ссылки на данные из этой таблицы. Это делает данные более читаемыми и обеспечивает их аудируемость со временем. Если бизнес-ключ используется в качестве первичного ключа справочной таблицы, это даёт преимущество: его можно использовать в ER-моделях или для обеспечения ссылочной целостности (если включена), например, в целях отладки.

Таблица 6.9 «Календарные данные в справочной таблице без истории» показывает пример данных из календарной справочной таблицы:

В этом примере снова используется атрибут RecordSource, поскольку данные поступают из Master Data Services (MDS). Если пользователь изменяет данные в MDS, это перезаписывает содержимое справочной таблицы, так как история изменений не отслеживается. В других случаях данные могут не поступать ниоткуда извне — тогда поля LoadDate и RecordSource не нужны. Тем не менее, хорошей практикой считается брать данные из аналитического мастер-данных источника, так как это позволяет бизнес-пользователям редактировать данные без участия IT. Это является предпосылкой для управляемой самостоятельной аналитики (managed self-service BI).

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

РИСУНОК 6.9 Спутник со справочными данными (логическая модель)

Спутник Address ссылается на справочную таблицу State через почтовые аббревиатуры штатов США (USPS). Таким образом, справочник указывает на наличие более описательной информации о штате в справочной таблице. Благодаря этому не теряется читаемость в спутнике, и при этом сохраняется базовый принцип использования сущностей Data Vault.

Справочные таблицы с историей (History-Based Reference Tables)

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

Подход Data Vault к этой задаче заключается в добавлении стандартных спутников к справочной таблице, представленной в предыдущем разделе. В то время как базовая таблица содержит только неисторизированные атрибуты, спутник хранит справочные данные, требующие истории. Рисунок 6.10 показывает расширенную версию справочной таблицы из предыдущего раздела. Она дополнена спутником Fiscal Calendar, который добавляет два историзируемых атрибута к справочной таблице: Fiscal Year и Fiscal Quarter. Благодаря их историзации бизнес получает возможность изменять эти данные в будущем или учитывать изменения в прошлом. Это может быть необходимо, если, например, две организации с разными фискальными календарями объединились, и бизнесу нужно работать с историческими отчётами.

РИСУНОК 6.10 Справочная таблица с историей для календаря (логическая модель)

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

Рисунок 6.11 показывает физическую модель, полученную из логической модели на рисунке 6.6.

РИСУНОК 6.11 Физическая модель историзируемого календаря с использованием спутника Data Vault (физическая модель)

Спутник SatFiscalCalendar присоединяется к справочной таблице через её первичный ключ Date. Мы не используем хешированную версию ключа ради читаемости справочной таблицы. Если бы мы предпочли использовать хеш Date, это потребовало бы его использования в качестве первичного ключа, что, в свою очередь, повлияло бы на использование справочной таблицы. В остальном спутник очень похож на стандартные спутники Data Vault 2.0 — особенно это касается использования LoadDate в первичном ключе и LoadEndDate для задания окончания срока действия записей спутника.

Коды и описания (Code and Descriptions)

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

Например, FAA (Федеральное авиационное управление США) использует коды операций, представленные в таблице 6.10, для классификации воздушных судов по предполагаемому назначению:

Таблица 6.10 Список стандартных кодов операций FAA

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

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

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

РИСУНОК 6.12 Таблица справочных кодов и описаний (логическая модель)

Рисунок 6.12 показывает минимальную справочную таблицу для кодов и описаний. Обычно в такой таблице присутствуют дополнительные описательные атрибуты, например:

• Краткое описание (Short description): используется в диаграммах и других графиках, поскольку в столбчатых, круговых и прочих диаграммах имеется ограниченное место для подписей.
• Порядок сортировки (Sort order): большинство справочных данных не сортируются в алфавитном порядке при использовании в отчётах. Вместо этого бизнес хочет самостоятельно определять порядок вывода записей в измерениях.
• Внешняя ссылка (External reference): часто это URL-адрес, где можно найти больше информации о записи справочных данных. Полезно для интеграции справочных данных с Wiki в корпоративной сети.
• Владелец (Owner): указывает функциональное подразделение, ответственное за поддержание записи.
• Комментарий (Comment): произвольный текст, описывающий запись справочных данных для бизнес-пользователя, который её обслуживает.

ER-модель справочной таблицы кодов и описаний представлена на рисунке 6.13.

РИСУНОК 6.13 Справочная таблица кодов и описаний (физическая модель)

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

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

Данные FAA, представленные в таблице 6.10, будут храниться в физической таблице, как показано в таблице 6.11.

Таблица 6.11 Таблица кодов и описаний

Таблица 6.11 включает данные из двух групп: стандартные коды операций (StdOpCode) и ограниченные коды операций (RstOpCode) от FAA. Обе группы определяются с помощью атрибута Group и содержат одну или несколько записей, идентифицируемых уникальным атрибутом Code. Поэтому первичный ключ таблицы должен быть составным — по столбцам Group и Code.

Существует два варианта использования справочной таблицы кодов и описаний в спутниках. Возможно использовать составной первичный ключ, состоящий из атрибутов Group и Code, как внешний ключ (с обеспечением ссылочной целостности или без неё) в спутнике. Или, если внешние ключи не используются в модели, можно использовать только атрибут Code в спутнике и определять Group неявно через атрибут спутника. Это означает добавление жёстко заданных фильтров в предложения WHERE при получении или объединении данных для их разрешения. Это допустимая практика — модель при этом «типизирует» коды и описания, позволяя всем кодам существовать в обобщённой таблице на уровне подтипа. Однако второй подход требует документации, чтобы понимать, какая Group соответствует какому атрибуту спутника, без необходимости анализа кода из виртуальных фактов и измерений или ETL-кода.

Коды и описания с историей (Code and Descriptions with History)

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

РИСУНОК 6.14 Справочная таблица кодов и описаний со спутником для отслеживания истории (логическая модель)

Как видно на рисунке, эта концепция снова основана на использовании спутника, который хранит атрибуты, требующие отслеживания истории. В этом примере это Short Description и Long Description. Если есть атрибуты, для которых не нужно хранить историю, их можно добавить в саму справочную таблицу. Атрибут Sort Order следует именно такому подходу.

ER-диаграмма таблицы кодов и описаний с историей представлена на рисунке 6.15.

РИСУНОК 6.15 Справочная таблица кодов и описаний со спутником для отслеживания истории (физическая модель)

Наличие составного первичного ключа в справочной таблице требует, чтобы спутник ссылался на оба атрибута первичного ключа. Атрибуты, не требующие отслеживания истории — в данном случае SortOrder — добавляются в родительскую таблицу, а атрибуты, по которым нужна история, — в спутник. Атрибуты ShortDescription и LongDescription являются такими полями.

Сообщение Перевод 6 Главы — Продвинутое моделирование Data Vault 2.0 — Advanced Data Vault Modeling появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

ГЛАВА 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.

Глава 4 — Моделирование Data Vault 2.0

Аннотация

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

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

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

• Моделирование данных (Data modeling)
• Сателлиты (Satellites)
• Хаб-сущности (Hub Entities)
• Линк-сущности (Link Entities)
• Бизнес-ключ (Business Key)
• Смарт-ключи (Smart Keys)
• Интеллектуальные ключи (Intelligent Keys)
• Бизнес-ключи (Business Keys)
• Суррогатный ключ (Surrogate Key)
• Временные метки (Time Stamps)
• Идентификаторы источников записей (Record Source Identifiers)

В этой главе представлен подход Data Vault, включая основные типы сущностей, используемые при моделировании хранилищ данных на основе Data Vault. Данная модель ориентирована на масштабируемые сети (scale-free networks), которые часто встречаются в природе, поэтому перед определением типов сущностей кратко рассматриваются такие сети. Каждое определение сопровождается примерами рассматриваемого типа сущности.

Обратите внимание, что данная глава частично основана на книге Super Charge Your Data Warehouse Дэна Линстедта.

Также стоит отметить, что в этой главе используется логический язык моделирования, называемый Visual Data Vault. Дополнительную информацию, включая белую книгу и набор шаблонов для Microsoft Visio, можно найти на сайте https://www.visualdatavault.com/.

• VisualDataVault.v11.zip

Введение в моделирование Data Vault

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

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

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

Рисунок 4.1. Дорожная сеть США: случайная сеть

В случайной сети, такой как дорожная сеть США, большинство хабов имеет всего несколько соединений. Эта характеристика является результатом множества исторических решений, обусловленных географическими, политическими и экономическими факторами. Например, стоимость строительства автомагистралей, как правило, ограничивает количество дорог, добавляемых в систему. То же самое относится к авиационной системе США, представленной на Рисунке 4.2.

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

Рисунок 4.2. Авиационная сеть США: сеть без масштаба

Мы увидим, что хранилище данных, построенное с использованием модели Data Vault, так же легко расширять, как и любую другую сеть без масштаба (scale-free network).

Терминология моделирования Data Vault

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

Цель модели Data Vault — максимально точно представить бизнес. Исходя из этой цели, рассмотрим критически важные характеристики бизнеса:

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

Эти ключевые характеристики позволяют компании выживать в современных конкурентных рынках. Модель Data Vault разработана таким образом, чтобы поддерживать все эти ключевые характеристики при построении системы хранилища данных. Используя модель Data Vault, вы сможете максимально точно адаптировать хранилище данных под бизнес и использовать Data Vault в своих интересах.

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

Каждая сущность выполняет определенную функцию:

• Хаб отделяет бизнес-ключи от остальной модели.
• Линк хранит связи между бизнес-ключами (и/или хабами).
• Сателлит хранит контекст (атрибуты бизнес-ключа или отношений).

Хаб-сущности (Hub Entities)

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

Из-за центральной роли этих бизнес-ключей в идентификации бизнес-объектов модель Data Vault отделяет их от остальной модели. Назначение хаб-сущности — хранить бизнес-ключи бизнес-объектов вместе с некоторыми другими данными, называемыми метаданными.

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

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

Линк-сущности (Link Entities)

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

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

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

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

Рисунок 4.3. Линк, соединяющий три хаба (логический дизайн)

Рисунок 4.4. Линк, представляющий соединение между двумя хабами (логический дизайн)

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

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

Саттелит-сущности (Satellite Entities)

Модель Data Vault, состоящая только из хабов и линков, не обеспечила бы нас достаточной информацией. Они предоставляют только информацию о взаимосвязи между бизнес-объектами. Недостающий элемент — это контекст этих бизнес-объектов и контекст этих линков. Для транзакции рейса таким контекстом может быть время в воздухе или задержка рейса по соображениям безопасности.

Саттелиты добавляют эту функциональность в модель Data Vault. Они (Satellites) хранят атрибуты, которые принадлежат либо бизнес-ключу (в хабе), либо связи, либо транзакции (в линке) (Рисунок 4.5).

Рисунок 4.5 Саттелиты на хабах и линках (логический дизайн)

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

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

Определение хаба

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

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

Бизнес-ключ может быть составным ключом. Пример составного ключа — идентификационный номер транспортного средства (VIN), который включает информацию о производителе (первые три символа, называемые WMI-кодом) и информацию, специфичную для поставщика, такую как завод-изготовитель и серийный номер. Эти составные ключи также известны как «умные» (smart) или интеллектуальные (intelligent) ключи, и они рассматриваются подробнее позже в этой главе.

Хаб отслеживает появление нового бизнес-ключа в хранилище данных. Он использует метаданные для отслеживания системы-источника (называемой Record Source) и даты и времени поступления бизнес-ключа в хранилище данных (называемой Load Date). Кроме того, для каждого бизнес-ключа в хабе генерируется хеш-ключ. Хеш-ключ используется для ссылки на бизнес-объект в других сущностях Data Vault, таких как линки и саттелиты. Помимо этого, он повышает производительность загрузки данных в хранилище и объединения бизнес-ключей внутри модели.

Рисунок 4.6 Пример физической структуры сущности хаба в Data Vault (физический дизайн)

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

Метаданные хаба (в данном случае атрибуты LoadDate и RecordSource) следует размещать в начале сущности. Это упрощает дизайн (так как все хабы начинаются с одинаковых атрибутов) и облегчает поддержку сущностей Data Vault.

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

Рисунок 4.7 Хаб Data Vault (логический символ)

Определение бизнес-ключа (Business Key)

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

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

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

Некоторые примеры бизнес-ключей:

• Номера клиентов
• Номера продуктов (также UPC, EAN или ISBN штрих-коды, в зависимости от случая)
• Номера счетов
• Идентификационные номера транспортных средств (VIN)
• Номера деталей
• Номера счетов-фактур
• Автомобильные номера
• Номера портфелей
• Номера пропусков сотрудников
• Номера заявок в службу поддержки
• Номера водительских удостоверений
• Номера нарядов на работы

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

В некоторых случаях бизнесу не удается обеспечить истинную уникальность бизнес-ключа. Например, один производитель гитар использовал следующую систему для серийных номеров: «первая цифра — это год воспроизводимой модели, вторая цифра — это год производства». Это приводит к дублированию для любых лет с одинаковыми последними цифрами (например, 1996/2006). Для создания действительно уникального бизнес-ключа требуется комбинация серийного номера и года производства.

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

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

Композитные ключи — Composite Keys (также известные как умные ключи — Smart Keys, интеллектуальные ключи — Intelligent Keys)

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

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

• Код мирового производителя (WMI)
• Секция описания транспортного средства (VDS)
• Секция идентификатора транспортного средства (VIS)

Коды WMI уникальны и присваиваются только одному автопроизводителю. Однако один производитель может иметь несколько WMI-кодов. Код VDS определяет тип транспортного средства и включает информацию о модели и кузове. Код VIS идентифицирует отдельные автомобили (Рисунок 4.8).

Рисунок 4.8 Индивидуальные секции идентификационного номера транспортного средства

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

• Штрих-коды (UPC, EAN и т. д.)
• IMEI-номер, используемый для идентификации мобильных устройств
• MAC-адреса для идентификации сетевого оборудования
• ISBN-коды для книг
• ISSN-коды для периодических изданий
• Номера телефонов
• Адреса электронной почты
• Номера кредитных карт

В Visual Data Vault, языке логического моделирования для Data Vault, различают композитные ключи и умные ключи:

• Композитный ключ состоит из уникальной комбинации нескольких колонок.
• Умный ключ хранится в одном столбце, где отдельные части бизнес-ключа объединены (например, идентификационный номер транспортного средства на Рисунке 4.8).

Процесс идентификации бизнес-ключа

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

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

«Как вы идентифицируете, отслеживаете или находите информацию?»

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

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

Другие источники информации:

• Данные и модели в исходных системах
• XML/XSD-схемы
• Уникальные индексы на бизнес-ключах (это первый индикатор наличия бизнес-ключа)
• Электронные таблицы, OLAP-кубы, документация программного обеспечения

Область действия бизнес-ключей (Scope of Business Keys)

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

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

Рисунок 4.9 иллюстрирует эту зависимость

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

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

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

Не должно существовать двух автомобилей с одинаковым VIN. Однако автопроизводитель может решить использовать только последние 14 символов VIN, чтобы сэкономить место в операционных системах. Это объясняется тем, что все VIN начинаются с одних и тех же трех символов — WMI-кода производителя.

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

Разница между бизнес-ключами и суррогатными ключами (Business Keys vs Surrogate Keys)

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

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

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

Структура хаба (Hub Entity Structure)

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

Для всех хабов Data Vault характерны следующие атрибуты:

• Хеш-ключ (Hash key)
• Бизнес-ключ(и) (Business key(s))
• Дата загрузки (Load date)
• Источник записи (Record source)

Кроме того, существует необязательный атрибут:

• Дата последнего обнаружения (Last seen date)

Хеш-ключ (Hash Key)

Запросы к финальной модели Data Vault требуют намного больше соединений (joins), чем в традиционном хранилище данных. Поэтому при создании модели необходимо подготовить Data Vault так, чтобы увеличить скорость обработки соединений. Здесь на помощь приходит хеш-ключ:

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

Хеш-ключ в хабе Data Vault помогает улучшить производительность поиска (lookup) в хранилище данных. Когда ETL-процесс загружает хаб Data Vault данными из промежуточной таблицы (stage table), он проверяет, существуют ли уже бизнес-ключи источника в целевом хабе.

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

Безопасный метод вычисления хеш-ключа для бизнес-ключа хаба рассматривается в главе 11 «Извлечение данных».

Ключевые аспекты хеш-ключей:

• Каждый уникальный бизнес-ключ в хабе Data Vault должен иметь уникальный хеш-ключ.
• Рекомендуется использовать алгоритм MD5 (или другой алгоритм хеширования, например SHA-1).
• Хеш-ключи никогда не должны быть доступны бизнес-пользователям и не должны использоваться за пределами Data Vault.
• Как и суррогатные ключи, хеш-ключи не несут бизнес-смысла – они предназначены только для ускорения и упрощения соединений.
• Важно отметить, что хеш-ключ заменяет порядковый номер (sequence number), который использовался в Data Vault 1.0.

Почему отказались от порядковых номеров в пользу хеш-ключей?

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

Доказательство этого утверждения рассматривается в следующих главах.

Бизнес-ключ (Business Key)

Атрибут бизнес-ключа в хабе Data Vault хранит бизнес-ключ, который был определен в процессе идентификации бизнес-ключей.

Этот атрибут является основной целью хаба Data Vault. Поэтому он является центральным элементом хаба.

Тип данных бизнес-ключа

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

Композитные ключи в хабе

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

Как хранить композитные ключи в хабе?

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

В таком случае хаб должен содержать два уникальных ключа:

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

Множественные хабы для частей композитного ключа

Можно создать несколько хабов для каждой отдельной части композитного бизнес-ключа.

Например, для идентификационного номера автомобиля (VIN) можно создать:

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

Дата загрузки (Load Date)

Дата загрузки (Load Date) указывает, когда бизнес-ключ впервые поступил в хранилище данных.

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

Использование единой даты загрузки позволяет:

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

Дата загрузки генерируется хранилищем данных (или ETL-процессом, который выполняет загрузку).

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

Источник записи (Record Source)

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

Источник записи (Record Source) — это жестко заданное поле, которое обеспечивает прослеживаемость загружаемого набора данных.
Если у бизнес-ключа есть несколько источников данных, то источник записи должен указывать мастер-источник данных.
Если бизнес-ключ отсутствует в мастер-источнике, но присутствует в других источниках данных, тогда источник записи должен указывать фактический источник данного ключа.

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

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

Лучше не использовать обобщенные источники, например:

• «SAP» для всех данных SAP.

Вместо этого используйте наиболее детализированный уровень:

• «SAP.FINANCE.GL» — указывает модуль главной книги в финансовом приложении SAP.

Дата последнего обнаружения (Last Seen Date)

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

Этот процесс известен как Change Data Capture (CDC).

CDC поддерживается многими реляционными СУБД, включая Microsoft SQL Server.
Однако многие операционные системы не предоставляют такую дельта-загрузку.
Вместо этого источники данных предоставляют полный дамп всей таблицы, содержащей все актуальные записи операционной системы.

Такой метод называется полной загрузкой (full load).

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

Чтобы определить удаленные данные при полной загрузке, ETL-процесс должен:

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

Важно: В некоторых системах, например, mainframe, запись может не экспортироваться, если она заблокирована для редактирования.

Зачем нужна дата последнего обнаружения (Last Seen Date)

Если источник данных работает таким образом, дата последнего обнаружения (Last Seen Date) может помочь:

• Решить, когда запись следует считать удаленной.
• Определить временной порог, после которого запись считается удаленной.

Как работает дата последнего обнаружения

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

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

В Главе 11 подробно рассматриваются причины этой проблемы и методы заполнения даты последнего обнаружения.

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

Хабы, показанные на Рисунке 4.10, демонстрируют использование различных атрибутов.

Рисунок 4.10 Пример хабов Data Vault (физический дизайн)

HubAirline

Использует идентификационный номер авиакомпании (AirlineID), назначаемый Министерством транспорта США (US DOT), для уникальной идентификации авиакомпании.
Бизнес-ключ представлен в виде хэш-ключа AirlineKey, который создается путем хеширования AirlineID.

HubCarrier

Использует код перевозчика (Carrier Code), присваиваемый IATA.
Этот код шире применяется для идентификации перевозчика, чем AirlineID.
Проблема: код перевозчика не всегда уникален, так как один и тот же код мог быть присвоен разным перевозчикам в разные периоды времени.

HubFlight

Использует составной бизнес-ключ для представления объекта «рейс».

Составной ключ состоит из двух независимых бизнес-ключей:

• Carrier (перевозчик).
• FlightNum (номер рейса).

Отдельный хаб для номера рейса бессмыслен, так как:

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

HubFlightCode

Альтернативный способ представления составного бизнес-ключа.

В этом случае:

• Составной ключ представлен в одном поле FlightCode.
• Отдельные компоненты ключа также хранятся в Carrier и FlightNum.

HubAirplane

Использует атрибут LastSeenDate.

Это оправдано, так как:

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

Определение Link

Тип сущности Link отвечает за моделирование транзакций, ассоциаций, иерархий и переопределений бизнес-терминов.

• Link соединяет бизнес-ключи; следовательно, связи моделируются между хабами.
• Links фиксируют и записывают прошлые, настоящие и будущие взаимоотношения между элементами данных с максимально возможной детализацией.
• Links не фиксируют временные линии или временные аспекты — такие концепции (включая актуальный статус связи) являются частью контекста, а не задачей links.
• По этой причине в links не должно быть конечных дат (end-dated) или другой временной информации, за исключением атрибута Load Date (по техническим и информационным причинам).
• Links представляют связь, которая существует в настоящее время или существовала в прошлом.
• Добавление временных ограничений в link-структуры (например, Begin Date и End Date) привязывает связь к одной временной шкале и заставляет хранилище данных завершать и запускать эту связь только один раз.

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

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

Link содержит:

• Хэш-ключ каждого связанного хаба.
• Дополнительные метаданные (обсуждаются далее в этой главе).

Типичная сущность Data Vault link представлена на Рисунке 4.11.

Рисунок 4.11 Link сущность в Data Vault (физический дизайн)

Первичный ключ сущности — это хеш-ключ, который идентифицирует link внутри хранилища данных.

Этот ключ используется спутниками (satellites), которые добавляют контекст к link, или другими link, которые ссылаются на данный link.
Хеш-ключ также улучшает поиск записей при загрузке новых данных в таблицу.
Он основан на бизнес-ключах CarrierCode и AirportSeqID, которые хранятся в соответствующих хабах.
Атрибуты Load Date и Record Source предоставляют информацию о времени загрузки записи и ее источнике.

На протяжении всей книги для Data Vault links будет использоваться логический символ, показанный на Рисунке 4.12.

Рисунок 4.12 Логический символ Data Vault link

Форма сущности напоминает звено цепи, что помогает лучше идентифицировать этот базовый элемент.
Кроме того, используется иконка цепи для той же цели.
Data Vault link соединяет два или более хабов (ссылки на хабы), поэтому он всегда изображается вместе с ними (Рисунок 4.13).

Рисунок 4.13 Link, соединяющий два хаба (логическая схема)

Links обеспечивают масштабируемость модели Data Vault.

Можно начать с относительно небольшой модели хранилища данных в Data Vault.
Затем эта модель может расширяться (масштабироваться) путем добавления новых хабов и links для создания более крупной структуры.

Причины использования отношений многие-ко-многим

Отношения многие-ко-многим предоставляют ряду преимуществ для модели.

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

Поскольку отношения моделируются в link-сущностях, такие сущности:

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

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

Пример:

Допустим, сегодня бизнес определяет правило:

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

В традиционной третьей нормальной форме (3NF) эта связь моделируется через внешний ключ в дочерней таблице аэропортов, который ссылается на первичный ключ в таблице перевозчиков (Рисунок 4.14).

Рисунок 4.14 Отношение один-ко-многим (физическая модель)

Но если бизнес изменит правило:

«Теперь один аэропорт может обслуживаться несколькими авиаперевозчиками.»

Это потребует изменения структуры данных для поддержки отношения многие-ко-многим (Рисунок 4.15).

Рисунок 4.15 Отношение многие-ко-многим (физическая модель)

Проблема в том, что изменение бизнес-правила приводит к необходимости переработки существующих структур.

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

Link-сущности могут моделировать любые типы связей:

• 1:m,
• m:n,
• m:1,
• 1:1,
• без изменений в самой структуре link-таблицы.

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

Таким образом, модель Data Vault стремится свести необходимость реинжиниринга к нулю.

Гибкость Links

Links значительно повышают гибкость модели Data Vault.

Добавлять новые links или изменять тип связи существующих links легко,
→ это позволяет IT-отделу быстрее реагировать на изменения в бизнесе.

Чтобы добавить новую функциональность,
→ IT достаточно добавить новые hubs и связать их links с существующими hubs.
Пример:

На рисунке 4.16 показана начальная модель Data Vault для примера с авиацией (логическая схема).

Рисунок 4.16 Исходная модель до изменений (логический дизайн)

Если бизнес решает добавить информацию о самолете, в Data Vault добавляется новый hub, затем он связывается links с существующей моделью (Рисунок 4.17).

Рисунок 4.17 Модель Data Vault после модификации (логический дизайн)

При этом существующая модель не изменяется.

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

Links для объединения распределенных хранилищ данных
Links можно использовать не только внутри одного хранилища данных, но и для связи распределенных хранилищ, где часть модели хранится в одном месте, а другая часть — в другом (Рисунок 4.18).

Рисунок 4.18 Распределенное хранилище данных, соединенное links Data Vault

На схеме:

• Data Vault с информацией о полетах в США
• Data Vault с информацией о полетах в Европе
• Традиционное хранилище данных для Азиатско-Тихоокеанского региона

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

Гранулярность Links

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

Если связь в Data Vault уже находится в эксплуатации и бизнес требует изменения гранулярности, есть два варианта для рефакторинга модели Data Vault. Во-первых, мы можем изменить существующую связь и добавить ссылку на другой хаб. Однако это потребует перепроектирования существующих ETL-работ и также необходимо определить, как будет обрабатываться исторические данные в новой связи (которые имеют другую гранулярность). Это также ставит под угрозу возможность аудита данных, поскольку исходная система никогда не поставляла значение NULL (Рисунок 4.19).

Рисунок 4.19 Манипулирование историческими данными в связи Data Vault

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

Обратите внимание, что на Рисунке 4.19 каждая ссылка на другие бизнес-объекты (хабы) представлена псевдо-хеш-ключом и бизнес-ключом в фигурных скобках (например, «8fe9… {UA}»).

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

SQL-запрос в центре Рисунка 4.20 представляет собой бизнес-правило, которое описывает, как обрабатывать старые данные. Например, правило указывает, что аэропорт в старых данных должен быть установлен как «неизвестный», что представлено хеш-ключом 0 (упрощено). Полученная таблица используется для создания таблицы Business Vault, как обсуждается в Главе 14, «Загрузка размерной информационной модели», или измерения в информационной модели.

Рисунок 4.20 Объединение исторических данных (верхний левый угол) с новыми данными (верхний правый угол) из отдельных связей Data Vault

Второй вариант также работает, когда необходимо удалить уровень гранулярности (ссылку на хаб) (Рисунок 4.21).

Рисунок 4.21 Удаление исторических данных в связи Data Vault

Если мы просто удалим столбец «Самолет» из старой связи, мы потеряем данные из-за удаления ссылки из связи. Это худший случай для аудируемого хранилища данных. Снижение данных работает аналогично оператору GROUP BY без каких-либо мер.

Рисунок 4.22 показывает уменьшение уровня гранулярности. Обратите внимание на SELECT DISTINCT в SQL-запросе.

Рисунок 4.22 Объединение исторических данных (верхний левый угол) с новыми данными (верхний правый угол) из отдельных связей Data Vault

Link Unit-of-Work (Единица работы связи)

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

В Таблице 4.1 показан пример упрощенной таблицы исходной системы, которая станет основой для связи Data Vault.

Таблица 4.1 Единица работы в исходной системе

Данные в исходной таблице идентифицируют соединения между аэропортами, обслуживаемыми перевозчиками. Каждый перевозчик (в данном случае два перевозчика), идентифицированный номерами последовательности 222 и 729, обслуживает различные исходные аэропорты и соединяет их с аэропортами назначения. Если данные нормализуются, то следующие две таблицы (Таблица 4.2) будут результатом:

Таблица 4.2 Нормализованная исходная система

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

Таблица 4.3 Денормализованная исходная система

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

Структура сущности Link

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

• Хеш-ключ
• Дата загрузки
• Источник записи

Также возможно использовать дополнительный атрибут:

• Дата последнего просмотра

В дополнение к этим обязательным атрибутам, связь Data Vault может иметь следующий дополнительный атрибут:

• Ключ зависимого дочернего элемента

Хеш-ключ (Hash Key)

Подобно хабам в Data Vault, связь (Link) должна иметь хеш-ключ. Когда связь загружается данными из таблицы staging, задача ETL должна проверить, существует ли уже данное отношение или транзакция в таблице связи, поскольку не должно быть дублирующих записей связи, представляющих одно и то же отношение или транзакцию. Для этого задача ETL должна сравнить бизнес-ключи всех связанных бизнес-объектов. Поскольку реляционная база данных медленно сравнивает строки переменной длины (что является обычной характеристикой бизнес-ключей), производительность поиска часто бывает низкой. Проблема становится более серьезной, если бизнес-ключи не хранятся в связи Data Vault и должны быть соединены с ключами из ссылочных хабов, прежде чем их можно будет сравнивать. Хеш-ключ заменяет последующие соединения с ссылочными хабами при загрузке данных из staging-таблиц. Для выполнения соединений вычисляется хеш-код для комбинации всех бизнес-ключей в связи. Поскольку существует большая вероятность ошибок при вычислении хеш-кодов для бизнес-ключей, безопасный метод будет обсуждаться в Главе 11, «Извлечение данных».

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

Ключ зависимого дочернего объекта (Dependent Child Key)

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

К дегенеративным полям (degenerate fields) применяются следующие правила:

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

Примеры дегенеративных полей включают:

• Номера строк в счетах
• Стороны кассетной ленты (сторона A и сторона B)
• Номер страницы в книге
• Последовательный номер в кадре TCP
• Временная метка сообщения электронной почты

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

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

Примеры ссылок

Рисунок 4.23 представляет несколько примеров таблиц сущностей связи Data Vault.

Рисунок 4.23 Примеры связей Data Vault (физический дизайн)

Первая связь, LinkConnection, соединяет в общей сложности четыре хаба: хабы аэропортов-перевозчиков, исходных аэропортов, аэропортов назначения и номер рейса. Обратите внимание, что хаб аэропорта был упомянут дважды: один раз через SourceAirportHashKey и второй раз через DestinationAirportHashKey. Кроме того, связь включает обязательные метаданные LoadDate и RecordSource.

Вторая связь ссылается только на два других хаба: HubCarrier и HubAirport.

Определение спутника

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

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

Спутник прикрепляется только к одному хабу или связи. Поэтому он идентифицируется хеш-ключом родительского элемента и временной меткой изменения (Рисунок 4.24):

Рисунок 4.24 Сущность спутника Data Vault (физический дизайн)

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

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

• Внешний цвет автомобиля
• Имя и фамилия человека (например, клиента или сотрудника)
• Адрес доставки заказа
• Количество свободных мест в самолете
• Название бизнеса авиаперевозчика
• Описания продуктов в каталоге товаров
• Дата начала и окончания аренды автомобиля

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

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

Мы будем использовать логический символ, показанный на Рисунке 4.25, для рисования спутников в этой книге.

Рисунок 4.25 Спутник Data Vault (логический символ)

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

Важность сохранения истории

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

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

Поскольку необходимо сохранять историю данных, обновлять или изменять данные в спутнике запрещается. Единственное исключение из этого правила — атрибут Load End Date предыдущей версии данных. Глава 12, «Загрузка Data Vault», показывает, как изменить этот атрибут. Кроме того, в спутник добавляются только те исходные записи, в которых произошло хотя бы одно изменение. Следовательно, спутник является дельта-ориентированным, что сравнимо с измерением типа II в моделировании размерностей.

Разделение спутников (Splitting Satellites)

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

Разделение по исходной системе (Splitting by Source System)

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

Преимущества такой практики следующие:

• Она позволяет дизайнеру добавлять новые источники данных, не изменяя существующие сущности спутников.
• Убирает необходимость изменять входящие данные так, чтобы они соответствовали существующим структурам (например, путем преобразования данных в другой тип данных или разбиения, объединения, изменения длины, сокращения или другого манипулирования входящими данными).
• Она позволяет модели Data Vault сохранять историю системы источника и, следовательно, сохранять аудит для системы. Рассмотрим спутник, который хранит данные из нескольких систем: изменение в одной системе создаст новую запись в спутнике. Из количества строк не будет сразу понятно, какая система вызвала изменение.
• Она максимизирует параллелизм загрузки, поскольку нет конкуренции (на уровне ввода/вывода или базы данных) за целевой ресурс (спутник). Данные могут быть вставлены в спутник немедленно, не учитывая поступление данных из других систем, которые могут также пытаться вставить свои данные сразу.
• Позволяет интегрировать данные в реальном времени без необходимости интегрировать их с исходными данными, загруженными из пакетов. Нет зависимостей между несколькими системами, которые могли бы заставить систему иметь оба типа данных (в реальном времени и из пакетов) готовыми одновременно.

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

Разделение по скорости изменений (Splitting by Rate of Change)

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

Рисунок 4.26 Спутник до обновления пролетенных миль

Поскольку последний атрибут изменяется каждый раз, когда самолет выполняет полет, это создаст новую запись в спутнике для отслеживания изменения. Для этого необходимо отслеживать текущее состояние других атрибутов. Но поскольку они не изменились, они просто занимают место в новой записи (Рисунок 4.27).

Рисунок 4.27 Спутник после обновления пролетенных миль

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

Структура сущности спутника

Кроме атрибутов, которые хранят описательные данные в спутнике, требуются следующие метаданные:

• Дата загрузки
• Источник записи

Кроме того, в сущностях спутников Data Vault требуются следующие атрибуты:

• Хеш-ключ родителя
• Дата окончания загрузки

Следующие атрибуты являются необязательными для спутников Data Vault:

• Дата извлечения
• Хеш-дифференциал

Родительский хеш-ключ (Parent Hash Key)

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

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

Дата загрузки (Load Date)

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

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

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

Дата окончания загрузки (Load End Date)

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

Хеш-разница (Hash Difference)

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

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

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

Примечание: В моделях Data Vault сокращение для хеш-разницы часто обозначается как hdiff или hash diff.

Глава 11, «Извлечение данных», показывает, как вычислять атрибут хеш-разницы при его использовании в загрузках спутников.

Дата извлечения (Extract Date)

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

При использовании прямого доступа через SQL дата извлечения часто недоступна. Однако ETL-процессы обычно ведут журнал своей активности, включая дату и время извлечения данных из исходных систем. Таким образом, дата извлечения доступна как метаданные в процессных логах ETL-инструмента и не требует включения в Data Vault.

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

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

Примеры спутников

Рисунок 4.28 представляет несколько примеров спутников Data Vault.

Рисунок 4.28 Примеры спутников Data Vault (физическое проектирование)

Первый пример, SatAirport, зависит от HubAirport через AirportSeq. Идентифицирующий основной ключ представляет собой комбинацию AirportSeq и LoadDate (дата и время, когда эта запись была впервые увидена хранилищем данных). Кроме того, спутник использует атрибуты метаданных LoadEndDate и RecordSource. Для ускорения поиска изменений в строках спутник также использует необязательный атрибут HashDiff. Остальная часть спутника состоит из описательных атрибутов из системы источника.
SatAirportTZ был выделен из SatAirport, потому что он хранит атрибут, который меняется чаще, чем описательные атрибуты в SatAirport. В то время как эти атрибуты меняются очень редко (менее одного раза за десять лет), GMT-смещение локации меняется дважды в год (когда регион аэропорта переходит на летнее время). Если бы атрибут GMTOffset хранился в SatAirport, все описательные атрибуты были бы скопированы в новую строку, даже если изменения касаются только этого атрибута, а не всей описательной информации.
Последний спутник — это спутник на ссылке Data Vault, LinkConnection. Он хранит все описательные данные о соединении. Поскольку информация предоставляется в виде дельта-загрузок (система источника предоставляет только новую информацию о соединениях), нет необходимости искать, какие данные уже существуют, и, следовательно, нет необходимости в атрибуте HashDiff.

Ведущий ключ связи (Link Driving Key)

Пример SatConnection на рисунке 4.28 зависит от связи (link), как описано ранее. Модель на рисунке 4.29 показывает эту взаимосвязь.

Рисунок 4.29 Связь, привязанная к четырем концентраторам (логический дизайн)

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

Таблица 4.4 показывает две записи, описывающие одно и то же соединение. Очевидно, что описательная информация была обновлена в исходной системе и зафиксирована как изменение спутником. Обе записи ссылаются на одно и то же соединение, используя одинаковый Connection Hash Key. Атрибут Load Date указывает, когда данные были загружены из исходной системы.

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

Соединение идентифицируется тремя ссылками на концентраторы, которые выделены жирными стрелками на рисунке 4.30 (модифицированная версия рисунка 4.29).

Таблица 4.4 Данные спутника в SatConnection

Рисунок 4.30 Связь с ведущим ключом (логический дизайн)

Такой набор ссылок на концентраторы называется ведущим ключом (driving key) в моделировании Data Vault 2.0. Часто его также называют первичным ключом исходной структуры.

Таблица 4.5 показывает данные внутри структуры связи.

Таблица 4.5 LinkConnection с заполненными данными

Заполненные данные в LinkConnection показывают, что United Airlines изменила код рейса с UA4711 на UA123 для соединения Денвер (DEN) – Нью-Йорк (JFK).

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

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

Таблица 4.6 Данные спутника в SatConnection с ведущим ключом

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

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

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

Результатом этой взаимосвязи является то, что первая запись для connection hash key 28db… получает дату окончания, установленную как дата загрузки следующей записи (минус одна секунда или меньше).

Сообщение Перевод 4 Главы — Моделирование Data Vault 2.0 — Что такое Hub / Link / Satellite? появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

ГЛАВА 3 – Методология Data Vault 2.0

Аннотация

Методология Data Vault 2.0 представляет собой уникальный подход к разработке хранилищ данных и основана на нескольких гибких методологиях и техниках построения хранилищ данных, включая CMMI, Six Sigma, TQM, SDLC и анализ функциональных точек (Function Point Analysis). В этой главе рассматриваются основы этих стандартов и объясняется, как методология Data Vault 2.0 объединяет их.

Основное внимание в главе уделяется практическим аспектам ведения проектов в рамках методологии Data Vault 2.0.

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

• данные
• CMMI
• Six Sigma
• TQM
• SDLC
• анализ функциональных точек
• методология

Стандарт Data Vault 2.0 представляет собой наилучшую практику управления проектами, называемую «методология Data Vault 2.0». Она основана на ключевых стандартах разработки программного обеспечения и адаптирует их для использования в области хранилищ данных. На Рисунке 3.1 показаны стандарты, которые повлияли на формирование методологии Data Vault 2.0.

Рисунок 3.1 Компоненты методологии Data Vault 2.0

Объединяя эти стандарты, методология Data Vault 2.0 становится одной из лучших практик управления проектами в сфере хранилищ данных. Для координации работы команды и выполнения повседневных задач проекта применяется Scrum. В рамках двух- или трехнедельного спринта команда использует мини-водопад, основанный на жизненном цикле разработки программного обеспечения (SDLC). Целью такого подхода является завершение всех необходимых поставляемых компонентов по итогам итерации, чтобы они могли быть внедрены в промышленную эксплуатацию.

Методы управления проектами из PMI Project Management Body of Knowledge (PMBOK), признанные в сертификации Project Management Professional (PMP), используются для определения и выполнения проектного плана на физическом уровне проекта.

Capability Maturity Model Integration (CMMI) применяется для общего управления и контроля проекта, а также используется при проведении обзоров и сессий по улучшению процессов.

Всеобщее управление качеством (TQM) реализуется в рамках замкнутого цикла, обеспечивая непрерывное улучшение как самого процесса, так и обрабатываемых данных. Когда бизнес-пользователи участвуют в согласовании наборов данных из разных источников и исправлении ошибок в системах-источниках, они следуют принципам TQM. В разделе 3.3.2 мы обсудим, почему такой подход требует большего числа мероприятий по сравнению с традиционными методами управления качеством данных (DQ).

Принципы и правила Six Sigma применяются для достижения максимальной оптимизации и гибкости в процессе построения и внедрения хранилищ данных в стиле Data Vault 2.0. Этот процесс основан на метриках (сравнение оценок с фактическими значениями) и ключевых показателях эффективности (KPI), которые рассматриваются в разделе 3.1.4.

Методология Data Vault 2.0 состоит из трех основных видов деятельности, в рамках которых применяются методы, представленные на Рисунке 3.1:

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

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

Планирование проекта

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

Методология Data Vault 2.0 заимствует свои возможности по планированию проектов из PMP. В отличие от гибкой методологии Scrum, в Data Vault 2.0 делается акцент на наличие формального плана проекта в рамках спринта. Каждый проект имеет проектный план, который включает:

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

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

• Бизнес-спонсор (Business Sponsor): Бизнес-спонсоры должны обеспечивать соответствие проекта бизнес-целям и культурным целям организации; представлять проект, особенно перед высшим руководством; быть его ключевыми защитниками и привлекать к нему внимание других ключевых заинтересованных сторон; организовывать ресурсы для обеспечения успешности проекта; способствовать решению проблем, обеспечивая их эскалацию на уровень организации для эффективного устранения; поддерживать руководителя проекта, оказывая менторскую, коучинговую и лидерскую поддержку; а также создавать устойчивость результатов проекта, чтобы обеспечить их долгосрочную применимость.
• Технический бизнес-аналитик (Technical Business Analyst): Технические бизнес-аналитики устанавливают стандарты и списки управления доступом; приоритизируют запросы на изменения; определяют новые требования; создают новые отчеты для широкой аудитории бизнес-пользователей; помогают команде в отладке альфа-версий; участвуют в разработке и проектировании информационных витрин; а также создают учебные материалы для пользователей. Технический бизнес-аналитик является продвинутым пользователем, который подчиняется бизнесу, но обладает техническими навыками, включая понимание моделей данных и способность использовать или писать SQL напрямую.
• Руководитель проекта (Project Manager): Эта роль отвечает за то, чтобы команда проекта завершила выполнение проекта. Руководитель проекта разрабатывает план проекта, управляет выполнением проектных задач командой и обеспечивает принятие и одобрение результатов проекта со стороны спонсора и других заинтересованных сторон. Кроме того, данная роль отвечает за коммуникацию, включая отчеты о статусе, управление рисками и эскалацию проблем, которые не могут быть решены внутри команды проекта.
• ИТ-менеджер (IT Manager): Менеджеры информационных технологий (IT) обеспечивают непрерывность бизнеса и его успешность. По этой причине они курируют проекты и следят за эффективным использованием ресурсов. IT-менеджеры объективно консультируют руководство по вопросам того, где IT может принести пользу бизнесу; согласовывают затраты, сроки и стандарты, которым необходимо соответствовать, а также контролируют их выполнение в ходе проекта; помогают организации плавно переходить от устаревших систем к новым; и держат руководство в курсе хода текущих проектов.
• ETL-разработчик (ETL Developer): Участники команды, назначенные на роль Extract, Transform, Load (ETL), реализуют процессы загрузки данных и управления потоками данных, включая загрузку данных из систем-источников в промежуточное хранилище (staging), из промежуточного хранилища в структуры Data Vault, а затем в Business Vault и информационные витрины. Они также отвечают за создание виртуальных витрин данных или реализацию «мягких» бизнес-правил в ETL по запросу бизнеса.
• Разработчик отчетов (Report Developer): Разработчики отчетов создают отчеты, ориентированные на бизнес, на основе информационных витрин, таблиц Business Vault или (в редких случаях) напрямую на Raw Data Vault. В большинстве случаев им не требуется реализовывать бизнес-правила для этой задачи, однако в редких случаях создание бизнес-отчета может потребовать реализации ограниченного количества бизнес-правил прямо в отчете. Это следует избегать, так как это негативно сказывается на производительности и снижает возможность повторного использования.
• Архитектор данных / Архитектор информации (Data Architect / Information Architect): Архитекторы информации (в отрасли они известны как архитекторы данных, однако, по нашему мнению, этот термин вводит в заблуждение, так как они должны работать с информацией, а не только с данными; см. Главу 2, Масштабируемая архитектура хранилища данных) отвечают за информационную архитектуру и интеграцию данных.
• Менеджер метаданных (Metadata Manager): Эта роль отвечает за планирование проектирования метаданных; обеспечивает основу для разработки метаданных; координирует деятельность и коммуникацию с другими ролями и проектами; управляет уровнями доступа к метаданным для всех участников и внешних сотрудников, которым требуется работать с метаданными.
• Менеджер изменений (Change Manager): Менеджер изменений гарантирует, что новая функциональность не приведет к сбоям в других ИТ- или бизнес-сервисах при развертывании. Также эта роль отвечает за обеспечение возможности развертывания в рабочей среде и за предотвращение блокировки развертывания другими проектами.

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

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

Рисунок 3.2 Характеристики и обязанности технического бизнес-аналитика

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

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

Часть необходимого взаимопонимания со стороны бизнеса заключается в осознании того, что IT-команда должна иметь возможность работать без постоянных отвлечений на повседневные проблемы в течение своих двухнедельных спринтов. Вопросы, возникающие в операционной деятельности, должны быть запланированы на один из следующих спринтов. Для достижения этого IT также должно изменить свое мышление: их задача — не просто решать проблемы бизнеса, а создавать условия, при которых бизнес сможет решать часть, а в идеале большинство своих проблем самостоятельно, без вовлечения IT. Именно здесь на первый план выходит концепция «управляемого» (managed) самообслуживания в бизнес-аналитике (BI).

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

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

Рисунок 3.3 Определенные процессы, показывающие каналы коммуникации в методологии Data Vault 2.0

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

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

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

Когда разрабатываются новые релизы системы хранилища данных, команды разработки используют тот же подход, что и в традиционной разработке ПО. Они выпускают Alpha-версии для раннего тестирования, Beta-версии для тестирования на ограниченной бизнес-аудитории и Gamma-версии для продакшена. Alpha-релизы должны затрагивать только технических участников команды, включая технического бизнес-аналитика, как показано на Рисунке 3.4.

Рисунок 3.4 Зона охвата Alpha-релиза в методологии Data Vault 2.0

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

Обычно Alpha-релиз распространяется среди технических бизнес-аналитиков после первых двух или трех спринтов проекта хранилища данных.

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

Рисунок 3.5 Зона охвата Beta-релиза в методологии Data Vault 2.0

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

Рисунок 3.6 Зона охвата Gamma-релиза в методологии Data Vault 2.0

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

Capability Maturity Model Integration

Capability Maturity Model Integration (CMMI) — это модель улучшения процессов, разработанная более 20 лет назад и управляемая Институтом программной инженерии (SEI) при Университете Карнеги-Меллона (США). CMMI спонсируется правительством США (в частности, Министерством обороны США) и используется организациями всех размеров по всему миру. Данная модель помогла оптимизировать затраты, сократить доработки и уровень дефектов, а также улучшить сроки выполнения работ и качество.

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

• CMMI for Development — модель управления и улучшения процессов для организаций, занимающихся разработкой программного обеспечения;
• CMMI for Acquisition — модель для организаций, которым необходимо инициировать и управлять закупками продуктов и услуг;
• CMMI for Services — модель процессов для организаций, помогающая им развертывать и управлять услугами.

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

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

CMMI можно интегрировать с другими фреймворками и лучшими практиками, такими как гибкая разработка (agile development), PMP и Six Sigma. Это возможно потому, что CMMI не определяет, как должна выполняться разработка программного обеспечения, а вместо этого указывает, что должно быть сделано для улучшения процессов разработки. Таким образом, CMMI поддерживает принципы agile, предоставляя референсную модель для успешных сред разработки.
CMMI также поддерживает интеграцию с Six Sigma, позволяя реализовывать области процессов CMMI в виде проектов Six Sigma (например, DMAIC). PMP также совместим с CMMI, поскольку существует перекрытие между областями знаний PMBOK (Project Management Body of Knowledge) и процессными областями CMMI.

Существуют две разные представления CMMI:

1. Непрерывное представление (continuous representation)
2. Поэтапное представление (staged representation)

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

Поэтапная модель (staged model) ориентирована на организацию в целом и предлагает дорожную карту в виде последовательности этапов (stages), отсюда и название. Эти этапы называются уровнями зрелости (maturity levels) и отражают степень зрелости организации в рамках набора процессных областей.
По мере продвижения организации по уровням зрелости она внедряет все больше практик из различных процессных областей. Как только организация удовлетворяет целям всех процессных областей на одном уровне зрелости, она может перейти на следующий уровень для дальнейшего улучшения своих процессов.

Непрерывная модель (continuous model) отличается от поэтапной модели, поскольку не задает четкий порядок внедрения процессных областей, которые должны быть улучшены. Вместо этого она сосредотачивается на каждой процессной области отдельно и на том, как ее можно улучшить. Каждая процессная область имеет свой собственный уровень возможностей (capability level). При этом группировка процессных областей в данной модели отсутствует.

Следующие разделы более подробно представляют уровни возможностей и уровни зрелости CMMI.

Уровни возможностей (Capability Levels)

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

• 0. Неполный (Incomplete)
• 1. Выполняемый (Performed)
• 2. Управляемый (Managed)
• 3. Определенный (Defined)
• 4. Количественно управляемый (Quantitatively Managed)
• 5. Оптимизируемый (Optimizing)

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

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

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

Следующий уровень возможностей, которого может достичь организация, — это уровень возможностей 3: определенный (Defined).
Он характеризуется определенным процессом, который представляет собой управляемый процесс, созданный на основе набора стандартных процессов организации и адаптированный к конкретным условиям.
Процесс был настроен в соответствии с руководящими принципами организации и включает описание процесса. Кроме того, он вносит процессный опыт обратно в общую процессную организацию.

Уровень возможностей 4: количественно управляемый (Quantitatively Managed) — это определенный процесс (см. уровень 3), который использует статистические и другие количественные методы для управления выбранными подпроцессами. Эти методы используются для выявления процессов, которые дают больше дефектных результатов или обладают более низким качеством.

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

Уровни зрелости

Уровни зрелости отличаются от уровней способности, так как они применяются к наборам областей процессов, в которых необходимо достичь совокупного набора целей (в отличие от уровней способности, которые применяются к отдельным областям процессов). В модели CMMI используются следующие уровни зрелости, которые объясняются в этом разделе:

1. Начальный (Initial)
2. Управляемый (Managed)
3. Определенный (Defined)
4. Количественно управляемый (Quantitatively Managed)
5. Оптимизируемый (Optimizing)

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

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

Уровень зрелости 3: определенный характеризуется четко описанными и понятными процессами, которые документированы в стандартах, процедурах, инструментах и методах. Организационные стандартные процессы устанавливаются и совершенствуются со временем. Ключевое отличие между уровнями зрелости 2 и 3 заключается в том, что на уровне 2 стандарты, описания процессов и процедуры могут различаться для каждой конкретной реализации процесса. Однако на уровне 3 стандарты, описания процессов и процедуры адаптируются из стандартных процессов организации.

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

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

Переход на уровень зрелости 5

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

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

Интеграция CMMI в методологию Data Vault 2.0

Методология Data Vault 2.0 позволяет организациям достичь уровня зрелости 5 по CMMI, решая следующие задачи:

• Измеримость (Measurable): Раздел 3.1.4 опишет, как процесс оценки в методологии Data Vault 2.0 основан на сравнении оценочного и фактического объема работ. Для этого необходимо фиксировать соответствующую информацию на протяжении всего процесса.
• Повторяемость (Repeatable): Для оценки будущих затрат важно иметь повторяемые процессы. Модель Data Vault 2.0 помогает в этом благодаря шаблонным, основанным на паттернах процессам моделирования и загрузки данных в корпоративное хранилище данных.
• Определенность (Defined): Data Vault 2.0 поддерживает четко определенные стандарты, правила, процедуры и готовые шаблоны, включая проектную документацию. Пример такого определения процессов представлен на рисунке 3.3. Определенность также способствует повторяемости процессов.
• Гибкость (Flexible): Методология поддерживает быстрые последовательные развертывания (от двух до трех недель, в зависимости от возможностей или предпочтений организации). Также возможны изменения в размерах команды в зависимости от потребностей. Это соответствует определенным паттернам Data Vault 2.0, которые помогают новым членам команды быстро понять процессы и включиться в реализацию или тестирование.
• Масштабируемость (Scalable): После развертывания хранилища данных на основе Data Vault 2.0 в одной части предприятия можно добавлять дополнительную функциональность, необходимую другим подразделениям. Это возможно благодаря органическому росту моделей Data Vault 2.0 — характеристике, которая не только уникальна для Data Vault, но и была заложена в подход к моделированию с самого начала.
• Мониторинг (Monitored): Регулярные командные обзоры, как в Scrum (например, на встречах ретроспективы), и постоянные релизы в каждом спринте гарантируют, что бизнес-пользователи не теряют интерес к проекту и его деятельности. Напротив, это поддерживает высокий уровень вовлеченности, что ускоряет реакцию бизнеса, если ИТ не предоставляет ожидаемых результатов.
• Управляемость (Governed): Мониторинг также включает в себя управление. Если релизы не соответствуют (или не превышают) задокументированные стандарты, проект приостанавливается и пересматривается, чтобы в будущем соответствовать требованиям. Это осуществляется в рамках двух- или трехнедельных спринтов.
• Оптимизация (Optimized): Процессы Data Vault 2.0 способствуют оптимизации благодаря низкой сложности: чем ниже сложность процессов разработки, тем меньше зависимостей необходимо учитывать при постоянном совершенствовании процессов.

Таблица 3.1 показывает действия и задачи методологии Data Vault 2.0 и их связь с уровнями зрелости CMMI.

Таблица 3.1 — Соответствие методологии Data Vault 2.0 уровням зрелости CMMI

Организации могут использовать эту таблицу, чтобы сосредоточиться на определенных действиях Data Vault при продвижении по уровням зрелости. Например, параллельные команды должны становиться объектом внимания организации только после достижения уровня зрелости CMMI 4 (количественно управляемый) и при переходе на уровень 5 (оптимизируемый). Это соответствует ранее описанной рекомендованной практике продвижения по уровням зрелости, а не попытке сразу достичь статуса оптимизируемой организации. Хотя первый подход требует больше времени и тщательной проработки организационных возможностей, он сопряжен с гораздо меньшими рисками по сравнению с прямым стремлением к уровню зрелости 5.

Управление проектом

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

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

Исключением из этого правила является долгосрочное (или общее) планирование, необходимое на программном или корпоративном уровне организации.

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

Так как модель Data Vault 2.0 была создана на основе модели сети с центральным узлом и подключенными элементами (hub-and-spoke network model, подробнее об этом в главе 5 «Промежуточное моделирование Data Vault»), она изначально разработана для поддержки такого эволюционного подхода.

Создание модели Data Vault — это естественная эволюция. Наилучший подход к реализации хранилища данных на основе Data Vault 2.0 — сосредоточиться на четко определенной, узконаправленной задаче, где бизнес-ключи охватывают несколько функциональных областей. Следует избегать попыток смоделировать всю организацию сразу, как это обычно делается в традиционных архитектурах, представленных в главе 1 «Введение в хранилища данных». В этих устаревших архитектурах моделирование всей организации требуется, поскольку внесение изменений в исходную модель (нормализованную до третьей нормальной формы или в виде звездной схемы) слишком затратно. Поэтому разработчики пытаются внедрить в исходную модель как можно больше функций, чтобы минимизировать будущие изменения. Однако, учитывая изменчивость бизнес-среды, такой подход нереалистичен.

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

Однако гибкость зависит не только от модели Data Vault или архитектуры. Она также зависит от людей: участников проекта внутри команды и внешних специалистов, поддерживающих основную команду разработки. Успешный гибкий проект требует хорошо обученных специалистов, которые следуют дисциплинированному, совместному подходу (как описано в предыдущем разделе). Также важно привлекать всех заинтересованных лиц, которые вовлечены в создание хранилища данных. Это не только бизнес-пользователи. Команды разработки часто забывают вовлекать операционные и службы поддержки на ранних этапах процесса.

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

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

В конечном итоге цели гибкой (agile) поставки заключаются в следующем:

• Масштабирование agile: Это касается не только увеличения размера команды, но также распределения команды по разным локациям, соответствия нормативным требованиям, управления сложностью (доменной, технической и организационной) и интеграции в корпоративную среду.
• Избегать хаоса: Плохо управляемые проекты сталкиваются с теми же проблемами, что и неуправляемые. Нельзя просто «быть agile» без дисциплины agile. Учитесь на ошибках прошлых спринтов и постоянно улучшайте свои процессы.
• Эффективное начало: Прежде чем приступить к разработке системы, необходимо прояснить бизнес-проблемы, определить жизнеспособное техническое решение, спланировать подход, настроить рабочую среду и собрать команду. Также важно заручиться поддержкой заинтересованных сторон в отношении выбранного подхода и стратегии внедрения.
• Переход от отдельных специалистов к agile-командам: Каждый член команды должен сосредоточиться на совместной работе для достижения целей проекта, а не на индивидуальных выгодах.
• Постепенное наращивание решения: Каждый спринт должен давать результат, который может быть использован бизнес-пользователями. Только в этом случае они смогут дать реалистичную и ценную обратную связь о текущем решении. Цель — не просто продемонстрировать что-то, а ввести в реальную эксплуатацию.
• Развертывание гибких решений: Современная бизнес- и технологическая среда сложна. Agile-решение должно быть развернуто с учетом этой сложности.
• Использование корпоративных методологий: Методология Data Vault 2.0 уже включает в себя проверенные корпоративные методологии, такие как CMMI, Scrum, Six Sigma, PMP и др. Существуют и другие дисциплины, помогающие развертывать, сопровождать и поддерживать решения, например, ITIL (Библиотека инфраструктуры информационных технологий). Используйте эти проверенные подходы, особенно если они уже применяются в вашей организации.
• Адаптация стратегии управления (governance): Управление agile-проектами должно быть встроено в процесс спринтов. Поскольку решение поставляется к концу каждого спринта, необходимо проверять соответствие установленным в организации стандартам и правилам.

Эти цели заимствованы из Disciplined Agile Delivery (DAD), который применяется в корпоративных организациях для гибкой поставки программного обеспечения. Это гибридный подход, который расширяет Scrum за счет проверенных стратегий Agile Modeling (AM), Extreme Programming (XP) и Unified Process (UP). Таким образом, он следует схожей стратегии с методологией Data Vault 2.0, но с четкой ориентацией на хранилища данных и бизнес-аналитику.

Scrum

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

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

В результате были разработаны гибкие методологии (agile), чтобы сделать процесс разработки программного обеспечения более адаптивным и успешным в целом. Scrum является одним из примеров такой гибкой методологии, и он описан в следующих разделах. Он был введен в конце 1990-х годов и стал «подавляющим [agile] фаворитом».

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

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

Цель Scrum — создавать потенциально готовый к выпуску инкремент (potentially shippable increment) в каждом спринте, представляющий собой новую версию системы, которую можно продемонстрировать бизнес-пользователям и потенциально выпустить в продакшн (Рисунок 3.7).

Рисунок 3.7 Поток требований в процессе Scrum

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

Рисунок 3.8 Быстрые итерации в Scrum

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

Следующие разделы объясняют элементы Scrum более подробно.

Итеративный подход

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

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

Рисунок 3.9 Управление проектом в Scrum

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

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

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

Бэклог продукта и спринта

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

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

Рисунок 3.10 Бэклог и приоритет

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

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

Интеграция Scrum с методологией Data Vault 2.0

Чтобы стать гибкой проектной командой и достичь целей, представленных в начале этого раздела, команда должна развиваться через различные уровни CMMI. Слишком многие команды и организации просто решают быть «гибкими», не применяя корректно принципы выбранной методологии. Все гибкие подходы, включая Scrum, следуют набору принципов, которые необходимы для того, чтобы команда могла стать гибкой. Без правильного следования этим принципам команда попадает в число тех, кто лишь делает вид, что «разрабатывает по Agile», но на самом деле отказывается от большинства управленческих процессов проекта. Однако Agile-проектное управление не означает «отсутствие управления проектом». Это другой подход к управлению проектом, требующий, чтобы члены команды знали принципы и умели их применять.

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

Более того, для ведения гибких проектов необходима гибкая организация. Если организация мыслит в стиле водопадной модели с передачей артефактов «через забор» между отделами (например, от разработки к тестированию, затем к бизнесу) и внесение изменений в промышленную эксплуатацию требует минимум 3 недель, ваша команда не сможет работать эффективно с точки зрения гибкой методологии. Как уже упоминалось в этой главе, цель состоит в том, чтобы изменения, разрабатываемые в одной итерации, вводились в промышленную эксплуатацию в том же спринте. Эта цель может не всегда быть достижимой, например, если невозможно сократить изменение до управляемого объема, который можно разработать и развернуть в рамках одного спринта. В этом случае артефакт может дорабатываться в нескольких спринтах, пока он не будет готов к развертыванию. Однако стандартной практикой должно быть развертывание в том же спринте, в котором разрабатывается артефакт.

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

CMMI может помочь в развитии как команды, так и организации для достижения гибкости. Следуя рекомендациям, изложенным в разделе 3.1.1 (подраздел «Продвижение к уровню зрелости 5»), организации со временем развивают эти навыки, давая членам команды возможность учиться, применять и совершенствовать свои Agile-навыки. Фактически, Scrum строится на уровне 5 CMMI (оптимизация), где команды стремятся улучшать свои способности со временем. Мы рассмотрим это более подробно в разделе 3.3.

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

• Удовлетворение потребностей заказчика: Для выполнения этой обязанности команда должна быстро и непрерывно доставлять не просто работающее программное обеспечение, а полезное программное обеспечение. Под этим мы понимаем, что инкремент должен приносить ценность пользователю (и работать).
• Частые поставки: Чтобы демонстрировать прогресс бизнес-пользователям и другим заинтересованным сторонам, команда BI должна поставлять работающее программное обеспечение на регулярной основе (в течение недель, а не месяцев).
• Измерение прогресса: Разработчики часто измеряют свой прогресс количеством затраченных человеко-часов и сравнивают его с первоначальным или обновленным планом. В гибких методах разработки, таких как методология Data Vault 2.0, прогресс измеряется работающим программным обеспечением, а именно реализованными функциями.
• Готовность к изменениям: Гибкие BI-команды не должны избегать поздних изменений в изначальных требованиях. Чтобы соответствовать бизнес-требованиям и поддерживать удовлетворенность пользователей результатами, процесс сбора требований в Data Vault 2.0 является непрерывным.
• Тесное сотрудничество: Бизнес-пользователи и разработчики должны ежедневно работать над новыми функциями хранилища данных. Однако цель не в том, чтобы оперативно исправлять проблемы в продакшене. Они должны совместно разрабатывать новые функции в рамках текущего спринта. Оперативные исправления должны выполняться отделом эксплуатации, поэтому хранилище данных должно разрабатываться так, чтобы бизнес мог самостоятельно его поддерживать без вовлечения IT.
• Личное общение: Команды BI должны избегать переписки по электронной почте и вместо этого встречаться лично для решения текущих вопросов.
  Мотивация сотрудников: Мотивация часто основана на доверии и является двусторонним процессом.
• Техническое совершенство: Чтобы обеспечить долгосрочную удовлетворенность бизнес-пользователей, необходимо технически совершенное решение. Однако IT не должно стремиться достичь этого сразу. Вместо этого следует сфокусироваться на хорошем дизайне, который в конечном итоге приведет к созданию отличного продукта в гибкой манере. В этом помогает модель Data Vault 2.0, так как она обеспечивает расширяемость модели для добавления новых функций в будущих спринтах.
• Простота: Настоящие инженеры любят простые решения. Не добавляйте функции, которые не нужны бизнесу. Не модифицируйте модель Data Vault 2.0 системными атрибутами, если в этом нет реальной необходимости. Всякий раз, когда в решение добавляется сложность, для этого должна быть веская причина. Это упрощает поддержку конечного решения.
• Самоорганизующиеся команды: Члены команды несут ответственность за самоорганизацию вокруг поставленных задач.
• Регулярная адаптация: Команда BI несет ответственность за пересмотр прошлых решений и проверку их актуальности в изменившихся условиях или обстоятельствах. Эта обязанность может быть самой сложной, поскольку людям трудно признать ошибки. Однако решение, принятое шесть месяцев назад в тех условиях, не было ошибкой. Ошибкой было бы продолжать его придерживаться, если обстоятельства изменились.

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

Определение проекта

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

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

Зачастую архитекторы пытаются строить хранилище данных слой за слоем: они определяют начальный набор источников данных для генерации всех требуемых отчетов или OLAP-кубов (online analytical processing). Затем они реализуют весь слой стейджинга, загружая туда все исходные таблицы, включая ETL-процессы для их загрузки. После завершения слоя стейджинга они начинают моделировать корпоративное хранилище данных в максимально полном виде, поскольку дорабатывать его позже слишком дорого. После реализации ETL-пакетов создаются витрины данных, чтобы наконец удовлетворить потребности бизнес-пользователей. Такой подход обычно занимает месяцы, если не годы, включая несколько этапов отладки и исправления ошибок.

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

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

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

Рекомендуемый подход для достижения этой цели — использовать ограниченный (scoped) подход к инжинирингу требований и реализации отдельных функций, как показано на рисунке 3.11.

Рисунок 3.11 Определение границ отчета

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

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

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

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

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

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

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

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

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

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

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

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

Гибкий сбор требований

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

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

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

Задача состоит в том, чтобы показать эти отчеты пользователям и спросить их: «Что не так с этим отчетом?» Оказывается, что бизнес-пользователи могут легко указать на проблемы в отчете и, таким образом, предоставить все бизнес-правила, которые IT необходимо внедрить для создания финального отчета.

Процедура данного подхода к сбору требований включает следующие шаги:

• Идентификация необходимых данных: Как описано в предыдущем разделе, первый шаг — определить источники данных для Raw Mart и его отчета. Опять же, только данные, относящиеся к данному контексту, должны быть загружены в промежуточную область (staging area) и в корпоративное хранилище данных (enterprise data warehouse). Если возможно, объем данных следует уменьшить для ускоренного вывода. Например, данные, которые нужны только для финального отчета, но не для промежуточного необработанного отчета, следует исключить на этом этапе.
• Создание Raw Mart: После загрузки данных в Raw Data Vault на их основе создается Raw Mart. При загрузке Raw Mart не реализуются никакие бизнес-правила. Вместо этого данные просто переводятся из модели Data Vault в измерительную модель. Лучший подход для этого — использование виртуальных представлений (virtual views), так как их легко создавать.
• Создание Raw Reports: Как только данные попадают в измерительный Raw Mart, можно создавать Raw Reports (необработанные отчеты). Поскольку к данным не применены бизнес-правила, отчет содержит как хорошие, так и плохие, и проблемные данные.
  До этого момента IT контролирует время поставки. Они отвечают за то, чтобы быть гибкими до данного этапа. Следующие шаги выполняются уже со стороны бизнеса:

• Размещение Raw Reports на стене: Когда Raw Reports созданы на основе Raw Mart, они представляются участникам встречи по сбору требований. Хороший способ — распечатать их и повесить на одной стороне комнаты. Если это невозможно или непрактично, можно использовать LCD-проектор для демонстрации отчетов группе. Однако преимущество печатных отчетов на стене в том, что участники могут потратить столько времени, сколько им нужно, чтобы изучить отчет и добавить комментарии или исправления непосредственно на бумажную версию. Большинство проблем с отчетом становятся очевидными для участников. Они могут объяснить IT, в чем проблемы отчетов и почему их нельзя использовать в текущем виде.
• Сбор бизнес-правил и других требований: IT должно напрямую спрашивать участников, что делает отчет непригодным и как его можно сделать полезным для бизнеса. Какие изменения в данных необходимы, чтобы сделать их корректными? Ответы бизнес-пользователей содержат недостающие бизнес-правила, которые необходимо задокументировать в документе требований и применить к данным, загружаемым в Raw Report. Важно отметить, что следует меньше фокусироваться на оформлении отчета, поскольку этот вопрос должен решаться бизнесом и, в идеале, не должен зависеть от IT.
  Как только требования хотя бы частично собраны, IT снова берет на себя управление проектом, реализуя бизнес-правила и другие требования:
• Трансформация бизнес-правил и других требований: Последний шаг в этом цикле — перевод бизнес-правил и других требований, полученных от бизнеса и задокументированных в документе требований, в программную логику. Это можно сделать либо через ETL-потоки, либо виртуально в SQL-представлениях. Бизнес-правила превращают необработанные данные в информацию на пути от Raw Data Vault к Business Vault или Information Mart.

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

Рекомендуемая практика — записывать эти встречи по сбору требований и создавать Wiki или другой веб-ресурс с поддержкой Web 2.0, доступный для всех сотрудников организации. Записи встреч, включая описание выявленных бизнес-правил, должны быть опубликованы на этом веб-ресурсе, чтобы обеспечить прозрачность процесса сбора требований. Механизмы Web 2.0 позволяют участникам оставлять комментарии или даже модифицировать бизнес-правила в соответствии со своим пониманием. Такой подход гарантирует, что требования изначально будут корректными.

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

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

Оценка проекта

Процесс оценки в методологии Data Vault 2.0 основан на анализе функциональных точек (Function Point Analysis, FPA). Этот подход рекомендуется по сравнению с другими методами оценки, так как он предполагает разбиение функциональности на отдельные элементы, что в Data Vault 2.0 делать достаточно просто (благодаря стандартизированным артефактам). Используя FPA, члены команды оценивают необходимую функциональность хранилища данных, рассчитывая функциональные точки для отдельных элементов и оценочные часы, требуемые для их реализации.

Анализ функциональных точек

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

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

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

Например, одна и та же функциональность, запрашиваемая бизнес-пользователем, может потребовать 100 строк кода на C#, но 500 строк кода на C. Однако функциональные точки измеряют именно функциональность, предоставленную конечному пользователю, или ту, что будет предоставлена в будущем.

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

Рисунок 3.12 Функциональные характеристики программного обеспечения

Функциональные характеристики программного обеспечения включают:

• Внешние входы (EI, External Inputs) – данные, поступающие в систему.
• Внешние выходы (EO, External Outputs) и внешние запросы (EQ, External Inquiries) – данные, покидающие систему тем или иным образом.
• Внутренние логические файлы (ILF, Internal Logical Files) – данные, созданные и хранящиеся внутри системы.
• Файлы внешнего интерфейса (EIF, External Interface Files) – данные, которые поддерживаются вне системы, но необходимы для выполнения задач.

Оценка функциональных точек также включает оценку сложности системы в целом.

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

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

Измерение с использованием функциональных точек

Для измерения размера программной системы каждый из ее компонентов анализируется по характеристикам, описанным в предыдущем разделе. International Function Point User Group (IFPUG), организация, ответственная за анализ функциональных точек, рекомендует следующий порядок действий для выполнения измерения:

Шаг 1: Определение типа подсчета функциональных точек

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

• Подсчет функциональных точек для проекта разработки (Development project function point count)
• Подсчет функциональных точек для проекта улучшения (Enhancement project function point count)
• Подсчет функциональных точек для приложения (Application function point count)

Шаг 2: Определение границы подсчета

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

Шаг 3: Определение и подсчет типов функций данных

В предыдущем разделе были представлены два типа функций данных:

• Внутренние логические файлы (ILF, Internal Logical Files)
• Файлы внешнего интерфейса (EIF, External Interface Files)

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

Шаг 4: Определение и подсчет типов транзакционных функций

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

• Внешний ввод (EI, External Input)
• Внешний вывод (EO, External Output)
• Внешние запросы (EQ, External Inquiries)

Шаг 5: Определение необработанного количества функциональных точек

Количество функциональных типов, полученных на этапах 3 и 4, корректируется с учетом сложности.

Шаг 6: Определение коэффициента корректировки значений

Коэффициент корректировки значений (Value Adjustment Factor, VAF) отражает общую ценность системы для пользователя, оценивая ее общую функциональность. Величина VAF определяется по 14 характеристикам системы.

Шаг 7: Расчет итогового количества функциональных точек

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

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

Анализ функциональных точек для хранилищ данных

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

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

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

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

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

Границы в хранилищах данных

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

Рисунок 3.13. Границы приложения хранилища данных

На Рисунке 3.13 показано, что каждая функция включает:

• Таблицы промежуточного слоя (staging tables)
• Объекты в ядре хранилища данных
• Объекты витрины данных (data mart)

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

Отчеты

• Размерности и показатели в OLAP-кубе
• Элементы на панели мониторинга

Оценка размера

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

Таблица 3.2. Соответствие компонентов хранилища данных типам функциональных точек

Причина, по которой промежуточные таблицы (staging tables), находящиеся в границах хранилища данных, считаются внешними интерфейсными файлами (EIF), а не внутренними логическими файлами (ILF), заключается в том, что они в основном хранят внешние данные в виде прямой копии, дополненной простыми метаданными. Однако если к этим таблицам применяется внутренняя обработка, они считаются внутренними логическими файлами (ILF).

По той же причине целевые таблицы (target tables) считаются внутренними логическими файлами (ILF), а не внешними. Они обновляются данными, обработанными в пределах хранилища данных.

Маппинги (mappings) в хранилище данных реализуют требуемую логику путем извлечения данных из исходных таблиц, их преобразования и загрузки в целевые таблицы. Они считаются внешним вводом (EI), поскольку изменяют поведение системы за счет реализации бизнес-правил.

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

Системные оповещения (Process alerts) информируют внешние системы о статусах процессов ETL и, следовательно, считаются внешним выводом (EO).

Оценка факторов сложности ETL

Третья трансформация заключается в определении факторов, влияющих на сложность процессов ETL. Типичные факторы сложности представлены на Рисунке 3.14.

РИСУНОК 3.14 Диаграмма причин и следствий для факторов сложности ETL

Диаграмма показывает причины и следствия факторов сложности в типичных ETL-проектах. Однако не все эти факторы коррелируют с фактическими затратами усилий. Они зависят от организации и проектных команд. Чтобы выявить факторы, оказывающие влияние, требуется корреляционный анализ, например поэтапный метод регрессионного анализа (step-wise forward regression analysis).

Пример уравнения для регрессионного анализа в рамках конкретного проекта по хранилищу данных может выглядеть следующим образом (Уравнение 3.1):
Пример уравнения для регрессионного анализа:

Y=A⋅x5+B⋅x9+C⋅x15+D⋅x16+E⋅x19+F⋅(x2⋅x4)+G⋅(x3⋅x4)+H
Y=A⋅x5+B⋅x9+C⋅x15+D⋅x16+E⋅x19+F⋅(x2⋅x4)+G⋅(x3⋅x4)+H

Где:

x5: Количество целевых столбцов
x9: Тип трансформации
x15: Файл параметров, который необходимо изменить или создать
x16: Новое сопоставление (mapping)
x19: Неприведенные функциональные точки (unadjusted function points)
x2x4: Объем обработанных данных * Количество трансформаций (взаимосвязанные факторы)
x3x4: Критерии производительности * Количество трансформаций (взаимосвязанные факторы)

Фактическое уравнение для регрессионного анализа проекта также будет включать коэффициенты регрессии, которые в Уравнении 3.1 обозначены символами A–H.

Применение анализа функциональных точек к хранилищам данных

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

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

Процесс оценки должен поддерживать IT-команду, когда бизнес запрашивает оценку сроков или затрат усилий на реализацию запрашиваемой функциональности.

Способность предоставлять обоснованные оценки является ключевым требованием CMMI (Capability Maturity Model Integration) для достижения уровней зрелости выше начального/выполняемого уровня.

Например, FPA может применяться на уровне зрелости 2 (управляемый уровень) для:

• Квантификации объема функциональных требований в управлении требованиями.
• Оценки затрат усилий и стоимости в управлении проектами.
• Предоставления данных по функциональным точкам руководству и т. д.

Для выполнения процесса оценки с использованием FPA необходимо вести точные метрики по прошлым проектам разработки хранилищ данных.

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

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

Таблица 3.3 демонстрирует пример, который актуален в рамках одного конкретного проекта.

Таблица 3.3 Человеко-часы на один функциональный пункт (Person Hours per Function Point)

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

Как мы уже обсуждали ранее, количество функциональных пунктов зависит от функциональных характеристик разрабатываемого программного обеспечения. Чтобы использовать FPA (анализ функциональных пунктов) в методологии Data Vault 2.0, функциональные характеристики ПО (внешние входные данные, внешние выходные данные, внешние запросы, внутренние логические файлы и внешние интерфейсные файлы) пришлось адаптировать, чтобы они отражали специфику проектов Data Vault. Определены следующие функциональные характеристики хранилищ данных, построенных с использованием Data Vault:

• Загрузка стейджа
• Загрузка хаба
• Загрузка линка
• Загрузка сателлита
• Загрузка измерения
• Загрузка факта
• Построение отчёта

Аналогичным образом можно определить и другие функциональные характеристики, например, для PIT-таблиц (point-in-time), мостовых таблиц, сущностей Business Vault или OLAP-кубов. В целом, процедуры загрузки в Data Vault 2.0 представляют собой EtL-паттерны (маленькая «t» в «EtL» означает, что трансформация минимальна): для загрузки Raw Data Vault требуется минимальное преобразование сырых данных. Следовательно, функциональные пункты для таких трансформаций должны быть низкими, что приводит к высокой степени оптимизации, низкому уровню сложности и простым расчётам функциональных пунктов.

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

Таблица 3.4 Функциональные пункты и уровень трудозатрат

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

Оценочные функциональные пункты указывают количество функциональных пунктов, рассчитанных для данного типа элемента. Колонка Estimated Total Hours представляет собой произведение колонки Estimated Function Points из Таблицы 3.4 на значение Person Hours per Function Point из Таблицы 3.3.

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

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

Необходимо помнить, что данная таблица должна составляться индивидуально для каждого проекта и обновляться со временем. Может потребоваться дополнительное различение между менее или более сложными рабочими элементами (например, загрузками сателлитов в примере из Таблицы 3.4). Чтобы запустить этот процесс, важно следовать общей процедуре, описанной ранее, чтобы получить оценку функциональных пунктов, которая соотносится с фактическими трудозатратами на создание элементов, а также отслеживать количество человеко-часов, требуемых для реализации и тестирования этих функциональных пунктов.

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

Функциональные пункты для корпоративного хранилища данных

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

• Стейджинг-таблицы: Количество функциональных пунктов зависит от необходимого уровня нормализации. Рассмотрим случай плоских файлов в формате CSV, которые не требуют нормализации (для стейджинга), поскольку все колонки могут быть добавлены в стейджинг напрямую. Сравните это с файлами XML или COBOL, которые не так просто загрузить в реляционные таблицы, как файлы CSV, из-за наличия вложенных структур. Для загрузки таких данных требуется определённое усилие по нормализации, чтобы преобразовать данные из их структурированного формата в набор реляционных таблиц. Однако можно избежать этих затрат на нормализацию, загружая данные в иерархические таблицы (например, используя тип данных XML), что приведёт к (значительному) снижению производительности.
• Загрузки стейджинга и Data Vault: В зависимости от сложности ETL-процесса, необходимого для загрузки стейджинг-таблиц или сущностей Data Vault (таких как хабы, линки, сателлиты и т. д.), количество функциональных пунктов будет различаться. Функциональные пункты для хабов, как правило, одинаковы, независимо от размера или состава бизнес-ключа. В остальных случаях это правило не работает: чем больше хабов связано с линком, тем больше функциональных пунктов должно быть назначено из-за немного более сложного ETL-потока данных (однако все линковые связи между двумя хабами должны иметь одинаковое количество функциональных пунктов). Также влияют такие факторы, как количество атрибутов в сателлите, перегрузка сателлитов и их разбиение. Однако основное внимание следует уделять сложности самого маппинга для этой функциональной характеристики. Общее правило: хабы загружаются проще всего, линки — от простых до средних, а сателлиты часто загружаются со средней или высокой сложностью.
• Загрузки информационных витрин: В этих функциональных характеристиках ключевым фактором являются количество и сложность бизнес-правил, а также количество дополнительных колонок, реализуемых в процессе ETL-загрузки. Также важно учитывать, где именно реализуются бизнес-правила — в ETL или виртуально в SQL-представлениях. Кроме того, следует различать функциональные пункты для таблиц фактов, измерений, OLAP-кубов, реляционных отчётов и т. д.
• Загрузки Business Vault: Они схожи с информационными витринами, поскольку также включают реализацию бизнес-правил.

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

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

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

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

Как только команда определила, что и в каком объёме будет поставлено в предстоящем спринте, фокус смещается на выполнение проекта, которое рассматривается в следующем разделе.

Выполнение проекта

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

• Определить начальную архитектуру: Поскольку в рамках спринта нет времени на разработку окончательной архитектуры за один шаг, требуется начальная архитектура, позволяющая применять эволюционный подход.
• Моделировать детали «just-in-time»: Вместо того чтобы заранее моделировать всё корпоративное хранилище данных, моделируйте только те области, которые необходимы для реализации функционала в рамках текущего спринта.
• Раннее подтверждение архитектурных решений: Убедитесь, что архитектурные решения проверяются на ранних этапах. Лучше потерпеть неудачу в начале процесса и внести соответствующие изменения в архитектуру, чем столкнуться с проблемами позднее (что может привести к значительным затратам). Поздние изменения в архитектуре обходятся очень дорого.
• Фокус на использовании: Реализуйте только ту функциональность, которая имеет непосредственную бизнес-ценность.
• Избегайте стремления к «единой истине»: Фокусируйтесь на фактах и данных (подробнее об этом можно узнать в Главе 1, разделах 1.2.3 и 1.2.4).
• Организация работы по требованиям: Поскольку требования проще документировать и изменять, чем реализовывать или модифицировать саму реализацию, фиксация требований даёт значительную пользу для выполнения проекта.
• Активное участие заинтересованных сторон: Следуйте Scrum, проводя ежедневные стендапы. Убедитесь, что заинтересованные стороны присутствуют на этих встречах и участвуют в обсуждении.

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

Таблица 3.5. Цели гибкой поставки

Таблица 3.5 показывает, что команда выполняет внутри спринта «мини-водопад». Этот водопад следует традиционному жизненному циклу разработки программного обеспечения (SDLC), который кратко описан в разделе 3.2.1. Применение этих концепций в методологии Data Vault 2.0 рассмотрено в разделе 3.2.2.

Традиционный жизненный цикл разработки программного обеспечения

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

Рисунок 3.15 демонстрирует репрезентативную версию оригинальной каскадной методологии.

РИСУНОК 3.15. Каскадная модель

На рисунке показано, что данная модель включает пять этапов:

• Инженерия требований
• Проектирование
• Реализация и модульное тестирование
• Интеграционное и системное тестирование
• Эксплуатация и сопровождение

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

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

Инженерия требований

На этом этапе проектная команда собирает и аккумулирует все бизнес- и технические требования организации. Основным результатом данного этапа является документ «Определение хранилища данных» (Data Warehouse Definition), который эквивалентен документу «Спецификация требований к программному обеспечению» (Software Requirements Specification, SRS) в области разработки операционного ПО. Этот документ полностью описывает все необходимые функции и ограничения создаваемого хранилища данных, включая следующие требования:

• Требования к данным в рамках бизнес-областей
• Архитектурные требования
• Требования к аудиту
• Требования к архивированию

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

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

Традиционные методы включают следующее:

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

Современные методы включают следующее:

• Совместное проектирование приложений (Joint Application Design, JAD), при котором ключевые пользователи, менеджеры и системные аналитики совместно собирают системные требования.
• Прототипирование для дополнения процесса определения требований.

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

Проектирование

На этапе проектирования разработчики хранилища данных разрабатывают его архитектуру, включая уровни и модули системы. Определение архитектуры основывается на документе «Определение хранилища данных» (Data Warehouse Definition) и включает в себя описание баз данных для каждого уровня, таких как структура таблиц промежуточного слоя (staging area), таблиц уровня хранилища данных (data warehouse layer) и звездной схемы в витрине данных (data mart). Для каждой базы данных определяются названия и столбцы всех таблиц. Часто определение базы данных выполняется с использованием инструментов моделирования «сущность-связь» (ER), которые позволяют создавать и документировать структуру базы данных.

Microsoft SQL Server 2012 включает SQL Server Management Studio, который позволяет быстро создавать и заполнять каждый уровень хранилища данных, используя инструмент Visual Database Tool Designer.

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

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

Реализация и модульное тестирование

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

Microsoft SQL Server 2012 включает различные инструменты для создания хранилища данных. Большинство из них доступны в среде разработки Microsoft Business Intelligence Development Studio. В эту среду разработки входят следующие инструменты:

• SQL Server Integration Services – для интеграции данных
• SQL Server Analysis Services – для разработки многомерных хранилищ данных (OLAP-кубов) и выполнения задач интеллектуального анализа данных (data mining)
• SQL Server Reporting Services – для разработки отчетов на основе реляционных и многомерных источников данных

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

• OLAP-клиенты для удобного просмотра OLAP-кубов и расширенных возможностей отчетности
• Среды анализа данных для предоставления расширенных аналитических возможностей конечным пользователям
• Инструменты ER-моделирования для определения и документирования баз данных
• Инструменты автоматизации наполнения хранилища данных, такие как генераторы DDL (Data Definition Language)
• Инструменты профилирования данных для более глубокого понимания исходных данных
• Инструменты обеспечения качества данных для очистки и оценки данных

Интеграция и системное тестирование

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

РИСУНОК 3.16. Тестирование снизу вверх

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

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

Эксплуатация и сопровождение

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

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

Применение жизненного цикла разработки ПО к методологии Data Vault 2.0

Жизненный цикл разработки программного обеспечения применяется в рамках спринта методологии Data Vault 2.0 в виде мини-водопада. Для выполнения этого мини-водопада используется проектный план. В таблице 3.6 приведён пример реализации нового отчёта.

Таблица 3.6. Agile-план проекта

Идентификатор (ID) определяет задачу в инструменте управления проектами, таком как Microsoft Project. В основном он используется внутри системы, например, в колонке «Предшественники» (Predecessors), где указываются зависимости между отдельными задачами. Колонка WBS используется для добавления проектной референсной строки к задаче. В следующем разделе обсуждается, как использовать этот идентификатор.

Колонка «Название задачи» (Task Name) содержит читаемое пользователем название, а колонка «Длительность» (Duration) показывает примерное время, необходимое для завершения задачи. В дополнение к длительности во многих проектах добавляется колонка «Объём работы» (Work), которая оценивает трудозатраты. Это необходимо, так как трудозатраты и длительность задачи могут различаться, если над одной задачей работают несколько сотрудников на полной ставке. Этот параметр может использоваться дополнительно к оценкам, полученным с помощью анализа функциональных точек (см. раздел 3.1.4).

Большинство инструментов управления проектами, включая Microsoft Project, поддерживают необязательную колонку «Заметки» (Notes), которая не показана в таблице 3.6. Её можно использовать для включения ссылок на дополнительные зависимости (по их техническим номерам), чтобы идентифицировать оставшиеся артефакты. Эта концепция эквивалентна проектной референсной строке в колонке WBS и также будет описана в одном из следующих разделов.

Обратите внимание, что проектный план в таблице 3.6 показывает рассчитанную длительность для двухнедельного спринта с общим объёмом в 58 часов. В этом примере также предполагается использование инструментов автоматизации для загрузки данных в Data Vault через ETL (элемент 3.7). Если автоматизация не используется, рекомендуется добавить детализированные задачи для загрузки хабов, связей и спутников (под элементами 3.7.1, 3.7.2 и 3.7.3).

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

При этом следует учитывать, что длительность некоторых задач должна оставаться фиксированной, как показано в таблице 3.6 (например, процедура утверждения). Нет смысла увеличивать длительность на 50%, если таблица адаптируется под трёхнедельный спринт. В любом случае, длительность задач должна быть скорректирована в соответствии с потребностями проекта. Кроме того, этап определения границ проекта (задачи с ID 2–4) критичен для его успеха, но при этом не должен занимать более двух часов.

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

Проектный план также показывает, что в ходе проекта создаются определённые артефакты. Это не ограничивается только моделями баз данных или потоками данных ETL. Одним из ключевых аспектов методологии Data Vault 2.0 является создание документации, ценной как для бизнеса, так и для ИТ. Необходимая документация включает:

• Бизнес-глоссарий: Этот документ помогает в построении информационных витрин, так как в нём идентифицируются и документируются бизнес-объекты и связанные с ними термины.
• Документация по требованиям: Описывает информационные витрины и отчёты в деталях. В решении хранилища данных не должно быть функциональности, для которой нет соответствующего зафиксированного требования. Документ должен быть максимально кратким, например, использовать user story объёмом около одной страницы на каждое требование.
• Проектный план: Содержит только задачи, которые необходимо выполнить в течение одного спринта.
• Глоссарий сокращений: В этом документе приведены распространённые сокращения, используемые в бизнесе или в технологической области хранилищ данных.
• Документ об объёме работ (Scope) или заявлении о выполнении работ (Statement of Work): Описывает объём спринта и фиксирует достигнутые соглашения. Является важным источником для процедуры утверждения (sign-off) в конце спринта.
• Документ запросов на изменения: Любой запрос на изменение уже реализованных требований требует документированного процесса, который основан на этом документе.
• Документ приёмки и утверждения (Delivery and Sign-off Document): Когда проектная команда передаёт новую функциональность в конце спринта, требуется утверждение (sign-off) со стороны бизнеса перед её развертыванием. Этот документ подтверждает, что переданная функциональность соответствует или превышает ожидания, изложенные в документации по требованиям или в документе запросов на изменения.
• Роли и обязанности: Определяет роли в проектной команде и связанные с ними обязанности.
• Иерархическая структура работ (Work Breakdown Structure): Разбивает общее поставляемое решение (хранилище данных) на управляемые компоненты.
• Иерархическая структура процессов (Process Breakdown Structure): Каждый бизнес-процесс, поддерживаемый хранилищем данных, должен быть описан с помощью диаграммы бизнес-процесса. Он должен быть смоделирован с таким уровнем детализации, который позволяет идентифицировать наборы данных и их бизнес-ключи.
• Иерархическая структура данных (Data Breakdown Structure): Для каждого (включённого в спринт) бизнес-отчёта создаются две таблицы: одна сопоставляет отчёт с исходными таблицами, другая — с источником Data Vault для вывода информационной витрины.
• Иерархическая структура организации (Organizational Breakdown Structure): Отображает организационные связи и может использоваться для распределения ресурсов в проекте. Создаётся совместно с иерархической структурой работ. Также связывает отдельных членов команды с ролями, определёнными в документе «Роли и обязанности».
• Стандарты моделирования данных: Этот документ содержит соглашения по наименованию сущностей Data Vault, фактов, измерений и их атрибутов. В нём приводится информация о согласованных стандартах моделирования определённых сущностей, системных атрибутов и т. д.
• Стандарты ETL: Описывает реализацию потоков управления и данных, включая соглашения по наименованию, требования к документации, вопросы физического проектирования и другие аспекты.

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

На рисунке 3.17 приведён пример иерархической структуры организации.

РИСУНОК 3.17 Пример иерархической структуры организации

В этой структуре каждая роль связана с членом команды, чьё имя указано на диаграмме. Стандарты управления проектами, такие как Project Management Professional (PMP), требуют, чтобы в проектных планах отслеживались роли, а не конкретные люди, поскольку отдельные участники могут исполнять лишь часть роли в проекте, но каждая роль должна быть заполнена на 100%. В противном случае график проекта не сможет быть соблюдён. То же самое относится и к CMMI.

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

Параллельные команды

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

Команды используют те же шаблоны, которые определены в этой главе, и создают документацию, соответствующую тем же принципам. При реализации и поставке бизнес-требований команды, работающие параллельно, синхронизируют свои модели данных с помощью сущности «связь» (link entity), которая обсуждается в главе 5 «Моделирование Intermediate Data Vault».

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

• Загрузка из источника в stage: новые члены команды должны знать, как создавать новые stage-таблицы и загружать данные из исходных таблиц. В лучшем случае для этого требуется только выполнение CREATE TABLE и конструкции INSERT INTO … SELECT FROM в SQL.
• Загрузка из stage в hub и link: снова очень похоже и просто. Требуется лишь использование SELECT DISTINCT, некоторой фильтрации для обработки только отсутствующих записей и оператора INSERT INTO для загрузки hub-ов и link-ов.
• Загрузка из stage в satellite: при использовании только SQL-операторов необходимы SELECT DISTINCT, сравнение строк и INSERT для сохранения актуальных данных.

Этот список показывает, что для добавления дополнительных ресурсов в проект, где уже есть эксперты по Data Vault, не требуется много специализированных навыков Data Vault. Более опытные разработчики и моделировщики могут направлять новых участников команды при выполнении этих задач. Следует отметить, что эти навыки применимы к командам, работающим без ETL-инструментов. В дополнение к этим навыкам требуется знание выбранного ETL-инструмента, например Microsoft SQL Server Integration Services. В главе 12 «Загрузка Data Vault» рассматривается процесс загрузки данных в Data Vault с использованием Microsoft SQL Server.

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

Техническая нумерация

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

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

Примеры артефактов:

• Отдельная роль в документе о ролях и обязанностях
• Один запрос на изменение в документе запросов на изменения
• Отдельное требование в документе требований
• Одна задача в проектном плане
• Один бизнес-объект в бизнес-глоссарии
• Одна аббревиатура в глоссарии аббревиатур

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

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

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

• Требования → исходные таблицы: это, вероятно, самая мощная схема перекрёстных ссылок, так как она идентифицирует исходные таблицы и атрибуты, используемые конкретным требованием. Должна существовать одна строка на каждое требование, определяющая источники для всех требований. Это одна из структур разбиения данных, упомянутая в предыдущем разделе.
• Исходные таблицы → таблицы Data Vault: эта схема создаётся перед разработкой ETL-процессов для загрузки таблиц Data Vault и указывает соответствие между исходной таблицей и целевыми таблицами Data Vault.
• Таблицы Data Vault → таблицы витрин данных (information mart): аналогично предыдущей схеме, этот документ показывает, как данные сопоставляются между таблицами Data Vault и витринами данных. Этот документ должен представлять собой простую матрицу без указания бизнес-правил, так как они должны быть задокументированы в требованиях.
• Требования → таблицы витрин данных: эта матрица аналогична первой схеме и указывает таблицы витрин данных, используемые определёнными требованиями. Опять же, должна существовать одна строка на каждое требование. Это вторая структура разбиения данных, упомянутая в предыдущем разделе.

Лучший подход — предоставлять эти схемы в виде матриц перекрёстных ссылок в инструменте моделирования или (если лучший вариант недоступен) в таблицах, например в Microsoft Excel. Таблица 3.7 демонстрирует, как должна выглядеть структура разбиения данных.

Таблица 3.7 Пример соответствия требований таблицам витрин данных

Таблица 3.7 демонстрирует сопоставление требований с целевыми объектами, также известное как соответствие требований таблицам витрин данных. В ней описано, какие таблицы измерений или фактов витрин данных используются для конкретного отчёта или элемента OLAP. В данном примере представлены три отчёта:

• Passenger,
• Airplane Utilization и
• Connections.

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

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

Таблица 3.8 Примеры аббревиатур для типов артефактов

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

Обзор и улучшение

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

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

Первое собрание фокусируется на продукте: участники оценивают, соответствуют ли реализованные функции ожиданиям и зафиксированным требованиям. По этой причине в обсуждении участвуют все заинтересованные стороны, связанные с рассматриваемыми функциями. Если в ходе собрания выявляются проблемы или отклонения от определённых требований, необходимо создать запрос на изменение, который будет реализован в одном из последующих спринтов. Для проведения этого обзора команда должна быть способна чётко идентифицировать ожидаемые функции и проследить их происхождение до первоначальных требований. Именно поэтому техническая нумерация, описанная в разделе 1.2.4, играет важную роль в методологии Data Vault 2.0. Улучшение результатов проекта невозможно, если команда не может полностью определить источник возникших проблем, но это является ключевым условием успешной оптимизации проекта.

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

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

Six Sigma

Six Sigma играет важную роль в процессе улучшения. Принципы Six Sigma применяются для достижения максимальной оптимизации гибкости процесса построения и внедрения корпоративных хранилищ данных в соответствии со стандартом Data Vault 2.0. Six Sigma опирается на измерения (оценки vs. фактические показатели) или KPI, чтобы определить, что пошло не так на уровне проекта, насколько спринт отклонился от намеченного курса и какие действия необходимо предпринять, чтобы привести процесс в соответствие.

Это процессная часть Six Sigma, применяемая к «исправлению ошибок» или «оптимизации» процесса создания систем бизнес-аналитики. Важно отметить, что такие измерения и KPI должны оценивать команды, а не отдельных членов команды. Data Vault 2.0, как и другие гибкие методологии, включая Disciplined Agile Delivery (DAD), ставит людей на первое место. Если сотрудники понимают, что их индивидуальная продуктивность оценивается, они найдут способы обхода этих измерений. Кроме того, в некоторых юрисдикциях измерение продуктивности отдельных сотрудников является незаконным. Метрики следует рассматривать как возможные индикаторы производительности. Чтобы выявить реальные причины проблем в проекте, следует разговаривать с его участниками, так как именно они, скорее всего, лучше всего знают, что происходит.

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

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

Преимущества Six Sigma заключаются в том, что она:

• Обеспечивает контроль качества продуктов и услуг
• Создаёт инновационные методы повышения качества
• Обеспечивает полное удовлетворение потребностей клиентов
• Формирует устойчивую культуру качества

Ключевая концепция Six Sigma заключается в улучшении производительности процессов для достижения трех целей:

• Снижение затрат на процессы
• Повышение удовлетворенности клиентов
• Увеличение выручки и, следовательно, прибыли

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

Существует множество типов входных данных в процессах, применяемых в проектах по хранилищам данных:

• Трудовые ресурсы
• Материалы (например, офисные принадлежности)
• Решения
• Информация
• Измерения

Хотя для большинства производственных компаний основным выходным результатом процессов является продукт, в R&D-ориентированных организациях результатом также могут быть процессы или другие разрабатываемые материалы.

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

Возможно анализировать отклонения в результате процесса, измерять и визуализировать их. Существует три характеристики, описывающие эти отклонения:

• Расположение (Location) – среднее значение качества
• Разброс (Spread) – диапазон значений
• Форма (Shape) – характер распределения отклонений

Чем больше отклонений в процессе, тем ниже качество результата. Следовательно, вариативность является главным врагом контроля качества. Однако отклонения зависят от различных факторов внутри организации или проекта, которые представлены на Рисунке 3.18 «Треугольник производительности процесса».

Вариативность в Six Sigma эквивалентна стандартному отклонению, статистическому измерению разброса данных. В статистике это отклонение обозначается греческой буквой σ (сигма).

Шесть стандартных отклонений означают, что результаты процесса максимально приближены к совершенству. Как показано на Рисунке 3.18, другие важные факторы — это временной цикл (cycle time) и выход (yield).

Выход (yield) – это процент успешных результатов процесса, выраженный в процентах. Он показывает долю выходных данных с приемлемым качеством.

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

Источники вариативности

Причины вариативности многообразны. Вариативность подразделяется на общие причины (common causes) и специальные причины (special causes).

Общие причины (common causes) присутствуют в любом повторяющемся процессе с стабильным и предсказуемым распределением во времени. Их трудно устранить, так как они являются неотъемлемой частью процесса. Единственный способ уменьшить их – это пересмотреть сам процесс. Однако редизайн процесса может ввести новые вариации.
Верхняя часть Рисунка 3.19 показывает вариативность стабильного и предсказуемого процесса, обусловленную общими причинами.

Рисунок 3.19 «Общие и специальные причины вариативности»

Специальные причины (special causes) также называются назначаемыми причинами (assignable causes).

• Эти редкие и нестандартные факторы изменяют распределение процесса.
• Если не устранить их, они непредсказуемо повлияют на результаты процесса.
• Наличие специальных причин разрушает стабильность процессов.

Это показано в нижней части Рисунка 3.19.

Рисунок 3.20 «Прорывные результаты в Six Sigma».

Применение Six Sigma в разработке программного обеспечения

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

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

В контексте определения процесса, данного в этой главе, не важно, является ли процесс:

• импровизированным (ad-hoc),
• уникальным каждый раз,
• или высокоповторяющимся.

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

• время между началом и завершением этапа процесса,
• количество и качество выходных данных,
• ожидаемая производительность продукта,
• и др.

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

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

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

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

Команды Six Sigma могут сосредоточиться либо на повторяющихся задачах в проекте (например, на проверках), либо на человеческих факторах. В любом случае важно правильно нормализовать данные, чтобы убедиться, что сравнения корректны.

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

Еще одним источником вариативности является внедрение ПО в среду пользователя.

Каркас Six Sigma

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

Три основных элемента, которые определяют этот каркас:

• Приверженность высшего руководства
• Вовлечение заинтересованных сторон
• Стратегия улучшения

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

Все эти компоненты управляют тремя различными функциями Six Sigma:

• Проектирование по Six Sigma (Design for Six Sigma)
• Производственная Six Sigma (Manufacturing Six Sigma)
• Операционная (транзакционная) Six Sigma (Transactional Six Sigma).

Приверженность высшего руководства

Приверженность высшего руководства необходима, так как Six Sigma — это стратегическое управленческое решение, которое должно инициироваться топ-менеджментом.

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

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

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

В улучшение процессов по Six Sigma должны быть вовлечены:

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

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

• доступ к обучающим курсам
• участие в проектных командах
• оценка эффективности процессов

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

Обучение и система поясов

Успех любой инициативы Six Sigma зависит от квалифицированных участников, таких как сотрудники.

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

• процесс работы проектных команд
• методы внедрения требований клиентов

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

Для этого в Six Sigma предусмотрены стандартизированные уровни подготовки, обозначенные системой поясов из боевых искусств:

• Белые пояса (White Belts)
• Зеленые пояса (Green Belts)
• Черные пояса (Black Belts)
• Мастера черных поясов (Master Black Belts)
• Чемпионы (Champions)

Наибольшее значение имеют Зеленые и Черные пояса, так как именно они становятся ключевыми участниками команд Six Sigma.

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

Для работы проектных команд рекомендуется следующий порядок действий:

• Создать команду Six Sigma и установить долгосрочное управленческое видение для организации.
• Сначала обучить чемпионов Six Sigma.
• Выбрать бизнес-направления, в которых Six Sigma будет внедряться в первую очередь.
• Обучить Зеленые и Черные пояса.
• Назначить Черные пояса в качестве проектных менеджеров на полную занятость в критически важных процессах, чтобы сосредоточиться на ключевых проблемах качества.
• Укрепить инфраструктуру для поддержки Six Sigma, например, путем внедрения систем управления знаниями, статистического контроля процессов и систем управления базами данных.
• Убедиться, что высшее руководство следит за ходом работы команд Six Sigma. Ввести регулярный “День Six Sigma” и организовывать презентации или награждения за достижения.

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

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

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

Улучшение по DMAIC

Стратегия улучшения, представленная в предыдущем разделе, основана на шагах DMAIC — подходе, который также называется прорывным (Breakthrough) подходом.

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

• Требования, критичные для клиента
• Цели и задачи проекта
• Роли и обязанности команды
• Объем проекта и ресурсы
• Базовый уровень производительности процесса
• Карту процесса, включая поставщика, входные данные, процесс, выходные данные и клиента

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

• Устав проекта
• Анализ вовлеченности заинтересованных сторон
• Диаграммы аффинности
• Голос клиента (Voice of the Customer)
• Анализ качества
• Анализ силового поля (Force Field Analysis)
• Анализ Парето
• Картирование процесса

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

После выявления проблем в процессе следующий шаг — поиск корневых причин на этапе анализа (analyze phase). Возможности для улучшения приоритизируются по двум критериям:

• Их влияние на удовлетворенность клиентов
• Их влияние на прибыльность

На этапе улучшения (improve phase) внедряются выявленные на предыдущем шаге возможности для улучшения. Участники проекта разрабатывают несколько возможных решений и выбирают наиболее эффективное по результатам и производительности.

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

Последним шагом улучшения по DMAIC является этап контроля (control step). Его цель — контролировать улучшенные процессы и гарантировать устойчивость инициативы Six Sigma. Однако, если результаты улучшений, выполненных на предыдущих шагах, окажутся под угрозой, процесс улучшения DMAIC может начаться заново, как показано на Рисунке 3.21.

Применение Six Sigma к хранилищам данных

Оба типа встреч — обзор спринта (sprint review meeting) и ретроспектива (retrospective meeting) — являются обязательными, если организация стремится сократить длину итерации с четырех до трех недель или с трех до двух недель.

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

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

В некоторых случаях технологии могут помочь, например, развертывание blue-green (описано в Главе 8 «Физический дизайн хранилища данных») или автоматизация ETL-процессов.

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

Еще одним фактором являются сами люди:

• Дополнительное обучение может сократить продолжительность процессов
• Дополнительные и более качественные ресурсы (технологические, организационные и человеческие) также могут ускорить работу

С учетом этого подхода разницы между разработкой ПО и разработкой хранилищ данных в контексте Six Sigma практически нет. Поэтому к хранилищам данных применяются те же концепции, что и в разделе [«Применение Six Sigma к программному обеспечению»](см. предыдущий раздел).

Всеобщее управление качеством (Total Quality Management)

Для достижения высочайшего качества менеджеры и команды часто обращаются к Total Quality Management (TQM) — набору теорий, методов, техник и стратегий управления качеством, предназначенных для конкуренции на мировом уровне.

TQM — это управленческий процесс, в котором основное внимание уделяется постоянному улучшению качества.

Термин «Total» (Всеобщее) в TQM указывает на то, что каждый сотрудник организации и каждая функциональная единица должны участвовать в непрерывном совершенствовании качества.

В этом смысле:

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

Типичные действия в рамках TQM:

• Проектирование экспериментов
• Круги качества
• Ценностная инженерия
• Затраты на качество
• Информационные системы
• Методы Тагучи
• Общее продуктивное обслуживание
• Статистический контроль процессов
• Гарантия качества
• Устойчивый (робастный) дизайн
• Компьютеризированное проектирование
• Развертывание функций качества
• Непрерывное улучшение
• Партисипативное управление (участие сотрудников в управлении)

Не включены деятельности, имеющие значение только для производственной отрасли, такие как планирование производственных ресурсов (MRP — Manufacturing Resource Planning).

Однако некоторые подходы могут быть адаптированы к хранилищам данных, особенно к системам DWH, построенным по стандарту Data Vault.

Кроме того, ряд концепций TQM уже описан в других частях этой главы (или будет рассмотрен в следующих разделах). Например:

• Партисипативное управление уже применяется в Scrum: вместо того чтобы принимать решения на высшем уровне организационной структуры проекта, полномочия передаются на более низкий уровень.
• То же касается TQM: ответственность за качество распределяется максимально низко.
• Члены проекта должны иметь право принимать обоснованные решения для улучшения качества продукта или услуги.
• Эти решения принимаются без предварительного одобрения со стороны руководства.

Типичные инициативы по внедрению TQM следуют поэтапному подходу, состоящему из пяти фаз, представленных на Рисунке 3.22.

Рисунок 3.22 Успешное внедрение TQM в пять фаз

Как показано на рисунке, пять фаз включают:

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

Однако не стоит путаться из-за Рисунка 3.22.

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

Измерения качества данных

Так как методология Data Vault 2.0 фокусируется на управлении качеством данных в рамках TQM, стоит рассмотреть две методологии, которые могут стать частью инициативы TQM в хранилищах данных.

Обе методологии основаны на объективной оценке качества данных.

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

Таблица 3.10 содержит список основных измерений качества данных.

Оценка измерений качества данных может быть:

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

Полное управление качеством данных (Total Data Quality Management)

Первая методология — Total Data Quality Management (TDQM), которая применяет человеческие и количественные ресурсы для улучшения продуктов и услуг, аналогично TQM.
TDQM поддерживает миграцию баз данных, продвигает использование стандартов данных и применение бизнес-правил для улучшения баз данных.

В TDQM существует четыре циклические фазы, представленные на Рисунке 3.23.

Рисунок 3.23. Фазы TDQM

Фаза определения – анализируются данные и собираются бизнес-требования.
Определяется информационная система производства данных.
На выходе получается логический и физический дизайн информационного продукта с атрибутами качества.
Создаётся E/R-модель качества, которая определяет информационный продукт и качество данных.

Фаза измерения – определяются метрики качества данных и выявляются проблемы качества после их анализа.

Фаза анализа – анализируются выявленные проблемы качества данных, и определяются первопричины ошибок.

Фаза улучшения – выбираются ключевые области для улучшения, а также разрабатываются стратегии и методы.
Эти стратегии и методы применяются в фазе определения, когда цикл TDQM начинается заново.

Качество хранилища данных (Data Warehouse Quality)

Вторая методология — Data Warehouse Quality (DWQ), разработанная в рамках европейского проекта по качеству хранилищ данных.
Хотя в DWQ используются те же фазы, что и в Total Data Quality Methodology, их значение и взаимосвязь отличаются.
Рисунок 3.24 показывает процессный поток методологии DWQ.

Рисунок 3.24. Фазы DWQ

Входными данными для фазы определения являются:

• определение данных из операционных систем,
• перспективы заинтересованных сторон,
• информация о проекте и контексте хранилища данных.

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

Бизнес-пользователи и другие заинтересованные стороны взвешивают эти измерения качества.

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

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

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

Интеграция TQM с методологией Data Vault 2.0

В методологии Data Vault 2.0 TQM служит механизмом управления для применения гибких методологий, CMMI и Six Sigma.
Благодаря этому TQM связывает элементы улучшения из этих методов, чтобы постоянно совершенствоваться и превышать ожидания бизнес-пользователей, бизнес-спонсоров и других заинтересованных сторон.

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

• Ориентация на клиента: качество в контексте TQM определяется клиентом. В случае хранилищ данных бизнес-пользователь определяет качество артефактов, создаваемых в проекте хранилища данных. Поэтому именно пользователи решают, стоит ли усилие команды хранилища данных, обучение, постоянное совершенствование процессов и повышение качества затраченных ресурсов.
• Всеобщее вовлечение сотрудников: для достижения высшего качества артефактов хранилища данных каждый сотрудник должен участвовать в процессах постоянного улучшения. Руководство обязано создать необходимые условия для поддержки этих усилий. Процессы непрерывного улучшения должны быть интегрированы в обычные бизнес-операции.
• Ориентация на процессы: аналогично Six Sigma, TQM фокусируется на процессах. Это идеально подходит для Data Vault 2.0, где четко определенные процессы с четкими этапами приводят к ожидаемым результатам. Показатели производительности контролируются постоянно. Если возникают неожиданные отклонения от ожидаемых результатов, они фиксируются и передаются в управление проектом.
• Интеграция: TQM не ограничивается одной функциональной командой. Для достижения всеобщего качества требуется интеграция различных функциональных подразделений, обеспечивающая их взаимосвязанную работу.
• Стратегический и системный подход: тотальное качество не достигается случайно. Оно является результатом стратегического планирования и управления и включает интеграцию качества в стратегический план организации.
• Постоянное улучшение: TQM невозможно без непрерывного повышения возможностей организации. TQM управляет этими постоянными улучшениями.
• Принятие решений на основе фактов: процесс улучшения основывается на измерениях производительности. Для этого организация должна постоянно собирать и анализировать данные.
• Коммуникация: эффективная коммуникация необходима для поддержания мотивации сотрудников на всех уровнях организации.

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

Иногда, когда в отчетах или OLAP обнаруживается ошибочная информация, организация не следует рекомендованному подходу TQM для определения первопричины ошибки и ее устранения (вероятно, в исходной системе или бизнес-процессах). Вместо этого организация принимает решение исправить ошибку где-то между исходной системой и конечными отчетами. Если выбран такой подход, то единственно допустимый способ исправления ошибки в хранилище данных — применение мягких бизнес-правил на выходе из Raw Data Vault, например, используя Business Vault или при предоставлении информационного хранилища.
В главе 13 «Реализация качества данных» показано, как реализовать управление качеством данных в хранилище. Однако, с точки зрения TQM, цель этих усилий — создание замкнутого цикла процесса. Это достигается путем вовлечения бизнес-пользователей в выравнивание данных в исходных системах и исправление ошибок непосредственно в исходных системах, а не в хранилище данных.

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

Глава 9 расскажет о управлении эталонными данными (MDM), которое позволяет бизнес-пользователям участвовать в управлении данными и требует взаимодействия «менеджмента» и управления качеством данных. Эти же принципы применяются для устранения разрывов и согласования всех исходных систем в соответствии с концепцией эталонных данных, определяемой бизнес-пользователями.

В этой же главе рассматривается управляемая самостоятельная аналитика BI (Managed Self-Service BI), которая позволяет бизнес-пользователям напрямую взаимодействовать с данными в корпоративном хранилище, вносить исправления в режиме реального времени, а также публиковать сообщения, создаваемые в процессе Managed Self-Service BI. Эти сообщения передаются обратно в операционные системы через Service-Oriented Architecture (SOA) и Enterprise Service Bus (ESB).

Для этого необходима функция обратной записи (write-back capabilities), которая позволит бизнес-пользователям вносить исправления в исходные системы.

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

ГЛАВА 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.

Сообщение Перевод 2 Главы — Масштабируемая архитектура хранилища данных появились сначала на 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.