Прагматика коригує теорію. Інтерв’ю Сергія Кузнецова з Джонотаном Ейнсворт, директором за напрямом “Бізнес-аналітика”, Oracle EMEA, Oracle, Бази даних, статті

 
Потреби сучасних підприємств у високотехнологічних корпоративних рішеннях в галузі бізнес-аналізу особливо гострі. І невипадково бізнес-аналітика сьогодні – ключовий ринок для Oracle. Про світові тенденції і передових рішеннях в цій галузі в інтерв’ю IT-порталу CITForum розповів Джонотан Ейнсворт (Jonathan Ainsworth), директор по напрямку “Бізнес-аналітика”, Oracle EMEA.

Здравствуйте, Джон. Мене звуть Сергій Кузнецов, і я представляю тут компанію CitForum. Спасибі за Вашу згоду дати нам інтерв’ю.


Свій перший питання я хотів би сформулювати наступним чином. Кілька років тому були, принаймні, три підходи до організації OLAP: реляційний OLAP (ROLAP), багатовимірний OLAP (MOLAP) і гібридний OLAP (HOLAP). Наскільки я пам’ятаю, основний метод, що використовувався Oracle, базувався на підході HOLAP: сховища даних (data warehouse) з використанням основної СУБД Oracle і вітрини даних (data mart) з використанням багатовимірної СУБД Oracle Express Server. Тепер ми чуємо тільки про Oracle OLAP, заснований на Oracle 10g. Чи означає це, що підхід ROLAP переміг у цьому змаганні?


Насправді, це не так. Наш підхід можна уявити, як оптимізацію архітектурної схеми. Але дозвольте мені приступити до відповіді на Ваше питання з викладу мого бачення всієї дискусії щодо ROLAP, MOLAP і HOLAP. Після цього я розповім про те, що ми маємо сьогодні.


Протягом багатьох років навколо цієї теми велися “релігійні війни”. В обговореннях MOLAP представлявся як підхід, що сприяє ефективності виконання запитів. Це дозволяло виробляти складну аналітику. Реляційний OLAP представлявся як підхід, що підтримує масштабованість оброблюваних обсягів даних. Крім того, ROLAP грунтувався на SQL, що забезпечувало гнучкість при виборі клієнтських інструментальних засобів. Однак ефективність виконання запитів була істотно нижче, ніж при використанні підходу MOLAP. Тому для оперативної аналітичної обробки доводилося переносити дані в інше середовище, таку як Express Server.


Що ж ми зробили для виправлення цієї ситуації? Ми просто перенесли Express Server і технологію MOLAP всередину основний СУБД Oracle. Тепер СУБД Oracle – це не тільки реляційна, але ще й багатовимірна СУБД. Це дозволило нам забезпечити масштабованість структур даних MOLAP. При управлінні цими структурами застосовується розбивка даних на розділи, розпаралелювання і т.д. Тепер можна будувати дуже великі багатовимірні сховища даних. Наприклад, для одного із замовників в США ми створили багатовимірне сховище на основі Oracle OLAP, побудоване на основі даних семи мільярдів транзакцій, що було абсолютно неможливо раніше.


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


Третій рівень забезпечує ефективний доступ до даних. Цей рівень може грунтуватися на технології ROLAP, і тоді в ньому використовуються звичайні реляційні схеми типу “зірка” і “сніжинка”. І тепер в Як альтернативу на цьому рівні можна створювати так звані аналітичні простору, що містять спеціальні багатовимірні структури даних. Це забезпечує оптимальний доступ до даних на верхньому рівні архітектури. Так що сховище даних тепер представляє комбінацію реляційної реалізації та технології MOLAP. На верхньому рівні сховища даних MOLAP фактично забезпечує реалізацію вітрин даних усередині сховища даних. Таким чином, в трирівневій архітектурі сховища даних забезпечуються аналітичні можливості MOLAP без потреби в ускладненні архітектури.


Дякую, Ваш відповідь повністю прояснив ситуацію. Наступні питання присвячені змінам, що відбуваються в області Business Intelligence засобів (BI) компанії Oracle. Всі ми були трохи здивовані, коли компанія Oracle придбала компанію Sieblel та її набір інструментальних засобів BI на додаток до власних коштів BI. Наскільки я розумію, основним відмінністю між традиційними засобами Oracle BI і засобами з набору Siebel Business Analytics є те, що кошти Oracle базуються на дійсно інтегрованих, фізичних окремих, узгоджених сховищах даних, в той час як кошти Siebel можуть працювати над даними, інтегровною з різних джерел в оперативному режимі, “на льоту” (над так званими “віртуальними” сховищами даних). Минулої осені я питав Білла Інмона про його ставлення до віртуальних сховищ даними, і він відповів, що існує тільки один різновид сховища даних – сховище фізично інтегрованих даних. Яка поточна позиція Oracle з цього питання?


Мене зовсім не дивує ця думка, оскільки Білл Інмон і Ральф Кімболл боряться за “чистоту релігії” протягом багатьох років. Але на практиці важко дотримуватися їх ортодоксальних позицій. Моя особиста точка зору, яка цілком відповідає можливостям BI від Siebel, полягає в тому, що кошти BI повинні застосовуватися і до динамічно сінхронізуемим даними. Я думаю, що сегментовані віртуальні сховища даних були тільки першою спробою, повернення до якої був би дуже небезпечний, оскільки такі сховища даних неможливо реалізувати. З іншого боку, я думаю, що підтримка єдиного корпоративного сховища даних, що включає всі дані, в тому числі, і ті, які надходять в реальному часі, є новою і цілком досяжною метою. І це буде не віртуальне сховище.


Ви маєте на увазі необроблені (raw) дані?


Так, включаючи необроблені дані. Всі дані. Що в цьому сенсі дає технологія Siebel? В цьому випадку ми можемо пов’язати кошти Siebel c сховищем даних, а можемо використовувати транзакційні джерела даних, які абсолютно не пов’язані зі сховищем даних. Однією з найбільш цікавих особливостей технології Siebel є те, що кошти Siebel можна застосовувати без побудови сховища даних за рахунок використання рівня метаданих, що описують дані всіх інформаційних джерел у вигляді єдиної логічної моделі. Це дуже важливо, тому що на практиці багато замовників не потребують побудові сховищ даних або не бажають витрачати на це кошти. Іншою перевагою цього підходу є те, що наш підхід робить доступними для аналізу всі дані, у той час як віртуальні сховища даних дозволяють інтегрувати тільки сховища даних, але не транзакційні джерела даних.


Ще одне питання, пов’язаний з попереднім. Як здається, люди платять великі гроші за проекти традиційних сховищ даних, оскільки очікують отримати в результаті щось дуже цінне для них: високоякісну аналітику. Для мене очевидно, що якість аналітики, заснованої на традиційних сховищах даних, має бути набагато вище якості аналітики на основі віртуальних сховищ, оскільки чим якісніше дані, тим якісніше результат аналізу. Чи потрібно розуміти, що, переходячи на використання технології Siebel, Oracle свідомо пропонує своїм замовникам користуватися неякісними даними і задовольнятися неякісним аналізом?


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


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


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


Так, цілком вірно. Рівень метаданих в обов’язковому порядку присутній при роботі зі сховищем даних і також використовується при потребі в доступі до транзакційних даних. Проміжний сервер, який називається аналітичним сервером, або BI-сервером, відповідає за управління шаром метаданих і генерацію запитів до окремих джерел даних. Засоби BI не знають, звідки беруться запитувані ними дані. На мою думку, в цьому полягає основна тенденція розвитку архітектури BI. Управління даними та метаданими повністю відділяється від засобів BI. До речі, технологія, яку ми отримали після придбання Siebel, була придбана Siebel в результаті поглинання компанії nQuire кілька років тому.


