Рост интереса к проблематике построения систем бизнес-аналитики обусловлен сегодня ситуацией на рынке, которая требует от компаний способности гибко, своевременно и адекватно реагировать на изменения.
В статье заместителя генерального директора компании Sybase Алены Еникеевой рассмотрены различные подходы к созданию систем отчетности и бизнес-аналитики, а также взаимозависимость между используемой технологической платформой, архитектурой, функциональностью и стоимостью таких систем.
Отчетность можно получать непосредственно в оперативных системах, которые также называют транзакционными, или OLTP-системами (On-Line Transaction Processing, обработка транзакций в режиме реального времени). К такому классу систем относятся автоматизированные банковские системы (АБС), ERP, системы биллинга, АСУП и др.
Каждая из OLTP-систем позволяет получать только отчеты на основе своих собственных данных, а подготовка бизнес-отчетов, охватывающих «зоны ответственности» разных OLTP-систем, как правило, требует большого количества программирования, экспорта в промежуточные форматы, дополнительных расчетов и осуществляется вручную. Это порождает сразу две проблемы: существенные временные затраты на подготовку нужной информации и высокую вероятность ошибок.
Кроме прочего, формирование отчетности ложится дополнительной нагрузкой на оперативные системы, которые прежде всего должны обеспечивать приемлемую производительность при выполнении своей основной задачи — обработки операций.
Попыткой разрешить конфликт интересов систем оперативной и аналитической обработки является создание копий или реплик оперативных систем для получения отчетов. При этом данные из «оригинальных» оперативных систем реплицируются в системы-копии без каких бы то ни было изменений структуры. Эта мера позволяет решить только одну из перечисленных проблем — снять с оперативных систем дополнительную нагрузку, снижающую их производительность.
Следующий подход — создание аналитических витрин данных. Витрины — это не просто копии, в которые реплицируются данные из OLTP-систем, они спроектированы специально для получения отчетов и анализа данных. Это означает, в частности, что в них применяются принципиально иные схемы (модели) данных, чем в OLTP-системах, а именно денормализованные модели данных типа «звезда».
При этом данные из систем-источников не просто реплицируются в витрины, а проходят более или менее сложные процессы извлечения, преобразования и загрузки (Extract, Transform, Load, ETL). Однако витринам свойственны недостатки, обусловленные их природой, подразумевающей ограниченность отдельной витрины конкретными рамками (предметная область, задача конкретного департамента, ограниченный период времени для анализа и т. д.), а именно:
Итак, витрины данных являются первым вариантом реальной дифференциации задач OLTP и OLAP. При этом витрины не могут решить задачу создания единого корпоративного репозитория данных, необходимого для обеспечения целостной картины бизнеса. В результате компания зачастую имеет лишь приблизительное представление, например, о том, сколько у нее клиентов.
Для преодоления указанных ограничений была предложена концепция хранилища данных масштаба предприятия (Enterprise Data Warehouse, EDW). Среда корпоративного хранилища данных выполняет две функции: во-первых, это архив детальной корпоративной информации за продолжительные периоды времени, во-вторых, аналитическая среда, обеспечивающая высокопроизводительную обработку многомерных запросов.
Идеальную концепцию корпоративного хранилища данных можно изобразить следующим образом (см. рис. 1).
Рис. 1. «Идеальное» корпоративное ХД %images[2]%
В качестве СУБД для построения хранилищ данных, как правило, используется одна из традиционных «универсальных» РСУБД, а критерием выбора при этом является существующий корпоративный стандарт, наличие корпоративной лицензии и сертифицированных специалистов либо пример организации-учредителя. Как правило, вопрос о выборе СУБД для хранилища данных вообще не стоит из-за кажущейся на первой взгляд очевидности выбора. Однако уместно заметить, что все «универсальные» РСУБД были спроектированы более 20 лет тому назад специально для OLTP-обработки данных. И хотя все поставщики инвестировали огромные средства в оптимизацию своих продуктов для аналитической обработки, именно транзакционная природа всех этих серверов является причиной таких известных явлений, как:
Оптимизировать универсальную РСУБД в случае с предопределенными аналитическими запросами можно, а вот раз и навсегда обеспечить возможность ad-hoc-анализа нельзя.
Таким образом, использование универсальных СУБД для построения аналитических хранилищ данных обусловливает, с одной стороны, значительные инвестиции в дополнительное аппаратное и программное обеспечение, людские ресурсы и т. д. для обеспечения приемлемой производительности, а с другой стороны, определяет существенные ограничения функциональной гибкости хранилища данных и количества пользователей системы.
В 1994 г. корпорация Sybase приобрела разработку компании Expressway Technologies — специальный сервер баз данных для обработки аналитических ad-hoc-запросов. Эта аналитическая СУБД получила название Sybase IQ, под которым и была представлена на рынке.
Sybase IQ никогда не рекомендуется и не используется для транзакционной обработки данных, так как поколоночное хранение информации, применяемое в ней, привело бы к крайне медленному выполнению OLTP-операций. Вся идеология Sybase IQ направлена на то, чтобы максимально эффективно справляться с выполнением операций, свойственных аналитической обработке. За счет поколоночного хранения данных Sybase IQ позволяет быстро выполнять массовые операции update, а также эффективно сжимать данные. Данные в Sybase IQ и есть индексы. По статистике, объем данных в Sybase IQ после индексирования на 20–70% меньше объема «сырых» загруженных данных.
Модель данных — второй компонент хранилища, в значительной степени определяющий его функциональные и стоимостные характеристики.
Поскольку нормализованная модель (3NF) не может быть эффективно использована для организации данных с целью их аналитической обработки, а в денормализованной модели («звезда») сложно хранить исторические данные, традиционным сегодня является подход, при котором происходит разделение архивного и аналитического слоев хранилища данных. Архивный слой традиционно разрабатывается в модели 3NF, предложенной Биллом Инмоном (Bill Inmon). Над архивным слоем строятся витрины данных с моделью данных «звезда». Они-то и составляют аналитический слой, с которым имеют дело пользователи.
Такая комбинация архивного и аналитического слоев (рис. 2) внедрена в тысячах компаний во всем мире и реализована в широком спектре предлагаемых готовых решений.
Рис. 2. Традиционный подход к реализации ХД %images[3]%
Очевидно, что при таком подходе пользователи не имеют прямого доступа ко всем корпоративным данным, и в большинстве случаев обращаются не к детальным данным, а к агрегатам, хранящимся в витринах. Таким образом, этот подход к построению корпоративного хранилища несет практически все ограничения витрин данных.
С того момента, когда в архитектуре хранилища были совмещены две модели (эта архитектура впервые была реализована около 1995 г., а к 2000 г. стала «лучшей практикой»), начались поиски пути эффективного предоставления всей функциональности обоих слоев в одном, а именно в слое, построенном по схеме «звезда». Самым известным противником двухслойного подхода был Ральф Кимбалл (Ralph Kimball), который опубликовал множество книг и статей, посвященных хранению исторических данных в схеме «звезда». Однако и ему не удалось воспроизвести все функции архивного слоя в аналитическом слое.
В 1997 г. ирландская консалтинговая компания Data Warehouse Network предложила революционный способ (Profiling) построения баз данных по схеме «звезда», предназначенный одновременно для эффективного хранения исторических данных и высокопроизводительной обработки многомерных запросов. Техника Profiling заключается в том, что между таблицей фактов и таблицами размерностей помещается профильная таблица (Profile), обеспечивающая эффективное хранение изменяющихся во времени данных. Эта техника обеспечила полную реализацию функциональности архивного хранилища данных в схеме «звезда», что сделало возможным существование единого хранилища данных, напрямую доступного для анализа.
В 1999 г. корпорация Sybase приобрела компанию Data Warehouse Network и создала на базе ее разработок продукт Sybase Industrial Warehouse Studio (IWS).
Объединение функционала аналитического и архивного слоев в едином хранилище данных на базе модели IWS обеспечивает прямой доступ для пользователей ко всей совокупности данных, как агрегированных, так и детальных. Доступ к данным осуществляется с помощью любых стандартных инструментов, обеспечивающих пользовательский интерфейс для визуализации и построения запросов (Business Objects, Cognos, Microstrategy и др.). Совместное хранение агрегированных и детальных данных снимает все технологические ограничения по степени детализации при анализе.
Упрощение архитектуры снижает затраты на построение и сопровождение хранилища. Сокращаются затраты на программное и аппаратное обеспечение витрин. Исчезает дополнительный уровень ETL между хранилищем и витринами данных.
Техники моделирования, реализованные в моделях IWS, направлены также на обеспечение высокой производительности. Например, в этих моделях реализован подход «все связано со всем», при котором таблицы фактов связаны со всеми нужными измерениями в пределах одной-двух связей, что обеспечивает высокую производительность обработки запросов на стандартных СУБД и аппаратных серверах.
Сегодня семейство продуктов IWS — это набор индустриальных физических моделей данных для ряда основных индустрий: финансовые услуги (розничный банк, инвестиционный банк, рынок ценных бумаг, обслуживание кредитных карточек, анализ рисков, в том числе по Bazel II), страхование, телекоммуникационные услуги (мобильная и фиксированная связь), розничные сети, средства массовой информации и некоторые другие.
