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

1. OLAP і OLTP Будь-яка транзакційна система, як правило, містить два типи таблиць. Один з них відповідає...
2. Шість рівнів архітектур сховища даних
3. Мал. 2. Шість рівнів архітектури сховища даних
4. Віртуальні сховища даних
5. Мал. 3. Віртуальні сховища даних
6. Незалежні вітрини даних
7. Мал. 4. Незалежні вітрини даних
8. Висновок
9. Література.
10. Ресурси для скачування

OLAP і OLTP

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

Історія OLAP починається в 1993, коли була опублікована стаття 3 «Забезпечення OLAP (оперативної аналітичної обробки) для користувачів - аналітиків». Спочатку здавалося, що поділу транзакційних і аналітичних систем (OLTP - OLAP) цілком достатньо.

Однак незабаром з'ясувалося, що OLAP - системи дуже погано справляються з роллю посередника між різними транзакційними системами - джерелами даних і клієнтськими додатками.

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

Мал. 1. Еволюція розуміння місця OLAP в архітектурі

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

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

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

Шість рівнів архітектур сховища даних

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

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

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

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

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

Мал. 2. Шість рівнів архітектури сховища даних

Перший рівень представлений джерелами даних, в якості яких виступають транзакційні і успадковані системи, архіви, розрізнені файли відомих форматів, документи MS Office, а також будь-які інші джерела структурованих даних.

На другому рівні розміщується система вилучення, перетворення і завантаження даних (ETL - Extract, Transformation and Load). Основне завдання ETL - витягти дані з різних систем, привести їх до узгодженого виду та завантажити в сховище. Програмно-апаратний комплекс, на якому реалізована система ETL, повинен володіти значною пропускною спроможністю. Але ще важливіше для нього - це висока обчислювальна продуктивність. Тому кращі з систем ETL здатні забезпечувати високий ступінь паралелізму обчислень, і навіть працювати з кластерами і обчислювальні грід.

Роль наступного рівня - надійне, захищене від несанкціонованого доступу, зберігання даних. Відповідно до пропонованої потрійний стратегією 4 , Ми вважаємо, що на цьому рівні повинні розміщуватися також системи ведення метаданих і нормативно-довідкової інформації (НДІ). Оперативний склад даних (Operational Data Store) необхідний тоді, коли потрібно якомога більше оперативний доступ до хай неповним, не до кінця узгодженим даними, доступним з найменшою можливою затримкою. Зони тимчасового зберігання (Staging area) потрібні для реалізації специфічного бізнес - процесу, наприклад, коли перед завантаженням даних контролер даних повинен переглянути їх і дати дозвіл на їх завантаження в сховище.

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

Інформаційні системи на рівні розподілу даних все ще не мають загальноприйнятого назви. Вони можуть називатися просто ETL, так само, як і система вилучення, перетворення і завантаження даних на другому рівні. Або, щоб підкреслити відмінності від ETL, їх іноді називають ETL-2. При цьому системи рівня розподілу даних виконують завдання, значно відрізняються від завдань ETL, а саме, вибірку реструктуризацію і доставку даних (SRD - Sample, Restructure, Deliver) ETL отримує дані з безлічі зовнішніх систем. SRD виконує вибірку з єдиного сховища даних. ETL отримує неузгоджені дані, які треба перетворити до єдиного формату. SRD має справу з очищеними даними, структури яких повинні бути приведені у відповідність до вимог різних додатків. ETL завантажує дані в центральне сховище. SRD має доставити дані в різні вітрини відповідно до прав доступу, графіком доставки і вимогами до складу інформації.

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

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

Віртуальні сховища даних

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

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

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

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

Мал. 3. Віртуальні сховища даних

У компанії багато різних користувачів з різними потребами? Нічого страшного, ми модифікуємо нашу універсальну програму під стільки варіантів, скільки потрібно.

З'явився новий джерело даних? Все чудово. Ми перепишемо всі наші програми з урахуванням особливостей цього джерела.

Змінився формат даних? Чудово. Ми перепишемо всі наші програми з урахуванням нового формату.

Все добре, все при справі, треба розширювати відділ програмування.

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

Може, все-таки є вигода від такої архітектури?

Ми отримали жорстку зв'язок між джерелами даних і аналітичними додатками. Будь-яка зміна в джерелі даних має узгоджуватися з розробниками універсального клієнта з тим, щоб уникнути передачі спотворених і невірно інтерпретованих даних в аналітичні програми. На кожному робочому місці необхідно підтримувати набір інтерфейсів доступу до різних систем - джерел.

Іноді кажуть, що все це очевидно і не варто витрачати час на роз'яснення того, що і так всім зрозуміло. Але чому ці ж розробники на запит користувача «Мені потрібні дані з вітрин А, Б і В» пишуть клієнтську програму, яка звертається до відразу до декількох вітрин, знову і знову відтворюючи померлу архітектуру віртуального сховища даних?

Незалежні вітрини даних

Незалежні вітрини даних з'явилися як фізична реалізація розуміння того, що транзакційна і аналітична обробка даних погано уживаються на одній ЕОМ. Причини несумісності полягають в наступному:

• Для транзакционной обробки характерна велика кількість читань і записів в базу даних. Аналітична обробка може зажадати всього кілька звернень до БД.
• Довжина записів в OLTP зазвичай не перевищує 1000 символів. Аналітичний запит може зажадати мегабайти даних за одне звернення для аналізу.
• Кількість користувачів транзакционной системи може досягати кілька тисяч чоловік. Число аналітиків зазвичай в межах декількох десятків.
• Характерними вимогами для транзакційних систем є цілодобова безперебійна робота 365 днів в році (24 х 365). Аналітична обробка не висуває настільки чітко сформульованих вимог до готовності аналітичних комплексів, але не підготовлена ​​вчасно звітність може привести до серйозних неприємностей, як для аналітиків, так і для підприємства.
• Навантаження на транзакційні системи розподіляється більш-менш рівномірно в часі. Навантаження на аналітичні системи, як правило, максимальна в кінці звітних періодів (місяця, кварталу, року).
• Транзакційна обробка здійснюється, в основному над поточними даними. Аналітичні обчислення проводяться над історичними даними.
• Дані в транзакційних системах можуть оновлюватися, тоді, як в аналітичних системах дані повинні тільки додаватися, і спроба внесення змін заднім числом повинна викликати, щонайменше, настороженість.

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

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

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

Мал. 4. Незалежні вітрини даних

Значить, потрібен єдиний репозиторій - сховище даних. Але інформація в вітринах не узгоджена. Кожна вітрина успадкувала від транзакционной системи свою термінологію, свою модель даних, свою нормативно-довідкову інформацію, в тому числі, кодування даних. Наприклад, в одній системі дата виконання операції може бути закодована в російському форматі ДД.ММ.РРРР (день, місяць, рік), а в іншій в американському форматі ММ.ДД. РРРР (місяць, день, рік). Значить, при злитті даних необхідно розуміти, що означає дата 06.05.2009 - це 5 червня, або 6 травня. Отже, нам потрібна система вилучення, перетворення і завантаження даних.

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

Висновок

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

Література.

1 Асадуллаев С. «Архітектури сховищ даних - II», 19.10.2009

2 Асадуллаев С. «Архітектури сховищ даних - III», 03.11.2009.

3 Codd EF, Codd SB, and Salley CT "Providing OLAP (On-line Analytical Processing) to User-Analysts: An IT Mandate". Codd & Date, Inc. +1993.

4 Асадуллаев С. "Дані, метадані та НДІ: потрійна стратегія створення сховищ даних" .2009

Ресурси для скачування

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів