Отчетность и аналитика для корпоративных данных: подходы и возможности

28 мая 2009 16:00

Рост интереса к проблематике построения систем бизнес-аналитики обусловлен сегодня ситуацией на рынке, которая требует от компаний способности гибко, своевременно и адекватно реагировать на изменения.

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

 

Отчетность на оперативных системах

Отчетность можно получать непосредственно в оперативных системах, которые также называют транзакционными, или OLTP-системами (On-Line Transaction Processing, обработка транзакций в режиме реального времени). К такому классу систем относятся автоматизированные банковские системы (АБС), ERP, системы биллинга, АСУП и др.

Каждая из OLTP-систем позволяет получать только отчеты на основе своих собственных данных, а подготовка бизнес-отчетов, охватывающих «зоны ответственности» разных 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), страхование, телекоммуникационные услуги (мобильная и фиксированная связь), розничные сети, средства массовой информации и некоторые другие.

     



  • © 2020 БАНКОВСКИЕ ТЕХНОЛОГИИ
    Первое издание на российском рынке, посвященное информационным технологиям для банков.
    Москва, Проспект Мира, д.3, корп. 1
    +7 (495) 120-81-42
    info@int-bank.ru

    Свидетельство СМИ ФС77-39103 от 11 марта 2010 года.
    По вопросам сайта просим обращаться к администрации сайта: info@int-bank.ru.
    При использовании материалов необходимо давать ссылку на www.banktech.ru.