基幹系バッチ処理をHadoopで高速化

基幹系バッチ処理をHadoopで高速化する記事を見つけたのでメモ。
以下ラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
プレスリリース｜2011年2月9日 |ウルシステムズ、業界初、基幹バッチ用のHadoopフレームワーク「Asakusa」 を開発、オープンソース化して提供開始 | ウルシステムズ株式会社 | UL Systems, Inc.

ウルシステムズ、基幹バッチ用HadoopフレームワークをOSS化 - ニュース：ITpro

基幹バッチが超高速化する？｜HATのブログ

業務システムは、日中のフロントエンドのリアルタイム処理と夜間の大量データを集計するバッチ処理の2パターンを組み合わせたアーキテクチャが多い。
フロント側はVisualBasic→CGI→Java→RailsやHTML5と次々に技術革新が起きているのに、バッチ側は昔のCobolで作った資産が残っていて、そこから脱皮できない時が多い。

基幹系の業務システムのバッチ処理では、昼間に業務データを溜め込む。
そして、夜間に業務データから自動仕訳して仕訳帳・仕入先台帳・得意先台帳を日次で作ったり、月末には請求締や支払締に関する残高処理を行ったり、損益月次計算書や貸借対照表、キャッシュフロー計算書を月次で出力する処理がメイン。
Cobolから脱皮できない理由は、日次の仕訳という大量データのトランザクション処理はCobolという枯れた技術で処理すればいいだろう、という発想から抜けきれないからだろう。

Googleが編み出したMapReduceという高速バッチ処理を夜間の業務バッチ処理に使おうという上記の記事の発想は個人的には注目に値すると思う。
そもそもバッチ処理が夜間に行われるのは、処理時間がかかるために夜間はフロント側のシステムを使わない時間帯を使うと言う理由が多いからだ。
バッチ処理がリアルタイム処理に近いならば、基幹系業務システムから集計したデータを経営分析データとして顧客に早くフィードバックできる利点がある。
製造のリードタイム削減、受注時の在庫確認、現金・預金のリアルタイムな残高確認など色んな機能がもっと使い易くなるはず。

上記の記事にある「DOAはDSLである」という発想も面白い。
「UMLモデリングの本質 (日経ITプロフェッショナルBOOKS)」で紹介されているが、OOAでもクラス間の制約はOCLで表現する手法もある。
しかし、モデルがより複雑になるだけで読みにくくなり、あまり利点を感じなかった。

だが、そもそもモデルは業務ロジックと言う制約を表現するためにあるのだから、単なるデータの入れ物だけでなく、その関連性も重要なはず。
RailsではActiveRecordによって、テーブルやSQLをDSLで表現している。
DOAで表現できるリレーションシップも同様にDSLですべて表現できるはず。

DSLで表現できるという意味は、認識できるすべての事象はソフトウェアで実装できるということ。
つまり、モデルを動かすことができて、すぐに検証できることを意味する。

モデルをDSLで表現しようと言う発想は、MDA(モデル駆動開発)のように昔から実験されてきたが、どれも胡散臭い。
OOAもMDAの方向へ走って、行き詰まった感がある。
モデルからプログラムを自動生成できたとしても、実際に動かして、たくさんの労力を投入してテストして、顧客の前でデモしてフィードバックを受けなければ、使えるシステムにはならない。

モデリングと言う上流工程もAgile開発のように、モデリングしながら検証してモデルを洗練させていく設計スタイルに変えられないのだろうか？