(57)【要約】【課題】分割処理を高速化する。【解決手段】処理対象である、バイナリデータが複数に分割された部分バイナリデータのデータ区切り位置を、バイナリデータを構成する所定のデータの特性に基づき検出する検出部２３と、検出したデータ区切り位置を示す情報を記憶手段に登録する登録部２２，２４と、記憶手段に登録された他の部分バイナリデータに関するデータ区切り位置を示す情報に基づき、検出したデータ区切り位置が正当であるかを判定する判定部２５とを備える。【選択図】図１
2015170170.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
処理対象である、バイナリデータが複数に分割された部分バイナリデータのデータ区切り位置を、前記バイナリデータを構成する所定のデータの特性に基づき検出し、
検出したデータ区切り位置を示す情報を記憶手段に登録し、
前記記憶手段に登録された他の部分バイナリデータに関するデータ区切り位置を示す情報に基づき、前記部分バイナリデータにおいて検出したデータ区切り位置が正当であるかを判定する
処理を実行させることを特徴とする、データ分割処理プログラム。
【請求項２】
前記処理対象の部分バイナリデータについて検出したデータ区切り位置と、前記記憶手段に登録された、前記バイナリデータにおいて前記処理対象の部分バイナリデータと隣接する部分バイナリデータについてのデータ区切り位置とが連続する場合に、検出したデータ区切り位置が正当であると判断する
処理を前記コンピュータに実行させることを特徴とする、請求項１記載のデータ分割処理プログラム。
【請求項３】
前記部分バイナリデータを構成する個々の単位レコードに含まれるデータ長情報に基づき、当該部分バイナリデータの位置を特定する
処理を前記コンピュータに実行させることを特徴とする、請求項１又は２記載のデータ分割処理プログラム。
【請求項４】
正当であると判断された前記データ区切り位置に基づき、前記バイナリデータのデータ区切り位置を確定する
処理を前記コンピュータに実行させることを特徴とする、請求項１〜３のいずれか１項に記載のデータ分割処理プログラム。
【請求項５】
バイナリデータを複数に分割した部分バイナリデータを処理するデータ分割処理装置であって、
処理対象の部分バイナリデータのデータ区切り位置を、前記バイナリデータを構成する所定のデータの特性に基づき検出する検出部と、
検出したデータ区切り位置を示す情報を記憶手段に登録する登録部と、
前記記憶手段に登録された他の部分バイナリデータに関するデータ区切り位置を示す情報に基づき、前記部分バイナリデータにおいて検出したデータ区切り位置が正当であるかを判定する判定部と、
を備えることを特徴とする、データ分割処理装置。
【請求項６】
バイナリデータを複数に分割して複数の処理部により処理する分割処理方法であって、
前記複数の処理部のそれぞれに、前記バイナリデータの一部である部分バイナリデータをそれぞれ割り当て、
前記複数の処理部はそれぞれ、割り当てられた部分バイナリデータのデータ区切り位置を、前記バイナリデータを構成する所定のデータの特性に基づき検出するとともに、検出したデータ区切り位置を示す情報を記憶手段に登録し、
前記複数の処理部はそれぞれ、他の処理部により前記記憶手段に登録されたデータ区切り位置を示す情報に基づき、前記部分バイナリデータにおいて検出したデータ区切り位置が正当であるかを判定する
ことを特徴とする、データ分割処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ分割処理プログラム，データ分割処理装置及びデータ分割処理方法に関する。
【背景技術】
【０００２】
近年、ウェブデータ等の大量のデータを処理するための処理システムとして、マップ−リデュース（Map-Reduce）型の分散処理システムが知られている。
マップ−リデュース型の分散処理システムにおいては、分散処理システム上のデータをデータブロックと呼ばれる単位に分割し、これらのデータブロックに対してマップ処理及びリデュース処理を順次適用する。
【０００３】
このようなマップ−リデュース型の分散処理システムによれば、各データブロックに対する一連の計算処理を複数の計算ノードで同時に分散して実行することが可能となる。
Hadoop（登録商標）は大規模データを効率的に分散処理・管理するためのＯＳＳ（Open Source Software）のフレームワークであり、主に分析処理で活用されている。このHadoopを基幹系のバッチ処理に適用することにより、データを複数のマシンに分散して処理させ、処理時間が課題となっている大規模バッチ処理の高速化が実現できる。
【０００４】
Hadoopにおいては、マスタノードが複数のスレーブノードにタスクをそれぞれ割り当て、スレーブノードは、マスタノードから割り当てられたマップタスク（Mapタスク）を実行する。
Hadoopでは、ファイルを一定のサイズのブロックに分割し、そのブロック毎にマップタスクで処理を行う。
【０００５】
図１５はHadoopのマップ−リデュースフレームワークの動作概要を示す図である。図１５に示す例においては、Hadoop分散ファイルシステム（HDFS：Hadoop Distributed File System）によって管理される１９６ＭＢのファイルが６４ＭＢのデータサイズを有する３つのブロックに分割され、それらを３つのマップタスクで並列に処理している。マップタスクから出力されたデータは、Shuffle&sortやReduceタスクを経て、ソートされた結果ファイルとして出力され、ＨＤＦＳに戻される。
【０００６】
このような分散処理システムにおいて、ファイルが分割されてもデータ自体は分割されないことが重要である。例えるならば、マップタスクに渡される「みかん」というデータが、「みか」と「ん」に分かれてはならない。このように一体として扱われるべきデータが分割されてしまうことを泣き別れという場合がある。
このため、６４ＭＢでファイル分割が行なわれた後、データの区切り位置を調整する必要がある。Hadoopのデフォルトでは、データの区切りとして改行コードを用い、この改行コードの位置を区切りとして処理することで、データの泣き別れを防いでいる。この区切りの調整処理はカスタマイズ可能であり、例えば任意の文字を区切りとするような、カスタマイズが可能になっている。
【０００７】
図１６はNetCOBOLの可変長レコード順ファイルのフォーマットを例示する図である。
NetCOBOLの可変長レコード順ファイルは、この図１６に示すように、データの前後に４バイトのレコード長情報を有する可変長レコードを複数連続することにより構成されている。データは利用者が設定する任意のバイナリ値である。また、データの前後に配置されるレコード長には同一の値が格納される。
【０００８】
なお、利用者はレコード長情報を設定・参照する必要はなく、COBOLランタイムシステムが参照・設定を行なう。
図１７はNetCOBOLの可変長レコード順ファイルのレコードイメージを示す図である。
この図１７に示す例においては、１つの可変長レコード毎に改行して見やすくしているが、実際は複数の可変長レコードが連続している。
【０００９】
NetCOBOLの可変長レコード順ファイルをHadoopで利用する場合、ブロック単位でファイル分割が行われた後、データの区切りを調整することができない。これは、データが利用者が任意に設定可能なバイナリ値であり、改行コードや任意の文字を区切りとする場合に、データ内にこれらの改行コードや区切り文字と同じ情報が含まれるおそれがあり、データの区切り位置を特定できないためである。
【００１０】
図１８はNetCOBOLの可変長レコード順ファイルを２つに分割する場合のレコードイメージを示す図である。
この図１８に示す例においては、ファイルを６４ＭＢのブロックサイズ単位で分割する場合に、データ長が１０５バイトのデータが、その途中で分断されてしまうことを示す。
そこで、NetCOBOLでは、レコードの位置を正しく求めてデータ区切り位置を調整するために、ブロックサイズによる分断位置から次の可変長レコードの先頭位置までの距離（バイト長）を保持する情報ファイルを予め作成し、この情報ファイルを区切りの調整処理で参照する手法が用いられる。
【００１１】
図１９はNetCOBOLの可変長レコード順ファイルと情報ファイルとを示す図である。
情報ファイルは、入力ファイルである可変長レコード順ファイルを読み込んでレコード長を加算し、ブロックサイズで分断される位置から次のレコード先頭位置までの情報を保持する。
図１９に示す例においては、情報ファイルにおいて、例えばファイルを先頭から６４ＭＢの位置で分割する場合に、その分断位置から次の可変長レコード（データ長が２０バイト）の先頭までのデータ長が５５バイトであることを示す。なお、情報サイズ作成時には、ブロックサイズもパラメータで指定する必要がある。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２０１２−１１８６６９号公報
【特許文献２】特表平１０−５００７９３号公報
【特許文献３】特開平３−６２１３７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
しかしながら、このような従来の分散処理システムにおいては、上述した情報ファイルを作成するために、処理対象ファイル全体を、その先頭から可変長レコードのレコード長を順次取り出して加算することで区切り位置を求める。このため、例えば、データサイズが数十〜数百ＧＢであり、レコード件数が数百万件程度の大きなサイズのファイルでは、情報ファイルの作成処理に時間がかかってしまう。例えば８０ＧＢのデータサイズのファイルにおいては、情報ファイルの作成に例えば１５分程度の時間を要する場合もある。
【００１４】
これにより、本来は処理時間の高速化を目的としてHadoopを導入するにもかかわらず、情報ファイルの作成に時間を要し、全体の処理時間で考えるとHadoopによる時間短縮効果が薄れてしまうという課題がある。
１つの側面では、本発明は、分割処理を高速化できるようにすることを目的とする。
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。
【課題を解決するための手段】
【００１５】
このため、このデータ分割処理方法は、バイナリデータを複数に分割して複数の処理部により処理する分割処理方法であって、前記複数の処理部のそれぞれに、前記バイナリデータの一部である部分バイナリデータをそれぞれ割り当て、前記複数の処理部はそれぞれ、割り当てられた部分バイナリデータのデータ区切り位置を、前記バイナリデータを構成する所定のデータの特性に基づき検出するとともに、検出したデータ区切り位置を示す情報を記憶手段に登録し、前記複数の処理部はそれぞれ、他の処理部により前記記憶手段に登録されたデータ区切り位置を示す情報に基づき、前記部分バイナリデータにおいて検出したデータ区切り位置が正当であるかを判定する。
【発明の効果】
【００１６】
一実施形態によれば、分割処理を高速化することができる。
【図面の簡単な説明】
【００１７】
【図１】実施形態の一例としての分散処理システムの機能構成を模式的に示す図である。
【図２】実施形態の一例としての分散処理システムのサーバのハードウェア構成を例示する図である。
【図３】実施形態の一例としての分散処理システムにおけるノード間共有情報を例示する図である。
【図４】実施形態の一例としての分散処理システムにおける特定部による区切り位置の特定方法を説明するための図である。
【図５】実施形態の一例としての分散処理システムにおける分割ファイルの区切り位置の調整方法を説明するフローチャートである。
【図６】実施形態の一例としての分散処理システムにおけるファイル読込部によるファイルの読み込み処理を説明するフローチャートである。
【図７】実施形態の一例としての分散処理システムにおけるファイル先頭記録部による処理を説明するフローチャートである。
【図８】実施形態の一例としての分散処理システムにおける整合性判定部及びファイル終端記録部による処理を説明するフローチャートである。
【図９】実施形態の一例としての分散処理システムにおける解析対象ファイルを例示する図である。
【図１０】実施形態の一例としての分散処理システムにおける解析対象ファイルの分割処理を説明するための図である。
【図１１】実施形態の一例としての分散処理システムにおける解析対象ファイルの分割処理を説明するための図である。
【図１２】実施形態の一例としての分散処理システムにおける解析対象ファイルの分割処理を説明するための図である。
【図１３】実施形態の一例としての分散処理システムの特定部が犯しうる区切り位置の誤検知を例示する図である。
【図１４】MicroFocusのレコード順ファイルの構成を例示する図である。
【図１５】Hadoopのマップ−リデュースフレームワークの動作概要を示す図である。
【図１６】NetCOBOLの可変長レコード順ファイルのフォーマットを例示する図である。
【図１７】NetCOBOLの可変長レコード順ファイルのレコードイメージを示す図である。
【図１８】NetCOBOLの可変長レコード順ファイルを２つに分割する場合のレコードイメージを示す図である。
【図１９】NetCOBOLの可変長レコード順ファイルと情報ファイルとを示す図である。
【発明を実施するための形態】
【００１８】
以下、図面を参照して本データ分割処理プログラム，データ分割処理装置及びデータ分割処理方法に係る実施の形態を説明する。ただし、以下に示す実施形態はあくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。又、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能等を含むことができる。
【００１９】
図１は実施形態の一例としての分散処理システム１の機能構成を模式的に示す図、図２はそのサーバのハードウェア構成を例示する図である。
本分散処理システム１は、複数（図１に示す例では４つ）のサーバ（計算ノード，ノード）１０−１〜１０−４をそなえ、これらの複数のサーバ１０−１〜１０−４で分散して処理を行なう。本分散処理システム１は、例えばHadoop（登録商標）を用いて分散処理を実現するマップ−リデュースシステムである。Hadoopはデータ（ファイル）を複数のマシンに分散して処理させるオープンソースのプラットフォームであり、公知の技術であるので、その詳細な説明は省略する。
【００２０】
また、本実施形態においては、処理対象のファイルが、図１６，図１７等に例示したNetCOBOLの規格に沿った可変長レコードファイル（以下、単にファイルという）である例について説明する。すなわち、処理対象のファイルはバイナリデータであり、また、処理対象のファイルは、複数の可変長レコード（単位レコード）を連続することにより構成されている。さらに、個々の可変長レコードにおいては、データの前後に当該データのデータ長を示すレコード長情報が配置されているというデータ構造上の特性（規則性）を有する。なお、可変長レコードにおけるデータよりも前側のレコード長情報を前側レコード長情報といい、データよりも後側に位置するレコード長情報を、後側レコード長情報という場合がある。
【００２１】
各サーバ１０−１〜１０−４はネットワーク５０を介して相互に通信可能に接続されている。ネットワーク５０は、例えばＬＡＮ（Local Area Network）等の通信回線である。
サーバ１０−１〜１０−４は、それぞれサーバ機能をそなえたコンピュータ（情報処理装置，処理部）である。各サーバ１０−１〜１０−４は、同様の構成を備える。以下、サーバを示す符号としては、複数のサーバのうち１つを特定する必要があるときには符号１０−１〜１０−４を用いるが、任意のサーバを指すときには符号１０を用いる。
【００２２】
また、図１に示す例においては、サーバ１０−１がマスタノードとして機能し、サーバ１０−２〜１０−４がスレーブノードとして機能する。以下、サーバ１０−１をマスタノードＭＮという場合があり、サーバ１０−２〜１０−４をそれぞれスレーブノードＳＮという場合がある。
マスタノードＭＮは、本分散処理システム１における処理を管理する装置であり、複数のスレーブノードＳＮにタスクをそれぞれ割り当てる。スレーブノードＳＮは、マスタノードＭＮから割り当てられたマップタスク（Mapタスク；以下、単にタスクという）を実行する。タスクを分散して割り当てられた複数のスレーブノードＳＮが、それぞれ割り当てられたタスクを並行して実行することによりジョブの処理時間を短縮する。
【００２３】
なお、図１に示す例においては、マスタノードＭＮもタスクトラッカ１３（後述）としての機能を備えており、このマスタノードＭＮにおいても割り当てられたタスクの実行を行なう機能を備えている。従って、図１に例示する分散処理システム１においては、サーバ１０−１もスレーブノードＳＮとして機能する。
また、本実施形態においては、各スレーブノードＳＮが、それぞれマップタスクを実行するものとする。
【００２４】
サーバ１０は、例えばサーバ機能をそなえたコンピュータ（情報処理装置，データ分割装置，処理部）である。サーバ１０は、図２に示すように、ＣＰＵ（Central Processing Unit）２０１，メモリ２０２，表示装置２０５，キーボード２０６，マウス２０７及び記憶装置２０８を備える。
メモリ２０２はＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）を含む記憶装置である。メモリ２０２のＲＯＭには、分散処理制御に係るソフトウェアプログラムやこのプログラム用のデータ類が書き込まれている。メモリ２０２上のソフトウェアプログラムは、ＣＰＵ２０１に適宜読み込まれて実行される。また、このメモリ２０２のＲＡＭには、後述するノード間共有情報１５が格納される。
【００２５】
また、メモリ２０２のＲＡＭは、一次記憶メモリあるいはワーキングメモリとして利用される。さらに、メモリ２０２のＲＡＭは、分割するファイルを格納する図示しないバッファ領域としても機能する。
表示装置２０５は、例えば、液晶ディスプレイやＣＲＴ（Cathode Ray Tube）ディスプレイであり、種々の情報を表示する。
【００２６】
キーボード２０６及びマウス２０７は入力装置であり、利用者がこれらの入力装置を用いて、種々の入力操作を行なう。例えば、マスタノードＭＮにおいて、利用者は、これらのキーボード２０６やマウス２０７を用いて、例えば、処理対象のファイルの指定や処理内容の指定（入力）を行なう。
記憶装置２０８は種々のデータやプログラムを格納する記憶装置であって、例えば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）である。又、記憶装置２０８は、例えば、複数のＨＤＤを組み合わせて、冗長化された１つのストレージとして管理するＲＡＩＤ（Redundant Arrays of Inexpensive Disks）装置であってもよい。
【００２７】
ＣＰＵ２０１は、種々の制御や演算を行なう処理装置であり、メモリ２０２に格納されたプログラムを実行することにより、種々の機能を実現する。
マスタノードＭＮにおいて、ＣＰＵ２０１は、図１に示す、ユーザアプリケーション機能部１１，ファイル管理部１２，ジョブトラッカ１４及びタスクトラッカ１３として機能する。
【００２８】
なお、これらのユーザアプリケーション機能部１１，ファイル管理部１２，ジョブトラッカ１４及びタスクトラッカ１３としての機能を実現するためのプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷ等），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ＋Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋ＲＷ，ＨＤ  ＤＶＤ等），ブルーレイディスク，磁気ディスク，光ディスク，光磁気ディスク等の、コンピュータ読取可能な記録媒体に記録された形態で提供される。そして、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。又、そのプログラムを、例えば磁気ディスク，光ディスク，光磁気ディスク等の記憶装置（記録媒体）に記録しておき、その記憶装置から通信経路を介してコンピュータに提供してもよい。
【００２９】
ユーザアプリケーション機能部１１，ファイル管理部１２，ジョブトラッカ１４及びタスクトラッカ１３としての機能を実現する際には、内部記憶装置（本実施形態ではメモリ２０２）に格納されたプログラムがコンピュータのマイクロプロセッサ（本実施形態ではＣＰＵ２０１）によって実行される。このとき、記録媒体に記録されたプログラムをコンピュータが読み取って実行してもよい。
【００３０】
同様に、スレーブノードＳＮにおいても、ＣＰＵ２０１が、プログラムを実行することにより、タスクトラッカ１３及びファイル管理部１２として機能する。
ユーザアプリケーション機能部１１は、ユーザからのジョブ依頼を受け付け、マップリデュースジョブ（Map-Reduceジョブ；以下、単にジョブという）を生成し、ジョブトラッカ１４にジョブを投入（ジョブ登録）する。
【００３１】
ユーザアプリケーション機能部１１は、ユーザがキーボード２０６やマウス２０７を用いて処理対象ファイルの指定や処理内容（指示内容）を入力すると、この入力された情報に基づいてジョブを生成する。
ジョブトラッカ１４は、ユーザアプリケーション機能部１１によって行なわれたジョブ登録に基づいて、クラスタ中の利用可能なタスクトラッカ１３にタスクを割り当てる、割り当て制御部としての機能を備える。
【００３２】
タスクトラッカ１３は、ジョブトラッカ１４から割り当てられたタスクを処理する。
なお、これらのユーザアプリケーション機能部１１，ジョブトラッカ１４及びタスクトラッカ１３としての機能は既知の種々の手法で実現することができ、その詳細な説明は省略する。
ファイル管理部１２は、処理対象のファイルを複数のサーバ１０の記憶装置２０８に分散して格納させる。以下、サーバ１０の記憶装置２０８にデータを格納することを、単にサーバ１０にデータを格納すると表現する。図１に示す例においては、サーバ１０−１にファイル１が、サーバ１０−２にファイル４が、サーバ１０−３にファイル２，５が、サーバ１０−４にファイル３が、それぞれ格納されている。
【００３３】
また、ファイル管理部１２は、処理対象のファイル（データ）を所定サイズ（例えば６４ＭＢ）の断片（データブロック，ブロック）に分割して、各ノードの記憶装置２０８に格納させる。すなわち、ファイル管理部１２はバイナリデータであるファイルを複数のブロック（部分バイナリデータ）に分割する分割処理部２０としての機能を備える。また、この分割処理部２０としての機能を備えるサーバ１０は、ファイルを複数に分割した分割ファイルを処理するデータ分割処理装置として機能する。以下、分割されたファイルの個々の部分を分割ファイルという場合がある。
【００３４】
さらに、分割処理部２０は、割り当てられた分割ファイルに含まれる全ての可変長レコードが、その途中で分断されることがないように、分割ファイルの区切り位置を調整する機能を備える。
分割処理部２０は、割り当てられた分割ファイルが可変長レコードの途中で分断されている場合、すなわち、分割ファイルの先頭や終端の区切り位置が可変長レコードの途中に位置する場合には、その区切り位置をずらす。これにより、分割ファイル中に含まれる全ての可変長レコードが、それぞれ２つのレコード長とデータ（レコードデータ）とを含むようにする。つまり、分割ファイル中の可変長レコードが連続する２つの分割ファイルに分かれて格納される（いわゆる泣き別れ状態）となることがないように、区切り位置を調整する。
【００３５】
分割処理部２０は、図１に示すように、ファイル読込部２１，ファイル先頭記録部２２，特定部２３，ファイル終端記録部２４及び整合性判定部２５を備える。
ファイル読込部２１は、メモリ２０２の図示しないバッファ領域に、ユーザアプリケーション機能部１１によって指定されたファイルのデータを格納する。また、ファイル読込部２１は、ファイルのデータをバッファ領域に読み込むに際して、バッファ領域の初期化も行なう。
【００３６】
ファイル先頭記録部２２は、ファイルの先頭位置を示す情報をノード間共有情報１５に記録する。
ノード間共有情報１５は、サーバ１０（ノード）間で共有される情報であって、各サーバ１０が、自らに割り当てられた分割ファイル（タスク）について区切り位置の調整後の先頭位置と終端位置とをそれぞれ記録する。
【００３７】
図３は実施形態の一例としての分散処理システム１におけるノード間共有情報１５を例示する図である。
この図３に示す例においては、ノード間共有情報１５は、タスク番号に対して開始位置及び終端位置を関連付けて構成されている。
タスク番号は、サーバ１０に割り当てられるタスクを特定する識別情報であり、タスクとは分割ファイルを示す。図３に示す例においてはタスク番号として１〜３の整数が用いられている。ただし、タスク番号は整数に限定されるものではなく、任意の文字列等を用いてもよく、種々変形して実施することができる。なお、以下、タスク番号のことをタスクＩＤという場合がある。
【００３８】
開始位置は分割ファイルの開始位置を示す情報であり、終端位置は分割ファイルの終端位置を示す情報である。これらの開始位置及び終了位置としては、例えば、分割前のファイルの先頭位置を基準（例えば０）とするアドレス情報が用いられる。
このように、ノード間共有情報１５を格納するメモリ２０２は、検出した区切り位置を示す情報（確定レコード先頭位置，確定レコード終端位置）を記憶する記憶手段として機能する。また、このノード間共有情報１５に開始位置（確定レコード先頭位置）や終端位置（確定レコード終端位置）を記憶するファイル先頭記録部２２やファイル終端記録部２４は、検出した区切り位置を示す情報をメモリ２０２に登録する登録部として機能する。
【００３９】
なお、ノード間共有情報１５は、例えば、マスタノードＭＮのメモリ２０２に格納され、各サーバ１０はこのマスタノードＭＮに格納されたノード間共有情報１５に対して更新や参照を行なう。すなわち、各サーバ１０がノード間共有情報１５を共用する。
ただし、ノード間共有情報１５の格納場所はマスタノードＭＮに限定されるものではなく、種々変形して実施することができる。例えば、いずれかのスレーブノードＳＮにノード間共有情報１５を格納してもよく、又、図示しない他の情報処理装置がノード間共有情報１５を格納してもよい。また、各サーバ１０が、それぞれノード間共有情報１５を備え、サーバ間通信を行なうことで各サーバ１０が有するノード間共有情報１５を同期させてもよい。
【００４０】
ファイル先頭記録部２２は、後述する特定部２３により特定される分割ファイル（タスク）の先頭位置を、ノード間共有情報１５にその分割ファイルのタスク番号に対応付けて開始位置として記録する。
ファイル終端記録部２４は、特定部２３が特定した分割ファイルの終端位置（確定レコード終端位置）を示す情報を、ノード間共有情報１５に終端位置として記録する。
【００４１】
特定部２３は分割ファイルのデータ構成上の特性（規則性）に基づき、分割ファイルに含まれる可変長レコードの位置（レコード位置，データ区切り位置）を特定するものであり、分割ファイルを構成する可変長レコード（所定のデータ）の特性に基づき、データ区切り位置を検出する。
特定部２３は、可変長レコードのヘッダに含まれるデータ長情報に基づき、当該可変長レコードと、後続する可変長レコードとの境界位置を特定する。すなわち、特定部２３は、可変長レコードのヘッダに含まれるデータ長情報に基づき、当該可変長レコードの位置を特定する。つまり、特定部２３は、可変長レコードにおいては、データの前後に当該データのデータ長を示すレコード長情報が配置されているというデータ構造上の特性に基づき、可変長レコードの位置を特定する。
【００４２】
特定部２３がバッファ領域に格納された分割ファイルをその先頭から走査し、この分割ファイル内において、先頭の可変長レコードの位置を特定すると、当該可変長レコードに後続する各可変長レコードについては、そのデータ長を順次参照することでそれぞれの位置を特定することができる。従って、分割ファイルに含まれる複数の可変長レコードのうち、その先頭の可変長レコードの前側レコード長情報の開始位置を特定することにより、当該分割ファイルに含まれる全ての可変長レコードの位置を特定することができる。これにより、分割ファイルの最後尾に位置する可変長レコードの終端位置も特定することができる。すなわち、特定部２３は、バッファ領域に格納された分割ファイルについて、当該分割ファイルに含まれる各可変長レコードを順次認識することで、その終端位置を特定する。
【００４３】
なお、バッファ領域における分割ファイルの走査位置は、例えば、図示しないポインタにより特定することができる。又、バッファ領域において、分割ファイルの先頭から終端に向かう方向を走査方向という場合がある。
特定部２３は、例えば、以下の（Ａ１）〜（Ａ６）の処理を行なうことで、分割ファイルの区切り位置を特定する。
【００４４】
図４は実施形態の一例としての分散処理システム１における特定部２３による区切り位置の特定方法を説明するための図である。なお、図４中においては、便宜上、マップタスク２について示し、マップタスク１，３についての図示を省略する。
（Ａ１）特定部２３は、分割ファイルが格納されたバッファ領域の先頭から４バイトを読み出す。処理対象のファイル中における、この読み出した４バイトのデータ位置を仮先頭位置とする。
【００４５】
（Ａ２）特定部２３は、４バイトの値（Ｘ）を解析して、このデータがレコード長であるか否かを確認する。
具体的には、特定部２３は、先ず、取得した４バイトの値（Ｘ）を符号なし整数値として、０＜Ｘ＜32768 の範囲内かどうか確認する。ここで、Ｘの上限値として32767と比較するのは、ＣＯＢＯＬのレコード長の最大値が32767だからである。
【００４６】
４バイトの値が０＜Ｘ＜32768の範囲外の場合は、この４バイトの値（Ｘ）はレコード長を表すものではないと判断できる。この場合、特定部２３は、バッファ領域において読み出しの先頭位置を走査方向に１バイトずらして、新たな４バイトのデータを読み出し、再度（Ａ２）の処理を実施する。４バイトの値が０＜Ｘ＜32768の範囲内の場合は、（Ａ３）の処理に移行する。
【００４７】
（Ａ３）取得した４バイトの値（図４に示す例では“２０００”）がレコード長情報であると仮定して、バッファ領域において、走査方向に、このレコード長情報が示すレコード長分進んだ位置（バッファ位置）に、同一の値のレコード長情報（後側レコード長情報）が存在するか確認する。
すなわち、バッファ領域において、走査方向に、このレコード長分進んだ位置から４バイトのデータを読み出し、先に取得した４バイトの値と同一であるか否かを確認する。
【００４８】
レコード長（２０００バイト）だけ進んだバッファ位置に同じレコード長（“２０００”）が存在しない場合は、取得した４バイトの値はレコード長ではなかったと判断され、（Ａ２）の処理に戻る。一方、レコード長（２０００バイト）だけ進んだバッファ位置に同じレコード長（“２０００”）が存在する場合は、レコード位置が検出できたものとして（Ａ４）の処理に移行する。
【００４９】
（Ａ４）取得した４バイトの値がレコード長であると想定し、そのレコード先頭位置（確定レコード先頭位置）をファイル先頭記録部２２に通知する。
（Ａ５）ファイル先頭記録部２２は、通知された確定レコード先頭位置を、当該分割ファイルに相当するタスク番号に関連づけてノード間共有情報１５に記録する。
また、正しいレコードの開始位置が判明したものとしてレコードの読み込み処理を行なう。すなわち、分割ファイルを構成する各可変長レコードのデータを、先頭から順次読み出す。この際、各可変長レコードについて、ヘッダに含まれるレコード長とデータのレコード長との整合性を確認しながら読み込みを行なう。
【００５０】
不整合が検出された場合には、上記（Ａ３）〜（Ａ５）における処理結果を破棄し、バッファ領域において読み出しの先頭位置を１バイトずらして、新たな４バイトのデータを読み出し、（Ａ２）の処理からやり直す。
（Ａ６）解析対象の分割ファイルの終端位置まで到達したら、特定部２３は、その終端位置を示す情報を確定レコード終端位置としてファイル終端記録部２４に通知する。
【００５１】
上述した確定レコード先頭位置及び確定レコード終端位置が、当該分割ファイルの区切り位置として用いられる。
従って、特定部２３は、処理対象の分割ファイル（部分バイナリデータ）のデータ区切り位置を、バイナリデータを構成する可変長レコードの構造上の特性に基づき検出する検出部として機能する。
【００５２】
その後、後述する整合性判定部２５が、ノード間共有情報１５を参照し、他のマップタスクで検出し記録した分割ファイルの位置との整合性チェックを行なう。
整合性判定部２５は、特定部２３によって特定された分割ファイルの位置と、他のマップタスクにおいて特定された分割ファイルの位置とを比較することにより、特定した分割ファイルの区切り位置の整合性を判定する。
【００５３】
整合性判定部２５は、ノード間共有情報１５を参照することで、特定部２３によって特定された確定レコード先頭位置と、他のマップタスクで検出し記録した分割ファイルの終端位置との整合性を確認する。
具体的には、整合性判定部２５は、特定部２３によって特定された確定レコード先頭位置を、処理対象のファイルにおいて、当該分割ファイルよりも前側（先行して）に隣接する他の分割ファイルを処理するマップタスクについてノード間共有情報１５に記録されている分割ファイルの終端位置（確認レコード終端位置）と比較する。この比較の結果、先行する分割ファイルの確認レコード終端位置が、当該マップタスクにおいて特定される確定レコード先頭位置と連続している場合に、整合性判定部２５は整合性があると判断する。
【００５４】
従って、整合性判定部２５は、メモリ２０２に登録された他の分割ファイル（部分バイナリデータ）に関する区切り位置を示す情報に基づき、検出した区切り位置が正当であるかを判定する判定部として機能する。
整合性判定部２５により整合性があると判定されると、分割処理部（確定部）２０は、確定レコード先頭位置と確定レコード終端位置とを分割ファイルのデータ区切り位置として確定する。すなわち、分割ファイルのデータ範囲は、確定レコード先頭位置が先頭であり、且つ、確定レコード終端位置が終端となるよう修正される。
【００５５】
従って、分割処理部２０は、判定されたデータ区切り位置に基づき処理対象のファイル（バイナリデータ）の区切り位置を確定する確定部として機能する。
このようにファイル管理部１２（分割処理部２０）によりデータの区切り位置が修正された分割ファイルは、タスクトラッカ１３に受け渡され、処理される。
上述の如く構成された実施形態の一例としての分散処理システム１における分割ファイルの区切り位置の調整方法を、図５に示すフローチャート（ステップＢ１〜Ｂ１２）に従って説明する。
【００５６】
ステップＢ１において、ファイル読込部２１は、メモリ２０２の図示しないバッファ領域に、ユーザアプリケーション機能部１１によって指定されたファイルのデータを格納する。
このステップＢ１における、ファイル読込部２１によるファイルの読み込み処理を、図６に示すフローチャート（ステップＢ１０１〜Ｂ１０２）に従って説明する。
【００５７】
ファイル先頭記録部２２は、ステップＢ１０１においてメモリ２０２のバッファ領域を初期化した後、ステップＢ１０２において、ユーザアプリケーション機能部１１によって指定されたファイルからバッファ単位でバッファ領域にデータを読み込む。
次に、図５のステップＢ２において、ファイル先頭記録部２２が、ファイルの先頭位置を示す情報をノード間共有情報１５に記録する。
【００５８】
このステップＢ２における、ファイル先頭記録部２２による処理を、図７に示すフローチャート（ステップＢ２０１〜Ｂ２０３）に従って説明する。
先ず、ステップＢ２０１において、ファイル先頭記録部２２は、処理中のタスク（分割ファイル）を特定するタスクＩＤを取得する。このタスクＩＤは、例えば、ユーザアプリケーション機能部１１から取得してもよく、又、ファイル管理部１２等が任意に設定してもよい。
【００５９】
ステップＢ２０２において、ファイル先頭記録部２２は、ノード間共有情報１５に接続して、ステップＢ２０３において、タスクＩＤと処理対象の分割ファイルの先頭の位置を示す情報とをノード間共有情報１５に記録する。
次に、図５のステップＢ３において、ファイル読込部２１は、処理対象の分割ファイルにおける終端位置であるか否かを確認する。すなわち、バッファ領域に展開された処理対象の分割ファイルにおいて、処理中（走査中）位置を示すポインタが分割ファイルの終端に到達しているか否かを確認する。
【００６０】
確認の結果、分割ファイルの終端に到達していない場合には（ステップＢ３のＮｏルート参照）、ステップＢ４において、特定部２３は、ポインタ位置から４バイトの値を読み出し、この４バイトの値に対して終端位置の判定処理を開始する。
ステップＢ５において、取得した４バイトの値（Ｘ）を符号なし整数値として、０＜Ｘ＜32768 の範囲内かどうか確認する。
【００６１】
４バイトの値が０＜Ｘ＜32768の範囲内の場合は（ステップＢ５のＹｅｓルート参照）、ステップＢ６において、取得した４バイトの値がレコード長（前側レコード長情報）であると仮定して、バッファ領域において、このレコード長分進んだ位置（バッファ位置）から４バイトの値を読み出す。
ステップＢ７において、ステップＢ４で取得した４バイトの値と、ステップＢ６でレコード長だけ進んだバッファ位置から取得した、後側レコード長情報と仮定される４バイトの値とが同一であるか否かを確認する。
【００６２】
ステップＢ４で取得した４バイトの値と、ステップＢ６で取得した４バイトの値とが同一である場合には（ステップＢ７のＹｅｓルート参照）、ステップＢ８に移行する。すなわち、ステップＢ４において、可変長レコードにおけるレコード長を正しく検出できたものとして、その可変長レコードからデータ（レコードデータ）を読み出し、ステップＢ３に戻る。
【００６３】
一方、ステップＢ５において４バイトの値が０＜Ｘ＜32768の範囲外の場合や（ステップＢ５のＮｏルート参照）、ステップＢ４で取得した４バイトの値と、ステップＢ６で取得した４バイトの値とが同一でない場合には（ステップＢ７のＮｏルート参照）、ステップＢ９において、分割ファイルにおけるポインタ位置（現在位置）を走査方向に１バイト進めた後、ステップＢ４に戻る。
【００６４】
また、ステップＢ３において、分割ファイルの終端に到達した場合には（ステップＢ３のＹｅｓルート参照）、ステップＢ１０において、整合性判定部２５による終端位置に対する判定（検証）とファイル終端記録部２４による終端位置の記録が行なわれる。
このステップＢ１０における、整合性判定部２５及びファイル終端記録部２４による処理を、図８に示すフローチャート（ステップＢ１１１〜Ｂ１１６）に従って説明する。
【００６５】
ステップＢ１１１において、整合性判定部２５は、処理中のタスク（分割ファイル）を特定するタスクＩＤを取得する。
ステップＢ１１２において、整合性判定部２５はノード間共有情報１５にアクセスして、ステップＢ１１３において、ファイル終端記録部２４が、ノード間共有情報１５にタスクＩＤ及び確定レコード終端位置を記録する。
【００６６】
ステップＢ１１４において、整合性判定部２５は、ステップＢ１１１において取得したタスクＩＤが１であるか否かを確認する。この確認の結果、タスクＩＤが１でない場合には（ステップＢ１１４のＮｏルート参照）ステップＢ１１５において、整合性判定部２５は、ノード間共有情報１５から、処理対象ファイルにおいて、処理中の分割ファイルよりも前側において連続する（すなわち、一つ前の）他の分割ファイルについての、確定レコード終端位置を読み出す。
【００６７】
そして、ステップＢ１１６において、整合性判定部２５は、この取得した一つ前の分割ファイルについての確定レコード終端位置の値に１を加算した値と、当該処理対象ファイルについて特定部２３が特定した確定レコード先頭位置とを比較する。
取得した一つ前の分割ファイルについての確定レコード終端位置の値に１を加算した値と、当該処理対象ファイルについて特定部２３が特定した確定レコード先頭位置とが一致した場合には（ステップＢ１１６のＹｅｓルート参照）、整合性があると判断して処理を終了する。
【００６８】
一方、取得した一つ前の分割ファイルについての確定レコード終端位置の値に１を加算した値と、当該処理対象ファイルについて特定部２３が特定した確定レコード先頭位置とが一致しない場合には（ステップＢ１１６のＮｏルート参照）、整合性がないと判断して処理を終了する。
なお、整合性の判断結果（整合性ありもしくは整合性なし）は、その旨を示す情報（例えばフラグ）をメモリ２０２等の所定の記憶領域に記録することが望ましい。
【００６９】
また、ステップＢ１１４における確認の結果、タスクＩＤが１である場合には（ステップＢ１１４のＹｅｓルート参照）、整合性判定部２５は、整合性があると判断して処理を終了する。ファイルの先頭位置については、先行する分割ファイルは存在しないからである。
その後、図５におけるステップＢ１１において、特定部２３は、整合性判定部２５による判定結果を参照して、整合性があると判断された場合には（ステップＢ１１のＹｅｓルート参照）、処理を終了する。
【００７０】
また、整合性がないと判断された場合には（ステップＢ１１のＮｏルート参照）、ステップＢ１２において、特定部２３は、分割ファイルにおけるポインタ位置（現在位置，確定レコード先頭位置）を走査方向に１バイトずらし、ステップＢ３に戻る。
次に、上述の如く構成された実施形態の一例としての分散処理システム１における解析対象ファイルの分割処理を、図９〜図１２を用いて例示する。図９は解析対象ファイルＦを例示する図である。解析対象ファイルＦは、ＮｅｔＣＯＢＯＬの可変長レコード順ファイルであり、以下においては、この図９に示すように、ファイル管理部１２が、この解析対象ファイル（ファイル）Ｆを、３つの分割ファイルＤＦ１〜ＤＦ３に分割する例を示す。各分割ファイルＤＦ１〜ＤＦ３はそれぞれ６４ＭＢのデータサイズを有する。
【００７１】
図１０，図１１及び図１２は、それぞれ分割ファイルＤＦ１，ＤＦ２及びＤＦ３に対する処理を示す。
分割ファイルＤＦ１はマップタスク１に（図１０参照）、分割ファイルＤＦ２はマップタスク２に（図１１参照）、また、分割ファイルＤＦ３はマップタスク３に（図１２参照）、それぞれ割り当てられ、各マップタスク１〜３によりそれぞれ処理される。
【００７２】
また、各マップタスク１〜３において、割り当てられた分割ファイルＤＦ１〜ＤＦ３は、それぞれに含まれる全ての可変長レコードが、それぞれ途中で分断されることがないように、上述した手法により区切り位置が調整される。
また、その際、各マップタスクにおいては、ファイル先頭記録部２２が、区切り位置の調整後の分割ファイルの確定レコード先頭位置をノード間共有情報１５の開始位置に格納し、又、確定レコード終端位置を、ノード間共有情報１５の終端位置に格納する。
【００７３】
図１０に例示するマップタスク１において処理される分割ファイルＤＦ１は、解析対象ファイルＦの先頭部分であるので、その確定レコード先頭位置は０であり、ノード間共有情報１５のタスク番号１の開始位置には０が登録される。
また、区切り位置の調整後の分割ファイルＤＦ１の終端位置が６４ＭＢ＋９０４Ｂ（バイト）であり、ノード間共有情報１５のタスク番号１の終端位置には６４ＭＢ＋９０４Ｂが登録される。
【００７４】
図１１に例示するマップタスク２において処理される分割ファイルＤＦ２についても同様に、区切り位置の調整後の分割ファイルＤＦ２の確定レコード先頭位置は６４ＭＢ＋９０５Ｂであり、ノード間共有情報１５のタスク番号２の開始位置には６４ＭＢ＋９０５Ｂが登録される。
また、区切り位置の調整後の分割ファイルＤＦ２の終端位置は１２８ＭＢ＋３８１Ｂであり、ノード間共有情報１５のタスク番号２の終端位置には１２８ＭＢ＋３８１Ｂが登録される。
【００７５】
図１２に例示するマップタスク３において処理される分割ファイルＤＦ３についても同様に、区切り位置の調整後の分割ファイルＤＦ３の確定レコード先頭位置は１２８ＭＢ＋３８２Ｂであり、ノード間共有情報１５のタスク番号３の開始位置には１２８ＭＢ＋３８２Ｂが登録される。
また、区切り位置の調整後の分割ファイルＤＦ３の終端位置は１２８ＭＢ＋２０７９Ｂであり、ノード間共有情報１５のタスク番号３の終端位置には１２８ＭＢ＋２０７９Ｂが登録される。
【００７６】
このように、実施形態の一例としての分散処理システム１によれば、各マップタスクにおいて、特定部２３が、バイナリデータである分割ファイルを、そのデータ構成の規則性を用いることで、その区切り位置を特定する。
例えば、分割ファイルを構成する可変長レコードが、データの前後にデータ長を示す情報を有している場合に、バッファ領域に格納された分割ファイルの先頭から走査して、レコード長を示すデータ（前側データ長情報）と想定される部分を検出する。そして、このレコード長と想定されるデータが示す値（データ長）だけ進んだバッファ位置にも、同一のレコード長と想定されるデータ（後側データ長情報）が検出された場合に、可変長レコードのレコード位置が検出できたとみなす。
【００７７】
この可変長レコードのレコード位置の検出を、分割ファイルの終端まで繰り返し行ない、また、途中で不整合が検出された場合には、開始位置を１バイト進めた位置を新たな確定レコード先頭位置としてレコード位置の検出を再度行なう。これにより、データ区切りを検証することができる。
本分散処理システム１によれば、処理対象ファイル全体をその先頭から可変長レコードのレコード長を順次取り出して加算することなく、分割ファイルの区切り位置（分断位置）を容易に特定することができる。従って、マップタスク処理に要する時間を短縮することができ、処理を高速化することができる。
【００７８】
また、分割ファイルのデータ範囲を、確定レコード先頭位置を先頭とし、確定レコード終端位置を終端とするように修正することで、可変長レコードの途中にデータ区切りが位置することがなく、ブロック分割による泣き別れを防止することができる。
このように、処理対象のデータがバイナリデータであっても、データの規則性を利用し、且つ、規則性によるデータ区切りを検証することで、ブロック分割による泣き別れを防止することができる。
【００７９】
また、各マップタスクにおいて、検証されたデータ区切りに基づき、その確定レコード先頭位置と確定レコード終端位置とをノード間共有情報１５に記録する。そして、整合性判定部２５が、このノード間共有情報１５を参照して、隣り合う分割ファイルの終端位置が、確定レコード先頭位置と連続することを確認する。
分割ファイルがバイナリデータであるので、可変長レコードのデータ部分に、レコード長データに似たデータが存在するおそれがある。特定部２３による区切り位置の検証時に、データ中のレコード長に似た値をレコード長と誤認し、更に、そのレコード長に似た値が示すデータ長だけ進んだ位置に、そのレコード長に似た値と同じ値が存在する場合に、区切り位置が誤検知されるおそれがある。
【００８０】
図１３は実施形態の一例としての分散処理システム１の特定部２３が犯しうる区切り位置の誤検知を例示する図である。
分割ファイルが格納されたバッファ領域から読み出した４バイトの値が32768未満の整数値であると、特定部２３は、この値をレコード長と誤検知することになる。なお、図１３中においては、便宜上、マップタスク２についてのみ示し、他のマップタスク１，３について図示を省略する。
【００８１】
図１３に示す例では、バッファ領域から読み出した４バイトの値が“１００”であったとする（符号Ｃ１参照）。なお、この図１３に示す例においては、本来のデータ長は、図中で“１０００”が記載されている部分である。
特定部２３は、取得した４バイトの値（“１００”）がレコード長であると仮定して、バッファ領域において、このレコード長分進んだ位置（バッファ位置）に、同一のレコード長データが存在するか確認する。
【００８２】
そして、この確認の結果、１００バイト進んだ先の４バイトの領域に、偶然、同じく“１００”が格納されている場合に（符号Ｃ２参照）、特定部２３は、レコード位置が検出できたものと判断してしまう。また、これにより、可変長レコードからデータ部分とみなされるデータの読み込みが行なわれる（符号Ｃ３参照）。このようにして読み込まれたデータ中は、本来レコード長を示すデータ“１０００”が含まれる等、正しいデータではない。
【００８３】
また、当該分割ファイルにおけるそれ以降の部分について、各可変長レコードについて、ヘッダに含まれるレコード長とデータのレコード長との整合性を確認しながら読み込みを行なった結果、その終端まで不整合が検出されなかった場合には（符号Ｃ４参照）、読み込まれた誤ったデータが使用されることになる。
このような場合に、特定部２３が確定レコード先頭位置及び確定レコード終端位置をノード間共有情報１５に記録し、整合性判定部２５が、他のノードによってノード間共有情報１５に記録された、当該分割ファイルと連続する他の分割ファイルの確定レコード先頭位置や確定レコード終端位置との連続性を調査することで、特定部２３による誤検知を検知することができるのである（符号Ｃ５参照）。
【００８４】
このように、整合性判定部２５がノード間による整合性の確認を行なうことにより、検出したデータ区切りがファイル全体で整合性を有することを確認することができ、信頼性を向上させることができる。
そして、開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。本実施形態の各構成及び各処理は、必要に応じて取捨選択することができ、あるいは適宜組み合わせてもよい。
【００８５】
例えば、上述した実施形態においては、整合性判定部２５は、分割ファイルの先頭位置が、他のマップタスクで検出し記録した分割ファイルの終端位置と連続するか否かを確認することで整合性を確認しているが、これに限定されるものではない。
すなわち、整合性判定部２５は、特定部２３によって特定された分割ファイルの終端位置が正しいものであるか否かを検証してもよい。
【００８６】
整合性判定部２５は、ノード間共有情報１５を参照することで、特定部２３によって特定された終端位置と、他のマップタスクで検出し記録した分割ファイルの先頭位置との整合性を確認することができる。
具体的には、整合性判定部２５は、特定部２３が特定した終端位置を、処理対象の分割ファイルに後続する他の分割ファイルを処理するマップタスクについてノード間共有情報１５に記録されている分割ファイルの先頭位置（確認レコード先頭位置）と比較する。この比較の結果、後続する分割ファイルの確認レコード先頭位置が、当該マップタスクにおいて到達した終端位置と連続している場合に、整合性判定部２５は整合性があると判断してもよい。
【００８７】
また、上述した実施形態においては、処理対象のファイルがNetCOBOLの規格に沿った可変長レコードファイルである例を示しているが、これに限定されるものではなく、種々変形して実施することができる。
図１４はMicroFocusのレコード順ファイルの構成を例示する図である。
この図１４に例示するレコード順ファイルは、可変長レコードで構成され、各可変長レコードが、書き込まれたデータ（レコード）の前に、レコード長を含むレコードヘッダーを備えるとともに、データの後に最大３文字の埋め込み文字を備える。埋め込み文字は、次のレコードが４バイトの境界で開始されるようにするためのものである。
【００８８】
また、このレコード順ファイルには、１２８バイトのファイルヘッダーレコードが含まれる。
本分散処理システム１においては、処理対象ファイルがこの図１４に例示するようなレコード順ファイルであってもよい。すなわち、特定部２３は、そのデータ構造の規則性に基づいて、分割ファイルに含まれる可変長レコードの位置（データ区切り位置）を特定する。
【００８９】
具体的には、特定部２３は、バッファ領域に格納された分割ファイルにおいて、ヘッダに含まれるレコード長を読み取り、このレコード長分進んだ位置から所定サイズ（最大３文字）のデータを読み出し、このデータが埋め込み文字であるか否かを確認すればよい。
このように、処理対象のデータ構造に応じて、特定部２３が、可変長レコードからのデータ読出位置や比較対象を適宜変更して実施することで、種々の処理対象データに適用することができる。
【００９０】
また、上述した実施形態においては、複数のサーバ１０を備え、これらの各サーバ１０においてそれぞれマップタスクが実行されるとともに分割処理部２０が分割ファイルの区切り位置の特定（修正）を行なっているが、これに限定されるものではない。例えば、１つのサーバ（情報処理装置）１０において、複数のマップタスクを実行してもよく、これらのマップタスク毎に分割処理部２０としてのプロセスを実行して分割ファイルの区切り位置の特定（修正）を行なってもよい。
【００９１】
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
コンピュータに、
処理対象である、バイナリデータが複数に分割された部分バイナリデータのデータ区切り位置を、前記バイナリデータを構成する所定のデータの中の特性に基づき検出し、
検出したデータ区切り位置を示す情報を記憶手段に登録し、
前記記憶手段に登録された他の部分バイナリデータに関するデータ区切り位置を示す情報に基づき、前記部分バイナリデータにおいて検出したデータ区切り位置が正当であるかを判定する
処理を実行させることを特徴とする、データ分割処理プログラム。
【００９２】
（付記２）
前記処理対象の部分バイナリデータについて検出したデータ区切り位置と、前記記憶手段に登録された、前記バイナリデータにおいて前記処理対象の部分バイナリデータと隣接する部分バイナリデータについてのデータ区切り位置とが連続する場合に、検出したデータ区切り位置が正当であると判断する
処理を前記コンピュータに実行させることを特徴とする、付記１記載のデータ分割処理プログラム。
【００９３】
（付記３）
前記部分バイナリデータを構成する個々の単位レコードに含まれるデータ長情報に基づき、当該部分バイナリデータの位置を特定する
処理を前記コンピュータに実行させることを特徴とする、付記１又は２記載のデータ分割処理プログラム。
【００９４】
（付記４）
正当であると判断された前記データ区切り位置に基づき、前記バイナリデータのデータ区切り位置を確定する
処理を前記コンピュータに実行させることを特徴とする、付記１〜３のいずれか１項に記載のデータ分割処理プログラム。
【００９５】
（付記５）
バイナリデータを複数に分割した部分バイナリデータを処理するデータ分割処理装置であって、
処理対象の部分バイナリデータのデータ区切り位置を、前記バイナリデータを構成する所定のデータの特性に基づき検出する検出部と、
検出したデータ区切り位置を示す情報を記憶手段に登録する登録部と、
前記記憶手段に登録された他の部分バイナリデータに関するデータ区切り位置を示す情報に基づき、前記部分バイナリデータにおいて検出したデータ区切り位置が正当であるかを判定する判定部と、
を備えることを特徴とする、データ分割処理装置。
【００９６】
（付記６）
前記判断部が、
前記処理対象の部分バイナリデータについて検出したデータ区切り位置と、前記記憶手段に登録された、前記バイナリデータにおいて前記処理対象の部分バイナリデータと隣接する部分バイナリデータについてのデータ区切り位置とが連続する場合に、検出したデータ区切り位置が正当であると判断する
ことを特徴とする、付記５記載のデータ分割処理装置。
【００９７】
（付記７）
前記検出部が、前記部分バイナリデータを構成する個々の単位レコードに含まれるデータ長情報に基づき、当該部分バイナリデータの位置を特定する
ことを特徴とする、付記５又は６記載のデータ分割処理装置。
（付記８）
正当であると判断された前記データ区切り位置に基づき、前記バイナリデータのデータ区切り位置を確定する確定部
を備えることを特徴とする、付記５〜７のいずれか１項に記載のデータ分割処理装置。
【００９８】
（付記９）
バイナリデータを複数に分割して複数の処理部により処理する分割処理方法であって、
前記複数の処理部のそれぞれに、前記バイナリデータの一部である部分バイナリデータをそれぞれ割り当て、
前記複数の処理部はそれぞれ、割り当てられた部分バイナリデータのデータ区切り位置を、前記バイナリデータを構成する所定のデータの特性に基づき検出するとともに、検出したデータ区切り位置を示す情報を記憶手段に登録し、
前記複数の処理部はそれぞれ、他の処理部により前記記憶手段に登録されたデータ区切り位置を示す情報に基づき、前記部分バイナリデータにおいて検出したデータ区切り位置が正当であるかを判定する
ことを特徴とする、データ分割処理方法。
【００９９】
（付記１０）
前記処理対象の部分バイナリデータについて検出したデータ区切り位置と、前記記憶手段に登録された、前記バイナリデータにおいて前記処理対象の部分バイナリデータと隣接する部分バイナリデータについてのデータ区切り位置とが連続する場合に、検出したデータ区切り位置が正当であると判断する
ことを特徴とする、付記９記載のデータ分割処理方法。
【０１００】
（付記１１）
前記部分バイナリデータを構成する個々の単位レコードに含まれるデータ長情報に基づき、当該部分バイナリデータの位置を特定する
ことを特徴とする、付記９又は１０記載のデータ分割処理方法。
（付記１２）
正当であると判断された前記データ区切り位置に基づき、前記バイナリデータのデータ区切り位置を確定する
ことを特徴とする、付記９〜１１のいずれか１項に記載のデータ分割処理方法。
【符号の説明】
【０１０１】
１    分散処理システム
１０，１０−１〜１０−４    サーバ（処理部，データ分割処理装置）
１１    ユーザアプリケーション機能部
１２    ファイル管理部
１３    タスクトラッカ
１４    ジョブトラッカ
１５    ノード間共有情報
２０    分散処理部
２１    ファイル読込部
２２    ファイル先頭記録部（登録部）
２３    特定部（検出部，確定部）
２４    ファイル終端記録部（登録部）
２５    整合性判定部（判定部）
２０１    ＣＰＵ
２０２    メモリ（記憶手段）
２０５    表示装置
２０６    キーボード
２０７    マウス
２０８    記憶装置
５０    ネットワーク
【図１】
2015170170.tif 000003
【図２】
2015170170.tif 000004
【図３】
2015170170.tif 000005
【図４】
2015170170.tif 000006
【図５】
2015170170.tif 000007
【図６】
2015170170.tif 000008
【図７】
2015170170.tif 000009
【図８】
2015170170.tif 000010
【図９】
2015170170.tif 000011
【図１０】
2015170170.tif 000012
【図１１】
2015170170.tif 000013
【図１２】
2015170170.tif 000014
【図１３】
2015170170.tif 000015
【図１４】
2015170170.tif 000016
【図１５】
2015170170.tif 000017
【図１６】
2015170170.tif 000018
【図１７】
2015170170.tif 000019
【図１８】
2015170170.tif 000020
【図１９】
2015170170.tif 000021