HBase の原則 - 分散システムでスナップショットはどのように機能しますか?

スナップショットの基本

スナップショットは、多くのストレージ システムやデータベース システムでサポートされている機能です。スナップショットは、特定の瞬間のファイル システム全体またはディレクトリのミラー イメージです。データ ファイルのミラーリングを実装する最も単純かつ最も強力な方法は、コピーをロックすることです (ロックする理由は、ミラーによって取得されたデータは特定の時点で完全に一貫している必要があるためです)。コピー期間中は、元のデータの更新や削除は許可されず、読み取り専用操作のみが提供され、コピーが完了するとロックが解除されます。この方法では実際にデータをコピーする必要があるため、データ量が多い場合は必然的に時間がかかります。コピーが長期間ロックされると、必然的にクライアントは長期間にわたって更新や削除ができなくなりますが、これは生産ラインでは許容できません。

スナップショット メカニズムはデータをコピーするものではなく、元のデータへのポインターとして理解できます。これは、HBase のような LSM システム構造では比較的簡単に理解できます。 HBase データ ファイルがディスクに保存されると、更新や削除などのインプレース変更操作は許可されなくなることがわかっています。更新または削除する場合は、新しいファイルに追加することができます (HBase には更新インターフェイスはまったくなく、削除コマンドも追加書き込みです)。このメカニズムでは、テーブルのスナップショットを取得するには、現在のテーブル内のすべてのファイルに対する新しい参照 (ポインター) を作成し、新しく書き込まれたデータを書き込むための新しいファイルを作成するだけです。次の図に示すように:

スナップショット プロセスには、主に次の 3 つのステップが含まれます。

• データの書き込み、更新、削除を一切許可しないグローバル ロックを追加します。
• Memstore のキャッシュデータをファイルにフラッシュする (オプション)
• すべての HFile ファイルに対して新しい参照ポインターを作成します。これらのポインタ メタデータはスナップショットです。

さらに考えると、 LSM システムは確かに理解しやすいですが、インプレース更新を行う他の非 LSM ストレージ システムでは、スナップショットをどのように実装するのでしょうか?

スナップショットはどのような機能を実現できますか?

スナップショットは HBase のコア機能です。スナップショットのさまざまな用途により、次のような多くの機能を実現できます。

完全/増分バックアップ: 高いデータ信頼性を実現するには、どのデータベースでもバックアップ機能が必要です。スナップショットを使用すると、オンライン ビジネス リクエストへの影響を最小限に抑えながら、テーブルのオンライン バックアップ機能を簡単に実装できます。バックアップ データを使用すると、異常が発生した場合に、指定したスナップショット ポイントにすばやくロールバックできます。増分バックアップでは、binlog を使用して、完全バックアップに基づいて定期的な増分バックアップを実行します。

使用シナリオ 1:一般的に、重要なビジネス データについては、少なくとも 1 日に 1 回スナップショットを実行してデータのスナップショット レコードを保存し、期限切れのスナップショットを定期的にクリーンアップすることをお勧めします。これにより、ビジネスで重大なエラーが発生してロールバックが必要になった場合に、以前のスナップショット ポイントにロールバックできます。

使用シナリオ 2:クラスターにメジャー アップグレードを実行する場合は、アップグレード中に例外が発生した場合にアップグレード前の状態にすばやくロールバックできるように、アップグレード前に重要なテーブルのスナップショットを実行することをお勧めします。

2. データ移行:ExportSnapshot機能を使用してスナップショットを別のクラスターにエクスポートし、データ移行を実現できます。

使用シナリオ 1:コンピュータ ルームのオンライン移行。通常、データはコンピュータ ルーム A にあります。コンピュータ ルーム A には十分なスロットやラックがないため、クラスター全体を、より大きな容量を持つ別のクラスター B に移行する必要があります。移行プロセス中はサービスを停止できません。移行の基本的な考え方は、まずスナップショットを使用してクラスター B の全データを復元し、次にレプリケーション テクノロジを使用してクラスター A の更新されたデータを増分コピーし、2 つのクラスターのデータが整合した後でクライアント要求をコンピューター ルーム B にリダイレクトすることです。具体的な手順については、https://www.cloudera.com/documentation/enterprise/5-5-x/topics/cdh_bdr_hbase_replication.html#topic_20_11_7 を参照してください。

使用シナリオ 2:スナップショットを使用してテーブル データを HDFS にエクスポートし、Hive\Spark を使用して監査レポート、月次レポートなどのオフライン OLAP 分析を実行します。

Hbase スナップショットの使用

最もよく使用されるスナップショット コマンドは、snapshot、restore_snapshot、clone_snapshot、および ExportSnapshot ツールです。具体的な使い方は以下のとおりです。

テーブル「sourceTable」のスナップショット「snapshotName」を取得します。スナップショットはデータの移動を伴わず、オンラインで実行できます。

 hbase> スナップショット'sourceTable' 、'snapshotName'

指定されたスナップショットを復元します。リカバリ プロセスでは、元のデータが置き換えられ、テーブルがスナップショット ポイントに復元されます。スナップショットポイント以降のすべての更新は失われます。 restore_snapshot 操作を実行する前に、元のテーブルを無効にする必要があることに注意してください。

 hbase> restore_snapshot 'スナップショット名'

スナップショットに基づいて新しいテーブルが復元されます。回復プロセスにはデータの移動は含まれず、数秒で完了します。どのように行われるのか興味がありますか?以下で説明させてください。

 hbase> clone_snapshot 'スナップショット名' 、'テーブル名'

ExportSnapshot コマンドを使用して、クラスター A のスナップショット データをクラスター B に移行します。ExportSnapshot は HDFS レベルでの操作であり、並列データ移行に MR を使用します。したがって、移行は MR が有効になっているマシンで実行する必要があります。 HMaster と HRegionServer はこのプロセスに参加しないため、追加のメモリ オーバーヘッドや GC オーバーヘッドは発生しません。唯一の影響は、データをコピーするときに DN が追加の帯域幅と IO 負荷を必要とすることです。 ExportSnapshot は、この問題に対処するために、帯域幅の使用を制限するパラメータ -bandwidth も設定します。

 hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot \  
 -スナップショット MySnapshot -コピー-からhdfs://srv2:8082/hbase \  
 -コピー-をhdfs://srv1:50070/hbase に -mappers 16 -bandwidth 1024\

Hbase スナップショット分散アーキテクチャ - 2 フェーズ コミット

Hbase は指定されたテーブルに対してスナップショット操作を実行します。実際には、スナップショットは対応するテーブルのすべての領域に対して実行されます。これらのリージョンは複数の RegionServers に分散されているため、スナップショット実行に参加しているすべてのリージョンが完了しているか、まったく開始されていないかを確認するメカニズムが必要です。一部の領域が完了し、一部の領域が未完了であるなどの中間状態があってはなりません。

HBase は、2 フェーズ コミット プロトコル (2PC) を使用して、スナップショットの分散アトミック性を保証します。 2PC は通常、コーディネーターと複数の参加者で構成されます。トランザクションの送信全体は、準備フェーズとコミット フェーズの 2 つのフェーズに分かれています。準備フェーズでは、コーディネーターがすべての参加者に準備コマンドを送信します。すべての参加者は、対応するリソース (ロック リソースなど) の取得を開始し、準備操作を実行して、実行が成功することを確認します。通常、コア作業は準備操作で完了します。そして、準備した返答をコーディネーターに返します。コーディネータは、すべての参加者から準備された応答（すべての参加者がコミットの準備ができていることを示す）を受信すると、コミット ステータスをローカルに保持し、コミット フェーズに入ります。コーディネーターはすべての参加者にコミット コマンドを送信します。コミット コマンドを受信すると、参加者はコミット操作を実行し、リソースを解放します。通常、コミット操作は非常に簡単です。

次に、HBase が 2PC プロトコルを使用してスナップショット アーキテクチャを構築する方法を見てみましょう。基本的な手順は次のとおりです。

1. 準備フェーズ: HMaster は ZooKeeper に '/acquired-snapshotname' ノードを作成し、このノードにスナップショット関連の情報 (スナップショット テーブル情報) を書き込みます。すべてのリージョンサーバーがこのノードを検出した後、/acquired-snapshotname ノードによって保持されるスナップショット テーブル情報に基づいて、現在のリージョンサーバーにターゲット テーブルが存在するかどうかを確認します。存在しない場合、コマンドは無視されます。存在する場合は、ターゲット テーブル内のすべてのリージョンを走査し、各リージョンでスナップショット操作を実行します。スナップショット操作の結果は最終フォルダーではなく、一時フォルダーに書き込まれることに注意してください。 regionserver の実行が完了すると、/acquired-snapshotname ノードの下に新しい子ノード /acquired-snapshotname/nodex が作成され、nodex ノードが regionserver 上の関連するすべてのリージョンのスナップショット準備作業を完了したことを示します。

