JobTracker HA

本日 CDH4.2 がリリースされました(リリースノート)が、その中の目玉機能としてあげられるのが
JobTracker HA
でしょう。

従来 Hadoop には、下記の SPOF (単一障害点)があると言われていました。
1. NameNode
2. JobTracker

1.に関しては、昨年NameNode HAが公開され解決していたのですが、今回のリリースで2.も実現されたことになります。
JobTracker HAはNameNode HAと同様にActive-Standby構成をとり、QJMやZKFCを利用しています。

詳細は下記リンクを参照して下さい。
https://ccp.cloudera.com/display/CDH4DOC/Configuring+High+Availability+for+the+JobTracker+%28MRv1%29

JobTrackerはNameNodeのようなメタ情報を持たないため、最悪障害発生時時にはJobTrackerを再起動してジョブを投入できたのですが、数時間かかるジョブのやりなおしは避けたいものです。このような機能が必要に応じて選択できるのは喜ばしいですね。

続)Cloudera Impala 情報 (15)

Impala情報 2013/2/26版

ニュース

impala-user MLにアーキテクチャーの話が流れていたので、取り急ぎ貼っておきます
(https://groups.google.com/a/cloudera.org/forum/?fromgroups=#!topic/impala-user/0NrhG3tE_Fw)

> Is there any difference in the way Impala reads HBase as compared to
> Hive/Hadoop?

Yes, reading from hbase involves the hbase client API; reading from
hdfs is done via libhdfs.

> Does the partitioned join that is going to be supported need the joining
> partitions to be co-located on a node?

No.

> Is it possible to implement an equivalent of reduce-side/ repartition join
> in Impala?

That will be supported in GA at the latest.

> Would it not be possible to sort a large table with Impala? I see that every
> ORDER BY clause needs to have a LIMIT specified.

Not at this point.

> How does Impala keep track of data locality? Does it collect the information
> from HDFS namenode and HBase metadata server?

It talks to the hdfs namenode.

> Does a task always get scheduled on a data local node? If yes, how does
> Impala prevent hotspots?

Impala tries to run scans locally, if at all possible. It makes not
attempt to avoid hot spots at the moment.

> Since Impala doesn’t materialize results on disk, is there a limit on the
> size of output?

The final output of the query is streamed back to the user, and only
needs to be materialized in memory for blocking operators (GROUP BY,
ORDER BY … LIMIT). In other words, if the query doesn’t contain such
blocking operators, there is no limit on the size of the result set,
otherwise it’s limited by the available main memory on the node to
which the query was submitted.

> What is the scheduling policy to schedule multiple queries in a Impala
> cluster?

Each of the impalad process can accept client requests, and requests
should be submitted to them in a round-robin fashion.

HDFSのfsimageとeditsの変更

HadoopのHDFSでは、NameNodeと呼ばれるノードがメタデータをディスク上に記録します。Hadoopのバージョンが上がりこれらのファイル名(と意味合い)が変更されていますが、象本3版(英語)にも反映されていません。

CDH3とCDH4における変更点を簡単にまとめてみました。
間違いがあれば指摘して下さいませませ。

http://www.slideshare.net/kernel023/hdfs-fsimage-and-edits-in-cdh3cdh4

OOM Killerが盛り上がっている

なぜかtwitterのTLでOOM Killer が空前の盛り上がり。
#OOM Killerたんって、、、何?(笑

その中にOOM Killerの解説についてのツイートがあったので少し紹介。
http://lwn.net/Articles/104179/

An aircraft company discovered that it was cheaper to fly its planes
with less fuel on board. The planes would be lighter and use less fuel
and money was saved. On rare occasions however the amount of fuel was
insufficient, and the plane would crash. This problem was solved by
the engineers of the company by the development of a special OOF
(out-of-fuel) mechanism. In emergency cases a passenger was selected
and thrown out of the plane. (When necessary, the procedure was
repeated.) A large body of theory was developed and many publications
were devoted to the problem of properly selecting the victim to be
ejected. Should the victim be chosen at random? Or should one choose
the heaviest person? Or the oldest? Should passengers pay in order not
to be ejected, so that the victim would be the poorest on board? And
if for example the heaviest person was chosen, should there be a
special exception in case that was the pilot? Should first class
passengers be exempted? Now that the OOF mechanism existed, it would
be activated every now and then, and eject passengers even when there
was no fuel shortage. The engineers are still studying precisely how
this malfunction is caused.

駄文ですが翻訳してみました。

ある航空会社では、格安で飛行機を飛ばすために、より少ない燃料を飛行機に搭載しておけば良いことを発見しました。飛行機がより軽くなり、燃料の使用量が少なくなり、費用が抑えられるようになります。しかし稀なケースですが、燃料が十分な量ではない場合には飛行機は墜落してしまいます。
この問題は、特別なOOF(燃料不足:Out of fuel)メカニズムを開発したエンジニアによって解決されました。緊急時には、乗客の一人が選択され、機体から外に放り出されます(必要があればこの処理が繰り返されます)。
この理論が大規模に開発され、犠牲者が適切に選択されたのかどうか、という問題について多くの論文が発表されました。
・犠牲者はランダムに選ばれるべきか?
・最も重い一人を選ぶべきなのか?
・それとも最年長者を選ぶべきか?
・乗客は放り出されないために代金を支払うべきだが、その中で最も貧しい乗客が犠牲者とされるのか?
・さらに、もし最も重い乗客が操縦士であった場合、特別な例外はあるのか?
・ファーストクラスの乗客は免除されるべきなのか?

現在この OOFメカニズムが存在しており、時々稼動しています。そして燃料が不足していない場合にさえも乗客を放り出しています。エンジニアは、この誤動作がどのように発生しているかを未だに学習しています。

kernel3.7.6でのoom killerのコードはこちら。最悪なプロセスを選ぶ badness()。ヒューリスティックってところが素敵(笑
http://lxr.linux.no/linux+v3.7.6/mm/oom_kill.c#L175
/**
175 * oom_badness – heuristic function to determine which candidate task to kill
176 * @p: task struct of which task we should calculate
177 * @totalpages: total present RAM allowed for page allocation
178 *
179 * The heuristic for determining which task to kill is made to be as simple and
180 * predictable as possible. The goal is to return the highest value for the
181 * task consuming the most memory to avoid subsequent oom failures.
182 */
183unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg,
184 const nodemask_t *nodemask, unsigned long totalpages)
185{
(略)

余談
kernel2.4系に含まれていた、スケジューラで最良のプロセスを選択する goodness()。
このアルゴリズムは男らしいと思う。(笑

http://lxr.linux.no/linux-old+v2.4.31/kernel/sched.c#L144

/*
131 * This is the function that decides how desirable a process is..
132 * You can weigh different processes against each other depending
133 * on what CPU they’ve run on lately etc to try to handle cache
134 * and TLB miss penalties.
135 *
136 * Return values:
137 * -1000: never select this
138 * 0: out of time, recalculate counters (but it might still be
139 * selected)
140 * +ve: “goodness” value (the larger, the better)
141 * +1000: realtime process, select this.
142 */
143
144static inline int goodness(struct task_struct * p, int this_cpu, struct mm_struct *this_mm)
145{
146 int weight;
147
148 /*

Posted in Uncategorized