CopyTableはシンプルなApacheHBaseユーティリティであり、当然のことながら、HBaseクラスター内またはあるHBaseクラスターから別のHBaseクラスターに個々のテーブルをコピーするために使用できます。このブログ投稿では、このツールとは何か、なぜ使用するのか、使用方法、およびいくつかの一般的な構成上の注意事項について説明します。
ユースケース：
CopyTableは、そのコアとなるApache Hadoop MapReduceジョブであり、標準のHBase Scan読み取りパスインターフェイスを使用して個々のテーブルからレコードを読み取り、標準のHBase Put書き込みパスインターフェイスを使用して別のテーブル（場合によっては別のクラスター）に書き込みます。多くの目的に使用できます：
- テーブルの内部コピー（貧乏人のスナップショット）
- リモートHBaseインスタンスのバックアップ
- インクリメンタルHBaseテーブルコピー
- HBaseテーブルの部分的なコピーとHBaseテーブルスキーマの変更
前提条件と制限：
CopyTableツールには、いくつかの基本的な前提条件と制限があります。まず、マルチクラスターの状況で使用する場合は、両方のクラスターがオンラインである必要があり、ターゲットインスタンスには、ソーステーブルとして定義された同じ列ファミリーを持つターゲットテーブルが存在する必要があります。
ツールは標準のスキャンとプットを使用するため、ターゲットクラスターは同じ数のノードまたはリージョンを持つ必要はありません。実際、テーブルの数やリージョンサーバーの数が異なる可能性があり、リージョンの分割境界が完全に異なる可能性があります。テーブル全体をコピーしているため、効率を高めるために、より大きなスキャナーキャッシュ値を設定するなどのパフォーマンス最適化設定を使用できます。 putインターフェイスを使用すると、異なるマイナーバージョンのクラスター間でコピーを作成できることも意味します。 （0.90.4-> 0.90.6、CDH3u3-> CDH3u4）またはワイヤー互換のバージョン（0.92.1-> 0.94.0）。
最後に、HBaseは行レベルのACID保証のみを提供します。これは、CopyTableの実行中に、新しく挿入または更新された行が発生する可能性があり、これらの同時編集が完全に含まれるか、完全に除外されることを意味します。行は一貫していますが、他の行の一貫性、因果関係、または配置の順序についての保証はありません。
テーブルの内部コピー（貧乏人のスナップショット）
最新の0.94.xバージョンまでのHBaseのバージョンは、テーブルスナップショットをサポートしていません。 HBaseのACIDの制限にもかかわらず、CopyTableは、特定のテーブルの物理コピーを作成する単純なスナップショットメカニズムとして使用できます。
列ファミリcf1とcf2を持つテーブルtableOrigがあるとします。すべてのデータをtableCopyにコピーします。最初に、同じ列ファミリーでtableCopyを作成する必要があります：
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
次に、同じHBaseインスタンスに新しい名前のテーブルを作成してコピーできます：
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig
これにより、データをコピーするMRジョブが開始されます。
リモートHBaseインスタンスのバックアップ
データを別のクラスターにコピーするとします。これは、1回限りのバックアップ、定期的なジョブ、またはクラスター間レプリケーションのブートストラップの場合があります。この例では、srcClusterとdstClusterの2つの別個のクラスターがあります。
このマルチクラスターの場合、CopyTableはプッシュプロセスです。ソースは現在のhbase-site.xmlが参照するHBaseインスタンスになり、追加された引数は宛先クラスターとテーブルを指します。これは、すべてのMRTaskTrackerが宛先クラスター内のすべてのHBaseノードとZKノードにアクセスできることも前提としています。この構成メカニズムは、hbase / mr構成をオーバーライドして、アクセス可能なリモートクラスターの設定を使用し、宛先クラスターのZKノードを指定することで、これをリモートクラスター上のジョブとして実行できることも意味します。これは、SLAが低いHBaseクラスターからデータをコピーし、それらに対してMRジョブを直接実行したくない場合に役立ちます。
–peer.adr設定を使用して、宛先クラスターのZKアンサンブル（コピー先のクラスターなど）を指定します。このためには、ZKクォーラムのIPとポート、およびHBaseインスタンスのHBaseルートZKノードが必要です。これらのマシンの1つがsrcClusterZK（hbase.zookeeper.quorumにリストされている）であり、デフォルトのzkクライアントポート2181（hbase.zookeeper.property.clientPort）とデフォルトのZKznode親/hbase（zookeeper.znode）を使用しているとします。親）。 （注：同じZKを使用する2つのHBaseインスタンスがある場合は、クラスターごとに異なるzookeeper.znode.parentが必要になります。
# 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
–peer.adrで–new.name引数を使用して、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
これにより、srcClusterのtableOrigからdstClusterのtableCopyテーブルにデータがコピーされます。
インクリメンタルHBaseテーブルコピー
宛先クラスターにテーブルのコピーを作成したら、後でソースクラスターに書き込まれる新しいデータをどのようにコピーしますか？単純に、CopyTableジョブを再度実行して、テーブル全体をコピーすることができます。ただし、CopyTableは、更新された行をsrcClusterから時間枠で指定されたバックアップdstClusterにコピーするだけのより効率的な増分コピーメカニズムを提供します。したがって、最初のコピーの後、前の1時間のみのデータをsrcClusterからdstCusterにコピーする定期的なcronジョブを実行できます。
これは、–starttimeおよび–endtime引数を指定することによって行われます。時間は、UNIXエポック時間からの10進ミリ秒として指定されます。
# 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
HBaseテーブルの部分的なコピーとHBaseテーブルスキーマの変更
デフォルトでは、CopyTableは一致する行からすべての列ファミリーをコピーします。 CopyTableは、特定の列ファミリからのみデータをコピーするためのオプションを提供します。これは、元のソースデータをコピーし、後続の処理によって追加される派生データ列ファミリーを除外する場合に役立ちます。
これらの引数を追加することにより、指定された列ファミリーからのデータのみをコピーします。
- –families =srcCf1
- –families =srcCf1、srcCf2
0.92.0以降、列ファミリー名を変更しながらコピーできます：
- –families =srcCf1：dstCf1
- srcCf1からdstCf1にコピー
- –families =srcCf1：dstCf1、dstCf2、srcCf3：dstCf3
- srcCf1からdestCf1にコピーし、dstCf2をdstCf2（名前変更なし）にコピーし、srcCf3をdstCf3にコピーします
dstCf *はdstClusterテーブルに存在する必要があることに注意してください！
0.94.0以降、削除マーカーをコピーし、限られた数の上書きバージョンを含めるための新しいオプションが提供されています。以前は、ソースクラスターで行が削除された場合、削除はコピーされませんでした。代わりに、その行の古いバージョンが宛先クラスターに残ります。これは、0.94.0リリースの高度な機能の一部を利用しています。
- –versions =vers
- ここで、versはコピーするセルバージョンの数です（デフォルトは1、つまり最新のみ）
- –all.cells
- 削除マーカーと削除されたセルもコピーします
よくある落とし穴
0.90.x、0.92.x、および0.94.xバージョンのHBaseクライアントは、hbase-site.xmlファイルで他のZooKeeperクォーラム構成設定が指定されている場合でも、クラスパスにある場合は常にzoo.cfgを使用します。この「機能」は、CDH3 HBaseで一般的な問題を引き起こします。これは、そのパッケージがデフォルトでzoo.cfgがHBaseのクラスパスに存在するディレクトリを含むためです。これは、CopyTable（HBASE-4614）を使おうとすると、フラストレーションを引き起こす可能性があります。この回避策は、zoo.cfgファイルをHBaseのクラスパスから除外し、hbase-site.xmlファイルでZooKeeper構成プロパティを指定することです。 http://hbase.apache.org/book.html#zookeeper
結論
CopyTableは、HBase 0.90.x（CDH3）のデプロイメントにシンプルで効果的なディザスタリカバリ保険を提供します。 CDH4のHBase0.92.xベースのHBaseで検出およびサポートされているレプリケーション機能と組み合わせて、CopyTableのインクリメンタル機能の価値は低下しますが、そのコア機能は、レプリケートされたテーブルをブートストラップするために重要です。 HBaseスナップショット（HBASE-50）などのより高度な機能は、実装時にディザスタリカバリに役立つ場合がありますが、CopyTableはHBase管理者にとって引き続き便利なツールです。