Guida decisionale di Microsoft Fabric: scegliere un archivio dati
Usare questa guida di riferimento e gli scenari di esempio per scegliere un archivio dati per i carichi di lavoro di Microsoft Fabric.
Proprietà dell'archivio dati
Questa tabella confronta gli archivi dati, ad esempio warehouse, lakehouse, data mart di Power BI ed eventhouse in base al volume di dati, al tipo, all'utente sviluppatore, al set di competenze, alle operazioni. e altre funzionalità.
| Warehouse | Lakehouse | Power BI Data mart | Eventhouse | |
|---|---|---|---|---|
| Volume dei dati | Nessun limite | Nessun limite | Fino a 100 GB | Illimitato |
| Tipo di dati | dati strutturati | Non strutturati, semistrutturati, strutturati | dati strutturati | Non strutturati, semistrutturati, strutturati |
| Utente sviluppatore principale | Sviluppatore di data warehouse, sviluppatore SQL | Ingegnere dei dati, scienziato dei dati | Citizen developer | Scienziato dei dati Citizen, ingegnere dei dati, scienziato dei dati, sviluppatore SQL |
| Set di competenze per sviluppatori primario | SQL | Spark (Scala, PySpark, Spark SQL, R) | Senza codice, SQL | Senza codice, KQL, SQL |
| Dati organizzati per | Database, schemi e tabelle | Cartelle e file, database e tabelle | Database, tabelle, query | Database, schemi e tabelle |
| Operazioni di lettura | T-SQL, Spark (supporta la lettura da tabelle tramite collegamenti, non supporta ancora l'accesso alle viste, stored procedure, funzioni e così via) | Spark, T-SQL | Spark, T-SQL, Power BI | KQL, T-SQL, Spark, Power BI |
| Operazioni di scrittura | T-SQL | Spark (Scala, PySpark, Spark SQL, R) | Flussi di dati, T-SQL | KQL, Spark, ecosistema di connettori |
| Transazioni a più tabelle | Sì | No | No | Sì, per l'inserimento a più tabelle. Vedere Criteri di aggiornamento. |
| Interfaccia di sviluppo principale | Script SQL | Notebook Spark, definizioni processo Spark | Power BI | Set di query KQL, database KQL |
| Sicurezza | Livello di oggetto (tabella, vista, funzione, stored procedure e così via), livello di colonna, livello di riga, DDL/DML, Dynamic Data Masking | Livello di riga, livello di colonna (per lakehouse si accede tramite un endpoint di analisi SQL), livello di tabella (quando si usa T-SQL), nessuno per Spark | Editor predefinito di sicurezza a livello di riga | Sicurezza a livello di riga |
| Accedere ai dati tramite i collegamenti | Sì, attraverso un lakehouse usando nomi in tre parti | Sì | No | Sì |
| Può essere un'origine per i collegamenti | Yes: Stable | Sì (file e tabelle) | No | Sì |
| Eseguire query tra elementi | Sì, eseguire query tra tabelle lakehouse e warehouse | Sì, eseguire query tra tabelle lakehouse e warehouse; eseguire query tra lakehouse (inclusi i collegamenti con Spark) | No | Sì, eseguire query tra database KQL, lakehouse e warehouse con collegamenti |
Scenari
Esaminare questi scenari per ricevere informazioni utili per la scelta di un archivio dati in Fabric.
Scenario 1
Susan, sviluppatrice professionista, è nuova in Microsoft Fabric. È pronta per iniziare a pulire, modellare e analizzare i dati, ma deve decidere se creare un data warehouse o un 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ù ampio, i principali utenti di questi dati sono anche esperti di strumenti analitici SQL e di SQL. Susan decide di usare un data warehouse, che consente al team di interagire principalmente con T-SQL, permettendo anche a qualsiasi utente Spark dell'organizzazione di accedere ai dati.
Susan crea un nuovo lakehouse e accede alle funzionalità del data warehouse con l'endpoint di analisi SQL lakehouse. Attraverso il portale di Fabric, crea collegamenti alle tabelle dati esterne e li inserisce nella cartella /Tables. Ora Susan può scrivere query T-SQL che fanno riferimento a collegamenti per eseguire query sui dati Delta Lake nel lakehouse. I collegamenti vengono visualizzati automaticamente come tabelle nell'endpoint di analisi SQL e possono essere sottoposti a query con T-SQL usando nomi in tre parti.
Scenario 2
Rob, ingegnere dei dati, 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 è costituita da utenti, 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 diversificate rispetto ai dati, permettendo ai membri del team altamente qualificati in T-SQL di utilizzare i dati.
Scenario 3
Ash, Citizen Developer, è uno sviluppatore di Power BI. Ha familiarità con Excel, Power BI e Office. Deve creare un prodotto dati per una business unit. Sa di non avere le competenze per creare un data warehouse o un lakehouse, e questi sembrano esagerati per le loro esigenze e volumi di dati. Esamina i dettagli nella tabella precedente e nota che i punti decisionali principali sono le proprie competenze e la necessità di una capacità di servizio autonomo, nessuna funzionalità di codice e un volume di dati inferiore a 100 GB.
Ash collabora con gli analisti aziendali che hanno familiarità con Power BI e Microsoft Office e sa che hanno già una sottoscrizione di capacità Premium. Quando pensa al team più ampio, si rende conto che i principali utenti di questi dati possono essere analisti, che hanno familiarità con gli strumenti analitici senza codice e SQL. Ash decide di usare un data mart di Power BI, che consente al team di interagire rapidamente per creare la funzionalità, usando un'esperienza senza codice. Le query possono essere eseguite tramite Power BI e T-SQL, consentendo anche a qualsiasi utente Spark dell'organizzazione di accedere ai dati.
Scenario 4
Daisy è un’analista aziendale esperta nell'uso di Power BI per analizzare i colli di bottiglia della catena di approvvigionamento di una grande catena di vendita al dettaglio a livello mondiale. Ha la necessità di creare una soluzione di dati scalabile in grado di gestire miliardi di righe di dati e che possa essere usata per creare dashboard e report da impiegare per prendere decisioni aziendali. I dati provengono da stabilimenti produttivi, fornitori, spedizionieri e altre fonti in vari formati strutturati, semistrutturati e non strutturati.
Daisy decide di usare una eventhouse per la scalabilità, i tempi di risposta rapidi, le funzionalità di analisi avanzate, tra cui l'analisi delle serie temporali, le funzioni geospaziali e la modalità di query diretta e veloce in Power BI. Le query possono essere eseguite usando Power BI e KQL per confrontare i periodi attuali e precedenti, identificare rapidamente i problemi emergenti o fornire i dati analitici geospaziali delle rotte terrestri e marittime.