HBase の構造を考える _3

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

HFile

So we are now at a very low level of HBase’s architecture. HFile’s (kudos to Ryan Rawson) are the actual storage files, specifically created to serve one purpose: store HBase’s data fast and efficiently. They are apparently based on Hadoop’s TFile (see HADOOP-3315) and mimic the SSTable format used in Googles BigTable architecture. The previous use of Hadoop’s MapFile’s in HBase proved to be not good enough performance wise. So how do the files look like?

前述のとおり、私たちは HBase のアーキテクチャの、きわめて低レベルを見ている。 HFile（kudos to Ryan Rawson）が、ひとつの目的だけに焦点を絞って作成される、ストレージ･ファイルの実体である。 その目的とは、高速かつ効率的に HBase のデータをストアすることである。一見したところ、Hadoop の TFile (HADOOP-3315 を参照）に基づき、また、Googles BigTable アーキテクチャで用いられる SSTable フォーマットに類似したものとなっている。 HBase における Hadoop MapFile の以前の用法は、充分なパフォーマンスを提供していないことが証明された。 そのファイルは、どのように見えるのだろうか？

The files have a variable length, the only fixed blocks are the FileInfo and Trailer block. As the picture shows it is the Trailer that has the pointers to the other blocks and it is written at the end of persisting the data to the file, finalizing the now immutable data store. The Index blocks record the offsets of the Data and Meta blocks. Both the Data and the Meta blocks are actually optional. But you most likely you would always find data in a data store file.

このファイルは可変長を持ち、唯一の固定的なブロックは、FileInfo と Trailer のブロックとなる。 上記の図に示すように、Trailer は他のブロックへのポインタを持ち、ファイルに対して永続的データの最後に記述され、不変のデータ･ストアを完結する。Index ブロックは、Data と Meta のブロックの、オフセットについて記録する。 Data と Meta のブロックは、現実には、どちらも任意のものとなる。ただし、データ･ストア･ファイルの中で、常にデータを見たいと思うはずだ。

How is the block size configured? It is driven solely by the HColumnDescriptor which in turn is specified at table creation time by the user or defaults to reasonable standard values. Here is an example as shown in the master web based interface:

そして、ブロック･サイズのコンフィグレーションはどうだろう？それは、ユーザー設定あるいはディフォルト値により、合理的で標準的な結果を得るために、テーブルの作成時に HColumnDescriptor により、１つずつ順番に処理される。 以下に示すのは、マスター Web ベースの、インターフェイスの例である：

{NAME => ‘docs’, FAMILIES => [{NAME => 'cache', COMPRESSION => 'NONE', VERSIONS => '3', TTL => '2147483647', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'false'}, {NAME => 'contents', COMPRESSION => 'NONE', VERSIONS => '3', TTL => '2147483647', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'false'}, ...

The default is "64KB" (or 65535 bytes). Here is what the HFile JavaDoc explains:

ディフォルトは、"64KB" (or 65535 bytes)である。 以下に、HFile JavaDoc での説明を転記する:

"Minimum block size. We recommend a setting of minimum block size between 8KB to 1MB for general usage. Larger block size is preferred if files are primarily for sequential access. However, it would lead to inefficient random access (because there are more data to decompress). Smaller blocks are good for random access, but require more memory to hold the block index, and may be slower to create (because we must flush the compressor stream at the conclusion of each data block, which leads to an FS I/O flush). Further, due to the internal caching in Compression codec, the smallest possible block size would be around 20KB-30KB."

ブロックのミニマム・サイズについて、 8KB ～ 1MB のブロック・サイズを、一般的には推奨します。 シーケンシャル･アクセスが主体ならば、大きなブロック･サイズが適しています。しかし、そのように設定すると、（データの解凍があるため）ランダム･アクセスが非効率になります。小さなブロックは、ランダム･アクセスに適していますが、Index ブロックを保持するために大量のメモリが必要とされ、また、生成にも時間がかかります（FS I/O フラッシュを生じる、それぞれのデータ･ブロックの終端において、圧縮ストリームをクリアする必要があるため）。 さらに、Compression コーデックにおける内部キャッシングが要因となり、最も小さくできるブロック･サイズは、およそ 20KB～30KB でしょう。

So each block with its prefixed "magic" header contains either plain or compressed data. How that looks like we will have a look at in the next section.

そのため、"magic" を伴なう個々のブロックは、プレーンなデータあるいは、圧縮されたデータを含むことになる。次のセクションで見るものは、どのように映るだろうか？

One thing you may notice is that the default block size for files in DFS is 64MB, which is 1024 times what the HFile default block size is. So the HBase storage files blocks do not match the Hadoop blocks. Therefore you have to think about both parameters separately and find the sweet spot in terms of performance for your particular setup.

DFS におけるディフォルトのファイル･ブロック･サイズが、64MBであることに気づくだろう。それは、HFile デフォルト･ブロック･サイズの 1024 倍である。 したがって、HBase ストレージ･ファイル･ブロックと、Hadoop ブロックは一致しない。そのため、双方のパラメータについて別個に考え、特定のセットアップにおけるパフォーマンスについて、スイート･スポットを見いだす必要がある。

One option in the HBase configuration you may see is hfile.min.blocksize.size. It seems to be only used during migration from earlier versions of HBase (since it had no block file format) and when directly creating HFile during bulk imports for example.

参照される可能性のある、HBase コンフィグレーションにおけるひとつの選択肢が、hfile.min.blocksize.size である。それは、従来の HBase バージョン（ブロック･ファイル形式を持たないため）からの移行において、また、例えばバルク･インポートでダイレクトに HFile を作成するときだけに、使用されると思われる。

So far so good, but how can you see if a HFile is OK or what data it contains? There is an App for that!

そこまでは良いが、Hfile が OK なのかどうか、また、どのようなデータ含まれるのかという点で、何を確認すれば良いのか？ 如何に、そのためのアプリケーションを示す！

The HFile.main() method provides the tools to dump a data file:

この HFile.main() メソッドは、データ・ファイルをダンプするためのツールを提供する：

01.$ hbase org.apache.hadoop.hbase.io.hfile.HFile
02.usage: HFile  [-f <ARG>] [-v] [-r <ARG>] [-a] [-p] [-m] [-k]
03. -a,–checkfamily    Enable family check
04. -f,–file <ARG>     File to scan. Pass full-path; e.g.
05.                            hdfs://a:9000/hbase/.META./12/34
06. -k,–checkrow       Enable row order check; looks for out-of-order keys
07. -m,–printmeta      Print meta data of file
08. -p,–printkv        Print key/value pairs
09. -r,–region <ARG>   Region to scan. Pass region name; e.g. ‘.META.,,1′
10. -v,–verbose        Verbose output; emits file and meta data delimiters

Here is an example of what the output will look like (shortened here):

以下に示すのは、出力の例である（省略部分あり）：

01.$ hbase org.apache.hadoop.hbase.io.hfile.HFile -v -p -m -f \
02. hdfs://srv1.foo.bar:9000/hbase/docs/999882558/mimetype/2642281535820134018
03.Scanning -> hdfs://srv1.foo.bar:9000/hbase/docs/999882558/mimetype/2642281535820134018
04….
05.K: \x00\x04docA\x08mimetype\x00\x00\x01\x23y\x60\xE7\xB5\x04 V: text\x2Fxml
06.K: \x00\x04docB\x08mimetype\x00\x00\x01\x23x\x8C\x1C\x5E\x04 V: text\x2Fxml
07.K: \x00\x04docC\x08mimetype\x00\x00\x01\x23xz\xC08\x04 V: text\x2Fxml
08.K: \x00\x04docD\x08mimetype\x00\x00\x01\x23y\x1EK\x15\x04 V: text\x2Fxml
09.K: \x00\x04docE\x08mimetype\x00\x00\x01\x23x\xF3\x23n\x04 V: text\x2Fxml
10.Scanned kv count –> 1554
11.Block index size as per heapsize: 296
12.reader=hdfs://srv1.foo.bar:9000/hbase/docs/999882558/mimetype/2642281535820134018, \
13.  compression=none, inMemory=false, \
14.  firstKey=US6683275_20040127/mimetype:/1251853756871/Put, \
15.  lastKey=US6684814_20040203/mimetype:/1251864683374/Put, \
16.  avgKeyLen=37, avgValueLen=8, \
17.  entries=1554, length=84447
18.fileinfoOffset=84055, dataIndexOffset=84277, dataIndexCount=2, metaIndexOffset=0, \
19.  metaIndexCount=0, totalBytes=84055, entryCount=1554, version=1
20.Fileinfo:
21.MAJOR_COMPACTION_KEY = \xFF
22.MAX_SEQ_ID_KEY = 32041891
23.hfile.AVG_KEY_LEN = \x00\x00\x00\x25
24.hfile.AVG_VALUE_LEN = \x00\x00\x00\x08
25.hfile.COMPARATOR = org.apache.hadoop.hbase.KeyValue\x24KeyComparator
26.hfile.LASTKEY = \x00\x12US6684814_20040203\x08mimetype\x00\x00\x01\x23x\xF3\x23n\x04

The first part is the actual data stored as KeyValue pairs, explained in detail in the next section. The second part dumps the internal HFile.Reader properties as well as the Trailer block details and finally the FileInfo block values. This is a great way to check if a data file is still healthy.

最初のパートは、KeyValue のペアとしてストアされる実際のデータであり、次のセクションで詳細に説明する。 2番目のパートは、内部にある HFile.Reader のプロパティだけではなく、 Trailer ブロックの詳細をダンプし、最終的に FileInfo ブロック値もダンプする。それは、データ･ファイルの状態をチェックする、素晴らしい方式である。

KeyValue’s

In essence each KeyValue in the HFile is simply a low-level byte array that allows for "zero-copy" access to the data, even with lazy or custom parsing if necessary. How are the instances arranged?

本質的に、HFile の個々の KeyValue は、低レベルのバイト･アレイであり、レイジーもしくはカスタムなパージングが必要であっても、対象となるデータへの "zero-copy" アクセスを可能にする。そして、どのようにインスタンスは配置されるのだろうか？

The structure starts with two fixed length numbers indicating the size of the key and the value part. With that info you can offset into the array to for example get direct access to the value, ignoring the key – if you know what you are doing. Otherwise you can get the required information from the key part. Once parsed into a KeyValue object you have getters to access the details.

このストラクチャは、キーと値のパートについて、そのサイズを示す 2つの固定長数により始まる。それらの情報を用いて、たとえば値へのダイレクト･アクセスを得るために、キーを無視して、アレイをオフセットできるが、何か起こるのか、知っている必要がある。さもなければ、キーのパートから、必要な情報を取得することになる。 一度、KeyValue オブジェクトへと解析されると、細部にアクセスするための getter を持つことになる。

Note: One thing to watch out for is the difference between KeyValue.getKey() and KeyValue.getRow(). I think for me the confusion arose from referring to "row keys" as the primary key to get a row out of HBase. That would be the latter of the two methods, i.e. KeyValue.getRow(). The former simply returns the complete byte array part representing the raw "key" as colored and labeled in the diagram.

Note: 警戒するべきことは、KeyValue.getKey () と KeyValue.getRow () の間の相違である。 私の場合は、HBase から Row を取りを出すために、主キーとして "row keys" を参照したことに、混乱の原因があった。それは、2つのメソッドの後者、すなわち KeyValue.getRow () のはずだ。前者は、このダイアグラムのカラー･ラベルとしての、ナマの ”key” を表示する、完全なバイト･アレイ･パートをリターンする。

This concludes my analysis of the HBase storage architecture. I hope it provides a starting point for your own efforts to dig into the grimy details. Have fun!

以上が、HBase ストレージ･アーキテクチャに関する私の分析である。これが、厄介な詳細を探求する、あなた自身の作業の出発点になることを希望する。 楽しんで行こう！

Update: Slightly updated with more links to JIRA issues. Also added Zookeeper to be more precise about the current mechanisms to look up a region.

Update 2: Added details about region references.

Update 3: Added more details about region lookup as requested.

Posted by Lars George

＜終わり＞

ーーー

間違いや、勘違いなど、ここはオカシイというのがありましたら、ご指摘くださ～い。 ーーー 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

HBase の構造を考える _2

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 の分割もしくは圧縮に際して使用される。通常、それらは空であり、また、ファイルを所定の場所とスワップする前に、新しいデータ･ファイルを寄せ集めるエリアとして使用される。

＜続く＞

＜関連＞
HBase の構造を考える _1
HBase の構造を考える _2
HBase の構造を考える _3
NoSQL Ecosystem とは？ _1
Hadoop DFS _ Introduction
エンタープライズ RDBMS を Hadoop で補完 _1
The Anatomy of Hadoop I/O Pipeline _1

HBase の構造を考える _1

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

AWS Management Console をビデオでど～ぞ！

AWS Management Console

A Web-based Interface to Manage Your Services

この新しい、Webベースの point-and-click UI を使って、成長する Amazon のWebサービス・インフラストラクチャにアクセスし、マネージしてください。AWS Management Console により、クラウド･コンピューティング環境全体における、細部が迅速に提供されるため、運用中のリソースの参照と、それらの管理が容易になります。

http://aws.amazon.com/console/

・・・ とのことです。 そして、EC2 に加えて、な、なんと、Elastic MapReduce と CloudFront まで、この Management Console を介して説明されているではありませんか！ まずは、以下の URL をクリックしてみてくださいな －－－ A.C.

Making AWS Simpler to Access and Use

The AWS Management Console provides a graphical user interface for Amazon EC2, Amazon Elastic MapReduce, and Amazon CloudFront, with additional Amazon infrastructure services scheduled to be added to the console in the coming months.

Amazon EC2 Features

With the AWS Management Console, developers can start and stop EC2 instances, view and perform actions on running instances, and manage Elastic Block Store volumes with simple clicks of a mouse. You can also see what configurations you have set (e.g. security groups, key pairs, and Elastic IPs) and modify them using interactive controls.

Watch an Audio/Video Screencast of the Amazon EC2 Console

Amazon Elastic MapReduce Features

With the AWS Management Console, developers can easily launch Elastic MapReduce job flows and monitor their progress. You can create as many job flows as you’d like by filling out a simple wizard. You can monitor job flow status as it progresses through execution stages, and, if required, terminate it with a single mouse click. Using our search interface you can view up to two weeks of job flow history.

Watch an Audio/Video Screencast of the Elastic MapReduce Console

Amazon CloudFront Features

Manage Amazon CloudFront through an easy to use interface. The AWS Management Console lets you review all your CloudFront distributions, create new distributions, or edit existing ones. All the features of the CloudFront API are supported: you can enable or disable distributions, configure CNAMEs, enable end-user logging, and more.

Watch an Audio/Video Screencast of the Amazon CloudFront Console

Future Roadmap

The following features and new services are scheduled to be added to the AWS Management Console in the near future. To request additional features, please submit requests on our feedback form.

• Tagging – Label and group Amazon EC2 resources with your own custom metadata to make it easier to identify and manage your instances, volumes, and other EC2 resources.
• Auto Scaling – Configure auto-scaling rules through a web-based UI.
• Amazon S3 Support – Create and delete Amazon S3 buckets, upload and download objects through your browser, edit permissions, set log data, and manage URLs.
• Amazon SimpleDB Support – Construct SimpleDB queries through a point-and-click query expression builder and explore your data through a graphical dataset viewer.
• Amazon SQS Support – Manage your SQS queues, add and retrieve messages from your queues, test and build your applications with help from the AWS Management Console.

Pasted from <http://aws.amazon.com/console/>

NoSQL Ecosystem とは？ _1

NoSQL Ecosystem
http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/#

// November 9th, 2009 // Development

 

By Jonathan Ellis, Systems Architect

Unprecedented data volumes are driving businesses to look at alternatives to the traditional relational database technology that has served us well for over thirty years. Collectively, these alternatives have become known as “NoSQL databases.”

前例のないデータ量が、30 年以上にもわたって適切なサービスを提供してきた、伝統的なリレーショナル･データベース･テクノロジーに替る選択肢を探し出せと、ビジネスに対して働きかけている。それらの代替物を集約すると、「NoSQL データベース」として認識されるものとなる。

The fundamental problem is that relational databases cannot handle many modern workloads.  There are three specific problem areas: scaling out to data sets like Digg’s (3 TB for green badges) or Facebook’s (50 TB for inbox search) or eBay’s (2 PB overall), per-server performance, and rigid schema design.

根本的な問題は、近年になって生じてきた、数多くの新しいワークロードを、リレーショナル･データベースが取り扱えない点にある。つまり、Digg（3 TB for green badges）／Facebook（50 TB for inbox search）／eBay（2 PB overall） のようなデータセットのスケールアウトおよび、サーバーごとのパフォーマンス、そして固定的なスキーマ設計という、3つの問題点がある。

Businesses, including The Rackspace Cloud, need to find new ways to store and scale large amounts of data. I recently wrote a post on  Cassandra, a non-relational database we have committed resources to. There are other non-relational databases being worked on and collectively, we call this the “NoSQL movement.”

The Rackspace Cloud を含めたビジネスにおいて、大量のデータをストアし、また、調整していくための、新しい方式が必要とされている。Cassandra に関する先日のポストでは、そのためのリソースとして、Non リレーショナル･データベースをコミットしていると書いた。 その他にも、運用されている Non リレーショナル･データベースがあり、それらを集約して「NoSQL ムーブメント」と称している。

The “NoSQL” term was actually coined by a fellow Racker, Eric Evans when Johan Oskarsson of Last.fm wanted to organize an event to discuss open source distributed databases. The name and concept both caught on.

この「NoSQL」という用語は、オープンソース分散データベースについてディスカッションするために、Last.fm の Johan Oskarsson がイベントを開催したいと望んだときに、Rackspace と親しい Eric Evans が言い出したものである。そして、その名前とコンセプトが、広く用いられるようになった。

Some people object to the NoSQL term because it sounds like we’re defining ourselves based on what we aren’t doing rather than what we are. That’s true, to a degree, but the term is still valuable because when a relational database is the only tool you know, every problem looks like a thumb.  NoSQL is making people aware that there are other options out there. But we’re not anti-relational-database for when that really is the best tool for the job; it’s “Not Only SQL,” rather than “No SQL at all.”

何人かの人々は、私たちが行う以外のことを、指し示す定義のように聞こえるという理由から、NoSQL という用語に反対した。それは、ひとつの局面から見れば事実であるが、リレーショナル･データベースが唯一のツールであり、何も問題がないと認識されている場合には、この用語は意味を成す。 つまり、他の選択肢があることを、NoSQL は人々に知らせることになる。 ただし、私たちはアンチ･リレーショナル･データベースではなく、また、現実的な面で作業に適したツールが欲しいだけであり、“No SQL at all” ではなく “Not Only SQL” なのである。

One real concern with the NoSQL name is that it’s such a big tent that there is room for very different designs.  If this is not made clear when discussing the various products, it results in confusion.  So I’d like to suggest three axes along which to think about the many database options: scalability, data and query model, and persistence design.

NoSQL という名前から連想すべきことは、それが極めて大きなテントであり、その中に、各種のデザインを収めるためのスペースがあるということだ。その点を明確にせずに、また、個々のプロダクトについて議論するとき、混乱が生じるだろう。そのため、数多くのデータベース・オプションについて考えるための、 scalability／data and query model／persistence design という3つの機軸を提案する。

I have chosen 10 NoSQL databases as examples.  This is not an exhaustive list, but the concepts discussed are crucial for evaluating others as well.

サンプルとして、10 種類の NoSQL データベースを選んだ。それは、包括的なリストではないが、それらの概念は、他の製品を評価する上で、決定的な指標となる。

ーーーーー

先日、CloudNewsCenter の鈴木逸平さんとお会いしたとき、Cloud を取り扱う日本のメディアは、なぜ Google ばかりを追いかけ、Rackspace には見向きもしないのか、という話題になりました。 この、クラウド界の実力者が、NoSQL にも深く関わっていることに、とても興味があります。 ーーー A.C.

＜関連＞

NoSQL Ecosystem とは？ _1
NoSQL Ecosystem とは？ _2
NoSQL Ecosystem とは？ _3
nosql-ja
サーバー保有台数ランキング
Rackspace のクラウド料金体系
ISP とクラウド経済

＜続く・・・＞

NoSQL Ecosystem とは？ _2

NoSQL Ecosystem
http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/#

// November 9th, 2009 // Development

By Jonathan Ellis, Systems Architect

Scalability

Scaling reads is easy with replication, so when we’re talking about scaling in this context, we mean scaling writes by automatically partitioning data across multiple machines.  We call systems that do this “distributed databases.”  These include Cassandra, HBase, Riak, Scalaris, Voldemort, and more. If your write volume or data size is more than one machine can handle then these are your only options if you don’t want to manage partitioning manually.  (You don’t.)

このコンテキストにおいて、スケーリングについて論じるとき、リプリケーションを用いることで読み取りの調整は簡単に行える。 つまり、マルチ･マシンをまたいでデータを自動的にパーテショニングする、書き込みのスケーリングが論点となる。そのようなシステムを、ここでは「分散データベース」と呼ぶ。たとえば、Cassandra／HBase／Riak／Scalaris／Voldemort などが、そこには含まれる。 そこには、1台のマシンでは処理し切れない量の、データを書き込む場合の選択肢がある。もし、手作業によりパーティショニングを行いたくないなら、唯一の選択肢となる。

There are two things to look for in a distributed database: 1) support for multiple datacenters and 2) the ability to add new machines to a live cluster transparently to your applications.

分散データベースには 2つのポイントがある。 それらは、1)マルチ･データセンターのサポートと、2) 対象となるアプリケーションのための活きたクラスタに対して、新しいマシンを透過的に加える能力である。

