Oracle BI Suite EE – сама «всеїдна» і «інтелектуальна» з аналітичних платформ, Oracle, Бази даних, статті

Ще зовсім недавно аналітики Gartner включали платформу Siebel Analytics лише в групу «Провидці» свого «магічного квадрата» – Magic Quadrant for Business Intelligence Platforms – відзначаючи технологічні гідності цієї платформи, вони не високо оцінили стратегію компанії по її просуванню. Після покупки компанії Siebel Systems корпорацією Oracle в минулому році і рішучих дій щодо її розвитку і просування, аналітики Gartner поміняли свою думку. Спробуємо розібратися наскільки заслужено Oracle Business Intelligence Suite Enterprise Edition (Oracle BI Suite ЇЇ) виявилася, на думку, Gartner в числі лідерів, особливо якщо врахувати, що більшість російських фахівців знає про цю платформу дуже небагато.


Платформи різні бувають


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


Платформи першої групи орієнтовані на роботу з виділеними джерелами даних – сховищами і вітринами даних, які спеціально сформовані для аналітичної обробки, що виражається і в особливих структурах і моделях даних цих джерел. В даний час найбільше визнання в якості моделі даних для аналізу даних отримала багатовимірна модель, яка може бути реалізована і засобами реляційних СУБД, і засобами багатовимірних (OLAP) СУБД. Ефективність і зручність виконання аналізу при використанні останніх значно вище, ніж при застосуванні реляційних СУБД, тому OLAP-сервери є ядром аналітичних платформ першої групи. До цієї групи належать аналітичні платформи Microsoft, Hyperion Solutions, «стара» аналітична платформа Oracle (тепер Oracle Business Intelligence Suite Standard Edition) і ін


Платформи другої групи, а це насамперед платформи компаній Business Objects, Cognos, Microstrategy, розроблені для роботи з більш широким колом джерел, в який крім сховищ і вітрин даних (Реляційних і багатовимірних) входять «звичайні» бази даних, що створюються транзакційними (класу OLTP) системами, і, можливо, інші джерела даних: XML-файли, плоскі файли, файли MS Excel … Можна сказати, що ці платформи в принципі «рівновіддалені» від різних джерел даних.


До складу платформ другої групи не входять OLAP-сервери та інші засоби безпосереднього доступу до джерел даних, для доступу до даних в цих платформах використовуються в основному стандартні інтерфейси до відповідних серверів: ODBC / JDBC для доступу до реляційних баз / сховищ, MDX (MultiDimensional eXpressions – мова запитів для простого та ефективного доступу до багатовимірним структурам даних, кшталт мови SQL) для доступу до багатовимірним (OLAP) … Крім того, в деяких платформах використовуються і «рідні» для конкретних джерел інтерфейси. Наприклад, інтерфейс OCI (Oracle Call Interface) для доступу до баз даних Oracle, інтерфейс XMLA (XML for Analysis – xml-стандарт) для доступу до багатовимірним сховищ SAP BI / BW, інтерфейси до баз даних популярних пакетів …


Архітектура


Платформа Oracle BI Suite EE по способам доступу до даних та архітектури відноситься до другої групи. В архітектурі цієї платформи (рис. 1) центральне місце займає аналітичний сервер – Oracle BI Server, через який реалізується весь доступ до різноманітних джерел даних.


Цей сервер називають аналітичним сервером додатків (business intelligence application server), так як він підтримує інтерфейси до реляційних і багатовимірним (OLAP) баз (ODBC, OCI, MDX, CLI), а також до плоских файлів, XML-документами, таблицями MS Excel, баз даних найбільш популярних додатків SAP R / 3 і mySAP, Oracle e-Business Suite, JD Edwards Enterprise One, Peoplesoft Enterprise, Oracle Siebel CRM та ін, а також виконує роль інтегратора, яка традиційно була прерогативою проміжної області (staging area) сховища даних. Мабуть, Oracle BI Suite EE – це сама «всеїдна» (в частині джерел даних) аналітична платформа.


Oracle BI Server також володіє всією необхідною серверної інфраструктурою, включаючи управління сесіями, запитами, відмінами і блокуваннями, веденням журналів і моніторингом активності, балансуванням навантаження на сервер, і, саме головне, ефективною системою кешування запитів користувачів і їх результатів.


Основними архітектурними компонентами системи є: Oracle BI Server, Oracle BI Web і Oracle Delivers Server


Рис. 1. Архітектура Oracle BI Suite ЇЇ


Oracle BI Server централізовано зберігає метадані про джерела даних і бізнес-об’єктах (business definitions) у своєму репозиторії, доступному всіх інструментів платформи Oracle BI EE.


Oracle BI Web надає інтерфейси для всіх компонент системи, що використовуються для візуалізації даних. Він взаємодіє з Oracle BI Server і виконує ряд найважливіших функцій: відповідає за авторизацію користувачів і персоналізацію інтерфейсу для них, генерацію логічних запитів до аналітичного серверу, зберігання та адміністрування метаданих (Web-каталог) для звітів і інтерактивних панелей, здійснює додаткову пост-обробку даних.


Oracle Delivers Server необхідний для роботи проактивного складової в платформі, що дозволяє задавати моделі для виявлення проблем, фільтрувати дані відповідно до заданих правил, повідомляти користувачів по безлічі каналів, включаючи електронну пошту і SMS і давати можливість користувачам приймати рішення у відповідь на сповіщення. Основні його функції це: створення та підписки на повідомлення, автоматичне оповіщення та планувальники, адміністрування каналів і облікових записів доставки.


Для досягнення високої продуктивності і масштабованості системи Oracle BI Server і Oracel BI Web можна об’єднувати в кластери. Підтримується можливість балансування навантаження, дозволяючи розподіляти запити і призначені для користувача сеанси на різні сервера.


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


Сучасна тенденція інтеграції програм з Internet технологіями знаходить свою повну підтримку в Oracle BI Suite EE. Так Oracle BI Web пропонує інтерфейс на основі Web-сервісів. В цілому вся платформа Oracle BI SuiteEE побудована на SOA (Service Oriented Architecture) архітектурі.


Клієнтські програми


Якщо способи доступу до джерел даних визначають архітектуру аналітичних платформ, то функціональність клієнтських додатків і аналітичних засобів визначає функціональні можливості системи. Більшість аналітичних платформ пропонують обмежений набір додатків, зазвичай складається з засобів побудови аналітичних запитів і звітів і деяких панелей або книг для об’єднання пов’язаних звітів і подання їх кінцевому користувачеві. Якщо ж платформа і володіє повним спектром аналітичних можливостей, то часто у кожного її компонента були свої метадані. На відміну від цього в Oracle BI Suite EE всі клієнтські програми та інструменти були з самого початку створені для спільного використання одних і тих же метаданих, аналітичного сервера додатків, інфраструктури обчислень та інструментів адміністрування, єдиної моделі безпеки та управління привілеями користувачів.


До складу платформи Oracle BI Suite EE входить наступний набір інструментів (клієнтських додатків):



Значною особливістю Oracle BI Suite EE є наявність компонентів для проактивного аналітики (BI Delivers). Ідея досить проста – сповіщення аналітичною системою про факт виходу того чи іншого показника за встановлені межі. При цьому в якості формованого події – вихід показника за встановлені межі – може виступати електронний лист із вкладеним звітом, sms-повідомлення, і т. д.


Крім того до складу клієнтських додатків в Oracle BI EE включений дуже потужний і функціональний сервер формування регламентованих звітів і форм (BI Publisher). Він має централізовану архітектуру, забезпечує генерацію та безпечне розповсюдження звітів і може працювати над однією і тією ж моделлю даних з Oracel BI EE.


І, нарешті, оголошено, що в Oracle BI EE буде реалізована інтеграція з Oracle BPEL PM, що відкриває перед розробниками широкі перспективи по включенню BI-засоби в бізнес-процеси компанії, включаючи організацію корпоративного документообігу.


Всі клієнтські програми реалізовані в «чистій» Web-середовищі, на основі HTML, DHTML, JavaScript – користувачеві не доведеться виконувати завантаження будь-якого клієнта, використовувати програмні розширення, елементи управління на базі ActiveX або Java аплети. Це дозволяє користувача працювати з системою, звідки завгодно для цього необхідно лише мати Web-браузер.


Метадані


Аналітичний сервер Oracle BI Server представляє дані користувачам згідно логічної бізнес-моделі – корпоративної семантичної моделі (Enterprise Semantic Model). Ця модель має три шари (рис. 2): фізичний, містить метадані про фізичних джерел даних, імена таблиць, первинні та зовнішні (primary and foreign) ключі, статистики по кількості рядків (row counts), правила доступу до таблиць, а також пул з’єднань; бізнес-шар, що містить описи вимірювань і ієрархій, логічні таблиці, правила вибору джерел даних, правила побудови обчислень, агрегаційних та часового аналізу, а також правила деталізації; шар вистави – спрощене, персоналізоване подання даних, до яких посилаються із застосуванням «логічного SQL».


Рис. 2. Шари корпоративної семантичної моделі


Фізичний шар цієї моделі пов’язаний з фізичними сполуками до джерел даних: реляційних і багатовимірним (OLAP) через SQL-вистави або MDX (тільки до багатовимірним), XML-, або будь-яке джерело даних з ODBC-інтерфейсом.


Бізнес-шар забезпечує рівень абстракції над фізичними об’єктами і дозволяє адміністратору групувати дані в логічні тематичні області (logical subject areas). «Напрями деталізації» (Drill paths) можуть бути встановлені з застосуванням визначень вимірювань і розмірностей. Вони можуть використовувати переваги вбудованого «движка» обчислень (in-built calculation engine) в аналітичному сервері.


Шар подання визначає, що кінцеві користувачі побачать, коли вони почнуть обирати дані в клієнтському додатку. Це може бути повний набір даних в бізнес-шарі або просто поднабор, і ви можете застосовувати фільтри і обмеження (scoping), так що окремі департаменти / співробітники побачать тільки «свої», безпосередньо для них призначені, дані.


