Враження від Oracle OLAP 11g. Частина 1

Автор: Андрій Пивоваров
Джерело: Блог Андрія Пивоварова

Коли Дмитро Волков запропонував мені виступити на семінарі Database Options Details з розповіддю про OLAP опцію в 11g, я спочатку подумав – так про що тут розповідати? Між дев'ятою і десятою версією було багато відмінностей. А між 10 і 11 начебто, нічого особливо не було. Ну, крім Cube-Organized Materialized Views. Потім вирішив, що на семінарі буде маса людей, які взагалі з OLAP не працювали, ні з якою версією, тому їм, можливо, буде цікаво дізнатися про OLAP взагалі. Заодно при підготовці і подивлюся уважніше, що там змінилося. Але виявилося, що змін несподівано багато.

Для експериментів я використовував Oracle 11.1.0.6 c OLAP Patch A (# 6459753) на VMware, на який було виділено 1Gb RAM.

У цій статті я орієнтуюся на людей, які вже знайомі з Oracle Express або Oracle OLAP, ну або хоча б у загальних рисах уявляє, що це. Для початкового ознайомлення пропоную почитати мої статті "Що таке OLAP" (Частина 1 Частина 2)

Інтеграція метаданих з Oracle Database

Перше, що кинулося в очі, це те, що дійсно через будь-який SQL інструмент тепер стало дуже зручно дивитися на дані, що лежать в OLAP кубах. Причому, як тільки ви створюєте якийсь об'єкт за допомогою Analytic Workspace Manager (AWM) (показник, вимірювання і т.д.) він тут же стає видно з SQL. Для цього автоматично створюється обв'язка з VIEW, кожен з яких містить виклик CUBE_TABLE. Виглядає це приблизно так:


1.       CREATE OR REPLACE VIEW UNITS_<A class=C title=CUBEhref = "http://www.infology.ru/gloss/imm-glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/">CUBE</A>_VIEW AS  
2.       SELECT  
3.           “UNITS”,   
4.           “SALES”,   
5.           “COST”,   
6.           “TIME”,   
7.           “CHANNEL”,   
8.           “CUSTOMER”,   
9.           “PRODUCT”  
10.   FROM TABLE(<A class=C title=CUBEhref = "http://www.infology.ru/gloss/imm-glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/">CUBE</ A> _TABLE (GLOBAL.UNITS_ <A class=C title=CUBE href="http://www.infology.ru/gloss/imm-glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/"> CUBE </ A>));

GLOBAL.UNITS_CUBE – це вказівка на те, що дані лежать в кубі UNITS_CUBE, який створювався в AWM. А CUBE_TABLE – таблична функція, такий універсальний виклик даних з об'єктів, що лежать в аналітичному прострастве.

У 10й версії теж була можливість побачити дані через SQL. Для цього була таблична функція OLAP_TABLE. (Власне, вона і зараз є, але сенсу її використовувати, напевно, не дуже багато) Але щоб змусити її працювати, потрібно було попередньо створити купу різних абстрактних типів даних, опису LIMITMAP та ін. Причому можна було помилитися на будь-якому кроці. Загалом, для початківців зовсім не підходило. Навіть був такий плагін до AWM, який ці типи міг створити сам, що, загалом, частково проблему вирішувало. Зараз нічого робити не треба. Для кожного виміру і куба є відповідна в'юшка. Ви можете легко робити запити до цих VIEW для того, щоб наприклад, фільтрувати вимірювання за атрибутами. Тобто, у вашому SQL запиті будуть об'єднуватися в'юшки вимірювань і куба, а оптимізатор сам знає як весь цей запит проштовхнути через CUBE_TABLE всередину OLAP движка, де він і буде відпрацьовано. Більш того, ніхто не забороняє об'єднувати дані з OLAP з даними з реляціонкі в будь-який запит. Наприклад, для того щоб з'єднати агреговані дані з детальними.

Крім того, в 10g виклики OLAP_TABLE працювали досить повільно. У 11g різниця у швидкості помітна неозброєним оком. Причому, вбудована Переглядач AWM працює досить повільно, але якщо такий самий запит виконати з SQL, він працює набагато швидше. Що говорить швидше за все про те, що Переглядач AWM генерує запити не так, або повільно обробляє результати. Взагалі, при бажанні це можна оттрассіровать, але мені поки що не вистачило часу.

Збільшення швидкості роботи SQL пов'язано з тим, що тепер обробка запитів оптимізатором зроблена більш розумно і фільтрація значень за вимірюваннями відбувається всередині аналітичного простору, тобто в движку OLAP, а не в самому Oracle, як це було в 10g. Якщо порівняти запит SQL і аналогічний йому DML запит виконувати з OLAP Worksheet, то різниця в швидкості не помітна. Тобто, SQL отрабативат приблизно також як і запит безпосередньо до двигуна.

Можна зробити висновок, що зв'язка SQL – CUBE_TABLE – стала цілком придатною для того, щоб користуватися нею для доступу до OLAP.

Як наслідок, до даних OLAP можна звертатися будь-яким ROLAP інструментом, наприклад Oracle Business Intelligence Enterprise Edition, який працює з базою Oracle через SQL. Інші API не обов'язкові.

При цьому, будь-які маніпуляції з движком OLAP, якщо це необхідно, можна робити використовуючи пакет DBMS_AW.

Спрощення стандартної форми

Коли я запустив новий AWM, виявилося, що в ньому зникла можливість дивитися структуру AW в режимі Object View.

Тут треба зробити невеличкий відступ.

У Oracle Express були призначені для користувача об'єкти. Були і внутрішні об'єкти, що зберігають метадані, які фізично були реалізовані об'єктами Express, такими як вимірювання, відносини, змінні і і.дз. Але внутрішні були в основному приховані від кінцевого користувача. Та й великий небходимости в них залазити не було. У 9й версії, коли OLAP став частиною СУБД Oracle, спочатку все залишалося, як було в Express, але потім, в районі 9.2.0.4 (точно не пам'ятаю) була придумана так звана стандартна форма (Standard Form, SF)

