Поради щодо успішного впровадження LuckyTemplates

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

Зміст

• Дизайн набору даних для реалізації проекту LuckyTemplates
  • 4 кроки до розробки набору даних
  • Виберіть бізнес-процес.
    • Антишаблон, якого слід уникати в реалізації LuckyTemplates
  • Задекларувати зерно.
  • Визначте розміри.
  • Визначте факти.
• Матриця шини даних для реалізації проекту LuckyTemplates
• Профілювання даних для впровадження LuckyTemplates
  • Служби інтеграції SQL Server
  • Студія DAX
  • LuckyTemplates робочий стіл
• Планування набору даних для впровадження LuckyTemplates
  • Вибір режиму набору даних
  • Деякі запитання, які слід поставити під час вибору режимів набору даних
• Висновок

Дизайн набору даних для реалізації проекту LuckyTemplates

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

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

4 кроки до розробки набору даних

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

Виберіть бізнес-процес.

На першому етапі кожен бізнес-процес представляється таблицею фактів із зірковою схемою розмірів.

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

Антишаблон, якого слід уникати в реалізації LuckyTemplates

Загальний антишаблон (який є відповіддю на повторювану проблему, яка зазвичай є неефективною та потенційно контрпродуктивною), якого потрібно уникати в проектах LuckyTemplates, — це розробка наборів даних для конкретних проектів або команд, а не для бізнес-процесів .

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

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

Незважаючи на те, що аналітичні потреби користувачів або команд є пріоритетом проектів LuckyTemplates, також важливо планувати стійкі рішення, які в кінцевому підсумку можуть бути спільно використані командами.

Задекларувати зерно.

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

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

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

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

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

Визначте розміри.

Розміри є лише природним побічним продуктом зерна, вибраного на попередньому етапі проектування.

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

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

Визначте факти.

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

Матриця шини даних для реалізації проекту LuckyTemplates

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

Архітектура, яку ви бачите тут, взята з The Data Warehouse Toolkit , 3rd edition by Ralph Kimball. Це дозволяє використовувати масштабовані моделі даних, які часто потрібні кільком бізнес-командам або функціям для доступу до тих самих бізнес-процесів і параметрів.

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

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

Профілювання даних для впровадження LuckyTemplates

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

Технічні метадані, включаючи діаграми баз даних і результати профілювання даних, важливі для етапу планування проекту.

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

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

Служби інтеграції SQL Server

Є кілька способів зробити це. Одним із методів є використання завдання профілювання даних у пакеті служб інтеграції SQL Server (SSIS).

Завдання профілювання даних вимагає з’єднань ADO.NET і може записати свій вихід у файл XML або змінну SSIS.

У цьому прикладі вихідними даними ADO.NET є сховище даних, база даних і SQL-сервер AdventureWorks, а місцем призначення є XML-файл.

Тож після виконання завдання XML-файл можна буде прочитати за допомогою засобу перегляду профілю даних SQL-сервера. Ви можете побачити результати в термінах нульової кількості та відсотків нульової кількості.

Студія DAX

Ще один спосіб профілювання даних — за допомогою DAX Studio. вам потрібно фактично ввести дані в набір даних LuckyTemplates, перейшовши до DAX Studio, перейшовши на вкладку розширених і запустивши .

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

LuckyTemplates робочий стіл

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

Планування набору даних для впровадження LuckyTemplates

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

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

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

Щоб уточнити процес планування набору даних, ця діаграма визначає різні рівні сховища даних і набору даних LuckyTemplates, де можна реалізувати трансформацію та бізнес-логіку.

у деяких проектах потрібна мінімальна трансформація, і її можна легко включити в набір даних power BI. Наприклад, якщо для таблиці розмірів потрібні лише кілька додаткових стовпців і є чіткі вказівки щодо того, як ці стовпці обчислюватимуться, ІТ-організація може вибрати впровадження цих перетворень у запитах потужності M, а не переглядати сховище даних.

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

Розробники наборів даних повинні регулярно аналізувати та повідомляти про наслідки наборів даних, якщо вони мають більший рівень складності.

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

Наприклад, проміжна таблиця та процедура зберігання SQL можуть знадобитися для підтримки, перегляду та оновлення процесу, або створення індексу може знадобитися для покращення продуктивності запитів для наборів даних DirectQuery.

Вибір режиму набору даних

Подальшим, але тісно пов’язаним кроком до планування набору даних є вибір між режимом імпорту за замовчуванням, DirectQuery/живим режимом або складеним режимом.

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

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

Так само, якщо видимість джерела даних майже в реальному часі є важливою, тоді DirectQuery або живий режим є єдиним варіантом для досягнення цього. режими DirectQuery та live дуже схожі один на одного. Обидва методи не зберігають дані в самому наборі даних, і обидва запитують вихідні системи безпосередньо для отримання даних на основі дій користувача. Тепер у нас є DirectQuery для наборів даних LuckyTemplates і DirectQuery для Analysis Services.

Деякі запитання, які слід поставити під час вибору режимів набору даних

Ось кілька запитань, які слід поставити, коли ви вирішуєте, який режим використовувати. чи є єдине джерело для нашого набору даних? Якщо єдиного джерела немає, це означає, що раніше ви не могли використовувати джерело DirectQuery/Live.

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

Якщо доступним є джерело DirectQuery/Live, чи здатне джерело підтримувати аналітичні запити? Якщо ви працюєте з мільярдами або трильйонами рядків, то, можливо, набір даних у режимі імпорту неможливий, і вам доведеться перейти до режиму DirectQuery або композитного режиму, щоб переконатися, що набір даних придатний для використання.

Якщо джерело DirectQuery/Live здатне підтримувати робоче навантаження, чи з’єднання DirectQuery/Live є більш цінним, ніж продуктивність і гнучкість, надані моделлю імпорту?

Висновок

Ця публікація завершує цю серію про планування проектів LuckyTemplates. Я вважаю, що це важливі кроки для кожного проекту Power BI, над яким ви працюєте. Ці кроки є важливими під час проведення належної перевірки, особливо в умовах бізнес-аналітики підприємства.

Все найкраще,

Грег Деклер