Növekményes frissítés és valós idejű adatok hibaelhárítása

A növekményes frissítés és a valós idejű adatmegoldás implementálásának két fázisa van: az első a paraméterek konfigurálása, a szűrés és a szabályzat definiálása a Power BI Desktopban, a második pedig a kezdeti szemantikai modellfrissítési művelet, majd a szolgáltatás későbbi frissítései. Ez a cikk az egyes fázisok hibaelhárítását ismerteti külön-külön.

Miután particionálta a táblát a Power BI szolgáltatás, fontos szem előtt tartani, hogy a DirectQueryvel valós idejű adatokat is kapó, növekményesen frissített táblák hibrid módban működnek, ami azt jelenti, hogy importálási és DirectQuery módban is működnek. Az ilyen növekményesen frissített hibrid táblákhoz kapcsolódó tábláknak kettős módot kell használniuk, hogy azok importálási és DirectQuery módban is használhatók legyenek teljesítménybeli büntetések nélkül. A jelentésvizualizációk emellett gyorsítótárazhatják az eredményeket, így elkerülhető, hogy a lekérdezések visszakerüljenek az adatforrásba, ami megakadályozza, hogy a tábla valós időben észlelje a legújabb adatfrissítéseket. A végső hibaelhárítási szakasz ezeket a hibrid módú problémákat ismerteti.

A növekményes frissítés és a valós idejű adatok hibaelhárítása előtt mindenképpen tekintse át a modellek és valós idejű adatok növekményes frissítését, valamint a növekményes frissítés és a valós idejű adatok konfigurálásának részletes adatait.

Konfigurálás a Power BI Desktopban

A növekményes frissítés és a valós idejű adatok konfigurálásakor előforduló legtöbb probléma a lekérdezések összecsukásával kapcsolatos. A modellek növekményes frissítésének áttekintése – A támogatott adatforrások esetében az adatforrásnak támogatnia kell a lekérdezések összecsukását.

Probléma: Az adatok betöltése túl sokáig tart

Az Power Query-szerkesztő az Alkalmaz lehetőség kiválasztása után az adatok betöltése túl sok időt és számítógép-erőforrást igényel. Több lehetséges oka is lehet.

Ok: Az adattípus eltérése

Ezt a problémát okozhatja egy adattípus eltérése, ahol Date/Time a szükséges adattípus a paraméterekhez és RangeEnd a RangeStart paraméterekhez, de a tábla dátumoszlopa, amelyre a szűrőket alkalmazza, nem Date/Time adattípus, vagy fordítva. A paraméterek adattípusának és a szűrt adatoszlopnak is adattípusnak kell lennie Date/Time , és a formátumnak meg kell egyeznie. Ha nem, a lekérdezés nem hajtható le.

Megoldás: Adattípus ellenőrzése

Ellenőrizze, hogy a növekményes frissítési tábla dátum/idő oszlopa Date/Time adattípus-e. Ha a tábla nem tartalmaz adattípusú oszlopotDate/Time, hanem egész szám típusú adattípust használ, létrehozhat egy függvényt, amely a dátum/idő értéket és RangeEnd a paramétereket RangeStart az adatforrástábla egész szám helyettesítő kulcsának megfelelően konvertálja. További információ: Növekményes frissítés konfigurálása – DateTime konvertálása egész számmá.

Ok: Az adatforrás nem támogatja a lekérdezések összecsukását

A növekményes frissítés és a modellek valós idejű adatai – A követelményeknek megfelelően a növekményes frissítés olyan adatforrásokhoz készült, amelyek támogatják a lekérdezések összecsukását. A szolgáltatásban való közzététel előtt győződjön meg arról, hogy az adatforrás-lekérdezések össze vannak hajtva a Power BI Desktopban, ahol a lekérdezések összecsukási problémái jelentősen összetettebbé tehetők. Ez a megközelítés különösen fontos a valós idejű adatok növekményes frissítési szabályzatba való felvételekor, mivel a valós idejű DirectQuery-partíció lekérdezésátadást igényel.

Megoldás: Lekérdezések ellenőrzése és tesztelése

A legtöbb esetben figyelmeztetés jelenik meg a Növekményes frissítési szabályzat párbeszédpanelen, amely jelzi, hogy az adatforráson végrehajtandó lekérdezés nem támogatja-e a lekérdezés összecsukását. Bizonyos esetekben azonban szükség lehet a lekérdezések összecsukásának további biztosítására. Ha lehetséges, monitorozza az adatforrásnak átadott lekérdezést egy olyan eszközzel, mint az SQL Profiler. Egy szűrőket tartalmazó lekérdezés, amely egy lekérdezésen RangeStart alapul, és RangeEnd egyetlen lekérdezésben kell végrehajtani.

