Fase 4: Migrazione della sicurezza e della governance

Questo articolo è la Fase 4 di un totale di 4 nella serie di procedure consigliate per la migrazione da Azure Synapse Spark a Microsoft Fabric.

Usare questo articolo nella fase finale della migrazione per convalidare i carichi di lavoro, allineare i controlli di sicurezza e governance e pianificare il cutover di produzione. Questo articolo fornisce indicazioni sulla mappatura della sicurezza e un approccio basato su una checklist per la convalida, l'ottimizzazione e la prontezza per il passaggio.

In questo articolo vengono illustrate le operazioni seguenti:

  • Mappare il controllo degli accessi basato sui ruoli di Synapse e i modelli di rete per lo spazio di lavoro Fabric, OneLake e i controlli di rete gestiti.
  • Riconnettere i flussi di lavoro di governance, inclusa l'integrazione Microsoft Purview e l'etichettatura.
  • Usare l'elenco di controllo fase per fase per la migrazione per convalidare, ottimizzare ed eseguire la transizione.
  • Pianificare la rimozione delle risorse di Synapse Spark legacy dopo il cutover riuscito.

Controllo di accesso

  • I Ruoli RBAC di Synapse (Amministratore di Synapse, Amministratore di Synapse SQL, Amministratore di Synapse Spark e altri) corrispondono ai ruoli dell'area di lavoro di Fabric (Amministratore, Membro, Collaboratore, Visualizzatore). Il modello di Fabric è più semplice con quattro ruoli.

  • I servizi collegati Synapse vengono sostituiti da connessioni Fabric. Creare connessioni tramite le impostazioni> dell'area di lavoroGestire connessioni e gateway. Per il codice del notebook, sostituire i riferimenti al servizio collegato con l'autenticazione basata su Key Vault o la configurazione diretta dell'endpoint.

  • OneLake RBAC offre un controllo di accesso ai dati con granularità fine a livello di cartella e tabella all'interno del Lakehouse.

Sicurezza della rete

  • Le reti virtuali gestite e gli endpoint privati di Synapse eseguono il mapping alla rete virtuale gestita di Fabric e agli endpoint privati gestiti. Si noti che Fabric Spark richiede pool personalizzati (non pool di avvio) per il supporto di endpoint privati gestiti.

  • I runtime di integrazione ospitati localmente (SHIR) in Synapse vengono sostituiti dai Gateway dati on-premise (OPDG) in Fabric. Gli IR di rete virtuale vengono sostituiti dai gateway dati della rete virtuale.

Governance

Se si utilizza Azure Purview con Azure Synapse, Microsoft Fabric offre un'integrazione nativa di Microsoft Purview per il catalogo dati, il lineage, le etichette di riservatezza e i criteri di accesso. Riconnetti l'account Purview per scansionare i spazi di lavoro di Fabric.

Elenco di controllo per la migrazione

Usare questo elenco di controllo per tenere traccia dello stato di avanzamento della migrazione di Spark. Ogni fase si basa su quella precedente. Completare tutti gli elementi in una fase prima di passare alla successiva.

Fase 1: Valutare e pianificare

Per indicazioni sulla pianificazione, modelli di migrazione e confronto delle funzionalità, vedere Fase 1: Strategia e pianificazione della migrazione.

  • 1.1 Completare l'inventario degli asset Spark: pool di Spark, notebook, definizioni dei processi Spark, database lake, database HMS (Hive Metastore) e servizi collegati usati nei notebook.
  • 1.2 Esaminare le differenze nelle funzionalità tra Synapse e Fabric. Flag blocker: carichi di lavoro GPU, API del catalogo non supportate, dipendenze del servizio collegato.
  • 1.3 Eseguire il controllo di pre-refactoring: cercare in tutti i notebook i modelli specifici di Synapse (spark.synapse.linkedService, getSecretWithLS, TokenLibrary, synapsesql). Conteggio dei notebook interessati.
  • 1.4 Controllare la compatibilità della libreria: eseguire pip freeze nei pool synapse, confrontarsi con le librerie predefinite di runtime 1.3 di Fabric. Elencare le librerie che devono essere preinstallate.
  • 1.5 Creare aree di lavoro Fabric, fornire capacità e creare elementi di Lakehouse di destinazione.
  • 1.6 Esportare configurazioni del pool di Spark, librerie personalizzate e proprietà Spark da Synapse Studio.

Fase 2: Configurare connessioni e credenziali

Per indicazioni sulla sostituzione e l'autenticazione del servizio collegato, vedere Fase 2: Migrazione del carico di lavoro Spark e Fase 4: Migrazione della sicurezza e della governance.

  • 2.1 Inventariare tutti i servizi collegati di Synapse usati dai notebook, dalle definizioni dei job Spark e dall'accesso ai dati di Lakehouse.
  • 2.2 Creare connessioni Fabric per origini dati esterne (ADLS Gen2, Cosmos DB, Azure SQL e altri) tramite Impostazioni dello spazio di lavoro>Gestire connessioni e gateway.
  • 2.3 Configurare Azure Key Vault con segreti per le origini dati che richiedono l'autenticazione basata su chiave (chiavi cosmos DB, chiavi dell'account di archiviazione, token Kusto). Configurare le politiche di accesso per l'identità della tua area di lavoro Fabric.
  • 2.4 Configurare le credenziali del principale del servizio per l'accesso OAuth di ADLS Gen2: registrare l'app in Entra ID, concedere il ruolo di Collaboratore dei dati del BLOB di Archiviazione, prendere nota dell'ID client, del segreto client e del tenant.
  • 2.5 Verificare la connettività: testare, da un notebook di Fabric, il recupero dei segreti da Key Vault e l'accesso all'account di archiviazione prima di procedere.

Fase 3: Eseguire la migrazione dei dati e del metastore Hive

Per indicazioni sulla migrazione dei metadati e dell'accesso ai dati del lake, vedere: Fase 3: Hive Metastore e migrazione dei dati e Migrazione di dati e pipeline.

  • 3.1 Creare collegamenti OneLake ai percorsi di ADLS Gen2 esistenti (approccio preferito senza copia). Usare le connessioni Fabric configurate nella Fase 2 per l'accesso tramite gateway dati.
  • 3.2 Per i file non Delta (CSV, JSON, Parquet), creare collegamenti nella sezione File. Se è necessaria la copia dei dati, usare AzCopy o l'attività di copia di Data Factory.
  • 3.3 Eseguire la migrazione di oggetti Metastore Hive. Scegliere un approccio: Opzione A: Eseguire notebook di esportazione/importazione HMS per tutti i metadati. Opzione B: usare Migration Assistant per le tabelle del database Delta Lake + esportazione/importazione HMS solo per non-Delta.
  • 3.4 Convalidare la registrazione automatica della tabella Delta in Lakehouse Explorer.
  • 3.5 Verificare che tutte le tabelle e i collegamenti importati siano visibili in Lakehouse Explorer e accessibili dai notebook.

Fase 4: Eseguire la migrazione dei carichi di lavoro Spark

Per la migrazione degli elementi, il refactoring del codice e le linee guida per la configurazione dell'ambiente, vedere Fase 2: Migrazione del carico di lavoro Spark.

  • 4.1 Eseguire Spark Migration Assistant per i notebook, le definizioni di processi Spark, i pool di Spark e i database lake. Esaminare il report di migrazione per individuare errori e avvisi.
  • 4.2 Creare ambienti Fabric con runtime Spark di destinazione, configurazione del pool e librerie personalizzate. Pre-installare librerie mancanti identificate nella fase 1.
  • 4.3 Rifattorizzare il notebook e il codice SJD: sostituire con , aggiornare i percorsi dei file ai percorsi di OneLake , sostituire i riferimenti al servizio collegato con connessioni al Key Vault o a Fabric e sostituire i metodi non supportati con gli equivalenti Spark SQL.
  • 4.4 Refactoring dei connettori: Kusto/ADX : sostituire il servizio collegato con accessToken tramite getToken(). Cosmos DB: sostituire getSecretWithLS con getSecret(akvName, secret).
  • 4.5 Sostituire i provider di token Synapse (LinkedServiceBasedTokenProvider, TokenLibrary) con OAuth ClientCredsTokenProvider standard tramite spark.conf.set().
  • 4.6 Testare i notebook refattorizzati e le SJDs end-to-end contro i dati (fase 3) e le connessioni (fase 2).

Fase 5: Sicurezza, governance e rete

Per indicazioni sulla sicurezza, la governance e il mapping di rete, vedere Fase 4: Migrazione della sicurezza e della governance.

  • 5.1 Mappare i ruoli RBAC di Synapse con i ruoli dell'area di lavoro Fabric (Amministratore, Membro, Collaboratore, Visualizzatore).
  • 5.2 Configurare RBAC di OneLake per il controllo di accesso ai dati a grana fine, a livello di cartella e di tabella.
  • 5.3 Configurare la rete virtuale gestita e gli endpoint privati gestiti per i carichi di lavoro Spark che accedono a origini dati private (richiede pool personalizzati).
  • 5.4 Sostituire SHIR con il gateway dati locale (OPDG) e sostituire VNet IR con il gateway dati della rete virtuale.
  • 5.5 Riconnettere Microsoft Purview per governance, derivazione ed etichette di riservatezza.
  • 5.6 Esaminare e applicare etichette di sensibilità agli elementi Lakehouse migrati in base alle esigenze.

Fase 6: Ottimizzare e convalidare

Per indicazioni sulla convalida post-migrazione e sull'idoneità alla produzione, vedere Fase 4: Migrazione della sicurezza e della governance.

  • 6.1 Abilitare il motore di esecuzione nativo (NEE) per migliorare le prestazioni di Spark nei carichi di lavoro Parquet e Delta.
  • 6.2 Eseguire OPTIMIZE VORDER nelle tabelle utilizzate da Power BI Direct Lake o dall'endpoint di analisi SQL.
  • 6.3 Eseguire carichi di lavoro paralleli e confrontare i risultati e le prestazioni dei processi Spark tra Synapse e Fabric.
  • 6.4 Reindirizza i consumer downstream, inclusi i report Power BI, le API e le applicazioni, agli endpoint di Fabric.
  • 6.5 Monitorare i carichi di lavoro Fabric usando l'hub di monitoraggio e l'emettitore di diagnostica per almeno due settimane.

Fase 7: Transizione

Per la convalida finale, il reindirizzamento downstream e le linee guida per la transizione, vedere Fase 4: Migrazione della sicurezza e della governance.

  • 7.1 Confermare che tutti i notebook, le unità SSD e i processi Spark migrati vengano eseguiti correttamente in Fabric.
  • 7.2 Verificare l'integrità dei dati tramite conteggi delle righe, convalida dello schema e confronto dei risultati della query.
  • 7.3 Comunicare il cutover agli stakeholder e aggiornare la documentazione.
  • 7.4 Disattivare i pool di Synapse Spark, i notebook e le risorse correlate.

Note

Dopo la migrazione, è consigliabile configurare l'integrazione di Fabric Git per i notebook migrati e le definizioni di processo Spark. Fabric supporta l'integrazione di Azure DevOps Git per il controllo del codice sorgente, la ramificazione e le pipeline di distribuzione. A differenza di Synapse (che usa i modelli arm per CI/CD), Fabric usa un modello basato sull'area di lavoro in cui si connette un'area di lavoro a un ramo Git e sincronizza direttamente gli elementi. I notebook, gli ambienti e i dischi SSD supportano tutti l'integrazione di Git. Configurare le pipeline di distribuzione (Sviluppo → Test → Prod) per gestire l'innalzamento di livello tra gli ambienti.

Contenuti correlati

  • Last updated on