Методика построения аналитического хранилища

[a.nalivaiko (Алёна)]

Этапы построения АХД.

Общая стратегия построения АХД подразумевает этапы работ по нижеприведенной схеме.

Анализ предметной области.

На этом этапе выполняется анализ предметной области в пределах границ объекта автоматизации (use case диарамма) с учетом функциональных требований совместно с заказчиком. Результат анализа отражается в концептуальной схеме.

ER-модель - модель данных, позволяющая описать концептуальные схемы предметной области. С ее помощью выделяются ключевые сущности и обозначаются связи между этими сущностями. Для построения ER-модели можно использовать любую известную нотацию, нпр. нотацию П. Чена.

При разработке ER необходимо обследовать предметную область (организацию, предприятие) и выявить:

1. Сущности, о которых хранятся данные в организации (предприятии), например, люди, места, идеи, события и т.д., (будут представлены в виде блоков);
2. Связи между этими сущностями (будут представлены в виде линий, соединяющих эти блоки) и вид связи;

• Существует три вида связи: один-к-одному, один-ко-многим, многие-ко-многим.
• Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой).
• Связь типа многие-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи многие-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. При построении нормализованной реляционной модели на основе ER-модели связь многие-ко-многим реализуется путем создания таблицы связи, связанной отношением один-ко-многим с таблицами сущностей, связанных отношением многие-ко-многим в ER-модели.
• Связь типа один-ко-многим означает, что один экземпляр первой сущности(левой) связан с несколькими экземплярами второй сущности (правой). При построении нормализованной реляционной модели на основе ER-модели связь один-ко-многим реализуется с помощью внешних ключей.

3. Свойства этих сущностей (будут представлены в виде имен атрибутов в этих блоках)

На практике не всегда удается построить корректную ER - модель на первом этапе реализации проекта в силу различных причин, например:

• заказчик предоставляет в качестве требований набор денормализованных данных - отчетов, и нет возможности совместно с заказчиком провести анализ предметной области, достаточный для построения адекватной ER-модели.

В таких случаях фиксируются допущения, в ER - модели объекты “черные ящики” отображаются as is. Предполагается, что по мере развития проекта необходимая аналитическая работа будет проведена, ER - модель будет доработана.

Результат этапа “Построение ER-модели”:

1. ER-модель с явным указанием нотации (схема).
2. Зафиксированные списком допущения, принятые в силу специфики проекта, со ссылками на конкретные объекты схемы.

Выбор способа построения аналитического хранилища данных.

При использовании инструментов Alpha BI для построения АХД есть способы построения аналитического хранилища:

• создать новое хранилище бизнес-объектов Alpha BI,
• использовать любое существующее хранилище:
  • хранилище бизнес-объектов Alpha BI,
  • сторонее реляционное хранилище

Выбор варианта зависит от закрываемых продуктом задач >> сценария использования продукта (за рамками данной статьи).

На момент построения реляционной модели должно быть четко определено какой из способов будет применяться.

Построение реляционной модели.

Построение реляционной модели выполняется в случае создания нового хранилища в Alpha BI на основе результатов анализа предметной области.

На основе ER-модели строится реляционная модель данных.

На первом этапе работы над реляционной моделью предлагается строить нормализованную модель, опираясь на следующие правила:

1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.
2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.
3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.
4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. у таблицы, находящейся на конце связи “N” делается поле с типом “Ссылка на объект”, объектом ссылки выступает уникальный идентификатор с конца связи “1”
5. Связи многие-ко-многим реализуется путем создания таблицы связи, связанной отношением один-ко-многим с таблицами сущностей, связанных отношением многие-ко-многим в ER-модели.

6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:

• все подтипы в одной таблице - организация иерархии(а)
• для каждого подтипа - отдельная таблица (б)

На практике не всегда удается построить нормализованную модель даже на первом этапе.

Реляционное хранилище может быть частично денормализовано в силу различных причин:

• специфика проекта такова, что заказчик предоставляет в качестве требований набор уже денормализованных данных - отчетов, и нет возможности совместно с заказчиком провести анализ предметной области, достаточный для построения адекватной ER-модели и нормализованной реляционной сответственно.
• на этапе анализа производительности на целевых объемах данных принято решение о денормализации

Для аналитических хранилищ справедливо следующее:

В целях оптимизации производительности возможна денормализация данных в реляционном хранилище (на больших объемах данных чаще всего так и происходит). Для аналитических хранилищ это нормально!!!

Но нужно понимать, что денормализация усложняет задачу обновления и поддержки данных в консистентном состоянии (ссылочная целостность и т.п.). Поэтому денормализацию стоит применять только после этапа анализа производительности на целевых объемах данных и только там, где этого требует соотношение:

• объемов данных,
• доступных вычислительных мощностей и
• ожиданий по производительности.

Результат этапа “Построение реляционной модели”:

1. Реляционная модель (диаграмма структуры данных - в любой известной нотации).
2. Зафиксированные списком допущения, принятые в силу специфики проекта, со ссылками на конкретные объекты схемы.

P.S. Схема, полученная в результате этапа построения реляционной модели, может быть изменена - нпр. на этапе оптимизации производительности - процесс циклический.

Восстановление реляционной модели.

Восстановление реляционной модели выполняется в том случае, когда хранилище уже существует - спроектированное для решения каких-то то задач (не факт, что АХД).

Продукт Alpha BI для чтения данных и построения представлений в аналитических инструментах позволяет:

• использовать стороннее реляционное храниище для чтения данных и построения представлений в аналитических инструментах,
• использовать собственное хранилище Бизнес объектов

Диаграмма структуры данных - представление реляционной модели - в этом случае строится по существующему хранилищу as is - Reverse Engineering. Для этого можно использовать любые инструменты, позволяющие построить диаграмму автоматически на основе существующей БД.

После построения диаграммы устанавливается соответствие ER-модели, выделяются и фиксируются несоответствия, потенциальные проблемы и т.п.

Результат этапа “Восстановление реляционной модели”:

1. Реляционная модель (диаграмма структуры данных - в любой известной нотации).
2. Зафиксированные списком несоответствия, потенциальные проблемы и т.п., со ссылками на конкретные объекты схемы.

Создание реляционного хранилища в Alpha BI.

На основе реляционной модели, построенной на предыдущем этапе, создается физическое хранилище в БД.

На этом этапе переходим к реализации инструментами Alpha BI:

1. Создаем Бизнес объекты с типом “RDBMS”, атрибуты хранилища - код соединения: RDBMS.
2. Запускаем процесс заполнения данными созданного хранилища - ручной ввод (Формы, Реестры), инструментом ETL или любым альтернативным инструментом.

Результат этапа “Создание реляционного хранилища”:

1. Созданные в Alpha BI “Бизнес объекты”.
2. Отраженные в документации проекта объекты.
   

Построение многомерной модели данных.

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

На основании требований заказчика выделяются:

• основные разрезы для анализа - это потенциальные претенденты на размерности.
• количественные характеристики фактов - меры.
• атрибутивная информация, аналитика в разрезе которых не нужна, но нужно выводить в качестве справочной информации и по которым возможна нужна фильтрация (>,<, =, !=, и тд) в атрибуты.

На этом этапе предполагается предварительная аналитическая работа перед созданием многомерной модели средствами Alpha BI.

Рекомендации по созданию размерностей

1. При выделении размерностей нужно постараться определить и установить каскадные связи атрибутов
   Например:
   День >> Месяц >> Квартал >> Полугодие >> Год
Город >> Регион >> Федеральный округ
   Выделение подобных иерархий позволит получить концептуально верное и понятное для анализа представление и положительно скажется на производительности, так как количество дочерних элементов размерности будет меньше, нежели при использовании отдельных размерностей.
2. Не создавайте иерархий, в которых атрибут нижнего уровня (A) насчитывает меньше элементов, чем в атрибуте уровня выше (B)

• Исчезает смысл от иерархии, так как по производительности это будет равносильно расчету плоской размерности с числом элементом (B).
• Логически не верно
• В случае если подобная иерархия нужна в виду предметной области, то лучше выделить в отдельные размерности