Non-distributed NoSQL databases include CouchDB, MongoDB, Neo4j, Redis, and Tokyo Cabinet. These can serve as persistence layers for distributed systems; MongoDB provides limited support for sharding, as does a separate Lounge project for CouchDB, and Tokyo Cabinet can be used as a Voldemort storage engine.

非分散型の NoSQL データベースには、 CouchDB ／MongoDB／Neo4j／Redis／Tokyo Cabinet が含まれる。 それらは分散システムのための、永続的なレイヤーの役割を担える。 つまり、MongoDB は sharding のための限定されたサポートを提供し、CouchDB のための分離された Lounge プロジェクトとして機能し、Tokyo Cabinet は Voldemort のストレージ･エンジンとして利用される。

Data and Query Model

There is a lot of variety in the data models and query APIs in NoSQL databases.

NoSQLデータベースには、多種多彩なデータモデルとクエリー API がある。

(Respective Links: Thrift, map/reduce views, Thrift, Cursor, Graph, Collection, Nested hashes, get/put, get/put, get/put)

Some highlights:

The columnfamily model shared by Cassandra and HBase is inspired by the one described by Google’s Bigtable paper, section 2. (Cassandra drops historical versions, and adds supercolumns.) In both systems, you have rows and columns like you are used to seeing, but the rows are sparse: each row can have as many or as few columns as desired, and columns do not need to be defined ahead of time.

