Погляд практика на нову аналітичну платформу Oracle Business Intelligence Suite Enterprise Edition

Початок 2006 року для корпорації Oracle ознаменувався черговим придбанням цього разу компанії Siebel, відомої в якості лідера на ринку CRM-систем і, зокрема своїм продуктом Siebel Analytics. Багато хто з партнерів, вже звиклі до такого роду подій, поставилися до цієї новини як до бажання Oracle зміцнити свої позиції на цьому ринку. До числа людей, що сприйняли цю звістку без особливого ентузіазму, належав і я, але тільки до тих пір, поки в липні 2006 року ми не стали активно працювати з новим продуктом Oracle Business Intelligence Suite Enterprise Edition або скорочено – Oracle BI.

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

У рамках цієї статті я хотів би виділити чотири основних технологічних аспекту нового продукту, що вигідно відрізняють його від колишньої аналітичної платформи Oracle, відомої як сімейство продуктів Oracle Discoverer (Нині – Oracle Business Intelligence Standard Edition – Oracle BI SE).

Архітектура сервера Oracle BI EE і переваги, які вона забезпечує

По-перше, Хотілося б відзначити технологічну архітектуру нової платформи і особливо її ядра – аналітичного сервера, завдяки якій він легко інтегрується з різними гетерогенними джерелами даних. Воно і зрозуміло. Оскільки раніше цей сервер розвивався в рамках незалежної компанії, він і не "заточувався" саме (і переважно) на роботу з базою даних Oracle. І якщо не брати до уваги технологічні переваги самої бази даних Oracle в порівнянні з іншими СУБД, що не є предметом обговорення цієї статті, то Oracle для цього сервера – не більше ніж один із можливих джерел даних. Один з джерел, з яким сервер взаємодіє настільки ж ефективно, як і з іншими. Беручи до уваги той факт, що аналітичний сервер не зберігає в собі ніяких даних (тому що це не сервер баз даних), а зберігає швидше "карту доступу" до даних, ми отримуємо досить цікавий результат.

Припустимо, що у замовника в промисловій експлуатації перебувають кілька транзакційних систем, що працюють з різними базами даних. І нам необхідно отримати консолідовану аналітичну звітність, яка повинна містити узгоджені між собою дані кожної з цих баз. Так ось, за допомогою аналітичного сервера ми можемо вирішити це завдання без проектування і побудови класичного сховища даних. Всі необхідні інтеграційні процеси можуть бути реалізовані усередині сервера. Фактично на його рівні може бути створено "віртуальне сховище даних", яке для клієнтських додатків буде виглядати як незалежне джерело денормалізованних даних (у звичних поняттях: аналізовані величини, аналітичні розрізи, ієрархії і т.д.). При обробці запитів, що надходять це "віртуальне сховище" буде їх транслювати до первинних джерел даних, в тому числі транзакційних! При цьому практично ніяких обмежень на тип СУБД-джерел – більшість відомих "в природі" СУБД інтегруються однаково технологічно.

Мені б не хотілося зараз більш докладно зупинятися на технічних подробицях такого роду рішень. Зрозуміло, що при складній вивірки первинних даних це буде зробити дещо складніше, ніж з допомогою звичних ETL-інструментів. Скажу лише, що для перекодування унікальних ідентифікаторів ми можемо використовувати відповідні Excel-таблиці, зареєструвавши їх у якості одного з джерела даних. Більше важливо тут інше, а саме: при необхідності отримати швидкий позитивний результат в стислі терміни на вузькій, локальної задачі, ми можемо використовувати описаний вище технологічний підхід, тобто реалізувати обмежений обсяг аналітичної звітності без проектування і впровадження сховища даних. При цьому, звичайно, слід пам'ятати, що ми зіткнемося з рядом обмежень, на яких я зупинюся нижче. Але погодьтеся, іноді ми опиняємося в ситуації, в якій дійсно необхідно продемонструвати швидкий позитивний результат з рішенням обмеженої функціональності. Особливо тоді, коли від цього може залежати фінансування проектів на найближчі кілька років. Зараз з інструментами нової платформи, ми можемо (без реалізації сховища по заданих алгоритмах) порахувати обмежена кількість ключових показників і дати доступ до них кількох топ-менеджерам (зрозуміло, якщо в транзакційних системах є вся необхідна інформація), тоді як раніше, на основі колишньої аналітичної платформи Oracle, зробити це було неможливо .

