Системы интеллектуальной обработки данных реального времени
Хранилища данных и приложения интеллектуальной обработки данных традиционно использовали "устаревшие" данные, данные с большой задержкой обновления - т.е. данные, обновляемые раз в месяц, неделю или день. Традиционалисты считают, что система интеллектуальной обработки данных реального времени (real time BI) вообще является сочетанием несочетаемого - для принятия стратегических решений не требуются данные, обновляемые чаще раза в сутки. Что упускают эти люди, так это то, что системы интеллектуальной обработки данных должны быть доступны всем на предприятии, а не только нескольким аналитикам и менеджерам для принятия стратегических и тактических решений. Оперативная интеллектуальная обработка данных требует данных с небольшой задержкой обновления.
В Analysis Services 2005 представлены новые возможности обработки для оперативной интеллектуальной обработки данных. В Analysis Services 2000 кубы - вне зависимости от варианта их хранения или стратегии использования разделов - обрабатывались с помощью модели "Pull". В Analysis Services запускался процесс, который искал новую информацию в базе-источнике данных, обрабатывал и при необходимости сохранял детализированные данные, и рассчитывал и сохранял агрегаты.
Модель Pull по-прежнему поддерживается в Analysis Services 2005, но были добавлены еще две модели, которые особенно полезны для интеллектуальной обработки данных с небольшой задержкой обновления:
- Получение (push) данных из канала Integration Services или пользовательского приложения. Данные могут напрямую попадать в раздел Analysis Services из канала пакета Integration Services, без промежуточного сохранения. Это может использоваться для уменьшения задержки обновления и затрат на хранение аналитических данных.
- Управление кубом как упреждающим кэшем, без административного вмешательства, для поддерживания в кэше заранее определенных уровня задержки обновления данных и характеристик производительности.
Производительность выполнения запросов в многомерном хранилище Analysis Services выше, чем в реляционном хранилище. Если кратко, то запросы выполняются быстрее всего в многомерном (MOLAP) хранилище. Обратной стороной этого является задержка обновления данных: многомерное хранилище является снимком реляционного источника данных. Основным преимуществом технологии упреждающего кэширования является максимизация производительности выполнения запросов и минимизация задержки обновления данных и затрат на администрирование.
Возможности упреждающего кэширования упрощают процесс управления устаревшими данными. Когда происходит транзакция в базе-источнике данных, например, новая транзакция по члену измерения или по факту, существующий "кэш" устаревает. Упреждающее кэширование обеспечивает настраиваемый механизм для определения, насколько часто нужно пересоздавать многомерный кэш; для определения, как выполняются запросы во время перестройки кэша; а также для запуска процесса перестройки кэша без административного вмешательства.
Упреждающее кэширование дает вам возможность устанавливать у куба автоматическое обновление его многомерного кэша при возникновении транзакции. Хотя Analysis Services обрабатывает данные очень быстро, обработка все-таки занимает определенное время. При необходимости ваша конфигурация упреждающего кэширования может автоматически перенаправлять запросы в реляционное хранилище, если обновление упреждающего кэша еще не закончено.
Когда вы разрабатываете конфигурацию вашего упреждающего кэша, важно помнить, что упреждающее кэширование настраивается для каждого многомерного раздела. Если раздел содержит данные за небольшой период времени, например, за час, то процесс обновления кэша происходит очень быстро. Наиболее сложные конфигурации упреждающего кэширования зависят от сообщения (notification), отправляемого реляционной базой данных в Analysis Services, о том, что произошло изменение данных. Реляционная база данных Microsoft SQL Server поддерживает такие сообщения. Для баз данных, которые не отправляют сообщения, Analysis Services может быть настроен на опрос базы данных на наличие изменений с помощью заранее созданного запроса.
Параметрами упреждающего кэширования являются:
- Период бездействия (Quiet period): Период времени, в течение которого на реляционном источнике данных не должны происходить транзакции, прежде чем сервер начнет обработку новой информации. Параметр обычно имеет значение меньше десяти секунд. Ожидание периода бездействия помогает избежать регулярного удаления и пересоздания кэша, если в реляционном источнике данных происходит множество последовательных обновлений.
- Задержка обновления данных (Latency): Как долго пользователи могут получать доступ к устаревшим данным. Если период задержки обновления данных равен нулю, пользовательские запросы перенаправляются в реляционный источник данных сразу же, как только получается сообщение. Если период задержки обновления данных равен 600 секундам, пользователи получают доступ к данным, которые не старше десяти минут. Установка периода в -1 означает, что пользователи будут получать доступ к устаревшим данным, пока не будет закончено пересоздание упреждающего кэша.
- Максимальный интервал до перестройки кэша (Silence override interval): максимальный период между сообщением об изменении данных и началом пересоздания упреждающего кэша. Если база-источник данных обновляется регулярно, этот параметр перекроет значение параметра "Период бездействия".
- Интервал между принудительными перестройками кэша (Force rebuild interval): этот параметр используется для обеспечения простой функциональности упреждающего кэширования на системах, где система базы-источника данных не поддерживает сообщения об изменении данных. Если источником данных является РСУБД SQL Server, этот параметр должен быть установлен в ноль.
