Přehled zásad aktualizace

Zásady aktualizací jsou mechanismy automatizace aktivované při zápisu nových dat do tabulky. Eliminují potřebu speciální orchestrace spuštěním dotazu, který transformuje ingestovaná data a uloží výsledek do cílové tabulky. V jedné tabulce je možné definovat více zásad aktualizací, což umožňuje různé transformace a ukládání dat do více tabulek současně. Cílové tabulky můžou mít jiné schéma, zásady uchovávání informací a další zásady ze zdrojové tabulky.

Například zdrojová tabulka trasování s vysokou rychlostí může obsahovat data formátovaná jako sloupec s volným textem. Cílová tabulka může obsahovat konkrétní trasovací čáry s dobře strukturovaným schématem vygenerovaným transformací volných textových dat zdrojové tabulky pomocí operátoru parse. Další informace najdete v běžných scénářích.

Následující diagram znázorňuje základní zobrazení zásad aktualizace. Zobrazuje dvě zásady aktualizace, které se aktivují při přidání dat do druhé zdrojové tabulky, a výsledkem je přidání transformovaných dat do dvou cílových tabulek.

Zásady aktualizací podléhají stejným omezením a osvědčeným postupům jako pravidelné příjem dat. Zásady se škálují podle velikosti clusteru a jsou efektivnější při zpracování hromadného příjmu dat.

Poznámka

• Zdrojová a cílová tabulka musí být ve stejné databázi.
• Schéma funkce zásady aktualizace a schéma cílové tabulky se musí shodovat v jejich názvech sloupců, typech a pořadí.

Příjem formátovaných dat zlepšuje výkon a csv je preferovaný, protože se jedná o dobře definovaný formát. Někdy ale nemáte žádnou kontrolu nad formátem dat nebo chcete ingestovaných dat rozšířit, například propojením záznamů s tabulkou statických dimenzí v databázi.

Aktualizovat dotaz zásad

Pokud je zásada aktualizace definovaná v cílové tabulce, může se na data ingestovaných do zdrojové tabulky spustit více dotazů. Pokud existuje více zásad aktualizace, není nutně známo pořadí provádění.

Omezení dotazů

• Dotaz související se zásadami může vyvolat uložené funkce, ale:
  • Nemůže provádět dotazy mezi clustery.
  • Nemá přístup k externím datům nebo externím tabulkám.
  • Nemůže vytvářet popisky (pomocí modulu plug-in).
• Dotaz nemá přístup ke čtení k tabulkám, které mají povolené zásady RestrictedViewAccess .
• Omezení zásad aktualizace pro příjem dat streamování najdete v tématu Omezení příjmu dat streamování.

Upozornění

Nesprávný dotaz může zabránit příjmu dat do zdrojové tabulky. Je důležité si uvědomit, že omezení a kompatibilita mezi výsledky dotazu a schématem zdrojové a cílové tabulky můžou způsobit nesprávný dotaz, který zabrání příjmu dat do zdrojové tabulky.

Tato omezení se ověřují při vytváření a spouštění zásad, ale ne při aktualizaci libovolných uložených funkcí, na které může dotaz odkazovat. Proto je důležité provádět jakékoli změny s opatrností, abyste zajistili, že zásady aktualizací zůstanou nedotčené.

Při odkazování na Source tabulku v Query části zásady nebo ve funkcích, na které Query část odkazuje:

• Nepoužívejte kvalifikovaný název tabulky. Místo toho použijte TableName.
• Nepoužívejte database("DatabaseName").TableName nebo cluster("ClusterName").database("DatabaseName").TableName.

Objekt zásady aktualizace

K tabulce může být přidruženo nula nebo více objektů zásad aktualizace. Každý takový objekt je reprezentován jako kontejner vlastností JSON s definovanými následujícími vlastnostmi.

Vlastnost	Typ	Description
IsEnabled	bool	Stavy, pokud je zásada aktualizace true – povolená nebo nepravda – zakázaná
Source	string	Název tabulky, která aktivuje vyvolání zásad aktualizace
Dotaz	string	Dotaz použitý k vytvoření dat pro aktualizaci
IsTransactional	bool	Uvádí, jestli jsou zásady aktualizace transakční nebo ne, výchozí hodnota je false. Pokud je zásada transakční a zásady aktualizace se nezdaří, zdrojová tabulka se neaktualizuje.
PropagateIngestionProperties	bool	Stavy, pokud se na cílovou tabulku vztahují vlastnosti zadané během příjmu dat do zdrojové tabulky, jako jsou značky rozsahu a čas vytvoření.
Spravovaná identita	string	Spravovaná identita, jejímž jménem se spouští zásady aktualizace. Spravovanou identitou může být ID objektu system nebo rezervované slovo. Pokud dotaz odkazuje na tabulky v jiných databázích nebo tabulkách s povolenými zásadami zabezpečení na úrovni řádků, musí být zásada aktualizace nakonfigurovaná se spravovanou identitou. Další informace najdete v tématu Použití spravované identity ke spuštění zásad aktualizace.

