Автор: Colin White
Дата публикации оригинала: 2008-04-30
Источник: Сайт BeyeNETWORK

Роль хранилищ данных (DWH) изменяется по мере того, как компании переходят к применению новых подходов в бизнес-аналитике.

Некоторое время назад в этой группе новостей я писал о влиянии подходов Enterprise 2.0 на бизнес-аналитику (BI). Сейчас я собираюсь написать о том, как бизнес-аналитика и хранилища данных могут использовать растущее значение бизнес-контента, создаваемого коллаборативными и социальными сетевыми технологиями Enterprise 2.0. Однако я решил, что перед этим я вначале должен пересмотреть роль хранилищ данных в проектах BI, потому что компании переходят к использованию новых подходов в бизнес-аналитике (например, в операционной BI), и эта роль изменяется.

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

Исторический аспект

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

Перед представлением содержания бизнес-аналитики многие компании анализируют свои бизнес-операции, используя приложения поддержки принятия решений (DSS), которые составляют запросы и отчёты напрямую по данным, хранящимся в базах данных бизнес-транзакций. При этом подходе существовало несколько проблем. Пятью основными проблемами являлись следующие:

  1. данные не всегда были в подходящей для отчета форме,
  2. данные зачастую имели проблемы с качеством (data quality),
  3. обработка для поддержки принятия решений ухудшала эффективность бизнес-транзакций,
  4. данные зачастую были распределены между большим количеством различных систем,
  5. имелась существенная нехватка исторической информации (historical data).

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

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

Традиционная бизнес-аналитика

Традиционно бизнес-аналитика в течение многих лет использовалась для принятия стратегических и тактических решений. Этот тип процессов включает в себя тщательную аналитическую обработку исторических (historical data) и сводных данных (summarized data), управление которыми осуществляется в хранилище данных предприятия (EDW). Проблемы эффективности данных, вызванные концентрированием данных в хранилище данных предприятия, привели к созданию витрин данных (data mart), которые решают проблемы с эффективностью путем распространения процессов обработки BI между многими хранилищами данных.

Проблема с витринами данных заключается в том, что организации зачастую строят их напрямую из баз данных бизнес-транзакций, а не из хранилища данных предприятия. Это происходит потому, что зачастую быстрее и легче построить витрину данных, чем вносить дополнительные данные в хранилище данных предприятия и строить витрину данных из хранилища данных. Другая проблема состоит в том, что многие организации имеют более одного хранилища данных «предприятия». Большое количество разъединённых хранилищ данных и витрин данных сталкивает нас с проблемами, связанными с целостностью (согласованностью) данных (data quality), которые, предполагалось, построение хранилищ данных будет решать в первую очередь.

Имеется много статей, написанных о проблемах построения десятков независимых витрин данных напрямую из операционных данных, и я не хочу обсуждать здесь эту проблему. Однако необходимо отметить, что витрина данных решает большую часть тех же вопросов, которые должно решать хранилище данных предприятия, с тем только исключением, что решения, происходящие из большого количества витрин данных, могут быть несогласованными (несовместимыми) точно так же, как могут быть несогласованными (несовместимыми) решения, основывающиеся на большом количестве баз данных бизнес-транзакций. Вопрос, связанный с большим количеством источников, можно смягчить, если в первую очередь интегрировать данные бизнес-транзакций, например, в оперативный склад данных (ODS) или хранилище основных данных (master data store). Здесь необходимо указать на вопрос, связанный с историческими данными, однако это решаемый вопрос.

Исторические данные и текущие данные

Различие между историческими и текущими данными должно выявляться легко, однако, это не так. Данные в хранилище данных бизнес-транзакций обычно являются текущими, хотя хранилище данных обычно рассматривается как историческое. Здесь возникает вопрос: “Что имеется ввиду под текущими и историческими?” Давайте посмотрим на пример.

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

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

В случае с данными CDR другая ситуация. В общем и целом, после того как я сделал телефонный звонок CDR для этого звонка никогда не меняются. Когда телефонная компания помещает CDR в хранилище данных для анализа, то являются ли эти данными текущими или историческими? Ответ состоит в том, что это текущие данные; хотя эти данные и устаревают со временем, однако они всегда остаются текущей версией данных. Как мы назовем хранилище данных CDR? Я предполагаю, что большинство людей назвало бы это витриной данных. Является ли это правильным названием? Имеет ли какую-то роль то, как мы назовем это, кроме того факта, что некоторые люди должны давать названия вещам? Вне зависимости от этого, мы, скорее всего, не захотим хранить данные CDR в хранилище данных предприятия. Однако полезно сохранять историческую запись результатов анализа CDR, потому что это со временем это показывает нам общие тенденции и модели.

Если информация CDR используется для обнаружения фактов мошенничества (fraud detection), то чем быстрее мы произведем анализ, тем быстрее сможем обнаружить факты мошенничества. Приложение бизнес-аналитики может обрабатывать данные «на лету», при их прохождении через систему, либо может производить анализ в хранилище постоянных данных, которое непрерывно пополняется данными CDR. Добыча данных (data mining) из прошлых записей CDR может помочь установить бизнес-правила для обнаружения факта мошенничества. Это приложение для обнаружения фактов мошенничества является хорошим примером приложения операционной BI.

Операционная бизнес-аналитика

Существует все возрастающее количество операционных бизнес-приложений, которые похожи на описанные ранее для анализа CDR. Коммерческая выгода этих приложений состоит в том, что они могут помогать компаниям становиться более динамичными, анализируя данные операций внутри дня. Итоговым примером этого типа обработки может стать алгоритмическая торговля (algorithmic trading), которая осуществляет обработку сложных событий (CEP) и направляет аналитические материалы для оптимизации торговых операций. Время реакции этих аналитических операций составляет долю секунды. При этом типе обработки нецелесообразно и не нужно хранить большие объемы задействованных данных в хранилище. Однако результаты процессов BI могут сохраняться для будущего использования.

Моделью для многих приложений операционной бизнес-аналитики является сбор данных, анализ данных и сохранение результатов (например, они анализируют данные перед их сохранением). Это отличается от традиционных BI-моделей сбора данных, сохранения данных, анализа данных и сохранения результатов. Другим примером операционной BI являются приложения BI, которые анализируют веб-трафик и бизнес-деятельность на коммерческих сайтах для отслеживания покупательских тенденций, оптимизации цен (price optimization) и так далее. Хотя эти приложения анализируют данные «на лету», они также могут использовать и исторические данные в хранилище данных для помощи в анализе.

Почему важно обсуждение этой темы? Основной причиной является то, что в настоящее время бизнес-аналитика является синонимом построения хранилищ данных. Это неправильный подход, и он должен быть изменён. Организация хранилищ данных является компонентом бизнес-аналитики, но бизнес-аналитика может помещать данные и в другие хранилища данных. В некоторых случаях приложение BI может даже не использовать данные, управление которыми осуществляется в хранилище данных. Тесная связь между бизнес-аналитикой и построением хранилищ данных является причиной использования таких терминов, как построение хранилищ виртуальных данных и виртуальная BI для описания других типов обработки BI. Эти термины являются ненужными и только путают всех.

Другим вопросом является то, что люди забыли, что построение хранилищ данных было создано для преодоления недостатков в системах бизнес-транзакций. Многие из этих вопросов сегодня могут быть решены. Меня волнует то, что построение хранилищ данных стало системой со своими собственными правами, и что компании сегодня распространяют хранилище данных на другие прикладные области, такие как управление основными данными (MDM) и управление контентом (content management). Это абсолютно неправильное направление, которое должно оспариваться.

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


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: