Convalida dei trasferimenti di dati tra HDFS e Cloud Storage

Last reviewed 2024-04-15 UTC

Quando copi o sposti dati tra sistemi di archiviazione distinti, ad esempio più cluster Apache Hadoop Distributed File System (HDFS) o tra HDFS e Cloud Storage, è buona norma eseguire un tipo di convalida per garantire l'integrità dei dati. Questa convalida è essenziale per assicurarsi che i dati non siano stati alterati durante il trasferimento.

Sebbene vari meccanismi garantiscano già l'integrità dei dati point-to-point in transito (ad esempio TLS per tutte le comunicazioni con Cloud Storage), la convalida esplicita dell'integrità end-to-end dei dati aggiunge protezione per i casi che potrebbero non essere rilevati dai tipici meccanismi in transito. In questo modo puoi rilevare potenziali alterazioni dei dati causate, ad esempio, da link di rete con interferenze, errori di memoria sui computer dei server e sui router lungo il percorso o bug software (ad esempio in una libreria utilizzata dai clienti).

Per Cloud Storage, questa convalida viene eseguita automaticamente lato client con comandi come cp e rsync di Google Cloud CLI. Questi comandi calcolano i checksums dei file locali, che vengono poi convalidati in base ai checksum calcolati da Cloud Storage al termine di ogni operazione. Se i checksum non corrispondono, l'gcloud CLI elimina le copie non valide e stampa un messaggio di avviso. Questo tipo di mancata corrispondenza si verifica raramente, ma se si verifica, puoi riprovare a eseguire l'operazione.

Ora esiste anche un modo per eseguire automaticamente la convalida end-to-end lato client in Apache Hadoop su file system eterogenei compatibili con Hadoop come HDFS e Cloud Storage. Questo articolo descrive in che modo la nuova funzionalità consente di confrontare in modo efficiente e accurato i checksum dei file.

Come HDFS esegue i checksum dei file

HDFS utilizza CRC32C, un controllo di ridondanza ciclica (CRC) di 32 bit basato sul polinomio di Castagnoli, per mantenere l'integrità dei dati in diversi contesti:

  • In stato inattivo, i DataNode Hadoop verificano continuamente i dati rispetto ai CRC memorizzati per rilevare e riparare la corruzione dei bit.
  • Durante il transito, i DataNode inviano CRC noti insieme ai dati collettivi corrispondenti e le librerie client HDFS calcolano in modo collaborativo i CRC per chunk da confrontare con i CRC ricevuti dai DataNode.
  • Per scopi amministrativi di HDFS, i checksum a livello di blocco vengono utilizzati per controlli di integrità manuali a basso livello di singoli file di blocco sui DataNode.
  • Per casi d'uso arbitrari a livello di applicazione, l'interfaccia FileSystem definisce getFileChecksum e l'implementazione HDFS utilizza i CRC granulari memorizzati per definire un controllo di congruenza a livello di file.

Per la maggior parte degli utilizzi quotidiani, i CRC vengono utilizzati in modo trasparente rispetto al livello di applicazione. Gli unici CRC utilizzati sono i CRC32C per chunk, che sono già precomputati e archiviati nei file di metadati insieme ai dati del blocco. La dimensione del frammento è definita da dfs.bytes-per-checksum e ha un valore predefinito di 512 byte.

Mancanza del tipo di checksum file predefinito di Hadoop

Per impostazione predefinita, quando utilizzi Hadoop, tutti i checksum esposti dall'API hanno la forma di un valore MD5 di una concatenazione di CRC32C dei chunk, a livello di blocco tramite DataTransferProtocol di basso livello o a livello di file tramite l'interfaccia FileSystem di primo livello. Un checksum a livello di file è definito come l'MD5 della concatenazione di tutti i checksum dei blocchi, ciascuno dei quali è un MD5 di una concatenazione di CRC dei chunk e viene quindi definito MD5MD5CRC32FileChecksum. Si tratta in pratica di un albero Merkle su tre livelli on demand.

Questa definizione del checksum a livello di file è sensibile ai dettagli di implementazione e di layout dei dati di HDFS, ovvero alla dimensione del chunk (512 byte per impostazione predefinita) e alla dimensione del blocco (128 MB per impostazione predefinita). Pertanto, questo checksum file predefinito non è adatto in nessuna delle seguenti situazioni:

  • Due copie diverse degli stessi file in HDFS, ma con dimensioni dei blocchi per file diverse configurate.
  • Due istanze diverse di HDFS con dimensioni di blocchi o chunk diverse configurate.
  • Una combinazione di HDFS e file system compatibili con Hadoop (HCFS) non HDFS come Cloud Storage.

Il seguente diagramma mostra come lo stesso file può avere diversi checksum a seconda della configurazione del file system:

Mancata corrispondenza del checksum

Puoi visualizzare il checksum predefinito di un file in HDFS utilizzando il comando fs -checksum di Hadoop:

hadoop fs -checksum hdfs:///user/bob/data.bin

In un cluster HDFS con una dimensione del blocco di 64 MB (dfs.block.size=67108864), questo comando mostra un risultato come il seguente:

hdfs:///user/bob/data.bin   MD5-of-131072MD5-of-512CRC32C   000002000000000000020000e9378baa1b8599e50cca212ccec2f8b7

