У цій статті йдеться про архітектуру сховищ даних. Чим керуватися за її побудові, які підходи працюють – і чому.

"Казка брехня - та в ній натяк ..."

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

Розбір польотів

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

1. У принципі, у нас непогане сховище: якщо не чіпати – все працює. Щоправда, щойно потрібно внести зміну – починаються «локальні обвали».
2. Дані завантажуються щодня, за регламентом, у межах великого процесу, протягом 8ч. І нас це влаштовує. Але якщо раптом виникає збій, це вимагає ручного втручання. І далі може працювати непередбачено довго, т.к. потрібна участь людини в процесі.
3. Накотили реліз – чекай на проблеми.
4. Якесь одне джерело не змогло вчасно віддати дані – чекають на всі процеси.
5. Цілісність даних контролює база даних – тому наші процеси падають помилково, коли вона порушується.
6. У нас дуже велике сховище – 2000 таблиць в одній спільній схемі. І ще 3000 у безлічі інших схем. Ми вже слабо уявляємо, як вони влаштовані та з якого приводу з'явилися. Тому нам буває складно щось перевикористати. І доводиться багато завдань вирішувати наново. Оскільки так простіше і швидше (ніж розбиратися «в чужому коді»). У результаті маємо розбіжності і функціонал, що дублюється.
7. Ми очікуємо, що джерело даватиме якісні дані. Але виявляється, що це негаразд. У результаті багато часу витрачаємо на вивірку своїх фінальних звітів. І дуже в цьому досягли успіху. У нас навіть є налагоджений процес. Щоправда, це триває час. Але користувачі звикли.
8. Користувач не завжди довіряє нашим звітам та вимагає обґрунтування тієї чи іншої цифри. У якихось випадках він має рацію, а в якихось ні. Але дуже складно їх доводити, т.к. у нас не передбачено засобів "наскрізного аналізу" (або data lineage).
9. Ми могли б залучити додаткових розробників. Але ж у нас проблема – як нам включити їх у роботу? Як найефективніше розпаралелити роботи?
10. Як розвивати систему поступово, не вдаючись у розробку «ядра системи» на цілий рік?
11. Сховище даних асоціюється із корпоративною моделлю. Але ми точно знаємо (бачили у банку XYZ), що будувати модель можна нескінченно довго (у банку XYZ шість місяців ходили та обговорювали бізнес-сутності, без будь-якого руху). А навіщо вона загалом? Чи, може, краще без неї, якщо з нею стільки проблем? Може її взагалі якось згенерувати?
12. Ми вирішили вести модель. Але як системно розвивати модель даних сховища? Чи потрібні нам правила гри і які вони можуть бути? Що це нам дасть? А якщо ми помилимося з моделлю?
13. Чи маємо ми зберігати дані, або історію їхніх змін, якщо «бізнесу вони не потрібні»? Не хотілося б «зберігати сміття» та ускладнювати використання цих даних для реальних завдань. Чи сховища збережуть історію? Яка вона буває? Як сховище працює з часом?
14. Чи потрібно намагатися уніфікувати дані на сховищі, якщо ми маємо систему управління НСІ? Якщо є МДМ, чи це означає, що тепер вся проблема з майстер-даними вирішена?
15. У нас незабаром очікується заміна ключових облікових систем. Чи сховище даних має бути готовим до зміни джерела? Як цього досягти?
16. Чи потрібні нам метадані? Що під цим розумітимемо? Де вони можуть бути використані? Як можна продати? Чи потрібно їх зберігати «в одному місці»?
17. Наші Замовники украй не стабільні у своїх вимогах та бажаннях – постійно щось змінюється. У нас взагалі бізнес дуже динамічний. Поки що ми щось робимо – це вже стає непотрібним. Як нам зробити так, щоб видавати результат максимально швидко – як гарячі пиріжки?
18. Користувачі потребують оперативності. Але ми можемо наші основні процеси завантаження запускати часто, т.к. це навантажує системи-джерела (погано позначається на продуктивності) – тому ми вішаємо додаткові потоки даних – які будуть забирати точково – те, що нам потрібно. Щоправда, виходить багато потоків. І частину даних ми потім викинемо. До того ж, буде проблема збіжності. Але інакше ніяк…

Антикрихкість

Через якийсь час картина наступна:
«Ось сховище. І воно працює, якщо його не чіпати. Проблеми виникають тоді, коли ми маємо щось змінювати».

До нас прилітає зміна, вплив якої ми не в змозі оцінити і осмислити (оскільки не заклали таких інструментів у систему спочатку) – і щоб не ризикувати, ми не чіпаємо те, що є, а робимо ще одну прибудову збоку, і ще одну, і ще - перетворюючи наше рішення на нетрів, або як кажуть у Латинській Америці, «фавели», куди навіть поліцейські заходити бояться.
Виникає відчуття втрати контролю над власною системою хаосу. Потрібно все більше рук, щоб підтримувати існуючі процеси та вирішувати проблеми. І зміни робити все складніше. Іншими словами, система стає нестійкою до стресів, неадаптивною до змін. І крім того, з'являється сильна залежність від персонажів, які знають фарватер, оскільки карти ні в кого немає.

Така властивість об'єкту – руйнуватися під впливом хаосу, випадкових подій та потрясінь - Нассим Ніколас Талеб називає крихкістю . А також вводить протилежне поняття: антикрихкість – коли предмет не руйнується від стресу та випадковостей, а отримує від нього пряму вигоду. («Антихрупність. Як отримати вигоду з хаосу»)
Інакше це можна назвати адаптивність або стійкість до змін .

Що це означає у цьому контексті? Які є джерела хаосу для ІТ-систем? І що означає «здобути вигоду з хаосу» з погляду ІТ архітектури?
Перша думка, яка спадає на думку – зміни, які приходять ззовні. Що є зовнішнім світом системи? Для сховища зокрема. Звичайно, насамперед – зміни з боку джерел даних для сховища:

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

Не менш критичні зміни ініціюються з боку споживачів сховища (зміна вимог):

• раніше для побудови звіту даних вистачало – тепер потрібно підключити додаткові поля чи нове джерело даних;
• раніше реалізовані методики обробки даних застаріли – потрібно переробити алгоритми та все, на що це впливає;
• раніше всіх влаштовувало поточне значення атрибута довідника на інформаційній панелі – тепер потрібне значення, актуальне на момент виникнення аналізованого факту/події;
• виникла вимога до глибини історії зберігання даних, якої раніше не було – зберігати дані не за 2 роки, а за 10 років;
• раніше було достатньо даних за станом «на кінець дня/періоду» - тепер потрібний стан даних «всередині дня», або на момент певної події (наприклад, прийняття рішення щодо кредитної заявки – для Basel II);
• раніше нас влаштовувала звітність за даними на вчора (T-1) чи пізніше, зараз нам потрібен T0;
• і т.д.

Але це ще не все.
Говорячи про мінливість, ми перш за все згадуємо зовнішні фактори. Адже всередині ми можемо все контролювати, нам так здається, чи не так? І так і ні. Так, більшість факторів, які поза зоною впливу – зовнішні. Але є й “внутрішня ентропія”. І саме через її наявність нам іноді потрібно повернутися "у точку 0". Почати гру спочатку.
У житті ми часто схильні починати з нуля. Чому нам це властиво? І чи це так погано?
Що стосується ІТ. Для самої системи – це може бути дуже добре – можливість переглянути окремі рішення. Особливо коли ми можемо зробити це локально. Рефакторинг - процес розплутування тієї «павутини», яка періодично виникає у розвитку системи. Повернення «до початку» може бути корисним. Але має ціну.
При грамотному управлінні архітектурою ця ціна знижується - і процес розвитку системи стає більш контрольованим і прозорим. Простий приклад: якщо дотримується принципу модульності – можна переписати окремий модуль, не торкнувшись зовнішні інтерфейси. І цього не можна зробити за монолітної конструкції.

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

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

Приклад системи з «казки про сховище» - це якраз вельми хитка система, побудована на крихких підходах до проектування. І якщо так відбувається – руйнація настає досить швидко, саме для цього система класу.
Чому я можу так стверджувати? Тема сховищ не є новою. Підходи та інженерні практики, які були за цей час вироблені, були спрямовані саме на це збереження життєздатності системи.
Простий приклад: одна з найбільш частих причинпровалу проектів сховищ «на зльоті» - це спроба побудувати сховище над системами-джерелами, що у стадії розробки, без узгодження інтеграційних інтерфейсів – спроба забрати дані безпосередньо з таблиць. У результаті пішли в розробку - цей час база даних джерела змінилася - і потоки завантаження в сховище стали непрацездатні. Переробляти щось пізно. А якщо ще й не підстрахувалися, зробивши кілька шарів таблиць усередині сховища – все можна викинути і починати заново. Це лише один із прикладів, причому один із простих.

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

Що таке сховище даних та навіщо ми його будуємо

Як взагалі люди дійшли того, що необхідні сховища даних? І чим вони відрізняються від просто «дуже великої бази даних»?
Давним-давно, коли у світі жили просто «системи обробки бізнес-даних», був поділу ІТ-систем такі класи як фронтальні oltp-системи, бэк-офисные dss, системи обробки текстових даних, сховища даних, і т.д.
Це був той час, коли Майклом Стоунбрейкером було створено першу реляційну СУБД Ingres.
І це був час, коли ера персональних комп'ютеріввихором увірвалася в комп'ютерну індустріюі назавжди перевернула усі уявлення ІТ спільноти того часу.

Тоді можна було легко зустріти корпоративні програми, написані на базі СУБД класу desktop – таких як Clipper, dBase та FoxPro. А ринок клієнт-серверних додатківі СУБД лише набирав обертів. Одна за іншою з'являлися сервери баз даних, які надовго займуть свою нішу в ІТ-просторі - Oracle, DB2 і т.д.
І було поширено термін «додаток баз даних». Що включало в себе таку програму? Спрощено - деякі форми введення, якими користувачі могли одночасно вводити інформацію, деякі розрахунки, які запускалися «по кнопці» чи «за розкладом», і навіть якісь звіти, які можна було побачити на екрані чи зберегти як файлів і надіслати на печатка.
"Нічого особливого - звичайний додаток, тільки є база даних, - так помітив один з моїх наставників на ранньому етапі трудового шляху. Чи так нічого особливого? – подумала тоді я.

Якщо придивитися - то особливості все-таки є. У міру зростання користувачів, обсягу інформації, що надходить, у міру зростання навантаження на систему - її розробники-проектувальники, щоб зберегти швидкодію на прийнятному рівні йдуть на деякі «хитрощі». Найперше – це поділ монолітної «системи обробки бізнес-даних» на програму обліку, яка підтримує роботу користувачів у режимі on-line, і окремо виділяють програму для batch-обробки даних та звітності. Кожна з цих програм має свою базу даних і навіть розміщується на окремому екземплярі сервера БД, з різними налаштуваннямипід різний характер навантаження – OLTP та DSS. І між ними вишиковуються потоки даних.

Це все? Здавалося б – проблему вирішено. Що ж відбувається далі?
А далі компанії зростають, їх інформаційні потреби множаться. Зростає і кількість взаємодій із зовнішнім світом. І в результаті є не одне велика програмащо повністю автоматизує всі процеси, а кілька різних, від різних виробників. Число систем, що породжують інформацію – систем-джерел даних у компанії збільшується. І рано чи пізно, виникне потреба побачити та зіставити між собою інформацію, отриману з різних систем. Так, у компанії з'являється Сховища даних – новий клас систем.
Загальноприйняте визначення цього класу систем звучить так.

Сховище даних (або Data Warehouse)– предметно-орієнтована інформаційна база даних, спеціально розроблена та призначена для підготовки звітів та бізнес-аналізу з метою підтримки прийняття рішень в організації

Ключові особливості сховищ даних

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

По-друге, це історичні дані – "Corporate memory" - Так називають сховища даних. Щодо роботи з часом у сховищах все дуже цікаво. В облікових системах дані є актуальними в моменті. Потім користувач робить якусь операцію – і дані оновлюються. При цьому історія змін може і не зберегтися – це залежить від практики обліку. Візьмемо, наприклад, решту на банківському рахунку. Нас може цікавити актуальний залишок на «зараз», на кінець дня або на момент події (наприклад, в момент розрахунку скорингового балу). Якщо перші два вирішуються досить просто, то для останнього, швидше за все, будуть потрібні спеціальні зусилля. Користувач, працюючи зі сховищем, може звертатися до минулих періодів, здійснювати їхнє порівняння з поточним тощо. Саме подібні можливості, пов'язані з часом, істотно відрізняють сховища даних від систем обліку – отримання стану даних у різних точках осі часу – на певну глибину у минулому.

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

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

Архітектурна концепція

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

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

Core Data Layer – ядро ​​сховища - центральний компонент системи, який відрізняє сховище від просто "платформи batch-інтеграції", або "великого звалища даних", оскільки його основна роль - це консолідація данихіз різних джерел, приведення до єдиних структур, ключів. Саме при завантаженні в ядро ​​здійснюється основна робота з якістю даних та загальні трансформації, які можуть бути складними.
Завдання цього шару– абстрагувати своїх споживачів від особливостей логічного устрою джерел даних та необхідності зіставляти дані з різних систем, забезпечити цілісність та якість даних.

Data Mart Layer - аналітичні вітрини – компонент, основна функція якого – перетворення даних до структур, зручним для аналізу (якщо з вітринами працює BI – це, як правило, dimensional model), або відповідно до вимог системи-споживача.
Зазвичай, вітрини беруть дані з ядра – як надійного і вивіреного джерела – тобто. користуються сервісом цього компонента щодо приведення даних до єдиного виду. Будемо називати такі вітрини регулярними . В окремих випадках вітрини можуть брати дані безпосередньо із стейджингу – оперуючи первинними даними (у ключах джерела). Такий підхід зазвичай використовується для локальних завдань, де не потрібна консолідація даних з різних систем і де потрібна оперативність більш ніж якість даних. Такі вітрини називають операційними . Деякі аналітичні показники можуть мати складні методики розрахунків. Тому, для таких нетривіальних розрахунків та трансформацій створюють так звані вторинні вітрини .
Завдання шару вітрин– підготовка даних відповідно до вимог конкретного споживача – BI-платформи, групи користувачів або зовнішньої системи.

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

Також виділяють спеціальний компонент (або набір компонентів), який надає сервісні функції всім шарів. Одне з ключових його завдань – функція, що управляє, - забезпечити «єдині правила гри» для всієї системи в цілому, залишаючи право на використання різних варіантів реалізації кожного з описаних вище шарів – у т.ч. використовувати різні технології завантаження та обробки даних, різні платформи зберігання тощо. Зватимемо його сервісним шаром (Service Layer) . Він не містить бізнес-даних, але має свої структури зберігання – містить область метаданих, а також область для роботи з якістю даних (і можливо інші структури – залежно від покладених на нього функцій).

Такий чіткий поділ системи на окремі компоненти суттєво підвищує керованість розвитку системи:

• знижується складність завдання, що ставиться розробнику функціоналу того чи іншого компонента (він не повинен одночасно вирішувати і питання інтеграції із зовнішніми системами, і продумувати процедури очищення даних, і думати про оптимальне представлення даних для споживачів) – завдання простіше декомпозувати, оцінити та виконати невеликий delivery;
• можна підключати на роботу різних виконавців (і навіть команд, чи підрядників) – т.к. такий підхід дозволяє ефективно розпаралелювати завдання, знижуючи їх взаємний вплив один на одного;
• наявність персистентного стейджинга дозволяє швидко підключити джерела даних, не проектуючи повністю ядро, або вітрини для всієї предметної області, а далі поступово добудовувати інші верстви відповідно до пріоритетів (причому дані будуть у сховищі – доступні системним аналітикам, що значно полегшить завдання подальшого розвитку сховища);
• наявність ядра дозволяє всю роботу з якістю даних (а також, можливі промахи та помилки) приховати від вітрин і від кінцевого користувача, а головне – використовуючи цей компонент як єдине джерело даних для вітрин, можна уникнути проблем зі збіжністю даних внаслідок реалізації загальних алгоритмів одному місці;
• виділення вітрин дозволяє врахувати відмінності та специфіку розуміння даних, які можуть бути у користувачів різних підрозділів, а їх проектування під вимоги BI дозволяє не лише видавати агреговані цифри, а й забезпечити перевірку достовірності даних шляхом надання можливостей drill down до первинних показників;
• наявність сервісного шару дозволяє виконувати наскрізний аналіз даних (data lineage), використовувати уніфіковані засоби аудиту даних, загальні підходи до виділення дельти змін, роботи з якістю даних, управління завантаженням, засоби моніторингу та діагностики помилок, прискорює вирішення проблем.

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

Ядро системи

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

Модель ядра сховища та корпоративна модель даних

Міф 1 Корпоративна модель даних – це величезна модель, що з тисяч сутностей (таблиць).
Насправді. У будь-якій предметній області, у будь-якому бізнес-домені, у даних будь-якої компанії, навіть найскладнішої, основних сутностей небагато – 20-30.

Міф 2 Не потрібно розробляти жодну «свою модель» - купуємо галузеву референсну модель – і робимо все за нею. Витрачаємо гроші – зате отримуємо гарантований результат.
Насправді. Референсні моделі можуть бути дуже корисні, т.к. містять галузевий досвід моделювання даної галузі. З них можна отримати ідеї, підходи, практики іменування. Перевірити «глибину охоплення» області, щоб не упустити з уваги щось важливе. Але ми навряд чи зможемо використовувати таку модель з коробки - як є. Це такий самий міф, як наприклад – покупка ERP-системи (або CRM) та її впровадження без будь-якого «докручування під себе». Цінність таких моделей народжується в їхній адаптації до реалій саме цього бізнесу, саме цієї компанії.

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

Час на розробку моделі справді знадобиться. Але це час, витрачене на «малювання сутностей» - це час, необхідне аналізу предметної області, вникнення у те, як влаштовані дані. Саме тому в цьому процесі дуже беруть участь аналітики, а також залучаються різні бізнес-експерти. І робиться це точково, вибірково. А не шляхом організації зустрічей за участю шаленої кількості людей, розсилок величезних анкет тощо.
Якісний бізнес та системний аналіз – ось що є ключовим при побудові моделі ядра сховища. Потрібно багато чого зрозуміти: де (у яких системах) породжуються дані, як вони влаштовані, у яких бізнес-процесах вони циркулюють тощо. Якісний аналіз ще жодній системі не шкодив. Швидше, навпаки – проблеми виникають із «білих плям» у нашому розумінні.

Розробка моделі даних – це процес винаходу і придумування чогось нового. Фактично модель даних у компанії вже існує. І процес її проектування радше схожий на «розкопки». Модель акуратно і ретельно виходить на світ із «ґрунту» корпоративних даних і вбирається в структуровану форму.

Міф 4 У нас в компанії бізнес настільки динамічний, і все так швидко змінюється, що марно нам робити модель - вона застаріє раніше, ніж ми введемо цю частину системи в експлуатацію.
Насправді. Згадаймо, що ключовий фактор ядра – стабільність. І насамперед, топології моделі. Чому? Тому що саме цей компонент є центральним і впливає на решту. Стабільність – це вимога і до моделі ядра. Якщо модель дуже швидко застаріває - значить вона неправильно спроектована. Для її розробки обрані не ті підходи та «правила гри». І це питання якісного аналізу. Ключові сутності корпоративної моделі змінюються дуже рідко.
Але якщо нам спаде на думку зробити для компанії, що торгують скажімо, кондитерськими виробами, замість довідника «Продукти» зробити «Цукерки», «Торти» та «Пироги». То коли з'явиться піца в переліку товарів - так, потрібно буде вводити безліч нових таблиць. І це якраз питання підходу.

Міф 5 Створення корпоративної моделі – це дуже серйозна, складна та відповідальна справа. І страшно зробити помилку.
Насправді. Модель ядра хоч і має бути стабільною, але все ж таки не «відлита в металі». Як і будь-які інші проектні рішення, її структуру можна переглядати та видозмінювати. Просто не потрібно забувати про цю її якість. Але це зовсім не означає, що на неї "не можна дихати". І це не означає, що неприпустимі тимчасові рішення та «заглушки», які мають бути заплановані до переробки.

Міф 6 Якщо у нас джерело даних – це, наприклад, система НСІ (або система управління майстер-даними – МДМ), то вона вже по-хорошому має відповідати корпоративній моделі (особливо, якщо вона нещодавно спроектована, і не встигла обрости «побочкою», «традиціями») » та часинками). Виходить, що для цього випадку нам модель ядра не потрібна?
Насправді. Так, у разі побудова моделі ядра сховище сильно полегшується – т.к. ми слідуємо готової концептуальної моделі верхнього рівня. Але не виключається зовсім. Чому? Тому що при побудові моделі певної системи діють деякі свої правила - які типи таблиць використовувати (для кожної сутності), як версіонувати дані, з якою гранулярністю вести історію, які метаатрибути (технічні поля використовувати) і т.п.

Крім того, яка б чудова та всеохоплююча система НСІ та МДМ у нас не була – як правило, виникнуть нюанси, пов'язані з існуванням локальних довідників «про те саме» в інших облікових системах. І цю проблему, чи хочемо ми цього, чи ні – доведеться вирішувати на сховищі – адже звітність та аналітику збирати тут.

Шар первинних даних (або історизований staging або операційний шар)

Дані в цьому шарі зберігаються в структурах, максимально близьких до системи-джерела – щоб зберегти первинні дані якомога ближче до їхнього первозданного вигляду. Ще одна назва цього компонента – «операційний шар».
Чому б просто не використовувати усталений термін "staging"? Справа в тому, що раніше, до «епохи великих даних і VLDB», дисковий простір був дуже дорогим – і часто первинні дані якщо і зберігалися, то обмежений інтервал часу. І часто ім'ям “staging” називають очищуванийбуфер.
Тепер же технології зробили крок вперед - і ми можемо дозволити собі не тільки зберігати всі первинні дані, але історизувати їх з тим ступенем гранулярності, який тільки можливий. Не означає, що ми повинні контролювати зростання даних і скасовує необхідність управляти життєвим циклом інформації, оптимізуючи вартість зберігання даних, залежно від «температури» використання – тобто. виводячи «холодні дані», які менш потрібні, на більш дешеві носії та платформи зберігання.

Що нам дає наявність «історизованого стейджингу»:

• можливість помилитися (у структурах, алгоритмах трансформації, гранулярності ведення історії) – маючи первинні дані, що повністю історизуються, в зоні доступності для сховища, ми завжди можемо зробити перезавантаження наших таблиць;
• можливість подумати – ми можемо не поспішати з опрацюванням великого фрагмента ядра у цій ітерації розвитку сховища, т.к. у нашому стейджингу у будь-якому випадку будуть, причому з рівним тимчасовим горизонтом (крапка «відліку історії» буде одна);
• можливість аналізу – ми збережемо навіть ті дані, яких вже немає у джерелі – вони могли там затертися, поїхати до архіву тощо. – у нас вони залишаються доступними для аналізу;
• можливість інформаційного аудиту – завдяки максимально докладній первинній інформації ми зможемо потім розбиратися – як у нас працювало завантаження, що ми в результаті отримали такі цифри (для цього потрібно ще мати маркування мета-атрибутами та відповідні метадані, за якими працює завантаження – це вирішується на сервісному) шарі).

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

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

Шар аналітичних вітрин

Якщо споживачем є зовнішня система, то, як правило, вона диктує ті структури даних, які їй необхідні та регламенти забору інформації. Хорошим підходом вважається такий, за якого за коректний забір даних відповідає сам споживач. Сховище дані підготувало, сформувало вітрину, забезпечило можливість інкрементального забору даних (маркування мета-атрибутами для подальшого виділення дельти змін), а система-споживач далі сама керує та відповідає за те, як вона цією вітриною користується. Але бувають особливості: коли система не має активного компонента для забору даних - потрібен або зовнішній компонент, який виконає інтегруючу функцію, або сховище виступить у ролі "платформи інтеграції" - і забезпечить коректне інкрементальне відвантаження даних далі - за межі сховища. Тут спливає багато нюансів, і правила інтерфейсної взаємодії мають бути продумані та зрозумілі обом сторонам (втім, як завжди – коли це стосується інтеграції). До подібних вітрин зазвичай застосовується регламентне очищення/архівування даних (рідко потрібно, щоб ці «транзитні дані» зберігалися тривалий час).

Найбільше значення з погляду аналітичних завдань є вітрини «для людей» - точніше для інструментів BI, з якими вони працюють.
Втім, є категорія «особливо просунутих користувачів» – аналітики, дослідники даних – яким не потрібні ні BI-інструменти, ні регламентні процеси наповнення зовнішніх спеціалізованих систем. Їм потрібні деякі «загальні вітрини» і «своя пісочниця», де вони можуть створювати таблиці та трансформації на власний розсуд. У цьому випадку відповідальність сховища полягає у забезпеченні наповнення даними цих загальних вітрин у відповідність до регламенту.
Окремо можна назвати таких споживачів як засоби Data Mining – глибокого аналізу даних. Такі інструменти мають свої вимоги до перепідготовки даних, і з ними працюють експерти з дослідження даних. Для сховища завдання зводиться - знову ж таки до підтримки обслуговування по завантаженню деяких вітрин узгодженого формату.

Проте, повернемося до аналітичних вітрин. Саме вони становлять інтерес з погляду розробників-проектувальників сховища у цьому шарі даних.
На мою думку, найкращий підхід до проектування вітрин даних, перевірений часом, на який зараз «заточені» практично всі платформи BI – це підхід Ральфа Кімбалла. Він відомий під назвою dimensional modeling - Багатомірне моделювання. Існує безліч публікацій на цю тему. Наприклад, з основними правилами можна ознайомитись у публікації . І, звичайно ж, можна рекомендувати від гуру багатовимірного моделювання. Інший корисний ресурс – «Поради Кімбалла»
Багатомірний підхід до створення вітрин описаний і опрацьований настільки добре – як з боку «євангелістів методу», так і з боку провідних вендорів ПЗ, що немає сенсу тут якось докладно на ньому зупинятися – першоджерело завжди краще.

Хотілося б зробити лише один акцент. «Звітність та аналітика» буває різною. Є «важкий reporting» - попередньо замовлені звіти, які формуються у вигляді файлів і доставляються користувачам за передбаченими каналами доставки. А є інформаційні панелі – BI dashboards. По суті це web-додатки. І на час відгуку цих додатків пред'являються такі самі вимоги, як і будь-якого іншого web-додатка. Це означає, що нормальний час оновлення панелі BI – це секунди, а не хвилини. Важливо це пам'ятати розробки рішення. Як цього досягти? Стандартний метод оптимізації: дивимося, із чого складається час відгуку і що ми можемо впливати. На що найбільше витрачається час? На фізичні (дискові) читання БД, на передачу даних через мережу. Як зменшити обсяг даних, що зчитуються і передаються за один запит? Відповідь очевидна і проста: потрібно дані або агрегувати, або накласти фільтр на великі таблиці фактові таблиці, що беруть участь у запиті, і виключити з'єднання великих таблиць (звернення до фактових таблиць повинні йти тільки через вимірювання).

Навіщо потрібен BI? Чим він зручний? Чому ефективна багатовимірна модель?
BI дозволяє користувачеві виконувати так звані «нерегламентовані запити». Що це означає? Це означає, що ми запит заздалегідь точно не знаємо, але ми знаємо які показники в яких розрізах користувач може запросити. Користувач формує такий запит шляхом вибору відповідних фільтрів BI. І завдання розробника BI та проектувальника вітрин – забезпечити таку логіку роботи програми, щоб дані або фільтрувалися, або агрегувалися, не допускаючи ситуації, коли даних вимагається надто багато – і програма «повисала». Зазвичай починають з агрегованих цифр, далі заглиблюючись до детальніших даних, але попутно встановлюючи потрібні фільтри.

Не завжди достатньо просто побудувати «правильну зірку» – і отримати зручну структуру для BI. Іноді потрібно десь застосувати денормалізацію (оглядаючись при цьому, як це вплине на завантаження), а десь зробити вторинні вітрини та агрегати. Десь додати індекси чи проекції (залежно від СУБД).

Таким чином, шляхом “проб та помилок” можна отримати структуру, оптимальну для BI – яка врахує особливості як СУБД, так і BI-платформи, а також вимоги користувача щодо представлення даних.
Якщо ми дані ми беремо з «ядра», то така переробка вітрин матиме локальний характер, ніяк не впливаючи на складну обробку первинних даних, отриманих безпосередньо із систем-джерел – ми лише «перекладаємо» дані у зручний для BI формат. І можемо собі дозволити зробити це багато разів, у різний спосіб, у відповідність до різними вимогами. На даних ядра робити це набагато простіше і швидше, ніж збирати з «первинки» (структура та правила якої, як ми знаємо, до того ж може «плисти»).

Сервісний шар

До цього шару відносять дві області зберігання даних:

• область метаданих – використовується механізму управління завантаженням даних;
• область якості даних – для реалізації оф-лайн перевірок якості даних (тобто тих, що не вбудовані безпосередньо в процеси ETL).

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

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

Не ставлю завдання тут повністю висвітлити цю тему – організації завантаження – лише розставляю акценти, куди варто звернути увагу.
Наведений підхід – це лише один із варіантів. Він досить адаптивний. І його "концептуальним прототипом" послужив конвеєр Toyota і система "точно під час" (just-in-time). Тобто. ми тут відходимо від широко поширеної парадигми виключно «нічного завантаження даних», а завантажуємо невеликими порціями протягом дня – у міру готовності даних у різних джерелах: що прийшло – те й завантажили. При цьому у нас працює безліч паралельних процесів. А «гарячий хвіст» нових даних буде «моргати» - і через якийсь час вирівнюватися. Ми маємо врахувати таку особливість. І у разі потреби формувати користувацькі вітринами «зрізами», де все вже цілісне. Тобто. не можна одночасно досягти і оперативності, і консистентності (цілісності). Потрібен баланс – десь важливе одне, десь інше.

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

Проектування та ведення моделей даних сховища

Чи можна розібратися без моделі? В принципі можна. І розібратися, і «прикинути картинки на папірці», і «пошерстити – поселити» дані. Але набагато простіше, зрозуміліше і швидше користуватися готовим артефактом – моделлю даних. А також розуміти "логіку її влаштування" - тобто. добре б мати загальні правила гри.

А найголовніше, навіть не це. Найголовніше, що при проектуванні моделі ми змушені (просто без варіантів!) щільніше і глибоко вивчити предметну область, особливості пристрою даних та їх використання у різних бізнес-кейсах. І ті питання, які б ми з легкістю "відсунули" як складні, "замилили", накидаючи наші таблички, не намагаючись при цьому саме проектуватимодель - ми будемо змушені поставити і вирішувати зараз, при аналізі та проектуванні, а не потім - коли будуватимемо звіти і думати про те, «як звести несумісне» і щоразу «винаходити велосипед».

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

Проектування моделей даних – це окрема, дуже велика тема. При проектуванні сховищ використовуються два основних підходи.
Для ядра добре підходить підхід «сутність-зв'язок» - коли будується нормалізована (3NF) модель з урахуванням саме дослідження предметної області, точніше виділеної її області. Тут грає та сама «корпоративна модель», про яку йшлося вище.

При проектуванні аналітичних вітрин підходить багатовимірна модель . Цей підхід добре лягає розуміння бізнес-користувачів – т.к. це модель, проста і зручна для людського сприйняття – люди оперують зрозумілими та звичними поняттями метрик (показників) та розрізів, за якими вони аналізуються. І це дозволяє просто і чітко побудувати процес збору вимог – ми малюємо набір «матриць розрізів та показників», спілкуючись із представниками різних підрозділів. А потім зводимо в одну структуру - "модель аналізу": формуємо "шину вимірювань" і визначаємо факти, які на них визначені. Попутно опрацьовуємо ієрархії та правила агрегації.

Далі дуже просто перейти до фізичної моделі, додавши елементи оптимізації з урахуванням особливостей СУБД Наприклад, для Oracle це буде секціонування, набір індексів тощо. Для Vertica буде використано інші прийоми – сортування, сегментація, секціонування.
Також може бути потрібна спеціальна денормалізація - коли ми свідомо вносимо надмірність у дані, завдяки яким покращуємо швидкодію запитів, але при цьому ускладнюємо оновлення даних (бо надмірність потрібно буде враховувати і підтримувати в процесі завантаження даних). Можливо, для поліпшення швидкодії, нам також доведеться створити додаткові таблиці-агрегати, або використовувати такі додаткові можливості СУБД як проекції в Vertica.

Отже, під час моделювання даних сховища ми фактично вирішуємо кілька завдань:

• завдання побудова концептуальної (логічної) моделі ядра - системний та бізнес-аналіз - дослідження предметної галузі, заглиблення в деталі та облік нюансів «живих даних» та їх використання у бізнесі;
• завдання побудови моделі аналізу – і надалі концептуальної (логічної) моделі вітрин;
• Завдання побудови фізичних моделей - управління надмірністю даних, оптимізація з урахуванням особливостей СУБД під запити та завантаження даних.

Резюмуємо.

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

Особливості проектів сховищ даних

Сховище даних – це замовлення ПЗ

Сховище даних – це інтеграційний проект

Сховище даних – це колективний проект

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

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

Сховище даних має більший термін життя в порівнянні з іншими системами

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

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

Поступовий ітеративний розвиток

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

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

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

Сховища даних – «мульти-проектна історія»

Баланс інновацій та перевірених рішень

Подивимося на СУБД – як найбільш критичну та важливу для сховищ технологічну платформу.
Останнім часом явно намітився дрейф реляційних баз даних, створених спочатку як «універсальних» у бік спеціалізації. Вже давно провідні вендори випускають різні опції – для програм різного класу (OLTP, DSS & DWH). Крім того, з'являються додаткові можливості для роботи з текстом, геоданими і т.д.

Але цим справа не обмежилася - стали з'являтися продукти, які спочатку орієнтовані певний клас завдань – тобто. спеціалізовані СУБД. Вони можуть використовувати реляційну модель, а можуть і ні. Важливо те, що вони спочатку «заточені» не просто на зберігання та обробку «бізнесу інформації» в цілому, а під певні завдання.

Мабуть, централізація та спеціалізація – це два взаємодоповнюючі тренди, які періодично змінюють один одного, забезпечуючи розвиток та баланс. Так само як і еволюційний (поступовий) поступовий розвиток та кардинальні зміни. Так, у 90-х роках Майкл Стоунбрейкер був одним із авторів Маніфесту баз даних III покоління, в якому чітко звучала думка, що світові не потрібна ще одна революція у світі баз даних. Однак через 10 років він публікує роботи, в яких анонсує передумови початку нової ериу світі СУБД - саме виходячи з їхньої спеціалізації.
Він наголошує на тому, що поширені універсальні СУБД побудовані на «безрозмірній» (one-size-fits-all) архітектурі, яка не враховує ні змін апаратних платформ, ні поділу додатків на класи, для яких можна придумати більш оптимальне рішення, ніж реалізуючи Універсальні вимоги.
І починає розвивати низку проектів у відповідність із цією ідеєю. Один з яких – C-Store – колонкова СУБД, спроектована в архітектурі shared nothing (SN), спочатку створена спеціально для систем класу сховищ даних. Далі цей продукт отримав комерційний розвиток як HP Vertica.

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

Епілог

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

"Унікальність антикрихкості полягає в тому, що вона дозволяє нам працювати з невідомістю, робити щось в умовах, коли ми не розуміємо, що саме робимо, - і досягати успіху"/Нассім Н.Талеб/

Галузеві моделі даних

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

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

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

Як правило, виділяються моделі вищого рівня (і більш загальні за змістом) та нижчого (відповідно, більш детальні). Верхній рівень моделювання – це так звані концептуальні моделі даних(conceptual data models), які дають загальну картину функціонування підприємства чи організації. Концептуальна модель включає основні концепції чи предметні галузі, критичні для функціонування організації; зазвичай їх кількість вбирається у 12-15. Така модель описує класи сутностей, важливих для організації (бізнес-об'єкти), їх характеристики (атрибути) та асоціації між парами цих класів (тобто зв'язку). Оскільки в бізнес-моделюванні термінологія ще остаточно не встояла, у різних англомовних джерелах концептуальні моделі даних можуть також називатися subject area model (що можна перевести як моделі предметних областей) або subject enterprise data model (предметні корпоративні моделі даних).

Наступний ієрархічний рівень – це логічні моделі даних(logical data models). Вони також можуть називатися корпоративними моделями даних або бізнес-моделями. Ці моделі містять структури даних, їхні атрибути та бізнес-правила та надають інформацію, яку використовує підприємство, з погляду бізнес-перспективи. У такій моделі дані організовані у вигляді сутностей та зв'язків між ними. Логічна модель представляє дані в такий спосіб, що вони легко сприймаються бізнес-користувачами. У логічній моделі може бути виділено словник даних – перелік всіх сутностей з їх точними визначеннями, що дозволяє різним категоріям користувачів мати загальне розуміння всіх вхідних та інформаційних вихідних потоків моделі. Наступний нижчий рівень моделювання – це вже фізична реалізація логічної моделі за допомогою конкретних програмних засобів та технічних платформ.

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

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

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

Компанія може мати два шляхи створення корпоративної логічної моделі даних: будувати її самостійно або скористатися готовою галузевою моделлю(industry logical data model). У разі відмінності у термінах відбивають лише різні підходи до побудови однієї й тієї ж логічної моделі. У тому випадку, якщо компанія самостійно розробляє та впроваджує власну логічну модель даних, то така модель, як правило, має назву просто корпоративної логічної моделі. Якщо ж організація вирішує користуватися готовим продуктом професійного постачальника, тоді можна говорити про галузевій логічної моделі даних. Остання є готовою логічну модель даних, з високим ступенем точності, що відображає функціонування певної галузі. Галузева логічна модель – це предметно-орієнтований та інтегрований вид усієї інформації, яка має знаходитись у корпоративному Сховищі даних для отримання відповідей як на стратегічні, так і на тактичні бізнес-питання. Як і будь-яка інша логічна модель даних, галузева модель залежить від прикладних рішень. Вона також не включає похідні дані або інші обчислення для швидшого вилучення даних. Як правило, більшість логічних структур такої моделі знаходять гарне втілення у її ефективній фізичній реалізації. Такі моделі розробляються багатьма постачальниками для різних галузей діяльності: фінансової сфери, виробництва, туризму, охорони здоров'я, страхування і т.д.

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

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

Спеціаліст у галузі бізнес-аналітики (Business Intelligence) Стів Хобермен (Steve Hoberman) виділяє п'ять факторів, які необхідно брати до уваги при вирішенні питання про придбання галузевої моделі даних. Перший – це час та засоби, необхідні для побудови моделі. Якщо організації необхідно швидко досягти результатів, то галузева модель надасть перевагу. Використання галузевої моделі не може негайно забезпечити картину всієї організації, але здатне заощадити значну кількість часу. Замість власне моделювання час буде витрачено на зв'язування існуючих структур з галузевою моделлю, а також на обговорення того, як краще налаштувати її під потреби організації (наприклад, які визначення мають бути змінені, а які елементи даних – додані).

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

