Jak jeden nadmiernie wykorzystany model semantyczny z pewnością zepsuł naszą zdolność BI... i czego się nauczyliśmy. The Monday Morning Spike Poniedziałkowy poranek Spike Ponad 300 sklepów w Stanach Zjednoczonych przygotowywało się do nadchodzącego tygodnia, drukując codzienne raporty sprzedaży i zapasów z Power BI. Wracając do głównej siedziby, dzień zaczął się jak każdy inny - cichy tłum monitorów, pierwsze łyky kawy, wypełnienie skrzynki odbiorczej. Pierwsza wiadomość przyszła po tym. “Hey, my report’s not loading - can you please check, I need it for a meeting?” Kilka minut później kolejny. “Hey, PowerBI is slow - can you please bump up the capacity ?” Potem jeszcze trzy. W oknie Teams wyświetlono format kolejki pomocy, który stał się widoczny w ciągu dziesięciu minut. Dostąpiłem dostęp do tablicy kontrolnej, aby znaleźć niewielki problem, który spodziewałem się zobaczyć. Cały zakres wykresu wyświetlał wartości czerwone. Fabric capacity Utilization had spiked to 350 %, and I was completely taken aback. Tablice kontrolne stały się nieodpowiednie, a raporty na stronach zajęły zbyt długo, aby je załadować, a platforma BI obsługująca 300 sklepów doświadczyła krytycznych problemów z wydajnością. The day had just started, and we were already in firefighting mode. Tracing the Problem Pierwszym krokiem było otwarcie Wykorzystanie wykresów wykazało najwyższe wykorzystanie, ponieważ jedna jednostka obliczeniowa w przestrzeni roboczej nagle osiągnęła maksymalną pojemność. Fabric Capacity Metrics dashboard Kopanie głębiej, znajdziemy one dataset consuming over 10× more compute than every other model combined. To pozwoliło nam na generowanie różnych stronowych i regularnych raportów, które przedstawiły wszystkie szczegółowe informacje o wydajności w kategorii sklepów. Został zbudowany przez nas, który jest Centrum Doskonałości BI dla sprawozdawczości przedsiębiorstw. Jednak, ponieważ nasza organizacja stosuje model samodzielnej analizy, każdy może tworzyć i udostępniać raporty za pomocą tego zestawu danych. This was a critical dataset 20 million-row semantic model The operations followed their typical pattern until that specific week. So what changed? Zaczęliśmy śledzić dzienniki aktywności wraz z oknami czasowymi i połączeniami z raportami.System ujawnił wzorzec, który pokazał, że 300 różnych użytkowników uzyskało dostęp do tego samego modelu za pośrednictwem stronowych raportów skierowanych do sklepu wokół tego samego okna czasu. Aby to potwierdzić, wyłączyliśmy te raporty na jeden dzień. System działał at its peak capacity since the beginning of its operation. We had our culprit. The Discovery: XMLA Read Operations Odkrycie: XMLA Read Operations Kiedy zbadaliśmy szczegółowy widok operacji, dominuje jedna metryka: XMLA Read Operations. That was puzzling. The native Power BI feature Paginated Reports operated as external connections. 
 
 
 Właściwa dokumentacja Microsoftu daje odpowiedź: Punkt końcowy XMLA umożliwia operacje odczytu i zapisu w zestawach danych Power BI Premium, co pozwala narzędziom zewnętrznym i interfejsom API na wykonywanie zapytań i kontrolowanie modeli danych. Microsoft’s own documentation gives the answer: Punkt końcowy XMLA umożliwia operacje odczytu i zapisu w zestawach danych Power BI Premium, co pozwala narzędziom zewnętrznym i interfejsom API na wykonywanie zapytań i kontrolowanie modeli danych. Punkt końcowy XMLA umożliwia raportom stronowym dostęp do modeli semantycznych w taki sam sposób, jak Silnik zbiorów danych otrzymuje bezpośrednie wykonanie partii DAX ze wszystkich operacji renderowania i eksportu stron. Excel, DAX Studio or any external system 
 
 
 Jak zauważa SQLBI: Raporty oparte na stronach generują wysoką równowagę zapytań, ponieważ każda renderowana strona wykonuje własną partię zapytań DAX. As SQLBI notes: Raporty oparte na stronach generują wysoką równowagę zapytań, ponieważ każda renderowana strona wykonuje własną partię zapytań DAX. Każde wydrukowanie raportów użytkowników sklepu tworzyło wiele sesji XMLA - każda z nich była ciężką, pełną lekturą. o Rozpoczął się rozpad rozproszonego systemu komputerowego. standard Monday printing operation Evaluating the Fixes Ocena stałych Odkryliśmy przyczynę, zanim zaczęliśmy testować różne rozwiązania, aż do odkrycia skutecznej metody. 
 
 
 
 
 
 
 
 
 
 
 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. Zostań na żywo w BigQuery Utrzymuj DirectQuery do BigQuery, aby uniknąć importowanego modelu semantycznego. Zbyt kosztowne; XMLA czyta nadal zużywa obliczenia tkaniny. Tabele z tkaniną Wprowadź dane do Fabric i użyj DirectQuery w modelu semantycznym. ⚠️ Niewielka poprawa, ale konkurencja XMLA pozostała. SQL Endpoint z OLE DB Podłączanie stronowych raportów bezpośrednio do punktu końcowego SQL. ⚠️ Technicznie możliwe, ale złożone; utracone relacje i dodane IT. Model semantyczny Lean (wybrana) Stwórz uproszczony model z tylko niezbędną granularnością i metryką. ✅ Masywna redukcja zużycia obliczeniowego i stabilna wydajność. The Fix That Worked Naprawa, która zadziałała Zespół opracował specyficzny model semantyczny dla stronowych raportów, który zawierał only required granularity and metrics. Kiedy go wdrożyliśmy, następny poniedziałek opowiedział historię. Peak utilization fell from 350 % to under 80% System wyprodukował raporty na stronach, które działały bez problemów, gdy do systemu uzyskało dostęp ponad 100 użytkowników. Interactive dashboards remained fast and stable. Tablica kontrolna metryki tkaniny pokazała, że obliczenia had been declining at a steady rate. Szybszy model uzyskał kontrolę dzięki swojej prostej strukturze projektowej. Why XMLA Read Operations Matter Dlaczego operacje XMLA Read Matter Incydent ujawnił, że raporty na stronach opierają się na innym mechanizmie pamięci podręcznej niż raporty interaktywne, a XMLA czyta obejście pamięci podręcznej w całości, aby bezpośrednio wyszukiwać silnik zbiorów danych. Każde narzędzie, które używa XMLA do łączenia się z programem Excel, stronowymi raportami lub niestandardowymi skryptami, będzie używać interaktywnych jednostek obliczeniowych (CU) z pojemności dla każdego zapytania. 
 
 
 Jak wynika z badań TDWI: Głównym powodem szczytów pojemności wynika z wzorców projektowania, które nie uwzględniają równoczesnego wykonywania zapytań, zamiast skupiać się na objętości danych. As TDWI research notes: The main reason for capacity spikes stems from design patterns which fail to consider concurrent query execution instead of focusing on data volume. Sytuacja rozwinęła się w taki sam sposób, jak opisano.System przetwarzał jednocześnie wiele żądań, co nie spowodowało żadnych zmian w naszej objętości danych. Dla zespołów BI przedsiębiorstwa oznacza to, że planowanie wydajności dotyczy tak samo zachowania użytkownika, jak rozmiar modelu. Aby uniknąć podobnych problemów: 
 
 
 
 Obciążenia segmentowe: System wymaga dwóch odrębnych modeli do działania dla funkcji interaktywnych i operacji stronowych. Monitorowanie operacji XMLA: Fabric pozwala zidentyfikować problemy z wydajnością, gdy pojawiają się po raz pierwszy za pomocą metryki poziomu operacyjnego. Zrównanie skalowania pojemności: System musi wykonywać synchronizację SKU między niższymi i wyższymi w wyznaczonych ciężkich okresach pracy. What We Learned Czego się nauczyliśmy Wydajność Pageinated Reports pogarsza się, gdy system działa w ciężkich warunkach obciążenia. Dashboards aren’t the main compute consumers. Proces analizy dla jednego analityka i 300 sklepów podąża tą samą ścieżką obliczeniową. 
 
 
 
 
 
 
 Uproszczenie zwycięża złożoność: Lean model daje lepsze wyniki niż złożone, wielowarstwowe warsztaty. Widzialność zapobiega kryzysowi: aplikacja Fabric Metrics zapewnia widoki z precyzyjnymi funkcjami diagnostycznymi, zamiast zmuszać ich do podejmowania decyzji na podstawie niepewnych założeń. Zarządzanie jest równoznaczne z wydajnością: Organizacja musi tworzyć określone wytyczne, które określą, kiedy członkowie zespołu mogą uzyskać dostęp do wspólnych modeli. Samodzielna obsługa wymaga nadzoru: zespoły zyskują znaczną władzę poprzez autonomię tworzenia raportów, ale potrzebują systemów monitorowania, aby śledzić ich działania i zdefiniować zasady własności. Caching nie jest uniwersalny: zachowanie pamięci podręcznej interaktywnych raportów różni się od raportów na stronach, więc organizacje muszą zrozumieć mechanizmy obsługi zapytań, aby zapobiec nieoczekiwanym szczytom obliczeniowym. Zapobieganie jest tańsze niż odzyskiwanie: każda nowa implementacja zbioru danych obejmuje teraz segmentację obciążeń roboczych i monitorowanie XMLA jako standardowe funkcje. Większy obraz Problem niezawodności dotyczył wielu modeli, ponieważ wymagał właściwego funkcjonowania zarówno systemów projektowania architektonicznego, jak i systemów zarządzania. Operacje Retail BI zależą od rytmicznego wzorca, ponieważ potrzebują danych w czasie rzeczywistym, aby podejmować decyzje dotyczące cen, personelu, realizacji i operacji sprzedaży. 
 
 
 Jak pisze MIT Sloan Management Review: Analitycy przewyższają innych, nie tworząc więcej raportów, ale regulując, w jaki sposób dane są zużywane. As MIT Sloan Management Review writes: Analitycy przewyższają innych, nie tworząc więcej raportów, ale regulując, w jaki sposób dane są zużywane. Nasze systemy przeszły przebudowę, aby poradzić sobie z obciążeniem i własnością, co pozwoliło nam przejść od nadzwyczajnej walki z pożarami do planowanego zarządzania. Wymaga niezawodnego wsparcia w podejmowaniu decyzji. The main focus of BI goes beyond fast data delivery Zamknięcie myśli Lekcja z tego poniedziałku stała się trwałą prawdą, której się nauczyliśmy. Prawdziwa przyczyna awarii zdolności systemowych wynika z wyborów projektowych, które zostały dokonane bez odpowiedniej wiedzy o działaniu systemu. Dashboards visualize data. Paginated reports distribute it. But BI engineers govern how it all holds together. Spike obliczeniowy otrzymał rozwiązanie, ale nasz zespół znalazł kluczowe powiązanie między Fabric, XMLA i systemami zarządzania, które wspierają stabilność analizy przedsiębiorstwa. Next time, when 300 stores print again, we’ll be ready. O autorze Rupesh Ghosh pracuje jako główny inżynier ds. Business Intelligence w firmie Total Wine & More, a jednocześnie prowadzi doktorat wykonawczy w dziedzinie biznesu na Uniwersytecie w Cumberlands.

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

Ten dźwięk jest produkowany w oryginalnym języku historii!

Gdy 300 magazynów jest drukowanych na raz: debugging 350% spike do obliczeń w Power BI Fabric

About Author

UWAGI

ZAWIEŚĆ TAGI

ARTYKUŁ TEN ZOSTAŁ PREZENTOWANY W

Related Stories

Google's Gemini AI: A Thought Experiment in Deception

Verified Writers

MashRadar Reviewed HackerNoon - Everything You Need to Know

Meet the Writer: HackerNoon's Contributor Emmanuel Nwaka, Content Marketing Professional

Google's Gemini AI: A Thought Experiment in Deception

Verified Writers

MashRadar Reviewed HackerNoon - Everything You Need to Know

Meet the Writer: HackerNoon's Contributor Emmanuel Nwaka, Content Marketing Professional

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps