Nell’articolo Data lakes: soluzioni in GCP abbiamo parlato dei data lakes come strumento per l’archiviazione di dati grezzi che verranno successivamente elaborati per essere memorizzati nei data warehouses. Tra le varie soluzioni proposte dalla piattaforma cloud di Google vi è il Cloud Storage.
Google Cloud Storage è il servizio di archiviazione essenziale per lavorare con i dati, specialmente quelli non strutturati. Analizziamo perché Google Cloud Storage è una scelta popolare per implementare un data lake. I dati e il Cloud Storage persistono oltre la vita delle macchine virtuali o dei cluster in GCP. È persistente ed è anche relativamente poco costoso rispetto al costo di macchine dedicate al calcolo. Quindi, per esempio, potrebbe risultare più vantaggioso mettere in cache i risultati dei calcoli precedenti all’interno del cloud storage. Oppure, se non si ha bisogno di un’applicazione sempre in esecuzione, potrebbe essere utile salvare lo stato dell’applicazione nel cloud storage, e poi spegnere la macchina che è in esecuzione o quando non se ne ha bisogno.
Caratteristiche del Cloud Storage
Il Cloud Storage è un object store, ossia memorizza e recupera solo oggetti binari senza considerare quali dati sono in essi contenuti. Tuttavia, in una certa misura, fornisce anche la compatibilità con il file system e può fare in modo che gli oggetti assomiglino e funzionino come se fossero file. Pertanto, è possibile copiare i file dentro e fuori di esso. I dati memorizzati nel cloud storage rimarranno fondamentalmente lì per sempre, il che significa che sono durevoli, ma sono disponibili istantaneamente o sono fortemente coerenti.
I dati possono essere criptati, resi provati o condivisi in base alle esigenze. Essendo un servizio globale, si possono raggiungere i dati da qualsiasi luogo. Nonostante ciò, i dati possono anche essere tenuti in una singola posizione geografica, se esistono alcuni vincoli funzionali del caso d’uso. Infine, i dati vengono serviti con una latenza moderata e un alto throughput.
Le due entità principali nel cloud storage sono i buckets e gli oggetti. I bucket sono dei contenitori al cui interno gli oggetti esistono. I bucket sono identificati da un namespace globalmente unico. Ciò significa che quando un nome viene assegnato ad un bucket, esso non può essere utilizzato da nessun altro fino a quando quel bucket non viene cancellato e, di conseguenza, quel nome viene rilasciato. Avere uno namespace globale per i bucket semplifica enormemente la localizzazione di un particolare bucket. Infatti, durante la definizione di un bucket, è necessario specificare la regione o le regioni in cui risiederà. Scegliendo una regione vicina a dove i dati saranno elaborati, si ridurrà la latenza.
Tutti gli oggetti presenti in un bucket sono replicati. Ciò implica una durabilità quasi del 100%, poiché quando una replica viene persa o corrotta il cloud storage potrà sostituirla con una copia. Inoltre, l’oggetto viene sempre servito dalla replica più vicina al richiedente riducendo la latenza e aumentando il throughput. Questa strategia è applicata sia per bucket regionale che multi-region.
Infine, il cloud storage memorizza anche i metadati associati ad ogni singolo oggetto. Ulteriori funzioni del cloud storage utilizzano i metadati per scopi come il controllo dell’accesso, la compressione, la crittografia e la gestione del ciclo di vita degli oggetti e dei bucket. Per esempio, il cloud storage è a conoscenza di quando un oggetto è stato memorizzato grazie ai metadati e, pertanto, può impostare automaticamente la sua cancellazione dopo un determinato periodo di tempo.
Creazione di un bucket: come configurarlo
La creazione di un bucket può avvenire sia tramite interfaccia grafica di Google Cloud che da linea di comando con gsutil. Indipendentemente dalla modalità usata, è necessario prendere diverse decisioni quando si crea un bucket.
La prima è la posizione del bucket, che non può essere più cambiata dopo la sua creazione. Se c’è la necessità di spostare un bucket in seguito, bisognerà copiare tutto il contenuto nella nuova posizione e pagare le spese di uscita dalla rete. Quindi la scelta deve essere oculata.
La posizione potrebbe essere una singola regione (ad esempio Europa del nord o Asia del sud), o su più regioni, come ad esempio UE o Asia, che significa che l’oggetto è replicato in diverse regioni all’interno dell’Unione europea o dell’Asia rispettivamente. La terza opzione è quella della doppia regione. Ad esempio, Nord America per significa che l’oggetto è replicato in quello centrale degli Stati Uniti e in quello orientale degli Stati Uniti.
Quindi, come si fa a scegliere una regione? Dipende dal contesto applicativo. Se, ad esempio, tutti i vostri calcoli e tutti i vostri utenti sono in Asia, è possibile scegliere una regione asiatica per ridurre la latenza di rete.
Ma oltre a questo, come si fa a scegliere tra Asia Sud uno e Asia multi-region? Se si seleziona una singola regione, i dati saranno replicati in più zone all’interno di quella regione. In questo modo una singola zona potrebbe non essere raggiungibile, ma si avrà comunque ancora accesso ai dati. Infatti, zone diverse all’interno della stessa regione forniscono l’isolamento dalla maggior parte dei guasti sia infrastrutturali che software. Ovviamente, se l’intera regione non è raggiungibile a causa di un disastro naturale, non sarà possibile accedere a quei dati. Se si vuole essere sicuri che i dati siano sempre disponibili anche durante un disastro naturale, è necessario selezionare multi-region o doppia regione. In questo caso le repliche saranno memorizzate in data center fisicamente separati.
In terzo luogo, è necessario determinare quanto spesso è necessario accedere o modificare i dati. Il costo del bucket dipende, infatti, da quante volte si accede. Si possono ottenere sconti significativi se si accede ai dati non più di una volta al mese o una volta al trimestre. Ma in quali casi è possibile? Alcuni esempi sono l’archiviazione dei dati, i backup o il disaster recovery.
Simulazione del file system
Il cloud storage usa il nome del bucket e il nome dell’oggetto per simulare un file system. Ecco come funziona.
Il nome del bucket è il primo termine dell’URI a cui viene aggiunta, dopo lo /, il nome dell’oggetto. Il nome dell’oggetto può contenere il carattere / ripetuto più volte. In questo modo si simula un sistema di percorsi di file e cartelle anche se in realtà è solo il nome di un singolo oggetto. Nell’esempio mostrato il nome del bucket è declass, mentre il nome dell’oggetto è de/modules/02/script.sh. Se questo percorso fosse in un file system, sembrerebbe una serie di directory annidate che iniziano con declass.
Per tutti gli scopi pratici, Google Cloud Storage funziona come un file system, ma ci sono alcune differenze chiave. Per esempio, immaginate di voler spostare tutti i file nella directory 02 nella directory 03 all’interno della directory dei moduli. In un file system, avreste una struttura di directory reali e modifichereste semplicemente i metadati del file system. Pertanto, l’intero spostamento risulta un’operazione atomica. In un object store che simula un file system, invece, dovreste cercare tra tutti gli oggetti contenuti nel bucket i nomi che hanno 02 nella giusta posizione nel nome. A quel punto dovreste modificare ogni nome degli oggetti e rinominarli usando 03. Ciò produrrebbe apparentemente lo stesso risultato dello spostamento di file tra le directory. Tuttavia, invece di lavorare con una dozzina di file in una directory, il sistema dovrà cercare su migliaia di oggetti nel bucket per localizzare quelli con i nomi giusti e poi cambiare ognuno di essi. Quindi le prestazioni sono un pò diverse.
Il tempo necessario per spostare degli oggetti dalla directory 02 alla directory 03 può risultare molto più grande a seconda di quanti altri oggetti sono memorizzati in quel bucket. Inoltre, durante lo spostamento ci sarà un’incoerenza della lista con alcuni file nella vecchia directory e alcuni nella nuova directory. Una buona pratica è quella di evitare l’uso di informazioni sensibili come parte dei nomi dei bucket, perché i nomi dei bucket sono in un namespace globale.
Funzionalità aggiuntive
Oltre alle caratteristiche descritte in precedenza è necessario citare alcune funzionalità aggiuntive.
I dati nei bucket possono essere tenuti privati. Si può accedere a Google Cloud Storage utilizzando il metodo di accesso ai file, che consente ad esempio di utilizzare un comando di copia dalla directory locale dei file a Google Cloud Storage. Il cloud storage è accessibile anche via web all’indirizzo: storage.cloud.google.com. Il sito utilizza TLS o HTTPS per trasportare i dati, proteggendo di conseguenza le credenziali così come i dati in transito.
Il cloud storage ha molte altre funzioni di gestione degli oggetti. Ad esempio, è possibile impostare una politica di conservazione su tutti gli oggetti in un bucket che preveda la cancellazione automatica dell’oggetto dopo un periodo prestabilito. È possibile anche usare il versioning per tracciare tutte le modifiche apportate ad un oggetto in modo tale da recuperare vecchie versioni se necessario. Si può anche gestire il ciclo di vita degli oggetti. Ad esempio, si può impostare uno spostamento automatico degli oggetti dopo 30 giorni dalla loro consultazione nella classe di archiviazione nearline, o dopo 90 giorni nella classe di archiviazione coldline. In questo modo si ottimizzano i costi.
