Архітектури сховищ даних – 3, Oracle, Бази даних, статті

Третя робота завершує цикл з трьох статей, присвячених архитектурам сховищ даних (СД) та їх попередників. Велика кількість різних підходів, методів і рекомендацій призводять до деякої плутанини понять, достоїнств, недоліків і меж застосовності тих чи інших архітектурних рішень. У першій статті 1 розглянуті еволюція розуміння місця OLAP, компоненти архітектури ХД, віртуальні ХД і незалежні вітрини даних. Друга публікація 2 присвячена таким архитектурам, як централізоване ХД з системою вилучення, перетворення і завантаження даних (ETL), сховище даних з системою вилучення, завантаження та перетворення даних (ELT), ЦСД з оперативним складом даних (ОCД), розширена модель з вітринами даних (ВД). У цій статті розглянуті сховище з накопиченням даних в ВД, централізована ETL з паралельними ХД та ВД, ХД з інтеграційної шиною, а також рекомендована архітектура сховища даних


Централізована ETL з паралельними сховищами і вітринами даних



В даному випадку система вилучення, перетворення і завантаження даних (ETL) є центром, навколо якого будується вся архітектура КХД. Інформація з різнорідних джерел надходить в ETL, яка завантажує очищені і узгоджені дані в центральне сховище даних (ЦСД), в оперативний склад даних (ОСД), якщо він є, і, при необхідності, в зони тимчасового зберігання. Це звичайна практика для КХД. Незвичайним є завантаження даних з ETL безпосередньо у вітрини даних.


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


З тих чи інших причин, подібні архітектури зустрічаються, і однією з проблем їх експлуатації є складнощі з відновленням даних після краху вітрин, напряму постачати з ETL. Справа в тому, що кошти ETL не призначені для довготривалого зберігання витягнутих і очищених даних. Транзакційні системи, як правило, орієнтовані на виконання поточних операцій. Тому при втраті даних в вітринах, пов’язаних з ETL, доводиться або піднімати інформацію із засобів резервного копіювання (backup) транзакційних систем, або організовувати історичні архіви систем – джерел даних. Подібні архіви не тільки вимагають коштів на своє створення і підтримку в експлуатації, але і є, з корпоративної точки зору, надмірними, оскільки дублюють функції корпоративного сховища, але призначені для обмеженої кількості вітрин даних.


Ще одним рішенням є подвійне підключення подібних вітрин – безпосередньо до засобів ETL і до сховища даних, що призводить до непорозумінь і неузгодженості результатів аналітичних робіт. Причина криється в тому, що дані, що надходять у сховище, як правило, проходять додаткові перевірки на несуперечливість з вже завантаженими даними. Наприклад, може прийти фінансовий документ з реквізитами, майже збігаються з документом, що надійшли в ЦСД раніше. Система ETL, не володіючи пам’яттю про всі завантажених даних, не може виявити, чи є новий документ законним виправленням існуючого, чи це помилка.


Рис. 1. Централізована ETL з паралельними ХД І ВД

 

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


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


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


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


Сховище з накопиченням даних у вітринах



Підставою для появи цієї архітектури з’явилися такі передумови.



  1. Деякі компанії до цих пір впроваджують і експлуатують розрізнені прикладні вітрини даних. Якість даних в цих вітринах задовольняє аналітиків, що працюють з вітринами.
  2. У деяких компаніях склалася думка, що створення корпоративного сховища даних (КХД) подібно смертельного трюку з непередбачуваними наслідками. Незважаючи на те, що труднощі створення та впровадження КХД, перш за все, пов’язані не з технологічними питаннями, а з поганою організацій проекту і недостатнім залученням експертів – майбутніх користувачів КХД, тим не менш, виникає бажання піти легким шляхом.
  3. Вимога швидких результатів. Необхідність звітувати щоквартально викликає потребу у швидких відчутних результатах. В результаті з’являється прагнення зробити і впровадити якесь обмежене рішення без зв’язку з іншими завданням.

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


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


Рис. 2. Сховище з накопиченням даних у вітринах

 

Діагноз – користувачі незалежних прикладних вітрин говорять на різних мовах бізнесу, і кожна вітрина містить власні метадані.


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


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


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


Ця робота неможлива без використання засобів ведення метаданих і НДІ, область дії яких поширюватиметься тільки на центральне сховище (ЦСД), так як незалежні вітрини даних містять свої метадані та НДІ.


В результаті керівництво та експерти можуть отримати узгоджені і несуперечливі звіти, але вони не зможуть простежити походження даних наскрізним чином, так як між незалежними вітринами і ЦСД є розрив у веденні метаданих.


Таким чином, прагнення до досягнення сьогохвилинних результатів і до демонстрації швидких успіхів призводить до відмови від єдиного, наскрізного управління метаданими і НДІ. Підсумком такого підходу є наявність семантичних островів, де співробітники говорять на різних бізнес – мовами.


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


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


Сховище даних з інтеграційної шиною



Широке поширення сервіс – орієнтованої архітектури (СОА) 3 привело до бажання використовувати її в рішеннях для корпоративних сховищ даних (КХД) замість коштів витягу, перетворення і завантаження даних (ETL) в центральне сховище (ЦСД) і замість коштів вибірки, реструктуризації та доставки даних (SRD) у вітрини даних.


Інтеграційна шина, яка лежить в основі СОА, призначена для інтеграції веб – сервісів і додатків і виконує наступні задачі:



Рис. 3. Сховище даних з інтеграційної шиною
 

 

На перший погляд функціональні можливості СОА дозволяють застосувати її для заміни ETL і SRD. Дійсно, ETL виконує посередницькі функції між ЦСД і джерелами даних, а SRD є посередником між ЦСД і вітринами даних. Якщо замінити ETL і SRD на інтеграційну шину, то, здавалося б, можна скористатися гнучкістю, що надається шиною для інтеграції додатків. Уявімо собі, що ЦСД, оперативний склад даних (ОСД), зони тимчасового зберігання, системи ведення метаданих і НДІ звертаються до шини як незалежні програми із запитами до джерел даних на оновлення даних.


Перш за все, в рази зросте навантаження на системи-джерела даних, так як одна і та ж інформація буде багаторазово передаватися за запитами в ЦСД, ОСД, зони тимчасового зберігання та системи управління метаданими і НДІ. Очевидне рішення – створити власне сховище даних при шині для кешування запитів.


По-друге, регламент збору інформації, раніше централізований в ETL, тепер розсіяний по додаткам, запитуючою даних. Рано чи пізно виникнуть неузгодженості в регламентах збору даних для ЦСД, ОСД, систем ведення НДІ і метаданих. Дані, зібрані за різними методиками, в різні відрізки часу, оброблені за різними алгоритмами, будуть неузгоджені між собою. Тим самим буде зруйнована основна мета створення ЦСД як єдиного джерела узгоджених несуперечливих даних.


У разі заміни SRD на інтеграційну шину наслідки не настільки драматичні. Але для того, щоб ЦСД могло відповідати на запити вітрин даних, спрямованих через шину, воно має бути перетворено в сервіс. Це означає, що сховище повинне відповідати найбільш поширеній стилю web – сервісів, і підтримувати протоколи HTTP / HTTPS і SOAP і XML – формат повідомлень. Такий підхід працює для коротких повідомлень, але у вітрини необхідно передавати великий обсяг даних, що може бути вирішено за допомогою передачі двійкових об’єктів. Необхідна реструктуризація даних не може бути покладена на шину, і повинна виконуватися або в ЦСД, або у вітрині. Ця функція може бути вирішена за допомогою сервісу-посередника, що приймає дані, і передавального їх у вітрини даних після реструктуризації. Тобто, ми повертаємося до ідеї кошти SRD з шинним інтерфейсом.


Таким чином, інтеграційна шина може бути використана в архітектурі КХД як транспортна середу між джерелами даних і ETL і між SRD і вітринами даних в тих випадках, коли компоненти КХД територіально рознесені і знаходяться за міжмережевими екранами відповідно до строгих вимог до захисту інформації. В цьому випадку для забезпечення взаємодії достатньо, щоб був дозволений обмін за протоколами HTTP / HTTPS. Вся логіка збору та перетворення інформації повинна бути, як і раніше зосереджена в ETL і SRD.


Рекомендована архітектура КХД



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


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


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


По-третє, дані повинні бути доступні співробітникам в обсязі, необхідному і достатньому для виконання своїх функціональних обов’язків.


По-четверте, співробітники повинні мати єдине розуміння даних, тобто повинно бути встановлено єдине смисловий простір.


По-п’яте, необхідно, по можливості, усунути конфлікти в кодуваннях даних в системах джерелах.


Рис. 4. Рекомендована архітектура КХД

 

Пропонована архітектура слід перевіреним принципам модульного конструювання “непотоплюваних відсіків”. Стратегія “Розділяй і володарюй” застосовна не тільки в політиці. Поділяючи архітектуру на модулі, ми одночасно концентруємо в них певну функціональність, отримуючи владу над некерованою ІТ стихією. Засоби ETL забезпечують повний, надійний, точний збір інформації з джерел даних завдяки зосередженої в ETL логіці збору, обробки та перетворення даних і взаємодії з системами ведення метаданих і НДІ.


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


Система ведення НДІ є третейським суддею при вирішенні конфліктів кодувань даних.


Центральне сховище даних (ЦСД) несе тільки навантаження по надійному захищеного зберігання даних. В залежності від поставлених завдань, надійність програмно-технічного комплексу (ПТК) ЦСД може досягати 99,999%, тобто забезпечувати безперебійну роботу з простоєм не більше 5 хв на рік. ПТК ЦСД може забезпечувати захист даних від несанкціонованого доступу, саботажу і стихійних лих. Структура даних в ЦСД оптимізована виключно з метою забезпечення ефективного зберігання даних.


Засоби вибірки, реструктуризації та доставки даних (SRD) в такій архітектурі є єдиним користувачем ЦСД, беручи на себе всю роботу по заповненню вітрин даних та, тим самим, знижуючи навантаження на ЦСД з обслуговування запитів користувачів.


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


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


Застосування цієї архітектури разом з потрійною стратегією інтеграції даних, метаданих і НДІ 4, Дозволяє скоротити терміни і бюджет проекту впровадження КХД і розвивати його відповідно до мінливих вимог бізнесу.



Висновок



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


Рекомендована архітектура корпоративного сховища даних дозволяє створити в короткі терміни і з мінімальними інвестиціями працездатний прототип, корисний для бізнес-користувачів. Ключовим моментом цієї архітектури, що забезпечує еволюційний розвиток КХД, є впровадження на ранніх етапах систем ведення метаданих і НДІ.

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


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

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

Ваш отзыв

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

*

*