Vizualizace a interpretace diagnostiky dotazů v Power BI

Úvod

Jakmile zaznamenáte diagnostiku, kterou chcete použít, je dalším krokem pochopení toho, co říkají.

Je užitečné mít dobrou představu o tom, co přesně znamená každý sloupec ve schématu diagnostiky dotazů, což v tomto krátkém kurzu neopakujeme. Tady naleznete podrobný článek.

Obecně platí, že při vytváření vizualizací je lepší použít úplnou podrobnou tabulku. Vzhledem k tomu, že bez ohledu na počet řádků se pravděpodobně díváte na určité znázornění toho, jak se čas strávený v různých zdrojích sčítá, nebo jaký byl původně vygenerovaný nativní dotaz.

Jak jsme zmínili v našem článku o záznamu diagnostiky, pracuji s trasami OData a SQL pro stejnou tabulku (nebo téměř stejnou) – s tabulkou Customers z Northwind. Konkrétně se zaměřím na společnou žádost od našich zákazníků a jednu z jednodušších interpretací sad trasování: úplnou aktualizaci datového modelu.

Sestavení vizualizací

Při práci se sledovacími záznamy máte mnoho způsobů, jak je vyhodnotit. V tomto článku se zaměříme na dvě vizualizace: jedna zobrazí podrobnosti, které vás zajímají, a druhá umožní snadno nahlédnout na příspěvky času různých faktorů. Pro první vizualizaci se použije tabulka. Můžete zvolit libovolná pole, která se vám líbí, ale doporučené jsou ta, která poskytují snadnou a vysokou úroveň přehledu o tom, co se děje:

• Id
• Počáteční čas
• Dotaz
• krok
• Dotaz na zdroj dat
• Exkluzivní doba trvání (%)
• počet řádků
• Kategorie
• Je uživatelský dotaz
• Path

Pro druhou vizualizaci je jednou z možností použití skládaného sloupcového grafu. V parametru Axis můžete chtít použít ID nebo Step. Pokud se díváme na aktualizaci, protože nemá nic společného s kroky v samotném Editoru, pravděpodobně se chceme podívat na 'ID'. U parametru Legend byste měli nastavit Category nebo Operation (v závislosti na požadované členitosti). Pro hodnotu nastavte hodnotu Exclusive Duration (a ujistěte se, že se nejedná o %, abyste získali nezpracovanou hodnotu doby trvání). Nakonec u Tooltipu nastavte "Nejstarší čas zahájení".

Po sestavení vizualizace se ujistěte, že řadíte vzestupně podle počátečního času, abyste viděli pořadí, ve které se děje.

I když se vaše přesné potřeby můžou lišit, je tato kombinace grafů vhodným místem, kde začít hledat mnoho diagnostických souborů a pro různé účely.

Interpretace vizualizací

Jak jsme zmínili výše, s pomocí diagnostiky dotazů můžete odpovědět na mnoho otázek, ale dvě nejčastější se týkají toho, jak je čas využíván a jaký dotaz je odeslán do zdroje.

Položit otázku, jak je čas využitý, je jednoduché a bude to podobné pro většinu konektorů. Upozornění ohledně diagnostiky dotazů, jak je uvedeno jinde, spočívá v tom, že v závislosti na konektoru uvidíte výrazně odlišné schopnosti. Mnoho konektorů založených na rozhraní ODBC například nebude mít přesný záznam toho, jaký dotaz se odesílá do skutečného back-endového systému, protože Power Query vidí jenom to, co odesílá ovladač ODBC.

Pokud chceme zjistit, jak se čas stráví, můžeme se podívat na vizualizace, které jsme vytvořili výše.

Vzhledem k tomu, že jsou časové hodnoty pro zde použité ukázkové dotazy velmi malé, je lepší, když při práci s tím, jak Power BI zobrazuje čas, převedeme v editoru Power Query sloupec Exclusive Duration na 'Sekundy'. Jakmile tento převod provedeme, můžeme se podívat na náš graf a získat slušnou představu o tom, kde je čas stráven.

U výsledků OData vidím na obrázku, že velká většina času strávila načítáním dat ze zdroje – pokud v legendě vyberu položku Zdroj dat, zobrazí se všechny různé operace související s odesláním dotazu do zdroje dat.

Pokud provádíme všechny stejné operace a vytváříme podobné vizualizace, ale s trasováníMI SQL místo těch ODATA, uvidíme, jak se oba zdroje dat porovnávají.

Pokud vybereme tabulku Zdroje dat, například s diagnostikou ODATA, uvidíme první vyhodnocení (2.3 na tomto obrázku) vygeneruje dotazy na metadata, přičemž druhé vyhodnocení skutečně načítá data, o která nám záleží. Vzhledem k tomu, že v tomto případě načítáme malé objemy dat, načtení dat zabere jen malou chvíli (méně než desetina sekundy pro provedení celého druhého vyhodnocení a při samotném načítání dat méně než dvacetina sekundy), ale to nebude platit ve všech případech.

Jak je uvedeno výše, můžeme v legendě vybrat kategorii Zdroj dat a zobrazit vygenerované dotazy.

Zkoumání dat

Zkoumání cest

Při pohledu na to, pokud se zdá, že čas strávený je podivný – například v dotazu OData se může zobrazit dotaz zdroje dat s následující hodnotou:

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>

Tento dotaz zdroje dat je přidružený k operaci, která zabírá pouze 1% exkluzivní doby trvání. Mezitím je tu podobný:

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

Tento dotaz zdroje dat je přidružený k operaci, která zabírá téměř 75% exkluzivní doby trvání. Pokud zapnete Cestu, zjistíte, že ta druhá je ve skutečnosti podřízená té první. To znamená, že první dotaz v podstatě přidal trochu času, přičemž skutečné načítání dat bylo sledováno vnitřním dotazem.

Jedná se o extrémní hodnoty, ale jsou v mezích toho, co by mohlo být vidět.