Fas 4: Migrering av säkerhet och styrning

Den här artikeln är fas 4 av 4 i Azure Synapse Spark till Microsoft Fabric migrationsbästa praxis-serien.

Använd den här artikeln i den sista fasen av migreringen för att verifiera arbetsbelastningar, justera säkerhets- och styrningskontroller och planera produktionsnedskärningen. Den här artikeln innehåller vägledning om säkerhetsmappning och en checklista-baserad metod för validering, optimering och beredskap för övergång.

I den här artikeln lär du dig att:

  • Mappa Synapse RBAC- och nätverksmönster till Fabric arbetsyta, OneLake och hanterade nätverkskontroller.
  • Återanslut styrningsarbetsflöden, inklusive Microsoft Purview integrering och etikettering.
  • Använd checklistan för fas-för-fas-migrering för att verifiera, optimera och utföra växling.
  • Planera avveckling av befintliga Synapse Spark-resurser efter en lyckad övergång.

Åtkomstkontroll

  • Synapse RBAC-roller (Synapse-administratör, Synapse SQL-administratör, Synapse Spark-administratör med flera) mappas till Fabric arbetsyteroller (administratör, medlem, deltagare, visningsprogram). Fabric modell är enklare med fyra roller.

  • Synapse-länkade tjänster ersätts av Fabric Anslutningar. Skapa anslutningar via arbetsyteinställningar>Hantera anslutningar och gatewayer. För notebook-kod ersätter du länkade tjänstreferenser med Key Vault-baserad autentisering eller direkt slutpunktskonfiguration.

  • OneLake RBAC ger detaljerad dataåtkomstkontroll på mapp- och tabellnivå i Lakehouse.

Nätverkssäkerhet

  • Synapse Managed VNet och Private Endpoints mappas till Fabric Managed VNet och Managed Private Endpoints. Observera att Fabric Spark kräver anpassade pooler (inte startpooler) för stöd för hanterad privat slutpunkt.

  • Självhostade Integration Runtimes (SHIR) i Synapse ersätts av On-premises Data Gateways (OPDG) i Fabric. Virtuella nätverks-IR:er ersätts av VNet-datagatewayer.

Styrelseskick

Om du använder Azure Purview med Synapse tillhandahåller Fabric inbyggd Microsoft Purview integrering för datakatalog, ursprung, känslighetsetiketter och åtkomstprinciper. Återanslut ditt Purview-konto för att skanna Fabric arbetsytor.

Checklista för migrering

Använd den här checklistan för att spåra förloppet via Spark-migreringen. Varje fas bygger på den föregående. Slutför alla objekt i en fas innan du går vidare till nästa.

Fas 1: Utvärdera och planera

Planeringsvägledning, migreringsmönster och funktionsjämförelse finns i Fas 1: Migreringsstrategi och planering.

  • 1.1 Slutför Spark-tillgångsinventering: Spark-pooler, notebook-filer, Spark-jobbdefinitioner, lakedatabaser, Hive Metastore-databaser (HMS) och länkade tjänster som används i notebook-filer.
  • 1.2 Granska funktionsskillnader mellan Synapse och Fabric. Flagga blockerare: GPU-arbetsbelastningar, katalog-API:er som inte stöds, länkade tjänstberoenden.
  • 1.3 Kör granskning före refaktorisering: Sök i alla anteckningsböcker efter Synapse-specifika mönster (spark.synapse.linkedService, getSecretWithLS, TokenLibrary, synapsesql). Räkna berörda bärbara datorer.
  • 1.4 Kontrollera bibliotekskompatibilitet: kör pip freeze på Synapse-pooler, jämför med Fabric Inbyggda bibliotek i Runtime 1.3. Visa en lista över bibliotek som måste vara förinstallerade.
  • 1.5 Skapa Fabric-arbetsytor, tillhandahåll kapacitet och skapa målobjekt för Lakehouse.
  • 1.6 Exportera Spark-poolkonfigurationer, anpassade bibliotek och Spark-egenskaper från Synapse Studio.

Fas 2: Konfigurera anslutningar och autentiseringsuppgifter

Vägledning för ersättning och autentisering av länkade tjänster finns i Fas 2: Migrering av Spark-arbetsbelastning och fas 4: Migrering av säkerhet och styrning.

  • 2.1 Inventera alla Synapse-länkade tjänster som används av notebooks, Spark-jobbdefinitioner och tillgång till Lakehouse-data.
  • 2.2 Skapa Fabric-anslutningar för externa datakällor (ADLS Gen2, Cosmos DB, Azure SQL och andra) via Arbetsyteinställningar>Hantera anslutningar och gatewayer.
  • 2.3 Konfigurera Azure Key Vault med hemligheter för datakällor som kräver nyckelbaserad autentisering (Cosmos DB-nycklar, lagringskontonycklar, Kusto-token). Konfigurera åtkomstprinciper för identiteten för din Fabric-arbetsyta.
  • 2.4 Konfigurera autentiseringsuppgifter för tjänstens principal för ADLS Gen2 OAuth-åtkomst: registrera appen i Entra ID, bevilja rollen Storage Blob Data Contributor, notera klient-ID/klienthemlighet/hyrande.
  • 2.5 Verifiera anslutningen: testa hämtning av hemlighet från Key Vault och åtkomst till lagringskonto från en Fabric notebook innan du fortsätter.

Fas 3: Migrera data och Hive-metaarkiv

Vägledning för lakemetadata och dataåtkomstmigrering finns i Fas 3: Hive Metastore och datamigrering samt Migrera data och pipelines.

  • 3.1 Skapa OneLake-genvägar till befintliga ADLS Gen2-sökvägar (nollkopiering, önskad metod). Använd Fabric-anslutningar som konfigurerats i fas 2 för åtkomst via datagateway.
  • 3.2 För icke-Delta-filer (CSV, JSON, Parquet) skapar du genvägar i avsnittet Filer. Om datakopiering krävs använder du AzCopy eller datafabrikens kopieringsaktivitet.
  • 3.3 Migrera Hive-metaarkivobjekt. Välj en metod: Alternativ A: Kör HMS-export-/importanteckningsböcker för alla metadata. Alternativ B: Använd Migration Assistant för Delta lake DB-tabeller + HMS-export/import endast för icke-Delta.
  • 3.4 Verifiera automatisk registrering av Delta-tabellen i Lakehouse Explorer.
  • 3.5 Kontrollera att alla importerade tabeller och genvägar visas i Lakehouse Explorer och är tillgängliga från notebook-filer.

Fas 4: Migrera Spark-arbetsbelastningar

Information om objektmigrering, kodrefaktorisering och vägledning för miljökonfiguration finns i Fas 2: Migrering av Spark-arbetsbelastning.

  • 4.1 Kör Spark-migrationsassistent för notebooks, Sparkjobbdefinitioner, Sparkpooler och sjödatabaser. Granska migreringsrapporten för fel och varningar.
  • 4.2 Skapa Fabric-miljöer med Spark-målkörningstid, poolkonfiguration och anpassade bibliotek. Installera bibliotek som saknas i fas 1 i förväg.
  • 4.3 Refactor notebook och SJD-kod: ersätt mssparkutils med notebookutils, uppdatera filsökvägar till OneLake abfss:// sökvägar, ersätt länkade tjänstreferenser med Key Vault eller Fabric Anslutningar och ersätt metoder som inte stöds spark.catalog med Spark SQL-motsvarigheter.
  • 4.4 Refaktorera anslutningar: Kusto/ADX – ersätt associerad tjänst med accessToken via getToken(). Cosmos DB – ersätt getSecretWithLS med getSecret(akvName, secret).
  • 4.5 Ersätt Synapse-tokenprovidrar (LinkedServiceBasedTokenProvider, TokenLibrary) med standard-OAuth ClientCredsTokenProvider via spark.conf.set().
  • 4.6 Testa omstrukturerade notebook-filer och SJD:er genom hela processen mot data (fas 3) och anslutningar (fas 2).

Fas 5: Säkerhet, styrning och nätverk

Vägledning för säkerhet, styrning och nätverksmappning finns i Fas 4: Migrering av säkerhet och styrning.

  • 5.1 Mappa Synapse RBAC-roller till Fabric arbetsområdesroller (administratör, medlem, bidragsgivare, granskare).
  • 5.2 Konfigurera OneLake RBAC för detaljerad dataåtkomstkontroll på mapp- och tabellnivå.
  • 5.3 Konfigurera hanterade virtuella nätverk och hanterade privata slutpunkter för Spark-arbetsbelastningar som har åtkomst till privata datakällor (kräver anpassade pooler).
  • 5.4 Ersätt SHIR med lokal datagateway (OPDG) och ersätt VNet IR med VNet Data Gateway.
  • 5.5 Återanslut Microsoft Purview för styrning, ursprung och känslighetsetiketter.
  • 5.6 Granska och tillämpa känslighetsetiketter på migrerade Lakehouse-objekt efter behov.

Fas 6: Optimera och verifiera

Vägledning för validering efter migreringen och produktionsberedskap finns i Fas 4: Migrering av säkerhet och styrning.

  • 6.1 Aktivera intern körningsmotor (NEE) för Spark-prestandaförbättringar på Parquet- och Delta-arbetsbelastningar.
  • 6.2 Kör OPTIMIZE VORDER på tabeller som används av Power BI Direct Lake eller SQL-analysslutpunkten.
  • 6.3 Kör parallella arbetsbelastningar och jämför Spark-jobbresultat och prestanda mellan Synapse och Fabric.
  • 6.4 Omdirigera nedströmsanvändare, inklusive Power BI rapporter, API:er och program, till Fabric slutpunkter.
  • 6.5 Övervaka Fabric arbetsbelastningar med Monitoring Hub och Diagnostic Emitter i minst en till två veckor.

Fas 7: Övergång

För slutlig validering, omdirigering nedströms och vägledning för övergång, se i Fas 4: Migrering av säkerhet och styrning.

  • 7.1 Bekräfta att alla migrerade notebook-filer, SJD:er och Spark-jobb körs i Fabric.
  • 7.2 Verifiera dataintegriteten via radantal, schemavalidering och jämförelse av frågeresultat.
  • 7.3 Meddela övergång till intressenter och uppdatera dokumentationen.
  • 7.4 Inaktivera Synapse Spark-pooler, notebook-filer och relaterade resurser.

Note

Efter migreringen bör du överväga att konfigurera Fabric Git-integrering för dina migrerade notebook-filer och Spark-jobbdefinitioner. Fabric stöder Azure DevOps Git-integrering för källkontroll, förgrening och distributionspipelines. Till skillnad från Synapse (som använder ARM-mallar för CI/CD) använder Fabric en arbetsytebaserad modell där du ansluter en arbetsyta till en Git-gren och synkroniserar objekt direkt. Notebook-filer, miljöer och SJD:er stöder alla Git-integration. Konfigurera distributionspipelines (Dev → Test → Prod) för att hantera befordran mellan miljöer.

Relaterat innehåll

  • Last updated on