Přírůstková aktualizace a data v reálném čase pro sémantické modely

Přírůstková aktualizace a data v reálném čase pro sémantické modely v Power BI poskytují efektivní způsoby zpracování dynamických dat a zlepšení výkonu aktualizace modelu. Díky automatizaci vytváření a správy oddílů přírůstková aktualizace snižuje množství dat, která je potřeba aktualizovat, a umožňuje zahrnutí dat v reálném čase. Tento článek vysvětluje, jak nakonfigurovat a používat funkce přírůstkové aktualizace v Power BI k zachycení rychle se pohyblivých dat a zvýšení výkonu.

Přírůstková aktualizace rozšiřuje plánované operace aktualizace tím, že poskytuje automatizované vytváření a správu oddílů pro tabulky sémantických modelů, které často načítají nová a aktualizovaná data. U většiny modelů obsahují jedna nebo více tabulek transakční data, která se často mění a může exponenciálně růst, například tabulka faktů ve schématu relační nebo hvězdicové databáze. Zásada přírůstkové aktualizace pro rozdělení tabulky, aktualizace pouze nejnovějších oddílů importu a volitelně použití jiného oddílu DirectQuery pro data v reálném čase může výrazně snížit množství dat, která se mají aktualizovat. Zároveň tato zásada zajišťuje, aby se do výsledků dotazu zahrnuly nejnovější změny ve zdroji dat.

S přírůstkovou aktualizací a daty v reálném čase:

  • Vyžaduje se méně cyklů aktualizace pro rychle se měnící data. Režim DirectQuery získá nejnovější aktualizace dat při zpracování dotazů bez nutnosti vysoké četnosti aktualizací.
  • Aktualizace jsou rychlejší. Je potřeba aktualizovat pouze nejnovější data, která se změnila.
  • Aktualizace jsou spolehlivější. Dlouhotrvající připojení k nestálým zdrojům dat nejsou nutná. Dotazy na zdrojová data běží rychleji, což snižuje potenciál problémů se sítí, které by mohly kolidovat.
  • Spotřeba prostředků se snižuje. Méně dat k aktualizaci snižuje celkovou spotřebu paměti a dalších prostředků v systémech Power BI i zdrojů dat.
  • Jsou povoleny velké sémantické modely. Sémantické modely s potenciálně miliardami řádků můžou růst, aniž by bylo nutné plně aktualizovat celý model každou operací aktualizace.
  • Nastavení je snadné. Zásady přírůstkové aktualizace se definují v Power BI Desktopu jenom s několika úlohami. Když Power BI Desktop sestavu publikuje, služba tyto zásady automaticky použije při každé aktualizaci.

Když publikujete model Power BI Desktopu do služby, každá tabulka v novém modelu má jeden oddíl. Tento jeden oddíl obsahuje všechny řádky pro danou tabulku. Pokud je tabulka velká, řekněme s desítkami milionů řádků nebo více, může aktualizace této tabulky trvat dlouhou dobu a spotřebovávat nadměrné množství prostředků.

Při přírůstkové aktualizaci služba dynamicky rozděluje a odděluje data, která je potřeba aktualizovat často od dat, která je možné aktualizovat méně často. Data tabulky se filtrují pomocí parametrů data a času Power Query s vyhrazenými názvy a rozlišují se malá a velká písmenaRangeStart.RangeEnd Když v Power BI Desktopu konfigurujete přírůstkovou aktualizaci, použijí se tyto parametry k filtrování jenom malého období dat načtených do modelu. Když Power BI Desktop publikuje sestavu do služba Power BI, při první operaci aktualizace vytvoří služba přírůstkovou aktualizaci a historické oddíly a volitelně oddíl DirectQuery v reálném čase na základě nastavení zásad přírůstkové aktualizace. Služba pak přepíše hodnoty parametrů tak, aby filtrovat a dotazovat data pro každý oddíl na základě hodnot data a času pro každý řádek.

Při každé následné aktualizaci filtry dotazu vrátí pouze tyto řádky v období aktualizace dynamicky definované parametry. Tyto řádky s datem a časem v rámci období aktualizace se aktualizují. Řádky s datem a časem už nejsou v období aktualizace součástí historického období, které se neaktualizuje. Pokud je oddíl DirectQuery v reálném čase součástí zásad přírůstkové aktualizace, aktualizuje se také jeho filtr tak, aby se vychytály všechny změny, ke kterým dochází po období aktualizace. Aktualizace i historická období se zahrnou dál. Při vytváření nových oddílů přírůstkové aktualizace se oddíly aktualizace už v období aktualizace stanou historickými oddíly. V průběhu času se historické oddíly stávají méně podrobnými, protože se sloučí dohromady. Pokud už historický oddíl není v historickém období definovaném zásadou, úplně se odebere z modelu. Toto chování se označuje jako vzor posuvné okno.

Obrázek představující vzor posuvné okno

Výhodou přírůstkové aktualizace je to, že služba zpracovává vše za vás na základě vámi definovaných zásad přírůstkové aktualizace. Ve skutečnosti se proces a oddíly vytvořené ze služby nezobrazují. Ve většině případů je dobře definovaná zásada přírůstkové aktualizace vše, co je nezbytné k významnému zlepšení výkonu aktualizace modelu. Oddíl DirectQuery v reálném čase se ale podporuje jenom pro modely v kapacitách Premium. Power BI Premium také umožňuje pokročilejší scénáře dělení a aktualizace prostřednictvím koncového bodu XML for Analysis (XMLA).

Požadavky

Další části popisují podporované plány a zdroje dat.

Podporované plány

Přírůstková aktualizace je podporovaná pro modely Power BI Premium, Premium na uživatele, Power BI Pro a Power BI Embedded.

Získání nejnovějších dat v reálném čase pomocí DirectQuery se podporuje jenom pro modely Power BI Premium, Premium na uživatele a Power BI Embedded.

Podporované zdroje dat

Přírůstková aktualizace a data v reálném čase fungují nejlépe pro strukturované a relační zdroje dat, jako jsou SQL Database a Azure Synapse, ale můžou také fungovat pro jiné zdroje dat. V každém případě musí váš zdroj dat podporovat následující:

Filtrování kalendářních dat – Zdroj dat musí podporovat určitý mechanismus filtrování dat podle data. U relačního zdroje se obvykle jedná o sloupec kalendářních dat data a času nebo celočíselného datového typu v cílové tabulce. Parametry RangeStart a RangeEnd, které musí být datovým typem datum a čas, filtruje data tabulky na základě sloupce kalendářního data. Pro sloupce kalendářních dat celočíselné náhradní klíče ve formě yyyymmdd, můžete vytvořit funkci, která převede hodnotu data a času v parametrech RangeStart a RangeEnd tak, aby odpovídaly celočíselné náhradní klíče sloupce kalendářního data. Další informace najdete v tématu Konfigurace přírůstkové aktualizace a dat v reálném čase – Převod data DateTime na celé číslo.

U jiných zdrojů dat musí být parametry RangeStart a RangeEnd předány zdroji dat nějakým způsobem, který umožňuje filtrování. U souborových zdrojů dat, ve kterých jsou soubory a složky uspořádané podle data, lze parametry RangeStart a RangeEnd použít k filtrování souborů a složek a k výběru souborů, které se mají načíst. U webových zdrojů dat je možné do požadavku HTTP integrovat parametry RangeStart a RangeEnd. Například následující dotaz lze použít k přírůstkové aktualizaci trasování z instance AppInsights:

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

Při konfiguraci přírůstkové aktualizace se ve zdroji dat spustí výraz Power Query, který obsahuje filtr data a času na základě parametrů RangeStart a RangeEnd. Pokud je filtr zadaný v kroku dotazu za počátečním zdrojovým dotazem, je důležité, aby posouvání dotazů zkombinuje počáteční krok dotazu s kroky, které odkazují na parametry RangeStart a RangeEnd. Například v následujícím výrazu dotazu se přeloží, Table.SelectRows protože bezprostředně následuje krok Sql.Database a SQL Server podporuje posouvání:

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"