Cassandra と HBase で共有されるcolumnfamily モデルは、Google の Bigtable ペーパーのセクション 2に記述されたことに触発されている（Cassandra はヒストリカル･バージョンを廃して、supercolumns を加える）。 双方のシステムにおいて、見慣れた Row/Column を持つことが可能だが、その Row の数は少ない。 つまり、それぞれの Row は、必要に応じたCloumn 数を持つことが可能であり、さらに、Column を事前に定義する必要はない。

The Key/value model is the simplest and easiest to implement but inefficient when you are only interested in querying or updating part of a value.  It’s also difficult to implement more sophisticated structures on top of distributed key/value.

この Key/Value モデルの実装は、最も簡潔で簡単だが、それらの値の一部だけをクエリーおよびアップデートするだけなら、効果的なものにはならない。さらに言えば、分散された Key/Value の上に、洗練された構造を実装することが困難になる。

Document databases are essentially the next level of Key/value, allowing nested values associated with each key.  Document databases support querying those more efficiently than simply returning the entire blob each time.

ネストされた値と個々の Key を結びつけるドキュメント･データベースは、Key/Value モデルにおける次の重要なテーマとなる。データベースがサポートするクエリーは、その都度 Blob 全体をリターンする方式よりも、効果的なものとなる。

Neo4J has a really unique data model, storing objects and relationships as nodes and edges in a graph.  For queries that fit this model (e.g., hierarchical data) they can be 1000s of times faster than alternatives.