Доступ до даних та обробка запитів


Oracle BI Server в частині обробки запитів запитів виконує дві основні функції: компіляцію вхідних запитів (від користувачів) в виконуваний код і безпосередньо виконання цього коду. Розбір та компіляція запиту складається з п’яти основних стадій: синтаксичного аналізу, генерації логічного запиту, навігації, переписування і генерації кінцевого коду. При цьому основний і найважливішою є саме стадія переписування або оптимізації запитів. На цій стадії сервер займається оптимізацією з урахуванням специфіки кожного конкретного джерела. Механізм об’єднання даних враховує фізичне розташування даних (Таблиця бази даних або, наприклад, плоский файл), особливості функціональності SQL, підтримуваного базою даних, а також аналітичної складності запиту.


У платформі Oracle BI Suite ЇЇ обробка запитів до даних максимально переноситься, наскільки це можливо, на сервери джерел даних. Хоча аналітичний сервер цієї платформи може виконувати OLAP-обчислення і аналіз, краще все-таки використовувати для цього виділений OLAP-сервер, і, аналогічно, при роботі зі надвеликими наборами даних краще використовувати високопродуктивний сервер реляційної СУБД. Тому, коли можливо, для обробки використовуються саме ці технології, а не аналітичний сервер, роль якого в цьому випадку полягає в прийнятті запитів від інструменту (клієнтського додатку) і їх трансляції в пропозиції SQL (або MDX) до баз вихідних даних. Коли ці бази повертають результати, аналітичний сервер зводить дані, якщо потрібно, сам виконує деякі обчислення, форматує ці дані і повертає їх клієнтського додатку.


Згенеровані пропозиції SQL оптимізуються, щоб була можливість користуватися перевагами бази даних джерела. Її сервер може отримувати доступ до даних в агрегованих таблицях (aggregate tables), якщо він «знає» про таких. Це може означати, наприклад, що ви можете прямо відображати вимірювання на більш високий рівень агрегування, до агрегованих таблиць в базі даних, які можна використовувати як заміну для механізму перезапису в запиті (query rewrite mechanism) в базі даних Oracle. Цю особливість можна задіяти, щоб задати аналітичного серверу використання іншого подання (View) SQL для аналітичного простору (analytic workspace) Oracle, якщо потрібно агрегування більш високого рівня.


В цілому, Oracle BI Server надає дуже широкі можливості налаштування доступу даними та їх обробки з максимальним використанням метаданих, за що цей сервер деякими аналітиками іменується «інтелектуальним» (intelligent).


Сховища «віртуальні» і «справжні»


Вище дуже коротко представлені архітектура і основні особливості Oracle BI Suite EE. Безумовно, розробники при застосуванні цієї платформи придумають нові схеми і підходи до створення додатків. Зараз же хотілося б зупинитися лише на одному моменті.


Припустимо, що у замовника в промисловій експлуатації є кілька транзакційних систем зі своїми базами даних (первинними джерелами) і потрібно отримати консолідовану аналітичну звітність на основі даних з цих баз даних. За допомогою Oracle BI Server можна вирішити це завдання без проектування і побудови класичного сховища даних! Фактично, можна створити «віртуальне сховище даних », яке для клієнтських додатків буде виглядати як незалежне джерело денормалізованних даних (у звичних поняттях: аналізовані величини, аналітичні розрізи, ієрархії і т. д.). При обробці вступників запитів аналітичний сервер буде їх транслювати до первинних джерел даних, у тому числі транзакційних. Мінуси такого рішення – навантаження на первинні джерела і неефективна для звітів фізична модель даних в первинних джерелах (в основному сильно нормалізована, розподілена структура). Для вирішення цих проблем і пропонується будувати «справжнє» сховище даних … Тому «віртуальне сховище даних» можна розглядати як швидке і тимчасове рішення, щоб потім перейти до повноцінного сховища даних.


Однак, обидва ці варіанти з «віртуальним» і «справжнім» сховищами даних не виключають один одного і можливе їх ефективне поєднання, завдяки механізму доступу до даних в Oracle BI Server.


Будь-яке сховище даних працює за розкладом, відповідно до регламенту, наприклад, тільки вночі. З іншого боку, сховище забезпечує зниження навантаження на транзакційні (облікові) системи – первинні джерела даних. Крім того, інформація в сховищах розміщена в денормалізованном вигляді, що забезпечує мінімальний час відгуку системи на запити. Oracle BI Server можна налаштувати таким чином, що при зверненні до історичних даних він буде «прозоро» для користувача переадресовувати запити сховища, а при зверненні до даних, наприклад, поточного дня – до бази даних транзакційної системи. Альтернативним варіантом рішення може бути використання агрегованої інформації, яка міститься в сховищі, з можливістю її деталізації до первинних проводок, що знаходяться в транзакційної системі.


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


***


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

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


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

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

Ваш отзыв

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

*

*