Операційні BI-засоби. Проблеми та їх вирішення, Oracle, Бази даних, статті

Основні проблеми, пов’язані з операційною BI-технологією, полягають в організаційній підтримці й фінансуванні для забезпечення своєчасних даних в традиційному середовищі Сховища.

Організаційні проблеми


Завдання вимог . Одна з найбільших складнощів з операційними BI-засобами полягає в тому, що бізнес-користувачі прагнуть отримати своєчасні дані для управління операційними процесами, не маючи при цьому явною мети і чіткого розуміння необхідних витрат і часу. Деякі менеджери вимагають більш свіжих даних, так як у них періодично виникає така потреба, або їх конкуренти вже впровадили операційне BI-засіб. Честолюбні IT-фахівці часто надто поспішають допомогти бізнес-користувачам в реалізації цієї ідеї, іноді навіть не формулюючи конкретне застосування таких інструментів.


З іншого боку, BI-професіонал з серйозним знанням структури організації та галузі може виконати вимогу своєчасного надання інформації ще до того, як бізнес-спеціаліст цього зажадає, а також грамотно розробити архітектуру операційного кошти.


Оцінка витрат . За визначенням, операційні BI-засоби надають інформацію про події в міру їх виникнення або незабаром після їх настання так, щоб бізнес-фахівець міг ефективно реагувати і оптимізувати бізнес-процеси. Проте витрати на впровадження операційної BI-системи зростають у міру скорочення латентності даних.


Навчання користувачів . Організації часто змушені перенавчати користувачів, щоб ті могли розібратися, як використовувати й інтерпретувати “своєчасні” дані. Крім того, вони можуть створювати нові можливості для співробітників, що стимулює їх для вивчення інформації. Так як деякі IT-розробники не надають значення посилальної цілісності і алгоритмам агрегування, а також відмовляються від використання процедур очищення даних при завантаженні, то компаніям необхідно попереджати користувачів про якість та узгодженості.


Технічні проблеми


У Сховище чи поза ним? Перша технічна проблема, яку необхідно вирішити, це вибір архітектури. Зокрема, необхідно визначитися, чи буде застосовуватися Сховище даних. Це самий фундаментальний питання, і відповісти на нього не завжди легко.


Багато хто вважає, що критично важливо адаптувати існуюче Сховище для підтримки операційної BI-середовища. Головною складністю є застосування тих же бізнес-правил для інтеграції, очищення та оцінки потоків операційних даних, як і для даних у Сховище. Винесення операційних потоків з Сховища знижує якість даних і створює дівергентние вибірки, які можуть не узгоджуватися між собою.


Однак є й ті фахівці, які з цією думкою не погоджуються. Вони вважають, що Сховище стає “вузьким місцем”, якщо намагатися завантажити всі дані, при тому що користувачам в будь-який момент може знадобитися виконати запит. BI-постачальники, такі як Business Objects, Hyperion, SAS і ряд інших, що підтримують інтегровані запити, вважають, що їхні інструменти забезпечують простий і недорогий спосіб отримання своєчасних даних і постачання їх користувачам в потрібний момент і на досить якісному рівні.


Аналогічно, постачальники вбудованих BI-засобів, керованих подіями аналітичних платформ, складних додатків і аналітики, що виконується в пам’яті, стверджують, що їхні продукти надають найбільш прийнятну реалізацію OBI. Ці розробники вважають, що Сховище даних дуже важливо для застосування історичного контексту до даних в реальному часі, але не обов’язково для управління цими даними.


Незважаючи ні на що, Сховища стали усталеною практикою в корпоративних середовищах і мало знайдеться організацій, які відмовляться від застосування своїх DW-інвестицій, не спробувавши адаптувати архітектуру для підтримки своєчасних даних і операційних процесів. Галузеві опитування показують, що практично половина організацій (51%) застосовують як операційні, так і аналітичні звіти з однієї і тієї ж середовища.


Більшість компаній застосовують Сховище для вирішення завдань операційної BI-технології. Проте вони стикаються з низкою проблем.


Вибір правильної технології. Для побудови операційної 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 урахуванням того, що багато рішень вимагають негайних дій, варто автоматизувати тільки добре відомі бізнес-процеси. Для підвищення точності і узгодженості запитів потрібне застосування прогнозних моделей, що тягне за собою зростаючу складність і додаткові витрати на автоматизацію.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*