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

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

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

Окинув він своїм поглядом збори і питає:
— Ось ти, бабо знаєш, як воно влаштоване наше сховище?
— Ні, діду, не знаю. Та й звідки мені знати? Он там які браві хлопці його охороняють! Одні усищи які! Не підступишся. Я зайшла якось їх провідати, пиріжків напекла. А вони пиріжки з'їли, вуса витерли і кажуть: «Та чого ти прийшла, бабо? Яке тобі сховище? Ти скажи – який тобі звіт потрібен – ми тобі зробимо! Ти головне пиріжки частіше принесеш! Аж надто вони у тебе смачні.»
— А ти, улюблена онучка, знаєш як влаштовано наше сховище?
— Ні, діда, не знаю. Дали мені як-то доступ до нього. Підключилася я, дивлюсь — а там таблиць – видимо-невидимо. І в схеми різні сховані. Очі розбігаються… Я спершу розгубилася. А потім придивилася – якісь із них порожні, інші заповнені, та лише наполовину. А ще дані, схоже, повторюються. Не дивно, що дисків не напасешся, з такою надмірністю!
— Ну а ти, кіт, що скажеш про сховище наше? Є в ньому щось хороше?
— Та як не сказати, дід – скажу. Я внучкиной прохання намагався в окремій схемці пилотик смастырить – витринку маленьку. Щоб зрозуміти, яка торгівля для нашої держави вигідна – які продукти добре у купців йдуть, ті данину платять – поповнюють скарбницю. А які – з рук геть погано. І став я з цього сховища дані собі підбирати. Фактів назбирав. І став намагатися зіставити їх супроти продуктів. І що ж, дід, я побачив, продукти, то вони начебто й однакові, а дивишся в таблички – різні! Почав я їх тоді гребінцем внучкиным причісувати. Чухав-чухав – і привів до певної одноманітності, пестить око. Але рано я зрадів – на другий день я запустив свої скриптики чудові дані в витринке оновити – а в мене все і роз'їхалась! «Як так?» — думаю, — внучка-то піди засмутиться – сьогодні треба було б наш пилотик міністру показувати. Як же ми підемо-то – з такими даними?
— Так, сумні казки, кіт, розповідаєш. Ну а ти, мишка-шкряботушка, невже не намагалася довідатися про сховище? Ти у нас дівчина жвава, швидка, товариська! Що ти нам повідаєш?
— Так, дідусю, не намагатися – звичайно, я мишка тиха, та проворна. Попросила якось онука кота модель даних нашого державного сховища роздобути. А кіт, звісно, до мене прийшов – тебе, каже, мишка, вся надія! Ну що добру справу хорошим людям (і котів) не зробити? Пішла я в замок, де начальник сховища модель даних у сейфі ховає. І зачаїлася. Дочекалася, коли він ту модель з сейфа-то вийме. Тільки він за кавою вийшов – я стриб на стіл. Дивлюся на модель – нічого зрозуміти не можу! Як так? Не впізнаю наше сховище! У нас таблиць тисячі незліченні, даних – потоки невгамовні! А тут – все струнко так красиво… Поглянув на цю модель – і назад в сейф прибрав.
— Так, вже зовсім дивні речі, ти нам, мишка, повідала.
Міцно задумався дід.
— Що робити-то будемо, други мої? Адже з таким сховищем довго не проживеш… Користувачі он скоро – зовсім втратять терпіння.
image

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

Розбір польотів
Ніхто з нас, працюючи над створенням і розвитком якої-небудь системи, не хоче, щоб це виявилася «времянка», або рішення, яке «відімре» через рік або два, т. к. виявиться не в силах відповідати вимогам та очікуванням з боку Замовників і Бізнесу. Який би сильний крен у бік «гнучких методологій» не спостерігався нині, людині набагато приємніше відчувати себе «майстром», який робить скрипки, ніж ремісником, який штампує палички для одноразових барабанів.
Наш намір звучить природно: робити системи, добротні і якісні, які не зажадають від нас регулярних «нічних чувань з напилком», за які нам не буде соромно перед кінцевими користувачами і які не будуть виглядати «чорним ящиком» для всіх «непосвячених» послідовників.
Для початку накидаем список типових проблем, з якими ми регулярно стикаємося, працюючи з сховищами. Просто запишемо те, що є – поки без спроби упорядкувати і формалізувати.
  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. Користувачі вимагають оперативності. Але ми не можемо наші основні процеси завантаження запускати часто, т. к. це навантажує системи-джерела (погано позначається на продуктивності) – тому, ми вішаємо додаткові потоки даних, які будуть забирати точково – те, що нам потрібно. Правда, виходить багато потоків. І частина даних ми потім викинемо. До того ж буде проблема збіжності. Але по-іншому ніяк...
Вже вийшло досить багато. Але це не повний список – його легко доповнити і розвинути. Ми не будемо його ховати в стіл, а повісимо на видному місці – тримаючи ці питання у фокусі своєї уваги в процесі роботи.
Наше завдання — виробити в результаті комплексне рішення.

Антихрупкость
Дивлячись на наш список, можна зробити один висновок. Не складно створити деяку «базу даних для звітності», накидати туди даних або навіть побудувати якісь регламентні процеси оновлення даних. Система починає якось жити, з'являються користувачі, а з ними зобов'язання і SLA, виникають нові вимоги, підключаються додаткові джерела, відбувається зміна методологій – все це треба враховувати в процесі розвитку.
Через якийсь час картина наступна:
«Ось сховище. І воно працює, якщо його не чіпати. Проблеми виникають тоді, коли ми повинні щось змінювати».
До нас прилітає зміна, вплив якого ми не в силах оцінити і осмислити (оскільки не заклали таких інструментів у систему спочатку) – і щоб не ризикувати, ми не чіпаємо те, що є, а робимо ще одну прибудову збоку, і ще одну, і ще — перетворюючи наше рішення в нетрі, або як кажуть в Латинській Америці, «фавели», куди навіть поліцейські бояться заходити.
Виникає відчуття втрати контролю над власною системою, хаосу. Потрібно все більше рук, щоб підтримувати існуючі процеси і вирішувати проблеми. І зміни вносити все складніше. Іншими словами, система стає нестійкою до стресів, неадаптівной до змін. І крім того, з'являється сильна залежність від персонажів, які «знають фарватер», оскільки «карти» ні в кого немає.
Така властивість об'єкта – руйнуватися під впливом хаосу, випадкових подій і потрясінь — Нассім Ніколас Талеб називає крихкістю. А також вводить протилежне поняття: антихрупкость коли предмет не руйнується від стресу і випадковостей, а отримує від нього пряму вигоду. «Антихрупкость. Як отримати вигоду з хаосу»
Інакше це можна назвати адаптивність або стійкість до змін.
Що це означає в даному контексті? Які є джерела хаосу» для ІТ-систем? І що значить «отримати вигоду з хаосу» з точки зору ІТ архітектури?
Перша думка, яка приходить в голову – зміни, які приходять ззовні. Що є зовнішнім світом для системи? Для сховища зокрема. Звичайно, насамперед – зміни з боку джерел даних для сховища:
  • зміна форматів вхідних даних;
  • заміна одних систем-джерел даних на інші;
  • зміна правил/платформ інтеграції систем;
  • зміна трактувань даних (формати зберігаються, змінюється логіка роботи з даними);
  • зміна моделі даних, якщо інтеграція зроблена на рівні даних (розбір журнальних файлів транзакцій бази даних);
  • зростання обсягів даних — поки даних в системі-джерелі було небагато, і навантаження була невелика – можна було забирати їх коли завгодно, скільки завгодно важким запитом, дані і навантаження зросли – тепер є суворі обмеження;
  • і т. д.
Змінюватися можуть самі системи-джерела, склад інформації та її структура, тип інтеграційної взаємодії, а також сама логіка роботи з даними. Кожна система реалізує свою модель даних і підходи роботи з ними, які відповідають цілям та завданням системи. І як би не прагнули уніфікувати галузеві моделі та референсні практики – все одно нюанси неминуче будуть спливати. (Та й до того ж сам процес галузевої уніфікації, з різних причин не сильно просувається.)
Культура роботи з корпоративними даними – наявність і контроль інформаційної архітектури, єдина семантична модель, системи управління майстер-даними (МДМ) дещо полегшують завдання консолідації даних в сховище, але не виключають її необхідність.
Не менш критичні зміни ініціюються з боку споживачів сховища (зміна вимог):
  • раніше для побудови звіту даних вистачало – тепер потрібно підключити додаткові поля або новий джерело даних;
  • раніше реалізовані методики обробки даних застаріли – потрібно переробити алгоритми і все, на що це впливає;
  • раніше всіх влаштовувало поточне значення атрибута довідника на інформаційній панелі – тепер потрібне значення, актуальне на момент виникнення аналізованого факту/ події;
  • виникла вимога до глибини історії зберігання даних, якого раніше не було зберігати дані не за 2 роки, а за 10 років;
  • раніше було достатньо даних за станом на кінець дня/ періоду» — тепер потрібно стан даних «всередині дня», або на момент певної події (наприклад, прийняття рішення по кредитній заявці – для Basel II);
  • раніше нас влаштовувала звітність за даними на вчора (T-1) або пізніше, зараз нам потрібен T0;
  • і т. д.