Тепер про обмеження "віртуального сховища даних". У цій, здавалося б, привабливою "медалі", як і очікувалося, є і зворотна сторона. Я б навіть сказав "міна". Справа в тому, що за останні кілька місяців мені неодноразово доводилося чути таку думку шановних людей про нову аналітичної платформі Oracle: "Сховища взагалі більше можуть не знадобитися" . Не можу з цим погодитися. Справа в тому, що саме завдяки апаратних ресурсів серверів, на яких реалізовано сховища даних, користувачі аналітичних систем не навантажують облікові системи, що виконують, як відомо, свої, не менш важливі функції. Так що, якщо реалізувати аналітичне рішення з "віртуальним сховищем даних", яким будуть активно користуватися кілька десятків користувачів – можна "Поставити на коліна" будь-яку облікову систему, не кажучи вже про те, що швидкість відгуку запитів аналітичного рішення залишить бажати кращого. Звичайно, у аналітичного сервера Oracle BI EE можна активно задіяти кеш, що певною мірою знизить навантаження, але я не думаю, що це панацея.

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

З сховищем, без сховища і …

Другий аспект, на якому мені хотілося б зупинитися, випливає з тих же самих особливостей нового аналітичного сервера Oracle. По суті, вище було розглянуто два крайні варіанти побудови архітектури аналітичного рішення: класичний підхід, зі створенням корпоративного сховища даних, маппінг і всієї випливає з цього "кухнею", і підхід з "легкої надбудовою" над транзакційними системами, що представляє собою фактично всього лише "карту доступу до даних". Інтуїтивно зрозуміло, що "істина десь поряд". Так ось саме чудове полягає в тому, що ці два варіанти не виключають один одного і можливо їх поєднання в рамках одного проекту. І можливість такого поєднання треба обов'язково розглядати при реалізації проектів! Нижче я поясню, про що йде мова.

Фактично, будь-яке корпоративне сховище даних – це історичні дані в силу того, що комп'ютер у нього здійснюється за розкладом, у відповідності з регламентом, наприклад, вночі. А це означає, що практично в будь-який момент часу інформація в сховище в тій чи іншій мірі вже є застарілою. З іншого боку, сховище, як нам добре відомо, забезпечує зниження навантаження на системи – Джерела даних. Крім того, інформація в сховищах розміщена в денормалізованном вигляді, що забезпечує мінімальний час відгуку системи на запити. А це саме по собі важливе.

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

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

У довершення до всього слід згадати ще одну важливу особливість нового аналітичного сервера Oracle, про яку я до сих пір не говорив. Справа в тому, що цей сервер може сам по собі бути незалежним ODBC-Джерелом даних. Здавалося б, це несуттєвий факт, але, якщо подумати, то саме на цій підставі можна говорити про фактичну, а не декларованої відкритості архітектури. Судіть самі, припустимо, з якої-небудь причини (мені важко її зараз припустити, але все ж) наш замовник захотів користуватися клієнтськими додатками третіх фірм. Або просто продовжувати використовувати "старі" додатки, до яких звикли його співробітники і які його влаштовують. Ніяких протиріч. Все, про що йшла мова в цій статті до цих пір, може використовуватися в рамках аналітичного сервера Oracle, який буде незалежним джерелом даних, як якщо б це була яка-небудь база даних. Подобається Вам використовувати продукти третіх фірм – використовуйте! Чи не це захист вкладених інвестицій?

Про клієнтських додатках Oracle BI EE

