Hadoopの本質は分散I/Oにあり～クラウド時代の非同期処理

Hadoop向け基幹バッチ分散処理ソフト「Asakusa」の記事がとても素晴らしいのでメモ。

【元ネタ】
第1回　分散処理を隠蔽し、大規模開発を可能に - Hadoop向け基幹バッチ分散処理ソフト「Asakusa」の全貌：ITpro

第3回　業務の境界や並列性を見極め処理を分割 - Hadoop向け基幹バッチ分散処理ソフト「Asakusa」の全貌：ITpro

基幹バッチ再構築のニーズは大きい、Hadoopの課題をAsakusaで解決する - インタビュー：ITpro

Twitter / @akipii: Asakusaの本質は分散I/O。ディスクの入出力がバッチ処理のボトルネック。クラウド時代の非同期処理の設計技法は、ジョブフローからバッチ処理をDSLで自動生成することにあり。

Asakusa Enterprise Batch Processing Framework for Hadoop from Takashi Kambayashi

CobolやPLSQLで書かれた古臭いバッチ処理は、全てHadoopで代用できないものか？
Cobolの生産性の低さは長年の問題だ、と思う。
結局、総合テストで動かさないと、まともに動く事を保障できない。
リリース間際までバグ修正ばかり追いまくられる。

Cobolの最大の欠点は、自動テストライブラリが無い事。
JavaはJUnit、Rubyはtest/unitのライブラリがある。
C++/CもCppUnit、CUnitすらある。
PLSQLならば、Javaからストアドをキックするツールを作る事で、DBUnitを使う事は可能だ。
しかし、Cobolにそのようなツールがあると聞いたことは無い。

基幹系業務システムの開発の最大のボトルネックはバッチ処理。
バッチ処理を制するものが業務システムを制する。
そのバッチ処理は50年以上前からCobolのまま何も進化していない。
だからこそ技術革新のブレークスルーが今起きてもおかしくない。

バッチ処理のボトルネックはディスクの入出力。
CPUがいくら早くても、ディスクの読み書きが遅いからトータルの処理時間は変わらない。

(引用開始)
Hadoopを使ってシステムの性能を高めるには、いかにディスクI/Oを分散させるかという観点が欠かせない。
ディスクI/Oを分散させるには、事前に処理の並列性を担保する必要がある。
Asakusaは基幹バッチ処理を高速化するために、設計段階から処理の並列性を確保し、そのままシームレスに開発につなげる仕組みである。
Asakusaでアプリケーションを開発する際は、この設計から実装までをシームレスにつなげるところが焦点になる。
本稿では、分散I/Oと表裏一体となる並列性の確保の考え方が、バロック音楽の通奏低音のように流れることに留意してほしい。
(引用終了)

つまり、Hadoopの本質は分散I/Oにある。
だからHadoopでディスクへ並列に読み書きすれば処理は早くなる。
そのためには、プログラムが並列処理になるように書いて、副作用をなくす。
関数型言語の発想が必要になってくる。

バッチ処理の設計書によく書かれているジョブフロー図は、リンクつきリスト(Linked List)に過ぎない。
だから、処理を分割したときに、並列に動くような設計をしておけば、Hadoopの威力が大きくなる。

AsakusaのソースはJavaで書かれているようだ。
ジョブフローからDSLでソースを自動生成する仕組みみたい。
浅海さんはSacalaでDSLを書くソースを公開されている。
関数型言語Scalaならば、並列処理をより簡単に書ける可能性がある。

asami/AsakusaScalaDslSample - GitHub

クラウド時代の技術は、KVSのような脱RDBの方向に走っているけれども、昔から何も変わっていないCobolを置き換える技術がそろそろ出てきてもいい気がする。
その鍵は非同期処理における並列プログラミングにある気がする。