Це спеціальна обв'язка метаданих, потрібна для інтеграції з СУБД Oracle. Але проблема в тому, що ті об'єкти, які створювалися в AWM і які користувач вважав вимірами, показниками і т.д., на самому справі фізично лежать зовсім в інших об'єктах, а дістатися до них можна було лише расшіфорвав складний шар метаданих SF. А SF сама по собі змінювалася з кожним патчсетом. Express завжди славився своїм дуже гнучким мовою, який зараз називається OLAP DML. На ньому можна було написати дуже складні розрахункові формули і програми, для роботи з багатовимірними об'єктами. Але складність SF по суті вбивала цю можливість, так як було досить складно розшифровувати метадані, до того ж, велика ймовірність, що в наступному релізі щось поміняється і ваша програма перестане працювати. А SF вважається об'єктом внутрішнім і підтримка минулих версій SF не гарантується.

Тому, в AWM минулих версій було два види подання об'єктів OLAP – Model View і Object View. Model View показував як об'єкти виглядають через призму SF, Object View – як вони зберігаються на самому справі. Що й говорити, знайти відповідники між двома предствленного було дуже складно.

У 11 версії все стало набагато простіше. Створюємо ми з AWM куб UNITS_CUBE, а в ньому показник SALES. Тепер у OLAP DML ми можемо побачити об'єкт UNITS_CUBE_SALES, назва якого складено з назви куба і назви показника. Це ж поширюється і на обчислювані показники. У нас тепер знову є простий шлях використання наших показників у формулах і програмах. І не важливо, що насправді, це не куб, а формула, яка дивиться на інший об'єкт. Для нас вже не важливо знати, як саме він зберігається.
Хоча, якщо комусь цікаво, можна і подивитися:



  1. ->dsc UNITS_<A class=C title=CUBE href=”http://www.infology.ru/gloss/i
    mm-glossary/Title/Y3ViZQ == / Referer/LzIwMDkvMDQvMzAvODE4Lw ==/">CUBE</A>_SALES   

  2.   

  3. DEFINE UNITS_<A class=C title=CUBE href=”http://www.infology.ru/gloss/imm-
    glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/”>CUBE</A>
    _SALES FORMULA LOCKDFN NUMBER WITH NULLTRACKING   

  4. <TIME CHANNEL CUSTOMER PRODUCT>   

  5. EQ this_aw!UNITS_<A class=C title=CUBE href=”http://www.infology.ru/gloss/imm-
    glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/”>CUBE</A>_STORED
    (this_aw!UNITS_<A class=C title=CUBEhref = "http://www.infology.ru/gloss/imm-glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/">CUBE</A>_MEASURE_DIM SALES)   

  6.   

  7. ->dsc units_<A class=C title=cube href=”http://www.infology.ru/gloss/imm-glossary/Title/Y3ViZQ==
    /Referer/LzIwMDkvMDQvMzAvODE4Lw==/”>cube</A>_stored   

  8.   

  9. DEFINE UNITS_<A class=C title=CUBEhref = "http://www.infology.ru/gloss/imm-glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/">CUBE</A>_STORED VARIABLE 
    READONLY LOCKDFN NUMBER   

  10. WITH NULLTRACKING WITH AGGCOUNT CHANGETRACKING   

  11. <UNITS_<A class=C title=CUBEhref = "http://www.infology.ru/gloss/imm-glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/">CUBE</A>_MEASURE_DIM 
    TIME UNITS_<A class=C title=CUBEhref = "http://www.infology.ru/gloss/imm-glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/">CUBE</A>_COMPOSITE   

  12. <CHANNEL CUSTOMER PRODUCT>>   

  13.   

  14. ->dsc units_<A class=C title=cubehref = "http://www.infology.ru/gloss/imm-glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/">cube</A>_composite   

  15.   

  16. DEFINE UNITS_<A class=C title=CUBEhref = "http://www.infology.ru/gloss/imm-glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/">CUBE</A>_COMPOSITE 
    COMPOSITE READONLY LOCKDFN   

  17. <CHANNEL CUSTOMER PRODUCT> COMPRESSED  