До цих пір ми обговорювали можливості ядра нової платформи – аналітичного сервера. Хотілося б коротко зупинитися і на тому, що ж із себе представляють її клієнтські програми. Я не ставлю собі зараз завдання перерахувати всю можливу функціональність цих додатків – зараз у вільному доступі достатньо матеріалів по новій платформі і її додатків, в тому числі і російською мовою (див., наприклад, сторінку сайту Oracle СНД c посиланнями на брошури http://www.oracle.com/global/ru/pdfs/tech/). Мені лише хотілося б поділитися своїми міркуваннями про те, що нового це може дати розробникам і чому останнім буде простіше виходити на ринок з конкурентоспроможними рішеннями.

Якщо чесно, то до знайомства з новою платформою я перебував у межах відносно чітких стереотипів: звітність буває регламентована і аналітична, регламентована звітність – це скоріше до обліковими системам, а для аналітики – все більше "опція". А ось аналітичні гнучкі звіти (Oracle Discovever) – Це коник. Робочий інструмент аналітиків, "золотих хлопчиків", які обов'язково знайдуть з допомогою інструменту, який ми їм, зрозуміло, дамо, відповіді практично на будь-які питання.

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

Іншими словами, колишня технологічна платформа, дозволяла надати Замовникові дуже гнучке рішення, що забезпечує роботу не стільки зі звітами, скільки з "тематичними вітринами даних". У цьому випадку користувач міг працювати з вітриною, користуючись переднастроєних звітністю скоріше як "точкою входу", ніж як кінцевим затребуваним результатом. І в цьому сенсі Oracle Discoverer (Версії Desktop і Plus), на моє переконання, і зараз є флагманським продуктом. Більш того, в цьому контексті нова аналітична платформа і цей продукт один одного доповнюють.

Але життя показало, що кількість користувачів, яким така гнучкість допомагає, а не заважає в роботі, як це не парадоксально, обмежена. І переважна більшість користувачів потребує більш простих і ергономічних засобах, а саме:


отримати необхідну інформацію на обмеженому просторі монітора і розібратися з нею за обмежений час бажано без необхідності маніпулювати клавіатурою та мишею.


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

Мені хотілося б відзначити, що додатки нової аналітичної платформи, в порівнянні з Oracle Discover, дозволяють при одних і тих же трудовитратах побудувати ергономічні робочі місця не тільки для аналітиків, але і для користувачів, роль яких ніяк не пов'язана з аналізом і оптимізацією бізнес-процесів компанії. А трудовитрати, як відомо, і визначають вартість (в усякому разі, собівартість) проекту.

Прикладом можуть служити менеджери з продажу, для яких важливо реалізувати відповідну сторінку з інформацією, прямо пов'язаної з їх фінансовою мотивацією. Але головне, що стало дуже зручно формувати зведену інформацію для топ-менеджменту, коли необхідно на обмеженому просторі монітора представити зведену інформацію в зручному для сприйняття вигляді. Це третій аспект, На якому я хотів зупинитися. Але, як кажуть, краще один раз побачити, ніж сім раз почути, тому якщо Ви ще не знайомі з цією платформою, – спробуйте і тоді самі зможете оцінити її переваги.

Про проактивного аналітиці

На закінчення хотілося б зупинитися на тому, що фахівці Oracle називають "проактивного аналітикою". Ідея досить проста і банальна, а саме: "хотілося б, щоб аналітична система не тільки дозволяла мені контролювати ключові показники ефективності, але і сама, при необхідності, тим чи іншим чином сповіщала про вихід того чи іншого показника за встановлені межі ".

Серед клієнтських додатків нової платформи є таке, яке вирішує саме це завдання. При цьому в якості формованого події (при виході показника за встановлені межі) може виступати електронне лист із вкладеним звітом, sms на мобільний телефон, що привертає увагу до звіту по обороту продажів і т.д. Але саме чудове полягає навіть не в цьому. Починаючи з версії Oracle BI EE 10.1.3.2, реалізована інтеграція програми, що формує такі бізнес-події, з "движком" Oracle BPEL PM , Що забезпечує workflow для обробки сформованих подій за відповідно встановленим ланцюжках.

Я зараз навіть не беруся фантазувати, перебираючи всі можливі в цьому зв'язку варіанти технологічної архітектури комплексних інтеграційних проектів . Але одне я знаю точно: 2006 рік став для нас ключовим з точки зору технологічного прориву і тепер в наших руках знаходиться одна з найбільш передових технологій. Тим легше нам буде задовольнити потреби підприємств-клієнтів, а значить – ще більше зміцнити свої позиції на ринку.

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


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

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

Ваш отзыв

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

*

*