І інтеграційні взаємодії з системами-джерелами, і вимоги з боку споживачів сховища даних – це зовнішні фактори для сховища даних: одні системи-джерела змінюють інші, зростають обсяги даних, формати вхідних даних змінюються, користувальницькі вимоги змінюються і т. п. І все це – типові зовнішні зміни, до яких наша система – наше сховище повинно бути готово. При правильній архітектурі вони не повинні вбити систему.
Але це ще не все.
Говорячи про мінливості, ми насамперед згадуємо зовнішні фактори. Адже всередині ми можемо контролювати, нам так здається, вірно? І так, і ні. Так, більшість факторів, які поза зоною впливу — зовнішні. Але є і внутрішня «ентропія». І саме в силу її наявності нам інколи потрібно повернутися «в точку 0». Почати гру спочатку.
У житті ми часто схильні починати з нуля. Чому нам це властиво? Та чи так це погано?
Стосовно до ІТ. Для самої системи – це може виявитися дуже добре – можливість переглянути окремі рішення. Особливо, коли ми можемо зробити це локально. Рефакторинг — процес розплутування тієї «павутини», яка періодично виникає в процесі розвитку системи. Повернення «до початку» може бути корисний. Але має ціну.
При грамотному управлінні архітектурою ця ціна знижується — і сам процес розвитку системи стає більш контрольованою і прозорою. Простий приклад: якщо дотримується принцип модульності – можна переписати окремий модуль, не торкнувшись зовнішні інтерфейси. І цього не можна зробити при монолітної конструкції.
Антихрупкость системи визначається архітектурою, яка в неї закладена. І саме ця властивість робить її адаптивної.
Коли ми говоримо про адаптивної архітектурі – ми маємо на увазі, що система здатна адаптуватися до змін, а зовсім не те, що ми саму архітектуру постійно змінюємо. Навпаки, чим більш стійка і стабільна архітектура, чим менше вимог, які тягнуть за собою її перегляд – тим більш адаптивна система.
Набагато більш високу ціну будуть мати рішення, що передбачають перегляд всієї архітектури цілком. І для їхнього прийняття потрібно мати дуже вагомі підстави. Наприклад, такою підставою може служити вимога, яку не можна реалізувати в рамках існуючої архітектури. Тоді кажуть – з'явилася вимога, що впливає на архітектуру.
Таким чином, ми також повинні знати свої «кордони антихрупкости». Архітектура не розробляється «у вакуумі» — вона спирається на поточні вимоги, очікування. І якщо ситуація принципово змінюється – ми повинні розуміти, що вийшли за межі поточної архітектури – і нам потрібно переглянути її, виробити інше рішення – і продумати шляхи переходу.
Наприклад, ми заложились на те, що у сховищі нам потрібні будуть дані завжди на кінець дня, паркан даних ми будемо робити щодня по стандартних інтерфейсів систем (через набір уявлень). Потім від підрозділу управління ризиками прийшли вимоги про необхідність одержувати дані не в кінці дня, а на момент прийняття рішення про кредитування. Не потрібно намагатися «натягувати не натягиваемое» — потрібно просто визнати цей факт – чим швидше, тим краще. І почати опрацьовувати підхід, який дозволить нам вирішити завдання.
Тут виникає дуже тонка грань – якщо ми будемо брати до уваги тільки «вимоги в моменті» і не будемо дивитися на кілька кроків вперед (і на кілька років вперед), то ми збільшуємо ризик зіткнутися з впливає на архітектуру вимогою занадто пізно – і ціна наших змін буде дуже висока. Дивитися трохи вперед – в межах нашого горизонту – ще нікому не шкодило.
Приклад системи з «казки про сховище» — це якраз приклад вельми хиткою системи, побудованої на делікатних підходів до проектування. І якщо так відбувається руйнування настає досить швидко, саме для цього класу систем.
Чому я можу так стверджувати? Тема сховищ не нова. Підходи та інженерні практики, які були за цей час вироблені, були спрямовані саме на це – збереження життєздатності системи.
Простий приклад: одна з найбільш частих причин провалу проектів сховищ «на злеті» — це спроба побудувати сховище над системами-джерелами, що знаходяться у стадії розробки, без погодження інтеграційних інтерфейсів – спроба забрати дані безпосередньо з таблиць. У підсумку пішли в розробку – за цей час база даних джерела змінилася – і потоки завантаження в сховище стали непридатними для сценарій виконання. Переробляти що-то пізно. А якщо ще і не підстрахувалися, зробивши кілька шарів таблиць всередині сховища – то все можна викинути і починати заново. Це лише один з прикладів, причому один з простих.
Критерій крихкого і антихрупкого за Талебу простий. Головний суддя – час. Якщо система витримує перевірку часом, і показує свою «живучість» і «захист від ударів» — вона має властивість антихрупкости.
Якщо при проектуванні системи ми будемо враховувати антихрупкость як вимога – то це спонукає нас використовувати такі підходи до побудови її архітектури, які зроблять систему більш адаптивної і до «хаосу ззовні», до «хаосу зсередини». І в кінцевому рахунку система буде мати більш довгий термін життя.
Нікому з нас не хочеться робити «времянки». І не треба себе обманювати, що по-іншому нині не можна. Дивитися на кілька кроків уперед – це нормально для людини в будь-який час, тим більш у кризовий.

Що таке сховище даних і навіщо ми його будуємо
Стаття, присвячена архітектурі сховищ, передбачає, що читач не тільки обізнаний, що це таке, але також і має деякий досвід роботи з подібними системами. Тим не менше я вважала за потрібне це зробити – повернутися до витоків, до початку шляху, тому що саме там знаходиться «точка опори» розвитку.
Як взагалі люди прийшли до того, що необхідні сховища даних? І чим вони відрізняються від просто «дуже великий бази даних»?
Давним-давно, коли на світі жили просто «системи обробки бізнес-даних», не було поділу ІТ-систем на такі класи як фронтальні oltp-системи, бек-офісні dss, системи обробки текстових даних, сховища даних і т. д.
Це був той час, коли Майклом Стоунбрейкером була створена перша реляційна СУБД Ingres.
І це був час, коли ера персональних комп'ютерів вихором увірвалася в комп'ютерну індустрію і назавжди перевернула всі уявлення ІТ спільноти того часу.
Тоді можна було легко зустріти корпоративні додатки, написані на базі СУБД класу desktop – таких як Clipper, dBase і FoxPro. А ринок клієнт-серверних додатків і СУБД тільки набирав обертів. Одна за одною з'являлися сервера баз даних, які надовго займуть свою нішу в IT-просторі – 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), використовувати уніфіковані засоби аудиту даних, загальні підходи до виділення дельти змін, роботі з якістю даних, управління завантаженням, засоби моніторингу і діагностики помилок, прискорює вирішення проблем.
Такий підхід до декомпозиції також робить систему більш стійкою до зміною (порівняно з «монолітною конструкцією») — забезпечує її антихрупкость:
  • зміни з боку систем-джерел відпрацьовуються на стейджинге — в ядрі при цьому модифікуються лише ті потоки, на які впливають ці стейджинговые таблиці, на вітрини вплив мінімально або відсутня;
  • зміни вимог з боку споживачів відпрацьовуються здебільшого на вітринах (якщо при цьому не вимагається додаткова інформація, якої ще немає у сховищі).
Далі ми пройдемося по кожному з представлених вище компонентів і подивимося на них трохи докладніше.

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

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

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

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

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

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

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

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

Шар первинних даних (або историзируемый staging або операційний шар)
схемою він позначений як Primary Data Layer. Роль цього компоненту: інтеграція з системами-джерелами, завантаження та зберігання первинних даних, а також попередня очистка даних — перевірка на відповідність правилам форматно-логічного контролю, зафіксованих в «угоді про інтерфейс взаємодії» з джерелом.
Крім того, даний компонент вирішує дуже важливу для сховища завдання – виділення «істинної дельти змін» — не залежно від того, чи дозволяє джерело відстежувати зміни в даних чи ні і яким чином (за яким критерієм їх можна «зловити»). Як тільки дані потрапили в стейджинг – для всіх інших верств питання виділення дельти вже зрозумілий – завдяки маркуванню мета-атрибутами.
Дані в цьому шарі зберігаються в структурах, максимально близьких до системи-джерела – щоб зберегти первинні дані як можна ближче до їх первісного вигляду. Ще одна назва цього компонента — «операційний шар».
Чому б просто не використовувати усталений термін «staging»? Справа в тому, що раніше, до «епохи великих даних і VLDB», дисковий простір було дуже дорого і часто первинні дані якщо і зберігалися, то обмежений інтервал часу. І часто ім'ям «staging» називають очищається буфер.
Тепер же технології зробили крок вперед – і ми можемо дозволити собі не тільки зберігати всі первинні дані, але історизувати їх з тієї ступенем гранулярности, яка тільки можлива. Це не означає, що ми не повинні контролювати зростання даних і не скасовує необхідність управляти життєвим циклом інформації, оптимізуючи вартість зберігання даних, в залежності від «температури» використання – тобто відводячи «холодні дані», які менш затребувані, на більш дешеві носії і платформи зберігання.
Що нам дає наявність «историзируемого стейджинга»:
  • можливість помилитися (в структурах, в алгоритмах трансформації, гранулярности ведення історії) – маючи повністю историзируемые первинні дані в зоні доступності для сховища, ми завжди можемо зробити перезавантаження наших таблиць;
  • можливість подумати – ми можемо не поспішати з опрацюванням великого фрагмента ядра саме в цій ітерації розвитку сховища, т. к. в нашому стейджинге в будь-якому випадку будуть, причому з рівним часовим горизонтом (крапка «відліку історії» буде одна);
  • можливість аналізу – ми збережемо навіть ті дані, яких вже немає в джерелі – вони могли там затереться, виїхати в архів і т. д. – у нас же вони залишаються доступними для аналізу;
  • можливість інформаційного аудиту – завдяки максимально докладної первинної інформації ми зможемо потім розбиратися – як у нас працювала завантаження, що ми в результаті отримали такі цифри (для цього потрібно ще мати маркування мета-атрибутами і відповідні метадані, за якими працює завантаження – це вирішується на сервісному шарі).
Які можуть виникнути складності при побудові «историзируемого стейджинга»:
  • було б зручно виставити вимоги до транзакційний цілісності цього шару, але практика показує, що це важко досяжно (це означає, що в цій галузі ми не гарантуємо посилальну цілісність батьківських і дочірніх таблиць) – вирівнювання цілісності відбувається на наступних шарах;
  • цей шар містить дуже великі обсяги (самий об'ємний на сховище — незважаючи на всю надмірність аналітичних структур) – і треба вміти поводитися з такими обсягами – як з точки зору завантаження, так і з точки зору запитів (інакше можна серйозно деградувати продуктивність всього сховища).
Що ще цікавого можна сказати про цей шар.
По-перше, якщо ми відходимо від парадигми «наскрізних процесів завантаження» — то для нас більше не працює правило «караван йде зі швидкістю останнього верблюда», точніше ми відмовляємося від принципу «каравану» і переходимо на принцип «конвеєра»: взяв дані з джерела – поклав у свій шар – готовий брати наступну порцію. Це означає, що
1) ми не чекаємо, поки статися обробка на інших шарах;
2) ми не залежимо від графіка надання даних іншими системами.
Простіше кажучи, ми ставимо на розклад процес завантаження, який бере дані з одного джерела через певний спосіб підключення до нього, перевіряє, виділяє дельту – і поміщає дані в цільові таблиці стейджинга. І все.
По-друге, ці процеси, як видно, влаштовані дуже просто – можна сказати тривіально, з точки зору логіки. А це значить – їх можна дуже добре оптимізувати і завдний, знижуючи навантаження на нашу систему і прискорюючи процес підключення джерел (час розробки).
Щоб це сталося, потрібно дуже добре знати особливості технологічні особливості платформи, на якій працює цей компонент – і тоді можна зробити дуже ефективний інструмент.

Шар аналітичних вітрин
Шар Вітрин (Data Mart Layer на схемі) відповідає за підготовку та надання даних кінцевим споживачам – людям або систем. На цьому рівні максимально враховуються вимоги споживача – як логічні (понятійні), так і фізичні. Сервіс повинен надавати рівно те, що потрібно – не більше, не менше.
Якщо споживачем є зовнішня система, то як правило, вона диктує ті структури даних, які їй необхідні і регламенти забору інформації. Хорошим підходом вважається такий, при якому за коректний паркан даних відповідає сам споживач. Сховище дані підготувало, сформувало вітрину, забезпечило можливість інкрементального забору даних (маркування мета-атрибутами для подальшого виділення дельти змін), а система-споживач далі сама керує і відповідає за те, як вона цією вітриною користується. Але бувають особливості: коли система не має активного компонента для забору даних – потрібен або зовнішній компонент, який виконує інтегруючу функцію, або сховище виступить в ролі «платформи інтеграції» — і забезпечить коректну инкрементальную відвантаження даних далі – за межі сховища. Тут спливає багато нюансів, і правила взаємодії інтерфейсного повинні бути продумані і зрозумілі обом сторонам (втім, як завжди, коли справа стосується інтеграції). До таких вітрин, як правило, застосовується регламентне очищення/ архівування даних (рідко потрібно, щоб ці «транзитні дані» зберігалися тривалий час).
Найбільше значення з точки зору аналітичних задач являють собою вітрини «для людей» — точніше для інструментів BI, з якими вони працюють.
Втім, є категорія «особливо просунутих користувачів» — аналітики, дослідники даних — яким не потрібні ні BI-інструменти, ні регламентні процеси наповнення зовнішніх спеціалізованих систем. Їм потрібні якісь «загальні вітрини» і «своя пісочниця», де вони можуть створювати таблиці і трансформації на свій розсуд. В цьому випадку відповідальність сховища полягає у забезпеченні наповнення даними цих загальних вітрин у відповідність з регламентом.
Окремо можна виділити таких споживачів як засоби Data Mining – глибокого аналізу даних. Такі інструменти мають свої вимоги до преподготовке даних, і з ними також працюють експерти з дослідження даних. Для сховища завдання зводиться знову ж таки до підтримки сервісу по завантаженню якихось вітрин узгодженого формату.
Однак, повернемося до аналітичних вітрин. Саме вони становлять інтерес з точки зору розробників-проектувальників сховища в цьому шарі даних.
На мій погляд, кращий підхід до проектування вітрин даних, перевірений часом, на який зараз «заточені» практично всі платформи BI – це підхід Ральфа Кімбола. Він відомий під назвою dimensional modeling – багатовимірне моделювання. Існує велика кількість публікацій на цю тему. Наприклад, з основними правилами можна ознайомитися в публікації Маргі Росс. І звичайно ж, можна рекомендувати книгу-бестселлер від гуру багатовимірного моделювання. Інший корисний ресурс – «Поради Кімбола»
Багатовимірний підхід до створення вітрин описаний і опрацьований настільки добре – як з боку «євангелістів методу», так і з боку провідних вендорів, що немає сенсу тут якось докладно на ній зупинятися – першоджерело завжди краще.
Хотілося б зробити лише один акцент. «Звітність та аналітика» буває різною. Є «важкий reporting» — предзаказанные звіти, які формуються у вигляді файлів і доставляються користувачам за передбаченими каналів доставки. А є інформаційні панелі – BI dashboards. По своїй суті це web-додатки. І до часу відгуку цих додатків пред'являються такі ж вимоги, як і для будь-якого іншого web-додатки. Це означає, що нормальний час оновлення BI-панелі – це секунди, а не хвилини. Важливо це пам'ятати при розробці рішення. Як цього досягти? Стандартний метод оптимізації: дивимося, з чого складається час відгуку і на що ми можемо впливати. На що найбільше витрачатися час? Фізичні (дискові) читання БД, на передачу даних по мережі. Як зменшити обсяг прочитуваних і переданих даних за один запит? Відповідь очевидна і проста: потрібно дані або агрегувати, або накласти фільтр на великі таблиці фактові таблиці, які беруть участь у запиті, та виключити з'єднання великих таблиць (звернення до фактовою таблиць повинні йти тільки через вимірювання).
Для чого потрібен BI? Чим він зручний? Чому ефективна багатовимірна модель?
BI дозволяє користувачеві виконувати так звані «нерегламентовані запити». Що це означає? Це означає, що ми запит заздалегідь точно не знаємо, але ми знаємо які показники в яких розрізах користувач може запросити. Користувач формує такий запит шляхом вибору відповідних фільтрів BI. І завдання розробника BI і проектувальника вітрин – забезпечити таку логіку роботи програми, щоб дані або фільтрувалися, або агрегировались, не допускаючи ситуації, коли даних запитується занадто багато – і додаток «повисало». Зазвичай починають з агрегованих цифр, далі заглиблюючись до більш детальним даними, але попутно встановлюючи потрібні фільтри.
Не завжди досить просто побудувати «правильну " зірку» — і отримати зручну структуру для BI. Іноді потрібно десь застосувати денормализацию (озираючись при цьому, як це вплине на завантаження), а де-то зробити вторинні вітрини та агрегати. Десь додати індекси або проекції (в залежності від СУБД).
Таким чином, шляхом «проб і помилок» можна отримати структуру, оптимальну для BI – яка врахує особливості як СУБД, так і BI-платформи, а також вимоги користувача за поданням даних.
Якщо ми дані ми беремо з «ядра», то така переробка вітрин буде носити локальний характер, ніяк не впливаючи на складну обробку первинних даних, отриманих безпосередньо з систем-джерел – ми лише «перекладаємо» дані в зручний для BI формат. І можемо собі дозволити зробити це безліч разів, різними способами, у відповідність з різними вимогами. На даних ядра робити це набагато простіше і швидше, ніж збирати з «первинки» (структура і правила якої, як ми знаємо, до того ж може «поплисти»).

Сервісний шар
Сервісний шар (на схемі — Service Layer) відповідає за реалізацію загальних (сервісних) функцій, які можуть використовуватися для обробки даних у різних шарах сховища – управління завантаженням, управління якістю даних, діагностика проблем і засоби моніторингу і т. п.
Наявність даного рівня забезпечує прозорість та структурованість потоків даних у сховище.
До цього шару відносять дві області зберігання даних:
  • область метаданих – використовується для механізму управління завантаженням даних;
  • область якості даних – для реалізації офф-лайн перевірок якості даних (тобто тих, що не вбудовані безпосередньо в ETL-процеси).
Можна по-різному вибудувати процес управління завантаженням. Один з можливих підходів такий: розбиваємо всі безліч таблиць сховища на модулі. В модуль можуть бути включені таблиці тільки одного шару. Таблиці, що входять до складу кожного модуля завантажуємо в рамках окремого процесу. Назвемо його керуючий процес. Запуск керуючого процесу ставиться на свій розклад. Керуючий процес оркеструє виклики атомарних процесів, кожен з яких завантажує одну таблицю, а також містить деякі загальні кроки.
Очевидно, що досить просто розділити таблиці staging на модулі – з систем-джерел, точніше їх точок підключення. Але для ядра це зробити вже складніше – т. к. там нам необхідно забезпечити цілісність даних, а значить потрібно враховувати залежності. Тобто будуть виникати колізії, які необхідно вирішувати. І є різні методи їх вирішення.
Важливим моментом у керуванні завантаженням є опрацювання єдиного підходу до обробки помилок. Помилки класифікуються за рівнем критичності. При виникненні критичної помилки процес повинен зупинитися, і як можна швидше, оскільки її виникнення говорить про істотну проблему, яка може призвести до псування даних у сховище. Таким чином, управління завантаженням – це не тільки запуск процесів, але і їх зупинка, а також запобігання несвоєчасного запуску (помилково).
Для роботи сервісного шару створюється спеціальна структура метаданих. У цій області буде зберігатися інформація про процеси завантаження, що завантажуються наборах даних, контрольні точки, які використовуються для ведення инкремента (який процес до якої точки дочитав) та інша службова інформація, необхідна для функціонування системи.
Важливо відзначити, що всі цільові таблиці у всіх шарах маркуються спеціальним набором мета-полів, один з яких ідентифікатор процесу, який актуалізував це рядок. Для таблиць всередині сховища таке маркування процесом дозволяє використовувати уніфікований спосіб подальшого виділення дельти змін. При завантаженні даних шар первинних даних справа йде складніше – алгоритм виділення дельти для різних завантажуваних об'єктів може бути різним. Зате логіка обробки прийнятих змін і їх накатка на цільові таблиці для ядра і вітрин куди складніше, ніж для стейджинга, де все досить тривіально – легко завдний і продумати повторно використовуються типові кроки (процедури).
Не ставлю завдання тут повністю висвітлити цю тему – організації завантаження – лише розставляю акценти, на які варто звернути увагу.
Наведений підхід – це лише один з варіантів. Він досить адаптивний. І його «концептуальним прототипом» послужив конвеєр Toyota і система «точно під час» (just-in-time). Тобто тут ми відходимо від широко розповсюдженої парадигми виключно «нічний завантаження даних», а завантажуємо невеликими порціями протягом дня, по мірі готовності даних у різних джерелах: що прийшло і завантажили. При цьому у нас працюють безліч паралельних процесів. А «гарячий хвіст» свіжих даних буде постійно «моргати» — і через якийсь час вирівнюватися. Ми повинні врахувати таку особливість. І у разі необхідності формувати власні вітринами «зрізами», де все вже цілісно. Тобто не можна одночасно досягти і оперативності, і консистентности (цілісності). Потрібен баланс – десь важливо одне, де щось інше.
Вкрай важливо передбачити кошти журналювання і моніторингу. Хорошою практикою є використання типізованих подій, де можна задати різні параметри і налаштувати систему повідомлень – підписку на певні події. Оскільки дуже важливо, щоб коли буде потрібно втручання адміністратора системи – він дізнався б про це якомога раніше і отримав всю необхідну діагностичну інформацію. Журнали також можуть використовуватися для аналізу проблем «пост-фактум», а також для розслідування інцидентів порушень працездатності системи, у т. ч. якості даних.

Проектування і ведення моделей даних сховища
Чому при розробці будь-якої системи, де задіяна база даних (а у сховищі – особливо), важливо приділяти увагу проектування моделей даних? Чому б просто не накидати набір таблиць, де завгодно – хоч в текстовому редакторі? Навіщо нам «ці картинки»?
Як не дивно, подібні запитання ставлять навіть досвідчені розробники.
Взагалі-то так, ніщо не заважає накидати таблиці і почати їх використовувати. Якщо… якщо при цьому в голові (!) у розробника є струнка загальна картина тієї структури, яку він різьбить. А що, якщо розробників кілька? А що, якщо ці таблиці буде використовувати хтось ще? А що якщо пройде час – людина залишить цю область, а потім до неї знову повернеться?
Чи можна розібратися без моделі? В принципі, можна. І розібратися, і «прикинути картинки на папірці», і «прошерстити — поселектить» дані. Але набагато простіше, зрозуміліше і швидше скористатися готовим артефактом – моделлю даних. А також розуміти логіку її влаштування» — тобто добре б мати загальні правила гри.
А найголовніше навіть не це. Найголовніше, що при проектуванні моделі ми змушені просто без варіантів!) більш щільно і глибоко вивчити предметну область, особливості пристрою даних та їх використання в різних бізнес-кейси. І ті питання, які ми з легкістю «відсунули» як складні, «замилили», накидаючи наші таблички, не намагаючись при цьому саме проектувати модель — ми будемо змушені поставити і вирішувати зараз, при аналізі і проектуванні, а не потім, коли будемо будувати звіти і думати про те, «як поєднати непоєднуване» і кожен раз «винаходити велосипед».
Такий підхід є однією з тих інженерних практик, які дозволяють створювати антихрупкие системи. Оскільки вони зрозуміло влаштовані, прозорі, зручні для розвитку, а також відразу видно «межі крихкості» — можна більш точно оцінити масштаби лиха» при появі нових вимог і час, необхідний для редизайну (якщо він знадобиться).
Таким чином, модель даних – один з основних артефактів, який повинен підтримуватися в процесі розвитку системи. По-хорошому, вона повинна бути «на столі» у кожного аналітика, розробника і т. д. – усіх, хто бере участь у проектах розвитку системи.
Проектування моделей даних – це окрема, дуже велика тема. При проектуванні сховищ використовуються два основних підходи.
Для ядра добре підходить підхід «сутність-зв'язок» — коли будується нормалізована (3NF) модель на основі саме дослідження предметної області, точніше виділеної області. Тут грає та сама «корпоративна модель», про яку йшлося вище.
При проектуванні аналітичних вітрин підходить багатовимірна модель. Цей підхід добре лягає на розуміння бізнес-користувачів – т. к. це модель проста і зручна для людського сприйняття – люди оперують зрозумілими і звичними поняттями метрик (показників) і розрізів, з яких вони аналізуються. І це дозволяє просто і чітко вибудувати процес збору вимог – ми малюємо набір «матриць розрізів і показників», спілкуючись з представниками різних підрозділів. А потім зводимо в одну структуру – «модель аналізу»: формуємо «шину вимірювань» і визначаємо факти, які на них визначені. Попутно опрацьовуємо ієрархії і правила агрегації.
Далі дуже просто перейти до фізичної моделі, додавши елементи оптимізації з урахуванням особливостей СУБД. Наприклад, для Oracle це буде секционирование, набір індексів і т. д. Для Vertica будуть використані інші прийоми – сортування, сегментація, секционирование.
Також може знадобитися спеціальна денормалізація — коли ми свідомо робимо надмірність у дані, завдяки яким покращуємо швидкодію запитів, але при цьому ускладнюємо оновлення даних (т. к. надмірність потрібно буде враховувати і підтримувати в процесі завантаження даних). Можливо, з метою покращення швидкодії, нам також доведеться створити додаткові таблиці-агрегати, або використовувати такі додаткові можливості СУБД як проекції в Vertica.
І далі над такою структурою досить просто налаштувати інструменти BI, за допомогою яких кінцевий користувач буде бачити і аналізувати дані.
Отже, при моделюванні даних сховища ми фактично вирішуємо кілька завдань:
  • завдання побудова концептуальної (логічної) моделі ядра — системний і бізнес-аналіз — дослідження предметної області, поглиблення в деталі і врахування нюансів «живих даних» та їх використання в бізнесі;
  • завдання побудови моделі аналізу – і далі концептуальної (логічної) моделі вітрин;
  • завдання побудови фізичних моделей – управління надлишковістю даних, оптимізація з урахуванням особливостей СУБД під запити і завантаження даних.
При розробці концептуальних моделей, ми можемо не враховувати особливості конкретної СУБД, для якої ми проектуємо структуру БД. Більше того, ми можемо використовувати одну концептуальну модель для створення декількох фізичних під різні СУБД.
Резюмуємо.
  • Модель даних – це не набір красивих картинок», а процес її проектування – це не процес їх малювання. Модель відображає наше розуміння предметної області. А процес її складання – це процес її вивчення і дослідження. Ось на це витрачається час. А зовсім не на те, щоб «намалювати і розфарбувати».
  • Модель даних – це проектний артефакт, спосіб обміну інформацією в структурованому вигляді між учасниками команди. Для цього вона повинна бути всім зрозуміла (це забезпечується нотацією і поясненням) і доступна (опублікована).
  • Модель даних не створюється один раз і заморожується, а створюється і розвивається в процесі розвитку системи. Ми самі ставимо правила її розвитку. І можемо їх змінювати, якщо бачимо – як зробити краще, простіше, ефективніше.
  • Модель даних (фізична) дозволяє консолідувати і використовувати набір кращих практик, спрямованих на оптимізацію – тобто використовувати ті прийоми, які вже спрацювали для даної СУБД.
Особливості проектів сховищ даних
image
Зупинимося на особливостях проектів, в рамках яких в компанії будується і розвиваються сховища даних. І подивимося на них з точки зору впливу архітектурного аспекту. Чому для таких проектів важливо вибудовувати архітектуру, причому з самого початку. І саме наявність добре продуманої архітектури надає гнучкість проекту сховища даних, що дозволяє ефективно розподіляти роботу між виконавцями, а також простіше прогнозувати результат і робити процес більш передбачуваним.

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

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

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

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

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

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

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

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.