Režim DirectQuery v Power BI

V aplikácii Power BI Desktop alebo služba Power BI sa môžete rôznymi spôsobmi pripojiť k mnohým rôznym zdrojom údajov. Údaje môžete do služby Power BI importovať , čo je najbežnejší spôsob získania údajov. Môžete sa tiež priamo pripojiť k niektorým údajom v ich pôvodnom zdrojovom odkladacom priestore, ktorý sa nazýva DirectQuery. Tento článok sa venuje predovšetkým funkciám režimu DirectQuery.

Tento článok popisuje:

• Rôzne možnosti pripojenia údajov služby Power BI.
• Pokyny, kedy použiť režim DirectQuery namiesto importu.
• Obmedzenia a dôsledky použitia režimu DirectQuery.
• Odporúčania na úspešné používanie režimu DirectQuery.
• Zistite, ako diagnostikovať problémy s výkonom režimu DirectQuery.

Článok sa zameriava na pracovný postup Režim DirectQuery, keď vytvárate zostavu v aplikácii Power BI Desktop, ale vzťahuje sa aj na pripojenie prostredníctvom režimu DirectQuery v služba Power BI.

Poznámka

Režim DirectQuery je súčasťou služby SQL Server Analysis Services. Táto funkcia zdieľa mnoho podrobností s priamym dotazom v službe Power BI, sú tu však medzi nimi dôležité rozdiely. Tento článok sa venuje primárne režimu DirectQuery so službou Power BI, nie so službou SQL Server Analysis Services.

Ďalšie informácie o používaní režimu DirectQuery so službou SQL Server Analysis Services nájdete v téme Používanie režimu DirectQuery pre sémantické modely služby Power BI a Analysis Services (ukážka). Režim DirectQuery pdf si môžete stiahnuť aj v službe SQL Server 2016 Analysis Services.

Režimy pripojenia údajov služby Power BI

Power BI sa môže pripojiť k veľkému množstvu rôznych zdrojov údajov, ako napríklad k:

• Online služby ako Salesforce a Dynamics 365.
• Databázy ako SQL Server, Access a Amazon Redshift.
• Jednoduché súbory v Exceli, JSON a ďalších formátoch.
• Iné zdroje údajov, napríklad Spark, webové lokality a Microsoft Exchange.

Údaje z týchto zdrojov môžete importovať do služby Power BI. K niektorým zdrojom sa môžete pripojiť aj pomocou režimu DirectQuery. Súhrn zdrojov údajov, ktoré podporujú režim DirectQuery, nájdete v téme Zdroje údajov podporované režimom DirectQuery. Zdroje s podporou režimu DirectQuery sú primárne zdroje, ktoré dokážu zabezpečiť dobrý výkon interaktívnych dotazov.

Ak je to možné, mali by ste údaje do služby Power BI importovať. Importovanie využíva vysoký výkon nástroja dotazov služby Power BI a poskytuje mimoriadne interaktívne a plnohodnotné prostredie.

Ak svoje ciele nemôžete dosiahnuť importovaním údajov, napríklad ak sa údaje často menia a zostavy musia zodpovedať najnovším údajom, zvážte použitie režimu DirectQuery. Režim DirectQuery je uskutočniteľný len vtedy, ak základný zdroj údajov môže typickému agregačnému dotazu poskytnúť interaktívne výsledky dotazu za menej ako päť sekúnd a je schopný zvládnuť záťaž vygenerovaného dotazu. Dôkladne zvážte obmedzenia a dôsledky použitia režimu DirectQuery.

Možnosti importu a režimu DirectQuery služby Power BI sa postupne vyvíjajú. Zmeny, ktoré zabezpečujú väčšiu flexibilitu pri používaní importovaných údajov, umožňujú importovať častejšie a eliminujú niektoré nevýhody používania režimu DirectQuery. Bez ohľadu na vylepšenia je pri používaní režimu DirectQuery dôležité výkon základného zdroja údajov. Ak je základný zdroj údajov pomalý, použitie režimu DirectQuery pre tento zdroj nie je vhodné.

Nasledujúce časti sa zaoberajú tromi možnosťami pripojenia k údajom: import, DirectQuery a dynamické pripojenie. Zvyšok článku sa zameriava na režim DirectQuery.

Pripojenia importu

Keď sa pripojíte k zdroju údajov, ako je napríklad SQL Server, a importujete údaje v aplikácii Power BI Desktop, objavia sa nasledujúce výsledky:

• Pri prvom získaní údajov definuje každá množina vybraných tabuliek dotaz, ktorý vráti množinu údajov. Tieto dotazy môžete pred načítaním údajov upraviť, napríklad použiť filtre, agregovať údaje alebo spojiť rôzne tabuľky.

• Pri načítavaní sa všetky údaje definované dotazmi importujú do vyrovnávacej pamäte služby Power BI.

• Vytvorenie vizuálu v aplikácii Power BI Desktop dotazuje údaje vo vyrovnávacej pamäti. Ukladací priestor služby Power BI zabezpečí, že dotaz je rýchly a všetky zmeny vizuálu sa prejavia okamžite.

• Vizuály neodrážajú zmeny základných údajov v úložisku údajov. Ak chcete obnoviť údaje, musíte ich znova importovať.

• Publikovaním zostavy do služba Power BI ako súbor .pbix sa vytvorí a nahrá sémantický model, ktorý obsahuje importované údaje. Potom môžete naplánovať obnovenie údajov, napríklad každý deň znova importovať údaje. V závislosti od umiestnenia pôvodného zdroja údajov môže byť potrebné nakonfigurovať lokálnu bránu údajov na obnovenie.

• Otvorenie existujúcej zostavy alebo vytvorenie novej zostavy v služba Power BI znova dotazuje importované údaje, čím sa zabezpečí interaktivita.

• Vizuály alebo celé strany zostáv môžete pripnúť ako dlaždice tabúľ v služba Power BI. Dlaždice sa automaticky obnovia pri každom obnovení základného sémantického modelu.

Pripojenia v režime DirectQuery

Keď používate DirectQuery na pripojenie k zdroju údajov v aplikácii Power BI Desktop, objavia sa nasledujúce výsledky:

• Zdroj vyberiete pomocou možnosti Získať údaje . V prípade relačných zdrojov môžete stále vybrať množinu tabuliek, ktoré definujú dotaz, ktorý logicky vráti množinu údajov. V prípade multidimenzionálnych zdrojov, ako je napríklad SAP Business Warehouse (SAP BW), vyberte len zdroj.

• Pri načítavaní sa do ukladacieho priestoru služby Power BI neimportujú žiadne údaje. Namiesto toho power BI Desktop pri vytváraní vizuálu odošle dotazy na základný zdroj údajov na načítanie potrebných údajov. Čas potrebný na obnovenie vizuálu závisí od výkonu základného zdroja údajov.

• Zmeny príslušných údajov sa v existujúcich vizuáloch neprejavia okamžite. Stále je potrebné vykonať obnovenie. Aplikácia Power BI Desktop znova odošle potrebné dotazy pre každý vizuál a podľa potreby aktualizuje vizuál.

• Publikovaním zostavy do služba Power BI sa vytvorí a nahrá sémantický model, rovnaký ako v prípade importu. Tento sémantický model však neobsahuje žiadne údaje.

• Otvorenie existujúcej zostavy alebo vytvorenie novej zostavy v služba Power BI dotazuje základný zdroj údajov na načítanie potrebných údajov. V závislosti od umiestnenia pôvodného zdroja údajov môže byť potrebné nakonfigurovať lokálnu bránu údajov na získanie údajov.

• Ako dlaždice tabule môžete pripnúť vizuály alebo celé strany zostáv. Aby sa zabezpečilo, že otváranie tabule bude rýchle, dlaždice sa podľa plánu obnovujú automaticky (napríklad každú hodinu). Frekvenciu obnovovania môžete kontrolovať v závislosti od toho, ako často sa údaje menia a od dôležitosti zobrazenia najnovších údajov.

• Keď otvoríte tabuľu, dlaždice zodpovedajú údajom z posledného obnovenia, ktoré nemusia nevyhnutne zodpovedať najnovším zmenám vykonaným v základnom zdroji údajov. Otvorenú tabuľu môžete obnoviť, aby ste mali istotu, že je aktuálna.

Dynamické pripojenia

Keď sa pripojíte k službe SQL Server Analysis Services, môžete si vybrať medzi importom údajov alebo dynamickým pripojením k vybratému dátovému modelu. Dynamické pripojenie je podobné režimu DirectQuery. Žiadne údaje sa neimportujú a na základný zdroj údajov sa dotazuje, aby sa obnovili vizuály.

Keď napríklad použijete import na pripojenie k službe SQL Server Analysis Services, definujete dotaz voči externému zdroju služby SQL Server Analysis Services a importujete údaje. Ak sa pripojíte dynamicky, nedefinujete dotaz a celý externý model sa zobrazí v zozname polí.

Táto situácia platí aj pri pripájaní k nasledujúcim zdrojom, s tým rozdielom, že neexistuje možnosť importovania údajov:

• Sémantické modely Power BI, napríklad pripojenie k sémantickému modelu služby Power BI, ktorý je už publikovaný v službe, s cieľom vytvoriť prostredníctvom neho novú zostavu.

• Microsoft Dataverse.

Pri publikovaní zostáv služby SQL Server Analysis Services, ktoré používajú dynamické pripojenia, je správanie v služba Power BI podobné zostavám DirectQuery nasledujúcimi spôsobmi:

• Otvorenie existujúcej zostavy alebo vytvorenie novej zostavy v služba Power BI dotazuje základný zdroj služby SQL Server Analysis Services, pravdepodobne bude vyžadovať lokálnu bránu údajov.

• Dlaždice tabule sa podľa plánu obnovujú automaticky, napríklad každú hodinu.

Dynamické pripojenie sa od režimu DirectQuery líši aj niekoľkými spôsobmi. Dynamické pripojenia napríklad vždy odovzdajú identitu používateľa, ktorý otvára zostavu, základnému zdroju služby SQL Server Analysis Services.

Prípady použitia režimu DirectQuery

Pripojenie v režime DirectQuery môže byť užitočné v nasledujúcich scenároch. Vo viacerých z týchto prípadov je ponechanie údajov v ich pôvodnom zdrojovom umiestnení potrebné alebo výhodné.

Režim DirectQuery v službe Power BI ponúka najväčšie výhody v nasledujúcich scenároch:

• Údaje sa často menia a potrebujete vytváranie zostáv takmer v reálnom čase.
• Je potrebné spracovať veľké objemy údajov bez potreby predbežnej agregácie.
• Základný zdroj definuje a používa pravidlá zabezpečenia.
• platia obmedzenia suverenity údajov,
• Zdrojom je multidimenzionálny zdroj obsahujúci mierky, napríklad SAP BW.

Údaje sa často menia a potrebujete vytváranie zostáv takmer v reálnom čase

Modely s importovanými údajmi môžete obnovovať maximálne raz za hodinu, častejšie s predplatnými na Power BI Pro alebo Power BI Premium. Ak sa údaje neustále menia a je nutné, aby sa v zostavách zobrazovali najnovšie údaje, použitie importu s plánovaným obnovením nemusí spĺňať vaše potreby. Údaje môžete streamovať priamo do služby Power BI, hoci v tomto prípade existuje obmedzenie podporovaného objemu údajov.

Použitie režimu DirectQuery znamená, že pri otvorení alebo obnovení zostavy alebo tabule sa vždy zobrazia najnovšie údaje v zdroji. Dlaždice tabule možno aktualizovať aj častejšie (až každých 15 minút).

Údaje sú veľmi objemné

Ak sú údaje veľmi objemné, import všetkých údajov nie je uskutočniteľný. Režim DirectQuery nevyžaduje žiadny veľký prenos údajov, pretože dotazuje údaje na mieste. Veľký objem údajov však môže tiež spomaliť výkon dotazov voči danmu základnému zdroju.

Nemusíte vždy importovať všetky podrobné údaje. Tento Editor Power Query zjednodušuje predbežnú agregáciu údajov počas importu. Technicky vzaté je možné importovať presne agregované údaje, ktoré potrebujete pre každý vizuál. Hoci režim DirectQuery predstavuje najjednoduchší prístup k objemným údajom, importovanie agregovaných údajov môže byť riešením, ak je základný zdroj údajov pri režime DirectQuery príliš pomalý.

Tieto podrobnosti sa týkajú iba použitia služby Power BI. Ďalšie informácie o používaní veľkých modelov v službe Power BI nájdete v téme O veľkých sémantických modeloch v službe Power BI Premium. Obmedzená nie je ani frekvencia obnovenia údajov.

Základný zdroj definuje pravidlá zabezpečenia

Pri importovaní údajov sa Power BI pripojí k zdroju údajov pomocou poverení aplikácie Power BI Desktop pre aktuálneho používateľa alebo pomocou prihlasovacích údajov nakonfigurovaných pre plánované obnovenie z služba Power BI. Pri publikovaní a zdieľaní zostáv, ktoré importovali údaje, musíte dbať na to, aby ste ich zdieľali iba s používateľmi, ktorí majú povolené tieto údaje, alebo musíte ako súčasť sémantického modelu definovať zabezpečenie na úrovni riadkov.

Režim DirectQuery umožňuje odovzdať prihlasovacie údaje zobrazovača zostáv základnému zdroju, pričom sa na ne vzťahujú pravidlá zabezpečenia. DirectQuery podporuje jediné prihlásenie (SSO) k zdrojom údajov Azure SQL a prostredníctvom brány údajov aj k lokálnym serverom SQL. Ďalšie informácie nájdete v téme Prehľad jediného prihlásenia (SSO) pre brány v službe Power BI.

platia obmedzenia suverenity údajov,

Niektoré organizácie majú politiky v oblasti suverenity údajov, čo znamená, že údaje nemôžu opustiť priestory organizácie. Tieto údaje predstavujú problémy pri riešeniach založených na importe údajov. V režime DirectQuery zostávajú údaje na základnom mieste zdroja. Aj režim DirectQuery však služba Power BI uchováva niektoré vyrovnávacie pamäte údajov na úrovni vizuálu z dôvodu plánovaného obnovenia dlaždíc.

Základný zdroj údajov používa mierky

Základný zdroj údajov, ako napríklad SAP HANA alebo SAP BW, obsahuje mierky. Mierky znamenajú, že importované údaje už majú určitú úroveň agregácie definovanú dotazom. Vizuál, ktorý požaduje údaje s vyššou úrovňou agregácie, ako je napríklad TotalSales podľa roka, ďalej agreguje agregovanú hodnotu. V prípade súčtových mier, ako je napríklad Sum a Min, je táto agregácia v poriadku, ale v prípade mierok bez pripočítania môže byť problém, ako napríklad Average (Priemer ) a DistinctCount (PočetJe tu).

Jednoduché získanie správnych agregovaných údajov potrebných pre vizuál priamo zo zdroja vyžaduje odosielanie dotazov pre každý vizuál ako v režime DirectQuery. Keď sa pripojíte k SAP BW, výberom režimu DirectQuery sa toto spracovanie mierok umožní. Ďalšie informácie nájdete v téme Režim DirectQuery a SAP BW.

V súčasnosti režim DirectQuery cez SAP HANA zaobchádza s údajmi rovnakým spôsobom ako s relačným zdrojom a produkuje správanie podobné importu. Ďalšie informácie nájdete v téme Režim DirectQuery a SAP HANA.

Obmedzenia režimu DirectQuery

Používanie režimu DirectQuery má niekoľko potenciálne negatívnych dôsledkov. Niektoré z týchto obmedzení sa mierne líšia v závislosti od konkrétneho zdroja, ktorý používate. V nasledujúcich častiach sa uvádzajú všeobecné dôsledky použitia režimu DirectQuery a obmedzenia súvisiace s výkonom, zabezpečením, transformáciami, modelovaním a vykazovaním.

Všeobecné dôsledky

Medzi všeobecné dôsledky a obmedzenia týkajúce sa používania režimu DirectQuery vyplýva:

• Ak sa údaje zmenia, je potrebné ich obnoviť, aby sa zobrazili najnovšie údaje. Vzhľadom na použitie vyrovnávaných pamätí nemožno zaručiť, že vizuály budú vždy zobrazovať najnovšie údaje. Vizuál môže napríklad zobrazovať transakcie za posledný deň. Zmena rýchleho filtra môže obnoviť vizuál tak, aby zobrazoval transakcie za posledné dva dni, vrátane najnovších a novoprijatých transakcií. Ale vrátenie rýchleho filtra do pôvodnej hodnoty by mohlo spôsobiť, že sa znova zobrazí predchádzajúca hodnota uložená vo vyrovnávacej pamäti. Ak chcete vymazať všetky vyrovnávacie pamäte, vyberte položku Obnoviť a obnovte všetky vizuály na stránke, aby sa zobrazili najnovšie údaje.

• V prípade zmeny údajov neexistuje žiadna záruka konzistencie medzi vizuálmi. Rôzne vizuály na rovnakej alebo inej strane či stranách, sa môžu obnovovať v rôznom čase. Ak sa údaje v základnom zdroji menia, nie je zaručené, že bude každý vizuál zobrazovať údaje v rovnakom časovom bode.

  Vzhľadom na to, že na jeden vizuál sa môže vyžadovať viac ako jeden dotaz (napríklad na získanie podrobností a súčtov), nie je zaručená ani konzistencia v rámci jedného vizuálu. Ak by ste konzistentnosť zaručiť chceli, vyžadovalo by to obnovenie všetkých vizuálov vždy, keď sa niektorý vizuál obnoví, ako aj použitie nákladných funkcií v základnom zdroji údajov, ako je napríklad izolácia snímok.

  Tento problém môžete minimalizovať tak, že vyberiete možnosť Obnoviť , aby sa obnovili všetky vizuály na strane. Podobný problém so zachováním konzistentnosti sa vyskytne aj v prípade režimu importu pri importovaní údajov z viac ako jednej tabuľky.

• Ak chcete zohľadniť zmeny schémy, je potrebné obnovenie v aplikácii Power BI Desktop. Po publikovaní zostavy obnoví vizuály v zostave pomocou možnosti Obnoviť v služba Power BI. Ak sa však základná zdrojová schéma zmení, služba Power BI automaticky neaktualizuje zoznam dostupných polí. Ak sa zo základného zdroja odstránia tabuľky alebo stĺpce, môže pri obnovení dôjsť k zlyhaniu dotazu. Ak chcete aktualizovať polia v modeli tak, aby odrážali zmeny, musíte otvoriť zostavu v aplikácii Power BI Desktop a vybrať položku Obnoviť.

• Obmedzenie jedného milióna riadkov sa môže vrátiť pre ľubovoľný dotaz. Existuje pevne daný limit jedného milióna riadkov, ktorý môže v jednom dotaze vrátiť základný zdroj. Toto obmedzenie zvyčajne nemá žiadne dôsledky a vizuály nezobrazujú toľko bodov. Tento limit je však možné dosiahnuť, ak služba Power BI nevykoná úplnú optimalizáciu odoslaných dotazov a požiada o pomocný výsledok, ktorý limit presiahne.

  Obmedzenie môže nastať aj pri vytváraní vizuálu – na ceste k prijateľnejšiemu konečnému stavu. Tento limit môže napríklad dosiahnuť zahrnutie položiek Customer (Zákazník ) a TotalSalesQuantity (Celkový objem predaja), ak existuje viac ako milión zákazníkov, až kým nepoužijete nejaký filter. Chyba, ktorá vráti výsledok: Množina výsledkov dotazu na externý zdroj údajov prekročila maximálnu povolenú veľkosť 1 000 000 riadkov.

  Poznámka

  Kapacity Premium vám umožňujú prekročiť limit jedného milióna riadkov. Ďalšie informácie nájdete v téme Maximálny počet riadkov s priebežným nastavením.

• Model nie je možné zmeniť z režimu importu do režimu DirectQuery. Ak importujete všetky potrebné údaje, model môžete prepnúť z režimu DirectQuery do režimu importu. Nie je možné prepnúť späť do režimu DirectQuery, a to najmä v dôsledku množiny funkcií, ktorú režim DirectQuery nepodporuje. V prípade multidimenzionálnych zdrojov, ako je napríklad SAP BW, sa nemôžete prepnúť z režimu DirectQuery do režimu importu ani z dôvodu odlišného spôsobu spracovania externých mierok.

Vplyv na výkon a načítanie

Ak používate režim DirectQuery, práca s ním závisí od výkonu základného zdroja údajov. Ak napríklad po zmene hodnoty rýchleho filtra trvá obnovenie vizuálu menej ako päť sekúnd, je prostredie primerané, aj keď v porovnaní s okamžitou odozvou s importovanými údajmi sa môže cítiť pomalšie. Ak pre pomalý zdroj trvá obnovenie jednotlivých vizuálov dlhšie ako desať sekúnd, je skúsenosť neprimerane nízka. Dotazom môže dokonca ujsť časový časový predlok.

Okrem výkonu základného zdroja má vplyv aj zaťaženie zdroja. Každý používateľ, ktorý otvorí zdieľanú zostavu, a každá dlaždica tabule, ktorá sa obnoví, odošle na základný zdroj aspoň jeden dotaz pre každý vizuál. Zdroj musí byť schopný takéto zaťaženie spracovať a zároveň si zachovať adekvátny výkon.

Vplyv na zabezpečenie

Pokiaľ základný zdroj údajov nepoužíva jediné prihlásenie, zostava DirectQuery vždy po publikovaní do služba Power BI používa na pripojenie k zdroju rovnaké pevne dané prihlasovacie údaje. Ihneď po publikovaní zostavy DirectQuery je potrebné nakonfigurovať poverenia používateľa, aby ste ho mohli používať. Kým tieto poverenia nenakonfigurujete, pri pokuse o otvorenie zostavy v služba Power BI sa vyskytne chyba.

Keď zadáte prihlasovacie údaje používateľa, Power BI použije tieto poverenia pre každého, kto otvorí zostavu, a to isté ako pre importované údaje. Každý používateľ uvidí rovnaké údaje, pokiaľ v zostave nedefinuje zabezpečenie na úrovni riadkov. Rovnakú pozornosť je potrebné venovať aj zdieľaní zostavy ako pri importovaných údajoch, a to aj v prípade, ak sú v základnom zdroji definované pravidlá zabezpečenia.

