Guida alle decisioni 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
Usare queste informazioni per confrontare archivi dati di Fabric, ad esempio warehouse, lakehouse, eventhouse, database SQL e Datamart di Power BI, in base al volume di dati, al tipo, all'utente sviluppatore, al set di competenze, alle operazioni e ad altre funzionalità. Questi confronti sono organizzati nelle due tabelle seguenti:
| Tabella 1 di 2 | Lakehouse | Magazzino | Eventhouse |
|---|---|---|---|
| volume di dati | Illimitato | Illimitato | Illimitato |
| Tipo di dati | Non strutturato semistrutturato strutturato |
Strutturato semistrutturato (JSON) |
Non strutturato semistrutturato, strutturato |
| Persona sviluppatore principale | Ingegnere dei dati, Scienziato dei dati | Sviluppatore di data warehouse, progettista dei dati, data engineer, sviluppatore di database | Sviluppatore di app, scienziato dei dati, ingegnere dei dati |
| Competenza principale di sviluppo | Spark (Scala, PySpark, Spark SQL, R) | SQL | Nessun codice, KQL, SQL |
| Dati organizzati da | Cartelle e file, database e tabelle | Database, schemi e tabelle | Database, schemi e tabelle |
| operazioni di lettura | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| operazioni di scrittura | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, ecosistema di connettori |
| transazioni su più tabelle | No | Sì | Sì, per l'inserimento di più tabelle |
| Interfaccia di sviluppo primaria | Notebook Spark, definizioni di job Spark | Script SQL | KQL Queryset, KQL Database |
| sicurezza | RLS, CLS**, a livello di tabella (T-SQL), nessuno per Spark | livello oggetto, RLS, CLS, DDL/DML, mascheramento dinamico dei dati | Sicurezza a livello di riga (RLS) |
| Accedere ai dati tramite collegamenti | Sì | Sì, tramite l'endpoint di analisi SQL | Sì |
| può essere un'origine per le scorciatoie | Sì (file e tabelle) | Sì (tabelle) | Sì |
| query tra gli elementi | Sì | Sì | Sì |
| Analisi avanzata | Interfaccia per l'elaborazione dei dati su larga scala, il parallelismo dei dati predefinito e la tolleranza di errore | Interfaccia per l'elaborazione dei dati su larga scala, il parallelismo dei dati predefinito e la tolleranza di errore | Elementi nativi delle serie temporali, funzionalità complete di spazio geografico e query |
| supporto per la formattazione avanzata | Tabelle definite con PARQUET, CSV, AVRO, JSON e qualsiasi formato di file compatibile con Apache Hive | Tabelle definite con PARQUET, CSV, AVRO, JSON e qualsiasi formato di file compatibile con Apache Hive | Indicizzazione completa per dati di testo libero e semistrutturati come JSON |
| la latenza di ingestione | Disponibile immediatamente per effettuare query | Disponibile immediatamente per le query | L'inserimento in coda e l'inserimento in streaming ha una latenza di un paio di secondi. |
* Spark supporta la lettura da tabelle tramite scorciatoie, ma non supporta ancora l'accesso a viste, stored procedure e funzioni.
| Tabella 2 di 2 | il database SQL diFabric | Power BI Datamart |
|---|---|---|
| volume di dati | 4 TB | Fino a 100 GB |
| Tipo di dati | Strutturato semistrutturato Non strutturato |
Strutturato |
| Persona principale dello sviluppatore | Sviluppatore di intelligenza artificiale, sviluppatore di app, sviluppatore di database, amministratore del database | Data scientist, analista dei dati |
| Competenza principale di sviluppo | SQL | Nessun codice, SQL |
| Dati organizzati da | Database, schemi, tabelle | Database, tabelle, interrogazioni |
| operazioni di lettura | T-SQL | Spark, T-SQL |
| operazioni di scrittura | T-SQL | Flussi di dati, T-SQL |
| transazioni a più tabelle | Sì, conformità ACID completa | No |
| Interfaccia di sviluppo primaria | Script SQL | Power BI |
| Sicurezza | Livello oggetto, RLS, CLS, DDL/DML, mascheramento dati dinamico | Editor RLS integrato |
| Accedere ai dati tramite collegamenti | Sì | No |
| può essere una fonte per le scorciatoie | Sì (tabelle) | No |
| query tra gli elementi | Sì | No |
| Analitica avanzata | Funzionalità analitiche T-SQL, dati replicati in Delta Parquet in OneLake per l'analisi | Interfaccia per l'elaborazione dei dati con l'ottimizzazione automatizzata delle prestazioni |
| supporto per la formattazione avanzata | Supporto delle tabelle per OLTP, JSON, vector, graph, XML, spatial, key-value | Tabelle definite con PARQUET, CSV, AVRO, JSON e qualsiasi formato di file compatibile con Apache Hive |
| la latenza di ingestione | Disponibile immediatamente per le query | Disponibile immediatamente per le interrogazioni |
** Sicurezza a livello di colonna disponibile in Lakehouse tramite un endpoint di analisi SQL, usando T-SQL.
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
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 sono analisti, che hanno 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'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 5
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 di dati con Fabric Data Factory per importare dati nel database SQL dell'infrastruttura.