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

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



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


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


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


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


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


Рис. 1. Централізоване сховище даних з ETL

 

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


Як видно, до засобів ETL пред'являються різні вимоги:



У зв'язку з цими, часто взаємовиключними вимогами, проектування і розробка засобів ETL перетворюється на складне завдання навіть тоді, коли використовуються рішення, пропоновані на ринку.


 


Централізоване сховище даних з ELT



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


З тим, щоб зрозуміти, які порівняльні переваги і недоліки систем ETL і ELT, звернемося до трьох основних функцій корпоративного сховища даних (КХД):



  1. Повний і своєчасний збір та обробка інформації від джерел даних;
  2. Надійне і захищене зберігання даних;
  3. Надання даних для аналітичних робіт.

На вхід систем ETL / ELT надходять різнорідні дані, які необхідно порівняти, очистити, привести до єдиних форматів, обробити за необхідними обчислювальним алгоритмам. З одного боку, в системах ETL / ELT дані практично не затримуються, з іншого – через ці системи в сховище втікає основний потік інформації. Тому вимоги до забезпечення захисту інформації можуть бути помірними.
Рис. 2. Централізоване сховище даних з ELT

 

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


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


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


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


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


Незважаючи на декларовані переваги продуктивності схеми ELT, на практиці з'ясовується, що



  1. Якість даних впливає на час їх завантаження. Наприклад, ETL під час очищення і перетворенні даних може відкидати до 90% повторюваних даних. ELT в цьому випадку завантажить всі дані в ЦХД, де і буде відбуватися очищення.
  2. Швидкість перетворення даних в сховищі сильно залежить від алгоритмів обробки і структур даних. У деяких випадках більш ефективна SQL – обробка усередині бази даних сховища, в інших – швидше будуть працювати зовнішні програми, извлекающие дані для обробки та завантажили результати обробки в сховище.
  3. Деякі алгоритми дуже складно реалізувати, використовуючи засоби SQL. Це накладає обмеження на використання схеми ELT, тоді як ETL може використовувати більш ефективні інструменти обробки даних
  4. ETL є єдиною областю, де сконцентровані правила вилучення, обробки і завантаження даних, що спрощує експлуатацію, доопрацювання і тестування алгоритмів. ELT, навпаки, розносить алгоритми збору і завантаження з алгоритмами перетворення даних. Тобто, для тестування нових алгоритмів перетворення потрібно або ризикувати цілісністю даних у сховище, що знаходиться в промисловому виробництві, або створювати тестову копію сховища, що є досить дорогим заходом.

Таким чином, порівнюючи ETL і ELT, ми бачимо, що переваги при завантаженні і перетворенні даних неочевидні, що ELT стикається з обмеженнями SQL при перетворенні даних, і що економія на програмно – Апаратному комплексі ELT призводить до фінансових витрат на створення програмно-апаратної тестової копії ЦХД.


Застосування ELT, можливо, виправдано, якщо:



  1. Немає жорстких вимог до надійності, продуктивності і захищеності сховища.
  2. Бюджетні обмеження змушують йти на ризик втрати даних.
  3. Сховище даних і джерела даних взаємодіють через сервісну шину (SOA).

Останній випадок найбільш екзотичний, але і він має право на існування в певних умовах. У цьому випадку на шину покладено інтеграція джерел з ХД на рівні обміну повідомленнями, і мінімальне (За мірками сховища) перетворення даних і їх завантаження сховище.


 


Централізоване ХД з ОCД



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


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


Рис. 3. Централізоване ХД з ОCД

 

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


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


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


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

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


 


Розширена модель ХД з вітринами даних



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


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


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


Рис. 4. Розширена модель з вітринами даних

 

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


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


Якщо вітрини наповнюються прямо з КХД, то фактична кількість користувачів знижується з сотень і тисяч до десятків вітрин, які і є користувачами КХД. При використанні коштів SRD (Sample, Restructure, Delivery – вибірка, реструктуризація, доставка) кількість користувачів скорочується до 1. У цьому випадку вся логіка інформаційного постачання вітрин зосереджується в SRD. Вітрини можуть бути оптимізовані під обслуговування користувача запитів. Програмно-технічний комплекс КХД може бути оптимізовано виключно під надійне, захищене зберігання даних.


Засоби SRD також пом'якшують навантаження на КХД за рахунок того, що різні вітрини можуть звертатися до одних і тих же даних, тоді як SRD витягує дані один раз, перетворює до різних форматів і доставляє в різні вітрини даних.


 


Висновок



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


Читати частина 3

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


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

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

Ваш отзыв

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

*

*