Scalability of the Hadoop Distributed File System _3
Yahoo! Developer Network Blog
May 5, 2010
http://developer.yahoo.net/blogs/hadoop/2010/05/scalability_of_the_hadoop_dist.html?
Reasonable Load Expectations
We have learned by now that the name-node can use 70% of its time to process external client requests. Even with a handful of clients one can saturate the name-node performance by letting the clients send requests to the name-node with very high frequency. The name-node most probably would become unresponsive, potentially sending the whole cluster into a tailspin because internal load requests do not have priority over regular client requests.
これまでに、外部クライアントのリクエストを処理する時間の 70％ を、Name-Node が使えるを学んできた。 ただし、ひと握りのクライアントを用いるときでさえ、クライアントから Name-Node へ向けて極端な頻度でリクエストを送信すると、Name-Node は飽和してしまうだろう。 内部に負荷をもたらすリクエストが、クライアントからの一般的なリクエストに対して優先されないと、大半のケースにおいて Name-Node は反応を失い、クラスタ全体を急速に劣化させる可能性を生じる。
In practice, the extreme load bursts are uncommon. Regular Hadoop clusters run MapReduce jobs, and jobs perform conventional file reads or writes. To get or put data from or to HDFS, a client first accesses the name-node and receives block locations, and then directly talks to data-nodes to transfer file data. Thus the frequency of name-node requests is bound by the rate of data transfer from data-nodes.
現実的に見て、極端な負荷によるバーストは一般的ではない。 通常の Hadoop クラスタは MapReduce のジョブを実行し、それらのジョブが標準的なファイルの Read／Write を行う。 HDFS を相手にデータの送受信を行うために、クライアントは最初に Name-Node にアクセスし、ブロックのロケーションを受け取り、続いて、ファイル・データを転送するために、Data-Node とダイレクトに交信する。したがって、Name-Node におけるリクエストの頻度は、Data-Node からのデータ転送のレートにより拘束される。
Typically a map task of a MapReduce jobs reads one block of data. We estimate how much time it takes for a client to retrieve a block replica and, based on that, evaluate the expected read load on the name-node — namely, how many “get block location” requests the name-node should expect per second from 100,000 clients. We apply the same technique to evaluate the write load on the cluster.
典型的な MapReduce ジョブのマップ･タスクは、1つのデータ･ブロックを読み込む。
私たちは、クライアントがブロック･レプリカを取得するために、費やす時間を見積もることができる。そして、それに基づいて、Name-Node 上での読み取りの負荷を評価する。 つまり、Name-Node が想定すべき、1秒あたりの "get block location" リクエスト数を、10,000 クライアントを前提として予測することになる。クラスタにおける書き込みの負荷に対しても、同じテクニックで評価できる。
Performance Limitations
The read and write throughputs have been measured by the DFSIO benchmark and are summarized in Table 3.
この read／write に関するスループットは、Table 3 に示されるように、DFSIO ベンチマークにより測定されている。
Another series of throughput results produced by NNThroughputBenchmark (Table 4) measures the number of open (the same as get block location) and create operations processed by the name-node per second:
NNThroughputBenchmark （Table 4）により生成される、もう 1つのスループットは、Name-Node により 1 秒ごとに処理される、ブロックのオープン（get block location と同じ）と作成に関する頻度を測定している。
The read throughput in Table 3 indicates that 100,000 readers are expected to produce 68,750 get-block-location requests to the name-node per second. And Table 4 confirms that the name-node is able to process that many requests even if only 70% of its processing capacity is dedicated to this task.
NNThroughputBenchmark （Table 4）により生成される、もう 1つのスループットは、1 秒ごとに Name-Node により処理される、ブロックのオープン（get block location と同じ）と作成に関する頻度を測定している。Table 3 における read スループットによると、100,000 reader が Name-Node に対して、1秒あたり 68,750 回の get-block-location リクエストを発行すると予測される。 そして Table 4 では、このタスクが占有する処理容量の 70% であっても、Name-Node が数多くのリクエストを処理できることが確認される。
A 10,000 node HDFS cluster with the internal load at 30% will be able to handle an expected read-only load produced by 100,000 HDFS clients.
30％ の内部負荷を伴なう 10,000ノードの HDFS クラスタは、100,000の HDFS クライアントが生じる read-only の負荷を処理できるだろう。
The write performance is not as optimistic. According to Table 3, 100,000 writers are expected to provide an average load of 41,667 create block requests per second on the name-node. This is way above 3,920 creates per second — 70% of possible processing capacity of the name-node (see Table 4).
書き込みのパフォーマンスに関しては、楽観できない。 Table 3 によると、100,000 writer が Name-Node に対して、1 秒あたり 41,667 回の create-block リクエストを、平均として発行すると予測される。 つまり、Name-Node の処理容量の 70% に相当する、毎秒3,920 回の生成を上回ることになる（参照 Table 4）。
A reasonably expected write-only load produced by 100,000 HDFS clients on a 10,000 node HDFS cluster will exceed the throughput capacity of a single name-node.
10,000のノードの HDFS クラスタにおける、100,000 の HDFS クライアントが生成する write-only の負荷については、単一の Nme-Node のスループット容量を超えると予測すべきだろう。
We have seen that a 10,000-node HDFS cluster with single name-node is expected to handle a workload of 100,000 readers well. However, even 10,000 writers can produce enough workload to saturate the name-node, making it a bottleneck for linear scaling.
私たちが確認してきたことは、単一の Name-Node を持つ 10,000ノードの HDFS クラスタが、100,000 reader のワークロードを適切に処理するだろうというものだ。 しかし、10,000 writer のケースでさえ、単一の Name-Node を充分に飽和させるワークロードを生成するため、リニアなスケールにボトルネックを生じる。
Such a large difference in performance is attributed to get-block-locations (read workload) being a memory-only operation, while creates (write workload) requires journaling, which is bounded by the local hard drive performance.
このような、パフォーマンスにおける大きい相違は、get-block-locations（read workload）が memory-only 操作であるのに対して、create（write workload）がローカルな HDD の性能に拘束される journaling を要求することに起因する。
There are ways to improve the single name-node performance. But any solution intended for single namespace server optimization lacks scalability.
単一の Name-Node におけるパフォーマンスを、改善する方法は存在する。 しかし、単一の名前空間サーバーの最適化を意図する、あらゆるソリューションはスケーラビリティを失う。
Looking into the future — especially taking into account that the ratio of small files tend to grow — the most promising solutions seem to be based on distributing the namespace server itself both for workload balancing and for reducing the single server memory footprint.
前向にいこう。 とりわけ、小さなファイルの比率が、増大していく傾向にあることを考慮に入れよう。 最も有望なソリューションは、ワークロードのバランスを取り、シングル･サーバーのメモリ･フットプリントを低減する、名前空間サーバー自体を分散していくという、方式に基づいて達成されると思われる。
I hope you will benefit from the information provided above. Please refer to the USENIX ;login: article for more details.
ここで提供した情報から、メリットが得られることを希望する。 詳細に関しては、 USENIX ;login: の記事を参照してほしい。
ーーーーー
Konstantin V. Shvachko
Hadoop Distributed File System (HDFS) Team, Yahoo!
ーーーーー
＜関連＞
HDFS のスケーラビリティを考察する _1
HDFS のスケーラビリティを考察する _2
HDFS のスケーラビリティを考察する _3
ーーーーー
Hadoop DFS _ Introduction
NoSQL Ecosystem とは？ _1