Neo4J は、クラフにおけるノードとエッジとして、特徴的なデータ・モデルおよび、強化されたオブジェクトとリレーションを持つ。このモデル（たとえば階層的なデータ）に適合するクエリーのために、その他のテクノロジーと比較して 1000倍ほど高速になるだろう。

Scalaris is unique in offering distributed transactions across multiple keys.  (Discussing the trade-offs between consistency and availability is beyond the scope of this post, but that is another aspect to keep in mind when evaluating distributed systems.)

Scalaris は、マルチ･キーをまたいだ分散トランザクションを提供するという点でユニークである。（コンシステンシーとアベイラビリティのトレードオフという論点は、このポストのスコープ外となるが、分散システムを評価する際に、気に留めておくべき別の局面となる）

ーーーーー

抄訳といっても、ちょっとアヤフヤ過ぎるところがあるかと思います。 ご指摘などをいただけると嬉しいです。 ーーー A.C.

＜関連＞

NoSQL Ecosystem とは？ _1
NoSQL Ecosystem とは？ _2
NoSQL Ecosystem とは？ _3
nosql-ja
サーバー保有台数ランキング
Rackspace のクラウド料金体系
ISP とクラウド経済

＜続く・・・＞

NoSQL Ecosystem とは？ _3

NoSQL Ecosystem
http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/#

