Node-level aggregation の概要

本投稿は Hadoop Advent Calendar 25日目(#hadoopAC12jp)です．現在投稿中のパッチである MAPREDUCE-4502 の内容の日本語資料がないのに気づいたので，その説明をします．

現在取り組み中のパッチの内容

Node-level aggregation は，MapTask 毎に部分集約(Combine処理)を行うための機能です．従来の Combine 処理よりも広い範囲で適用できるため，より高速な処理が可能となります．

設計

MRAppMaster が各ノードを調停して，MapTask にNode-level aggregation を開始するように指示します．Combine 処理は重いので，処理によっては Combine 処理によるデータの圧縮効果よりもオーバヘッドの方が大きくなってしまう場合があります．そこで，現在の設計では，しきい値を超えたら Node-level aggregation を開始するようにしています．また，耐故障性も担保できるように設計しています．

改造箇所

1. Mapper
2. Reducer
2. MRAppMaster(JobTracker)
3. Mapper-MRAppMaster間の Umbilical Protocol

だいたい全部ですね^^;

ユーザからどう見えるか

設計上はフラグで本機能をON/OFF切り替えできるようになっています．最終的には，

conf.enableLocalAggregation();

としたら本機能が有効になるようにする予定です．

ベンチマーク

現在とっている最中なので，乞うご期待^^;

終わりに

現在 Hadoop の標準機能に入れようと取り組んでいる最中の Node-level Aggregation について書きました．

本機能を実装する上で，Hadooper の皆様の声をぜひ聞いておきたいというところが本音です．もし何か要望がありましたら，気軽に @oza_x86 までお気軽にご連絡ください．よろしくお願いします．

fluent-logger-scala の maven repository を公開しました

fluent-logger-scala の maven repository を，sonatype に公開 しました．
2012/11/20 現在，apache maven の Central Repository から利用できるようになっています．
Scala コンパイラのバージョンは，2.8.1，2.8.2，2.9.0，2.9.1，2.9.2 をサポートしています．

使い方

build.sbt に以下を追加することで，maven 同様に利用可能となります．

 
resolvers += "Apache Maven Central Repository" at "http://repo.maven.apache.org/maven2/"
libraryDependencies += "org.fluentd" % "fluent-logger-scala_''scala_version''" % "0.2.0"

''scala_version'' の部分は，2.8.1，2.8.2，2.9.0，2.9.1，2.9.2のいずれかで置き換えてください． 2.9.2 を利用する場合は，

 
resolvers +=  "Apache Maven Central Repository" at "http://repo.maven.apache.org/maven2/"

libraryDependencies += "org.fluentd" % "fluent-logger-scala_2.9.2" % "0.2.0"

とすれば動作します．

今後について

これからですが，Scala のオブジェクトをそのまま FluentLogger#log() に突っ込めるようにしていく予定です．なお，オブジェクト変換には msgpack-scala.jar を利用予定です．

謝辞

今回のリリースに辺り，TreasureData の @muga_nishizawa さんが fluentd プロジェクトのために sonatype 周りの手続きをしてくださいました．
また，@xuwei-k さんにはリリースに先立ち bug fix のための pull req を， @kmizu さんには便利な publish 方法を教えて頂きました．
みなさま，ありがとうございます！

Renewed fluent-logger-scala!

fluent-logger-scala を，fluent-logger-java  を使う形に更新し，公開した．特徴は以下の通り．

1. Scala のmutable/immutable Map を利用できるように拡張．
2. fluent-logger-java の提供している API を全てサポート．

テストがまだいい加減で， fluentd が 24224 ポートで立ち上がっていることを前提としている．そのうち Mock を利用したテストを追加する予定．ただ，コアの部分をほぼ fluent-logger-java に依存するように書いたので，安定して使えるようになっていると思う．

最後に，fluent-logger-scala の利用例をテストコードから抜粋:

    val logger = FluentLoggerFactory.getLogger("debug")
    val data1 = new HashMap[String, Object]();
    data1.put("k1", "v1");
    data1.put("k2", "v2");
    FluentLoggerFactory.flushAll
    FluentLoggerFactory.closeAll

API が Scala っぽくないとか，もっとこうした方が良いとかあれば，是非ご意見ください．

Auto Commit Memory に関するメモ

Fusion IO が，Auto Commit Memory という新技術のプレスリリースをした．プレスリリースによると，数十億 IOPS という驚異的な性能が出るということだが，PCI Express の Bus を介して毎回 commit しているとすると，明らかに物理性能を超えており，ホントにデータの永続化が保証されているか気になったのでメモしておく．根拠は全て書いているが，ところどころに私の予想が入っているため，正しさは保証できないので注意されたし．

まず，数十億 IOPS を達成するには，PCI Express の bus を介していたら間に合わない．しかし，特殊なハードウェアを使っているわけではなく，プレスリリースには HP ProLiant DL 370 + ioDrive2 Duos を使っていると記述されている．

(プレスリリースから引用 http://www.fusionio.com/press-releases/fusion-io-breaks-one-billion-iops-barrier) 

This demonstration used eight HP ProLiant DL370 servers, each equipped with eight ioDrive2 Duos, to break the one billion IOP barrier when transferring 64 byte data packets.

現状の x86 間に合うとすれば，「データがインメモリに書かれただけである」という場合くらいだろう．すると，1つの仮説が浮かび上がる．

Auto Commit Memory はOSのメモリ管理とフラッシュディスクと電源の合わせ技

まず，Auto Commit Memory の中で使われているであろう技術は，SSDAlloc という名前で既に論文化されている[1]．使われているかもしれない，という根拠は，著者のページに Fusion IO と産学提携している 都度が書いてあるためだ(もちろん，違う技術が使われている可能性もありますが :P )．

SSDAlloc を用いることにより，OS から見てメモリとFlashディスクを透過的に扱うことができる．メモリとフラッシュディスクを透過的に扱うと，1つ大きな問題にぶち当たる．sync() ができないため，データの永続性を保証できない．そこで，ACM では電源のバッテリーを工夫することで，データの払い出しを保証していると予想される．これは，プレスリリースの以下の文言からも見て取れる．

(プレスリリースから引用 http://www.fusionio.com/press-releases/fusion-io-breaks-one-billion-iops-barrier)

Data integrity is assured by the ioMemory architecture’s ability to flush all in-flight data, even if the power is abruptly cut, without the need for super capacitors or batteries. 

スリリースの以下の文言からも見て取れる．つまり，技術の中身はOSのメモリ管理とフラッシュディスクと電源の合わせ技，というわけだ．

ソフトウェアに与える影響
Auto Commit Memory により，フラッシュディスクはメモリと透過的に扱うことができる．逆に，sync は ACM にとっては最適化の邪魔になる．すると，sync を発行する DB は軒並みレガシー化する．

逆に，Volt-DB や Oracle Coherence ・Gemfire といった インメモリDB・データグリッドは，ACM を用いることにより全て永続化が保証される．完全に DB の代替になることが可能になる．

まとめ
Auto Commit Memory は，メモリとFlush Driveを透過的に繋ぐ技術であると予想される．あくまでも「Auto Commit Memory」であり，sync してる訳ではないことに注意が必要．すると sync は最適化の邪魔となる．逆に，sync を発行しないインメモリDB・データグリッド技術が世間を圧巻するだろう．このデバイスは，費用対効果さえ高ければ計算機のモデルを変える可能性が非常に高い．今後の動向に注目していきたい．

[1] SSDAlloc: hybrid SSD/RAM memory management made easy. 著者の HP を見るとわかるが，Fusion IO と産学提携しているようだ．