レプリケーション（この以前のブログ記事で説明）はしばらくの間リリースされており、ApacheHBaseで最も使用されている機能の1つです。異なるピアでデータを複製するクラスターを持つことは、DR戦略としてであれ、本番/ステージング/開発環境間でデータを複製するシームレスな方法としてであれ、非常に一般的な展開です。これは、1秒未満のレイテンシー内でさまざまなHBaseデータベースの同期を維持する効率的な方法ですが、レプリケーションは、機能が有効にされた後に取り込まれたデータに対してのみ動作します。つまり、レプリケーションの展開に関係するすべてのクラスター上の既存のデータは、他の方法でピア間でコピーする必要があります。異なるピアクラスター上の既存のデータを同期するために使用できるツールはかなりあります。スナップショット、BulkLoad、CopyTableは、以前のClouderaブログ投稿で取り上げられたそのようなツールのよく知られた例です。この記事では、 HashTable / SyncTableについて説明します。 内部実装ロジックのいくつか、それを使用することの長所と短所、および上記の他のデータコピー技術のいくつかとの比較について詳しく説明します。
一言で言えばHashTable/SyncTable
HashTable / SyncTable は、個別のステップとして実行される2つのmap-reduceジョブとして実装されたツールです。 CopyTableに似ています テーブルデータのコピーの一部または全体を実行できるツール。 CopyTableとは異なり ターゲットクラスター間で分岐するデータのみをコピーし、コピー手順中にネットワークリソースとコンピューティングリソースの両方を節約します。
プロセスで実行される最初のステップは、 HashTableです。 map-reduceジョブ。これは、データをリモートピア（通常はソースクラスター）にコピーする必要があるクラスターで実行する必要があります。実行方法の簡単な例を以下に示します。必要な各パラメータの詳細な説明は、この記事の後半にあります。
hbase org.apache.hadoop.hbase.mapreduce.HashTable --families =cfmy-table/hashes/test-tbl…20/04/2805:05:48INFOmapreduce.Job：map 100％reduce 100 ％20/04/28 05:05:49 INFO mapreduce.Job：ジョブjob_1587986840019_0001が正常に完了しました20/04/28 05:05:49 INFO mapreduce.Job：カウンター：68…ファイル入力フォーマットカウンターバイト読み取り=0ファイル出力フォーマットカウンターバイト書き込み=6811788
一度HashTable 上記のコマンドによるジョブの実行が完了し、いくつかの出力ファイルがソースhdfs / hashes / my-tableに生成されました。 ディレクトリ：
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スーパーグループ02020-04-2805:05 / hashes / test-tbl / hashes / _SUCCESSdrwxr-xr-x --root supergroup 0 2020-04-28 05:05 / hashes / test-tbl / hashes / part-r-00000 -rw-r--r--2rootスーパーグループ67909092020-04-2805:05 / hashes / test-tbl / hashes / part-r-00000 / data-rw-r--r--2rootスーパーグループ20879 2020-04-28 05:05 / hashes / test-tbl / hashes / part-r-00000 / index-rw-r--r--2rootスーパーグループ992020-04-2805:04 / hashes / test- tbl/manifest-rw-r--r--2ルートスーパーグループ1532020-04-2805:04 / hashes / test-tbl / components
これらは、 SyncTableの入力として必要です。 走る。 SyncTable ターゲットピアで起動する必要があります。以下のコマンドはSyncTableを実行します HashTableの出力用 前の例から。 ドライランを使用します この記事の後半で説明するオプション：
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-tbltest-tbltest-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper $ CounterBATCHES =97148HASHES_MATCHED =97146HASHES_NOT_MATCHED =2MATCHINGCELLS =17MATCHINGROWS =2RANGESNOTMATCHED =2 1
クイックリファレンスとして、両方の例で指定されたパラメータを実際の環境値に置き換えることができます。この記事の残りの部分では、実装の詳細について詳しく説明します。
なぜ2つの異なるステップなのですか？
このツールの主な目的は、2つのクラスター間で欠落しているデータのみを識別してコピーすることです。 ハッシュテーブル シャーディング/インデックス作成ジョブとして機能し、テーブルデータのバッチを分析し、ハッシュインデックスを生成します。 これらのバッチごとに。これらは、 / hashes / my-tableの下のファイルに書き込まれた出力です。 ジョブパラメータの1つとして渡されたhdfsディレクトリ。前述のように、この出力は SyncTableに必要です。 仕事。 SyncTable HashTable、で使用されるのと同じバッチサイズでターゲットテーブルをローカルにスキャンします また、 HashTableで使用されるのと同じ関数を使用して、これらのバッチのハッシュ値を計算します。 次に、ローカルバッチハッシュを比較します HashTableの値を使用した値 出力。ハッシュ値が等しい場合は、バッチ全体が2つのクラスターで同一であり、そのセグメントに何もコピーする必要がないことを意味します。それ以外の場合は、ソースクラスター内のバッチのスキャンを開き、各セルがターゲットクラスター内にすでに存在するかどうかを確認し、分岐するセルのみをコピーします。スパースでわずかに異なるデータセットでは、これにより、2つのクラスター間でコピーされるデータがはるかに少なくなります。また、不一致をチェックするためにソースでスキャンする必要があるセルの数はわずかです。
必要なパラメータ
ハッシュテーブル 必要なパラメータは2つだけです。関連するハッシュやその他のメタ情報ファイルが書き込まれるテーブル名と出力パスです。 SyncTable HashTableを使用します それぞれソースクラスターとターゲットクラスターのテーブル名とともに、入力としてdirを出力します。 HashTableを使用しているため / SyncTable リモートクラスター間でデータを移動するには、 sourcezkcluster SyncTableのオプションを定義する必要があります 。これは、ソースクラスターのzookeeperクォーラムアドレスである必要があります。この記事の例では、ソースクラスターのアクティブなネームノードアドレスも直接参照しているため、 SyncTable ソースクラスターから直接ハッシュ出力ファイルを読み取ります。または、 HashTable 出力は、ソースクラスターからリモートクラスターに手動でコピーできます（たとえば、distcpを使用）。
| 注：異なるKerberosレルムでのリモートクラスターの操作は、CDH6.2.1以降でのみサポートされます。 |
詳細オプション
両方のHashTable およびSyncTable 最適な結果を得るために調整できる追加のオプションオプションを提供します。
ハッシュテーブル startrow / starttime、stoprow / stoptime を使用して、行キーと変更時間の両方でデータをフィルタリングできます。 それぞれプロパティ。データセットの範囲は、バージョンによって制限することもできます および家族 プロパティ。 バッチサイズ プロパティは、ハッシュされる各部分のサイズを定義します。これは、同期パフォーマンスに直接影響します。不一致が非常に少ない場合は、バッチサイズの値を大きく設定すると、SyncTableでスキャンする必要がなくデータセットの大部分が無視されるため、パフォーマンスが向上する可能性があります。
SyncTable ドライランを提供します ターゲットに適用される変更のプレビューを可能にするオプション。
SyncTable デフォルトの動作では、ターゲット側でソースデータをミラーリングするため、ターゲットには存在するがソースには存在しない追加のセルは、最終的にターゲット側で削除されます。これは、アクティブ-アクティブレプリケーション設定でクラスターを同期する場合には望ましくない場合があり、そのような場合は doDeletes オプションをfalseに設定して、ターゲットでの削除の複製をスキップできます。同様のdoPutsもあります 追加のセルをターゲットクラスターに挿入してはならない場合のフラグ。
出力の分析
ハッシュテーブル SyncTable、のメタ情報を含むいくつかのファイルを出力します ただし、これらは人間が読める形式ではありません。既存のデータに変更を加えることはないため、関連情報はユーザーコンテキストにはほとんど関係ありません。
SyncTable これは、ターゲットに実際に変更を適用するステップであり、ターゲットクラスターデータを実際に変更する前に、その概要を確認することが重要な場合があります（ dryrun を参照）。 上記のオプション）。マップの最後にいくつかの関連するカウンターを公開し、実行を減らします。上記の例の値を見ると、 97148があったことがわかります。 ハッシュ化されたパーティション（ BATCHESによって報告されます カウンター）、 SyncTable そのうちの2つだけで発散が検出されました（ HASHES_MATCHED による） およびHASHES_NOT_MACTHED カウンター）。さらに、ハッシュが異なる2つのパーティション内で、17個のセル 2行以上 一致していました（ MATCHING_CELLS によって報告されたとおり） およびMATCHING_ROWS、 それぞれ）、ただし2行もありました これらの2つのパーティションで分岐します（ RANGESNOTMATCHED による） およびROWSWITHDIFFS ）。最後に、 SOURCEMISSINGCELLS およびTARGETMISSINGCELLS セルがソースクラスターまたはターゲットクラスターにのみ存在するかどうかを詳しく教えてください。この例では、ソースクラスターにはターゲット上にないセルが1つありましたが、ターゲットにはソース上にないセルもありました。 SyncTable以降 dryrunを指定せずに実行されました オプションと設定doDeletes falseのオプション 、ジョブはターゲットクラスター内の余分なセルを削除し、ソースで見つかった余分なセルをターゲットクラスターに追加しました。 書き込みがないと仮定 どちらかのクラスターで発生し、その後、まったく同じ SyncTableを実行します ターゲットクラスターのコマンドは違いを示しません：
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --sourcezkcluster =zk1.example.com、zk2.example.com、zk3.example.com：2181：/ hbase hdfs：// nn：9000 / hashes / test-tbltest-tbltest-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper $ CounterBATCHES =97148HASHES_MATCHED=97148…
該当するシナリオ
データ同期
一見すると、 HashTable / SyncTable CopyTableと重複しているように見える場合があります ツールですが、どちらのツールがより適しているかという特定のシナリオがまだあります。最初の比較例として、 HashTable / SyncTableを使用します 100,004行を含むテーブルの初期ロードで合計データサイズが5.17GBの場合、 SyncTableの場合は数分かかります。 完了するには：
... 20/04/29 03:48:00 INFO mapreduce.Job：実行中のジョブ：job_1587985272792_001120 / 04/29 03:48:09 INFO mapreduce.Job：ジョブjob_1587985272792_0011がuberモードで実行中：false20 / 04 / 29 03:48:09 INFO mapreduce.Job：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 .Job：ジョブjob_1587985272792_0011が正常に完了しました…org.apache.hadoop.hbase.mapreduce.SyncTable $ SyncMapper $ CounterBATCHES =97148EMPTY_BATCHES =97148HASHES_NOT_MATCHED =97148RANGESNOTMATCHED =97148ROWSWITHDIFFS =100004TARGETMISSINGCELLこのような小さなデータセットでも、 CopyTable より速く実行されました（ SyncTable の間、約3分 データセット全体をコピーするのに6分かかりました）：
... 20/04/29 05:12:07 INFO mapreduce.Job：実行中のジョブ：job_1587986840019_000520 / 04/29 05:12:24 INFO mapreduce.Job：ジョブjob_1587986840019_0005 uberモードで実行中：false20 / 04 / 29 05:12:24 INFO mapreduce.Job：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 .Job：map 50％reduce 0％20/04/29 05:14:37 INFO mapreduce.Job：map 75％reduce 0％20/04/29 05:15:14 INFO mapreduce.Job：map 100％reduce 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次に、両方のツールを再度使用して、データセット全体のまばらな違いに対処しましょう。 test-tbl これらすべての例で使用されているテーブルには、ソースクラスターに4つのリージョンがあります。前の例ですべての元のデータセットがターゲットクラスターにコピーされた後、ソース側にのみ4つの行を追加し、既存のリージョンごとに1つ追加してから、 HashTable / SyncTableを実行します。 もう一度同期します 両方のクラスター：
20/04/29 05:29:23 INFO mapreduce.Job：実行中のジョブ：job_1587985272792_001320 / 04/29 05:29:39 INFO mapreduce.Job：ジョブjob_1587985272792_0013 uberモードで実行中：false20 / 04/29 05： 29:39 INFO mapreduce.Job：map 0％reduce 0％20/04/29 05:29:53 INFO mapreduce.Job：map 50％reduce 0％20/04/29 05:30:42 INFO mapreduce.Job： map 100％reduce 0％20/04/29 05:30:42 INFO mapreduce.Job：Jobjob_1587985272792_0013が正常に完了しました…org.apache.hadoop.hbase.mapreduce.SyncTable$ SyncMapper $ CounterBATCHES =97148HASHES_MATCHED =97144HASHES_NOT_MATCHED =4MATCHINGCELLS =42MATCH 5RANGESNOTMATCHED =4ROWSWITHDIFFS =4TARGETMISSINGCELLS =4TARGETMISSINGROWS =44つでそれを見ることができます パーティションの不一致、 SyncTable かなり速かった（完了するのに約1分）。 CopyTableの使用 これと同じ同期を実行するには 次の結果を示しました：
20/04/29 08:32:38 INFO mapreduce.Job：実行中のジョブ：job_1587986840019_000820 / 04/29 08:32:52 INFO mapreduce.Job：ジョブjob_1587986840019_0008 uberモードで実行中：false20 / 04/29 08： 32:52 INFO mapreduce.Job：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.Job： map 50％reduce 0％20/04/29 08:34:48 INFO mapreduce.Job：map 75％reduce 0％20/04/29 08:35:31 INFO mapreduce.Job：map 100％reduce 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=0CopyTable データセット全体をコピーする場合と同じ時間がテーブルの同期にかかりましたが、4つしかありませんでした。 コピーするセル。これは、この非常に小さなデータセットとアイドル状態のクラスターでは問題ありませんでしたが、データセットが大きく、ターゲットクラスターがデータを書き込む多くのクライアントアプリケーションでも使用されている可能性がある本番環境のユースケースでは、 CopyTable > SyncTableと比較した場合のパフォーマンスの低下 さらに高くなります。
スナップショットのエクスポート、一括読み込み、または元の直接コピーなど、ターゲットクラスターの初期読み込み（ターゲットにはデータがまったくない）に組み合わせて使用できる追加のツール/機能もあることを言及する価値がありますソースクラスターからのテーブルdirs。コピーする大量のデータを含む初期ロードの場合、テーブルスナップショットを取得してから、 ExportSnapshotを使用します ツールは、 SyncTableなどのオンラインコピーツールよりも優れています。 またはCopyTable。
レプリケーションの整合性の確認
HashTable / SyncTableのもう1つの一般的な使用法は、レプリケーションの問題の可能性をトラブルシューティングするときに、クラスター間のレプリケーション状態を監視することです。このシナリオでは、VerifyReplicationツールの代替として機能します。通常、2つのクラスター間の状態をチェックする場合、不一致がまったくないか、一時的な部分的な問題により、大きなデータセットのごく一部が同期しなくなります。前の例で使用したテスト環境では、両方のクラスターに一致する値を持つ100,008行が存在するはずです。ドライランオプションを使用して宛先クラスターでSyncTableを実行すると、違いを特定できます。
20/05/04 10:47:25 INFO mapreduce.Job：実行中のジョブ：job_1588611199158_0004…20/05/04 10:48:48 INFO mapreduce.Job：map 100％reduce 0％20/05/04 10 ：48：48 INFO mapreduce.Job：ジョブjob_1588611199158_0004が正常に完了しました…HBaseCountersBYTES_IN_REMOTE_RESULTS =3753476784BYTES_IN_RESULTS =5549784600ROWS_SCANNED=100008…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper $ CounterBATCHソースクラスターのVerifyReplicationツール。比較のためにスキャンするリモートクラスターを見つけることができるように、パラメーターの1つとしてピアIDを渡します：20/05/04 11:01:58 INFO mapreduce.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：Jobjob_1588611196128_0001が正常に完了しました…HBaseCountersBYTES_IN_REMOTE_RESULTS=2761955495BYTES_IN_RESULTS=5549784600…org.apache.hadoop.hbase.mapreduce .replication.VerifyReplication $ Verifier $ CountersGOODROWS =100008 ...違いはありませんが、SyncTableは、ソースパーティションとターゲットパーティション間で一致するすべてのハッシュを検出するため、リモートソースクラスターを再度スキャンする必要がありません。 VerificationReplicationは、両方のクラスターのセルごとに1つずつ比較を実行します。このような小さなデータセットを処理する場合でも、すでに高いネットワークコストがかかる可能性があります。
ソースクラスターに1つの行を追加し、チェックを再実行します。 VerificationReplicationを使用する場合：
20/05/05 11:14:05 INFO mapreduce.Job：実行中のジョブ：job_1588611196128_0004…20/05/05 11:16:32 INFO mapreduce.Job：map 100％reduce 0％20/05/05 11 ：16：32 INFO mapreduce.Job：ジョブjob_1588611196128_0004が正常に完了しました…org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication $ Verifier $ CountersBADROWS =1GOODROWS =100008ONLY_IN_SOURCE_TABLE_ROWS=1…SyncTableを使用する前に、新しいセルが追加されたため、HashTableを使用してソースでハッシュを再生成する必要があります。
20/05/04 11:31:48 INFO mapreduce.Job：実行中のジョブ：job_1588611196128_0003…20/ 05/04 11:33:15 INFO mapreduce.Job：ジョブjob_1588611196128_0003が正常に完了しました...現在SyncTable：
20/05/07 05:47:51 INFO mapreduce.Job：実行中のジョブ：job_1588611199158_0014…20/ 05/0705：49：20 INFO mapreduce.Job：ジョブjob_1588611199158_0014が正常に完了しました… org.apache.hadoop.hbase.mapreduce.SyncTable $ SyncMapper $ CounterBATCHES =97148HASHES_NOT_MATCHED =97148MATCHINGCELLS =749593MATCHINGROWS =100008RANGESMATCHED =97147RANGESNOTMATCHED =1ROWSWITHDIFFS =1TARGETMISSINGCELLS =1TA2つのリモートクラスター間の追加のスキャンとセルの比較により、実行時間の増加が見られます。一方、VerifyReplicationの実行時間にはほとんど変化が見られませんでした。
結論
HashTable / SyncTable は、2つのクラスターデータセット間のまばらな不一致を処理するときに、データを移動するための貴重なツールです。データのパーティション分割とハッシュを使用して、2つのデータセットの範囲の違いを効率的に検出し、2つのクラスターのデータを比較しながらスキャンするセルの数を減らし、ターゲットクラスターに既存の値を不必要に配置することを回避します。上記の例のいくつかで示されているように、これは特効薬ではありませんが、 CopyTableと機能が重複しているように見える場合があります。 ツールの場合、後者は、より大きな連続範囲の不一致セルを処理するときに、より優れたパフォーマンスを提供できます。その意味で、 HashTable / SyncTable 両方のクラスターにすでにデータが存在する場合、またはピアの1つが一時的に使用できなくなったために既存のレプリケーション設定が中断された場合に、最も適切です。
関連記事：
https://blog.cloudera.com/apache-hbase-replication-overview/
https://blog.cloudera.com/approaches-to-backup-and-disaster-recovery-in-hbase/
https://blog.cloudera.com/online-apache-hbase-backups-with-copytable/
https://blog.cloudera.com/introduction-to-apache-hbase-snapshots/