HBaseのMOBの新しいサポートの背後にある設計上の決定について学びます。
Apache HBaseは、分散型でスケーラブルでパフォーマンスが高く、一貫性のあるKey Valueデータベースであり、さまざまなバイナリデータ型を格納できます。比較的小さな値（<10K）を多数保存し、低レイテンシの読み取りと書き込みを提供するのに優れています。
ただし、読み取りと書き込みのレイテンシを低く維持しながら、ドキュメント、画像、その他の中程度のオブジェクト（MOB）をHBaseに保存する必要性が高まっています。そのようなユースケースの1つは、署名およびスキャンされた顧客ドキュメントを保管する銀行です。別の例として、交通機関は交通状況や移動中の車のスナップショットを保存したい場合があります。これらのMOBは通常、追記型です。
残念ながら、圧縮によって作成されるI / O圧力が絶えず増加するため、適度なサイズの値（100K〜10MB）が多数保存されている状況では、パフォーマンスが低下する可能性があります。交通カメラからの1TBの写真（それぞれ1MBのサイズ）が毎日HBaseに保存される場合を考えてみます。保存されたファイルの一部は、マイナーな圧縮によって複数回圧縮され、最終的に、データはメジャーな圧縮によって書き換えられます。これらのMOBの蓄積に加えて、圧縮によって作成されたI / Oは圧縮を遅くし、memstoreのフラッシュをさらにブロックし、最終的には更新をブロックします。大きなMOBストアは頻繁なリージョン分割をトリガーし、影響を受けるリージョンの可用性を低下させます。
これらの欠点に対処するために、ClouderaとIntelのエンジニアはHBaseブランチ（hbase-11339：HBase MOB）にMOBサポートを実装しました。このブランチはHBase1.1または1.2でマスターにマージされ、CDH5.4.xでもすでに存在してサポートされています。
MOBでの操作は通常、書き込みが多く、更新や削除がまれで、読み取りの頻度が比較的低くなります。 MOBは通常、メタデータと一緒に保存されます。 MOBに関連するメタデータには、たとえば、車の番号、速度、色などがあります。メタデータはMOBに比べて非常に小さいです。メタデータは通常、分析のためにアクセスされますが、MOBは通常、行キーで明示的に要求された場合にのみランダムにアクセスされます。
ユーザーは、同じAPIで低レイテンシーのHBaseでMOBの読み取りと書き込みを行い、クラスター間の強力な一貫性、セキュリティ、スナップショット、HBaseレプリケーションなどを望んでいます。これらの目標を達成するために、MOBはHBaseのメインI/Oパスから新しいI/Oパスに移動されました。
この投稿では、この設計アプローチと、それが選択された理由について学習します。
可能なアプローチ
この問題にはいくつかの可能なアプローチがありました。私たちが検討した最初のアプローチは、調整された分割および圧縮ポリシーを使用してMOBをHBaseに格納することでした。desiredMaxFileSizeを大きくすると、領域分割の頻度が減り、圧縮が少ないかまったくない場合、ライトアンプリフィケーションのペナルティを回避できます。このアプローチにより、書き込みの待ち時間とスループットが大幅に向上します。ただし、保存されるファイルの数が増えるにつれ、1つのストアで開かれるリーダーが多すぎて、OSで許可されている数よりも多くなります。その結果、大量のメモリが消費され、読み取りパフォーマンスが低下します。
もう1つのアプローチは、HBase + HDFSモデルを使用して、メタデータとMOBを別々に保存することでした。このモデルでは、単一のファイルがHBaseのエントリによってリンクされています。これはクライアントソリューションであり、トランザクションはクライアントによって制御されます。MOBによってHBase側のメモリが消費されることはありません。このアプローチは50MBを超えるオブジェクトでは機能しますが、MOBの場合、HDFSのデフォルトのブロックサイズは128MBであるため、多くの小さなファイルは非効率的なHDFSの使用につながります。
たとえば、NameNodeに48GBのメモリがあり、各ファイルが3つのレプリカを持つ100KBであるとします。各ファイルは300バイト以上のメモリを使用するため、48GBのメモリを備えたNameNodeは約1億6000万のファイルを保持できます。これにより、合計で16TBのMOBファイルしか保存できなくなります。
改善点として、小さなMOBファイルを大きなファイルにアセンブルし（つまり、ファイルに複数のMOBエントリを含めることができます）、オフセットと長さをHBaseテーブルに格納して高速で読み取ることができます。ただし、データの一貫性を維持し、削除されたMOBと小さなMOBファイルを圧縮で管理することは困難です。
さらに、このアプローチを使用する場合は、新しいセキュリティポリシーを検討し、書き込みのアトミックプロパティを失い、レプリケーションとスナップショットによって提供されるバックアップとディザスタリカバリを失う可能性があります。
HBaseMOBデザイン
結局、MOBをHBaseに保存することに関する懸念のほとんどは、圧縮によって作成されたI / Oに関係するため、重要なのは、領域の分割と圧縮を回避するために、通常の領域による管理からMOBを移動することでした。
HBase MOBの設計は、メタデータとMOBを別々に保存するため、HBase+HDFSアプローチに似ています。ただし、違いはサーバー側の設計にあります。memstoreはMOBをディスクにフラッシュする前にキャッシュし、MOBは各フラッシュで「MOBファイル」と呼ばれるHFileに書き込まれ、各MOBファイルには単一のファイルではなく複数のエントリがあります。各MOBのHDFSで。このMOBファイルは特別な領域に保存されます。すべての読み取りと書き込みは、現在のHBaseAPIで使用できます。
書き込みと読み取り
各MOBにはしきい値があります。セルの値の長さがこのしきい値よりも大きい場合、このセルはMOBセルと見なされます。
MOBセルがリージョンで更新されると、通常のセルと同様に、WALとmemstoreに書き込まれます。フラッシュでは、MOBがMOBファイルにフラッシュされ、MOBファイルのメタデータとパスがフラッシュされてファイルが保存されます。データの一貫性とHBaseレプリケーション機能は、この設計に固有のものです。
MOBの編集は通常より大きくなります。同期では、対応するI / Oも大きくなるため、WALの同期操作が遅くなる可能性があります。同じWALを共有する他のリージョンがある場合、これらのリージョンの書き込みレイテンシーが影響を受ける可能性があります。ただし、データの一貫性と非揮発性が必要な場合は、WALが必須です。
セルは、しきい値を変更することにより、圧縮内の保存されたファイルとMOBファイルの間を移動できます。デフォルトのしきい値は100KBです。
以下に示すように、MOBファイルのパスを含むセルは参照セルと呼ばれます。 。タグはセルに保持されるため、HBaseセキュリティメカニズムに引き続き依存できます。
参照セルには、通常のセルと区別するための参照タグがあります。参照タグは、MOBファイル内のMOBセルを意味するため、読み取りにはさらに解決が必要です。
読み取り中、ストアスキャナーはスキャナーを開いてmemstoreにファイルを保存します。参照セルが満たされると、スキャナーはセル値からファイルパスを読み取り、そのファイルから同じ行キーを探します。スキャン中のMOBファイルに対してブロックキャッシュを有効にできるため、シークを高速化できます。
すべてのMOBファイルに対してリーダーを開く必要はありません。必要な場合は1つだけ必要です。このランダム読み取りは、MOBファイルの数の影響を受けません。したがって、MOBファイルが十分に大きい場合は、MOBファイルを何度も圧縮する必要はありません。
MOBファイル名は読み取り可能であり、開始キーのMD5、このMOBファイル内のセルの最新の日付、およびUUIDの3つの部分で構成されます。最初の部分は、このMOBファイルがフラッシュされる領域の開始キーです。通常、MOBにはユーザー定義のTTLがあるため、2番目の部分をTTLと比較することで、期限切れのMOBファイルを見つけて削除できます。
スナップショット
スナップショットをより使いやすくするために、MOBファイルは特別なダミー領域に保存されます。これにより、スナップショット、テーブルのエクスポート/クローン、およびアーカイブが期待どおりに機能します。
スナップショットをテーブルに保存する場合、スナップショットにMOB領域を作成し、既存のMOBファイルをマニフェストに追加します。スナップショットを復元するときは、MOB領域にファイルリンクを作成します。
クリーンで圧縮
MOBファイルを削除する必要がある状況は2つあります。MOBファイルの有効期限が切れている場合と、MOBファイルが小さすぎて、HDFSの効率を向上させるために大きなファイルにマージする必要がある場合です。
HBase MOBには、マスターに雑用があります。MOBファイルをスキャンし、ファイル名の日付によって決定された期限切れのファイルを見つけて、それらを削除します。したがって、ディスク領域は、期限切れのMOBファイルをエージングオフすることによって定期的に再利用されます。
少数のエントリのみがMOBとして適格である行を書き込む場合、MOBファイルはHDFSブロックと比較して比較的小さい可能性があります。また、削除されたセルがある可能性があります。 HDFSの使用率を向上させるには、削除したセルを削除し、小さなファイルを大きなファイルにマージする必要があります。 MOB圧縮は、小さいファイルのみを圧縮し、大きいファイルは変更されないため、大きいファイルへの繰り返しの圧縮が回避されます。
覚えておくべき他のいくつかのこと：
- どのセルが削除されるかを知ってください。すべてのHBaseメジャー圧縮では、削除マーカーはドロップされる前にdelファイルに書き込まれます。
- MOB圧縮の最初のステップでは、これらのdelファイルがより大きなファイルにマージされます。
- すべての小さいMOBファイルが選択されます。小さいファイルの数が既存のMOBファイルの数と等しい場合、この圧縮は主要な圧縮と見なされ、ALL_FILES圧縮と呼ばれます。
- これらの選択されたファイルは、ファイル名の開始キーと日付によって分割されます。各パーティションの小さなファイルはdelファイルで圧縮されているため、削除されたセルを削除できます。その間に、新しい参照セルを持つ新しいHFileが生成され、コンパクターは新しいMOBファイルをコミットしてから、このHFileをHBaseに一括ロードします。
- すべてのパーティションの圧縮が完了した後、ALL_FILES圧縮が含まれている場合は、delファイルがアーカイブされます。
MOBファイルのライフサイクルを以下に示します。基本的に、これらはmemstoreがフラッシュされたときに作成され、スナップショットによって参照されていないか、アーカイブで期限切れになっていない場合、HFileCleanerによってファイルシステムから削除されます。
結論
要約すると、新しいHBase MOB設計は、ほとんどのセキュリティ、圧縮、およびスナップショット機能を維持しながら、MOBをHBaseのメインI/Oパスから移動します。これは、MOBの操作の特性に対応し、MOBの書き込み増幅をより予測可能にし、読み取りと書き込みの両方で低レイテンシーを維持します。
Jincheng Duは、Intelのソフトウェアエンジニアであり、HBaseの貢献者です。
Jon Hsiehは、Clouderaのソフトウェアエンジニアであり、HBaseコミッター/PMCメンバーです。彼はApacheFlumeの創設者でもあり、ApacheSqoopのコミッターでもあります。