// November 9th, 2009 // Development

By Jonathan Ellis, Systems Architect

Persistence Design

By persistence design I mean, “how is data stored internally?”

私の考える、パーシスタンスに関するデザインとは、"どのような方式で、データを内部的にストアするか？" ということである。

The persistence model tells us a lot about what kind of workloads these databases will be good at.

上記のデータベースが、どのような種類のワークロードを得意とするのか、パーシスタンス･モデルというものが教えてくれる。

In-memory databases are very, very fast (Redis achieves over 100,000 operations per second on a single machine), but cannot work with data sets that exceed available RAM.  Durability (retaining data even if a server crashes or loses power) can also be a problem; the amount of data you can expect to lose between flushes (copying the data to disk) is potentially large.  Scalaris, the other in-memory database on our list, tackles the durability problem with replication, but since it does not support multiple data centers your data will be still be vulnerable to things like power failures.

イン･メモリのデータベースは、桁外れに高速であるが（Redis はシングル･マシン上で毎秒100,000回のオペレーションを実行する）、利用可能な RAM を超えるデータセットは取り扱えない。さらに、耐障害性（サーバー･クラッシュや停電でもデータを維持る）も問題となり得る。つまり、フラッシュ（ディスクへのデータ・コピー）を行わない間に失うことになるデータは、きわめて大量のものとなり得る。上記のリストにおける、別種のインメモリー･データベースである Scalaris は、リプリケーションを用いて耐久性の問題に取り組む。ただし、複数のデータセンターをまたぐサポートが無いため、依然として停電などの被害を免れない。