Poznámka

V produkčních systémech nastavte IsTransactional:true , abyste zajistili, že cílová tabulka nepřijde o data při přechodných selháních.

Poznámka

Kaskádové aktualizace jsou povoleny, například z tabulky A, do tabulky B, do tabulky C. Pokud jsou však zásady aktualizací definovány cyklickém způsobem, zjistí se to za běhu a řetěz aktualizací se vyříznou. Data se do každé tabulky v řetězu ingestují jenom jednou.

Příkazy pro správu

Mezi příkazy pro správu zásad aktualizace patří:

• .show table *TableName* policy update zobrazuje aktuální zásady aktualizace tabulky.
• .alter table *TableName* policy update definuje aktuální zásady aktualizace tabulky.
• .alter-merge table *TableName* policy update připojí definice k aktuálním zásadám aktualizace tabulky.
• .delete table *TableName* policy update odstraní aktuální zásady aktualizace tabulky.

Zásady aktualizace se inicializovaly po příjmu dat

Zásady aktualizací se projeví, když se data ingestují nebo přesunou do zdrojové tabulky nebo když se ve zdrojové tabulce vytvoří rozsahy pomocí některého z následujících příkazů:

• .ingest (pull)
• .ingest (vloženo)
• .set | .append | .set-or-append | .set-or-replace
• Rozsahy .move
• Rozsahy .replace
  • Příkaz se PropagateIngestionProperties projeví pouze v operacích příjmu dat. Když se zásady aktualizace aktivují jako součást .move extents příkazu nebo .replace extents , nemá tato možnost žádný vliv.

Upozornění

Při vyvolání zásady aktualizace jako součást .set-or-replace příkazu se ve výchozím nastavení nahradí data v odvozených tabulkách stejným způsobem jako ve zdrojové tabulce. Pokud replace je vyvolán příkaz, může dojít ke ztrátě dat ve všech tabulkách s relací zásad aktualizace. Zvažte místo toho použití .set-or-append .

Odebrání dat ze zdrojové tabulky

Po ingestování dat do cílové tabulky je můžete volitelně odebrat ze zdrojové tabulky. Nastavte období obnovitelného odstranění (nebo 00:00:00) v zásadách0sec uchovávání informací ve zdrojové tabulce a zásady aktualizace jako transakční. Platí následující podmínky:

• Zdrojová data se ze zdrojové tabulky nedají dotazovat.
• Zdrojová data se v rámci operace příjmu dat neuchovávají v trvalém úložišti.
• Provozní výkon se zlepšuje. Prostředky po příjmu dat jsou omezené pro operace výmazu na pozadí v rozsahech ve zdrojové tabulce.

Poznámka

Pokud má zdrojová tabulka období obnovitelného 0sec odstranění (nebo 00:00:00), musí být všechny zásady aktualizace odkazující na tuto tabulku transakční.

Dopad na výkon

Zásady aktualizací můžou ovlivnit výkon clusteru a příjem dat pro rozsahy dat se vynásobí počtem cílových tabulek. Dotaz související se zásadami je důležité optimalizovat. Dopad zásad aktualizace na výkon můžete otestovat vyvoláním zásad v již existujících rozsahech, před vytvořením nebo změnou zásady nebo pomocí funkce použité s dotazem.

Vyhodnocení využití prostředků

Pomocí nástroje .show queriespoužijte k vyhodnocení využití prostředků (procesoru, paměti atd.) s následujícími parametry:

• Source Nastavte vlastnost, název zdrojové tabulky, jakoMySourceTable
• Query Nastavení vlastnosti pro volání funkce s názvemMyFunction()

// '_extentId' is the ID of a recently created extent, that likely hasn't been merged yet.
let _extentId = toscalar(
    MySourceTable
    | project ExtentId = extent_id(), IngestionTime = ingestion_time()
    | where IngestionTime > ago(10m)
    | top 1 by IngestionTime desc
    | project ExtentId
);
// This scopes the source table to the single recent extent.
let MySourceTable =
    MySourceTable
    | where ingestion_time() > ago(10m) and extent_id() == _extentId;
// This invokes the function in the update policy (that internally references `MySourceTable`).
MyFunction

Selhání

S výchozím nastavením IsTransactional:falseje možné data stále přijímat do zdrojové tabulky, i když se zásady nespustí.

Nastavení IsTransactional:true zaručuje konzistenci mezi daty ve zdrojové a cílové tabulce. Pokud ale podmínky zásad selžou, data se do zdrojové tabulky neingestují. Případně se v závislosti na podmínkách někdy data ingestují do zdrojové tabulky, ale ne do cílové tabulky. Pokud je ale vaše zásada definovaná nesprávně nebo dojde k neshodě schématu, data se do zdrojové nebo cílové tabulky neingestují. Neshoda mezi výstupním schématem dotazu a cílovou tabulkou může být například způsobena vyřazením sloupce z cílové tabulky.

Selhání můžete zobrazit pomocí .show ingestion failures příkazu .

.show ingestion failures
| where FailedOn > ago(1hr) and OriginatesFromUpdatePolicy == true

Léčba selhání

Netransakční zásady

Pokud je tato možnost nastavená na IsTransactional:false, bude se ignorovat jakékoli selhání při spuštění zásad. Příjem dat se automaticky nezkusí znovu. Ingestování můžete zkusit ručně.

Transakční zásady

Pokud je nastavená hodnota IsTransactional:true, pokud je pullmetoda příjmu dat , je zapojena služba Správa dat a příjem dat se automaticky opakuje podle následujících podmínek:

• Opakování se provádí, dokud není splněno některé z následujících konfigurovatelných nastavení limitu: DataImporterMaximumRetryPeriod nebo DataImporterMaximumRetryAttempts
• Ve výchozím nastavení DataImporterMaximumRetryPeriod jsou dva dny a DataImporterMaximumRetryAttemptsje to 10.
• Doba záběhu začíná na 2 minuty a zdvojnásobí se. Takže čekání začíná na 2 minuty, pak se zvýší na 4 min, na 8 min, na 16 min a tak dále.

V ostatních případech můžete ingestování ručně zopakovat.

Příklad extrakce, transformace a načtení

Nastavení zásad aktualizace můžete použít k extrakci, transformaci a načítání (ETL).

V tomto příkladu použijte zásadu aktualizace s jednoduchou funkcí k provedení ETL. Nejprve vytvoříme dvě tabulky:

• Zdrojová tabulka – Obsahuje jeden sloupec typu řetězec, do kterého se ingestují data.
• Cílová tabulka – obsahuje požadované schéma. Zásady aktualizace jsou definovány v této tabulce.

1. Pojďme vytvořit zdrojovou tabulku:

   .create table MySourceTable (OriginalRecord:string)
   

2. Dále vytvořte cílovou tabulku:

   .create table MyTargetTable (Timestamp:datetime, ThreadId:int, ProcessId:int, TimeSinceStartup:timespan, Message:string)
   

3. Pak vytvořte funkci pro extrakci dat:

   .create function
    with (docstring = 'Parses raw records into strongly-typed columns', folder = 'UpdatePolicyFunctions')
        ExtractMyLogs()
       {
       MySourceTable
       | parse OriginalRecord with "[" Timestamp:datetime "] [ThreadId:" ThreadId:int "] [ProcessId:" ProcessId:int "] TimeSinceStartup: " TimeSinceStartup:timespan " Message: " Message:string
       | project-away OriginalRecord
   }
   

4. Teď nastavte zásadu aktualizace tak, aby vyvolala funkci, kterou jsme vytvořili:

   .alter table MyTargetTable policy update
   @'[{ "IsEnabled": true, "Source": "MySourceTable", "Query": "ExtractMyLogs()", "IsTransactional": true, "PropagateIngestionProperties": false}]'
   

5. Pokud chcete vyprázdnit zdrojovou tabulku po přijetí dat do cílové tabulky, definujte zásadu uchovávání informací ve zdrojové tabulce tak, aby jako její SoftDeletePeriodhodnota byla 0s.

    .alter-merge table MySourceTable policy retention softdelete = 0s
   

Související obsah

• Běžné scénáře použití zásad aktualizace tabulek
• Kurz: Směrování dat pomocí zásad aktualizace tabulek