Как спроектировать КХД: 4 метода моделирования данных для архитектора Big Data

Автор Категория , ,
Как спроектировать КХД: 4 метода моделирования данных для архитектора Big Data

Сегодня мы поговорим о проектировании архитектуры корпоративных хранилищ данных (КХД) и рассмотрим, какие методы и инструменты используются для моделирования структуры DWH и динамики ETL-процессов. В этой статье про основы Data Modelling разберем, что такое OLAP и OLTP, почему 3-я нормальная форма стала стандартом в SQL-СУБД, чем схемы звезды отличается от снежинки, как подход Data Vault оптимизирует работу Apache Hadoop и какова польза всех этих методов для архитектора Big Data.

Краткий обзор методов моделирования данных

Все методы моделирования данных можно разделить на 2 группы: структурные и процессные. Реляционная парадигма, актуальная для типовых КХД, фокусируется на определении сущностей и взаимосвязей между ними, чтобы затем представить эти концепции в виде связанных таблиц с помощью ER-диаграмм (Entity-Relationship). Для описания потоков движения данных в бизнес-анализе используются DFD-диаграммы (Data Flow Diagram). DFD-схемы наглядно показывают обмен информацией между хранилищами данных (не в смысле КХД, а скорее, базы-источники, потребители и прочие места хранения), внутренними процессами системы и внешними по отношению к ней сущностями. Данный динамический метод можно использовать при концептуальном проектировании Big Data решений, когда определяются основные источники и потребители данных, а также процессы их обработки, в частности, ETL. Такая визуализация пригодится при проектировании современных КХД, интегрированных с озерами данных (Data Lake) и облачными сервисами расширенной аналитики Big Data.

Возвращаясь к структурному дизайну DWH, отметим 3 наиболее распространенных метода моделирования [1]:

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

Инструментально все эти методы реализованы в виде различных CASE-средств, которые позволяют создавать ER-диаграммы и проверять их корректность. Часто они входят в состав платформ для создания DWH, например, как это сделано в SAP BW∕4 HANA.

DFD, DWH, Data Lake, моделирование потоков данных, Data Flow Diagram
Пример DFD-диаграммы для процессов работы с данными в DWH и Data Lake

Как появился Data Vault или недостатки 3NF и звездных схем для КХД

Поскольку исторически DWH возникли из реляционных СУБД, они унаследовали также и подходы к проектированию, принятые в этой области. В частности, использование 3NF – третьей нормальной формы, когда каждый неключевой атрибут таблицы должен предоставлять информацию о лишь о полном ключе и ни о чём более. Напомним, в теории СУБД, нормальная форма – это совокупность требований, которым должно удовлетворять отношение, чтобы избежать избыточности, которая может привести к логически ошибочным результатам выборки или изменения данных. 3NF избавляет от транзитивных зависимостей: любой столбец таблицы зависеть только от ключевого столбца, что позволяет обеспечивать целостность данных в СУБД [2]. Этот подход был создан в 60-70хх гг. XX века Эдгаром Коддом (Edgar F. Codd) и Кристофером Дейт (Christopher J. Date) для систем оперативной обработки транзакций в реальном времени (OLTP, Online Transaction Processing). В начале 1980-х концепция 3NF была адаптирована для проектирования КХД, когда к первичным ключам каждой таблицы добавилась временная метка (date-time stamp). Однако такое применение этого подхода показало его следующие недостатки [3]:

  • проблемы масштабируемости и гибкости из-за сильной связанности таблиц, когда добавление дополнительной родительской таблицы вызовет каскадные изменения всех нижележащих подчиненных таблиц. А при вставке новой строки с существующим родительским ключом все дочерние строки должны быть повторно переназначены на новый родительский ключ.
  • зависимость первичного ключа от времени и от вышеупомянутой связанности таблиц;
  • трудности загрузки в режиме near real-time;
  • трудоемкие запросы;
  • проектирование «сверху вниз» и соответствующая top-down (нисходящая) реализация.

Чтобы обойти эти недостатки, со второй половине 1980-х в моделировании данных стала использоваться схема звезды (Star schema), удобная для хранения многомерных показателей. Именно эта модель лежит в основе витрин данных (Data Mart) – срезов КХД или реляционных OLAP-кубов в BI-системах для интерактивной аналитической обработки данных (Online analytical processing). При этом таблица фактов (центр звезды) содержит агрегированные данные для составления отчетов, а денормализованные таблицы измерений (лучи) описывает хранимые данные. Модификацию звездной схемы, когда отдельные таблицы измерений нормализованы с целью сокращения избыточности и определения всех зависимостей, называют «снежинкой». Она использует меньше дискового пространства и лучше сохраняет целостность данных. Недостаток снежинки в сложности запросов для доступа к данным из-за увеличенного числа соединений таблиц [4].

Предметно-ориентированные звездные схемы, приспособленные для мульти-предметных КХД, чтобы удовлетворить возрастающие потребности enterprise сектора в DWH-продуктах, называются согласованные витрины данных (Conformed Data Marts). По сути, согласованные витрины данных – это нескольких взаимосвязанных звездных схем, набор таблиц фактов, связанных через первичные/внешние ключи. Для этой модели также характерен ряд проблем, которые затрудняют ее применение в современных КХД [3]:

  • изолированность предметно-ориентированной информации;
  • возможная избыточность данных;
  • несовместимые структуры запросов;
  • трудности масштабируемости;
  • несовместимая степень детализации таблиц фактов, которая усложняет их связывание, а также ограничивает дизайн, масштабируемость и гибкость модели данных;
  • проблемы синхронизации при загрузках в режиме near real-time;
  • ограниченные представления корпоративной информации;
  • неудобная среда для интеллектуального анализа данных (Data Mining);
  • необходимость проектирования «сверху вниз» с реализацией «снизу вверх».

Чтобы исправить эти недостатки и сделать проектирование КХД боле эффективным, в начале 2000-х годов была предложена модель Data Vault, основанная на реляционных принципах, нормализации данных и математике избыточности. В отличие от 3NF и звездных схем, она по-другому представляет отношения между сущностями, а также иначе структурирует поля таблиц и временные метки. Благодаря этому Data Vault может хранить больше детальных данных в меньшем физическом объеме, по сравнению с 3-ей нормальной формой и звездой [3]. Это преимущество актуально не только для реляционных сред, а сохраняется и в NoSQL-парадигме, когда данные могут храниться с использованием разных схем (хэш-таблицы, документы, графовые деревья, разреженные матрицы). Поэтому Data Vault позволяет сэкономить место и в HDFS, благодаря чему этот подход эффективен для построения не только КХД, но и для озер данных (Data Lake). Именно поэтому он был выбран Big Data архитекторами банка Тинькофф для проектирования озера данных, построенного по LSA-принципу и интегрированного с корпоративным DWH [5]. Подробнее об этом решении мы рассказывали здесь.

Data Warehouse, DWH, КХД, корпоративное хранилище данных, проектирование КХД, звезда и снежинка,
Схемы звезды и снежинки для проектирования DWH

В следующей статье мы рассмотрим, ключевые понятия Data Vault, а также основные принципы этого подхода к моделированию данных. А как использовать все это на практике при разработке КХД и Data Lake для эффективного хранения больших данных, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

  1. http://iso.ru/ru/press-center/journal/1682.phtml
  2. https://ru.wikipedia.org/wiki/Нормальная_форма
  3. http://www.dwh-club.com/ru/dwh-bi-articles/data-vault-terminy-obekty-osnovy-arhitektury.html
  4. https://habr.com/ru/post/441538/
  5. https://habr.com/ru/company/tinkoff/blog/259173/