Azure Data Lake Storage considerazioni chiave

Informazioni sulle considerazioni sull'archiviazione chiave per i data lake di Azure.

Gestione del ciclo di vita

Archiviazione di Azure offre livelli di accesso diversi, che consentono di archiviare i dati degli oggetti BLOB nel modo più conveniente possibile. I livelli di accesso disponibili sono i seguenti:

  • Archiviazione ad accesso frequente: ottimizzata per l'archiviazione di dati a cui si accede di frequente.
  • Bello: Ottimizzato per l'archiviazione dei dati a cui si accede raramente. I dati vengono archiviati per almeno 30 giorni.
  • Livello ad accesso sporadico: Ottimizzato per l'archiviazione di dati a cui si accede raramente o viene modificato. I dati vengono archiviati per almeno 90 giorni. Il livello di accesso saltuario presenta costi di archiviazione più bassi e costi di accesso più alti rispetto al livello di accesso frequente.
  • Archivio: ottimizzato per l'archiviazione di dati a cui si accede raramente. I dati vengono archiviati per almeno 180 giorni con requisiti di latenza flessibili, nell'ordine di ore.

Quando si usano i livelli di accesso, tenere presenti le informazioni seguenti:

  • Solo i livelli di accesso ad accesso frequente e sporadico possono essere impostati a livello di account. Il livello di accesso Archivio non è disponibile a livello di account.

  • I livelli ad accesso frequente, sporadico e archivio possono essere impostati a livello di BLOB durante il caricamento o dopo il caricamento.

  • I dati nel livello ad accesso sporadico hanno una disponibilità leggermente inferiore, ma offrono le stesse caratteristiche di durabilità elevata, latenza di recupero e velocità effettiva dei dati del livello ad accesso frequente. Per i dati nel livello ad accesso sporadico, la disponibilità leggermente inferiore e i costi di accesso più elevati possono essere compromessi accettabili per ridurre i costi di archiviazione complessivi rispetto al livello frequente.

  • Il tipo Archivio archivia i dati offline e offre costi di archiviazione più bassi. Tuttavia, comporta anche i costi di riattivazione e accesso dei dati più elevati.

Per altre informazioni, vedere Livelli di accesso ad accesso frequente, sporadico e archivio per i dati BLOB.

Attenzione

Per l'analisi su scala cloud, è consigliabile implementare la gestione del ciclo di vita usando un microservizio personalizzato e considerare attentamente l'impatto dello spostamento dei dati individuabili dall'utente nell'archiviazione ad accesso sporadico.

È consigliabile spostare sezioni del data lake al livello ad accesso sporadico solo per carichi di lavoro ben compresi.

Connettività dei data lake

Ognuno dei data lake deve usare gli endpoint privati inseriti nella rete virtuale della zona di destinazione dei dati. Per fornire l'accesso tra zone di destinazione, connettere le zone di destinazione dei dati tramite il peering di rete virtuale. Questa connessione offre una soluzione ottimale sia dal punto di vista dei costi che dal punto di vista del controllo di accesso.

Per altre informazioni, vedere Endpoint privati e Zona di destinazione di gestione dei dati nella zona di destinazione dei dati.

Importante

È possibile accedere ai dati da una zona di destinazione dei dati da un'altra zona di destinazione dei dati tramite il peering di rete virtuale tra le zone. Questa operazione viene eseguita usando gli endpoint privati associati a ogni account data lake. È consigliabile disattivare tutti gli accessi pubblici ai laghi e usare endpoint privati. Il team operativo della piattaforma deve controllare la connettività di rete tra le zone di destinazione dei dati.

Eliminazione temporanea per i contenitori

L'eliminazione temporanea per i contenitori protegge i dati da eliminazioni accidentali o dannose. Se si abilita l'eliminazione temporanea dei contenitori per l'account di archiviazione, i contenitori eliminati e il relativo contenuto vengono conservati in Archiviazione di Azure per un lungo periodo di tempo scelto. Durante il periodo di conservazione dei dati, è possibile ripristinare i contenitori eliminati in precedenza. Il ripristino di un contenitore ripristina anche tutti i BLOB all'interno di tale contenitore quando è stato eliminato.

Abilitare le funzionalità di protezione dei dati seguenti per ottenere la protezione dei dati DEI BLOB end-to-end:

Avviso

L'eliminazione di un account di archiviazione non può essere annullata. L'eliminazione temporanea del contenitore non protegge dall'eliminazione dell'account di archiviazione, ma solo dall'eliminazione dei contenitori all'interno di un account. Per proteggere un account di archiviazione dall'eliminazione, configurare un blocco sulla risorsa dell'account di archiviazione. Per altre informazioni sul blocco delle risorse di Azure Resource Manager, vedere Bloccare le risorse per impedire modifiche impreviste.

Monitoraggio

In una zona di destinazione dei dati, tutto il monitoraggio deve essere inviato alla sottoscrizione di gestione su scala aziendale per l'analisi.

Per informazioni sui dati di monitoraggio usati da Archiviazione di Azure, vedere Monitoraggio delle risorse di Azure con Monitoraggio di Azure. Per altre informazioni sui log e sulle metriche create da Archiviazione di Azure, vedere Monitoraggio Archiviazione BLOB di Azure.

Le voci di log vengono create solo se le richieste vengono eseguite sull'endpoint del servizio. I tipi di richieste autenticate registrate sono:

  • Richieste riuscite
  • Richieste non riuscite, tra cui errori di timeout, limitazione, rete, autorizzazione e di altro tipo
  • Richieste che usano una firma di accesso condiviso o OAuth, incluse le richieste riuscite e non riuscite
  • Richieste ai dati di analisi, ad esempio i dati di log classici nel $logs contenitore e i dati delle metriche di $metric classe nelle tabelle

Le richieste eseguite dalla stessa Analisi archiviazione, ad esempio, la creazione oppure l'eliminazione di log, non vengono registrate. I tipi di richieste anonime registrate sono:

  • Richieste riuscite
  • Errori del server
  • Errori di timeout per client e server
  • Richieste HTTP GET non riuscite con il codice di errore 304 (Not Modified)

Tutte le altre richieste anonime non riuscite non vengono registrate.

Importante

Impostare i criteri di monitoraggio predefiniti per controllare l'archiviazione e inviare i log alla sottoscrizione di gestione su scala aziendale.

Passaggi successivi