Хочется признать актуальность статьи А. Резниченко “OLAP в России”, опубликованной в PC Week/RE, № 25/2000, с. 19.

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

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

Какие объемы можно считать достойными для OLAP-систем? В какой архитектуре строить хранилища данных? Нам кажется, что существует четыре варианта.

1. OLAP - это новый метод манипуляции с данными, заменяющий статичные отчеты; способ быстрого получения отчета в различных разрезах и быстрого обобщения детальных данных. Поэтому большую выгоду конечному пользователю может принести даже настольное средство, манипулирующее всего лишь тысячами записей. Например, экономисту может быть полезен анализ балансов или отчетов о прибылях и убытках за год, выполненный средствами OLAP, ибо в этом случае ему не придется заказывать десятки отчетов у программистов. Именно на решение этой задачи в последнее время ориентируются корпоративные и персональные ROLAP - системы, которые имеют прямой доступ к существующим в компании базам данных или используют данные, выгруженные в собственные локальные таблицы. Такие системы дешевы и просты как во внедрении, так и в освоении, и мы считаем, что у них большое будущее. Поэтому программу такого класса разработали и мы, она успешно работает в ряде банков и предприятий. К концу сентября мы выпустим в продажу довольно мощный OLAP-компонент собственного производства. Он в состоянии обрабатывать до сотен тысяч записей, полученных из реляционных СУБД. Это будет первый российский продукт класса OLAP.

2. Как показывает опыт, задачи работы с архивными данными гораздо шире, чем сжатие и детализация статистической информации. Например, для банков важно просто хранить и быстро извлекать стандартные банковские данные. Эти данные глубоко связаны друг с другом: клиент, документ, проводка, счет. Требуется вычислять сложные показатели, выпускать регламентированные отчеты за произвольный период. При этом нужно отражать такие специфические данные, как архивная проводка или заключительные обороты, которые не всегда ложатся в схему “звезда”. Эта задача наилучшим образом решается построением сложного реляционного DWH. В его рамках можно эффективно выполнять и вычисление предопределенных агрегатов, таких, как консолидированный балансовый счет за стандартные временные периоды. Реляционное хранилище, созданное нашей компанией и собирающее первичные данные из 15 филиалов, внедрено в Собинбанке; завершается внедрение отчетов на базе хранилища. Сейчас начинаем внедрение этой системы в Петрокоммерцбанке. Правильность такого подхода подтверждают и собственные банковские разработки.

3. Для решения узко очерченных задач анализа статистической информации, поддержки принятия решений, в тех случаях, когда требуется манипулировать большим количеством измерений, оптимальным является создание витрин данных в многомерной БД. При этом атомарные данные хранятся в реляционном хранилище гибридной архитектуры - HOLAP. Классической задачей, которая идеально ложится в эту архитектуру, является анализ продаж торгового предприятия. Мы уже реализовали ряд таких решений и получили вполне удовлетворительные результаты. Одна система сейчас внедряется в самарском торговом комплексе “Московский”, другая готовится к внедрению в рамках проекта Ассоциации российских банков “Орион”.

4. Если задача анализа очерчена рамками однородных финансовых показателей, объем данных велик, но предприятие при этом не планирует создание полномасштабного DWH, то оптимальным решением будет построение DWH в MOLAP-архитектуре. Тогда данные можно загружать непосредственно из OLTP. Мы встречали такие решения, однако они не снимают проблемы создания единого информационного пространства для крупной организации и в большинстве случаев рассматриваются как временные.

Владимир Некрасов, технический директор компании Intersoft Lab.

Версия для печати