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.
Usare questa guida di riferimento e gli scenari di esempio per scegliere un archivio dati per i carichi di lavoro di Microsoft Fabric, tutti disponibili in una risorsa di archiviazione unificata in OneLake.
| Caso d'uso ideale | Carico di lavoro di Microsoft Fabric | Dati disponibili in OneLake in formato tabella aperta per impostazione predefinita |
|---|---|---|
| Streaming di dati dell'evento, granularità elevata (in tempo, spazio, dettaglio - JSON/Testo) per l'analisi interattiva | Eventhouse | Sì |
| Intelligenza artificiale, NoSQL e ricerca vettoriale | Cosmos DB in Fabric (anteprima) | Sì |
| Database transazionale operativo, database OLTP | Database SQL in Fabric (anteprima) | Sì |
| Enterprise Data Warehouse, BI basato su SQL, OLAP, supporto completo delle transazioni SQL | Data warehouse | Sì |
| Big Data e Machine Learning, dati non/semi/strutturati, ingegneria dei dati | Lakehouse | Sì |
Utenti e set di competenze
| Carico di lavoro di Microsoft Fabric | Utenti di sviluppatori principali | Set di competenze principali, strumenti | Lingue principali |
|---|---|---|---|
| Eventhouse | Sviluppatore di app, data scientist, data engineer | Nessun codice, KQL, SQL | KQL (linguaggio di query Kusto), T-SQL |
| Cosmos DB in Fabric (anteprima) | Sviluppatore di intelligenza artificiale, sviluppatore di app | Concetti relativi a NoSQL, API REST simili ad Azure Cosmos DB | Integrazione dell'API REST tramite JavaScript/TypeScript, Python, C#, Java e altri |
| Database SQL in Fabric (anteprima) | Sviluppatore di intelligenza artificiale, sviluppatore di app, sviluppatore di database, amministratore del database | Amministrazione e sviluppo di database, simili a database SQL di Azure, SSMS, VS Code e strumenti di query compatibili con SQL Server | T-SQL |
| Data warehouse Fabric | Sviluppatore di data warehouse, progettista di dati, data engineer, sviluppatore di database | Concetti relativi al data warehousing, progettazione di database con schema star, SSMS, VS Code e strumenti di query compatibili con SQL Server | T-SQL, Nessun codice |
| Lakehouse | Ingegnere dei dati, Scienziato dei dati | PySpark, Delta Lake, notebook | Spark (Scala, PySpark, Spark SQL, R) |
Scenari
Esaminare questi scenari per informazioni sulla scelta di un archivio dati in Fabric.
Scenario 1
Susan, uno sviluppatore professionista, è una novità di Microsoft Fabric. Sono pronti per iniziare a pulire, modellare e analizzare i dati, ma devono decidere di creare un data warehouse o una lakehouse. Dopo aver esaminato i dettagli nella tabella precedente, i punti decisionali principali sono il set di competenze disponibile e la necessità di transazioni a più tabelle.
Susan ha trascorso molti anni nella creazione di data warehouse su motori di database relazionali e ha familiarità con la sintassi e le funzionalità di SQL. Pensando al team più grande, i principali consumatori di questi dati sono anche esperti con SQL e strumenti analitici. Susan decide di usare un Fabric warehouse, che consente al team di interagire principalmente con T-SQL, consentendo anche a qualsiasi utente Spark dell'organizzazione di accedere ai dati.
Susan crea un nuovo data warehouse e interagisce con esso usando T-SQL esattamente come gli altri database di SQL Server. La maggior parte del codice T-SQL esistente che ha scritto per compilare il proprio warehouse in SQL Server funzionerà sul data warehouse di Fabric semplificando la transizione. Se sceglie di, può anche usare gli stessi strumenti che funzionano con gli altri database, ad esempio SQL Server Management Studio. Usando l'editor SQL nel portale di Fabric, Susan e altri membri del team scrivono query analitiche che fanno riferimento ad altri data warehouse e tabelle Delta in lakehouse semplicemente usando nomi in tre parti per eseguire query tra database.
Scenario 2
Rob, un data engineer, deve archiviare e modellare diversi terabyte di dati in Fabric. Il team ha una combinazione di competenze di PySpark e T-SQL. La maggior parte del team che esegue query T-SQL sono consumer e pertanto non è necessario scrivere istruzioni INSERT, UPDATE o DELETE. Gli sviluppatori rimanenti hanno familiarità con il funzionamento dei notebook e, poiché i dati vengono archiviati in Delta, possono interagire con una sintassi SQL simile.
Rob decide di usare un lakehouse, che consente al team di ingegneria dei dati di usare le proprie competenze diverse rispetto ai dati, consentendo ai membri del team altamente qualificati in T-SQL di utilizzare i dati.
Scenario 3
Daisy è un'analista aziendale esperta nell'uso di Power BI per analizzare i colli di bottiglia della catena di approvvigionamento per una grande catena globale di vendita al dettaglio. È necessario creare una soluzione di dati scalabile in grado di gestire miliardi di righe di dati e può essere usata per creare dashboard e report che possono essere usati per prendere decisioni aziendali. I dati provengono da impianti, fornitori, spedizionieri e altre fonti in vari formati strutturati, semistrutturati e non strutturati.
Daisy decide di usare un Eventhouse grazie alla scalabilità, ai tempi di risposta rapidi, alle funzionalità di analisi avanzate, tra cui l'analisi delle serie temporali, le funzioni geospaziali e la modalità di query diretta veloce in Power BI. Le query possono essere eseguite usando Power BI e KQL per confrontare tra i periodi correnti e precedenti, identificare rapidamente i problemi emergenti o fornire analisi geospaziale delle rotte terrestri e marittime.
Scenario 4
Kirby è un progettista di applicazioni esperto nello sviluppo di applicazioni .NET per i dati operativi. Hanno bisogno di un database a concorrenza elevata con conformità completa delle transazioni ACID e chiavi esterne fortemente applicate per l'integrità relazionale. Kirby vuole il vantaggio dell'ottimizzazione automatica delle prestazioni per semplificare la gestione quotidiana dei database.
Kirby decide di usare un database SQL in Fabric, con lo stesso motore di database SQL del database SQL di Azure. I database SQL in Fabric vengono ridimensionati automaticamente per soddisfare la domanda durante il giorno lavorativo. Hanno la piena funzionalità delle tabelle transazionali e la flessibilità dei livelli di isolamento delle transazioni da serializzabile a snapshot di lettura confermata. Il database SQL in Fabric crea e elimina automaticamente indici non cluster in base a segnali sicuri dei piani di esecuzione osservati nel tempo.
Nello scenario di Kirby, i dati dell'applicazione operativa devono essere uniti ad altri dati in Fabric: in Spark, in un magazzino dati e da eventi in tempo reale in un'istanza di Eventhouse. Ogni database Fabric include un endpoint di analisi SQL, permettendo l'accesso in tempo reale ai dati da Spark o tramite query di Power BI in modalità DirectLake. Queste soluzioni di creazione di report risparmiano il database operativo primario dal sovraccarico dei carichi di lavoro analitici ed evitano la denormalizzazione. Kirby dispone anche di dati operativi esistenti in altri database SQL e deve importare tali dati senza trasformazione. Per importare dati operativi esistenti senza alcuna conversione dei tipi di dati, Kirby progetta pipeline con Fabric Data Factory per importare dati nel database SQL di Fabric.