У цьому розділі описано 8 ситуацій, коли зусилля зі створення сховища даних приречені на невдачу, часто попри найкращі наміри.
1. Зосередження на ідеології, а не на практиці
Існує багато хороших підручників зі сховищ даних, і багато шкіл пропонують курси зі сховищ даних. Однак, прочитання підручників чи проходження курсів не робить людину гуру сховищ даних.
Наприклад, я бачив, як хтось наполягав на застосуванні правил зовнішнього ключа між таблицями розмірностей і таблицями фактів, починаючи з першого дня розробки. Це не є розумним з кількох причин: 1) Середовище розробки за своєю природою передбачає багато ігор з даними – багато оновлень, видалень і вставок. Обмеження зовнішнього ключа лише затягує процес розробки довше, ніж потрібно. 2) Це сповільнює час завантаження ETL. 3) Це обмеження є марним, тому що коли дані завантажуються в таблицю фактів, ми вже повинні перейти до таблиці розмірностей, щоб отримати відповідний зовнішній ключ, таким чином, ми вже виконали те, що мало б бути зроблено за допомогою обмеження зовнішнього ключа.
2. Ускладнення процесу без потреби
Сховище даних за своєю суттю є досить складним проектом, і не потрібно його ще більше ускладнювати.
Наведемо приклад: Вихідний файл містить один факт. Особа, відповідальна за управління проектом, наполягає на тому, щоб цей факт був розбитий на кілька різних метрик під час ETL. Ідеальний варіант звучить розумно: Скоротити кількість рядків у таблиці фактів, щоб інтерфейсний інструмент міг швидше згенерувати звіт. На жаль, з таким підходом є кілька проблем: По-перше, ETL став невиправдано складним. Мало того, що в ETL тепер потрібні оператори типу case, так ще й через те, що факт не завжди можна розбити на відповідні метрики через неузгодженість даних, виникла потреба створити багато логіки, щоб подбати про винятки. По-друге, ніколи не рекомендується розробляти модель даних і процес ETL на основі того, що найбільше підходить для фронт-енд інструменту. По-третє, в кінцевому підсумку, у звітах доводилося підсумовувати ці окремі метрики, щоб отримати те, що дійсно потрібно користувачам, а це означає, що вся додаткова робота була марною.
3. Відсутність чіткого права власності
Оскільки проекти зі створення сховищ даних зазвичай зачіпають багато різних відділів, цілком природно, що в проекті беруть участь кілька команд. Однак для того, щоб проект був успішним, необхідно чітко визначити відповідальність за нього. Не чітке володіння різними компонентами проекту, а самим проектом. Я бачив випадок, коли кілька груп володіють частиною проекту, кожна з яких є власником частини проекту. Зрозуміло, що такі проекти ніколи не завершувалися так швидко, як мали б, мали тенденцію до недовиконання, мали негнучку інфраструктуру (оскільки кожна група робила те, що найкраще для неї, а не для проекту в цілому). Я бачив, що результатом таких проектів є те, що вони пристосовані для того, щоб перекладати відповідальність на інших. Якщо щось не так, то завжди винна інша група. Зрештою, ніхто ні за що не відповідає, і не дивно, чому проект сповнений проблем. Переконатися в тому, що одна людина/одна група несе повну відповідальність за успіх проекту зі створення сховища даних, має першорядне значення для забезпечення успішності проекту.
4. Нерозуміння правильного протоколу
Незалежно від того, чи працюєте ви як консультант, чи як внутрішній ресурс, вам потрібно розуміти протокол організації, щоб побудувати успішне сховище даних / вітрину даних.
Я брав участь у проекті, де команда вважала, що вся розробка завершена, протестована, задокументована, перенесена у виробничу систему і готова до здачі в строк, і була готова відсвяткувати бонусні гроші, які клієнт обіцяв за вчасну здачу. Однак було упущено одну річ: клієнт завжди вимагає, щоб будь-яка виробнича система спочатку пройшла через його QA-групу. Керівник проекту в цьому випадку цього не помітив. Таким чином, замість того, щоб завершити проект вчасно і в рамках бюджету, його довелося затримати ще на чотири місяці, перш ніж запустити онлайн, і все через те, що керівництво проекту не було знайоме з організаційним протоколом.
5. Не повне розуміння впливу проекту до його початку
Тут я говорю про те, що вплив проекту виявляється набагато меншим, ніж очікувалося. Я бачив спроби створення дата-маркетів, коли в проект було вкладено значну кількість ресурсів, а по завершенню проекту було лише два користувачі. Це явно той випадок, коли хтось не зробив правильного вибору, оскільки ці ресурси явно можна було б краще використати в інших проектах.
6. Намагайтеся відкусити більше, ніж можете прожувати
Це означає, що проект намагається досягти чогось більш грандіозного, ніж передбачалося. Нижче наведено два приклади:
Існують проекти сховищ даних, які намагаються контролювати весь проект – аж до того, що диктують, як має бути побудована вихідна система для збору даних, і як саме ці дані мають бути зібрані. Хоча ідея благородна – часто під час проекту ми виявляємо, що дані вихідної системи мають багато проблем, і тому є сенс переконатися, що вихідна система побудована правильно – в реальності це не практично. По-перше, вихідні системи побудовані так, як вони є, з певних причин – і аналіз даних повинен бути лише одним із завдань, а не єдиним. Крім того, це призведе до того, що система зберігання даних буде гарною в теорії, але дуже негнучкою в реальності.
У цьому ж ключі я бачив, як власник проекту намагається нав’язати власні ідеї решті компанії, а потім доручає своїй команді побудувати систему таким чином, щоб вона враховувала цю можливість. Звичайно, насправді відбувається те, що ніхто не приймає його ідеї, і багато часу та зусиль було витрачено даремно.
7. Сліпе дотримання певних стандартів
Я бачив випадки, коли цілеспрямовані зусилля докладаються до того, щоб різні вітрини даних використовували однакову інфраструктуру, починаючи від інструментів, що використовуються (наприклад, певний інструмент ETL повинен використовуватися для виконання ETL, незалежно від того, наскільки простим є цей процес), і закінчуючи користувацьким досвідом (наприклад, користувачі повинні мати доступ до однакового набору критеріїв вибору звітів).
Це абсурдний спосіб побудови вітрин даних. Сама причина існування різних вітрин даних полягає в тому, що між ними існують відмінності, тому наполягати на тому, щоб усі вони відповідали певному стандарту, – марна справа. Я бачив, як ETL-інструменти сліпо накладали на ETL-процеси, які вимагають лише серії SQL-запитів.
Що стосується інтерфейсу, то це має ще менше сенсу. По-перше, різні проекти, навіть якщо вони можуть бути дуже схожими, все одно різні. Інакше вони належали б до одного проекту. Крім того, користувачам насправді байдуже, чи мають їхні уявлення про різні вітрини даних однаковий вигляд і відчуття. Їх хвилює лише те, чи дані з’являються там вчасно і чи є цифри достовірними.
8. Погане управління проектами
Погане управління проектами може проявлятися кількома способами, і деякі з наведених вище прикладів ілюструють небезпеку поганого управління проектами. Коротше кажучи, можна з упевненістю сказати, що поганий керівник проекту прирече проект на провал.
Для проектів зі створення сховищ даних ключовим є досвід, особливо практичний. Це не робота для тих, хто щойно закінчив програму MBA, або для тих, хто лише прочитав усі книжки про сховища даних, але не мав практичного досвіду.
ОРИГІНАЛ СТАТТІ:Recipes For Failure – Why Data Warehouses Fail
🚀Долучайтесь до нашої спільноти Telegram:
🚀Долучайтесь до нашої спільноти FaceBook:
