Статья посвящена последним достижениям в области таких современных и актуальных на сегодняшний день технологий, как хранилища данных. Рассматриваются основные особенности проектирования хранилищ данных, их роль в современном мире, преимущества использования, назначение и типы задач, решаемые системами такого класса. Проводится краткий обзор основных типов хранилищ данных и особенностей их архитектуры.
Ключевые слова: хранилище данных, витрина данных, enterprise data warehouse, dimensional, измерение, таблица фактов, нормализация, реляционная модель, база данных, data mart, БД, СУБД, ХД.
Введение
Среди современных информационных технологий можно выделить такое направление, как технология хранения данных. Важность этой технологии состоит не только в том, чтобы обеспечить хранение и безопасность данных, но и, учитывая тот факт, что объемы хранимой информации увеличиваются со временем в геометрической прогрессии, обеспечить доступность и высокую производительность обработки накапливаемых данных. Наряду с другими направлениями информационных технологий, рассматриваемая область не стоит на месте. Растет многообразие и сложность решений для хранения и обработки данных. В данной статье рассматриваются особенности проектирования и разновидности современных хранилищ данных.
Технологии хранения данных
Для того чтобы лучше понимать суть проектирования хранилищ данных (ХД) и причины появления их разновидностей рассмотрим, для начала, базовые понятия в технологиях хранения данных и какие виды ХД могут быть реализованы. Стоит обратить внимание, что ХД — это база данных (БД), спроектированная определенным образом и обладающая такими свойствами, чтобы удовлетворить потребности предприятия и решить те задачи, ради которых оно было создано. Но при этом важно различать между собой понятия БД и ХД, т. к. в классическом понимании они имеют существенные отличия. Для того чтобы хорошо ориентироваться в технологиях проектирования БД и ХД, в ключевых понятиях, рассматриваемых в данной статье, а также для четкого понимания разницы между системами такого класса, как БД и ХД рекомендуется статья М. В. Коновалова [2]. Приведенные в указанной работе обзор и результаты исследований, которые послужили основой для текущей публикации, очень значимы для понимания теории разработки таких систем. Также в статье М. В. Коновалова [2] оригинально и глубоко выполнен анализ рассматриваемых технологий, логично и обоснованно разобраны основные вопросы, которые необходимо прорабатывать на начальных этапах проектирования, чтобы избежать существенных дополнительных расходов в будущем. Грамотно выполнен обзор с использованием информации из компетентных источников, освещены ключевые особенности проектирования реляционных систем. Материал, изложенный понятно и на высоком профессиональном уровне, помогает найти ответы на многие вопросы, возникающие при разработке подобного класса систем, и рекомендуется специалистам, желающим существенно расширить компетенцию в области проектирования БД и ХД.
Рассмотрим такое понятие, как нормализация. Это одно из ключевых свойств БД, целью которого является минимизация избыточности и противоречивости данных. Нормализация в БД приводит к тому, что создается большое количество связанных между собой таблиц. В результате, выполнение сложных запросов приводит к тому, что необходимо объединить между собой большое количество таблиц, что неизбежно приводит к увеличению времени работы запроса. Нормализация делает модель ХД слишком сложной, затрудняет ее понимание и ухудшает производительность выполнения запросов. На примере нормализации и других свойств, профессионально и наглядно рассматриваются особенности и принципиальные отличия разработки БД и ХД в работе М. В. Коновалова [2]. Крайне ценны современный взгляд и грамотный, аргументированный подход, применяемые в процессе исследования таких сложных, с точки зрения архитектуры, систем и с учетом бурно развивающегося рынка ИТ-индустрии. Также о большом практическом опыте и глубокой экспертизе автора в данной области говорит структурированный анализ современных ИТ-решений, предоставляемых лидирующими мировыми производителями, и их положение на сегодняшнем рынке.
Создание ХД подразумевает ненормализованную структуру данных, в которой возможна избыточность. Т. е. это реляционная БД, обладающая избыточностью в следствии агрегированности. Рассмотрим подробнее, в чем заключается эта избыточность, агрегированность и где она проявляется. Суть в том, что один и тот же показатель может встречать несколько раз: в виде ежедневной агрегации, ежемесячной, ежегодной и т. д. Также могут встречаться аномалии при манипулировании данными. Такое ХД ориентировано, прежде всего, на высокую производительность при выполнении не стандартизованных, аналитических запросов.
На самом деле из-за такой ненормализованности, БД уже не может считаться реляционной. Потому что в реляционной БД не допускается такое хранение данных, когда одни и те же значения встречаются по несколько раз. Такая БД называется пространственной, а технология — dimensional. Моделирование по технологии Dimensional сходно с моделированием связей и сущностей для реляционной модели, но отличаются целями. Реляционная модель акцентируется на целостности и эффективности ввода данных. Модель dimensional (или модель измерений) ориентирована в первую очередь на выполнение сложных запросов к БД и высокую скорость извлечения любого массива, т. к. эта информация уже содержится в готовом виде. Ее не нужно собирать готовить, обрабатывать, но вместе с тем присутствует избыточность. В этом заключается одно из основополагающих отличий между технологиями реляционной модели и dimensional.
Особенности проектирования ХД
В целом, проектирование ХД во многом схоже с проектированием классической БД, но при проектировании ХД важно учитывать такую схему, когда ключевые выходные данные, которые нужны для анализа, передаются в центральную таблицу, вокруг которой формируется ряд справочников. Эта особенность также характеризует технологию dimensional, которая при проектировании схожа с моделированием связей и сущностей для реляционной модели, но, как упоминалось выше, отличается целями.
Итак, самая простая базовая схема для построения ненормализованной пространственной БД, называемой ХД — это схема «Звезда» (или «Star Schema», см. Рис. 1). Это может быть одна или несколько центральных таблиц, которая называется таблицей фактов. В этой таблице содержатся результирующие показатели, т. е. интересующие в первую очередь, данные, которые требуется в дальнейшем анализировать. Такими данными могут быть, например, транзакции, клиентские операции, другими словами — результаты финансовой деятельности компании. И также есть родительские таблицы (справочники, различные нормативные данные), информацией из которых сопровождается каждый факт центральной таблицы. Эти таблицы называются измерениями. Таким образом, существуют связи между таблицей фактов и таблицами измерений. Эти связи зависят от времени — это означает, что в определенный момент времени каждой записи из таблицы фактов соответствует определенная запись из таблицы измерений. Как отмечено в работе М. В. Коновалова [2], зависимость от времени является одной из важнейших особенностей ХД, которая необходима для поддержки историчности данных, возможности построения различных моделей, зависимых от времени не только на конкретную дату, но и за период, а также для прогнозирования. В указанной статье агрегированы и оригинально представлены самые важные свойства, определяющие архитектуру таких информационных систем как БД и ХД. Уникальность и новизна исследований состоят в сформулированных зависимостях между ключевыми свойствами, а также в логичном и последовательном разъяснении их принадлежности к системам подобного класса.
Итак, технология dimensional подразумевает создание большой таблицы фактов и ряда таблиц — измерений.
Особенности схемы «звезда» заключается в том, что этот стандарт модели в размерном моделировании обеспечивает высокую скорость выполнения запросов посредством денормализации и разделения данных на справочники.
Схема «звезда» проектируется каждый раз индивидуально, в зависимости от предметной ориентированности и направления организации, для которой она разрабатывается, т. к. меняться будут как фактические показатели, так и измерения. Невозможно создать универсальную денормализованную структуру данных, обеспечивающую высокую производительность при выполнении любого аналитического запроса. Поэтому схема «звезда» строится так, чтобы обеспечить наивысшую производительность при выполнении одного самого важного запроса, либо для группы однотипных, схожих по структуре, запросов.
Рис. 1. Схема хранилища данных «звезда»
Другой, более сложной схемой проектирования ХД называется «снежинка». В центре такой схемы также находится таблица фактов. По сути, это схема «звезда», в которой таблицы измерений нормализованы. В результате схема по своей структуре напоминает снежинку. Чем больше степень нормализации таблиц измерений, тем сложнее выглядит структура схемы «снежинка». Такая схема позволяет обеспечить значительно более глубокий уровень детализации за счет нескольких уровней связанных таблиц. Нормализация таблиц измерений, в отличие от схемы «звезда», позволяет минимизировать избыточность данных и более эффективно выполнять запросы, связанные со структурой значений измерений. Но за нормализацию таблиц измерений не редко приходится расплачиваться временем выполнения запросов. Особенно это касается аналитических запросов, когда необходимо выбирать и агрегировать большие объемы данных из большого числа таблиц.
Прежде чем создать ХД со схемой типа «звезда», необходимо проанализировать бизнес-правила предметной области с целью выяснения центрального вопроса, ответ на который наиболее важен в решении задачи: Какие ключевые потребности? Что требуется проанализировать? Что моделировать, прогнозировать? Что интересует? — Все прочие вопросы должны быть объединены вокруг этого основного вопроса и моделирование должно начинаться с него. Данные необходимые для ответа на этот вопрос должны быть помещены в центральную таблицу модели — таблицу факта.
Таблицы фактов иизмерений
Таблица фактов является основной таблицей ХД. Как правило, она содержит сведения об объектах или событиях, совокупность которых требуется анализировать. Обычно наиболее часто встречаются 4 типа фактов. К ним относятся:
‒ факты, связанные с транзакциями (Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата). Т. е. это факты каких-либо действий;
‒ факты, связанные с «моментальными снимками» (Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например, на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка. Т. е. это результаты по прошествии какого-то времени. Цена открытия, закрытия, дневная цена и т. д.;
‒ факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки). Т. е. в данном случае речь идет об элементах каких-то бумажных документов;
‒ факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют собой возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).
Таблицы измерений содержат неизменяемые либо редко изменяемые данные. Они также содержат как минимум одно описательное поле (обычно с именем члена измерения) и, как правило, целочисленное ключевое поле, обычно это суррогатный ключ для однозначной идентификации члена измерения. Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов. Скорость роста таблиц измерений должна быть незначительной по сравнению со скоростью роста таблицы фактов. Например, добавление новой записи в таблицу измерений, характеризующую товары, производится только при появлении нового товара, не продававшегося ранее.
Таблица фактов, которая является центральной таблицей, может состоять из сотен миллионов строк и содержать суммирующие или фактические данные, которые призваны помогать отвечать на требуемые вопросы. Она соединяет данные, которые хранились бы во многих таблицах традиционных БД. Таблица фактов и таблицы измерений связаны идентифицирующими связями, при этом первичные ключи таблицы измерений мигрируют в таблицу факта в качестве внешних ключей. В размерной модели направление связей явно не показывается, они определяются типом таблиц. Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа дата/время, т. к. из-за размеров таблицы, хранить в ней повторяющиеся текстовые описания, как правило, не выгодно. Лучше поместить их в меньшие по объему таблицы измерений. Поэтому в таблице фактов, как правило, не хранят тексты, тем более повторяющиеся, т. к. это значительно увеличит ее размер. Как правило, в ней ключи в виде кодов. А все тексты (расшифровка) — в измерениях. Помимо этого, таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут получены агрегатные данные.
Разновидности ХД
Существует два основных вида ХД: корпоративные ХД и киоски данных.
Корпоративное ХД (enterprise data warehouse) — содержит информацию обо всех сторонах деятельности предприятия. Обычно оно формируется на основании данных, касающихся нескольких различных аспектов деятельности организации, например, клиентов, продуктов и продаж, и служит для поддержки принятия тактических и стратегических решений.
Киоски (или витрины) данных — еще одна из разновидностей ХД. Поскольку создание ХД — это сложный трудоемкий и дорогостоящий процесс, и разработка полноценного ХД может занять несколько лет, альтернативой может быть витрина данных или data mart. Это небольшая часть ХД или отдельное самостоятельное ХД, которое предметно-ориентировано для какого-либо департамента, подразделения или небольшого предприятия. Например, может содержать информацию о клиентах, счетах, продуктах. Не включать информацию об операциях (фактических и плановых) и т. д.
Витрины могут разрабатываться вместе с основным ХД, предоставляя подразделениям определенный ограниченный набор данных о какой-либо предметной области. Витрины строятся значительно быстрее ХД, но в последствии могут возникнуть сложности с интеграцией, если при разработке не были учтены все детали бизнес-модели.
На практике промышленное ХД не обязательно принадлежит строго одному из двух указанных выше типов. Например, скорость обработки данных и сроки предоставления результирующих данных на базе корпоративного ХД для поддержки принятия тактических и стратегических решений корпорации могут не удовлетворять потребностям некоторых отделов или направлений бизнеса. Поэтому наряду с полноценными enterprise data warehouse в компании могут создаваться, так называемые, оперативные ХД, которые, за счет меньшего объема, способны значительно быстрее предоставить необходимые данные своим заказчикам, тем самым удовлетворить их потребности в аналитических данных.
Заключение
Подводя итоги, хотелось бы обратить внимание, что корпоративное ХД — это сложная и очень дорогостоящая ИС, к проектированию которой важно подходить очень тщательно. Необходимо хорошо понимать потребности ключевых бизнес-заказчиков, потому что в противном случае, ошибки, совершенные на этом этапе, могут в будущем стоить очень дорого. Т. к. ХД требуется постоянно развивать и поддерживать с учетом изменяющихся требований бизнеса, принципиально важно подойти серьезно к выбору существующих на рынке технологий и решений. Только грамотное и продуманное на всех этапах решение способно существенно сократить издержки предприятия, повысить качество предоставляемых услуг и, как следствие, обеспечить конкурентоспособность компании на рынке.
Литература:
- Database Data Warehousing Guide // ORACLE. — URL https://docs.oracle.com/database/121/DWHSG/part1.htm#DWHSG8062 (дата обращения: 02.09.2018).
- Коновалов М. В. Обзор и сравнительный анализ промышленных хранилищ данных и баз данных // Молодой ученый. — 2018. — № 24. — URL https://moluch.ru/archive/210/51452/ (дата обращения: 02.09.2018).
- Ralph Kimball, Margy Ross. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling. Third Edition. — John Wiley & Sons, 2013.
- Академия Microsoft: Проектирование хранилищ данных для приложений систем деловой осведомленности (Business Intelligence Systems) // Национальный Открытый Университет «ИНТУИТ». — URL https://www.intuit.ru/studies/courses/599/455/info (дата обращения: 02.09.2018).
