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 qualche tipo di convalida per garantire l'integrità dei dati. Questo tipo di convalida è essenziale per assicurarsi che i dati non siano stati alterati durante il trasferimento.
Anche se vari meccanismi assicurano da punto a punto l'integrità dei dati in transito (ad esempio TLS per tutte le comunicazioni con Cloud Storage), i dati end-to-end espliciti la convalida dell'integrità aggiunge la protezione per i casi che potrebbero non essere rilevati dai 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 a bug del software (ad esempio in una libreria utilizzati dai clienti).
Per Cloud Storage, questa convalida avviene automaticamente lato client con
Google Cloud CLI
come cp e rsync. Questi comandi calcolano
checksum,
che vengono poi convalidati in base ai checksum calcolati
Cloud Storage al termine di ogni operazione. Se i checksum non corrispondono,
gcloud CLI elimina le copie non valide e stampa un avviso
per creare un nuovo messaggio email. Questa mancata corrispondenza si verifica raramente e, se si verifica, puoi riprovare
operativa.
Ora c'è anche un modo per eseguire automaticamente l'esecuzione automatica end-to-end sul lato client convalida in Apache Hadoop in 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.
Modalità di esecuzione dei checksum dei file da parte di HDFS
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:
- At-rest, i DataNodes di Hadoop verificano continuamente i dati rispetto ai CRC archiviati per rilevare e riparare bit-rot.
- In transito, i DataNode inviano CRC noti insieme al corrispondente codice e le librerie client HDFS calcolano in modo collaborativo i CRC per con i CRC ricevuti dai DataNodes.
- 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 in relazione alle
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. Il chunk
la dimensione è definita da dfs.bytes-per-checksum e ha un valore predefinito di 512 byte.
Limiti del tipo di checksum predefinito dei file 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. A livello di file
il checksum è definito come l'MD5 della concatenazione di tutti i checksum dei blocchi,
ognuno dei quali è un MD5 di una concatenazione di CRC a blocchi ed è quindi
denominato MD5MD5CRC32FileChecksum. Si tratta di una soluzione on demand,
a tre strati
Albero di Merkle.
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). Quindi questo checksum predefinito del file non è adatto in una delle seguenti situazioni:
- Due copie diverse degli stessi file in HDFS, ma con file diversi per file le dimensioni dei blocchi configurate.
- Due diverse istanze di HDFS con diverse dimensioni di blocco o chunk configurato.
- Una combinazione di HDFS e non HDFS File system compatibili con Hadoop (HCFS) 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 checksum del nuovo 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 nuovo
CRC a blocchi compositi e CRC di file compositi come CRC composti matematicamente
tra i CRC dei blocchi archiviati. L'utilizzo di questo tipo sostituisce l'uso di un MD5 del tipo
CRC dei componenti per calcolare un singolo CRC che rappresenti l'intero
blocco o file ed è indipendente dalla granularità di livello inferiore dei CRC a blocchi.
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 scoprire di più sull'algoritmo CRC in questo Download del 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 loco per essere compatibile con i metadati di blocco esistenti e non richiede la modifica del percorso normale con la verifica di chunking. Ciò significa anche che anche i deployment di HDFS preesistenti di grandi dimensioni adottare questa funzione per sincronizzare i dati in modo retroattivo. Per ulteriori dettagli, puoi scarica il documento PDF di progetto completo.
Utilizzo del nuovo tipo di checksum CRC composito
Per utilizzare il nuovo tipo di checksum CRC composito in Hadoop, imposta il valore
Proprietà dfs.checksum.combine.mode in COMPOSITE_CRC (invece di quella predefinita
valore MD5MD5CRC). Quando un file viene copiato da una posizione a un'altra,
tipo di checksum a livello di chunk (ovvero la proprietà dfs.checksum.type che
il valore predefinito è CRC32C) deve corrispondere anche in entrambe le località.
Puoi visualizzare il nuovo tipo di checksum per un file in HDFS passando il parametro
Argomento -Ddfs.checksum.combine.mode=COMPOSITE_CRC a Hadoop
Comando 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, il risultato è lo stesso simile al seguente:
hdfs:///user/bob/data.bin COMPOSITE-CRC32C c517d290
Per Cloud Storage, devi anche impostare esplicitamente il connettore Cloud Storage
da fs.gs.checksum.type a CRC32C. Per impostazione predefinita, questa proprietà è
NONE, con la conseguente disattivazione dei checksum dei file per impostazione predefinita. 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. Grazie all'utilizzo di checksum CRC compositi, ora puoi garantire che i dati l'integrità viene preservata durante il trasferimento di file tra tutti i tipi di Hadoop configurazioni di cluster Kubernetes.
Se esegui distcp, come nell'esempio seguente, la convalida è
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à composita di checksum CRC è disponibile in Apache Hadoop 3.1.1 (vedi note di rilascio), e backport alle versioni 2.7, 2.8 e 2.9 sono in fase di sviluppo. È stata incluso per impostazione predefinita nelle versioni secondarie di Cloud Dataproc 1.3 dalla fine del 2018.