Третій фактор – досвід в оцінці ризиків та моделюванні. Створення корпоративної моделі даних потребує кваліфікованих ресурсів як із боку бізнесу, і IT-персоналу. Як правило, менеджери добре знають або роботу організації загалом, або діяльність конкретного відділу. Лише деякі з них мають як широкі (у масштабах всієї компанії), так і глибокі (у рамках підрозділів) знання про свій бізнес. Більшість менеджерів зазвичай добре знають лише одну область. Тому для того, щоб отримати загальнокорпоративну картину, потрібні істотні бізнес-ресурси. Це збільшує вимоги до IT-персоналу. Чим більше бізнес-ресурсів потрібно для створення та тестування моделі, тим більш досвідченими мають бути аналітики. Вони повинні не тільки знати, як отримати інформацію від бізнес-персоналу, але також вміти знаходити загальну точку зору в спірних галузях та бути здатними подавати всю цю інформацію в інтегрованому вигляді. Той, хто займається створенням моделі (у багатьох випадках це той же аналітик), повинен мати гарні навички моделювання. Створення корпоративних логічних моделей вимагає моделювання «для майбутнього» та здатності конвертувати складний бізнес у буквальному значенні «в квадрати та лінії».

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

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

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

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

Галузеві моделі даних забезпечують компаніям єдине інтегроване уявлення про їх бізнес-інформацію. Багатьом компаніям буває непросто здійснити інтеграцію своїх даних, хоча це є необхідною умовоюбільшість загальнокорпоративних проектів. За даними дослідження Інституту Сховищ даних (The Data Warehousing Institute, TDWI), понад 69% опитаних організацій виявили, що інтеграція є істотним бар'єром під час впровадження нових додатків. Навпаки, здійснення інтеграції даних приносить компанії суттєвий дохід.

Галузева модель даних, окрім зв'язків із вже існуючими системами, дає великі переваги при здійсненні загальнокорпоративних проектів, таких як планування ресурсів підприємства (Enterprise Resource Planning, ERP), управління основними даними, бізнес-аналітика, підвищення якості даних та підвищення кваліфікації працівників.

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

Публікації

1. Стів Хобермен (Steve Hoberman). Використання галузевої логічної моделі даних як корпоративної моделі.
2. Клодіа Імхоф (Claudia Imhoff). Оперативне створення Сховищ даних та виконання проектів Business Intelligence за допомогою моделювання даних (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Корпоративна база даних є центральною ланкою корпоративної інформаційної системи та дозволяє створити єдине інформаційний простіркорпорації. Корпоративні бази даних

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

PAGE 15

ТЕМА V. КОРПОРАТИВНІ БАЗИ ДАНИХ

лекція 8

V .1. Організація даних у корпоративних системах. Корпоративні бази даних

V .2. СУБД та структурні рішення у корпоративних системах.

V.3. Технології Internet / Intranet та корпоративні рішення щодо доступу до баз даних.

V .1. ОРГАНІЗАЦІЯ ДАНИХ У КОРПОРАТИВНИХ СИСТЕМАХ. КОРПОРАТИВНІ БАЗИ ДАНИХ

Корпоративна базаданих є центральною ланкою корпоративної інформаційної системи та дозволяє створити єдиний інформаційний простір корпорації. Корпоративні бази даних (рис.1.1).

Існують різні визначення баз даних.

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

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

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

Мета створення баз данихяк форми зберігання даних побудова системи даних, що не залежать від прийнятих алгоритмів (програмного забезпечення), застосовуваних технічних засобів, фізичного розташуванняданих в ЕОМ. База даних передбачає багатоцільове використання (кілька користувачів, безліч форм документів та запитів одного користувача).

Основні вимоги до баз даних:

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

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

База знань (БЗ)  сукупність баз даних та використовуваних правил, отриманих від осіб, що приймають рішення. База знань є елементом експертних систем.

Слід розрізнятирізні способи представлення даних.

Фізичні дані –це дані, що зберігаються у пам'яті ЕОМ.

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

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

Рис. 1.1. Структура взаємодії підрозділів із інформаційними ресурсами корпорації.

Корпоративні бази даних буваютьзосереджені (централізовані) та розподілені .

Зосереджена (централізована)база даних - це база даних, дані якої фізично зберігається в пристроїв однієї обчислювальної машини. На рис. 1.2 представлена ​​схема серверної програмидля доступу до баз даних у різних платформах.

Рис.1.2. Схема гетерогенної централізованої бази даних

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

• Великий потік обміну даними;
• Високий трафік у мережі;
• Низька надійність;
• Низька загальна продуктивність.

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

• Вищий ступінь одночасності обробки внаслідок розподілу навантаження;
• Поліпшення використання даних на місцях під час виконання віддалених (дистанційних) запитів;
• Найменші витрати;
• Простота керування локальними базами.

Витрати створення мережі, у вузлах якої перебувають робочі станції (малі ЕОМ), набагато нижчі, ніж витрати на створення аналогічної системи з використанням великої ЕОМ. На Рис.1.3 наведена логічна схема розподіленої бази даних.

Рис.1.3. розподілена база даних корпорації.

Дамо наступне визначення розподіленої бази даних.

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

Найважливішими вимогами до характеристик розподіленої бази даних є:

• Масштабованість;
• Сумісність;
• Підтримка різних моделей даних;
• Перенесення;
• Прозорість розташування;
• Автономність вузлів розподіленої бази даних (Site Autonomy);
• обробка розподілених запитів;
• Виконує розподілені транзакції.
• Підтримка однорідної системи безпеки.

Прозорість розташування дозволяє користувачам працювати з базами даних, не знаючи нічого про їхнє розташування. Автономність вузлів розподіленої бази даних означає, що ведення кожної бази може відбуватися незалежно від інших. Розподілений запит - це такий запит (SQL-пропозиція), під час виконання якого відбувається доступ до об'єктів (таблиць або уявлень) різних баз даних. За виконання розподілених транзакцій здійснюється узгоджене управління (concurrency control) усіма залученими базами даних. Oracle7 використовує технологію двофазної передачі для виконання розподілених транзакцій.

Бази даних, що становлять розподілену базу даних, не обов'язково повинні бути однорідними (тобто вестися однією СУБД) або оброблятися в середовищі однієї і тієї ж операційної системи та/або на комп'ютерах одного типу. Наприклад, одна база даних може бути базою Oracle на комп'ютері SUN з операційною системою SUN OS(UNIX), друга база даних може вестися СУБД DB2 на мейнфреймі IBM 3090 з операційною системою MVS, а для ведення третьої бази може використовуватися СУБД SQL/DS також на мейнфрейме IBM, але з операційною системою VM. Обов'язково тільки одна умова - всі машини з базами даних повинні бути доступні через мережу, в яку вони входять.

Основне завдання розподіленої бази даних– розподіл даних через мережу та забезпечення доступу до неї. Існують такі способи вирішення цього завдання:

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

Під час створення розподіленої бази даних на концептуальному рівні доводиться вирішувати такі завдання:

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

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

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

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

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

Інформаційні сховищаСьогодні багато хто визнає, що вже зараз у більшості компаній експлуатується кілька БД і для успішної роботи з інформацією потрібні не просто різнотипні бази даних, а різні покоління СУБД. Згідно зі статистикою, у кожній організації використовують у середньому 2,5 різних СУБД. Стала очевидною необхідність "ізолювати" бізнес компаній, вірніше людей, що займаються цим бізнесом, від технологічних особливостей баз даних, надати користувачам єдиний погляд на корпоративну інформацію незалежно від того, де вона фізично зберігається. Це стимулювало появу технології інформаційних сховищ ( Data Warehousing, DW).

Основна мета DW -створення єдиного логічного уявлення даних, які у різнотипних БД, чи, іншими словами, єдиної моделі корпоративних даних.

Новий виток розвитку DW став можливим завдяки вдосконаленню інформаційних технологійзагалом, зокрема появі нових типів баз даних на основі паралельної обробки запитів, що у свою чергу спиралися на досягнення у галузі паралельних комп'ютерів. Були створеніпрограми-конструктори запитівз інтуїтивним графічним інтерфейсом, що дозволили легко будувати складні запити до БД Різноманітне ПЗпроміжного шару (midleware)забезпечило зв'язокміж різнотипними базами даних, і, нарешті, різко подешевшалипристрої зберігання інформації.

У структурі корпорації може бути присутнімбанк даних.

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

Банк даних розглядають як інформаційно-довідкову систему, основне призначення якої полягає:

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

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

V .2. СУБД І СТРУКТУРНІ РІШЕННЯ У КОРПОРАТИВНИХ СИСТЕМАХ

Системи управління базами даних та знань

Важливою складовою сучасних інформаційних систем є системи управління базами даних (СУБД).

СУБД - Комплекс програмних та мовних засобів, призначених для створення, ведення та використання баз даних.

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

Основна особливість сучасних СУБД - те, що сучасні СУБД підтримують такітехнології як:

• Технологію клієнт/сервер.
• Підтримка мов БД. Цемова визначення схемиБД (SDL - Schema Definition Language),мова маніпулювання даними (DML - Data Manipulation Language), інтегровані мови SQL (Structured Queue Language), QDB (Query - By - Example) і QMF (Query Management Facility ) – розвинений периферійний засіб специфікації запитів та генерації звітів для DB 2 і т. д.;
• Безпосереднє керування даними у зовнішній пам'яті.
• Управління буферами оперативної пам'яті.
• Управління транзакціями. OLTP – технологія (On-Line Transaction Processing), OLAP –технологія (On-Line Analysis Processing)для DW.
• Забезпечити захист та цілісність даних. Використання системи дозволяється лише користувачам, які мають право доступу до даних. При виконанні користувачами операцій над даними підтримується узгодженість даних, що зберігаються (цілісність). Це важливо в корпоративних розрахованих на багато користувачів інформаційних системах.
• Журналізація.

Сучасні СУБД повинні забезпечувати виконання вимог до баз даних, наведених вище. Крім цього вони повинні відповідати наступним принципам:

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

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

• їх можливостей стосовно розподілених (корпоративних) баз;
• їх ставлення до типу моделі даних, що реалізується в СУБД.

По відношенню до корпоративних (розподілених) баз даних умовно можна виділити такі типи СУБД:

• СУБД "робочого столу". Ці продукти, в першу чергу, орієнтовані на роботу з персональними даними (дані "робочого столу"). Вони мають набори команд спільного використання загальних БД, але невеликого розміру (типу малого офісу). Насамперед, це СУБД типу Ассеss, dВАSЕ, Рагаdох, ЕохРго. Чому Ассеss, dВАSЕ, Рагаdох, ЕохРго мають незадовільний доступ до корпоративних даних. Справа в тому, що не існує простого способу подолати бар'єр між персональними та корпоративними даними. І суть навіть не в тому, що механізм СУБД персональних даних (або малого офісу) орієнтований на доступ до даних через багато шлюзів, міжмережевих продуктів і т.д. Проблема полягає в тому, що ці механізми пов'язані з повною передачею файлів і відсутністю розгалуженої підтримки індексів, внаслідок чого черги до сервера практично зупиняють роботу у великих системах.
• Спеціалізовані високопродуктивні розраховані на багато користувачів СУБД. Такі СУБД характеризуються наявністю розрахованого на багато користувачів ядра системи, мови маніпулювання даними та наступними функціями, характерними для розвинених розрахованих на багато користувачів СУБД:
• організацією буферного пулу;
• наявністю системи обробки черг транзакцій;
• наявністю механізмів розрахованого на багато користувачів блокування даних;
• веденням журналу транзакцій;
• наявністю механізмів розмежування доступу.

Це СУБД типу Oracle, DВ2, SQL/Server, Informix, Sybase, ADABAS, Titanium та інші надають широкий сервіс обробки корпоративних БД.

Під час роботи з базами даних використовується механізм транзакцій.

Транзакція - Це логічна одиниця роботи.

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

Транзакція має чотири важливі властивості, відомі яквластивості АСІД:

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

Транзакція зазвичай починається автоматично з моменту приєднання користувача до СУБД і продовжується доти, доки не відбудеться одна з наступних подій:

• Подано команду COMMIT WORK (зафіксувати транзакцію).
• Подано команду ROLLBACK WORK (відкотити транзакцію).
• Відбулося від'єднання користувача від СУБД.
• Стався збій системи.

Для користувача вона носить, як правило,атомарний характер. Насправді це складний механізм взаємодії (додаток) – база даних. Програмне забезпечення корпоративних систем використовують механізм обробки транзакцій у реальному часі (Online Transaction Processing Systems, OLTP), зокрема програми бухгалтерського обліку, програмне забезпеченняприйому та обробки клієнтських заявок, фінансові програми, виробляють масу інформації. Ці системи розраховані (і відповідним чином оптимізовані) на обробку великих обсягів даних, виконання складних транзакцій та інтенсивних операцій читання/запису.

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

Доставкою інформації кінцевому користувачеві - займаються системи аналітичної обробки даних у реальному часі(On-line Analytical Processing, OLAP), Які забезпечують виключно простий доступ до даних за рахунок зручних засобів генерації запитів та аналізу результатів. В OLAP-системах цінність інформаційного товару збільшується завдяки застосуванню різноманітних методів аналізу та статистичної обробки. Крім того, ці системи оптимізовані з точки зору швидкості вилучення даних, збору узагальненої інформації та орієнтовані на пересічних користувачів (мають інтуїтивно зрозумілий інтерфейс). Якщо OLTP-система видає відповіді на прості питання типу "який був рівень продажу товару N у регіоні M у січні 199х р.?", то OLAP-системи готові до більш складним запитамкористувачів, наприклад: "Дати аналіз продажу товару N по всіх регіонах за планом на другий квартал у порівнянні з двома попередніми роками".

Архітектура клієнт/сервер

У сучасних системахрозподіленої обробки інформації, центральне місце займають технологіїклієнт/сервер. В системі архітектури клієнт-серверобробка даних розділена між комп'ютером-клієнтом та комп'ютером-сервером, зв'язок між якими відбувається через мережу. Цей поділ процесів обробки даних ґрунтується на групуванні функцій. Як правило, комп'ютер-сервер баз даних виділяється для виконання операцій з базами даних, а комп'ютер-клієнт виконує прикладні програми. На малюнку 2.1 показано проста системаархітектури клієнт-сервер, до складу якої входять комп'ютер, що діє як сервер, та інший комп'ютер, що діє як його клієнт. Кожна машина виконує різні функції та має власні ресурси.

Рис. 2.1. Система архітектури клієнт-сервер

Основна функція комп'ютера-клієнта полягає у виконанні програми (інтерфейсу з користувачем та логіки уявлення) та здійсненні зв'язку з сервером, коли цього вимагає програма.

Сервер (Server) – це об'єкт (ЕОМ), що надає послуги іншим об'єктам на їх запит.

Як випливає вже з терміну, головна функція комп'ютера-сервера полягає в обслуговуванні потреб клієнта. Термін "Сервер" використовується для позначення двох різних груп функцій: файл-сервер та сервер баз даних (далі ці терміни означають залежно від контексту або програмне забезпечення, що реалізує зазначені групи функцій, або комп'ютери з цим програмним забезпеченням). Файл-сервери призначені до виконання операцій із базами даних, їх основна функція - поділ файлів між кількома користувачами, тобто. забезпечення одночасного доступу багатьох користувачів до файлів на комп'ютері – файл-сервері. Приклад файл-сервера є операційна система NetWare компанії Novell. Сервер баз даних можна встановити та привести в дію на комп'ютері - файл-сервері. СУБД Oracle у вигляді NLM (Network Loadable Module) виконується серед NetWare на файл-сервері.

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

