Eseguire la migrazione da Esplora dati di Azure (ADX) a Fabric Real-Time intelligence (Eventhouse)

Questo articolo illustra come eseguire gradualmente la transizione dei carichi di lavoro di analisi da Esplora dati di Azure a Eventhouse in Fabric Real-Time intelligence senza tempi di inattività. Iniziare usando Fabric come livello di query mentre ADX continua a inserire dati per esplorare le funzionalità di Fabric. Quando sei pronto, esegui la migrazione completa spostando lo schema e l'acquisizione in Fabric.

Se non puoi attendere che i dati in ADX raggiungano la fine del periodo di conservazione e devi copiarli in Eventhouse, considera lo strumento open source Kusto Copy.

Utilizzare i dati ADX in Fabric

Mantenere ADX solo per l'inserimento e spostare l'esecuzione di query in Fabric usando uno di questi due metodi per usare i dati ADX da Fabric senza duplicare i dati.

• Collegamento al database di Fabric (follower)

  Crea un collegamento a un database di Esplora dati di Azure ed esegui query senza migrare i dati in Fabric. Una scorciatoia del database nel carico di lavoro Real-Time Intelligence di Fabric è un riferimento incorporato in un database Kusto Query Language (KQL) a un database di origine in Esplora dati di Azure. Il comportamento del collegamento al database è simile a un database di follower. È di sola lettura, sincronizza i nuovi dati con un leggero ritardo (da secondi a minuti) e consente a tutti gli elementi di Fabric di visualizzare ed eseguire query sui dati ADX senza riprovare.

• Collegare il cluster ADX come origine querybile

  In Fabric, assicurarsi di disporre di una connessione al cluster ADX. Aggiungere una fonte Esplora dati di Azure in un set di query KQL, che consente ad alcuni elementi di Fabric, come i set di query e i dashboard in tempo reale, di interrogare i dati ADX. Per altre informazioni, vedere Eseguire query sui dati in un set di query KQL - Microsoft Fabric.

  Prova le funzionalità di Fabric, come la generazione di query assistita da Copilot, i Notebook, Activator e i report di Power BI nei tuoi dati ADX. Eseguire tutti i dashboard e le query in Fabric mentre l'inserimento continua a verificarsi in ADX. Quando si è pronti per la migrazione completa, seguire i passaggi successivi.

Passaggi di alto livello per la migrazione

Seguire questa procedura per eseguire la migrazione da ADX a Fabric:

1. Creare un nuovo database KQL in Fabric con lo schema ADX
2. Creare una vista con l'operatore union che accede sia alla tabella nel database KQL sia alla tabella nel database ADX
3. Reindirizzare gli endpoint di query al database KQL in Fabric Eventhouse
4. Passa l'acquisizione dei dati a Fabric
5. Ritirare il cluster ADX

Nelle sezioni seguenti vengono fornite informazioni dettagliate su ogni passaggio.

Creare un database KQL in Fabric con lo schema ADX

1. Creare un database KQL vuoto in una eventhouse di Fabric che alla fine sostituisce il database ADX. Deve avere gli stessi schemi di tabelle e funzioni del database ADX. Per istruzioni, vedere Creare una sede eventi e un database KQL.

2. Replicare lo schema

   Usare Sync Kusto o esportare lo schema dal database ADX per ricrearlo nel database KQL di Fabric. SyncKusto è uno strumento dedicato che sincronizza gli schemi di database Kusto (tabelle, funzioni e così via) tra ambienti.

   In alternativa, è possibile eseguire il comando KQL: .show database schema as csl script in ADX, che genera uno script di tutte le definizioni di tabella, le funzioni e i criteri, quindi eseguire lo script generato nel database KQL in Fabric usando .execute database script.

3. Verificare lo schema

   Verificare che tutte le tabelle, le colonne, i tipi di dati e i criteri pertinenti (conservazione, memorizzazione nella cache e così via) nel database KQL corrispondano a quelli nel database ADX. A questo punto, il database KQL di Fabric è vuoto ma pronto per ricevere i dati ed è comunque possibile eseguire query su ADX usando i metodi della sezione Esplorare i dati ADX in Fabric .

Creare visualizzazioni unione per l'accesso facile ai dati

Per evitare interruzioni durante la migrazione dei dati, creare viste KQL in Fabric che combinano i dati del database ADX precedente e del nuovo database KQL di Fabric. Questo approccio consente alle query di restituire un set di dati completo durante la transizione:

1. Definire le visualizzazioni unione

   Per ogni tabella, creare una funzione archiviata in Fabric (con .create function with (view=true)) che unisce la tabella Fabric alla tabella ADX corrispondente. Assegna alla funzione esattamente lo stesso nome della tabella per sovrascriverla in modo trasparente. Ad esempio, per una tabella MyTable, creare una funzione usando il comando seguente:

   .create function with (view=true) MyTable() {
       MyTable 
       | union cluster("YourADXCluster").database("YourDatabase").MyTable
   }
   

   Questa vista restituisce l'unione dell'oggetto locale MyTable nel database KQL di Fabric, che è attualmente vuoto o riceve nuovi dati e la tabella MyTable remota nel database ADX.

   Poiché il nome della vista è MyTable, qualsiasi query o report che utilizza tale nome di tabella esegue automaticamente query su entrambe le origini.

   Fabric e ADX potrebbero trovarsi in cluster o tenant diversi. Se il comando di creazione segnala il riferimento esterno, usare l'opzione skipvalidation=true nella creazione della funzione, a volte necessaria per le funzioni tra cluster.

2. Testare la visualizzazione

   Esegui una query di conteggio o di esempio sulla vista (ad esempio, MyTable | count) per assicurarti che restituisca dati da ADX. Il database KQL di Fabric è ancora vuoto, ma quando si esegue la migrazione dell'inserimento nel passaggio successivo, la vista inizia a restituire record precedenti e nuovi.

Reindirizzare gli endpoint di query al database KQL in Fabric Eventhouse

Aggiornare ora gli strumenti e le applicazioni per eseguire query sul nuovo database KQL di Fabric anziché sul database ADX:

1. Aggiornare le stringhe di connessione

   Modificare le applicazioni di analisi, le query KQL o i report di Power BI per usare l'endpoint del database KQL (URI di query), anziché il cluster ADX. Le query rimangono invariate perché i nomi delle tabelle e KQL non sono stati modificati, ma ora vengono eseguiti in Fabric. A causa della vista di unione creata nel passaggio precedente, gli utenti che eseguono query nel database KQL di Fabric continuano a ottenere, tramite la vista, tutti i dati storici da ADX oltre a tutti i nuovi dati acquisiti in Fabric.

2. Report e app di test

   Assicurarsi che i dashboard e gli script ottengano risultati come previsto dal database KQL di Fabric. Le prestazioni potrebbero variare leggermente. Se è stato usato un collegamento, Fabric potrebbe memorizzare nella cache alcuni dati ADX. Questo passaggio sposta di fatto gli endpoint delle query in Fabric. Da qui in poi, tutte le operazioni di lettura/query si verificano in Fabric.

Passare all'acquisizione dei dati in Fabric

Con le query ora gestite da Fabric, indirizzare i flussi di dati in ingresso a Fabric:

1. Reindirizzare le pipeline di acquisizione

   Modifica tutti i produttori di dati, come i dispositivi IoT, i processi ETL (extract-transform-load), le connessioni di Event Hubs e altri, che in precedenza acquisivano dati nel database ADX, in modo che li acquisiscano nel database KQL di Fabric. Questo passaggio può includere la modifica degli URL del cluster, l'autenticazione o l'aggiornamento delle stringhe di connessione in Azure Data Factory, Analisi di flusso o app personalizzate per usare l'endpoint o l'URI di inserimento del database KQL.

2. Verificare il nuovo flusso di dati

   Verificare che i nuovi record siano inseriti nelle tabelle nel database KQL. Il database KQL in Fabric inizia ad accumulare dati. Poiché stai usando le viste UNION, le query in Fabric mostrano ancora un set di dati unificato. Nel corso del tempo, i dati in ADX diventano obsoleti perché non vengono inseriti nuovi dati in ADX dopo questa opzione.

Ritirare il cluster ADX

Quando si è certi che tutti i dati necessari siano disponibili in Fabric, rimuovere le risorse ADX precedenti:

1. Rimuovere i riferimenti all'unione

   Modificare o rimuovere le viste di unione in modo che le query non recuperino dati dal cluster ADX. Ad esempio, aggiornare la definizione della funzione a MyTable { MyTable } per usare solo i dati locali, oppure rimuovere la funzione se la tabella fisica in Fabric contiene tutti i dati. Verificare che le query e i dashboard funzionino come previsto con dati solo di Fabric.

2. Archiviare o trasferire dati cronologici (se necessario)

   Se in ADX sono ancora presenti dati storici che non sono stati trasferiti (ad esempio, se non si è atteso che scadessero), considerare l'esportazione di tali dati in Fabric prima della disattivazione. In caso contrario, continuare se i dati in ADX superano i requisiti di conservazione.

3. Disattivare ADX

   Quando Fabric gestisce sia le query sia l'acquisizione dei dati, arrestare o eliminare il cluster ADX per ridurre i costi. Tutti gli utenti devono ora connettersi a Fabric.

Riassunto

Seguendo la procedura descritta in questo articolo, si esegue la migrazione da ADX a Fabric con interruzioni minime. Si inizia spostando il livello di consumo in Fabric, sbloccando funzionalità come Copilot, Power BI, Notebook e Activator, per poi spostare gradualmente il back-end in Fabric. Ora l'intelligence in tempo reale di Fabric (Eventhouse) gestisce sia l'inserimento che l'interrogazione dei dati e ADX non viene utilizzato.