Chapter 3 バッチ処理の方式(3)
4 パーティショニング(区分化)
パーティショニングの技法を用いることで、大きなバッチアプリケーションの複数を同時並行で実行することができるようになる。
この目的は、長時間のバッチジョブに必要な合計処理時間を短縮することである。
うまく区分化できた処理は入力ファイルがそれように分割し、主なデータベーステーブルもアプリケーションが異なるデータのセットごとにアクセスできるように区分化されたものとなる。
加えて、区分化された処理は割り当てられたデータのセットだけを処理するようにデザインされねばならない。区分化のアーキテクチャはデータベース設計とデータベース自体の区分化方式(戦略)に密接に繋がっている。
なお、データベースの区分化というのは、大抵の場合有効であるとはいえ、必ずしもデータベースの物理的な分割を意味しないことに注意して欲しい。以下の図は区分化のアプローチを図示したものである。
Figure 3 1
パーティションの数の構成が動的に可能であるような柔軟性を兼ね備えているべきである。自動的またはユーザーによる管理の両方ができることが望ましい。自動的な構成は入力ファイルのサイズや入力レコード数のようなパラメーターに基づいて行われるだろう。
Chapter 3 バッチ処理の方式(2)
ちょっと日が開いてしまいましたが、続きいきます。
1 バッチウィンドウ内での通常処理
オンラインと分割されたバッチウィンドウにおいて単純なバッチ処理が実行されるためには、「更新対象のデータがオンラインユーザーや他のバッチプロセスによって必要とならないこと」が求められる。同時実行性は問題とはならず、ただ1回だけのコミットがバッチ処理実行の最後に行われるだろう。
しかしながらほとんどの場合、もっと堅牢なアプローチを採用するほうが適切である。バッチシステムは時が経つにつれ複雑さと扱うデータ量の両方が大きくなっていく傾向がある、ということを理解しておかねばならない。ロック方式が設定されておらず、システムがまだ1つのコミットポイントにのみ依存しているような場合、バッチプログラムを修正することは多大な労力を伴うことになるだろう。そのため、最も単純なバッチ処理システムであっても、以降で説明するようなもっと複雑なバッチ処理時に検討すべき場合と同様に、再開-復帰操作ためのコミット処理の必要性を検討すべきである。
Chapter 3 バッチ処理の方式/戦略 (1)
バッチシステムの設計と実装の手助けとなるような、基本的なバッチアプリケーションのビルディングブロックとパターンがサンプルチャートやコード抜粋の形で設計者とプログラマーに提供されるべきであろう。バッチジョブを設計するに当たっては、ビジネスロジックは実装可能な以下に示す標準的なビルディングブロックを用いた一連の処理ステップ(a series of steps)へ分解される必要がある。
変換アプリケーション(Conversion Applications)
外部システムに対して生成する または 外部システムから供給されるファイルの各タイプに応じて、トランザクションのレコードを処理するために必要となる標準的な形式に変換するアプリケーションが必要になる(場合がある)。この種のバッチアプリケーションは部分的または全部がユーティリティ的なモジュールから構成される場合がある(「基本バッチサービス」を参照)
- 検証アプリケーション(Validation Applications)
検証アプリケーションは、全ての入力/出力レコードが正しく整合性が保たれているかを保証する。検証処理はファイルヘッダーやトレイラー、チェックサムやレコード単位のクロスチェックと同様の検証アルゴリズムを用いて行われる
- 展開アプリケーション(Extract Applications)
データベースや入力ファイルから、レコードのセットを読み込み、あらかじめ決められたルールに基づいてレコードを選択し、出力ファイルへレコードを書き出すアプリケーション
- 展開/更新アプリケーション(Extract/Update Applications)
データベースや入力ファイルから、レコードを読み込み、各入力レコードのデータに応じてデータベースや出力ファイルへ変更(更新)を行うアプリケーション
- 処理&更新アプリケーション(Processing and Updating Applications)
展開アプリケーションや検証アプリケーションからの入力トランザクションを処理するアプリケーション。通常、この処理は処理に必要なデータを得るためにデータベースを読み込み、場合によってはデータベースを更新ないし出力処理用にレコードを新規生成する
- 出力/フォーマットアプリケーション(Output/Format Applications)
入力ファイルを読み込み、レコード内容を標準的な形式に適した形に再構築して他のプログラムやシステムへ転送したり、印刷用の出力ファイルを生成したりするアプリケーション。
さらには、上述のビルディングブロックを使用して構築できないようなビジネスロジックのために、基本的なアプリケーションシェルが必要になることもある。
主なビルディングブロックに加え、各アプリケーションは以下のような標準ユーティリティのステップを1つないし複数利用する場合があるだろう。
- ソート(並べ替え)
入力ファイルを読み込み、レコード内のソート用のキーとなるフィールドに応じて順番を並べ替え、そのレコードを出力ファイルへと処理する。ソートは通常、標準的なシステム(訳者註：OSのsortコマンドなどのことを指すと思われる)ユーティリティが利用される。
- スプリット(分割)
1つの入力ファイルを読み込み、そのフィールドの値に基づいて複数の出力ファイルのどれかへと各レコードを書き出す。スプリット処理はパラメータ指定した標準的なシステムユーティリティによって行われることもあれば、カスタム開発される場合もある
- マージ(併合)
複数の入力ファイルからレコードを読み取り、それらのファイルからのデータを組み合わせたデータを1つの出力ファイルへと処理する。マージ処理はパラメーターを指定した標準的なシステムユーティリティで行われることもあれば、カスタム開発される場合もある
さらに、バッチアプリケーションは入力データによってカテゴリ分けすることができる。
- データベース駆動型
データベースから取得する行や値に基づいて動作する
- ファイル駆動型
ファイルから取得するレコードや値に基づいて動作する
- メッセージ駆動型
メッセージキューから取得するメッセージに基づいて動作する
あらゆるバッチシステムの基礎となるのは、その処理方式(processing strategy)である。処理方式の選択にあたって影響を及ぼす要因としては、以下のようなものがある：
- バッチ処理システムの想定ボリューム
- オンライン処理との同時実行性
- 他のバッチ処理との同時実行性
- 利用できるバッチウィンドウ(企業はどんどん稼働中の状態つまり24x7の稼動を求めており、このことは明確なバッチウィンドウというものがもはや無くなってくることに繋がってくる)
バッチ処理の典型的な処理方式の選択肢を以下に挙げる：
- オフライン時間帯の、バッチウィンドウ内での通常処理
- バッチとオンライン処理との同時実行
- 多数の異なるバッチ処理の並列実行、または一時点での同時実行
- パーティショニング(区分化処理)(例：同一ジョブの多数のインスタンスが、同時に処理)
- 上記の組み合わせ
上記のリストの順番は、そのままその実装時の複雑さを表している。つまり、バッチウィンドウでの処理が最も実装が容易で、逆に区分化処理が最も困難である。
これらの内いくつかまたは全ての処理方式は、商用のスケジューラー製品でサポートされているものもあるだろう。
以下のセクションでは、これらの処理方式をもっと詳細に議論していくことにする。バッチ処理によって採用されるコミットとロック戦略は処理方式の種別に依存しているということが重要な点である。オンラインのロック戦略と同じ原則を利用する。従って、バッチアーキテクチャは全体のアーキテクチャを設計する場合、単純に後から思いつけるようなものではない。
ロック方式は、通常のデータベースが実装するロックのみを利用するか、またはアーキテクチャにおいて実装される別のカスタムロックサービスを利用して実現する。ロックサービスは(たとえば専用のDB上テーブルに必要な情報を保持することで)アプリケーションプログラムがDB操作を要求することを許可したり拒否したりするものである。バッチジョブがロックを必要とする状況で異常終了してしまうのを回避するために、リトライロジックもこのアーキテクチャを利用して実装されるかもしれない。
Chapter 1 紹介
多くのエンタープライズ分野でのアプリケーションは、ミッションクリティカル環境におけるビジネス処理を行うために大量(bulk)処理を必要とする。これらのビジネス処理は自動化され、ユーザーの操作を伴わずに大量の情報を複雑に処理する。これらの処理は、典型的には時間起動(time based)なイベント(例：月末の計算や通知、集計)や、定期的に複雑なビジネスルールを繰り返し大量のデータセットに対する横断的な処理(例：保険利息決定や利率調整)や、フォーマット・妥当性の検証・トランザクションを保った状態での処理を必要とするような内部または外部システムなどから受け取る情報から成っている。このように、“バッチ処理”は、大企業においては毎日何百万件というトランザクションの処理に適用されている。
Springバッチは、日々のエンタープライズシステムの処理に対して重要な堅牢なバッチアプリケーションの開発を可能とするための、軽量で習得しやすいバッチフレームワークとして設計される。Springバッチは生産性の高い、POJOベースの開発アプローチに立脚しており、これはSpring Frameworkの登場によって既に人々が理解している通りに汎用的な利用のしやすさを提供するものである。これによって、開発者が必要とするときに先進的なエンタープライズサービスを利用できるようにする。
Springバッチは、大量のレコードを処理するときに不可欠な再利用性のある機能を提供する。この機能にはロギング/トレース、トランザクション管理、ジョブ処理統計、ジョブの再開、スキップ、リソース管理などが含まれる。また、それらに加えてより進んだ最適化やパーティショニング技術によって極端に大量で高パフォーマンスが求められるバッチジョブを実現可能にするようなテクニカルサービスやフィーチャーも提供する。
SpringバッチはSpringポートフォリオを構成する一部分である。(訳者註：http://www.springframework.org/sub-projectsを参照のこと。Spring Web FlowやSpring Web Servicesなどと同じSpringのサブプロジェクトとしてSpring Batchは位置づけられている)
続きは後日
CHAPTER 1 Spring Batch
「Spring Batch」は、2007年5月7日にSpringのポートフォリオへの新たな追加プロダクトとしてアナウンスされた。「Java技術の新たなフロンティアへの適用：エンタープライズ分野におけるSpringバッチを用いたバッチ処理」と題され、5月11日のJavaOneにおいて、Rod JohnsonとScott Wintermute、Wayne Lundらによってプレゼンテーションが行われた。ソースコードはSourceForgeのSVNリポジトリーに公開される見込みで、1.0-M2リリースが6月の上旬(今年の早期に内部M1リリースを行った後に)行われている。フィードバック歓迎！
Springバッチとリリーススケジュールの告知用のメーリングリストがある。講読はこちらのリストにあるサイトを訪問して欲しい。
1 概要
Springバッチは、繰り返し実行するタスクの集まりとして与えられる長時間実行処理(long-running processes)を処理するための技術的なフレームワークとプログラミングモデルを提供するものである。典型的なバッチプログラムは、一般的にはデータベース・ファイル、キューから大量のレコードを読みこみ、何らかの方法でデータを処理し、そのデータを加工した形態で出力する。Springバッチはこの基本的なバッチ処理の反復を自動化し、典型的にはオフライン環境においてユーザーとの相互のやり取りなしに行われるような一覧のトランザクションを実行する能力をユーザーに提供する。
バッチジョブは、大抵のITプロジェクトにおいて登場する。そして、Springバッチは堅牢さとエンタープライズ用途に耐えるスケーラビリティを持つソリューションを提供する唯一のオープンソースフレームワークである。バッチ処理は多数のエンタープライズ分野でのデータ処理のパイプライン(例：支払や決算システム)用のアプリケーション様式(style)であるものの、標準的なアーキテクチャがこれまで無く、そのため多くのプロジェクトで開発工数やメンテナンスコストを払いつつ独自のカスタムアーキテクチャを開発してきた経緯がある。
1.1 ビジネスシナリオ
1.2 技術的な目的
- バッチ開発者がSpringのプログラミングモデルを利用：ビジネスロジックへの集中。フレームワークがインフラ的部分の面倒を見る
- インフラとバッチコンテナとバッチアプリケーションとのそれぞれの関心事の明確な分離
- 全てのプロジェクトが実装可能なインターフェースとしての、共通のコンテナサービスの提供
- 箱から取り出してすぐ利用できるようにするためのシンプルなコンテナインターフェースのデフォルト実装を提供
- サービスの構成・カスタマイズ・拡張が容易であること。これはSpringフレームワークを全てのレイヤーで利用することで実現する
- 全てのコンテナサービスは、インフラ層に影響を及ぼすことなく容易に置き換えまたは拡張が可能であること
- シンプルな開発モデルを提供すること。Mavenを利用してビルドされ、完全にアプリケーションから分離したJARが利用される
続き、は、何かコメントがつくか、気力が続けばということで…
(追記：勝手訳、すこしずつ開始しました)
注目していこう
http://www.itmedia.co.jp/enterprise/articles/0705/10/news026.html
バッチ処理に関するSpring Frameworkファミリーとしてアナウンスされたもの。
まだ具体的なリソースやコードとしては実質ないようだが、それでも個人的に要注目。
Accentureがコミットしているのも面白い。
また、Spring Batchのプロジェクトページにある、バッチ処理に関するUsecaseは、今までこの手の分野は書籍もなく、エンジニアの暗黙知(経験や口伝)などであった部分にある程度光を当てて公開しているという面で非常に価値があるように思う。
…すこしずつ翻訳でもしてみようか。
とりあえずプロジェクトのトップページの部分を勝手翻訳。単なる市井のSEの勝手翻訳なので、適当にそのあたりは割り引いて読んで欲しい
Beehive
WebLogicの野望が多分に含まれているApache Beehiveをダウンロードしてみる…てこれまだインキュベータプロジェクトの中だったか。
http://incubator.apache.org/beehive/
仕事柄あんまりWebLogic関連のプロダクト(といっても究極には一つしかないが…)に触ることのない身としては，とりあえず見ておくか…というところで。
