OLAP-куб. Введение

Записаться

1. От ETL к OLAP-кубу

Мы продолжаем курс «Введение в OLAP и хранилища данных». Ранее были созданы ETL-процедуры (Extract, Transform, Load — извлечение, преобразование, загрузка). Они собирают данные из разных источников: баз данных, отдельных файлов, удалённых сервисов, например котировок. Затем информация попадает в хранилище данных (Data Warehouse, DWH), где хранится по определённой архитектуре.

В практической работе использовалась схема «снежинка» (snowflake schema). Это централизованное хранилище с таблицами измерений (dimensions) и таблицами фактов (fact tables). Состав измерений и фактов зависит от бизнес-задач. Бизнес-аналитик заказывает витрину данных (data mart), а администратор хранилища формирует набор измерений и фактов для неё. Так как аналитиков несколько, витрины могут пересекаться. Поэтому измерения и факты создаются шире — для обслуживания нескольких витрин.

В классическом подходе Инмона (Inmon) централизованное хранилище хранит данные в нормализованном виде. В подходе Кимбалла (Kimball) акцент делается на dimensional modeling — измерения и факты, звезду или снежинку и витрины для быстрой аналитики. В практической работе выбран второй путь: заранее готовится снежинка под витрину, чтобы быстро получать аналитические срезы.

2. Зачем нужен OLAP-куб

Между снежинкой и витриной находится OLAP-куб (On-Line Analytical Processing — оперативная аналитическая обработка). Он:

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

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

Для построения куба нужны:

• готовая снежинка, созданная ETL-процедурой;
• понимание бизнес-задачи и желаемой витрины.

3. MOLAP и хранение куба

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

Схема такая: в одном секторе хранилища находится снежинка, в другом — собранный OLAP-куб. К кубу подключаются BI-системы (Business Intelligence — бизнес-аналитика) и выгружают данные для бизнес-аналитика.

4. Создание проекта куба в Visual Studio Data Tools

Создать OLAP-куб на базе SQL Server проще всего в Visual Studio Data Tools. Можно использовать не полную Visual Studio, а компонент Data Tools. В Visual Studio 2019 он интегрирован, в 2017 может идти отдельно.

Порядок:

1. Выбрать New Project.
2. В шаблонах выбрать Analysis Services.
3. Среди проектов выбрать MOLAP / Multidimensional, а не ROLAP.
4. Задать имя, например OLAP_Test.
5. Нажать OK.

Создаётся пустой проект с заготовками компонентов.

5. Структура проекта

• Data Source — подключение к источнику данных.
• Data Source Views — конкретные таблицы, выгружаемые из источников.
• Cube — окончательно созданный OLAP-куб.
• Dimensions — измерения, участвующие в кубе.
• Mining Structures — структуры для Data Mining (интеллектуального анализа данных).
• Roles — роли и полномочия при работе с кубом.

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

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

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

Куб не просто ускоряет запросы. Он задаёт семантику данных: какие показатели можно суммировать, как связаны измерения, какие иерархии доступны, как сортировать и фильтровать срезы. Это снижает нагрузку на аналитика и уменьшает риск разночтений в отчётах. Выбор MOLAP усиливает скорость за счёт многомерного хранения, но требует отдельного серверного слоя и предварительной подготовки. Поэтому такая архитектура эффективна там, где бизнес готов инвестировать в инфраструктуру ради оперативных и повторяемых решений.

Создание куба в Visual Studio Data Tools показывает, что аналитическая система — это не один отчёт и не одна таблица, а проект с чёткой структурой. Подключения, представления, измерения и сам куб разделены, что упрощает сопровождение. Дополнительные компоненты — Data Mining и роли — расширяют систему: первая добавляет прогнозные и классификационные модели, вторая управляет доступом. В результате аналитик получает быстрый доступ к согласованным данным, администратор — управляемую среду, а бизнес — основу для решений, где скорость и точность важнее первичной детализации.