CopyTable adalah utilitas Apache HBase sederhana yang, secara mengejutkan, dapat digunakan untuk menyalin tabel individual dalam klaster HBase atau dari satu klaster HBase ke klaster HBase lainnya. Dalam posting blog ini, kita akan membicarakan tentang alat ini, mengapa Anda ingin menggunakannya, cara menggunakannya, dan beberapa peringatan konfigurasi umum.
Kasus penggunaan:
CopyTable pada intinya adalah pekerjaan Apache Hadoop MapReduce yang menggunakan antarmuka jalur baca HBase Scan standar untuk membaca catatan dari tabel individual dan menulisnya ke tabel lain (mungkin pada cluster terpisah) menggunakan antarmuka jalur tulis HBase Put standar. Dapat digunakan untuk berbagai tujuan:
- Salinan tabel internal (snapshot orang miskin)
- Pencadangan instans HBase jarak jauh
- Salinan tabel HBase tambahan
- Salinan tabel HBase sebagian dan skema tabel HBase berubah
Asumsi dan batasan:
Alat CopyTable memiliki beberapa asumsi dan batasan dasar. Pertama, jika digunakan dalam situasi multi-cluster, kedua cluster harus online dan instance target harus memiliki tabel target yang ada dengan keluarga kolom yang sama yang didefinisikan sebagai tabel sumber.
Karena alat ini menggunakan pemindaian dan penempatan standar, cluster target tidak harus memiliki jumlah node atau wilayah yang sama. Faktanya, ia dapat memiliki jumlah tabel yang berbeda, jumlah server wilayah yang berbeda, dan dapat memiliki batas pemisahan wilayah yang sama sekali berbeda. Karena kami menyalin seluruh tabel, Anda dapat menggunakan pengaturan pengoptimalan kinerja seperti menyetel nilai cache pemindai yang lebih besar untuk efisiensi yang lebih tinggi. Menggunakan antarmuka put juga berarti bahwa salinan dapat dibuat di antara kelompok versi minor yang berbeda. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) atau versi yang kompatibel dengan kabel (0.92.1 -> 0.94.0).
Terakhir, HBase hanya menyediakan jaminan ACID tingkat baris; ini berarti saat CopyTable sedang berlangsung, baris yang baru dimasukkan atau diperbarui dapat terjadi dan pengeditan bersamaan ini akan sepenuhnya disertakan atau sepenuhnya dikecualikan. Meskipun baris akan konsisten, tidak ada jaminan tentang konsistensi, kausalitas, atau urutan penempatan pada baris lainnya.
Salinan tabel internal (snapshot orang miskin)
Versi HBase hingga dan termasuk versi 0.94.x terbaru tidak mendukung snapshot tabel. Terlepas dari keterbatasan ACID HBase, CopyTable dapat digunakan sebagai mekanisme snapshot naif yang membuat salinan fisik dari tabel tertentu.
Katakanlah kita memiliki tabel, tableOrig dengan keluarga kolom cf1 dan cf2. Kami ingin menyalin semua datanya ke tableCopy. Kita harus terlebih dahulu membuat tableCopy dengan keluarga kolom yang sama:
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
Kami kemudian dapat membuat dan menyalin tabel dengan nama baru pada instance HBase yang sama:
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig
Ini memulai tugas MR yang akan menyalin data.
Pencadangan instans HBase jarak jauh
Katakanlah kita ingin menyalin data ke cluster lain. Ini bisa menjadi cadangan satu kali, pekerjaan berkala atau bisa untuk bootstrap untuk replikasi lintas-cluster. Dalam contoh ini, kita akan memiliki dua cluster terpisah:srcCluster dan dstCluster.
Dalam kasus multi-cluster ini, CopyTable adalah proses push — sumber Anda akan menjadi instance HBase yang dirujuk oleh hbase-site.xml Anda saat ini dan argumen yang ditambahkan mengarah ke cluster dan tabel tujuan. Ini juga mengasumsikan bahwa semua MR TaskTrackers dapat mengakses semua node HBase dan ZK di cluster tujuan. Mekanisme konfigurasi ini juga berarti bahwa Anda dapat menjalankan ini sebagai tugas pada kluster jarak jauh dengan mengganti konfigurasi hbase/mr untuk menggunakan pengaturan dari kluster jarak jauh mana pun yang dapat diakses dan menentukan node ZK di kluster tujuan. Ini bisa berguna jika Anda ingin menyalin data dari cluster HBase dengan SLA yang lebih rendah dan tidak ingin menjalankan tugas MR secara langsung.
Anda akan menggunakan pengaturan –peer.adr untuk menentukan ansambel ZK cluster tujuan (mis. cluster tempat Anda menyalin). Untuk ini, kami memerlukan IP dan port kuorum ZK serta node root ZK HBase untuk instans HBase kami. Katakanlah salah satu dari mesin ini adalah srcClusterZK (terdaftar di hbase.zookeeper.quorum) dan kita menggunakan port default zk client 2181 (hbase.zookeeper.property.clientPort) dan default ZK znode parent /hbase (zookeeper.znode. induk). (Catatan:Jika Anda memiliki dua instans HBase menggunakan ZK yang sama, Anda memerlukan zookeeper.znode.parent yang berbeda untuk setiap cluster.
# create new tableOrig on destination cluster dstCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell # on source cluster run copy table with destination ZK quorum specified using --peer.adr # WARNING: In older versions, you are not alerted about any typo in these arguments! srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase tableOrig
Perhatikan bahwa Anda dapat menggunakan argumen –new.name dengan –peer.adr untuk menyalin ke tabel dengan nama berbeda di dstCluster.
# create new tableCopy on destination cluster dstCluster$ echo "create 'tableCopy', 'cf1', 'cf2'" | hbase shell # on source cluster run copy table with destination --peer.adr and --new.name arguments. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase --new.name=tableCopy tableOrig
Ini akan menyalin data dari tableOrig di srcCluster ke tableCopy table dstCluster.
Inkremental salinan tabel HBase
Setelah Anda memiliki salinan tabel di cluster tujuan, bagaimana Anda menyalin data baru yang kemudian ditulis ke cluster sumber? Secara naif, Anda bisa menjalankan pekerjaan CopyTable lagi dan menyalin seluruh tabel. Namun, CopyTable menyediakan mekanisme penyalinan tambahan yang lebih efisien yang hanya menyalin baris yang diperbarui dari srcCluster ke dstCluster cadangan yang ditentukan dalam jangka waktu tertentu. Jadi, setelah penyalinan awal, Anda kemudian dapat memiliki tugas cron berkala yang menyalin data hanya dari jam sebelumnya dari srcCluster ke dstCuster.
Ini dilakukan dengan menentukan argumen –starttime dan –endtime. Waktu ditentukan sebagai milidetik desimal sejak waktu epoch unix.
# WARNING: In older versions, you are not alerted about any typo in these arguments! # copy from beginning of time until timeEnd # NOTE: Must include start time for end time to be respected. start time cannot be 0. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=1 --endtime=timeEnd ... # Copy from starting from and including timeStart until the end of time. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timeStart ... # Copy entries rows with start time1 including time1 and ending at timeStart excluding timeEnd. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timestart --endtime=timeEnd
Salinan tabel HBase sebagian dan perubahan skema tabel HBase
Secara default, CopyTable akan menyalin semua keluarga kolom dari baris yang cocok. CopyTable menyediakan opsi untuk hanya menyalin data dari keluarga kolom tertentu. Ini bisa berguna untuk menyalin data sumber asli dan mengecualikan keluarga kolom data turunan yang ditambahkan dengan mengikuti pemrosesan.
Dengan menambahkan argumen ini, kami hanya menyalin data dari keluarga kolom yang ditentukan.
- –families=srcCf1
- –families=srcCf1,srcCf2
Mulai dari 0.92.0 Anda dapat menyalin sambil mengubah nama keluarga kolom:
- –keluarga=srcCf1:dstCf1
- salin dari srcCf1 ke dstCf1
- –keluarga=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
- salin dari srcCf1 ke destCf1, salin dstCf2 ke dstCf2 (tanpa ganti nama), dan srcCf3 ke dstCf3
Harap dicatat bahwa dstCf* harus ada di tabel dstCluster!
Mulai dari 0.94.0 opsi baru ditawarkan untuk menyalin penanda penghapusan dan menyertakan sejumlah versi yang ditimpa. Sebelumnya, jika sebuah baris dihapus di cluster sumber, penghapusan tidak akan disalin — sebagai gantinya, versi basi dari baris tersebut akan tetap berada di cluster tujuan. Ini memanfaatkan beberapa fitur lanjutan rilis 0.94.0.
- –versi=vers
- di mana vers adalah jumlah versi sel yang akan disalin (defaultnya adalah 1 alias yang terbaru saja)
- –semua.sel
- salin juga hapus penanda dan sel yang dihapus
Perangkap Umum
Klien HBase dalam versi 0.90.x, 0.92.x, dan 0.94.x selalu menggunakan zoo.cfg jika berada di classpath, bahkan jika file hbase-site.xml menentukan pengaturan konfigurasi kuorum ZooKeeper lainnya. “Fitur” ini menyebabkan masalah umum di CDH3 HBase karena paketnya secara default menyertakan direktori tempat zoo.cfg tinggal di classpath HBase. Ini dapat dan telah menyebabkan frustrasi ketika mencoba menggunakan CopyTable (HBASE-4614). Solusi untuk ini adalah dengan mengecualikan file zoo.cfg dari classpath HBase Anda dan untuk menentukan properti konfigurasi ZooKeeper di file hbase-site.xml Anda. http://hbase.apache.org/book.html#zookeeper
Kesimpulan
CopyTable menyediakan asuransi pemulihan bencana yang sederhana namun efektif untuk penerapan HBase 0.90.x (CDH3). Sehubungan dengan fitur replikasi yang ditemukan dan didukung dalam HBase berbasis HBase 0.92.x CDH4, fitur tambahan CopyTable menjadi kurang berharga tetapi fungsionalitas intinya penting untuk mem-bootstrap tabel yang direplikasi. Sementara fitur yang lebih canggih seperti snapshot HBase (HBASE-50) dapat membantu pemulihan bencana saat diimplementasikan, CopyTable akan tetap menjadi alat yang berguna bagi administrator HBase.
