Guida alle decisioni di Microsoft Fabric: scegliere un archivio dati

  • Articolo

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

Data warehouse Lakehouse Power BI Datamart Database KQL (Eventhouse)
Volume di dati Nessun limite Nessun limite Fino a 100 GB Nessun limite
Tipo di dati dati strutturati Non strutturato, semistrutturato, strutturato dati strutturati Non strutturato, semistrutturato, strutturato
Persona dello sviluppatore principale Sviluppatore di Data Warehouse, tecnico SQL Data engineer, data scientist Sviluppatore cittadino Citizen Data scientist, Data engineer, Data scientist, SQL Engineer
Set di competenze per sviluppatori primario SQL Spark(Scala, PySpark, Spark SQL, R) Nessun codice, SQL Nessun 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 a viste, stored procedure, fuction 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 di più tabelle. Vedere Criteri di aggiornamento.
Interfaccia di sviluppo principale Script SQL Notebook Spark, definizioni di processi Spark Power BI KQL Queryset, KQL Database
Sicurezza Livello di oggetto (tabella, vista, funzione, stored procedure e così via), livello di colonna, livello di riga, DDL/DML, maschera dati dinamica Livello di riga, 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 collegamenti Sì (indirettamente attraverso il lago) Sì No Sì
Può essere un'origine per i collegamenti Sì (tabelle) Sì (file e tabelle) No Sì
Eseguire query tra elementi Sì, eseguire una query tra tabelle lakehouse e warehouse Sì, eseguire una 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
Analisi avanzata Elementi nativi time series, funzionalità di archiviazione geospaziale completa e query
Supporto avanzato per la formattazione Indicizzazione completa per dati di testo libero e semistrutturati come JSON
Latenza di inserimento Inserimento in coda, l'inserimento in streaming ha una latenza di un paio di secondi

Nota

Eventhouse è un'area di lavoro per più database KQL. Il database KQL è disponibile a livello generale, mentre Eventhouse è in anteprima. Per altre informazioni, vedere Panoramica di Eventhouse (anteprima).

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 consumer di questi dati sono anche esperti con strumenti analitici SQL e SQL. Susan decide di usare un data warehouse, che consente al team di interagire principalmente con T-SQL, consentendo anche a qualsiasi utente Spark dell'organizzazione di accedere ai dati.

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 IN edizione Standard RT, 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

Ash, uno sviluppatore cittadino, è uno sviluppatore di Power BI. Hanno familiarità con Excel, Power BI e Office. Devono creare un prodotto dati per una business unit. Sanno che non hanno abbastanza le competenze per creare un data warehouse o una lakehouse e quelli sembrano troppo per le loro esigenze e volumi di dati. Esaminano i dettagli nella tabella precedente e vedono che i punti decisionali principali sono le proprie competenze e la loro necessità di un self-service, 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 pensano al team più grande, si rendono conto che i principali consumer di questi dati possono essere analisti, familiarità con gli strumenti analitici senza codice e SQL. Ash decide di usare un datamart 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 business analyst esperto nell'uso di Power BI per analizzare i colli di bottiglia della supply chain per una grande catena di vendita al dettaglio globale. È 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 database KQL 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.

Contenuto correlato