Sinkronisasi Data Cluster HBase dengan alat HashTable/SyncTable

Replikasi (dibahas dalam artikel blog sebelumnya) telah dirilis untuk sementara waktu dan merupakan salah satu fitur Apache HBase yang paling banyak digunakan. Memiliki cluster yang mereplikasi data dengan rekan yang berbeda adalah penerapan yang sangat umum, baik sebagai strategi DR atau hanya sebagai cara yang mulus untuk mereplikasi data antara lingkungan produksi/pementasan/pengembangan. Meskipun ini merupakan cara yang efisien untuk menjaga agar database HBase yang berbeda tetap sinkron dalam latensi sub-detik, replikasi hanya beroperasi pada data yang diserap setelah fitur diaktifkan. Itu berarti data yang sudah ada sebelumnya di semua cluster yang terlibat dalam penyebaran replikasi masih perlu disalin di antara rekan-rekan dengan cara lain. Ada beberapa alat yang dapat digunakan untuk menyinkronkan data yang sudah ada sebelumnya pada kelompok rekan yang berbeda. Snapshots, BulkLoad, CopyTable adalah contoh terkenal dari alat tersebut yang tercakup dalam posting blog Cloudera sebelumnya. Dalam artikel ini kita akan membahas HashTable/SyncTable, merinci beberapa logika implementasi internalnya, pro dan kontra penggunaannya, dan bagaimana perbandingannya dengan beberapa teknik penyalinan data lain yang disebutkan di atas.

Singkatnya HashTable/SyncTable

HashTable/SyncTable adalah alat yang diimplementasikan sebagai dua pekerjaan pengurangan peta yang dijalankan sebagai langkah individual. Tampilannya mirip dengan CopyTable alat, yang dapat melakukan salinan data sebagian atau seluruh tabel. Tidak seperti CopyTable itu hanya menyalin data yang berbeda antara cluster target, menghemat sumber daya jaringan dan komputasi selama prosedur penyalinan.

Langkah pertama yang harus dijalankan dalam proses adalah HashTable pekerjaan pengurangan peta. Ini harus dijalankan pada cluster yang datanya harus disalin ke rekan jarak jauh, biasanya cluster sumber. Contoh singkat tentang cara menjalankannya ditunjukkan di bawah ini, penjelasan mendetail tentang setiap parameter yang diperlukan diberikan nanti di artikel ini:

hbase org.apache.hadoop.hbase.mapreduce.HashTable --families=cf my-table /hashes/test-tbl…20/04/28 05:05:48 INFO mapreduce.Job:  map 100% mengurangi 100 %20/04/28 05:05:49 INFO mapreduce.Pekerjaan:Job job_1587986840019_0001 berhasil diselesaikan20/04/28 05:05:49 INFO mapreduce.Pekerjaan:Penghitung:68…Format Input File Penghitung Bytes Baca=0File Output Format Penghitung Bytes Tertulis=6811788

Setelah HashTable eksekusi pekerjaan dengan perintah di atas selesai, beberapa file output telah dihasilkan di sumber hdfs /hashes/my-table direktori:

hdfs dfs -ls -R /hashes/test-tbldrwxr-xr-x   - root supergroup          0 2020-04-28 05:05 /hashes/test-tbl/hashes-rw-r--r--   2 root supergrup          0 28-04-2020 05:05 /hashes/test-tbl/hashes/_SUCCESSdrwxr-xr-x   - root supergrup          0 28-04-2020 05:05 /hashes/test-tbl/hashes/part-r-00000 -rw-r--r--   2 root supergrup    6790909 28-04-2020 05:05 /hashes/test-tbl/hashes/part-r-00000/data-rw-r--r--   2 root supergrup      20879 28-04-2020 05:05 /hashes/test-tbl/hashes/part-r-00000/index-rw-r--r--   2 root supergroup         99 2020-04-28 05:04 /hashes/test- tbl/manifest-rw-r--r--   2 root supergrup        153 28-04-2020 05:04 /hashes/test-tbl/partitions

Ini diperlukan sebagai masukan untuk SyncTable Lari. SyncTable harus diluncurkan pada rekan target. Perintah di bawah ini menjalankan SyncTable untuk keluaran HashTable dari contoh sebelumnya. Ini menggunakan dryrun opsi dijelaskan nanti di artikel ini:

hbase org.apache.hadoop.hbase.mapreduce.SyncTable --dryrun --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://source- cluster-active-nn/hashes/test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97146HASHES_NOT_MATCHED=2MATCHINGCELLS=17MATCHINGROWS=2CHINGROWS=2 1

Sebagai referensi cepat, Anda dapat mengganti parameter yang diberikan pada kedua contoh dengan nilai lingkungan Anda yang sebenarnya. Sisa artikel ini akan membahas detail implementasi secara lebih mendalam.

Mengapa dua langkah berbeda?

Tujuan utama dari alat ini adalah untuk mengidentifikasi dan menyalin hanya data yang hilang di antara dua cluster. HashTable bekerja sebagai pekerjaan sharding/pengindeksan, menganalisis kumpulan data tabel dan menghasilkan indeks hash untuk setiap batch ini. Ini adalah output yang ditulis dalam file di bawah /hashes/my-table direktori hdfs dilewatkan sebagai salah satu parameter pekerjaan. Seperti disebutkan sebelumnya, output ini diperlukan oleh SyncTable pekerjaan. SyncTable memindai tabel target secara lokal dalam ukuran batch yang sama seperti yang digunakan oleh HashTable, dan juga menghitung nilai hash untuk kumpulan ini menggunakan fungsi yang sama yang digunakan oleh HashTable. Kemudian membandingkan hash batch lokal nilai dengan satu dari HashTable keluaran. Jika nilai hash sama, itu berarti seluruh batch identik di dua cluster, dan tidak ada yang perlu disalin pada segmen itu. Jika tidak, ini akan membuka pemindaian untuk kumpulan di kluster sumber, memeriksa apakah setiap sel sudah ada di kluster target, hanya menyalin sel yang berbeda. Pada set data yang sedikit berbeda, ini akan menghasilkan lebih sedikit data yang disalin di antara dua cluster. Ini juga hanya membutuhkan sejumlah kecil sel untuk dipindai di sumber untuk memeriksa ketidakcocokan.

Parameter yang Diperlukan

HashTable hanya membutuhkan dua parameter:nama tabel dan jalur keluaran tempat hash terkait dan file info meta lainnya akan ditulis. SyncTable menggunakan HashTable output dir sebagai input, bersama dengan nama tabel di sumber dan di cluster target, masing-masing. Karena kami menggunakan HashTable /SyncTable untuk memindahkan data antar cluster jarak jauh, sourcezkcluster opsi harus ditentukan untuk SyncTable . Ini harus menjadi alamat kuorum penjaga kebun binatang dari cluster sumber. Dalam contoh artikel ini, kami juga telah mereferensikan alamat node nama aktif cluster sumber secara langsung, sehingga SyncTable akan membaca file output hash langsung dari cluster sumber. Atau, HashTable output dapat disalin secara manual dari cluster sumber ke cluster jarak jauh (dengan distcp, misalnya).

CATATAN:Bekerja dengan kluster jarak jauh di bawah ranah kerberos yang berbeda hanya didukung dari CDH 6.2.1 dan seterusnya.

Opsi lanjutan

Keduanya HashTable dan SyncTable menawarkan opsi opsional tambahan yang dapat disesuaikan untuk hasil yang optimal.

HashTable memungkinkan untuk memfilter data dengan kunci baris dan waktu modifikasi, dengan startrow/starttime, stoprow/stoptime properti, masing-masing. Cakupan kumpulan data juga dapat dibatasi oleh versi dan keluarga properti. ukuran batch properti mendefinisikan ukuran setiap bagian yang akan di-hash. Ini berdampak langsung pada kinerja sinkronisasi. Dalam kasus ketidakcocokan yang sangat sedikit, menyetel nilai ukuran kumpulan yang lebih besar dapat menghasilkan kinerja yang lebih baik karena bagian kumpulan data yang lebih besar akan diabaikan tanpa perlu dipindai oleh SyncTable.

SyncTable menyediakan dryrun opsi yang memungkinkan pratinjau perubahan diterapkan di target.

SyncTable perilaku default adalah untuk mencerminkan data sumber di sisi target, jadi setiap sel tambahan yang ada di target tetapi tidak ada di sumber akhirnya dihapus di sisi target. Itu bisa tidak diinginkan saat menyinkronkan cluster di bawah pengaturan replikasi Aktif-Aktif dan untuk kasus seperti itu, doDeletes opsi dapat diubah menjadi false, melewatkan replikasi penghapusan pada target. Ada juga doPuts similar yang serupa tandai untuk kasus di mana sel tambahan tidak boleh dimasukkan ke dalam cluster target.

Menganalisis keluaran

HashTable mengeluarkan beberapa file dengan informasi meta untuk SyncTable, mereka, bagaimanapun, tidak dapat dibaca manusia. Itu tidak melakukan perubahan apa pun pada data yang ada, jadi info terkait kurang menarik untuk konteks pengguna.

SyncTable adalah langkah yang benar-benar menerapkan modifikasi pada target dan mungkin penting untuk meninjau ringkasannya sebelum benar-benar mengubah data cluster target (lihat dryrun opsi yang disebutkan di atas). Ini menerbitkan beberapa penghitung yang relevan di akhir peta mengurangi eksekusi. Melihat nilai dari contoh di atas, kita dapat melihat ada 97148 partisi di-hash (dilaporkan oleh BATCHES counter), yang SyncTable mendeteksi divergensi hanya dalam dua di antaranya (menurut HASHES_MATCHED dan HASHES_NOT_MACTHED penghitung). Selain itu, dalam dua partisi yang memiliki hash berbeda, 17 sel lebih dari 2 baris cocok (seperti yang dilaporkan oleh MATCHING_CELLS dan MATCHING_ROWS, masing-masing), tetapi ada juga 2 baris divergen, pada dua partisi ini (menurut RANGESNOTMATCHED dan ROWSWITHDIFFS ). Akhirnya, SOURCEMISSINGCELLS dan TARGETHILANG SEL beri tahu kami secara detail jika sel hanya ada di sumber atau kluster target. Dalam contoh ini, cluster sumber memiliki satu sel yang tidak berada pada target, tetapi target juga memiliki sel yang tidak berada pada sumber. Sejak SyncTable dijalankan tanpa menentukan dryrun opsi dan pengaturan doDeletes pilihan untuk salah , pekerjaan telah menghapus sel ekstra di kluster target dan telah menambahkan sel ekstra yang ditemukan di sumber ke kluster target. Dengan asumsi tidak ada tulisan terjadi pada kedua kluster, proses berikutnya dari SyncTable . yang sama perintah di cluster target tidak akan menunjukkan perbedaan:

hbase org.apache.hadoop.hbase.mapreduce.SyncTable --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://nn:9000/hashes /test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97148…

Skenario yang Berlaku

Sinkronisasi Data

Sekilas, HashTable/SyncTable mungkin tampak tumpang tindih dengan CopyTable alat, tetapi masih ada skenario khusus di mana salah satu alat akan lebih cocok. Sebagai contoh perbandingan pertama, menggunakan HashTable/SyncTable untuk pemuatan awal tabel yang berisi 100.004 baris dan total ukuran data 5,17 GB diperlukan beberapa menit hanya untuk SyncTable untuk menyelesaikan:

...20/04/29 03:48:00 INFO mapreduce.Job:Menjalankan job:job_1587985272792_001120/04/29 03:48:09 INFO mapreduce.Job:Job job_1587985272792_0011 berjalan dalam mode uber :false20/04/ 29 03:48:09 INFO mapreduce.Pekerjaan: map 0% reduce 0%20/04/29 03:54:08 INFO mapreduce.Job: map 100% reduce 0%20/04/29 03:54:09 INFO mapreduce .Pekerjaan:Pekerjaan pekerjaan_1587985272792_0011 berhasil diselesaikan…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148EMPTY_BATCHES=97148HASHES_NOT_MATCHED=97148RANGESNOTMATCHED=97148ROWSWITHDIFFS>

Bahkan pada dataset kecil seperti itu, CopyTable dieksekusi lebih cepat (kira-kira 3 menit, sementara SyncTable butuh 6 menit untuk menyalin seluruh kumpulan data):

...20/04/29 05:12:07 INFO mapreduce.Job:Menjalankan job:job_1587986840019_000520/04/29 05:12:24 INFO mapreduce.Job:Job job_1587986840019_0005 berjalan dalam mode uber :false20/04/ 29 05:12:24 INFO mapreduce.Pekerjaan: map 0% reduce 0%20/04/29 05:13:16 INFO mapreduce.Job: map 25% reduce 0%20/04/29 05:13:49 INFO mapreduce .Pekerjaan: kurangi peta 50% 0%20/04/29 05:14:37 INFO mapreduce.Pekerjaan: map 75% kurangi 0%20/04/29 05:15:14 INFO mapreduce.Pekerjaan: map 100% kurangi 0 %20/04/29 05:15:14 INFO mapreduce.Job:Job job_1587986840019_0005 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2787236791BYTES_IN_RESULTS=5549784428MILLIS_BETWEEN_NEXTS=130808NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1334REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100004RPC_CALLS=2657RPC_RETRIES=0

Sekarang mari kita gunakan kedua alat itu lagi untuk menangani perbedaan yang jarang pada kumpulan data. tes-tbl tabel yang digunakan pada semua contoh ini memiliki empat wilayah di cluster sumber. Setelah semua kumpulan data asli disalin ke cluster target pada contoh sebelumnya, kami menambahkan empat baris tambahan di sisi sumber saja, satu untuk setiap wilayah yang ada, lalu jalankan HashTable/SyncTable lagi untuk sinkronisasi kedua cluster:

20/04/29 05:29:23 INFO mapreduce.Job:Menjalankan job:job_1587985272792_001320/04/29 05:29:39 INFO mapreduce.Job:Job job_1587985272792_0013 berjalan dalam mode uber :false20/04/29 05:29:39 INFO mapreduce.Pekerjaan:  map 0% reduce 0%20/04/29 05:29:53 INFO mapreduce.Pekerjaan:  map 50% reduce 0%20/04/29 05:30:42 INFO mapreduce.Pekerjaan:peta 100% pengurangan 0%20/04/29 05:30:42 INFO mapreduce.Pekerjaan:Pekerjaan pekerjaan_1587985272792_0013 berhasil diselesaikan…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97144HASHES_NOT_MATCHCELLS=4MATCHINGCHELLS=4MATCH 5RANGESNOTMATCHED=4ROWSWITHDIFFS=4TARGETMISSINGCELLS=4TARGETMISSINGROWS=4

Kita bisa melihatnya hanya dengan empat partisi tidak cocok, SyncTable jauh lebih cepat (kira-kira satu menit untuk menyelesaikan). Menggunakan CopyTable untuk melakukan sinkronisasi yang sama ini menunjukkan hasil sebagai berikut:

20/04/29 08:32:38 INFO mapreduce.Job:Menjalankan job:job_1587986840019_000820/04/29 08:32:52 INFO mapreduce.Job:Job job_1587986840019_0008 berjalan dalam mode uber :false20/04/29 08:32:52 INFO mapreduce.Pekerjaan:  map 0% reduce 0%20/04/29 08:33:38 INFO mapreduce.Job:  map 25% reduce 0%20/04/29 08:34:15 INFO mapreduce.Pekerjaan:map 50% kurangi 0%20/04/29 08:34:48 INFO mapreduce.Pekerjaan:  map 75% kurangi 0%20/04/29 08:35:31 INFO mapreduce.Job:  map 100% kurangi 0%20/ 04/29 08:35:32 INFO mapreduce.Job:Job job_1587986840019_0008 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2762547723BYTES_IN_RESULTS=5549784600MILLIS_BETWEEN_NEXTS=340672NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1323REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100008RPC_CALLS=2657RPC_RETRIES=0

CopyTable membutuhkan waktu yang sama untuk menyinkronkan tabel seperti saat menyalin seluruh kumpulan data, meskipun hanya ada empat sel untuk disalin. Ini masih ok untuk dataset yang sangat kecil ini, dan dengan cluster yang tidak aktif, tetapi dalam kasus penggunaan produksi dengan set data yang lebih besar dan di mana cluster target juga dapat digunakan oleh banyak aplikasi klien yang menulis data di dalamnya, CopyTable penurunan kinerja dibandingkan dengan SyncTable akan lebih tinggi lagi.

Perlu disebutkan bahwa ada juga alat/fitur tambahan yang dapat digunakan dalam kombinasi untuk pemuatan awal kluster target (target tidak memiliki data sama sekali), seperti ekspor snapshot, pemuatan massal, atau bahkan salinan langsung dari file asli. direktori tabel dari cluster sumber. Untuk pemuatan awal dengan jumlah data yang besar untuk disalin, ambil snapshot tabel lalu gunakan ExportSnapshot alat akan mengungguli alat salin online seperti SyncTable atau CopyTable.

Memeriksa Integritas Replikasi

Penggunaan umum lainnya dari HashTable/SyncTable adalah untuk memantau status replikasi antar kluster, saat memecahkan masalah kemungkinan replikasi. Dalam skenario ini berfungsi sebagai alternatif alat VerifyReplication. Biasanya saat memeriksa status antara dua kluster, tidak ada ketidakcocokan sama sekali atau masalah sementara telah menyebabkan sebagian kecil dari kumpulan data yang lebih besar tidak sinkron. Di lingkungan pengujian yang telah kami gunakan untuk contoh kami sebelumnya harus ada 100.008 baris dengan nilai yang cocok di kedua cluster. Menjalankan SyncTable pada cluster tujuan dengan opsi dryrun akan memungkinkan kami mengidentifikasi perbedaan apa pun:

20/05/04 10:47:25 INFO mapreduce.Job:Menjalankan job:job_1588611199158_0004…20/05/04 10:48:48 INFO mapreduce.Job:  map 100% mengurangi 0%20/05/04 10 :48:48 INFO mapreduce.Pekerjaan:Pekerjaan pekerjaan_158861199158_0004 berhasil diselesaikan…Penghitung HBaseBYTES_IN_REMOTE_RESULTS=3753476784BYTES_IN_RESULTS=5549784600ROWS_SCANNED=100008…org.apache.hadoop.hbase.mapreduce.SyncTable47 alat VerifyReplication pada cluster sumber. Kami meneruskan id rekan sebagai salah satu parameternya sehingga dapat menemukan cluster jarak jauh untuk dipindai sebagai perbandingan:20/05/04 11:01:58 INFO mapreduce.Job:Running job:job_1588611196128_0001…20/05/04 11:04:39 INFO mapreduce.Job:  map 100% reduce 0%20/05/04 11:04:39 INFO mapreduce.Job:Job job_1588611196128_0001 berhasil diselesaikan… Penghitung HBaseBYTES_IN_REMOTE_RESULTS=2761955495BYTES_IN_RESULTS=5549784600…org.apache.hadoreduce .replication.VerifyReplication$Verifier$CountersGOODROWS=100008...

Tanpa perbedaan, SyncTable menemukan semua hash yang cocok antara partisi sumber dan target dan dengan demikian, menghindari kebutuhan untuk memindai kluster sumber jarak jauh lagi. VerifyReplication melakukan perbandingan satu per satu untuk setiap sel di kedua cluster yang mungkin sudah membawa biaya jaringan yang tinggi bahkan ketika berurusan dengan kumpulan data kecil seperti itu.

Menambahkan satu baris tambahan di cluster sumber dan melakukan pemeriksaan lagi. Dengan VerifyReplication:

20/05/05 11:14:05 INFO mapreduce.Job:Menjalankan job:job_1588611196128_0004…20/05/05 11:16:32 INFO mapreduce.Job:  map 100% mengurangi 0%20/05/05 11 :16:32 INFO mapreduce.Pekerjaan:Pekerjaan pekerjaan_1588611196128_0004 berhasil diselesaikan…org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$CountersBADROWS=1GOODROWS=100008ONLY_IN_SOURCE_TABLE_ROWS=1…

Sebelum kita dapat menggunakan SyncTable, kita harus membuat ulang hash pada sumber dengan HashTable lagi, karena sekarang ada sel baru:

20/05/04 11:31:48 INFO mapreduce.Job:Menjalankan job:job_1588611196128_0003…20/05/04 11:33:15 INFO mapreduce.Job:Job job_1588611196128_0003 berhasil diselesaikan...

Sekarang SyncTable:

20/05/07 05:47:51 INFO mapreduce.Job:Menjalankan job:job_1588611199158_0014…20/05/07 05:49:20 INFO mapreduce.Job:Job job_1588611199158_0014 berhasil diselesaikan… org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_NOT_MATCHED=97148MATCHINGCELLS=749593MATCHINGROWS=100008RANGESMATCHED=97147RANGESNOTMATCHED=1ROWSWITHDIFFS>pre=1TARGETMISSING

Kita dapat melihat peningkatan waktu eksekusi karena pemindaian tambahan dan perbandingan sel antara dua cluster jarak jauh. Sementara itu, waktu eksekusi VerifyReplication menunjukkan sedikit variasi.

Kesimpulan

HashTable/SyncTable adalah alat yang berharga untuk memindahkan data, ketika berhadapan dengan ketidakcocokan yang jarang antara dua kumpulan data cluster. Itu membuat penggunaan partisi data dan hashing untuk secara efisien mendeteksi perbedaan pada rentang dari dua set data, mengurangi jumlah sel yang akan dipindai saat membandingkan data dari dua cluster, sementara juga menghindari penempatan nilai yang sudah ada yang tidak perlu di cluster target. Ini bukan peluru perak, seperti yang ditunjukkan pada beberapa contoh di atas, sementara itu mungkin tampak tumpang tindih fungsinya dengan CopyTable alat, yang terakhir dapat menawarkan kinerja yang lebih baik saat menangani rentang sel yang tidak cocok dan berurutan yang lebih besar. Dalam hal ini, HashTable/SyncTable akan paling dapat diterapkan dalam kasus di mana kedua cluster sudah memiliki beberapa data yang berada, atau dalam kasus di mana pengaturan replikasi yang ada telah terganggu oleh tidak tersedianya sementara salah satu rekan.