Популярні питання

Перша зустріч – це відверта розмова. Ми ставимо питання про бізнес-контекст, поточні проблеми та очікуваний результат, ви розповідаєте про своє бачення. На виході маємо розуміння з обох сторін, як підійти до задачі.

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

Lakehouse поєднує принципи data lake і data warehouse: дає змогу працювати з великими масивами різнотипних даних і водночас підтримувати структуровану аналітику. Але універсально кращого варіанта немає: вибір між data lake, data warehouse і data lakehouse залежить від типів даних, задач аналітики та вимог до архітектури.

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

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

Підтримка після релізу – окремий напрямок роботи. За потреби підписуємо SLA і беремо відповідальність за uptime, усунення багів та оновлення. Формат залежить від проєкту: десь потрібна реакція протягом години, десь достатньо регулярного перегляду логів раз на тиждень. Тривалість теж гнучка: від кількох місяців до довгострокового супроводу.

Послідовно: спершу аудит поточних систем, щоб зрозуміти, які джерела даних критичні. Далі – вибір архітектури під масштаб бізнесу. Потім побудова ETL/ELT-конвеєрів, які переносять і трансформують дані. І тільки в кінці – підключення BI-шару для дашбордів і звітів. Пропуск аудиту або спроба почати одразу з BI підвищують ризик того, що платформа буде побудована на неузгоджених даних і потребуватиме переробки вже після запуску.

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

RLS обмежує доступ до окремих рядків моделі даних залежно від ролі користувача. Тому один і той самий звіт може показувати різні дані різним людям.

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

Створіть RLS-роль, задайте правило фільтрації, протестуйте його, опублікуйте модель і призначте користувачів або групи до ролі в Power BI Service. Окремо перевірте їхні права в робочому просторі та доступ до звіту.

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

У внутрішніх системах обмежуємо доступи та впроваджуємо багаторівневу авторизацію. У BI ізолюємо середовища і контролюємо права аж до рівня окремих дашбордів. В e-commerce – захист API, шифрування платежів, аудит трафіку. Працювали з банками, держструктурами та юридичними компаніями, де вимоги до безпеки особливо жорсткі.

У статичному RLS правило фільтрації закріплене за роллю. У динамічному воно може змінюватися залежно від користувача, наприклад через USERPRINCIPALNAME() і таблицю відповідності.

Для цього використовують RLS Power BI: правила моделі визначають, які дані побачить користувач після входу.

У Power BI Desktop використовуйте View as, щоб перевірити звіт від імені ролі. Після публікації роль також можна протестувати у Power BI Service.

Типові помилки: помилка в DAX-фільтрі, некоректно призначені ролі робочого простору, застаріла таблиця відповідності та спроба замінити RLS звичайними фільтрами у звіті.

DAX (Data Analysis Expressions) — мова формул для розрахунків у Power BI. DAX працює з таблицями, стовпцями та зв'язками моделі даних, а результат мір змінюється залежно від поточних фільтрів звіту.

DAX дозволяє створювати власні бізнес-метрики: наприклад, розраховувати маржинальність, порівнювати показники між періодами або будувати наростаючий підсумок. Power BI може працювати і без власних DAX-формул, але DAX у Power BI потрібен для розрахунків, яких немає у вихідних даних і які мають змінюватися залежно від фільтрів звіту.

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

Достатньо впевнено володіти базовим набором: CALCULATE (зміна контексту фільтрів), SUM і SUMX (агрегація), DIVIDE (безпечне ділення) та функціями часової аналітики — SAMEPERIODLASTYEAR, DATESYTD, TOTALYTD.

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