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.
Questo articolo fornisce linee guida sulle procedure consigliate che consentono di ottimizzare le prestazioni, ridurre i costi e proteggere l'account di Archiviazione di Azure abilitato per Data Lake Storage.
Trova la documentazione
Azure Data Lake Storage non è un servizio dedicato né un tipo di account di archiviazione. Si tratta di un set di funzionalità che supportano carichi di lavoro analitici a velocità effettiva elevata. La documentazione di Data Lake Storage fornisce procedure consigliate e indicazioni per l'uso di queste funzionalità. Per tutti gli altri aspetti della gestione degli account, ad esempio la configurazione della sicurezza di rete, la progettazione per la disponibilità elevata e il ripristino di emergenza, vedere il contenuto della documentazione sull'archiviazione BLOB.
Valutare il supporto delle funzionalità e i problemi noti
Usare il modello seguente durante la configurazione dell'account per l'uso delle funzionalità di archiviazione BLOB.
Consulta l'articolo Supporto delle funzionalità di Archiviazione BLOB negli account di Archiviazione di Azure per determinare se una funzionalità è completamente supportata nel tuo account. Alcune funzionalità non sono ancora supportate o hanno supporto parziale negli account abilitati per Data Lake Storage. Il supporto delle funzionalità è sempre in espansione, quindi assicurarsi di esaminare periodicamente questo articolo per gli aggiornamenti.
Vedere l'articolo Problemi noti relativi ad Azure Data Lake Storage per verificare se sono presenti limitazioni o indicazioni speciali sulla funzionalità che si intende usare.
Analizzare gli articoli sulle funzionalità per eventuali indicazioni specifiche per gli account abilitati per Data Lake Storage.
Comprendere i termini usati nella documentazione
Quando si passa da un set di contenuto all'altro, si notano alcune lievi differenze di terminologia. Ad esempio, il contenuto incluso nella documentazione dell'archiviazione BLOB usa il termine BLOB anziché file. Tecnicamente, i file che carichi nel tuo account di archiviazione diventano blob nel tuo account. Pertanto, il termine è corretto. Tuttavia, il termine BLOB può causare confusione se si usa il termine file. Si vede anche il termine contenitore utilizzato per riferirsi a un file system. È opportuno considerare questi termini come sinonimi.
Prendere in considerazione premium
Se i carichi di lavoro richiedono una bassa latenza coerente o richiedono un numero elevato di operazioni di output di input al secondo (IOPS), è consigliabile usare un account di archiviazione BLOB in blocchi Premium. Questo tipo di account rende i dati disponibili tramite hardware ad alte prestazioni. I dati vengono archiviati in unità SSD ottimizzate per la bassa latenza. Le unità SSD offrono una velocità effettiva superiore rispetto ai dischi rigidi tradizionali. I costi di archiviazione delle prestazioni Premium sono più elevati, ma i costi delle transazioni sono inferiori. Pertanto, se i carichi di lavoro eseguono un numero elevato di transazioni, un account BLOB in blocchi di prestazioni Premium può essere economico.
Se l'account di archiviazione verrà usato per l'analisi, è consigliabile usare Azure Data Lake Storage insieme a un account di archiviazione BLOB in blocchi Premium. Questa combinazione di uso di account di archiviazione BLOB in blocchi Premium insieme a un account abilitato per Data Lake Storage è detto livello Premium per Azure Data Lake Storage.
Ottimizzare l'inserimento dei dati
Quando si acquisiscono dati da un sistema di origine, l'hardware di origine, l'hardware di rete di origine o la connettività di rete verso l'account di archiviazione può creare colli di bottiglia.
Hardware di origine
Indipendentemente dal fatto che si usino macchine virtuali o macchine virtuali locali in Azure, selezionare attentamente l'hardware appropriato. Per le unità disco, valutare l'uso di unità a stato solido (SSD) e scegliere unità disco con velocità di rotazione più elevate. Per l'hardware di rete, usare i controller di interfaccia di rete più veloci possibili. In Azure, usare macchine virtuali Azure D14, che dispongono di hardware disco e di rete adeguatamente potenti.
Connettività di rete all'account di archiviazione
La connettività di rete tra i dati di origine e l'account di archiviazione può talvolta creare un collo di bottiglia. Quando i dati di origine sono locali, è consigliabile usare un collegamento dedicato con Azure ExpressRoute. Se i dati di origine si trovano in Azure, le prestazioni sono ottimali quando i dati si trovano nella stessa area di Azure dell'account abilitato per Data Lake Storage.
Configurare gli strumenti di inserimento dei dati per la massima parallelizzazione
Per ottenere prestazioni ottimali, usare tutta la velocità effettiva disponibile eseguendo il maggior numero possibile di letture e scritture in parallelo.
La tabella seguente riepiloga le impostazioni principali per diversi strumenti di inserimento comuni.
| Strumento | Impostazione |
|---|---|
| DistCp | -m (mappatore) |
| Azure Data Factory | copie parallele |
| Sqoop | fs.azure.block.size, -m (mapper) |
| AzCopy | AZCOPY_CONCURRENCY_VALUE |
Per un elenco più completo degli strumenti di inserimento, vedere Selezionare gli strumenti di migrazione.
Nota
Le prestazioni complessive delle operazioni di inserimento dipendono da altri fattori specifici dello strumento usato per inserire i dati. Per indicazioni aggiornate, vedere la documentazione per ogni strumento che si intende usare.
L'account può essere ridimensionato per fornire la velocità effettiva necessaria per tutti gli scenari di analisi. Per impostazione predefinita, un account abilitato per Data Lake Storage offre una velocità effettiva sufficiente nella configurazione predefinita per soddisfare le esigenze di un'ampia categoria di casi d'uso. Se raggiungi il limite predefinito, contatta Supporto di Azure per configurare il tuo account in modo da garantire una maggiore velocità effettiva.
Set di dati struttura
Prendere in considerazione la prepianificazione della struttura dei dati. Il formato di file, le dimensioni dei file e la struttura di directory possono influire negativamente sulle prestazioni e sui costi.
Formati di file
È possibile inserire dati in vari formati. I dati possono essere visualizzati in formati leggibili come JSON, CSV o XML o come formati binari compressi, ad esempio .tar.gz. I dati possono venire in varie dimensioni. I dati possono essere costituiti da file di grandi dimensioni (alcuni terabyte), ad esempio i dati di un'esportazione di una tabella SQL dai sistemi locali. I dati possono anche venire sotto forma di un numero elevato di file di piccole dimensioni (pochi kilobyte), ad esempio i dati provenienti da eventi in tempo reale da una soluzione Internet delle cose (IoT). È possibile ottimizzare l'efficienza e i costi scegliendo un formato di file e dimensioni di file appropriati.
Hadoop supporta un set di formati di file ottimizzati per l'archiviazione e l'elaborazione di dati strutturati. Alcuni formati comuni includono Avro, Parquet e il formato Optimized Row Columnar (ORC). Tutti questi formati sono formati di file binari leggibili dal computer. Sono compressi per facilitare la gestione delle dimensioni dei file. Hanno uno schema incorporato in ogni file, che li rende autodescrittivi. La differenza tra questi formati è la modalità di archiviazione dei dati. Avro archivia i dati in un formato basato su righe e i formati Parquet e ORC archiviano i dati in un formato a colonne.
Utilizzare il formato di file Avro quando gli schemi di I/O sono orientati maggiormente alla scrittura oppure quando gli schemi di query privilegiano il recupero completo di più righe di record. Ad esempio, il formato Avro funziona bene con un bus di messaggi come Hub eventi o Kafka che scrivono più eventi o messaggi in successione.
Utilizzare i formati di file Parquet e ORC quando gli schemi di I/O sono prevalentemente orientati alla lettura o quando le query sono incentrate su un sottoinsieme di colonne all'interno dei record. Le transazioni di lettura possono essere ottimizzate per recuperare colonne specifiche anziché leggere l'intero record.
Apache Parquet è un formato di file open source ottimizzato per le pipeline di analisi con intensa attività di lettura. La struttura di archiviazione a colonne di Parquet consente di ignorare i dati non rilevanti. Le query sono molto più efficienti perché possono limitare l'ambito dei dati da inviare dall'archiviazione al motore di analisi. Inoltre, poiché i tipi di dati simili (per una colonna) vengono archiviati insieme, Parquet supporta schemi di codifica e compressione dei dati efficienti che possono ridurre i costi di archiviazione dei dati. Servizi come Azure Synapse Analytics, Azure Databricks e Azure Data Factory dispongono di funzionalità native che sfruttano i formati di file Parquet.
Dimensioni file
I file di dimensioni maggiori comportano prestazioni migliori e costi ridotti.
In genere, i motori di analisi, ad esempio HDInsight, presentano un sovraccarico per ogni file che comporta attività come l'elenco, il controllo dell'accesso e l'esecuzione di varie operazioni sui metadati. Se si archiviano i dati come molti file di piccole dimensioni, questa scelta può influire negativamente sulle prestazioni. In generale, organizzare i dati in file di dimensioni maggiori per ottenere prestazioni migliori (da 256 MB a 100 GB di dimensioni). Alcuni motori e applicazioni potrebbero avere problemi di elaborazione efficiente dei file con dimensioni superiori a 100 GB.
L'aumento delle dimensioni dei file può anche ridurre i costi delle transazioni. Le operazioni di lettura e scrittura vengono fatturate con incrementi di 4 megabyte in modo che venga addebitato un addebito per l'operazione indipendentemente dal fatto che il file contenga o meno 4 megabyte o solo pochi kilobyte. Per informazioni sui prezzi, vedere Prezzi di Azure Data Lake Storage.
Le pipeline di dati hanno talvolta un controllo limitato sui dati non elaborati costituiti da molti file di piccole dimensioni. In generale, il sistema deve avere un certo tipo di processo per aggregare file di piccole dimensioni in quelli più grandi per l'uso da parte delle applicazioni downstream. Se si elaborano dati in tempo reale, è possibile usare un motore di streaming in tempo reale (ad esempio Analisi di flusso di Azure o Spark Streaming) insieme a un broker di messaggi (ad esempio Hub eventi o Apache Kafka) per archiviare i dati come file di dimensioni maggiori. Durante l'aggregazione di file di piccole dimensioni in file di dimensioni maggiori, è consigliabile salvarli in un formato ottimizzato per la lettura, ad esempio Apache Parquet per l'elaborazione downstream.
Struttura delle directory
Ogni carico di lavoro ha requisiti diversi per il modo in cui utilizza i dati. Tuttavia, quando si lavora con l'Internet of Things (IoT), in scenari batch o quando si ottimizza per i dati di serie temporali, prendi in considerazione questi layout comuni.
Struttura IoT
Nei carichi di lavoro IoT è possibile inserire una grande quantità di dati che si estende su numerosi prodotti, dispositivi, organizzazioni e clienti. Pianificare in anticipo la struttura delle directory per garantire l'organizzazione, la sicurezza e l'elaborazione efficiente dei dati da parte dei sistemi a valle. Un modello generale da prendere in considerazione può essere il layout seguente:
- {Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/
I dati di telemetria per gli atterraggi relativi a un motore di un aereo nel Regno Unito potrebbero ad esempio essere simili alla struttura seguente:
- UK/Planes/BA1293/Engine1/2017/08/11/12/
In questo esempio, inserendo la data alla fine della struttura di directory, è possibile usare gli elenchi di controllo di accesso per proteggere più facilmente le aree e le questioni relative a utenti e gruppi specifici. Se si posizionasse il formato della data all'inizio, sarebbe molto più difficile mettere in sicurezza queste aree e questi argomenti. Ad esempio, se si vuole fornire l'accesso solo ai dati del Regno Unito o a determinati piani, è necessario applicare un'autorizzazione separata per numerose directory nella directory ogni ora. Questa struttura aumenterebbe anche in modo esponenziale il numero di directory col passare del tempo.
Struttura dei job batch
Un approccio comunemente usato nell'elaborazione batch consiste nell'inserire i dati in una directory "in". Quindi, una volta elaborati i dati, inserire i nuovi dati in una directory "out" per i processi downstream da utilizzare. Questa struttura di directory viene talvolta usata per i processi che richiedono l'elaborazione su singoli file e potrebbe non richiedere un'elaborazione parallela elevata su set di dati di grandi dimensioni. Analogamente alla struttura IoT consigliata in precedenza, una buona struttura di directory include le directory a livello padre per elementi come area geografica e materia (ad esempio, organizzazione, prodotto o produttore). Prendere in considerazione data e ora nella struttura per consentire una migliore organizzazione, ricerche filtrate, sicurezza e automazione nell'elaborazione. Il livello di granularità per la struttura di data è determinato dall'intervallo con cui i dati vengono caricati o elaborati, ad esempio ogni ora, ogni giorno o anche ogni mese.
Talvolta l'elaborazione di file ha esito negativo a causa del danneggiamento dei dati o di formati imprevisti. In questi casi, una struttura di directory può beneficiare di una cartella /bad in cui spostare i file per un'ulteriore ispezione. Il processo batch può anche gestire la generazione di report o la notifica di questi file bad per l'intervento manuale. Si consideri la struttura di modelli seguente:
- {Region}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/
- {Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/
- {Area}/{SubjectMatter(s)}/Bad/{aa}/{mm}/{dd}/{hh}/
Una società di marketing riceve ad esempio estratti giornalieri di dati degli aggiornamenti dei clienti dai committenti in America del Nord, Potrebbe apparire come il frammento seguente prima e dopo l'elaborazione:
- NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
- NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv
Nel caso comune di dati batch elaborati direttamente in database, ad esempio Hive o database SQL tradizionali, non è necessaria una directory in ingresso o in uscita perché l'output viene già inserito in una cartella separata per la tabella Hive o il database esterno. Ad esempio, le estrazioni giornaliere dei clienti vengono depositate nelle rispettive directory. Un servizio come Azure Data Factory, Apache Oozie o Apache Airflow attiva quindi un processo Hive o Spark giornaliero per elaborare e scrivere i dati in una tabella Hive.
Struttura dei dati delle serie temporali
Per i carichi di lavoro di Hive, lo sfoltimento delle partizioni dei dati di serie temporali può aiutare alcune query a leggere solo un sottoinsieme dei dati, migliorando così le prestazioni.
Tali pipeline che inseriscono dati di serie temporali spesso inseriscono i file con una denominazione strutturata per file e cartelle. Di seguito è riportato un esempio comune per i dati strutturati per data:
/DataSet/YYYY/MM/DD/datafile_YYYY_MM_DD.tsv
Si noti che le informazioni di data/ora vengono visualizzate sia come cartelle sia nel nome del file.
Per la data e l'ora, di seguito è riportato un modello comune
/DataSet/YYYY/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv
Anche in questo caso, la scelta relativa all'organizzazione di file e cartelle deve prevedere una gestione ottimizzata dei file di maggiori dimensioni e l'inclusione di un numero ragionevole di file in ogni cartella.
Configurare la sicurezza
Per iniziare, esaminare le raccomandazioni nell'articolo Raccomandazioni sulla sicurezza per l'archiviazione Blob. Sono disponibili indicazioni sulle procedure consigliate su come proteggere i dati da eliminazioni accidentali o dannose, proteggere i dati dietro un firewall e usare Microsoft Entra ID come base della gestione delle identità.
Vedere quindi l'articolo Modello di controllo di accesso in Azure Data Lake Storage per indicazioni specifiche per gli account abilitati per Data Lake Storage. Questo articolo illustra come usare i ruoli di controllo degli accessi in base al ruolo di Azure insieme agli elenchi di controllo di accesso (ACL) per applicare le autorizzazioni di sicurezza per directory e file nel file system gerarchico.
Inserimento, elaborazione e analisi
È possibile inserire dati in un account abilitato Data Lake Storage da molte origini diverse e in molti modi diversi.
Ad esempio, è possibile inserire grandi set di dati da cluster HDInsight e Hadoop o set più piccoli di dati ad hoc per la creazione di prototipi di applicazioni. È possibile inserire dati trasmessi generati da varie origini, ad esempio applicazioni, dispositivi e sensori. Per questo tipo di dati, utilizza strumenti per acquisire ed elaborare i dati evento per evento in tempo reale, quindi scrivi gli eventi in batch nel tuo account. È anche possibile inserire i log del server Web, che contengono informazioni come la cronologia delle richieste di pagina. Per i dati di log, è consigliabile scrivere script o applicazioni personalizzati per caricarli in modo da avere la flessibilità necessaria per includere il componente di caricamento dei dati come parte dell'applicazione Big Data di grandi dimensioni.
Quando i dati sono disponibili nell'account, è possibile eseguire analisi su tali dati, creare visualizzazioni e persino scaricare i dati nel computer locale o in altri repository, ad esempio un database SQL di Azure o un'istanza di SQL Server.
La tabella seguente consiglia gli strumenti che è possibile usare per inserire, analizzare, visualizzare e scaricare i dati. Usare i collegamenti in questa tabella per trovare indicazioni su come configurare e usare ogni strumento.
Nota
Questa tabella non riflette l'elenco completo dei servizi di Azure che supportano Data Lake Storage. Per visualizzare un elenco dei servizi di Azure supportati e del relativo livello di supporto, vedere Azure servizi che supportano Azure Data Lake Storage.
Monitorare i dati di telemetria
Il monitoraggio dell'uso e delle prestazioni del servizio è una parte importante dell'operazionalizzazione del servizio. Esempi di telemetria includono operazioni frequenti, operazioni con latenza elevata o operazioni che causano la limitazione della frequenza sul lato servizio.
È possibile accedere a tutti i dati di telemetria per l'account di archiviazione tramite Archiviazione di Azure log in Monitoraggio di Azure. Questa funzionalità integra l'account di archiviazione con Analisi dei log e Hub eventi, consentendo anche di archiviare i log in un altro account di archiviazione. Per visualizzare l'elenco completo delle metriche e dei log delle risorse e i relativi schemi, vedere informazioni di riferimento sui dati di monitoraggio di Archiviazione di Azure.
La posizione in cui si sceglie di archiviare i log dipende dal modo in cui si prevede di accedervi. Ad esempio, se si vuole accedere ai log quasi in tempo reale e poter correlare gli eventi nei log con altre metriche di Monitoraggio di Azure, archiviare i log in un'area di lavoro Log Analytics. Quindi, esegui query sui log usando KQL e scrivi query che enumerano la tabella StorageBlobLogs nell'area di lavoro.
Se si vogliono archiviare i log sia per query quasi in tempo reale che per la conservazione a lungo termine, configurare le impostazioni di diagnostica per inviare i log a un'area di lavoro Log Analytics e a un account di archiviazione.
Se si vuole accedere ai log tramite un altro motore di query, ad esempio Splunk, configurare le impostazioni di diagnostica per inviare i log a un hub eventi e inserire i log dall'hub eventi alla destinazione scelta.
È possibile abilitare i log di Archiviazione di Azure in Monitoraggio di Azure tramite il portale di Azure, PowerShell, il interfaccia della riga di comando di Azure e i modelli di Azure Resource Manager. Per le distribuzioni su larga scala, usare Criteri di Azure con supporto completo per le attività di correzione. Per altre informazioni, vedere ciphertxt/AzureStoragePolicy.