Основные проблемы, связанные с операционной BI-технологией, заключаются в организационной поддержке и финансировании для обеспечения своевременных данных в традиционной среде Хранилища.
Организационные проблемы
Задание требований . Одна из наибольших сложностей с операционными BI-средствами состоит в том, что бизнес-пользователи стремятся получить своевременные данные для управления операционными процессами, не имея при этом явной цели и четкого понимания требуемых затрат и времени. Некоторые менеджеры требуют более свежих данных, так как у них периодически возникает такая потребность или их конкуренты уже внедрили операционное BI-средство. Честолюбивые IT-специалисты часто слишком спешат помочь бизнес-пользователям в реализации этой идеи, иногда даже не формулируя конкретное применение таких инструментов.
С другой стороны, BI-профессионал с серьезным знанием структуры организации и отрасли может выполнить требование своевременного предоставления информации еще до того, как бизнес-специалист этого потребует, а также грамотно разработать архитектуру операционного средства.
Оценка расходов . По определению, операционные BI-средства предоставляют информацию о событиях по мере их возникновения или вскоре после их наступления так, чтобы бизнес-специалист мог эффективно реагировать и оптимизировать бизнес-процессы. Однако расходы на внедрение операционной BI-системы возрастают по мере сокращения латентности данных.
Обучение пользователей . Организации часто вынуждены переобучать пользователей, чтобы те могли разобраться, как использовать и интерпретировать "своевременные" данные. Кроме того, они могут создавать новые возможности для сотрудников, что стимулирует их для изучения информации. Так как некоторые IT-разработчики не придают значения ссылочной целостности и алгоритмам агрегирования, а также отказываются от использования процедур очистки данных при загрузке, то компаниям необходимо предупреждать пользователей о качестве и согласованности.
Технические проблемы
В Хранилище или вне его? Первая техническая проблема, которую необходимо решить, это выбор архитектуры. В частности, необходимо определиться, будет ли применяться Хранилище данных. Это самый фундаментальный вопрос, и ответить на него не всегда легко.
Многие считают, что критически важно адаптировать существующее Хранилище для поддержки операционной BI-среды. Главной сложностью является применение тех же бизнес-правил для интеграции, очистки и оценки потоков операционных данных, как и для данных в Хранилище. Вынесение операционных потоков из Хранилища снижает качество данных и создает дивергентные выборки, которые могут не согласовываться между собой.
Однако есть и те специалисты, которые с этим мнением не соглашаются. Они считают, что Хранилище становится "узким местом", если пытаться загрузить все данные, при том что пользователям в любой момент может понадобиться выполнить запрос. BI-поставщики, такие как Business Objects, Hyperion, SAS и ряд других, поддерживающие интегрированные запросы, считают, что их инструменты обеспечивают простой и недорогой способ получения своевременных данных и поставки их пользователям в нужный момент и на достаточно качественном уровне.
Аналогично, поставщики встроенных BI-средств, управляемых событиями аналитических платформ, сложных приложений и аналитики, выполняемой в памяти, утверждают, что их продукты предоставляют наиболее приемлемую реализацию OBI . Эти разработчики считают, что Хранилище данных очень важно для применения исторического контекста к данным в реальном времени, но не обязательно для управления этими данными.
Несмотря ни на что, Хранилища стали устоявшейся практикой в корпоративных средах и мало найдется организаций, которые откажутся от применения своих DW-инвестиций, не попытавшись адаптировать архитектуру для поддержки своевременных данных и операционных процессов. Отраслевые опросы показывают, что практически половина организаций (51%) применяют как операционные, так и аналитические отчеты из одной и той же среды.
Большинство компаний применяют Хранилище для решения задач операционной BI-технологии. Однако они сталкиваются с рядом проблем.
Выбор правильной технологии. Для построения операционной BI-среды можно использовать ряд технологий, которые можно классифицировать по трем категориям, каждая из которых определяется способом передачи данных в системе:
- Сбор данных . Сбор, преобразование и перемещение данных их исходных систем в аналитическую среду в нужный момент времени. Для этого можно применять ETL-инструменты, средства репликации, технологии сбора изменившихся данных, управляемые событиями механизмы направления потоков, средства передачи сообщений, инструменты запросов BI и EII. На практике большинство компаний используется сочетание этих методов.
- Хранение данных . Полученные данные могут храниться по-разному, в том числе в одном или нескольких уровнях Хранилища (в ХД, в витрине данных, в OLAP-кубе), в операционном складе данных, либо в аналитической среде, управляемой событиями.
- Предоставление данных . Для отображения данных, полученных из аналитических процессов, компании применяют приложения собственной разработки, порталы, BI-инструменты, инструментальные панели либо сочетание этих подходов.
Некоторые из описанных технологий позволяют решать сразу несколько задач. Например BI и EII-инструменты собирают и отображают данные. Аналитические платформы, управляемые событиями в сочетании с инструментами передачи сообщений, поддерживают все три вида операций.
Опрос большинства компаний показывает, что для поддержки операционной BI-среды применяется одновременно несколько технологий, чаще всего - операционные склады данных, более частая пакетная загрузка, сбор изменившихся данных.
Повышение масштабируемости и производительности . Еще одной ключевой проблемой является построение систем, которые масштабируются для поддержки большего числа пользователей, источников данных и объемов информации с растущим уровнем производительности, при условии гарантированного качества данных и безопасности. Возникает необходимость внедрения высокопроизводительных платформ ХД, а также сложных инструментов интеграции данных. Чтобы гарантировать масштабируемость и производительность нужно модернизировать сети и оборудование, добиться параллельного выполнения ключевых процессов ETL, для адекватного выполнения растущих требований производительности, а также для устранения узких мест в процессе обработки.
За счет распараллеливания базы данных и ETL-процессов, а также за счет модернизации серверов и других аппаратных средств, удается существенно сократить время обработки.
Вставка записей ( inserts ). Чтобы повысить эффективность ETL-процессов, некоторые эксперты предлагают вставлять новые записи (то есть загружать данные), а не добавлять, изменять или удалять уже существующие записи. Они считают, что стоит избегать обновлений любой ценой. При наличии больших выборок данных на поиск записи и ее обновление уходит слишком много времени. И хотя в этом случае возникает множество дублируемой информации, однако можно использовать SQL-операторы distinct и group-by для поиска и удаления дубликатов.
Этот процесс извлечения, загрузки и преобразования (extract, load, and transform - ELT) несколько отличается от традиционного подхода извлечения, преобразования и загрузки (extract, transform, and load - ETL).
Повышение доступности и возможности восстановления . В среде Хранилища со своевременной поставкой данных на восстановление после ошибок остается очень мало времени, так как интервалы пакетной обработки очень малы или вообще отсутствуют. Система, работающая в реальном времени, не оставляет времени на фиксацию проблем, а потому может начаться нагромождение сообщений.
Лучший способ избежать этой проблемы - построить готовую доступную систему для выполнения процессов сбора и предоставления данных. Эти системы распараллеливают точки сбоев, работают в кластеризованной среде, поддерживают процессы резервирования и восстановления. Недостаток этого подхода в том, что исторические и текущие данные разделяются по двум разным системам, что усложняет пользователям возможности оценки своевременных данных в историческом контекста.
Использование возможностей смешанной загрузки . Многие поставщик СУБД существенно повысили качество возможностей оптимизации эффективности долгосрочных стратегических запросов, тактически запросов, процессов загрузки и обновления за счет использования смешанной загрузки.
Планировщик приоритетов - это "регулировщик движения", который постоянно распределяет ресурсы процессора по тактически запросам, гарантируя отклик на запрос в течение долей секунды. Кроме того, непрерывно проводится мониторинг текущих задач и динамически регулируется распределение процессоров для оптимизации эффективности. Кроме того, администратор может сконфигурировать и расставить приоритеты по группам пользователей, видам операций и другим показателям.
СУБД, поддерживающая обработку со смешанной загрузкой, позволяет компании выполнить сразу все этапы. Можно загрузить текущие и исторические данных в ту же базу и оптимизировать производительность по всем видам запросов. Без СУБД, поддерживающей смешанную загрузку, многие компании отказываются использовать Хранилище для операционных BI-средств. Однако в плане возможностей смешанной загрузки между поставщиками есть различия, и их необходимо тщательно оценивать. Кроме того, выполнение сразу нескольких операций на одной платформе может потребовать обновления оборудования для поддержки адекватной эффективности. Поэтому необходимо заранее просчитать расходы, решаясь на выбор такого подхода.
Устранение проблем с согласованием . Если запросы пользователя и ETL-процессы обращаются к одной и той же таблице, то потенциально существует вероятность блокировки одного процесса другим, а также снижения эффективности запроса или загрузки. Помимо требований к смешанной загрузке, проблема согласования заставляет многих хранить исторические и текущие данные в различных складах данных.
Обеспечение одновременного чтения и записи . Если данные вставляются, а не обновляются, то база данных не блокирует таблицу. Единственная проблема заключается в том, что данные могут быть не синхронизированы, если пользователь обращается к таблице до того, как все вставки были выполнены. Чтобы избежать путаницы, есть смысл обеспечить пользователя определенными директивами в отношении выполнения нерегламентируемых запросов на данных в реальном времени. Это поможет динамически помечать по времени все отчеты. Кроме того, важно отказаться от кэширования на BI-серверах, так как нет никакого смысла в загрузке данных каждый час, если BI-инструмент запрашивает данных из кэша, которые обновляется единожды в день.
Внешний кэш в реальном времени . Еще один подход состоит в загрузке данных в кэш-память вне Хранилища. Текущие данные извлекаются из кэша. Запросы, требующие комбинации исторических и текущих данных, объединяют данными в набор временных таблиц либо в Хранилище, либо в кэше в реальном времени, в зависимости от того, где содержится наибольший объем затребованных данных. Этот тип слияний требует программирования сложных SQL-процедур и непрост в поддержке.
Синхронизация агрегированных данных . Проблема, связанная с согласованием запросов, возникает в тех случаях, когда пользователи выполняют запросы на агрегированных таблицах, которые динамически не обновляются. Большинство организации ожидают окончания дня, чтобы провести перерасчет агрегированных показателей в соответствии с текущими данными. Поэтому администраторам в этом случае необходимо заниматься обучением пользователей, в частности рассказывать о временной чувствительности данных, на которых выполняются запросы. Однако если объемы данных невелики, то можно проводить перерасчет итоговых показателей динамически в отдельном разделе. После завершения расчета необходимо отобразить обновленные агрегированные показатели.
Существует множество задач, связанных с внедрением операционных BI-средств. Описанные здесь проблемы в основном связаны с преобразованием архитектуры Хранилища для поддержки передачи информации в реальном времени. И хотя существуют и другие способы обеспечения своевременного предоставления сведений для поддержки операционных BI-средств, однако многие эксперты рекомендуют использовать среду Хранилища, что гарантирует согласованные данные для всей организации.
Рекомендации
Операционная BI-технология охватывает широкий круг приложений, подходов и методик. И хотя в этой ситуации сложно предложить совет, который охватил бы все потенциальные возможности использования этой технологии, однако общие рекомендации могут быть следующие:
1. Не стоит проводить строгую черту между аналитическими и операционными процессами и технологиями. Так как временные рамки все жестче, и скорость ведения бизнеса все возрастает, традиционные границы между аналитическими и операционными процессами и технологиями стираются.
Операционные BI-средства - это скорее мировоззрение, а не конкретный набор технологий или архитектурным подходом. Для поддержки операционной BI-технологии в первую очередь необходимо продумать операции. Затем нужно учесть разнородную смесь технологий - любой метод, добавляющий интеллекта в бизнес процесс.
2. Планомерно повышать уровень операционной BI -технологии. Для начала организациям необходимо определиться, нужно ли запускать операционные отчеты в Хранилище, или в отдельной среде. Далее необходимо постепенно повышать уровень операционной BI-системы, в том числе внедряя операционные инструментальные панели, встроенные BI-средства, или даже управляемую событиями аналитику.
3. Поместить своевременные данные в исторический контекст. Большинству пользователей необходимо рассматривать данные в реальном времени именно в этом контексте. Если возможно, то лучше адаптировать уже существующую среду Хранилища для обеспечения информации в реальном времени и поддержки единого согласованного источника информации.
4. Добиваться архитектурной простоты. Для операционных BI-средств возникает соблазн построения сложных сред обработки, включающих новые технологии и оборудование. Лучшим рецептом оказывается применение старых проверенных технологий и их адаптация. Самые эффективные архитектуры как правило просты.
5. Четко оценивать расходы на операционные BI -средства. Расходы растут по мере снижения латентности данных. Операционные BI-системы ориентированы на конкретную задачу, а поэтому устаревание может обойтись компании довольно дорого. Поэтому есть смысл в повышать отказоустойчивость и возможность восстановления . Чтобы привести в соответствие потоки данных и скорость выполнения запросов, необходимо использовать более быстрое и мощное оборудование, а также параллельное ПО.
6 . Добиваться простоты предоставления данных. В операционной BI-среде лучше всего представлять данные пользователям в максимально простой форме. Стоит избегать сложных отчетов и часто слишком перегруженных параметрами инструментальных панелей. Может потребоваться создание собственного графического Интерфейса для передачи данных напрямую, что имеет смысл для тех процессов, по которым проводится мониторинг и управление.
7. Ввести замкнутый цикл обработки информации . Организации, использующие инструментальные панели для мониторинга бизнес-процессов, лучше понимают, как их бизнес работает и что нужно предпринять в различных ситуациях. Иначе выражаясь эти компании могут использовать свои знания для создания интеллектуальны предупреждений, которые уведомляют о возникающих проблемах, обеспечивают соответствующие отчеты для просмотра и выбора последующих действий.
8. Внедрить аналитику в традиционные процессы. Применение прогнозных моделей к операционным процессам может повысить эффективность. В частности, это относится к задачам оптимизации склада и минимизации излишков. Аналитика также может устранить сложные правила, автоматизирующие действия в ответ на поток входящих бизнес-событий.
9. Автоматизировать бизнес-процессы с осторожностью. Автоматизированные системы часто уходят из-под контроля, заваливая пользователей ненужными предупреждениями и запуская не требующиеся действия. C учетом того, что многие решения требуют немедленных действий, стоит автоматизировать только хорошо известные бизнес-процессы. Для повышения точности и согласованности запросов требуется применение прогнозных моделей, что влечет за собой возрастающую сложность и дополнительные расходы на автоматизацию.