Наблюдаемый сегодня рост интереса к вопросам построения систем бизнес-аналитики обусловлен ситуацией на рынке, требующей от компаний способности гибко, своевременно и адекватно реагировать на изменения. Имеющиеся подходы к решению задачи извлечения информации из корпоративных данных обладают рядом ограничений при строго регламентированных возможностях.
Рассмотрим ряд подходов к решению задачи получения необходимой информации из корпоративных данных, а также особенности взаимозависимости между используемой технологической платформой, архитектурой, функциональностью и стоимостью таких систем.
Отчетность на оперативных системах
Отчетность можно получать непосредственно в оперативных системах, называемых транзакционными или OLTP-системами (On-Line Transaction Processing — «оперативная обработка транзакций»), к ним относятся, например, автоматизированные банковские системы, ERP, системы биллинга, АСУП и др. Организация данных в OLTP-системах оптимизирована для быстрой обработки «точечных» запросов. Для этого применяются так называемые «нормализованные» модели данных, которые специально созданы для обработки транзакций и оптимальны для многочисленных точечных операций типа insert и update. Как правило, это третья нормальная форма (3NF). Нормализованные модели очень сложны, что делает работу с ними практически невозможной для аналитиков, и речь в данном случае идет только о более или менее жестком наборе получаемых отчетов.
Обычно OLTP-система позволяет получать отчеты на основе своих собственных данных, а подготовка бизнес-отчетов, охватывающих «зоны ответственности» разных OLTP-систем или нуждающихся в рассмотрении внешних данных, как правило, требует программирования, экспорта в промежуточные форматы, дополнительных расчетов и осуществляется «вручную», что порождает сразу две проблемы: существенные временные затраты на подготовку необходимой информации и повышение вероятности ошибок.
На корректность получаемой информации негативно влияет также и то, что порядок и формат ввода оперативных данных в OLTP-системы, адекватные задачам оперативной обработки, совсем не отвечают требованиям обработки аналитической и статистической. Например, один и тот же клиент может быть заведен в систему много раз, причем с разными форматами записи имени (И. И. Иванов, Иван Иванович Иванов, Иванов И. и т.д.), что не мешает оперативной обработке конкретного взаимодействия с Ивановым, но делает практически невозможным анализ всех взаимодействий с ним, а также получение информации о точном количестве клиентов компании.
Формирование отчетности ложится дополнительной нагрузкой на оперативные системы, которые должны обеспечивать приемлемую производительность при выполнении своей прямой задачи — обработки операций. Попытки разрешить этот конфликт путем разнесения во времени потоков транзакционной обработки и генерации отчетов являются скорее временным обезболиванием, чем терапией, поскольку по мере роста объема данных, количества и сложности отчетов время генерации отчетности начинает превышать допустимую протяженность выделенных для этих операций «окон» (например, отчеты уже не успевают сгенерироваться за ночь). И наконец, оперативные системы накладывают существенные ограничения на хранение ретроспективных данных, так как попросту не предназначены для этого.
Создание копий OLTP-систем
Попыткой разрешить конфликт интересов систем оперативной и аналитической обработки — отделить задачи по получению отчетности и аналитике от обработки транзакций — является создание копий или «реплик» оперативных систем для получения отчетов. При этом данные из «оригинальных» оперативных систем реплицируются в системы-копии без каких бы то ни было изменений структуры. Эта мера позволяет решить только одну проблему — снятия с оперативных систем дополнительной нагрузки для повышения их производительности. Да и эта проблема решается лишь частично, так как сами механизмы репликации, в большинстве случаев основанные на обращении непосредственно к базе данных, снижают производительность систем-источников — обращения к таблицам базы конкурируют с оперативной обработкой транзакций. Исключение составляют технологии репликации, основанные на обращениях не к базе, а к журналу транзакций (например, технология Sybase Replication Server).
Витрины данных
Следующий подход — создание аналитических витрин данных (рис. 1). Витрины не являются просто копиями, в которые реплицируются данные из OLTP-систем, но спроектированы специально для получения отчетов и анализа данных. Это означает, в частности, применение принципиально других схем (моделей) данных, чем те, что применяются в OLTP-системах, а именно денормализованных моделей данных типа «звезда».
При необходимости такие модели легко поддаются дальнейшей денормализации с целью получения более высокой производительности. С этой же целью, а также для снижения затрат на создание и сопровождение витрин данных, во многих случаях в витринах хранят агрегированные (предварительно обработанные) данные, что позволяет сократить их объем.
Следующим принципиальным отличием витрин от копий оперативных систем является то, что данные из систем-источников не просто реплицируются в витрины, а проходят более или менее сложные процессы извлечения, преобразования и загрузки (Extract, Transform, Load, ETL). Эти процессы реализуются по заданным правилам и позволяют извлекать из систем-источников только необходимые для аналитики оперативные данные, осуществлять их очистку (выявлять дубликаты, ошибочные данные), трансформировать (например, с применением заданных алгоритмов получать агрегированные значения) и загружать в витрины. Однако сама природа витрин подразумевает ограниченность отдельной витрины рамками предметной области, задачей конкретного департамента, периодом времени для анализа и т.д. Это приводит к возникновению следующих ситуаций:
-
перекрестный анализ, при котором необходим доступ к данным разных департаментов и, соответственно, разных витрин, оказывается существенно затруднен;
-
из разных витрин зачастую получаются отчеты, противоречащие друг другу (примером может служить случай, когда при расчете прибыльности разные департаменты применяют различные алгоритмы);
-
в различных витринах может использоваться различная терминология (например, департамент продаж понимает под «активным клиентом» того, кто обслуживался последний раз не более месяца назад, а департамент маркетинга трактует «активного клиента» как того, кто обслуживается в компании не менее трех раз в месяц);
-
критически важная для компании информация часто оказывается распределенной по разным витринам, например, информация о клиенте, который пользуется разными продуктами компании (например, в случае со страховой компанией, приобрел добровольное страхование личного автотранспорта, а также страхование жизни), скорее всего, находится в разных витринах, что затрудняет сегментирование и профилирование клиентской базы с целью повышения эффективности маркетинговых кампаний и выявления возможностей для дополнительных и перекрестных продаж;
-
ограниченный доступ к детальным данным значительно затрудняет определенные виды анализа, например, для максимально точного расчета прибыльности нужен доступ именно к детальным транзакционным данным.
Итак, витрины данных являются первым вариантом реальной дифференциации задач OLTP и OLAP (OnLine Analytical Processing, оперативная аналитическая обработка), позволяя решить значительную часть проблем, возникающих при применении систем и технологий, предназначенных для оперативной обработки данных, и решении чужеродных для них задач по получению отчетности и аналитике. При этом витрины не могут решить задачу создания единого корпоративного репозитария данных, необходимого для обеспечения целостной картины бизнеса.
Централизованное корпоративное хранилище
Корпоративное хранилище данных (Enterprise Data Warehouse, EDW) призвано стать единым репозитарием всех данных предприятия, прошедших процессы выверки и очистки на этапе загрузки в хранилище. Этот репозитарий должен служить достоверным, актуальным архивом исторических, не подлежащих изменению данных, а также обеспечивать хранение данных, изменяющихся во времени, поддерживая все потребности разных категорий пользователей компании в области отчетности и аналитики: детализация агрегированных значений в отчетах до уровня транзакционных данных, анализ по всей совокупности корпоративных данных, обработка незапланированных запросов «на лету», а также «добыча данных» и прогнозирование. Корпоративное хранилище данных выполняет две функции: архива детальной информации, накопленной предприятием за продолжительные периоды времени, и аналитической среды, обеспечивающей высокопроизводительную обработку многомерных запросов. Идеальная структура корпоративного хранилища представлена на рис. 2.
СУБД и аналитические хранилища данных
В качестве СУБД для построения хранилищ данных, как правило, используется одна из традиционных «универсальных» реляционных СУБД, а критерием выбора при этом является существующий корпоративный стандарт, наличие корпоративной лицензии и сертифицированных специалистов. Уместно заметить, что все «универсальные» реляционные СУБД были спроектированы более 20 лет тому назад специально для обработки транзакций. И хотя их производители инвестировали огромные средства в оптимизацию своих продуктов для аналитической обработки (например, включение поддержки схемы «звезда» непосредственно в «движки» поставляемых транзакционных СУБД), именно транзакционная природа всех этих серверов стала причиной таких известных явлений, как высокая стоимость повышения производительности хранилища данных (в значительной степени за счет масштабирования оборудования); высокие затраты на администрирование и сложные настройки, особенно при появлении новых запросов; многократное «разбухание» хранилища по сравнению с объемом «сырых» загруженных данных («взрыв данных»).
В случае с предопределенными аналитическими запросами и отчетами любую универсальную реляционную СУБД можно более или менее успешно настроить для достижения приемлемой производительности путем создания требуемых индексов, пусть и ценой дополнительных усилий и увеличения объема базы данных. Оптимизировать универсальную реляционную СУБД раз и навсегда под любые аналитические запросы, которые могут появиться у пользователей, в реальности практически невозможно — фактически это означало бы создание индексов на каждой таблице для всех возможных комбинаций сочетания колонок. Не говоря уже о том, каких затрат потребовало бы создание таких индексов при построении и использовании базы. Кроме этого, объем данных в таком хранилище по сравнению с объемом загружаемых туда «сырых» данных увеличился бы катастрофически.
В 1994 году корпорация Sybase приобрела созданный в компании Expressway Technologies специальный сервер баз данных для обработки незапланированных аналитических запросов [1]. Этот сервер может быть назван инвертной реляционной базой данных, так как, опираясь на традиционную реляционную структуру и терминологию, в отличие от традиционных универсальных реляционных СУБД, использует не построчный принцип хранения данных, а поколоночный. Эта аналитическая СУБД была представлена на рынке под названием Sybase IQ.
Sybase IQ никогда не рекомендуется и не используется для транзакционной обработки данных — единичные операции типа update, insert и delete, составляющие основу транзакционной обработки, выполнялись бы на этой СУБД крайне медленно. Вся идеология Sybase IQ направлена на то, чтобы максимально эффективно справляться с выполнением операций, свойственных аналитической обработке. Скорость обработки незапланированных запросов и генерации аналитических отчетов превосходит производительность универсальных СУБД в десятки–сотни раз [1]. При этом высокая производительность достигается на стандартном аппаратном оборудовании за счет внутреннего дизайна СУБД.
Индексирование в Sybase IQ проводится не под типы запросов, как в традиционных СУБД, а под типы данных [1] — для индексирования не нужно знать, какие запросы и отчеты потребуются в процессе использования хранилища. Индексирование выполняется еще до момента написания запросов, что позволяет в полной мере поддерживать работу пользователя в режиме незапланированных запросов. Разные типы индексов строятся отдельно по каждой колонке в зависимости от типа данных в этой колонке. При обработке запроса сервер автоматически («на лету») комбинирует индексы, что снимает необходимость искать эффективное сочетание колонок для построения по ним индекса для конкретного запроса, как в случае со стандартными универсальными СУБД.
Модель данных корпоративного хранилища
На первый взгляд кажется логичным применить для создания аналитического хранилища денормализованную модель, поскольку, как было уже отмечено, именно такая модель в наибольшей степени адекватна природе аналитической обработки данных. Однако широко распространено убеждение, что схема «звезда», идеально подходящая для построения отдельной витрины данных в конкретной предметной области, не может быть использована для организации всех корпоративных данных в едином хранилище.
Поскольку нормализованная модель не может быть эффективно использована для организации данных с целью их аналитической обработки (в первую очередь из-за своей сложности), а денормализованная модель («звезда») имеет целый ряд специфических особенностей, осложняющих ее использование для построения архива корпоративных данных, традиционным сегодня является подход, при котором происходит разделение архивного и аналитического слоев хранилища данных. Архивный слой традиционно разрабатывается в модели 3NF, или, точнее, в 3NF Time Variant, предложенной Биллом Инмоном и позволяющей хранить изменяющиеся во времени данные, что является обязательным требованием к хранилищу [2]. Над архивным слоем строятся витрины данных с моделью данных «звезда». Они-то и составляют аналитический слой, с которым имеют дело пользователи (рис. 3).
Единый репозитарий данных компании
С момента, когда в архитектуре впервые были совмещены две модели, начались поиски пути эффективного предоставления всей функциональности обоих слоев в одном, а именно в слое, построенном по схеме «звезда». Самым известным противником двухслойного подхода был Ральф Кимбалл [3], однако и ему не удалось воспроизвести все функции архивного слоя в аналитическом слое.
В 1997 году ирландская консалтинговая компания Data Warehouse Network предложила революционный способ Profiling построения баз данных по схеме «звезда», одновременно предназначенный для эффективного хранения исторических данных и высокопроизводительной обработки многомерных запросов. Техника Profiling заключается в том, что между таблицей фактов и таблицами размерностей помещается «профильная таблица» (Profile), обеспечивающая эффективное хранение изменяющихся во времени данных. Эта техника обеспечила полную реализацию функциональности архивного хранилища данных в схеме «звезда», что делает возможным наличие единого хранилища данных, напрямую доступного для анализа.
В 1999 году корпорация Sybase приобрела компанию Data Warehouse Network и создала на базе ее разработок продукт Sybase Industrial Warehouse Studio (IWS) — набор физических моделей данных для ряда основных индустрий: финансовые услуги, страхование, телекоммуникационные услуги, розничные сети, средства массовой информации и некоторые другие.
Объединение функционала аналитического и архивного слоев в едином хранилище данных на базе модели IWS означает прямой доступ для пользователей ко всей совокупности данных, как к агрегированным так и детальным. Это снимает функциональные ограничения, накладываемые витринами. Доступ к данным осуществляется с помощью любых стандартных инструментов, обеспечивающих пользовательский интерфейс для визуализации и построения запросов (Business Objects, Cognos, Microstrategy и др.). При том что c применением IWS отпадает необходимость в создании витрин данных с целью обеспечения высокой производительности и упрощения работы бизнес-пользователей, сохраняется возможность делать это, например, если в качестве одного из аналитических приложений поверх корпоративного хранилища используется готовый специализированный аналитический пакет, например аналитические приложения от компании SAS.
Упрощение архитектуры снижает расходы на построение и сопровождение хранилища, сокращаются затраты на программное и аппаратное обеспечение витрин, исчезает дополнительный уровень ETL между хранилищем и витринами данных.
Техники моделирования, реализованные в моделях IWS, направлены также на обеспечение высокой производительности. Например, в этих моделях реализован подход «Все связано со всем», при котором таблицы фактов связаны со всеми нужными измерениями в пределах одной-двух связей, что обеспечивает высокую производительность обработки запросов на стандартных СУБД и аппаратных серверах.
Возможно, не вполне очевидным результатом является то, что такая организация хранилища делает возможными выполнение реальных незапланированных запросов силами самих бизнес-пользователей. Это происходит в первую очередь за счет «интуитивности» модели — каждая предметная область в IWS (фактически «звезда») организована так же, как понятный пользователю метаслой в инструментах, предоставляющих интерфейс для построения запросов (например, «юниверс» в терминах Business Objects — набор каталогов бизнес-терминов, их параметров и методов извлечения, характерных для предметной области и соответствующих определенным данным), и естественным образом трансформируется в него.
Литература
-
Philip Howard, Sybase IQ — an Evaluation by Bloor Research. December 2006.
-
W. H. Inmon, Claudia Imhoff, Ryan Sousa, Corporate Information Factory. 2nd Edition. Wiley, 2001, ISBN10: 0471399612
-
Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. (Second Edition).
Алена Еникеева (Alyona.Yenikeyeva@sybase.ru) — заместитель генерального директора, Business Development, Sybase CIS (Москва).
