Scegliere un archivio dati analitici in Azure
In un'architettura per Big Data è spesso necessario un archivio dati analitici in grado di servire dati elaborati in un formato strutturato su cui è possibile eseguire query con strumenti di analisi. Gli archivi dati analitici che supportano l'esecuzione di query per ottenere dati dal percorso ad accesso frequente e da quello ad accesso sporadico sono collettivamente denominati livello di gestione o archiviazione di gestione dati.
Al livello di gestione vengono trattati i dati elaborati ottenuti da entrambi i percorsi. Nell'architettura lambda il livello di gestione è suddiviso in un livello di elaborazione rapida, che archivia i dati elaborati in modo incrementale, e in un livello di elaborazione batch, che contiene l'output elaborato in batch. Il livello di gestione richiede un solido supporto per le operazioni di lettura casuali a bassa latenza. L'archiviazione dei dati per il livello di elaborazione rapida deve supportare anche le operazioni di scrittura casuali perché il caricamento dei dati in batch nell'archivio causerebbe ritardi indesiderati. Al contrario, l'archiviazione dei dati per il livello di elaborazione batch non deve supportare le operazioni di scrittura casuali, ma solo quelle in batch.
Non esiste un'unica soluzione di gestione dei dati ottimale per tutte le attività di archiviazione dei dati. Le soluzioni più adatte variano in base alle attività da eseguire. La maggior parte delle app cloud e dei processi su Big Data nel mondo reale presenta un'ampia varietà di requisiti di archiviazione dei dati e spesso sfrutta una combinazione di soluzioni di archiviazione.
Opzioni disponibili per la scelta di un archivio dati analitici
Sono disponibili diverse opzioni per l'archiviazione di gestione dati in Azure, in base alle esigenze specifiche:
- Azure Synapse Analytics
- Pool di Spark di Azure Synapse
- Azure Databricks
- Esplora dati di Azure
- Database SQL di Azure
- SQL Server in una macchina virtuale di Azure
- HBase/Phoenix in HDInsight
- Hive LLAP in HDInsight
- Azure Analysis Services
- Azure Cosmos DB
Queste opzioni offrono vari modelli di database ottimizzati per diversi tipi di attività:
- I database a chiave-valore contengono un singolo oggetto serializzato per ogni valore di chiave. Sono utili per archiviare grossi volumi di dati quando si vuole ottenere un solo elemento per un determinato valore di chiave e non si devono eseguire query in base ad altre proprietà dell'elemento.
- I database a documenti sono database chiave-valore in cui i valori sono costituiti da documenti. In questo contesto, per "documento" si intende una raccolta di valori e campi con nome. Il database archivia in genere i dati in un formato, ad esempio XML, YAML, JSON o JSON binario (BSON), ma può usare testo normale. I database a documenti possono eseguire query su campi non chiave e definire indici secondari per rendere più efficiente il processo di query. Sono quindi più adatti per le applicazioni che devono recuperare dati in base a criteri più complessi rispetto al valore della chiave del documento. Sono ad esempio utili per eseguire query sui campi relativi a ID prodotto, ID cliente o nome del cliente.
- I database dell'archivio colonne sono archivi dati chiave/valore che archiviano ogni colonna separatamente su disco. Un database dell'archivio colonne wide è un tipo di database dell'archivio colonne che archivia le famiglie di colonne, non solo singole colonne. Ad esempio, un database di censimento potrebbe avere una famiglia di colonne per il nome di una persona (prima, middle, last), una famiglia per l'indirizzo della persona e una famiglia per le informazioni sul profilo della persona (data di nascita, sesso). Il database può archiviare ogni famiglia di colonne in una partizione separata, mantenendo tutti i dati per una persona correlata alla stessa chiave. In questo modo, un'applicazione può leggere una singola famiglia di colonne senza dover leggere tutti i dati relativi a un'entità.
- I database a grafo archiviano le informazioni come una raccolta di oggetti e relazioni. Un database a grafo può eseguire in modo efficiente query in grado di attraversare la rete degli oggetti e le relazioni tra di essi. Gli oggetti possono ad esempio essere costituiti da dipendenti all'interno di un database delle risorse umane e può essere necessario eseguire query rapide per cercare tutti i dipendenti che lavorano direttamente o indirettamente per un determinato responsabile.
- I database di telemetria e serie temporali sono una raccolta di oggetti di sola accodamento. I database di telemetria indicizzano in modo efficiente i dati in un'ampia gamma di archivi colonne e strutture in memoria, rendendoli la scelta ottimale per l'archiviazione e l'analisi di grandi quantità di dati di telemetria e di serie temporali.
Criteri di scelta principali
Per limitare le possibilità di scelta, rispondere prima di tutto a queste domande:
È necessaria una soluzione di archiviazione di gestione che possa essere usata come percorso ad accesso frequente per i dati? In caso affermativo, limitare la scelta alle opzioni ottimizzate per un livello di elaborazione rapida.
È necessario il supporto per l'elaborazione parallela elevata (MPP, Massively Parallel Processing), in cui le query vengono distribuite automaticamente tra più processi o nodi? In caso affermativo, selezionare un'opzione che supporta la scalabilità orizzontale delle query.
Si preferisce usare un archivio dati relazionale? In caso affermativo, limitare la scelta alle opzioni con un modello di database relazionale. Si noti tuttavia che alcuni archivi non relazionali supportano la sintassi SQL per le query e che è possibile usare strumenti come PolyBase per eseguire query su archivi dati non relazionali.
Si raccolgono dati di serie temporali? Si usano dati di solo accodamento?
Matrice delle funzionalità
Le tabelle seguenti contengono un riepilogo delle differenze principali in termini di funzionalità.
Funzionalità generali
| Funzionalità | Database SQL | Pool SQL di Azure Synapse | Pool di Spark di Azure Synapse | Esplora dati di Azure | HBase/Phoenix in HDInsight | Hive LLAP in HDInsight | Azure Analysis Services | Azure Cosmos DB |
|---|---|---|---|---|---|---|---|---|
| Servizio gestito | Sì | Sì | Sì | Sì | Sì 1 | Sì 1 | Sì | Sì |
| Modello di database primario | Relazionale (formato archivio colonne quando si usano indici columnstore) | Tabelle relazionali con archiviazione di colonne | Archivio a colonne esteso | Archivio relazionale (archivio colonne), dati di telemetria e serie temporali | Archivio a colonne esteso | Hive/In memoria | Modelli semantici tabulari | Archivio a documenti, a grafo, a chiave-valore, a colonne esteso |
| Supporto per il linguaggio SQL | Sì | Sì | Sì | Sì | Sì (con driver JDBC Phoenix) | Sì | No | Sì |
| Ottimizzato per un livello di elaborazione rapida | Sì 2 | Sì 3 | Sì | Sì | Sì | Sì | No | Sì |
[1] Con configurazione e scalabilità manuali.
[2] Con tabelle ottimizzate per la memoria e indici hash o non cluster.
[3] Supportato come output di Analisi di flusso di Azure.
Funzionalità di scalabilità
| Funzionalità | Database SQL | Pool SQL di Azure Synapse | Pool di Spark di Azure Synapse | Esplora dati di Azure | HBase/Phoenix in HDInsight | Hive LLAP in HDInsight | Azure Analysis Services | Azure Cosmos DB |
|---|---|---|---|---|---|---|---|---|
| Server regionali ridondanti per disponibilità elevata | Sì | No | No | Sì | Sì | No | Sì | Sì |
| Supporta la scalabilità orizzontale delle query | No | Sì | Sì | Sì | Sì | Sì | Sì | Sì |
| Scalabilità dinamica (aumento delle prestazioni) | Sì | Sì | Sì | Sì | No | No | Sì | Sì |
| Supporto per la memorizzazione nella cache dei dati in memoria | Sì | Sì | Sì | Sì | No | Sì | Sì | No |
Funzionalità di sicurezza
| Funzionalità | Database SQL | Azure Synapse | Esplora dati di Azure | HBase/Phoenix in HDInsight | Hive LLAP in HDInsight | Azure Analysis Services | Azure Cosmos DB |
|---|---|---|---|---|---|---|---|
| Autenticazione | SQL/Microsoft Entra ID | SQL/Microsoft Entra ID | Microsoft Entra ID | local/Microsoft Entra ID 1 | local/Microsoft Entra ID 1 | Microsoft Entra ID | utenti di database/Microsoft Entra ID tramite il controllo di accesso (gestione delle identità e degli accessi)) |
| Crittografia dei dati inattivi | Sì 2 | Sì 2 | Sì | Sì 1 | Sì 1 | Sì | Sì |
| Sicurezza a livello di riga | Sì | Sì 3 | Sì | Sì 1 | Sì 1 | Sì | No |
| Supporto dei firewall | Sì | Sì | Sì | Sì 4 | Sì 4 | Sì | Sì |
| Maschera dati dinamica | Sì | Sì | Sì | Sì 1 | Sì | No | No |
[1] Richiede l'uso di un cluster HDInsight aggiunto al dominio.
[2] Richiede l'uso di Transparent Data Encryption per crittografare e decrittografare i dati inattivi.
[3] Filtra solo i predicati. Vedere Sicurezza a livello di riga
[4] Se usato all'interno di una rete virtuale di Azure. Per altre informazioni, vedere Estendere Azure HDInsight usando un Rete virtuale di Azure.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Zoiner Tejada | CEO e architetto
Passaggi successivi
- Analizzare i dati in un data warehouse relazionale
- Creare un database singolo - Database SQL di Azure
- Creare un'area di lavoro di Azure Databricks
- Creare un cluster Apache Spark in Azure HDInsight usando portale di Azure
- Creazione di un'area di lavoro di Synapse
- Esplorare i servizi dati di Azure per l'analisi moderna
- Esplorare i servizi di analisi e database di Azure
- Eseguire query su Azure Cosmos DB usando l'API per NoSQL