Del via

Overfør fra Azure Data Explorer (ADX) til Fabric Real-Time Intelligence (Eventhouse)

I denne artikel kan du se, hvordan du gradvist kan overføre dine analysearbejdsbelastninger fra Azure Data Explorer til Eventhouse i Fabric Real-Time intelligens uden nedetid. Start med at bruge Fabric som forespørgselslag, mens ADX fortsætter med at indtage data for at udforske Fabrics funktioner. Når du er klar, kan du overføre fuldt ud ved at flytte skema og indtagelse til Fabric.

Notat

Du kan få mere at vide om forskellene mellem Fabric Real-Time Intelligence og sammenlignelige Azure-løsninger under Sammenlign med Azure-løsninger.

Forbrug ADX-data i Fabric

Behold kun ADX til indtagelse, og flyt forespørgsler til Fabric ved hjælp af en af disse to metoder til at bruge ADX-data fra Fabric uden at duplikere data.

  • Genvej til stofdatabase (følger)

    Opret en databasegenvej til en Azure Data Explorer-database, og forespørg uden at overføre data til Fabric. En databasegenvej i arbejdsbelastningen for Fabric Real-Time Intelligence er en integreret reference i en KQL-database (Kusto Query Language) til en kildedatabase i Azure Data Explorer. Databasegenvejens funktionsmåde svarer til en følgerdatabase. Det er skrivebeskyttet, synkroniserer nye data med en lille forsinkelse (sekunder til minutter) og giver alle Fabric-elementer mulighed for at få vist og forespørge på ADX-data uden at genindlæse dem.

  • Vedhæft ADX-klyngen som en kilde, der kan forespørges på

    I Fabric skal du sørge for, at du har forbindelse til ADX-klyngen. Tilføj en Azure Data Explorer-kilde i KQL-forespørgselssæt, som gør det muligt for visse Fabric-elementer som forespørgselssæt og dashboards i realtid at forespørge på ADX-data. Du kan få flere oplysninger under Forespørg på data i et KQL-forespørgselssæt – Microsoft Fabric.

    Prøv Fabrics funktioner som Copilot-assisteret forespørgselsgenerering, notesbøger, Activator og Power BI-rapporter på dine ADX-data. Kør alle dine dashboards og forespørgsler i Fabric, mens indtagelsen fortsætter i ADX. Når du er klar til at migrere fuldt ud, skal du følge de næste trin.

Migreringstrin på højt niveau

Følg disse trin for at migrere fra ADX til Fabric:

  1. Opret en ny KQL-database i Fabric med ADX-skemaet
  2. Opret en visning med unionsoperator, der har adgang til både tabel i KQL-database og tabel i ADX-database
  3. Omdiriger forespørgselsslutpunkter til KQL Database i Fabric Eventhouse
  4. Skift dataindtagelse til Fabric
  5. Trække ADX-klyngen tilbage

De følgende afsnit indeholder oplysninger om hvert trin.

Opret KQL-database i Fabric med ADX-skema

  1. Opret en tom KQL-database i et Fabric-eventhus, der til sidst erstatter ADX-databasen. Den skal have det samme tabeller og funktionsskema som din ADX-database. Du kan finde instruktioner under Oprette et eventhus og en KQL-database.

  2. Replikere skemaet

    Brug Sync Kusto, eller eksportér skemaet fra ADX-databasen for at genskabe det i Fabric KQL-databasen. SyncKusto er et dedikeret værktøj, der synkroniserer Kusto-databaseskemaer (tabeller, funktioner osv.) mellem miljøer.

    Du kan også køre KQL-kommandoen: .show database schema i ADX, som genererer et script med alle tabeldefinitioner, funktioner og politikker, og derefter køre det genererede script på KQL-databasen i Fabric.

  3. Bekræft skema

    Bekræft, at alle tabeller, kolonner, datatyper og relevante politikker (opbevaring, cachelagring osv.) i KQL-databasen stemmer overens med dem i ADX-databasen. På dette tidspunkt er Fabric KQL-databasen tom, men klar til at modtage data, og du kan også stadig forespørge på ADX ved hjælp af metoder fra afsnittet Udforsk ADX-data i Fabric .

Opret foreningsvisninger for problemfri dataadgang