Není nutné, aby konečný dotaz podporoval posouvání. Například v následujícím výrazu používáme neskládání NativeQuery, ale integrujeme parametry RangeStart a RangeEnd přímo do SQL:

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

Pokud ale zásada přírůstkové aktualizace zahrnuje získání dat v reálném čase pomocí DirectQuery, transformace bez posouvání se nedají použít. Pokud se jedná o čistou zásadu režimu importu bez dat v reálném čase, modul mashupu dotazů může kompenzovat a použít filtr místně, což vyžaduje načtení všech řádků tabulky ze zdroje dat. To může způsobit, že přírůstková aktualizace bude pomalá a proces může docházet k prostředkům buď v služba Power BI, nebo v místní bráně dat – což efektivně porazí účel přírůstkové aktualizace.

Vzhledem k tomu, že podpora posouvání dotazů se u různých typů zdrojů dat liší, je potřeba provést ověření, aby se zajistilo, že je logika filtru zahrnutá do dotazů, které se spouštějí ve zdroji dat. Power BI Desktop se ve většině případů pokusí provést toto ověření za vás při definování zásad přírůstkové aktualizace. U zdrojů dat založených na SQL, jako jsou SQL Database, Azure Synapse, Oracle a Teradata, je toto ověření spolehlivé. Jiné zdroje dat ale nemusí být možné ověřit bez trasování dotazů. Pokud Power BI Desktop nedokáže potvrdit dotazy, zobrazí se v dialogovém okně konfigurace zásad přírůstkové aktualizace upozornění.

Snímek obrazovky s upozorněním na posouvání dotazů

Pokud se zobrazí toto upozornění a chcete ověřit, jestli dochází k potřebnému posouvání dotazů, použijte funkci Diagnostiky Power Query nebo pomocí nástroje podporovaného zdrojem dat, jako je SQL Profiler. Pokud k posouvání dotazů neděje, ověřte, že je logika filtru zahrnutá do dotazu předávaného zdroji dat. Pokud ne, dotaz pravděpodobně obsahuje transformaci, která brání posouvání.

Před konfigurací řešení přírůstkové aktualizace nezapomeňte důkladně přečíst pokyny k posouvání dotazů v Power BI Desktopu a posouvání dotazů Power Query a porozumět jim. Tyto články vám můžou pomoct určit, jestli váš zdroj dat a dotazy podporují posouvání dotazů.

Jeden zdroj dat

Pokud konfigurujete přírůstkovou aktualizaci a data v reálném čase pomocí Power BI Desktopu nebo nakonfigurujete pokročilé řešení pomocí jazyka TMSL (Tabular Model Scripting Language) nebo tabulkového objektového modelu (TOM) prostřednictvím koncového bodu XMLA, musí se všechny oddíly, ať už import nebo DirectQuery, dotazovat data z jednoho zdroje.

Jiné typy zdrojů dat

Pomocí více vlastních funkcí dotazů a logiky dotazů je možné přírůstkovou aktualizaci použít s jinými typy zdrojů dat, pokud filtry založené na RangeStart nich a RangeEnd lze je předat v jednom dotazu, jako jsou zdroje dat, jako jsou soubory excelového sešitu uložené ve složce, soubory v SharePointu a informační kanály RSS. Mějte na paměti, že jde o pokročilé scénáře, které vyžadují další přizpůsobení a testování nad rámec toho, co je zde popsáno. V části Komunity si dále v tomto článku projděte návrhy, jak najít další informace o používání přírůstkové aktualizace pro jedinečné scénáře.

Lhůty

Bez ohledu na přírůstkovou aktualizaci mají modely Power BI Pro časový limit aktualizace dvě hodiny a nepodporují získávání dat v reálném čase pomocí DirectQuery. U modelů v kapacitě Premium je časový limit pět hodin. Operace aktualizace jsou náročné na procesy a paměť. Úplná operace aktualizace může použít tolik jako dvojnásobnou velikost paměti vyžadovanou samotným modelem, protože služba udržuje snímek modelu v paměti, dokud nebude operace aktualizace dokončena. Operace aktualizace můžou být také náročné na procesy, které spotřebovávají značné množství dostupných prostředků procesoru. Operace aktualizace musí také spoléhat na nestálá připojení ke zdrojům dat a schopnost těchto systémů zdrojů dat rychle vracet výstup dotazu. Časový limit je zárukou, která omezuje nadlimitní spotřebu dostupných prostředků.

Poznámka:

U kapacit Premium nemají operace aktualizace prováděné prostřednictvím koncového bodu XMLA žádný časový limit. Další informace najdete v tématu Rozšířená přírůstková aktualizace s koncovým bodem XMLA.

Vzhledem k tomu, že přírůstková aktualizace optimalizuje operace aktualizace na úrovni oddílu v modelu, může se výrazně snížit spotřeba prostředků. Současně platí, že i s přírůstkovou aktualizací, pokud neprojdou koncovým bodem XMLA, jsou operace aktualizace svázané se stejnými dvěma hodinovými a pětihodinovými limity. Efektivní zásada přírůstkové aktualizace nejen snižuje množství dat zpracovaných operací aktualizace, ale také snižuje množství nepotřebných historických dat uložených v modelu.

Dotazy můžou být také omezeny výchozím časovým limitem zdroje dat. Většina relačních zdrojů dat umožňuje přepisovat časové limity ve výrazu Power Query M. Například následující výraz používá funkci přístupu k datům SQL Serveru k nastavení CommandTimeout na dvě hodiny. Každé období definované rozsahy zásad odešle dotaz, který sleduje nastavení časového limitu příkazu:

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"

U velmi velkých modelů v kapacitách Premium, které pravděpodobně obsahují miliardy řádků, je možné počáteční operaci aktualizace spustit. Bootstrapping umožňuje službě vytvářet objekty tabulky a oddílů pro model, ale nenačítá a zpracovává data do žádného oddílu. Pomocí aplikace SQL Server Management Studio můžete nastavit, aby se oddíly zpracovávaly jednotlivě, postupně nebo paralelně, abyste snížili množství dat vrácených v jednom dotazu a také vynechali časový limit pětihodinových hodin. Další informace najdete v tématu Rozšířená přírůstková aktualizace – Zabránění vypršení časových limitů při počáteční úplné aktualizaci.

Aktuální datum a čas

Ve výchozím nastavení se aktuální datum a čas určuje na základě koordinovaného univerzálního času (UTC) v době aktualizace. U aktualizací na vyžádání a plánovaných aktualizací můžete v části Aktualizovat nakonfigurovat jiné časové pásmo, které se bude brát v úvahu při určování aktuálního data a času. Například aktualizace, která nastane v 18:00 Tichomoří (USA a Kanada) s nakonfigurovaným časovým pásmem určuje aktuální datum a čas na základě tichomořský čas, nikoli UTC, což by vrátilo následující den.

Snímek obrazovky s dialogovým oknem Naplánovaná aktualizace zobrazující vstupní pole časového pásma

Operace aktualizace, které nejsou vyvolány prostřednictvím služba Power BI, jako je například příkaz aktualizace XMLA TMSL nebo rozšířené rozhraní API pro aktualizaci, nebere v úvahu nakonfigurované časové pásmo plánované aktualizace a výchozí nastavení UTC.

Konfigurace přírůstkové aktualizace a dat v reálném čase

Tato část popisuje důležité koncepty konfigurace přírůstkové aktualizace a dat v reálném čase. Až budete připraveni na podrobnější podrobné pokyny, přečtěte si téma Konfigurace přírůstkové aktualizace a dat v reálném čase.

