Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Журнал ВРМ World

Своевременная бизнес-аналитика

Своевременные данные: консолидация или федерализация?

Автор статьи уже обращал внимание на то, как возрастает интерес организаций к использованию бизнес-аналитики, причем не только для стратегического планирования и тактического анализа, но и в процессе принятия решений в течение дня. Автор обозначает термином оперативная своевременная бизнес-аналитика (Business Intelligence) те средства бизнес-аналитики, которые используются для принятия именно таких "быстрых" решений в течение дня. Слово оперативная указывает, что Business Intelligence применяется для оптимизации ежедневных оперативных бизнес-процессов, а термин своевременная - что эта оптимизация производится с частотой, которая диктуется потребностями бизнеса. Временной масштаб этого понятия может изменяться от текущего момента (т.е. режим реального времени) до нескольких минут или часов.

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

Своевременная консолидация данных

Традиционные средства Хранилищ данных включают осуществление стандартных, обычно пакетных, процессов извлечения, преобразования и загрузки данных (ETL), которые извлекают данные из оперативных источников, преобразуют их и загружают в Хранилище. Таким образом, эти процессы могут рассматриваться как процессы консолидации данных. Другая технология консолидации данных - их репликация. Третий подход - управление контентом корпорации (enterprise content management, сокр. ECM), когда неструктурированные и полу-структурированные данные (документы, рекламные материалы, web-данные) консолидируются и помещаются в репозиторий. Все три типа консолидации данных перемещают или копируют данные из источников в место назначения. Цель консолидации данных - предоставить пользователям ясное, последовательное, интегрированное и управляемое представление данных, которые могут применяться для различных нужд.

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

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

Своевременная федерализация данных

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

В общих чертах, доступ к федеративным данным включает разделение федеративного запроса на подкомпоненты и отправку каждого подкомпонента для обработки туда, где находятся требуемые данные. Сервер федеративных запросов обобщает результаты и посылает ответ в то приложение, от которого поступил запрос. Федерализация данных обеспечивается программными средствами интеграции корпоративной информации (enterprise information integration - EII), которые весьма разнообразны по набору функциональных возможностей. Эффективность и оптимизация запросов, например, - это одна ключевая область, в которой данные продукты существенно отличаются между собой. Другие области включают поддержку неструктурированных данных, а также бизнес-данных в пакетных приложениях от поставщиков, таких как компании SAP и Siebel.

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

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

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

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

Когда стоит использовать федерализацию данных

Вот несколько условий, при которых федерализация данных может рассматриваться как разумный подход.

  • Своевременный доступ к быстро меняющимся данным. Копирование быстро меняющихся данных в операционных системах может оказаться слишком затратным; кроме того, в этом процессе всегда будут задержки. Федерализация может быть использована для прямого доступа к оперативным исходным данным. Но при этом надо не забывать о вопросах эффективности и безопасности, связанных с доступом к оперативной информации. Один и тот же федеративный запрос также может быть использован для доступа как к оперативной информации, так и к историческим данным из Хранилища данных.
  • Прямой доступ к исходным данным с правом записи. Работа с копиями данных обычно не рекомендуется в тех случаях, когда есть необходимость их изменения, так как между копией и оригиналом могут возникнуть проблемы, связанные с целостностью данных. Даже при возможности использования двусторонних средств консолидации данных необходимо применять схемы двухфазного блокирования.
  • Трудности с копированием исходных данных. В тех случаях, когда пользователям необходим доступ к весьма разнородным данным и информации, объединение всех этих структурированных и неструктурированных данных в единой консолидированной копии может быть проблематичным.
  • Стоимость копирования данных превышает стоимость удаленного доступа к ним. Затраты, связанные с возможным негативным влиянием на производительность, а также сетевые затраты, необходимые для доступа к удаленным данным, должны быть сопоставлены с затратами на получение, хранение и поддержку консолидированных данных в едином Хранилище. В некоторых случаях будет очевидно, что лучше использовать федерализацию данных, например, когда объем данных в источниках слишком велик для копирования или когда используется очень небольшая часть скопированных данных.
  • Запрещено копирование исходных данных. Копирование данных из источника, который контролируется другой организацией, может быть невозможно по соображениям безопасности, права собственности или лицензионным причинам.
  • Потребности пользователей не известны заранее. Открытие пользователям прямого и самостоятельного доступа к данным - это очевидный аргумент в пользу федерализации. Здесь, однако, необходима осторожность, поскольку пользователи способны создавать такие запросы, которые потребуют очень много времени на обработку и могут негативно повлиять на работоспособность как источника данных, так и сети. Кроме того, существует риск, что такие запросы могут давать неправильные ответы из-за семантической несогласованности разных складов данных внутри организаций.

Когда стоит использовать консолидацию данных

Аргументы в пользу консолидации данных прямо противоположны аргументам, поддерживающим федерализацию.

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

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