Hvis du vil undgå afbrydelser under dataoverførsel, skal du oprette KQL-visninger i Fabric, der kombinerer data fra både den gamle ADX-database og den nye Fabric KQL-database. Denne fremgangsmåde gør det muligt for forespørgsler at returnere et komplet datasæt under overgangen:

  1. Definere foreningsvisninger

    For hver tabel skal du oprette en gemt funktion i Fabric (med .create function with (view=true)), der forbinder Fabric-tabellen med den tilsvarende ADX-tabel. Navngiv funktionen nøjagtigt det samme som tabellen for at tilsidesætte den på en gennemsigtig måde. For en tabel MyTableskal du f.eks. oprette en funktion ved hjælp af følgende kommando:

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

    Denne visning returnerer foreningen af den lokale MyTable i Fabric KQL-databasen, som i øjeblikket er tom eller modtager nye data, og fjerntabellen MyTable i ADX-databasen.

    Da navnet på visningen er MyTable, forespørger alle forespørgsler eller rapporter, der bruger dette tabelnavn, automatisk begge kilder.

    Fabric og ADX kan være i forskellige klynger eller lejere. Hvis oprettelseskommandoen klager over den eksterne reference, skal du bruge skipvalidation=true indstillingen i funktionsoprettelsen, som nogle gange er nødvendig for funktioner på tværs af klynger.

  2. Test visningen

    Kør en optællings- eller eksempelforespørgsel i visningen (f.eks. ) for at sikre, MyTable | countat den returnerer data fra ADX. Fabric KQL-databasen er stadig tom nu, men når du overfører indtagelse i næste trin, begynder visningen at returnere både gamle og nye poster.

Omdiriger forespørgselsslutpunkter til KQL Database i Fabric Eventhouse

Opdater nu dine værktøjer og programmer for at forespørge på den nye Fabric KQL-database i stedet for ADX-databasen:

  1. Opdater forbindelsesstrenge

    Skift analyseprogrammer, KQL-forespørgsler eller Power BI-rapporter for at bruge KQL-databasens slutpunkt (forespørgsels-URI) i stedet for ADX-klyngen. Forespørgslerne forbliver de samme, da tabelnavne og KQL ikke blev ændret, men de kører nu i Fabric. På grund af den foreningsvisning, der blev oprettet i det forrige trin, får brugere, der forespørger på Fabric KQL-databasen, stadig alle historiske data fra ADX via visningen plus eventuelle nye data, der indtages i Fabric.

  2. Test rapporter og apps

    Sørg for, at dashboards og scripts får resultater som forventet fra Fabric KQL-databasen. Ydeevnen kan variere lidt. Fabric kan cache nogle ADX-data, hvis du har brugt en genvej. Dette trin flytter effektivt forespørgselsslutpunkterne til Fabric. Herfra sker alle læse-/forespørgselshandlinger på Fabric.

Skift dataindtagelse til Fabric

Med forespørgsler, der nu betjenes af Fabric, kan du dirigere de indgående datastrømme til Fabric:

  1. Ompunktér indtagelsespipelines

    Skift alle dataproducenter som IoT-enheder, ETL-job (extract-transform-load), Event Hubs-forbindelser og andre, der tidligere indtages i ADX-databasen, så de indtages i Fabric KQL-databasen. Dette trin kan omfatte ændring af URL-adresser til klynger, godkendelse eller opdatering af forbindelsesstrenge i Azure Data Factory, Stream Analytics eller brugerdefinerede apps for at bruge slutpunktet for indtagelse af KQL-databasen eller URI'en.

  2. Bekræft nyt dataflow

    Kontrollér, at nye poster lander i tabeller i KQL-databasen. KQL-databasen i Fabric begynder at akkumulere data. Da du bruger foreningsvisningerne, viser forespørgsler i Fabric stadig et samlet datasæt. Over tid bliver data i ADX forældede, fordi der ikke indtages nye data i ADX efter dette skift.

Trække ADX-klyngen tilbage

Når du er sikker på, at alle nødvendige data er tilgængelige i Fabric, skal du tage de gamle ADX-ressourcer ud af drift:

  1. Fjern fagforeningsreferencer

    Rediger eller slip foreningsvisningerne, så forespørgsler ikke trækkes fra ADX-klyngen. Du kan f.eks. opdatere funktionsdefinitionen til MyTable { MyTable } kun at bruge lokale data eller droppe funktionen, hvis den fysiske tabel i Fabric indeholder alle data. Kontrollér, at dine forespørgsler og dashboards fungerer som forventet med Fabric-data.

  2. Arkivere eller overføre historiske data (hvis nødvendigt)

    Hvis der stadig er historiske data i ADX, der ikke er blevet flyttet (f.eks. hvis du ikke ventede på, at de blev ældet ud), kan du overveje at eksportere disse data til Fabric før lukningen. Ellers skal du fortsætte, hvis dataene i ADX er uden for opbevaringskravene.

  3. Nedlukning af ADX

    Når Fabric leverer både forespørgsler og indtagelse, skal du lukke eller slette ADX-klyngen for at spare omkostninger. Alle brugere skal oprette forbindelse til Fabric nu.

Resumé

Ved at følge trinnene i denne artikel migrerer du fra ADX til Fabric med minimal afbrydelse. Du starter med at flytte forbrugslaget til Fabric, som låser op for funktioner som Copilot, Power BI, Notebooks og Activator, og derefter gradvist flytte backend til Fabric. Nu håndterer Fabrics realtidsintelligens (Eventhouse) både indtagelse og forespørgsel af dine data, og ADX er ikke i brug.

  • Last updated on