3. В размерностях, насчитывающих большое количество записей на листовом, ключевом уровне нужно придумать некоторую группировку, которая позволит организовать иерархию. Соотношения числа элементов между уровнями должны быть в несколько раз, десятки раз.

• Существенно повысит производительность OLAP
• Появятся дополнительные аналитические разрезы, которые позволят пользователям увидеть ошибки в данных

4. Используйте общие размерности
   Если в нескольких кубах используются одинаковые срезы для аналитики, то лучше выделить общую размерность. OLAP-серверу проще получить атрибуты и количество элементов у ОР, нежели у локальной.
   Если кеш по ОР уже прогрет, то OLAP-запрос к другому кубу, который тоже использует это размерность выполнится быстрее.

• Использование локальной размерности допустимо только в том случае, если количество уникальных элементов размерности примерно равно количеству строк в таблице фактов куба.**

5. Не выделять в уровни размерности (или в отдельные размерности) элементы, которые фактически являются атрибутами.
   Если по этому элементу не нужна аналитика, и информация по нему несет исключительно информационный характер, то это атрибут.
   По значениям атрибутов также можно проводить фильтрацию. (Например, атрибутом является дата договора - можно отсортировать по дате. Фильтрацию можно организовать либо настроив фильтр на атрибут на размерности или прописав обращение Properties)

Рекомендации по созданию кубов

1. Не стоит нагружать один куб большим количество мер, которые концептуально можно разделить в несколько групп
2. В большом кубе пользователи могут запутаться

• Сложнее разрабатывать, поддерживать, тестировать
• Существует вероятность, что при изменении чего-то одного, может сломаться другое
• Плохое влияние на производительность (чем больше мер, тем хуже производительность - приходится рассчитывать большее количество агрегатов)

3. Для анализа значений мер из разных кубов на пересечении общих размерностей можно использовать виртуальные кубы.

Результат этапа “Построение многомерной модели данных”:

1. Зафиксированный набор предполагаемых элементов многомерной модели - общих размерностей, кубов, виртуальных кубов со ссылками на элементы физического хранилища.
2. Схема многомерной модели.

Пример схемы многомерной модели.

Подготовка АХД в Alpha BI.

При подготовке АХД решается следующая задача: обеспечить уровень абстракции поверх физической реляционной модели, который включает необходимые для построения многомерной модели сущности, поля.

Уровень абстракции может быть реализован:

• на уровне БД - с помощью представлений (View, MatView),
• на уровне приложения AlphaBI - с помощью Бизнес объектов

По результатам BI анализа для каждого из кубов, общих размерностей - элементов многомерной модели, связянных с физическим хранилищем - определить абстрактное хранилище:

• если физическое хранилище является сторонним по отношению к Alpha BI:
  1. Создать кастомное соединение со сторонним хранилищем (либо использовать ранее созданное).
  2. Создать Бизнес объект с типом “Запрос к RDBMS”, атрибуты хранилища:
  • код соединения: код кастомниго соединения со сторонним хранилищем
  • тело запроса: должно содержать получение только необходимых для OLAP полей
• если используется хранилище Alpha BI:
  • если источником данных для куба/общей размерности является не 1 таблица, а набор связанных (нпр, для многоуровневой иерархии, которая строится на нормализованном хранилище), создать Бизнес объект с типом “Запрос к RDBMS” и запросом (join связанных таблиц), результат выполнения которого даст “денормализованное” (избыточное) представление данных - достаточное для построения общей размерности/куба,
  • в противном случае использовать Бизнес объект с типом “RDBMS” уже созданный ранее при создании хранилища.

В дальнейшем при оптимизации производительности объекты типа “Запрос к RDBMS”, определяющие join таблиц, могут быть заменены на представления (View, MatView) или таблицы (Table) на уровне физического хранилища. Такую оптимизацию не рекомендуется делать на начальном этапе реализации проекта в условиях нечетких, часто меняющихся требований от заказчика,т.к. при изменении требований изменение Бизнес объектов типа “Запрос к RDBMS” (текста запроса) менее трудозатратно, чем изменение структуры физического хранилища >> более гибкая реализация, но ухудшающая производительность.

