Варианты реализации Хранилищ данных

Записаться

Варианты реализации хранилищ данных

Виртуальное хранилище данных

В отличие от физического хранилища, где собранные и согласованные данные записываются на носитель, в виртуальном хранилище данных физического уровня хранения нет. Есть только ОДС (Operational Data Store, ODS) — операционное хранилище, промежуточный слой согласованных текущих данных. При обращении к хранилищу ODS «на лету» формирует нужную структуру в оперативной памяти и передаёт её клиенту. Многомерная модель и OLAP-куб (Online Analytical Processing cube) физически нигде не хранятся. В ODS данные из первичных источников слиты и согласованы в рамках третьей нормальной формы (3НФ), а затем преобразуются в структуры, удобные для анализа.

Достоинства:

• экономия дискового пространства;
• работа с текущими данными на максимально детализированном уровне.

Недостатки:

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

Хранилище же предназначено для накопления истории и ретроспективного анализа.

Корпоративная фабрика Инмона

Хранилище Инмона (Inmon) — корпоративная фабрика, включающая OLTP-системы (Online Transaction Processing), ODS, центральное хранилище, витрины данных и систему Data Mining (интеллектуального анализа данных). ODS накапливают временные срезы процессов, согласуют данные и передают их в хранилище, чтобы история не терялась. В ODS информация более детализирована; в хранилище могут применяться разные уровни агрегации.

Этапы:

1. Извлечение данных из первичных источников.
2. Загрузка в реляционную базу в 3НФ.
3. Использование нормализованного хранилища для наполнения презентационных репозиториев.
4. Построение витрин данных и проведение Data Mining.

Пользователь при запросе к хранилищу Инмона фактически работает с большой нормализованной моделью, которая «на лету» перестраивается под анализ. Хранится всё, как есть, но время аналитических запросов растёт.

Хранилище Кимбалла

В хранилище Кимбалла (Kimball) используется многомерная модель «звезда» и «снежинка». Данные из первичных источников не сохраняются как есть в 3НФ: при перемещении и согласовании они сразу перестраиваются в схему «звезда» или «снежинка». Проводится агрегация и углубление информации под будущие аналитические запросы.

Архитектура двухуровневая: подготовка данных и само хранилище. Пользователь видит «звезду» или «снежинку», но не видит исходные данные. При переходе от первичных источников часть информации теряется: аналитика строится только на выбранных данных. Зато они хранятся в форме, ускоряющей анализ. Хранилище Кимбалла — это, по сути, коллекция витрин данных (Data Marts), под каждый запрос используется своя витрина.

Гибридное хранилище данных

Гибридное хранилище — трёхуровневая архитектура, совмещающая подходы Инмона и Кимбалла. На первом уровне хранится нормализованное корпоративное хранилище на базе 3НФ, которое не оптимизирует запросы. На втором уровне создаются витрины данных, согласованные с OLAP-концепцией (Online Analytical Processing). На третьем уровне находятся клиентские рабочие машины бизнес-аналитиков, которые выполняют запросы, строят прогнозы и помогают руководителям принимать решения.

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

Формат хранения данных в OLAP-кубах

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

Краткие итоги

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

Подход Инмона решает проблему полноты: данные из первичных источников стекаются через ODS в центральное нормализованное хранилище, где сохраняются в 3НФ. Это даёт согласованность и возможность строить витрины и Data Mining. Но плата — сложность и замедление запросов, потому что аналитическую модель приходится перестраивать на лету. На практике такой подход выбирают, когда важнее единая корпоративная картина и сохранение всей истории, чем мгновенный отклик.

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

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