Одна з важливих вимог до сервера - це те, що операційна система, в середовищі якої розміщено сервер баз даних, повинна бути багатозадачною (і, бажано, але не обов'язково, розраховано на багато користувачів). Наприклад, СУБД Oracle, встановлена ​​на персональному комп'ютері з операційною системою MS-DOS (або PC-DOS), що не відповідає вимогам багатозадачності, не може використовуватися як сервер баз даних. І та ж СУБД Oracle, встановлена ​​на комп'ютері з багатозадачною (хоч і не багатокористувацькою) операційною системою OS/2, може бути сервером баз даних. Багато різновидів систем UNIX, MVS, VM та деякі інші Операційні системиє і багатозадачними, і розрахованими на багато користувачів.

Розподілені обчислення

Термін "розподілені обчислення" часто використовується для позначення двох різних, хоч і взаємододаткових концепцій:

• розподілена база даних;
• Розподілена обробка даних.

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

Існує багато типів серверів:

• сервер баз даних;
• Сервер печатки;
• Сервер віддаленого доступу;
• Факс-сервер;
• Web-сервер і т.д.

В основі базової технології Клієнт/серверлежать такі базові технології, як:

• Технології операційних систем; концепція взаємодії відкритих систем; створення об'єктно-орієнтованих середовищ функціонування програм;
• Телекомунікаційні технології;
• Мережеві технології;
• Технології графічного інтерфейсу користувача ( GUI);
• І т.д.

Переваги технології клієнт-сервер:

• Технологія клієнт/сервер дозволяє проводити обчислення на неоднорідних обчислювальних середовищах. Незалежність від платформ: доступ до різноманітних мережних середовищ, до складу яких входять комп'ютери різних типів із різними операційними системами.
• Незалежність джерел даних: доступ до інформації різнорідних баз даних. Приклади таких систем – DB2, SQL/DS, Oracle, Sybase.
• Баланс завантаження клієнта та сервера.
• Виконання обчислень там, де це відбувається найефективніше;
• Надають можливість ефективного масштабування;
• Міжплатформні обчислення. Міжплатформні обчислення визначаються просто як реалізація технологій у неоднорідних обчислювальних середовищах. Тут мають бути забезпечені такі можливості:
• Програма повинна виконуватись на декількох платформах;
• На всіх платформах воно повинно мати той самий інтерфейс і логіку роботи;
• Додаток має інтегруватися з рідною операційним середовищем;
• Воно має однаково поводитися на всіх платформах;
• Для нього має передбачатися проста та узгоджена підтримка.

 Розподілені обчислення. Розподілені обчислення передбачають розподіл робіт між декількома обчислювальними машинами (щоправда, розподілені обчислення більш широке поняття).

 Розукрупнення. Розукрупнення – перенесення додатків великих ЕОМ на малі комп'ютерні платформи.

• Зниження витрат на інфраструктуру та апаратні засоби. Економічність: доступність недорогого комп'ютерного обладнання і все більшого поширення локальних мереж роблять технологію клієнт-сервер економічнішою за інші технології обробки даних. Обладнання може бути модернізовано, щойно виникне потреба.

 Скорочення загального часу виконання програми;

 Зменшення використання клієнтом пам'яті;

 Скорочення мережного трафіку.

• Можливість роботи з мультимедіа: на сьогодні створено чимало програм роботи з мультимедіа для ПК. Подібних програмДля зміни термінал-хост або ні, або вони дуже дорогі.
• Можливість залучення великих обчислювальних ресурсів для операцій з базами даних: оскільки програми виконуються на комп'ютерах-клієнтах, на комп'ютері-сервері для операцій з базами даних вивільняються додаткові (порівняно з конфігурацією термінал-хост) ресурси, такі як обчислювальні ресурси центрального процесора та оперативна пам'ять.
• Вища продуктивність роботи програмістів: продуктивність праці програмістів зростає завдяки використанню таких засобів, як SQL*Forms і CASE: вони дозволяють розробляти програми швидше, ніж такі мови програмування, як C, PL1 чи COBOL.
• Підвищення продуктивності роботи кінцевих користувачів: в даний час багато кінцевих користувачів освоїли такі системи, як Lotus, Paradox, Word Perfect, Harvard Graphics і т.д.

Інтерфейс серверної частини визначено та фіксовано. Тому можливе створення нових клієнтських частин існуючої системи(Приклад інтероперабельності на системному рівні).

Рис. 2.2. Ілюстрація доступу клієнтів до спільного ресурсу сервера.

Як впровадити технологію клієнт-сервер

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

• комп'ютер-сервер бази даних;
• комп'ютери-клієнтів;
• комунікаційна мережа;
• мережеве програмне забезпечення;
• прикладне програмне забезпечення.

Мова SQL . Мова запитів високого рівня - SQL (Structured Query Language ) служить для реалізації запитів до баз даних, таких як ЯМД, ЯОД та ПЯД і прийнятий як стандарт. Мова SQL спочатку був прийнятий як мова даних програмних виробів фірми IBM та ЯМД реляційної СУБД SYSTEM R фірми IBM . Важливою особливістю мови SQL полягає в тому, що та сама мова представляється через два різні інтерфейси, а саме: через інтерактивний інтерфейс і через інтерфейс прикладного програмування (динамічний SQL). Динамічний SQL складається з безлічі можливостей вбудованої мови SQL , передбачених спеціально для конструювання інтерактивних додатків, де під інтерактивним додатком розуміється програма, написана для підтримки звернення до бази даних кінцевого користувача, що працює на інтерактивному терміналі. Мова SQL забезпечує виконання функцій визначення, маніпулювання та управління даними баз даних та є прозорим для користувача з точки зору реалізованої СУБД.

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

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

Модель даних складається із трьох компонентів:

• Структура даних подання з погляду користувача на базу даних.
• Допустимі операції, що виконуються на структурі даних. Потрібно мати можливість працювати з цією структурою за допомогою різних операцій ЯОД та ЯМД. Багата структура нічого не варта, якщо немає можливості оперувати її вмістом.
• Обмеження контролю цілісності. Модель даних має бути забезпечена засобами, що дозволяють зберігати її цілісність та захищати її. Як приклад розглянемо два наступні обмеження:
• Кожне поддерево повинно мати вихідний вузол. У ієрархічних базах даних можна зберігати породжені вузли без вихідного вузла.
• Щодо реляційної бази даних може бути однакових кортежів. Для файлу ця вимога потребує унікальності всіх записів.

Однією з найважливіших параметрів роботи СУБД є можливість пов'язувати об'єкти.

Існують такі види зв'язків між об'єктами:

• Один до одного (1:1). Один об'єкт однієї множини може бути пов'язаний з одним об'єктом іншої множини.
• Один-до-багатьом (1:M). Один об'єкт однієї множини може бути пов'язаний з багатьма об'єктами іншої множини.
• Багато хто до багатьох (M:N). Один об'єкт однієї множини може бути пов'язаний з багатьма об'єктами іншої множини, але при цьому один об'єкт іншої множини може бути пов'язаний з багатьма об'єктами першої множини.
• Розгалужена . Один об'єкт однієї множини може бути пов'язаний з об'єктами багатьох множин.
• Рекурсивна . Один об'єкт даної множиниможе бути пов'язаний об'єктом цієї ж множини.

Існують такі основні моделі даних:

• Реляційна модельданих.
• Ієрархічна модель даних.
• Неповна мережна модель даних.
• Модель даних CODASYL.
• Розширена мережева модель даних.

V.3. ТЕХНОЛОГІЇ INTERNET/INTRANET І КОРПОРАТИВНІ РІШЕННЯ ЗА ДОСТУПОМ ДО БАЗІВ ДАНИХ

Основною проблемою систем, заснованих на архітектурі "клієнт-сервер", є те, що відповідно до концепції відкритих систем від них потрібна мобільність у якомога ширшому класі апаратно-програмних рішень відкритих систем. Навіть якщо обмежитися UNIX-орієнтованими локальними мережами, у різних мережах застосовується різна апаратура та протоколи зв'язку. Спроби створення систем, що підтримують всі можливі протоколи, призводить до їх перевантаження мережевими деталями на шкоду функціональності.

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

Загальним рішенням проблеми мобільності систем, заснованих на архітектурі "клієнт-сервер", є опора на програмні пакети, що реалізують протоколи віддаленого виклику процедур (RPC - Remote Procedure Call). При використанні таких засобів звернення до сервісу у віддаленому вузлі має вигляд звичайного виклику процедури. Засоби RPC, у яких, природно, міститься вся інформація про специфіку апаратури локальної мережі та мережевих протоколів, переводить виклик у послідовність мережевих взаємодій. Тим самим, специфіка мережного середовища та протоколів прихована від прикладного програміста.

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

У цій статті йдеться про архітектуру сховищ даних. Чим керуватися за її побудові, які підходи працюють – і чому.

"Казка брехня - та в ній натяк ..."

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

Розбір польотів

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

1. У принципі, у нас непогане сховище: якщо не чіпати – все працює. Щоправда, щойно потрібно внести зміну – починаються «локальні обвали».
2. Дані завантажуються щодня, за регламентом, у межах великого процесу, протягом 8ч. І нас це влаштовує. Але якщо раптом виникає збій, це вимагає ручного втручання. І далі може працювати непередбачено довго, т.к. потрібна участь людини в процесі.
3. Накотили реліз – чекай на проблеми.
4. Якесь одне джерело не змогло вчасно віддати дані – чекають на всі процеси.
5. Цілісність даних контролює база даних – тому наші процеси падають помилково, коли вона порушується.
6. У нас дуже велике сховище – 2000 таблиць в одній спільній схемі. І ще 3000 у безлічі інших схем. Ми вже слабо уявляємо, як вони влаштовані та з якого приводу з'явилися. Тому нам буває складно щось перевикористати. І доводиться багато завдань вирішувати наново. Оскільки так простіше і швидше (ніж розбиратися «в чужому коді»). У результаті маємо розбіжності і функціонал, що дублюється.
7. Ми очікуємо, що джерело даватиме якісні дані. Але виявляється, що це негаразд. У результаті багато часу витрачаємо на вивірку своїх фінальних звітів. І дуже в цьому досягли успіху. У нас навіть є налагоджений процес. Щоправда, це триває час. Але користувачі звикли.
8. Користувач не завжди довіряє нашим звітам та вимагає обґрунтування тієї чи іншої цифри. У якихось випадках він має рацію, а в якихось ні. Але дуже складно їх доводити, т.к. у нас не передбачено засобів "наскрізного аналізу" (або data lineage).
9. Ми могли б залучити додаткових розробників. Але ж у нас проблема – як нам включити їх у роботу? Як найефективніше розпаралелити роботи?
10. Як розвивати систему поступово, не вдаючись у розробку «ядра системи» на цілий рік?
11. Сховище даних асоціюється із корпоративною моделлю. Але ми точно знаємо (бачили у банку XYZ), що будувати модель можна нескінченно довго (у банку XYZ шість місяців ходили та обговорювали бізнес-сутності, без будь-якого руху). А навіщо вона загалом? Чи, може, краще без неї, якщо з нею стільки проблем? Може її взагалі якось згенерувати?
12. Ми вирішили вести модель. Але як системно розвивати модель даних сховища? Чи потрібні нам правила гри і які вони можуть бути? Що це нам дасть? А якщо ми помилимося з моделлю?
13. Чи маємо ми зберігати дані, або історію їхніх змін, якщо «бізнесу вони не потрібні»? Не хотілося б «зберігати сміття» та ускладнювати використання цих даних для реальних завдань. Чи сховища збережуть історію? Яка вона буває? Як сховище працює з часом?
14. Чи потрібно намагатися уніфікувати дані на сховищі, якщо ми маємо систему управління НСІ? Якщо є МДМ, чи це означає, що тепер вся проблема з майстер-даними вирішена?
15. У нас незабаром очікується заміна ключових облікових систем. Чи сховище даних має бути готовим до зміни джерела? Як цього досягти?
16. Чи потрібні нам метадані? Що під цим розумітимемо? Де вони можуть бути використані? Як можна продати? Чи потрібно їх зберігати «в одному місці»?
17. Наші Замовники украй не стабільні у своїх вимогах та бажаннях – постійно щось змінюється. У нас взагалі бізнес дуже динамічний. Поки що ми щось робимо – це вже стає непотрібним. Як нам зробити так, щоб видавати результат максимально швидко – як гарячі пиріжки?
18. Користувачі потребують оперативності. Але ми можемо наші основні процеси завантаження запускати часто, т.к. це навантажує системи-джерела (погано позначається на продуктивності) – тому ми вішаємо додаткові потоки даних – які будуть забирати точково – те, що нам потрібно. Щоправда, виходить багато потоків. І частину даних ми потім викинемо. До того ж, буде проблема збіжності. Але інакше ніяк…

Антикрихкість

Через якийсь час картина наступна:
«Ось сховище. І воно працює, якщо його не чіпати. Проблеми виникають тоді, коли ми маємо щось змінювати».

До нас прилітає зміна, вплив якої ми не в змозі оцінити і осмислити (оскільки не заклали таких інструментів у систему спочатку) – і щоб не ризикувати, ми не чіпаємо те, що є, а робимо ще одну прибудову збоку, і ще одну, і ще - перетворюючи наше рішення на нетрів, або як кажуть у Латинській Америці, «фавели», куди навіть поліцейські заходити бояться.
Виникає відчуття втрати контролю над власною системою хаосу. Потрібно все більше рук, щоб підтримувати існуючі процеси та вирішувати проблеми. І зміни робити все складніше. Іншими словами, система стає нестійкою до стресів, неадаптивною до змін. І крім того, з'являється сильна залежність від персонажів, які знають фарватер, оскільки карти ні в кого немає.

Така властивість об'єкту – руйнуватися під впливом хаосу, випадкових подій та потрясінь - Нассим Ніколас Талеб називає крихкістю . А також вводить протилежне поняття: антикрихкість – коли предмет не руйнується від стресу та випадковостей, а отримує від нього пряму вигоду. («Антихрупність. Як отримати вигоду з хаосу»)
Інакше це можна назвати адаптивність або стійкість до змін .

Що це означає у цьому контексті? Які є джерела хаосу для ІТ-систем? І що означає «здобути вигоду з хаосу» з погляду ІТ архітектури?
Перша думка, яка спадає на думку – зміни, які приходять ззовні. Що є зовнішнім світом системи? Для сховища зокрема. Звичайно, насамперед – зміни з боку джерел даних для сховища:

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

Не менш критичні зміни ініціюються з боку споживачів сховища (зміна вимог):

• раніше для побудови звіту даних вистачало – тепер потрібно підключити додаткові поля чи нове джерело даних;
• раніше реалізовані методики обробки даних застаріли – потрібно переробити алгоритми та все, на що це впливає;
• раніше всіх влаштовувало поточне значення атрибута довідника на інформаційній панелі – тепер потрібне значення, актуальне на момент виникнення аналізованого факту/події;
• виникла вимога до глибини історії зберігання даних, якої раніше не було – зберігати дані не за 2 роки, а за 10 років;
• раніше було достатньо даних за станом «на кінець дня/періоду» - тепер потрібний стан даних «всередині дня», або на момент певної події (наприклад, прийняття рішення щодо кредитної заявки – для Basel II);
• раніше нас влаштовувала звітність за даними на вчора (T-1) чи пізніше, зараз нам потрібен T0;
• і т.д.

Але це ще не все.
Говорячи про мінливість, ми перш за все згадуємо зовнішні фактори. Адже всередині ми можемо все контролювати, нам так здається, чи не так? І так і ні. Так, більшість факторів, які поза зоною впливу – зовнішні. Але є й “внутрішня ентропія”. І саме через її наявність нам іноді потрібно повернутися "у точку 0". Почати гру спочатку.
У житті ми часто схильні починати з нуля. Чому нам це властиво? І чи це так погано?
Що стосується ІТ. Для самої системи – це може бути дуже добре – можливість переглянути окремі рішення. Особливо коли ми можемо зробити це локально. Рефакторинг - процес розплутування тієї «павутини», яка періодично виникає у розвитку системи. Повернення «до початку» може бути корисним. Але має ціну.
При грамотному управлінні архітектурою ця ціна знижується - і процес розвитку системи стає більш контрольованим і прозорим. Простий приклад: якщо дотримується принципу модульності – можна переписати окремий модуль, не торкнувшись зовнішніх інтерфейсів. І цього не можна зробити за монолітної конструкції.

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

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

Приклад системи з «казки про сховище» - це якраз вельми хитка система, побудована на крихких підходах до проектування. І якщо так відбувається – руйнація настає досить швидко, саме для цього система класу.
Чому я можу так стверджувати? Тема сховищ не є новою. Підходи та інженерні практики, які були за цей час вироблені, були спрямовані саме на це збереження життєздатності системи.
Простий приклад: одна з найчастіших причин провалу проектів сховищ «на зльоті» - це спроба побудувати сховище над системами-джерелами, що знаходяться на стадії розробки, без узгодження інтеграційних інтерфейсів – спроба забрати дані безпосередньо з таблиць. У результаті пішли в розробку - цей час база даних джерела змінилася - і потоки завантаження в сховище стали непрацездатні. Переробляти щось пізно. А якщо ще й не підстрахувалися, зробивши кілька шарів таблиць усередині сховища – все можна викинути і починати заново. Це лише один із прикладів, причому один із простих.

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

Що таке сховище даних та навіщо ми його будуємо

Як взагалі люди дійшли того, що необхідні сховища даних? І чим вони відрізняються від просто «дуже великої бази даних»?
Давним-давно, коли у світі жили просто «системи обробки бізнес-даних», був поділу ІТ-систем такі класи як фронтальні oltp-системи, бэк-офисные dss, системи обробки текстових даних, сховища даних, і т.д.
Це був той час, коли Майклом Стоунбрейкером було створено першу реляційну СУБД Ingres.
І це був час, коли ера персональних комп'ютерів вихором увірвалася в комп'ютерну індустрію і назавжди перевернула усі уявлення ІТ суспільства того часу.

Тоді можна було легко зустріти корпоративні програми, написані на базі СУБД класу desktop – таких як Clipper, dBase та FoxPro. А ринок клієнт-серверних додатків та СУБД лише набирав обертів. Одна за іншою з'являлися сервери баз даних, які надовго займуть свою нішу в ІТ-просторі - Oracle, DB2 і т.д.
І було поширено термін «додаток баз даних». Що включало в себе таку програму? Спрощено - деякі форми введення, якими користувачі могли одночасно вводити інформацію, деякі розрахунки, які запускалися «по кнопці» чи «за розкладом», і навіть якісь звіти, які можна було побачити на екрані чи зберегти як файлів і надіслати на печатка.
«Нічого особливого – звичайна програма, тільки є база даних,» - так зауважив один із моїх наставників на ранньому етапі трудового шляху. Чи так нічого особливого? – подумала тоді я.

Якщо придивитися - то особливості все-таки є. У міру зростання користувачів, обсягу інформації, що надходить, у міру зростання навантаження на систему - її розробники-проектувальники, щоб зберегти швидкодію на прийнятному рівні йдуть на деякі «хитрощі». Найперше – це поділ монолітної «системи обробки бізнес-даних» на програму обліку, яка підтримує роботу користувачів у режимі on-line, і окремо виділяють програму для batch-обробки даних та звітності. Кожна з цих програм має свою базу даних і навіть розміщується на окремому екземплярі сервера БД, з різними налаштуваннями під різний характер навантаження – OLTP та DSS. І між ними вишиковуються потоки даних.

Це все? Здавалося б – проблему вирішено. Що ж відбувається далі?
А далі компанії зростають, їх інформаційні потреби множаться. Зростає і кількість взаємодій із зовнішнім світом. І в результаті є не одна велика програма, яка повністю автоматизує всі процеси, а кілька різних, від різних виробників. Число систем, що породжують інформацію – систем-джерел даних у компанії збільшується. І рано чи пізно, виникне потреба побачити та зіставити між собою інформацію, отриману з різних систем. Так, у компанії з'являється Сховища даних – новий клас систем.
Загальноприйняте визначення цього класу систем звучить так.

Сховище даних (або Data Warehouse)– предметно-орієнтована інформаційна база даних, спеціально розроблена та призначена для підготовки звітів та бізнес-аналізу з метою підтримки прийняття рішень в організації

Ключові особливості сховищ даних

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

По-друге, це історичні дані – "Corporate memory" - Так називають сховища даних. Щодо роботи з часом у сховищах все дуже цікаво. В облікових системах дані є актуальними в моменті. Потім користувач робить якусь операцію – і дані оновлюються. При цьому історія змін може і не зберегтися – це залежить від практики обліку. Візьмемо, наприклад, решту на банківському рахунку. Нас може цікавити актуальний залишок на «зараз», на кінець дня або на момент події (наприклад, в момент розрахунку скорингового балу). Якщо перші два вирішуються досить просто, то для останнього, швидше за все, будуть потрібні спеціальні зусилля. Користувач, працюючи зі сховищем, може звертатися до минулих періодів, здійснювати їхнє порівняння з поточним тощо. Саме подібні можливості, пов'язані з часом, істотно відрізняють сховища даних від систем обліку – отримання стану даних у різних точках осі часу – на певну глибину у минулому.

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

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

Архітектурна концепція

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

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

Core Data Layer – ядро ​​сховища - центральний компонент системи, який відрізняє сховище від просто "платформи batch-інтеграції", або "великого звалища даних", оскільки його основна роль - це консолідація данихіз різних джерел, приведення до єдиних структур, ключів. Саме при завантаженні в ядро ​​здійснюється основна робота з якістю даних та загальні трансформації, які можуть бути складними.
Завдання цього шару– абстрагувати своїх споживачів від особливостей логічного устрою джерел даних та необхідності зіставляти дані з різних систем, забезпечити цілісність та якість даних.

Data Mart Layer - аналітичні вітрини – компонент, основна функція якого – перетворення даних до структур, зручним для аналізу (якщо з вітринами працює BI – це, як правило, dimensional model), або відповідно до вимог системи-споживача.
Зазвичай, вітрини беруть дані з ядра – як надійного і вивіреного джерела – тобто. користуються сервісом цього компонента щодо приведення даних до єдиного виду. Будемо називати такі вітрини регулярними . В окремих випадках вітрини можуть брати дані безпосередньо із стейджингу – оперуючи первинними даними (у ключах джерела). Такий підхід зазвичай використовується для локальних завдань, де не потрібна консолідація даних з різних систем і де потрібна оперативність більш ніж якість даних. Такі вітрини називають операційними . Деякі аналітичні показники можуть мати складні методики розрахунків. Тому, для таких нетривіальних розрахунків та трансформацій створюють так звані вторинні вітрини .
Завдання шару вітрин– підготовка даних відповідно до вимог конкретного споживача – BI-платформи, групи користувачів або зовнішньої системи.

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

Також виділяють спеціальний компонент (або набір компонентів), який надає сервісні функції всім шарів. Одне з ключових його завдань – функція, що управляє, - забезпечити «єдині правила гри» для всієї системи в цілому, залишаючи право на використання різних варіантів реалізації кожного з описаних вище шарів – у т.ч. використовувати різні технології завантаження та обробки даних, різні платформи зберігання тощо. Зватимемо його сервісним шаром (Service Layer) . Він не містить бізнес-даних, але має свої структури зберігання – містить область метаданих, а також область для роботи з якістю даних (і можливо інші структури – залежно від покладених на нього функцій).

Такий чіткий поділ системи на окремі компоненти суттєво підвищує керованість розвитку системи:

• знижується складність завдання, що ставиться розробнику функціоналу того чи іншого компонента (він не повинен одночасно вирішувати і питання інтеграції із зовнішніми системами, і продумувати процедури очищення даних, і думати про оптимальне представлення даних для споживачів) – завдання простіше декомпозувати, оцінити та виконати невеликий delivery;
• можна підключати на роботу різних виконавців (і навіть команд, чи підрядників) – т.к. такий підхід дозволяє ефективно розпаралелювати завдання, знижуючи їх взаємний вплив один на одного;
• наявність персистентного стейджинга дозволяє швидко підключити джерела даних, не проектуючи повністю ядро, або вітрини для всієї предметної області, а далі поступово добудовувати інші верстви відповідно до пріоритетів (причому дані будуть у сховищі – доступні системним аналітикам, що значно полегшить завдання подальшого розвитку сховища);
• наявність ядра дозволяє всю роботу з якістю даних (а також, можливі промахи та помилки) приховати від вітрин і від кінцевого користувача, а головне – використовуючи цей компонент як єдине джерело даних для вітрин, можна уникнути проблем зі збіжністю даних внаслідок реалізації загальних алгоритмів одному місці;
• виділення вітрин дозволяє врахувати відмінності та специфіку розуміння даних, які можуть бути у користувачів різних підрозділів, а їх проектування під вимоги BI дозволяє не лише видавати агреговані цифри, а й забезпечити перевірку достовірності даних шляхом надання можливостей drill down до первинних показників;
• наявність сервісного шару дозволяє виконувати наскрізний аналіз даних (data lineage), використовувати уніфіковані засоби аудиту даних, загальні підходи до виділення дельти змін, роботи з якістю даних, управління завантаженням, засоби моніторингу та діагностики помилок, прискорює вирішення проблем.

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

Ядро системи

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

Модель ядра сховища та корпоративна модель даних

Міф 1 Корпоративна модель даних – це величезна модель, що з тисяч сутностей (таблиць).
Насправді. У будь-якій предметній області, у будь-якому бізнес-домені, у даних будь-якої компанії, навіть найскладнішої, основних сутностей небагато – 20-30.

Міф 2 Не потрібно розробляти жодну «свою модель» - купуємо галузеву референсну модель – і робимо все за нею. Витрачаємо гроші – зате отримуємо гарантований результат.
Насправді. Референсні моделі можуть бути дуже корисні, т.к. містять галузевий досвід моделювання даної галузі. З них можна отримати ідеї, підходи, практики іменування. Перевірити «глибину охоплення» області, щоб не упустити з уваги щось важливе. Але ми навряд чи зможемо використовувати таку модель з коробки - як є. Це такий самий міф, як наприклад – покупка ERP-системи (або CRM) та її впровадження без будь-якого «докручування під себе». Цінність таких моделей народжується в їхній адаптації до реалій саме цього бізнесу, саме цієї компанії.

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

Час на розробку моделі справді знадобиться. Але це час, витрачене на «малювання сутностей» - це час, необхідне аналізу предметної області, вникнення у те, як влаштовані дані. Саме тому в цьому процесі дуже беруть участь аналітики, а також залучаються різні бізнес-експерти. І робиться це точково, вибірково. А не шляхом організації зустрічей за участю шаленої кількості людей, розсилок величезних анкет тощо.
Якісний бізнес та системний аналіз – ось що є ключовим при побудові моделі ядра сховища. Потрібно багато чого зрозуміти: де (у яких системах) породжуються дані, як вони влаштовані, у яких бізнес-процесах вони циркулюють тощо. Якісний аналіз ще жодній системі не шкодив. Швидше, навпаки – проблеми виникають із «білих плям» у нашому розумінні.

Розробка моделі даних – це процес винаходу і придумування чогось нового. Фактично модель даних у компанії вже існує. І процес її проектування радше схожий на «розкопки». Модель акуратно і ретельно виходить на світ із «ґрунту» корпоративних даних і вбирається в структуровану форму.

Міф 4 У нас в компанії бізнес настільки динамічний, і все так швидко змінюється, що марно нам робити модель - вона застаріє раніше, ніж ми введемо цю частину системи в експлуатацію.
Насправді. Згадаймо, що ключовий фактор ядра – стабільність. І насамперед, топології моделі. Чому? Тому що саме цей компонент є центральним і впливає на решту. Стабільність – це вимога і до моделі ядра. Якщо модель дуже швидко застаріває - значить вона неправильно спроектована. Для її розробки обрані не ті підходи та «правила гри». І це питання якісного аналізу. Ключові сутності корпоративної моделі змінюються дуже рідко.
Але якщо нам спаде на думку зробити для компанії, що торгують скажімо, кондитерськими виробами, замість довідника «Продукти» зробити «Цукерки», «Торти» та «Пироги». То коли з'явиться піца в переліку товарів - так, потрібно буде вводити безліч нових таблиць. І це якраз питання підходу.

Міф 5 Створення корпоративної моделі – це дуже серйозна, складна та відповідальна справа. І страшно зробити помилку.
Насправді. Модель ядра хоч і має бути стабільною, але все ж таки не «відлита в металі». Як і будь-які інші проектні рішення, її структуру можна переглядати та видозмінювати. Просто не потрібно забувати про цю її якість. Але це зовсім не означає, що на неї "не можна дихати". І це не означає, що неприпустимі тимчасові рішення та «заглушки», які мають бути заплановані до переробки.

Міф 6 Якщо у нас джерело даних – це, наприклад, система НСІ (або система управління майстер-даними – МДМ), то вона вже по-хорошому має відповідати корпоративній моделі (особливо, якщо вона нещодавно спроектована, і не встигла обрости «побочкою», «традиціями») » та часинками). Виходить, що для цього випадку нам модель ядра не потрібна?
Насправді. Так, у разі побудова моделі ядра сховище сильно полегшується – т.к. ми слідуємо готової концептуальної моделі верхнього рівня. Але не виключається зовсім. Чому? Тому що при побудові моделі певної системи діють деякі свої правила - які типи таблиць використовувати (для кожної сутності), як версіонувати дані, з якою гранулярністю вести історію, які метаатрибути (технічні поля використовувати) і т.п.

