Condividi tramite

Panoramica dell'esportazione continua dei dati

  • Articolo

Si applica a: ✅Microsoft Fabric✅Azure Esplora dati

Questo articolo descrive l'esportazione continua dei dati da Kusto in una tabella esterna con una query eseguita periodicamente. I risultati vengono archiviati nella tabella esterna, che definisce la destinazione, ad esempio Archiviazione BLOB di Azure e lo schema dei dati esportati. Questo processo garantisce che tutti i record vengano esportati "esattamente una volta", con alcune eccezioni.

Per impostazione predefinita, l'esportazione continua viene eseguita in modalità distribuita, in cui tutti i nodi esportano simultaneamente, quindi il numero di elementi dipende dal numero di nodi. L'esportazione continua non è progettata per i dati di streaming a bassa latenza.

Per abilitare l'esportazione continua dei dati, creare una tabella esterna e quindi creare una definizione di esportazione continua che punta alla tabella esterna.

In alcuni casi, è necessario usare un'identità gestita per configurare correttamente un processo di esportazione continua. Per altre informazioni, vedere Usare un'identità gestita per eseguire un processo di esportazione continua.

Autorizzazioni

Tutti i comandi di esportazione continua richiedono almeno le autorizzazioni di amministratore del database.

Linee guida per l'esportazione continua

  • Schema di output:

    • Lo schema di output della query di esportazione deve corrispondere allo schema della tabella esterna a cui si esporta.

  • Frequenza:

    • L'esportazione continua viene eseguita in base al periodo di tempo configurato nella intervalBetweenRuns proprietà . Il valore consigliato per questo intervallo è di almeno alcuni minuti, a seconda delle latenze che si è disposti ad accettare. L'intervallo di tempo può essere inferiore a un minuto, se la velocità di inserimento è elevata.

      Nota

      Funge intervalBetweenRuns solo da raccomandazione e non è garantito che sia preciso. L'esportazione continua non è adatta per l'esportazione di aggregazioni periodiche. Ad esempio, una configurazione di intervalBetweenRuns=1h con un'aggregazione oraria (T | summarize by bin(Timestamp, 1h)) non funzionerà come previsto, perché l'esportazione continua non verrà eseguita esattamente all'ora. Pertanto, ogni contenitore orario riceverà più voci nei dati esportati.

  • Numero di file:

    • Il numero di file esportati in ogni iterazione di esportazione continua dipende dalla modalità di partizionamento della tabella esterna. Per altre informazioni, vedere esportare in un comando di tabella esterna. Ogni iterazione di esportazione continua scrive sempre in nuovi file e non aggiunge mai a quelli esistenti. Di conseguenza, il numero di file esportati dipende anche dalla frequenza di esecuzione dell'esportazione continua. Il parametro frequency è intervalBetweenRuns.

  • Account di archiviazione tabelle esterne:

    • Per ottenere prestazioni ottimali, il database e gli account di archiviazione devono essere raggruppati nella stessa area di Azure.
    • L'esportazione continua funziona in modo distribuito, in modo che tutti i nodi esesportino simultaneamente. Nei database di grandi dimensioni e, se il volume di dati esportato è di grandi dimensioni, ciò potrebbe causare la limitazione delle risorse di archiviazione. È consigliabile configurare più account di archiviazione per la tabella esterna. Per altre informazioni, vedere errori di archiviazione durante i comandi di esportazione.

Esattamente una volta esportata

Per garantire l'esportazione "esattamente una volta", l'esportazione continua usa cursori di database. La query di esportazione continua non deve includere un filtro timestamp. Il meccanismo dei cursori del database garantisce che i record non vengano elaborati più volte. L'aggiunta di un filtro timestamp nella query può causare dati mancanti nei dati esportati.

I criteri IngestionTime devono essere abilitati in tutte le tabelle a cui si fa riferimento nella query che devono essere elaborati "esattamente una volta" nell'esportazione. Il criterio è abilitato per impostazione predefinita in tutte le tabelle appena create.

La garanzia per l'esportazione "esattamente una volta" è solo per i file segnalati nel comando Mostra artefatti esportati. L'esportazione continua non garantisce che ogni record venga scritto una sola volta nella tabella esterna. Se si verifica un errore dopo l'inizio dell'esportazione e alcuni artefatti sono già stati scritti nella tabella esterna, la tabella esterna potrebbe contenere duplicati. Se un'operazione di scrittura è stata interrotta prima del completamento, la tabella esterna potrebbe contenere file danneggiati. In questi casi, gli artefatti non vengono eliminati dalla tabella esterna, ma non vengono segnalati nella visualizzare il comando degli artefatti esportati. L'utilizzo dei file esportati tramite garantisce show exported artifacts command nessuna duplicazione e nessun danneggiamento.

Esportare da tabelle dei fatti e delle dimensioni

Per impostazione predefinita, si presuppone che tutte le tabelle a cui viene fatto riferimento nella query di esportazione siano tabelle dei fatti. Di conseguenza, hanno come ambito il cursore del database. La sintassi dichiara in modo esplicito le tabelle con ambito (fatto) e non con ambito (dimensione). Per informazioni dettagliate, vedere il overparametro nel comando create.

La query di esportazione include solo i record aggiunti dopo l'esecuzione dell'esportazione precedente. La query di esportazione può contenere tabelle delle dimensioni in cui tutti i record della tabella delle dimensioni sono inclusi in tutte le query di esportazione. Quando si usano join tra tabelle dei fatti e delle dimensioni nell'esportazione continua, tenere presente che i record nella tabella dei fatti vengono elaborati una sola volta. Se l'esportazione viene eseguita mentre mancano record nelle tabelle delle dimensioni per alcune chiavi, i record per le rispettive chiavi non vengono eseguiti o includono valori Null per le colonne della dimensione nei file esportati. La restituzione di record mancanti o Null dipende dal fatto che la query usi inner o outer join. La forcedLatency proprietà nella definizione di esportazione continua può essere utile in tali casi, in cui le tabelle dei fatti e delle dimensioni vengono inserite contemporaneamente per i record corrispondenti.

Nota

L'esportazione continua delle sole tabelle delle dimensioni non è supportata. La query di esportazione deve includere almeno una singola tabella dei fatti.

Monitorare l'esportazione continua

Monitorare l'integrità dei processi di esportazione continua usando le metriche di esportazione seguenti:

  • Continuous export max lateness - Ritardo massimo (in minuti) delle esportazioni continue nel database. Questo è il tempo tra ora e il tempo minimo ExportedTo di tutti i processi di esportazione continua nel database. Per altre informazioni, vedere .show continuous export comando.
  • Continuous export result - Esito positivo/negativo di ogni esecuzione di esportazione continua. Questa metrica può essere suddivisa in base al nome dell'esportazione continua.

Usare il .show continuous export failures comando per visualizzare gli errori specifici di un processo di esportazione continua.

Avviso

Se un'esportazione continua ha esito negativo per oltre 7 giorni a causa di un errore permanente, l'esportazione verrà disabilitata automaticamente dal sistema. Gli errori permanenti includono: tabella esterna non trovata, mancata corrispondenza tra lo schema di query di esportazione continua e schema di tabella esterna, l'account di archiviazione non è accessibile. Dopo aver risolto l'errore, è possibile riabilitare l'esportazione continua usando il .enable continuous export comando .

Utilizzo di risorse

  • L'impatto dell'esportazione continua sul database dipende dalla query in cui è in esecuzione l'esportazione continua. La maggior parte delle risorse, ad esempio CPU e memoria, viene utilizzata dall'esecuzione della query.
  • Il numero di operazioni di esportazione che possono essere eseguite contemporaneamente è limitato dalla capacità di esportazione dei dati del database. Per altre informazioni, vedere Limitazione dei comandi di gestione. Se il database non dispone di capacità sufficiente per gestire tutte le esportazioni continue, alcuni iniziano a ritardare.
  • Il comando show commands-and-queries può essere usato per stimare l'utilizzo delle risorse.
    • Filtrare per | where ClientActivityId startswith "RunContinuousExports" visualizzare i comandi e le query associati all'esportazione continua.

Esportare dati storici

L'esportazione continua avvia l'esportazione dei dati solo dal punto di creazione. I record inseriti prima di tale ora devono essere esportati separatamente usando il comando di esportazione non continua. I dati cronologici potrebbero essere troppo grandi da esportare in un singolo comando di esportazione. Se necessario, partizionare la query in diversi batch più piccoli.

Per evitare duplicati con i dati esportati dall'esportazione continua, utilizzare StartCursor restituiti dal comando show continuous export ed esportare solo i record where cursor_before_or_at del valore del cursore. Ad esempio:

.show continuous-export MyExport | project StartCursor
StartCursor
636751928823156645

Seguito da:

.export async to table ExternalBlob
<| T | where cursor_before_or_at("636751928823156645")

Esportazione continua da una tabella con sicurezza a livello di riga

Per creare un processo di esportazione continua con una query che fa riferimento a una tabella con i criteri di sicurezza a livello di riga, è necessario:

Esportazione continua in tabella differenziale - Anteprima

L'esportazione continua in una tabella delta è attualmente in anteprima.

Importante

Il partizionamento delle tabelle delta non è supportato nell'esportazione continua dei dati.

Kusto non scriverà nelle tabelle delta esistenti se la versione del writer del protocollo delta è superiore a 1.

Per definire l'esportazione continua in una tabella delta, seguire questa procedura:

  1. Creare una tabella delta esterna, come descritto in Creare e modificare tabelle esterne delta in Archiviazione di Azure.

    Nota

    Se lo schema non viene fornito, Kusto proverà a dedurrlo automaticamente se è già presente una tabella delta definita nel contenitore di archiviazione di destinazione.
    Il partizionamento delle tabelle delta non è supportato.

  2. Definire l'esportazione continua in questa tabella usando i comandi descritti in Creare o modificare l'esportazione continua.

    Importante

    Lo schema della tabella delta deve essere sincronizzato con la query di esportazione continua. Se la tabella differenziale sottostante cambia, l'esportazione potrebbe non riuscire con un comportamento imprevisto.

Limiti

General (Generale):

  • Nelle tabelle di destinazione sono consentiti i formati seguenti: CSV, TSV, JSONe Parquet.
  • L'esportazione continua non è progettata per funzionare su viste materializzate, perché una vista materializzata potrebbe essere aggiornata, mentre i dati esportati nell'archiviazione vengono sempre accodati e mai aggiornati.
  • L'esportazione continua non può essere creata nei database follower poiché i database follower sono di sola lettura e l'esportazione continua richiede operazioni di scrittura.
  • I record nella tabella di origine devono essere inseriti direttamente nella tabella, usando criteri di aggiornamento o inserimenti da comandi di query. Se i record vengono spostati nella tabella utilizzando extent con estensione move o usando la tabella con estensione rename, l'esportazione continua potrebbe non elaborare questi record. Vedere le limitazioni descritte nella pagina Cursori di database.
  • Se gli artefatti usati dall'esportazione continua sono destinati a attivare le notifiche di Griglia di eventi, vedere la sezione problemi noti nella documentazione di Griglia di eventi.

Tra database e tra cluster:

  • L'esportazione continua non supporta le chiamate tra cluster.
  • L'esportazione continua supporta le chiamate tra database solo per le tabelle delle dimensioni. Tutte le tabelle dei fatti devono trovarsi nel database locale. Per altri dettagli, vedere Esportazione da tabelle dei fatti e delle dimensioni.
  • Se l'esportazione continua include chiamate tra database, deve essere configurata con un'identità gestita.

Cross-database e cross-Eventhouse:

  • L'esportazione continua non supporta le chiamate cross-Eventhouse.
  • L'esportazione continua supporta le chiamate tra database solo per le tabelle delle dimensioni. Tutte le tabelle dei fatti devono trovarsi nel database locale. Per altri dettagli, vedere Esportazione da tabelle dei fatti e delle dimensioni.

Criteri:

Contenuto correlato