hadoop-mesos
mesos と hadoop を組み合わせて利用しようとすると，JobTracker/TaskTracker を書き換える必要があるという問題があった．書き換えた版はmesos 以下のレポジトリに公開されているけれども，コミュニティが開発した最新版を利用する際には rebase してコンパイルする必要があった．
ところが，最新 mesos では hadoop-mesos という jar ファイルを置くだけで起動ができてしまうらしい(@Guutara さんに教えてもらった)．
https://github.com/mesos/hadoop
hadoop-mesos は一言で言うと mesos ドライバである．パッチを当てる必要がなくなったカラクリは以下の通り:
- org.apache.hadoop.mapred.TaskScheduler の継承して mesos 用に改変．これにより，実装コストを抑えつつ JobTracker 本体へパッチを当てることを防止している．起動は無改変の JobTracker と同様人手で行うが，その際に mesos すり替えた版が起動する．
- TaskTracker は mesos ドライバからランタイムに起動する．
hadoop-mesos が動作する前提として，TaskScheduler.java/TaskTracker.java のインタフェースが変わらないことが挙げられる．
雑感
hadoop-1.x 系を利用する場合であれば，以降そんなに大きな変更が加わることもないだろうから，合理的な設計だと思う．hadoop-2.x 系や JobTracker-HA に対応させようとすると結構しんどそうである．
HADOOP-10000
Apache Hadoop の hadoop-common のチケット数が10000を超えたみたい． なお，10000のチケットは HttpServer log link is inaccessible in secure cluster． https://issues.apache.org/jira/browse/HADOOP-10000
Llama - Low Latency Application MAster
http://cloudera.github.io/llama/
Cloudera のエンジニア達が，Impala の YARN 対応させる上で必要な機能を足したのが llama とのこと． あとで技術的詳細をかく．
HDFS-4953(mmap(2) を用いたローカル読み込みの高速化)について
HDFSが高速に？mmapによるzero-copyでの読み込みにて，id:kawamon さんが，HDFS-4953 のチケットについてコメントをしていた．Hadoop の処理は，IO した後の Java のオブジェクト生成などが原因で CPU ボトルネックになりやすい．よって，この手のCPUコストを削減するための高速化手法は頻繁に使われるようになるだろう．
ところで，mmap(2) について1点，気になる話を教えてもらったのでまとめておく．CentOS 5 のような古い OS では，ページフォールトハンドラがmmap用のセマフォを保持したまま IO を発行してしまう*1．mmap 用のセマフォを保持したまま IO を発行してしまうと，その間に発生した全てのページフォールトが IO 待ちになってしまい，結果非常に動作が重くなる．もっとも，最近のカーネルだとロックをリリースした後にしてくれるので，関係ないのだが，CentOS 5 上で上記の機能は利用しない方が良い．該当機能をオフにするには，dfs.client.mmap.cache.size を 0 に設定すれば良い．
*1:http://lwn.net/Articles/200215/
ZKFC のドキュメントまとめ
ZooKeeper Failover Controler に関して記述しているドキュメント一覧．一番上のドキュメントを抑えておけば，趣旨，アーキテクチャ，故障時の挙動に関しては(設計レベルで)理解できる．実際の挙動については，今のところコードを読むしかない．