Результат этапа “Подготовка АХД”:

1. Для каждого предполагаемого элемента многомерной модели определено хранилище,
2. Созданные в Alpha BI Бизнес объекты типа “Запрос к RDBMS” .
3. Отраженные в документации проекта объекты.
   

Создание многомерной модели данных в Alpha BI.

На основе результатов BI анализа и созданных Бизнес объектов выполняется построение многомерной модели инструментами Alpha BI.

1. Создать Источник данных со ссылкой на соединение:
2. RDBMS - при использовании хранилища AlphaBI
3. кастомное соединение - при использовании стороннего хранилища
4. В источнике создать:
5. Общие размерности
6. Кубы
7. Виртуальные кубы
8. Синхронизировать схему.

Результат этапа “Создание многомерной модели”:

1. Созданный в Alpha BI источник данных с общими размерностями, кубами, виртуальными кубами
2. Отраженные в документации проекта объекты.
   

Построение OLAP представлений в Alpha BI.

1. Построить OLAP представления в соответствии с требованиями и результатами BI анализа.
2. Убедиться, что созданные представления покрывают все требования заказчика с точки зрения функциональности:
3. набор аналитических срезов,
4. степень детализации,
5. корректность расчета агрегатов,
6. сортировки,
7. фильтры,
8. и прочее
9. При необходимости:
10. применить расчетные элементы в OLAP представлении,
11. доработать многомерную модель,
12. доработать физическое хранилище (если используется хранилище Alpha BI).

Результат этапа “Построение OLAP представлений”:

1. Созданные в Alpha BI OLAP представления, полностью покрывающие функциональные требования заказчика.
2. Отраженные в документации проекта объекты.
   

Анализ производительности в целевых условиях.

На этом этапе необходимо протестировать производительность аналитического инструмента DWH/OLAP в условиях максимально приближенных к целевым.

Под “целевыми условиями” понимается:

1. Инфраструктура, вычислительные мощности.
2. Топология развертывания продукта.
3. Предполагаемый объем анализируемых данных.

Предполагается, что задача подготовки соответствующей тестовой среды (в т.ч. и наполнения данными в необходимом объеме) будет решена - если нет, сначала придется решить ее.

Кейсы для тестирования производительности вручную:

1. Выполнить ранее созданные OLAP представления.
2. Построить и выполнить представления, которые в дальнейшем могут использоваться как источники данных для отчетов или аналитических панелей.

Результат этапа “Анализ производительности в целевых условиях”:

• Ответ на вопрос “Производительность не ниже ожидаемой?”.

Диагностика проблем производительности.

При возникновении проблем производительности (производительность ниже ожидаемой) необходимо определить на каком уровне и по какой причине возникают проблемы.

Под “уровнями” понимаются:

• Web клиент (Браузер),
• сервер приложения AlphaBI,
• OLAP сервер,
• сервер БД

Задача диагностики вероятно будет решаться силами технических специалистов с применением соответствующих средств диагностики (за рамками данной статьи).

Результат этапа “Диагностика проблем производительности”:

• Зафиксированный список проблем производительности с указанием места возникновения и причины.

Оптимизация производительности.

В зависимости от результатов диагностики определяется метод оптимизации производильности:

1. Оптимизация на уровне многомерной модели:
   Несоблюдение рекомендаций по созданию кубов, размерностей часто приводит к проблемам производительности - проверить и исправить типичные ошибки проектирования. Подходы, приводящие к просадке производительности АХД
2. Оптимизация на уровне OLAP сервера:
3. Изменение схемы управления кэшем OLAP сервера,
4. Изменение конфигурации OLAP сервера
5. Оптимизация на уровне БД:
6. Добавление индексов,
7. Денормализация - замена Бизнес объектов типа “Запрос к RDBMS”, определяющие join таблиц, на денормализованные представления (View, MatView) или таблицы (Table)
8. Тюнинг БД
9. Наращивание вычислительных ресурсов

Результат этапа “Оптимизация производительности”:

• Устранение проблем производительности.