2. コミット フェーズ: すべてのリージョン サーバーがスナップショットの準備作業を完了すると、つまり、/acquired-snapshotname ノードの下に対応する子ノードを作成すると、hmaster はスナップショットの準備が完全に完了したと見なします。マスターは新しいノード /reached-snapshotname を作成し、参加しているリージョン サーバーにコミット コマンドが送信されたことを示します。すべてのリージョンサーバーが /reached-snapshotname ノードを検出すると、スナップショット コミット操作を実行します。コミット操作は非常に簡単です。準備フェーズで生成された結果を一時フォルダーから最終フォルダーに移動するだけで済みます。実行が完了すると、/reached-snapshotname ノードの下に新しい子ノード /reached-snapshotname/nodex が作成され、ノード nodex がスナップショット作業を完了したことを示します。

3. 中止フェーズ: 一定時間内に /acquired-snapshotname ノードの数が条件を満たさない場合 (および、regionserver の準備作業が完了していない場合)、hmaster はスナップショットの準備作業がタイムアウトしたとみなします。 hmaster は別の新しいノード /abort-snapshotname を作成します。すべてのリージョンサーバーがこのコマンドをリッスンすると、スナップショットによって生成された結果が一時フォルダーにクリーンアップされます。

このシステムでは、HMaster がコーディネーターの役割を果たし、RegionServer が参加者の役割を果たしていることがわかります。 HMaster と RegionServer 間の通信は Zookeeper を介して完了します。同時に、トランザクションのステータスも Zookeeper 上のノードに記録されます。 HMaster の高可用性の場合、マスター HMaster がクラッシュすると、スレーブ HMaster は Zookeeper のステータスに基づいてトランザクションの送信を続行するか中止するかを決定できます。

スナップショットコア実装

前のセクションでは、アーキテクチャの観点から、スナップショットが分散システムでアトミック操作を実行する方法について説明しました。では、各リージョンでは実際にどのようにスナップショットを実装するのでしょうか? hmaster はどのようにしてすべてのリージョン スナップショットの結果を集計しますか?

リージョンでスナップショットを実装するにはどうすればよいですか?

基本原則のセクションでは、スナップショットは実際にデータをコピーするのではなく、ポインター参照を使用して一連のメタデータを作成することについて説明しました。では、メタデータとは一体何でしょうか?実際、スナップショットのプロセス全体は基本的に次のようになります。

これらは、デバッグ ログ内の次のスニペットに対応します。

 snapshot.FlushSnapshotサブプロシージャ: スナップショット領域をフラッシュします。yixin:yunxin、user1359、1502949275629.77f4ac61c4db0be9075669726f3b72e6。始めました…
 snapshot.SnapshotManifest: 'yixin:yunxin,user1359,1502949275629.77f4ac61c4db0be9075669726f3b72e6.'を保存しています。スナップショットのリージョン情報。
 snapshot.SnapshotManifest:参照の作成  hfiles用
snapshot.SnapshotManifest: スナップショット参照の追加  [] hfilesの場合

注意: リージョンによって生成されるスナップショット ファイルは一時ファイルです。生成ディレクトリは /hbase/.hbase-snapshot/.tmp です。通常、スナップショット プロセスは非常に高速であるため、単一のリージョンによって生成されたスナップショット ファイルを確認することは困難です。

hmaster はどのようにしてすべてのリージョン スナップショットの結果を集計しますか?

すべてのリージョンでスナップショットが完了すると、hmaster は統合操作 (統合) を実行して、すべてのリージョン スナップショット マニフェストを 1 つのマニフェストに統合します。統合スナップショット ファイルは、HDFS ディレクトリのパス /hbase/.hbase-snapshot/snapshotname/data.manifest にあります。次の図に示すように、スナップショット ディレクトリには 3 つのファイルがあることに注意してください。

このうち、.snapshotinfo はスナップショットの対象となるテーブル名やスナップショット名など、スナップショットの基本情報です。 data.manifest は、スナップショットの実行後に生成されるメタデータ情報、つまりスナップショットの結果情報です。 hadoop dfs -cat /hbase/.hbase-snapshot/snapshotname/data.manifest を使用して、次の情報を表示できます。

clone_snapshot を実装するにはどうすればいいですか?

前述したように、スナップショットは、restore_snapshot、clone_snapshot、export snapshot など、多くの重要な操作を実行するために使用できます。このセクションでは、clone_snapshot 関数がどのように実装されているかを見ていきます。早速本題に入りましょう。全体のプロセスは次のように要約できます。

• 事前チェック: ターゲット テーブルがスナップショットまたは復元されていないことを確認します。それ以外の場合は、エラーが直接返されます。
• tmpフォルダに新しいテーブルディレクトリを作成し、テーブルディレクトリに新しい.tabledescファイルを作成し、ファイルにテーブルスキーマ情報を書き込みます。
• 新しいリージョン ディレクトリを作成します。この手順は、clone_snapshot と create table の最大の違いです。新しいリージョン ディレクトリは、スナップショット マニフェストの情報に基づいて決定されます。この地域にはどのような柱族がいますか?列ファミリにはどのような HFile ファイルがありますか?すべてはここから来ています。

ここで興味深いのは、clone_snapshot によるテーブルのクローン作成プロセスにはデータの移動が含まれないため、クローンされたテーブルにはどのようなファイルが含まれているかということです。元のテーブル内のファイルとデータ ファイル間の対応関係を確立するにはどうすればよいですか?この問題の解決方法は、分割処理における参照ファイルの解決方法と基本的に同じです。ただし、clone_snapshot では参照ファイルではなく、リンクファイルと呼ばれます。参照ファイルとは異なり、リンクファイルには内容がなく、ファイル名だけが問題になります。たとえば、元のファイル名が abc の場合、生成されるリンクファイルは table=region-abc になります。この方法では、元のテーブル内の元のファイルの特定のパス (xxx/table/region/hfile) を簡単に見つけることができるため、データを移動する必要はありません。

上図では、LinkFile ファイル名は music=5e54d8620eae123761e5290e618d556b-f928e045bb1e41ecbef6fc28ec2d5712 です。定義によれば、次の図に示すように、 music は元のファイルのテーブル名、 5e54d8620eae123761e5290e618d556b は参照ファイルが配置されている領域、 f928e045bb1e41ecbef6fc28ec2d5712 は参照ファイルであることがわかります。

規則によれば、次の図に示すように、LinkFile ファイル名 ***/music/5e54d8620eae123761e5290e618d556b/cf/f928e045bb1e41ecbef6fc28ec2d5712 に従って参照ファイルを直接見つけることができます。

4. テーブルディレクトリをtmpフォルダからhbaseルートの場所に移動する

5. メタテーブルを変更し、クローンされたテーブルのリージョン情報をメタテーブルに追加します。クローンされたテーブルのリージョン名は、元のデータテーブルのリージョン名とは異なることに注意してください（リージョン名はテーブル名に関連しています。テーブル名が異なる場合、リージョン名も必ず異なります）

6. これらのリージョンをラウンドロビン方式でクラスター全体に均等に分散し、ZK でクローン テーブルのステータスを有効に設定して、外部に正式にサービスを提供します。

その他注意事項

別の質問に注目したかどうかは分かりません。上記の説明によると、スナップショットは実際には元のテーブルの一連のメタデータであり、主にテーブル スキーマ情報、元のテーブルのすべての領域の領域情報、領域に含まれる列ファミリ情報、および領域の下のすべての hfile ファイル名とファイル サイズが含まれていることがわかります。元のテーブルが圧縮され、hfile 名が変更されたり、領域が分割されたり、元のテーブルが削除されたりした場合、以前に取得したスナップショットは無効になりますか?

機能実装の観点から見ると、ユーザーが任意の時点で作成したスナップショットが無効になることは絶対にありません。では、上記に挙げたさまざまな状況でスナップショットの無効化を回避するにはどうすればよいでしょうか? HBase の実装も比較的簡単です。元のテーブルが圧縮される前に、元のテーブルがアーカイブ ディレクトリにコピーされ、その後圧縮が実行されます (テーブル削除操作の場合、通常は削除されたテーブル データもアーカイブ ディレクトリに移動されます)。この方法では、スナップショットに対応するメタデータの意味は失われませんが、元のデータはデータ ディレクトリに存在しなくなり、アーカイブ ディレクトリに移動されます。

次の実験を試すことができます:

• スナップショットを使用して、スナップショット 'test'、'test_snapshot' などのテーブルのスナップショットを取得します。
• アーカイブディレクトリを確認し、ディレクトリが存在しないことを確認します: /hbase-root-dir/archive/data/default/test
• テーブル test に対して major_compact 操作を実行します: major_compact 'test'
• アーカイブ ディレクトリを再度確認すると、元のテスト テーブルがこのディレクトリに移動され、/hbase-root-dir/archive/data/default/test が存在することがわかります。

同様に、元のテーブルに対して delete 'test' などの削除操作を実行すると、アーカイブ ディレクトリの下にもディレクトリが見つかります。通常のテーブルを削除する場合とは異なり、通常のテーブルを削除すると、削除されたテーブルのデータ ファイルは最初はアーカイブに表示されますが、一定期間待つと、アーカイブ内のデータは完全に削除され、取得できなくなります。これは、アーカイブ内のジャンク ファイルを定期的にクリーンアップするためのスレッド (HFileCleaner) がマスター上で開始され、これらの削除されたジャンク ファイルが定期的にクリーンアップされるためです。ただし、スナップショットの元のテーブルが削除されてアーカイブに入力された後は、定期的にクリーンアップすることはできません。前述のように、複製された新しいテーブルは実際のファイルを複製するのではなく、元のファイルを指すリンクを生成します。このタイプのファイルは LinkFile と呼ばれます。当然ですが、LinkFile がこれらの元のファイルを指している限り、それらを削除することはできません。さて、ここで2つの質問があります。

1. LinkFile はいつ実際のデータ ファイルになりますか?

前回の記事「HBase の原則 - すべてのリージョン セグメンテーションの詳細はここにあります」を読んだことがあるなら、この質問を見ると間違いなく既視感を感じることでしょう。はい、HBase のリージョンが 2 つのサブリージョンに分割されると、サブリージョン内のファイルも参照ファイルになります。これらの参照ファイルは、実際には圧縮が実行されると独自のファイル ディレクトリに移行されます。 LinkFile についても同様です。クローンされた新しいテーブルで圧縮が実行されると、マージされたファイルが新しいディレクトリに書き込まれ、関連する LinkFile が削除されます。ちなみに、理論的には、圧縮中にもこれが実行されます。

2. システムがアーカイブ内の元のテーブル ファイルを削除する場合、これらのファイルが一部の LinkFiles によってまだ参照されていることをどのようにして知るのでしょうか?

HBase Split 後、システムは親リージョンのデータ ファイルを削除する必要があります。まず、2 つの子領域にそれを指す参照ファイルが存在しないことを確認する必要があります。システムはこれをどのように確認するのでしょうか?前のセクションでは、メタ テーブルに親領域に対応する 2 つの子領域が格納され、2 つの子領域のすべてのファイルがスキャンされて参照ファイルがあるかどうかが確認されることを分析しました。参照ファイルがない場合、親領域のデータ ファイルを安全に削除できます。もちろん、まだ参照ファイルが残っている場合は諦めるしかありません。

クローン後に元のテーブル ファイルを削除すると、以前と同じですか?答えはノーです。 HBase は、元のテーブル ファイルに基づいて参照ファイルを見つけるために、バック参照メカニズムという別の方法を使用します。 HBase システムは、元のテーブル ファイルが参照ファイルを見つけられるように、アーカイブ ディレクトリに新しいバック参照ファイルを作成します。バック参照ファイルがどのようなファイルであるか、また元のファイルに基づいて LinkFile をどのように見つけるかを見てみましょう。

• (1) 元のファイル: /hbase/data/table-x/region-x/cf/file-x
• （２）クローンによって生成されたLinkFileは/hbase/data/table-cloned/region-y/cf/{table-x}-{region-x}-{file-x}なので、LinkFileに基づいて元のファイルを見つけるのは簡単です。
• (3) バック参照ファイル: /hbase/.archive/data/table-x/region-x/cf/.links-file-x/{region-y}.{table-cloned}。ご覧のとおり、バック参照ファイル パスには、すべての元のファイルと LinkFiles に関する情報が含まれています。したがって、元のファイル /table-x/region-x/cf/file-x に基づいて LinkFile を効果的に見つけることができます: /table-cloned/region-y/cf/{table-x}-{region-x}-{file-x}

この時点で、興味のある友人は、この知識ポイントをつなぎ合わせて簡単な実験を行うことができます。

（1）スナップショットを使用してテーブルのスナップショットを取得します（例：スナップショット 'table-x'、'table-x-snapshot'）。

(2) clone_snapshotを使用して新しいテーブルを複製します。例: clone_snapshot 'table-x-snapshot','table-x-cloned'。新しいテーブル test_clone の HDFS ファイル ディレクトリをチェックして、LinkFile が存在することを確認します。

（３）元のテーブルtable-xを削除します（テーブルを削除する前に、アーカイブ内に元のテーブルファイルがないことを確認してください）。元のテーブル ファイルがアーカイブに入っていること、およびアーカイブ内にバック参照ファイルがあることを確認します。バック参照ファイルの形式に注意してください。

(4) テーブル 'table-x-clone' に対して major_compact を実行します。コマンドは major_compact 'test_clone' です。コマンドを実行する前に、table-x-clone ファイル ディレクトリに LinkFile が存在することを確認してください。

(5) major_compactを実行した後、table-x-cloneのHDFSファイルディレクトリをチェックして、すべてのLinkFilesが存在せず、すべて実際のデータファイルになっていることを確認します。