Konfigurace přírůstkové aktualizace se provádí v Power BI Desktopu. U většiny modelů se vyžaduje jenom několik úloh. Mějte však na paměti následující body:

  • Po publikování do služba Power BI nemůžete z Power BI Desktopu znovu publikovat stejný model. Opětovné publikování odebere všechny existující oddíly a data, které už v modelu jsou. Pokud publikujete do kapacity Premium, je možné provést následné změny schématu metadat pomocí nástrojů, jako je open source ALM Toolkit, nebo pomocí TMSL. Další informace najdete v tématu Rozšířená přírůstková aktualizace – nasazení pouze s metadaty.
  • Po publikování do služba Power BI nemůžete model stáhnout zpět jako soubor .pbix do Power BI Desktopu. Vzhledem k tomu, že modely ve službě můžou růst tak velké, je nepraktické je stáhnout a otevřít na typickém stolním počítači.
  • Při získávání dat v reálném čase pomocí DirectQuery nemůžete model publikovat do pracovního prostoru mimo Premium. Přírůstková aktualizace s daty v reálném čase se podporuje jenom v Power BI Premium.

Vytvoření parametrů

Pokud chcete v Power BI Desktopu nakonfigurovat přírůstkovou aktualizaci, nejprve vytvoříte dva parametry data a času Power Query s vyhrazenými názvy RangeStart rozlišující malá a velká písmena a RangeEnd. Tyto parametry definované v dialogovém okně Spravovat parametry v Editor Power Query se zpočátku používají k filtrování dat načtených do tabulky modelu Power BI Desktopu tak, aby zahrnovaly pouze řádky s datem a časem v daném období. RangeStart představuje nejstarší nebo nejstarší datum a čas a RangeEnd představuje nejnovější nebo nejnovější datum a čas. Jakmile je model publikován do služby RangeStart a RangeEnd služba je automaticky přepsána k dotazování na data definovaná obdobím aktualizace zadaným v nastavení zásad přírůstkové aktualizace.

Například tabulka zdroje dat FactInternetSales průměruje 10 000 nových řádků za den. Pokud chcete omezit počet řádků původně načtených do modelu v Power BI Desktopu, zadejte dvoudenní období mezi RangeStart a RangeEnd.

Snímek obrazovky s dialogovým oknem Spravovat parametry zobrazující parametry RangeStart a RangeEnd

Filtrování dat

RangeStart S definovanými parametry RangeEnd použijete vlastní filtry kalendářních dat ve sloupci kalendářních dat tabulky. Filtry, které použijete, vyberou podmnožinu dat načtených do modelu, když vyberete Použít.

Snímek obrazovky místní nabídky sloupce s vybranou možností Vlastní filtr

V našem příkladu FactInternetSales se po vytvoření filtrů na základě parametrů a použití kroků načtou do modelu dva dny dat (zhruba 20 000 řádků).

Definování zásad

Po použití filtrů a načtení podmnožina dat do modelu definujete zásadu přírůstkové aktualizace tabulky. Po publikování modelu do služby služba použije zásadu k vytvoření a správě oddílů tabulky a provádění operací aktualizace. K definování zásad použijete dialogové okno Přírůstková aktualizace a data v reálném čase k určení požadovaných i volitelných nastavení.

Snímek obrazovky s dialogovým oknem Přírůstková aktualizace a data v reálném čase zobrazující možnost Přírůstková aktualizace této tabulky zapnutá

Table

Ve výchozím nastavení vyberte tabulku, kterou jste vybrali v zobrazení Data. Povolte přírůstkovou aktualizaci tabulky pomocí posuvníku. Pokud výraz Power Query pro tabulku neobsahuje filtr založený na parametrech RangeStart , RangeEnd přepínač není k dispozici.

Požadovaná nastavení

Nastavení Archivovat data začínající před datem aktualizace určuje historické období, ve kterém jsou řádky s datem a časem v daném období zahrnuty do modelu, plus řádky pro aktuální neúplné historické období a řádky v období aktualizace až do aktuálního data a času.

Pokud například zadáte pět let, uloží tabulka posledních pět celých let historických dat do oddílů roku. Tabulka bude obsahovat také řádky pro aktuální rok v čtvrtletích, měsících nebo dnech, a to až do a včetně období aktualizace.

U modelů v kapacitách Premium je možné zastaralé historické oddíly selektivně aktualizovat v členitosti určené tímto nastavením. Další informace najdete v tématu Pokročilá přírůstková aktualizace – Oddíly.