• Pripojenie v sémantických modeloch služby Power BI a službách Analysis Services v režime DirectQuery vždy používa jediné prihlásenie, takže zabezpečenie je podobné dynamickým pripojeniam k službe Analysis Services.

• Alternatívne poverenia nie sú podporované pri vytváraní pripojení DirectQuery k SQL Serveru z aplikácie Power BI Desktop. Môžete použiť svoje aktuálne poverenia systému Windows alebo prihlasovacie údaje databázy.

• Viaceré zdroje údajov môžete v modeli DirectQuery použiť pomocou zložených modelov. Keď používate viacero zdrojov údajov, je dôležité pochopiť vplyvy zabezpečenia na to, ako sa údaje medzi základnými zdrojmi údajov presúvajú tam a späť.

Obmedzenia transformácie údajov

Režim DirectQuery obmedzuje transformácie údajov, ktoré môžete použiť v rámci Editor Power Query. V prípade importovaných údajov môžete jednoducho použiť sofistikovanú množinu transformácií, ktorá údaje vyčistí a preformuje, kým ich použijete na vytvorenie vizuálov. Môžete napríklad analyzovať dokumenty JSON alebo kontingenčné údaje zo stĺpca do formulára riadka. Tieto transformácie sú v režime DirectQuery ešte viac obmedzené.

Keď sa pripojíte k online zdroju analytického spracovania (OLAP), ako je SAP BW, nemôžete definovať žiadne transformácie a celý externý model sa preberá zo zdroja. V prípade relačných zdrojov, ako je napríklad SQL Server, môžete stále definovať množinu transformácií pre každý dotaz, tieto transformácie sú však z dôvodu výkonu obmedzené.

Všetky transformácie sa musia použiť v každom dotaze na základný zdroj, nie iba raz pri obnovení údajov. Transformácie musia byť primerane možné preložiť do jedného natívneho dotazu. Ak použijete transformáciu, ktorá je príliš zložitá, zobrazí sa chyba, ktorú buď bude potrebné odstrániť, alebo bude potrebné prepnúť model pripojenia na import.

Okrem toho dialógové okno Získať údaje alebo Editor Power Query použiť čiastkové výbery v rámci dotazov, ktoré vygenerujú a odosielajú na načítanie údajov pre vizuál. Dotazy definované v Editor Power Query musia byť v tomto kontexte platné. Konkrétne to znamená, že nie je možné použiť dotaz s bežnými výrazmi tabuľky, ani dotaz vyvolávajúci uložené procedúry.

Obmedzenia modelovania

Výraz modelovanie v tomto kontexte označuje vylepšenie a obohatenie nespracovaných údajov pri vytváraní zostavy pomocou údajov. Príklady modelovania:

• Definovanie vzťahov medzi tabuľkami.
• pridanie nových výpočtov, ako sú napríklad vypočítané stĺpce a mierky,
• Premenovanie a skrytie stĺpcov a mierok.
• Definovanie hierarchií.
• Definovanie formátovania stĺpcov, predvoleného súhrnu a poradia zoradenia.
• Zoskupenie alebo klastrovanie hodnôt.

Pri používaní režimu DirectQuery môžete vykonať mnohé z týchto obohatení modelu a použiť princíp obohatenia nespracovaných údajov, aby ste zlepšili neskoršie používanie. Niektoré možnosti modelovania však nie sú pri režime DirectQuery k dispozícii alebo sú obmedzené. Tieto obmedzenia sa používajú, aby sa predišlo problémom s výkonom.

Nasledujúce obmedzenia sa spoločné pre všetky zdroje DirectQuery. Na jednotlivé zdroje sa môžu vzťahovať ďalšie obmedzenia.

• Žiadna preddeľovaná hierarchia dátumov: V prípade importovaných údajov má každý stĺpec s dátumom alebo dátumom a časom preddeľujú predvolene aj vstavanú hierarchiu údajov. Ak napríklad importujete tabuľku predajných objednávok obsahujúcu stĺpec OrderDate (DátumObjednávky) a vo vizuáli použijete orderDate (DátumObjednávky ), môžete vybrať vhodnú úroveň dátumu, ako napríklad rok, mesiac alebo deň. Táto preddeľovaná hierarchia dátumov nie je k dispozícii s režimom DirectQuery. Ak je v základnom zdroji k dispozícii tabuľka dátumov (čo je v mnohých údajových skladoch bežné), môžete použiť funkcie časovej inteligencie jazyka DAX (Data Analysis Expressions) ako zvyčajne.

• Podpora dátumu a času iba na úrovni sekúnd: V prípade sémantických modelov, ktoré používajú stĺpce času, vytvára služba Power BI dotazy do základného zdroja DirectQuery iba do úrovne podrobností pre sekundy, nie do milisekúnd. Odstráňte zo zdrojových stĺpcov údaje v milisekundách.

• Obmedzenia vo vypočítaných stĺpcoch: Vypočítané stĺpce môžu byť iba v rámci riadka, čiže môžu odkazovať len na hodnoty iných stĺpcov rovnakej tabuľky bez použitia agregačných funkcií. Povolené skalárne funkcie jazyka DAX, ako LEFT()napríklad , sú tiež obmedzené na funkcie, ktoré možno odoslať do základného zdroja. Tieto funkcie sa líšia v závislosti od presných možností zdroja. Funkcie, ktoré nie sú podporované, nie sú pri vytváraní dotazu DAX pre vypočítaný stĺpec uvedené v automatickom dokončovaní a ich použitie spôsobí chybu.

• Žiadna podpora pre funkcie jazyka DAX typu nadradený-podriadený: Keď ste v režime DirectQuery, nie je možné použiť rodinu DAX PATH() funkcií, ktoré zvyčajne spracovávali štruktúry nadradených a podriadených prvkov, ako sú napríklad grafy kont alebo hierarchie zamestnancov.

• Žiadne klastrovanie: Keď používate režim DirectQuery, nie je možné využiť funkcie klastrovania na automatické vyhľadávanie skupín.

Obmedzenia tvorby zostáv

Modely DirectQuery podporujú takmer všetky možnosti tvorby zostáv. Ak základný zdroj ponúka vhodnú úroveň výkonu, môžete použiť rovnakú množinu vizualizácií ako pri importovaných údajoch.

Jedným zo všeobecných obmedzení je, že maximálna dĺžka údajov v textovom stĺpci pre sémantické modely DirectQuery je 32 764 znakov. Vytváranie zostáv z dlhších textov má za následok chybu.

Nasledujúce funkcie zostáv Power BI môžu spôsobiť problémy s výkonom v zostavách založených na režime DirectQuery:

• Filtre mierok: Vizuály, ktoré používajú mierky alebo zoskupenia stĺpcov, môžu v týchto mierkach obsahovať filtre. Nasledujúci obrázok napríklad zobrazuje SalesAmount (ObjemPredaja ) podľa Category (Kategória), ale iba pre kategórie s predajom väčším ako 20 miliónov .

  

  Tento prístup spôsobí, že na základný zdroj sa odošlú dva dotazy:

  • Prvý dotaz načíta kategórie, ktoré spĺňajú podmienku , že SalesAmount (ObjemPredaja) je väčší ako 20 miliónov.
  • Druhý dotaz načíta údaje potrebné pre vizuál vrátane kategórií, ktoré spĺňajú podmienku WHERE .

  Tento prístup zvyčajne funguje dobre, ak existujú stovky alebo tisíce kategórií, ako v tomto príklade. Ak je počet kategórií ešte väčší, výkon sa môže znížiť. Ak existuje viac ako milión kategórií, dotaz zlyhá.

• Filtre TopN: Môžete definovať rozšírené filtre na filtrovanie iba prvých alebo posledných N hodnôt zoradených podľa miery. Filtre môžu obsahovať napríklad prvých 10 kategórií. Tento prístup opäť posiela do základného zdroja dva dotazy. Prvý dotaz však zo základného zdroja vráti všetky kategórie a potom sa TopN dané kategórie určia na základe vrátených výsledkov. Tento prístup môže viesť k problémom s výkonom alebo k zlyhaniu dotazu v dôsledku obmedzenia jedného milióna riadkov vo výsledkoch dotazu, závisí to však od kardinality daného stĺpca.

• Medián: Každá agregácia, napríklad Sum alebo Count Distinct, sa odosiela do základného zdroja. Základný zdroj však zvyčajne median agregáciu nepodporuje. V prípade mediansa podrobné údaje získavajú zo základného zdroja a medián sa vypočítava z vrátených výsledkov. Tento prístup je vhodný pri výpočte mediánu z pomerne malého počtu výsledkov.

  Ak je kardinalita veľká z dôvodu obmedzenia jedného milióna riadkov, môžu sa vyskytnúť problémy s výkonom alebo zlyhania dotazov. Napríklad dotazovanie na medián počtu obyvateľov krajiny/oblasti môže byť prijateľné, ale medián predajných cien nemusí byť prijateľný.

• Pokročilé textové filtre, napríklad "obsahuje": Rozšírené filtrovanie textového stĺpca umožňuje filtre ako contains a begins with. Tieto filtre môžu v prípade niektorých zdrojov údajov spôsobovať zníženie výkonu. Nepoužívajte najmä predvolený contains filter, ak potrebujete presnú zhodu. Hoci výsledky môžu byť v závislosti od skutočných údajov rovnaké, výkon sa môže v dôsledku týchto indexov významne líšiť.

• Rýchle filtre s viacnásobným výberom: Predvolene umožňujú rýchle filtre iba jeden výber. Povolenie viacnásobného výberu vo filtroch môže spôsobiť problémy s výkonom. Ak používateľ vyberie napríklad 10 produktov, ktoré ho zaujímajú, po každom novom výbere sa na zdroj odošlú dotazy. Aj keď používateľ môže vybrať ďalšiu položku pred dokončením dotazu, znamená to zvýšenú záťaž základného zdroja.

• Súčty vo vizuáloch tabuliek: V tabuľkách a maticiach sa predvolene zobrazujú súčty a medzisúčty. V mnohých prípadoch je získanie hodnôt týchto súčtov vyžaduje odoslanie samostatných dotazov na základný zdroj. Táto požiadavka sa vzťahuje vždy, keď použijete DistinctCount agregáciu, alebo vo všetkých prípadoch, ktoré používajú režim DirectQuery cez SAP BW alebo SAP HANA. Tieto súčty môžete vypnúť pomocou tably Formát .

Odporúčania týkajúce sa režimu DirectQuery

Táto časť poskytuje podrobné pokyny týkajúce sa úspešného používania režimu DirectQuery vzhľadom na ich dôsledky.

Základný výkon zdroja údajov

Overte si, či obnovenie jednoduchých vizuálov trvá do piatich sekúnd, aby ste dosiahli prijateľný interaktívny zážitok. Ak obnovovanie vizuálov trvá dlhšie ako 30 sekúnd, je pravdepodobné, že ďalšie problémy po publikovaní zostavy spôsobí, že riešenie nebude nepoužiteľné.

Ak sú dotazy pomalé, skontrolujte dotazy odoslané na základný zdroj a zistite dôvod pomalého výkonu. Ďalšie informácie nájdete v téme Diagnostika výkonu.

Tento článok sa nezaoberá širokou škálou odporúčaní optimalizácie databázy pre celú množinu potenciálnych základných zdrojov. Nasledujúce štandardné databázové postupy platia vo väčšine situácií:

• Na zlepšenie výkonu sú vzťahy v závislosti od celočíselných stĺpcov namiesto spojenia stĺpcov iných typov údajov.

• Vytvorte vhodné indexy. Tvorba indexu vo všeobecnosti znamená použitie indexov ukladacieho priestoru stĺpcov v zdrojoch, ktoré ich podporujú, napríklad SQL Server.

• Aktualizujte všetky potrebné štatistické údaje v zdroji.

Návrh modelu

Pri definovaní modelu postupujte podľa týchto pokynov:

• Vyhnite sa zložitým dotazom vo Editor Power Query. Editor Power Query preloží zložitý dotaz na jeden dotaz SQL. Jeden dotaz sa zobrazí v čiastkovom výbere každého dotazu odoslaného na danú tabuľku. Ak by bol tento dotaz zložitý, mohlo by dôjsť k problémom s výkonom pri každom jeho odoslaní. Skutočný dotaz SQL pre množinu krokov môžete získať kliknutím pravým tlačidlom myši na posledný krok v časti Použité kroky v Editor Power Query a výberom položky Zobraziť natívny dotaz.

• Používajte jednoduché mierky. Aspoň spočiatku obmedzte mierky na jednoduché agregácie. Ak majú miery uspokojivé výsledky, môžete definovať zložitejšie mierky, ale musíte venovať pozornosť výkonu.

• Nepoužívajte vzťahy vo vypočítaných stĺpcoch. V databázach, v ktorých potrebujete vykonať spojenia viacerých stĺpcov, služba Power BI nepovoľuje vytváranie vzťahov na základe viacerých stĺpcov ako primárneho kľúča alebo cudzieho kľúča. Bežným alternatívnym riešením je zreťaziť stĺpce pomocou vypočítaného stĺpca a spojenie založiť na ňom.

  Toto alternatívne riešenie je vhodné pre importované údaje, ale v prípade režimu DirectQuery spôsobí spojenie výrazu. Tento výsledok zvyčajne bráni použitiu indexov a vedie k nízkemu výkonu. Jediným alternatívnym riešením je v skutočnosti realizovať viacero stĺpcov v jednom stĺpci v základnom zdroji údajov.

• Nepoužívajte vzťahy v stĺpcoch uniqueidentifier. Služba Power BI natívne uniqueidentifier nepodporuje typ údajov. Definovanie vzťahu medzi uniqueidentifier stĺpcami má za následok dotaz so spojením, ktorý zahŕňa pretypovanie. Opäť platí, že takýto prístup často vedie k nízkemu výkonu. Jediným alternatívnym riešením je realizovať stĺpce alternatívneho typu v základnom zdroji údajov.

• Skryte vo vzťahoch stĺpec "do". Stĺpec to vo vzťahoch je zvyčajne primárnym kľúčom to tabuľky. Tento stĺpec by mal byť skrytý, ale ak je skrytý, nezobrazuje sa v zozname polí a nedá sa použiť vo vizuáloch. Stĺpce, na ktorých sú založené vzťahy, sú v skutočnosti systémovými stĺpcami (napríklad náhradné kľúče v údajovom sklade). Stále je najlepšie tieto stĺpce skryť.

  Ak má stĺpec význam, vytvorte viditeľný vypočítaný stĺpec s jednoduchým výrazom, ktorý bude rovnaký ako primárny kľúč, napríklad:

      ProductKey_PK   (Destination of a relationship, hidden)
      ProductKey (= [ProductKey_PK],   visible)
      ProductName
      ...
  

• Skontrolujte všetky vypočítané stĺpce a zmeny typov údajov. Vypočítavané tabuľky môžete použiť pri používaní režimu DirectQuery so zloženými modelmi. Tieto možnosti nie sú nevyhnutne škodlivé, ale budú mať za následok dotazy, ktoré namiesto jednoduchých odkazov na stĺpce obsahujú výrazy. Tieto dotazy môžu spôsobiť, že sa nepoužijú indexy.

• Nepoužívajte vo vzťahoch obojsmerné krížové filtrovanie. Použitie obojsmerného krížového filtrovania môže viesť k príkazom dotazov, ktoré nefungujú správne. Ďalšie informácie o obojsmernom krížovom filtrovaní nájdete v téme Povolenie obojsmerného krížového filtrovania pre režim DirectQuery v aplikácii Power BI Desktop alebo si stiahnite bielu dokumentáciu o obojsmernom krížovom filtrovaní . Príklady v tejto dokumentácii sa týkajú služby SQL Server Analysis Services, ale základné body sa vzťahujú aj na službu Power BI.

• Experimentujte s nastavením Predpokladať použitie referenčnej integrity. Nastavenie Predpokladať použitie referenčnej integrity vo vzťahoch umožňuje dotazom používať INNER JOIN namiesto OUTER JOIN príkazov. Tento pokyn zvyčajne zvýši výkon dotazu, aj keď to závisí od konkrétnych detailov zdroja údajov.

• V Editor Power Query nepoužívajte filtrovanie relatívnych údajov. V Editor Power Query je možné definovať filtrovanie relatívnych dátumov. Môžete napríklad filtrovať riadky, v ktorých je dátum za posledných 14 dní.

  

  Tento filter sa však preloží do filtra na základe pevného dátumu, napríklad času vytvorenia dotazu, ako môžete vidieť v natívnom dotaze.

  

  Tieto údaje pravdepodobne nie sú to, čo chcete. Ak chcete zabezpečiť, aby sa filter použil na základe dátumu v čase spustenia zostavy, použite filter dátumu v zostave. Pomocou funkcie môžete vytvoriť vypočítaný stĺpec, ktorý vypočíta počet dní predtým DAX DATE() , a použiť tento vypočítaný stĺpec vo filtri.

Návrh zostavy

Pri vytváraní zostavy, ktorá používa pripojenie DirectQuery, postupujte podľa týchto pokynov:

• Zvážte použitie možností zníženia počtu dotazov: Služba Power BI poskytuje možnosti zostavy na odoslanie menšieho počtu dotazov a zakázanie určitých interakcií, ktoré spôsobujú slabý výkon v prípade dlhého spúšťania výsledných dotazov. Tieto možnosti platia pri interakcii so zostavou v aplikácii Power BI Desktop a platia aj vtedy, keď ju používatelia používajú v služba Power BI.

  V aplikácii Power BI Desktop získate prístup k týmto možnostiam tak, že prejdete do časti Súbor>Možnosti a nastavenia>Možnosti a vyberiete položku Zníženie počtu dotazov.

  

  Výbery na obrazovke Zníženie počtu dotazov umožňujú zobraziť tlačidlo Použiť pre rýchle filtre alebo výbery filtrov. Neodošlú sa žiadne dotazy, kým nevyberiete tlačidlo Použiť vo filtri alebo v rýchlych filtroch. Dotazy potom použijú vaše výbery na filtrovanie údajov. Toto tlačidlo vám umožní vykonať niekoľko výberov rýchlych filtrov a filtrov ešte predtým, než ich použijete.

• Najprv použite filtre: Vizuál vždy začnite vytvárať pomocou všetkých vhodných filtrov. Napríklad skôr než presuniete položky TotalSalesAmount (CelkovýOblasťPredaja) a ProductName (NázovProduktu) a potom vyfiltrujete konkrétny rok, použijete na začiatok filter Year ( Rok ).

  V každom kroku vytvárania vizuálu sa odosiela dotaz. Aj keď je možné pred dokončením prvého dotazu vykonať ďalšiu zmenu, zbytočne to zaťažuje základný zdroj. Ak filtre použijete už na začiatku, tieto prechodné dotazy budú menej nákladné. Ak filtre nepou ídete včas, môže sa stať, že dosiahnete obmedzenie jedného milióna riadkov.

• Obmedzte počet vizuálov na strane: Keď otvoríte stranu alebo zmeníte rýchly filter alebo filter na úrovni strany, všetky vizuály na strane sa obnovia. Počet paralelných dotazov je limitný. Ako rastie počet vizuálov, niektoré vizuály sa obnovujú sériovo, čím sa zvyšuje čas potrebný na obnovenie strany. Preto je najlepšie obmedziť počet vizuálov na jednej strane a namiesto toho použiť viac jednoduchších strán.

• Zvážte vypnutie interakcií medzi vizuálmi: Predvolene možno vizualizácie na strane zostavy použiť na krížové filtrovanie a krížové zvýraznenie ostatných vizualizácií na strane. Ak napríklad v koláčovom grafe vyberiete rok 1999 , krížovo sa zvýrazní stĺpcový graf, aby sa zobrazil predaj podľa kategórie za rok 1999.

  

  Krížové filtrovanie a krížové zvýraznenie v režime DirectQuery vyžaduje odoslanie dotazov na základný zdroj. Túto interakciu by ste mali vypnúť, ak je reakcia na výbery používateľov neprimerane dlhá.

  Pomocou nastavení Zníženia počtu dotazov môžete krížové zvýraznenie zakázať v celej zostave alebo prípad od prípadu. Ďalšie informácie nájdete v téme Ako sa vizuály navzájom krížovo filtrujú v zostave Power BI.

Maximálny počet pripojení

Môžete nastaviť maximálny počet pripojení, ktoré DirectQuery otvorí pre jednotlivé základné zdroje údajov, a tak riadiť počet dotazov súbežne odoslaných do každého zdroja údajov.

V predvolenom nastavení DirectQuery otvorí maximálne desať súbežných pripojení. Ak chcete zmeniť maximálny počet aktuálneho súboru v aplikácii Power BI Desktop, prejdite na položky Možnosti súboru>a Nastavenia> Možnosti a vyberte položku DirectQuery v časti Aktuálny súbor na ľavej table.

Toto nastavenie je povolené iba vtedy, keď je v aktuálnej zostave aspoň jeden zdroj DirectQuery. Hodnota sa vzťahuje na všetky zdroje DirectQuery a na všetky nové zdroje DirectQuery pridané do tejto zostavy.

Keď zvýšite maximálny počet pripojení na zdroj údajov, umožníte na základný zdroj údajov odosielať ďalšie dotazy, a to až do maximálneho zadaného počtu. Tento prístup je užitočný, ak je na jednej strane veľa vizuálov alebo zostavu pristupuje v rovnakom čase veľa používateľov. Po dosiahnutí maximálneho počtu pripojení sa ďalšie dotazy zaradia do frontu, kým nebude k dispozícii pripojenie. Vyšší limit má za následok väčšiu záťaž základného zdroja, takže nie je zaručené, že toto nastavenie zlepší celkový výkon.

Po publikovaní zostavy do služba Power BI závisí maximálny počet súbežných dotazov od pevných limitov nastavených v cieľovom prostredí, v ktorom je zostava publikovaná. Power BI, Power BI Premium a Power BI Report Server ukladajú rôzne limity. V tabuľke nižšie sú uvedené horné limity aktívnych pripojení na zdroj údajov pre každé prostredie služby Power BI. Tieto obmedzenia sa vzťahujú na cloudové zdroje údajov a lokálne zdroje údajov, ako sú napríklad SQL Server, Oracle a Teradata.

Environment	Horná hranica na zdroj údajov
Power BI Pro	Počet aktívnych pripojení: 10
Power BI Premium	Závisí od obmedzenia sémantického modelu SKU
Power BI Report Server	Počet aktívnych pripojení: 10

Poznámka

Nastavenie maximálneho počtu pripojení DirectQuery sa vzťahuje na všetky zdroje DirectQuery, keď povolíte rozšírené metaúdaje, čo je predvolené nastavenie pre všetky modely vytvorené v aplikácii Power BI Desktop.

Režim DirectQuery v služba Power BI

Všetky zdroje údajov DirectQuery sú podporované z aplikácie Power BI Desktop a niektoré zdroje sú k dispozícii aj priamo z služba Power BI. Podnikový používateľ môže použiť službu Power BI na pripojenie k svojim údajom napríklad v službe Salesforce a okamžite získať tabuľu bez toho, aby použil aplikáciu Power BI Desktop.

Priamo v služba Power BI sú k dispozícii iba tieto dva zdroje s podporou DirectQuery:

• Spark
• Azure Synapse Analytics (predtým Sklad údajov SQL)

Aj v prípade týchto dvoch zdrojov je stále najlepšie spustiť používanie režimu DirectQuery v aplikácii Power BI Desktop. Aj keď je počiatočné vytvorenie pripojenia v služba Power BI jednoduché, existujú obmedzenia ďalšieho vylepšovania výslednej zostavy. V službe napríklad nie je možné vytvoriť žiadne výpočty alebo použiť mnohé analytické funkcie alebo obnoviť metaúdaje tak, aby odrážali zmeny základnej schémy.

Výkon zostavy DirectQuery v služba Power BI závisí od stupňa zaťaženia základného zdroja údajov. Zaťaženie závisí od:

• Počet používateľov, ktorí zdieľajú zostavu a tabuľu.
• Zložitosť zostavy.
• Určuje, či zostava definuje zabezpečenie na úrovni riadkov.

Správanie zostavy v služba Power BI

Keď otvoríte zostavu v služba Power BI, všetky vizuály na aktuálne zobrazenej strane sa obnovia. Každý vizuál vyžaduje aspoň jeden dotaz na základný zdroj údajov. Niektoré vizuály vyžadujú viac dotazov. Vizuál môže napríklad zobrazovať agregované hodnoty z dvoch rôznych tabuliek faktov alebo obsahovať zložitejšiu mierku alebo obsahovať súčty nesúčtových mier, ako je napríklad miera Count Distinct. Pri prechode na novú stranu sa tieto vizuály obnovia. Pri obnovení sa na základný zdroj odošle nová množina dotazov.

Každá interakcia používateľa so zostavou môže spôsobiť obnovenie vizuálov. Výber inej hodnoty v rýchlych filtri napríklad vyžaduje odoslanie novej množiny dotazov, aby sa obnovili všetky dotknuté vizuály. To isté platí aj pre výber vizuálu na krížové zvýraznenie iných vizuálov alebo zmenu filtra. Podobne platí, že vytvorenie alebo úprava zostavy vyžaduje odoslanie dotazov pre každý krok na ceste k vytvoreniu konečného vizuálu.

Niektoré výsledky sa tiež tiež chovpli do vyrovnávacej pamäte. Ak boli nedávno získané presne rovnaké výsledky, vizuál sa obnoví okamžite. Ak je definované zabezpečenie na úrovni riadkov, vyrovnávacie pamäte sa medzi používateľmi nezdieľajú.

Používaním režimu DirectQuery sa v niektorých funkciách, ktoré služba Power BI ponúka pre publikované zostavy, vzťahuje niekoľko dôležitých obmedzení:

• Rýchle prehľady nie sú podporované: Rýchle prehľady Power BI prehľadávajú rôzne podmnožiny sémantického modelu a pomocou množiny sofistikovaných algoritmov umožňujú objavovať potenciálne zaujímavé prehľady. Keďže rýchle prehľady vyžadujú dotazy s vysokým výkonom, táto funkcia nie je k dispozícii v sémantických modeloch, ktoré používajú režim DirectQuery.

• Použitie funkcie Explore in Excel (Preskúmať v Exceli) má za následok slabý výkon: Sémantický model môžete preskúmať pomocou funkcie Explore in Excel (Preskúmať v Exceli ), ktorá vám umožňuje vytvárať kontingenčné tabuľky a kontingenčné grafy v Exceli. Táto funkcia je podporovaná pre sémantické modely, ktoré používajú režim DirectQuery, ale výkon je nižší než pri vytváraní vizuálov v službe Power BI. Ak je pre vaše scenáre použitie Excelu dôležité, mali by ste pri rozhodovaní o tom, či použiť režim DirectQuery, zohľadnite tento problém.

• Excel nezobrazuje hierarchie: Ak napríklad použijete funkciu Analyzovať v Exceli, Excel nezobrazuje žiadne hierarchie definované v modeloch azure Analysis Services alebo sémantických modeloch Power BI, ktoré používajú DirectQuery.

Obnovenie tabule

Na služba Power BI môžete pripnúť jednotlivé vizuály alebo celé strany na tabule ako dlaždice. Dlaždice založené na sémantických modeloch DirectQuery sa automaticky obnovujú odoslaním dotazov do základných zdrojov údajov podľa plánu. V predvolenom nastavení sa sémantické modely obnovujú každú hodinu, ale v rámci sémantických nastavení modelu môžete nakonfigurovať obnovenie medzi týždenne a každých 15 minút.

Ak v modeli nie je definované žiadne zabezpečenie na úrovni riadkov, každá dlaždica sa obnoví raz a výsledky sa budú zdieľať medzi všetkými používateľmi. Ak používate zabezpečenie na úrovni riadkov, každá dlaždica vyžaduje na odoslanie samostatných dotazov na používateľa na základný zdroj.

Môže dôjsť k rozsiahlemu násobiteľspôsobu. Tabuľa s desiatimi dlaždicami, zdieľaná so 100 používateľmi, vytvorená v sémantickom modeli pomocou režimu DirectQuery so zabezpečením na úrovni riadkov, má za následok odoslanie najmenej 1 000 dotazov na základný zdroj údajov na každé obnovenie. Starostlivo zvážte použitie zabezpečenia na úrovni riadkov a konfiguráciu plánu obnovenia.

Časové limity dotazu

Ak na jednotlivé dotazy v služba Power BI platí časový limit štyri minúty. Dotazy, ktoré sú spustené dlhšie ako štyri minúty, zlyhajú. Cieľom tohto limitu je zabrániť problémom spôsobeným príliš dlhým vykonávaním. Režim DirectQuery by ste mali používať iba v prípade zdrojov, ktoré môžu poskytovať interaktívny výkon dotazov.

Diagnostika výkonu

Táto časť popisuje, ako diagnostikovať problémy s výkonom alebo ako získať podrobnejšie informácie na optimalizáciu zostáv.

Začnite diagnostikovať problémy s výkonom radšej v aplikácii Power BI Desktop než v služba Power BI. Problémy s výkonom často vychádzajú z výkonu základného zdroja. Problémy môžete ľahšie identifikovať a diagnostikovať v izolovanejšom prostredí aplikácie Power BI Desktop.

Týmto prístupom okamžite vylúčite určité súčasti, ako je napríklad brána Power BI. Ak sa v aplikácii Power BI Desktop nevyskytnú problémy s výkonom, môžete preskúmať špecifiká zostavy v služba Power BI.

Analyzátor výkonu aplikácie Power BI Desktop je užitočný nástroj na identifikáciu problémov. Pokúste sa izolovať problémy jedného vizuálu a nie viacerých vizuálov na strane. Ak je jeden vizuál na stránke aplikácie Power BI Desktop pomalý, použite Analyzátor výkonu na analýzu dotazov odosielaných do základného zdroja.

Môžete si tiež prezrieť sledovania a diagnostické informácie, ktoré emitujú niektoré základné zdroje údajov. Aj v prípade, že zo zdroja nie sú žiadne sledovania, súbor sledovania môže obsahovať užitočné podrobnosti o spustení dotazu a možnostiach jeho zlepšenia. Pomocou nasledujúceho procesu môžete zobraziť dotazy, ktoré Služba Power BI odošle, a ich časy vykonania.

Zobrazenie dotazov pomocou rozhrania SQL Server Profiler

V predvolenom nastavení zaznamenáva aplikácia Power BI Desktop udalosti počas danej relácie do súboru sledovania s názvom FlightRecorderCurrent.trc. Súbor sledovania sa nachádza v priečinku aplikácie Power BI Desktop aktuálneho používateľa v priečinku s názvom AnalysisServicesWorkspaces.

V prípade niektorých zdrojov DirectQuery zahŕňa tento súbor sledovania všetky dotazy odoslané na základný zdroj údajov. Do denníka odosielajú dotazy nasledujúce zdroje údajov:

• SQL Server
• Databáza Azure SQL
• Azure Synapse Analytics (predtým Sklad údajov SQL)
• Oracle
• Teradata
• SAP HANA

Súbory sledovania si môžete prečítať pomocou rozhrania SQL Server Profiler, ktoré je súčasťou bezplatného nástroja na stiahnutie aplikácie SQL Server Management Studio.

Ak chcete otvoriť súbor sledovania aktuálnej relácie:

1. Počas relácie aplikácie Power BI Desktop vyberte položky Súbor>Možnosti a nastavenia>Možnosti a potom vyberte položku Diagnostika.

2. V časti Zhromažďovanie výpisov pri zlyhaní vyberte položku Otvoriť priečinok s výpismi pri zlyhaní/so sledovaním.

   

   Otvorí sa priečinok Power BI Desktop\Traces .

3. Prejdite do nadradeného priečinka a potom do priečinka AnalysisServicesWorkspaces , ktorý obsahuje jeden priečinok pracovného priestoru pre každú otvorenú inštanciu aplikácie Power BI Desktop. Tieto priečinky majú k názvu príponu celého čísla, napríklad AnalysisServicesWorkspace2058279583. Priečinok pracovného priestoru sa po skončení relácie aplikácie Power BI Desktop odstráni.

   V priečinku pracovného priestoru aktuálnej relácie služby Power BI obsahuje priečinok \Data súbor sledovania FlightRecorderCurrent.trc. Poznačte si umiestnenie.

4. Otvorte nástroj SQL Server Profiler a vyberte položky Súbor>Otvoriť>súbor sledovania.

5. Prejdite na súbor sledovania aktuálnej relácie služby Power BI alebo zadajte cestu k súboru sledovania a otvorte súbor FlightRecorderCurrent.trc.

Nástroj SQL Server Profiler zobrazí všetky udalosti aktuálnej relácie. Nasledujúca snímka obrazovky zvýrazňuje skupinu udalostí pre dotaz. Každá skupina dotazov má nasledujúce udalosti:

• Udalosti Query Begin aQuery End, ktoré predstavujú začiatok a koniec dotazu jazyka DAX generovaného zmenou vizuálu alebo filtra v používateľskom rozhraní služby Power BI, alebo z filtrovania alebo transformácie údajov v Editor Power Query.

• Jeden alebo viacero párov DirectQuery Begin udalostí a DirectQuery End , ktoré predstavujú dotazy odoslané na základný zdroj údajov ako súčasť vyhodnocovania dotazu jazyka DAX.

Súbežne môže bežať viacero dotazov jazyka DAX, takže je možné udalosti z rôznych skupín prekladané. Hodnotu môžete použiť na ActivityID určenie udalostí danej skupiny.

Zaujímajú sa aj nasledujúce stĺpce:

• TextData (Textové údaje): Textové detaily udalosti. V prípade Query Begin udalostí a Query End podrobností je dotaz DAX. V prípade DirectQuery Begin udalostí a DirectQuery End je v podrobnostiach popísaný dotaz SQL odoslaný na základný zdroj. Textové údaje aktuálne vybratej udalosti sa zobrazia aj na table v dolnej časti obrazovky.
• EndTime (Koncový čas): Čas dokončenia udalosti.
• Duration (Trvanie): Čas v milisekundách potrebný na spustenie dotazu jazyka DAX alebo SQL.
• Chyba: Vyskytla sa chyba a v takom prípade sa udalosť zobrazí červenou farbou.

Zaznamenanie sledovania, ktoré vám pomôže diagnostikovať potenciálny problém s výkonom:

1. Otvorte jednu reláciu aplikácie Power BI Desktop, aby ste predišli zámene s viacerými priečinkami pracovného priestoru.

2. V aplikácii Power BI Desktop vykonajte množinu akcií, ktoré ho zaujímajú. Zahrňte aj niekoľko ďalších akcií, aby ste sa uistili, že akcie, ktoré ho zaujímajú, sa zaznamenajú do súboru sledovania.

3. Otvorte nástroj SQL Server Profiler a preskúmajte sledovanie. Nezabúdajte, že keď zatvoríte aplikáciu Power BI Desktop, súbor sledovania sa odstráni. Ďalšie akcie vykonané v aplikácii Power BI Desktop sa nezobrazia okamžite. Ak chcete zobraziť nové udalosti, musíte zavrieť a znova otvoriť súbor sledovania.

Snažte sa, aby jednotlivé relácie boli primerane malé, napríklad desať sekúnd akcií, nie niekoľko stoviek. Týmto spôsobom budete môcť ľahšie interpretovať súbor sledovania. Existuje tiež obmedzenie veľkosti súboru sledovania. V dlhých reláciách môže dôjsť k vynechaniu počiatočných udalostí.

Vysvetlenie formátu dotazov

Všeobecný formát dotazov aplikácie Power BI Desktop používa čiastkové výbery pre každú tabuľku, na ktorú odkazujú. Dotaz Editor Power Query definuje dotazy čiastkového výberu. Predpokladajme napríklad, že máte nasledujúce tabuľky TPC-DS na SQL Serveri:

Spustenie nasledujúceho dotazu:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

Vytvorí nasledujúci vizuál v službe Power BI:

Obnovením vizuálu sa vytvorí dotaz SQL na nasledujúcom obrázku. Existujú tri čiastkové dotazy pre Web_Sales, Itema Date_dim, ktoré vracajú všetky stĺpce v príslušnej tabuľke, aj keď vizuál odkazuje len na štyri stĺpce.

Editor Power Query definuje presné čiastkové dotazy. Pri tomto použití čiastkového výberu dotazov sa nepreukázal vplyv na výkon zdrojov údajov, ktoré podporuje Režim DirectQuery. Zdroje údajov, napríklad SQL Server, optimalizujú odkazy na ostatné stĺpce.

Služba Power BI používa tento vzor preto, že analytik poskytne priamo dotaz SQL. Power BI použije dotaz v poskytnutej podobe bez pokusu o jeho prepísanie.

Súvisiaci obsah

Ďalšie informácie o režime DirectQuery v službe Power BI nájdete v téme:

• Použitie režimu údajov v aplikácii Power BI Desktop

Tento článok opisoval aspekty režimu DirectQuery spoločné pre všetky zdroje údajov. Podrobné informácie o konkrétnych zdrojoch nájdete v nasledujúcich článkoch:

• Režim DirectQuery a SAP HANA
• Režim DirectQuery a SAP BW
• Používanie režimu DirectQuery pre sémantické modely služby Power BI a Analysis Services