Як одна надмірно використана семантична модель, безумовно, зіткнулася з нашими можливостями BI ... і що ми дізналися. The Monday Morning Spike Понеділок зранку Spike Більше 300 магазинів по всій США готувалися до наступного тижня, друкуючи щоденні звіти про продаж та інвентаризацію з Power BI. Повернувшись до штаб-квартири, день почався, як і будь-який інший - тиха гума моніторів, перші коктейлі кави, вхідні ящики заповнюються. Перше повідомлення прийшло після цього. “Hey, my report’s not loading - can you please check, I need it for a meeting?” Через кілька хвилин – інший. “Hey, PowerBI is slow - can you please bump up the capacity ?” Потім ще три. У вікні Teams з'явився формат черги на допомогу, який став помітний протягом десяти хвилин. Я отримав доступ до панелі, щоб знайти незначну проблему, яку я очікував побачити.Все діапазон діаграму показав червоні значення. Fabric capacity Utilization had spiked to 350 %, and I was completely taken aback. Додаток став безвідповідальним, а сторінковані звіти зайняли занадто довго, щоб завантажити, а платформа BI, яка підтримувала 300 магазинів, зазнала критичних проблем з продуктивністю. The day had just started, and we were already in firefighting mode. Tracing the Problem Першим кроком було відкриття Графи використання показали найвище використання, тому що одна обчислювальна одиниця робочого простору раптово досягла своєї максимальної потужності. Fabric Capacity Metrics dashboard Поглиблюючись, ми знайшли one dataset consuming over 10× more compute than every other model combined. Це дозволило нам генерувати різні сторінкові та регулярні звіти, які представляли всю детальну інформацію про продуктивність категорії магазину. будується нами, що є центром передового досвіду BI для корпоративних звітів. Однак, оскільки наша організація слідує моделі самообслуговування аналітики, будь-хто може створювати і ділитися звітами за допомогою цього набору даних. This was a critical dataset 20 million-row semantic model The operations followed their typical pattern until that specific week. So what changed? Система виявила закономірність, яка показала, що 300 різних користувачів отримували доступ до однієї і тієї ж моделі через сторінкові звіти, орієнтовані на магазин, навколо того ж часового вікна. Щоб підтвердити це, ми вимкнули ці повідомлення на один день. Система працює at its peak capacity since the beginning of its operation. We had our culprit. The Discovery: XMLA Read Operations Відкриття: XMLA Read Operations Коли ми розглянули детальний вигляд операцій, домінувала одна метрія: XMLA Read Operations. That was puzzling. The native Power BI feature Paginated Reports operated as external connections. 
 
 
 Відповідь на це дає власна документація Microsoft: Кінцева точка XMLA дозволяє читати/записувати операції на наборах даних Power BI Premium, що дозволяє зовнішнім інструментам та API виконувати запити та контролювати моделі даних. Microsoft’s own documentation gives the answer: Кінцева точка XMLA дозволяє читати/записувати операції на наборах даних Power BI Premium, що дозволяє зовнішнім інструментам та API виконувати запити та контролювати моделі даних. Кінцева точка XMLA дозволяє Paginated Reports отримувати доступ до семантичних моделей так само, як Двигун набору даних отримує пряме групове виконання DAX від усіх операцій рендерингу та експортування сторінок. Excel, DAX Studio or any external system 
 
 
 Як зазначає SQLBI: Пагіновані звіти генерують високу сумісність запитів, тому що кожна відтворена сторінка виконує власну партію запитів DAX. As SQLBI notes: Пагіновані звіти генерують високу сумісність запитів, тому що кожна відтворена сторінка виконує власну партію запитів DAX. Кожен магазин користувачів друкував звіти, створюючи кілька сеансів XMLA - кожен з них важкий, повний читання. ТІ Це призвело до розпаду розподіленої комп'ютерної системи. standard Monday printing operation Evaluating the Fixes Оцінювання фіксів Ми виявили причину, перш ніж почати випробовувати різні рішення, поки не виявили ефективний метод. 
 
 
 
 
 
 
 
 
 
 
 Option 
 Description 
 Outcome 
 
 
 
 
 Keep Live to BigQuery 
 Maintain DirectQuery to BigQuery to avoid imported semantic model. 
 ❌ Too costly; XMLA reads still consume Fabric compute. 
 
 
 
 
 Fabric-Ingested Tables 
 Ingest data into Fabric and use a DirectQuery in the semantic model. 
 ⚠️ Minor improvement but XMLA concurrency remained. 
 
 
 
 
 SQL Endpoint with OLE DB 
 Connect paginated reports directly to SQL endpoint. 
 ⚠️ Technically possible but complex; lost relationships and added IT overhead. 
 
 
 
 
 Lean Semantic Model (Chosen) 
 Create a simplified model with only necessary granularity and metrics. 
 ✅ Massive reduction in compute usage and stable performance. Залишайтеся живими в BigQuery Підтримуйте DirectQuery до BigQuery, щоб уникнути імпортованої семантичної моделі. Занадто дорого; XMLA читає все ще споживають обчислення тканини. Тканинні таблиці Введіть дані в Fabric і використовуйте DirectQuery в семантичній моделі. ⚠️ Невелике поліпшення, але конкуренція XMLA залишилася. SQL Endpoint з OLE DB Підключення сторінкових звітів безпосередньо до кінцевої точки SQL. ⚠️ Технічно можливо, але складно; втрачені відносини і додані IT-переваги. Семантична модель Lean (вибрана) Створіть спрощену модель з тільки необхідною гранулярністю і метрикою. ✅ Масивне скорочення використання обчислювальної техніки та стабільна продуктивність. The Fix That Worked Ремонт, який працював Команда розробила специфічну семантичну модель для сторінкових звітів, яка включала only required granularity and metrics. Коли ми розгорнули його, наступний понеділок розповів історію. Peak utilization fell from 350 % to under 80% Система виробляла сторінкові звіти, які працювали без проблем, коли більше 100 користувачів отримували доступ до системи. Interactive dashboards remained fast and stable. Матеріальні метричні панелі показали, що обчислення had been declining at a steady rate. М'яка модель досягла контролю через свою просту конструкційну структуру. Why XMLA Read Operations Matter Чому XMLA читає операції Інцидент показав, що сторінковані звіти покладаються на інший механізм кешування, ніж інтерактивні звіти, і XMLA читає обхід кешування повністю, щоб запитувати двигун набору даних безпосередньо. Будь-який інструмент, який використовує XMLA для підключення до Excel, Paginated Reports або налаштованих скриптів, буде використовувати інтерактивні обчислювальні одиниці (CU) з можливості для кожного запиту. 
 
 
 Як зазначає дослідження TDWI: Основна причина піків потужності походить від шаблонів дизайну, які не розглядають одночасне виконання запитів, а не зосереджуються на обсязі даних. As TDWI research notes: Основна причина піків потужності походить від шаблонів дизайну, які не розглядають одночасне виконання запитів, а не зосереджуються на обсязі даних. Ситуація розвивалася так само, як описано.Система одночасно обробляла кілька запитів, що не призвело до зміни обсягу наших даних. Для корпоративних команд BI це означає, що планування продуктивності так само стосується поведінки використання, як і розміру моделі. Щоб уникнути подібних проблем: 
 
 
 
 Робочі навантаження сегментів: система вимагає двох різних моделей для функціонування інтерактивних функцій та операцій на сторінках. Моніторинг операцій XMLA: Fabric дозволяє визначити проблеми з продуктивністю, коли вони вперше з'являються через метрику рівня експлуатації. Вирівнювання масштабування потужності: система повинна виконувати синхронізацію SKU між нижчими і вищими під час їх призначених важких операційних періодів. What We Learned Що ми навчилися Виробництво Paginated Reports погіршується, коли система працює в умовах важких робочих навантажень. Dashboards aren’t the main compute consumers. Процес аналізу для одного аналітика і 300 магазинів слідує одному обчислювальному шляху. 
 
 
 
 
 
 
 Спрощення перевершує складність: М’яка модель дає передові результати, ніж складні багатошарові роботи. Видимість запобігає кризам: додаток Fabric Metrics надає перегляди з точними діагностичними можливостями, а не змушує їх ґрунтувати свої рішення на невизначених припущеннях. Управління дорівнює продуктивності: Організація повинна створювати певні рекомендації, які визначатимуть, коли члени команди можуть отримати доступ до спільних моделей. Самообслуговування вимагає нагляду: Команди отримують значну автономію через створення звітів, але потребують систем моніторингу для відстеження їх діяльності та визначених правил власності. Кешінг не є універсальним: поведінка кешінгу інтерактивних звітів відрізняється від сторінкових звітів, тому організаціям необхідно зрозуміти механізми обробки запитів, щоб запобігти несподіваним обчислювальним пікам. Профілактика коштує дешевше, ніж відновлення: кожна нова реалізація набору даних тепер включає сегментацію робочого навантаження та моніторинг XMLA як стандартні функції. Найбільша картина Проблема надійності торкнулася декількох моделей, оскільки вона вимагала належного функціонування як архітектурного проектування, так і систем управління. Операції Retail BI залежать від ритмічного шаблону, тому що йому потрібні дані в реальному часі для прийняття рішень щодо ціноутворення, персоналу, виконання та операцій з продажу. 
 
 
 Як пише MIT Sloan Management Review: Лідери аналітики перевершують інших, не виробляючи більше звітів, а керуючи тим, як споживаються дані. As MIT Sloan Management Review writes: Лідери аналітики перевершують інших, не виробляючи більше звітів, а керуючи тим, як споживаються дані. Наші системи були перероблені, щоб впоратися з навантаженням і володінням, що дозволило нам перейти від екстреної пожежної боротьби до планового управління. Це вимагає надійної підтримки у прийнятті рішень. The main focus of BI goes beyond fast data delivery Закриття думки Урок з того понеділка став постійною істиною, яку ми дізналися. Справжня причина несправності потужності системи випливає з дизайнерських виборів, які були зроблені без належного знання операцій системи. Dashboards visualize data. Paginated reports distribute it. But BI engineers govern how it all holds together. Обчислювальний пик отримав рішення, але наша команда виявила критичний зв'язок між Fabric, XMLA та системами управління, які підтримують стабільність корпоративної аналітики. Next time, when 300 stores print again, we’ll be ready. Про автора Рупеш Гхош працює головним інженером з бізнес-розвідки в Total Wine & More, продовжуючи свій виконавчий докторський ступінь в галузі бізнесу в Університеті Камберлендс. Його дослідницькі інтереси включають управління даними, розвідку рішень, управління проектами та економічно ефективну аналітику BI.

The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

Це аудіо створено мовою оригіналу історії!

Коли 300 магазинів друкуються одночасно: дебування 350-процентної вершини обчислення в тканині Power BI

About Author

КОМЕНТАРІ

ПОВІСИТИ БИРКИ

ЦЯ СТАТТЯ БУЛА ПРЕДСТАВЛЕНА В

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps