Lekérdezésdiagnosztikák vizualizációja és értelmezése a Power BI

A használni kívánt diagnosztikák rögzítése után a következő lépés a mondanivalójuk megértése.

Hasznos, ha jól ismeri a lekérdezésdiagnosztikai séma egyes oszlopainak jelentését. Ez az oktatóanyag nem fedi le ezeket az információkat. A teljes leírásért tekintse meg a lekérdezésdiagnosztikát.

Vizualizációk készítésekor általában használja a teljes részletes táblázatot. Függetlenül attól, hogy hány sort tartalmaz, valószínűleg valamilyen módon szemlélteti a különböző erőforrásokban töltött idő összeadását, vagy azt, hogy a natív lekérdezés mit adott ki.

Ahogy a diagnosztika rögzítéséről szóló cikkben említettük, ez a példa a Northwind Ügyfelek táblájának OData- és SQL-nyomkövetéseivel működik. A fókusz elsősorban az ügyfelektől érkező gyakori kérdésekre és az egyik könnyebben értelmezhető nyomkövetési csoportra koncentrál: az adatmodell teljes frissítésére.

Vizualizációk készítése

A nyomkövetések áttekintésekor többféleképpen is kiértékelheti őket. Ez a cikk két vizualizációt ismertet. Az első vizualizáció megjeleníti a fontos részleteket, a másik pedig a különböző tényezők időbeli hozzájárulását. Az első vizualizációhoz használjon táblázatot. Tetszőleges mezőket kiválaszthat, de ha egyszerűen, magas szinten szeretné áttekinteni a történteket, használja a következő mezőket:

A második vizualizációhoz használjon halmozott oszlopdiagramot. Az Axis paraméterben használja az Id vagy Step lehetőséget. Ha a Frissítés elemet tekinti meg, mivel annak nincs köze a Szerkesztő lépéseihez, valószínűleg csak az Azonosítót szeretné megnézni. A Jelmagyarázat paraméternél állítsa be a kategóriát vagy a műveletet (a kívánt részletességtől függően). Az Érték paraméternél állítsa be a Kizárólagos időtartam értéket, és győződjön meg arról, hogy nem a %, hogy megkapja a nyers időtartam értékét. Végül az Elemleírás paraméternél állítsa be a legkorábbi kezdési időpontot.

A vizualizáció létrehozása után győződjön meg arról, hogy a legkorábbi kezdési időpont szerint növekvő sorrendbe rendez, hogy látható legyen az események előfordulási sorrendje.

Képernyőkép a lekérdezésdiagnosztikáról a nyomkövetési táblázattal és az időtartam halmozott sávdiagramjával kategória és azonosító szerint.

Bár a pontos igények eltérőek lehetnek, a diagramok ezen kombinációja jó kiindulópont számos diagnosztikai fájl megtekintéséhez és számos célra.

A vizualizációk értelmezése

Ahogy korábban említettük, a lekérdezési diagnosztikák számos kérdés megválaszolásában segíthetnek. A két leggyakoribb kérdés az, hogy mennyi időt töltenek el, és milyen lekérdezést küldenek a forrásnak.

Annak megértése, hogy mire megy el az idő, egyszerű, és a legtöbb összekötő esetében hasonló. Máshol is említettük azonban, hogy az összekötőtől függően drasztikusan eltérő képességeket láthat. Számos ODBC-alapú összekötő például nem ad pontos rekordot az ODBC-illesztőnek küldött lekérdezésről, amelyet Power Query küld.

Annak megtekintéséhez, hogy mire fordítódik az idő, tekintse át a korábban létrehozott vizualizációkat.

Mivel az itt használt mintalekérdezések időértékei nagyon kicsik, ha a Power BI időjelentési módjával szeretne dolgozni, célszerűbb a Exclusive Duration oszlopot másodpercekre alakítani a Power Query-szerkesztőben. Miután elvégezte ezt az átalakítást, megtekintheti a diagramot, és áttekintheti, hogy hol tölti az időt.

Az OData-eredmények esetében az alábbi képen látható, hogy az adatok forrásból való lekérése az idő nagy részét tölti. Ha kiválasztja az Adatforrás elemet a jelmagyarázaton, az megjeleníti a lekérdezés adatforrásnak való küldéséhez kapcsolódó összes különböző műveletet.

Képernyőkép az OData-lekérdezések diagnosztikájáról részletes nyomkövetési táblázattal és az adatforrás idejét kiemelő időtartamdiagrammal.

Ha ugyanazokat a műveleteket hajtja végre, és hasonló vizualizációkat készít, de az ODATA-k helyett az SQL-nyomkövetéseket használja, láthatja, hogyan hasonlítja össze a két adatforrást.

Képernyőkép az SQL-értékelések részletes nyomkövetési táblázatáról, valamint egy olyan diagramról, amely a kizárólagos időtartamot hasonlítja össze azonosító és kategória szerint.

Ha kiválasztja az adatforrástáblát, például az ODATA-diagnosztikát, láthatja, hogy az első értékelés (a képen látható 2.3) metaadat-lekérdezéseket küld, a második értékelés pedig lekéri a fontos adatokat. Ez a példa kis mennyiségű adatot kér le, így az adatlekérés kis időt vesz igénybe (a teljes második kiértékeléshez kevesebb, mint egy tized másodperc, magának az adatlekérésnek kevesebb mint a huszadik másodperce), de ez a sebesség nem minden esetben igaz.

Mint korábban, válassza ki a jelmagyarázat Adatforrás kategóriáját a kibocsátott lekérdezések megtekintéséhez.

Ásás az adatokba

Útvonalak keresése

Ha megvizsgálja ezeket az adatokat, észreveheti, hogy az eltöltött idő szokatlannak tűnik. Az OData-lekérdezésben például láthatja, hogy egy adatforrás-lekérdezés a következő értékkel rendelkezik:

Request:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle%20eq%20%27Sales%20Representative%27&$select=CustomerID%2CCountry HTTP/1.1
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7

<Content placeholder>

Response:
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7
Content-Length: 435

<Content placeholder>

Ez az adatforrás-lekérdezés olyan művelethez van társítva, amely csak a kizárólagos időtartam 1% vesz igénybe. Eközben van egy hasonló:

Request:
GET https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry HTTP/1.1

Response:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry
HTTP/1.1 200 OK

Ez az adatforrás-lekérdezés egy olyan művelethez kapcsolódik, amely a kizárólagos végrehajtási idő közel 75%-át veszi igénybe. Ha bekapcsolja az útvonal funkciót, felfedezheti, hogy az utóbbi valójában az előbbi gyermeke. Ez a megállapítás azt jelenti, hogy az első lekérdezés alapvetően egy kis időt ad hozzá önmagában, és a belső lekérdezés nyomon követi a tényleges adatlekérést.

Ezek az értékek szélsőségesek, de a látható értékek határán belül vannak.

  • Last updated on