A rövid dátum/idő időtartamot is megadhatja azokban a RangeStartRangeEnd paraméterekben, amelyek legfeljebb néhány ezer sort tartalmaznak. Ha az adatforrásból a modellbe szűrt adatok betöltése hosszú időt vesz igénybe, és folyamatigényes, az valószínűleg azt jelenti, hogy a lekérdezés nem lesz hajtva.

Ha úgy ítéli meg, hogy a lekérdezés nincs összehajtva, tekintse meg a Power BI Desktop és a Power Query összecsukható lekérdezésének összecsukási útmutatóját, amely segítséget nyújt annak azonosításához, hogy mi akadályozhatja a lekérdezések összecsukását, és hogyan, vagy ha az adatforrás még a lekérdezések összecsukását is támogatja.

Szemantikai modell frissítése a szolgáltatásban

A növekményes frissítési problémák elhárítása a szolgáltatásban attól függően különbözik, hogy a modell milyen kapacitásban lett közzétéve. A Prémium szintű kapacitások szemantikai modelljei támogatják az olyan eszközök használatát, mint az SQL Server Management Studio (SSMS) az egyes partíciók megtekintéséhez és szelektív frissítéséhez. A Power BI Pro-modellek viszont nem biztosítanak eszközhozzáférést az XMLA-végponton keresztül, így a növekményes frissítési problémák hibaelhárítása egy kicsit több próbaverziót és hibát igényelhet.

Probléma: A kezdeti frissítés túllépi az időkorlátot

A Megosztott kapacitású Power BI Pro-modellek ütemezett frissítése kétórás időtartammal rendelkezik. Ez az időkorlát a prémium szintű kapacitásban lévő modellek esetében öt órára nő. Az adatforrásrendszerek a lekérdezés visszatérési méretkorlátját vagy a lekérdezés időtúllépését is előírhatják.

Ok: Az adatforrás-lekérdezések nincsenek összehajtva

Bár a lekérdezések összecsukásával kapcsolatos problémák általában a Power BI Desktopban határozhatók meg a szolgáltatásban való közzététel előtt, előfordulhat, hogy a modellfrissítési lekérdezések nem lesznek összehajtva, ami túlzott frissítési időt és a lekérdezések összefésülési motorjának erőforrás-kihasználtságát okozhatja. Ez a helyzet azért fordul elő, mert a rendszer létrehoz egy lekérdezést a modell minden partíciója számára. Ha a lekérdezések nem lesznek hajtva, és az adatok nem lesznek szűrve az adatforrásban, a motor megpróbálja szűrni az adatokat.

Megoldás: A lekérdezések összecsukásának ellenőrzése

Az adatforrás nyomkövetési eszközével megállapíthatja, hogy az egyes partíciókhoz átadott lekérdezés egyetlen lekérdezés, amely a RangeStart és a RangeEnd paraméterek alapján tartalmaz szűrőt. Ha nem, ellenőrizze, hogy a lekérdezések összecsukása a Power BI Desktop-modellben történik-e, amikor kis mennyiségű szűrt adatot tölt be a modellbe. Ha nem, először a modellben végezze el a javítást, végezzen metaadat-frissítést a modellre (XMLA-végpont használatával), vagy ha egy Power BI Pro-modell egy megosztott kapacitáson, törölje a hiányos modellt a szolgáltatásban, tegye közzé újra, és próbálkozzon újra egy kezdeti frissítési művelettel.

Ha azt állapítja meg, hogy a lekérdezések nem lesznek összehajtva, tekintse meg a Power BI Desktop és a Power Query összecsukási útmutatóját, amely segít azonosítani, hogy mi akadályozhatja a lekérdezések összecsukását.

Ok: A partíciókba betöltött adatok túl nagyok

Megoldás: A modell méretének csökkentése

Az időtúllépést sok esetben az okozza, hogy a lekérdezendő és a modellpartíciókba betöltött adatok mennyisége meghaladja a kapacitás által előírt időkorlátot. Csökkentse a modell méretét vagy összetettségét, vagy fontolja meg a modell kisebb darabokra bontását.

Megoldás: Nagyméretű modell tárolási formátumának engedélyezése

