Agile Cat — in the cloud

Agile_Cat 的、今年最大の発見とは?

Posted in .Chronicle, James Hamilton, NoSQL by Agile Cat on December 31, 2009

ぜんぜん速くならないランダム・アクセス

ハードウェアは解らないし、あまり書く機会もない Agile_Cat ですが、この 20数年の間に、HDD のランダム・アクセスが殆ど速くなっていないという事実には、かなりビックリしました。 以下のグラフは、師匠とお呼びしたいほど敬愛しております、James Hamilton 氏の ISCA 2009-PDF からのもので、同氏と Dava Patterson 氏による調査の結果と記載されています。

HDD Speed 

シーケンシャルの方はといいますと、ご覧のとおり、この間に100倍以上のパフォーマンス向上が達成されています。 HDD というハードウェアの構造上の問題なのかとも思いますが、SSD になったからとして、いきなり変わるものでもなさそうです。

SSD Speed

これは、自分のノート PC にインストールした SSD と、メインのデスクトップで使っているHDD の、read/write 速度の比較です。 1.8インチと 3.5インチという違いがありますが、4k ブロックの write では、反対に SSD の速度が低下しているという状況です。

もちろん、eBay の最安値を狙って、Agile_Cat が 2年ほど前に購入したものと、最新の SSD では、その間に大きな進歩があるのでしょう。 しかし、それにしても、たとえば Hadoop が見せつけた、RDB に対するケタ違いの能力差と比べると、SSD によるパフォーマンスの向上は微々たるものとなってしまいます。

そして、ランダム・アクセスの速度が向上しない状況と、SSD が(それほど)効果的なソリューションとならない状況を合わせると、ますます RDB は不利になり、その反対に、ハードウェアの進歩という追い風を受ける NoSQL は、その真価を発揮するようになっていくのでしょう。

・・・ とは言え、クラウド・ビジネスの 2010年における最初の主戦場は、Azure 対 Salesforce になりそうな気配です。 どちらも、既存のソリューションを、そのままクラウドへというスタンスのビジネスを推進しています。 もちろん、それも重要な視点であり、IT 全体の進化にとって不可欠な要素ですが、このようなデータを見ると、いずれは RDB が、Next Legacy の代名詞になるような気がしてならないのです、、、と 大晦日になっても考えています。。。

そんなこんなで、今年の Agile_Cat も、これが最後のポストとなります。 そして、この一年を振り返ってみると、この James が提示してくれたグラフが、ずっと意識の底にあり、そこを起点にして、あらゆる事象を眺めてきたような気がします。

ーーー

今年は、たくさんの方にアクセスしてもらえて、ほんとうに嬉しかったです。 有難うございました。そして、来年も よろしくお願いしま~~~す。

では、みなさん、良いお年をお迎えください。 ーーー A.C.

<関連>
役割を減じる Cloud での RDBMS

Agile_Cat 2009 – Top 10

Posted in Research by Agile Cat on December 30, 2009

Hadoop が上位を占めた 2009!

AC

ついに、Database Sharding が最後まで逃げきってしまいました。 これには、とにかく 驚きです! 多くの人が、RDB の限界に気づき、その視点から情報を追いかけてきた結果だと思います。 それと、一連の Hadoop 関連のポストにも驚きです。正直言って、こんなにも、Hadoop が人気者だとは想像すらしませんでした。

その中でも、” Overview of Hadoop Conference 2009 in Japan ” は初めての英語のポストで、ハドゥカンが終わった直後に、眠い目をこすりながら書いたという記憶があります。お恥ずかしながらという英語ですが、この後から http://twitter.com/Agile_Cat で、海外からの Follower さんが急に増えたりして、結果としては良かったと思っています。

