Quando copi o sposti dati tra sistemi di archiviazione distinti, ad esempio più cluster HDFS (Apache Hadoop Distributed File System) o tra HDFS e Cloud Storage, è consigliabile eseguire un tipo di convalida per garantire l'integrità dei dati. Questa convalida è essenziale per assicurarti che i dati non siano stati modificati durante il trasferimento.
Mentre vari meccanismi garantiscono già l'integrità dei dati point-to-point in transito (ad esempio TLS per tutte le comunicazioni con Cloud Storage), una convalida esplicita dell'integrità dei dati end-to-end aggiunge protezione per i casi che potrebbero passare inosservati dai tipici meccanismi dei dati in transito. Questo può aiutarti a rilevare potenziali danni ai dati causati, ad esempio, da link di rete rumorosi, errori di memoria sui computer server e sui router lungo il percorso o bug software (ad esempio in una libreria utilizzata dai clienti).
Per Cloud Storage, questa convalida avviene automaticamente lato client con comandi come gsutil
cp e rsync. Questi comandi calcolano i file checksum locali, che vengono quindi convalidati in base ai checksum calcolati da Cloud Storage alla fine di ogni operazione. Se i checksum non corrispondono, gsutil elimina le copie non valide e visualizza un messaggio di avviso.
Questa mancata corrispondenza si verifica raramente e, in caso affermativo, puoi riprovare a eseguire l'operazione.
Ora c'è anche un modo per eseguire automaticamente la convalida lato client end-to-end in Apache Hadoop tramite 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 preciso i checksum dei file.
In che modo HDFS esegue i checksum dei file
HDFS utilizza CRC32C, un controllo di ridondanza ciclico (CRC) a 32 bit basato sul polinomio Castagnoli, per mantenere l'integrità dei dati in diversi contesti:
- I dati inattivi di Hadoop DataNodes verificano continuamente i dati rispetto ai CRC archiviati per rilevare e riparare bit-rot.
- Durante il transito, i DataNode inviano i CRC noti insieme ai dati in blocco corrispondenti e le librerie client HDFS calcolano cooperativamente i CRC per blocco per confrontarli con i CRC ricevuti dai DataNodes.
- Per scopi amministrativi di HDFS, vengono utilizzati checksum a livello di blocco per controlli manuali di integrità di basso livello dei singoli file a blocchi su DataNodes.
- Per casi d'uso arbitrari a livello di applicazione, l'interfaccia
FileSystemdefiniscegetFileChecksum, mentre l'implementazione HDFS utilizza i suoi CRC granulari archiviati per definire un checksum a livello di file.
Per la maggior parte degli utilizzi quotidiani, i CRC vengono utilizzati in modo trasparente per quanto riguarda il livello di applicazione. Gli unici CRC utilizzati sono i CRC32C per blocco, già precalcolati e archiviati in file di metadati insieme ai dati a blocchi. La dimensione del blocco è definita da dfs.bytes-per-checksum e ha un valore predefinito di 512 byte.
Carenze del tipo di checksum dei file predefinito di Hadoop
Per impostazione predefinita, quando utilizzi Hadoop, tutti i checksum esposti alle API assumono la forma di un MD5 di una concatenazione di CRC32C di blocchi, a livello di blocco tramite DataTransferProtocol di basso livello o a livello di file tramite l'interfaccia FileSystem di livello superiore. Un checksum a livello di file è definito come l'MD5 della concatenazione di tutti i checksum a blocchi, ognuno dei quali è un MD5 di una concatenazione di CRC di blocchi e pertanto è indicato come MD5MD5CRC32FileChecksum. Si tratta di un Merkle Tree
a tre livelli on demand.
Questa definizione del checksum a livello di file è sensibile ai dettagli di implementazione e layout dei dati di HDFS, ovvero la dimensione del blocco (valore predefinito 512 byte) e la dimensione del blocco (valore predefinito: 128 MB). Quindi questo checksum predefinito del file non è adatto in nessuna delle seguenti situazioni:
- Due copie diverse degli stessi file in HDFS, ma con dimensioni dei blocchi per file configurate diverse.
- Due diverse istanze di HDFS con diverse dimensioni di blocco o blocchi configurati.
- Una combinazione di file system compatibili con Hadoop (HCFS) HDFS e non HDFS, come Cloud Storage.
Il seguente diagramma mostra in che modo lo stesso file può avere checksum diversi a seconda della configurazione del file system:
Puoi visualizzare il checksum predefinito per 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 simile al 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), verrà visualizzato un output diverso:
hdfs:///user/bob/data.bin MD5-of-0MD5-of-512CRC32C 000002000000000000000000d3a7bae0b5200ed6707803a3911959f9
In questi esempi puoi vedere che i due checksum differiscono per lo stesso file.
Come funziona il nuovo checksum del file CRC composito di Hadoop
Un nuovo tipo di checksum, monitorato in HDFS-13056, è stato rilasciato in Apache Hadoop 3.1.1 per risolvere queste carenze. Il nuovo tipo, configurato da dfs.checksum.combine.mode=COMPOSITE_CRC, definisce nuovi CRC a blocchi compositi e CRC di file composito come CRC composti matematicamente nei CRC dei blocchi composti archiviati. L'utilizzo di questo tipo sostituisce l'uso di un MD5 dei
CRC dei componenti al fine di calcolare un singolo CRC che rappresenta l'intero blocco o file e che sia indipendente dalla granularità di livello inferiore dei CRC di blocchi.
La composizione dei CRC ha molti vantaggi: è efficiente, consente ai checksum risultanti di essere completamente indipendenti da blocchi/blocco e permette il confronto tra file di righe e replicati, tra diverse istanze HDFS e tra HDFS e altri sistemi di archiviazione esterni. Puoi scoprire di più sull'algoritmo CRC in questo download del PDF.
Il seguente diagramma illustra la coerenza del checksum di un file dopo il trasferimento in configurazioni di file system eterogenee:
Questa funzionalità è minimamente invasiva: può essere aggiunta per essere compatibile con i metadati del blocco esistenti e non deve modificare il normale percorso di verifica dei blocchi. Ciò significa anche che anche i deployment HDFS preesistenti di grandi dimensioni possono adottare questa funzionalità per sincronizzare i dati in modo retroattivo. Per ulteriori dettagli, puoi scaricare il documento PDF completo sul 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é il valore predefinito MD5MD5CRC). Quando un file viene copiato da una posizione a un'altra, anche il tipo di checksum a livello di blocco (ovvero la proprietà dfs.checksum.type, il cui valore predefinito è 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 Hadoop fs -checksum:
hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -checksum hdfs:///user/bob/data.bin
Indipendentemente dalla configurazione delle dimensioni del blocco nel cluster HDFS, vedrai lo stesso output, come nell'esempio 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, questa proprietà è impostata su
NONE per impostazione predefinita, causando la disattivazione dei checksum dei file per impostazione predefinita. Questo comportamento predefinito dal connettore Cloud Storage è una misura preventiva per evitare un problema con distcp, in cui viene generata un'eccezione in caso di mancata corrispondenza dei tipi di checksum anziché in caso di errore controllato. Il comando è simile al seguente:
hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -Dfs.gs.checksum.type=CRC32C -checksum gs://[BUCKET]/user/bob/data.bin
Il comando visualizza lo stesso output dell'esempio precedente su HDFS:
gs://[BUCKET]/user/bob/data.bin COMPOSITE-CRC32C c517d290
Come puoi vedere, i checksum CRC compositi restituiti dai comandi precedenti corrispondono tutti, indipendentemente dalla dimensione del blocco, nonché tra HDFS e Cloud Storage. Utilizzando i checksum CRC composti, 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 restituirà un avviso.
Accedi alla funzione
La nuova funzionalità di checksum CRC composita è disponibile in Apache Hadoop 3.1.1 (consulta le note di rilascio) e i backport per le versioni 2.7, 2.8 e 2.9 sono in fase di sviluppo. È stato incluso per impostazione predefinita nelle versioni secondarie di Cloud Dataproc 1.3 dalla fine del 2018.