Per lo stesso file in un altro cluster con una dimensione del blocco di 128 MB (dfs.block.size=134217728), viene visualizzato un output diverso:

hdfs:///user/bob/data.bin   MD5-of-0MD5-of-512CRC32C    000002000000000000000000d3a7bae0b5200ed6707803a3911959f9

In questi esempi puoi vedere che i due checksum sono diversi per lo stesso file.

Come funziona il nuovo checksum file CRC composito di Hadoop

Per risolvere questi problemi, in Apache Hadoop 3.1.1 è stato rilasciato un nuovo tipo di checksum, monitorato in HDFS-13056. Il nuovo tipo, configurato da dfs.checksum.combine.mode=COMPOSITE_CRC, definisce nuovi CRC di blocchi compositi e CRC di file compositi come il CRC composto matematicamente tra i CRC dei chunk archiviati. L'utilizzo di questo tipo sostituisce l'utilizzo di un MD5 dei CRC dei componenti per calcolare un singolo CRC che rappresenta l'intero blocco o file ed è indipendente dalla granularità di livello inferiore dei CRC dei chunk.

La composizione CRC presenta molti vantaggi: è efficiente, consente ai checksum risultanti di essere completamente indipendenti da chunk/blocchi e consente il confronto tra file a strisce e replicati, tra istanze HDFS diverse e tra HDFS e altri sistemi di archiviazione esterni. Puoi trovare maggiori dettagli sull'algoritmo CRC in questo download in formato PDF.

Il seguente diagramma mostra come il checksum di un file sia coerente dopo il trasferimento tra configurazioni di file system eterogenee:

Corrispondenza del checksum

Questa funzionalità è minimamente invasiva: può essere aggiunta in modo da essere compatibile con i metadati dei blocchi esistenti e non è necessario modificare il normale percorso della verifica degli chunk. Ciò significa anche che anche i grandi implementazioni HDFS esistenti possono adottare questa funzionalità per sincronizzare i dati in modo retroattivo. Per ulteriori dettagli, puoi scaricare il documento PDF completo del design.

Utilizzo del nuovo tipo di checksum CRC composito

Per utilizzare il nuovo tipo di checksum CRC composito in Hadoop, imposta la proprietà dfs.checksum.combine.mode su COMPOSITE_CRC (anziché sul valore predefinito MD5MD5CRC). Quando un file viene copiato da una posizione all'altra, anche il tipo di checksum a livello di chunk (ovvero la proprietà dfs.checksum.type che per impostazione predefinita è CRC32C) deve corrispondere in entrambe le posizioni.

Puoi visualizzare il nuovo tipo di checksum per un file in HDFS passando l'argomento -Ddfs.checksum.combine.mode=COMPOSITE_CRC al comando -Ddfs.checksum.combine.mode=COMPOSITE_CRC di Hadoop:fs -checksum

hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -checksum hdfs:///user/bob/data.bin

Indipendentemente dalla configurazione della dimensione del blocco del cluster HDFS, viene visualizzato lo stesso output, ad esempio il seguente:

hdfs:///user/bob/data.bin   COMPOSITE-CRC32C    c517d290

Per Cloud Storage, devi anche impostare esplicitamente la proprietà fs.gs.checksum.type del connettore Cloud Storage su CRC32C. In caso contrario, il valore predefinito di questa proprietà è NONE, il che comporta la disattivazione dei checksum dei file per impostazione predefinita. Questo comportamento predefinito del connettore Cloud Storage è una misura preventiva per evitare un problema con distcp, in cui viene sollevata un'eccezione se i tipi di checksum non corrispondono anziché interrompersi in modo elegante. Il comando è il seguente:

hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -Dfs.gs.checksum.type=CRC32C -checksum gs://[BUCKET]/user/bob/data.bin

Il comando mostra lo stesso output dell'esempio precedente su HDFS:

gs://[BUCKET]/user/bob/data.bin COMPOSITE-CRC32C    c517d290

Puoi vedere che i checksum CRC compositi restituiti dai comandi precedenti sono tutti uguali, indipendentemente dalle dimensioni dei blocchi, nonché tra HDFS e Cloud Storage. Utilizzando i checksum CRC compositi, ora puoi garantire che l'integrità dei dati venga preservata durante il trasferimento di file tra tutti i tipi di configurazioni di cluster Hadoop.

Se esegui distcp, come nell'esempio seguente, la convalida viene eseguita automaticamente:

hadoop distcp -Ddfs.checksum.combine.mode=COMPOSITE_CRC -Dfs.gs.checksum.type=CRC32C hdfs:///user/bob/* gs://[BUCKET]/user/bob/

Se distcp rileva una mancata corrispondenza del checksum del file tra l'origine e la destinazione durante la copia, l'operazione non andrà a buon fine e verrà restituito un avviso.

Accesso alla funzionalità

La nuova funzionalità di controllo CRC composito è disponibile in Apache Hadoop 3.1.1 (consulta le note di rilascio), e sono in corso backport alle versioni 2.7, 2.8 e 2.9. È stato incluso per impostazione predefinita nelle versioni subminor di Cloud Dataproc 1.3 dalla fine del 2018.