Översikt över uppdateringsprincip

Gäller för: ✅Microsoft Fabric✅Azure Data Explorer

Uppdateringsprinciper utlöses när nya data skrivs till en tabell. De eliminerar behovet av särskild orkestrering genom att köra en fråga för att transformera inmatade data och spara resultatet i en måltabell. Flera uppdateringsprinciper kan definieras i en enda tabell, vilket möjliggör olika transformeringar och sparar data till flera tabeller samtidigt. Måltabellerna kan ha ett annat schema, en kvarhållningsprincip och andra principer från källtabellen.

En källtabell med hög hastighet kan till exempel innehålla data som är formaterade som en fritextkolumn. Måltabellen kan innehålla specifika spårningslinjer, med ett välstrukturerat schema som genereras från en omvandling av källtabellens fritextdata med operatorn parsning. Mer information finns i vanliga scenarier.

Följande diagram visar en övergripande vy över en uppdateringsprincip. Den visar två uppdateringsprinciper som utlöses när data läggs till i den andra källtabellen. När de har utlösts läggs transformerade data till i de två måltabellerna.

En uppdateringsprincip omfattas av samma begränsningar och metodtips som vanlig inmatning. Principen skalas ut enligt Eventhouse-storleken och är effektivare vid hantering av massinmatning.

Not

• Käll- och måltabellen måste finnas i samma databas.
• Funktionsschemat för uppdateringsprincipen och måltabellschemat måste matcha deras kolumnnamn, typer och ordning.
• Funktionen uppdateringsprincip kan referera till tabeller i andra databaser. För att göra detta måste uppdateringsprincipen definieras med en ManagedIdentity-egenskap, och den hanterade identiteten måste ha viewerroll på de refererade databaserna. Inmatning av formaterade data förbättrar prestanda och CSV är att föredra på grund av att det är ett väldefinierat format. Ibland har du dock ingen kontroll över dataformatet, eller så vill du utöka inmatade data, till exempel genom att koppla poster med en statisk dimensionstabell i databasen.

Uppdatera principfråga

Om uppdateringsprincipen har definierats i måltabellen kan flera frågor köras på data som matas in i en källtabell. Om det finns flera uppdateringsprinciper är körningsordningen inte nödvändigtvis känd.

Frågebegränsningar

• Den principrelaterade frågan kan anropa lagrade funktioner, men:
  • Det går inte att köra frågor mellan eventhouse.it.it can't perform cross-eventhouse queries.
  • Den kan inte komma åt externa data eller externa tabeller.
  • Det går inte att göra pratbubblar (med hjälp av ett plugin-program).
• Frågan har inte läsbehörighet till tabeller som har RestrictedViewAccess-principen aktiverad.
• Som standard är inmatningsprincipen streaming aktiverad för alla tabeller i Eventhouse. Om du vill använda funktioner med join-operatorn i en uppdateringsprincip måste inmatningsprincipen för direktuppspelning inaktiveras. Använd kommandot .altertableTableNamepolicystreamingingestionPolicyObject för att inaktivera det.

Varning

En felaktig fråga kan förhindra datainmatning i källtabellen. Det är viktigt att observera att begränsningar, liksom kompatibiliteten mellan frågeresultaten och schemat för käll- och måltabellerna, kan orsaka en felaktig fråga för att förhindra datainmatning i källtabellen.

Dessa begränsningar verifieras när principen skapas och körs, men inte när godtyckliga lagrade funktioner som frågan kan referera till uppdateras. Därför är det viktigt att göra ändringar med försiktighet för att säkerställa att uppdateringsprincipen förblir intakt.

När du refererar till tabellen Source i Query delen av principen, eller i funktioner som refereras av Query delen:

• Använd inte tabellens kvalificerade namn. Använd i stället TableName.
• Använd inte database("<DatabaseName>").TableName eller cluster("<EventhouseName>").database("<DatabaseName>").TableName.

Uppdateringsprincipobjektet

En tabell kan ha noll eller flera associerade uppdateringsprincipobjekt. Varje sådant objekt representeras som en JSON-egenskapsväska med följande egenskaper definierade.

Egenskap	Typ	Beskrivning
IsEnabled	bool	Tillstånd om uppdateringsprincipen är true – aktiverad eller falskt – inaktiverad
Källa	string	Namnet på tabellen som utlöser anrop av uppdateringsprincipen
Fråga	string	En fråga som används för att skapa data för uppdateringen
IsTransactional	bool	Tillstånd om uppdateringsprincipen är transaktionell eller inte är standard falskt. Om principen är transaktionell och uppdateringsprincipen misslyckas uppdateras inte källtabellen.
SpridaIngestionEgenskaper	bool	Tillstånd om egenskaper som anges under inmatningen till källtabellen, till exempel utsträckningstaggar och skapandetid, gäller för måltabellen.
Hanterad identitet	string	Den hanterade identitet för vilken uppdateringsprincipen körs. Den hanterade identiteten kan vara ett objekt-ID eller det system reserverade ordet. Uppdateringsprincipen måste konfigureras med en hanterad identitet när frågan refererar till tabeller i andra databaser eller tabeller med en aktiverad säkerhetsprincip på radnivå. Mer information finns i Använda en hanterad identitet för att köra en uppdateringsprincip.

Not

I produktionssystem anger du IsTransactional:sant för att säkerställa att måltabellen inte förlorar data i tillfälliga fel.

Not

Sammanhängande uppdateringar tillåts, till exempel från tabell A till tabell B, till tabell C. Men om uppdateringsprinciper definieras på ett cirkulärt sätt identifieras detta vid körning och uppdateringskedjan klipps ut. Data matas bara in en gång till varje tabell i kedjan.

Hanteringskommandon

Uppdateringsprinciphanteringskommandon omfattar:

• .show table *TableName* policy update visar den aktuella uppdateringsprincipen för en tabell.
• .alter table *TableName* policy update definierar den aktuella uppdateringsprincipen för en tabell.
• .alter-merge table *TableName* policy update lägger till definitioner i den aktuella uppdateringsprincipen i en tabell.
• .delete table *TableName* policy update tar bort den aktuella uppdateringsprincipen för en tabell.

Uppdateringsprincip initieras efter inmatning

Uppdateringsprinciper börjar gälla när data matas in eller flyttas till en källtabell eller omfång skapas i en källtabell. Dessa åtgärder kan utföras med något av följande kommandon:

• .ingest (pull)
• .ingest (infogad)
• .set | .append | .set-or-append | .set-or-replace
• .move-omfattningar
• .replace-omfattningar
  • Kommandot PropagateIngestionProperties börjar bara gälla vid inmatningsåtgärder. När uppdateringsprincipen utlöses som en del av ett .move extents- eller .replace extents-kommando har det här alternativet ingen effekt.

Varning

När uppdateringsprincipen anropas som en del av ett .set-or-replace kommando ersätts som standard data i härledda tabeller på samma sätt som i källtabellen. Data kan gå förlorade i alla tabeller med en uppdateringsprinciprelation om kommandot replace anropas. Överväg att använda .set-or-append i stället.

Ta bort data från källtabellen

När du har matat in data till måltabellen kan du ta bort dem från källtabellen. Ange en period för mjuk borttagning av 0sec (eller 00:00:00) i källtabellens kvarhållningsprincipoch uppdateringsprincipen som transaktionell. Följande villkor gäller:

• Källdata kan inte frågas från källtabellen
• Källdata sparas inte i beständig lagring som en del av inmatningsåtgärden
• Driftprestandan förbättras. Resurser efter inmatning minskas för bakgrundsrensningsåtgärder i omfattningar i källtabellen.

Not

När källtabellen har en mjuk borttagningsperiod på 0sec (eller 00:00:00) måste alla uppdateringsprinciper som refererar till den här tabellen vara transaktionella.

Prestandapåverkan

Uppdateringsprinciper kan påverka prestanda och inmatning för datautbredningar multipliceras med antalet måltabeller. Det är viktigt att optimera den principrelaterade frågan. Du kan testa prestandapåverkan för en uppdateringsprincip genom att anropa principen i redan befintliga omfattningar, innan du skapar eller ändrar principen eller på den funktion som används med frågan.

Utvärdera resursanvändning

Använd .show queriesför att utvärdera resursanvändning (CPU, minne och så vidare) med följande parametrar:

• Ange egenskapen Source, källtabellens namn, som MySourceTable
• Ange egenskapen Query för att anropa en funktion med namnet MyFunction()

// '_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

Transaktionsinställningar

Inställningen uppdateringsprincip IsTransactional definierar om uppdateringsprincipen är transaktionell och kan påverka beteendet för principuppdateringen enligt följande:

• IsTransactional:false: Om värdet är inställt på standardvärdet falsegaranterar uppdateringsprincipen inte konsekvens mellan data i käll- och måltabellen. Om en uppdateringsprincip misslyckas matas data endast in till källtabellen och inte till måltabellen. I det här scenariot lyckas inmatningsåtgärden.
• IsTransactional:true: Om värdet är inställt på santgaranterar inställningen konsekvens mellan data i käll- och måltabellerna. Om en uppdateringsprincip misslyckas matas inte data in till käll- eller måltabellen. I det här scenariot misslyckas inmatningsåtgärden.

Hantera fel

När principuppdateringar misslyckas hanteras de på olika sätt beroende på om inställningen IsTransactional är true eller false. Vanliga orsaker till fel med uppdateringsprinciper är:

• Ett matchningsfel mellan frågeutdataschemat och måltabellen.
• Eventuella frågefel.

Du kan visa principuppdateringsfel med hjälp av kommandot .show ingestion failures med följande kommando: I andra fall kan du försöka mata in igen manuellt.

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

Exempel på extrahering, transformering, inläsning

Du kan använda uppdateringsprincipinställningar för att utföra extrahering, transformering, inläsning (ETL).

I det här exemplet använder du en uppdateringsprincip med en enkel funktion för att utföra ETL. Först skapar vi två tabeller:

• Källtabellen – innehåller en enda strängtypad kolumn som data matas in i.
• Måltabellen – innehåller önskat schema. Uppdateringsprincipen definieras i den här tabellen.

1. Nu ska vi skapa källtabellen:

   .create table MySourceTable (OriginalRecord:string)
   

2. Skapa sedan måltabellen:

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

3. Skapa sedan en funktion för att extrahera data:

   .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. Ange nu uppdateringsprincipen för att anropa funktionen som vi skapade:

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

5. Om du vill tömma källtabellen när data har matats in i måltabellen definierar du kvarhållningsprincipen i källtabellen så att den har 0:ar som SoftDeletePeriod.

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

Relaterat innehåll

• Vanliga scenarier för användning av tabelluppdateringsprinciper
• Självstudie: Dirigera data med hjälp av tabelluppdateringsprinciper