Крім того, яка б чудова та всеохоплююча система НСІ та МДМ у нас не була – як правило, виникнуть нюанси, пов'язані з існуванням локальних довідників «про те саме» в інших облікових системах. І цю проблему, чи хочемо ми цього, чи ні – доведеться вирішувати на сховищі – адже звітність та аналітику збирати тут.

Шар первинних даних (або історизований staging або операційний шар)

Дані в цьому шарі зберігаються в структурах, максимально близьких до системи-джерела – щоб зберегти первинні дані якомога ближче до їхнього первозданного вигляду. Ще одна назва цього компонента – «операційний шар».
Чому б просто не використовувати усталений термін "staging"? Справа в тому, що раніше, до «епохи великих даних і VLDB», дисковий простір був дуже дорогим – і часто первинні дані якщо і зберігалися, то обмежений інтервал часу. І часто ім'ям “staging” називають очищуванийбуфер.
Тепер же технології зробили крок вперед - і ми можемо дозволити собі не тільки зберігати всі первинні дані, але історизувати їх з тим ступенем гранулярності, який тільки можливий. Не означає, що ми повинні контролювати зростання даних і скасовує необхідність управляти життєвим циклом інформації, оптимізуючи вартість зберігання даних, залежно від «температури» використання – тобто. виводячи «холодні дані», які менш потрібні, на більш дешеві носії та платформи зберігання.

