Migrera från Azure Data Explorer (ADX) till Fabric Real-Time intelligence (Eventhouse)

Den här artikeln visar hur du gradvis övergår dina analysarbetsbelastningar från Azure Data Explorer till Eventhouse i Fabric Real-Time intelligens utan driftstopp. Börja med att använda Fabric som frågeskikt medan ADX fortsätter att mata in data för att utforska Fabrics funktioner. När du är redo migrerar du fullt ut genom att flytta schema och datainhämtning till Fabric.

Om du inte kan vänta tills dina data i ADX har åldrats och behöver kopiera dem till Eventhouse kan du överväga open-source verktyget Kusto Copy.

Använda ADX-data i Fabric

Behåll ADX endast för inläsning och flytta frågekörningen till Fabric med någon av dessa två metoder för att använda ADX-data från Fabric utan att duplicera data.

• Databasgenväg i Fabric (sekundär)

  Skapa en databasgenväg till en Azure Data Explorer-databas och fråga utan att migrera data till Fabric. En databasgenväg i Fabric Real-Time Intelligence-arbetsbelastningen är en inbäddad referens i en Kusto Query Language-databas (KQL-databas) till en källdatabas i Azure Data Explorer. Beteendet för databasgenvägen liknar en uppföljningsdatabas. Den är skrivskyddad, synkroniserar nya data med en liten fördröjning (sekunder till minuter) och låter alla Infrastrukturobjekt visa och köra frågor mot ADX-data utan att behöva ange dem igen.

• Bifoga ADX-klustret som en frågebar källa

  I Infrastruktur kontrollerar du att du har en anslutning till ADX-klustret. Lägg till en Azure Data Explorer-källa i KQL-frågeuppsättning, vilket gör att vissa Fabric-objekt, som frågeuppsättningar och instrumentpaneler i realtid, kan fråga ADX-data. Mer information finns i Fråga efter data i en KQL-frågeuppsättning – Microsoft Fabric.

  Prova Fabrics funktioner som Copilot-assisterad frågegenerering, Notebooks, Activator och Power BI-rapporter på dina ADX-data. Kör alla dina dashboards och frågor i Fabric medan inläsningen fortsätter i ADX. När du är redo att migrera helt följer du nästa steg.

Migreringssteg på hög nivå

Följ de här stegen för att migrera från ADX till Fabric:

1. Skapa en ny KQL-databas i Fabric med ADX-schemat
2. Skapa en vy med unionoperatorn som har åtkomst till både tabellen i KQL-databasen och tabellen i ADX-databasen
3. Omdirigera frågeslutpunkter till KQL Database i Fabric Eventhouse
4. Växla datainhämtning till Fabric
5. Dra tillbaka ADX-klustret

Följande avsnitt innehåller information om varje steg.

Skapa KQL-databas i Fabric med ADX-schema

1. Skapa en tom KQL-databas i ett Fabric-händelsehus som så småningom ersätter ADX-databasen. Den måste ha samma tabeller och funktionsschema som ADX-databasen. Anvisningar finns i Skapa ett eventhouse och en KQL-databas.

2. Kopiera schemat

   Använd Sync Kusto eller exportera schemat från ADX-databasen för att återskapa det i Fabric KQL-databasen. SyncKusto är ett dedikerat verktyg som synkroniserar Kusto-databasscheman (tabeller, funktioner osv.) mellan miljöer.

   Du kan också köra KQL-kommandot: .show database schema as csl script i ADX, som genererar ett skript med alla tabelldefinitioner, funktioner och principer, och sedan köra det genererade skriptet på KQL-databasen i Fabric med ..execute database script

3. Verifiera schema

   Bekräfta att alla tabeller, kolumner, datatyper och relevanta principer (kvarhållning, cachelagring osv.) i KQL-databasen matchar dem i ADX-databasen. Vid det här laget är Fabric KQL-databasen tom men redo att ta emot data, och du kan fortfarande även fråga ADX med hjälp av metoder från avsnittet Utforska ADX-data i Fabric.

Skapa unionsvyer för sömlös dataåtkomst

För att undvika avbrott under datamigreringen skapar du KQL-vyer i Infrastrukturresurser som kombinerar data från både den gamla ADX-databasen och den nya Fabric KQL-databasen. Med den här metoden kan frågor returnera en fullständig datamängd under övergången:

1. Definiera kombinerade vyer

   För varje tabell skapar du en lagrad funktion i Fabric (med .create function with (view=true)) som slår samman Fabric-tabellen med motsvarande ADX-tabell. Ge funktionen exakt samma namn som tabellen för att transparent åsidosätta den. För en tabell MyTableskapar du till exempel en funktion med hjälp av följande kommando:

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

   Den här vyn returnerar unionen av den lokala vyn MyTable i Fabric KQL-databasen, som för närvarande är tom eller tar emot nya data, och fjärrtabellen MyTable i ADX-databasen.

   Eftersom namnet på vyn är MyTable, frågar alla frågor eller rapporter som använder det tabellnamnet automatiskt båda källorna.

   Fabric och ADX kan finnas i olika kluster eller klientorganisationer. Om skapandekommandot klagar på den externa referensen använder du alternativet skipvalidation=true när du skapar funktionen, vilket ibland behövs för funktioner över flera kluster.

2. Testa vyn

   Kör en count- eller exempelfråga i vyn (till exempel MyTable | count) för att se till att den returnerar data från ADX. Fabric KQL-databasen är fortfarande tom nu, men när du migrerar inmatning i nästa steg börjar vyn returnera både gamla och nya poster.

Omdirigera frågeslutpunkter till KQL Database i Fabric Eventhouse

Uppdatera nu dina verktyg och program för att fråga den nya Fabric KQL-databasen i stället för ADX-databasen:

1. Uppdatera anslutningssträngar

   Ändra analysprogram, KQL-frågor eller Power BI-rapporter för att använda KQL-databasens slutpunkt (fråge-URI) i stället för ADX-klustret. Frågorna är desamma eftersom tabellnamnen och KQL inte har ändrats, men de körs nu i Fabric. På grund av den union-vy som skapades i föregående steg får användare som kör frågor mot Fabric KQL-databasen fortfarande alla historiska data från ADX via vyn, plus eventuella nya data som matas in i Fabric.

2. Testa rapporter och appar

   Se till att instrumentpaneler och skript får resultat som förväntat från Fabric KQL-databasen. Prestanda kan variera något. Fabric kan cachelagra vissa ADX-data om du använde en genväg. Det här steget flyttar i praktiken slutpunkterna för frågor till Fabric. Från och med nu sker alla läs- och frågeåtgärder i Fabric.

Byt datainhämtning till Fabric

När frågor nu betjänas av Fabric dirigerar du de inkommande dataströmmarna till Fabric:

1. Peka om inmatningspipelines

   Ändra alla dataproducenter som IoT-enheter, ETL-jobb (extract-transform-load), Event Hubs-anslutningar och andra som tidigare matas in i ADX-databasen, så att de matas in i Fabric KQL-databasen. Det här steget kan omfatta ändring av kluster-URL:er, autentisering eller uppdatering av anslutningssträngar i Azure Data Factory, Stream Analytics eller anpassade appar för att använda KQL-databasinmatningsslutpunkten eller URI:n.

2. Verifiera nytt dataflöde

   Kontrollera att nya poster hamnar i tabeller i KQL-databasen. KQL-databasen i Fabric börjar samla in data. Eftersom du använder unionsvyerna visar frågor i Fabric fortfarande en enhetlig datauppsättning. Med tiden blir data i ADX inaktuella eftersom inga nya data matas in i ADX efter den här växeln.

Dra tillbaka ADX-klustret

När du är säker på att alla nödvändiga data är tillgängliga i Infrastrukturresurser inaktiverar du de gamla ADX-resurserna:

1. Ta bort unionsreferenser

   Ändra eller släpp unionsvyerna så att frågor inte hämtas från ADX-klustret. Du kan till exempel uppdatera funktionsdefinitionen till att MyTable { MyTable } endast använda lokala data eller släppa funktionen om den fysiska tabellen i Fabric har alla data. Kontrollera att dina frågor och instrumentpaneler fungerar som förväntat med data enbart från Fabric.

2. Arkivera eller överföra historiska data (om det behövs)

   Om det fortfarande finns historiska data i ADX som inte har flyttats (till exempel om du inte väntade på att de skulle åldras ut) bör du överväga att exportera dessa data till Infrastrukturresurser före avstängning. Fortsätt annars om data i ADX överskrider kraven på lagringstid.

3. Inaktivera ADX

   När Fabric hanterar både frågor och inmatning stänger du av eller tar bort ADX-klustret för att spara kostnader. Alla användare bör ansluta till Fabric nu.

Sammanfattning

Genom att följa stegen i den här artikeln migrerar du från ADX till Fabric med minimala avbrott. Du börjar med att flytta konsumtionslagret till Fabric, vilket ger tillgång till funktioner som Copilot, Power BI, Notebooks och Activator, och flyttar sedan gradvis backenden till Fabric. Nu hanterar Fabrics realtidsinformation (Eventhouse) både inmatning och frågekörning av dina data, och ADX används inte.