HBaseの構造(Server構成)

提供: LunaBiblos

以下に示された理由により、このページの編集を行うことができません:

このページのソースを閲覧し、コピーすることができます:

{{Navi|Software|DataBase|KeyValueストア}} {{前後の文書|前文書=HBaseの構造(概要とDataModel)|次文書=HBaseの構造(Clientの仕組)}} {| !Hbase||BigTable |- |HbaseMaster||BigTable Master Server |- |HbaseRegionServer||BigTable Tablet Server |} == HbaseMaster == *Regionファイルの割り当て *HRegionServerの監視 *Tableの管理 HBaseMasterは各HRegionServerへのRegionファイル割り当て管理を行います。<br> 最初に割り当てられるRegionファイルは、「今後割り当てられる物も含めた全META Regionファイルがある場所のデータ」を保持するROOT Regionファイルです。各META Regionファイルは、そのHBaseが保有するユーザ作成のTable群を構成するRegionファイルの場所のデータを保持しています。<br> META Regionファイルの割り当てが完了すると、続いて各HRegionServerに対してユーザ作成Tableを構成するRegionファイルが均等に成るように割り当てを開始します。<br> HBaseMasterは最初に割り当てたROOT Regionファイルを保持するHRegionServerの場所の情報を保持します。<br> またHbaseMasterは各HRegionServerの稼働状態を監視しています。あるHRegionServerが応答停止した場合、その応答停止したHRegionServerのWrite-Aheadログを各Regionファイル毎に分割します。応答停止したHRegionServerが保持しているRegionファイルは別のHRegionServerへ割り当てられる前にWrite-AheadログからRegionファイルへ未適用の編集内容を適用した後、別のHRegionServerへ割り当てられます。<br> 加えてHBaseMasterはTableの有効無効の管理、Table構造の変更等の管理作業も行います。 現在のVerのHBaseでは、HBaseMasterの停止は即Cluster全体の停止を意味しています。BigTableのTablet ServerはMasterとの通信が行えなくても自分が保持するTabletファイルに基づくデータの提供を行う事が出来ます。HBaseはBigTableの様に外部の監視Serverを置いていない為にこの現象が発生します。BigTableのMasterはTabletファイルと共に、TabletServerがTabletに対してAtomicな操作が行える事を保証するファイルロック管理'''Chubby'''を割り当てます。HBaseは全てのHRegionServerの管理は単一のHBaseMasterから行っています。 === META Table === META TableはユーザがHBaseの中に作成したTableを構成する全てのRegionファイルの下記情報をHRegionInfoとして保持しています。 *先頭Keyと末尾Key *そのRegionファイルが有効か無効か *そのRegionファイルを現在保持しているHRegionServerのアドレス情報 ユーザが作成するTableが増え、Regionファイルが増えるにつれてMETA Tableも大きく成っていきます。なお.META.テーブルの1個のROWは約1KBです。 === ROOT Table === ROOT Tableは単一のRegionファイルのみで構成される様に制限されており、全META Tableを構成するRegionファイルがある場所の情報を保持しています。META Tableが他TableのRegionファイルの情報を保持している様に、ROOT Tableは各META Tableを構成する全RegionファイルのHRegionInfoと、各META Table構成Regionファイルが保存されているHRegionServerのアドレス情報を保持しています。 なおROOT Table、META Tableに含まれる1つのRowは約1KBです。初期設定ではRegionファイルの最大容量は256MBに設定されている為、ROOT Table/ROOT Regionファイルは最大で256,000個迄の.META.テーブルのRegionファイルを管理する事が出来ます。<br> またMETA Tableは全体で最大で90億個のRegionファイルを保持する事が出来、これはHbase全体では最大で18EB(Exabyte)のDataを保持する事が出来る事を意味しています。 == HRegionServer == HRegionServerはClientからの読出/書込のRequestを受けて実際に処理を行います。<br> HBaseMasterと通信して自分が提供するRegionファイルの一覧を受け取り、HBaseMasterに自分が応答可能だという事を伝えます。Regionファイルの配置やその他の処理指令は常にHbaseMasterへの応答可能報告を伴って行われます。 === 書込命令 === 書込命令を受け取るとまず最初に'''HLog'''と呼ばれるWrite-Aheadログ(先行書込ログファイル)に書込命令の内容が書き込まれます。一つのHRegionServerが保持する全てのRegionファイルに対する書込命令は、同一のLogファイルに書き込まれます。HLogに書き込まれた後、その情報は'''Memcache'''と呼ばれるMemory上のCacheに保存されます。このMemcacheはHStore毎に生成されます。 === 読込命令 === 読込命令を受け取るとまず最初にMemcache上に該当のDataがあるか否か確認します。無い場合は該当するMapFileを取得しにいきます。 === Cache Flush === MemCacheの容量が事前に設定した容量に達しているとMemoryからDiscへの一括書込「'''Cache Flush'''」が行われ、新たにMapFileが生成されるとHLogにDiscへの書込が行われた事を記録します。再度Cache Flushが行われた際は前回のCache Flash以後に付け加えられたデータのみをDiscに書込ます。このCache FlushはRelive Memory Pressureが起きた際にも実行されます。 データの読込/書込命令を受けるのと同時にMemcacheの大きさの確認が入る為に、それらのRequestと同時にCache Flushが行われる事があります。新たなMapFileが作られ始めると、そのMapFileが'''HStore'''上で有効になる迄、読込/書込命令は待機する事にないます。 === Compactions === 事前に設定した閾値の容量を超えたMapFileが増えてくると、最近書き込まれたMapFileを統合する'''Minor Compaction'''と云う処理が実行されます。 '''Major Compaction'''は定期的に行われ、全てのMapFileを単一のMapFileへと統合します。<br> 古いMapFileは得てして非常に巨大な物になっている事が多い為、そのファイルを読み出し、まだ充分に小さな新しいMapFileと統合した後、再度書き込みする事は時間とIO帯域を喰ってしまう為、Major Compactionが常に行われる事はありません。 データの読込/書込命令を受けるのと同時にMemcacheの大きさの確認が入る為に、それらのRequestと同時にCompactionsが行われる事があります。新たなMapFileが作られ始めると、そのMapFileがHStore上で有効になり、統合され不要になった統合元のMapFileが削除される迄、読込/書込命令は待機する事にないます。 == Region Split == HStoreを構成するMapFileの容量が指定された大きさ(初期値256MB)を超えると'''Region Split'''というRegionファイルの分割が行われます。Region Splitは対象のRegionファイルに含まれるRowの範囲が半分に成る様にRegionファイルを分割します。(ファイルサイズで半分ではありません)<br> 新たに作られるRegionファイルは親RegionファイルのMapFileの一部から拾い出される物であるので非常に素早く行われます。 親Regionファイルが無効状態となり、HRegionServerは新たに子Regionファイルを生成しその情報をMETA テーブルに書き込まれるとともにHBaseMasterには分割が行われた事が連絡され、HBaseMasterはこの新たな子Regionファイルを分割を行ったHRegionServerへと割り当てます。<br> 万が一この分割が行われた事がHBaseMasterに到達しなかった場合でも、HBaseMasterは定期的に行う割り当て情報をMETA テーブルに持たないRegionファイルの調査によって発見されて処理が成されます。 一度親Regionファイルが無効状態となると、そのRegionファイルに対する読込/書込命令は停止されます。HBase ClientはRegionファイルの分割が行われた事を検知する機能を有しており、新たな子Regionファイルが有効状態に成るまで処理を待機します。 分割して生まれた子Regionファイルの片方に対してCompactionが実行されると、親Regionファイルが持つデータが子RegionファイルへとCOPYされます。両方の子Regionファイルに対してCompactionが実行されると、元の親RegionファイルはGarbage Collectionの対象と成ります。 == 参考 == *[http://wiki.apache.org/hadoop/Hbase/HbaseArchitecture Hbase/HbaseArchitecture] {{前後の文書|前文書=HBaseの構造(概要とDataModel)|次文書=HBaseの構造(Clientの仕組)}}

HBaseの構造(Server構成) に戻る。