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

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

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

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

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

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.

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

Епілог

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

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

В останніх п'ять днів мене мучить повідомлення: “Не вдається створити резервну копію для цього iPhone/iPad/iPod, тому що в iCloud недостатньо вільного місця”. Я це сповіщення наполегливо ігнорував, але настав час не тільки з ним розправитися, а й розповісти про вирішення цієї проблеми докладніше.

Недостатньо вільного місця в iCloud. Що робити?

Змінити план сховища

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

Зараз у мене підключено 50 гігабайт за 59 рублів на місяць і для мене це комфортна ціна за достатню мені кількість гігабайт. Якщо платити 169 рублів, то буде доступно 200 гігабайт. Але я вирішив себе стримувати. Не тому, що мені шкода 169 рублів, а тому, що 50 гігабайт у хмарі дозволить вчасно проводити чистки медіатеки, не пускати все на самоплив.

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

Налаштування->iCloud->Сховище->Змінити план сховища

Чищення медіатеки iCloud

Саме медіатека iCloud найчастіше займає більшу частину місця у хмарі. Особливо, якщо у вас до хмари підв'язаний iPhone. ;)

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

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

Одна фотка або 1 секунда відео займає приблизно 2 мегабайти. Отже, видалення навіть 100 знімків дасть зайві 200 мегабайт.

Якщо файли такі цінні, чому б не викачати їх через сайт iCloud.com і залити на окремий диск? Чомусь впевнений, що більшості людей не потрібна у медіатеці більша частина контенту.

Видалення/зменшення резервної копії пристроїв

З видаленням, гадаю, все зрозуміло. Рідко, але буває, що для якогось пристрою немає сенсу робити резервну копію. Наприклад, у мене є iPod – зараз він служить виключно для музики. Сенс мені робити резервну копію цього пристрою? Також потрібно видаляти резервні копії тих пристроїв, які вам більше не належать (наприклад, продали).

Видалення резервної копії відбувається в налаштуваннях:

Налаштування->iCloud->Сховище->Керувати. Вибираємо копію та натискаємо кнопку “Видалити копію”. Ви можете видаляти копії інших пристроїв, підключених до Apple ID.

Але резервну копію в iCloud можна зменшити:

Налаштування->iCloud->Сховище->Керувати.Вибираємо копію поточногопристрої. Внизу з'являється список програм, дані яких потрапляють в резервну копію. Відключаємо ту частину програм, які не повинні на вашу думкуробити бекапи в iCloud. Дивіться на скріншот нижче: за рахунок відключення частини програм від iCloud я зменшив резервну копію на 1.5 гігабайта.

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

Видалення файлів із iCloud Drive

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

Заходимо до програми iCloud Drive. Якщо його немає, увімкніть відображення в налаштуваннях: Установки->iCloud->iCloud Drive->На екрані “Додому”.

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

Налаштування->iCloud->Сховище->Керувати. Розділ "Документи та дані".

Видалення поштових повідомлень

Ця порада вже з особистого досвіду. Мені Apple якось самостійно створила скриньку в домені iCloud.com. Цілком непотрібна мені поштова скринька. Дивно, як він пережив ці всі роки, але я періодично забув його відключати. І іноді випадково ним користуюся, коли з телефону надсилаю файли поштою. Таким чином я примудрився зайняти в iCloud більше 300 мегабайт. (Дивимося тут: Налаштування->iCloud->Сховище->Керувати->Mail)

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

Підсумок

Це всі поради та способи трохи розвантажити iCloud. Усім добра і більше вільного часу та місця!

Всім привіт! Резервні копії робити потрібно – це факт. І, як ми знаємо, компанія Apple пропонує нам два чудові варіанти резервного збереження інформації – за допомогою iCloud або iTunes. І якщо з iTunes все більш-менш зрозуміло – підключили до комп'ютера та ОК, то з iCloud можуть бути проблеми. Які? Найрізноманітніші.

Наприклад, зовсім недавно мій iPhone почав «радувати» мене повідомленням з таким текстом: «iPhone – збій резервного копіювання. У сховищі iCloud недостатньо вільного простору для збереження резервних копій даних iPhone». Знімаєш телефон із зарядки, а тут ось така помилка. Місця йому бачите чи не вистачає!

Погляньмо, чому це відбувається і що взагалі з усім цим можна зробити? Поїхали ж!

Загальна інформація або чому відбувається збій копіювання iCloud?

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

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

Але розмір цього сховища не безкінечний – для будь-якого користувача компанія Apple безкоштовно виділяє лише 5 гігабайт. І ось коли ви не вкладаєтеся в ці рамки, то з'являється помилка "Збій резервного копіювання - недостатньо вільного простору".

Що можна зробити та як виправити збій?

Є кілька варіантів позбавиться помилки резервного копіювання.

Спосіб №1 – Заплатити

Усі хочуть грошей і Apple не є винятком. За порівняно невелику суму можна просто змінити свій тарифний план iCloud і перейти з безкоштовного (5 ГБ) на будь-який інший тариф з великим обсягом пам'яті. Так би мовити, докупити зайве місце у «хмарі». Як це зробити?

Відкриваємо «Налаштування – Ваш обліковий запис – iCloud – Сховище – Купити ще місце» та вибираємо тариф, який підходить саме вам.

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

Спосіб №2 – Безкоштовний, але відносно довгий

Чи не хочете нікому платити? Цілком розумію ваше бажання – грошей багато не буває, а тут ще Apple списуватиме абонентку щомісяця. Зовсім очманіли!

Що ж, можна безкоштовно. Але тоді доведеться «вкластися» у 5 ГБ хмарного сховища. Для цього переходимо в «Налаштування – Ваш обліковий запис – iCloud – Сховище – Управління» та дивимося, які документи та дані там зберігаються.

Бачите, як щось зайве займає дороге місце? Сміливо вимикайте.

Також варто звернути увагу на «Медіатеку iCloud» (Налаштування – Фото та Камера). Якщо ця опція включена, то ваші фотографії та відео примусово відправляються в «хмару», тим самим з'їдаючи простір сховища.

Але іноді може статися ситуація, як у мене – вільного місця аж 4,9 ГБ (з 5 ГБ безкоштовних), а при створенні резервної копії iCloud все одно відбувається збій. Чому це відбувається? Справа в тому, розмір наступної копії набагато більше ніж 5 ГБ - iPhone не може її створити так як вона не поміститься у відведений ліміт.

Ви також можете подивитися у себе цю інформацію, відкривши вкладку «Резервні копії» в Сховищі iCloud. Більше того, тут завжди можна підкоригувати дані з яких складатиметься копія (для того, щоб «вкластися» у відведені 5 ГБ) і, можливо, у вас це навіть вийде!

Спосіб №3 – Безкоштовний та швидкий

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

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

Для цього відкриваємо «Налаштування – Ваш обліковий запис – iCloud» та пересуваємо повзунок навпроти відповідного пункту меню.

Все, жодних збоїв більше не буде. Перемога!

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

P.S. Хочеш більше вільного безкоштовного місця в iCloud? Я теж! Об'єднаємо наші зусилля – ставимо лайк і тиснемо на кнопки соціальних мереж. Я свій «+1» уже поставив, справа за вами!

P.S.S. Після прочитання статті залишилися чи постали якісь питання? Обов'язково пишіть у коментарі – намагатимемося розібратися всі разом!

Коли-небудь настане момент, коли ви захочете змінити свій тарифний план iCloud. Це можна зробити як через iOS, так і через MacOS.

При створенні облікового запису iCloud ви безкоштовно отримуєте 5Гб пам'яті в сховищі, де можна зберігати копії своїх даних, включаючи фото та документи. Залежно від того, скільки у вас пристроїв ці 5Гб швидко заповняться. Apple також пропонує три платні передплати: на 50Гб, 200Гб та 2Тб. Також можна оформити передплату на 200Гб або 2Тб на всю родину.

Як змінити тарифний план iCloud у iOS

Для початку потрібно зайти в Налаштуванняна своєму iPhone чи iPad.

1) Зайдіть у секцію Облікові записи та паролі.

2) Виберіть свій акаунтiCloud.

3) Зайдіть у Сховище.

4) Тут ви побачите загальний обсяг сховища та доступну пам'ять. Вибравши Управління, Ви зможете подивитися, на що йде найбільше вільної пам'яті.

5) Поверніться на екран Сховище та натисніть Придбати ще місце.

6) На цьому екрані ви побачите свій тарифний план та список доступних. Ви також зможете відмовитись від своєї платної підписки.

7) Виберіть передплату, яка вам подобається.

8) Натисніть Придбатиу правому верхньому кутку екрана. Після цього з'явиться підтвердження набуття нового тарифного плану.

9) Щоб скасувати свої дії, натисніть Назад у лівому верхньому куті екрана.

Як змінити тарифний план iCloud на Mac

1) Зайдіть в меню Apple та виберіть Системні налаштування >iCloud.

2) Виберіть Управлінняу нижньому правому кутку вікна.

3) Виберіть Придбати ще місцев правому верхньому куті.

4) На наступному екрані ви побачите свій тарифний план та всі доступні.

5) Якщо ви бажаєте розширити сховище, виберіть передплату та натисніть Далі.

6) Введіть свій пароль Apple ID та натисніть Придбати.

7) Щоб відмовитися від платної передплати, натисніть Вибрати безкоштовний план, виберіть передплату, а потім натисніть Готово.

Про зменшення обсягу сховища

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

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

Компанія Apple надає своїм користувачам 5 Гб безкоштовного місця у хмарному сховищі iCloud. Однак, на жаль, цього обсягу вистачає не кожному. Коли сховище майже заповнене, нові резервні копії перестають створюватися, і у користувача постає питання: що робити, і тут є два шляхи – очистити «хмару» від старих непотрібних даних, звільнивши місце для нових, або купити додатковий обсяг сховища iCloud.

У цій статті розповімо, як правильно діяти і в тій, і в іншій ситуації.

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

Для здійснення цієї схеми, якщо ви вирішили видалити непотрібний контент:

Якщо ви хочете перенести контент на комп'ютер:

1. Підключіть девайс до ПК, відкрийте через розділ "Мій комп'ютер".
2. Скопіюйте вміст на комп'ютер і видаліть його класичним способом.
3. Виконайте третій крок попередньої інструкції.

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

Отже, як очистити місце у сховищі iCloud, використовуючи це меню:

1. Відкриваємо "Налаштування" айфона або іншого iOS-гаджета.
2. Якщо ваш девайс працює на iOS 10.3 і пізніших версіях платформи, топаємо своє ім'я, далі iCloud, в іншому випадку, натискаємо відразу iCloud — в обох випадках на самому вершині ви побачите статистику використовуваного простору.
   
3. Тиснемо розділ «Сховище», далі «Управління».
   
4. Тепер топаємо по резервній копії - перед вами з'явиться список усіх програм, дані яких зберігаються в ній. Тут ви й отримаєте відповідь на питання, чому сховище так швидко заповнилося — за замовчуванням девайс бекапіт масу інформації, зберігання якої користувач зовсім не потребує, але не переживайте, зараз ми візьмемо справу в свої руки.
   
5. Отже, для звільнення місця потрібно відключити повзунки навпроти всіх програм, дані в яких ми не хочемо бекапити. При появі діалогового вікна тиснемо «Вимкнути та видалити».
6. Після того, як чистка виконана, прокручуємо в самий низ і тиснемо "Видалити копію". Не хвилюйтеся, зараз ми створимо нову з новими вашими налаштуваннями.
7. Відкрийте розділ iCloud у меню «Налаштування», виберіть «Резервна копія в iCloud», натисніть посилання «Створити резервну копію».
   

Готово! Тепер у хмарі зберігається лише те, що вам потрібне.

Хороша порада! Не зберігайте свої фото та відео в «хмарі» — вони займають багато місця, а рано чи пізно їх все одно доведеться скидати на комп'ютер. Якщо вам важливо, що цей тип контенту зберігався в iCloud, рекомендуємо включити налаштування «Оптимізація сховища…», якщо ви раніше не користувалися ним. Для її активації зайдіть у iCloud, далі "Фото", поставте галочку навпроти параметра "Оптимізація сховища ...".

Як збільшити обсяг сховища?

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

Apple пропонує три тарифи:

• 50 Гб за 59 рублів на місяць
• 200 Гб за 149 рублів на місяць
• 2 ТБ за 599 рублів на місяць

Для того, щоб купити більше місця в айклауд:

Ось і все – як бачите, користуватися iCloud у плані очищення та придбання нового місця дуже просто!

Підсумуємо

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