Що нам дає наявність «історизованого стейджингу»:

• можливість помилитися (у структурах, алгоритмах трансформації, гранулярності ведення історії) – маючи первинні дані, що повністю історизуються, в зоні доступності для сховища, ми завжди можемо зробити перезавантаження наших таблиць;
• можливість подумати – ми можемо не поспішати з опрацюванням великого фрагмента ядра у цій ітерації розвитку сховища, т.к. у нашому стейджингу у будь-якому випадку будуть, причому з рівним тимчасовим горизонтом (крапка «відліку історії» буде одна);
• можливість аналізу – ми збережемо навіть ті дані, яких вже немає у джерелі – вони могли там затертися, поїхати до архіву тощо. – у нас вони залишаються доступними для аналізу;
• можливість інформаційного аудиту – завдяки максимально докладній первинній інформації ми зможемо потім розбиратися – як у нас працювало завантаження, що ми в результаті отримали такі цифри (для цього потрібно ще мати маркування мета-атрибутами та відповідні метадані, за якими працює завантаження – це вирішується на сервісному) шарі).

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

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

Шар аналітичних вітрин

Якщо споживачем є зовнішня система, то, як правило, вона диктує ті структури даних, які їй необхідні та регламенти забору інформації. Хорошим підходом вважається такий, за якого за коректний забір даних відповідає сам споживач. Сховище дані підготувало, сформувало вітрину, забезпечило можливість інкрементального забору даних (маркування мета-атрибутами для подальшого виділення дельти змін), а система-споживач далі сама керує та відповідає за те, як вона цією вітриною користується. Але бувають особливості: коли система не має активного компонента для забору даних - потрібен або зовнішній компонент, який виконає інтегруючу функцію, або сховище виступить у ролі "платформи інтеграції" - і забезпечить коректне інкрементальне відвантаження даних далі - за межі сховища. Тут спливає багато нюансів, і правила інтерфейсної взаємодії мають бути продумані та зрозумілі обом сторонам (втім, як завжди – коли це стосується інтеграції). До подібних вітрин зазвичай застосовується регламентне очищення/архівування даних (рідко потрібно, щоб ці «транзитні дані» зберігалися тривалий час).

Найбільше значення з погляду аналітичних завдань є вітрини «для людей» - точніше для інструментів BI, з якими вони працюють.
Втім, є категорія «особливо просунутих користувачів» – аналітики, дослідники даних – яким не потрібні ні BI-інструменти, ні регламентні процеси наповнення зовнішніх спеціалізованих систем. Їм потрібні деякі «загальні вітрини» і «своя пісочниця», де вони можуть створювати таблиці та трансформації на власний розсуд. У цьому випадку відповідальність сховища полягає у забезпеченні наповнення даними цих загальних вітрин у відповідність до регламенту.
Окремо можна назвати таких споживачів як засоби Data Mining – глибокого аналізу даних. Такі інструменти мають свої вимоги до перепідготовки даних, і з ними працюють експерти з дослідження даних. Для сховища завдання зводиться - знову ж таки до підтримки обслуговування по завантаженню деяких вітрин узгодженого формату.

Проте, повернемося до аналітичних вітрин. Саме вони становлять інтерес з погляду розробників-проектувальників сховища у цьому шарі даних.
На мою думку, найкращий підхід до проектування вітрин даних, перевірений часом, на який зараз «заточені» практично всі платформи BI – це підхід Ральфа Кімбалла. Він відомий під назвою dimensional modeling - Багатомірне моделювання. Існує безліч публікацій на цю тему. Наприклад, з основними правилами можна ознайомитись у публікації Маргі Росс. І, звичайно ж, можна рекомендувати від гуру багатовимірного моделювання. Інший корисний ресурс – «Поради Кімбалла»
Багатомірний підхід до створення вітрин описаний і опрацьований настільки добре – як з боку «євангелістів методу», так і з боку провідних вендорів ПЗ, що немає сенсу тут якось докладно на ньому зупинятися – першоджерело завжди краще.

Хотілося б зробити лише один акцент. «Звітність та аналітика» буває різною. Є «важкий reporting» - попередньо замовлені звіти, які формуються у вигляді файлів і доставляються користувачам за передбаченими каналами доставки. А є інформаційні панелі – BI dashboards. По суті це web-додатки. І на час відгуку цих додатків пред'являються такі самі вимоги, як і будь-якого іншого web-додатка. Це означає, що нормальний час оновлення панелі BI – це секунди, а не хвилини. Важливо це пам'ятати розробки рішення. Як цього досягти? Стандартний метод оптимізації: дивимося, із чого складається час відгуку і що ми можемо впливати. На що найбільше витрачається час? На фізичні (дискові) читання БД, на передачу даних через мережу. Як зменшити обсяг даних, що зчитуються і передаються за один запит? Відповідь очевидна і проста: потрібно дані або агрегувати, або накласти фільтр на великі таблиці фактові таблиці, що беруть участь у запиті, і виключити з'єднання великих таблиць (звернення до фактових таблиць повинні йти тільки через вимірювання).

Навіщо потрібен BI? Чим він зручний? Чому ефективна багатовимірна модель?
BI дозволяє користувачеві виконувати так звані «нерегламентовані запити». Що це означає? Це означає, що ми запит заздалегідь точно не знаємо, але ми знаємо які показники в яких розрізах користувач може запросити. Користувач формує такий запит шляхом вибору відповідних фільтрів BI. І завдання розробника BI та проектувальника вітрин – забезпечити таку логіку роботи програми, щоб дані або фільтрувалися, або агрегувалися, не допускаючи ситуації, коли даних вимагається надто багато – і програма «повисала». Зазвичай починають з агрегованих цифр, далі заглиблюючись до детальніших даних, але попутно встановлюючи потрібні фільтри.

Не завжди достатньо просто побудувати «правильну зірку» – і отримати зручну структуру для BI. Іноді потрібно десь застосувати денормалізацію (оглядаючись при цьому, як це вплине на завантаження), а десь зробити вторинні вітрини та агрегати. Десь додати індекси чи проекції (залежно від СУБД).

Таким чином, шляхом “проб та помилок” можна отримати структуру, оптимальну для BI – яка врахує особливості як СУБД, так і BI-платформи, а також вимоги користувача щодо представлення даних.
Якщо ми дані ми беремо з «ядра», то така переробка вітрин матиме локальний характер, ніяк не впливаючи на складну обробку первинних даних, отриманих безпосередньо із систем-джерел – ми лише «перекладаємо» дані у зручний для BI формат. І можемо собі дозволити зробити це безліч разів, у різний спосіб, у відповідність до різними вимогами. На даних ядра робити це набагато простіше і швидше, ніж збирати з «первинки» (структура та правила якої, як ми знаємо, до того ж може «плисти»).

