Informácie o používaní režimu DirectQuery v službe Power BI

Keď používate aplikáciu Power BI Desktop alebo službu Power BI, môžete sa pripojiť k rôznym druhom zdrojov údajov a rôznymi spôsobmi tieto pripojenia údajov vytvárať. Údaje môžete do služby Power BI importovať, čo je najbežnejší spôsob získania údajov, alebo sa k údajom v pôvodnom zdrojovom odkladacom priestore pripojíte priamo. Tento postup sa označuje ako DirectQuery. Tento článok popisuje funkcie režimu DirectQuery:

  • Rôzne možnosti pripojenia v rámci režimu DirectQuery
  • Pokyny, kedy zvážiť použitie režimu DirectQuery namiesto importovania
  • Nevýhody používania režimu DirectQuery
  • Osvedčené postupy pri používaní režimu DirectQuery

Osvedčené postupy použite pri rozhodovaní, či použiť import alebo režim DirectQuery:

  • Vždy, keď je to možné, mali by ste údaje do služby Power BI importovať. Pri importe sa využíva vysoký výkon nástroja dotazov služby Power BI, ktorý ponúka interaktívne prostredie s množstvom funkcií.
  • Ak importovanie údajov nie je na vaše účely vhodné, zvážte použitie režimu DirectQuery. Ak sa napríklad údaje často menia a zostavy musia zodpovedať najnovším údajom, režim DirectQuery môže byť vhodnejšou voľbou. Použitie režimu DirectQuery je vhodné len vtedy, ak základný zdroj údajov môže typickému agregačnému dotazu poskytnúť interaktívne dotazy (menej ako 5 sekúnd) a je schopný zvládnuť záťaž vyplývajúcu z generovania dotazov. Mali by ste tiež starostlivo zvážiť zoznam obmedzení, ktoré prináša použitie režimu DirectQuery.

Množina funkcií, ktorú služba Power BI ponúka pri používaní importu a režimu DirectQuery, sa postupne vyvíja. Zmeny budú zahŕňať poskytnutie väčšej flexibility pri používaní importovaných údajov, aby bolo možné import využívať vo viacerých prípadoch, a tiež eliminovanie niektorých nevýhod použitia režimu DirectQuery. Bez ohľadu na tieto vylepšenia platí, že pri používaní režimu DirectQuery je rozhodujúci výkon základného zdroja údajov. Ak je základný zdroj údajov pomalý, použitie režimu DirectQuery nebude pre daný zdroj vhodné.

Tento článok popisuje použitie režimu DirectQuery so službou Power BI, a nie so službou SQL Server Analysis Services. Režim DirectQuery je zahrnutý aj v službe SQL Server Analysis Services. Mnohé podrobnosti popísané v tomto článku preto platia aj pre túto funkciu. Existujú však aj dôležité rozdiely. Informácie o používaní režimu DirectQuery so službou SQL Server Analysis Services nájdete v téme Režim DirectQuery v službe SQL Server 2016 Analysis Services.

Tento článok sa zameriava na odporúčaný pracovný postup pri používaní režimu DirectQuery, keď sa zostava vytvára v aplikácii Power BI Desktop, ale zároveň zahŕňa aj postup priameho pripojenia v službe Power BI.

Režimy pripojenia služby Power BI

Služba Power BI sa môže pripojiť k množstvu rôznych zdrojov údajov, medzi ktoré patria:

  • Online služby (Salesforce, Dynamics 365 a ďalšie),
  • databázy (SQL Server, Access, Amazon Redshift a ďalšie),
  • jednoduché súbory (Excel, JSON a ďalšie),
  • iné zdroje údajov (Spark, webové lokality, Microsoft Exchange a ďalšie).

V prípade týchto zdrojov je možné údaje do služby Power BI importovať. K niektorým sa ale 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. V budúcnosti plánujeme pridať do režimu DirectQuery podporu ďalších zdrojov údajov. Zameriavame sa predovšetkým na zdroje, pri ktorých je možné v rámci interaktívnych dotazov očakávať dostatočný výkon.

Služba SQL Server Analysis Services je špeciálny prípad. Keď sa pripájate k službe SQL Server Analysis Services, môžete si vybrať medzi importom údajov alebo dynamickým pripojením. Dynamické pripojenie je podobné režimu DirectQuery. Žiadne údaje sa neimportujú a na základný zdroj údajov sa vždy posiela dotaz, ktorý obnovuje vizuál. Dynamické pripojenie sa v mnohých iných ohľadoch líši, a preto sa používa výraz dynamické pripojenie , aby sa odlíšilo od režimu DirectQuery.

Existujú tri možnosti pripojenia údajov: import, režim DirectQuerydynamické pripojenie.

Pripojenia v rámci importu

Keď pri importe použijete v aplikácii Power BI Desktop príkaz Získať údaje, ktorým sa pripojíte k zdroju údajov, napríklad k SQL Serveru, pripojenie sa bude správať takto:

  • Na začiatku vykonania príkazu Získať údaje sa pre každú množinu vybraných tabuliek definuje dotaz, ktorý vráti množinu údajov. Tieto dotazy je možné pred načítaním údajov upraviť. Môžete napríklad použiť filtre, agregovať údaje alebo spojiť rôzne tabuľky.
  • Pri načítavaní sa všetky údaje definované týmito dotazmi importujú do vyrovnávacej pamäte služby Power BI.
  • Pri vytváraní vizuálu v aplikácii Power BI Desktop sa budú odosielať dotazy na importované údaje. Vďaka uloženiu do služby Power BI prebehne dotaz rýchlo. Všetky zmeny vizuálu sa prejavia okamžite.
  • Zmeny základných údajov sa vo vizuáloch neprejavia. Ak chcete údaje importovať znova, je potrebné ich obnoviť.
  • Pri publikovaní zostavy ako súboru .pbix do služby Power BI sa v službe Power BI vytvorí a nahrá množina údajov. Importované údaje sú súčasťou tejto množiny údajov. Následne je možné naplánovať obnovenie týchto údajov, aby sa napríklad každý deň znova importovali. V závislosti od umiestnenia pôvodného zdroja údajov môže byť potrebné nakonfigurovať lokálnu bránu údajov.
  • Keď v službe Power BI otvárate existujúcu zostavu alebo vytvárate novú zostavu, opäť sa odosielajú dotazy na importované údaje, čím sa zaisťuje interaktivita.
  • Vizuály alebo celé strany zostáv je možné pripnúť ako dlaždice na tabuli. Dlaždice sa aktualizujú automaticky pri každej aktualizácii množiny údajov.

Pripojenia v rámci režimu DirectQuery

Keď pri pripojení pomocou režimu DirectQuery použijete v aplikácii Power BI Desktop príkaz Získať údaje, aby ste sa pripojili k zdroju údajov, pripojenie sa bude správať takto:

  • V počiatočnej fáze príkazu Získať údaje sa vyberie zdroj. V prípade relačných zdrojov sa vyberie množina tabuliek a každá z nich stále definuje dotaz, ktorý logicky vráti množinu údajov. V prípade multidimenzionálnych zdrojov, ako napríklad SAP BW, sa vyberie len zdroj.
  • Pri načítavaní sa však do ukladacieho priestoru služby Power BI neimportujú žiadne údaje. Namiesto toho sa budú pri vytváraní vizuálu v aplikácii Power BI Desktop odosielať dotazy na základný zdroj údajov, aby sa získali potrebné údaje. Čas obnovenia 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. Dotazy potrebné pre každý vizuál sa odosielajú znova a vizuál sa podľa potreby aktualizuje.
  • Pri publikovaní zostavy do služby Power BI sa v službe Power BI znova vytvorí množina údajov – rovnako ako pri importe. Súčasťou tejto množiny údajov však nie sú žiadne údaje.
  • Keď v službe Power BI otvárate existujúcu zostavu alebo vytvárate novú zostavu, opäť sa na získanie potrebných údajov odosiela dotaz na základný zdroj údajov. V závislosti od umiestnenia pôvodného zdroja údajov môže byť potrebné – ako v prípade režimu importu – nakonfigurovať lokálnu bránu údajov pre prípad, že sa údaje obnovia.
  • Vizuály alebo celé strany zostáv je možné pripnúť ako dlaždice na tabuli. 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 obnovenia môžete nastaviť tak, aby zodpovedala tomu, ako často sa údaje menia a ako dôležité je zobrazenie najnovších údajov. Pri otváraní tabule budú dlaždice zodpovedať ú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 pripájate k službe SQL Server Analysis Services, existuje možnosť buď údaje z vybraného modelu údajov importovať, alebo sa k vybranému modelu údajov pripojiť dynamicky. Ak použijete import, definujete dotaz na externý zdroja služby SQL Server Analysis Services a údaje sa importujú obvyklým spôsobom. Ak použijete dynamické pripojenie, žiadny dotaz sa nedefinuje a celý externý model sa zobrazí v zozname polí.

Situácia popísaná v predchádzajúcom odseku platí aj pri pripájaní k nasledujúcim zdrojom, s tým rozdielom, že neexistuje možnosť importovania údajov:

  • Množiny údajov Power BI, napríklad pripojenie k množine údajov Power BI, ktorá bola vytvorená a publikovaná v službe skôr, aby sa pomocou nej vytvorila nová zostava.
  • Microsoft Dataverse.

Správanie zostáv vytvorených pomocou služby SQL Server Analysis Services je pri publikovaní do služby Power BI podobné zostavám DirectQuery nasledujúcimi spôsobmi:

  • Keď v službe Power BI otvárate existujúcu zostavu alebo vytvárate novú zostavu, odosielajú sa dotazy na príslušný zdroj služby SQL Server Analysis Services (pravdepodobne bude vyžadovať lokálnu bránu údajov).
  • Dlaždice tabule sa automaticky obnovujú podľa plánu, napríklad každú hodinu.

Existujú však aj dôležité rozdiely. Pri dynamickom pripojení sa napríklad základnému zdroju služby SQL Server Analysis Services vždy odovzdáva identita používateľa, ktorý otvára zostavu.

Porovnanie máme za sebou – zvyšok článku bude zameraný len na režim DirectQuery.

Kedy je režim DirectQuery užitočný?

V nasledujúcej tabuľke sú popísané scenáre, v ktorých je pripojenie v režime DirectQuery obzvlášť užitočné. Tabuľka obsahuje aj prípady, keď sa za výhodnejšie považuje nechať údaje v pôvodnom zdroji. Popis obsahuje diskusiu o tom, či je daný scenár k dispozícii v službe Power BI.

Obmedzenie Popis
Údaje sa často menia a generovanie zostáv je potrebné takmer v reálnom čase Modely s importovanými údajmi je možné obnoviť maximálne raz za hodinu (častejšie s predplatným 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í tieto požiadavky spĺňať. Ú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 naopak znamená, že pri otvorení alebo obnovení zostavy alebo tabule sa vždy zobrazia najnovšie údaje v zdroji. Dlaždice tabule je navyše možné aktualizovať častejšie (až každých 15 minút).
Údaje sú veľmi objemné Ak sú dáta veľmi objemné, import všetkých údajov nie je uskutočniteľný. Režim DirectQuery naopak objemné prenosy údajov nevyžaduje, pretože dotazy prebiehajú lokálne.

Z objemných údajov však tiež môže vyplývať, že výkon dotazov voči danému základnému zdroju je príliš nízky (ako je to popísané v časti Dôsledky vyplývajúce z používania režimu DirectQuery). Nemusíte zakaždým importovať všetky podrobné údaje. Namiesto toho môžete údaje počas importu vopred agregovať. Editor power query uľahčuje predbežné agregáciu počas importu. V krajných prípadoch by bolo možné importovať konkrétne agregované údaje potrebné pre jednotlivé vizuály. Hoci režim DirectQuery predstavuje najjednoduchší prístup k objemným údajom, importovanie agregovaných údajov môže byť vhodnejšie, ak je základný zdroj príliš pomalý.
V základnom zdroji sú definované pravidlá zabezpečenia Keď sa importujú údaje, služba Power BI sa pripojí k zdroju údajov pomocou prihlasovacích údajov aktuálneho používateľa z aplikácie Power BI Desktop alebo pomocou prihlasovacích údajov, ktoré sú definované v nastavení plánovaného obnovenia zo služby Power BI. Keď takúto zostavu s údajmi v režime Import publikujete a zdieľate, dajte si pozor, aby ste ju zdieľali iba s používateľmi, ktorí môžu zobraziť rovnaké údaje, alebo ako súčasť množiny údajov definujte zabezpečenie na úrovni riadkov.

Režim DirectQuery umožňuje odovzdať prihlasovacie údaje zobrazovača zostavy do základného zdroja a následne použiť pravidlá zabezpečenia. Jediné prihlásenie je podporované pre zdroje údajov SQL Azure a prostredníctvom brány údajov aj pre lokálne servery SQL. Podrobnejšie informácie nájdete v článku 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. Riešenie na základe importu by teda zjavne bolo problematické. Naopak, pri použití režimu DirectQuery tieto údaje zostanú v základnom zdroji.

Aj režim DirectQuery však uchováva niektoré vyrovnávacie pamäte údajov na úrovni vizuálov v službe Power BI, a to kvôli plánovanému obnoveniu dlaždíc.
Základným zdrojom údajov je zdroj OLAP obsahujúci mierky Ak základný zdroj údajov obsahuje mierky, napríklad SAP HANA alebo SAP Business Warehouse, import údajov prináša ďalšie problémy. Znamená to, že importované údaje majú určitú úroveň agregácie, ktorá je definovaná dotazom. Sú to napríklad miery TotalSales (PredajCelkom) za Class (Trieda), Year (Rok) a City (Mesto). Ak je vizuál vytvorený tak, že odosiela dotaz na údaje s vyššou úrovňou agregácie, napríklad na TotalSales (PredajCelkom) za Year (Rok), ďalej agreguje už agregované hodnoty. V prípade súčtových mier, ako je napríklad Sum alebo Min je táto agregácia v poriadku, ale pri nesúčtových mierach, ako je napríklad Average (Priemer) alebo DistinctCount (PočetJedinečných), je problematická.

Ak by ste chceli získanie správnych agregovaných údajov (podľa potrieb konkrétneho vizuálu) priamo zo zdroja uľahčiť, museli by ste dotazy odosielať pre každý vizuál ako v prípade režimu DirectQuery.

Keď sa pripájate k zdroju SAP Business Warehouse (BW), výberom režimu DirectQuery sa toto spracovanie mierok umožní. Informácie o riešení SAP BW nájdete v téme Režim DirectQuery a SAP BW.

V súčasnosti ich však režim DirectQuery cez SAP HANA spracúva rovnakým spôsobom ako relačný zdroj a poskytuje podobné správanie ako import. Tento prístup je podrobnejšie popísaný v téme Režim DirectQuery a SAP HANA.

Môžeme to zhrnúť tak, že vzhľadom na aktuálne možnosti režimu DirectQuery v službe Power BI ponúka režim DirectQuery výhody v nasledujúcich scenároch:

  • údaje sa často menia a generovanie zostáv je potrebné takmer v reálnom čase,
  • spracovanie veľmi objemných údajov bez potreby ich predbežnej agregácie,
  • platia obmedzenia suverenity údajov,
  • zdrojom je multidimenzionálnym zdrojom obsahujúcim miery (napríklad SAP BW).

Podrobnosti v predchádzajúcom zozname sa týkajú iba použitia služby Power BI. Na importovanie údajov by ste tiež mohli použiť externý model služby SQL Server Analysis Services alebo služby Azure Analysis Services. Na pripojenie k tomuto modelu potom môžete použiť službu Power BI. Hoci tento prístup vyžaduje ďalšiu konfiguráciu, poskytuje väčšiu flexibilitu. Umožňuje importovať oveľa väčšie objemy údajov. Obmedzená nie je ani frekvencia obnovenia údajov.

Dôsledky vyplývajúce z používania režimu DirectQuery

Používanie režimu DirectQuery má potenciálne negatívne dôsledky, ktoré sú uvedené v tejto časti. Niektoré z týchto obmedzení sa mierne líšia v závislosti od konkrétneho použitého zdroja. Obmedzeniami sa zaoberáme len tam, kde je to potrebné. Úplne odlišným zdrojom sa venujeme v samostatných článkoch.

Výkon a zaťaženie základného zdroja

Keď používate režim DirectQuery, práca s ním vo veľkej miere závisí od výkonu základného zdroja údajov. Ak napríklad po zmene hodnoty rýchleho filtra trvá obnovenie vizuálu niekoľko sekúnd (zvyčajne menej ako päť sekúnd), je správanie prostredia primerané. V porovnaní s okamžitou odozvou pri importe údajov do služby Power BI sa prostredie môže zdať pomalšie. Ak pre pomalý zdroj trvá načítanie jednotlivých vizuálov dlhšie ako desať sekúnd, je také prostredie úplne nevyhovujúce. Dotazom môže dokonca vypršať časový limit.

Okrem výkonu základného zdroja je potrebné venovať pozornosť aj zaťaženiu zdroja. Zaťaženie má vplyv na výkon. 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 ku každému vizuálu. Táto skutočnosť vyžaduje zdroj, ktorý bude schopný takéto zaťaženie spracovať a zároveň si zachovať adekvátny výkon.

Vplyv na zabezpečenie pri kombinovaní zdrojov údajov

V modeli DirectQuery môžete použiť viacero zdrojov údajov pomocou funkcie Zložené modely, rovnako ako pri importovaní údajov. Ak používate viaceré zdroje údajov, je dôležité vedieť, ako sa údaje medzi základnými zdrojmi údajov presúvajú a aký vplyv na zabezpečenie to prináša.

Obmedzenie transformácií údajov

Podobne existujú obmedzenia v transformáciách údajov, ktoré možno použiť v programe Power Query Editor. V prípade importovaných údajov je možné použiť sofistikovanú množinu transformácií, ktorá údaje vyčistí a nanovo sformuje, kým ich použijete na vytvorenie vizuálov (ako je napríklad analýza dokumentov JSON alebo transformácia orientácie údajov zo stĺpca do riadka). Tieto transformácie sú v režime DirectQuery ešte viac obmedzené.

Keď sa pripájate k zdroju OLAP, ako je napríklad SAP Business Warehouse, nie je možné 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, je stále možné definovať množinu transformácií pre každý dotaz, tieto transformácie sú však z dôvodu výkonu obmedzené.

Takéto transformácie bude nutné použiť v každom dotaze na základný zdroj, nie iba raz pri obnovení údajov, takže sú obmedzené na transformácie, ktoré možno adekvátne 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 do režimu importu.

Okrem toho dotaz, ktorý je výsledkom dialógového okna Získať údaje alebo Editora power query, sa použije v podvýbere v rámci dotazov generovaných a odoslaných na načítanie potrebných údajov pre vizuál. Dotaz definovaný v power query editore musí byť platný v tomto kontexte. Konkrétne to znamená, že nie je možné použiť dotaz používajúci bežné tabuľkové výrazy, 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, ktorá údaje používa. Príklady:

  • Definovanie vzťahov medzi tabuľkami
  • Pridanie nových výpočtov (vypočítaných stĺpcov a vypočítavaných mierok)
  • Premenovanie a skrytie stĺpcov a mierok
  • Definovanie hierarchií
  • Definovanie formátovania, predvoleného súhrnu a zoradenia stĺpcov
  • Zoskupenie alebo klastrovanie hodnôt

Pri používaní režimu DirectQuery je možné stále vykonať mnohé z týchto rozšírení modelu a zároveň stále platí princíp, že nespracované údaje sa rozširujú, aby sa zlepšilo neskoršie používanie. Niektoré možnosti modelovania však nie sú pri používaní režimu DirectQuery dostupné alebo sú obmedzené. Tieto obmedzenia sa vo všeobecnosti používajú, aby sa predišlo problémom s výkonom. Nižšie je uvedený zoznam obmedzení, ktoré platia pre všetky zdroje DirectQuery. Ďalšie obmedzenia, ktoré sa môžu vzťahovať na jednotlivé zdroje, sú popísané v časti Ďalšie kroky.

  • Žiadna preddefinovaná hierarchia údajov: Keď importujete údaje, každý stĺpec s dátumom alebo dátumom a časom bude mať preddefinovanú aj hierarchiu údajov. Ak napríklad importujete tabuľku predajných objednávok vrátane stĺpca OrderDate (DátumObjednávky), pri výbere možnosti OrderDate vo vizuáli budete môcť vybrať vhodnú úroveň (rok, mesiac, deň), ktorú chcete použiť. Táto preddefinovaná hierarchia dátumov nie je v režime DirectQuery k dispozícii. 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 funkcie časovej inteligencie jazyka DAX použiť ako zvyčajne.
  • Podpora dátumu a času iba s presnosťou na sekundy: Pri používaní stĺpcov s časom v množine údajov vytvára služba Power BI dotazy iba pre základný zdroj a do úrovne presnosti na sekundy. Dotazy na milisekundy sa do zdroja DirectQuery neposielajú. Túto časť časov preto zo zdrojových stĺpcov odstráňte.
  • Obmedzenia vo vypočítaných stĺpcoch: Vypočítané stĺpce sú obmedzené na vnútorné riadky – bez použitia agregačných funkcií môžu odkazovať len na hodnoty iných stĺpcov rovnakej tabuľky. Platí tiež, že povolené skalárne funkcie jazyka DAX, ako je napríklad LEFT(), sú obmedzené len na funkcie, ktoré možno odoslať do základného zdroja. Tieto funkcie sa líšia podľa presných možností zdroja. Funkcie, ktoré nie sú podporované, nebudú pri vytváraní funkcie jazyka 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ý-podradený: Ak pracujete v režime DirectQuery, nemôžete používať skupinu funkcií DAX PATH(), ktoré sa zvyčajne používajú na spracovanie štruktúr typu nadradený-podradený, ako je napríklad účtovná osnova alebo hierarchia zamestnancov.
  • Vypočítané tabuľky nie sú podporované: Možnosť definovať vypočítanú tabuľku pomocou výrazov jazyka DAX nie je v režime DirectQuery podporovaná.
  • Filtrovanie vzťahov: Informácie o obojsmernom filtrovaní nájdete v téme Obojsmerné krížové filtrovanie. Ukážky v tejto technickej dokumentácii sa týkajú služby SQL Server Analysis Services. Základné body platia rovnako aj pre službu Power BI.
  • Ž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. Pokiaľ základný zdroj dokáže poskytnúť dostačujúcu úroveň výkonu, je možné použiť rovnakú množinu vizualizácií. Existujú dôležité obmedzenia týkajúce sa niekoľkých ďalších možností, ktoré služba Power BI ponúka po publikovaní zostavy:

  • Rýchle prehľady nie sú podporované: Rýchle prehľady Power BI prehľadávajú rôzne podmnožiny množiny údajov a pomocou skupiny sofistikovaných algoritmov vytvárajú prehľady, ktoré by vás mohli zaujímať. Vzhľadom na dotazy, ktoré sú mimoriadne náročné na výkon, nie je táto funkcia v množinách údajov používajúcich režim DirectQuery k dispozícii.
  • Použitie funkcie Explore in Excel (Preskúmať v Exceli) pravdepodobne zhorší výkon: Údaje v množine údajov môžete preskúmať pomocou funkcie Explore in Excel (Preskúmať v Exceli). Tento prístup umožňuje vytvoriť v Exceli kontingenčné tabuľky a grafy. Hoci je táto funkcia v množinách údajov používajúcich režim DirectQuery podporovaná, výkon je väčšinou horší než pri vytváraní vizuálov v službe Power BI. Platí preto, že ak je pre vás použitie Excelu dôležité, mali by ste s tým pri výbere režimu DirectQuery počítať.
  • Hierarchie sa nezobrazujú v Excel: Pri pripájaní pomocou funkcie DirectQuery z Excel k modelu služby Azure Analysis Services alebo množine údajov služby Power BI, napríklad pomocou funkcie Analyzovať v Excel, sa nezobrazujú žiadne hierarchie definované v modeli alebo množine údajov.
  • Maximálna dĺžka pre textové stĺpce: Maximálna dĺžka údajov v textovom stĺpci pre množiny údajov pomocou DirectQuery je 32 764 znakov. Vytváranie zostáv z textov dlhších ako uvedené bude mať za následok chybu.

Zabezpečenie

Ako to už bolo popísané vyššie v tomto článku, zostava v režime DirectQuery vždy po publikovaní do služby Power BI používa na pripojenie k základnému zdroju údajov rovnaké pevne dané prihlasovacie údaje. Toto správanie sa vzťahuje na DirectQuery, nie na dynamické pripojenia k službe SQL Server Analysis Services, ktoré sa v tomto ohľade líšia. Ihneď po publikovaní zostavy DirectQuery je potrebné nakonfigurovať prihlasovacie údaje používateľa, ktoré sa budú používať. Kým tieto prihlasovacie údaje nenakonfigurujete, spôsobí to pri otvorení zostavy v službe Power BI chybu.

Keď zadáte prihlasovacie údaje používateľa, budú sa používať bez ohľadu na to, ktorý používateľ zostavu otvorí. V tomto ohľade je to úplne rovnaké ako pri importe údajov. Každý používateľ uvidí rovnaké údaje, pokiaľ v zostave nedefinujete zabezpečenie na úrovni riadkov. Rovnakú pozornosť je potrebné venovať aj zdieľaniu zostavy, ak sú v základnom zdroji definované pravidlá zabezpečenia.

Navyše alternatívne prihlasovacie údaje nie sú podporované pri vytváraní pripojení v rámci režimu DirectQuery k serveru SQL z aplikácie Power BI Desktop. Môžete použiť svoje aktuálne prihlasovacie údaje systému Windows alebo prihlasovacie údaje databázy.

Správanie v službe Power BI

Táto časť popisuje správanie zostavy DirectQuery v službe Power BI, aby ste porozumeli úrovni zaťaženia, ktorému bude serverový zdroj údajov vystavený. Toto zaťaženie závisí od počtu používateľov, s ktorými sa budú zostava a tabuľa zdieľať, od zložitosti zostavy a od skutočnosti, či bolo v zostave definované zabezpečenie na úrovni riadkov.

Zostavy – otvorenie, ich používanie a úpravy

Po otvorení zostavy sa všetky vizuály na aktuálne zobrazenej strane obnovia. Každý vizuál zvyčajne 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šie miery či 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ýchlom filtri napríklad vyžaduje odoslanie novej množiny dotazov, aby sa obnovili všetky dotknuté vizuály. To isté platí aj pre kliknutie na vizuál, aby sa krížovo zvýraznili ostatné vizuály, alebo pre zmenu filtra.

Podobne platí, že pri úprave novej zostavy sa vyžaduje, aby sa dotazy odosielali pre každý krok na ceste k vytvoreniu konečného vizuálu.

Niektoré výsledky sa tiež ukladajú 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ú.

Obnovenie tabule

Jednotlivé vizuály alebo celé strany možno pripnúť na tabuľu ako dlaždice. Dlaždice založené na množinách údajov DirectQuery sa obnovujú automaticky podľa plánu. Dlaždice odosielajú dotazy na serverový zdroj údajov. Množiny údajov sa predvolene obnovujú každú hodinu, ale v nastavení množiny údajov je možné obnovenie nakonfigurovať v intervale od 15 minút až po celý týždeň.

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. V opačnom prípade môže dôjsť k rozsiahlemu násobnému efektu. Každá dlaždica vyžaduje, aby so na základný zdroj odoslali samostatné dotazy za každého používateľa.

Tabuľa s desiatimi dlaždicami, zdieľaná so 100 používateľmi, vytvorená v množine údajov pomocou režimu DirectQuery, so zabezpečením na úrovni riadkov a obnovením každých 15 minút by znamenala odosielanie najmenej 1 000 dotazov na serverový zdroj každých 15 minút.

Je preto potrebné starostlivo zvážiť používanie zabezpečenia na úrovni riadkov aj konfiguráciu plánu obnovenia.

Časové limity

Pre jednotlivé dotazy v službe Power BI platí štvorminútový časový limit. Dotazy, ktoré trvajú dlhšie, nebudú úspešné. Zdôrazňovali sme, že režim DirectQuery odporúčame používať v prípade zdrojov, pri ktorých je výkon dotazov takmer interaktívny. Cieľom tohto limitu je zabrániť problémom s príliš dlhou dobou spustenia.

Ďalšie dôsledky

Medzi ďalšie všeobecné dôsledky použitia režimu DirectQuery patria nasledujúce:

  • Ak sa údaje menia, je potrebné ich obnovovať, aby sa zabezpečilo zobrazenie najnovších údajov: Vzhľadom na použitie vyrovnávacích pamätí nemožno zaručiť, že vizuál bude vždy zobrazovať najnovšie údaje. Vizuál môže napríklad zobrazovať transakcie za posledný deň. Pretože sa zmenil rýchly filter, pravdepodobne sa obnoví, aby zobrazoval transakcie za posledné dva dni. K týmto transakciám môžu patriť nedávne, novovzniknuté transakcie. Vrátením rýchleho filtra do pôvodného stavu by sa opäť zobrazila predtým získaná hodnota z vyrovnávacej pamäte.

    Po výbere možnosti Obnoviť sa všetky vyrovnávacie pamäte vymažú a obnovia sa všetky vizuály na strane, aby sa zobrazili najnovšie údaje.

  • Ak sa údaje menia, 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 z rovnakého okamihu. Vzhľadom na to, že niektoré vizuály vyžadujú viac ako jeden dotaz (napríklad na získanie podrobností a súčtov), nie je možné zaručiť konzistentnosť ani 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í, spolu s použitím rôznych 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 zaručením konzistentnosti nastáva aj v prípade, že používate režim importu a údaje importujete z viac ako jednej tabuľky.

  • Obnovenie v aplikácii Power BI Desktop je potrebné pre premietnutie akýchkoľvek zmien metaúdajov: Po publikovaní zostavy sa vizuály v zostave obnovia použitím možnosti Obnoviť. Ak došlo k zmene schémy základného zdroja, týmito zmenami sa automaticky nezmenia dostupné polia v zozname polí. Ak sa zo základného zdroja odstránili tabuľky alebo stĺpce, môže pri obnovení dôjsť k zlyhaniu dotazu. Keď otvoríte zostavu v aplikácii Power BI Desktop a vyberiete možnosť Obnoviť, polia v modeli sa aktualizujú a budú odrážať vykonané zmeny.

  • Obmedzenie jedného milióna riadkov vrátených pre ľubovoľný dotaz: Existuje pevne daný limit jedného milióna riadkov vzťahujúci sa na počet riadkov, ktorý je možné v jednom dotaze vrátiť do základného zdroja. Toto obmedzenie zvyčajne nemá žiadne dôsledky a samotné vizuály nebudú zobrazovať toľko bodov. Obmedzenie je však možné dosiahnuť, ak služba Power BI nevykonáva úplnú optimalizáciu odoslaných dotazov a vyskytne sa požiadavka na medzivýsledok, ktorý limit presiahne. Môže k tomu dôjsť aj pri vytváraní vizuálu – na ceste k prijateľnejšiemu konečnému stavu. Toto obmedzenie by sa dosiahlo napríklad zahrnutím položiek Customer (Zákazník) a TotalSalesQuantity (CelkovýObjemPredaja), ak by existoval viac ako milión zákazníkov a nepoužil by sa žiadny filter.

    Zobrazená chyba by vyzerala takto: „Množina výsledkov dotazu na externý zdroj údajov prekročila maximálnu povolenú veľkosť 1 000 000 riadkov.“

  • Medzi režimami importu a DirectQuery nie je možné prepínať: Hoci v modeli je možné prejsť z režimu DirectQuery do režimu importu, je potrebné importovať všetky potrebné údaje. Takisto potom nie je možné prepnúť späť, a to najmä v dôsledku množiny funkcií, ktoré režim DirectQuery nepodporuje. Modely DirectQuery pracujúce s multidimenzionálnymi zdrojmi, ako napríklad SAP BW, takisto nie je možné prepnúť z režimu DirectQuery na režim importu, a to v dôsledku odlišného spôsobu spracovania externých mier.

Režim DirectQuery v službe Power BI

Z aplikácie Power BI Desktop sú podporované všetky zdroje. Niektoré zdroje sú dostupné aj priamo zo služby Power BI. Podnikový používateľ môže napríklad použiť službu Power BI, aby sa pripojil k údajom v službe Salesforce, a okamžite získať tabuľu bez toho, aby použil aplikáciu Power BI Desktop.

Priamo v tejto službe sú k dispozícii len dva zdroje podporujúce režim DirectQuery:

  • Spark
  • Azure Synapse Analytics (predtým SQL Data Warehouse)

Odporúča sa však, aby ste pri používaní režimu DirectQuery s týmito dvomi zdrojmi začínali v aplikácii Power BI Desktop. Dôvodom je, že ak počiatočné pripojenie nadviažete v službe Power BI, bude platiť množstvo kľúčových obmedzenia. Aj keď bol východiskový bod jednoduchý, ak začnete v službe Power BI, platia obmedzenia týkajúce sa ďalšieho vylepšovania výslednej zostavy. Nemôžete napríklad vytvárať výpočty, používať analytické funkcie ani obnovovať metaúdaje tak, aby zodpovedali zmenám základnej schémy.

Pokyny na úspešné používanie režimu DirectQuery

Ak sa chystáte používať režim DirectQuery, v tejto časti nájdete podrobné pokyny, ktoré vám pomôžu dosiahnuť úspech. Pokyny v tejto časti vyplývajú z vyššie popísaných dôsledkov používania režimu DirectQuery.

Výkon serverového zdroja údajov

Overte si, či obnovenie jednoduchých vizuálov trvá primerane dlho. Primeraný čas obnovenia interaktívneho prostredia je do piatich sekúnd. Ak sa vizuály načítavajú dlhšie ako 30 sekúnd, je vysoko pravdepodobné, že po publikovaní zostavy sa objavia ďalšie problémy. Riešenie tak nemusí byť nepoužiteľné.

Ak sú dotazy pomalé, skontrolujte dotazy, ktoré sa odosielajú na základný zdroj, a zistite dôvod ich výkonu. Tento článok sa nezaoberá rôznymi osvedčenými postupmi optimalizácie databáz pre celý rad potenciálnych základných zdrojov. Zaoberá sa len štandardnými databázovými postupmi, ktoré platia vo väčšine situácií:

  • Vzťahy založené na stĺpcoch s celými číslami vo všeobecnosti poskytujú vyšší výkon ako spojenia stĺpcov iných typov údajov.
  • Mali by sa vytvoriť vhodné indexy. Tvorba indexu vo všeobecnosti znamená, že použijete indexy ukladacieho priestoru stĺpcov v zdrojoch, ktoré ich podporujú, ako je napríklad SQL Server.
  • Mali by sa aktualizovať všetky potrebné štatistické údaje v zdroji.

Pokyny pre návrh modelu

Pri definovaní modelu zvážte nasledujúce pokyny:

  • Vyhnite sa zložitým dotazom v editore power query. Power Query Editor prekladá komplexný dotaz do jedného SQL dotazu. Tento jediný dotaz sa objaví 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ý SQL dotaz pre množinu krokov je možné získať výberom posledného kroku v Editore power query a výberom položky Zobraziť natívny dotaz v kontextovej ponuke.

  • Používajte jednoduché mierky. Aspoň na začiatku odporúčame obmedziť miery na jednoduché agregácie. Až keď majú miery uspokojivé výsledky, môžete začať definovať zložitejšie miery. Stále však sledujte ich výkon.

  • Nepoužívajte vzťahy vo vypočítaných stĺpcoch. Tento pokyn sa týka databáz, v ktorých potrebujete, aby sa v spojeniach používalo viac stĺpcov. Služba Power BI v súčasnosti neumožňuje, aby bol vzťah založený na viacerých stĺpcoch ako cudzí/primárny kľúč. 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 režime DirectQuery spôsobí spojenie výrazu. Takýto výsledok často bráni použitiu indexov a vedie k nízkemu výkonu. Jediným alternatívnym riešením je zlúčiť v základnej databáze niekoľko stĺpcov do jedného.

  • Nepoužívajte vzťahy v stĺpcoch uniqueidentifier. Služba Power BI natívne nepodporuje typ údajov uniqueidentifier. Ak definujete vzťah medzi stĺpcami typu uniqueidentifier, výsledkom bude dotaz so spojením, ktorého súčasťou je zmena typu. Opäť platí, že takýto prístup často vedie k nízkemu výkonu. Kým tento konkrétny prípad nebude optimalizovaný, jediným alternatívnym riešením je zlúčiť stĺpce alternatívneho typu v základnej databáze.

  • Skryte vo vzťahoch cieľový stĺpec. Cieľový stĺpec vzťahu je zvyčajne primárnym kľúčom cieľovej tabuľky. Tento stĺpec by mal byť skrytý. 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). Skrytie takýchto stĺpcov je vhodným krokom. 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ľúč, ako je to uvedené v nasledujúcom príklade:

        ProductKey_PK   (Destination of a relationship, hidden)
        ProductKey (= [ProductKey_PK],   visible)
        ProductName
        ...
    
  • Skontrolujte všetky použitia vypočítaných stĺpcov a zmeny typov údajov. Použitie týchto funkcií nemusí byť nutne škodlivé. Spôsobujú však odosielanie dotazov na základný zdroj, ktoré namiesto jednoduchých odkazov na stĺpce obsahujú výrazy. To môže spôsobiť, že sa nepoužijú indexy.

  • Nepoužívajte vo vzťahoch obojsmerné krížové filtrovanie. Používanie obojsmerného krížového filtrovania môže viesť k príkazom dotazov, ktoré nefungujú správne.

  • 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ť príkazy INNER JOIN namiesto OUTER JOIN. Tento pokyn zvyčajne zvýši výkon dotazu, aj keď to závisí od špecifikácií konkrétneho zdroja údajov.

  • Nepoužívajte filtrovanie relatívnych údajov v editore power query. V editore power query je možné definovať filtrovanie relatívnych dátumov. Môžete napríklad filtrovať riadky obsahujúce dátum z posledných 14 dní.

    Filtrovanie riadkov za posledných 14 dní

    Tento filter však bude fungovať na základe pevného dátumu podľa dňa, kedy bol dotaz vytvorený. Tento výsledok si môžete prezrieť zo zobrazenia natívneho dotazu.

    Filtrovanie riadkov v natívnom dotaze SQL

    Tento výsledok ste pravdepodobne nechceli. Ak chcete mať istotu, že sa filter použije na základe dátumu v okamihu spustenia zostavy, použite ho radšej v zostave ako filter zostavy. V súčasnosti to urobíte tak, že vytvoríte vypočítaný stĺpec, v ktorom pomocou funkcie DAX DATE() vypočítate počet uplynulých dní, a potom tento vypočítaný stĺpec použijete vo filtri.

Pokyny pre návrh zostavy

Pri vytváraní zostavy s pripojením DirectQuery sa riaďte podľa nasledujúcich pokynov:

  • Zvážte použitie možností zníženia počtu dotazov: Služba Power BI umožňuje zostave posielať menej dotazov a zakázať určité interakcie, ktoré by viedli k zníženiu výkonu, ak by výsledné dotazy bežali príliš dlho. V aplikácii Power BI Desktop získate prístup k týmto možnostiam tak, že prejdete do ponuky Súbor > Možnosti a nastavenia > Možnosti a vyberte položku Zníženie počtu dotazov.

    Možnosti zníženia počtu dotazov

    Začiarknutím políčok v časti Zníženie počtu dotazov môžete zakázať krížové zvýrazňovanie v rámci celej zostavy. V rýchlych filtroch alebo vo výberoch filtrov môžete tiež zobraziť tlačidlo Použiť. Umožní vám to vyberať rôzne rýchle filtre a výbery filtrov ešte skôr, než ich použijete. Kým v rýchlom filtri nevyberiete tlačidlo Použiť, neodošlú sa žiadne dotazy. Vybraté možnosti sa potom môžu použiť na filtrovanie údajov.

    Tieto možnosti platia pri práci so zostavou v aplikácii Power BI Desktop. Platia aj pre používateľov, ktorí zostavu používajú v službe Power BI.

  • Najprv použite filtre: Vizuál vždy začnite vytvárať použitím všetkých vhodných filtrov. Napríklad skôr než presuniete položky TotalSalesAmount (CelkovýObjemPredaja) a ProductName (NázovProduktu) a potom vyfiltrujete konkrétny rok, použite filter Year (Rok) hneď na začiatku. 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žijete 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, obnovia sa všetky vizuály na strane. Existuje aj limit počtu súbežne odosielaných dotazov. Ako rastie počet vizuálov, budú sa niektoré vizuály obnovovať sériovo, čím sa predĺži čas potrebný na obnovenie celej strany. Odporúča sa preto obmedziť počet vizuálov na jednej strane a radšej mať niekoľko jednoduchších strán.

  • Zvážte vypnutie interakcie medzi vizuálmi: V predvolenom nastavení 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.

    Niekoľko krížovo filtrovaných a zvýraznených vizuálov

    Krížové filtrovanie a krížové zvýraznenie v režime DirectQuery vyžaduje odoslanie dotazov na základný zdroj. Ak je odozva na výber možností používateľom neprimerane dlhá, mali by ste interakciu radšej vypnúť. Túto interakciu môžete vypnúť. Môžete ju vypnúť buď pre celú zostavu (pozrite si popis v predchádzajúcej časti o možnostiach zníženia počtu dotazov), 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.

Problémy s výkonom môžu okrem predchádzajúcich návrhov spôsobovať aj všetky nasledujúce funkcie zostáv:

  • Filtre mierok: Vizuály zahŕňajúce miery (alebo zoskupenia stĺpcov) môžu v týchto mierach obsahovať filtre. Na nasledujúcom obrázku sa napríklad zobrazuje SalesAmount (ObjemPredaja) podľa Category (Kategórie), ale zahrnuté sú len kategórie s predajom nad 20 miliónov.

    Vizuál zobrazujúci miery, ktoré obsahujú filtre

    Výsledkom tohto prístupu je, že sa na základný zdroj 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 potom načíta údaje potrebné pre vizuál vrátane kategórií, ktoré spĺňajú podmienku klauzuly WHERE.

    Tento prístup zvyčajne funguje dobre, ak sú kategórií stovky alebo tisíce ako v tomto príklade. Ak je počet kategórií ešte väčší, výkon sa môže znížiť. Ak je kategórií, ktoré vyhovujú podmienke, viac ako milión, dotaz zlyhá. Dôvodom je obmedzenie jedného milióna riadkov, o ktorom sme už hovorili.

  • Filtre TopN: Rozšírené filtre môžete definovať tak, aby filtrovali iba prvých alebo posledných N hodnôt zoradených podľa miery. Filtre môžu obsahovať napríklad prvých desať kategórií predchádzajúceho vizuálu. Týmto spôsobom sa na základný zdroj opäť odošlú dva dotazy. Prvý dotaz však zo základného zdroja vráti všetky kategórie a prvých n hodnôt sa určí až 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 dosiahnutia obmedzenia jedného milióna riadkov, závisí to však od kardinality daného stĺpca.

  • Medián: Vo všeobecnosti platí, že každá agregácia, napríklad Sum alebo Count Distinct, sa odosiela do základného zdroja. Neplatí to však pre medián, pretože základný zdroj túto funkciu agregácie väčšinou nepodporuje. V týchto prípadoch sa 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ý, ak sa medián vypočítava z relatívne malého počtu výsledkov. V prípade veľkej kardinality môžu nastať problémy s výkonom alebo môže dotaz zlyhať v dôsledku dosiahnutia obmedzenia jedného milióna riadkov. Napríklad medián počtu obyvateľov krajiny môže byť prijateľný, ale medián predajných cien už nie.

  • Pokročilé textové filtre (obsahuje a podobné): Keď filtrujete textový stĺpec, pokročilé filtrovanie umožňuje používať rôzne filtre, napríklad obsahuje a začína na. Tieto filtre môžu v prípade niektorých zdrojov údajov spôsobovať zníženie výkonu. Obzvlášť predvolený filter obsahuje by sa nemal používať, ak sa snažíte nájsť 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 použitia týchto indexov významne líšiť.

  • Viacnásobné rýchle filtre: Predvolene umožňujú rýchle filtre iba jeden výber. Ak vo filtroch povolíte viacnásobný výber, môže dôjsť k problémom s výkonom, pretože používateľ v rýchlom filtri vyberie množinu položiek. Ak používateľ vyberie napríklad desať produktov, ktoré ho zaujímajú, znamená to, že po každom novom výbere sa na zdroj odošlú dotazy. Aj keby používateľ vybral ďalšiu položku pred dokončením dotazu, takisto to znamená zvýšenú záťaž základného zdroja.

  • Zvážte vypnutie súčtov vo vizuáloch: V tabuľkách a maticiach sa predvolene zobrazujú súčty a medzisúčty. V mnohých prípadoch sa do základného zdroja musia na získanie hodnôt týchto súčtov odosielať samostatné dotazy. Platí to pri každom použití agregácie DistinctCount alebo v prípadoch, keď sa režim DirectQuery používa s riešením SAP BW alebo SAP HANA. Tieto súčty by ste mali vypnúť pomocou tably Formát.

Možnosť nastavenia maximálneho počtu pripojení pre DirectQuery

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

V predvolenom nastavení DirectQuery otvorí maximálne desať simultánnych pripojení. Maximálny počet pre aktuálny súbor môžete zmeniť v aplikácii Power BI Desktop. Prejdite do ponuky Súbor > Možnosti a nastavenia > Možnosti. V časti Aktuálny súbor na ľavej table vyberte položku Publikované nastavenia množiny údajov.

Nastavenie maximálneho počtu pripojení režimu DirectQuery

Toto nastavenie je povolené len 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 tej istej zostavy.

Keď zvýšite maximálny počet pripojení na zdroj údajov, umožníte na základný zdroj údajov odosielať viac dotazov, a to až do maximálneho zadaného počtu. Tento prístup je vhodný, ak je na jednej strane veľa vizuálov alebo zostavu otvára mnoho používateľov naraz. Keď sa dosiahne maximálny počet pripojení, ďalšie dotazy sa zaradia do frontu, kým nebude pripojenie k dispozícii. Zvýšenie tohto limitu 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.

Keď je zostava publikovaná, maximálny počet súbežných dotazov odosielaných na základný zdroj údajov závisí aj od pevných obmedzení. Tieto obmedzenia sa líšia podľa cieľového prostredia, v ktorom sa zostava publikuje. Rôzne prostredia, ako napríklad Power BI, Power BI Premium alebo Power BI Report Server, môžu mať rôzne obmedzenia.

Poznámka

Maximálny počet pripojení DirectQuery sa vzťahuje na všetky zdroje DirectQuery, keď sú povolené rozšírené metaúdaje, čo je predvolené nastavenie pre všetky modely vytvorené v Power BI Desktop.

Diagnostika problémov s výkonom

Táto časť popisuje, ako diagnostikovať problémy s výkonom a ako získať podrobnejšie informácie, ktoré umožnia optimalizovať zostavy.

Odporúčame začať diagnostikovať problémy s výkonom radšej v aplikácii Power BI Desktop než v službe 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é komponenty, ako je napríklad brána Power BI. Ak sa problémy s výkonom v aplikácii Power BI Desktop nevyskytujú, preskúmajte špecifiká zostavy v službe Power BI. Analyzátor výkonu je užitočný nástroj na identifikáciu problémov v rámci tohto procesu.

Podobne sa odporúča najskôr sa pokúsiť izolovať problémy jedného vizuálu, než to skúšať s viacerými vizuálmi na strane.

Povedzme, že ste vykonali kroky popísané v predchádzajúcich odsekoch tejto časti. Teraz máme na strane v aplikácii Power BI Desktop jeden vizuál, ktorý je stále pomalý. Ak chcete zistiť, aké dotazy aplikácia Power BI Desktop odosiela na základný zdroj, použite analyzátor výkonu. Takisto si môžete prezrieť informácie o sledovaní a diagnostike, ktoré generuje základný zdroj údajov. Sledovanie môže tiež obsahovať užitočné podrobnosti o spustení dotazu a možnostiach jeho zlepšenia.

Aj keď informácie o sledovaní v zdroji chýbajú, môžete zobraziť dotazy, ktoré odosiela služba Power BI, spolu s ich časom vykonania. Popis nájdete v ďalšej časti.

Určenie dotazov odoslaných aplikáciou Power BI Desktop

Predvolene zaznamenáva aplikácia Power BI Desktop udalosti počas danej relácie do súboru sledovania s názvom FlightRecorderCurrent.trc.

V prípade niektorých zdrojov DirectQuery sú v tomto denníku uvedené všetky dotazy odoslané na základný zdroj údajov. Zostávajúce zdroje DirectQuery budú zahrnuté v budúcnosti. Do denníka odosielajú dotazy nasledujúce zdroje:

  • SQL Server
  • Databáza Azure SQL
  • Azure Synapse Analytics (predtým SQL Data Warehouse)
  • Oracle
  • Teradata
  • SAP HANA

Súbor sledovania nájdete v priečinku AppData aktuálneho používateľa:

<User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces

K tomuto priečinku sa dostanete tak, keď v aplikácii Power BI Desktop vyberiete položky Súbor > Možnosti a nastavenia > Možnosti a potom položku Diagnostika. Zobrazí sa nasledujúce dialógové okno:

Prepojenie na otvorenie priečinka sledovania

Keď v časti Možnosti diagnostiky vyberiete položku Otvoriť priečinok s výpismi pri zlyhaní/so sledovaním, otvorí sa nasledujúci priečinok: <User>\AppData\Local\Microsoft\Power BI Desktop\Traces.

Keď prejdete do nadradeného priečinka, zobrazí sa priečinok 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 pridanú číselnú príponu, napríklad AnalysisServicesWorkspace2058279583.

V tomto priečinku sa nachádza priečinok \Data. Obsahuje súbor sledovania FlightRecorderCurrent.trc pre aktuálnu reláciu služby Power BI. Zodpovedajúci priečinok pracovného priestoru sa po skončení relácie aplikácie Power BI Desktop odstráni.

Na čítanie súborov sledovania môžete použiť nástroj SQL Server Profiler. Môžete si ho bezplatne stiahnuť ako súčasť aplikácie SQL Server Management Studio.

Po stiahnutí a inštalácii aplikácie SQL Server Management Studio spustite nástroj SQL Server Profiler.

SQL Server Profiler

Súbor sledovania otvoríte takto:

  1. V nástroji SQL Server Profiler vyberte položky File > Open > Trace file (Súbor > Otvoriť > Súbor sledovania).

  2. Zadajte cestu k súboru sledovania aktuálne otvorenej relácie služby Power BI, napríklad: C:\Users<user>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data.

  3. Otvorte súbor FlightRecorderCurrent.trc.

Zobrazia sa všetky udalosti aktuálnej relácie. Tu je zobrazený príklad s poznámkami a zvýraznenými skupinami udalostí. Každá skupina obsahuje nasledujúce udalosti:

  • Udalosti Query BeginQuery End, ktoré predstavujú začiatok a koniec dotazu jazyka DAX vygenerovaného používateľským rozhraním (napríklad z vizuálu alebo z vyplnenia zoznamu hodnôt vo filtri používateľského rozhrania).
  • Jeden alebo viacero párov udalostí DirectQuery BeginDirectQuery End, ktoré predstavujú dotaz odoslaný na základný zdroj údajov v rámci vyhodnotenia dotazu jazyka DAX.

Súbežne môže bežať niekoľko dotazov jazyka DAX, takže je možné udalosti z rôznych skupín prekladať. Hodnotu ActivityID môžete použiť na určenie udalostí patriacich do rovnakej skupiny.

SQL Server Profiler s udalosťami Query Begin a Query End

Ďalšie stĺpce, ktoré by vás mohli zaujímať:

  • TextData (Textové údaje): Textové detaily udalosti. V prípade udalostí Query Begin/End je v podrobnostiach uvedený dotaz DAX. V prípade udalostí DirectQuery Begin/End je v podrobnostiach uvedený dotaz SQL odoslaný na základný zdroj. V dolnej časti sa tiež zobrazuje obsah stĺpca TextData aktuálne vybranej udalosti.
  • EndTime (Koncový čas): Čas dokončenia udalosti.
  • Duration (Trvanie): Čas v milisekundách potrebný na vykonanie dotazu jazyka DAX alebo SQL.
  • Error (Chyba): Označuje prípadnú chybu (ak sa vyskytla, udalosť sa zobrazí červenou farbou).

Na obrázku vyššie sú niektoré menej zaujímavé stĺpce zúžené, aby bolo lepšie vidno ostatné stĺpce.

Pri zaznamenávaní a sledovaní odporúčame nasledujúci postup, ktorý vám pomôže diagnostikovať možné problémy s výkonom:

  • Otvorte len jednu reláciu aplikácie Power BI Desktop, aby ste sa vyhli neprehľadnému zobrazeniu viacerých priečinkov pracovného priestoru.
  • V aplikácii Power BI Desktop vykonajte množinu akcií, ktoré vás zaujímajú. Zahrňte aj niekoľko ďalších akcií, aby ste sa uistili, že akcie, ktoré vás zaujímajú, sa zaznamenajú do súboru sledovania.
  • Otvorte nástroj SQL Server Profiler a podľa vyššie uvedeného postupu preskúmajte sledovanie. Nezabúdajte, že keď zatvoríte aplikáciu Power BI Desktop, súbor sledovania sa odstráni. Takisto sa okamžite nezobrazia ďalšie akcie v aplikácii Power BI Desktop. Súbor sledovania by ste mali zatvoriť a znova otvoriť, aby sa zobrazili nové udalosti.
  • Snažte sa, aby jednotlivé relácie boli primerane krátke, 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, ktoré sa týka veľkosti súboru sledovania. V dlhých reláciách môže dôjsť k vynechaniu počiatočných udalostí.

Princíp formátu dotazu odoslaného aplikáciou Power BI Desktop

Aplikácia Power BI Desktop vytvára a odosiela dotazy vo všeobecnom formáte, ktorý používa čiastkové výbery pre každú odkazovanú tabuľku. Čiastkový Power Query editor dotaz editora. Pozrite si napríklad nasledujúce tabuľky TPC-DS na SQL Serveri:

Tabuľky TPC-DS na SQL Serveri

Zamyslite sa nad nasledujúcim dotazom:

Vzorový dotaz

Výsledkom tohto dotazu je nasledujúci vizuál:

Vizuálny výsledok dotazu

Obnovením vizuálu vznikne nasledujúci dotaz SQL. Ako vidíte, pre tabuľky Web Sales, ItemDate_dim existujú tri čiastkové výbery. Každý z nich vráti všetky stĺpce príslušnej tabuľky, hoci vizuál v skutočnosti odkazuje len na štyri z nich. Dotazy, ktoré sú v čiastkových výberoch tieňované, sú presne výsledkom dotazov definovaných v editore dotazov Power Query Editor. Pri tomto spôsobe použitia čiastkových výberov zatiaľ nebol zaznamenaný vplyv na výkon zdrojov údajov podporujúcich režim DirectQuery. Zdroje údajov, napríklad SQL Server, optimalizujú odkazy na ostatné stĺpce.

Služba Power BI používa tento spôsob, pretože použitý dotaz SQL môže poskytnúť priamo analytik. Použije sa presne tak, ako je poskytnutý, teda bez pokusu o jeho prepísanie.

Dotaz SQL použitý v poskytnutej podobe

Ďalší postup

Tento článok popisuje aspekty režimu DirectQuery spoločné pre všetky zdroje údajov. Existujú však aj určité podrobnosti špecifické pre jednotlivé zdroje. Nasledujúce články popisujú konkrétne zdroje:

Ďalšie informácie o režime DirectQuery získate v nasledujúcich zdrojoch: