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
definiscegetFileChecksum
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:
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:
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.