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

Третя робота завершує цикл з трьох статей, присвячених архитектурам сховищ даних (СД) та їх попередників. Велика кількість різних підходів, методів та рекомендацій призводять до певної плутанини понять, достоїнств, недоліків і меж застосування тих чи інших архітектурних рішень. У першій статті 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>

*

*