Memtables and SSTables buffer writes in memory (a “memtable”) after writing to an append-only commit log for durability.  When enough writes have been accepted, the memtable is sorted and written to disk all at once as a “sstable.”  This provides close to in-memory performance since no seeks are involved, while avoiding the durability problems of purely in-memory approaches.  (This is described in more detail in sections 5.3 and 5.4 of the previously-referenced Bigtable paper, as well as in The log-structured merge-tree.)

Memtables と SSTables のバッファは耐障害性を確保するために、append-only commit log を書いた後に、イン･メモリ（memtable）での書き込みを行う。必要とされる書き込みが受け付けられたとき、 この memtable はソートされ、ひとまとめにされた ”sstable” としてディスクに書き込まれる。それにより、seek が消費する時間が無関係となるため、インメモリーに近いパフォーマンスが提供されるが、純粋なインメモリーのアプローチにおける、永続性の問題は回避されてしまう。（その点については、以前に参照した Bigtable ペーパーのセクション 5.3 と 5.4 に詳述されている。また、 The log-structured merge-tree のセクションにも、同様に記述されている）

B-Trees have been used in databases since practically the beginning of time.  They provide robust indexing support, but performance is poor on rotational disks (which are still by far the most cost-effective) because of the multiple seeks involved in reading or writing anything.

B-Trees は、とりわけ、その初期において、データベースを使ってきた。そこでは、堅牢なインデックスがサポートされるが、読み書きにおいて、たくさんの seek が生じるため、（依然として費用効果が最も高い）磁気ディスク上でのパフォーマンスは低い。

An interesting variant is CouchDB’s append-only B-Trees, which avoids the overhead of seeks at the cost of limiting CouchDB to one write at a time.

面白い使い方は、CouchDB の append-only B-Trees であり、CouchDB からの書き込みを1回に制限するという犠牲を払って、seek によるオーバーヘッドを回避する。

Conclusion

The NoSQL movement has exploded in 2009 as an increasing number of businesses wrestle with large data volumes.  The Rackspace Cloud is pleased to have played an early role in the NoSQL movement, and continues to commit resources to Cassandra and support events like NoSQL East.

NoSQL conference announcements and related discussion can be found on the Google discussion group.

NoSQL ムーブメントは、大量のデータと格闘する企業が増えるにつれて高まり、2009年に爆発した。NoSQL の早期において、Rackspace Cloud は積極的に活動してきた。そして、Cassandra と NoSQL East などのイベントに対して、リソースを提供し続けていく。NoSQL カンファレンスと、それに関連するディスカッションは、Google ディスカッション・グループで参照できる。

ーーーーー

昨日ですが、http://twitter.com/Agile_Cat 上で、” なぜ エコシステムなんだ? ” というディスカッションが、http://twitter.com/okachimachiorz さん、そして http://twitter.com/tatsuya6502 さんとの間になりました。 著者の意図が掴めないのですが、みなさんは どう思います？ ーーー A.C.

＜関連＞
NoSQL Ecosystem とは？ _1
NoSQL Ecosystem とは？ _2
NoSQL Ecosystem とは？ _3
nosql-ja
サーバー保有台数ランキング
Rackspace のクラウド料金体系
ISP とクラウド経済

＜おわり＞

Intel 48 Cores + Hadoop

Futuristic Intel Chip Could Reshape How Computers are Built, Consumers Interact with Their PCs and Personal Devices

SANTA CLARA, Calif., Dec. 2, 2009 – Intel Labs 研究者がデモンストレーションしたのは、48-core Intel プロセッサであり、つまりは、シングルチッ･プクラウド･コンピュータであり、ラップトップや、PC、サーバーなどのデザインで用いられている、現在における数多くのアプローチを再考させるものである。 この未来のチップは、現時点で広く利用されているIntel Core ブランド･プロセッサと比較して、10～20倍の能力のある処理エンジンを内部に持つ。

この研究における長期的なゴールは、まったく新しいソフトウェア･アプリケーションと、コンピュータのマンマシン･インターフェイスをドライブするための、途方も無いスケールを加えていくことである。Intel が来年に計画しているのは、新しいソフトウェア･アプリケーションとプログラミング･モデルの具体的な研究のために、100 個以上の実験用チップを、産業界と教育機関で共有していくことだ。

Intel は、2010 年の前半には、Core ブランド･チップの新しいラインに主要な特徴を統合し、後半には 6-core と 8-core のプロセッサに、それらを導入する。その一方で、このプロトタイプを用いて、1つのシリコン･チップ上に、プログラムを処理できる48個の Intel プロセッシング･コアを取り込んでいく。さらに、 情報共有のための、高速のオン･チップ･ネットワークと、新たに開発されたパワー･マネジメント技術も取り込む。それにより、わずか25ワットから、最大性能時における 125ワットまでの間で、48コアにおける全てをエネルギーを、きわめて効率的に操作できる（今日の Intel プロセッサの消費電力は、標準的な家庭用電球2個分ほど）。

＜中略＞

マルチ･コア･プロセッサのプログラミングは、シングル･シリコン･チップ上の Many Core へ向かう、コンピュータとソフトウェアのメーカーにとって、重要なチャレンジとして認識されている。 このプロトタイプが実現するのは、一般的で効果的な並列プログラミングのアプローチであり、クラウド･データセンターのソフトウェアで用いられ、このチップに適用されるものとなる。

こんな画面も、Youtube の動画でチラッ見られますよ～～～

Intel／HP／Yahoo の Open Cirrus コラボレーションからの研究者により、この 48 IA コアチップへのクラウド･アプリケーションのポートが始まっている。それは、Java framework を用いる Hadoop であり、Rattner が証明しているような、データ･セントリッな分散アプリケーションをサポートしている。 

