Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
si applica a:✅database SQL in Microsoft Fabric
Questo articolo descrive come usare il database SQL in Fabric come destinazione ETL inversa all'interno di un ambiente di dati basato su Fabric. Fornisce indicazioni sull'architettura, modelli operativi e considerazioni sull'implementazione per lo spostamento di dati curati da origini analitiche (ad esempio Microsoft Fabric Data Warehouse o Fabric Lakehouse) nel database SQL in Fabric per l'utilizzo operativo da parte di applicazioni, API ed esperienze in tempo reale.
Che cos'è l'ETL inverso in Fabric?
Molti clienti hanno investito molto tempo e impegno nella creazione di processi di estrazione, trasformazione, caricamento (ETL) per trasformare i dati operativi non elaborati in dati analitici più raffinati che possono essere usati per la creazione di report aziendali. Il risultato finale di un processo ETL è in genere un archivio analitico, ad esempio un magazzino o una lakehouse a cui accede un livello di report come Power BI. Questa architettura serve bene agli utenti aziendali, ma la creazione di report è relativamente statica e le informazioni dettagliate possono essere derivate solo dall'intervento umano. Usando L'ETL inverso, è possibile inserire i dati trasformati in sistemi operativi in modo che le applicazioni e gli agenti possano ottenere informazioni dettagliate da questi dati analizzati in tempo reale. L'ETL inverso esegue il push dei dati dai fatti e dalle dimensioni negli archivi analitici in un livello di servizio a cui è possibile accedervi tramite endpoint come GraphQL o direttamente tramite query TDS (Tabular Data Stream).
Anche se è possibile connettere le applicazioni operative direttamente a un warehouse o a un lakehouse, questi archivi dati sono progettati per carichi di lavoro analitici. Gli archivi dati operativi, come il database SQL in Fabric, sono progettati per supportare query transazionali e offrono prestazioni e scalabilità migliori per i carichi di lavoro operativi. I database operativi offrono anche la possibilità di arricchire ulteriormente i dati con incorporamenti vettoriali e metadati aggiuntivi per facilitare la ricerca vettoriale e ibrida, nonché la generazione avanzata del recupero (RAG).
- In questo modello, il magazzino o lakehouse rimane il sistema di registrazione analitica.
- Il database SQL in Fabric funge da archivio operativo che offre bassa latenza, indicizzazione perfezionata, vincoli di dati e relazioni rigorosi e i contratti di servizio previsti dai team dell'applicazione.
Destinazioni ETL inverse comuni
Le destinazioni ETL inverse comuni rappresentano in genere sezioni di dati curate e di alto valore che i sistemi operativi possono utilizzare con una trasformazione minima. Queste destinazioni sono progettate per offrire accesso a bassa latenza ai dati attendibili mantenendo al tempo stesso la logica di business applicata nel livello analitico. Gli esempi includono:
- Dati dei clienti e degli utenti (ad esempio metriche di engagement, ad esempio attività di sessione, utilizzo delle funzionalità e interazioni)
- Dati sulle vendite e sul marketing (ad esempio, metriche di assegnazione dei punteggi come la propensione all'acquisto, i punteggi di engagement, la probabilità di convertire)
- Dati operativi e transazionali (ad esempio, dati di ordine e inventario, ad esempio livelli di scorte, stato ordine e tempi di consegna)
- Dati derivati da intelligenza artificiale/apprendimento automatico (ad esempio, raccomandazioni personalizzate sui prodotti, punteggi predittivi come il rischio di abbandono o la propensione all'upsell o l'analisi del sentiment)
Meccanismi di spostamento dei dati
Il processo inizia definendo i dati di origine, impostando la destinazione e quindi selezionando un meccanismo di spostamento dei dati. Scegliere uno o più dei meccanismi seguenti per trasferire i dati dall'archivio analitico al database SQL in Fabric.
Suggerimento
Come regola generale, usare:
- Pipeline per semplici caricamenti di copia e pianificati.
- Flussi di dati Gen2 per trasformazioni a basso codice.
- Spark per l'elaborazione complessa e su larga scala (incluso Machine Learning).
- T-SQL tra elementi , dove disponibile per mantenere le operazioni incentrate su SQL, ad esempio aggiungendo una tabella nel database SQL a una tabella in un warehouse o in un endpoint di analisi SQL.
| Meccanismo | Usare quando | Punti di forza | Considerazioni |
|---|---|---|---|
| Pipeline di dati di Fabric | Sono necessari carichi gestiti e ripetibili (batch o micro batch) di operazioni di copia dei dati | Integrazione di prima classe; supporta il watermarking e le stored procedure | Concorrenza; scalare il database SQL durante i caricamenti |
| Flusso di dati Gen2 | Sono necessarie trasformazioni dei dati a basso codice e logica avanzata dei processi | Adatto alle imprese; supporta la modellazione e la pulizia delle colonne | Velocità effettiva inferiore per volumi di grandi dimensioni; partizionamento dei piani |
| Spark (notebook/attività) | Sono necessarie trasformazioni complesse basate su codice e rimodelli su larga scala | Controllo completo del codice; letture Delta efficienti; Supporto per la scrittura JDBC | Autenticazione e invio in batch; evitare transazioni di grandi dimensioni |
| Query T-SQL tra elementi | È necessario lo spostamento SQL nel database tra gli elementi di Fabric | Impianti idraulici minimi; SQL nativo; facile da pianificare |
Architettura di riferimento: ETL inverso al database SQL in Fabric
L'architettura di riferimento per LTL inverso in Fabric riunisce i blocchi predefiniti essenziali necessari per rendere operativi i dati analitici curati. Illustra il flusso dei dati da origini analitiche attendibili tramite i livelli di trasformazione in un database SQL strutturato. Il database operativo funge da interfaccia per i sistemi downstream. Questo modello garantisce che le applicazioni, le API e gli strumenti di creazione di report possano accedere a dati di bassa latenza e di alta qualità senza compromettere l'integrità del sistema analitico del record.
I componenti principali di questo flusso includono:
- Origine: set di dati curati da un data warehouse di Fabric o Lakehouse (Delta).
- Trasformazioni: trasformazioni ETL inverse applicate tramite pipeline, Dataflow Gen2, Spark o T-SQL tra elementi.
- Destinazione: database SQL in Fabric con schemi definiti di destinazione, cronologia (facoltativo), quarantena e servizio.
- Consumer: applicazioni tramite GraphQL o TDS, API e Power BI per dashboard e report in tempo reale.
Components
I componenti seguenti sono coinvolti nel flusso generale per l'uso del database SQL in Fabric come destinazione ETL inversa.
Schemi di distribuzione e atterraggio
- Eseguire il mapping dei dati di origine agli schemi di destinazione appropriati nel database SQL in Fabric.
- Facoltativamente, mantenere uno
historyschema per la verificabilità. - Usare uno
quarantineschema per rifiutare (problemi di qualità dei dati). - Definire uno
servingschema per l'utilizzo downstream con vincoli e indicizzazione appropriati.
Orchestrazione
- Pianificare i trasferimenti in Fabric usando Pipelines, Dataflows o Spark Jobs.
- Usare la pianificazione predefinita per configurare la cadenza, l'ora di inizio e il fuso orario.
- Pianifica notebook Spark tramite il portale Fabric o l'API.
- Monitorare le esecuzioni end-to-end nel Fabric Monitoring hub.
Consumption
- Esporre i dati tramite endpoint GraphQL o T-SQL tramite TDS usando librerie client come ADO.NET (e altri).
- Creare dashboard e visualizzazioni di Power BI direttamente sul database SQL in Fabric.
Governance e sicurezza
- Usare Microsoft Entra ID per l'autenticazione e l'autorizzazione.
- Combinare le autorizzazioni dei ruoli dell'area di lavoro Fabric e le autorizzazioni SQL per un controllo granulare.
- Facoltativamente, configurare le chiavi gestite dal cliente per la crittografia dei dati inattivi.
- Controllare l'accesso e proteggere i dati in transito tramite collegamento privato.
Erogazione delle applicazioni
Dopo aver curato e aggiornato i dati nel database SQL, concentrarsi per abilitare l'accesso rapido e affidabile per gli utenti operativi. In questo contesto, l'applicazione che gestisce significa esporre set di dati attendibili tramite interfacce a bassa latenza allineate ai modelli di applicazione moderni.
Dopo che i dati vengono inseriti e aggiornati nel database SQL in Fabric:
- Per gestire i carichi di lavoro operativi, esporre i dati tramite endpoint GraphQL o il protocollo TDS , da usare tramite ADO.NET e altre librerie client. Ad esempio, fornire informazioni sul prodotto, supply chain o casi d'uso del servizio clienti.
- Associare il set di dati a Power BI per distribuire dashboard in tempo reale e analisi self-service.
Considerazioni specifiche del tessuto
Il database SQL in Fabric usa lo stesso motore di database SQL del database SQL di Azure ed è controllato, protetto, fatturato e gestito tramite il portale di Fabric. Offre anche il mirroring incorporato in file Delta/Parquet archiviati in Microsoft OneLake, a cui si accede tramite un endpoint di analisi SQL. Poiché si trova nell'ambiente Microsoft Fabric, è necessario tenere presenti alcune considerazioni quando si crea la progettazione:
- Parità delle funzionalità: il database SQL in Fabric sta convergendo con il database SQL di Azure. Convalidare funzionalità specifiche necessarie per assicurarsi che siano adatti allo scopo e monitorare gli aggiornamenti della roadmap.
- Modello di sicurezza: il database SQL in Fabric usa solo l'autenticazione con ID Entra Di Microsoft . Pianificare di conseguenza le identità per pipeline, flussi di dati e processi Spark.
- Replica: il database SQL in Fabric replica automaticamente i dati di sola lettura in OneLake. Questa sincronizzazione è utile per la creazione di report e le esigenze di analisi, mentre il database rimane disponibile per i carichi di lavoro operativi di lettura/scrittura.