(57)【要約】【課題】大量データをターゲットとした従来のバッチ処理システムでは、ＤＢに格納されたバッチ処理対象データをバッチ処理クラスタに一度に転送するため時間がかかり、全体のバッチ処理時間が長くなる。【解決手段】このため、本発明では、バッチ実行周期の間に、バッチ管理システムが、データベースサーバに格納されたデータの更新情報を複数回抽出し、更新情報に基づいて、前回の更新処理から今回の更新処理までの間における更新データを保存・管理し、更新データを分散ファイルシステムに逐次転送する手法を採用する。【選択図】図２
2014041501.tif 000002
【特許請求の範囲】
【請求項１】
データベースサーバに接続されるバッチ管理システムによるバッチ処理対象データの高速読込み方法において、
バッチ実行周期の間に、バッチ管理システムが、前記データベースサーバに格納されたデータの更新情報を複数回抽出する処理と、
前記バッチ管理システムが、前記更新情報に基づいて、前回の更新処理から今回の更新処理までの間における更新データを保存・管理する処理と、
前記バッチ管理システムが、前記更新データを分散ファイルシステムに逐次転送する処理と
を有するバッチ処理対象データの高速読込み方法。
【請求項２】
請求項１に記載のバッチ処理対象データの高速読込み方法において、
前記バッチ管理システムが、前記更新データのハッシュ値を保存・管理する処理
を有することを特徴とするバッチ処理対象データの高速読込み方法。
【請求項３】
請求項２に記載のバッチ処理対象データの高速読込み方法において、
前記分散ファイルシステムが、前記更新データに基づいてバッチ処理入力データを更新する処理と、
バッチ処理を開始する前に、前記分散ファイルシステムが、前記バッチ処理入力データと前記ハッシュ値とを照合して整合性を確認する処理と、
前記分散ファイルシステムが、整合性が確認された前記バッチ処理入力データについてバッチ処理を実行する処理と、
前記分散ファイルシステムが、バッチ処理後のデータをバッチ処理出力データとして前記データベースサーバに反映する処理と
を有することを特徴とするバッチ処理対象データの高速読込み方法。
【請求項４】
請求項１に記載のバッチ処理対象データの高速読込み方法において、
前記バッチ管理システムは、前記データベースサーバを構成するデータベースが出力するトランザクションログを前記更新情報として取得する
ことを特徴とするバッチ処理対象データの高速読込み方法。
【請求項５】
請求項１に記載のバッチ処理対象データの高速読込み方法において、
前記バッチ管理システムは、前記更新データを、指定個数のエントリ毎に纏めて抽出し、抽出されたエントリの値を結合して第１のハッシュ値を算出して保存・更新し、
前記分散ファイルシステムは、前記指定個数のエントリに対応するデータ部分を前記バッチ処理入力データから抽出して第２のハッシュ値を算出し、前記第１のハッシュ値と照合する
ことを特徴とするバッチ処理対象データの高速読込み方法。
【請求項６】
請求項５に記載のバッチ処理対象データの高速読込み方法において、
前記指定個数のエントリのデータサイズは、前記バッチ処理におけるファイルサイズと一致するように設定される
ことを特徴とするバッチ処理対象データの高速読込み方法。
【請求項７】
請求項５に記載のバッチ処理対象データの高速読込み方法において、
前記分散ファイルシステムは、前記第１のハッシュ値と前記第２のハッシュ値が一致しない場合、当該照合結果に対応するエントリ群を前記バッチ管理システムから取得して前記バッチ処理入力データに反映し、整合性が確保された後に、バッチ処理を実行する
ことを特徴とするバッチ処理対象データの高速読込み方法。
【請求項８】
データベースサーバに接続されるバッチ管理システムであって、
バッチ実行周期の間に、前記データベースサーバに格納されたデータの更新情報が抽出されるたび、前回の更新処理から今回の更新処理までの間における更新データを保存・管理するデータベースと、
前記更新データを、バッチ処理を実行する分散ファイルシステムに対して逐次転送する処理部と
を有するバッチ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、バッチ処理対象データのバッチ処理システムへの読み込み処理を高速化する技術に関する。
【背景技術】
【０００２】
近年、ビックデータ(big data)の蓄積・バッチ処理・分析技術に対する需要が高まりつつある。その理由は、複数台の汎用サーバによるクラスタ構成が可能となり、低コストでのデータのアーカイブ・並列処理が実現されたことによる。現在、多くの企業において、この種のシステムが採用されている。
【０００３】
ところで、企業システムが実行する処理業務には、基幹システム等の業務システムが生成・取り扱うデータを、業務システム側のデータベースからバックエンド側のデータベースに移行してバッチ処理する処理業務がある。
【０００４】
本明細書では、バックエンド側に位置してバッチ処理を実行するシステムを「バッチ処理システム」という。バッチ処理システムは、業務システム側のデータベースからデータを読み込むと、設定されたバッチプロセスを実行し、自システム内のデータベース上にバッチ処理結果を保存する。現在、このバッチ処理に要する時間を短縮して、業務の効率化を図る取り組みが行われている。
【０００５】
例えば特許文献１では、データを入出力する際の負荷を低減するために、外部記憶媒体に対するデータのI/O回数を少なくする技術が提案されている。この技術は、データベースに対する複数の全件検索要求を受け付けた場合に、メモリにロードされたデータを再利用することにより外部記憶媒体へのI/O回数を低減するものであり、データベースへのアクセス性能とバッチ処理性能の向上を図っている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平０８−６８２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところが、特許文献１に記載された発明は、バッチ処理に際し、一度に大量のデータをメモリにキャッシュすることを要求する。このように大量のメモリを消費するバッチ方法は、システムのコスト高を招いてしまう。また、現実問題として、バッチ対象とする全てのデータを、バッチ処理システム内のメモリに書き込めない可能性もある。
【０００８】
そこで、発明者は、低コストでありながらも、バッチ処理を高速に実行できる手法として、汎用PCクラスタを利用した並列バッチ処理技術に着目した。ただし、現時点において、Hadoop/HDFS等のオープンソース系のソフトウェアを単純に適用してバッチ処理システムを構成しても、それだけではバッチ処理の高速化は実現されず、システム動作の信頼性も担保することができない。
【０００９】
そこで、発明者は、汎用PCクラスタを利用した並列バッチ処理システムに対し、データを高速に読み込むことができる仕組みが必要であるとの認識に至った。
【課題を解決するための手段】
【００１０】
発明者は、データソースとしてのデータベースサーバから分散ファイルシステムへのデータの転送を、以下の手順により実行する手法を提案する。
【００１１】
すなわち、バッチ実行周期の間に、バッチ管理システムが、データベースサーバに格納されたデータの更新情報を複数回抽出する処理と、バッチ管理システムが、更新情報に基づいて、前回の更新処理から今回の更新処理までの間における更新データを保存・管理する処理と、バッチ管理システムが、更新データを分散ファイルシステムに逐次転送する処理とを実行する手法を提案する。
【発明の効果】
【００１２】
本発明によれば、バッチ実行周期の間に、データソースとしてのデータベースサーバにおける更新状況（更新データ）を、定期的に分散ファイルシステムに反映することができる。この結果、バッチ処理の実行開始時に分散ファイルシステムに転送されるデータ量を削減することができ、バッチ処理に要する時間を大幅に短縮することができる。前述以外の課題、構成及び効果は、以下の実施の形態の説明により明らかにされる。
【図面の簡単な説明】
【００１３】
【図１】実施例に係るシステムの全体構成を示す図。
【図２】実施例に係るバッチ処理の全体処理手順を示す図。
【図３】テーブルのハッシュ値管理に関する概要を説明する図。
【図４】テーブル差分管理ＤＢのテーブル例を示す図。
【図５】ハッシュ値管理ＤＢのテーブル例を示す図。
【図６】差分データ抽出処理手順を説明するフローチャート。
【図７】バッチ処理手順を説明するフローチャート。
【発明を実施するための形態】
【００１４】
以下、図面に基づいて、本発明の実施の形態を説明する。なお、本発明の実施の態様は、後述する形態例に限定されるものではなく、その技術思想の範囲において、種々の変形が可能である。
【００１５】
［実施例］
（システム構成）
図１に、本実施例が想定するシステムの全体構成を示す。利用者端末１０１は、ＬＡＮ１０２経由で業務サーバ１０３に接続されている。利用者は、利用者端末１０１を使用して業務サービス１０６にアクセスする。ここで、業務サーバ１０３はコンピュータを基本構成とし、演算装置、ハードディスク等の大規模ストレージ装置、通信インターフェース及び周辺装置で構成される。業務サービス１０６は、コンピュータによるプログラム処理を通じて実現される。
【００１６】
業務サーバ１０３には、バックグラウンドで実行される並列バッチ処理を管理するバッチ管理サーバ１０４と、並列バッチ処理を実際に実行するバッチ処理クラスタ１１５とがＬＡＮ１０２経由で接続されている。なお、バッチ処理クラスタ１１５は、複数台のバッチ処理サーバ１０５で構成されている。本明細書では、バッチ管理サーバ１０４単独、又は、バッチ管理サーバ１０４とバッチ処理クラスタ１１５で構成されるシステムを「バッチ管理システム」という。
【００１７】
業務サーバ１０３のストレージ装置には、業務サービスＤＢ１０７やそのトランザクションログ１０８が格納されている。業務サービスＤＢ１０７には、業務サービスが使用するデータが格納されている。ここでの格納データがバッチ処理の対象となる。業務サービスＤＢ１０７は、トランザクションログ１０８を出力・保存するモードで稼働される。トランザクションログ１０８は、業務サーバ１０３の公開ディレクトリに保存されており、アクセスが許可された他のサーバからダウンロードすることができる。
【００１８】
バッチ管理サーバ１０４もコンピュータを基本構成とし、演算装置、ハードディスク等のストレージ装置、通信インターフェース及び周辺装置で構成される。バッチ管理サーバ１０４では、バッチ管理サービス１０９が稼動している。バッチ管理サービス１０９は、コンピュータによるプログラム処理を通じて実現される。
【００１９】
バッチ管理サービス１０９は、システム全体におけるバッチ処理の管理・制御を実行し、例えば業務サービスＤＢ１０７内におけるバッチ処理対象データ（バッチ処理の対象となるテーブルの特定カラムに関するデータ）と、前回アクセス時のデータに対する更新を管理する。バッチ管理サーバ１０４のストレージ装置には、テーブル差分管理ＤＢ１１０及びハッシュ値管理ＤＢ１１１が格納されている。
【００２０】
バッチ処理クラスタ１１５を構成するバッチ処理サーバ１０５も、コンピュータを基本構成とする。各バッチ処理サーバ１０５には、バッチアプリケーション１１２と分散処理フレームワーク１１３がインストールされている。分散処理フレームワーク１１３は、クラスタノード間での協調したデータストア及び並列処理を実行するプログラムであり、バッチアプリケーション１１２の実行も制御する。また、バッチ処理サーバ１０５は、二次記憶装置１１４を備えている。二次記憶装置１１４は、例えばハードディスク装置等のストレージ装置で構成される。
【００２１】
ここで、分散処理フレームワーク１１３が、クラスタノード間でデータを共有するための分散ファイルシステムを構成するベースとなる。分散処理フレームワークの一例には、Apache Hadoopがある。Hadoopは、分散ファイルシステムであるHDFS上にデータを格納し、MapReduceフレームワークで並列分散処理を行うことができる。本実施例では、分散処理フレームワークとして、Hadoopを仮定するが、同様の機構を有する他の分散処理フレームワークでも良い。
【００２２】
（バッチ処理フロー）
図２に、図１に示すシステムにおいて実行されるバッチ処理フローの流れを説明する。図２は、業務サーバ１０３、バッチ管理サーバ１０４及びバッチ処理クラスタ１１５の間における処理動作の流れを表している。
【００２３】
業務サーバ１０３では、トランザクションログ１０８が、業務サービスＤＢ１０７へのアクセスが発生した段階で随時出力される。
【００２４】
バッチ管理サーバ１０４では、バッチ管理サービス１０９が定期的に業務サーバ１０３にアクセスし、トランザクションログ１０８をダウンロードする。この実施例では、トランザクションログ１０８の発生タイミングとは無関係に、トランザクションログ１０８のダウンロードが定期的に実行される。もっとも、バッチ管理サーバ１０４は、トランザクションログ１０８の発生をトリガーとして、トランザクションログ１０８のダウンロードを実行しても良い。
【００２５】
バッチ管理サービス１０９では、業務サービスＤＢ１０７を構成するテーブル群のうち、どのテーブルとカラムのデータをバッチ処理用にフェッチするかが予め定義されている。バッチ管理サービス１０９は、このトランザクションログ１０８に基づいて、前回からの更新部分を検知し、指定されたテーブルのカラムデータのみを管理するテーブル差分管理ＤＢ１１０のデータを更新する。
【００２６】
本実施例の場合、バッチ管理サービス１０９は、更新部分を含むエントリ群のデータのハッシュ値を計算し、ハッシュ値管理ＤＢ１１１に登録する。本実施例の場合、ハッシュ値の計算は、差分エントリが更新される度に行う。ここで、更新部分を含むエントリ群のデータのハッシュ値を登録・管理する理由は、分散処理フレームワーク上で実際にバッチ処理を実行する際に、バッチ処理入力データが、実際の業務サービスＤＢ１０７上に存在するデータと一致しているか否かを効率的に確認できるようにするためである。
【００２７】
このハッシュ値の計算は、分散処理フレームワークが提供する分散ファイルシステムで信頼性が担保されていない場合に効果的である。例えばHadoop/HDFS等のオープンソース系のソフトウェアは、現時点において、バッチ処理の基盤に用いるには信頼性に難がある。しかし、後述する整合性の確認動作を採用すれば、Hadoop/HDFS等のオープンソース系のソフトウェアにより構成された分散ファイルシステムの信頼性を、従来システムと同等レベルまで引き上げることができる。
【００２８】
バッチ管理サービス１０９は、更新があったエントリのみをバッチ処理クラスタ１１５に逐次転送する。このように、転送されるデータは、更新のあったエントリのみである。このため、バッチ処理クラスタ１１５に転送されるデータ量は、業務サービスＤＢ１０７のデータ量に対して非常に少なく済む。また、更新のあったエントリのデータは、バッチ処理クラスタ１１５におけるバッチ実行周期の間も逐次転送される。バッチ処理クラスタ１１５は、逐次受信されるデータを、分散処理フレームワークが構成する分散ファイルシステム上のバッチ処理入力データに反映する。
【００２９】
このように、本実施例では、差分データのみ逐次更新する方式を採用する。この方式の採用により、バッチ処理クラスタ１１５で実際にバッチ処理を実行する際に一度に大量のデータを転送する必要がなくなる。このため、従来システムに比して、バッチ開始時におけるデータの読み込み時間が短縮される。結果的に、バッチ処理開始から終了までに要する時間を、従来システムに比して、大幅に短縮することが可能になる。
【００３０】
なお、バッチ処理クラスタ１１５は、バッチ処理の開始に先立って、バッチ管理サーバ１０４の間でバッチ処理入力データの整合性を確認し（具体的には、バッチ処理入力データから計算されるハッシュ値とハッシュ値管理ＤＢ１１１に登録されたハッシュ値とを照合し）、整合性が確認された場合にバッチ処理を実行する。
【００３１】
バッチ処理クラスタ１１５は、バッチ処理の終了後、集計値を計算してストレージ装置に格納する。バッチ処理クラスタ１１５は、計算された集計値をバッチ処理出力データ２０２として業務サーバ１０３の業務サービスＤＢ１０７に転送する。バッチ処理クラスタ１１５は、このバッチ処理出力データ２０２に基づいて、業務サービスＤＢ１０７にバッチ処理結果を反映する。
【００３２】
（ハッシュ値の管理）
ここでは、図３に基づいて、テーブルのハッシュ値を管理する方法について説明する。図３に示すテーブルは、テーブル差分管理ＤＢ１１０に格納されているデータである。テーブルデータが与えられた場合、バッチ管理サービス１０９は、先頭から指定された行数のエントリ群を抽出し、その個々の値を結合した値に対してハッシュ値を計算し、その値をハッシュ値管理ＤＢ１１１に登録する。
【００３３】
例えば図３の例の場合、バッチ管理サービス１０９は、１０行ずつデータを抽出し、最初の１０行に関しては、「001-00001」、「佐藤 一郎」、「34,000」、「001-00002」、「山田 花子」、「8,200」、・・・、「001-00010」、「鈴木 太郎」、「102,100」をバイナリ値として単純に結合して一つのバイナリ値を算出し、そのバイナリ値に対してハッシュ値h1を計算して登録する。同様に、バッチ管理サービス１０９は、次の１１行から２０行目までのデータについてハッシュ値h2を計算して登録する。以下同様に、バッチ管理サービス１０９は、ハッシュ値を計算してハッシュ値管理ＤＢ１１１に登録する。
【００３４】
ここで、バッチ管理サービス１０９は、差分エントリの更新時、更新があったエントリを含むデータ部分（実施例では１０行分のデータ）についてのみハッシュ値を再計算すればよく、毎回、テーブル内の全てのデータについてハッシュ値を計算する必要はない。この計算方法により、ハッシュ値の計算処理の高速化を実現することができる。
【００３５】
ここで、テーブルデータを分割する際の指定行数は、HDFSが管理するブロックサイズ（デフォルトでは64MB）を考慮することが望ましい。例えば指定行数のデータサイズの定数倍が、HDFSのブロックサイズに一致するように指定行数を設定する。このように指定行数を設定することにより、ブロックファイルを跨ぐ指定行数のテーブルデータの存在を回避することができる。その結果、HDFS上でのバッチ処理入力データの効率的な読み書きを実現することができる。
【００３６】
（テーブルの構造例）
ここでは、バッチ管理サーバ１０４で管理されるテーブル差分管理ＤＢ１１０とハッシュ値管理ＤＢ１１１のテーブル例について説明する。
【００３７】
図４に、テーブル差分管理ＤＢ１１０のテーブル例を示す。図４は、EC（electronic commerce）サイトにおける各会員情報に関するＤＢを想定した図である。なお、業務サーバ１０３側の業務サービスＤＢ１０７には、会員情報のマスタテーブルが格納されている。
【００３８】
会員番号４０１、氏名４０２、月別購入金額４０３は、業務サービスＤＢ１０７に格納されているマスタテーブルのうちバッチ処理に必要とされる属性である。テーブル差分管理ＤＢ１１０には、これらの属性からなる部分テーブルが保持される。当該構造の採用により、テーブル差分管理ＤＢ１１０におけるデータの更新時間やデータ量の削減が実現される。また、テーブル差分管理ＤＢ１１０には、更新フラグ４０４も保持される。更新フラグ４０４は、業務サービスＤＢ１０７からの前回のデータ抽出時から今回のデータ抽出時までの間に更新があったエントリの識別に使用される属性である。更新があったエントリには値「１」が設定され、更新が無かったエントリには値「０」が設定される。バッチ管理サービス１０９は、更新フラグ１０４の値に基づいてハッシュ値を再計算するか否かを判定する。
【００３９】
図５は、ハッシュ値管理ＤＢ１１１のテーブル例を示している。本実施例の場合、テーブルの属性値には、テーブルＩＤ５０１、開始エントリＩＤ５０２、終了エントリＩＤ５０３、ハッシュ値５０４が含まれる。テーブルＩＤ５０１は、テーブル差分管理ＤＢ１１０に格納されているテーブルのＩＤを示している。本実施例では、図４に記載のテーブルのテーブルＩＤを「Ｔ１」で表している。また、開始エントリＩＤ５０２と終了エントリＩＤ５０３は、ハッシュ値を計算するエントリ群の最初と最後のエントリのキー値を示している。テーブルＴ１の主キーは会員番号であり、この会員番号をベースに用い、開始エントリＩＤと終了エントリＩＤが定義されている。また、ハッシュ値５０４は、指定されたエントリ群について、図３で説明した方式により計算されたハッシュ値が格納される。
【００４０】
（差分データ抽出処理手順）
図６に、バッチ管理サービス１０９において実行される差分データ抽出処理手順のフローチャートを示す。バッチ管理サービス１０９は、業務サーバ１０３上にある業務サービスＤＢ１０７が出力するトランザクションログ１０８を取得する（ステップ６０１）。
【００４１】
次に、バッチ管理サービス１０９は、取得したトランザクションログに基づいて、業務サービスＤＢ１０７において更新されたエントリデータを抽出する（ステップ６０２）。
【００４２】
抽出したデータ内に、テーブル差分管理ＤＢ１１０に格納されたバッチ処理用のテーブルの属性値に相当するものが含まれる場合、バッチ管理サービス１０９は、その更新エントリの値をテーブル差分管理ＤＢ１１０に反映する（ステップ６０３）。このデータの反映時に、バッチ管理サービス１０９は、更新フラグ４０４の値を「１」に設定する。
【００４３】
全ての更新エントリの値についてテーブル差分管理ＤＢ１１０に反映処理が終了すると、バッチ管理サービス１０９は、更新フラグ４０４の値を参考に更新エントリを探索し、更新エントリを含む指定エントリ群のハッシュ値を計算する（ステップ６０４）。ハッシュ値が計算されると、バッチ管理サービス１０９は、計算したハッシュ値をハッシュ値管理ＤＢ１１１に登録し（ステップ６０５）、その後、更新データを分散ファイルシステム上のバッチ処理入力データに反映する（ステップ６０６）。
【００４４】
この一連のプロセスは、バッチ管理サービス１０９によって定期的に実行される。これにより、業務サービスＤＢ１０７の更新データが、バッチ実行周期の間も、逐次、バッチ処理入力データに反映される。これにより、バッチ処理の実行時に、一度にデータ移行が発生することなく、バッチ処理全体の時間短縮を実現することができる。
【００４５】
（バッチ処理手順）
図７に、バッチ処理クラスタ１１５において実行されるバッチ処理手順のフローチャートを示す。バッチ処理クラスタ１１５は、バッチ処理が開始されると、まず、バッチ処理入力データの整合性をチェックする（ステップ７０１）。具体的には、バッチ処理クラスタ１１５は、各ブロックデータ群についてハッシュ値を計算し、ハッシュ値管理ＤＢ１１１に格納されている対応する値と照合する。ここで、ブロックデータとは、バッチ処理入力データの部分データであり、指定行数のエントリデータに対応するデータである。
【００４６】
次に、バッチ処理クラスタ１１５は、ハッシュ値が一致しないブロックデータ群の有無をチェックする（ステップ７０２）。ハッシュ値が一致しないブロックデータ群が存在する場合（ステップ７０２で肯定結果）、バッチ処理クラスタ１１５は、一致しない部分をテーブル差分管理ＤＢ１１０から抽出してバッチ入力データを修正し（ステップ７０３）、その後、バッチ処理を実行する（ステップ７０４）。これに対し、ハッシュ値が一致しないブロックデータが存在しない場合（ステップ７０２で否定結果）、バッチ処理クラスタ１１５は、整合性が確認できたと判定し、実際のバッチ処理を実行する（ステップ７０４）。
【００４７】
最後に、バッチ処理クラスタ１１５は、分散ファイルシステム上に保存されたバッチ処理出力データに基づいて業務サービスＤＢ１０７を更新する（ステップ７０５）。
【００４８】
（まとめ）
前述したように、バッチ管理サーバ１０４は、バッチ実行周期の間に、データソースとしての業務サービスＤＢ１０７の更新データを定期的に抽出してテーブル差分管理ＤＢ１１０に反映し、その都度、更新データをバッチ処理クラスタ１１５の分散ファイルシステムに反映する。この結果、バッチ処理の実行開始時に分散ファイルシステムに転送されるデータ量を削減することができ、バッチ処理に要する時間を大幅に短縮することができる。
【００４９】
また、本実施例の場合、バッチ処理クラスタ１１５は、バッチ処理を開始する前にバッチ処理入力データについてハッシュ値を計算し、バッチ管理サーバ１０４で管理するハッシュ値と照合し、問題がある場合には事前に修正処理を実行する。これにより、バッチ処理クラスタ１１５を構成する分散ファイルシステムの信頼性に問題がある場合でも、バッチ処理入力データの信頼性を保証することができる。
【００５０】
以上により、業務システムにおけるデータベースのデータを正確かつ高速にバッチできる、安価なバッチ処理システムを実現することができる。
【００５１】
［他の実施例］
本明細書で提案する発明は、上述した形態例に限定されるものでなく、様々な変形が考えられる。例えば、上述した実施例は、発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成・機能を備える必要は無い。また、実施例の構成に既知の構成を追加したり、実施例の一部の構成を削除又は置換することもできる。
【００５２】
また、上述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路その他のハードウェアとして実現しても良い。また、前述の実施例では、各サーバを構成するコンピュータによるプログラムの実行を通じ、各機能を実現する場合について説明したが、各機能をモジュール基板やＡＳＩＣ等のハードウェア資源を通じて実現しても良い。
【００５３】
また、制御線や情報線は、説明上必要と考えられるものを示すものであり、製品上必要な全ての制御線や情報線を表すものでない。実際にはほとんど全ての構成が相互に接続されていると考えて良い。
【符号の説明】
【００５４】
１０１…利用者端末、１０２…ＬＡＮ、１０３…業務サーバ、１０４…バッチ管理サーバ、１０５…バッチ処理サーバ、１０６…業務サービス、１０７…業務サービスＤＢ、１０８…トランザクションログ、１０９…バッチ管理サービス、１１０…テーブル差分管理ＤＢ、１１１…ハッシュ値管理ＤＢ、１１２…バッチアプリケーション、１１３…分散処理フレームワーク、１１４…二次記憶装置、１１５…バッチ処理クラスタ、２０１…バッチ処理入力データ、２０２…バッチ処理出力データ、４０１…会員番号、４０２…氏名、４０３…月別購入金額、４０４…更新フラグ、５０１…テーブルＩＤ、５０２…開始エントリＩＤ、５０３…終了エントリＩＤ、５０４…ハッシュ値。
【図１】
2014041501.tif 000003
【図２】
2014041501.tif 000004
【図３】
2014041501.tif 000005
【図４】
2014041501.tif 000006
【図５】
2014041501.tif 000007
【図６】
2014041501.tif 000008
【図７】
2014041501.tif 000009