Quando copi o sposti dati tra sistemi di archiviazione distinti, come più File system distribuito Apache Hadoop (HDFS) o tra HDFS e Cloud Storage è una buona idea eseguire un qualche 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. Questo può aiutarti a rilevare potenziali danni ai dati causati, ad esempio, da link di rete rumorosi, errori di memoria sui computer e router lungo il percorso oppure bug del software (ad esempio in una libreria che utilizzati 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
checksums,
che vengono poi convalidati in base ai checksum calcolati
Cloud Storage al termine di ogni operazione. Se i checksum non corrispondono,
l'interfaccia a riga di comando gcloud elimina le copie non valide e stampa un messaggio di avviso. Questa mancata corrispondenza si verifica raramente e, se si verifica, puoi riprovare
operativa.
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 come la nuova funzionalità consente di confrontare in modo efficiente e preciso i checksum dei file.
Come HDFS esegue i checksum dei file
HDFS utilizza CRC32C, uno standard a 32 bit controllo di ridondanza ciclico (CRC) basata sul polinomio di Castagnoli, per mantenere l'integrità dei dati contesti diversi:
- 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.
- Ai fini amministrativi di HDFS, i checksum a livello di blocco vengono utilizzati di basso livello controlli di integrità manuali di singoli file di blocco su DataNodes.
- Per casi d'uso arbitrari a livello di applicazione, l'interfaccia
FileSystemdefiniscegetFileChecksume l'implementazione HDFS utilizza i suoi CRC granulari per definire un checksum 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 blocco, che
sono già precalcolati e archiviati in file di metadati insieme ai dati a blocchi. 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 si utilizza Hadoop, tutti i checksum esposti alle API assumono la forma di
MD5
di una concatenazione di CRC32C di blocchi,
a livello di blocco attraverso DataTransferProtocol di basso livello oppure
a livello di file attraverso 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 all'implementazione i dettagli del layout dei dati di HDFS, ovvero la dimensione del chunk (valore predefinito: 512 byte) la dimensione del blocco (il valore predefinito è 128 MB). 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 dei blocchi o dei chunk diverse configurate.
- Una combinazione di HDFS e file system compatibili con Hadoop (HCFS) non HDFS come Cloud Storage.
Il seguente diagramma mostra come uno stesso file può finire con che dipendono dalla configurazione del file system:
Puoi visualizzare il checksum predefinito per un file in HDFS utilizzando lo strumento Hadoop
Comando fs -checksum:
hadoop fs -checksum hdfs:///user/bob/data.bin
In un cluster HDFS con dimensione del blocco di 64 MB (dfs.block.size=67108864),
questo comando visualizza 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), vedrai 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 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 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 offre molti vantaggi: è efficiente; questo permette all'output i checksum siano completamente indipendenti da blocchi/chunk; e consente il confronto tra file con striping e replicati, tra diverse istanze HDFS, 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 fornisce uno sguardo alla coerenza del checksum di un file 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 deployment HDFS esistenti di grandi dimensioni 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:
hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -checksum hdfs:///user/bob/data.bin
Indipendentemente dalla configurazione della dimensione del blocco del cluster HDFS, il risultato è lo stesso simile al 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. Per impostazione predefinita, questa proprietà è
NONE, con la disattivazione per impostazione predefinita dei checksum dei file. Questo comportamento predefinito
dal connettore Cloud Storage è una misura preventiva per evitare
con distcp, dove viene sollevata un'eccezione se il checksum tipi non corrisponde
invece di farlo in modo controllato. Il comando ha questo aspetto:
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
Puoi vedere che i checksum CRC compositi restituiti dai comandi precedenti corrispondono tutte, indipendentemente dalla dimensione del blocco, nonché tra HDFS e Cloud spazio di archiviazione. 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 restituirà un avviso.
Accesso alla funzione
La nuova funzionalità di checksum CRC composito è disponibile in Apache Hadoop 3.1.1 (consulta le note di rilascio), e sono in corso di sviluppo backport alle versioni 2.7, 2.8 e 2.9. È stata inclusa per impostazione predefinita nelle versioni subminor di Cloud Dataproc 1.3 dalla fine del 2018.