Хранилище реального времени

Нил Рейден
Независимый эксперт, создает и внедряет информационные хранилища и аналитические приложения для клиентов в Северной Америке и Европе.

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

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

Спрос на прикладные системы реального времени должен вырасти по нескольким причинам, а новые идеи, реализуемые поставщиками, будут находить отклик в среде потребителей. Например, распространение алгоритмов управления, построенных на базе правил (rule engines) создаст необходимость во внедрении более автоматизированных бизнес-процессов (в которых люди вовсе не будет задействованы), и подобная автоматизация является весьма плодородной почвой для внедрения ХДРВ. Когда эти процессы требуют ответов на аналитические вопросы, у человека просто не хватает времени, чтобы обработать запрос с помощью OLAP-инструментария. Приложение тогда само свяжется с генератором запросов. Концепция ХДРВ также стимулирует появление новых бизнес-процессов, когда компании глубоко осознают ее реальные возможности. С дальнейшим распространением идеи ХДРВ окажут воздействие на специалистов-практиков, что резко снизит остроту проблемы, обусловленную задержкой предоставления оперативной информации при исполнении реальных бизнес-процессов и время ответа на те или иные прямые запросы. Хотя, с другой стороны, какой смысл иметь свежие данные, полученные всего несколько минут назад, если на обработку запроса уйдет пять минут, или же целый час на построение витрины данных или куба?

Определение реального времени

Определения ХДРВ различаются, но в основном они оперируют таким понятием, как время ожидания в циклах обновления данных. Я считаю, что хранилище данных реального времени - это такое информационное хранилище, которое обновляется чаще, чем это могут обеспечить процессы извлечения, преобразования и загрузки (ETL-процессы). Скорее всего, ХДРВ потребует перепроектирования ETL-процесса, а также, возможно, и архитектурной схемы. Если системы BI (Business Intelligence) зависят от витрин данных и извлечения данных, перепроектирование потребуется в обязательном порядке. В большинстве случаев одно ХДРВ требует более одного цикла обновления в день.

Некоторые считают, что информационное хранилище, которое предоставляет быстрые ответы на запросы (ну, скажем, менее чем за пять секунд), работает в реальном времени. Хотя использование термина "реальное время" технически не вполне корректно, быстрые отклики на запросы могут быть необходимым компонентом BI в реальном времени, если даже цикл обновления составляет один раз в день, а то и реже. Возьмите, к примеру, онлайновое приложение для кредитной карты от кредитного учреждения. Представьте, что интерактивное приложение посылает запрос в информационное хранилище, чтобы сформулировать оценку кредитоспособности, основанную на 20, 30 или даже 50 атрибутах. Если информационное хранилище может вернуть достоверные результаты в течение нескольких секунд, то к нему можно применить определение ХДРВ. Ральф Кимбэлл в своей книге "Инструментарий сетевого хранилища данных: построение информационного хранилища с возможностью работы в Интернете" (Wiley, 2000 г.) определяет понятие "кэш с быстрым откликом", формируемый хранилищем данных в пакетном режиме, который готов к большому количеству похожих запросов (обычно от пользователей Интернета) и выстраивает очередь из ответов для быстрой доставки.

Запрашивание самых последних данных у системы оперативной обработки лучше всего доверить ей самой. Данные уже там. Но запросы оперативных данных в реальном времени не могут браться только из одной системы. Средства интеграции корпоративных приложений (EAI -- Enterprise Application Intergration) совместно с универсальной архитектурой передачи сообщений открыли путь к реализации новых возможностей всего несколько лет назад. Однако большая часть этих внедрений была связана с работой уже существующих систем, так что внедрение требовало изрядного количества доработок. Инструменты EAI, в свою очередь, не были предназначены для интеграции информации, а были созданы, чтобы осуществить взаимодействие транзакционных OLTP-систем Поэтому в них не содержалось представлений об аналитических запросах, метаданных или каких-либо других полезных конструкциях информационного хранилища.

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

Кому это нужно?

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

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

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

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

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

Как это сделать

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

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

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

Представьте себе новые возможности

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