A Prémium szintű kapacitásokban közzétett modellek esetében, ha a modell 1 GB vagy annál nagyobb méretűre nő, javíthatja a frissítési művelet teljesítményét, és meggyőződhet arról, hogy a modell nem korlátozza a méretkorlátokat, ha engedélyezi a nagy méretű modell tárolási formátumát , mielőtt végrehajtja az első frissítési műveletet a szolgáltatásban. További információ: Nagy modellek a Power BI Premiumban.

Megoldás: Bootstrap kezdeti frissítése

A Prémium kapacitásokban közzétett modellek esetében elindíthatja a kezdeti frissítési műveletet. A rendszerindítás lehetővé teszi, hogy a szolgáltatás tábla- és partícióobjektumokat hozzon létre a modellhez, de az előzményadatokat nem töltheti be és dolgozhatja fel egyik partícióba sem. További információ: Speciális növekményes frissítés – Időtúllépések megakadályozása a kezdeti teljes frissítésnél.

Ok: Az adatforrás lekérdezésének időtúllépése

A lekérdezéseket az adatforrás alapértelmezett időkorlátja korlátozhatja.

Megoldás: A lekérdezési kifejezés időkorlátjának felülbírálása

Számos adatforrás lehetővé teszi a lekérdezési kifejezés felülírási időkorlátját. További információ: Modellek növekményes frissítése – Időkorlátok.

Probléma: A frissítés duplikált értékek miatt meghiúsul

Ok: Módosultak a post dátumok

Frissítési művelet esetén a modell csak az adatforrásban megváltozott adatokat frissíti. Mivel az adatok dátummal vannak osztva, javasoljuk, hogy a post (tranzakciós) dátumok ne változnak.

Ha véletlenül módosítanak egy dátumot, akkor két probléma léphet fel: A felhasználók az előzményadatokban bizonyos összegeket módosítanak (ez nem szabad, hogy megtörténjen), vagy a frissítés során hibaüzenet jelenik meg, amely azt jelzi, hogy az egyedi érték valójában nem egyedi. Az utóbbi esetében ez a helyzet akkor fordulhat elő, ha a növekményes frissítéssel konfigurált táblát egy másik táblával 1 való kapcsolatban használják 1:N oldalként, és egyedi értékekkel kell rendelkezniük. Ha egy adott azonosító adatai módosulnak, az azonosító megjelenik egy másik partíción, és a motor észleli, hogy az érték nem egyedi.

Megoldás: Adott partíciók frissítése

Ha egy vállalatnak módosítania kell néhány múltbeli adatot a dátumokról, lehetséges megoldás, ha az SSMS használatával frissíti az összes partíciót attól a ponttól kezdve, ahol a módosítás az aktuális frissítési partícióig található, így a 1 kapcsolat oldala egyedi marad.

Probléma: Az adatok csonkolt állapotban vannak

Ok: Túllépte az adatforrás lekérdezési korlátját

Egyes adatforrások, például az Azure Data Explorer, a Log Analytics és az Alkalmazás Elemzések, 64 MB(tömörített) korlátot tartalmazhatnak a külső lekérdezésekhez visszaadható adatokon. Előfordulhat, hogy az Azure Data Explorer explicit hibát ad vissza, de mások, például a Log Analytics és az Alkalmazás Elemzések esetében a visszaadott adatok csonkulnak.

Megoldás: Kisebb frissítési és tárolási időszakok megadása

Adjon meg kisebb frissítési és tárolási időszakokat a szabályzatban. Ha például egyéves frissítési időszakot adott meg, és lekérdezési hibát ad vissza, vagy a visszaadott adatokat csonkolja, próbálkozzon 12 hónapos frissítési időszakkal. Biztosítani szeretné, hogy az aktuális frissítési partícióra vagy a frissítési és tárolási időszakokon alapuló előzménypartíciók lekérdezései ne adjanak vissza 64 MB-nál több adatot.

Probléma: A frissítés partíciókulcs-ütközések miatt meghiúsul

Ok: Az adatforrás dátumoszlopában szereplő dátum frissül

A dátumoszlop szűrője dinamikusan particionálja az adatokat a Power BI szolgáltatás időszaktartományaiba. A növekményes frissítés nem támogatja azokat az eseteket, amikor a szűrt dátumoszlop frissül a forrásrendszerben. A frissítés beszúrásként és törlésként van értelmezve, nem tényleges frissítésként. Ha a törlés az előzménytartományban történik, és nem a növekményes tartományban, akkor a rendszer nem veszi fel, ami adatfrissítési hibákat okozhat partíciókulcs-ütközések miatt.

Hibrid mód a szolgáltatásban (előzetes verzió)

Ha a Power BI valós idejű adatokat tartalmazó növekményes frissítési szabályzatot alkalmaz, a növekményesen frissített táblát hibrid táblává alakítja, amely importálási és DirectQuery módban is működik. Figyelje meg a DirectQuery-partíciót egy mintatábla következő partíciólistájának végén. A DirectQuery-partíciók jelenléte hatással van a táblát lekérdező kapcsolódó táblákra és jelentésvizualizációkra.

Probléma: A lekérdezési teljesítmény gyenge

Ok: A kapcsolódó táblák nem kettős módban találhatók

Az importálási és DirectQuery módban működő hibrid táblákhoz minden kapcsolódó táblának kettős módban kell működnie, hogy gyorsítótárazottként vagy gyorsítótárazottként működhessenek a Power BI-modellnek küldött lekérdezés kontextusától függően. A kettős mód lehetővé teszi, hogy a Power BI csökkentse a modell korlátozott kapcsolatainak számát, és hatékony adatforrás-lekérdezéseket hozzon létre a jó teljesítmény érdekében. Korlátozott kapcsolatok nem küldhetők le az adatforrásba, amely megköveteli, hogy a Power BI a szükségesnél több adatot kérjen le. Mivel a kettős táblák DirectQuery vagy Importálás táblaként is működhetnek, ez a helyzet elkerülhető.

Megoldás: Kapcsolódó táblák konvertálása kettős módúra

Növekményes frissítési szabályzat konfigurálásakor a Power BI Desktop arra emlékezteti, hogy a kapcsolódó táblákat váltsa kettős módra, amikor a Legfrissebb adatok valós idejű lekérése a DirectQueryvel (csak Prémium verzió) lehetőséget választja. Emellett ellenőrizze az összes meglévő táblakapcsolatot Modell nézetben.

A jelenleg DirectQuery módban működő táblák egyszerűen válthatók kettős módra. A tábla tulajdonságai alatt, a Speciális területen válassza a Kettős lehetőséget a Tárolási mód listamezőből. A jelenleg importálási módban működő táblákhoz azonban manuális munka szükséges. A kettős táblák működési korlátai ugyanazok, mint a DirectQuery-táblák. A Power BI Desktop ezért nem tudja konvertálni az importálási táblákat, mert előfordulhat, hogy más, kettős módban nem elérhető funkciókra támaszkodnak. Ezeket a táblákat manuálisan kell létrehoznia DirectQuery módban, majd kettős módba kell konvertálnia őket. További információ: Tárolási mód kezelése a Power BI Desktopban.

Probléma: A jelentésvizualizációk nem a legújabb adatokat jelenítik meg

Ok: A Power BI gyorsítótárazza a lekérdezési eredményeket, javítja a teljesítményt és csökkenti a háttérbetöltést

A Power BI alapértelmezés szerint gyorsítótárazza a lekérdezési eredményeket, így a jelentésvizualizációk lekérdezései akkor is gyorsan feldolgozhatók, ha azok DirectQueryn alapulnak. A szükségtelen adatforrás-lekérdezések elkerülése javítja a teljesítményt és csökkenti az adatforrások terhelését, de azt is jelentheti, hogy a forráson végzett legújabb adatváltozások nem szerepelnek az eredményekben.

Megoldás: Automatikus oldalfrissítés konfigurálása

A forrásból származó legújabb adatváltozások lekéréséhez konfigurálja az automatikus oldalfrissítést a jelentésekhez a Power BI szolgáltatás. Az automatikus oldalfrissítés meghatározott időközönként, például öt másodperc vagy tíz perc alatt végezhető el. Az adott intervallum elérésekor az adott lap összes vizualizációja frissítési lekérdezést küld az adatforrásnak, és ennek megfelelően frissít. Másik lehetőségként frissítheti a vizualizációkat egy lapon az adatok változásainak észlelése alapján. Ehhez a megközelítéshez olyan változásészlelési mértékre van szükség, amelyet a Power BI a módosítások adatforrásának lekérdezésére használ. A változásészlelés csak a prémium szintű kapacitás részét képező munkaterületeken támogatott. További információ: Automatikus oldalfrissítés a Power BI-ban.

Kapcsolódó tartalom

• Adatfrissítés a Power BI-ban
• Speciális növekményes frissítés az XMLA-végponttal
• Adatfolyamok növekményes frissítése