exam18 2
Реферат к лекции 18 (34): Аналитические и экспертные системы
Выполнил: Малаховецкий Дмитрий
Проверил: Афанасьев Вадим
Дэн Линстедт - изобретатель метода моделирования хранилища данных. Его путь начался в 90-х годах, когда он строил крупное корпоративное хранилище данных (EDW) для крупного оборонного подрядчика США. Он хорошо разбирался в традиционных методах моделирования (третья нормальная форма и размерное моделирование). Однако затраты на рефакторинг этих моделей, особенно по мере изменения бизнес-требований, с каждым днем становились все более проблематичными.
В результате он решил найти более эффективный способ моделирования данных, который обеспечил бы ему необходимую гибкость. Он потратил десять лет, с 1990 по 2000 год, в течение которых ему удалось создать метод моделирования Data Vault (свод данных).
Data Vault можно описать, как ориентированный на детали, отслеживающий историю и уникально связанный набор нормализованных таблиц, которые поддерживают одну или несколько функциональных областей бизнеса. Это гибридный подход к моделированию данных, включающий в себя лучшее из 3-й нормальной формы (3NF) и звездообразной схемы (Dimensional), которые являются традиционными методами проектирования Data Warehouse платформ.
Рассмотрим более детально:
- "Ориентированный на детали" - нацелен на принцип хранения данных с наименьшим доступным уровнем детализации (granularity).
- "Отслеживающий историю" - поддерживает концепцию, согласно которой все происходящие изменения должны фиксироваться (отслеживаться) в хранилище данных.
- "Уникально связанный" - описывает моделирование взаимосвязей, поскольку они (логически) существуют между бизнес-концепциями.
- "Нормализованных" - направлен на разделение основных бизнес-концепций, ключей (Hubs) и контекстуальных данных (Satellites).
Hub (хабы) – основное представление сущности (клиент, продукт, заказ) с позиции бизнеса. Таблица-Хаб содержит одно или несколько полей, отражающих сущность в понятиях бизнеса. В совокупности эти поля называются «бизнес ключ». Идеальный кандидат на звание бизнес-ключа это ИНН организации или VIN номер автомобиля, а сгенерированный системой ID будет наихудшим вариантом. Бизнес ключ всегда должен быть уникальным и неизменным.
Помимо натуральных ключей (например, "order_number"), хабы могут иметь следующие атрибуты:
суррогатный ключ – опциональный атрибут, который является обычно членом числовой последовательности ("order_hash_key");
временная метка загрузки – это дата и время, когда ключ впервые появился в БД ("load_date");
источник данных – записывается для трассировки данных ("record_source").
Links (ссылки) – ссылки связывают несколько хабов связью многие-ко-многим. Она содержит те же метаданные, что и хаб. Ссылка может быть связана с другой ссылкой, но такой подход создает проблемы при загрузке, так что лучше выделить одну из ссылок в отдельный хаб.
Satellites (спутники) - все описательные атрибуты хаба или ссылки (контекст) помещаются в таблицы-спутники. Помимо контекста таблица-спутник содержит стандартный набор метаданных (временную метку загрузки и источник записи) и только один ключ «родителя». В спутниках можно без проблем хранить историю изменения контекста, каждый раз добавляя новую запись при обновлении контекста в системе-источнике. Для хаба или ссылки может быть сколь угодно спутников, обычно контекст разбивается по частоте обновления. Контекст из разных систем-источников принято класть в отдельные спутники.
Point-In-Time (момент времени) - является производной от спутника. Используется для обеспечения поиска информации для заданных моментов времени.
Bridge (мост) содержит временные метки последней загрузки. Эта сущность подобна сущности момент времени, но охватывает всю предметную область или схему данных. Бизнес-пользователи часто хотят видеть данные, сгруппированные различным образом. В простейшем случае одно подразделение (к примеру, отдел маркетинга) имеет свою иерархию покупателей, а другое подразделение (к примеру, отдел продаж) имеет другую иерархию тех же покупателей. Можно включить обе иерархии в измерение "Покупатель". Однако несколько иерархий, встроенных прямо в измерение, сделают его малопригодным для использования. Для поддержки дополнительных иерархий в хранилище создается отдельная таблица, с помощью которой пользователь может сгруппировать данные по любой из имеющихся иерархий. Это и есть сущность-мост, или таблица-мост (bridge table).
User Grouping Link (сущность-связь для группировки пользователей) - содержит информацию, которая предоставляет пользователю определенную точку зрения на данные, но не влияет на их содержание в хранилище данных.
При создании модели Data Vault необходимо сначала создать сущности и описать их атрибуты, а затем установить связи между ними. Сущности должны создаваться в следующем порядке:
- Хабы (Hub) должны содержать бизнес-ключи предметной области.
- Ссылки (Link) для поддержки взаимосвязей между бизнес-ключами, т.е. информация о деятельности организации в контексте бизнес-ключей.
- Спутники (Satellite) для описания полной картины деятельности организации с точки зрения бизнес-процедур.
- Моменты времени (Point In Time) для обеспечения поиска моментов времени изменения описательной информации.
При создании связей в структуре модели Data Vault следует соблюдать правила поддержки ссылочной целостности (Referential integrity):
- Ключи Hub не могут мигрировать в другие концентраторы, т.е. не поддерживается отношение «родитель-потомок» для Hub.
- Hub взаимодействуют между собой через Link таблицы.
- Сущность-Link может быть использована для связи более двух Hub.
- Сущности-Link могут быть связаны друг с другом.
- Сущности-Link должны связывать минимально два Hub.
- Суррогатные ключи могут использоваться для Hub и Link.
- Бизнес-ключи Hub никогда не изменяются, так же, как и их первичные ключи.
- Satellite могут связываться с Hub и Link.
- Могут быть использованы стандартные таблицы временных меток (standalone table), такие как календарь, время, код и описание.
- Satellite всегда содержат либо временную метку загрузки, либо числовой указатель на временную метку загрузки (на стандартные таблицы временных меток).
- Сущности-Link могут иметь суррогатные ключи.
- Если Hub имеет более двух Satellite, то может быть создана сущность Point In Time.
- В Satellite не должно быть строк-дубликатов.
- Данные в Satellite разделяются по типу информации или по скорости изменения.
Последовательный подход к загрузке данных в корпоративное хранилище
Сперва первичные данные из бизнес-приложений поступают в операционный слой Stage area. Здесь не происходит никакой трансформации: таблицы полностью повторяют исходную структуру, а все ограничения на вставку данных или проверку целостности внешних ключей отключаются. Это делается, чтобы оставить возможность работы с поврежденными или неполными данные. Также здесь выполняется дополнение таблиц метаданными по модели: создаются хеши бизнес-ключей, вставляется информация о времени загрузки (load timestamp) и источнике данных (record source).
Далее данные разбиваются по типам сущностей: Хабы, Ссылки и Спутники;
Затем выполняется загрузка в область сырых данных - Raw Data Vault, при этом не происходит агрегирования и пересчета. Сначала загружаются Хабы, потом Ссылки, а в конце — Спутники. Возможна параллельная загрузка при отсутствии связей link2link.
Наконец, структурированные по модели Data Vault данные попадают в область Business Vault — опциональную вспомогательную надстройку над Raw, где хранятся уже в переработанном виде: агрегированные результаты, сконвертированные валюты и т.д.
Разделение на Business Vault и Raw Data Vault лишь логическое, физически обе эти базы находятся в одном месте и необходимо для упрощенного формирования витрин данных (Data Mart). Обычно каждая витрина представлена в виде отдельной СУБД или схемы для решения конкретных бизнес-задач. Поэтому в Data Mart может быть реализована своя «звезда» или «снежинка». По возможности таблицы внутри витрин следует делать виртуальными — вычисляемыми «на лету». Для этого обычно используются SQL-представления (SQL views).
Нарушение целостности данных - например, отсутствие записей в нескольких хабах, выявленное при загрузке таблиц-ссылок. Решить это можно перезапуском ETL-процесса (процесс приведения данных из нескольких разных учетных систем к одним справочникам и их загрузка в хранилище данных) или отключением механизма предварительной проверки данных, делая проверку данных уже после их загрузки в Stage area.
Сложности работы в режиме реального времени, когда данные приходят настолько быстро, что ETL-системы не успевают оперативно поместить их в буферную область, очистить и подготовить к загрузке в корпоративное хранилище данных. Чтобы ускорить этот процесс, при работе в режиме реального времени (near real-time) таблицы-ссылки и спутники заполняются почти одновременно с родительскими хабами. Организовать это помогают принципы массивно-параллельной архитектуры (massive parallel processing, MPP), реализованные в Data Vault 2.0.
Подводя итог, можно сказать, что модель Data Vault является альтернативой более традиционным подходам в моделировании хранилищ данных по следующим причинам:
- возможность поддержки разнообразия и количества данных, поступающих из исходных систем, т.е. масштабируемость;
- возможность поддержки частых изменений, которые требуются при использовании гибкой практики разработки программного обеспечения (Agile);
- возможность предоставить бизнес-пользователям контекстуальное представление данных, где они могут легко исследовать и анализировать данные, полученные из различных источников.
Что такое Data Vault: моделирование КХД для архитектора Big Data
Пример проектирования модели "Свод данных"
Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop