Юрий Кудрявцев,
эксперт направления CPM-решений
компании КРОК

Использование Hyperion Essbase для ассортиментного анализа в компании «Спортмастер».

Источник: статья подготовлена по презентации "Анализ больших объемов данных на базе Hyperion Essbase Опыт Спортмастер и КРОК" А. Тюренкова, руководителя отдела Datawarehouse компании Спортмастер и автора на Oracle TechForum2008, ноябрь 2008,
http://www.oracleclub.ru/techforum/program.html, секция "Oracle Data Integrator. Хранилища данных".

Введение

Описание задачи

Летом 2008 года компании Спортмастер и Крок провели пилотный проект по нагрузочному тестированию Oracle Essbase. Целью пилотного проекта было испытание многомерного сервера для решения задачи анализа ассортимента и коллекционного планирования. Для этого в течение месяца специалисты «Крок» и «Спортмастер» проводили интеграцию с существующим хранилищем данных, загрузку данных в многомерный OLAP-куб Essbase и нагрузочные испытания на данных порядка 40 млн. строк по продажам и около 550 млн. строк по ежедневным складским остаткам. Использовались данные за 9 месяцев.

Компания Спортмастер имеет более 700 объектов хранения (логистических узлов и магазинов) на территории СНГ и артикульную базу в более чем 1 200 000 наименований, чем обусловлена необходимость использования специализированного высокогопроизводительного средства. При этом ассортиментный анализ проводится по 15 атрибутов для артикулов (цвет, размер, коллекция, торговая марка и пр.), ряду атрибутов (площадь, проект, дивизион, даты открытия и пр.) для объектов, а также по типам операций (опт, розница и пр.). Итоговый объем анализируемой информации, с учетом рассчитанных агрегатов, превысил 1,5 млрд. записей. Полное время загрузки и расчета куба при этом составило менее полутора часов. Исходный объем данных в текстовых файлах составил около 70 Гб. Насколько известно авторам, это максимальные по объемам характеристики Essbase проекта на территории СНГ.

Была обеспечена максимально возможная скорость отклика на запросы пользователей, реализованы расчетные показатели по эффективности товарооборота, продажам и валовой прибыли с квадратного метра, настроены отчеты и презентационные панели в Oracle BI Suite EE Plus и Hyperion Visual Explorer.

Тестирование других BI-средств

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

ROLAP

Использование ROLAP (реляционный OLAP, данные и агрегаты куба хранятся в РСУБД) технологии от Microstrategy вызвало следующие, типичные для ROLAP-решений проблемы:

• резкое ухудшение производительности при использовании parent-child измерений (измерение товаров построено в ХД СпортМастер именно таким образом, чтобы возможно было гибко добавлять уровни группировки артикулов). Parent-child измерения при использовании ROLAP обычно «нормализуются» в уровневые иерархии (в английской литературе такая операция называется рассчетом замыканий, closure), что требует пересчета подобных таблиц при каждом изменении измерения и глобальном изменении таблицы при увеличении/уменьшении вложенности
• сложности с фильтрацией и рассчетами над атрибутами (атрибуты хранятся в Entity – Attribute – Value модели, поэтому обращение к ним требует дополнительных операций соединения)
• временные затраты на обновление материализованных представлений. Построение ряда представлений занимало более 3-4х часов.

MOLAP

Были протестированы MOLAP (многомерный OLAP, данные и агрегаты хранятся в многомерной бд) средства Cognos PowerPlay и Oracle OLAP Option. При этом были отмечены следующие недостатки:

• сложности с использованием parent-child измерений и измерений большого объема
• отсутствие в Cognos Transformer атрибутов измерений и связанные с этим сложности моделирования
• производительность Discoverer клиента при работе с большими измерениями (измерение полностью импортируется на клиента, что в случае измерения с более 1 млн элементов приводит к значительной потере производительности)

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

Oracle Essbase как инструмент работы с большими объемами данных

Как известно, OLAP-сервер Essbase появился в линейке продуктов компании Oracle после поглощения последней компании Hyperion. При этом надо отметить, что Essbase – очень широко известная технология, разработанная компанией Arbor Software в начале 90х годов прошлого века. Более того, Essbase – первая «каноническая» OLAP-система, именно ее рассматривал как пример в своей знаменитой статье Эдгар Кодд, вводя термин OLAP («Providing OLAP to User-analysts: An IT Mandate»,1993). Связанный с этой статьей скандал (Кодд был спонсирован Arbor) мы опустим, достаточно сказать, что термин OLAP первое время ассоциировался именно с Essbase.

Essbase изначально позиционировался как многопользовательское расширение электронных таблиц, он так и называется: Extended SpreadSheet dataBASE (не тот был маркетинг в прошлом веке, совсем не тот). Изначальная ориентация на финансовые отчеты и анализ (основное на тот момент применение электронных таблиц) предопределило богатый функционал встроенных финансовых функций, различные типы консолидации элементов измерений, возможность задавать собственные последовательности вычислений в виде скриптов и, конечно, возможность ручного ввода данных пользователями.

Однако с течением времени Essbase стал выходить за рамки сугубо финансовых задач. Использование многомерных кубов оказалось удобным для множества других областей, прежде всего для анализа продаж. Однако в этом применении от системы нужны были несколько другие свойства, не было необходимости ручного ввода данных (данные загружаются автоматически, Essbase только рассчитывает агрегаты), не было необходимости в столь сложных расчетах и, главное, нужна была поддержка огромных объемов данных (почековые продажи большой розничной сети и ее же бюджет доходов и расходов отличаются по числу записей на многие порядки). Поэтому в Essbase был добавен новый формат хранения – Aggregate Storage Option, ASO (предназначенный для агрегации данных). Исходный формат, предназначенный больше для сложных вычислительных задач и ввода данных называется Block Storage Option.

Хотелось бы также отметить, что при разработке ASO формата Hyperion совместно с Microsoft разработали и в каком-то виде «стандартизировали» язык запросов к многомерным кубам – MultiDimensional eXpressions, который сейчас широко известен благодаря популярности OLAP-системы Microsoft Analysis Services.

Очевидно, что в данном пилоте использовалось Aggregate Storage Option. Рассмотрим основные особенности этого формата хранения, которые позволяют достигать высокой производительности в загрузке данных и обработке запросов.

Расчет агрегатированных представлений

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

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

Рис.1. Пример работы помощника по выбору агрегированных представлений.
Ось Y на графике -- стоимость выполнения запроса, X – объем многомерного куба

Параллельная загрузка данных

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

Рис 2. Загрузка данных в несколько буферов одновременно.

В пилоте, используя подобную технологию, была достигнута скорость загрузки данных в куб 40 Мб\с, что было близко к скорости простого копирования файлов.

Сжатие данных

Данные в кубах Essbase хранятся в сжатом виде, причем очень важным является выбор измерения сжатия. Поскольку Essbase хранит не индивидуальные значения, а группы значений, необходимо, чтобы по этому измерению значения присутствовали в большинстве элементов и заполненные элементы были близки друг к другу (между группами может быть любое количество отсутствующих элементов). Средняя наполняемость подобной группы (average bundle fill) напрямую влияет на общий уровень сжатия.

К примеру, если объем исходных данных в текстовом виде равен 70 Гб, то при выборе измерения сжатия с average bundle fill близким к 4 (значение колеблется от 1 до 16, 16 – наилучшее сжатие) размер куба - 10 Гб, а при выборе измерения сжатия с average bundle fill близким к 8, размер куба равен 5 Гб.

Сортировка элементов измерения может существенно изменить наполняемость групп, что дает возможность дополнительной оптимизации.

Выводы

Проведенные испытания показали, что подобные объемы далеко не предел возможностей Oracle Essbase.

Более подробный рассказ о других вариантах использования Essbase, множестве не менее интересных настроек и техник предполагается опубликовать в следующих номерах RE.