Нагадаю, що через SQL той же куб можна побачити через вьюшку UNITS_CUBE_VIEW, а показник SALES відповідно буде UNITS_CUBE_VIEW.SALES

  SELECT time,   


  product,   


  customer,   


  channel,   


  sales   


FROM units_ <A class=C title=cube href="http://www.infology.ru/gloss/imm-glossary/Title/Y3ViZQ==/Referer/LzIwMDkvMDQvMzAvODE4Lw==/"> cube </ A> _view


WHERE rownum < 15;   


TIME      PRODUCT CUSTOMER CHANNEL      SALES   


——— ——- ——– ——- ———-   


 TOTAL     TOTAL   TOTAL    TOTAL      4000968   
CY1999    TOTAL   TOTAL    TOTAL       330425   
CY2003    TOTAL   TOTAL    TOTAL       534069   
CY1998    TOTAL   TOTAL    TOTAL       253816   
CY2005    TOTAL   TOTAL    TOTAL       565718   
CY2006    TOTAL   TOTAL    TOTAL       584929   
CY2004    TOTAL   TOTAL    TOTAL       587419   
CY2000    TOTAL   TOTAL    TOTAL       364233   
CY2002    TOTAL   TOTAL    TOTAL       364965   
CY2001    TOTAL   TOTAL    TOTAL       415394   
CY2000.Q1 TOTAL   TOTAL    TOTAL        88484   
CY2001.Q2 TOTAL   TOTAL    TOTAL        97346   
CY2001.Q3 TOTAL   TOTAL    TOTAL       105704   
CY2005.Q3 TOTAL   TOTAL    TOTAL       138953  


І ось тут видно основна відмінність даних, які дістаються з OLAP від даних, які беруться зі звичайних таблиць Oracle. Зверніть увагу на першу сходинку, де чотири слова "TOTAL". У цьому рядку – агрегат (Сума) з продажу по всіх вимірах. Якщо б ми хотіли дістати суму по всіх вимірах зі звичайної таблиці, нам потрібно було написати щось на зразок

select sum(sales) from units_fact

А OLAP вже видає всі можливі агрегати, тому замість підсумовування, нам потрібно в умовах SQL запиту WHERE описати фільтр цього рядка. Саме підсумовування робити не треба. Суму вже порахував OLAP сервер.

Це природно накладає деякі умови на програмування SQL над OLAP. Наприклад, в тому ж BI EE потрібно спеціальним чином описати правила обрахунку рівнів ієрархій, що б не пішло підсумовування за вже агрегованим даними.

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

Далі буде.

 


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


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

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

Ваш отзыв

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

*

*