Növekményes frissítés és valós idejű adatok szemantikai modellekhez
A Szemantikai modellek növekményes frissítése és valós idejű adatai a Power BI-ban hatékony módszereket biztosítanak a dinamikus adatok kezelésére és a modellfrissítési teljesítmény javítására. A partíciók létrehozásának és kezelésének automatizálásával a növekményes frissítés csökkenti a frissíteni kívánt adatok mennyiségét, és lehetővé teszi a valós idejű adatok felvételét. Ez a cikk bemutatja, hogyan konfigurálhatja és használhatja a növekményes frissítési funkciókat a Power BI-ban a gyorsan mozgó adatok rögzítéséhez és a teljesítmény javításához.
A növekményes frissítés kibővíti az ütemezett frissítési műveleteket azáltal, hogy automatikus partíciólétrehozást és felügyeletet biztosít az új és frissített adatokat gyakran betöltő szemantikai modelltáblákhoz. A legtöbb modell esetében egy vagy több tábla olyan tranzakcióadatokat tartalmaz, amelyek gyakran változnak, és exponenciálisan növekedhetnek, például egy ténytáblát egy relációs vagy csillagadatbázis-sémában. A tábla particionálására szolgáló növekményes frissítési szabályzat, amely csak a legújabb importálási partíciókat frissíti, és ha egy másik DirectQuery-partíciót használ valós idejű adatokhoz, jelentősen csökkentheti a frissíteni kívánt adatok mennyiségét. Ezzel egyidejűleg ez a szabályzat biztosítja, hogy az adatforrás legújabb módosításai bekerülnek a lekérdezés eredményeibe.
Növekményes frissítéssel és valós idejű adatokkal:
- Kevesebb frissítési ciklusra van szükség a gyorsan változó adatokhoz. A DirectQuery mód a lekérdezések feldolgozásakor megkapja a legújabb adatfrissítéseket, anélkül, hogy nagy frissítési ütemet igényelne.
- A frissítések gyorsabbak. Csak a legutóbb módosított adatokat kell frissíteni.
- A frissítések megbízhatóbbak. Nem szükséges hosszú ideig futó kapcsolatokat létesíteni az ingadozó adatforrásokkal. A forrásadatok lekérdezései gyorsabban futnak, így a hálózati problémák akadályozhatják a problémát.
- Az erőforrás-felhasználás csökken. A kevesebb frissítendő adat csökkenti a memória és más erőforrások általános használatát mind a Power BI-ban, mind az adatforrásrendszerekben.
- A nagy szemantikai modellek engedélyezve vannak. A potenciálisan több milliárd sorból álló szemantikai modellek anélkül növekedhetnek, hogy az összes frissítési művelettel teljes mértékben frissíteni kellene a teljes modellt.
- A beállítás egyszerű. A növekményes frissítési szabályzatok csak néhány feladattal vannak definiálva a Power BI Desktopban. Amikor a Power BI Desktop közzéteszi a jelentést, a szolgáltatás automatikusan alkalmazza ezeket a szabályzatokat az egyes frissítésekkel.
Amikor közzétesz egy Power BI Desktop-modellt a szolgáltatásban, az új modell minden táblája egyetlen partícióval rendelkezik. Az egyetlen partíció az adott tábla összes sorát tartalmazza. Ha a táblázat nagy, például több tízmillió sorból vagy többből, a tábla frissítése hosszú időt vehet igénybe, és túlzott mennyiségű erőforrást használhat fel.
A növekményes frissítéssel a szolgáltatás dinamikusan particionálja és elkülöníti a gyakran frissíteni kívánt adatokat a ritkábban frissíthető adatoktól. A táblázatadatok szűrése a Power Query dátum- és időparamétereivel történik, a fenntartott, kis- és nagybetűk megkülönböztetésévelRangeStart.RangeEnd Ha növekményes frissítést konfigurál a Power BI Desktopban, ezek a paraméterek a modellbe betöltött adatoknak csak egy kis részét szűrik. Amikor a Power BI Desktop közzéteszi a jelentést a Power BI szolgáltatás, a szolgáltatás az első frissítési művelettel növekményes frissítési és előzménypartíciókat hoz létre, és opcionálisan valós idejű DirectQuery-partíciót hoz létre a növekményes frissítési szabályzat beállításai alapján. A szolgáltatás ezután felülbírálja a paraméterértékeket az egyes partíciók adatainak szűréséhez és lekérdezéséhez az egyes sorok dátum/idő értékei alapján.
Minden további frissítés esetén a lekérdezési szűrők csak a paraméterek által dinamikusan definiált frissítési időszakon belüli sorokat ad vissza. A frissítési időszakon belül dátummal/idővel rendelkező sorok frissülnek. Azok a sorok, amelyek a frissítési időszakon belül már nem érik el a dátumot/időt, az előzményidőszak részévé válnak, amely nem frissül. Ha egy valós idejű DirectQuery-partíció szerepel a növekményes frissítési szabályzatban, a szűrője is frissül, így a frissítési időszak után bekövetkező módosításokat is felveszi. A frissítési és az előzményidőszakok is előre lesznek állítva. Az új növekményes frissítési partíciók létrehozásakor a frissítési időszakban már nem szereplő frissítési partíciók lesznek előzménypartíciók. Idővel az előzménypartíciók kevésbé lesznek részletesek, mivel egyesítve vannak. Ha egy előzménypartíció már nem szerepel a szabályzat által meghatározott előzményidőszakban, a rendszer teljesen eltávolítja azt a modellből. Ezt a viselkedést gördülő ablakmintának nevezzük.
A növekményes frissítés szépsége, hogy a szolgáltatás az Ön által meghatározott növekményes frissítési szabályzatok alapján kezeli az összeset. Valójában az abból létrehozott folyamat és partíciók nem láthatók a szolgáltatásban. A legtöbb esetben csak egy jól definiált növekményes frissítési szabályzat szükséges a modellfrissítési teljesítmény jelentős javításához. A valós idejű DirectQuery-partíció azonban csak prémium szintű kapacitású modellek esetén támogatott. A Power BI Premium speciálisabb partíció- és frissítési forgatókönyveket is lehetővé tesz az XML for Analysis (XMLA) végponton keresztül.
Követelmények
A következő szakaszok a támogatott terveket és adatforrásokat ismertetik.
Támogatott csomagok
A növekményes frissítés a Power BI Premium, a felhasználónkénti Premium, a Power BI Pro és a Power BI Embedded modellek esetében támogatott.
A Legújabb adatok valós idejű lekérése a DirectQueryvel csak a Power BI Premium, a felhasználónkénti Premium és a Power BI Embedded modellek esetében támogatott.
Támogatott adatforrások
A növekményes frissítés és a valós idejű adatok a legjobban strukturált, relációs adatforrásokhoz, például az SQL Database-hez és az Azure Synapse-hoz használhatók, de más adatforrásokhoz is használhatók. Az adatforrásnak mindenesetre támogatnia kell a következőket:
Dátumszűrés – Az adatforrásnak támogatnia kell bizonyos mechanizmusokat az adatok dátum szerinti szűréséhez. Relációs forrás esetén ez általában a céltábla dátum/idő vagy egész adattípusának dátumoszlopa. A RangeStart és a RangeEnd paraméterek, amelyeknek dátum/idő típusúaknak kell lenniük, szűrik a tábla adatait a dátumoszlop alapján. Az egész szám típusú helyettesítő kulcsok yyyymmdddátumoszlopaihoz létrehozhat egy függvényt, amely a RangeStart és a RangeEnd paraméterek dátum/idő értékét a dátumoszlop egész szám helyettesítő kulcsainak megfelelően konvertálja. További információ: Növekményes frissítés és valós idejű adatok konfigurálása – DateTime konvertálása egész számmá.
Más adatforrások esetében a RangeStart és a RangeEnd paramétereket olyan módon kell átadni az adatforrásnak, amely lehetővé teszi a szűrést. Az olyan fájlalapú adatforrások esetében, amelyekben a fájlok és mappák dátum szerint vannak rendszerezve, a RangeStart és a RangeEnd paraméterekkel szűrheti a fájlokat és mappákat a betöltendő fájlok kiválasztásához. Webes adatforrások esetén a RangeStart és a RangeEnd paraméterek integrálhatók a HTTP-kérésbe. Például a következő lekérdezés használható egy AppInsights-példány nyomkövetéseinek növekményes frissítéséhez:
let
strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps/<app-guid>/query",
[Query=[#"query"="traces
| where timestamp >= datetime(" & strRangeStart &")
| where timestamp < datetime("& strRangeEnd &")
",#"x-ms-app"="AAPBI",#"prefer"="ai.response-thinning=true"],Timeout=#duration(0,0,4,0)])),
TypeMap = #table(
{ "AnalyticsTypes", "Type" },
{
{ "string", Text.Type },
{ "int", Int32.Type },
{ "long", Int64.Type },
{ "real", Double.Type },
{ "timespan", Duration.Type },
{ "datetime", DateTimeZone.Type },
{ "bool", Logical.Type },
{ "guid", Text.Type },
{ "dynamic", Text.Type }
}),
DataTable = Source[tables]{0},
Columns = Table.FromRecords(DataTable[columns]),
ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap , {"AnalyticsTypes"}),
Rows = Table.FromRows(DataTable[rows], Columns[name]),
Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => { c{0}, c{3}}))
in
Table
A növekményes frissítés konfigurálásakor a Rendszer végrehajt egy Olyan Power Query-kifejezést, amely a RangeStart és a RangeEnd paraméterek alapján tartalmaz dátum-/idő szűrőt. Ha a szűrő a kezdeti forrás lekérdezés után egy lekérdezési lépésben van megadva, fontos, hogy a lekérdezés összecsukása kombinálja a kezdeti lekérdezési lépést a RangeStart és a RangeEnd paraméterekre hivatkozó lépésekkel. A következő lekérdezési kifejezésben például az összecsukható lesz, Table.SelectRows mert azonnal követi a lépést, és az SQL Server támogatja az Sql.Database összecsukást:
let
Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
Data = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
#"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
#"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))
in
#"Filtered Rows1"
Nincs szükség a végleges lekérdezésre az összecsukás támogatásához. A következő kifejezésben például egy nem összecsukható NativeQueryt használunk, de a RangeStart és a RangeEnd paramétereket közvetlenül integráljuk az SQL-be:
let
Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
Data
Ha azonban a növekményes frissítési szabályzat magában foglalja a valós idejű adatok DirectQueryvel való lekérését, a nem összecsukható átalakítások nem használhatók. Ha ez egy valós idejű adatok nélküli, tiszta importálási módú szabályzat, a lekérdezésegyesítési motor kompenzálhatja és alkalmazhatja a szűrőt helyileg, ami megköveteli a tábla összes sorának lekérését az adatforrásból. Ez lassú növekményes frissítéshez vezethet, és a folyamat elfogyhat az erőforrásokból a Power BI szolgáltatás vagy egy helyszíni adatátjáróban – ezzel hatékonyan legyőzve a növekményes frissítés célját.
Mivel a lekérdezések összecsukásának támogatása eltérő a különböző típusú adatforrások esetében, ellenőrizni kell, hogy a szűrőlogika szerepel-e az adatforráson futtatott lekérdezésekben. A Legtöbb esetben a Power BI Desktop megkísérli elvégezni ezt az ellenőrzést a növekményes frissítési szabályzat meghatározásakor. Az OLYAN SQL-alapú adatforrások esetében, mint az SQL Database, az Azure Synapse, az Oracle és a Teradata, ez az ellenőrzés megbízható. Előfordulhat azonban, hogy más adatforrások nem tudják ellenőrizni a lekérdezések nyomon követése nélkül. Ha a Power BI Desktop nem tudja megerősíteni a lekérdezéseket, figyelmeztetés jelenik meg a Növekményes frissítési szabályzat konfigurációs párbeszédpaneljén.
Ha ezt a figyelmeztetést látja, és ellenőrizni szeretné, hogy a lekérdezések összecsukása szükséges-e, használja a Power Query Diagnostics szolgáltatást, vagy kövesse nyomon a lekérdezéseket az adatforrás által támogatott eszközzel, például az SQL Profilerrel. Ha a lekérdezés összecsukása nem történik meg, ellenőrizze, hogy a szűrőlogika szerepel-e az adatforrásnak átadott lekérdezésben. Ha nem, akkor valószínű, hogy a lekérdezés olyan átalakítást tartalmaz, amely megakadályozza az összecsukást.
A növekményes frissítési megoldás konfigurálása előtt mindenképpen olvassa el és ismerje meg a Lekérdezés összecsukási útmutatóját a Power BI Desktopban és a Power Query-lekérdezés összecsukáskor. Ezek a cikkek segítenek meghatározni, hogy az adatforrás és a lekérdezések támogatják-e a lekérdezések összecsukását.
Egyetlen adatforrás
Ha növekményes frissítést és valós idejű adatokat konfigurál a Power BI Desktop használatával, vagy speciális megoldást konfigurál a táblázatos modell szkriptelési nyelvével (TMSL) vagy táblázatos objektummodellel (TOM) az XMLA-végponton keresztül, minden partíciónak, legyen az importálás vagy DirectQuery, egyetlen forrásból kell lekérdeznie az adatokat.
Egyéb adatforrástípusok
Az egyéni lekérdezési függvények és a lekérdezési logika használatával a növekményes frissítés más típusú adatforrásokkal is használható, ha a szűrők egy lekérdezésen alapulnak RangeStart és RangeEnd továbbíthatók, például egy mappában tárolt Excel-munkafüzetfájlokkal, SharePoint-fájlokkal és RSS-hírcsatornákkal. Ne feledje, hogy ezek olyan speciális forgatókönyvek, amelyek további testreszabást és tesztelést igényelnek az itt leírtakon túl. Az egyedi forgatókönyvek növekményes frissítésével kapcsolatos további információkért tekintse meg a cikk későbbi, Közösségi szakaszát.
Határidők
A növekményes frissítéstől függetlenül a Power BI Pro-modellek frissítési időkorlátja két óra , és a DirectQueryvel nem támogatják a valós idejű adatok lekérését. Prémium szintű kapacitásban lévő modellek esetén az időkorlát öt óra. A frissítési műveletek folyamat- és memóriaigényesek. A teljes frissítési művelet a modell által igényelt memória kétszeresét is használhatja, mivel a szolgáltatás a frissítési művelet befejezéséig megőrzi a modell pillanatképét a memóriában. A frissítési műveletek folyamatigényesek is lehetnek, és jelentős mennyiségű rendelkezésre álló CPU-erőforrást használnak fel. A frissítési műveleteknek az adatforrásokhoz való illékony kapcsolatokra is támaszkodniuk kell, valamint arra, hogy az adatforrásrendszerek képesek legyenek gyorsan visszaadni a lekérdezés kimenetét. Az időkorlát védelmet nyújt a rendelkezésre álló erőforrások túlzott felhasználásának korlátozásához.
Feljegyzés
Prémium szintű kapacitások esetén az XMLA-végponton keresztül végrehajtott frissítési műveleteknek nincs időkorlátja. További információ: Speciális növekményes frissítés az XMLA-végponttal.
Mivel a növekményes frissítés optimalizálja a frissítési műveleteket a modell partíciószintjén, az erőforrás-felhasználás jelentősen csökkenthető. Ugyanakkor a növekményes frissítés esetén is, ha nem lépnek át az XMLA-végponton, a frissítési műveleteket ugyanazok a kétórás és ötórás korlátok kötik. A hatékony növekményes frissítési szabályzat nem csak a frissítési művelettel feldolgozott adatok mennyiségét csökkenti, hanem csökkenti a modellben tárolt szükségtelen előzményadatok mennyiségét is.
A lekérdezéseket az adatforrás alapértelmezett időkorlátja is korlátozhatja. A legtöbb relációs adatforrás lehetővé teszi a Power Query M kifejezésben a felülírási időkorlátokat. Az alábbi kifejezés például az SQL Server adatelérési függvényével állítja be a CommandTimeoutot két órára. A szabályzattartományok által meghatározott minden egyes időszak elküld egy lekérdezést, amely a parancs időtúllépési beállítását követi:
let
Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
#"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
#"Filtered Rows"
A prémium szintű kapacitásokban lévő, nagy méretű, valószínűleg több milliárd sorból álló modellek esetében a kezdeti frissítési művelet elindítható. A rendszerindítás lehetővé teszi, hogy a szolgáltatás tábla- és partícióobjektumokat hozzon létre a modellhez, de nem tölt be és dolgoz fel adatokat egyik partícióba sem. Az SQL Server Management Studio használatával úgy állíthatja be a partíciókat, hogy egyenként, egymás után vagy párhuzamosan dolgozzanak fel, így csökkentheti az egyetlen lekérdezésben visszaadott adatok mennyiségét, és megkerülheti az ötórás időkorlátot is. 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.
Aktuális dátum és idő
Alapértelmezés szerint az aktuális dátum és idő a frissítés időpontjában az egyezményes világidő (UTC) alapján lesz meghatározva. Igény szerinti és ütemezett frissítések esetén konfigurálhat egy másik időzónát a "Frissítés" alatt, amelyet a rendszer figyelembe vesz az aktuális dátum és idő meghatározásakor. Például a csendes-óceáni idő (USA és Kanada) 20:00-kor, konfigurált időzónával történő frissítés a csendes-óceáni idő alapján határozza meg az aktuális dátumot és időpontot, nem pedig az UTC-t, amely a következő napon tér vissza.
A Power BI szolgáltatás nem meghívott frissítési műveletek( például az XMLA TMSL frissítési parancsa vagy a bővített frissítési API) nem veszik figyelembe a konfigurált ütemezett frissítési időzónát, és alapértelmezés szerint UTC-re.
Növekményes frissítés és valós idejű adatok konfigurálása
Ez a szakasz a növekményes frissítés és a valós idejű adatok konfigurálásának fontos fogalmait ismerteti. Ha készen áll a részletesebb részletes utasításokra, tekintse meg a növekményes frissítés és a valós idejű adatok konfigurálását ismertető cikket.
A növekményes frissítés konfigurálása a Power BI Desktopban történik. A legtöbb modell esetében csak néhány feladatra van szükség. Tartsa azonban szem előtt a következő szempontokat:
- Miután közzétette a Power BI szolgáltatás, nem teheti közzé ugyanazt a modellt újra a Power BI Desktopból. Az újbóli közzététel eltávolítja a modellben már meglévő partíciókat és adatokat. Ha prémium szintű kapacitásban tesz közzé, a metaadatséma további módosításait olyan eszközökkel végezheti el, mint a nyílt forráskódú ALM-eszközkészlet, vagy a TMSL használatával. További információ: Speciális növekményes frissítés – Csak metaadatok üzembe helyezése.
- Miután közzétette a Power BI szolgáltatás, nem töltheti le a modellt .pbix formátumban a Power BI Desktopba. Mivel a szolgáltatás modelljei ekkora méretűek lehetnek, nem praktikus letölteni és megnyitni őket egy tipikus asztali számítógépen.
- Ha valós idejű adatokat kap a DirectQueryvel, nem teheti közzé a modellt egy nem Prémium szintű munkaterületen. A valós idejű adatokat tartalmazó növekményes frissítés csak a Power BI Premiumban támogatott.
Paraméterek létrehozása
Ha növekményes frissítést szeretne konfigurálni a Power BI Desktopban, először két Power Query dátum- és időparamétert hoz létre fenntartott, kis- és nagybetűket megkülönböztető névvel RangeStart és RangeEnd. Ezek az Power Query-szerkesztő Paraméterek kezelése párbeszédpanelen definiált paraméterek kezdetben a Power BI Desktop modelltáblájába betöltött adatok szűrésére szolgálnak, hogy csak azokat a sorokat tartalmazzák, amelyeken belül dátum/idő van. RangeStart a legrégebbi vagy legkorábbi dátumot/időt jelöli, és RangeEnd a legújabbat vagy a legújabb dátumot/időt jelöli. Miután közzétette a modellt a szolgáltatásban, RangeStart és RangeEnd a szolgáltatás automatikusan felülírja a növekményes frissítési szabályzat beállításaiban megadott frissítési időszak által meghatározott adatok lekérdezéséhez.
A FactInternetSales adatforrástáblája például naponta átlagosan 10 000 új sort átlagl. A Power BI Desktopban a modellbe eredetileg betöltött sorok számának korlátozásához adjon meg két napos időszakot a következők között RangeStart RangeEnd: .
Adatok szűrése
A RangeStart megadott paraméterekkel RangeEnd egyéni dátumszűrőket alkalmazhat a tábla dátumoszlopára. Az alkalmazott szűrők kiválasztják a modellbe betöltött adatok egy részhalmazát, amikor az Alkalmaz lehetőséget választja.
A FactInternetSales-példában a paraméterek alapján létrehozott szűrők és a lépések alkalmazása után két napnyi adat (körülbelül 20 000 sor) lesz betöltve a modellbe.
Szabályzat definiálása
A szűrők alkalmazása és az adatok egy részhalmazának a modellbe való betöltése után növekményes frissítési szabályzatot kell meghatároznia a táblához. Miután közzétette a modellt a szolgáltatásban, a szolgáltatás a táblapartíciók létrehozására és kezelésére, valamint frissítési műveletek végrehajtására használja a szabályzatot. A szabályzat meghatározásához használja a Növekményes frissítés és a valós idejű adatok párbeszédpanelt a szükséges és az opcionális beállítások megadásához.
Tábla
A Tábla kijelölése listamező alapértelmezés szerint az Adat nézetben kijelölt táblára van bekapcsolva. Növekményes frissítés engedélyezése a táblázathoz a csúszkával. Ha a tábla Power Query-kifejezése nem tartalmaz szűrőt a paraméterek és RangeEnd a RangeStart paraméterek alapján, a kapcsoló nem érhető el.
Kötelező beállítások
A frissítési dátum beállítása előtt kezdődő archív adatok határozzák meg azt az előzményidőszakot, amelyben az adott időszakban dátumot/időt tartalmazó sorok szerepelnek a modellben, valamint az aktuális hiányos előzményidőszak sorait, valamint a frissítési időszak sorait az aktuális dátumig és időpontig.
Ha például öt évet ad meg, a tábla az elmúlt öt év előzményadatait évpartíciókban tárolja. A táblázat az aktuális év sorait is tartalmazza negyedéves, havi vagy napi partíciókban, egészen a frissítési időszakig.
Prémium kapacitású modellek esetén a háttérrendszerbeli előzménypartíciók szelektíven frissíthetők a beállítás által meghatározott részletességgel. További információ: Speciális növekményes frissítés – Partíciók.
A frissítési dátum beállítása előtt kezdődő növekményes frissítési adatok határozzák meg azt a növekményes frissítési időszakot, amelyben az adott időszakhoz tartozó összes sor szerepel a frissítési partíciókban, és minden frissítési művelettel frissül.
Ha például három napos frissítési időszakot ad meg minden frissítési művelettel, a szolgáltatás felülbírálja azokat RangeStart és RangeEnd a paramétereket, hogy egy háromnapos időszakon belüli dátum/idő típusú sorok lekérdezését hozza létre, amelynek kezdete és befejezése az aktuális dátumtól és időtől függ. A rendszer frissíti azokat a sorokat, amelyekben az elmúlt három napban dátum/idő szerepel az aktuális frissítési művelet időpontjáig. Ilyen típusú szabályzat esetén a FactInternetSales modelltáblánkra számíthat a szolgáltatásban, amely naponta átlagosan 10 000 új sort ad meg, és körülbelül 30 000 sort frissít minden frissítési művelettel.
Adjon meg egy olyan időszakot, amely csak a pontos jelentéskészítéshez szükséges sorok minimális számát tartalmazza. Ha egynél több táblára határoz meg szabályzatokat, akkor is ugyanazokat RangeStart és RangeEnd paramétereket kell használni, még akkor is, ha az egyes táblákhoz különböző tárolási és frissítési időszakok vannak meghatározva.
Választható beállítások
A DirectQuery (csak Prémium) beállítással valós időben lekérheti a legújabb adatokat az adatforrás kiválasztott táblájából a növekményes frissítési időszakon túl a DirectQuery használatával. A növekményes frissítési időszaknál későbbi dátum/idő értékkel rendelkező összes sort egy DirectQuery-partíció tartalmazza, és minden modelllekérdezéssel lekéri az adatforrásból.
Ha például ez a beállítás engedélyezve van, minden frissítési műveletnél a szolgáltatás továbbra is felülbírálja a RangeStart lekérdezést és RangeEnd a paramétereket, hogy létrehozhasson egy lekérdezést a frissítési időszak utáni dátummal/idővel rendelkező sorokhoz, és a kezdés az aktuális dátumtól és időponttól függ. Az aktuális frissítési művelet időpontját követő dátum/idő sorokat is belefoglaljuk. Ezzel a szabályzattípussal a szolgáltatás FactInternetSales modelltáblája tartalmazza a legújabb adatfrissítéseket.
A Csak a teljes napok frissítése beállítás biztosítja, hogy az egész nap összes sora szerepeljön a frissítési műveletben. Ez a beállítás nem kötelező, kivéve, ha a DirectQuery (csak Prémium) beállítással valós időben engedélyezi a legújabb adatok lekérését. Tegyük fel például, hogy a frissítés minden reggel 4:00-kor fog futni. Ha az adatforrástáblában éjfél és hajnali 4 óra közötti négy órában új adatsorok jelennek meg, akkor nem kell őket figyelembe vennie. Egyes üzleti metrikák, például az olaj- és gáziparban napi hordók, nem értik a részleges napokat. Egy másik példa egy pénzügyi rendszer adatainak frissítése, ahol az előző hónap adatait a hónap tizenkettedik naptári napján hagyják jóvá. Beállíthatja a frissítési időszakot egy hónapra, és ütemezheti, hogy a frissítés a hónap tizenkettedik napján fusson. Ezzel a beállítással például február 12-én frissítené a januári adatokat.
Ne feledje, hogy ha az ütemezett frissítés nem UTC időzónára van konfigurálva, a szolgáltatás frissítési műveletei UTC idő alatt futnak, ami meghatározhatja a tényleges dátumot és a teljes időszakokat.
Az Adatváltozások észlelése beállítás még szelektívebb frissítést tesz lehetővé. Kijelölhet egy dátum/idő oszlopot, amellyel csak azokat a napokat azonosíthatja és frissítheti, ahol az adatok megváltoztak. Ez a beállítás feltételezi, hogy egy ilyen oszlop létezik az adatforrásban, amely általában naplózási célokra szolgál. Ez az oszlop nem lehet ugyanaz az oszlop, amelyet az adatok és RangeEnd paraméterek RangeStart particionálásához használnak. Ennek az oszlopnak a maximális értékét a növekményes tartomány minden egyes időszakára kiértékeli a rendszer. Ha az utolsó frissítés óta nem változott, nincs szükség az időszak frissítésére, ami tovább csökkentheti a növekményesen frissített napokat háromról egyre.
A jelenlegi kialakítás megköveteli, hogy az adatváltozásokat észlelő oszlop megmaradjon, és gyorsítótárazva legyen a memóriában. A számosság és a memóriahasználat csökkentésére az alábbi technikák használhatók:
- A frissítéskor csak az oszlop maximális értékét őrizze meg, esetleg Egy Power Query-függvény használatával.
- A frissítési gyakoriságra vonatkozó követelményeknek megfelelően csökkentse a pontosságot elfogadható szintre.
- Adjon meg egy egyéni lekérdezést az adatváltozások észleléséhez az XMLA-végpont használatával, és kerülje az oszlopérték teljes megőrzését.
Bizonyos esetekben tovább bővíthető az Adatváltozások észlelése lehetőség engedélyezése. Előfordulhat például, hogy el szeretné kerülni az utolsó frissítési oszlop megőrzését a memóriában lévő gyorsítótárban, vagy olyan forgatókönyveket szeretne engedélyezni, amelyekben egy konfigurációs/utasítástáblát kinyerési-átalakítási-betöltési (ETL-) folyamatok készítenek, hogy csak azokat a partíciókat jelöljék meg, amelyeket frissíteni kell. Ilyen esetekben a Prémium szintű kapacitások esetében használja a TMSL-t és/vagy a TOM-et az adatváltozások észlelésének viselkedésének felülbírálásához. További információ: Speciális növekményes frissítés – Egyéni lekérdezések az adatváltozások észleléséhez.
Közzététel
A növekményes frissítési szabályzat konfigurálása után közzéteszi a modellt a szolgáltatásban. Ha a közzététel befejeződött, végrehajthatja a kezdeti frissítési műveletet a modellen.
Feljegyzés
A növekményes frissítési szabályzattal rendelkező szemantikai modellek, hogy valós időben kapják meg a legfrissebb adatokat a DirectQueryvel, csak prémium szintű munkaterületen tehetők közzé.
A Prémium kapacitásokhoz hozzárendelt munkaterületeken közzétett modellek esetében, ha úgy gondolja, hogy a modell 1 GB-nál nagyobbra nő, javíthatja a frissítési művelet teljesítményét, és biztosíthatja, hogy a modell ne korlátozza a méretkorlátokat a nagyméretű szemantikai modell tárolási formátumának beállításával , 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.
Fontos
Miután a Power BI Desktop közzétette a modellt a szolgáltatásban, a .pbix nem tölthető le.
Frissítés
Miután közzétette a szolgáltatást, végrehajt egy kezdeti frissítési műveletet a modellen. Ennek a frissítésnek egyéni (manuális) frissítésnek kell lennie, hogy nyomon tudja követni az előrehaladást. A kezdeti frissítési művelet végrehajtása eltarthat egy ideig. Létre kell hozni a partíciókat, be kell tölteni az előzményadatokat, az olyan objektumokat, mint a kapcsolatok és a hierarchiák létrejönnek vagy újraépülnek, és újra kell számolni a számított objektumokat.
A későbbi, egyenként vagy ütemezett frissítési műveletek sokkal gyorsabbak, mert csak a növekményes frissítési partíciók frissülnek. A többi feldolgozási műveletnek továbbra is meg kell történnie, például a partíciók egyesítése és az újraszámítás, de általában sokkal kevesebb időt vesz igénybe, mint a kezdeti frissítés.
Automatikus jelentésfrissítés
Az olyan jelentések esetében, amelyek növekményes frissítési szabályzattal rendelkező modellt használnak a legfrissebb adatok valós idejű lekéréséhez a DirectQuery használatával, érdemes engedélyezni az automatikus oldalfrissítést rögzített időközönként vagy a változásészlelés alapján, hogy a jelentések késedelem nélkül tartalmazzák a legújabb adatokat. További információ: Automatikus oldalfrissítés a Power BI-ban.
Speciális növekményes frissítés
Ha a modell prémium szintű kapacitáson van, és engedélyezve van egy XMLA-végpont, a növekményes frissítés tovább bővíthető speciális forgatókönyvek esetén. Az SQL Server Management Studio használatával például megtekintheti és kezelheti a partíciókat, elindíthatja a kezdeti frissítési műveletet, vagy frissítheti a háttérrendszerbeli előzménypartíciókat. További információ: Speciális növekményes frissítés az XMLA-végponttal.
Közösség
A Power BI-nak élénk közössége van, ahol az MVP-k, a bi-szakemberek és a társviszonyok megosztják egymással a vitafórumokban, videókban, blogokban és egyebekben szerzett tapasztalatokat. A növekményes frissítés megismeréséhez tekintse meg az alábbi erőforrásokat:
- Power BI-közösség
- Keresés a "Power BI növekményes frissítés" kifejezésben a Bingben
- Keresés a "Fájlok növekményes frissítése" kifejezésre a Bingben
- Keresés a "Meglévő adatok megőrzése növekményes frissítéssel" kifejezésre a Bingben