それと、驚いたのは、” NoSQL Ecosystem とは? ” が 7位に入ったことです。 このポストが、12月 10日前後だったことを考えると、これは大変な勢いです。 間違いなく、2010 年の注目すべき領域となるでしょう。

  1: Database Sharding _1
  2: Hadoop : Twitter よ、お前もか!
  3: Hadoop World 2009 レポート
  4: 速報 : Hadoop Conference 2009 Tokyo レポート
  5: PDC 2009 セッションが発表に!
  6: Overview of Hadoop Conference 2009 in Japan
  7: NoSQL Ecosystem とは? _1
  8: Hadoop Conference Japan 2009 が、もう満員だって!
  9: ITIL V2 は消えてしまうのか?
10: Hadoop DFS Architecture_3

ご覧のように、Agile_Cat 2009 Top 10 は、Database Sharding と、Microsoft、NoSQL、そしてシブイところで ITIL が、それぞれ 1つずつありますが、その他はすべて Hadoop 関連となりました。さて、来年は、どのような展開になるのでしょうか? ーーー A.C.

Agile_Cat 2009 – Top 11~20

Posted in Research by Agile Cat on December 29, 2009

Google のスケール感覚が目立った 2009!

AC

以下のリストで思い入れがあるのは、なんといっても ”Google 的 クラウド連携の ABC ?” です。 これは、Google I/O のビデオから起こしたもので、けっこう時間をかけて Visio で作ったのですよ~~~。 おそらく、今年の Agile_Cat の中では、もっともマクロな視点を提供しているポストかと思います。 これに関連するものとしては、” Google は 1000万台のサーバーを目指す ? ” がありますが、もう少し調べたいと思いつつ、今年はできませんでした。

それと、” Windows Azure MapReduce Demo ” も、Simon さんとのやりとりの後に出てきただけに、とても嬉しいポストとなりました。 実は、”Hadoop が Microsoft の教材に?” を見て、彼にメールを送ったら、この Web キャストが出てきたので、ひょっとしらモチベーションの一部になったのかとも思っています。Azure+MapReduce というキーワードは、とにかく Agile_Cat 的には大満足でした。

なお、” AppFabric とは?” は順当な結果で、” David Chappell のヒミツ ” では、David さんの知られざる一面がご披露されています。 未読の方は、ぜひ、ど~ぞ。それと、”サーバー保有台数ランキング” も面白いですよ ~~~。

11: Google 的 クラウド連携の ABC ?
12: エンタープライズ RDBMS を Hadoop で補完 _2
13: Hadoop DFS _ Introduction
14: Hadoop DFS Architecture _7
15: Windows Azure MapReduce Demo
15: サーバー保有台数ランキング
16: HP のコンテナ・データセンター
17: Database Sharding _3
18: エンタープライズ RDBMS を Hadoop で補完 _1
19: AppFabric とは?
20: David Chappell のヒミツ

明日は、いよいよ Top 10 です。 おそらく、みなさんが エッエエ~~~ と思う結果になるでしょう。 ぜひ、ご覧ください。

Agile_Cat 2009 – Top 21~30

Posted in Research by Agile Cat on December 28, 2009

今年のランキング情報で、2010 を占おう!

AC

Amazon、Google、Microsoft の御三家が、それなりにランキングをシェアしていて、そこに Hadoop 関連の情報が混ざるという、Agile_Cat らしい展開です。 ”Hadoop が Microsoft の教材に?” は、Simon Guest さんの資料から抽出したものですが、とても面白いコンテンツになりました。 夏の TechED US で、彼は、Hadoop とか、MapReduce とか、おぉっ! と思う内容に触れ始めました。このポストと、”Azure White Paper の SDS 部分が改変” には、http://twitter.com/nsharp_2ch さんの貴重なコメントがついていますので、ぜひ、ご参照ください。

”Amazon のプライベート クラウド” と ”Google Data Center を YouTube で!” も、それぞれが 2009 という年を象徴するコンテンツだと思います。 なお、YouTube での紹介は ”Google Data Center を YouTube で!” の方が画像が見やすいです。 それと、”Hadoop とベンチマーク” は ス・ゴ・イ です。1TB/分 のソートが可能だという、2009年6月時点での、Yahoo の発表内容をまとめたものです。

21: Hadoop とベンチマーク
22: NoSQL Ecosystem とは? _2
23: 教育機関への Dryad 提供が始まる
24: Azure White Paper の SDS 部分が改変
25: Hadoop が Microsoft の教材に?
26: Google Data Center を YouTube で!
27: Amazon のプライベート クラウド
28: Hadoop DFS Architecture_2
29: Windows Storage Server 2008 とは?
30: Windows Azure Storage の新機能

明日は、Agile_Cat 2009 – Top 11~20 です。 ど~ぞ、お楽しみに。 ーーー A.C.

HBase の構造を考える _1

Posted in NoSQL by Agile Cat on December 27, 2009

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

image

About Me

My Photo

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 の創造的で恵まれたコミッターたちが、その迷路を自在に前後へとナビゲートするにもかかわらず、一貫したイメージを保持することが極めて難しいと認識した。したがって、私はペーパーにスケッチを描くことに決めた。 しれが、以下のものである。

HBase Large

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)にストアされるとき、それらのファイルが実際より小さなブロックに分割されることに気付くだろう。この方式は、大きなデータや小さなでデータを適切に操作するような、システムのコンフィグレーションを可能にするための 1つの領域である。そのことについては、後に触れる。

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 のインスタンスを持つ。 ここまでで、それらの協調動作することだけではなく、例外ルールもあることが分かるはずだ。

<続く>

ーーー

3回くらいに分けて掲載して良く予定です。 ーーー 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

Gartner : Ray Ozzie – Interview 0

Posted in Businesses, Interviews, Microsoft by Agile Cat on December 26, 2009

Gartner Fellows Interview With Microsoft’s Ray Ozzie on Cloud Computing
30 October 2009
Neil MacDonald, David Mitchell Smith
http://www.gartner.com/technology/media-products/reprints/microsoft/172235.html

Gartner RAS Core Research Note G00172235

image

Cloud-based computing will create the biggest discontinuity of the IT landscape since the Internet. We sat down with Ray Ozzie, chief software architect at Microsoft, to discuss his vision for cloud computing, and the impact on enterprise computing and the IT industry.

クラウドベースのコンピューティングにより、Internet が始まって以来、経験したことの無い最大の断層が、IT にもたらされるだろう。 私たちは、Microsoft のチーフ・ソフトウェア・アーキテクトである Ray Ozzie にインタビューを試み、クラウド・コンピューティングおよび、エンタープライズ・コンピューティングと IT 業界への影響について、彼のビジョンを聞き出し、ディスカッションした。

Overview

Cloud-based computing will fundamentally transform how enterprises procure and consume technology solutions. Vendors such as Microsoft, which rely almost exclusively on revenue from traditional shrink-wrapped software, are threatened by the shift, but must embrace the technological and business model discontinuities. At this critical transition point for Microsoft, and nearly a year after Microsoft publicly disclosed its cloud-computing strategy, Gartner Fellows Neil MacDonald and David Smith met with Microsoft Chief Software Architect Ray Ozzie to talk about how Microsoft and the industry have progressed during the past year, and to look ahead at what’s next for cloud computing.

クラウドベースのコンピューティングにより、企業におけるテクノロジー・ソリューションの、入手と消費の方式が根本的に変化するだろう。Microsoft のような企業は、つまり、これまでのパッケージ・ソフトウェアからの収益に大きく依存するベンダーは、こうした大転換により脅やかされるが、テクノロジーとビジネスにおける不連続なモデルは受け入れなくてはならない。 Microsoft がクラウド・コンピューティング戦略を発表してから 1年がたった。この、クリティカルな移行期において、Gartner Fellows である Neil MacDonald と David Smith は Ray Ozzie と会見した。 そして、これまでの 1年間に 、どのように Microsoft と業界が進歩してきたのか、また、クラウド・コンピューティングの先に何を見ているのか、という視点から議論した。

Key Findings

Ozzie’s (and thus, Microsoft’s) vision of cloud computing emphasizes hybrid enterprise/cloud computing, where organizations choose when and where computing takes place locally versus in cloud-based infrastructure, and emphasizes that the on-premises and cloud-based solutions work seamlessly together.

Ozzie と Microsoft のクラウド・コンピューティングに関するビジョンは、エンタープライズとクラウドのハイブリッドを強調するものである。 つまり、ローカルとクラウドをベースとしたインフラストラクチャを、どのような方式で、また、どのようなタイミングで活用するのかという点を、企業が選択できるものである。それは、オンプレミスとクラウドをベースとしたソリューションが、シームレスに機能することを意味する。

As with early encryption issues, Ozzie believes that security and privacy issues will be addressed as the industry matures in a combination of legislative advances, as well as industry cooperation.

セキュリティとプライバシーの問題は、暗号化の問題における初期の頃のように、法的な整備だけではなく、そこに業界での協調が加わり、双方が成熟するにつれて、取り組みが進んでいくと Ozzie は信じている。

Ozzie’s vision for cloud computing includes system infrastructure, an application platform and finished applications being delivered as a service.

クラウド・コンピューティングに関する Ozzie のビジョンには、サービスとして提供される、システム・インフラストラクチャと、アプリケーションプ・ラットフォーム、そして、最終的なアプリケーションが含まれる。

Microsoft is investing in its own data centers because it must in order to provide its consumer-based services. It believes it is helping to lead the industry in providing innovations in data center architectures.

Microsoft はが自身のデータセンターに投資するのは、コンシューマ・ベースのサービスを提供するために、それが必要だからだ。 それにより、データセンターのアーキテクチャにおいて、この業界にインベーションを提供する事になると信じている。

Ozzie believes the future of cloud computing is in the experience delivered via a browser across multiple devices — mobile, PC and TV-type screens — which is a vision he refers to as "three screens and a cloud."

クラウド・コンピューティングの未来は、Ozzie が「3つのスクリーンとクラウド」として参照するビジョンにおいて、つまりモバイル/PC/TV タイプのスクリーンという、マルチ・デバイスをまたいだブラウザにより実現されるエクスペリエンスにあると信じている。

Recommendation

Use this discussion to better understand the vision behind Microsoft’s cloud-based strategy and how it differs from other cloud-based providers.

Microsoft におけるクラウド・ベースの戦略と、他のクラウド・プロバイダーとの違いを理解するために、このディスカッションを使って欲しい。

Table of Contents

Analysis

1.0      Ozzie’s Vision for Cloud-Based Computing
2.0      The Importance of Microsoft Data Centers to Its Vision
3.0      Changes Needed for Developers and Operations to Embrace Cloud Computing
4.0      Addressing the Security Concerns of Cloud Computing
5.0      Beyond Cloud Computing
6.0      Thoughts on Following Bill Gates

ーーーーー

とりあえず、前書きの部分だけですがポストします。かなりのボリュームのインタビューなので、間があくかもしれませんが、4~5 回に分けてポストしていくつもりです。 このインタビューの存在を教えてくれた、http://twitter.com/nsharp_2ch さんに感謝です。 ーーー A.C.

 

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

image

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 の構造を考える _3

Posted in NoSQL by Agile Cat on December 24, 2009

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

image

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 の以前の用法は、充分なパフォーマンスを提供していないことが証明された。 そのファイルは、どのように見えるのだろうか?

HBase_2

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 により、1つずつ順番に処理される。 以下に示すのは、マスター 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" アクセスを可能にする。そして、どのようにインスタンスは配置されるのだろうか?

HBase_3

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

%d bloggers like this: