Overzicht van updatebeleid
Van toepassing op: ✅Microsoft Fabric✅Azure Data Explorer-
Updatebeleid is automatiseringsmechanismen die worden geactiveerd wanneer nieuwe gegevens naar een tabel worden geschreven. Ze elimineren de noodzaak van speciale indeling door een query uit te voeren om de opgenomen gegevens te transformeren en het resultaat op te slaan in een doeltabel. Er kunnen meerdere updatebeleidsregels worden gedefinieerd in één tabel, waardoor verschillende transformaties mogelijk zijn en gegevens tegelijkertijd in meerdere tabellen kunnen worden opgeslagen. De doeltabellen kunnen een ander schema, bewaarbeleid en ander beleid uit de brontabel hebben.
Een brontabel met een hoge snelheid kan bijvoorbeeld gegevens bevatten die zijn opgemaakt als een kolom met vrije tekst. De doeltabel kan specifieke traceringslijnen bevatten, met een goed gestructureerd schema dat is gegenereerd op basis van een transformatie van de vrije-tekstgegevens van de brontabel met behulp van de parseringsoperator. algemene scenario'svoor meer informatie.
In het volgende diagram ziet u een weergave op hoog niveau van een updatebeleid. Er worden twee updatebeleidsregels weergegeven die worden geactiveerd wanneer gegevens worden toegevoegd aan de tweede brontabel. Zodra ze zijn geactiveerd, worden getransformeerde gegevens toegevoegd aan de twee doeltabellen.
Een updatebeleid is onderhevig aan dezelfde beperkingen en best practices als normale opname. Het beleid wordt uitgeschaald op basis van de clustergrootte en is efficiënter bij het verwerken van bulkopname.
Een updatebeleid is onderhevig aan dezelfde beperkingen en best practices als normale opname. Het beleid wordt uitgeschaald op basis van de grootte van Eventhouse en is efficiënter bij het verwerken van bulkopname.
Notitie
- De bron- en doeltabel moeten zich in dezelfde database bevinden.
- Het schema van de beleidsfunctie bijwerken en het schema van de doeltabel moeten overeenkomen met de kolomnamen, typen en volgorde.
- De functie updatebeleid kan verwijzen naar tabellen in andere databases. Hiervoor moet het updatebeleid worden gedefinieerd met een eigenschap
ManagedIdentity
en moet de beheerde identiteitviewer
rol hebben voor de databases waarnaar wordt verwezen. Het opnemen van opgemaakte gegevens verbetert de prestaties en csv heeft de voorkeur vanwege een goed gedefinieerde indeling. Soms hebt u echter geen controle over de indeling van de gegevens of wilt u opgenomen gegevens verrijken, bijvoorbeeld door records samen te voegen met een statische dimensietabel in uw database.
Beleidsquery bijwerken
Als het updatebeleid is gedefinieerd in de doeltabel, kunnen meerdere query's worden uitgevoerd op gegevens die zijn opgenomen in een brontabel. Als er meerdere updatebeleidsregels zijn, is de uitvoeringsvolgorde niet noodzakelijkerwijs bekend.
Querybeperkingen
- De beleidsgerelateerde query kan opgeslagen functies aanroepen, maar:
- Er kunnen geen query's tussen clusters worden uitgevoerd.
- Er is geen toegang tot externe gegevens of externe tabellen.
- Het kan geen bijschriften maken (met behulp van een invoegtoepassing).
- De query heeft geen leestoegang tot tabellen waarvoor het RestrictedViewAccess-beleid is ingeschakeld ingeschakeld.
- Zie beperkingen voor streamingopname voor updatebeleidsbeperkingen.
- De beleidsgerelateerde query kan opgeslagen functies aanroepen, maar:
- Er kunnen geen cross-eventhouse-query's worden uitgevoerd.
- Er is geen toegang tot externe gegevens of externe tabellen.
- Het kan geen bijschriften maken (met behulp van een invoegtoepassing).
- De query heeft geen leestoegang tot tabellen waarvoor het RestrictedViewAccess-beleid is ingeschakeld ingeschakeld.
- Standaard is het Streaming-opnamebeleid is ingeschakeld voor alle tabellen in Eventhouse. Als u functies wilt gebruiken met de
join
-operator in een updatebeleid, moet het beleid voor streamingopname zijn uitgeschakeld. Gebruik de opdracht.alter
table
TableNamepolicy
streamingingestion
PolicyObject om het uit te schakelen.
Waarschuwing
Een onjuiste query kan gegevensopname in de brontabel voorkomen. Het is belangrijk om te weten dat beperkingen, evenals de compatibiliteit tussen de queryresultaten en het schema van de bron- en doeltabellen, een onjuiste query kan veroorzaken om gegevensopname in de brontabel te voorkomen.
Deze beperkingen worden gevalideerd tijdens het maken en uitvoeren van het beleid, maar niet wanneer willekeurige opgeslagen functies waarnaar de query kan verwijzen, worden bijgewerkt. Daarom is het van cruciaal belang om wijzigingen aan te brengen met voorzichtigheid om ervoor te zorgen dat het updatebeleid intact blijft.
Wanneer u verwijst naar de Source
tabel in het Query
deel van het beleid of in functies waarnaar wordt verwezen door het Query
gedeelte:
- Gebruik de gekwalificeerde naam van de tabel niet. Gebruik in plaats daarvan
TableName
. - Gebruik geen
database("<DatabaseName>").TableName
ofcluster("<ClusterName>").database("<DatabaseName>").TableName
.
- Gebruik de gekwalificeerde naam van de tabel niet. Gebruik in plaats daarvan
TableName
. - Gebruik geen
database("<DatabaseName>").TableName
ofcluster("<EventhouseName>").database("<DatabaseName>").TableName
.
Het updatebeleidsobject
Aan een tabel kunnen nul of meer updatebeleidsobjecten zijn gekoppeld. Elk dergelijk object wordt weergegeven als een JSON-eigenschappenverzameling, waarbij de volgende eigenschappen zijn gedefinieerd.
Eigenschap | Type | Beschrijving |
---|---|---|
IsEnabled | bool |
Statussen als updatebeleid is waar - ingeschakeld of onwaar - uitgeschakeld |
Bron | string |
Naam van de tabel die aanroep van het updatebeleid activeert |
Vraag | string |
Een query die wordt gebruikt voor het produceren van gegevens voor de update |
IsTransactional | bool |
Geeft aan of het updatebeleid transactioneel is of niet, de standaardwaarde is onwaar. Als het beleid transactioneel is en het updatebeleid mislukt, wordt de brontabel niet bijgewerkt. |
PropagateIngestionProperties | bool |
Geeft aan of eigenschappen die zijn opgegeven tijdens de opname in de brontabel, zoals omvangstags en aanmaaktijd, van toepassing op de doeltabel. |
ManagedIdentity | string |
De beheerde identiteit namens wie het updatebeleid wordt uitgevoerd. De beheerde identiteit kan een object-id of het system gereserveerde woord zijn. Het updatebeleid moet worden geconfigureerd met een beheerde identiteit wanneer de query verwijst naar tabellen in andere databases of tabellen met een ingeschakeld beveiligingsbeleid op rijniveau. Zie Een beheerde identiteit gebruiken om een updatebeleid uit te voerenvoor meer informatie. |
Notitie
Stel in productiesystemen IsTransactional
in:waar om ervoor te zorgen dat de doeltabel geen gegevens verliest in tijdelijke storingen.
Notitie
Trapsgewijze updates zijn toegestaan, bijvoorbeeld van tabel A, naar tabel B, naar tabel C. Als updatebeleidsregels echter op een kringvormige manier worden gedefinieerd, wordt dit tijdens runtime gedetecteerd en wordt de keten van updates geknipt. Gegevens worden slechts eenmaal opgenomen in elke tabel in de keten.
Beheeropdrachten
Opdrachten voor beleidsbeheer bijwerken zijn onder andere:
-
.show table *TableName* policy update
geeft het huidige updatebeleid van een tabel weer. -
.alter table *TableName* policy update
definieert het huidige updatebeleid van een tabel. -
.alter-merge table *TableName* policy update
definities toevoegt aan het huidige updatebeleid van een tabel. -
.delete table *TableName* policy update
verwijdert het huidige updatebeleid van een tabel.
Updatebeleid wordt gestart na opname
Updatebeleid wordt van kracht wanneer gegevens worden opgenomen of verplaatst naar een brontabel, of gebieden worden gemaakt in een brontabel. Deze acties kunnen worden uitgevoerd met behulp van een van de volgende opdrachten:
- .ingest (pull)-
- .ingest (inline)
- .set | .append | .set-or-append | .set-or-replace
- .move extents
-
.replace extents
- De opdracht
PropagateIngestionProperties
wordt alleen van kracht in opnamebewerkingen. Wanneer het updatebeleid wordt geactiveerd als onderdeel van een opdracht.move extents
of.replace extents
, heeft deze optie geen effect.
- De opdracht
Waarschuwing
Wanneer het updatebeleid wordt aangeroepen als onderdeel van een .set-or-replace
opdracht, worden gegevens in afgeleide tabellen standaard op dezelfde manier vervangen als in de brontabel.
Gegevens kunnen verloren gaan in alle tabellen met een updatebeleidsrelatie als de opdracht replace
wordt aangeroepen.
Overweeg in plaats daarvan .set-or-append
te gebruiken.
Gegevens uit de brontabel verwijderen
Nadat u gegevens hebt opgenomen in de doeltabel, kunt u deze desgewenst verwijderen uit de brontabel. Stel een periode voor voorlopig verwijderen in van 0sec
(of 00:00:00
) in het bewaarbeleid van de brontabelen het updatebeleid als transactioneel. De volgende voorwaarden zijn van toepassing:
- De brongegevens kunnen niet worden opgeslagen in de brontabel
- De brongegevens blijven niet behouden in duurzame opslag als onderdeel van de opnamebewerking
- Operationele prestaties worden verbeterd. Resources na opname worden verminderd voor bewerkingen op de achtergrond voor gebieden in de brontabel.
Notitie
Wanneer de brontabel een periode voor voorlopig verwijderen van 0sec
(of 00:00:00
) heeft, moet elk updatebeleid dat naar deze tabel verwijst, transactioneel zijn.
Invloed op de prestaties
Updatebeleid kan van invloed zijn op de prestaties en opname voor gegevensverspreiding wordt vermenigvuldigd met het aantal doeltabellen. Het is belangrijk om de beleidsgerelateerde query te optimaliseren. U kunt de invloed van het updatebeleid op de prestaties testen door het beleid aan te roepen voor al bestaande gebieden, voordat u het beleid maakt of wijzigt, of door de functie die met de query wordt gebruikt.
Resourcegebruik evalueren
Gebruik .show queries
om het resourcegebruik (CPU, geheugen enzovoort) te evalueren met de volgende parameters:
- Stel de eigenschap
Source
, de naam van de brontabel, in alsMySourceTable
- Stel de eigenschap
Query
in om een functie met de naamMyFunction()
aan te roepen
// '_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
Transactionele instellingen
Met het updatebeleid IsTransactional
instelling wordt gedefinieerd of het updatebeleid transactioneel is en het gedrag van de beleidsupdate als volgt kan beïnvloeden:
-
IsTransactional:false
: als de waarde is ingesteld op de standaardwaarde, onwaar, garandeert het updatebeleid geen consistentie tussen gegevens in de bron- en doeltabel. Als een updatebeleid mislukt, worden gegevens alleen opgenomen in de brontabel en niet in de doeltabel. In dit scenario is de opnamebewerking geslaagd. -
IsTransactional:true
: als de waarde is ingesteld op true, garandeert de instelling consistentie tussen gegevens in de bron- en doeltabellen. Als een updatebeleid mislukt, worden gegevens niet opgenomen in de bron- of doeltabel. In dit scenario is de opnamebewerking mislukt.
Fouten afhandelen
Wanneer beleidsupdates mislukken, worden ze anders verwerkt op basis van of de IsTransactional
-instelling is true
of false
. Veelvoorkomende redenen voor updatebeleidsfouten zijn:
- Een onjuiste overeenkomst tussen het queryuitvoerschema en de doeltabel.
- Elke queryfout.
U kunt mislukte beleidsupdates weergeven met behulp van de opdracht .show ingestion failures
met de volgende opdracht: In elk ander geval kunt u handmatig opnieuw proberen opname uit te voeren.
.show ingestion failures
| where FailedOn > ago(1hr) and OriginatesFromUpdatePolicy == true
Voorbeeld van extraheren, transformeren, laden
U kunt beleidsinstellingen bijwerken gebruiken om ETL (extract, transform, load) uit te voeren.
In dit voorbeeld gebruikt u een updatebeleid met een eenvoudige functie om ETL uit te voeren. Eerst maken we twee tabellen:
- De brontabel: bevat één kolom met tekenreekstypen waarin gegevens worden opgenomen.
- De doeltabel - Bevat het gewenste schema. Het updatebeleid is gedefinieerd in deze tabel.
We gaan de brontabel maken:
.create table MySourceTable (OriginalRecord:string)
Maak vervolgens de doeltabel:
.create table MyTargetTable (Timestamp:datetime, ThreadId:int, ProcessId:int, TimeSinceStartup:timespan, Message:string)
Maak vervolgens een functie om gegevens te extraheren:
.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 }
Stel nu het updatebeleid in om de functie aan te roepen die we hebben gemaakt:
.alter table MyTargetTable policy update @'[{ "IsEnabled": true, "Source": "MySourceTable", "Query": "ExtractMyLogs()", "IsTransactional": true, "PropagateIngestionProperties": false}]'
Als u de brontabel wilt leegmaken nadat gegevens zijn opgenomen in de doeltabel, definieert u het bewaarbeleid voor de brontabel om 0s te hebben als
SoftDeletePeriod
..alter-merge table MySourceTable policy retention softdelete = 0s