хранилище данных в реальном времени: технологические решения
По мере развития информационных возможностей компаний современное корпоративное хранилище претерпевает существенные технологические изменения. Очередным крупным шагом на этом пути должно стать ХД, обеспечивающее как анализ исторических данных, так и работу в реальном времени – так называемое «активное» хранилище. Стимулирующими факторами здесь являются растущие потребности клиентов, в частности в отношении скорости предоставления услуг, а также более серьезные нормативные требования к поддержке исторической информации о бизнесе.
Дальновидное руководство понимает, что хранилище может сыграть ключевую роль в реализации всей стратегии бизнеса в целом. Расширяя его применение до уровня сотрудников, занимающихся операционной деятельностью, поставщиков и клиентов, — компании получают растущий объем данных, но при этом обеспечивают принятие более грамотных решений. Информация — это ресурс, зависящий от времени, и ее своевременность напрямую определяет ее ценность для бизнеса.
Когда средства BI не ограничиваются управлением отчетностью за прошлые периоды и долгосрочным планированием, их возможности выходят за рамки предприятия, расширяя круг пользователей (начиная от обслуживающего персонала, сотрудников центров обработки звонков, и закачивая поставщиками, партнерами и даже клиентами).
Традиционные хранилища данных поддерживаются за счет периодического выполнения пакетных работ, когда из операционных данных извлекаются некоторые большие выборки долговременных данных, проводится их очистка, преобразование и загрузка в хранилище. Эффективное «активное» хранилище, требует постоянного обнаружения и доставки в него данных в реальном времени из ключевых транзакционных систем.
Для интеграции в реальном времени существующий пакетный метод нужно заменить на процессы, которые непрерывно отслеживают состояние исходных систем, фиксируют и преобразуют изменения в данных по мере их возникновения, а затем загружают эти изменения в хранилище; и чем режим их работы ближе к реальному времени, тем лучше.
В последнее время новые технологии, такие как передача сообщений (messaging) и интеграция корпоративных приложений (EAI), обеспечили лучшие возможности построения активных хранилищ данных и более качественную интегрированную аналитику.
XML и обмен сообщениями
В конце 90-х компании рассматривали XML как универсальное средство для передачи своевременных транзакционных данных в хранилище. Идея состояла в том, чтобы по мере возникновения транзакций обеспечивать постоянные синхронные обновления систем поддержки принятия решений. Но, хотя эта концепция и казалась простой, у нее есть ряд скрытых особенностей. Во-первых, для каждой операции транзакционная система должна генерировать документ в фиксированном формате, а это может оказаться затратным по времени. Во-вторых, документы часто становятся большими по объему за счет тэгов и метаданных. Например, транзакции на основе протокола XMPP (Extensible Messaging and Presence Protocol, расширяемый протокол сообщений и присутствия) содержат для каждой точки данных открывающие и закрывающие тэги. Чтобы послать простую запись, содержащую всего лишь имя и фамилию, необходимо сгенерировать следующий код:
<first_name>Jim</first_name>
<last_name>Smith</last_name>
То есть сама запись содержит только 8 символов, а передаваемый документ — 55 символов. Еще больший объем возникает в результате описания типов, заголовков и т.п. В результате XML-протоколы не могут широко использоваться в очень крупных хранилищах, куда поступают миллионы транзакций в день. Однако XML очень удобен при передаче коротких сообщений, а также и в веб-приложениях для передачи транзакций в СУБД.
Отдельные поставщики выбрали иной подход к обмену сообщениями и создали стандарты интерфейсов, такие как электронный обмен данными (Electronic Data Interchange, EDI), или IDocs, которые упрощают форматирование и передачу транзакционных записей. Сокращение накладных расходов, связанное с использованием этих форматов, позволило компаниям автоматически передавать записи в свои вновь созданные хранилища в реальном времени.
мгновенная передача сообщений для операционной отчетности в хранилище данных
В 2003 году, основными претендентами в стандартизации мгновенной передачи сообщений были XMPP и SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions).
Как уже говорилось, XMPP удобен для обработки коротких записей, например SMS-трафика. Но вызывает серьезные накладные расходы при передачи больших объемов транзакций. С другой стороны, недостаток его конкурента (SIMPLE) состоит в том, что он обеспечивает поддержку для простых текстовых сообщений, но не работает для других форматов. Поэтому каждому поставщику приходится разрабатывать свои собственные расширения, которые в итоге оказываются несовместимыми. Еще одна проблема с протоколом SIMPLE — это поддержка протокола UDP, а также TCP на уровне передачи. Поскольку UDP не предусматривает контроля качества доставки, то пакеты данных могут быть потеряны, а возможности возобновления и контроля процесса ограничены. Это очень плохо для крупных систем отчетности, качество работы которых напрямую зависит о своевременных, точных и полных данных.
Таким образом, первые версии SIMPLE не получили широкого применения для хранилищ данных в реальном времени и систем отчетности.
Microsoft становится поставщиком средств интеграции приложений
Хотя с протоколом SIMPLE возникает ряд проблем, тем не менее, он стал хорошей платформой для многих поставщиков. В 2003 году компания Microsoft разработала проект под названием Real-Time Communication Server, расширяющий протокол SIMPLE. А в 2004 году была запущена новая версия продукта для передачи сообщений, известного под названием BizTalk Server 2004. Он был призван решать две важные цели. В первую очередь, предполагалось обеспечение интеграции B2B. Во-вторых, этот продукт должен был стать платформой для интеграции корпоративных приложений, в том числе транзакционных систем и средств отчетности внутри организации.
Компания Microsoft обеспечила более удобную альтернативу очень сложному процессу стандартизации, который охватывал несколько десятков пересекающихся стандартов и подходов к EAI. Ключевая архитектура BizTalk Server — это упрощенная серверная система. Для поддержки принятия решений в EAI-инфраструктуре Biztalk обеспечивает услуги бизнес-операций (Business Activity Services, BAS), устанавливаемые на исходной системе для обеспечения сообщений. Кроме того, администратор хранилища может отслеживать процесс загрузки из нескольких исходных систем, используя инструмент мониторинга бизнес-операций (BAM), входящий в состав Biztalk.
Biztalk 2004 был хорошим шагом вперед в области EAI. В процессе развития продукт был дополнен средствами балансировки загрузки сети (Network Load Balancing, NLB) и расширенной консолью управления (Enhanced Management Console, MMC), предназначенной для удаленного управления и конфигурирования множество исходных систем с установленной услугой BAS. В 2006 году вышла новая версия BizTalk Server 2006, вобравшая в себя ряд конструктивных изменений.
можно ли доверять технологии передачи сообщений как средству обеспечения данных?
Надежность — это одна из главных проблем при передаче сообщений в хранилище. Сегодня существует три основных уровня надежности. Во-первых, можно получить подтверждение, что записи отправлены. Во-вторых, можно получить подтверждение, что они были отправлены не один раз. В-третьих, можно получить подтверждение, что они отправлены строго один раз. Однако очень сложно вновь запустить отправку сообщений, если они уже отсылались, даже если они не были получены (как понять, что транзакция не была получена?)
Поборники XML-инструментов предложили стандарт под названием WS-Reliability. Это простой путь пакетирования каждой записи перед отсылкой ее в хранилище. Кроме того, он позволяет отслеживать передачу и возобновлять процесс, если произошел сбой. При использовании WS-Reliability записи пакетируются с помощью SOAP. Эти пакеты могут отсылаться в любой момент, даже в асинхронном режиме. Можно также использовать и другие стандарты, в том числе AS2, RNIF или XML (ebXML).
Компания Microsoft объединила свои усилия с IBM, BEA Systems и TIBCO для разработки стандарта более высокой надежности. В апреле 2005 года состоялась встреча, на которой был заявлено, что OASIS принимает стандарт, названный Web Services Reliable Messaging (WS-RM). Стандарт получил хорошую поддержку от многих производителей программного обеспечения, а также от государственных учреждений и правительств.
Стандарту WS-RM предстоит пройти еще немалый путь в борьбе за победу в сфере EAI. А технология передачи сообщений наконец обретет свой потенциал для обеспечения бесперебойной передачи записи между транзакционными и аналитическими системами внутри организаций и между бизнес-партнерами.
современные реалии
Однако, ожидая появления на рынке самых последних инструментов, множество компаний по-прежнему заполняет системы отчетности данными с помощью асинхронных ночных загрузок. Ситуация стала постепенно меняться. Целый ряд компаний повысил частоту загрузок до нескольких раз в день. Стимулирующим фактором для них стало упрощение разработки программ извлечения, которые просто выбирают измененные записи в транзакционной системе. Среди других причин можно назвать возможность параллельной загрузки данных, повышение надежности сетей и доступности лучших пакетных DW- средств среди ERP-поставщиков. Другие производители тоже не отстают, и сегодня почти все ERP-разработчики обеспечивают возможность загрузки дельта-записей (только измененных или новых записей) в свое стандартное хранилище. За счет этого удается обеспечить более своевременную операционную отчетность, не возлагая дополнительной нагрузки на транзакционные системы.
Некоторые из поставщиков средств интеграции приложений обеспечивают возможности фиксации определенных событий в потоке транзакций для анализа. Ряд производителей обеспечивает свои собственные инструменты операционного анализа и инструментальные панели. Среди них можно назвать IBM (WebSphere Business Monitor), Microsoft (BizTalk Server). Такой подход делает процесс фиксации более эффективным и сокращает латентность данных. Механизм интеграции данных может фиксировать изменения в операционных системах путем отслеживания событий как в данных, так и в приложениях. Мониторинг событий данных включает в себя известные СУБД-методы, такие как триггеры БД, репликацию данных и обработку журналов восстановления БД. Для поддержки мониторинга событий приложений поставщики ХД разработали специальные интерфейсы к ПО передачи сообщений и интеграции корпоративных приложений, также обеспечивая поддержку веб-сервисов.
зачем нужно физическое хранилище данных?
Обсуждая интеграцию корпоративных приложений и мгновенную передачу сообщений, мы вдруг обратились к вопросу о необходимости выделения хранилища в виде физической структуры вне транзакционной системы компании. Почему бы не выполнять запросы напрямую на транзакционной системе, просто использовав больше аппаратной памяти и процессоров? Такой вопрос встает часто. И хотя эксперты с традиционным подходом не хотят этого признавать, однако для небольших компаний, вложивших средства в ERP, владеющих сравнительно небольшим объемом данных и имеющих в штате всего лишь несколько аналитиков, это может быть хорошим выходом.
Для таких некрупных фирм создание отчетных таблиц внутри транзакционной системы с «отчетными записями» — это, по сути, создание репозитория операционных данных, фактически, с нулевой временной задержкой. Подобные системы можно оптимизировать для отчетности и аналитики, сокращая сложность таблиц (выполняя денормализацию). В эти случаях хранилище являет собой виртуальную сущность, в которой доступ к данным ведется в реальном времени.
Однако на каком-то этапе роста компании необходимо создание физического хранилища, так как. в худшем случае аналитические операции начнут мешать выполнению базовых функций транзакционной системы (таких как прием заказов, управление складом, отгрузками, производством).
Что нас ждет в будущем?
В целом можно сказать, что именно в области обработки данных в реальном времени заложен большой потенциал для развития технологии хранилищ данных. Средства интеграции приложений, а также наработки самих поставщиков средств business intelligence, нацелены на решение такой задачи. В итоге компании-клиенты обретут средства, позволяющие не только анализировать произошедшие в прошлом события, но и текущую ситуацию, а также строить прогнозы на будущее.
Поиск средств реализации хранилища в реальном времени в значительной степени зависит от грамотного выбора подхода, который позволит не только повысить качество информации в хранилище, но и сделает ее надежной и актуальной. Критерии выбора могут учитывать такие соображения, как частота обновления данных, приемлемое устаревание, объемы, целостность данных, требования к преобразованию и ограничения по обработке.
Кроме вышеперечисленных факторов необходимо также учитывать такие возможности как:
интеграция метаданных;
параллельная обработка;
средства обработки документооборота;
двунаправленная обработка (как входящих, так и исходящих сообщений);
поддержка стандартов;
масштабируемость;
фиксация изменений в данных;
обеспечение средств разработки интерфейса.
Intersoft Lab по материалам зарубежных сайтов¶
Дальновидное руководство понимает, что хранилище может сыграть ключевую роль в реализации всей стратегии бизнеса в целом. Расширяя его применение до уровня сотрудников, занимающихся операционной деятельностью, поставщиков и клиентов, — компании получают растущий объем данных, но при этом обеспечивают принятие более грамотных решений. Информация — это ресурс, зависящий от времени, и ее своевременность напрямую определяет ее ценность для бизнеса.
Когда средства BI не ограничиваются управлением отчетностью за прошлые периоды и долгосрочным планированием, их возможности выходят за рамки предприятия, расширяя круг пользователей (начиная от обслуживающего персонала, сотрудников центров обработки звонков, и закачивая поставщиками, партнерами и даже клиентами).
Традиционные хранилища данных поддерживаются за счет периодического выполнения пакетных работ, когда из операционных данных извлекаются некоторые большие выборки долговременных данных, проводится их очистка, преобразование и загрузка в хранилище. Эффективное «активное» хранилище, требует постоянного обнаружения и доставки в него данных в реальном времени из ключевых транзакционных систем.
Для интеграции в реальном времени существующий пакетный метод нужно заменить на процессы, которые непрерывно отслеживают состояние исходных систем, фиксируют и преобразуют изменения в данных по мере их возникновения, а затем загружают эти изменения в хранилище; и чем режим их работы ближе к реальному времени, тем лучше.
В последнее время новые технологии, такие как передача сообщений (messaging) и интеграция корпоративных приложений (EAI), обеспечили лучшие возможности построения активных хранилищ данных и более качественную интегрированную аналитику.
XML и обмен сообщениями
В конце 90-х компании рассматривали XML как универсальное средство для передачи своевременных транзакционных данных в хранилище. Идея состояла в том, чтобы по мере возникновения транзакций обеспечивать постоянные синхронные обновления систем поддержки принятия решений. Но, хотя эта концепция и казалась простой, у нее есть ряд скрытых особенностей. Во-первых, для каждой операции транзакционная система должна генерировать документ в фиксированном формате, а это может оказаться затратным по времени. Во-вторых, документы часто становятся большими по объему за счет тэгов и метаданных. Например, транзакции на основе протокола XMPP (Extensible Messaging and Presence Protocol, расширяемый протокол сообщений и присутствия) содержат для каждой точки данных открывающие и закрывающие тэги. Чтобы послать простую запись, содержащую всего лишь имя и фамилию, необходимо сгенерировать следующий код:
<first_name>Jim</first_name>
<last_name>Smith</last_name>
То есть сама запись содержит только 8 символов, а передаваемый документ — 55 символов. Еще больший объем возникает в результате описания типов, заголовков и т.п. В результате XML-протоколы не могут широко использоваться в очень крупных хранилищах, куда поступают миллионы транзакций в день. Однако XML очень удобен при передаче коротких сообщений, а также и в веб-приложениях для передачи транзакций в СУБД.
Отдельные поставщики выбрали иной подход к обмену сообщениями и создали стандарты интерфейсов, такие как электронный обмен данными (Electronic Data Interchange, EDI), или IDocs, которые упрощают форматирование и передачу транзакционных записей. Сокращение накладных расходов, связанное с использованием этих форматов, позволило компаниям автоматически передавать записи в свои вновь созданные хранилища в реальном времени.
мгновенная передача сообщений для операционной отчетности в хранилище данных
В 2003 году, основными претендентами в стандартизации мгновенной передачи сообщений были XMPP и SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions).
Как уже говорилось, XMPP удобен для обработки коротких записей, например SMS-трафика. Но вызывает серьезные накладные расходы при передачи больших объемов транзакций. С другой стороны, недостаток его конкурента (SIMPLE) состоит в том, что он обеспечивает поддержку для простых текстовых сообщений, но не работает для других форматов. Поэтому каждому поставщику приходится разрабатывать свои собственные расширения, которые в итоге оказываются несовместимыми. Еще одна проблема с протоколом SIMPLE — это поддержка протокола UDP, а также TCP на уровне передачи. Поскольку UDP не предусматривает контроля качества доставки, то пакеты данных могут быть потеряны, а возможности возобновления и контроля процесса ограничены. Это очень плохо для крупных систем отчетности, качество работы которых напрямую зависит о своевременных, точных и полных данных.
Таким образом, первые версии SIMPLE не получили широкого применения для хранилищ данных в реальном времени и систем отчетности.
Microsoft становится поставщиком средств интеграции приложений
Хотя с протоколом SIMPLE возникает ряд проблем, тем не менее, он стал хорошей платформой для многих поставщиков. В 2003 году компания Microsoft разработала проект под названием Real-Time Communication Server, расширяющий протокол SIMPLE. А в 2004 году была запущена новая версия продукта для передачи сообщений, известного под названием BizTalk Server 2004. Он был призван решать две важные цели. В первую очередь, предполагалось обеспечение интеграции B2B. Во-вторых, этот продукт должен был стать платформой для интеграции корпоративных приложений, в том числе транзакционных систем и средств отчетности внутри организации.
Компания Microsoft обеспечила более удобную альтернативу очень сложному процессу стандартизации, который охватывал несколько десятков пересекающихся стандартов и подходов к EAI. Ключевая архитектура BizTalk Server — это упрощенная серверная система. Для поддержки принятия решений в EAI-инфраструктуре Biztalk обеспечивает услуги бизнес-операций (Business Activity Services, BAS), устанавливаемые на исходной системе для обеспечения сообщений. Кроме того, администратор хранилища может отслеживать процесс загрузки из нескольких исходных систем, используя инструмент мониторинга бизнес-операций (BAM), входящий в состав Biztalk.
Biztalk 2004 был хорошим шагом вперед в области EAI. В процессе развития продукт был дополнен средствами балансировки загрузки сети (Network Load Balancing, NLB) и расширенной консолью управления (Enhanced Management Console, MMC), предназначенной для удаленного управления и конфигурирования множество исходных систем с установленной услугой BAS. В 2006 году вышла новая версия BizTalk Server 2006, вобравшая в себя ряд конструктивных изменений.
можно ли доверять технологии передачи сообщений как средству обеспечения данных?
Надежность — это одна из главных проблем при передаче сообщений в хранилище. Сегодня существует три основных уровня надежности. Во-первых, можно получить подтверждение, что записи отправлены. Во-вторых, можно получить подтверждение, что они были отправлены не один раз. В-третьих, можно получить подтверждение, что они отправлены строго один раз. Однако очень сложно вновь запустить отправку сообщений, если они уже отсылались, даже если они не были получены (как понять, что транзакция не была получена?)
Поборники XML-инструментов предложили стандарт под названием WS-Reliability. Это простой путь пакетирования каждой записи перед отсылкой ее в хранилище. Кроме того, он позволяет отслеживать передачу и возобновлять процесс, если произошел сбой. При использовании WS-Reliability записи пакетируются с помощью SOAP. Эти пакеты могут отсылаться в любой момент, даже в асинхронном режиме. Можно также использовать и другие стандарты, в том числе AS2, RNIF или XML (ebXML).
Компания Microsoft объединила свои усилия с IBM, BEA Systems и TIBCO для разработки стандарта более высокой надежности. В апреле 2005 года состоялась встреча, на которой был заявлено, что OASIS принимает стандарт, названный Web Services Reliable Messaging (WS-RM). Стандарт получил хорошую поддержку от многих производителей программного обеспечения, а также от государственных учреждений и правительств.
Стандарту WS-RM предстоит пройти еще немалый путь в борьбе за победу в сфере EAI. А технология передачи сообщений наконец обретет свой потенциал для обеспечения бесперебойной передачи записи между транзакционными и аналитическими системами внутри организаций и между бизнес-партнерами.
современные реалии
Однако, ожидая появления на рынке самых последних инструментов, множество компаний по-прежнему заполняет системы отчетности данными с помощью асинхронных ночных загрузок. Ситуация стала постепенно меняться. Целый ряд компаний повысил частоту загрузок до нескольких раз в день. Стимулирующим фактором для них стало упрощение разработки программ извлечения, которые просто выбирают измененные записи в транзакционной системе. Среди других причин можно назвать возможность параллельной загрузки данных, повышение надежности сетей и доступности лучших пакетных DW- средств среди ERP-поставщиков. Другие производители тоже не отстают, и сегодня почти все ERP-разработчики обеспечивают возможность загрузки дельта-записей (только измененных или новых записей) в свое стандартное хранилище. За счет этого удается обеспечить более своевременную операционную отчетность, не возлагая дополнительной нагрузки на транзакционные системы.
Некоторые из поставщиков средств интеграции приложений обеспечивают возможности фиксации определенных событий в потоке транзакций для анализа. Ряд производителей обеспечивает свои собственные инструменты операционного анализа и инструментальные панели. Среди них можно назвать IBM (WebSphere Business Monitor), Microsoft (BizTalk Server). Такой подход делает процесс фиксации более эффективным и сокращает латентность данных. Механизм интеграции данных может фиксировать изменения в операционных системах путем отслеживания событий как в данных, так и в приложениях. Мониторинг событий данных включает в себя известные СУБД-методы, такие как триггеры БД, репликацию данных и обработку журналов восстановления БД. Для поддержки мониторинга событий приложений поставщики ХД разработали специальные интерфейсы к ПО передачи сообщений и интеграции корпоративных приложений, также обеспечивая поддержку веб-сервисов.
зачем нужно физическое хранилище данных?
Обсуждая интеграцию корпоративных приложений и мгновенную передачу сообщений, мы вдруг обратились к вопросу о необходимости выделения хранилища в виде физической структуры вне транзакционной системы компании. Почему бы не выполнять запросы напрямую на транзакционной системе, просто использовав больше аппаратной памяти и процессоров? Такой вопрос встает часто. И хотя эксперты с традиционным подходом не хотят этого признавать, однако для небольших компаний, вложивших средства в ERP, владеющих сравнительно небольшим объемом данных и имеющих в штате всего лишь несколько аналитиков, это может быть хорошим выходом.
Для таких некрупных фирм создание отчетных таблиц внутри транзакционной системы с «отчетными записями» — это, по сути, создание репозитория операционных данных, фактически, с нулевой временной задержкой. Подобные системы можно оптимизировать для отчетности и аналитики, сокращая сложность таблиц (выполняя денормализацию). В эти случаях хранилище являет собой виртуальную сущность, в которой доступ к данным ведется в реальном времени.
Однако на каком-то этапе роста компании необходимо создание физического хранилища, так как. в худшем случае аналитические операции начнут мешать выполнению базовых функций транзакционной системы (таких как прием заказов, управление складом, отгрузками, производством).
Что нас ждет в будущем?
В целом можно сказать, что именно в области обработки данных в реальном времени заложен большой потенциал для развития технологии хранилищ данных. Средства интеграции приложений, а также наработки самих поставщиков средств business intelligence, нацелены на решение такой задачи. В итоге компании-клиенты обретут средства, позволяющие не только анализировать произошедшие в прошлом события, но и текущую ситуацию, а также строить прогнозы на будущее.
Поиск средств реализации хранилища в реальном времени в значительной степени зависит от грамотного выбора подхода, который позволит не только повысить качество информации в хранилище, но и сделает ее надежной и актуальной. Критерии выбора могут учитывать такие соображения, как частота обновления данных, приемлемое устаревание, объемы, целостность данных, требования к преобразованию и ограничения по обработке.
Кроме вышеперечисленных факторов необходимо также учитывать такие возможности как:
интеграция метаданных;
параллельная обработка;
средства обработки документооборота;
двунаправленная обработка (как входящих, так и исходящих сообщений);
поддержка стандартов;
масштабируемость;
фиксация изменений в данных;
обеспечение средств разработки интерфейса.
Intersoft Lab по материалам зарубежных сайтов¶
Сетевые решения. Статья была опубликована в номере 08 за 2007 год в рубрике технологии
