Kuinka yksi käytetty semanttinen malli varmasti kaatui BI-kapasiteetillemme ... ja mitä olemme oppineet. The Monday Morning Spike Maanantaiaamu Spike Yli 300 myymälää ympäri Yhdysvaltoja valmistautuivat seuraavaan viikkoon tulostamalla päivittäiset myynti- ja varastoraporttinsa Power BI:stä. Takaisin päämajaan, päivä alkoi kuin mikään muu - hiljainen monitorointi, ensimmäiset kahvikupit, postilaatikko täyttyy. Ensimmäinen viesti tuli sen jälkeen. “Hey, my report’s not loading - can you please check, I need it for a meeting?” Muutaman minuutin kuluttua toinen. “Hey, PowerBI is slow - can you please bump up the capacity ?” Sitten kolme lisää. Teams-ikkunassa näkyi help-desk-joukkueformaatti, joka tuli näkyviin kymmenen minuutin kuluessa. Olen päässyt sisään Ohjauspaneeli löytää pienen ongelman, jonka odotin näkevän.Kaavion koko alue näytti punaisia arvoja. Fabric capacity Utilization had spiked to 350 %, and I was completely taken aback. Ohjauspaneelit olivat tulleet reagoimattomiksi, kun taas sivutettujen raporttien lataaminen kesti liian kauan ja BI-alustalla, joka tuki 300 myymälää, oli kriittisiä suorituskykyongelmia. The day had just started, and we were already in firefighting mode. Tracing the Problem Ensimmäinen askel oli avata Käyttötaulukot osoittivat korkeimman käytön, koska yksi työtilan laskentayksikkö yhtäkkiä saavutti enimmäiskapasiteettinsa. Fabric Capacity Metrics dashboard Kaivaa syvemmälle ja löytää one dataset consuming over 10× more compute than every other model combined. Tämä antoi meille mahdollisuuden tuottaa erilaisia sivutettuja ja säännöllisiä raportteja, jotka esittelivät kaikki yksityiskohtaiset myymälän luokan suorituskykytiedot. Olemme rakentaneet BI:n huippuosaamiskeskuksen yritysraportointiin.Koska organisaatiomme noudattaa itsepalvelun analytiikkamallia, kuka tahansa voi rakentaa ja jakaa raportteja tämän tietokokonaisuuden avulla.Tämä joustavuus on tehokas, mutta se myös vaikeuttaa päivittäisen kulutuksen seurantaa ja hallintaa. This was a critical dataset 20 million-row semantic model The operations followed their typical pattern until that specific week. So what changed? We started tracing activity logs together with time windows and report connections. The system revealed a pattern which showed that 300 distinct users accessed the same model through store-facing paginated reports around the same time window. Vahvistukseksi olemme poistanut nämä raportit pois käytöstä yhden päivän ajan. Järjestelmä toimii at its peak capacity since the beginning of its operation. We had our culprit. The Discovery: XMLA Read Operations Lähde: XMLA Read Operations Kun tarkastelimme yksityiskohtaista toimintojen näkymää, yksi mittari hallitsi: XMLA Read Operations. That was puzzling. The native Power BI feature Paginated Reports operated as external connections. 
 
 
 Microsoftin oma dokumentti antaa vastauksen: XMLA-päätteen avulla voit lukea ja kirjoittaa toimintoja Power BI Premium -tietokokonaisuuksissa, joiden avulla ulkoiset työkalut ja API:t voivat suorittaa kyselyitä ja hallita tietomalleja. Microsoft’s own documentation gives the answer: XMLA-päätteen avulla voit lukea ja kirjoittaa toimintoja Power BI Premium -tietokokonaisuuksissa, joiden avulla ulkoiset työkalut ja API:t voivat suorittaa kyselyitä ja hallita tietomalleja. XMLA-päätteen avulla Paginated Reports voi käyttää semanttisia malleja samalla tavalla kuin Dataset-moottori vastaanottaa suoran DAX-erän suorittamisen kaikista sivun renderointi- ja vientioperaatioista. Excel, DAX Studio or any external system 
 
 
 Kuten SQLBI huomauttaa: Paginoidut raportit tuottavat korkean kyselyn samanaikaisuuden, koska jokainen renderoitu sivu suorittaa oman DAX-kyselyn erän. As SQLBI notes: Paginoidut raportit tuottavat korkean kyselyn samanaikaisuuden, koska jokainen renderoitu sivu suorittaa oman DAX-kyselyn erän. Jokainen myymälän käyttäjän tulostusraportti oli luomassa useita XMLA-istuntoja - jokainen raskas, täydellinen lukeminen. Sillä Tämä johti hajautetun tietokonejärjestelmän romahtamiseen. standard Monday printing operation Evaluating the Fixes Määrittele kiinteät Löysimme perimmäisen syyn ennen kuin aloimme testata erilaisia ratkaisuja, kunnes löysimme tehokkaan menetelmän. 
 
 
 
 
 
 
 
 
 
 
 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. Pysy elossa BigQuery Säilytä DirectQuery BigQuery vältetään tuoda semanttinen malli. 🔸 Liian kallista; XMLA lukee yhä kuluttaa Fabric-tietokonetta. Integroituja pöytiä Syötä dataa Fabric ja käytä DirectQuery semanttisessa mallissa. ⚠️ Pieni parannus, mutta XMLA: n kilpailukyky pysyi. SQL Endpoint ja OLE DB Liitä sivuutetut raportit suoraan SQL-päätepisteeseen. ⚠️ Teknisesti mahdollista, mutta monimutkaista; menetettyjä suhteita ja lisättyjä IT: n ylijäämiä. Lean semanttinen malli (valittu) Luo yksinkertaistettu malli, jossa on vain tarvittavat rakeisuus ja mittarit. ✅ Massiivinen laskennallisen käytön väheneminen ja vakaa suorituskyky. The Fix That Worked Korjaus, joka toimi Tiimi kehitti erityisen lean semanttisen mallin sivuilla oleville raporteille, jotka sisälsivät only required granularity and metrics. Kun se otettiin käyttöön, seuraava maanantai kertoi tarinan. Peak utilization fell from 350 % to under 80% Järjestelmä tuotti sivutettuja raportteja, jotka toimivat ilman ongelmia, kun järjestelmään pääsi yli 100 käyttäjää. Interactive dashboards remained fast and stable. Fabric metrics -paneeli osoitti, että laskenta had been declining at a steady rate. Leaner-malli saavutti hallinnan yksinkertaisen suunnittelurakenteensa kautta. Why XMLA Read Operations Matter Miksi XMLA: n lukeminen on tärkeää Tapaus paljasti, että sivuilla olevat raportit luottavat eri välimuistiin kuin vuorovaikutteiset raportit, ja XMLA lukee ohitusta välimuistiin kokonaan kysyäkseen suoraan tietokokonaisuuden moottoria. Kaikki työkalut, jotka käyttävät XMLA:ta yhteyden muodostamiseen Excel, Paginated Reports tai mukautettuja skriptejä, käyttävät vuorovaikutteisia laskentayksiköitä (CU) kapasiteetista jokaiseen kyselyyn. 
 
 
 Kuten TDWI tutkimus toteaa: Pääasiallinen syy kapasiteetin kärjistymiseen johtuu suunnitteluprosesseista, joissa ei oteta huomioon samanaikaista kyselyn suorittamista sen sijaan, että keskitytään tietomäärään. As TDWI research notes: Pääasiallinen syy kapasiteetin kärjistymiseen johtuu suunnitteluprosesseista, joissa ei oteta huomioon samanaikaista kyselyn suorittamista sen sijaan, että keskitytään tietomäärään. Järjestelmä käsitteli useita pyyntöjä samanaikaisesti, minkä seurauksena tietomäärämme ei muuttunut. Enterprise BI -tiimille tämä tarkoittaa, että suorituskyvyn suunnittelu koskee yhtä paljon käyttäytymistä kuin mallin kokoa. Samankaltaisten ongelmien välttämiseksi: 
 
 
 
 Segmenttityöt: Järjestelmä vaatii kaksi erillistä mallia vuorovaikutteisten toimintojen ja sivutettujen toimintojen toimintaan. XMLA-toimintojen tarkkailu: Fabric mahdollistaa suorituskykyongelmien tunnistamisen, kun ne ilmestyvät ensimmäisen kerran sen toiminnan tason mittareiden kautta. Kapasiteetin skaalautuminen: Järjestelmän on suoritettava SKU-synkronointi alempien ja korkeampien välillä nimettyjen raskaiden käyttöjaksojen aikana. What We Learned Mitä opimme Paginated Reportsin suorituskyky heikkenee, kun järjestelmä toimii raskaissa työkuormitusolosuhteissa. Dashboards aren’t the main compute consumers. XMLA toimii kaikkien istuntojen kautta yhdellä pääsytasolla.Yhden analyytikon ja 300 myymälän analyysimenettely seuraa samaa laskentareittiä. 
 
 
 
 
 
 
 Yksinkertaistaminen voittaa monimutkaisuuden: Lean-malli tuottaa parempia tuloksia kuin monimutkaiset monikerroksiset työpajat. Näkyvyys estää kriisit: Fabric Metrics -sovellus tarjosi tarkkoja diagnostisia ominaisuuksia sen sijaan, että se pakottaisi heidät tekemään päätöksiä epävarmojen oletusten perusteella. Hallinto vastaa suorituskykyä: Organisaation on luotava erityisiä ohjeita, jotka määrittävät, milloin tiimin jäsenet voivat käyttää jaettuja malleja. Itsenäinen palvelu vaatii valvontaa: Tiimit saavat merkittävää valtaa raportoinnin rakentamisen autonomian kautta, mutta he tarvitsevat seurantajärjestelmiä, jotka seuraavat heidän toimiaan ja määrittelevät omistajuussäännöt. Välimuisti ei ole yleismaailmallinen: Interaktiivisten raporttien välimuisti käyttäytyminen eroaa sivutetuista raportteista, joten organisaatioiden on ymmärrettävä kyselynkäsittelymekanismit odottamattomien laskennallisten huippujen estämiseksi. Ennaltaehkäisy on edullisempaa kuin palauttaminen: Jokainen uusi tietokokonaisuuden toteutus sisältää nyt työmäärän segmentoinnin ja XMLA-valvonnan vakioominaisuuksina. Suurempi kuva Luotettavuusongelma vaikutti useisiin malleihin, koska se vaati sekä arkkitehtonisen suunnittelun että hallintojärjestelmien asianmukaista toimintaa. Retail BI:n toiminta riippuu rytmisestä kuvasta, koska se tarvitsee reaaliaikaisia tietoja hinnoittelua, henkilöstöä, täytäntöönpanoa ja myyntiä koskevien päätösten tekemiseen. 
 
 
 MIT Sloan Management Review kirjoittaa: Analytiikan johtajat eivät ylitä muita tuottamalla enemmän raportteja, vaan hallitsemalla sitä, miten tietoja kulutetaan. As MIT Sloan Management Review writes: Analytiikan johtajat eivät ylitä muita tuottamalla enemmän raportteja, vaan hallitsemalla sitä, miten tietoja kulutetaan. Järjestelmämme on suunniteltu uudelleen käsittelemään kuormitusta ja omistajuutta, mikä mahdollisti siirtymisen hätätilanteisiin perustuvasta palontorjunnasta aikataulun mukaiseen hallintoon. Tämä edellyttää luotettavaa päätöksenteon tukea. The main focus of BI goes beyond fast data delivery Ajatusten sulkeminen Tuon maanantain oppitunnista tuli pysyvä totuus, jonka opimme. Todellinen syy järjestelmän kapasiteetin epäonnistumiseen johtuu suunnitteluvaihtoehdoista, jotka tehtiin ilman asianmukaista tietoa järjestelmän toiminnasta. Dashboards visualize data. Paginated reports distribute it. But BI engineers govern how it all holds together. Laskennallinen kärki sai ratkaisun, mutta tiimimme löysi kriittisen yhteyden Fabricin, XMLA:n ja hallintojärjestelmien välillä, jotka tukevat yritysanalyysien vakautta. Next time, when 300 stores print again, we’ll be ready. Kirjoittajan puolesta Rupesh Ghosh työskentelee johtavana Business Intelligence -insinöörinä Total Wine & More -yrityksessä ja jatkaa liiketoiminnan tohtorintutkintoa Cumberlandsin yliopistossa.Tutkimuksen etuja ovat datahallinto, päätöksenteko, projektinhallinta ja kustannustehokas BI-analyysi.

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

Tämä ääni on tuotettu tarinan alkuperäisellä kielellä!

Kun 300 myymälää tulostetaan kerralla: 350-prosenttisen laskentapisteen debugging Power BI Fabricissa

About Author

KOMMENTIT

RIPUTA TAGSIA

TÄMÄ ARTIKKELI ESITETTIIN

Related Stories

PENANCE

Why Choosing to Publish on HackerNoon First Matters

Dear Public Relations Manager, Here’s How to Use HackerNoon for Your Clients

How Apex Fusion Achieved FINMA Qualification Without Compromising Decentralization

PENANCE

Why Choosing to Publish on HackerNoon First Matters

Dear Public Relations Manager, Here’s How to Use HackerNoon for Your Clients

How Apex Fusion Achieved FINMA Qualification Without Compromising Decentralization

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps