Anvil
О компании
Анвил CRM
Анвил Performance
Блог
Контакты

Хранилища данных и OLAP

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

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

Не секрет, что в подавляющем большинстве компаний, в том числе работающих на территории СНГ вообще и Украины в частности, проблема сбора и накопления первичных данных успешно решена. Сегодня рынок предлагает широкий выбор операционных, биллинговых, бухгалтерских систем. Однако время собирать камни прошло: данные недостаточно копить, они должны работать, чтобы приносить прибыль.

Для этого данные должны помочь ответить на типичные проблемы бизнеса:

  • в каком регионе был достигнут максимальный уровень сбыта данной продукции в прошлом году (в какой именно торговой точке, у какой категории покупателей она пользовалась наивысшим спросом);
  • какова динамика продаж по региону во времени (были ли сезонные всплески, хватало ли запаса товара на складах);
  • какой прогноз спроса дает тренд на 2'й квартал этого года (что будет, если уровень инфляции составит 2,5% в месяц, а конкуренты поднимут цены на 10%).

Особенности задачи анализа данных

На эти вопросы невозможно либо очень трудно ответить в терминах транзакционной СУБД - силу того, что ее OLTP-структура максимально нормализована для учета данных (где характерны короткие обновляющие транзакции) и очень плохо приспособлена для массированного длительного чтения.

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

  • могут быть расположены в различных подразделениях, чаще всего не имеющих связи в online-режиме;
  • расположены в базах, ориентированных на оперативную работу и массированный ввод пользователями, а не на построение "тяжелых" аналитических отчетов;
  • данные могут находиться в различных БД систем разных производителей, и их крайне сложно связать между собой.

Необходимость отдельного решения

А зачем вообще переносить данные из оперативных систем в хранилище? Ведь, казалось бы, отчеты можно построить "напрямую" и в обычной учетной системе.

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

Рассматриваемая далее технология хранилищ данных решает эту и многие другие проблемы.

Опыт построения хранилищ

Для решения задачи построения единой корпоративной отчетности и аналитики во всем мире применяется техника построения корпоративных хранилищ данных (Warehousing) и работа отчетной подсистемы уже по этим хранилищам, а не по оперативной информации.

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

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

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

Что такое Warehousing

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

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

Нередко это специализированные реляционные базы данных, называемые также хранилищами данных (Data Warehouse). В отличие от оперативных БД, с которыми работают приложения, модифицирующие данные, хранилища предназначены исключительно для обработки и анализа информации, поэтому проектируются так, чтобы время выполнения запросов к ним было минимальным (как правило, применяется денормализация). Обычно данные копируются в хранилище из оперативных БД согласно определенному расписанию.

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

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

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

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

Для лучшего понимания сути Data Mining см. таблицу 1.

Таблица 1. Примеры формулировок задач при использовании методов OLAP и Data Mining
OLAPData Mining
Каковы средние показатели травматизма для курящих и некурящих?Встречаются ли точные шаблоны в описаниях людей, подверженных повышенному травматизму?
Каковы средние размеры телефонных счетов существующих клиентов в сравнении со счетами бывших клиентов, отказавшихся от услуг телефонной компании?Имеются ли характерные портреты клиентов, которые, по всей вероятности, собираются отказаться от услуг телефонной компании?
Какова средняя величина ежедневных покупок по украденной и по неукраденной кредитной карточке?Существуют ли стереотипные схемы покупок для случаев мошенничества с кредитными карточками?

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

Таблица (таблицы) фактов является основой хранилища данных и содержит сведения об объектах либо событиях, совокупность которых будет анализироваться.

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

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

Каждая таблица измерений должна находиться в отношении <один ко многим> с таблицей фактов.

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

Два подхода к наполнению хранилищ

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

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

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

Фрагмент статьи А.Банасевича, А. Гурленко из журнала "Корпоративные системы" № 4/2002