HBase Architecture 101 – Storage_1
Monday, October 12, 2009
http://www.larsgeorge.com/2009/10/hbase-architecture-101-storage.html
About Me
- Lars George
-
- I am a Software Engineer by heart and work on large scale, distributed, failover-safe systems. Especially "NoSQL" type storage architectures and their related projects like Hadoop with HBase, Hive, Pig. Or Dynomite, Voldemort, Cassandra and so on. I am offering consulting services in this area and for these products. Contact me at info@larsgeorge.com or read about my offer!
View my complete profile
One of the more hidden aspects of HBase is how data is actually stored. While the majority of users may never have to bother about it you may have to get up to speed when you want to learn what the various advanced configuration options you have at your disposal mean. "How can I tune HBase to my needs?", and other similar questions are certainly interesting once you get over the (at times steep) learning curve of setting up a basic system. Another reason wanting to know more is if for whatever reason disaster strikes and you have to recover a HBase installation.
多くのケースにおいて、HBase の隠された局面のひとつは、実際にデータをストアする方式となる。その点について、大多数のユーザーは気にする必要が無いかもしれないが、各種の先進的なコンフィグレーションを学習したいと望むときには、取捨選択のスピードを上げる必要があるかもしれない。まず、”どうしたら HBase をニーズに合わせられるか？” という疑問がある。そして、（ときには重要な）基本的なシステムを設定するための学習曲線を超えた途端に、他の類似する問題が生じてくる。さらに多くのことを知りたくなる理由は、その理由が災害対策であったとしても、HBase インストレーションをリカバーが必要だという点にある。
In my own efforts getting to know the respective classes that handle the various files I started to sketch a picture in my head illustrating the storage architecture of HBase. But while the ingenious and blessed committers of HBase easily navigate back and forth through that maze I find it much more difficult to keep a coherent image. So I decided to put that sketch to paper. Here it is.
私として努力したのは、多様なファイルを取り扱う各クラスを知ることであり、HBase のストレージ・アーキテクチャを例証するスケッチから取り掛かった。 なぜなら、HBase の創造的で恵まれたコミッターたちが、その迷路を自在に前後へとナビゲートするにもかかわらず、一貫したイメージを保持することが極めて難しいと認識した。したがって、私はペーパーにスケッチを描くことに決めた。 しれが、以下のものである。
Please note that this is not a UML or call graph but a merged picture of classes and the files they handle and by no means complete though focuses on the topic of this post. I will discuss the details below and also look at the configuration options and how they affect the low-level storage files.
それは、UML や Call Graph ではないが、取り扱うクラスとファイルをマージしたものである。ただし、このポストのトピックに、完全に焦点を合わせたものでもない。以下に詳細を記述し、さらにコンフィグレーション･オプションと、それらが低レベルのストレージ･ファイルに影響を与える様子にも注目していく。
The Big Picture
So what does my sketch of the HBase innards really say? You can see that HBase handles basically two kinds of file types. One is used for the write-ahead log and the other for the actual data storage. The files are primarily handled by the HRegionServer’s. But in certain scenarios even the HMaster will have to perform low-level file operations. You may also notice that the actual files are in fact divided up into smaller blocks when stored within the Hadoop Distributed Filesystem (HDFS). This is also one of the areas where you can configure the system to handle larger or smaller data better. More on that later.
それらのファイルは、主として HRegionServer のものとして取り扱われる。 ただし、特定のシナリオでは、HMaster でさえ低レベルのファイル操作を必要とするだろう。さらに、Hadoop Distributed Filesystem（HDFS）にストアされるとき、それらのファイルが実際より小さなブロックに分割されることに気付くだろう。この方式は、大きなデータや小さなでデータを適切に操作するような、システムのコンフィグレーションを可能にするための １つの領域である。そのことについては、後に触れる。
The general flow is that a new client contacts the Zookeeper quorum (a separate cluster of Zookeeper nodes) first to find a particular row key. It does so by retrieving the server name (i.e. host name) that hosts the -ROOT- region from Zookeeper. With that information it can query that server to get the server that hosts the .META. table. Both of these two details are cached and only looked up once. Lastly it can query the .META. server and retrieve the server that has the row the client is looking for.
新しいクライアントが、特定の Row キーを探すために、最初に Zookeeper quorum （Zookeeper ノードの別個のクラスタ）とのコンタクトを取るというのが、一般的な流れである。 Zookeeper から、ROOT リージョンをホストするサーバー名（すなわちホスト名）を検索することで、それが実行される。 この情報を用いることで、そのサーバーにクエリーをかけることが可能となり、.META table をホストするサーバーが取得される。 ここでの 2つの詳細情報は、どちらもキャッシュされ、一度調べられるだけである。最終的に、.META サーバーへのクエリーが可能となり、クライアントが探している Row を持つ、サーバーへの検索が実現される。
Once it has been told where the row resides, i.e. in what region, it caches this information as well and contacts the HRegionServer hosting that region directly. So over time the client has a pretty complete picture of where to get rows from without needing to query the .META. server again.
たとえば、region などの Row が存在する場所と、一度会話が成立すると、その情報をキャッシュし、その region をダイレクトにホスティングする HRegionServer とコンタクトを取る。そして、クライアントは再び .META サーバーへのクエリーを必要とすることなく、Row を取得すべき場所の、きわめて詳細な全体像を、長時間にわたり維持することになる。
Note: The HMaster is responsible to assign the regions to each HRegionServer when you start HBase. This also includes the "special" -ROOT- and .META. tables.
Note: HBase を起動するとき、それぞれの HRegionServer に対して region を割り当てる責任を、HMaster は持つ。 それにより、 "special" -ROOT- と .META table も取り込むことになる。
Next the HRegionServer opens the region it creates a corresponding HRegion object. When the HRegion is "opened" it sets up a Store instance for each HColumnFamily for every table as defined by the user beforehand. Each of the Store instances can in turn have one or more StoreFile instances, which are lightweight wrappers around the actual storage file called HFile. A HRegion also has a MemStore and a HLog instance. We will now have a look at how they work together but also where there are exceptions to the rule.
続いて、HRegionServer は対象となる region をオープンし、それが対応する HRegion オブジェクトを生成する。 HRegion が "open" されるとき、あらかじめユーザーが定義したように、すべてのテーブルに対応する個々の HColumnFamily のための、Store インスタンスが設定される。 HFile と呼ばれる実際のストレージ･ファイルのラッパーである、1つ以上の StoreFile インスタンスを、それぞれの Store インスタンスは持つことができる。 さらに、HRegion は MemStore と HLog のインスタンスを持つ。 ここまでで、それらの協調動作することだけではなく、例外ルールもあることが分かるはずだ。
＜続く＞
ーーー
３回くらいに分けて掲載して良く予定です。 ーーー A.C.
＜関連＞
HBase の構造を考える _1
HBase の構造を考える _2
HBase の構造を考える _3
NoSQL Ecosystem とは？ _1
Hadoop DFS _ Introduction
エンタープライズ RDBMS を Hadoop で補完 _1
The Anatomy of Hadoop I/O Pipeline _1
