Hadoopの死角、COBOLバッチ処理の並列化 - ＠IT（情報元のブックマーク数）
COBOLでの分散処理とHadoopの違いとか、グリッドバッチとかの話。
そして、企業内コンピューティングにおいても、「情報爆発」「ビッグデータ（Big Data）」と呼ばれるほどにデータ量の増加が進んでいる。その一方で、何十年にも渡って使い続けてきたCOBOLなどによるバッチ処理プログラムが毎日動いている現場も数多い。
Hadoopの死角、COBOLバッチ処理の並列化：現場にキく、Webシステムの問題解決ノウハウ（8） - ＠IT
今回は、メインフレーム時代の遺産といえるCOBOLバッチに悩む現場の話と、“単純な並列化”に潜む罠、そして、その回避策を紹介しよう。
COBOL→Javaコンバータでは処理は返還されるけど、高速化するわけじゃない。
COBOLプログラムをJavaに書き直しても、バッチ処理の性質やJavaのJITコンパイラの特性から、従来よりも高速化するとは限らない。むしろ、性能を出すのに苦労する場合さえある。再構築とテストの工数を掛けるメリットが見い出しにくいという現状がある。バッチ処理の世界は、何十年も使われてきた、いわば最後まで残った“ブラックボックス”が生き続けている領域なのだ。
Hadoopの死角、COBOLバッチ処理の並列化：現場にキく、Webシステムの問題解決ノウハウ（8） - ＠IT
バッチをグリッドで処理するソリューション、
このような企業内コンピューティングの現場のニーズを満たすために、さまざまな方法があるが、例えば“グリッドバッチソリューション”（以下、グリッドバッチ）という概念がある。これは、既存のバッチ処理プログラムを書き直さずに並列処理することを目的としている。
Hadoopの死角、COBOLバッチ処理の並列化：現場にキく、Webシステムの問題解決ノウハウ（8） - ＠IT
データ入出力に注目して、データを分割して、グリッド処理させて最後に再結合する。単純ですね。
“グリッドバッチ”の狙いは単純だ。既存のバッチ処理プログラムには手を加えず、その入力と出力に注目する。プログラムに与えるデータをうまく分割し、複数のサーバ上で並列処理させ、プログラムの出力を再結合する。
Hadoopの死角、COBOLバッチ処理の並列化：現場にキく、Webシステムの問題解決ノウハウ（8） - ＠IT
クラウドで注目を浴びているMapReduceアルゴリズムは処理の分散と集約の仕組みを提供する点がポイントだが、“グリッドバッチ”も、データの分散と集約の仕組みを提供する。もちろん“グリッドバッチ”はMapReduceと直接の関係はない。ただ、大量データ処理を並列処理により高速化するという目的は共通している。
こんなインフラのボトルネック・・・
この“グリッドバッチ”の技術上のハイライトは、並列処理したデータを集約する仕組みだ。並列処理で高速化するといっても、低速のネットワークやディスクを使いデータを集約するのでは、ネットワーク帯域やディスクの書き込み（I/O）速度がボトルネックとなってしまう。
Hadoopの死角、COBOLバッチ処理の並列化：現場にキく、Webシステムの問題解決ノウハウ（8） - ＠IT
グリッドバッチは、既存資産をグリッド処理させる技術、Hadoopは新しく開発する場合に活用できるコア技術。まぁ、まったく別もんだな。
最後に、“グリッドバッチ”とHadoopとは、どのような違いがあるのか比較してみよう。
Hadoopの死角、COBOLバッチ処理の並列化：現場にキく、Webシステムの問題解決ノウハウ（8） - ＠IT
以上見てきたように、“グリッドバッチ”のコンセプトは、古いプログラムを最新のクラウド環境で活用し、いままで実現できなかった大量データ処理を実現するというものだ。企業内に眠っている大量のデータを有用に活用するなどの用途で有効かと思われる。現在Linux版を提供中だが、Windows 版の計画もあるとのことだ。
Hadoopの死角、COBOLバッチ処理の並列化：現場にキく、Webシステムの問題解決ノウハウ（8） - ＠IT