Сервісний шар

До цього шару відносять дві області зберігання даних:

• область метаданих – використовується механізму управління завантаженням даних;
• область якості даних – для реалізації оф-лайн перевірок якості даних (тобто тих, що не вбудовані безпосередньо в процеси ETL).

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

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

Не ставлю завдання тут повністю висвітлити цю тему – організації завантаження – лише розставляю акценти, куди варто звернути увагу.
Наведений підхід – це лише один із варіантів. Він досить адаптивний. І його "концептуальним прототипом" послужив конвеєр Toyota і система "точно під час" (just-in-time). Тобто. ми тут відходимо від широко поширеної парадигми виключно «нічного завантаження даних», а завантажуємо невеликими порціями протягом дня – у міру готовності даних у різних джерелах: що прийшло – те й завантажили. При цьому у нас працює безліч паралельних процесів. А «гарячий хвіст» нових даних буде «моргати» - і через якийсь час вирівнюватися. Ми маємо врахувати таку особливість. І у разі потреби формувати користувацькі вітринами «зрізами», де все вже цілісне. Тобто. не можна одночасно досягти і оперативності, і консистентності (цілісності). Потрібен баланс – десь важливе одне, десь інше.

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

Проектування та ведення моделей даних сховища

Чи можна розібратися без моделі? В принципі можна. І розібратися, і «прикинути картинки на папірці», і «пошерстити – поселити» дані. Але набагато простіше, зрозуміліше і швидше користуватися готовим артефактом – моделлю даних. А також розуміти "логіку її влаштування" - тобто. добре б мати загальні правила гри.

А найголовніше, навіть не це. Найголовніше, що при проектуванні моделі ми змушені (просто без варіантів!) щільніше і глибоко вивчити предметну область, особливості пристрою даних та їх використання у різних бізнес-кейсах. І ті питання, які б ми з легкістю "відсунули" як складні, "замилили", накидаючи наші таблички, не намагаючись при цьому саме проектуватимодель - ми будемо змушені поставити і вирішувати зараз, при аналізі та проектуванні, а не потім - коли будуватимемо звіти і думати про те, «як звести несумісне» і щоразу «винаходити велосипед».

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

Проектування моделей даних – це окрема, дуже велика тема. При проектуванні сховищ використовуються два основних підходи.
Для ядра добре підходить підхід «сутність-зв'язок» - коли будується нормалізована (3NF) модель з урахуванням саме дослідження предметної області, точніше виділеної її області. Тут грає та сама «корпоративна модель», про яку йшлося вище.

При проектуванні аналітичних вітрин підходить багатовимірна модель . Цей підхід добре лягає розуміння бізнес-користувачів – т.к. це модель, проста і зручна для людського сприйняття – люди оперують зрозумілими та звичними поняттями метрик (показників) та розрізів, за якими вони аналізуються. І це дозволяє просто і чітко побудувати процес збору вимог – ми малюємо набір «матриць розрізів та показників», спілкуючись із представниками різних підрозділів. А потім зводимо в одну структуру - "модель аналізу": формуємо "шину вимірювань" і визначаємо факти, які на них визначені. Попутно опрацьовуємо ієрархії та правила агрегації.

Далі дуже просто перейти до фізичної моделі, додавши елементи оптимізації з урахуванням особливостей СУБД. Наприклад, для Oracle це буде секціонування, набір індексів тощо. Для Vertica буде використано інші прийоми – сортування, сегментація, секціонування.
Також може бути потрібна спеціальна денормалізація - коли ми свідомо вносимо надмірність у дані, завдяки яким покращуємо швидкодію запитів, але при цьому ускладнюємо оновлення даних (бо надмірність потрібно буде враховувати і підтримувати в процесі завантаження даних). Можливо, для поліпшення швидкодії, нам також доведеться створити додаткові таблиці-агрегати, або використовувати такі додаткові можливості СУБД як проекції в Vertica.

Отже, під час моделювання даних сховища ми фактично вирішуємо кілька завдань:

• завдання побудова концептуальної (логічної) моделі ядра - системний та бізнес-аналіз - дослідження предметної галузі, заглиблення в деталі та облік нюансів «живих даних» та їх використання у бізнесі;
• завдання побудови моделі аналізу – і надалі концептуальної (логічної) моделі вітрин;
• Завдання побудови фізичних моделей - управління надмірністю даних, оптимізація з урахуванням особливостей СУБД під запити та завантаження даних.

Резюмуємо.

• Модель даних – це не набір «красивих картинок», а процес її проектування – це процес малювання. Модель відбиває наше розуміння предметної області. А процес її складання – це процес її вивчення та дослідження. Ось на це витрачається час. А зовсім не на те, щоб намалювати і розфарбувати.
• Модель даних – це проектний артефакт, спосіб обміну інформацією структурованому вигляді між учасниками команди. Для цього вона має бути всім зрозуміла (це забезпечується нотацією та поясненням) та доступна (опублікована).
• Модель даних не створюється один раз і заморожується, а створюється та розвивається у процесі розвитку системи. Ми самі ставимо правила її розвитку. І можемо їх міняти, якщо бачимо – як зробити краще, простіше, ефективніше.
• Модель даних (фізична) дозволяє консолідувати та використати набір кращих практик, вкладених у оптимізацію – тобто. використовувати ті прийоми, які спрацювали для даної СУБД.

Особливості проектів сховищ даних

Сховище даних – це замовлення ПЗ

Сховище даних – це інтеграційний проект

Сховище даних – це колективний проект

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

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

Сховище даних має більший термін життя в порівнянні з іншими системами

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

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

Поступовий ітеративний розвиток

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

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

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

Сховища даних – «мульти-проектна історія»

Баланс інновацій та перевірених рішень

Подивимося на СУБД – як найбільш критичну та важливу для сховищ технологічну платформу.
Останнім часом явно намітився дрейф реляційних баз даних, створених спочатку як «універсальних» у бік спеціалізації. Вже давно провідні вендори випускають різні опції – для програм різного класу (OLTP, DSS & DWH). Крім того, з'являються додаткові можливості для роботи з текстом, геоданими і т.д.

Але цим справа не обмежилася - стали з'являтися продукти, які спочатку орієнтовані певний клас завдань – тобто. спеціалізовані СУБД. Вони можуть використовувати реляційну модель, а можуть і ні. Важливо те, що вони спочатку «заточені» не просто на зберігання та обробку «бізнесу інформації» в цілому, а під певні завдання.

Мабуть, централізація та спеціалізація – це два взаємодоповнюючі тренди, які періодично змінюють один одного, забезпечуючи розвиток та баланс. Так само як і еволюційний (поступовий) поступовий розвиток та кардинальні зміни. Так, у 90-х роках Майкл Стоунбрейкер був одним із авторів Маніфесту баз даних III покоління, в якому чітко звучала думка, що світові не потрібна ще одна революція у світі баз даних. Однак через 10 років він публікує роботи, в яких анонсує передумови початку нової ери у світі СУБД - саме виходячи з їхньої спеціалізації.
Він наголошує на тому, що поширені універсальні СУБД побудовані на «безрозмірній» (one-size-fits-all) архітектурі, яка не враховує ні змін апаратних платформ, ні поділу додатків на класи, для яких можна придумати більш оптимальне рішення, ніж реалізуючи Універсальні вимоги.
І починає розвивати низку проектів у відповідність із цією ідеєю. Один з яких – C-Store – колонкова СУБД, спроектована в архітектурі shared nothing (SN), спочатку створена спеціально для систем класу сховищ даних. Далі цей продукт отримав комерційний розвиток як HP Vertica.

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

Епілог

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

"Унікальність антикрихкості полягає в тому, що вона дозволяє нам працювати з невідомістю, робити щось в умовах, коли ми не розуміємо, що саме робимо, - і досягати успіху"/Нассім Н.Талеб/

Щоб продавати, треба розуміти, що продаємо

Визначимося з термінологією та поняттями. ( Data Warehouse) - це не система ключових показників ефективності (КПЕ, KPI), це не велика базаданих, це не аналітичний OLAP-інструмент, це не інтелектуальна система, що дозволяє видобувати нові дані та отримувати статистичні залежності, це не система єдиної НСІ – це все не ХД, якщо говорити про нього у контексті окремо взятого пункту.

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

Потенційні клієнти на корпоративне сховище даних та що вони отримують?

Як визначити потенційних корпоративних клієнтів, яким необхідне сховище даних?

1. Насамперед, у повсякденній діяльності у компанії має виникати маса інформації. Це можуть бути телефонні дзвінки, фінансові транзакції, скарги/відгуки клієнтів, заявки клієнтів на відвантаження, інформація зі супутників-шпигунів тощо. В принципі, все що завгодно, головне, щоб даних було багато.
2. У потенційного клієнта має бути бажання бачити та аналізувати цю інформацію. При цьому період аналізу повинен бути досить широким – від дня або навіть години, до аналізу кількох років.
3. У клієнта повинна бути нормально працююча інфраструктура (серверів, з'єднаних витою парою або USB портом, бути не повинно). Якщо інфраструктури клієнта немає – йому її потрібно продати.

Які вигоди клієнт отримує від запровадження корпоративного сховища даних?

1. З'являється єдина інформаційна система зберігання корпоративних даних, де використовується єдина довідкова інформація.
2. Виникає можливість проведення всебічного аналізу бізнесу. Наприклад: які клієнти є найбільш прибутковими та вигідними; яка послуга, у яких клієнтів є найбільш затребуваною, які претензії найчастіші й у яких регіонах тощо.
3. Виникає можливість проведення аналізу з використанням історичних даних. Найчастіше операційні (автоматичні щоденні бізнес-процеси) системи не дозволяють цього робити, у них банально не вистачає місця для зберігання історії та потужності для проведення аналізу.
4. З'являється можливість з'єднання та аналізу інформації, що раніше зберігалася в різних інформаційних системах. Наприклад, дані щодо трафіку різних філій зберігаються в білінгових системах від різних розробників. Після застосування ХД з'являється можливість їх аналізу разом, в єдиному звіті.
5. З'являється можливість аналізу та схрещування різних за родом даних. Наприклад, гроші та трафік, кількість персоналу та кількість відмов чи претензій тощо.
6. З'являється основа для якіснішого розрахунку собівартості послуг – на підставі інформації з корпоративного сховища даних можна отримувати більш адекватні дані для натуральних баз розподілу.

З чого складається корпоративне сховище даних

З яких компонентів будує корпоративне сховище даних із технічної точки зору?

Компоненти корпоративного сховища даних підприємства

1. У клієнта завжди є операційні системи. джерела данихдля корпоративного сховища даних Це, наприклад, бухгалтерські, білінгові, банківські тощо. системи.
2. Використовуючи ETL-додаток(програмне забезпечення, що дозволяє вилучати, трансформувати та завантажувати дані), дані із систем-джерел потрапляють до бази даних сховища даних. Як ETL-засоби можуть використовуватися: Informatica Power Center, IBM DataStage, Oracle Data Integrator, Oracle WareHouse Builder. Існують і продукти від інших вендорів, але вони майже не представлені на російському ринку.
3. Сама база данихкорпоративного сховища не є абстрактною за своєю структурою (набором таблиць, полів у них та взаємозв'язків між таблицями), а створена на основі моделі даних. Як база даних у переважній більшості використовується або Oracle, або Teradata.
4. Модель данихє описом усіх сутностей, об'єктів бази даних корпоративного сховища даних і включає: концептуальну модель даних, логічну модель даних та фізичну модель бази даних . На рівні концептуальної моделі визначаються сутності та взаємозв'язки між ними. На рівні логічної моделі сутності діляться на бізнес-області, їм дається докладний та повний опис, прописуються взаємозв'язки. При розробці фізичної моделі бази даних визначається вся структура бази даних - від таблиць та полів у них, до партицій та індексів. Моделі данихСьогодні на ринок постачають IBM, SAP і Oracle, але покупка моделі даних не означає автоматичну побудову правильного корпоративного сховища.Модель даних- це коробковий продукт. Її необхідно модифікувати під потреби конкретного клієнта.
5. Далі, вже використовуючи дані з корпоративного сховища даних, проводиться налаштування областей аналізу, звітності та вітрин даних. Надалі користувачі цілком самостійно можуть будувати необхідну звітність та проводити багатовимірний аналіз. Як інструменти аналізу в основному використовуються Business Objects, Oracle Discoverer, IBM AlphaBlocks та інші продукти.

Як виглядають компоненти корпоративного сховища даних (модель даних, ETL-процеси, вітрини даних)

Наведемо наочні приклади моделі даних, реалізації ETL-процесу, форми підтримки єдиної НСІ, вітрин даних.

Логічна модельданих.
Визначає сутності, їх атрибути та зв'язки між ними.

ETL процесусунення дублікатів у вихідних даних

Форма введення даних для формування єдиного довідника

Вітрина даниху формі табличного звіту

Вітрина данихз графіком та колірним
виведенням даних за заданою умовою

Вітрина данихз графіком

Супутнє програмне та апаратне забезпечення

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

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

Крім серверів для зберігання значного обсягу інформації необхідні дискові масиви.

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

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

Ковтун М.В. Серпень 2010