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

OLAP (On-Line Analytical Processing) — технология многомерного анализа данных. Специальные методы хранения информации, такие как предварительный расчет агрегированных данных, позволяют OLAP-системам за кратчайшее время выдавать итоги обработки больших массивов данных.

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

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

Миф 1: трудозатраты на настройку OLAP сопоставимы с созданием очередного отчета

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

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

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

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

Миф 2: данные OLAP актуальны

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

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

Другой вариант — повышение оперативности OLAP-базы, например, за счет инкрементального обновления кубов, которое заключается в передаче в хранилище — и оттуда в OLAP — только изменений, произошедших с момента последней синхронизации. Это требует включения механизма регистрации изменений в первичной базе и процедуры синхронизации первичной базы с хранилищем и кубами. Тем не менее этот метод позволяет уменьшить время синхронизации больших баз с часов до минут, то есть сделать OLAP действительно оперативным инструментом анализа.

Миф 3: все виды отчетности — через OLAP

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

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

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

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

Миф 4: работа в OLAP не требует обучения персонала

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

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

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

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

Вадим Ляхин — менеджер проектов, ГК «Инталев», vadim@intalev.com.ua