Saat Anda menyalin atau memindahkan data antara sistem penyimpanan yang berbeda, seperti beberapa cluster Apache Hadoop Distributed File System (HDFS) atau antara HDFS dan Cloud Storage, sebaiknya lakukan beberapa jenis validasi untuk menjamin integritas data. Validasi ini penting untuk memastikan data tidak diubah selama transfer.
Meskipun berbagai mekanisme sudah memastikan integritas data point-to-point dalam pengiriman (seperti TLS untuk semua komunikasi dengan Cloud Storage), validasi integritas data menyeluruh secara eksplisit menambahkan perlindungan untuk kasus yang mungkin tidak terdeteksi oleh mekanisme transit standar. Hal ini dapat membantu Anda mendeteksi potensi kerusakan data yang disebabkan, misalnya, link jaringan yang berisik, error memori pada komputer server dan router di sepanjang jalur, atau bug software (seperti di library yang digunakan pelanggan ).
Untuk Cloud Storage, validasi ini terjadi secara otomatis di sisi klien dengan perintah Google Cloud CLI seperti cp dan rsync. Perintah tersebut menghitung checksums file lokal, yang kemudian divalidasi terhadap checksum yang dihitung oleh Cloud Storage di akhir setiap operasi. Jika checksum tidak cocok, gcloud CLI akan menghapus salinan yang tidak valid dan mencetak pesan peringatan. Ketidakcocokan ini jarang terjadi, dan jika demikian, Anda dapat mencoba kembali
operasi tersebut.
Kini ada cara untuk otomatis melakukan validasi end-to-end dari sisi klien di Apache Hadoop di seluruh sistem file heterogen yang kompatibel dengan Hadoop, seperti HDFS dan Cloud Storage. Artikel ini menjelaskan bagaimana fitur baru ini memungkinkan Anda membandingkan checksum file secara efisien dan akurat.
Cara HDFS melakukan checksum file
HDFS menggunakan CRC32C, pemeriksaan redundansi siklik (CRC) 32 bit berdasarkan polinomial Castagnoli, untuk mempertahankan integritas data dalam konteks yang berbeda:
- Dalam penyimpanan, Hadoop DataNodes terus memverifikasi data terhadap CRC yang tersimpan untuk mendeteksi dan memperbaiki bit-rot.
- Saat transit, DataNode mengirimkan CRC yang diketahui bersama dengan data massal yang sesuai, dan library klien HDFS secara kooperatif menghitung CRC per bagian untuk dibandingkan dengan CRC yang diterima dari DataNode.
- Untuk tujuan administratif HDFS, checksum level blok digunakan untuk pemeriksaan integritas manual tingkat rendah pada setiap file blok di DataNode.
- Untuk kasus penggunaan lapisan aplikasi arbitrer, antarmuka
FileSystemmenentukangetFileChecksum, dan implementasi HDFS menggunakan CRC detail yang tersimpan untuk menentukan checksum tingkat file.
Untuk sebagian besar penggunaan sehari-hari, CRC digunakan secara transparan terkait dengan
lapisan aplikasi. Satu-satunya CRC yang digunakan adalah CRC32C per bagian, yang
sudah dihitung sebelumnya dan disimpan dalam file metadata bersama data blok. Ukuran potongan
ditentukan oleh dfs.bytes-per-checksum dan memiliki nilai default 512 byte.
Kekurangan dari jenis checksum file default di Hadoop
Secara default saat menggunakan Hadoop, semua checksum yang terekspos API berbentuk
MD5
yang merupakan penyambungan dari bagian CRC32C,
baik di level blok hingga level rendah DataTransferProtocol, atau pada
level file melalui antarmuka FileSystem level atas. Checksum level file didefinisikan sebagai MD5 dari penyambungan semua {i>checksum<i} blok,
yang masing-masing merupakan MD5 gabungan dari potongan CRC, dan oleh karena itu
disebut sebagai MD5MD5CRC32FileChecksum. Ini sebenarnya adalah pohon Merkle
tiga lapis
on demand.
Definisi checksum tingkat file ini sensitif terhadap implementasi dan detail tata letak data HDFS, yaitu ukuran potongan (default 512 byte) dan ukuran blok (default 128 MB). Jadi, checksum file default ini tidak cocok dalam salah satu situasi berikut:
- Dua salinan berbeda dari file yang sama dalam HDFS, tetapi dengan ukuran blok per file yang berbeda dikonfigurasi.
- Dua instance HDFS berbeda dengan ukuran blok atau potongan berbeda yang telah dikonfigurasi.
- Kombinasi sistem file yang kompatibel dengan Hadoop (HCFS) HDFS dan non-HDFS seperti Cloud Storage.
Diagram berikut menunjukkan bagaimana file yang sama dapat memiliki checksum yang berbeda, bergantung pada konfigurasi sistem file:
Anda dapat menampilkan checksum default untuk file dalam HDFS menggunakan perintah
fs -checksum Hadoop:
hadoop fs -checksum hdfs:///user/bob/data.bin
Dalam cluster HDFS yang memiliki ukuran blok 64 MB (dfs.block.size=67108864),
perintah ini akan menampilkan hasil seperti berikut:
hdfs:///user/bob/data.bin MD5-of-131072MD5-of-512CRC32C 000002000000000000020000e9378baa1b8599e50cca212ccec2f8b7
Untuk file yang sama dalam cluster lain yang memiliki ukuran blok 128 MB
(dfs.block.size=134217728), Anda akan melihat output yang berbeda:
hdfs:///user/bob/data.bin MD5-of-0MD5-of-512CRC32C 000002000000000000000000d3a7bae0b5200ed6707803a3911959f9
Anda dapat melihat dalam contoh ini bahwa kedua {i>checksum<i} berbeda untuk file yang sama.
Cara kerja checksum file CRC komposit baru Hadoop
Jenis checksum baru, yang dilacak di
HDFS-13056,
dirilis di Apache Hadoop 3.1.1 untuk mengatasi kekurangan ini. Jenis
baru, yang dikonfigurasi oleh dfs.checksum.combine.mode=COMPOSITE_CRC, menentukan
CRC blok komposit baru dan CRC file gabungan sebagai CRC yang disusun secara matematis di seluruh bagian CRC
yang tersimpan. Menggunakan jenis ini berarti mengganti penggunaan MD5 dari
CRC komponen untuk menghitung satu CRC yang mewakili seluruh
blok atau file, dan tidak bergantung pada perincian tingkat rendah dari CRC potongan.
Komposisi CRC memiliki banyak manfaat — efisien; memungkinkan {i>checksum<i} yang dihasilkan menjadi sepenuhnya potongan/blok agnostik; dan memungkinkan perbandingan antara file garis dan file replika, antara instance HDFS yang berbeda, serta antara HDFS dan sistem penyimpanan eksternal lainnya. (Anda dapat mempelajari detail algoritme CRC lebih lanjut di download PDF ini.)
Diagram berikut menunjukkan konsistensi checksum file setelah transfer ke seluruh konfigurasi sistem file heterogen:
Fitur ini bersifat minimal invasif: dapat ditambahkan agar kompatibel dengan metadata blok yang sudah ada, dan tidak perlu mengubah jalur normal verifikasi bagian. Ini juga berarti bahwa deployment HDFS besar yang sudah ada dapat menggunakan fitur ini untuk menyinkronkan data secara surut. Untuk mengetahui detail selengkapnya, Anda dapat mendownload dokumen PDF desain lengkap.
Menggunakan jenis checksum CRC komposit yang baru
Untuk menggunakan jenis checksum CRC komposit baru dalam Hadoop, tetapkan properti dfs.checksum.combine.mode ke COMPOSITE_CRC (bukan MD5MD5CRC nilai default). Saat file disalin dari satu lokasi ke lokasi lain, jenis checksum tingkat bagian (yaitu, properti dfs.checksum.type yang
ditetapkan secara default ke CRC32C) juga harus cocok di kedua lokasi.
Anda dapat menampilkan jenis checksum baru untuk file dalam HDFS dengan meneruskan argumen -Ddfs.checksum.combine.mode=COMPOSITE_CRC ke perintah fs -checksum Hadoop:
hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -checksum hdfs:///user/bob/data.bin
Terlepas dari konfigurasi ukuran blok cluster HDFS, Anda akan melihat output yang sama, seperti berikut ini:
hdfs:///user/bob/data.bin COMPOSITE-CRC32C c517d290
Untuk Cloud Storage, Anda juga harus menetapkan properti konektor Cloud Storage secara eksplisit fs.gs.checksum.type ke CRC32C. Jika tidak, properti ini ditetapkan secara default ke
NONE, sehingga menyebabkan checksum file dinonaktifkan secara default. Perilaku default oleh konektor Cloud Storage ini merupakan tindakan pencegahan untuk menghindari masalah distcp, yang akan memunculkan pengecualian jika jenis checksum tidak cocok, bukan gagal dengan baik. Perintahnya terlihat seperti berikut:
hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -Dfs.gs.checksum.type=CRC32C -checksum gs://[BUCKET]/user/bob/data.bin
Perintah ini menampilkan output yang sama seperti pada contoh sebelumnya di HDFS:
gs://[BUCKET]/user/bob/data.bin COMPOSITE-CRC32C c517d290
Anda dapat melihat bahwa checksum CRC gabungan yang ditampilkan oleh perintah sebelumnya semua cocok, berapa pun ukuran bloknya, serta antara HDFS dan Cloud Storage. Dengan menggunakan checksum CRC gabungan, sekarang Anda dapat menjamin bahwa integritas data dipertahankan saat mentransfer file ke semua jenis konfigurasi cluster Hadoop.
Jika Anda menjalankan distcp, seperti dalam contoh berikut, validasi akan dilakukan secara otomatis:
hadoop distcp -Ddfs.checksum.combine.mode=COMPOSITE_CRC -Dfs.gs.checksum.type=CRC32C hdfs:///user/bob/* gs://[BUCKET]/user/bob/
Jika distcp mendeteksi ketidakcocokan checksum file antara sumber dan tujuan
selama penyalinan, operasi akan gagal dan menampilkan peringatan.
Mengakses fitur
Fitur checksum CRC komposit baru tersedia di Apache Hadoop 3.1.1 (lihat catatan rilis), dan backport ke versi 2.7, 2.8, dan 2.9 sedang dikerjakan. Library ini telah disertakan secara default dalam Cloud Dataproc 1.3 versi lebih rendah sejak akhir 2018.