Data přírůstkové aktualizace začínající před nastavením data aktualizace určují období přírůstkové aktualizace, ve kterém jsou všechny řádky s datem a časem v daném období zahrnuty do oddílů aktualizace a aktualizovány s každou operací aktualizace.

Pokud například zadáte období aktualizace tři dny s každou operací aktualizace, služba přepíše RangeStart a RangeEnd parametry pro řádky s datem a časem v rámci třídenního období, přičemž začátek a konec závisí na aktuálním datu a čase. Řádky s datem a časem za poslední tři dny až do aktuálního času operace aktualizace se aktualizují. S tímto typem zásad můžete očekávat, že naše tabulka modelu FactInternetSales ve službě, která průměruje 10 000 nových řádků za den, aktualizuje přibližně 30 000 řádků s každou operací aktualizace.

Zadejte období, které zahrnuje pouze minimální počet řádků potřebných k zajištění přesného vykazování. Když definujete zásady pro více než jednu tabulku, musí se použít stejné RangeStart parametry i RangeEnd v případě, že jsou pro každou tabulku definována různá období ukládání a aktualizace.

Volitelná nastavení

Nastavení Získat nejnovější data v reálném čase pomocí DirectQuery (jenom Premium) umožňuje načíst nejnovější změny z vybrané tabulky ve zdroji dat mimo období přírůstkové aktualizace pomocí DirectQuery. Všechny řádky s datem a časem pozdějším než období přírůstkové aktualizace jsou zahrnuty do oddílu DirectQuery a načteny ze zdroje dat s každým dotazem modelu.

Pokud je například toto nastavení povolené, při každé operaci aktualizace služba stále přepíše RangeStart a RangeEnd parametry pro vytvoření dotazu na řádky s datem a časem po období aktualizace, přičemž začátek závisí na aktuálním datu a čase. Řádky s datem a časem po aktuální době operace aktualizace jsou zahrnuty také. S tímto typem zásad zahrnuje tabulka modelu FactInternetSales ve službě nejnovější aktualizace dat.

Nastavení Pouze aktualizovat dokončené dny zajišťuje, že všechny řádky pro celý den jsou součástí operace aktualizace. Toto nastavení je volitelné, pokud nepovolíte možnost Získat nejnovější data v reálném čase pomocí nastavení DirectQuery (jenom Premium). Řekněme například, že aktualizace je naplánovaná tak, aby se spustila každé ráno v 4:00. Pokud se nové řádky dat zobrazí v tabulce zdroje dat během těchto čtyř hodin mezi půlnocí a 4:00, nechcete je za ně počítat. Některé obchodní metriky, jako jsou barel za den v ropy a plynárenský průmysl, nemají smysl s částečnými dny. Dalším příkladem je aktualizace dat z finančního systému, kde se data za předchozí měsíc schvalují ve dvanáctém kalendářním dni v měsíci. Období aktualizace můžete nastavit na jeden měsíc a naplánovat spuštění aktualizace na dvanáctý den v měsíci. Při výběru této možnosti by se například aktualizovala lednová data 12. února.

Mějte na paměti, že pokud není plánovaná aktualizace nakonfigurovaná pro časové pásmo mimo UTC, operace aktualizace ve službě běží v čase UTC, což může určit datum účinnosti a úplná období.

Nastavení Zjistit změny dat umožňuje ještě selektivnější aktualizaci. Můžete vybrat sloupec data a času, který slouží k identifikaci a aktualizaci pouze těch dnů, ve kterých se data změnila. Toto nastavení předpokládá, že takový sloupec existuje ve zdroji dat, což je obvykle pro účely auditování. Tento sloupec by neměl být stejný sloupec, který se používá k rozdělení dat pomocí RangeStart parametrů a RangeEnd parametrů. Maximální hodnota tohoto sloupce se vyhodnotí pro každé období v přírůstkovém rozsahu. Pokud se od poslední aktualizace nezměnila, není potřeba období aktualizovat, což by mohlo potenciálně dále snížit počet dnů přírůstkových aktualizací ze tří na jednu.

