Wenn Sie Daten zwischen verschiedenen Speichersystemen wie mehreren Apache Hadoop Distributed File System-Clustern (HDFS) oder zwischen HDFS und Cloud Storage kopieren oder verschieben, sollte eine Art Validierung zur Gewährleistung der Datenintegrität erfolgen. Diese Validierung ist wichtig, um sicherzugehen, dass die Daten während der Übertragung nicht geändert wurden.
Während verschiedene Verfahren bereits für eine Punkt-zu-Punkt-Datenintegrität bei der Übertragung sorgen (z. B. TLS für die gesamte Kommunikation mit Cloud Storage), bietet die explizite End-to-End-Datenintegritätsprüfung zusätzlichen Schutz für Fälle, die von herkömmlichen Verfahren für die Übertragung nicht erkannt werden. Auf diese Weise können Sie eine potenzielle Datenkorruption erkennen, die beispielsweise durch Fehler während der Netzwerkübertragung, durch Speicherfehler auf Servercomputern und Routern entlang des Pfads oder durch Softwarefehler (z. B. in einer von Kunden verwendeten Bibliothek) verursacht werden kann.
Bei Cloud Storage erfolgt diese Validierung automatisch clientseitig mit Google Cloud CLI-Befehlen wie cp und rsync. Diese Befehle berechnen checksums der lokalen Dateien, die am Ende jedes Vorgangs mit den von Cloud Storage berechneten Prüfsummen verglichen werden. Wenn die Prüfsummen nicht übereinstimmen, löscht die gcloud CLI die ungültigen Kopien und gibt eine Warnmeldung aus. Diese Diskrepanzen treten nur selten auf. Sollte dies der Fall sein, können Sie den Vorgang wiederholen.
Jetzt gibt es auch eine Möglichkeit, die clientseitige End-to-End-Validierung in Apache Hadoop für heterogene Hadoop-kompatible Dateisysteme wie HDFS und Cloud Storage automatisch durchzuführen. In diesem Artikel wird beschrieben, wie Sie mit der neuen Funktion Dateiprüfsummen effizient und genau vergleichen können.
HDFS-Dateiprüfsummen ausführen
HDFS verwendet CRC32C, eine zyklische 32‑Bit-Redundanzprüfung (Cyclic Redundancy Check, CRC) auf Grundlage eines Castagnoli-Polynoms zur Wahrung der Datenintegrität in verschiedenen Kontexten:
- Bei Inaktivität überprüft Hadoop DataNodes Daten kontinuierlich anhand gespeicherter CRCs, um Bitrot zu erkennen und zu reparieren.
- Während der Übertragung senden die DataNodes bekannte CRCs zusammen mit den entsprechenden Bulk-Daten und die HDFS-Clientbibliotheken berechnen gemeinsam CRCs pro Chunk, um sie mit den von den DataNodes empfangenen CRCs zu vergleichen.
- Für HDFS-Verwaltungszwecke werden Prüfsummen auf Blockebene für untergeordnete manuelle Integritätsprüfungen einzelner Blockdateien in DataNodes verwendet.
- Für Anwendungsfälle auf beliebiger Anwendungsebene definiert die
FileSystem-SchnittstellegetFileChecksumund die HDFS-Implementierung verwendet ihre gespeicherten, detailgenauen CRCs, um eine Prüfsumme auf Dateiebene zu definieren.
Für die meisten täglichen Anwendungen werden die CRCs in Bezug auf die Anwendungsebene transparent verwendet. Als einzige CRCs werden die CRC32Cs pro Block verwendet, die bereits vorberechnet und zusammen mit Blockdaten in Metadatendateien gespeichert sind. Die Blockgröße wird durch dfs.bytes-per-checksum definiert und hat einen Standardwert von 512 Byte.
Schwachstellen des standardmäßigen Dateiprüfsummentyps von Hadoop
Bei Verwendung von Hadoop haben alle per API bereitgestellten Prüfsummen standardmäßig die Form einer MD5 der Verkettung von Chunk-CRC32Cs, entweder auf Blockebene über das untergeordnete DataTransferProtocol oder auf Dateiebene über die übergeordnete FileSystem-Schnittstelle. Eine Prüfsumme auf Dateiebene ist als MD5 der Verkettung aller Blockprüfsummen definiert, von denen jede eine MD5 einer Verkettung von Chunk-CRCs ist und daher als MD5MD5CRC32FileChecksum bezeichnet wird. Dies ist praktisch ein On-Demand-Merkle-Baum mit drei Ebenen.
Diese Definition der Prüfsumme auf Dateiebene hängt von den Implementierungs- und Datenlayout-Details des HDFS ab, vor allem von der Chunk-Größe (standardmäßig 512 Byte) und der Blockgröße (standardmäßig 128 MB). Daher ist diese standardmäßige Dateiprüfsumme in folgenden Situationen nicht geeignet:
- Zwei verschiedene Kopien derselben Dateien in HDFS, für die jedoch unterschiedliche Blockgrößen pro Datei konfiguriert sind
- Zwei verschiedene Instanzen von HDFS, für die unterschiedliche Block- oder Chunk-Größen konfiguriert sind
- Hadoop-kompatible Dateisysteme (Hadoop Compatible File System, HCFS) mit einer Kombination aus HDFS und Nicht-HDFS, z. B. Cloud Storage
Das folgende Diagramm zeigt, wie dieselbe Datei je nach Konfiguration des Dateisystems zu unterschiedlichen Prüfsummen führen kann:
Sie können die Standardprüfsumme für eine Datei in HDFS mit dem Hadoop-Befehl fs -checksum anzeigen lassen:
hadoop fs -checksum hdfs:///user/bob/data.bin
In einem HDFS-Cluster mit einer Blockgröße von 64 MB (dfs.block.size=67108864) wird mit diesem Befehl ein Ergebnis wie das folgende aufgerufen:
hdfs:///user/bob/data.bin MD5-of-131072MD5-of-512CRC32C 000002000000000000020000e9378baa1b8599e50cca212ccec2f8b7
Für dieselbe Datei in einem anderen Cluster mit einer Blockgröße von 128 MB (dfs.block.size=134217728) wird ausgegeben:
hdfs:///user/bob/data.bin MD5-of-0MD5-of-512CRC32C 000002000000000000000000d3a7bae0b5200ed6707803a3911959f9
Diese Beispiele zeigen, dass sich die beiden Prüfsummen für dieselbe Datei unterscheiden.
Funktionsweise der neuen zusammengesetzten CRC-Prüfsumme von Hadoop
Ein in HDFS-13056 erfasster Prüfsummentyp wurde in Apache Hadoop 3.1.1 implementiert, um diese Schwachstellen zu beheben. Der neue durch dfs.checksum.combine.mode=COMPOSITE_CRC konfigurierte Typ definiert neue zusammengesetzte Block-CRCs und zusammengesetzte Datei-CRCs als das mathematisch zusammengesetzte CRC für die gespeicherten Chunk-CRCs. Die Verwendung dieses Typs ersetzt die Verwendung einer MD5 der Komponenten-CRCs, um einen einzelnen CRC zu berechnen, der den gesamten Block oder die gesamte Datei darstellt und unabhängig vom untergeordneten Detaillierungsgrad von Chunk-CRCs ist.
Die CRC-Zusammensetzung hat viele Vorteile: Sie ist effizient, sie ermöglicht die vollständige Chunk- und Blockunabhängigkeit der resultierenden Prüfsummen, den Vergleich zwischen Stripeset- und replizierten Dateien, zwischen verschiedenen HDFS-Instanzen und zwischen HDFS und anderen externen Speichersystemen. (Weitere Informationen zum CRC-Algorithmus finden Sie in diesem PDF-Download.)
Das folgende Diagramm zeigt, wie die Prüfsumme einer Datei nach der Übertragung über heterogene Dateisystemkonfigurationen konsistent ist:
Diese Funktion ist minimal-invasiv: Sie kann direkt hinzugefügt werden, sodass sie mit vorhandenen Blockmetadaten kompatibel ist, und sie muss den normalen Pfad der Chunk-Validierung nicht ändern. Das bedeutet auch, dass selbst große, bereits vorhandene HDFS-Bereitstellungen diese Funktion nutzen können, um Daten rückwirkend zu synchronisieren. Falls Sie weitere Informationen wünschen, können Sie das vollständige PDF-Dokument herunterladen.
Neuen zusammengesetzten CRC-Prüfsummentyp verwenden
Wenn Sie den neuen zusammengesetzten CRC-Prüfsummentyp mit Hadoop verwenden möchten, legen Sie das Attribut dfs.checksum.combine.mode auf COMPOSITE_CRC (anstatt auf den Standardwert MD5MD5CRC) fest. Wird eine Datei von einem Speicherort an einen anderen kopiert, muss der Prüfsummentyp auf Chunk-Ebene (d. h. das Attribut dfs.checksum.type, das standardmäßig CRC32C lautet) auch an beiden Speicherorten übereinstimmen.
Sie können den neuen Prüfsummentyp für eine Datei in HDFS anzeigen lassen. Übergeben Sie dazu das Argument -Ddfs.checksum.combine.mode=COMPOSITE_CRC-Ddfs.checksum.combine.mode=COMPOSITE_CRC an den Hadoop-Befehl fs -checksum:
hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -checksum hdfs:///user/bob/data.bin
Unabhängig von der Blockgrößenkonfiguration des HDFS-Clusters sehen Sie die gleiche Ausgabe wie die folgende:
hdfs:///user/bob/data.bin COMPOSITE-CRC32C c517d290
Für Cloud Storage müssen Sie auch das Attribut fs.gs.checksum.type von Cloud Storage-Connector auf CRC32C festlegen. Andernfalls verwendet dieses Attribut NONE, sodass Dateiprüfsummen standardmäßig deaktiviert sind. Dieses Standardverhalten von Cloud Storage-Connector ist eine vorbeugende Maßnahme, um ein Problem mit distcp zu vermeiden. Wenn die Prüfsummentypen nicht übereinstimmen, wird damit anstelle eines Fehlers eine Ausnahme ausgelöst. Der Befehl sieht folgendermaßen aus:
hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -Dfs.gs.checksum.type=CRC32C -checksum gs://[BUCKET]/user/bob/data.bin
Die Befehlsausgabe ist identisch mit der im vorherigen Beispiel für HDFS:
gs://[BUCKET]/user/bob/data.bin COMPOSITE-CRC32C c517d290
Sie sehen, dass die von den vorherigen Befehlen zurückgegebenen zusammengesetzten CRC-Prüfsummen unabhängig von der Blockgröße und zwischen HDFS und Cloud Storage übereinstimmen. Durch die Verwendung zusammengesetzter CRC-Prüfsummen können Sie jetzt die Beibehaltung der Datenintegrität beim Übertragen von Dateien zwischen allen Arten von Hadoop-Clusterkonfigurationen erreichen.
Wenn Sie distcp wie im folgenden Beispiel ausführen, erfolgt die Überprüfung automatisch.
hadoop distcp -Ddfs.checksum.combine.mode=COMPOSITE_CRC -Dfs.gs.checksum.type=CRC32C hdfs:///user/bob/* gs://[BUCKET]/user/bob/
Wenn distcp während des Kopiervorgangs einen Prüfsummenkonflikt zwischen der Quelle und dem Ziel erkennt, schlägt der Vorgang fehl und gibt eine Warnung zurück.
Zugriff auf die Funktion
Die neue Funktion für zusammengesetzte CRC-Prüfsummen ist auch in Apache Hadoop 3.1.1 verfügbar (siehe Versionshinweise). Eine Rückportierung in die Versionen 2.7, 2.8 und 2.9 befindet sich in der Entwicklung. Die Funktion ist seit Ende 2018 standardmäßig in Sub-Minor-Versionen von Cloud Dataproc 1.3 enthalten.