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
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:
| Lakehouse | Magazzino | Eventhouse | |
|---|---|---|---|
| Volume dei dati | Nessun limite | Nessun limite | Nessun limite |
| Tipo di dati | Destrutturati semistrutturato, dati strutturati |
Strutturato semistrutturato (JSON) |
Destrutturati semistrutturato, dati strutturati |
| Utente sviluppatore principale | Ingegnere dei dati, scienziato dei dati | Sviluppatore di data warehouse, progettista dei dati, data engineer, sviluppatore di database | Sviluppatore di app, data scientist, data engineer |
| Competenza di sviluppo principale | Spark (Scala, PySpark, Spark SQL, R) | SQL | Senza codice, KQL, SQL |
| Dati organizzati per | 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 a più tabelle | No | Sì | Sì, per l'inserimento di più tabelle |
| Interfaccia di sviluppo principale | Notebook Spark, definizioni di processi Spark | Script SQL | Set di query KQL, database KQL |
| Sicurezza | Sicurezza a livello di riga, CLS**, livello di tabella (T-SQL), nessuno per Spark | Livello di oggetto, sicurezza a livello di riga, CLS, DDL/DML, maschera dati dinamica | Sicurezza a livello di riga |
| Accedere ai dati tramite i collegamenti | Sì | Sì | Sì |
| Può essere un'origine per i collegamenti | Sì (file e tabelle) | Yes: Stable | Sì |
| Eseguire query tra 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 avanzato per la formattazione | 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 |
| Latenza di inserimento | Disponibile immediatamente per l'esecuzione di query | Disponibile immediatamente per l'esecuzione di query | Inserimento in coda, inserimento in streaming ha una latenza di un paio di secondi |
* Spark supporta la lettura da tabelle tramite collegamenti, non supporta ancora l'accesso a viste, stored procedure, funzioni e così via.
| Database SQL dell'infrastruttura | Power BI Data mart | |
|---|---|---|
| Volume dei dati | 4 TB | Fino a 100 GB |
| Tipo di dati | Strutturato semistrutturato, dati non strutturati |
dati strutturati |
| Utente sviluppatore principale | Sviluppatore di intelligenza artificiale, sviluppatore di app, sviluppatore di database, amministratore del database | Data scientist, analista dei dati |
| Competenza di sviluppo principale | SQL | Senza codice, SQL |
| Dati organizzati per | Database, schemi, tabelle | Database, tabelle, query |
| 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 principale | Script SQL | Power BI |
| Sicurezza | Livello di oggetto, sicurezza a livello di riga, CLS, DDL/DML, maschera dati dinamica | Editor predefinito di sicurezza a livello di riga |
| Accedere ai dati tramite i collegamenti | Sì | No |
| Può essere un'origine per i collegamenti | Yes: Stable | No |
| Eseguire query tra elementi | Sì | No |
| Analisi avanzata | Funzionalità analitiche T-SQL, dati replicati in parquet differenziale in OneLake per l'analisi | Interfaccia per l'elaborazione dei dati con l'ottimizzazione automatizzata delle prestazioni |
| Supporto avanzato per la formattazione | 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 |
| Latenza di inserimento | Disponibile immediatamente per l'esecuzione di query | Disponibile immediatamente per l'esecuzione di query |
** Sicurezza a livello di colonna disponibile in Lakehouse tramite un endpoint di analisi SQL, usando T-SQL.
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. 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ù ampio, i principali utenti di questi dati sono anche esperti di strumenti analitici SQL e di SQL. 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, 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 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 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 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 i periodi attuali e precedenti, identificare rapidamente i problemi emergenti o fornire i dati analitici geospaziali 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 di database SQL di Azure. I database SQL in Fabric vengono ridimensionati automaticamente per soddisfare la domanda durante il giorno lavorativo. Hanno la funzionalità completa delle tabelle transazionali e la flessibilità dei livelli di isolamento delle transazioni da serializzabili a snapshot di cui è stato eseguito il commit di lettura. 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 aggiunti ad altri dati in Fabric: in Spark, in un warehouse e da eventi in tempo reale in un'istanza di Eventhouse. Ogni database di Infrastruttura include un endpoint di analisi SQL, in modo che i dati siano accessibili in tempo reale da Spark o con query di Power BI tramite la 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.