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

Bevezetés

Miután rögzítette a használni kívánt diagnosztikát, a következő lépés az, hogy megértse, mit mondanak.

Hasznos, ha jól megértjük, hogy a lekérdezésdiagnosztikai séma egyes oszlopai pontosan mit jelentenek, amit ebben a rövid oktatóanyagban nem fogunk megismételni. Erről itt van egy teljes írás.

Vizualizációk készítésekor általában jobb, ha a teljes részletes táblázatot használja. Mivel függetlenül attól, hogy hány sorból áll, valószínűleg a különböző erőforrásokban töltött idő összeadásának valamilyen ábrázolása, vagy a natív lekérdezés kibocsátása.

Ahogy a diagnosztikák rögzítéséről szóló cikkünkben is említettük, ugyanazon táblához (vagy majdnem) az Ügyfelek táblához tartozó OData- és SQL-nyomkövetésekkel dolgozom a Northwindből. Elsősorban az ügyfeleinktől érkező gyakori kérdésekre koncentrálok, és az egyik egyszerűbben értelmezhető nyomkövetési csoportra: az adatmodell teljes frissítésére.

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

A nyomkövetések során többféleképpen is kiértékelheti őket. Ebben a cikkben egy két vizualizációs felosztásra összpontosítunk– az egyik a fontos részletek megjelenítésére, a másik pedig a különböző tényezők időbeli hozzájárulásainak egyszerű megtekintésére. Az első vizualizációhoz táblázatot használunk. Tetszőleges mezőket kiválaszthat, de azokat, amelyek egyszerű, magas szintű áttekintéshez ajánlottak, áttekintheti, hogy mi történik:

• Azonosító
• Kezdési időpont
• Lekérdezés
• Lépés
• Adatforrás-lekérdezés
• Kizárólagos időtartam (%)
• Sorok száma
• Kategória
• Felhasználói lekérdezés
• Elérési út

A második vizualizáció esetében az egyik lehetőség a halmozott oszlopdiagram használata. A Tengely paraméterben érdemes lehet az "Id" vagy a "Step" paramétert használni. Ha a Frissítés elemet vizsgáljuk, mert nincs köze a Szerkesztő lépéseihez, valószínűleg csak az "Azonosítót" szeretnénk megnézni. A Jelmagyarázat paraméternél a "Kategória" vagy a "Művelet" értéket kell megadnia (a kívánt részletességtől függően). Az "Érték" értéknél állítsa be a "Kizárólagos időtartam" értéket (és győződjön meg arról, hogy nem a %, így megkapja a nyers időtartam értékét). Végül az elemleírásnál állítsa be a legkorábbi kezdési időpontot.

Miután elkészült a vizualizáció, gondoskodjon arról, hogy növekvő sorrendben rendezze a "Legkorábbi kezdési időpont" szerint, hogy látható legyen a dolgok sorrendje.

Bár a pontos igények eltérőek lehetnek, a diagramok e 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 fentebb említettük, számos kérdésre megpróbálhat válaszolni a lekérdezésdiagnosztikával, de a leggyakrabban látható kettő azt kérdezi, hogy mennyi időt tölt, és megkérdezi, hogy mi az a lekérdezés, amelyet a forrásnak küldött.

Azt kérdezi, hogyan tölti az időt könnyű, és hasonló lesz a legtöbb összekötő. A lekérdezésdiagnosztikával kapcsolatos figyelmeztetés, ahogyan máshol is említettük, az összekötőtől függően drasztikusan eltérő képességeket fog látni. Sok ODBC-alapú összekötő például nem rendelkezik pontos rögzítéssel arról, hogy milyen lekérdezést küld a rendszer a tényleges háttérrendszernek, mivel a Power Query csak azt látja, amit az ODBC-illesztőnek küld.

Ha látni szeretnénk, hogyan telik az idő, akkor csak a fent létrehozott vizualizációkat tekinthetjük meg.

Mivel az itt használt minta lekérdezések időértékei olyan kicsik, hogy a Power BI-jelentések időértékeivel szeretnénk dolgozni, jobb, ha a Kizárólagos időtartam oszlopot másodpercekké alakítjuk a Power Query-szerkesztőben. Miután ezt az átalakítást elvégeztük, megnézhetjük a diagramunkat, és képet kaphatunk arról, hogy hol van az idő.

Az OData-eredmények esetében a képen az látható, hogy az adatok forrásból való lekérésével töltött idő nagy része – ha kiválasztom 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.

Ha ugyanazokat a műveleteket hajtjuk végre, és hasonló vizualizációkat készítünk, de az ODATA-k helyett az SQL-nyomkövetésekkel, láthatjuk, hogyan összehasonlítani a két adatforrást!

Ha kiválasztjuk az Adatforrás táblát, például az ODATA-diagnosztikával, láthatjuk, hogy az első értékelés (a képen a 2.3) metaadat-lekérdezéseket bocsát ki, a második értékelés pedig ténylegesen lekérte a fontos adatokat. Mivel ebben az esetben kis mennyiségű adatot kérünk le, a visszahívott adatok kis időt vesznek igénybe (a teljes második kiértékeléshez kevesebb mint egy tizedmásodperccel, és maga az adatlekéréshez kevesebb mint huszadmásodperccel), de ez nem minden esetben igaz.

A fentieknek megfelelően a jelmagyarázatban kiválaszthatjuk az "Adatforrás" kategóriát a kibocsátott lekérdezések megtekintéséhez.

Ásás az adatokba

Útvonalak keresése

Ha ezt látja, úgy tűnik, hogy az eltöltött idő furcsa – például az OData-lekérdezésen láthatja, hogy van egy adatforrás-lekérdezés a következő értékkel:

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 például a kizárólagos időtartam 1%-át veszi 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 van társítva, amely a kizárólagos időtartam közel 75%-át veszi igénybe. Ha bekapcsolja az elérési utat, felfedezheti, hogy az utóbbi valójában az előbbi gyermeke. Ez azt jelenti, hogy az első lekérdezés alapvetően kis időt adott hozzá önmagában, és a tényleges adatlekérést a "belső" lekérdezés követi nyomon.

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