25 | December | 2009 | Agile Cat --- in the cloud

HBase の構造を考える _2

Posted in NoSQL by Agile Cat on December 25, 2009

HBase Architecture 101 – Storage_2
Monday, October 12, 2009
http://www.larsgeorge.com/2009/10/hbase-architecture-101-storage.html

Stay Put

So how is data written to the actual storage? The client issues a HTable.put(Put) request to the HRegionServer which hands the details to the matching HRegion instance. The first step is now to decide if the data should be first written to the "Write-Ahead-Log" (WAL) represented by the HLog class. The decision is based on the flag set by the client using Put.writeToWAL(boolean) method. The WAL is a standard Hadoop SequenceFile (although it is currently discussed if that should not be changed to a more HBase suitable file format) and it stores HLogKey’s. These keys contain a sequential number as well as the actual data and are used to replay not yet persisted data after a server crash.

そうなると、どのようにして、実際のストレージへの書き込みが行われるのだろうか？ここでのクライアントは、HRegion インスタンスとのマッチングへ向けて、詳細を手渡すための HRegionServer に対して、HTable.put(Put)リクエストを発行する。その時の最初のデータが、HLog クラスが代行する "Write-Ahead-Log" (WAL) により書き込まれるべきものなら、最初にステップを決定することになる。この決定は、Put.writeToWAL(boolean) メソッドを用いる、クライアントが設定するフラグに基づく。この WAL とは、スタンダード Hadoop SequenceFile （HBase に合ったファイル形式への変更について、議論の最中であるが）であり、HLogKey をストアする。これらのキーは、連続した番号だけではなく、実際のデータも含む。そして、サーバーがクラッシュした場合には、その時点で永続化されていないデータを再処理する。

Once the data is written (or not) to the WAL it is placed in the MemStore. At the same time it is checked if the MemStore is full and in that case a flush to disk is requested. When the request is served by a separate thread in the HRegionServer it writes the data to an HFile located in the HDFS. It also saves the last written sequence number so the system knows what was persisted so far. Let"s have a look at the files now.

WAL へのデータ書き込みが行われた直後に、あるいは失敗した直後に、それらのデータは MemStore に配置される。それと同時に、MemStore が一杯になっているかどうかのチェックが行われ、一杯の場合には、ディスクへ向けたフラッシュが要求される。そのリクエストが、HRegionServer 内の別スレッドにより処理されるとき、それらのデータが、HDFS 内のHFile へ向けて書き出される。さらに、連続した最後の番号も保存されるため、これまでに永続化されているデータについても、システムは知ることになる。ここで、ファイル自体を見てみよう。

Files

HBase has a configurable root directory in the HDFS but the default is /hbase. You can simply use the DFS tool of the Hadoop command line tool to look at the various files HBase stores.

HBase は、コンフィグレーションが可能な root ディレクトリを HDFS 内に持つが、デフォルトは / hbase となっている。各種のファイル HBase ストアを参照する際には、Hadoop コマンド･ライン･ツールから、シンプルに DFS ツールを使うことができる。

01.$ hadoop dfs -lsr /hbase/docs
02….
03.drwxr-xr-x   – hadoop supergroup          0 2009-09-28 14:22 /hbase/.logs
04.drwxr-xr-x   – hadoop supergroup          0 2009-10-15 14:33 /hbase/.logs/srv1.foo.bar,60020,1254172960891
05.-rw-r–r–   3 hadoop supergroup      14980 2009-10-14 01:32 /hbase/.logs/srv1.foo.bar,60020,1254172960891/hlog.dat.1255509179458
06.-rw-r–r–   3 hadoop supergroup       1773 2009-10-14 02:33 /hbase/.logs/srv1.foo.bar,60020,1254172960891/hlog.dat.1255512781014
07.-rw-r–r–   3 hadoop supergroup      37902 2009-10-14 03:33 /hbase/.logs/srv1.foo.bar,60020,1254172960891/hlog.dat.1255516382506
08….
09.-rw-r–r–   3 hadoop supergroup 137648437 2009-09-28 14:20 /hbase/docs/1905740638/oldlogfile.log
10….
11.drwxr-xr-x   – hadoop supergroup          0 2009-09-27 18:03 /hbase/docs/999041123
12.-rw-r–r–   3 hadoop supergroup       2323 2009-09-01 23:16 /hbase/docs/999041123/.regioninfo
13.drwxr-xr-x   – hadoop supergroup          0 2009-10-13 01:36 /hbase/docs/999041123/cache
14.-rw-r–r–   3 hadoop supergroup   91540404 2009-10-13 01:36 /hbase/docs/999041123/cache/5151973105100598304
15.drwxr-xr-x   – hadoop supergroup          0 2009-09-27 18:03 /hbase/docs/999041123/contents
16.-rw-r–r–   3 hadoop supergroup 333470401 2009-09-27 18:02 /hbase/docs/999041123/contents/4397485149704042145
17.drwxr-xr-x   – hadoop supergroup          0 2009-09-04 01:16 /hbase/docs/999041123/language
18.-rw-r–r–   3 hadoop supergroup      39499 2009-09-04 01:16 /hbase/docs/999041123/language/8466543386566168248
19.drwxr-xr-x   – hadoop supergroup          0 2009-09-04 01:16 /hbase/docs/999041123/mimetype
20.-rw-r–r–   3 hadoop supergroup     134729 2009-09-04 01:16 /hbase/docs/999041123/mimetype/786163868456226374
21.drwxr-xr-x   – hadoop supergroup          0 2009-10-08 22:45 /hbase/docs/999882558
22.-rw-r–r–   3 hadoop supergroup       2867 2009-10-08 22:45 /hbase/docs/999882558/.regioninfo
23.drwxr-xr-x   – hadoop supergroup          0 2009-10-09 23:01 /hbase/docs/999882558/cache
24.-rw-r–r–   3 hadoop supergroup   45473255 2009-10-09 23:01 /hbase/docs/999882558/cache/974303626218211126
25.drwxr-xr-x   – hadoop supergroup          0 2009-10-12 00:37 /hbase/docs/999882558/contents
26.-rw-r–r–   3 hadoop supergroup 467410053 2009-10-12 00:36 /hbase/docs/999882558/contents/2507607731379043001
27.drwxr-xr-x   – hadoop supergroup          0 2009-10-09 23:02 /hbase/docs/999882558/language
28.-rw-r–r–   3 hadoop supergroup        541 2009-10-09 23:02 /hbase/docs/999882558/language/5662037059920609304
29.drwxr-xr-x   – hadoop supergroup          0 2009-10-09 23:02 /hbase/docs/999882558/mimetype
30.-rw-r–r–   3 hadoop supergroup      84447 2009-10-09 23:02 /hbase/docs/999882558/mimetype/2642281535820134018
31.drwxr-xr-x   – hadoop supergroup          0 2009-10-14 10:58 /hbase/docs/compaction.dir

The first set of files are the log files handled by the HLog instances and which are created in a directory called .logs underneath the HBase root directory. Then there is another subdirectory for each HRegionServer and then a log for each HRegion.

最初のファイル･セットは、HLog インスタンスが操作するログ･ファイルであり、HBase root ディレクトリの .logs と呼ばれるディレクトリ内に作成される。続いて、個々の HRegionServer のためのサブディレクトリがあり、さらに、HRegion のためのログが表示されている。

Next there is a file called oldlogfile.log which you may not even see on your cluster. They are created by one of the exceptions I mentioned earlier as far as file access is concerned. They are a result of so called "log splits". When the HMaster starts and finds that there is a log file that is not handled by a HRegionServer anymore it splits the log copying the HLogKey’s to the new regions they should be in. It places them directly in the region’s directory in a file named oldlogfile.log. Now when the respective HRegion is instantiated it reads these files and inserts the contained data into its local MemStore and starts a flush to persist the data right away and delete the file.

その後に続くのは、クラスタ上で見ることはないと思われる、oldlogfile.log と呼ばれるファイルである。前述のとおり、ファイル･アクセスが関与する限り、それらのファイルが、例外処理により生成される。それらは、いわゆる "log splits" の結果である。 HMaster が開始され、もはや HRegionServer に操作されないログファイルが見つかったとき、制御が存在すべき新しい region に HLogKey のログ･コピーが分割される。そして、region ディレクトリ内の、oldlogfile.log という名前のファイル内に、ダイレクトに配置される。このタイミングで、つまり、個々の HRegion がインスタンス化されるとき、それらのファイルが読み込まれ、その内容であるデータがローカルの MemStore に挿入され、正しい位置に永続化するためのフラッシュが実行されてから、このファイルが削除される。

Note: Sometimes you may see left-over oldlogfile.log.old (yes, there is another .old at the end) which are caused by the HMaster trying repeatedly to split the log and found there was already another split log in place. At that point you have to consult with the HRegionServer or HMaster logs to see what is going on and if you can remove those files. I found at times that they were empty and therefore could safely be removed.

Note: 時々、使い残しの oldlogfile.log.old （もう1つの .old が最後に付く）を見かけるだろうが、それらは、HMaster が繰り返してログ分割を行い、また、所定の場所に別のスプリット･ログを見つけた結果である。その時点において、HRegionServer および HMaster のログと相談する必要がある。それにより、起こっている事象を知り、また、それらのファイルの削除に関して判断する。その時点で、ファイルの内容が空であれば、安全に削除出できることに気づいた。

The next set of files are the actual regions. Each region name is encoded using a Jenkins Hash function and a directory created for it. The reason to hash the region name is because it may contain characters that cannot be used in a path name in DFS. The Jenkins Hash always returns legal characters, as simple as that. So you get the following path structure:

その後に続くファイルのセットは、実際の region となる。それぞれの region 名が、Jenkins Hash 関数を用いてコード化され、それのためのディレクトリが作られる。ハッシュを行う理由は、DFS のパス名に使用できない文字が、region 名に含まれる可能性があるためだ。 Jenkins Hash は、適切な文字と、常にシンプルな形でリターンする。次に取得するのは、以下のパス構造となる：

/hbase/<tablename>/<encoded-regionname>/<column-family>/<filename>

In the root of the region directory there is also a .regioninfo holding meta data about the region. This will be used in the future by an HBase fsck utility (see HBASE-7) to be able to rebuild a broken .META. table. For a first usage of the region info can be seen in HBASE-1867.

対象となる rehion ディレクトリの root には、その region のメタデータを持つ、.regioninfo が存在する。それは、将来において、破壊された .META table の再生を実現する、HBase fsck ユーティリティ（HBASE-7 を参照）により使用される。この region 情報に関する最初の用法は、HBASE-1867 で参照できる。

In each column-family directory you can see the actual data files, which I explain in the following section in detail.

それぞれの Column ファミリー･ディレクトリ内では、次のセクションで詳細を説明する、実際のデータ･ファイルが参照される。

Something that I have not shown above are split regions with their initial daughter reference files. When a data file within a region grows larger than the configured hbase.hregion.max.filesize then the region is split in two. This is done initially very quickly because the system simply creates two reference files in the new regions now supposed to host each half. The name of the reference file is an ID with the hashed name of the referenced region as a postfix, e.g. 1278437856009925445.3323223323. The reference files only hold little information: the key the original region was split at and wether it is the top or bottom reference. Of note is that these references are then used by the HalfHFileReader class (which I also omitted from the big picture above as it is only used temporarily) to read the original region data files. Only upon a compaction the original files are rewritten into separate files in the new region directory. This also removes the small reference files as well as the original data file in the original region.

これまでに説明していないものとして、region の分割が、最初の子供を参照するファイルを持つことがあるう。 region 内のデータ･ファイルが、コンフィグレーションされた hbase.hregion.max.filesize より大きくなるとき、その region は 2つに分割される。そのための処理が、きわめて速く最初に処理されるのは、システムが新しい region 内で 2つのリファレンス･ファイルを作成し、それぞれの半分をホストすると推測されるからである。リファレンス･ファイルの名前は、たとえば1278437856009925445.3323223323 のようなプリフィックスとして、参照されるハッシュ名を持つ ID となる。このリファレンス･ファイルは、少量の情報だけを持つ。つまり、オリジナル region は分割され、トップあるいはボトムを参照するようになる点がポイントである。その後に、これらのリファレンスが、オリジナルの region データ･ファイルを読むために、HalfHFileReader クラス（テンポラリなものであるため、上記の図には記載していない）により使用される点に注目すべきだ。圧縮だけが行われ、オリジナル･ファイルは、新しい region ディレクトリ内の分離されたファイルへと書き直される。さらに、小さなリファレンス･ファイルが削除されるだけではなく、オリジナル region のオリジナルのデータ･ファイルも削除される。

And this also concludes the file dump here, the last thing you see is a compaction.dir directory in each table directory. They are used when splitting or compacting regions as noted above. They are usually empty and are used as a scratch area to stage the new data files before swapping them into place.

そして、最終的なファイルのダンプは以下のようになる。末尾にあるのは、それぞれのテーブル･ディレクト内のリcompaction.dir ディレクトリである。それは、前述のとおり、region の分割もしくは圧縮に際して使用される。通常、それらは空であり、また、ファイルを所定の場所とスワップする前に、新しいデータ･ファイルを寄せ集めるエリアとして使用される。

＜続く＞