Наступний мій питання відноситься до різних видів ліцензування засобів BI, підтримуваних Oracle. Наскільки я розумію, ви підтримуєте (або збираєтеся підтримувати) три роздільних редакції наборів засобів BI: Oracle Business Intelligence Suite Enterprise Edition, Oracle Business Intelligence Suite Standard Edition і Oracle Business Intelligence Suite Standard Edition One. Про останню редакцію я чув у зв’язку з оголошенням Oracle нової стратегії підтримки малих і середніх підприємств. У чому полягає сенс виділення цих редакцій і чи слід розуміти, що остання з них являє собою “BI для бідних”?


Так, дійсно, Oracle Business Intelligence Suite існує в трьох редакціях. Oracle Business Intelligence Suite Enterprise Edition включає засоби Siebel Business Analytics, що дозволяють працювати як з сховищами даних, так і з транзакційними даними. При цьому сьогодні Oracle BI Suite Enterprise Edition складається тільки із засобів Siebel. Але дуже скоро, в кінці листопада ця редакція буде включати 70% технології Siebel і 30% технології Oracle. І дуже швидко ми досягнемо співвідношення 50% на 50%.


Oracle Business Intelligence Suite Standard Edition повністю складається з традиційних засобів бізнес-аналітики Oracle, а Oracle BI Suite Standard Edition One – це суміш з різних технологій Enterprise Edition і Standard Edition. З традиційних засобів в цю редакцію увійде Oracle Warehouse Builder. Standard Edition One буде також включати наступні засоби з набору Siebel: BI Server, що забезпечує доступ до різнорідних джерел даних; засіб виконання нерегламентованих запитів Answers; засіб побудови інформаційних панелей Dashboard. На додаток до цього, ми будемо забезпечувати засіб генерації звітів XML Publisher.


Що б очікуємо від цієї редакції? Для багатьох невеликих компаній типові потреби в BI обмежуються простими запитами і формуванням звітів над транзакційними системами і / або базами даних, заснованими на технології Oracle або інших постачальників СУБД. Але в міру зростання компаній з’являються потреби в більш складних можливості BI, зокрема, в спеціалізованих базах даних, орієнтованих на формування звітів: вітрин даних, або початкових сховищ даних. Включається до складу Standard Edition One Oracle Warehouse Builder дозволяє будувати сховище даних на основі різних джерел даних. Засіб Answers дозволяє формувати нерегламентовані звіти на основі побудованого сховища даних або транзакційних джерел даних. Таким чином, почавши з малого, сьогоднішні малі підприємства можуть нарощувати ІТ-системи в міру зростання потреб.


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


Це не зовсім так. Звичайно, ліцензія Standard Edition One накладає деякі обмеження. У Enterprise Edition присутні деякі функціональні можливості, не поставляються в Standard Edition One, але необхідні для великих компаній. У Standard Edition One ми включаємо необхідний мінімум можливостей, що дозволяють компаніям почати використовувати BI, ця редакція призначена для вирішення задач малих і середніх підприємств. Є й інші істотні обмеження. Наприклад, мінімальна ліцензія Standard Edition One передбачає одночасну роботу п’яти користувачів, а максимальна допускає наявність 50 користувачів. При подальшому зростанні потреб потрібно переходити до Enterprise Edition. Вартість ліцензії складає тисячу доларів на одного користувача. Інше обмеження виставляється на спосіб використання BI-сервера: до нього можна підключити одну базу даних Oracle, одну базу даних будь-якого іншого виробника і будь-яке число плоских файлів. Ці обмеження не заважають невеликим компаніям з користю використовувати засоби BI для вирішення своїх типових проблем, але не усувають інтерес до переходу до Enterprise Edition при зростанні компанії та її потреб.


Чи правильно я розумію, що при зростанні компанії і появу потреби в позбавленні від цих обмежень шляхом переходу до Enterprise Edition не потрібні ніякі технічні зміни?


Міграція від Standard Edition One до Enterprise Edition не повинна викликати у компаній ніяких проблем або навіть труднощів. Змінюється тільки вид ліцензії.


Мій наступний питання відноситься до технології Data Mining. Якщо я правильно зрозумів, опція Data Mining доступна тільки при придбанні корпоративної ліцензії (Enterprise License) на Oracle 10g. Чи означає це, що ви вважаєте непотрібної технологію Data Mining малим і середнім підприємствам?