Aktuální návrh vyžaduje, aby byl sloupec pro detekci změn dat trvalý a uložen v mezipaměti do paměti. Ke snížení kardinality a spotřeby paměti je možné použít následující techniky:

  • Zachovat pouze maximální hodnotu sloupce v době aktualizace, třeba pomocí funkce Power Query.
  • Snižte přesnost na přijatelnou úroveň vzhledem k vašim požadavkům na frekvenci aktualizace.
  • Definujte vlastní dotaz pro detekci změn dat pomocí koncového bodu XMLA a vyhněte se úplnému zachování hodnoty sloupce.

V některých případech je možné ještě vylepšit možnost Zjistit změny dat. Můžete se například chtít vyhnout zachování sloupce poslední aktualizace v mezipaměti v paměti nebo povolit scénáře, kdy je konfigurační/instrukční tabulka připravená procesy extrakce a transformace načítání (ETL) pro označení pouze těch oddílů, které je potřeba aktualizovat. V takových případech u kapacit Premium použijte TMSL nebo TOM k přepsání chování detekce změn dat. Další informace najdete v tématu Pokročilá přírůstková aktualizace – vlastní dotazy pro detekci změn dat.

Publikovat

Po konfiguraci zásad přírůstkové aktualizace publikujete model do služby. Po dokončení publikování můžete v modelu provést počáteční operaci aktualizace.

Poznámka:

Sémantické modely se zásadami přírůstkové aktualizace pro získání nejnovějších dat v reálném čase pomocí DirectQuery je možné publikovat pouze do pracovního prostoru Premium.

Pokud se domníváte, že modely publikované do pracovních prostorů přiřazených kapacitám Premium se model zvýší nad 1 GB, můžete zlepšit výkon operace aktualizace a zajistit, aby model nepřekládal limity velikosti tím, že před provedením první operace aktualizace ve službě povolíte nastavení formátu úložiště velkých sémantických modelů. Další informace najdete v tématu Velké modely v Power BI Premium.

Důležité

Jakmile Power BI Desktop publikuje model do služby, nemůžete stáhnout tento soubor .pbix zpět.

Aktualizovat

Po publikování do služby provedete v modelu počáteční operaci aktualizace. Tato aktualizace by měla být individuální (ruční) aktualizace, abyste mohli sledovat průběh. Dokončení počáteční operace aktualizace může nějakou dobu trvat. Oddíly se musí vytvářet, načítat historická data, objekty, jako jsou relace a hierarchie vytvořené nebo znovu sestavené, a počítané objekty se přepočítávají.

Následné operace aktualizace, buď jednotlivé, nebo naplánované, jsou mnohem rychlejší, protože se aktualizují jenom oddíly přírůstkové aktualizace. Další operace zpracování musí proběhnout i nadále, například sloučení oddílů a přepočtu, ale obvykle trvá mnohem kratší dobu než počáteční aktualizace.

Automatická aktualizace sestavy

U sestav, které používají model se zásadami přírůstkové aktualizace k získání nejnovějších dat v reálném čase pomocí DirectQuery, je vhodné povolit automatickou aktualizaci stránky v pevném intervalu nebo na základě detekce změn, aby sestavy obsahovaly nejnovější data bez zpoždění. Další informace najdete v tématu Automatická aktualizace stránky v Power BI.

Rozšířená přírůstková aktualizace

Pokud je váš model v kapacitě Premium s povoleným koncovým bodem XMLA, je možné přírůstkovou aktualizaci dále rozšířit pro pokročilé scénáře. Sql Server Management Studio můžete například použít k zobrazení a správě oddílů, spuštění počáteční operace aktualizace nebo aktualizaci zastaralých historických oddílů. Další informace najdete v tématu Rozšířená přírůstková aktualizace s koncovým bodem XMLA.

Komunita

Power BI má živou komunitu, ve které MVP, profesionálové a kolegové sdílejí odborné znalosti v diskuzích, videích, blogech a dalších. Při získávání informací o přírůstkové aktualizaci si projděte tyto zdroje informací: