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:

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. I dati del database sono in genere archiviati in un determinato formato, ad esempio XML, YAML, JSON o BSON, ma possono essere presenti anche in formato 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 solo 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 Azure Data Explorer HBase/Phoenix in HDInsight Hive LLAP in HDInsight Azure Analysis Services Azure Cosmos DB
Servizio gestito 1 1
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ì (con driver JDBC Phoenix) No
Ottimizzato per un livello di elaborazione rapida 2 3 No

[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 Azure Data Explorer HBase/Phoenix in HDInsight Hive LLAP in HDInsight Azure Analysis Services Azure Cosmos DB
Server regionali ridondanti per disponibilità elevata No No No
Supporta la scalabilità orizzontale delle query No
Scalabilità dinamica (aumento delle prestazioni) No No
Supporto per la memorizzazione nella cache dei dati in memoria No No

Funzionalità di sicurezza

Funzionalità Database SQL Azure Synapse Azure Data Explorer HBase/Phoenix in HDInsight Hive LLAP in HDInsight Azure Analysis Services Azure Cosmos DB
Authentication 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 (IAM)
Crittografia dei dati inattivi 2 2 1 1
Sicurezza a livello di riga 3 1 1 No
Supporto dei firewall 4 4
Maschera dati dinamica 1 No No

[1] Richiede l'uso di un cluster HDInsight aggiunto al dominio.

[2] Richiede l'uso della crittografia TDE (Transparent Data Encryption) per crittografare e decrittografare i dati inattivi.

[3] Filtra solo i predicati. Vedere Sicurezza a livello di riga

[4] Quando è usato all'interno di una rete virtuale di Azure. Vedere Estendere Azure HDInsight usando Rete virtuale di Azure.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Passaggi successivi