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

Журнал ВРМ World

Нужна ли хранилищам данных чрезмерная оперативность?

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

Согласно оценкам IDC, лишь в 17% организаций отмечают, что их устраивает производительность процесса загрузки данных в хранилище. Часть проблемы заключается в том, что во многих случаях традиционное ETL-приложение (Extract, Transform, Load - извлечение, преобразование, загрузка) использовалось для реализации всех требований, связанных с миграцией данных. Дело в том, что всё чаще подобная стратегия «единого размера, подходящего всем» не работает. Даже если в организации уже построено хранилище данных и используются ETL-инструменты, требуется обратиться к другим подходам для перемещения данных в режиме реального времени, чтобы обеспечить приемлемую актуальность данных в хранилище.

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

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

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

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

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

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

Чтобы достичь действительно максимально возможной оперативности, необходимо существенно изменить как инструментарий, так и архитектуру системы. Одним из способов решения проблемы в такой базе данных может стать создание промежуточной области (staging area), где информация будет загружаться и трансформироваться перед отправкой в базу данных. Это можно осуществить путём создания отдельного набора таблиц в главной базе данных или внедрения «теневой» системы, содержащей её копию на отдельном сервере. В любом случае ETL-процедуры выполняются на суррогатной базе и очищенные данные загружаются в основные таблицы.

Наличие «теневой» системы довольно дорого обходится, поскольку требует, по существу, дубликата хранилища данных. Однако это меньше влияет на производительность, особенно на время обработки запросов. В любом случае стоит отметить, что может понадобиться блокирование запросов на момент обновления главной базы данных. Другой вопрос для рассмотрения – это кэширование. В многих хранилищах данных его активно применяют для ускорения отклика на запросы. В системах реального времени кэш должен постоянно обновляться, чтобы обеспечить свою целостность. Поскольку зачастую это медленный процесс, производительность хранилища данных, вероятно, пострадает. По сути, переход к хранилищу данных, работающему в режиме реального времени, это пример надуманной проблемы. Результат может быть благоприятным, но его достижение требует непропорциональных усилий и затрат. Что делает этот вопрос вопросом рентабельности. Зачастую потребуется тщательное исследование, чтобы определить, что выгода перевешивают затраты.

Публикации

  1. Дэн Вессет (Dan Vesset). Хранилища данных с малой задержкой: ответ на большой вопрос о больших данных (Low-Latency Data Warehousing: Answering Big Questions About Big Data). Август 2011 г.
  2. Рик Кук (Rick Cok). Хранилище данных в реальном времени – имеет ли смысл? (Real Time Data Warehouse - Is It Worth It?