Якщо Power BI при кожному оновленні очищає назви, зшиває довідники й відновлює логіку, якої немає в джерелі, звіт стає крихким. Він працює, доки в джерелі нічого не змінилося. Частину цієї роботи треба винести в модель даних і правила підготовки, а частину повернути туди, де помилки виникають.
Як виглядає BI, який «лікує» джерела
Умовний, але дуже впізнаваний приклад. Звіт про отримувачів послуг будується з реєстру. У Power Query (редактор підготовки даних у Power BI) кілька десятків кроків: прибрати пробіли на початку назв, звести «м. Київ», «Київ» і «КИЇВ» до одного значення, підтягнути коди областей з окремого файлу, відфільтрувати тестові записи за словом «тест» у прізвищі.
Звіт показує гарні цифри. Але подивіться на ознаки:
- Десятки кроків заміни значень. Кожне оновлення заново виправляє ті самі помилки, бо в джерелі їх ніхто не виправив.
- Довідник відповідностей в Excel. Таблиця «як було, як має бути» лежить поруч зі звітом, часто з назвою на кшталт
mapping_final_v3.xlsx. Власника в неї немає, крім автора звіту. - Те саме очищення в кількох звітах. Кожен аналітик пише свою версію, трохи інакше. Джерело одне, а цифр на нараді дві.
- Визначення показників живуть у DAX (мові формул Power BI). Хто вважається отримувачем, який статус активний, на яку дату рахуємо: це вирішує міра у звіті, а не погоджене правило.
- Оновлення ламається в понеділок зранку, бо в джерелі перейменували колонку або додали нове написання.
Якщо ви впізнали дві-три ознаки, звіт тримається на одному файлі й одній людині.
Чому це крихко
Це схоже на пляму на стелі від даху, що протікає. Можна щомісяця її перефарбовувати, і стеля виглядатиме охайно. Але дах так і тече, а фарба коштує щоразу.
Аналогія неідеальна: пляму на стелі бачать усі, а виправлення в Power Query бачить лише автор файлу. І кожна кімната фарбується своєю фарбою, тобто кожен звіт очищує дані по-своєму.
Звідси чотири практичні наслідки:
- Помилка в джерелі живе вічно. Ті, хто вводить дані, не дізнаються, що вводять їх неправильно.
- Різні звіти дають різні цифри, бо очищення в них трохи різне.
- Знання зосереджене в одній людині. Відпустка або звільнення автора, і звіт перетворюється на чорну скриньку.
- Оновлення стає повільним і непередбачуваним, бо важка підготовка виконується щоразу в кожному звіті.
Що залишити в Power Query, а що винести
Виносити все підряд не треба. Корисне питання одне: чи користується цим правилом ще хтось, крім цього звіту?
Залишити в BI:
- форматування, підписи, порядок категорій для візуалів;
- фільтри, що стосуються лише цього звіту;
- легке перетворення таблиці під конкретний графік;
- міри, які описують відображення, а не визначення показника.
Винести в модель даних і шар підготовки:
- нормалізацію значень: назви, регістр, формати дат і номерів;
- довідники відповідностей, у таблиці з власником, а не в чиємусь файлі;
- пошук і обробку дублікатів;
- визначення показників: хто отримувач, який статус активний, на яку дату зріз;
- з'єднання даних з різних систем.
Повернути в джерело:
- помилки, які повторюються з кожним завантаженням. Їх треба виправляти там, де вводять: правилом у формі, довідником замість вільного тексту, перевіркою під час введення.
Умовний приклад шарів підготовки
Схема нижче не прив'язана до конкретного інструмента. Це може бути база даних, потоки даних (dataflows) у Power BI чи окреме сховище. Порядок важливіший за технологію.
- Сирий шар. Копія даних з джерела як є, з датою завантаження. Тут нічого не виправляємо, щоб завжди можна було перевірити, що прийшло.
- Очищений шар. Правильні типи, формати й нормалізовані значення. Довідники відповідностей підключаються тут, і в кожного є власник.
- Шар бізнес-логіки. Визначення показників і таблиці, з яких будуються звіти: хто отримувач, які статуси, яка дата зрізу. Одне визначення для всіх звітів.
- BI. Візуалізація, фільтри й міри поверх готової моделі. Звіт показує, а не ремонтує.
Окремо від шарів варто вести список помилок, знайдених під час очищення. Він іде власнику джерела, щоб кількість виправлень з часом зменшувалася, а не росла.
Як почати без великої перебудови
- Відкрийте Power Query свого головного звіту і позначте кожен крок: формат, очищення чи бізнес-логіка.
- Знайдіть кроки, які повторюються у двох і більше звітах. Їх виносьте першими: вони вже коштують вам різних цифр.
- Ручні таблиці відповідностей перенесіть в одне місце і призначте їм власника.
- Складіть перелік помилок, які звіт виправляє щоразу, і передайте його власнику джерела.
- Те, що залишилося в звіті, має стосуватися лише показу.
Після кількох таких кроків бізнес-аналітика знову займається тим, для чого вона потрібна: допомагає приймати рішення. А правила підготовки стають частиною архітектури даних, а не секретом одного файлу.
Питання до вас: скільки кроків у вашому найбільшому Power Query і скільки з них насправді лікують джерело?