Дійсно, опція Data Mining зазвичай надається тільки при придбанні корпоративної ліцензії – це якраз одне з істотних відмінностей Standard Edition One від Enterprise Edition. Це пов’язано з тим, що зазвичай data mining в середовищі сховищ даних використовується аналітиками при наявності великих обсягів даних. Зазвичай data mining потрібно для аналізу і передбачення поведінки замовників в компаніях з дуже великим числом транзакційних замовників. Я думаю, що це обмеження не перешкоджає використанню технології data mining в тих випадках, коли це дійсно потрібно, а в цих випадках за причини великих обсягів даних і інтенсивної транзакційної обробки все одно потрібна корпоративна ліцензія. От якщо б обмеження стосувалося використання OLAP, воно було б дійсно суттєвим. На мою думку, у повсякденній практиці невеликих компаній OLAP є набагато більш затребуваною технологією, ніж data mining.


В цьому році можна відзначати десятирічний ювілей об’єктно-реляційної технології баз даних. Зокрема, десять років тому з’явилася СУБД Oracle8 з об’єктно-реляційними можливостями. Принесли чи яку-небудь користь ці розширені можливості для технології BI?


Так, є дуже хороший приклад використання об’єктно-реляційних засобів для підтримки OLAP. На основі об’єктної технології СУБД Oracle забезпечується доступ на мові SQL до багатовимірним аналітичним даними. Ми використали цю технологію, щоб дати можливість працювати з багатовимірними даними так, як якщо б вони були реляційними. Це приклад використання об’єктно-реляційних засобів у внутрішніх розробках Oracle. Чесно кажучи, я не знаю прикладів застосування об’єктно-реляційних розширень зовнішніми розробниками прикладних систем. Зазвичай вони грунтуються на чисто реляційних можливостях.


Це цілком відповідає моїм власним спостереженням. Майже у всіх випадках об’єктно-реляційні кошти використовувалися самими компаніями-виробниками СУБД, а не користувачами.


Я хотів би дещо додати з цього приводу. Багато аналітиків вважають, що скоро сховища даних будуть містити не тільки реляційні або багатовимірні дані. У сховищах даних будуть зберігатися графічні зображення, фотографії, документи та інші продукти спільної діяльності людей. Наприклад, у Великобританії створюється сховище даних мережі залізниць для підтримки функціонування цієї мережі. Дані збираються на основі реального функціонування залізниць з метою характеристики їх якості. Фахівці використовують дуже складні механізми для розпізнавання різного роду несправностей. Зокрема, вони збирають, зберігають і обробляють сотні фотографій. Подібні “м’які” дані в ряді випадків дозволяють серйозно допомагати при аналізі даних.


На закінчення я хотів би дізнатися Вашу думку з приводу майбутнього Oracle Business Intelligence Suite.


Це дуже об’ємне питання. Компанія Oracle планує в наступні кілька років зробити значні інвестиції в розвиток ринку та технологій продуктів та програм BI. На мою думку, найбільш цікавим і що обіцяє напрямком є ​​аналітичні програми. Ми повинні домогтися уніфікації програм BI, які прийшли з компанією Siebel, з традиційними програмами BI Oracle. Ми повинні також домогтися уніфікації додатків BI з Fusion Applications. Повинна бути можливість використання додатків BI спільно з іншими додатками Fusion Applications, щоб підвищити загальний рівень інтелектуальності додатків.


Я вважаю, що неявно Ви мали на увазі SOA, оскільки, як мені здається, Fusion Applications – це, зокрема, шлях Oracle до наповнення загальної ідеї сервіс-орієнтованої архітектури конкретним і розвиненим змістом.


Безумовно. Продукти BI можуть відмінно використовуватися в цій архітектурі. Тому дуже цікавим напрямком є ​​інтеграція засобів BI із засобами Oracle для підтримки SOA. Це дозволить використовувати засоби BI та засоби підтримки SOA для створення розвинених інтелектуальних користувальницьких додатків, заснованих на сервіс-орієнтованої архітектури.


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

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


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

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

Ваш отзыв

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

*

*