Panoramica dei criteri di aggiornamento
I criteri di aggiornamento sono meccanismi di automazione attivati quando i nuovi dati vengono scritti in una tabella. Eliminano la necessità di orchestrazione speciale eseguendo una query per trasformare i dati inseriti e salvare il risultato in una tabella di destinazione. È possibile definire più criteri di aggiornamento in una singola tabella, consentendo trasformazioni diverse e salvare i dati in più tabelle contemporaneamente. Le tabelle di destinazione possono avere uno schema diverso, criteri di conservazione e altri criteri dalla tabella di origine.
Ad esempio, una tabella di origine di traccia ad alta frequenza può contenere dati formattati come colonna free-text. La tabella di destinazione può includere righe di traccia specifiche, con uno schema ben strutturato generato da una trasformazione dei dati free-text della tabella di origine usando l'operatore di analisi. Per altre informazioni, scenari comuni.
Il diagramma seguente illustra una visualizzazione generale di un criterio di aggiornamento. Vengono visualizzati due criteri di aggiornamento attivati quando i dati aggiunti alla seconda tabella di origine e generano l'aggiunta di dati trasformati alle due tabelle di destinazione.
Un criterio di aggiornamento è soggetto alle stesse restrizioni e alle procedure consigliate dell'inserimento regolare. I criteri vengono ridimensionati in base alle dimensioni del cluster ed è più efficiente quando si gestisce l'inserimento bulk.
Nota
- La tabella di origine e di destinazione deve trovarsi nello stesso database.
- Lo schema della funzione dei criteri di aggiornamento e lo schema della tabella di destinazione devono corrispondere ai nomi di colonna, ai tipi e all'ordine.
L'inserimento di dati formattati migliora le prestazioni e csv è preferibile a causa di un formato ben definito. A volte, tuttavia, non si ha alcun controllo sul formato dei dati oppure si desidera arricchire i dati inseriti, ad esempio aggiungendo record con una tabella di dimensioni statiche nel database.
Query sui criteri di aggiornamento
Se i criteri di aggiornamento vengono definiti nella tabella di destinazione, più query possono essere eseguite sui dati inseriti in una tabella di origine. Se sono presenti più criteri di aggiornamento, l'ordine di esecuzione non è necessariamente noto.
Limitazioni delle query
- La query correlata ai criteri può richiamare funzioni archiviate, ma:
- Non è possibile eseguire query tra cluster.
- Non può accedere a dati esterni o tabelle esterne.
- Non può effettuare callout (usando un plug-in).
- La query non dispone dell'accesso in lettura alle tabelle con i criteri RestrictedViewAccess abilitati.
- Per le limitazioni dei criteri di aggiornamento nell'inserimento in streaming, vedere Limitazioni per l'inserimento in streaming.
Avviso
Una query errata può impedire l'inserimento dei dati nella tabella di origine. È importante notare che le limitazioni, nonché la compatibilità tra i risultati della query e lo schema delle tabelle di origine e di destinazione, possono causare una query errata per impedire l'inserimento dei dati nella tabella di origine.
Queste limitazioni vengono convalidate durante la creazione e l'esecuzione dei criteri, ma non quando le funzioni archiviate arbitrarie che la query potrebbe fare riferimento vengono aggiornate. Pertanto, è fondamentale apportare modifiche con cautela per garantire che i criteri di aggiornamento rimangano intatti.
Quando si fa riferimento alla Source
Query
tabella nella parte del criterio o nelle funzioni a cui fa riferimento la Query
parte:
- Non usare il nome qualificato della tabella. Usare invece
TableName
. - Non usare
database("DatabaseName").TableName
ocluster("ClusterName").database("DatabaseName").TableName
.
Oggetto criteri di aggiornamento
Una tabella può avere zero o più oggetti criteri di aggiornamento associati. Ogni oggetto viene rappresentato come un contenitore di proprietà JSON, con le proprietà seguenti definite.
Proprietà | Type | Descrizione |
---|---|---|
IsEnabled | bool |
Stati se il criterio di aggiornamento è true - abilitato o false - disabilitato |
Source | string |
Nome della tabella che attiva la chiamata dei criteri di aggiornamento |
Query | string |
Query usata per produrre dati per l'aggiornamento |
IsTransactional | bool |
Indica se il criterio di aggiornamento è transazionale o meno, il valore predefinito è false. Se il criterio è transazionale e il criterio di aggiornamento ha esito negativo, la tabella di origine non viene aggiornata. |
PropagateIngestionProperties | bool |
Indica se le proprietà specificate durante l'inserimento nella tabella di origine, ad esempio tag extent e tempo di creazione, si applicano alla tabella di destinazione. |
ManagedIdentity | string |
Identità gestita per conto del quale viene eseguito il criterio di aggiornamento. L'identità gestita può essere un ID oggetto o la system parola riservata. I criteri di aggiornamento devono essere configurati con un'identità gestita quando la query fa riferimento alle tabelle in altri database o tabelle con criteri di sicurezza a livello di riga abilitati. Per altre informazioni, vedere Usare un'identità gestita per eseguire un criterio di aggiornamento. |
Nota
Nei sistemi di produzione impostare IsTransactional
:true per assicurarsi che la tabella di destinazione non perde i dati in errori temporanei.
Nota
Gli aggiornamenti a catena sono consentiti, ad esempio dalla tabella A alla tabella B, alla tabella C. Tuttavia, se i criteri di aggiornamento vengono definiti in modo circolare, questo viene rilevato in fase di esecuzione e la catena di aggiornamenti viene interrotta. I dati vengono inseriti una sola volta a ogni tabella della catena.
Comandi di gestione
I comandi di gestione dei criteri di aggiornamento includono:
.show table *TableName* policy update
mostra i criteri di aggiornamento correnti di una tabella..alter table *TableName* policy update
definisce i criteri di aggiornamento correnti di una tabella..alter-merge table *TableName* policy update
aggiunge le definizioni ai criteri di aggiornamento correnti di una tabella..delete table *TableName* policy update
elimina i criteri di aggiornamento correnti di una tabella.
I criteri di aggiornamento vengono avviati dopo l'inserimento
I criteri di aggiornamento hanno effetto quando i dati vengono inseriti o spostati in una tabella di origine o gli extent vengono creati in una tabella di origine usando uno dei comandi seguenti:
- Inserimento (pull)
- Ingest (inline)
- .set | .append | .set-or-append | .set-or-replace
- .move extents
- .replace extents
- Il
PropagateIngestionProperties
comando ha effetto solo nelle operazioni di inserimento. Quando il criterio di aggiornamento viene attivato come parte di un.move extents
comando o.replace extents
, questa opzione non ha alcun effetto.
- Il
Avviso
Quando il criterio di aggiornamento viene richiamato come parte di un .set-or-replace
comando, per impostazione predefinita i dati nelle tabelle derivate vengono sostituiti nello stesso modo della tabella di origine.
I dati possono essere persi in tutte le tabelle con una relazione di criteri di aggiornamento se viene richiamato il replace
comando.
In alternativa, considerare l'utilizzo di .set-or-append
.
Rimuovere i dati dalla tabella di origine
Dopo aver inseriti dati nella tabella di destinazione, è possibile rimuoverli facoltativamente dalla tabella di origine. Impostare un periodo di eliminazione temporanea di 0sec
(o 00:00:00
) nei criteri di conservazione della tabella di origine e i criteri di aggiornamento come transazionali. Si applicano le condizioni seguenti:
- I dati di origine non sono queryabili dalla tabella di origine
- I dati di origine non sono persistenti nell'archiviazione durevole come parte dell'operazione di inserimento
- Le prestazioni operative migliorano. Le risorse di post-inserimento vengono ridotte per le operazioni di pulitura in background sulle estensioni nella tabella di origine.
Nota
Quando la tabella di origine ha un periodo di eliminazione temporanea (o 00:00:00
), qualsiasi criterio di 0sec
aggiornamento che fa riferimento a questa tabella deve essere transazionale.
Impatto sulle prestazioni
I criteri di aggiornamento possono influire sulle prestazioni del cluster e l'inserimento per gli extent di dati viene moltiplicato in base al numero di tabelle di destinazione. È importante ottimizzare la query correlata ai criteri. È possibile testare l'impatto delle prestazioni di un criterio di aggiornamento richiamando i criteri su extent già esistenti, prima di creare o modificare i criteri oppure sulla funzione usata con la query.
Valutare l'utilizzo delle risorse
Usare .show queries
, per valutare l'utilizzo delle risorse (CPU, memoria e così via) con i parametri seguenti:
- Impostare la
Source
proprietà, il nome della tabella di origine, comeMySourceTable
- Impostare la
Query
proprietà per chiamare una funzione denominataMyFunction()
// '_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
Errori
Con l'impostazione predefinita di IsTransactional:
false
, i dati possono comunque essere inseriti nella tabella di origine anche se i criteri non vengono eseguiti.
L'impostazione IsTransactional:
true
garantisce la coerenza tra i dati nella tabella di origine e di destinazione. Tuttavia, se le condizioni dei criteri hanno esito negativo, i dati non vengono inseriti nella tabella di origine. In alternativa, a seconda delle condizioni, a volte i dati vengono inseriti nella tabella di origine, ma non nella tabella di destinazione. Tuttavia, se il criterio è definito in modo non corretto o si verifica una mancata corrispondenza dello schema, i dati non vengono inseriti nella tabella di origine o di destinazione. Ad esempio, una mancata corrispondenza tra lo schema di output della query e la tabella di destinazione potrebbe essere causata dall'eliminazione di una colonna dalla tabella di destinazione.
È possibile visualizzare gli errori usando il .show ingestion failures
comando .
.show ingestion failures
| where FailedOn > ago(1hr) and OriginatesFromUpdatePolicy == true
Trattamento degli errori
Criteri non transazionali
Se impostato su IsTransactional:
false
, qualsiasi errore di esecuzione del criterio viene ignorato. L'inserimento non viene ritentato automaticamente. È possibile ripetere manualmente l'inserimento.
Criteri transazionali
Se impostato su IsTransactional:
true
, se il metodo di inserimento è pull
, il servizio Gestione dati è coinvolto e l'inserimento viene eseguito automaticamente in base alle condizioni seguenti:
- I tentativi vengono eseguiti fino a quando non viene soddisfatta una delle impostazioni di limite configurabili seguenti:
DataImporterMaximumRetryPeriod
oDataImporterMaximumRetryAttempts
- Per impostazione predefinita, l'impostazione
DataImporterMaximumRetryPeriod
è due giorni eDataImporterMaximumRetryAttempts
è 10 - Il periodo di backoff inizia a 2 minuti e raddoppia. Quindi l'attesa inizia con 2 minuti, quindi aumenta a 4 min, a 8 min, a 16 minuti e così via.
In qualsiasi altro caso, è possibile ripetere manualmente l'inserimento.
Esempio di estrazione, trasformazione, caricamento
È possibile usare le impostazioni dei criteri di aggiornamento per eseguire estrazione, trasformazione, caricamento (ETL).
In questo esempio usare un criterio di aggiornamento con una funzione semplice per eseguire ETL. Prima di tutto, vengono create due tabelle:
- Tabella di origine: contiene una singola colonna tipizzata di stringa in cui vengono inseriti i dati.
- Tabella di destinazione: contiene lo schema desiderato. I criteri di aggiornamento sono definiti in questa tabella.
Creare la tabella di origine:
.create table MySourceTable (OriginalRecord:string)
Creare quindi la tabella di destinazione:
.create table MyTargetTable (Timestamp:datetime, ThreadId:int, ProcessId:int, TimeSinceStartup:timespan, Message:string)
Creare quindi una funzione per estrarre i dati:
.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 }
Impostare ora i criteri di aggiornamento per richiamare la funzione creata:
.alter table MyTargetTable policy update @'[{ "IsEnabled": true, "Source": "MySourceTable", "Query": "ExtractMyLogs()", "IsTransactional": true, "PropagateIngestionProperties": false}]'
Per svuotare la tabella di origine dopo l'inserimento dei dati nella tabella di destinazione, definire i criteri di conservazione nella tabella di origine in modo da avere 0 come .
SoftDeletePeriod
.alter-merge table MySourceTable policy retention softdelete = 0s
Contenuti correlati
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedereInvia e visualizza il feedback per