DirectQuery a Power BI-ban

A Power BI Desktopban vagy a Power BI szolgáltatás számos különböző adatforráshoz csatlakozhat különböző módokon. Adatokat importálhat a Power BI-ba, amely az adatok lekérésének leggyakoribb módja. Közvetlenül is csatlakozhat néhány adathoz az eredeti forrásadattárban, amelyet DirectQuerynek hívnak. Ez a cikk elsősorban a DirectQuery képességeit ismerteti.

Ez a cikk a következőket ismerteti:

• A Power BI különböző adatkapcsolati beállításai.
• Útmutató a DirectQuery importálás helyett való használatához.
• A DirectQuery használatának korlátozásai és következményei.
• Javaslatok a DirectQuery sikeres használatához.
• A DirectQuery teljesítményproblémáinak diagnosztizálása.

A cikk a DirectQuery munkafolyamatra összpontosít, amikor jelentést hoz létre a Power BI Desktopban, de a DirectQueryn keresztüli kapcsolódást is ismerteti a Power BI szolgáltatás.

Feljegyzés

A DirectQuery az SQL Server Analysis Services egyik funkciója is. Ez a funkció számos részletet oszt meg a Direct Queryvel a Power BI-ban, de vannak fontos különbségek is. Ez a cikk elsősorban a DirectQueryt és a Power BI-t ismerteti, nem az SQL Server Analysis Servicest.

A DirectQuery SQL Server Analysis Services szolgáltatással való használatáról további információt a DirectQuery használata Power BI szemantikai modellekhez és Analysis Serviceshez (előzetes verzió) című témakörben talál. A PDF DirectQueryt az SQL Server 2016 Analysis Servicesben is letöltheti.

Power BI-adatkapcsolati módok

A Power BI számos különböző adatforráshoz csatlakozik, például:

• Online szolgáltatások, például a Salesforce és a Dynamics 365.
• Olyan adatbázisok, mint az SQL Server, az Access és az Amazon Redshift.
• Egyszerű fájlok Excelben, JSON-ban és más formátumokban.
• Más adatforrások, például a Spark, a webhelyek és a Microsoft Exchange.

Ezekből a forrásokból adatokat importálhat a Power BI-ba. Egyes forrásokhoz a DirectQuery használatával is csatlakozhat. A DirectQueryt támogató források összegzése: A DirectQuery által támogatott adatforrások. A DirectQuery-kompatibilis források elsősorban olyan források, amelyek jó interaktív lekérdezési teljesítményt nyújtanak.

Ahol csak lehetséges, adatokat kell importálnia a Power BI-ba. Az importálás kihasználja a Power BI nagy teljesítményű lekérdezési motorját, és rendkívül interaktív, teljes funkcionalitású élményt nyújt.

Ha nem tudja teljesíteni a céljait adatok importálásával, például ha az adatok gyakran változnak, és a jelentéseknek a legújabb adatokat kell tükrözniük, fontolja meg a DirectQuery használatát. A DirectQuery csak akkor valósítható meg, ha a mögöttes adatforrás öt másodpercnél rövidebb idő alatt képes interaktív lekérdezési eredményeket biztosítani egy tipikus összesítő lekérdezéshez, és képes kezelni a létrehozott lekérdezési terhelést. Alaposan gondolja át a DirectQuery használatának korlátait és következményeit.

A Power BI importálási és DirectQuery-képességei idővel fejlődnek. Az importált adatok használatakor nagyobb rugalmasságot biztosító módosítások lehetővé teszik a gyakoribb importálást, és kiküszöbölik a DirectQuery használatának néhány hátrányait. A DirectQuery használatakor a fejlesztésektől függetlenül a mögöttes adatforrás teljesítménye jelentős szempont. Ha egy mögöttes adatforrás lassú, akkor a DirectQuery használata az adott forráshoz nem érhető el.

A következő szakaszok az adatokhoz való kapcsolódás három lehetőségét ismertetik: importálás, DirectQuery és élő kapcsolat. A cikk további része a DirectQueryre összpontosít.

Kapcsolatok importálása

Amikor olyan adatforráshoz csatlakozik, mint az SQL Server, és adatokat importál a Power BI Desktopban, az alábbi eredmények következnek be:

• Amikor először lekéri az adatokat, a kiválasztott táblák minden egyes készlete meghatároz egy lekérdezést, amely egy adatkészletet ad vissza. Ezeket a lekérdezéseket az adatok betöltése előtt szerkesztheti, például szűrők alkalmazásához, az adatok összesítéséhez vagy különböző táblák összekapcsolásához.

• Betöltéskor a lekérdezések által definiált összes adat importálható a Power BI-gyorsítótárba.

• Vizualizáció létrehozása a Power BI Desktopban lekérdezi a gyorsítótárazott adatokat. A Power BI-tároló biztosítja, hogy a lekérdezés gyors legyen, és a vizualizáció minden módosítása azonnal tükrözze.

• A vizualizációk nem tükrözik az adattárban lévő mögöttes adatok változásait. Az adatok frissítéséhez újra kell importálnia.

• Ha a jelentést .pbix-fájlként teszi közzé a Power BI szolgáltatás, létrehoz és feltölt egy szemantikai modellt, amely tartalmazza az importált adatokat. Ezután ütemezheti az adatok frissítését, például naponta újraimportálhatja az adatokat. Az eredeti adatforrás helyétől függően szükség lehet egy helyszíni adatátjáró konfigurálására a frissítéshez.

• Meglévő jelentés megnyitása vagy új jelentés létrehozása a Power BI szolgáltatás az importált adatokat ismét lekérdezi, biztosítva az interaktivitást.

• A vizualizációkat vagy a teljes jelentésoldalakat irányítópult-csempékként rögzítheti a Power BI szolgáltatás. A csempék automatikusan frissülnek, amikor az alapul szolgáló szemantikai modell frissül.

DirectQuery-kapcsolatok

Amikor DirectQuery használatával csatlakozik egy adatforráshoz a Power BI Desktopban, a következő eredmények következnek be:

• A forrás kiválasztásához használja az Adatok lekérése lehetőséget. Relációs források esetén továbbra is kiválaszthat olyan táblákat, amelyek olyan lekérdezést határoznak meg, amely logikailag visszaad egy adathalmazt. Többdimenziós források, például az SAP Business Warehouse (SAP BW) esetében csak a forrást kell kiválasztania.

• Betöltéskor a power BI-tárolóba nem importál adatokat. Vizualizáció létrehozásakor a Power BI Desktop lekérdezéseket küld a mögöttes adatforrásnak a szükséges adatok lekéréséhez. A vizualizáció frissítéséhez szükséges idő az alapul szolgáló adatforrás teljesítményétől függ.

• A mögöttes adatok módosításai nem jelennek meg azonnal a meglévő vizualizációkban. A frissítés továbbra is szükséges. A Power BI Desktop újraküldi az egyes vizualizációkhoz szükséges lekérdezéseket, és szükség szerint frissíti a vizualizációt.

• Ha közzéteszi a jelentést a Power BI szolgáltatás létrehoz és feltölt egy szemantikai modellt, ugyanaz, mint az importáláshoz. Ez a szemantikai modell azonban nem tartalmaz adatokat.

• Meglévő jelentés megnyitása vagy új jelentés létrehozása a Power BI szolgáltatás lekérdezi a mögöttes adatforrást a szükséges adatok lekéréséhez. Az eredeti adatforrás helyétől függően szükség lehet egy helyszíni adatátjáró konfigurálására az adatok lekéréséhez.

• Vizualizációkat vagy teljes jelentésoldalakat irányítópult-csempékként rögzíthet. Az irányítópultok gyors megnyitása érdekében a csempék automatikusan, például óránként frissülnek. A frissítés gyakoriságát attól függően szabályozhatja, hogy milyen gyakran változnak az adatok, és mennyire fontos a legújabb adatok megtekintése.

• Irányítópult megnyitásakor a csempék az utolsó frissítés időpontjában lévő adatokat tükrözik, nem feltétlenül az alapul szolgáló forráson végrehajtott legújabb módosításokat. A megnyitott irányítópultok frissítéséhez ellenőrizze, hogy az aktuális-e.

Élő kapcsolatok

Az SQL Server Analysis Serviceshez való csatlakozáskor dönthet úgy, hogy importálja az adatokat, vagy élő kapcsolatot használ a kiválasztott adatmodellhez. Az élő kapcsolat használata hasonló a DirectQueryhez. A rendszer nem importál adatokat, és a rendszer lekérdezi a mögöttes adatforrást a vizualizációk frissítéséhez.

Ha például importálással csatlakozik az SQL Server Analysis Services szolgáltatáshoz, definiál egy lekérdezést a külső SQL Server Analysis Services-forráshoz, és importálja az adatokat. Ha élőben csatlakozik, nem határoz meg lekérdezést, és a teljes külső modell megjelenik a mezőlistában.

Ez a helyzet akkor is fennáll, ha a következő forrásokhoz csatlakozik, kivéve, ha nincs lehetőség az adatok importálására:

• A Power BI szemantikai modelljei, például a szolgáltatásban már közzétett Power BI szemantikai modellhez csatlakozva új jelentést hozhatnak létre rajta.

• Microsoft Dataverse.

Ha élő kapcsolatokat használó SQL Server Analysis Services-jelentéseket tesz közzé, a Power BI szolgáltatás viselkedése a DirectQuery-jelentésekhez hasonló a következő módokon:

• Meglévő jelentés megnyitása vagy új jelentés létrehozása a Power BI szolgáltatás lekérdezi a mögöttes SQL Server Analysis Services-forrást, esetleg helyszíni adatátjárót igényel.

• Az irányítópult-csempék automatikusan, például óránként frissülnek.

Az élő kapcsolat is különbözik a DirectQuery számos módon. Az élő kapcsolatok például mindig átadják a jelentést megnyitó felhasználó identitását a mögöttes SQL Server Analysis Services-forrásnak.

DirectQuery-használati esetek

A DirectQueryvel való Csatlakozás az alábbi esetekben lehet hasznos. Számos ilyen esetben az adatok eredeti forráshelyén való hagyása szükséges vagy előnyös.

A DirectQuery a Power BI-ban az alábbi helyzetekben nyújtja a legnagyobb előnyöket:

• Az adatok gyakran változnak, és közel valós idejű jelentéskészítésre van szükség.
• A nagyméretű adatokat előaggregálás nélkül kell kezelnie.
• A mögöttes forrás biztonsági szabályokat határoz meg és alkalmaz.
• Az adatok szuverenitására vonatkozó korlátozások érvényesek.
• A forrás egy többdimenziós forrás, amely olyan mértékeket tartalmaz, mint például az SAP BW.

Az adatok gyakran változnak, és közel valós idejű jelentéskészítésre van szükség

Az importált adatokkal rendelkező modelleket óránként legfeljebb egyszer frissítheti, gyakrabban Power BI Pro- vagy Power BI Premium-előfizetésekkel. Ha az adatok folyamatosan változnak, és a jelentéseknek meg kell jeleníteniük a legújabb adatokat, előfordulhat, hogy az ütemezett frissítéssel végzett importálás nem felel meg az igényeinek. Az adatokat közvetlenül a Power BI-ba is streamelheti, bár az ebben az esetben támogatott adatmennyiségek korlátozottak.

A DirectQuery használata azt jelenti, hogy egy jelentés vagy irányítópult megnyitása vagy frissítése mindig a forrásban lévő legfrissebb adatokat jeleníti meg. Az irányítópult csempéi gyakrabban, 15 percenként is frissíthetők.

Az adatok nagyon nagyok

Ha az adatok nagyon nagyok, nem lehet az összeset importálni. A DirectQuery nem igényel nagy adattovábbítást, mert az adatokat a helyén kérdezi le. A nagy méretű adatok azonban túl lassúvá tehetik a lekérdezések teljesítményét az alapul szolgáló forráson.

Nem kell mindig teljes részletes adatokat importálnia. A Power Query-szerkesztő megkönnyíti az adatok előzetes összesítését az importálás során. Technikailag az egyes vizualizációkhoz szükséges összesítő adatok pontosan importálhatók. Bár a DirectQuery a nagy méretű adatok legegyszerűbb megközelítése, az összesített adatok importálása megoldást jelenthet, ha a mögöttes adatforrás túl lassú a DirectQuery számára.

Ezek a részletek csak a Power BI használatára vonatkoznak. A nagy modellek Power BI-ban való használatáról további információt a Power BI Premium nagy szemantikai modelljeiben talál. Az adatok frissítésének gyakorisága nincs korlátozva.

A mögöttes forrás biztonsági szabályokat határoz meg

Adatok importálásakor a Power BI az aktuális felhasználó Power BI Desktop-hitelesítő adataival vagy a Power BI szolgáltatás ütemezett frissítéséhez konfigurált hitelesítő adatokkal csatlakozik az adatforráshoz. Az importált adatokat tartalmazó jelentések közzétételekor és megosztásakor óvatosnak kell lennie, hogy csak az adatok megtekintésére jogosult felhasználókkal ossza meg őket, vagy a szemantikai modell részeként meg kell határoznia a sorszintű biztonságot.

A DirectQuery lehetővé teszi, hogy a jelentésmegjelenítő hitelesítő adatai átjutjanak a mögöttes forrásra, amely biztonsági szabályokat alkalmaz. A DirectQuery támogatja az egyszeri bejelentkezést (SSO) az Azure SQL-adatforrásokra, valamint egy adatátjárón keresztül a helyszíni SQL-kiszolgálókra. További információ: Az egyszeri bejelentkezés (SSO) áttekintése a Power BI-átjárók esetében.

Az adatelkonvertitás korlátozásai érvényesek

Egyes szervezetek az adatelkülönségre vonatkozó szabályzatokkal rendelkeznek, ami azt jelenti, hogy az adatok nem hagyhatják el a szervezet telephelyét. Ezek az adatok az adatimportáláson alapuló megoldásokkal kapcsolatos problémákat mutatnak be. A DirectQuery használatával az adatok a mögöttes forráshelyen maradnak. Azonban még a DirectQuery esetén is a Power BI szolgáltatás a csempék ütemezett frissítése miatt bizonyos adatgyorsítótárakat a vizualizáció szintjén tart.

A mögöttes adatforrás mértékeket használ

Egy mögöttes adatforrás, például az SAP HANA vagy az SAP BW mértékeket tartalmaz. A mértékek azt jelentik, hogy az importált adatok már a lekérdezés által meghatározott bizonyos összesítési szinten vannak. Egy vizualizáció, amely magasabb szintű aggregátumban kér adatokat, például totalSales by Year, tovább összesíti az összesített értéket. Ez az aggregáció az additív mértékek, például a Sum és a Min esetében rendben van, de nem additív mértékek, például az Átlag és a DistinctCount esetében is problémát jelenthet.

A vizualizációkhoz szükséges, közvetlenül a forrásból származó összesítő adatok egyszerű lekéréséhez vizualizációnkénti lekérdezéseket kell küldeni, ahogyan a DirectQueryben is. Amikor csatlakozik az SAP BW-hez, a DirectQuery kiválasztása lehetővé teszi a mértékek kezelését. További információ: DirectQuery és SAP BW.

Az SAP HANA-n keresztüli DirectQuery jelenleg relációs forrásként kezeli az adatokat, és az importáláshoz hasonló viselkedést eredményez. További információ: DirectQuery és SAP HANA.

DirectQuery-korlátozások

A DirectQuery használata negatív következményekkel járhat. Ezen korlátozások némelyike a használt forrástól függően kissé eltér. Az alábbi szakaszok a DirectQuery használatának általános következményeit, valamint a teljesítményre, a biztonságra, az átalakításokra, a modellezésre és a jelentéskészítésre vonatkozó korlátozásokat sorolják fel.

Általános következmények

A DirectQuery használatának néhány általános következménye és korlátozása:

• Ha az adatok megváltoznak, frissítenie kell a legújabb adatok megjelenítéséhez. A gyorsítótárak használata miatt nincs garancia arra, hogy a vizualizációk mindig a legújabb adatokat jelenítik meg. Egy vizualizáció például az elmúlt nap tranzakcióit jelenítheti meg. A szeletelő módosítása frissítheti a vizualizációt az elmúlt két nap tranzakcióinak megjelenítéséhez, beleértve a legutóbbi, újonnan érkezett tranzakciókat is. Ha azonban a szeletelőt az eredeti értékére adja vissza, az azt eredményezheti, hogy ismét megjelenik a gyorsítótárazott előző érték. A Frissítés gombra kattintva törölheti a gyorsítótárakat, és frissítheti a lapon található összes vizualizációt a legújabb adatok megjelenítéséhez.

• Ha az adatok megváltoznak, nincs garancia a vizualizációk közötti konzisztenciára. Előfordulhat, hogy különböző vizualizációk, akár ugyanazon az oldalon, akár különböző oldalakon, különböző időpontokban frissülnek. Ha a mögöttes forrás adatai változnak, nincs garancia arra, hogy minden vizualizáció ugyanabban az időben jeleníti meg az adatokat.

  Mivel egyetlen vizualizációhoz több lekérdezésre is szükség lehet, például a részletek és az összegek lekéréséhez, még az egyetlen vizualizáció konzisztenciája sem garantált. Ennek a konzisztenciának garantálásához az összes vizualizáció frissítésének többletterhelése szükséges minden vizualizáció frissítésekor, valamint olyan költséges funkciók használata, mint például a pillanatképek elkülönítése az alapul szolgáló adatforrásban.

  Ezt a problémát nagy mértékben enyhítheti, ha a Frissítés lehetőséget választva frissíti az oldalon található összes vizualizációt. Az importálási mód esetében is hasonló probléma áll fenn a konzisztencia fenntartásával, ha több táblából importál adatokat.

• A sémaváltozások megjelenítéséhez frissítenie kell a Power BI Desktopban. A jelentés közzététele után a Frissítés a Power BI szolgáltatás frissíti a jelentés vizualizációit. Ha azonban a mögöttes forrásséma megváltozik, a Power BI szolgáltatás nem frissíti automatikusan az elérhető mezők listáját. Ha a rendszer eltávolítja a táblákat vagy oszlopokat a mögöttes forrásból, az a frissítéskor lekérdezési hibát okozhat. Ha frissíteni szeretné a modell mezőit a változásoknak megfelelően, nyissa meg a jelentést a Power BI Desktopban, és válassza a Frissítés lehetőséget.

• Egy 1 millió sorból álló korlát bármely lekérdezésre visszatérhet. Van egy rögzített 1 millió sorból álló korlát, amely bármely lekérdezésben vissza tud térni az alapul szolgáló forráshoz. Ez a korlát általában nem jár gyakorlati következményekkel, és a vizualizációk nem fognak ennyi pontot megjeleníteni. A korlát azonban akkor fordulhat elő, ha a Power BI nem optimalizálja teljes mértékben az elküldött lekérdezéseket, és a korlátot meghaladó köztes eredményt kér.

  A korlát egy vizualizáció létrehozásakor is előfordulhat, egy ésszerűbb végső állapot felé vezető úton. Például az Ügyfél és a TotalSalesQuantity is elérheti ezt a korlátot, ha több mint 1 millió ügyfél van, amíg nem alkalmaz valamilyen szűrőt. A visszaadott hiba a következő: A külső adatforrásba történő lekérdezés eredményhalmaza túllépte az 1000000 sor maximális megengedett méretét.

  Feljegyzés

  A prémium szintű kapacitásokkal túllépheti az egymilliós korlátot. További információkért tekintse meg a köztes sorok maximális számát.

• A modell importálásról DirectQuery módra nem módosítható. Ha az összes szükséges adatot importálja, átválthat egy modellt DirectQuery módról importálási módra. Nem lehet visszaállni DirectQuery módra, elsősorban azért, mert a DirectQuery mód nem támogatja a funkciót. Többdimenziós források, például az SAP BW esetében a külső mértékek eltérő kezelése miatt sem válthat DirectQueryről importálási módra.

A teljesítmény és a terhelés következményei

A DirectQuery használatakor az általános élmény az alapul szolgáló adatforrás teljesítményétől függ. Ha az egyes vizualizációk frissítése, például egy szeletelő értékének módosítása után kevesebb, mint öt másodpercet vesz igénybe, a felhasználói élmény ésszerű, bár lassúnak tűnhet az importált adatokkal való azonnali válaszhoz képest. Ha a forrás lassúsága miatt az egyes vizualizációk frissítése több tíz másodpercnél tovább tart, a felhasználói élmény indokolatlanul gyenge lesz. Előfordulhat, hogy a lekérdezések időtúllépést eredményeznek.

A mögöttes forrás teljesítménye mellett a forrásra helyezett terhelés is hatással van a teljesítményre. Minden felhasználó, aki megnyitja a megosztott jelentést, és minden frissülő irányítópult-csempe vizualizációnként legalább egy lekérdezést küld az alapul szolgáló forrásnak. A forrásnak képesnek kell lennie kezelni egy ilyen lekérdezési terhelést az ésszerű teljesítmény fenntartása mellett.

Biztonsági következmények

Ha a mögöttes adatforrás nem használ egyszeri bejelentkezést, a DirectQuery-jelentések mindig ugyanazokat a rögzített hitelesítő adatokat használják a forráshoz való csatlakozáshoz, miután közzétették a Power BI szolgáltatás. Közvetlenül a DirectQuery-jelentés közzététele után konfigurálnia kell a felhasználó hitelesítő adatait. Amíg nem konfigurálja a hitelesítő adatokat, a jelentés megnyitása a Power BI szolgáltatás hibát eredményez.

Miután megadta a felhasználói hitelesítő adatokat, a Power BI azokat a hitelesítő adatokat használja, akik megnyitja a jelentést, ugyanúgy, mint az importált adatok esetében. Minden felhasználó ugyanazokat az adatokat látja, kivéve, ha a sorszintű biztonság a jelentés részeként van definiálva. A jelentés megosztására ugyanolyan figyelmet kell fordítania, mint az importált adatokra, még akkor is, ha az alapul szolgáló forrásban biztonsági szabályok vannak meghatározva.

• Csatlakozás Power BI szemantikai modellekre és Az Analysis Services DirectQuery módban való használata mindig egyszeri bejelentkezést használ, így a biztonság hasonló az Analysis Services élő kapcsolataihoz.

• A másodlagos hitelesítő adatok nem támogatottak, ha DirectQuery-kapcsolatokat létesít az SQL Serverrel a Power BI Desktopból. Az aktuális Windows-hitelesítő adatait vagy adatbázis-hitelesítő adatait használhatja.

• Egy DirectQuery-modellben több adatforrást is használhat összetett modellek használatával. Ha több adatforrást használ, fontos tisztában lenni azzal, hogy milyen biztonsági következményekkel jár az adatok előre-hátra mozgatása az alapul szolgáló adatforrások között.

Adatátalakítási korlátozások

A DirectQuery korlátozza a Power Query-szerkesztő belül alkalmazható adatátalakításokat. Az importált adatokkal egyszerűen alkalmazhat kifinomult átalakításokat az adatok megtisztítására és átalakítására, mielőtt vizualizációkat hoz létre. Elemezheti például a JSON-dokumentumokat, vagy oszlopból sorűrlapra forgathatja az adatokat. Ezek az átalakítások korlátozottabbak a DirectQueryben.

Amikor egy online elemzési (OLAP) forráshoz, például az SAP BW-hez csatlakozik, nem definiálhat átalakításokat, és a teljes külső modell a forrásból származik. Az olyan relációs források esetében, mint az SQL Server, lekérdezésenként továbbra is definiálhat átalakításokat, de ezek az átalakítások teljesítménybeli okokból korlátozottak.

Minden átalakítást minden lekérdezésen alkalmazni kell az alapul szolgáló forrásra, nem pedig egyszer az adatfrissítésre. Az átalakításoknak képesnek kell lenniük arra, hogy ésszerűen lefordíthatók legyenek egyetlen natív lekérdezésre. Ha túl összetett átalakítást használ, hibaüzenet jelenik meg, hogy vagy törölni kell, vagy a kapcsolati modell importálásra váltott.

Az Adatok lekérése párbeszédpanelen vagy Power Query-szerkesztő az általuk létrehozott és elküldött lekérdezéseken belüli alválasztásokat is használhatja a vizualizációk adatainak lekéréséhez. A Power Query-szerkesztő definiált lekérdezések érvényesnek kell lenniük ebben a környezetben. Nem lehet olyan lekérdezést használni, amely gyakran használt táblakifejezéseket használ, és nem is hívhat meg tárolt eljárásokat.

Modellezési korlátozások

Ebben a kontextusban a modellezés kifejezés azt jelenti, hogy a nyers adatok finomítása és bővítése az adatok használatával történő jelentéskészítés részeként történik. Példák modellezésre:

• Táblák közötti kapcsolatok definiálása.
• Új számítások, például számított oszlopok és mértékek hozzáadása.
• Oszlopok és mértékek átnevezése és elrejtése.
• Hierarchiák definiálása.
• Oszlopformázás, alapértelmezett összegzés és rendezési sorrend meghatározása.
• Értékek csoportosítása vagy csoportosítása.

A DirectQuery használatakor továbbra is számos ilyen modell-bővítést végezhet, és a nyers adatok bővítésének alapelvét használva javíthatja a későbbi felhasználást. Egyes modellezési képességek azonban nem érhetők el vagy korlátozottak a DirectQuery esetében. A rendszer a teljesítményproblémák elkerülése érdekében alkalmazza a korlátozásokat.

Az alábbi korlátozások az összes DirectQuery-forrásra jellemzőek. Az egyes forrásokra további korlátozások vonatkozhatnak.

• Nincs beépített dátumhierarchia: Importált adatok esetén minden date/datetime oszlopban alapértelmezés szerint elérhető egy beépített dátumhierarchia is. Ha például az OrderDate oszlopot tartalmazó értékesítési rendelések tábláját importálja, és az OrderDate értéket egy vizualizációban használja, kiválaszthatja a használni kívánt dátumszintet, például évet, hónapot vagy napot. Ez a beépített dátumhierarchia nem érhető el a DirectQueryvel. Ha a mögöttes forrásban elérhető egy Date tábla, ahogyan az sok adattárházban gyakori, az adatelemzési kifejezések (DAX) időintelligencia-függvényeit a szokásos módon használhatja.

• Dátum/idő támogatás csak másodpercig: Az időoszlopokat használó szemantikai modellek esetében a Power BI csak a másodperces részletességi szintig, nem pedig ezredmásodpercig ad le lekérdezéseket az alapul szolgáló DirectQuery-forrásra. Ezredmásodpercnyi adat eltávolítása a forrásoszlopokból.

• Számított oszlopok korlátozásai: A számított oszlopok csak soron belüliek lehetnek, azaz csak ugyanazon tábla más oszlopainak értékeire hivatkozhatnak összesítő függvények használata nélkül. Emellett az engedélyezett DAX skaláris függvények, például LEFT()a mögöttes forrásba leküldhető függvények. A függvények a forrás pontos képességeitől függően változnak. A nem támogatott függvények nem szerepelnek az automatikus kiegészítésben a számított oszlop DAX-lekérdezésének létrehozásakor, és ha használják, hibát eredményeznek.

• A szülő-gyermek DAX-függvények nem támogatottak: DirectQuery módban nem lehet olyan függvénycsaládot DAX PATH() használni, amely általában szülő-gyermek struktúrákat, például fiókdiagramokat vagy alkalmazotti hierarchiákat kezel.

• Nincs fürtözés: A DirectQuery használatakor nem használhatja a fürtözési képességet a csoportok automatikus keresésére.

Jelentéskészítési korlátozások

A DirectQuery-modellek szinte minden jelentéskészítési képessége támogatott. Mindaddig, amíg a mögöttes forrás megfelelő teljesítményt nyújt, ugyanazokat a vizualizációkat használhatja, mint az importált adatok esetében.

Az egyik általános korlátozás az, hogy a DirectQuery szemantikai modellek szövegoszlopaiban legfeljebb 32 764 karakter hosszúságú adatok láthatók. A hosszabb szövegekről való jelentéskészítés hibát eredményez.

A Következő Power BI-jelentéskészítési képességek teljesítményproblémákat okozhatnak a DirectQuery-alapú jelentésekben:

• Mértékszűrők: A mértékeket vagy oszlopösszesítéseket használó vizualizációk szűrőket tartalmazhatnak ezekben a mértékekben. Az alábbi ábrán például a SalesAmount kategória szerint látható, de csak a 20 M-nél több értékesítést tartalmazó kategóriák esetében.

  

  Ez a módszer két lekérdezést küld a mögöttes forrásnak:

  • Az első lekérdezés lekéri a 20 milliónál nagyobb SalesAmount feltételnek megfelelő kategóriákat.
  • A második lekérdezés lekéri a vizualizációhoz szükséges adatokat, amelyek tartalmazzák a feltételnek megfelelő WHERE kategóriákat.

  Ez a megközelítés általában akkor működik jól, ha több száz vagy több ezer kategória van, mint ebben a példában. A teljesítmény csökkenhet, ha a kategóriák száma sokkal nagyobb. A lekérdezés meghiúsul, ha több mint egymillió kategória van.

• TopN-szűrők: Speciális szűrőket határozhat meg, amelyekkel csak a mérték által rangsorolt felső vagy alsó N értékekre szűrhet. A szűrők közé tartozhat például a 10 legjobb kategória. Ez a módszer ismét két lekérdezést küld a mögöttes forrásnak. Az első lekérdezés azonban az alapul szolgáló forrás összes kategóriáját visszaadja, majd a rendszer a TopN visszaadott eredmények alapján határozza meg azokat. Az érintett oszlop számosságától függően ez a megközelítés teljesítményproblémákhoz vagy lekérdezési hibákhoz vezethet a lekérdezési eredmények egymillió sorkorlátja miatt.

• Medián: A rendszer minden összesítést leküld a mögöttes forrásba, például Sum vagy Count Distinct. Az aggregátumot azonban általában median nem támogatja a mögöttes forrás. A medianrendszer a részletes adatokat a mögöttes forrásból kéri le, a medián pedig a visszaadott eredményekből lesz kiszámítva. Ez a megközelítés ésszerű a medián viszonylag kis számú eredmény alapján történő kiszámításához.

  Teljesítményproblémák vagy lekérdezési hibák akkor fordulhatnak elő, ha a számosság nagy az egymilliós sorkorlát miatt. Előfordulhat például, hogy a medián ország/régió lakosságának lekérdezése ésszerű, de a medián értékesítési ár nem feltétlenül ésszerű.

• Speciális szövegszűrők, például a "tartalmaz": A szövegoszlopok speciális szűrése lehetővé teszi a hasonló és begins withhasonló contains szűrőket. Ezek a szűrők egyes adatforrások teljesítménycsökkenéséhez vezethetnek. Ha pontos egyezésre van szüksége, ne használja az alapértelmezett contains szűrőt. Bár az eredmények a tényleges adatoktól függően azonosak lehetnek, az indexek miatt a teljesítmény drasztikusan eltérő lehet.

• Többválasztós szeletelők: Alapértelmezés szerint a szeletelők csak egyetlen kijelölést engedélyeznek. A szűrők többszörös kijelölésének engedélyezése teljesítményproblémákat okozhat. Ha például a felhasználó 10 érdekes terméket választ ki, minden új kijelölés azt eredményezi, hogy a rendszer lekérdezéseket küld a forrásnak. Bár a felhasználó a lekérdezés befejezése előtt kiválaszthatja a következő elemet, ez a megközelítés további terhelést eredményez az alapul szolgáló forrásra.

• Táblavizualizációk összesítése: Alapértelmezés szerint a táblák és mátrixok az összegeket és részösszegeket jelenítik meg. Az ilyen összegek értékeinek lekéréséhez sok esetben külön lekérdezéseket kell küldeni a mögöttes forrásnak. Ez a követelmény minden olyan esetben érvényes, amikor aggregációt használ DistinctCount , vagy minden olyan esetben, amely DirectQueryt használ AZ SAP BW-n vagy AZ SAP HANA-n keresztül. Az ilyen összegeket a Formátum panelen kapcsolhatja ki.

DirectQuery-javaslatok

Ez a szakasz magas szintű útmutatást nyújt a DirectQuery sikeres használatához, figyelembe véve annak következményeit.

Mögöttes adatforrás teljesítménye

Ellenőrizze, hogy az egyszerű vizualizációk öt másodpercen belül frissülnek-e, hogy ésszerű interaktív élményt nyújtson. Ha a vizualizációk frissítése 30 másodpercnél tovább tart, valószínű, hogy a jelentés közzétételét követő további problémák megoldhatatlanná teszik a megoldást.

Ha a lekérdezések lassúak, vizsgálja meg a mögöttes forrásnak küldött lekérdezéseket, valamint a lassú teljesítmény okát. További információ: Teljesítménydiagnosztika.

Ez a cikk nem terjed ki az adatbázis-optimalizálási javaslatok széles körére a lehetséges mögöttes források teljes halmazában. A legtöbb esetben az alábbi szabványos adatbázis-eljárások érvényesek:

• A jobb teljesítmény érdekében a kapcsolatokat egész számoszlopokra alapozza ahelyett, hogy más adattípusok oszlopait összekapcsolja.

• Hozza létre a megfelelő indexeket. Az indexek létrehozása általában azt jelenti, hogy az oszloptár-indexeket olyan forrásokban használják, amelyek támogatják őket, például az SQL Servert.

• Frissítse a forrásban található összes szükséges statisztikát.

Modellterv

A modell meghatározásakor kövesse az alábbi útmutatást:

• Kerülje az összetett lekérdezéseket Power Query-szerkesztő. Power Query-szerkesztő egy összetett lekérdezést egyetlen SQL-lekérdezésre fordít le. Az egyetlen lekérdezés az adott táblába küldött összes lekérdezés alválasztásában jelenik meg. Ha ez a lekérdezés összetett, teljesítményproblémákat okozhat minden elküldött lekérdezésnél. A lépések egy csoportjához tartozó TÉNYLEGES SQL-lekérdezést úgy kérheti le, ha a jobb gombbal az utolsó lépésre kattint a Power Query-szerkesztő Alkalmazott lépések területen, majd a Natív lekérdezés megtekintése parancsot választja.

• A mértékek egyszerűek maradnak. Legalább kezdetben a mértékeket egyszerű aggregátumokra korlátozza. Ha a mértékek megfelelően működnek, összetettebb mértékeket határozhat meg, de figyeljen a teljesítményre.

• Kerülje a számított oszlopok kapcsolatait. Azokban az adatbázisokban, ahol többoszlopos illesztést kell végrehajtania, a Power BI nem engedélyezi a több oszlopon lévő kapcsolatok alapozását elsődleges kulcsként vagy idegen kulcsként. A gyakori megkerülő megoldás az oszlopok összefűzése számított oszlop használatával, és az illesztés alapja az adott oszlop.

  Ez a kerülő megoldás az importált adatok esetében ésszerű, de a DirectQuery esetében ez egy kifejezés összekapcsolásához vezet. Ez az eredmény általában megakadályozza az indexek használatát, és gyenge teljesítményhez vezet. Az egyetlen megkerülő megoldás az, ha a több oszlopot egyetlen oszlopba helyezi az alapul szolgáló adatforrásban.

• Kerülje a kapcsolatokat a "uniqueidentifier" oszlopokban. A Power BI natív módon nem támogatja az adattípusokat uniqueidentifier . Az oszlopok közötti uniqueidentifier kapcsolat definiálása egy olyan lekérdezést eredményez, amelyhez egy illesztés tartozik, amely egy leadással jár. Ez a megközelítés gyakran gyenge teljesítményhez vezet. Az egyetlen kerülő megoldás az, ha egy alternatív típusú oszlopot hoz létre a mögöttes adatforrásban.

• Rejtse el a "to" oszlopot a kapcsolatokon. A to kapcsolatok oszlopa általában a tábla elsődleges kulcsa to . Az oszlopnak rejtettnek kell lennie, de ha rejtett, akkor nem jelenik meg a mezőlistában, és nem használható vizualizációkban. A kapcsolatok alapjául szolgáló oszlopok gyakran valójában rendszeroszlopok, például helyettesítő kulcsok egy adattárházban. Még mindig a legjobb elrejteni az ilyen oszlopokat.

  Ha az oszlop jelentéssel rendelkezik, vezessen be egy olyan számított oszlopot, amely látható, és amelynek egyszerű kifejezése megegyezik az elsődleges kulccsal, például:

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

• Vizsgálja meg az összes számított oszlopot és adattípus-módosítást. Számított táblákat akkor használhat, ha a DirectQueryt összetett modellekkel használja. Ezek a képességek nem feltétlenül károsak, de olyan lekérdezéseket eredményeznek, amelyek kifejezéseket tartalmaznak, nem pedig egyszerű oszlopokra mutató hivatkozásokat. Ezek a lekérdezések azt eredményezhetik, hogy az indexek nem lesznek használatban.

• Kerülje a kétirányú keresztszűréseket a kapcsolatokon. A kétirányú keresztszűrés olyan lekérdezési utasításokhoz vezethet, amelyek nem teljesítenek megfelelően. A kétirányú keresztszűrésről további információt a DirectQuery kétirányú keresztszűrésének engedélyezése a Power BI Desktopban című témakörben, vagy a kétirányú keresztszűrésről szóló tanulmányban talál. A dokumentumban szereplő példák az SQL Server Analysis Servicesre vonatkoznak, de az alapvető szempontok a Power BI-ra is érvényesek.

• Kísérletezzen a hivatkozási integritás feltételezése beállításával. A kapcsolatok hivatkozási integritásának feltételezése beállítás lehetővé teszi a lekérdezések használatát INNER JOIN utasítások helyett OUTER JOIN . Ez az útmutató általában javítja a lekérdezési teljesítményt, bár az adatforrás jellemzőitől függ.

• Ne használja a relatív adatszűrést a Power Query-szerkesztő. A relatív dátumszűrés definiálható Power Query-szerkesztő. Szűrhet például azokra a sorokra, ahol a dátum az elmúlt 14 napban van.

  

  Ez a szűrő azonban egy rögzített dátum , például a lekérdezés létrehozási ideje alapján szűrővé alakul, ahogyan az a natív lekérdezésben is látható.

  

  Ezek az adatok valószínűleg nem azok, amelyeket szeretne. Ha meg szeretné győződni arról, hogy a szűrő a jelentés futtatásakor megadott dátum alapján van alkalmazva, alkalmazza a dátumszűrőt a jelentésben. Létrehozhat egy számított oszlopot, amely a függvény használatával kiszámítja a DAX DATE() napok számát, és ezt a számított oszlopot használja a szűrőben.

Jelentésterv

Amikor DirectQuery-kapcsolatot használó jelentést hoz létre, kövesse az alábbi útmutatást:

• Fontolja meg a lekérdezéscsökkentési beállítások használatát: A Power BI jelentésbeállításokkal kevesebb lekérdezést küldhet, és letilthat bizonyos olyan interakciókat, amelyek rossz élményt okoznak, ha az eredményül kapott lekérdezések futtatása hosszú ideig tart. Ezek a beállítások akkor érvényesek, ha a Power BI Desktopban használja a jelentést, és akkor is, amikor a felhasználók a Power BI szolgáltatás használják a jelentést.

  Ezeknek a beállításoknak a Power BI Desktopban való eléréséhez nyissa meg a Fájlbeállítások>és beállítások>lehetőséget, és válassza a Lekérdezések csökkentése lehetőséget.

  

  A Lekérdezések csökkentése képernyőn megjelenő kijelölésekkel megjelenítheti a szeletelők vagy szűrőkijelölések Alkalmazás gombját. A rendszer nem küld lekérdezéseket, amíg a szűrőn vagy szeletelőn az Alkalmaz gombot nem választja. A lekérdezések ezután a kijelölésekkel szűrik az adatokat. Ez a gomb lehetővé teszi, hogy több szeletelőt és szűrőt válasszon az alkalmazásuk előtt.

• Először alkalmazza a szűrőket: A vizualizáció létrehozásakor mindig alkalmazza a megfelelő szűrőket. Például ahelyett, hogy a TotalSalesAmount és a ProductName értékre húz, majd egy adott évre szűrne, alkalmazza a szűrőt az Év gombra az elején.

  A vizualizációk létrehozásának minden lépése lekérdezést küld. Bár az első lekérdezés befejezése előtt lehetséges egy újabb módosítás, ez a megközelítés továbbra is felesleges terhelést hagy a mögöttes forráson. A szűrők korai alkalmazása általában kevésbé költségessé teszi ezeket a köztes lekérdezéseket. A szűrők korai alkalmazásának elmulasztása az egymillió sorkorlátot is elérheti.

• Az oldalon lévő vizualizációk számának korlátozása: Amikor megnyit egy lapot, vagy módosít egy oldalszintű szeletelőt vagy szűrőt, az oldal összes vizualizációja frissül. A párhuzamos lekérdezések száma korlátozott. A vizualizációk számának növekedésével egyes vizualizációk sorozatosan frissülnek, ami növeli az oldal frissítéséhez szükséges időt. Ezért a legjobb, ha egyetlen oldalon korlátozza a vizualizációk számát, és ehelyett több egyszerűbb oldallal rendelkezik.

• Érdemes kikapcsolni a vizualizációk közötti interakciót: Alapértelmezés szerint a jelentésoldal vizualizációi használhatók keresztszűrésre és keresztkiemelésre a lapon lévő többi vizualizációra. Ha például az 1999-et választja a kördiagramon, az oszlopdiagram keresztkiemeléssel jelenik meg az 1999-hez tartozó értékesítések kategóriánkénti megjelenítéséhez.

  

  A DirectQuery keresztszűréséhez és keresztkiemeléséhez lekérdezéseket kell küldeni az alapul szolgáló forrásnak. Kapcsolja ki ezt az interakciót, ha a felhasználók kijelöléseire való válaszadáshoz szükséges idő indokolatlanul hosszú.

  A lekérdezéscsökkentési beállítások használatával letilthatja a keresztkiemelést a jelentésben, vagy eseti alapon. További információ: Hogyan szűrik egymást a vizualizációk egy Power BI-jelentésben.

Kapcsolatok maximális száma

Beállíthatja, hogy a DirectQuery legfeljebb hány kapcsolatot nyitjon meg az egyes mögöttes adatforrásokhoz, amelyek az egyes adatforrásoknak egyidejűleg küldött lekérdezések számát vezérli.

A DirectQuery alapértelmezés szerint legfeljebb 10 egyidejű kapcsolatot nyit meg. Ha módosítani szeretné az aktuális fájl maximális számát a Power BI Desktopban, lépjen a Fájlbeállítások>és Gépház> Options elemre, és válassza a DirectQuery lehetőséget a bal oldali panel Aktuális fájl szakaszában.

A beállítás csak akkor engedélyezett, ha az aktuális jelentésben legalább egy DirectQuery-forrás szerepel. Az érték az összes DirectQuery-forrásra és a jelentéshez hozzáadott új DirectQuery-forrásokra vonatkozik.

Az adatforrásonkénti kapcsolatok maximális számának növelése lehetővé teszi, hogy több lekérdezést küldjön a megadott maximális számig az alapul szolgáló adatforrásnak. Ez a módszer akkor hasznos, ha sok vizualizáció egy oldalon található, vagy sok felhasználó egyszerre fér hozzá egy jelentéshez. A kapcsolatok maximális számának elérése után a rendszer további lekérdezéseket is várólistára állít, amíg el nem érhető a kapcsolat. A magasabb korlát nagyobb terhelést eredményez a mögöttes forráson, így a beállítás nem garantált a teljes teljesítmény javítása érdekében.

Ha közzétesz egy jelentést a Power BI szolgáltatás, az egyidejű lekérdezések maximális száma a jelentés közzétételi célkörnyezetében beállított rögzített korlátoktól is függ. A Power BI, a Power BI Premium és a Power BI jelentéskészítő kiszolgáló különböző korlátokat szabnak meg. Az alábbi táblázat az egyes Power BI-környezetek adatforrásonkénti aktív kapcsolatainak felső korlátait sorolja fel. Ezek a korlátok a felhőalapú adatforrásokra és a helyszíni adatforrásokra, például az SQL Serverre, az Oracle-ra és a Teradata-ra vonatkoznak.

Környezet	Adatforrásonkénti felső korlát
Power BI Pro	10 aktív kapcsolat
Power BI Premium	A szemantikai modell termékváltozatának korlátozásától függ
Power BI jelentéskészítő kiszolgáló	10 aktív kapcsolat

Feljegyzés

A DirectQuery-kapcsolatok maximális száma az összes DirectQuery-forrásra érvényes a bővített metaadatok engedélyezésekor, amely a Power BI Desktopban létrehozott összes modell alapértelmezett beállítása.

DirectQuery a Power BI szolgáltatás

A Power BI Desktop minden DirectQuery-adatforrást támogat, és egyes források közvetlenül a Power BI szolgáltatás belülről is elérhetők. Az üzleti felhasználók a Power BI használatával csatlakozhatnak adataikhoz például a Salesforce-ban, és azonnal megkaphatják az irányítópultot a Power BI Desktop használata nélkül.

Csak a következő két DirectQuery-kompatibilis forrás érhető el közvetlenül a Power BI szolgáltatás:

• Spark
• Azure Synapse Analytics (korábban SQL Data Warehouse)

Még ebben a két forrásban is érdemes elkezdeni a DirectQuery használatát a Power BI Desktopban. Bár kezdetben könnyű kapcsolatot létesíteni a Power BI szolgáltatás, vannak korlátozások az eredményül kapott jelentés továbbfejlesztésére. A szolgáltatásban például nem lehet semmilyen számítást létrehozni, vagy számos elemzési funkciót használni, vagy frissíteni a metaadatokat a mögöttes séma változásainak megfelelően.

A DirectQuery-jelentések teljesítménye a Power BI szolgáltatás a mögöttes adatforrásra helyezett terhelés mértékétől függ. A terhelés a következőtől függ:

• A jelentést és az irányítópultot megosztó felhasználók száma.
• A jelentés összetettsége.
• Azt határozza meg, hogy a jelentés sorszintű biztonságot határoz-e meg.

Jelentés viselkedése a Power BI szolgáltatás

Amikor megnyit egy jelentést a Power BI szolgáltatás, az aktuálisan látható oldalfrissítés összes vizualizációja frissül. Minden vizualizációhoz legalább egy lekérdezésre van szükség a mögöttes adatforráshoz. Egyes vizualizációkhoz több lekérdezésre is szükség lehet. Egy vizualizáció például két különböző ténytáblából származó összesített értékeket jeleníthet meg, vagy összetettebb mértéket tartalmazhat, vagy egy nem additív mérték, például a Count Distinct összegeit is tartalmazhatja. Az új lapra való áttérés frissíti ezeket a vizualizációkat. A frissítés új lekérdezéskészletet küld a mögöttes forrásnak.

A jelentés minden felhasználói beavatkozása vizualizációk frissítését eredményezheti. Ha például kiválaszt egy másik értéket egy szeletelőn, új lekérdezéskészletet kell küldenie az összes érintett vizualizáció frissítéséhez. Ugyanez igaz a vizualizációk kiválasztására más vizualizációk keresztkiemeléséhez vagy szűrő módosításához. Hasonlóképpen, a jelentés létrehozásához vagy szerkesztéséhez lekérdezéseket kell küldeni az elérési út minden egyes lépéséhez a végső vizualizáció létrehozásához.

Van némi gyorsítótárazás az eredményekhez. A vizualizáció frissítése azonnal megtörténik, ha a közelmúltban pontosan ugyanazokat az eredményeket szerezték be. Ha sorszintű biztonság van meghatározva, ezek a gyorsítótárak nem lesznek megosztva a felhasználók között.

A DirectQuery használata néhány fontos korlátozást vezet be a közzétett jelentések Power BI szolgáltatás funkcióinak némelyikében:

• A gyors elemzések nem támogatottak: a Power BI gyorselemzései a szemantikai modell különböző részhalmazait keresik, miközben kifinomult algoritmusok készletét alkalmazzák a potenciálisan érdekes megállapítások felderítésére. Mivel a gyors elemzések nagy teljesítményű lekérdezéseket igényelnek, ez a funkció nem érhető el a DirectQueryt használó szemantikai modelleken.

• A Felfedezés az Excelben rossz teljesítményt eredményez: A szemantikai modelleket a Felfedezés az Excelben funkcióval vizsgálhatja meg, amellyel kimutatástáblákat és kimutatásdiagramokat hozhat létre az Excelben. Ez a funkció a DirectQueryt használó szemantikai modellek esetében támogatott, de a teljesítmény lassabb, mint vizualizációk létrehozása a Power BI-ban. Ha az Excel használata fontos a forgatókönyvek esetében, ezt a problémát figyelembe véve döntse el, hogy használja-e a DirectQueryt.

• Az Excel nem jeleníti meg a hierarchiát: Ha például az Elemzést az Excelben használja, az Excel nem jeleníti meg az Azure Analysis Services-modellekben vagy a DirectQueryt használó Power BI szemantikai modellekben definiált hierarchiát.

Irányítópult frissítése

A Power BI szolgáltatás az egyes vizualizációkat vagy teljes lapokat csempékként rögzítheti az irányítópultokon. A DirectQuery szemantikai modelleken alapuló csempék automatikusan frissülnek, ha ütemezetten küld lekérdezéseket a mögöttes adatforrásokhoz. Alapértelmezés szerint a szemantikai modellek óránként frissülnek, de a szemantikai modell beállításainak részeként heti és 15 percenként is konfigurálhatja a frissítést.

Ha a modellben nincs sorszintű biztonság definiálva, a rendszer minden csempét egyszer frissít, és az eredményeket az összes felhasználó megosztja. Ha sorszintű biztonságot használ, minden csempéhez felhasználónként külön lekérdezéseket kell küldeni az alapul szolgáló forrásnak.

Nagy multiplikátorhatás is lehet. Egy 10 csempét tartalmazó, 100 felhasználóval megosztott irányítópult, amely egy szemantikai modellen, a DirectQuery használatával, sorszintű biztonsággal jön létre, és minden frissítéshez legalább 1000 lekérdezést küld a mögöttes adatforrásnak. Ügyeljen a sorszintű biztonság használatára és a frissítési ütemezés konfigurálására.

Lekérdezési időtúllépések

A Power BI szolgáltatás egyes lekérdezéseire négy perces időtúllépés vonatkozik. A négy percnél hosszabb időt igénybevevő lekérdezések sikertelenek. Ez a korlát a túl hosszú végrehajtási idők által okozott problémák megelőzésére szolgál. A DirectQueryt csak olyan forrásokhoz érdemes használni, amelyek interaktív lekérdezési teljesítményt nyújtanak.

Teljesítménydiagnosztika

Ez a szakasz ismerteti, hogyan diagnosztizálhatja a teljesítményproblémákat, vagy hogyan kaphat részletesebb információkat a jelentések optimalizálásához.

Kezdje el diagnosztizálni a teljesítményproblémákat a Power BI Desktopban a Power BI szolgáltatás helyett. A teljesítményproblémák gyakran az alapul szolgáló forrás teljesítményén alapulnak. Egyszerűbben azonosíthatja és diagnosztizálhatja a problémákat az elszigeteltebb Power BI Desktop-környezetben.

Ez a megközelítés kezdetben kiküszöböl bizonyos összetevőket, például a Power BI-átjárót. Ha a teljesítményproblémák nem fordulnak elő a Power BI Desktopban, megvizsgálhatja a jelentés sajátosságait a Power BI szolgáltatás.

A Power BI Desktop teljesítményelemzője hasznos eszköz a problémák azonosításához. Próbálja meg elkülöníteni a problémákat egy vizualizációhoz, nem pedig egy oldalon lévő számos vizualizációhoz. Ha egy Power BI Desktop-oldalon egy vizualizáció lassú, a Teljesítményelemzővel elemezheti a Power BI Desktop által az alapul szolgáló forrásnak küldött lekérdezéseket.

Megtekintheti az egyes mögöttes adatforrások által kibocsátott nyomkövetési és diagnosztikai információkat is. A nyomkövetési fájl akkor is hasznos részleteket tartalmazhat, ha a forrásból nem származnak nyomkövetések, a lekérdezések futtatásának és javításának módjával kapcsolatban. Az alábbi eljárással megtekintheti a Power BI által küldött lekérdezéseket és azok végrehajtási idejét.

Lekérdezések megtekintése az SQL Server Profilerrel

A Power BI Desktop alapértelmezés szerint naplózza az eseményeket egy adott munkamenet során egy FlightRecorderCurrent.trc nevű nyomkövetési fájlba. A nyomkövetési fájl az aktuális felhasználó Power BI Desktop mappájában található egy AnalysisServicesWorkspaces nevű mappában.

Egyes DirectQuery-források esetében ez a nyomkövetési fájl tartalmazza az alapul szolgáló adatforrásnak küldött összes lekérdezést. A következő adatforrások küldenek lekérdezéseket a naplóba:

• SQL Server
• Azure SQL Database
• Azure Synapse Analytics (korábban SQL Data Warehouse)
• Oracle
• Teradata
• SAP HANA

A nyomkövetési fájlokat az ingyenesen letölthető SQL Server Management Studio részét képező SQL Server Profilerrel olvashatja el.

Az aktuális munkamenet nyomkövetési fájljának megnyitása:

1. Egy Power BI Desktop-munkamenet során válassza a Fájlbeállítások>és beállítások>lehetőséget, majd válassza a Diagnosztika lehetőséget.

2. Az Összeomlási memóriakép gyűjteménye csoportban válassza az Összeomlási memóriakép/nyomkövetés mappa megnyitása lehetőséget.

   

   Megnyílik a Power BI Desktop\Traces mappa.

3. Lépjen a szülőmappára, majd az AnalysisServicesWorkspaces mappára, amely a Power BI Desktop minden megnyitott példányához tartalmaz egy munkaterületi mappát. Ezek a mappák egy egész szám utótaggal vannak elnevezve, például AnalysisServicesWorkspace2058279583. A munkaterület mappája törlődik, amikor a társított Power BI Desktop-munkamenet véget ér.

   Az aktuális Power BI-munkamenet munkaterületi mappájában az \Data mappa tartalmazza a FlightRecorderCurrent.trc nyomkövetési fájlt. Jegyezze fel a helyet.

4. Nyissa meg az SQL Server Profilert, és válassza a Fájl>megnyitása>nyomkövetési fájl lehetőséget.

5. Keresse meg vagy írja be az aktuális Power BI-munkamenet nyomkövetési fájljának elérési útját, és nyissa meg a FlightRecorderCurrent.trc fájlt.

Az SQL Server Profiler megjeleníti az aktuális munkamenet összes eseményét. Az alábbi képernyőkép egy lekérdezés eseménycsoportját emeli ki. Minden lekérdezéscsoport a következő eseményekkel rendelkezik:

• Egy Query Begin és Query End egy esemény, amely egy vizualizáció vagy szűrő Power BI felhasználói felületén történő módosításával, illetve a Power Query-szerkesztő lévő adatok szűrésével vagy átalakításával létrehozott DAX-lekérdezés kezdetét és végét jelöli.

• Egy vagy több pár DirectQuery Begin és DirectQuery End esemény, amelyek a DAX-lekérdezés kiértékelésének részeként az alapul szolgáló adatforrásnak küldött lekérdezéseket jelölik.

Több DAX-lekérdezés is futtatható párhuzamosan, így a különböző csoportok eseményei egymásba fonhatók. Az érték használatával ActivityID meghatározhatja, hogy mely események tartoznak ugyanahhoz a csoporthoz.

A következő oszlopok is érdekesek:

• TextData: Az esemény szöveges részletei. Query End Az Query Begin események esetében a részletesség a DAX-lekérdezés. DirectQuery End A DirectQuery Begin részletek az alapul szolgáló forrásnak küldött SQL-lekérdezések. Az aktuálisan kijelölt esemény TextData-fájlja a képernyő alján lévő panelen is megjelenik.
• EndTime: Az esemény befejezésének időpontja.
• Időtartam: A DAX- vagy SQL-lekérdezés futtatásához ezredmásodpercben megadott időtartam.
• Hiba: Hiba történt-e, ebben az esetben az esemény pirosan is megjelenik.

Nyomkövetés rögzítése a lehetséges teljesítményproblémák diagnosztizálásához:

1. Nyisson meg egy Power BI Desktop-munkamenetet, hogy elkerülje a több munkaterületi mappa összekeverését.

2. Végezze el az érdeklődésre számot tartó műveleteket a Power BI Desktopban. Adjon meg még néhány műveletet, hogy a fontos eseményeket a nyomkövetési fájlba ürítse.

3. Nyissa meg az SQL Server Profilert, és vizsgálja meg a nyomkövetést. Ne feledje, hogy a Power BI Desktop bezárása törli a nyomkövetési fájlt. Emellett a Power BI Desktop további műveletei nem jelennek meg azonnal. Az új események megtekintéséhez be kell zárnia és újra meg kell nyitnia a nyomkövetési fájlt.

Tartsa az egyes munkamenetek viszonylag kicsi, talán 10 másodpercnyi művelet, nem több száz. Ez a módszer megkönnyíti a nyomkövetési fájl értelmezését. A nyomkövetési fájl méretének is van korlátja. Hosszú munkamenetek esetén előfordulhat, hogy a korai események elesnek.

A lekérdezések formátumának megismerése

A Power BI Desktop-lekérdezések általános formátuma minden hivatkozott táblához alkijelöléseket használ. A Power Query-szerkesztő lekérdezés határozza meg az alválasztási lekérdezéseket. Tegyük fel például, hogy az SQL Serveren a következő TPC-DS-táblák találhatók:

Futtassa a következő lekérdezést:

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

A következő vizualizációt kapja a Power BI-ban:

A vizualizáció frissítése az SQL-lekérdezést az alábbi képen hozza létre. Három alválasztási lekérdezés Web_Salesvan a megfelelő ItemDate_dimtábla összes oszlopának visszaadása esetén, annak ellenére, hogy a vizualizáció csak négy oszlopra hivatkozik.

Power Query-szerkesztő határozza meg a pontos alválasztási lekérdezéseket. Az alválasztási lekérdezések használata nem befolyásolja a DirectQuery által támogatott adatforrások teljesítményét. Az olyan adatforrások, mint az SQL Server, optimalizálják a többi oszlopra mutató hivatkozásokat.

A Power BI azért használja ezt a mintát, mert az elemző közvetlenül biztosítja az SQL-lekérdezést. A Power BI a megadott módon használja a lekérdezést anélkül, hogy megpróbálták volna újraírni.

Kapcsolódó tartalom

További információ a DirectQueryről a Power BI-ban:

• A DataQuery használata a Power BI Desktopban

Ez a cikk a DirectQuery minden adatforrásban gyakori aspektusait ismertette. Az egyes forrásokról az alábbi cikkekben olvashat részletesen:

• DirectQuery és SAP HANA
• DirectQuery és SAP BW
• A DirectQuery használata Power BI szemantikai modellekhez és Analysis Serviceshez