Hur en överanvänd semantisk modell verkligen kraschade vår BI-kapacitet ... och vad vi lärde oss. The Monday Morning Spike Måndagsmorgon Spike Över 300 butiker över hela USA förberedde sig för den kommande veckan och tryckte sina dagliga försäljnings- och lagerrapporter från Power BI. Tillbaka på huvudkontoret började dagen som alla andra - tyst buller av bildskärmar, första koppar kaffe, inkorg fyller upp. Det första meddelandet kom därefter. “Hey, my report’s not loading - can you please check, I need it for a meeting?” Några minuter senare en annan. “Hey, PowerBI is slow - can you please bump up the capacity ?” Sedan tre till. Teams-fönstret visade ett help-desk-körning format som blev synligt inom tio minuter. Jag fick tillgång till den instrumentpanelen för att hitta ett mindre problem som jag förväntade mig att se. Hela diagramområdet visade röda värden. Fabric capacity Utilization had spiked to 350 %, and I was completely taken aback. Dashboards hade blivit responsiva medan sidade rapporter tog för lång tid att ladda och BI-plattformen som stödde 300 butiker upplevde kritiska prestandaproblem. The day had just started, and we were already in firefighting mode. Tracing the Problem Första steget var att öppna Utnyttjandediagrammen visade den högsta användningen eftersom en arbetsytaberäkningsenhet plötsligt nådde sin maximala kapacitet. Fabric Capacity Metrics dashboard Gräva djupare, vi hittade one dataset consuming over 10× more compute than every other model combined. som gjorde det möjligt för oss att generera olika sidade och regelbundna rapporter som presenterade all detaljerad butikskategoriprestationsinformation. Vi har byggt BI Center of Excellence för företagsrapportering. Men eftersom vår organisation följer en självbetjäningsanalysmodell kan vem som helst bygga och dela rapporter med hjälp av denna datamängd. This was a critical dataset 20 million-row semantic model The operations followed their typical pattern until that specific week. So what changed? Vi började spåra aktivitetsloggar tillsammans med tidsfönster och rapportanslutningar.Systemet avslöjade ett mönster som visade att 300 olika användare fick tillgång till samma modell genom butiksinriktade sidorade rapporter runt samma tidsfönster. För att bekräfta, vi inaktiverade dessa rapporter för en enda dag. Systemet har opererat at its peak capacity since the beginning of its operation. We had our culprit. The Discovery: XMLA Read Operations Upptäckten: XMLA Läs Operationer När vi undersökte den detaljerade operationsvyn dominerade en metrik: XMLA Read Operations. That was puzzling. The native Power BI feature Paginated Reports operated as external connections. 
 
 
 Microsofts egen dokumentation ger svaret: XMLA-ändpunkten möjliggör läs- och skrivoperationer på Power BI Premium-datasatser som gör det möjligt för externa verktyg och API:er att utföra frågor och styra datamodeller. Microsoft’s own documentation gives the answer: XMLA-ändpunkten möjliggör läs- och skrivoperationer på Power BI Premium-datasatser som gör det möjligt för externa verktyg och API:er att utföra frågor och styra datamodeller. XMLA-ändpunkten gör det möjligt för Paginated Reports att komma åt semantiska modeller på samma sätt som Datasetmotorn tar emot direkt DAX-batchutförande från alla sidrenderings- och exportoperationer. Excel, DAX Studio or any external system 
 
 
 Som SQLBI noterar: Paginerade rapporter genererar hög frågekonkurrens eftersom varje renderad sida kör sin egen DAX-frågebatch. As SQLBI notes: Paginated reports generate high query concurrency because each rendered page executes its own DAX query batch. Varje butik användarutskrift rapporter skapade flera XMLA sessioner - var och en en tung, fullständig läsning. den har utvecklats till ett distribuerat datorsystem. standard Monday printing operation Evaluating the Fixes Utvärdera de fasta Vi upptäckte orsaken innan vi började testa olika lösningar tills vi upptäckte den effektiva metoden. 
 
 
 
 
 
 
 
 
 
 
 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. Håll Live till BigQuery Behåll DirectQuery till BigQuery för att undvika importerad semantisk modell. För dyrt; XMLA läser fortfarande förbrukar Fabric-datorer. Fabrik Ingested tabeller Ange data i Fabric och använd en DirectQuery i den semantiska modellen. ⚠️ Mindre förbättring men XMLA-konkurrensen förblev. SQL Endpoint med OLE DB Anslut sidade rapporter direkt till SQL-ändpunkten. ⚠️ Tekniskt möjligt men komplext; förlorade relationer och IT-överhuvud. Lean Semantic Model (väljs ut) Skapa en förenklad modell med endast nödvändig granularitet och mätvärden. Massiv minskning av datoranvändning och stabil prestanda. The Fix That Worked Den fix som fungerade Teamet utvecklade en specifik lean semantisk modell för sidade rapporter som inkluderade only required granularity and metrics. När vi implementerade den berättade följande måndag historien. Peak utilization fell from 350 % to under 80% Systemet producerade sidorade rapporter som fungerade utan problem när mer än 100 användare fick åtkomst till systemet. Interactive dashboards remained fast and stable. Fabric metrics instrumentpanelen visade att beräkningen had been declining at a steady rate. Den smalare modellen uppnådde kontroll genom sin enkla designstruktur. Why XMLA Read Operations Matter Varför XMLA Läs Operationer Matter Incidenten avslöjade att sidade rapporter förlitar sig på en annan cachingmekanism än interaktiva rapporter, och XMLA läser bypass caching helt och hållet för att fråga datamängdsmotorn direkt. Alla verktyg som använder XMLA för att ansluta till Excel, Paginated Reports eller anpassade skript använder interaktiva beräkningsenheter (CU) från kapacitet för varje fråga. 
 
 
 Som TDWI forskning noterar: Den främsta orsaken till kapacitetsspikar härrör från designmönster som misslyckas med att överväga samtidig frågeutförande istället för att fokusera på datavolymen. As TDWI research notes: Den främsta orsaken till kapacitetsspikar härrör från designmönster som misslyckas med att överväga samtidig frågeutförande istället för att fokusera på datavolymen. Situationen utvecklades på samma sätt som beskrivits.Systemet behandlade flera förfrågningar samtidigt vilket resulterade i ingen förändring i vår datamängd. För företagets BI-team betyder det att prestationsplanering handlar lika mycket om användningsbeteende som det handlar om modellstorlek. För att undvika liknande problem: 
 
 
 
 Segmentarbetsbelastningar: Systemet kräver två separata modeller för att fungera för interaktiva funktioner och sidade operationer. Övervaka XMLA-operationer: Med Fabric kan du identifiera prestandaproblem när de först dyker upp genom sina operationsnivåmätningar. Justera kapacitetsskalning: Systemet behöver utföra SKU-synkronisering mellan lägre och högre under sina utsedda tunga driftsperioder. What We Learned Vad vi lärt oss Prestanda för Paginated Reports försämras när systemet fungerar under tunga arbetsbelastningsförhållanden. Dashboards aren’t the main compute consumers. Analysprocessen för en analytiker och 300 butiker följer samma beräkningsväg. 
 
 
 
 
 
 
 Förenkling överträffar komplexitet: En mager modell ger överlägsna resultat än komplexa flerskiktade arbetsomgångar. Visibilitet förhindrar kris: Appen Fabric Metrics tillhandahöll visningar med exakta diagnostiska funktioner i stället för att tvinga dem att basera sina beslut på osäkra antaganden. Styrning är lika med prestanda: Organisationen behöver skapa särskilda riktlinjer som anger när teammedlemmar kan komma åt delade modeller. Självbetjäning kräver övervakning: Teams får betydande makt genom rapporteringsautonomi men behöver övervakningssystem för att spåra sin verksamhet och definierade ägarregler. Caching är inte universellt: Cachingbeteendet för interaktiva rapporter skiljer sig från sidrapporter, så organisationer behöver förstå sina frågehanteringsmekanismer för att förhindra oväntade beräkningsspikar. Förebyggande åtgärder är billigare än återvinning: Varje ny implementering av dataset inkluderar nu arbetsbelastningssegmentering och XMLA-övervakning som standardfunktioner. Den större bilden Tillförlitlighetsproblemet påverkade flera modeller eftersom det krävde korrekt drift av både arkitektonisk design och styrningssystem. Verksamheten hos Retail BI är beroende av ett rytmiskt mönster eftersom det behöver realtidsdata för att fatta beslut om prissättning, personal, uppfyllelse och försäljning. 
 
 
 Som MIT Sloan Management Review skriver: Analytics-ledare överträffar andra inte genom att producera fler rapporter, utan genom att styra hur data förbrukas. As MIT Sloan Management Review writes: Analytics-ledare överträffar andra inte genom att producera fler rapporter, utan genom att styra hur data förbrukas. Våra system genomgick en omdesign för att hantera belastning och ägande som gjorde det möjligt för oss att flytta från nödbaserad brandbekämpning till schemalagd styrning. eftersom det kräver tillförlitligt beslutsstöd. The main focus of BI goes beyond fast data delivery Stäng tankar Lektionen från den måndagen blev en bestående sanning som vi lärde oss. Den verkliga orsaken till systemkapacitetsfel härrör från designval som gjordes utan tillräcklig kunskap om systemoperationer. Dashboards visualize data. Paginated reports distribute it. But BI engineers govern how it all holds together. Dataspiken fick en lösning, men vårt team fann den kritiska kopplingen mellan Fabric, XMLA och styrningssystem som stöder stabiliteten i företagsanalys. Next time, when 300 stores print again, we’ll be ready. Om författaren Rupesh Ghosh arbetar som ledande Business Intelligence Engineer på Total Wine & More medan han bedriver sin Executive PhD i Business vid University of Cumberlands. Hans forskningsintressen inkluderar datastyrning, beslutsintelligens, projektledning och kostnadseffektiv BI-analys.

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

Det här ljudet är producerat på berättelsens originalspråk!

När 300 butiker skrivs ut på en gång: Debugging en 350% Compute Spike i Power BI Fabric

About Author

KOMMENTARER

HÄNG TAGGAR

DENNA ARTIKEL PRESENTERAS I

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps