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.
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 effettuare 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.
** Sicurezza a livello di colonna disponibile in Lakehouse tramite un endpoint di analisi SQL, usando T-SQL.
| Tabella 2 di 2 | il database SQL diFabric |
|---|---|
| volume di dati | 4 TB |
| Tipo di dati | Strutturato semistrutturato Non strutturato |
| Persona sviluppatore principale | Sviluppatore di intelligenza artificiale, sviluppatore di app, sviluppatore di database, amministratore del database |
| Competenza principale di sviluppo | SQL |
| Dati organizzati da | Database, schemi, tabelle |
| operazioni di lettura | T-SQL |
| operazioni di scrittura | T-SQL |
| transazioni su più tabelle | Sì, conformità ACID completa |
| Interfaccia di sviluppo primaria | Script SQL |
| sicurezza | Livello oggetto, RLS, CLS, DDL/DML, mascheramento dati dinamico |
| Accedere ai dati tramite collegamenti | Sì |
| può essere un'origine per le scorciatoie | Sì (tabelle) |
| query tra gli elementi | Sì |
| Analisi avanzata | Funzionalità analitiche T-SQL, dati replicati in Delta Parquet in OneLake per l'analisi |
| supporto per la formattazione avanzata | Supporto delle tabelle per OLTP, JSON, vector, graph, XML, spatial, key-value |
| la latenza di ingestione | Disponibile immediatamente per effettuare query |
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 di dati con Fabric Data Factory per importare dati nel database SQL dell'infrastruttura.