Обобщенная архитектура аналитической рабочей среды организации

С развитием концепции больших данных представление об архитектуре аналитической рабочей среды организации несколько меняется, поскольку контур обработки больших данных стал дополнительным магистральным каналом притока новых сведений. Рисунок 14.4 описывает обобщенную архитектуру рабочих сред организации для областей бизнес-аналитики (на основе традиционного хранилища данных – DW) и науки о данных (на основе хранилища больших данных).

Работа с данными в среде DW/BI осуществляется следующим образом. Из систем-источников данные поступают в область временного хранения, где подвергаются очистке и обогащению, интегрируются и отправляются на хранение в центральное хранилище данных (DW) или хранилище операционных данных (operational data store, ODS). Доступ к данным из DW осуществляется через витрины или кубы (data cube).

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

Для проведения бизнес-анализа в настоящее время предлагается широкий спектр BI-инструментов, которые можно разбить на следующие основные типы[470]:

● операционная отчетность – позволяет выявлять и анализировать краткосрочные (помесячные) и среднесрочные (годовые) тенденции и закономерности;

● управление эффективностью бизнеса (Business Performance Management, BPM) – позволяет производить формальную оценку измеримых показателей, соответствующих целям организации;

● приложения для оперативного анализа – могут включать функции анализа клиентов, финансов, цепочек поставок, организации производства, управления персоналом и т. п.

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

● Реляционная (ROLAP): функциональность OLAP реализуются посредством моделирования многомерности через определение связей между атрибутами стандартных двумерных таблиц систем управления реляционными базами данных. Стандартная схема модели данных в среде ROLAP – звездообразная.

● Многомерная (MOLAP): поддержка OLAP в составе или с использованием коммерческих и специализированных многомерных баз данных.

● Гибридная (HOLAP): сочетание ROLAP и MOLAP. Гибридные реализации позволяют хранить часть данных в MOLAP, а часть – в ROLAP. Реализации могут варьироваться в зависимости от имеющихся у проектировщика возможностей по контролю структуры разделов данных.

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

Выделенные на рисунке 14.4 архитектурные компоненты в различных организациях могут быть реализованы по-разному, в зависимости от выбранного архитектурного подхода. В частности, как мы уже говорили, архитектура Кимбалла подразумевает, что данные в хранилище структурно распределены по витринам данных подразделений, с помощью которых и обеспечивается их очистка, стандартизация и управление. В этом случае именно в витринах хранится история данных на максимально детализированном (атомарном) уровне[471].

Параллельно обработке данных в среде DW/BI во многих организациях осуществляется обработка входящих потоков больших данных. При этом данные сначала загружаются в специальное хранилище – озеро данных (data lake), а затем осуществляется их интеграция и исследование с построением моделей. Работа с большими данными будет рассмотрена более подробно далее (см. раздел 14.3).