Hadoop HBase part3 - kuangueの日記

ということで，HBaseについて．

最近，Hadoop内でも特に活発に開発されているHBaseについてです．これは，Google Bigtableの再実装ですね．HBase Architectureを読んでみたまとめを書いておきます．第3弾です．このエントリで翻訳は終了です．

HBase Master Server
それぞれのHRegionServerは，一つのHMasterにコンタクトし続けます．HMasterは，それぞれのHRegionServerに対して，どのHRegionをロードし，制御可能にしなければいけないかを通知する責任を持ちます．HMasterは，集計表を管理します．これは，どのHRegionServersが有効かを示します．もし，HRegionServerとHMasterの接続がタイムアウトになった場合，
1.HRegionServerは自分自身をkillし，空の状態で再起動します．
2.HMasterは，HRegionServerが死んだものとして，管理していたHRegionsを他のHRegionServersへ再配置します．
これは，Bigtableとは違うところですが，TabletServerは，Masterへの接続が死んだ後でも，Tabletsを管理します．この辺の制御をつなげた理由としては，Bigtableのように外部にロックマネージャーを持っていなかったためです．Bigtableでは，ひとつのMasterがあり，それは，tabletsを配置し，lock mager(chubby)も配置します．chubbyは，複数のTabletServersがtabletsにアトミックなアクセスを保証します．HBaseは全てのHRegtionServersへのアクセスに対して，一つの中心的なモジュールで管理します．それが，HMasterです．（これは，Bigtableと同様に危険ではない．それぞれのシステムは，ネットワーク構造上信頼がおける．HMasterもChubbyもデータシステムが
生きている限り行き続けなければなりません．Chubbyもつ長所はあるけど，ひとまずおいておきます．

HRegionServerが新しいHasterの元でチェックするときには，HMasterはそれぞれのHRegionServerへ，0個以上のHRegionsを割り当てることができるか聞きます．もし，HRegtionServerが志望しているときには，HMasterは，これらのHRegionsを配置していないものとして
マークします．その後，別のHRegionServersへの配置を試みます．それぞれのHRegionがテーブル名とそのキー範囲によって特定されたのを思い出して欲しい．キー範囲は，contiguousであるので，rangesは，いつもスタートを持ち，NULLエンドをもつ．よって，start-keyを示すだけで十分である．
#これは，つまり，範囲と入っているけど，1-100を二つに分割した場合に，1-50, 51-100となり，50と51がcontiguousだから，実質的に
#50の意味がないということだと思う．
で，実は，これは十分ではないです．それは，merge()とsplit()があるから，(処理が終わるまでは)同じ名前で全く違う二つのHRegionsが存在します．もし，システムがその時点で落ちたとするなら，両方のHRegionsが同時に存在してしまう．どちらのHRegionが正しいかの仲裁は，HBaseのめた情報にあります．同じHRegionの別バージョンを区別するために，HRegion nameに対してユニークなregionIdをつける必要があります．結局，idは，HRegion: tablename + startkey + regionIdを意味しています．例えば，以下のようにあらわされます
hbaserepository,w-nk5YNZ8TBb2uWFIRJo7V==,6890601455914043877

META Table
このidentifierを別のHRegionにあるrow-labelとして使うことも可能です．HRegionmeta-infoはHRegion内に格納されます．このテーブルをMETAテーブルと呼びます．このテーブルは，HRegion identifiersから物理的なHRegionServer上の配置場所への変換テーブルとなっています．METAテーブルそのものは，大きくなりますので，分割されます．全てのMETAテーブルを配置するためにROOTテーブルに全てのMETA HRegionsのリストを持たせます．ROOTテーブルは必ず一つのHRegionに含まれます．起動時には，HMasterは直ちにROOTテーブルをスキャンしようとします．なぜかというと，唯一つのHRegionが存在し，そいつの名前はHard-Codedだからです．なので，ROOTテーブルがどこかのHRegionServerに配置されるまで，待たないといけません．一度，ROOTテーブルが利用可能になると，HMasterはそのテーブルをスキャンし，全てのMETA HRegionsを得ます．そうしたら，METAテーブルをスキャンします．このときもまた，全てのMETA HRegionsが別のHRegionServersに配置されるまで待たなければなりません．最後に，HMasterがMETAテーブルをスキャンしたとき，HMasterは，HRegionsの全ての集合を知ることになります．そうなったら，それらのHRegionsをHRegionServersへ配置します．HMasterは，現在動作中のHRegionServersをメモリ上で管理します．HMasterが死ぬということは，システム全体が死亡することなので，ディスク上にこれらの情報を格納する意味はありません．
#すげー割り切り．さすがだ．

Bigtableでは，Tablet ->TabletServerのマッピングはChubbyに入っています．Bigtableと違って，HRegion ->HRegionServerのマッピングは物理的にMETAテーブルに格納されてます(chubbyが無いので仕方ない．)．

まとめると，METAテーブル及びROOTテーブルのそれぞれのレコードは三つのメンバをinfo: calumn familyに持っています．
1.info:regioninfo：はシリアル化されたHRegionInfo オブジェクトを持ちます．
2.info:server：は，HServerAddress.toString()によって得られたシリアル化された文字列を持ちます．この文字列は，HServerAddressの一つに供給されます(？？)．
3.info:startcode：は，シリアル化されたlong
intergerで，HRegionServerのスタート時に作成されます．HRegionServerはスタートコードをマスタへ送り，
META/ROOT regionsに書かれている情報が古いかどうかを確認する．このようにして，ROOT HRegionの場所が分かった後では，クライアントは，HMasterへコンタクトしなくてすむ．HMasterへの負荷は相対的に軽い．HMasterは，HRegionServersのタイムアウト，起動時のROOT/METAのスキャン，ROOT HRegionの場所を管理することが仕事です．

Hbaseクライアントは，（喜んで）複雑です．特定のユーザテーブルをスキャンすることを要求されたときなどは，ROOTやMETA
HRegionsをナビゲートする必要があります．もし，HRegionServerが利用できない，または，持っているべきHRegionを持っていない場合には，クライアントはちょっと待ってからリトライします．起動時やHRegionServerがこけたとき，HRegionからHRegionServerへの正しいマップはりよう不能になります．