詳しくは、↓ こちらで ど～ぞ。
http://www.intel.com/pressroom/archive/releases/2009/20091202comp_sm.htm

この実験に Hadoop が使われることが、とても自然に思えます。 Many Core の活躍の場を、Hadoop が作っていくと言っても過言ではないでしょう。 －－－ A.C. 

<関連>
Nehalem と仮想化

Overview of Hadoop Conference 2009 in Japan – English Edition

A Big Day Of  Yellow Elephant In Tokyo

Nov, 13, 2009 – The first Japanese Hadoop Conference was taken place in the center of Tokyo with Christophe Bisciglia of Cloudera.

 

Opening : Toru Nishikawa of Preferred Infrastructure

At first, a president of Preferred Infrastructure Toru Nishikawa talked about the entrance of Hadoop to over 200 audiences, as a pre-conference session.

Key Notes : Kazuki Ohta of Preferred Infrastructure and Christophe  Bisciglia of Cloudera

Kazuki came just back form the new type of influenza just before of this conference, however strongly, triggered the starting of big day in Japan. After that, Christophe talked about the now and then of Hadoop, following the essence and background of yellow elephant descriptions. He explained the current disadvantage of Hadoop honestly, and mentioned about the future advantage of one powerful. The almost of audiences felt his confidences coming from the success in New York, I trust. Actually, the needs for Hadoop he demonstrated means very real matters, such as  Yahoo, Facebook, Amazon, eBay, China telecom, KDDI, NTT, openPDC, VISA, JP Morgan and in Biogenetics.

In addition, he touched with Sqoop and Cloudera Desktop. The first one provides the data transformation from RDB to Hadoop, and will provide the appropriate migrate way to large volume of data processing. Meanwhile, Cloudera Desktop will the usability and manageability to Hadoop customers who live in the outside of IT development fields. Even if scientists, they will be able to build Hadoop application without to touch with MapReduce portion, Christophe said.

At the end of this session, He showed the rapid growth of Hadoop that demonstrated by numbers of Hadoop downloads and inst rations.

Keisuke Kawamura and Shuhei Nishioka of Rakuten

Rakuten is a major Japanese Web retail shop and has to deal with the growing of 20000 IDs per day. Thus, they want to have the scale elastic environments including Hadoop framwork for the large volume of data processing.   In orther hand, the company owns their original framework named Roma for the large volume of data management. In this session, there was the lecture of k-means overview, I interested.

Shinji Tanaka of Hatena

Hatena means the large and sophisticated Japanese SNS including advanced RSS services and so on.  They are in the research period and focus on utilizing Scala instead of and collaborate with Java.  As a functional language for Hadoop running of Java VM, they try to use Scala and develop a library for the purpose.

Tsutomu Okura of Blogeye and Yoshinobu Masatani of NTT Data

I describe two of different sessions into same paragraph, because of, these are two sides of the same coin. Tsutomu talked about the advantage of Elastic MapReduce in aspects of ease and economical matters, after the demonstration of Japanese Wikipedia analysis within Amazon AWS.  In other hand, NTT Data explained the advantage with Japanese large system integrator, except add-hock uses of Hadoop. However, eHarmony runs Elastic MapReduce everyday, actually.  What will be happened in here, I’m interesting in.

Mikio Yanashita of Net One Systems USA

It’s a great reports of Hadoop World in New York City last October. Mikio reported topics of application track in NY, such as results of Yahoo, China Telecoms and so on, mainly. Whole of topics demonstrated the scale and reliance of Hadoop. He added topics of Hadoop stove league in Silicon valley such as Doug Cutting’s changing seat.  How many Japanese engineers will go to there though his connection, I’ve just considered.

Nobuya Matsuoka and Yasuko Komiyama of Telanium.

In this company, for instance, mail access analysis has been addressed with NoSQL approach, Nobuya said. To avoid the expensive SAN, they tried to use Voldemort, Cassandra and HBase. After the experimentation period, they proceeded some of researches and developments with HBase. In this session, Yasuko gave some of technique including HBase scheme design, optimizing of table size and so on to audiences. Thanks to Telanium!

Closing : Christophe  Bisciglia of Cloudera and Atsushi Nakada of Nikkei Computer

Christophe came back on the stage, and gave details of recent "Cloudera Distribution for Hadoop" and thanks message to audiences. Atsushi explained what’s MapReduce and Hadoop, and concluded the position of Hadoop that means "democratization of MapReduce".

—- Reported by Agile Cat

速報 ： Hadoop Conference 2009 Tokyo レポート

簡単でスミマセンが、とりあえずの報告です

 

2009 年の 11 月 13日に、東京の外苑前にある TEPIA で、日本では初の Hadoop カンファレンスが、Cloudera の Christophe  Bisciglia さんをゲストに招いて開催されました。私にとって痛恨だったのは、当日になってプレ･カンファレンスに気づいたことで、西川さんが登壇されたとのことですが、それを聞き逃してしまったことです。

Web には、「 Haoop 入門（背景と利点）」となっていて、本カンファレンスのテーマとなっているオープンソースソフトウェア Hadoop の生まれた、背景・概要・利点などが紹介されたはずなので、とても残念な出だしとなってしまいました。

Cloudera ： Christophe  Bisciglia さん

本カンファレンスでは、太田さんのショート･スピーチから、Christophe さんにバトンタッチされ、Cloudera から見た Hadoop の概要というか、意義と背景、そして過去･現在･未来が語られました。 私の印象は、10月 2日のニューヨークでの時点から、着実に進歩しているなぁというものであり、ニーズとの結びつきについて、その説明に力強さが加わっていると感じられました。おそらく、ニューヨークでの成功に裏付けられた自信が、その背景にあるのだと思います。

その中でも、興味を引かれたのは、Sqoop という、RDB からデータをインポートして、Hadoop クラスターにエクスポートする概念で、これは Aron Kimball さんが、中心になって進めているプロジェクトとのことです。 Hadoop は RDB の市場を、その全てというわけではありませんが、着実に取りにいっていますね。

それと、Cloudera Desktop も面白そうです。 これは、Web を介して Hadoop を操作し、管理するためのデスクトップ製品であり、Hadoop 利用者の裾野を広げるという目的を持っているようです。 もちろん オープンソースです。

それと、Hadoop のどの部分をウィーク･ポイントとして捉え、どのように改善していくのかという話も面白かったです。 商用ソフトウェアと比較して、この辺りをアッケラカンとしゃべれるのが、Cloudera の強みだと思います。

そして、目覚しい勢いで伸びているダウンロード数と、インストール数がグラフで示され、また、超一流企業がユーザーとなっている状況も説明されました。 前回と比べて目新しかったのは、スマート･グリッド関係です。

楽天： 河村さん、西岡さん、

楽天では、毎日 20万 ID が増えているそうで、それに対応する柔軟なアーキテクチャを作るという目的の一環で、Hadoop が試験運用されているとのことです。 有名な ROMA はデータ管理のために、そして Hadoop はデータ処理のためにと、使い分けられるようです。まぁ、とにかく膨張していくデータを、どうすれば有効に使いこなせるかという販売業における王道を、Hadoop で何とかしようという熱意が伝わってきました。 この辺りで、スピーカーが西岡さんに切り替わり、テクノロジーについて、さらに深彫りしていく展開となりました。私として、一番うれしかったのは k-means の説明です。 もやもやしていたものが、とてもスッキリしました。 有難うございます！

はてな ： 田中さん－－－ blogeye.jp ： 大蔵さん －－－ NTTデータ ： 政谷さん

はてなでも、毎日のように数GB 単位で蓄積されるログを、いかに活用するかという点で Hadoop に期待し、また、すでに実証実験を開始しているとのことです。 そして、Java VM 上で利用できる関数型言語として Scala を利用している状況が説明されていました。ポイントは、Java と Scala を接続するためのライブラリとのことで、その開発に注力されているようでした。

大倉さんのセッションでは、Amazon の Elastics MapReduce を利用することで、簡単かつ低コストで Hadoop が利用できるという現状が説明されました。政谷さんのセッションでは、大手システム･インテグレータだからこそ可能な、Hadoop の活用方法が説明されました。 大量のデータを Hadoop で、アドホックに処理するなら Amazon がありますが、恒常的に利用するなら大手システム･インテグレータにお任せくださいという視点です。 この辺りの、Hadoop の運用方法は、とても興味深い領域です。 なにしろ、アメリカにおけるアドホック利用では、IBM ですら Amazon を使っているという現状があるからです。

Net One Systems USA ： 柳下さん

10月の Hadoop World New York の報告が行われました。 主に、アプリケーション･トラックからのトピックが中心であり、 Yahoo や China Telecom における、Hadoop の運用規模を中心に説明が行われました。 ただ、一番受けていたのは、シリコンバレーでは Hadoop のエンジニアが引く手あまたであり、私に相談してくれれば、無償で紹介しますよというくだりでした。 確かに、Doug Cutting が Yahoo から Cloudera に移籍したりと、かなりダイナミックに人材が行き来しているようですが、なんか 仲良くやってほしいなぁという気がしました。

Telanium.Inc ： 松岡さん、小宮山さん

かなり前から、Telanium さんではメールのアクセス解析などで、NoSQL に取り組んできたそうです。 SAN は高くつくのでという理由からですが、Voldemort や Cassandra なども評価した結果、HBase に白羽の矢を立てて、研究と開発を進めてきたとのことです。一概に Key-Value ペアと言っても、実際に動かしてみるとクセがあるようで、そこから得られた HBaseのスキーマ設計時の注意点や、テーブル･サイズの最適化などが語られました。

クロージング

Cloudera ： Christophe  Bisciglia さん －－－ 日経コンピュータ ：中田さん

再び登壇した Christophe さんから、最近の Cloudera Distribution for Hadoop に関する説明がありました。 そして、オーディエンスへの Thanks メッセージも印象的でした。 中田さんからは、Yahoo における Hadoop 運用が、いま流行のコンテナ･データセンターで行われているという説明と、Google で生まれた MapReduce を、誰もが利用できるように「民主化」するものが Hadoop なのだという、力強いメッセージがあり、全セッションが完了しました。

ーーー

セッションが終わって、半数くらいの方々が懇親会に参加されました。 Twitter ではお馴染みでも、会って話すのは初めてという方が多く、期待していたとおりの楽しいパーティとなりました。みなさん、有難うございました。 －－－ A.C.

＜めちゃ関連＞
楽天の河村さん：Hadoop Conference Japan 2009に参加しました
This is ARAKI’s daily notes 前半 後半

＜関連＞
Hadoop World 2009 レポート
Hadoop Conference Japan 2009 が、もう満員だって！
北京でも Hadoop World を開催
台湾でも Hadoop World を開催
Hadoop World Report：優良企業はなぜ Hadoop に走るのか
Hadoopが秘める可能性：オンプレミスでもクラウドでも使えるプラットフォームの魅力
Hadoopの最新動向を「Hadoop World:NY 2009」の資料から