WO2013179451A1 - 並列データ処理システム、計算機および並列データ処理方法 - Google Patents

並列データ処理システム、計算機および並列データ処理方法 Download PDF

Info

Publication number
WO2013179451A1
WO2013179451A1 PCT/JP2012/064149 JP2012064149W WO2013179451A1 WO 2013179451 A1 WO2013179451 A1 WO 2013179451A1 JP 2012064149 W JP2012064149 W JP 2012064149W WO 2013179451 A1 WO2013179451 A1 WO 2013179451A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
record
data set
thread
input data
Prior art date
Application number
PCT/JP2012/064149
Other languages
English (en)
French (fr)
Inventor
和生 合田
山田　浩之
喜連川　優
信男 河村
藤原　真二
茂木　和彦
Original Assignee
国立大学法人東京大学
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 国立大学法人東京大学, 株式会社日立製作所 filed Critical 国立大学法人東京大学
Priority to US14/404,550 priority Critical patent/US9841989B2/en
Priority to EP12878202.6A priority patent/EP2857975A4/en
Priority to JP2014518181A priority patent/JP5881025B2/ja
Priority to PCT/JP2012/064149 priority patent/WO2013179451A1/ja
Publication of WO2013179451A1 publication Critical patent/WO2013179451A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24532—Query optimisation of parallel queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication

Definitions

  • the present invention relates to parallel data processing technology.
  • the entire data set stored in storage or the like (for example, a file stored in a file system) is basically read and processed.
  • an application job
  • the data The entire set needs to be read, and data processing is not necessarily efficient, and thus the time required for data processing may be increased.
  • the time required to read the entire data set becomes longer, and thus the time required for data processing may become longer.
  • an object of the present invention is to shorten the time for data processing.
  • a parallel data processing system included in one computing node in a computer system that executes data processing in parallel in a plurality of computing nodes includes a first data group including a plurality of first data and a plurality of second data.
  • a parallel data processing execution unit that reads data from the data group including the second data group and executes the process.
  • the parallel data processing system may be, for example, a system module in the first and second embodiments described later.
  • the first data in the first data group may correspond to the second data in the second data group.
  • the first data group may be an index of the second data group.
  • the first data may include an index key value of the second data and a reference to one or more second data corresponding to the index key value.
  • the parallel data processing execution unit (A) Reading the first data from the first data group, acquiring the first value from the first data based on the first format information acquired from the application, (B) generating one or more threads for reading each of the one or more second data corresponding to the first value from the second data group based on the first reference information acquired from the application; (C) performing (A) to (B) on one or more first data in the first data group; (D) A plurality of the threads are executed in parallel.
  • the parallel data processing system may further include a reception unit that receives processing instructions from the application.
  • the instruction from the application generally defines the procedure, but the parallel data processing execution unit receives the instruction from the application and executes (A) to (D), so that the instruction from the application is Even if the procedure is defined, the parallel data processing system can execute out-of-order processing independent of the procedure.
  • the calculation node can read data related to data processing in parallel. Thereby, it is expected that the throughput of data reading is improved, and therefore, the time for data processing is shortened.
  • FIG. 1A illustrates a job execution model according to the first embodiment.
  • FIG. 1B illustrates a job execution model according to the second embodiment.
  • FIG. 2A illustrates a configuration of a calculation node according to the first embodiment.
  • FIG. 2B illustrates a configuration of a calculation node according to the second embodiment.
  • FIG. 3A illustrates a first configuration example of the computer system according to the embodiment.
  • FIG. 3B illustrates a second configuration example of the computer system according to the embodiment.
  • FIG. 4A shows a flow of map task execution processing according to the first embodiment.
  • FIG. 4B shows a flow of task execution processing according to the second embodiment.
  • FIG. 5A is a diagram for explaining the input data and the process for the input data according to the first embodiment.
  • FIG. 5A is a diagram for explaining the input data and the process for the input data according to the first embodiment.
  • FIG. 5B shows an example of a format and reference according to the first embodiment.
  • FIG. 5C is an example of a schematic diagram illustrating thread generation and thread execution.
  • FIG. 5D is a first diagram for explaining the input data and the process for the input data according to the second embodiment.
  • FIG. 5E is a second diagram for explaining the input data and the process for the input data according to the second embodiment.
  • FIG. 5F shows an example of a format according to the second embodiment.
  • FIG. 5G illustrates an example of a reference method according to the second embodiment.
  • FIG. 5H illustrates an example of a catalog according to the second embodiment.
  • FIG. 6A is an example of a schematic diagram for explaining a session during data acquisition.
  • FIG. 6A is an example of a schematic diagram for explaining a session during data acquisition.
  • FIG. 6B is an example of a schematic diagram for explaining a blocked session at the time of data acquisition according to the modification.
  • FIG. 7A shows a flow of a record acquisition process in a calculation node that acquires a record according to the first embodiment.
  • FIG. 7B shows a flow of record acquisition processing in a calculation node that manages records according to the first embodiment.
  • FIG. 7C illustrates the configuration of the data read request management table and the remote record acquisition request management table according to the first embodiment.
  • FIG. 7D illustrates a flow of record acquisition processing in a calculation node that acquires records according to the modification of the first embodiment.
  • FIG. 7E shows the flow of a record acquisition process in a calculation node that manages records according to a modification of the first embodiment.
  • FIG. 7A shows a flow of a record acquisition process in a calculation node that acquires a record according to the first embodiment.
  • FIG. 7B shows a flow of record acquisition processing in a calculation node that manages records according to the
  • FIG. 7F illustrates a configuration of a blocked remote record acquisition request management table according to a modification of the first embodiment.
  • FIG. 8A shows a configuration of a node-level resource constraint management table according to the first embodiment.
  • FIG. 8B illustrates a configuration of a job level resource constraint management table according to the first embodiment.
  • FIG. 8C illustrates a configuration of a process level resource constraint management table in the overall supervisor process according to the first embodiment.
  • FIG. 8D illustrates a configuration of a process level resource constraint management table in the supervisor process of each node according to the first embodiment.
  • FIG. 8E illustrates a configuration of a task level resource constraint management table in the overall supervisor process according to the first embodiment.
  • FIG. 8A shows a configuration of a node-level resource constraint management table according to the first embodiment.
  • FIG. 8B illustrates a configuration of a job level resource constraint management table according to the first embodiment.
  • FIG. 8C illustrates a configuration of a process level
  • FIG. 8F illustrates a configuration of a task level resource constraint management table in the supervisor process of each node according to the first embodiment.
  • FIG. 8G shows a flow of the overall resource constraint management process according to the first embodiment.
  • FIG. 8H illustrates a flow of resource constraint management processing in each node according to the first embodiment.
  • FIG. 9A illustrates a first example of tasks according to the first embodiment.
  • FIG. 9B illustrates an example of thread generation in the task illustrated in the first example according to the first embodiment.
  • FIG. 9C illustrates an example of thread generation in the task illustrated in the first example according to the first embodiment.
  • FIG. 9D illustrates a second example of the task according to the first embodiment.
  • FIG. 9E illustrates an example of thread generation in the task illustrated in the second example according to the first embodiment.
  • FIG. 1A shows a job execution model according to the first embodiment.
  • one solid circle represents one process (for example, a map process or a reduce process).
  • One dashed circle in the process indicates one task.
  • One rounded square in the task indicates one thread.
  • a job is executed by a plurality of computation nodes connected via a network.
  • a supervisor process in a compute node that supervises the entirety of multiple compute nodes distributes application code to all compute nodes that participate in job execution, and the supervisor supervisor process performs each computation. Allocate processes such as map process and reduce process to the supervisor process of the node.
  • the supervisor process of each compute node generates a process based on the instruction of the supervisory supervisor process. Further, the generated process generates a task based on an instruction from the supervisory supervisor process.
  • Each computation node executes the job by executing the map operation included in the application by executing the processes and tasks generated in this way.
  • the supervisory supervisor process may be any one of a plurality of supervisor processes in a plurality of computing nodes (that is, any one supervisor process may also serve as the supervisory supervisor process) or a plurality of supervisor processes.
  • a dedicated process functioning as a dedicated supervisory supervisor process prepared separately from the process may be used.
  • the process allocation is not limited to the above, and the supervisor supervisor process may instruct the supervisor process of each computation node to perform the process.
  • the process and task generation is not limited to the above, and the supervisor supervisor process directly performs the process. Also good.
  • the parallel data processing system executes the map process according to the job execution model, and stores the input data set # 1 (that is, the first data set) and the input data set # 2 (that is, the second data set) stored in the storage. ) And a map operation are executed, and the result record is written to an intermediate data set stored in the storage. Further, the reduction process is executed, the result record written in the intermediate data set is input, the reduction operation is executed, and the result record is written in the output data set # 1.
  • Each of the input data set, the intermediate data set, and the output data set is a collection of a plurality of records, and may be structured by some data structure or may not be structured.
  • the input data set # 2 may be a set of one or more files.
  • the input data set # 1 only needs to correspond to the record of the input data set # 2.
  • the input data set # 1 may be an index of the input data set # 2.
  • Each record of the input data set # 1 includes a predetermined index key value of the record of the input data set # 2 and a reference indicating one or more records of the input data set # 2 corresponding to the index key value.
  • the reference may include a storage position where the record of the input data set # 2 can be specified on the storage device, or the record can be specified on the data structure provided for storing the input data set # 2.
  • a unique index key may be included.
  • the input data set # 1 may have records corresponding to all the records of the input data set # 2, or only records corresponding to some of the records of the input data set # 2.
  • the input data set # 1 may not be an index of the input data set # 2.
  • the input data set # 1 and the input data set # 2 are connectable, the input data set # 1 is simply a collection of records, and the input data set # 2 is a collection of records, depending on the data structure.
  • a record of the input data set # 2 that is structured by a certain index key and has an index key value corresponding to the value of a certain item in a certain record of the input data set # 1 may be read. .
  • the input data set # 1 and the input data set # 2 may belong to the same data structure.
  • the input data set # 1 may be a set of internal nodes that constitute a B-tree
  • the input data set # 2 may be a set of leaf nodes that constitute the same B-tree.
  • the input data set # 1 is a set of nodes at a certain level constituting the B-tree
  • the input data set # 2 is a node at the next level (referenced from the input data set # 1) constituting the same B-tree.
  • the input data set may be composed of three or more. For example, there may be another input data set corresponding to the record of the input data set # 2.
  • the program code may be an instruction that can be executed by a processor generated by compilation or the like, an instruction that can be converted into an instruction that can be executed by the processor by an execution processing system, or the like. It may be a declaration that can generate an instruction that can be executed by the processor by an execution processing system or the like. Furthermore, it may be a combination of these and may further include other information.
  • the instruction and the declaration may be a byte string that can be interpreted by a processor, a compiler, an execution processing system, or the like, or may be described in a source code or the like.
  • the reduce operation is a program code included in the application stored in the calculation node.
  • a reduction operation is a program code that defines the processing applied to records in an intermediate data set. For example, a result is obtained by aggregating result records (consisting of key / value pairs) generated by a map operation according to a key. A record is generated.
  • the input data set # 1 may be an index of the input data set # 2.
  • each record of the input data set # 1 has a reference value indicating a predetermined index key value of the record of the input data set # 2 and one or more records of the input data set # 2 corresponding to the index key value. May include.
  • the input data set # 3 may be an index of the input data set # 4.
  • Each record of the input data set # 3 includes a predetermined index key value of the record of the input data set # 4 and a reference indicating one or more records of the input data set # 4 corresponding to the index key value.
  • the predetermined item of the record of the input data set # 2 may include a reference indicating one or more records of the input data set # 3.
  • the processor obtains a reference to the input data set # 3 from the record that satisfies the requirement.
  • the processor generates a thread that performs processing by referring to the input data set # 3 using the reference. If there are multiple references, the processor creates multiple threads. These threads are executed in parallel by the processor.
  • the processor generates a record to be input to the stage calculation # 1 based on the build method # 1 with respect to the record that satisfies the requirements, and executes the stage calculation # 1 using the record as an input. Further, the division operation # 1 is performed on the execution result record of one or more stage operations # 1, thereby determining the subsequent stage # 2 process to which the execution result record is to be sent.
  • the processor outputs so that the determined subsequent stage process can receive the execution result record. Specifically, the execution result is stored in an intermediate data set or sent to a subsequent stage process on the network.
  • the processor of the computation node executes a task in the stage # 2 process, acquires a record passed from the stage # 1 process in the task, executes the stage calculation # 2, and further divides By performing the calculation # 2, the process of the subsequent stage # 3 to which the execution result record of the stage calculation # 2 is to be sent is determined.
  • the processor outputs so that the process of the determined subsequent stage can receive the execution result record of the stage operation # 2.
  • the execution result is stored in an intermediate data set or sent to a subsequent stage process on the network.
  • records from a plurality of different data sets may be input in parallel or sequentially.
  • the first data set and the second data set have a relationship that allows respective records to be combined. That is, the first data set may not be structured, and the second data set may be structured. Since the second data set is structured, the second record corresponding to the record of the first data set associated with the second data set can be selectively extracted.
  • the second embodiment is an extension of the first embodiment, and the part described with respect to the first embodiment is applied to the second embodiment without being described again.
  • the memory 105 includes an application program (hereinafter referred to as an application) 110, a system module 120, a process manager 131, a task manager 132, a thread manager 133, a data reader / writer 140, a network manager 150, a storage manager 160, and an OS (Operating System) 170.
  • an application hereinafter referred to as an application
  • the system module 120, the process manager 131, the task manager 132, the thread manager 133, the data reader / writer 140, the network manager 150, and the storage manager 160 (hereinafter, individual program modules are collectively referred to as a module group) and the application 110 are static. Alternatively, it may be a library module that is dynamically linked and executed.
  • an instruction from the application 110 or a mutual instruction between program modules in the module group depends on a call interface disclosed by the module group.
  • the module group may be a program that operates separately from the application 110.
  • an instruction from the application 110 is based on means such as inter-process communication or shared memory.
  • the application 110 is a program that defines a job that reads an input data set stored in the storage 104, executes predetermined processing, and writes an output data set, and the calculation node executes the job by executing the application 110.
  • the map 110a, the reduce operation 110b, the division operation 110c, the format 110e (format # 1), and the format 110f (format 110f) are used as the information that defines the job (hereinafter referred to as job information).
  • job information hereinafter referred to as job information.
  • # 2 condition 110g.
  • the data reader / writer 140 reads / writes data from / to the storage based on instructions from the system module 120.
  • the data reader / writer 140 may be a file system, for example. For example, if the data reader / writer 140 needs to read / write data from / to the storage 104 of its own computing node 100 in order to perform the specified data read / write, the storage manager 160 causes the storage 104 to execute data read / write, When it is necessary to read / write data from / to the storage 104 of another computing node 100 connected via the network 200, the data is transferred to the storage 104 of another computing node 100 connected via the network 200 by the network manager 150. Read / write is executed. At this time, the data reader / writer 140 may temporarily cache data to be read / written using the memory resource of the memory 105.
  • the network manager 150 controls data communication with devices (for example, other computing nodes 100) connected via the network.
  • the storage manager 160 controls input / output with the storage 104 of its own computing node 100.
  • the OS 170 manages devices such as the NIC 102, the HBA 103, and the storage 104, and also manages the entire computing node 110.
  • the computing node 100 may include a plurality of at least one element of the CPU 101, the NIC 102, and the HBA 103 from the viewpoint of performance and availability.
  • the computing node 100 may include an input device (for example, a keyboard and a pointing device) (not shown) and a display device (for example, a liquid crystal display) (not shown).
  • the input device and the display device may be integrated.
  • the system module 120 includes a generalized stage function 124 and a supervisor function 122.
  • the generalized stage function 124 is program code (function) executed in each process shown in FIG. 1B.
  • the storage 400 includes one or more nonvolatile storage media.
  • the nonvolatile storage medium is, for example, a magnetic disk or a flash memory.
  • the storage 104 may include a plurality of nonvolatile storage media, and may further include a RAID (Redundant ARRAY of Independent Disks) controller that configures a storage space from the nonvolatile storage media. All or part of the storage resources of the storage 400 may be handled in the same manner as the storage 104 included in the computing node 100.
  • RAID Redundant ARRAY of Independent Disks
  • the processor 101 of the computing node 100 executes the processing of steps S10 to S15 by executing one thread SL1 for reading the record of the input data set # 1 and executing the processing. This process is realized by the processor 101 executing mainly the map function 121.
  • the processor 101 acquires one record from the input data set # 1.
  • the input data set # 1 may be stored in the storage 104 of its own calculation node 100, or may be stored in the storage 104 of another calculation node 100.
  • the record acquisition process for acquiring records from the input data set # 1 will be described later.
  • the processor 101 interprets the contents of each item included in the acquired record based on the format 110e (format # 1), and the input data set # 1 included in the condition 110g is obtained for the acquired record.
  • the condition for the record it is determined whether or not the record satisfies the condition. If necessary, the process proceeds to S12. If not necessary, the process proceeds to S15 although not shown.
  • a part of the condition 110g may be applied. If the condition 110g is not defined, the process may proceed to S12 as it is.
  • the processor 101 generates a thread SL2 for acquiring a record from the input data set # 2 and performing processing for one reference to the input data set # 2 of the acquired record.
  • the processor 101 determines whether or not there is a reference to the unprocessed input data set # 2 in the acquired record. If the result of this determination is affirmative, S13 is performed, while if the result of this determination is negative, S15 is performed. Thus, if there are a plurality of references to the input data set # 2 in the acquired record, the thread SL2 corresponding to the number of references is generated in S13. Note that when the resources necessary for generating the thread are insufficient, the generation of the thread SL2 may be temporarily suspended. At this time, one thread SL2 may be generated for each reference, or one thread SL2 may be generated for a plurality of (for example, a predetermined number) references.
  • the thread SL2 generated by the thread SL1 in S13 is executed by the CPU 101.
  • the processor 101 executes the processing of step S16 to step S19 by executing the thread SL2.
  • the processor 101 can execute a plurality of threads (thread SL1, thread SL2, etc.) in parallel.
  • the computing node 100 includes a plurality of processors 101, and a thread SL2 generated by one processor 101 may be executed by another processor 101. Note that the number of threads that can be executed in parallel is limited by the resources of the computing node 100 and the like.
  • the processor 101 acquires one record from the input data set # 2 using the reference acquired by the reference method 110h and the thread SL1.
  • the processor 101 interprets the contents of each item included in the acquired record based on the format 110f (format # 2), and the input data set # 2 included in the condition 110g for the acquired record. By applying the condition for the record, it is determined whether or not the record is necessary. If necessary, the process proceeds to S18. If not necessary, the process proceeds to S19 although not shown. In S17, a part of the condition 110g may be applied. If the condition 110g is not defined, the process may proceed to S18 as it is.
  • the processor 101 stores the acquired record in the calculation queue 180 of the main memory 105.
  • the processor 101 determines whether there is another record in the range indicated by the reference of the input data set # 2. If the result of this determination is affirmative, S16 is performed, while if the result of this determination is negative, this process is terminated and the thread SL2 that performed this process is terminated.
  • the processor 101 obtains one record from the computation queue 180, applies a map computation 110a to the record, executes a predetermined process on the record, and obtains the execution result. Output.
  • the processor 101 may execute S20 in a thread different from SL2. There may be one or more threads that execute S20.
  • the map calculation 110a may be applied by acquiring a plurality of records at once from the calculation queue 180. Instead of executing S18 in the thread SL2, the processor 101 may execute S20 after executing S17 in the thread SL2 and apply the map operation to the record of the result of S17.
  • the execution result may be stored in the main memory 105, or the execution result may be passed to a reduce process that executes subsequent processing.
  • a thread SL1 that reads records from the input data set # 1 and performs processing thereof and a thread SL2 that reads records from the input data set # 2 and performs processing thereof are provided separately.
  • the processing corresponding to S16 to S19 or S20 may be performed as it is without generating the thread SL2.
  • a predetermined number of threads SL1 may be generated, records may be read from the input data set # 1 by the threads SL1, and the processing may be performed.
  • SL1 may be newly generated, and processing corresponding to S10 to S15 may be performed.
  • FIG. 4B shows a flow of task execution processing according to the second embodiment.
  • This task execution process indicates a process executed in a task executed in the stage process in the job execution model shown in FIG. 1B.
  • the processor 101 of the computation node 100 executes the processing of steps S21 to S26 by executing one thread SLd 1 for reading the record of the input data set #d 1 and executing the processing.
  • the input data set #d 1 is the input data set # 1
  • the input data set #d 2 is the input data set # 2 .
  • the input data set #d 1 is the input data set # 5
  • the input data set #d 2 is an input data set # 6.
  • the processor 101 acquires one record from the input data set #d 1.
  • the input data set #d 1 may be stored in the storage 104 of its own calculation node 100 or may be stored in the storage 104 of another calculation node 100. Note that the record acquisition process of acquiring records from the input data set #d 1 will be described later.
  • the processor 101 based on the format 110m corresponding to the record in the input data set #d 1, with respect to interpret the contents of each item contained in the acquired record, the acquired records are included in the condition 110n by applying the criteria for records in the input data set #d 1, in the record to determine whether to satisfy the condition, if necessary, the process proceeds to S23, if not necessary, although not shown S26 move on. In S22, a part of the condition 110n may be applied. If the condition 110n is not defined, the process may proceed to S23 as it is.
  • the processor 101 the acquired record, it is determined whether there is a reference to the input data set #d 2. If the result of this determination is affirmative, S24 is performed, while if the result of this determination is negative, S26 is performed.
  • the processor 101 for one reference to the input data set #d 2 of the acquired record, it generates a thread SLd 2 for getting to process records from the input data set #d 2.
  • the processor 101 the acquired record, it is determined whether there are more references to input data set #d 2. If the result of this determination is affirmative, S24 is performed, while if the result of this determination is negative, S26 is performed. Thus, if there are a plurality of references to the input data set #d 2 in the acquired record, a thread SLd 2 corresponding to the number of references is generated in S24. Note that when the resources necessary for generating the thread are insufficient, the generation of the thread SLd 2 may be temporarily suspended. At this time, it may generate one thread SLd 2 for each of the one reference, may generate one thread SLd 2 for each of the plural reference (e.g., a predetermined number).
  • the processor 101 further determines whether there is another record in the input data set #d 1. If the result is affirmative in this determination, while performing S21, if is negative result of this determination, we end this process, and terminates the thread SLd 1 executing this process.
  • the thread SLd k generated from the thread SLd k-1 in S24 and S31 to be described later is executed by the processor 101.
  • k represents a natural number of 2 or more.
  • the processor 101 executes the processing of steps S27 to S35 by executing the thread SLd k .
  • the processor 101 can execute a plurality of threads (thread SLd 1 , thread SLd k, etc.) in parallel.
  • the computing node 100 includes a plurality of processors 101, and a thread generated by one processor 101 may be executed by another processor 101. The number of threads that can be executed in parallel is limited by the resources of the computing node 100 and the like.
  • the processor 101 based on the reference method 110o for referring to the input data set #SLd k using the reference and the references of record input data set #SLd k-1, the input data set #SLd k Get a record.
  • the processor 101 interprets the content of each item included in the acquired record based on the format 110f (format #d k ), and the input data set #d included in the condition 110n for the acquired record. By applying the condition for the record of k , it is determined whether or not the record is necessary. If necessary, the process proceeds to S29. If not necessary, the process proceeds to S35 although not shown. In S28, a part of the condition 110n may be applied. If the condition 110n is not defined, the process may proceed to S29 as it is.
  • the processor 101 determines whether or not access to the input data set #d k + 1 is further required. If the result of this determination is affirmative, S30 is performed, while if the result of this determination is negative, the process proceeds to S33. For example, in the stage # 1 process of FIG. 1B, a record is acquired from the input record # 1, a record is acquired from the input record # 2 according to the reference in the record, and a record is input from the input record # 3 according to the reference in the record In addition, it is necessary to acquire a record from the input record # 4 according to the reference in the record.
  • the processor 101 determines whether or not the acquired record has a reference to the input data set #d k + 1 . If the result of this determination is affirmative, S31 is performed, while if the result of this determination is negative, S35 is performed.
  • the processor 101 generates a thread SLd k + 1 for performing processing by acquiring a record from the input data set #d k + 1 for one reference to the input data set #d k + 1 of the acquired record.
  • the processor 101 determines whether or not the acquired record further includes a reference to the input data set #d k + 1 . If the result of this determination is affirmative, S31 is performed, while if the result of this determination is negative, S35 is performed. Thereby, if there are a plurality of references to the input data set #d k + 1 in the acquired record, a thread SLd k + 1 corresponding to the number of references is generated in S31. Note that when the resources necessary for generating the thread are insufficient, the generation of the thread SLd k + 1 may be temporarily suspended. At this time, it may generate one thread SLd k + 1 for each of the one reference, may generate one thread SLd k + 1 for each of the plural reference (e.g., a predetermined number).
  • the processor s101 builds (generates) a record in a predetermined format based on the acquired record and the build method 110p.
  • the processor 101 executes predetermined processing by applying the stage operation 110 j to the built record, and outputs the execution result.
  • the processor 101 instead of executing S34 after executing S33 in the thread SLd k , the processor 101 temporarily stores the built record in the calculation queue of the main memory 105, acquires one record from the calculation queue, and then executes S34. , And applying the stage operation 110j to the record, a predetermined process may be executed on the record, and the execution result may be output.
  • the processor 101 may execute S34 in a thread different from SLd k . There may be one or more threads that execute S34.
  • the stage calculation 110j may be applied by acquiring a plurality of records at once from the calculation queue.
  • CPU 101 further determines whether there is another record in the range indicated by the reference input dataset #d k. If this determination result is affirmative, while performing S27, if the result of this determination is negative, then the processing ends, it stops the thread SLd k executing this process.
  • the thread SLd k-1 may perform the processing corresponding to S27 to S35 without generating the thread SLd k .
  • a predetermined number of threads SLd 1 may be generated, and records may be read from the input data set # 1 by the threads SLd 1 and processed.
  • SLd 1 or SLd k is newly generated, and processing corresponding to S21 to S26 or processing corresponding to S27 to S35 is performed. Good.
  • FIG. 5A is a diagram for explaining the input data and the process for the input data according to the first embodiment.
  • Input data set # 2 stores one or more records including “Date & time”, “User”, “Product”, and “Comment”.
  • the input data set # 1 one or more records having items of “Product” and “Reference” are collected and managed for each year. That is, the input data set # 1 is divided by year and month.
  • the supervisor process performs parallel data processing by assigning a map task or the like for each of the collected parts (divided parts). At this time, one map task may be responsible for a plurality of divided portions.
  • “Product” stores a value of a key item (“Product”) used to search for a record in the input data set # 2.
  • “Reference” includes the physical record of the record corresponding to the record in the input data set # 2 that stores the same value as the value of “Product” in the record (reference destination record). A reference indicating the correct storage location is stored.
  • “Reference” stores references to the plurality of reference destination records.
  • the input record # 2 may have a structure (for example, a B-tree) in which a record can be searched with a certain key, and may be a reference for storing the value of the key in “Reference”.
  • a plurality of records may correspond to a certain reference.
  • the record format of input data set # 2 is described in format # 2. Further, a method of referring to the record of the input data set # 2 using “Reference” of the input data set # 1 is described in the reference method # 1.
  • the processor 101 reads the record of the input data set # 1 by executing the map function 121, and grasps the product and the reference in the record by the format # 1. . Then, the map function 121 determines whether or not a predetermined condition is met based on the value of Product, and identifies a reference of a record that satisfies the condition. Then, the processor 101 executes the map function 121 to acquire a record of the input data set # 2 based on the reference method # 1 and the reference.
  • FIG. 5B is a diagram for explaining the format and reference according to the first embodiment.
  • Format # 1 is information relating to the record format of the input data set # 1, and in this embodiment, a procedure for interpreting the record of the input data set # 1 is described.
  • Format # 1 includes interpreting an input record (that is, record of input data set # 1) in binary format, interpreting each column of the input record as Text type, Long type, Int type, Int type, It describes that a column of 1 (0) is used as a search key.
  • the column type is indicated using a type declaration in the Java (registered trademark) language, but the present invention is not limited to this.
  • Format # 2 is information relating to the record format of the input data set # 2, and in this embodiment, a procedure for interpreting the record of the input data set # 2 is described.
  • Format # 2 describes that an input record (that is, a record of input data set # 2) is interpreted in a text format (character string format).
  • the delimiter between the columns in the record is a comma, the first (0) column is the DateTime type, named “Date & Time”, and the second (1) column is the Text type. , “User”, the third (2) column is Text type, “Product”, the fourth (3) column is Text type, “Comment”, based on these To interpret the input column.
  • the reference method # 1 is a procedure for a method of referring to the record of the input data set # 2 by using “Reference” of the input data set # 1, and the second method of the input record (record corresponding to the format # 1). It is described that a record is obtained by referring to a physical reference using a column as an offset, a third column as a length, and a fourth column as a node ID.
  • the physical reference means that the specified offset (address) of the storage managed by the specified node ID is a starting point and a byte string for the specified length is used as a reference destination record.
  • FIG. 5C is an example of a schematic diagram illustrating thread generation and thread execution.
  • the upper side of FIG. 5C shows an example in which a process is executed by a single thread, and the lower side of FIG. 5C dynamically generates a thread according to the first embodiment and executes a plurality of threads in parallel.
  • An example is shown. Note that the notation in FIG. 5C follows the following rules.
  • the horizontal axis represents time.
  • a round rectangle with a long side in the figure means a series of processing by one thread.
  • the left end of the rounded rectangle represents the time when processing by the thread is started, and the right end of the rounded rectangle represents the time when processing by the thread is ended.
  • the value inside the rounded rectangle represents information (for example, the value of the first column of the record) indicating the record that is read along with the processing corresponding to the thread.
  • FIG. 5C shows an example in which each record of the input data set # 1 corresponding to February 2012 (2012-Feb) shown in FIG. 5A is acquired and the process is executed.
  • the processor when executed by a single thread, the processor records the second record from the top (2012-Feb) of input data set # 1 corresponding to February 2012 (2012-Feb). Read “Product” as “AX Skirt” and refer to the 7th record (“2012-Feb-07...”) Of input data set # 2 based on the “Reference” value of this record.
  • the map function 121 first corresponds to February 2012 (2012-Feb) of the input data set # 1 by the thread 5a.
  • the map function 121 reads the third record from the top of the input data set # 1 corresponding to 2012-Feb (the value of “Product” is “AX Skirt”) by the thread 5a, and the “Reference” of this record is read. Based on the four values, the thread 5c for referring to the eighth record (“2012-Feb-08...”) Of the input data set # 2 and the tenth record (“2012” of the input data set # 2) -Feb-08 ... ") thread 5d for referencing, 11th (“ 2012-Feb-08 ... ") thread 5e for referring to the input data set # 2, and input data Thread 5 for referring to the twelfth record of set # 2 ("2012-Feb-09 !) Sequentially generates and executed.
  • the map function 121 reads the fourth record from the top (the value of “Product” is “BC Bike”) corresponding to the 2012-Feb of the input data set # 1 by the thread 5a, and the “Reference” of this record is read. Based on the two values, a thread 5g for referring to the sixth record of the input data set # 2 and a thread 5h for referring to the ninth record of the input data set # 2 are generated and executed.
  • the map function 121 reads the fifth record from the top of the input data set # 1 corresponding to 2012-Feb (the value of “Product” is “BD Flower”) by the thread 5a, and the “Reference” of this record is read. Based on one value, a thread 5i for referring to the fifth record (“2012-Feb-03...”) Of the input data set # 2 is generated and executed.
  • FIG. 5D is a first diagram for explaining the input data and the process for the input data according to the second embodiment.
  • FIG. 5E is a second diagram for explaining the input data and the process for the input data according to the second embodiment.
  • the record of the input data set # 3 is further referred to by using the value of the record of the input data set # 2. Therefore, as shown in FIG. 5D, the application 110 further includes a reference method # 2 for referring to the input data set # 3 based on the record value (“User” value) of the input data set # 2.
  • the value of “User” is not a reference indicating a physical position of a record of the input data set # 3 corresponding to the value, but a reference indicating a logical position (searchable by the value). is there.
  • FIG. 5E shows an input data set # 3 and an input data set # 4.
  • the input data set # 4 stores one or more records including “User”, “Gender”, “Zip”, and “Address”.
  • one or more records having items of “User” and “Reference” are collected and managed for each predetermined range.
  • “User” the value of an item which is a key used for searching for a record in the input data set # 4 is stored.
  • “Reference” a reference indicating a physical storage position of a record (reference destination record) storing the same value as the value of “Product” in the record in the input data set # 4 is stored.
  • references to the plurality of reference destination records are stored.
  • the input record # 3 may have a structure (for example, a B-tree) that allows a record to be searched with a certain key, and may be a reference for storing the value of the key in “User”.
  • a plurality of records may correspond to a certain reference.
  • the record format of input data set # 3 is described in format # 3.
  • the record format of the input data set # 4 is described in format # 4. Further, a method of referring to the record of the input data set # 4 using “Reference” of the input data set # 3 is described in the reference method # 3. A procedure for generating a record to be output subsequently is described in the build method based on the acquired record.
  • the processor 101 reads the record of the input data set # 1 by executing the generalized stage function 124, and “Product” in the record by the format # 1 , “Reference”. Then, the generalization stage function 124 determines whether or not a predetermined condition is met based on the value of “Product”, and specifies “Reference” of a record that satisfies the condition. Then, the generalized stage function 124 acquires a record of the input data set # 2 based on the reference method # 1 and “Reference”.
  • the processor 101 executes the generalized stage function 124 to grasp “User”, “Product”, and “Comment” of the record of the read input data set # 2 according to the format # 2. Then, the generalization stage function 124 acquires a record of the input data set # 3 based on the value of “User” and the reference method # 2.
  • the processor 101 executes the generalized stage function 124 to grasp “User”, “Gender”, “Zip”, and “Address” of the record of the read input data set # 4 according to the format # 4. Then, the processor 101 executes the generalized stage function 124 to construct and output a record including “User”, “Product”, “Comment”, “Gender”, and “Zip” based on the build method. .
  • FIG. 5F is a diagram for explaining a format according to the second embodiment.
  • Format # 3 is information related to the record format of the input data set # 3. In this embodiment, a procedure for interpreting the record of the input data set # 3 is described. Format # 3 includes interpreting the input record (that is, record of input data set # 3) in binary format, interpreting each column of the input record as Text type, Long type, Int type, Int type, It describes that a column of 1 (0) is used as a search key.
  • Format # 4 is information related to the record format of the input data set # 4. In this embodiment, a procedure for interpreting the record of the input data set # 4 is described. Format # 4 describes that an input record (that is, a record of input data set # 4) is interpreted in a text format (character string format). The delimiter between the columns in the record is a comma, the first (0) column is Text type, named “User”, the second (1) column is Text type, Named “Gender”, the third (2) column is Text type, named “Zip”, the fourth (3) column is Text type, named “Address” and entered based on these Describes interpreting columns.
  • FIG. 5G is a diagram for explaining the reference method according to the second embodiment.
  • the reference method # 2 is a procedure for referring to the record of the input data set # 3 using the value of the record of the input data set # 2, and the second method of the input record (record corresponding to the format # 2). It describes that a column is used as a reference key and a record is obtained by referring to it with a logical reference.
  • the logical reference means that the reference destination data set is searched by the designated key value to identify the reference destination record.
  • the reference method # 3 is a procedure for a method of referring to the record of the input data set # 6 by using “Reference” of the input data set # 4, and the second method of the input record (record corresponding to the format # 5). It is described that a record is obtained by referring to a physical reference using a column as an offset, a third column as a length, and a fourth column as a node ID.
  • the physical reference means that the specified offset (address) of the storage managed by the specified node ID is a starting point and a byte string for the specified length is used as a reference destination record.
  • FIG. 5H shows an example of a catalog according to the second embodiment.
  • the format and the reference method are described in, for example, program code. Therefore, when the user prepares the format and the reference method, the user needs to be able to create the program code. However, not all users can create program codes. Therefore, in this embodiment, the user can specify a part of job information such as a format and a reference method by describing a catalog that is easier than the program code in the application, and based on the catalog, the parallel processing is performed. Let the data processing system execute data processing jobs. At this time, the parallel data processing system may execute the job after converting the catalog into a format or a reference method, or may directly execute the job using the catalog.
  • the catalog shown in FIG. 5H is described in XML (Extensible Markup Language), for example, and includes description sections 50a to 50d related to four data structures.
  • XML Extensible Markup Language
  • the data set of “user_comment” corresponding to the input data set # 2 has a format in which the text is divided into columns, the first (0) column is interpreted in the DateTime type, and this is used as a split key. It is described that the delimiter between columns is a comma.
  • the data set of “user_comment.product.index” corresponding to the input data set # 1 is in a format as a local secondary index corresponding to “user_comment”, and is in “user_comment”.
  • the third (2) column when the column delimiter is a comma is interpreted as a Text type and used as an index key.
  • the description parts 50c and 50d have the same description as the above description part. Note that it is not necessary to explicitly specify all necessary job information in the catalog. For those that are not explicitly specified, the system module etc. performs parallel data processing in accordance with the specified rules. Also good.
  • FIG. 6A is an example of a schematic diagram for explaining record acquisition according to the first embodiment.
  • 6A to 9C are descriptions of the first embodiment, but are not limited to the first embodiment but are also applied to the second embodiment.
  • the processor 101 of the computation node 100 executes a thread and obtains a record using the thread, if the record is a record stored in the storage 104 of its own computation node 100, the storage 104 Get a record.
  • the record is stored in the storage 104 of another calculation node 100, a record acquisition request for acquiring the record from the calculation node 100 to the other calculation node 100, for example, via the local area network 200.
  • the calculation node 100 acquires a record by receiving the record acquired from the storage 104 by the other calculation node 100 in accordance with the record acquisition request. At this time, a session is established between the computation node 100 and another computation node 100.
  • a session is created for each record acquisition request generated for each thread.
  • the number of threads increases, the number of extended sessions increases, and processing related to session management and control increases, resulting in a decrease in efficiency.
  • a session may be created for each block in which a plurality of record acquisition requests are collected.
  • FIG. 6B is an example of a schematic diagram for explaining blocking at the time of data acquisition according to the second embodiment.
  • the processor 101 of the calculation node 100 collects a plurality of record acquisition requests generated by a plurality of threads into one block (blocked record acquisition request), and the calculation node 100 and other calculation nodes 100 in units of the block. Create a session with Thereby, the number of sessions spanned between the computation nodes 100 can be reduced, and a reduction in processing efficiency can be prevented.
  • FIG. 7A shows a flow of record acquisition processing in a calculation node that acquires records according to the first embodiment.
  • This record acquisition processing corresponds to the processing of S10 and S16 in FIG. 4A and S21 and S27 in FIG. 4B.
  • the data read / write device 140 causes the storage manager 160 to issue a data read request for reading data necessary for acquiring a record to the storage 104 via the OS 170 and the HBA 103.
  • the storage manager 160 stores data read request information in the data read request management table 700 (see FIG. 7C), and sends a data read request to the request queue 740 in the main memory 105 of the computing node 100.
  • Add The OS 170 acquires a data read request from the request queue 740 and issues it to the storage 104 by the HBA 103.
  • the data reader / writer 140 identifies a thread that uses the received record based on the data read request management table 700, restarts the thread, and ends the record acquisition process.
  • FIG. 7B shows the flow of a record acquisition process in a calculation node that manages records according to the first embodiment.
  • the NIC 102 acquires the record acquisition request message, and the OS 170 stores it in the reception queue 760 of the main memory 105.
  • the data reader / writer 140 includes the received record in the acquisition completion message, and the network manager 150 transmits the acquisition completion message to the calculation node 100 that is the transmission source of the record acquisition request message, and ends the processing. Specifically, the network manager 150 adds an acquisition completion message to the transmission queue 760 in the main memory 105 of the computation node 100.
  • the process illustrated in FIG. 7A may be executed in threads (SL1, SL2, SLd 1 , SLd 2 , SLd k , SLd k + 1, etc.) that perform the processes of S10 and S16 in FIG. 4A and S21 and S27 in FIG. 4B.
  • the CPU 101 may execute the procedure corresponding to S41 to S45 in the same thread SL1 by executing the data acquisition process of S10 in the thread SL1.
  • the process illustrated in FIG. 7A is different from the threads (SL1, SL2, SLd 1 , SLd 2 , SLd k , SLd k + 1, etc.) that perform the processes of S10 and S16 in FIG. 4A and S21 and S27 in FIG.
  • the CPU 101 may execute the procedure corresponding to S41 to S45 in another thread by executing the data acquisition process of S10 in the thread SL1.
  • separate threads may be provided for the procedures corresponding to S41 to S45, the procedures corresponding to S46 to S47, and the procedures corresponding to S48 to S49, or the same thread may be used.
  • a plurality of threads may be provided for each procedure.
  • another thread may be provided to drive a procedure corresponding to S46 to S47 and a procedure corresponding to S48 to S49.
  • These driving operations may be performed by means such as an interrupt or a signal generated when the HBA 103 and the NIC 102 add the completion queue 750 and the reception queue 730.
  • FIG. 7D shows the flow of a record acquisition process in a calculation node that acquires a record according to a modification of the first embodiment.
  • the network manager 150 transmits a blocked remote record acquisition request message via the OS 170 and the NIC 102, and ends the process. Specifically, the network manager 150 stores the blocked remote record acquisition request message in the transmission queue 840 of the main memory 105, and the NIC 102 sends the blocked remote record acquisition request message from the transmission queue 840 to the destination calculation node 100. Send. Thus, since a plurality of record acquisition requests are made into one blocked remote record acquisition request message, the number of sessions established during communication can be reduced.
  • FIG. 7E shows the flow of record acquisition processing in a calculation node that manages records according to a modification of the first embodiment.
  • the data reader / writer 140 uses the storage manager 160 to read data necessary for acquiring a plurality of records to the storage 104 via the HBA 103 based on the plurality of record acquisition request messages.
  • the data read request is issued, and the process ends.
  • the storage manager 160 adds a plurality of data read requests to the request queue 880 in the main memory 105 of the computing node 100.
  • the HBA 104 acquires a data read request from the request queue 780 and issues it to the storage 104.
  • the storage 104 receives the data read request issued from the request queue 880, reads the record corresponding to the data read request, sends it to the HBA 103, and sends the data read by the HBA 103 to the completion queue 890 of the main memory 105. to add.
  • the storage manager 160 acquires a plurality of records corresponding to the data read request from the completion queue 890, extracts the records from the data, and passes them to the system module 120.
  • the data reader / writer 140 includes the received plurality of records in the blocked acquisition completion message, and the network manager 150 sends a blocked acquisition completion message to the computing node 100 that is the transmission source of the blocked remote record acquisition request message. Is transmitted, and the process ends. Specifically, the network manager 150 adds a blocked acquisition completion message to the transmission queue 870 in the main memory 105 of the computing node 100. The blocked acquisition completion message stored in the transmission queue 870 is transmitted by the NIC 102 to the calculation node 100 that is the transmission source of the blocked remote record acquisition request message. This blocked acquisition completion message is stored in the reception queue 850 by the NIC 102 in the calculation node 100 of the transmission source.
  • the process illustrated in FIG. 7D may be executed in threads (SL1, SL2, SLd 1 , SLd 2 , SLd k , SLd k + 1, etc.) that perform the processes of S10 and S16 in FIG. 4A and S21 and S27 in FIG. 4B.
  • the CPU 101 may execute the procedure corresponding to S61 to S65 in the same thread SL1 by executing the data acquisition process of S10 in the thread SL1.
  • the process illustrated in FIG. 7D is different from the threads (SL1, SL2, SLd 1 , SLd 2 , SLd k , SLd k + 1, etc.) that perform the processes of S10 and S16 in FIG. 4A and S21 and S27 in FIG.
  • the CPU 101 may execute the procedure corresponding to S61 to S65 in another thread by executing the data acquisition process of S10 in the thread SL1.
  • separate threads may be provided for the procedures corresponding to S61 to S65, the procedures corresponding to S66 to S67, and the procedures corresponding to S68 to S69, or the same thread may be used.
  • a plurality of threads may be provided for each procedure.
  • another thread may be provided to drive the procedure corresponding to S66 to S67 and the procedure corresponding to S68 to S69.
  • These driving operations may be performed by means such as an interrupt or a signal generated when the HBA 103 and the NIC 102 add the completion queue 750 and the reception queue 730.
  • the processing illustrated in FIG. 7E may be performed in a separate thread, or may be performed in the same thread, separately from the procedure corresponding to S70 to S71 and the procedure corresponding to S72 to S73.
  • a plurality of threads may be provided for each procedure. For example, a plurality of threads may be generated according to the blocked record acquisition request message acquired in S70, and the data read request may be executed by executing S71 in each of the threads. At this time, the same number of threads as the number of record acquisition requests included in the message may be generated, or a predetermined number of threads may be generated.
  • another thread may be provided. Such driving may be performed by means such as an interrupt or a signal generated by the addition of the HBA 103 to the completion queue 790.
  • FIG. 7F shows the configuration of a blocked remote record acquisition request management table according to a modification.
  • the blocked remote record acquisition request management table 830 includes a request issue time 832, the number of requests 833, and one or more record acquisition requests 834 as information for each blocked remote record acquisition request.
  • the record acquisition request 834 includes a thread ID 831, a calculation node ID 835, a record reference 836, a buffer address 837, and a completion flag 838.
  • Request issue time 832 indicates the time at which the blocked remote record acquisition request was issued.
  • the number of requests 833 indicates the number of record acquisition requests included in the bricked remote record acquisition request.
  • Record acquisition request 834 indicates the contents of the record acquisition request.
  • the thread ID 831 indicates an ID for identifying the thread that issued the record acquisition request.
  • information on how records are arranged in the data set is indispensable.
  • a text file is used as a data set and one of the lines is handled as a record
  • the record and the record are separated by a line feed code.
  • information that the record is delimited by a line feed code is indispensable.
  • a data set has a structure such as a B-tree
  • some records may be packed in an appropriate data structure in a page which is a unit of access on the storage.
  • information on the structure page length, page header / footer structure, record header / footer structure in a page, etc.
  • the system module or the like may cache a part of the data in the data set in the main memory to reduce access to the storage. For example, when acquiring a record by scanning a text file, instead of accessing the storage for each record, the data is read from the text file in units of 1 megabyte at a time and stored in the main memory. A record may be taken out from the inside.
  • the node level resource constraint management table 900 includes a computation node ID 901 and a resource constraint 902 as information for each computation node.
  • the resource constraint 902 has a thread count 903 and a main memory allocation 904.
  • Various information is as follows.
  • the calculation node ID 901 indicates the ID of the calculation node.
  • Resource constraint 902 indicates a resource constraint in the computation node corresponding to the computation node ID 901.
  • the number of threads 903 indicates the maximum number of threads that can be generated in the calculation node corresponding to the calculation node ID 901.
  • Main memory allocation 904 indicates the maximum amount of main memory that can be allocated in the calculation node corresponding to the calculation node ID 901.
  • the node-level resource constraint management table 910 on the lower side of FIG. 8A is managed by a supervisor process in each computation node 100.
  • the node level resource constraint management table 910 includes a calculation node ID 911, a resource constraint 912, and a resource usage 913 as information of its own calculation node.
  • the resource constraint 912 has a thread number 914 and a main memory allocation 915.
  • the resource use 913 has a thread number 916 and a main memory allocation 917.
  • Various information is as follows.
  • the calculation node ID 911 indicates the ID (calculation node ID) of its own calculation node.
  • Resource constraint 912 indicates a resource constraint in its own computation node.
  • Resource use 913 indicates a resource used in its own computation node.
  • the number of threads 914 indicates the maximum number of threads that can be generated in its own computation node.
  • Main memory allocation 915 indicates the maximum amount of main memory that can be allocated in its own computation node.
  • the number of threads 916 indicates the number of threads actually generated in its own computation node.
  • Main memory allocation 917 indicates the storage amount of the main memory actually allocated in its own computation node.
  • FIG. 8B shows the configuration of a job level resource constraint management table according to the first embodiment.
  • the resource level management table 920 at the upper level of FIG. 8B is managed by the overall supervisor process.
  • the job level resource constraint management table 920 includes a job ID 921, a calculation node ID 922, and a resource constraint 923 as information for each job.
  • the resource constraint 923 has a thread number 924 and a main memory allocation 925.
  • Various information is as follows.
  • the job ID 921 indicates a job ID (job ID).
  • the calculation node ID 922 indicates the ID (calculation node ID) of the calculation node that executes the job with the job ID 921.
  • Resource constraint 923 indicates a resource constraint for the job with job ID 921 in the computation node with computation node ID 922.
  • the thread number 924 indicates the maximum number of threads that can be generated for the job with the job ID 921 in the calculation node with the calculation node ID 922.
  • Main memory allocation 925 indicates the maximum amount of main memory that can be allocated to the job with job ID 921 in the calculation node with calculation node ID 922.
  • the node-level resource constraint management table 930 on the lower side of FIG. 8B is managed by a supervisor process in each computation node 100.
  • the node level resource constraint management table 930 includes a job ID 931, a calculation node ID 932, a resource constraint 933, and a resource usage 934 as information for each job in its own computation node.
  • the resource constraint 933 has a thread number 935 and a main memory allocation 936.
  • the resource use 934 has a thread number 937 and a main memory allocation 938.
  • Various information is as follows.
  • Job ID 931 indicates a job ID (job ID).
  • the calculation node ID 932 indicates an ID (calculation node ID) of its own calculation node.
  • Resource constraint 933 indicates a resource constraint for the job with job ID 931 in its own computation node 100.
  • FIG. 8C shows a configuration of a process level resource constraint management table in the supervisor process according to the first embodiment.
  • the process level resource constraint management table 940 is managed by the supervisory supervisor process.
  • the process level resource constraint management table 940 includes a process ID 941, a job ID 942, a calculation node ID 943, and a resource constraint 944 as information for each process.
  • the resource constraint 944 has a thread number 945 and a main memory allocation 946.
  • Various information is as follows.
  • Process ID 941 indicates a process ID (process ID).
  • Job ID 942 indicates a job ID.
  • the calculation node ID 943 indicates the ID (calculation node ID) of the calculation node that executes the process with the process ID 941 of the job with the job ID 921.
  • Resource constraint 944 indicates a resource constraint for the process with the process ID 941 of the job with the job ID 942 in the computation node with the computation node ID 943.
  • the number of threads 945 indicates the maximum number of threads that can be generated for the process with the process ID 941 of the job with the job ID 942 in the calculation node with the calculation node ID 943.
  • Main memory allocation 946 indicates the maximum storage amount of main memory that can be allocated to the process with the process ID 941 of the job with the job ID 942 in the calculation node with the calculation node ID 943.
  • FIG. 8D shows a configuration of a process level resource constraint management table in the supervisor process of each node according to the first embodiment.
  • the process level resource constraint management table 950 is managed by a supervisor process in each computation node 100.
  • the process level resource constraint management table 950 includes a process ID 951, a job ID 952, a computation node ID 953, a resource constraint 954, and a resource usage 955 as information for each process in each job in its own computation node.
  • the resource constraint 954 has a thread count 956 and a main memory allocation 957.
  • the resource use 955 has a thread count 958 and a main memory allocation 959.
  • Various information is as follows.
  • Process ID 951 indicates the ID of the process.
  • Job ID 952 indicates a job ID.
  • the calculation node ID 953 indicates the ID (calculation node ID) of its own calculation node 100.
  • Resource constraint 954 indicates a resource constraint for the process with the process ID 951 of the job with the job ID 952 in its own computation node 100.
  • Resource use 955 indicates the resource used for the process with the process ID 951 of the job with the job ID 952 in its own computation node 100.
  • the number of threads 956 indicates the maximum number of threads that can be generated for the process with the process ID 951 of the job with the job ID 952 in its own computation node 100.
  • Main memory allocation 957 indicates the maximum amount of main memory that can be allocated to the process with the process ID 951 of the job with the job ID 952 in its own computation node 100.
  • the number of threads 958 indicates the number of threads actually generated for the process with the process ID 951 of the job with the job ID 952 in its own computation node 100.
  • Main memory allocation 959 indicates the storage amount of the main memory actually allocated to the process with the process ID 951 of the job with the job ID 952 in its own computation node 100.
  • FIG. 8E shows the configuration of a task level resource constraint management table in the overall supervisor process according to the first embodiment.
  • the task level resource constraint management table 960 is managed by the supervisory supervisor process.
  • the task level resource constraint management table 960 includes a task ID 961, a process ID 962, a job ID 963, a calculation node ID 964, and a resource constraint 965 as information for each task.
  • the resource constraint 944 has a thread number 945 and a main memory allocation 946.
  • Task ID 961 indicates a task ID (process ID).
  • Process ID 962 indicates a process ID (process ID).
  • Job ID 963 indicates a job ID.
  • the calculation node ID 964 indicates the ID (calculation node ID) of the calculation node that executes the task with the task ID 961 of the process with the process ID 962 of the job with the job ID 963.
  • Resource constraint 965 indicates a resource constraint for the task with the task ID 961 of the process with the process ID 962 of the job with the job ID 963 in the computation node with the computation node ID 964.
  • the number of threads 966 indicates the maximum number of threads that can be generated for the task with the task ID 961 of the process with the process ID 962 of the job with the job ID 963 in the calculation node with the calculation node ID 964.
  • Main memory allocation 967 indicates the maximum storage amount of main memory that can be allocated to the task with task ID 961 of the process with process ID 962 of job ID 963 in the calculation node with calculation node ID 964.
  • FIG. 8F illustrates a configuration of a task level resource constraint management table in the supervisor process of each node according to the first embodiment.
  • the task level resource constraint management table 970 is managed by a supervisor process in each computation node 100.
  • the task level resource constraint management table 970 includes a task ID 971, a process ID 972, a job ID 973, a calculation node ID 974, a resource constraint 975, and a resource usage 976 as information on each task of each process in each job in its own computation node.
  • the resource constraint 975 has a thread number 977 and a main memory allocation 978.
  • the resource use 976 has a thread number 979 and a main memory allocation 980.
  • Task ID 971 indicates the ID of the task.
  • Process ID 972 indicates the ID of the process.
  • Job ID 973 indicates a job ID.
  • the calculation node ID 974 indicates the ID (calculation node ID) of its own calculation node 100.
  • the resource constraint 975 indicates a resource constraint for the task with the task ID 971 of the process with the process ID 972 of the job with the job ID 973 in its own computation node 100.
  • Resource use 976 indicates a resource that is used for the task with the task ID 971 of the process with the process ID 972 of the job with the job ID 973 in its own computation node 100.
  • the number of threads 977 indicates the maximum number of threads that can be generated for the task with the task ID 971 of the process with the process ID 972 of the job with the job ID 973 in its own computation node 100.
  • Main memory allocation 978 indicates the maximum amount of main memory that can be allocated to the task of task ID 971 of the process ID 972 of the job of job ID 973 in its own computation node 100.
  • the number of threads 979 indicates the number of threads actually generated for the task with the task ID 971 of the process with the process ID 972 of the job with the job ID 973 in the own computation node 100.
  • Main memory allocation 980 indicates the storage amount of main memory that is actually allocated to the task of task ID 971 of the process ID 972 of the job of job ID 973 in its own computation node 100.
  • FIG. 8G shows the flow of the integrated resource constraint management process according to the first embodiment.
  • the supervisory process in the computing node 100 that supervises the supervisor process of each computing node 100 assigns a new task, it calculates resource constraints for the new task.
  • the resource constraint specified by the user may be used, or the resource constraint may be calculated (for example, proportionally distributed) based on the policy specified by the user.
  • the supervisory supervisor process adds a record for the new task to the task level resource constraint management table 960 as shown in FIG. 8E, and stores the resource constraint calculated for the resource constraint of the record.
  • the supervisory supervisor process selects a computation node 100 that can execute a task within the scope of the resource constraint, and transmits the resource constraint related to the computation node to the computation node 100.
  • the supervisory supervisor process assigns a task to the selected computation node 100 and ends the process.
  • the supervisor process of the computing node 100 to which the task is assigned receives the resource constraint transmitted in Step S82, and registers the resource constraint in the task level resource constraint management table 970 as shown in FIG. 8F.
  • system module 120 of the compute node 100 to which the task is assigned executes the assigned task.
  • FIG. 8H illustrates a flow of resource constraint management processing in each computation node according to the first embodiment.
  • the resource constraint management process is realized, for example, when the system module 120 executes a task.
  • the process at the upper left of FIG. 8H (steps S90 to S94) is a process executed when attempting to generate a thread in a task. This is, for example, processing executed in S13 of FIG. 4A and S24 and S31 of FIG. 4B.
  • the system module 120 determines whether there are sufficient resources to generate a thread.
  • a task level resource constraint management table 970 a process level resource constraint management table 950, a job level resource constraint management table 930, and a node level
  • Each resource constraint management table 910 can be referred to, and it can be determined whether or not the resources available within the resource constraint range at each level are more than the resources sufficient to generate threads.
  • the system module 120 causes the thread manager 133 to generate a thread, allocates the resource to the thread, and reflects the allocation result in the resource usage of each resource constraint management table (910, 930, 950, and 970). .
  • the system module 120 starts executing the thread and ends the resource constraint management process.
  • the system module 120 saves the thread generation information to be referenced for generating a thread in the thread generation suspension management table 990.
  • the system module 120 sets the own thread as a suspended state where the generation of the thread is suspended, and ends the process.
  • the thread generation suspension management table 990 includes a task ID 991, a parent thread ID 992, a child thread ID 993, a time 994, and thread generation information 995 as information on threads that are suspended from thread generation.
  • Task ID 991 indicates the ID of the task.
  • the parent thread ID 992 indicates the ID of a parent thread (parent thread) that generates another thread.
  • Child thread ID 993 indicates the ID of a thread (child thread) that is a child generated from the thread.
  • Time 994 indicates the time when the generation of the thread is suspended.
  • the thread generation information 995 is information necessary for generating a thread (for example, information including a reference indicating a record referred to by a child thread).
  • the process in the upper right of FIG. 8H is a process for stopping the thread when the process executed by the thread is completed.
  • the system module 120 stops the executing thread.
  • the system module 120 releases resources allocated to its own thread. That is, the system module 120 deletes the amount of resources allocated to its own thread from the resource amounts (number of threads, main memory allocation amount) managed by resource usage such as the resource constraint management table 910. As a result, the resources allocated to the own thread can be allocated to other threads.
  • the processing at the lower right of FIG. 8H is processing that is executed when it is determined, for example, that there are sufficient resources to generate a thread based on the resource constraint management table 910.
  • This procedure may be driven, for example, by means such as an interrupt or a signal when resources are released in S96.
  • the system module 120 selects the thread generation information managed in the thread generation suspension management table 990.
  • the thread generation information to be selected may be, for example, the oldest thread generation information reserved.
  • the system module 120 resumes the parent thread that generates a thread based on the selected thread generation information.
  • the system module 120 executes child thread generation again based on the thread generation information. With this process, when there are sufficient resources to generate a thread, a thread that has been suspended can be generated.
  • FIG. 9A shows a first example of tasks according to the first embodiment.
  • FIG. 9A shows map task # 1111 of map process # 111 of map reduce job # 1 (corresponding to the job execution plan of FIG. 1A).
  • the record of # 1001 of the input data set # 1 includes references to 10 records # 2001 to # 2010 of the input data set # 2.
  • map task # 1111 acquires the record of # 1001 of input data set # 1, and acquires the record of input data set # 2.
  • the record of # 1001 of the input data set # 1 is referred to. If the record satisfies a predetermined condition, the reference included in the record is used. Thus, records # 2001 to # 2010 of the input data set # 2 are acquired.
  • FIG. 9B shows an example of thread generation in the task shown in the first example.
  • FIG. 9B illustrates thread generation when the task # 1111 illustrated in FIG. 9A is not performed when the resource constraint management process illustrated in FIG. 8H is not performed.
  • the horizontal axis represents time.
  • a round rectangle with a long side in the figure means a series of processing by one thread.
  • the left end of the rounded rectangle represents the time at which the processing by the thread is started, and the right end of the rounded rectangle represents the time at which the processing by the thread ends.
  • the value inside the (*) rounded rectangle represents information (for example, record ID) indicating a record that is read along with the processing corresponding to the thread.
  • the number of threads that can be executed simultaneously for the thread that acquires the record is “8”.
  • the thread 10a further acquires and processes the # 2008 record of the input data set # 2 and performs processing, the thread 10j that acquires and processes the record of # 2009 of the input data set # 2, and A thread 10k that acquires and processes a record of # 2010 of the input data set # 2 is generated and executed.
  • the main memory is allocated beyond the available amount of main memory, and thrashing occurs, resulting in a long execution time for these threads.
  • FIG. 9C illustrates an example of thread generation in the task illustrated in the first example according to the first embodiment.
  • FIG. 9C shows thread generation when the resource constraint management process shown in FIG. 8H is performed when the task # 1111 shown in FIG. 9A is executed.
  • the notation in FIG. 9C is the same as the rule in FIG. 9B.
  • the thread # 10a When the thread 10a that executes processing by acquiring the record # 1001 of the input data set # 1 is executed in the computation node 100, the thread # 10a acquires the record # 1001 and includes it in the record # 1001.
  • the thread 10b that acquires and processes the record of # 2001 of the input data set # 2 is generated and executed based on the received reference, and acquires and processes the record of # 2002 of the input data set # 2.
  • a thread 10c is generated and executed.
  • a thread 10d, a thread 10e, a thread 10f, a thread 10g, and a thread 10h are generated and executed. At this time, the same number of threads as “8”, which is the number of threads that can be executed simultaneously, are executed.
  • step S90 of the resource constraint management process since it is determined in step S90 of the resource constraint management process that there are not enough resources, the thread 10a is put on hold without generating a new thread.
  • the execution of the thread 10b When the execution of the thread 10b is completed, one new thread can be executed. Therefore, the execution of the thread 10a is resumed in step S98, and the record of # 2008 of the input data set # 2 is detected in step S99.
  • a thread 10i is generated that performs processing by acquiring.
  • the execution of the thread 10c is finished, the execution of the thread 10a is resumed, and the thread 10j that acquires and processes the record of # 2009 of the input data set # 2 is generated and executed.
  • the execution of the thread 10d When the execution of the thread 10d is completed, the execution of the thread 10a is resumed, and the thread 10k that acquires and processes the record of # 2010 of the input data set # 2 is generated and executed.
  • FIG. 9D shows a second example of tasks according to the second embodiment.
  • FIG. 9D shows the map task # 1111 of the map process # 111 of the map reduce job # 1 and the map task # 2111 of the map process # 211 of the map reduce job # 2. It is assumed that map task # 1111 and map task # 2111 are executed in parallel.
  • the record of # 1001 of the input data set # 1 includes references to 10 records from # 2001 to # 2010 of the input data set # 2.
  • the map task # 1111 acquires the record of # 1001 of the input data set # 1, and acquires the data of the input data set # 2 corresponding to this record.
  • the system module 120 When executing the map task # 1111, the system module 120 refers to the record of # 1001 of the input data set # 1, and if the record satisfies a predetermined condition, the system module 120 uses the reference included in the record. Thus, records # 2001 to # 2010 of the input data set # 2 are acquired.
  • map task # 2111 acquires a record of # 5001 of input data set # 5, and acquires a record of input data set # 6 corresponding to this record.
  • the system module 120 When executing the map task # 2111, the system module 120 refers to the record of # 5001 of the input data set # 5. If the record satisfies a predetermined condition, the system module 120 uses the reference included in the record. Thus, records # 6001 to # 6010 of the input data set # 6 are acquired.
  • FIG. 9E illustrates an example of thread generation in the task illustrated in the second example according to the first embodiment.
  • FIG. 9E shows thread generation when the resource constraint management process shown in FIG. 8H is performed when task # 1111 and task # 2111 shown in FIG. 9D are executed in parallel.
  • the main memory area available for task # 1111 is for five threads
  • the main memory area available for task # 2111 is for three threads. Note that the notation in FIG. 9E is the same as the rule in FIG. 9B.
  • the thread 11a When the thread 11a that executes processing by acquiring the record of # 1001 of the input data set # 1 is executed in the calculation node 100, the thread 11a acquires the record of # 1001 and is included in the record of # 1001.
  • the thread 11b that acquires and processes the record of # 2001 of the input data set # 2 is generated and executed based on the received reference, and acquires and processes the record of # 2002 of the input data set # 2.
  • a thread 11c is generated and executed.
  • a thread 10d and a thread 10e are generated and executed. At this time, an area corresponding to 5 threads in the main memory that can be used by the task # 1111 is used.
  • step S90 of the resource constraint management process since it is determined in step S90 of the resource constraint management process that there are not enough resources, the thread 11a does not generate a new thread, and its own thread is put on hold.
  • the execution of the thread 11b is completed, one new thread can be executed. Therefore, the execution of the thread 11a is resumed in step S98, and the record of # 2005 of the input data set # 2 in step S99.
  • a thread 11f is generated that performs processing by acquiring.
  • the execution of the thread 11c is finished, the execution of the thread 11a is resumed, and the thread 11g for acquiring and processing the record of # 2006 of the input data set # 2 is generated and executed.
  • the execution of the thread 11d When the execution of the thread 11d is finished, the execution of the thread 11a is resumed, and the thread 11h that acquires and processes the record of # 2007 of the input data set # 2 is generated, and the execution of the thread 11d is finished. In this case, the execution of the thread 11a is resumed, and the thread 11i for obtaining and processing the record of # 2008 of the input data set # 2 is generated.
  • the execution of the thread 11f is completed, the thread 11a Execution is resumed, and a thread 11j is generated that acquires and processes the record of # 2009 of the input data set # 2. , If the execution of the thread 11g is completed, the execution of the thread 11a is resumed, the input data set # 2 # thread 11k to perform acquisition and processing records 2010 are generated.
  • the thread 12a that performs processing by acquiring the record of # 5001 of the input data set # 5 is executed in parallel, the record of # 5001 is acquired by the thread 12a and included in the record of # 5001.
  • the thread 12b that acquires and processes the record of # 6001 of the input data set # 6 is generated and executed based on the received reference, and acquires and processes the record of # 6002 of the input data set # 6
  • a thread 12c is generated and executed. At this time, an area corresponding to three threads of the main memory that can be used for task # 2111 is used.
  • step S90 of the resource constraint management process since it is determined in step S90 of the resource constraint management process that there are not enough resources, the thread 12a does not generate a new thread, and its own thread is put on hold. When the execution of the thread 12b ends, one new thread can be executed. Therefore, the execution of the thread 12a is resumed in step S98, and the record of # 6003 of the input data set # 6 is detected in step S99. A thread 12d is generated that performs processing by acquiring.
  • a thread 12e for obtaining and processing the record of # 6004 of the input data set # 6 is generated, and when the execution of the thread 12d is finished, the input
  • a thread 12f for obtaining and processing the record of # 6005 of the data set # 6 is generated and the execution of the thread 12e is finished
  • the record of # 6006 of the input data set # 6 is obtained and processed.
  • a thread 12h for obtaining and processing the record of # 6007 of the input data set # 6 is generated, and when the execution of the thread 12g is finished.
  • a thread 12i for obtaining and processing the record of # 6008 of the input data set # 6 is generated, and the thread 12h
  • a thread 12j for obtaining and processing the record of # 6009 of the input data set # 6 is generated, and when the execution of the thread 12i is finished, # 6010 of the input data set # 6.
  • a thread 12k that acquires and processes the record is generated. In this way, a plurality of tasks can be executed in parallel.
  • Threads that are dynamically generated when executing parallel data processing.
  • a process or a kernel level thread such as a native POSIX thread or a lightweight process
  • Threads managed by the kernel
  • user-level threads threads managed by user programs and libraries such as fiber
  • It may be a collection of fixed procedures to be managed (for example, a function pointer managed by an appropriate structure), or a combination of these.
  • the unit of data handled by parallel data processing is a record, but the record may be arbitrary data. For example, it may be a collection of a certain number of columns, a collection of a variable number of columns, a simple text, a byte string, an image, sound, etc.
  • the multimedia content may also be a collection of these.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　並列データ処理システムは、複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群からデータを読み込んで処理を実行する並列データ処理実行部を有する。並列データ処理実行部は、（Ａ）第１データ群から、第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、第１データから第１の値を取得し、（Ｂ）アプリケーションから取得した第１参照情報に基づき、第１の値に対応する１以上の第２データのそれぞれを第２データ群から読み込むための１以上のスレッドを生成し、（Ｃ）（Ａ）～（Ｂ）を、第１データ群の１以上の第１データに対して実行し、（Ｄ）複数のスレッドを並行して実行する。

Description

並列データ処理システム、計算機および並列データ処理方法
　本発明は、並列データ処理技術に関する。
　企業等の活動においては、業務等に係る大量のデータを戦略的に利用することが極めて重要になってきている。大量のデータを利用するための情報システムとしては、Hadoopをはじめとする並列データ処理システムが用いられている。当該並列データ処理システムは、例えば、特許文献１に開示されている。
米国特許第７７５６９１９号明細書
　Hadoopをはじめとする並列データ処理システムにおいては、ストレージ等に格納されたデータセット（例えばファイルシステムに格納されたファイル）の全体を読み込んで処理することを基本としている。例えば、アプリケーション（ジョブ）が処理の対象とするデータに選択性を有する場合（即ち、ストレージ等に格納されたデータセットのうち一部のレコードを処理の対象とする場合）であっても、データセットの全体を読み込む必要があり、データ処理が必ずしも効率的でなく行われ、よってデータ処理に係る時間が長くなる場合がある。また、データセットが巨大化するに従い、データセットの全体を読み込むのに要する時間が長くなり、よってデータ処理に係る時間が長くなる場合がある。
　そこで、本発明の目的は、データ処理に係る時間を短縮することにある。
　複数の計算ノード（例えば、計算機）において並行してデータ処理を実行する計算機システムにおける１つの計算ノードが有する並列データ処理システムが、複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群からデータを読み込んで処理を実行する並列データ処理実行部を有する。並列データ処理システムは、例えば、後述する実施例１及び２におけるシステムモジュールでよい。第１データ群における第１データが、第２データ群の第２データに対応していてよい。例えば、第１データ群は第２データ群の索引であってよい。この際、第１データは、第２データの索引鍵の値と、当該索引鍵の値に対応する１以上の第２データへの参照を含んでよい。
　並列データ処理実行部は、
（Ａ）第１データ群から、第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、第１データから第１の値を取得し、
（Ｂ）アプリケーションから取得した第１参照情報に基づき、第１の値に対応する１以上の第２データのそれぞれを第２データ群から読み込むための１以上のスレッドを生成し、
（Ｃ）（Ａ）～（Ｂ）を、第１データ群の１以上の第１データに対して実行し、
（Ｄ）複数の前記スレッドを並行して実行する。
　並列データ処理システムは、処理の指示をアプリケーションから受け付ける受付部を更に有していてよい。アプリケーションからの指示は、一般に、手続を規定しているが、並列データ処理実行部は、アプリケーションからの指示を受けて、（Ａ）乃至（Ｄ）を実行することにより、アプリケーションからの指示が、手続を規定していても、並列データ処理システムは、手続に依存しない非順序の処理を実行することができる。
　本発明によれば、計算ノードはデータ処理に係るデータの読み込みを並行して実行することができるようになる。これにより、データ読み込みのスループットが向上し、故に、データ処理に係る時間が短縮されることが期待される。
図１Ａは、実施例１に係るジョブ実行モデルを示す。 図１Ｂは、実施例２に係るジョブ実行モデルを示す。 図２Ａは、実施例１に係る計算ノードの構成を示す。 図２Ｂは、実施例２に係る計算ノードの構成を示す。 図３Ａは、実施例に係る計算機システムの第１の構成例を示す。 図３Ｂは、実施例に係る計算機システムの第２の構成例を示す。 図４Ａは、実施例１に係るマップタスク実行処理の流れを示す。 図４Ｂは、実施例２に係るタスク実行処理の流れを示す。 図５Ａは、実施例１に係る入力データ及び入力データに対する処理を説明するための図である。 図５Ｂは、実施例１に係る書式及び参照の一例を示す。 図５Ｃは、スレッド生成及びスレッドの実行を説明する模式図の一例である。 図５Ｄは、実施例２に係る入力データ及び入力データに対する処理を説明するための第１の図である。 図５Ｅは、実施例２に係る入力データ及び入力データに対する処理を説明するための第２の図である。 図５Ｆは、実施例２に係る書式の一例を示す。 図５Ｇは、実施例２に係る参照方式の一例を示す。 図５Ｈは、実施例２に係るカタログの一例を示す。 図６Ａは、データ取得時のセッションを説明するための模式図の一例である。 図６Ｂは、変形例に係るデータ取得時のブロック化セッションを説明するための模式図の一例である。 図７Ａは、実施例１に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。 図７Ｂは、実施例１に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。 図７Ｃは、実施例１に係るデータ読み込み要求管理表及びリモートレコード取得要求管理表の構成を示す。 図７Ｄは、実施例１の変形例に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。 図７Ｅは、実施例１の変形例に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。 図７Ｆは、実施例１の変形例に係るブロック化リモートレコード取得要求管理表の構成を示す。 図８Ａは、実施例１に係るノードレベルの資源制約管理表の構成を示す。 図８Ｂは、実施例１に係るジョブレベルの資源制約管理表の構成を示す。 図８Ｃは、実施例１に係る統括スーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。 図８Ｄは、実施例１に係る各ノードのスーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。 図８Ｅは、実施例１に係る統括スーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。 図８Ｆは、実施例１に係る各ノードのスーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。 図８Ｇは、実施例１に係る統括資源制約管理処理の流れを示す。 図８Ｈは、実施例１に係る各ノードにおける資源制約管理処理の流れを示す。 図９Ａは、実施例１に係るタスクの第１の例を示す。 図９Ｂは、実施例１に係る第１の例に示すタスクにおけるスレッドの生成の一例を示す。 図９Ｃは、実施例１に係る第１の例に示すタスクにおけるスレッドの生成の一例を示す。 図９Ｄは、実施例１に係るタスクの第２の例を示す。 図９Ｅは、実施例１に係る第２の例に示すタスクにおけるスレッドの生成の一例を示す。
　以下、図面を参照しながら、幾つかの実施例及び変形例を説明する。なお、以下の説明により本発明が限定されるものではない。
　まず、実施例１に係るジョブ実行モデルを説明する。
　図１Ａは、実施例１に係るジョブ実行モデルを示す。なお、図１Ａにおいては、１つの実線の円は１つのプロセス（例えば、マッププロセスやリデュースプロセス）を示す。プロセス内の１つの破線の円は１つのタスクを示す。タスク中の１つの角丸四角は１つのスレッドを示す。
　当該ジョブ実行モデルによれば、ジョブはネットワークで接続された複数の計算ノードによって実行される。例えば、複数の計算ノードの全体を統括する計算ノードにおけるスーパバイザプロセス（以下、統括スーパバイザプロセスとする）が、ジョブの実行に参加する全計算ノードにアプリケーションのコードを配布し、統括スーパバイザプロセスが各計算ノードのスーパバイザプロセスに対してマッププロセスやリデュースプロセスなどのプロセスの割り当てを行う。各計算ノードのスーパバイザプロセスは、統括スーパバイザプロセスの指示に基づいて、プロセスを生成する。また、生成されたプロセスは、統括スーパバイザプロセスの指示に基づいて、タスクを生成する。各計算ノードは、このように生成されたプロセス及びタスクを実行することにより、アプリケーションに含まれるマップ演算等を実行して、ジョブを実行する。統括スーパバイザプロセスは、複数の計算ノードにおける複数のスーパバイザプロセスのいずれか１つであってもよいし（即ち、いずれか１つのスーパバイザプロセスが、統括スーパバイザプロセスを兼ねてもよいし）、複数のスーパバイザプロセスとは別に用意された、専用の統括スーパバイザプロセスとして機能する専用のプロセスであってもよい。また、プロセスの割り当ては上記に限らず、統括スーパスーパバイザプロセスが各計算ノードのスーパバイザプロセスに指示を行って行ってもよく、プロセスやタスクの生成は上記に限らず、統括スーパバイザプロセスが直接行ってもよい。
　並列データ処理システムは、ジョブ実行モデルに従い、マッププロセスを実行し、ストレージに格納された入力データセット＃１（即ち、第１のデータセット）と入力データセット＃２（即ち、第２のデータセット）とに含まれるレコードを読み込んで、マップ演算を実行し、その結果レコードをストレージに格納された中間データセットに書き込む。更に、リデュースプロセスを実行し、中間データセットに書き込まれた結果レコードを入力として、リデュース演算を実行し、その結果レコードを出力データセット＃１に書き込む。入力データセット、中間データセットならびに出力データセットはそれぞれ複数のレコードの集まりであり、何らかのデータ構造によって構造化されていてもよいし、構造化されていなくてもよい。例えば、入力データセット＃２は、１以上のファイルの集合であってもよい。
　入力データセット＃１はそのレコードが、入力データセット＃２のレコードに対応したものであればよい。例えば、入力データセット＃１は、入力データセット＃２の索引であってもよい。入力データセット＃１の各レコードは、入力データセット＃２のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット＃２の１以上のレコードを示す参照を含んでよい。この際、参照は入力データセット＃２のレコードを記憶装置上で特定可能な格納位置を含んでもよいし、入力データセット＃２を格納するのに設けられたデータ構造上においてレコードを特定可能な唯一性のある索引鍵を含んでもよい。また、入力データセット＃１は入力データセット＃２の全てのレコードに対応するレコードを有していてもよいし、入力データセット＃２の一部のレコードに対応するレコードのみを有していてもよい。また、入力データセット＃１は、入力データセット＃２の索引でなくてもよい。例えば、入力データセット＃１と入力データセット＃２は結合可能な関係にあり、入力データセット＃１は単なるレコードの集まりであり、入力データセット＃２はレコードの集まりであって、データ構造によってある索引鍵によって構造化されており、入力データセット＃１のあるレコードのある項目の値に対応するような、索引鍵の値を有する入力データセット＃２のレコードを読み込むものであってもよい。また、入力データセット＃１と入力データセット＃２は、同じデータ構造に属するものであってもよい。例えば、入力データセット＃１はＢ木を構成する内部ノードの集合であり、入力データセット＃２は同じＢ木を構成する葉ノードの集合であってもよい。更に、入力データセット＃１はＢ木を構成するあるレベルのノードの集合であり、入力データセット＃２は同じＢ木を構成する次のレベルの（入力データセット＃１から参照される）ノードの集合であってもよい。また、入力データセットは３つ以上から構成されてもよく、例えば、更に、入力データセット＃２のレコードに対応した別の入力データセットがあってもよい。
　マッププロセスにおいては、マップ演算、分割演算、書式＃１、書式＃２、参照方式、条件等に従い、各計算ノードのプロセッサによりデータ処理が実行される。マップ演算、分割演算、書式＃１、書式＃２、参照方式、条件等は、計算ノードに格納されているアプリケーションに含まれるプログラムコードである。マップ演算は、読み込んだレコードに対して適用される処理を規定するプログラムコードであり、例えば、読み込んだレコードからキーとバリューのペアからなる結果レコードを生成するものである。分割演算は、マップ演算を実行したのち、その実行結果を受け渡すリデュースプロセスを決定する際に実行されるプログラムコードであり、例えば、分割演算はマップ演算の結果レコードが含むキーに対するハッシュ演算などを含んでよい。書式＃１は、入力データセット＃１のレコードを解釈するための書式を規定するプログラムコードである。書式＃２は、入力データセット＃２のレコードを解釈するための書式を規定するプログラムコードである。参照方式は、入力データセット＃１のレコードの参照に従い、入力データセット＃２のレコードを取得する方式を規定するプログラムコードである。条件は、入力データセット＃１及び／又は入力データセット＃２に格納されたレコードのうちマップ演算の対象とするべきレコードの要件を規定するプログラムコードである。当該条件は、その全部もしくは一部が、入力データセット＃１ならびに入力データセット＃２のいずれかからレコードを読み込む際に実行されてもよいし、その全部もしくは一部が、読み込んだレコードをマップ演算に入力する際に実行されてもよい。なお、プログラムコードは、コンパイル等によって生成されたプロセッサで実行可能な命令であってもよいし、実行処理系等によってプロセッサで実行可能な命令に変換することができる命令であってもよいし、実行処理系等によってプロセッサで実行可能な命令を生成することのできる宣言であってもよい。更に、これらを組み合わせたものであってもよいし、他の情報を更に含んでよい。命令ならびに宣言は、プロセッサ、コンパイラもしくは実行処理系等が解釈可能なバイト列であってもよいし、ソースコート等で記述されていてもよい。
　具体的に説明すると、計算ノードのプロセッサは、マッププロセスにおいてタスクを実行し、当該タスクにおいて、入力データセット＃１からレコードを読み込み、書式＃１を用いてレコードを解釈し、条件に基づいて、当該レコードが要件を満たすかどうかを判定し、要件を満たしたレコードから入力データセット＃２への参照を取得する。この際、入力データセット＃１は、事前に複数のチャンクに分割されていてもよい。例えば、入力データセット＃１は複数のファイルから構成されていてもよく、統括スーパバイザプロセスが各々のファイルに対して別のタスクを割り当て、各タスクは割り当てられたファイルからレコードを読み込むこととしてもよい。もしくは、入力データセット＃１は、実行時に複数のチャンクから構成されているかの如く分割可能であってもよい。例えば、入力データセット＃１は単一のファイルから構成されており、当該ファイル中の複数の重なりのない領域を示す情報を備えており、統括スーパバイザプロセスがそれぞれの領域を先述のチャンクとして見做して別のタスクを割り当て、各タスクは割り当てられた領域からレコードを読み込むこととしてもよい。領域を示す情報は事前に与えられていてもよく、もしくは、統括スーパバイザプロセスによって実行時に決定されてもよい。また、領域と別の領域の間に重なりがあっても、読み込む際に一方の領域に割り当てられたタスクが重なり部分を読み込まないようにする手段が具備されていてもよい。また、入力データセット＃１からレコードを読み込む際に、入力データセット＃１が条件に規定された要件を満足するレコードに対して選択的なアクセスを可能とするデータ構造を以って構成されている（例えば、整列されている、もしくはＢ木等で構成されている）場合には、条件に規定された要件を用いて選択的なアクセスを行ってよい。
　次いで、プロセッサは、入力データセット＃１のレコードが含む参照に基づいて入力データセット＃２からレコードを読み込むためにスレッドを生成する。入力データセット＃１のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット＃１のレコードが有する参照の各々に対してスレッドを生成してもよい。これらのスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式に基づいて、参照によって入力データセット＃２のレコードを読み込む。プロセッサは、書式＃２を用いて読み込んだレコードを解釈し、条件に基づいて当該レコードが要件を満たすかどうかを判定する。プロセッサは、要件を満たすレコードに対して、マップ演算を実行し、更に、分割演算を実行することによりマップ演算の実行結果を送るべきリデュースプロセスを決定する。プロセッサは、決定したリデュースプロセスがマップ演算の実行結果を受け取れるように出力する。具体的には、実行結果を中間データセットに格納する。
　リデュースプロセスにおいては、リデュース演算等に従い、各計算ノードのプロセッサによりデータ処理が実行される。リデュース演算は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。リデュース演算は、中間データセットのレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算の生成した結果レコード（キーとバリューのペアからなる）をキーに従って集約することにより結果レコードを生成するものである。
　具体的には、プロセッサは、中間データセットからマップ演算の実行結果レコードを取得し、当該レコードを入力として、リデュース演算を実行して、その実行結果レコードを出力データセット＃１に格納する。
　マップ演算、分割演算、書式＃１、書式＃２、参照方式、条件、リデュース演算はその全てがアプリケーションで規定されている必要はなく、その一部が規定されていればよい。規定されていないものについては、所定の取り扱いを行ってよい。例えば、リデュース演算が規定されていない場合は（即ち、リデュースプロセスが規定されていない場合は）、マッププロセスの出力をジョブの出力と見做してよい。
　マッププロセス及び／又はリデュースプロセスでは、更に比較演算に従い、また、マッププロセスでは、更に集約演算に従い、各計算ノードのプロセッサによりデータ処理が実行されてもよい。比較演算、集約演算は、計算ノードに格納されているアプリケーションに含まれるプログラムコードである。比較演算は、マッププロセスにおいて分割演算の結果レコードを中間データセットに書き込む際に、もしくは、リデュースプロセスにおいてリデュース演算の入力レコードを中間データセットから読み込む際に、結果レコード／入力レコードを一旦、整列するために当該レコード間の順序性を規定するためのものである。例えば、比較演算は、マップ演算が生成した結果レコード（キーとバリューのペアからなる）のキーの値の大小を比較するものである。比較演算はアプリケーションによって規定されなくてもよいし、マッププロセスもしくはリデュースプロセスのどちらか一方のために規定されてもよいし、また、両方のプロセスに同じ比較演算が規定されてもよいし、両方のプロセスに異なる比較演算が規定されてもよい。集約演算は、マッププロセスにおいて分割演算の結果レコードを中間データセットに書き込む際に、結果レコードを一旦、集約するためのものである。例えば、集約演算は、マップ演算が生成した結果レコード（キーとバリューのペアからなる）のキーに従って集約することにより結果レコードを生成するものである。集約演算はアプリケーションによって規定されなくてもよい。マッププロセスに対して、比較演算と集約演算が規定されてもよい。この場合、例えば、比較演算に従って整列された結果レコードに対して集約演算が行われてもよい。
　マッププロセスでは、複数の異なるデータセットからのレコードを並行して、もしくは逐次的に入力してもよい。例えば、上記の例では、入力データセット＃１から参照された入力データセット＃２からレコードを読み込み、マップ演算への入力としていたが、更に、別に入力データセット＃１－２から参照された入力データセット＃２－２からレコードを読み込み、マップ演算への入力としてもよい。この際、書式＃１、書式＃２、参照方式、条件は、同じものを用いてもよいし、別のものを用いてもよい。
　図１Ａでは、文献 Jeffrey Dean, Sanjay Ghemawat: MapReduce: Simplified Data Processing on Large Clusters. Proceedings of OSDI 2004, pp. 137-15 (2004) に示されるマッププロセスとリデュースプロセスから構成されるジョブ実行モデルを示していたが、他のジョブ実行モデルであってもよい。例えば、図１Ａでは、入力データセットを２段とした例を示すが、入力データセットは、２段以上であってもよい。また、図１Ａでは、マッププロセスとリデュースプロセスの２つのステージのプロセスで構成されたジョブ実行モデルを示していたが、３以上のステージのプロセスで構成されたジョブ実行モデルであってもよい。また、図１Ａでは、先頭のマッププロセスのみがストレージに格納された入力データセットからレコードを読み込むようにしていたが、例えば、それ以外のステージのプロセスがストレージの入力データセットからレコードを読み込むようにしてもよい。また、図１Ａでは、マッププロセスはその結果レコードを一旦中間データセットに書き込み、リデュースプロセスが当該中間データセットから結果レコードを読み込むことにより、マッププロセスからリデュースプロセスへとレコードの受け渡しを行うようにしていたが、マッププロセスを実行する際に、マップ演算の結果レコードを中間データセットに格納せずにネットワークを通じて送信し、リデュースプロセスを実行する際に、当該マップ演算の結果レコードをネットワークを通じて受信してもよい。マッププロセスとリデュースプロセスを並行して実行してもよい。また、リデュースプロセスを実行する際に、リデュース演算の結果レコードを出力データセットに書き込まずに、コンソールやプリンタに出力してもよいし、ネットワークを経由して他の計算機等に送信してもよい。マッププロセスはその結果レコードをネットワークを通じてリデュースプロセスに送信し、リデュースプロセスはネットワークを通じて結果レコードを受信してもよい。このように拡張されたジョブ実行モデルの一例は、文献 Michael Isard, Mihai Budiu, Yuan Yu, Andrew Birrell, Dennis Fetterly: Dryad: distributed data-parallel programs from sequential building blocks. Proceedings of EuroSys 2007, pp. 59-72 (2007) や文献 Vinayak R. Borkar, Michael J. Carey, Raman Grover, Nicola Onose, Rares Vernica: Hyracks: A flexible and extensible foundation for data-intensive computing. Proceedings of ICDE 2011, pp. 1151-1162 (2011) に開示されている。
　次に、実施例２に係るジョブ実行モデルを説明する。
　図１Ｂは、実施例２に係るジョブ実行モデルを示す。なお、図１Ｂは図１Ａと同様に表記されている。実施例２に係るジョブ実行モデルは実施例１に係るジョブ実行モデルを拡張したものであり、実施例１に関して説明した部分は、改めて説明せずとも、実施例２に適用される。
　このジョブ実行モデルによれば、ジョブはネットワークで接続された複数の計算ノードによって実行される。図１Ｂに例示するジョブは、ステージ＃１プロセスを実行することにより、入力データセット＃１、入力データセット＃２、入力データセット＃３、及び入力データセット＃４からレコードを読み込み、これを入力として、ステージ演算＃１を実行し、その実行結果レコードをステージ＃２プロセスに送信する。また、ステージ＃２プロセスを実行することにより、実行結果レコードを受信し、これを入力としてステージ演算＃２を実行し、その実行結果レコードをステージ＃３プロセスに送信する。更に、ステージ＃３プロセスを実行することにより、実行結果レコードを受信し、これを入力としてステージ演算＃３を実行し、その実行結果レコードをステージ＃４に送信する。加えて、ステージ＃４プロセスを実行することにより、実行結果レコードを受信するとともに、入力データセット＃５及び入力データセット＃６からレコードを読み込み、これらを入力レコードとしてステージ＃４演算を実行し、実行結果レコードを出力データセット＃１に格納する。実施例１と同様に、異なるステージのプロセスの間では、中間データセットを経てデータを受け渡してもよいし、ネットワークによってデータを送受信してもよい。また、異なるステージのプロセスは並行して実行してもよい。
　入力データセット＃１は、入力データセット＃２の索引であってもよい。例えば、入力データセット＃１の各レコードは、入力データセット＃２のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット＃２の１以上のレコードを示す参照を含んでよい。同様に、入力データセット＃３は、入力データセット＃４の索引であってよい。入力データセット＃３の各レコードは、入力データセット＃４のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット＃４の１以上のレコードを示す参照を含んでよい。また、入力データセット＃２のレコードの所定の項目は、入力データセット＃３の１以上のレコードを示す参照を含んでよい。即ち、入力データセット＃２のあるレコードに対して入力データセット＃３の１以上のレコードを対応させることが可能であってよい。実施例１と同様に、参照は参照先の入力データセットのレコードを記憶装置上で特定可能な格納位置を含んでもよいし、参照先の入力データセットを構成するデータ構造においてレコードを特定可能な唯一性のある索引鍵を含んでもよい。また、参照元の入力データセットは参照先の入力データセットの全てのレコードに対応するレコードを有していてもよいし、参照先の入力データセットの一部のレコードに対応するレコードのみを有していてもよい。
　入力データセット＃５は、入力データセット＃６の索引であってもよい。入力データセット＃５の各レコードは、入力データセット＃６のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット＃６の１以上のレコードを示す参照を含んでよい。
　ステージ＃１プロセスにおいては、ステージ演算＃１、分割演算＃１、書式＃１、書式＃２、書式＃３、書式＃４、参照方式＃１、参照方式＃２、参照方式＃３、条件＃１、ビルド方式＃１等に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算＃１、分割演算＃１、書式＃１、書式＃２、書式＃３、書式＃４、参照方式＃１、参照方式＃２、参照方式＃３、条件＃１、ビルド方式＃１等は、計算ノードに格納されているアプリケーションに含まれたプログラムコードである。ステージ演算＃１は、読み込んだレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。分割演算＃１は、演算結果を受け渡す後続のステージのプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算は入力に対するハッシュ関数などを含んでよい。書式＃１、書式＃２、書式＃３ならびに書式＃４は、それぞれ入力データセット＃１、入力データセット＃２、入力データセット＃３ならびに入力データセット＃４のレコードを解釈するための書式を規定するプログラムコードである。参照方式＃１、参照方式＃２ならびに参照方式＃３は、それぞれ入力データセット＃１、入力データセット＃２ならびに入力データセット＃３のレコードの参照に従い、入力データセット＃２、入力データセット＃３ならびに入力データセット＃４のレコードを取得する方式を規定するプログラムコードである。条件＃１は、ステージ演算＃１の対象とするべきレコードの条件を規定する手続きである。条件＃１は、その全部もしくは一部が、入力データセット＃１、入力データセット＃２、入力データセット＃３ならびに入力データセット＃４のいずれかからレコードを読み込む際に実行されてもよいし、その全部もしくは一部が、読み込んだレコードをマップ演算に入力する際に実行されてもよい。ビルド方式＃１は、入力データセット＃１、入力データセット＃２、入力データセット＃３ならびに入力データセット＃４から読み込んだレコードからステージ演算＃１に入力するレコードを生成する方式を規定するプログラムコードである。
　具体的に説明すると、計算ノードのプロセッサは、ステージ＃１プロセスにおいてタスクを実行し、当該タスクにおいて、入力データセット＃１からレコードを読み込み、書式＃１を用いてレコードを解釈し、条件＃１に基づいて、当該レコードが要件を満足するかどうかを判定し、要件を満足するレコードから入力データセット＃２への参照を取得する。
　次いで、プロセッサは、入力データセット＃１のレコードが含む参照に基づいて入力データセット＃２からレコードを読み込むためにスレッドを生成する。入力データセット＃１のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット＃１のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式＃１に基づいて、参照によって入力データセット＃２からレコードを読み込む。プロセッサは、書式＃２を用いて読み込んだレコードを解釈し、条件＃１に基づいて、当該レコードが要件を満足するかどうかを判定する。更にプロセッサは、要件を満足するレコードから入力データセット＃３への参照を取得する。ここで、プロセッサは、参照を用いて入力データセット＃３を参照して処理を行うスレッドを生成する。複数の参照がある場合には、プロセッサは、複数のスレッドを生成する。これらスレッドは、プロセッサにより並行して実行される。
　更に次いで、プロセッサは、入力データセット＃２のレコードが含む参照に基づいて入力データセット＃３からレコードを読み込むためにスレッドを生成する。入力データセット＃２のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット＃２のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式＃２に基づいて、参照によって入力データセット＃３からレコードを読み込む。プロセッサは、書式＃３を用いて、読み込んだレコードを解釈し、条件＃１に基づいて、当該レコードが要件を満足するかどうかを判定する。更にプロセッサは、要件を満足するレコードから入力データセット＃４への参照を取得する。
　更に次いで、プロセッサは、入力データセット＃３のレコードが含む参照に基づいて入力データセット＃４からレコードを読み込むためにスレッドを生成する。入力データセット＃３のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット＃３のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式＃３に基づいて、参照によって入力データセット＃４からレコードを読み込む。プロセッサは、書式＃４を用いて読み込んだレコードを解釈し、条件＃１に基づいて、当該レコードが要件を満足するかどうかを判定する。プロセッサは、要件を満足するレコードに対して、ビルド方式＃１に基づいて、ステージ演算＃１に入力するレコードを生成し、当該レコードを入力としてステージ演算＃１を実行する。更に、１以上のステージ演算＃１の実行結果レコードに対して分割演算＃１を行うことにより、実行結果レコードを送るべき後続のステージ＃２のプロセスを決定する。プロセッサは、決定した後続のステージのプロセスが実行結果レコードを受け取れるように出力する。具体的には、実行結果を中間データセットに格納するか、ネットワークで後続のステージのプロセスに送る。
　ステージ＃２プロセスにおいては、ステージ演算＃２、分割演算＃２に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算＃２、分割演算＃２は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。例えば、ステージ演算＃２は、中間データセットから取得したレコード又はネットワークで送られたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。分割演算＃２は、実行結果を受け渡す後続のステージ＃３のプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算＃２は入力に対するハッシュ関数などを含んでよい。
　具体的に説明すると、計算ノードのプロセッサは、ステージ＃２プロセスにおいてタスクを実行し、当該タスクにおいて、ステージ＃１プロセスから受け渡されたレコードを取得し、ステージ演算＃２を実行し、更に分割演算＃２を行うことにより、ステージ演算＃２の実行結果レコードを送るべき後続のステージ＃３のプロセスを決定する。プロセッサは、決定した後続のステージのプロセスがステージ演算＃２の実行結果レコードを受け取れるように出力する。具体的には、実行結果を中間データセットに格納するか、ネットワークで後続のステージのプロセスに送る。
　ステージ＃３プロセスにおいては、ステージ演算＃３、分割演算＃３に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算＃３、分割演算＃３は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。例えば、ステージ演算＃３は、中間データセットから取得したレコード又はネットワークで送られたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。分割演算＃３は、実行結果を受け渡す後続のステージ＃４のプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算＃３は入力に対するハッシュ関数などを含んでよい。
　具体的に説明すると、計算ノードのプロセッサは、ステージ＃３プロセスにおいてタスクを実行し、当該タスクにおいて、ステージ＃２プロセスから受け渡されたレコードを取得し、ステージ演算＃３を実行し、更に分割演算＃３を行うことにより、ステージ演算＃３の実行結果レコードを送るべき後続のステージ＃４のプロセスを決定する。プロセッサは、決定した後続のステージのプロセスがステージ演算＃３の実行結果レコードを受け取れるように出力する。具体的には、実行結果を中間データセットに格納するか、ネットワークで後続のステージのプロセスに送る。
　ステージ＃４プロセスにおいては、ステージ演算＃４、書式＃５、書式＃６、参照方式＃４等に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算＃３、分割演算＃３、書式＃５、書式＃６、参照方式＃４は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。例えば、ステージ演算＃４は、中間データセットから取得したレコード又はネットワークで送られたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。書式＃５ならびに書式＃６は、それぞれ入力データセット＃５ならびに入力データセット＃６のレコードを解釈するための書式を規定するプログラムコードである。参照方式＃４は、入力データセット＃５のレコードの参照に従い、入力データセット＃６のレコードを取得する方式を規定するプログラムコードである。
　更に、具体的に説明すると、計算ノードのプロセッサは、ステージ＃４プロセスにおいてタスクを実行し、当該タスクにおいて、入力データセット＃５からレコードを読み込み、書式＃５を用いてレコードを解釈し、レコードから入力データセット＃６への参照を取得する。
　次いで、プロセッサは、入力データセット＃５のレコードが含む参照に基づいて入力データセット＃６からレコードを読み込むためにスレッドを生成する。入力データセット＃５のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット＃５のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式＃４に基づいて、参照によって入力データセット＃６からレコードを読み込む。プロセッサは、書式＃６を用いて読み込んだレコードを解釈する。また、ステージ演算＃３の実行結果であるレコードを取得する。これらのレコードを入力として、ステージ演算＃４を実行し、その実行結果レコードを出力データセット＃１に格納する。
　実施例１と同様に、ステージ演算＃１、分割演算＃１、書式＃１、書式＃２、書式＃３、書式＃４、参照方式＃１、参照方式＃２、参照方式＃３、条件＃１、ビルド方式＃１、ステージ演算＃２、分割演算＃２、ステージ演算＃３、分割演算＃３、ステージ演算＃４、書式＃５、書式＃６、参照方式＃４はその全てがアプリケーションで規定されている必要はなく、その一部が規定されていればよい。規定されていないものについては、所定の取り扱いを行ってよい。
　実施例１と同様に、各ステージのプロセスでは、更に比較演算、集約演算に従い、各計算ノードのプロセッサによりデータ処理が実行されてもよい。
　各ステージのプロセスでは、複数の異なるデータセットからのレコードを並行して、もしくは逐次的に入力してもよい。
　以上、実施例１及び２に係るジョブ実行モデルを説明した。ジョブ実行モデルは、それらに限定されない。
　実施例１及び２に係るジョブ実行モデルについての共通点は、例えば以下の通りである。
　Hadoopをはじめとする並列データ処理システムでは、一般に、記憶空間におけるデータ群は構造化されない。これに対して、実施例１および実施例２によれば、ストレージ（例えば、ファイルシステム）において、複数の第１のレコードで構成される第１のデータセット（例えば、入力データセット＃１）は、複数の第２のレコードで構成される第２のデータセット（例えば、入力データセット＃２）に対して関連付けられる。具体的には、例えば、第１のデータセットは、第２のデータセットのうちにデータ処理に要する第２のレコードを特定するための索引である。即ち、第１のデータセットは構造化されているが、第２のデータセットは構造化されていなくてもよい。第１のデータセットが構造化されていることにより、それに関連付けられた第２のデータセットは、仮にそれが構造化されていない場合であっても、第２のデータセットのうちにデータ処理に要する第２のレコードを特定してアクセスすることが可能となる。また、別の例を挙げるとすると、第１のデータセットと第２のデータセットはそれぞれのレコードを結合することできる関係である。即ち、第１のデータセットは構造化されておらず、第２のデータセットが構造化されていてもよい。第２のデータセットが構造化されていることにより、それに関連付けられた第１のデータセットのレコードに対応する第２のレコードを選択的に抽出することが可能となる。
　この際、実施例１および実施例２によれば、第１のデータセットの書式に関する情報（例えば書式＃１）や、第２のデータセットの書式に関する情報（例えば書式＃２）や、第１のレコードに基づいて第２のレコードを参照する方式に関する情報（例えば参照方式）をはじめとする情報がアプリケーションにより用意される。当該情報は、例えばプログラムコードである。当該情報は、個々のアプリケーションとは独立して別のプログラム（例えば後述するシステムモジュール等）が有してもよい。しかしながら、アプリケーションが個々にこれを用意することができることにも利点が認められる。例えば、データベース管理システム（ＤＢＭＳ；Database Management System）は、ストレージ空間におけるデータ群（テーブル）をリレーショナルモデルに基づき管理する。書式や参照方式等のカタログ情報は、アプリケーションとは独立に管理される。この場合、例えば、レコードのカラムの型は既にＤＢＭＳが用意している型（例えば、整数や文字列等）から選択することとなるが、アプリケーションによってはＤＢＭＳが既に備えている型以外の型を以ってカラムを解釈することが望ましい場合がある。アプリケーションが個々に書式や参照方式等の情報を用意することができることは、データ処理システムとしての柔軟性の観点から利点が認められる場合がある。また、ＤＢＭＳにおいては、一般に、データ集合（テーブル）における全てのレコードは、与えられたカタログ情報に厳密に従っていることを要請される。しかしながら、あるデータ集合に置いて特定の日時以降から記録されるレコードにカラムを追加するような場合にも、原則として、データ集合（テーブル）の全てのレコードにカラムを追加する必要がある。即ち、当該カラムを要しない特定の日付以前のレコードについても、（例えば空の）カラムを追加する必要がある。通常、このような操作には、データ集合（テーブル）を再構成や再編成する処理を要し、データ集合（テーブル）が大規模になるとその処理に係る時間は無視できない。他方で、アプリケーションが書式や参照方式等の情報を用意することができるとすると、アプリケーションによって特定の日付以前のレコードと特定の日付以降のレコードで異なる書式や参照方式等の情報を用意することができる。即ち、データ集合自体を変更することなく、アプリケーションを変更することによって、レコード書式の変更に柔軟にデータ処理を対応させることが可能となり、利点が認められる場合がある。
　また、実施例１および実施例２によれば、アプリケーションの規定したデータ処理のジョブ情報に基づき、アプリケーションとは別のプログラム（例えばシステムモジュール）が第１のデータセットから第１のレコードを読み込んで、当該レコードを当該ジョブ情報に基づき解釈し、それに基づきスレッドを生成して実行し、各スレッドにおいて更に第２のデータセットから第２のレコードを読み込み、読み込んだレコードに対してジョブ情報に規定された演算を実行することが可能となる。計算ノードはアプリケーションの規定したジョブ情報に従って、データ処理に係るデータ読み込みを並行して実行することができるようになる。これにより、データ読み込みのスループットが向上し、故に、データ処理に係る時間が短縮されることが期待される。
　以下、実施例１及び２を詳細に説明する。実施例２は実施例１を拡張したものであり、実施例１に関して説明した部分は、改めて説明せずとも、実施例２に適用される。
　図２Ａは、実施例１に係る計算ノードの構成を示す。図２Ａは、図１Ａに示すジョブ実行モデルに従いデータ処理を行う計算ノードの構成を示す。
　計算ノード１００は、パーソナルコンピュータ、ワークステーション、サーバ又はメインフレームなどの計算機であってよい。また、計算ノード１００は、計算機に装着して用いられる画像処理装置（ＧＰＵ；Graphical Processing Unit）などを具備する補助演算機器（例えば、画像処理装置（ＧＰＵ）カード）であってもよいし、計算機や補助演算機器において仮想化ソフトウェアや仮想化ハードウェア等によって構成された仮想的な計算機であってもよい。
　計算ノード１００は、通信インタフェースと、記憶装置と、それらに接続された演算装置とを有する。通信インタフェースとしては、例えば、ＮＩＣ（Network　interface　card）１０２と、ＨＢＡ（host　bus　adapter）１０３とがある。記憶装置としては、例えば、ストレージ１０４と、メモリ１０５とがある。演算装置は、例えばプロセッサ（ＣＰＵ；Central Processing Unit）１０１である。制御装置は、プロセッサ以外に、専用の処理（例えば暗号化又は復号化）を行うハードウェア回路を含んでもよい。プロセッサ１０１、ＮＩＣ１０２、ＨＢＡ１０３、及びメモリ１０５は、内部バス１０６を介して接続されている。ストレージ１０４は、ＨＢＡ１０３に接続されている。
　プロセッサ１０１は、コンピュータプログラムを実行する。ＮＩＣ１０２は、ネットワーク２００と計算ノード１００とを接続する。ネットワーク２００を介した通信のプロトコルとしては、例えば、ＴＣＰ／ＩＰ（Transmission　Control　Protocol／Internet　Protocol）が採用されてよい。ＨＢＡ１０３は、ストレージ１０４への入出力を仲介する。
　ストレージ１０４は、１つ以上の不揮発性の記憶媒体を含む。不揮発性の記憶媒体は、例えば、磁気ディスク或いはフラッシュメモリである。ストレージ１０４は、複数の不揮発性の記憶媒体を備え、更に当該不揮発性の記憶媒体から記憶空間を構成するＲＡＩＤ（Redundant　ARRAY　of　Independent　Disks）コントローラを備えてもよい。
　メモリ１０５は、例えば、揮発性の記憶媒体（例えばＤＲＡＭ（Dynamic　Random　Access　Memory））であり、ＣＰＵ１０１によって実行されるプログラムと、プログラムが使用するデータ等を記憶する。
　メモリ１０５は、アプリケーションプログラム（以下、アプリケーション）１１０、システムモジュール１２０、プロセスマネージャ１３１、タスクマネージャ１３２、スレッドマネージャ１３３、データ読み書き器１４０、ネットワークマネージャ１５０、ストレージマネージャ１６０、及びＯＳ（Operating　System）１７０を格納する。なお、システムモジュール１２０、プロセスマネージャ１３１、タスクマネージャ１３２、スレッドマネージャ１３３、データ読み書き器１４０、ネットワークマネージャ１５０、ストレージマネージャ１６０（以下、個々のプログラムモジュールを総じてモジュール群と称する）はアプリケーション１１０と静的もしくは動的にリンクして実行されるライブライモジュールであってもよく、この場合、アプリケーション１１０からの指示もしくはモジュール群におけるプログラムモジュール間の相互の指示はモジュール群が開示する呼び出しインタフェースによる。また、モジュール群はアプリケーション１１０とは別個に動作するプログラムであってもよく、この場合、アプリケーション１１０からの指示はプロセス間通信や共有メモリ等の手段による。
　アプリケーション１１０は、ストレージ１０４に格納された入力データセットを読み込んで所定の処理を実行し、出力データセットを書き込むジョブを規定するプログラムであり、計算ノードはアプリケーション１１０を実行することによって当該ジョブを実行する。アプリケーション１１０は、当該ジョブを規定する情報（以下、ジョブ情報とする）として、例えば、マップ演算１１０ａと、リデュース演算１１０ｂと、分割演算１１０ｃと、書式１１０ｅ（書式＃１）と、書式１１０ｆ（書式＃２）と、条件１１０ｇとを含む。
　マップ演算１１０ａは、読み込んだレコードに対して適用される処理を規定するプログラムコードであり、例えば、読み込んだレコードからキーとバリューのペアからなる結果レコードを生成するものである。分割演算１１０ｃは、マップ演算を実行したのち、その実行結果を受け渡すリデュースプロセスを決定する際に実行されるプログラムコードであり、例えば、分割演算はマップ演算の結果レコードが含むキーに対するハッシュ演算などを含んでよい。書式１１０ｅ（書式＃１）は、入力データセット＃１のレコードを解釈するための書式を規定するプログラムコードである。書式１１０ｆ（書式＃２）は、入力データセット＃２のレコードを解釈するための書式を規定するプログラムコードである。参照方式１１０ｈは、入力データセット＃１のレコードの参照に従い、入力データセット＃２のレコードを取得する方式を規定するプログラムコードである。条件１１０ｇは、入力データセット＃１及び／又は入力データセット＃２に格納されたレコードのうちマップ演算の対象とするべきレコードの要件を規定するプログラムコードである。なお、アプリケーション１１０は、上述のプログラムコードを全て規定しなくてもよい。規定されていないものについては、所定の取り扱いを行ってよい。例えば、リデュース演算を備えない場合は、リデュースプロセスを実行されず、マッププロセスにおけるマップ演算の実行結果レコードがそのまま出力データセットに格納される。更に、アプリケーション１１０は比較演算（図示せず）、集約演算（図示せず）を規定してもよい。
　システムモジュール１２０は、アプリケーション１１０とは独立しているもののアプリケーション１１０と連携して動作するプログラムモジュールであり、アプリケーション１１０からのジョブを実行する指示を受けて、アプリケーション１１０に規定されたジョブ情報に従いジョブを実行する。システムモジュール１２０は、アプリケーション１１０からジョブ実行の指示を受け付けるインタフェース部（図示せず）と、マップ関数１２１と、リデュース関数１２２と、スーパバイザ関数１２３とを含むエグゼキューション部とを有する。マップ関数１２１は、マッププロセスにおいて実行されるプログラムコード（関数）である。リデュース関数１２２は、リデュースプロセスにおいて実行されるプログラムコード（関数）である。スーパバイザ関数１２３は、スーパバイザプロセス（統括スーパバイザプロセスを含む）において実行されるプログラムコードである。システムモジュール１２０は、インタフェース部においてアプリケーション１１０からのジョブ実行の指示を受け付け、エグゼキューション部においてジョブを実行するのに要するプロセスを生成し、プロセスにおいて各関数を実行し、各関数を実行することによって、更にタスクとスレッドを生成して実行する。
　システムモジュール１２０の詳細を述べる。各計算ノードのＣＰＵ１０１は、システムモジュール１２０によってスーパバイザプロセスを生成し、当該スーパバイザプロセスにおいてスーパバイザ関数１２３を実行する。上述のスーパバイザプロセスの生成は、事前に例えば計算ノードを起動することにより自動的に行われてもよいし、ジョブの実行を開始してから必要に応じて行われてもよい。ジョブを実行する複数の計算ノード１００のスーパバイザプロセスのいずれかのスーパバイザプロセスは、複数の計算ノード１００を統括する処理も行う。なお、複数の計算ノード１００を統括するスーパバイザプロセスを統括スーパバイザプロセスという。なお、統括スーパバイザプロセスは、固定的にいずれかの計算ノード１００のスーパバイザプロセスとしてもよく、複数の計算ノード１００から選択した計算ノード１００のスーパバイザプロセスとしてもよい。なお、計算ノード１００以外の計算機に、統括スーパバイザプロセスを備えるようにしてもよい。
　統括スーパバイザプロセスは、ジョブの実行に参加する全計算ノード１００にアプリケーション１１０のコードを配布して、各スーパバイザプロセスに対してプロセスの割当てを行う。各ノードのスーパバイザプロセスは、統括スーパバイザプロセスの指示に基づいて、プロセスを生成する。統括スーパバイザプロセスは、ジョブ実行に参加する全計算ノードのスーパバイザプロセスの状態を把握する処理を行う。また、各スーパバイザプロセスは、自身の計算ノードにおけるジョブ実行に関わるプロセスの実行状態を把握する処理を行う。
　プロセスマネージャ１３１は、システムモジュールからの指示に基づき、プロセスを実行するのに要するメモリ資源を管理する。即ち、プロセスの生成、削除ならびに実行状態等を管理する。タスクマネージャ１３２は、システムモジュールからの指示に基づき、タスクを実行するのに要するメモリ資源を管理する。即ち、タスクの生成、削除ならびに実行状態等を管理する。スレッドマネージャ１３３は、システムモジュールからの指示に基づき、スレッドを実行するのに要するメモリ資源を管理する。即ち、スレッドの生成、削除ならびに実行状態等を管理する。
　データ読み書き器１４０は、システムモジュール１２０からの指示に基づき、ストレージへのデータの読み書きを行う。データ読み書き器１４０は例えばファイルシステムであってよい。例えば、データ読み書き器１４０は、指示されたデータ読み書きを行うのに自身の計算ノード１００のストレージ１０４に対するデータ読み書きを要する場合には、ストレージマネージャ１６０により、ストレージ１０４に対してデータ読み書きを実行させ、ネットワーク２００を介して接続された他の計算ノード１００のストレージ１０４に対するデータ読み書きを要する場合には、ネットワークマネージャ１５０により、ネットワーク２００を介して接続された他の計算ノード１００のストレージ１０４に対してデータ読み書きを実行させる。この際、データ読み書き器１４０は、メモリ１０５のメモリ資源を用いて、読み書きするデータを一時的にキャッシュさせてもよい。
　ネットワークマネージャ１５０は、ネットワークを介して接続された装置（例えば、他の計算ノード１００等）とのデータ通信を制御する。ストレージマネージャ１６０は、自身の計算ノード１００のストレージ１０４との入出力を制御する。ＯＳ１７０は、ＮＩＣ１０２、ＨＢＡ１０３、ストレージ１０４等の装置を管理するほか、計算ノード１１０の全体を管理する。
　本明細書においては、プログラムやその一部の名称（例えば、アプリケーション、システムモジュール、プロセス、タスク、スレッド）を主語として発明の実施例ならび変形例を説明する場合がある。この場合においては、プログラムやその一部は、計算ノード１００が具備する演算装置（例えばプロセッサ１０１）によって実行されることによって、定められた処理を、適宜に記憶装置（例えばメモリ１０５やストレージ１０４）及び／又は通信インタフェース（例えばＮＩＣ１０２やＨＢＡ１０３）を用いて行うものであるため、発明の実施例ならび変形例を説明する際の主語が演算装置、プロセッサ１０１もしくは計算ノード１００であるとして解釈してもよい。また、プログラムやその一部は、ハードウェアで行われても良く、その場合には、発明の実施例ならび変形例を説明する際の主語がプロセッサ１０１に代えて又は加えてそのハードウェアであるとして解釈してもよい。システムモジュール１２０、プロセスマネージャ１３１、タスクマネージャ１３２、スレッドマネージャ１３３、データ読み書き器１４０、ネットワークマネージャ１５０、ストレージマネージャ１６０等のようなコンピュータプログラムは、プログラムソースから計算ノード１００にインストールされてよい。プログラムソースは、例えば、計算ノード１００が読み取り可能な記憶メディアであってもよいし、計算ノード１００に通信可能に接続されている計算機であってもよい。
　計算ノード１００は、性能や可用性の観点から、ＣＰＵ１０１、ＮＩＣ１０２、ＨＢＡ１０３の少なくとも１つの要素を複数備えていてもよい。また、計算ノード１００は、入力デバイス（例えば、キーボード及びポインティングデバイス）（図示しない）と表示デバイス（例えば液晶ディスプレイ）（図示しない）とを有してよい。入力デバイスと表示デバイスは一体になっていてもよい。
　図２Ｂは、実施例２に係る計算ノードの構成を示す。図２Ｂは、図１Ｂに示すジョブ実行モデルに従いデータ処理を行う計算ノードの構成を示す。
　アプリケーション１１０は、ジョブ情報として、例えば、１以上のステージ演算１１０ｊと、１以上の分割演算１１０ｋと、１以上の書式１１０ｍと、1以上の条件１１０ｎと、1以上の参照方式１１０ｏと、1以上のビルド方式１１０ｐとを含む。
　ステージ演算１１０ｊは、ジョブ実行モデルにおける各ステージのプロセスにおいて入力されたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。図１Ｂのジョブ実行モデルの場合には、ステージ演算＃１～＃４の４つのステージ演算が含まれる。分割演算１１０ｋは、実行結果レコードを受け渡す後続のステージのプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算は入力に対するハッシュ演算などを含んでよい。書式１１０ｍは、各入力データセットのレコードを解釈するための書式を規定するプログラムコードである。図１Ｂに示すジョブ実行モデルを実行するアプリケーション１１０には、入力データセット＃１～＃６までのそれぞれに対応する書式１１０ｍが格納されている。条件１１０ｎは、ステージ演算の対象とするべきレコードの要件を規定するプログラムコードである。参照方式１１０ｏは、ある入力データセットのレコードの参照に従い、参照先の入力データセットからレコードを取得する方式を規定するプログラムコードである。ビルド方式１１０ｐは、実行結果のレコードの作成方法を示す情報である。なお、アプリケーション１１０は、上述のプログラムコードを全て規定しなくてもよい。規定されていないものについては、所定の取り扱いを行ってよい。更に、アプリケーション１１０は比較演算（図示せず）、集約演算（図示せず）を規定してもよい。
　システムモジュール１２０は、一般化ステージ関数１２４と、スーパバイザ関数１２２とを含む。一般化ステージ関数１２４は、図１Ｂに示す各プロセスにおいて実行されるプログラムコード（関数）である。
　図３Ａは、実施例に係る計算機システムの第１の構成例を示す。図３Ｂは、実施例に係る計算機システムの第２の構成例を示す。
　計算機システムは、図３Ａに示すように、ＮＩＣ１０２を介してネットワーク２００（例えば、Ethernet（登録商標）によるローカルエリアネットワーク）によって接続された複数の計算ノード１００から構成されてもよい。また、計算機システムは、図３Ｂに示すように、ＮＩＣ１０２を介してネットワーク２００によって接続され、更に、ＨＢＡ１０３を介してネットワーク３００（例えば、FibreChannelによるストレージエリアネットワーク）によって１以上のストレージ４００と接続される複数の計算ノード１００から構成されてもよい。また、ストレージ４００は、ネットワーク３００ではなくネットワーク２００に接続され、共有ファイルアクセス用の通信プロトコル（ＮＦＳやＣＩＦＳ）によって入出力を行うものであってもよい。
　ストレージ４００は、１つ以上の不揮発性の記憶媒体を含む。不揮発性の記憶媒体は、例えば、磁気ディスク或いはフラッシュメモリである。ストレージ１０４は、複数の不揮発性の記憶媒体を備え、更に当該不揮発性の記憶媒体から記憶空間を構成するＲＡＩＤ（Redundant　ARRAY　of　Independent　Disks）コントローラを備えてもよい。ストレージ４００のストレージ資源の全部もしくは一部は、計算ノード１００が含むストレージ１０４と同様に扱ってよい。
　図４Ａは、実施例１に係るマップタスク実行処理の流れを示す。
　このマップタスク実行処理は、図１Ａに示すジョブ実行モデルにおけるマッププロセスにおいて実行されるマップタスクにおいて実行される処理を示す。
　計算ノード１００のプロセッサ１０１が、入力データセット＃１のレコードを読み込んで処理を実行するための１つのスレッドＳＬ１を実行することにより、ステップＳ１０～ステップＳ１５の処理を実行する。この処理は、プロセッサ１０１が、主に、マップ関数１２１を実行することにより実現される。
　Ｓ１０で、プロセッサ１０１は、入力データセット＃１から１つのレコードを取得する。ここで、入力データセット＃１は、自身の計算ノード１００のストレージ１０４に格納されている場合もあれば、他の計算ノード１００のストレージ１０４に格納されている場合もある。なお、入力データセット＃１からレコードを取得するレコード取得処理については、後述する。
　Ｓ１１で、プロセッサ１０１は、書式１１０ｅ（書式＃１）に基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件１１０ｇに含まれる入力データセット＃１のレコードに対する条件を適用することにより、当該レコードが条件を満足するか否かを判定し、必要であれば、Ｓ１２に進む一方、必要でなければ、図示しないがＳ１５に進む。Ｓ１１では条件１１０ｇの一部が適用されてもよい。条件１１０ｇが規定されていない場合はそのままＳ１２に進んでもよい。
　Ｓ１２で、プロセッサ１０１は、取得したレコードに、入力データセット＃２への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ１３を行う一方、この判断の結果が否定的であれば、Ｓ１５を行う。
　Ｓ１３で、プロセッサ１０１は、取得したレコードの入力データセット＃２への１つの参照について、入力データセット＃２からレコードを取得して処理を行うためのスレッドＳＬ２を生成する。
　Ｓ１４で、プロセッサ１０１は、取得したレコードに、更に未処理の入力データセット＃２への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ１３を行う一方、この判断の結果が否定的であれば、Ｓ１５を行う。これにより、取得したレコードに、入力データセット＃２への参照が複数あれば、Ｓ１３によって、参照の数に応じたスレッドＳＬ２が生成されることとなる。なお、スレッドの生成に必要な資源が不足する場合には、スレッドＳＬ２の生成を一時的に保留してもよい。なお、この際、１つの参照の毎に１つのスレッドＳＬ２を生成してもよいし、複数（例えば所定数）の参照の毎に１つのスレッドＳＬ２を生成してもよい。
　Ｓ１５で、プロセッサ１０１は、入力データセット＃１に更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、Ｓ１０を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドＳＬ１を停止する。
　一方、Ｓ１３でスレッドＳＬ１により生成されたスレッドＳＬ２は、ＣＰＵ１０１によって実行される。プロセッサ１０１が、スレッドＳＬ２を実行することにより、ステップＳ１６～ステップＳ１９の処理を実行する。なお、本実施例では、プロセッサ１０１は、複数のスレッド（スレッドＳＬ１、スレッドＳＬ２等）を並行して実行することができる。計算ノード１００は複数のプロセッサ１０１を備えており、あるプロセッサ１０１で生成したスレッドＳＬ２が別のプロセッサ１０１で実行されてもよい。なお、並行実行可能なスレッドの数は、計算ノード１００の資源等によって制限がある。
　Ｓ１６で、プロセッサ１０１は、参照方法１１０ｈ及びスレッドＳＬ１で取得された参照を用いて、入力データセット＃２から１つのレコードを取得する。
　Ｓ１７で、プロセッサ１０１は、書式１１０ｆ（書式＃２）に基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件１１０ｇに含まれる入力データセット＃２のレコードに対する条件を適用することにより、当該レコードが必要であるか否かを判定し、必要であれば、Ｓ１８に進む一方、必要でなければ、図示しないがＳ１９に進む。Ｓ１７では条件１１０ｇの一部が適用されてもよい。条件１１０ｇが規定されていない場合はそのままＳ１８に進んでもよい。
　Ｓ１８で、プロセッサ１０１は、取得したレコードを、主記憶１０５の演算キュー１８０に格納する。
　Ｓ１９で、プロセッサ１０１は、入力データセット＃２の参照で示される範囲に更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、Ｓ１６を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドＳＬ２を終了させる。
　また、プロセッサ１０１は、Ｓ２０で、演算キュー１８０から１つのレコードを取得し、当該レコードに対して、マップ演算１１０ａを適用することにより、レコードに対して所定の処理を実行し、その実行結果を出力する。この際、プロセッサ１０１はＳ２０をＳＬ２とは別のスレッドにおいて実行してもよい。Ｓ２０を実行するスレッドは１つであってもよく、複数であってもよい。演算キュー１８０から一括して複数のレコードを取得してマップ演算１１０ａを適用してもよい。プロセッサ１０１はスレッドＳＬ２においてＳ１８を実行する代わりに、スレッドＳＬ２においてＳ１７を実行した後にＳ２０を実行してＳ１７の結果のレコードに対してマップ演算を適用してもよい。ここで、実行結果を出力する方法としては、例えば、実行結果を主記憶１０５に格納するようにしても良く、また、実行結果を後続の処理を実行するリデュースプロセスに渡すようにしてもよい。
　なお、図４Ａでは、入力データセット＃１からレコードを読み込み、その処理を行うスレッドＳＬ１と、入力データセット＃２からレコードを読み込み、その処理を行うスレッドＳＬ２を別に設けているが、スレッドＳＬ１がスレッドＳＬ２を生成せずにそのままＳ１６からＳ１９もしくはＳ２０までに相当する処理を行ってもよい。また、所定の数のスレッドＳＬ１を生成して、当該スレッドＳＬ１によって入力データセット＃１からレコードを読み込み、その処理を行ってもよい。更には、Ｓ１５で更にレコードがあると判断した際に、新たにＳＬ１を生成して、Ｓ１０からＳ１５に相当する処理を行ってもよい。
　図４Ｂは、実施例２に係るタスク実行処理の流れを示す。
　このタスク実行処理は、図１Ｂに示すジョブ実行モデルにおけるステージプロセスにおいて実行されるタスクにおいて実行される処理を示す。
　計算ノード１００のプロセッサ１０１が、入力データセット＃ｄ１のレコードを読み込んで処理を実行するための１つのスレッドＳＬｄ１を実行することにより、ステップＳ２１～ステップＳ２６の処理を実行する。ここで、図１Ｂのステージ＃１プロセスを実行するタスク実行処理においては、入力データセット＃ｄ１は、入力データセット＃１であり、入力データセット＃ｄ２は、入力データセット＃２である。また、図１Ｂのステージ＃４プロセスを実行するタスク実行処理においては、入力データセット＃ｄ１は、入力データセット＃５であり、入力データセット＃ｄ２は、入力データセット＃６である。
　Ｓ２１で、プロセッサ１０１は、入力データセット＃ｄ１から１つのレコードを取得する。ここで、入力データセット＃ｄ１は、自身の計算ノード１００のストレージ１０４に格納されている場合もあれば、他の計算ノード１００のストレージ１０４に格納されている場合もある。なお、入力データセット＃ｄ１からレコードを取得するレコード取得処理については、後述する。
　Ｓ２２で、プロセッサ１０１は、入力データセット＃ｄ１のレコードに対応する書式１１０ｍに基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件１１０ｎに含まれる入力データセット＃ｄ１のレコードに対する条件を適用することにより、当該レコードが条件を満足するか否かを判定し、必要であれば、Ｓ２３に進む一方、必要でなければ、図示しないがＳ２６に進む。Ｓ２２では条件１１０ｎの一部が適用されてもよい。条件１１０ｎが規定されていない場合はそのままＳ２３に進んでもよい。
　Ｓ２３で、プロセッサ１０１は、取得したレコードに、入力データセット＃ｄ２への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ２４を行う一方、この判断の結果が否定的であれば、Ｓ２６を行う。
　Ｓ２４で、プロセッサ１０１は、取得したレコードの入力データセット＃ｄ２への１つの参照について、入力データセット＃ｄ２からレコードを取得して処理を行うためのスレッドＳＬｄ２を生成する。
　Ｓ２５で、プロセッサ１０１は、取得したレコードに、更に入力データセット＃ｄ２への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ２４を行う一方、この判断の結果が否定的であれば、Ｓ２６を行う。これにより、取得したレコードに、入力データセット＃ｄ２への参照が複数あれば、Ｓ２４によって、参照の数に応じたスレッドＳＬｄ２が生成されることとなる。なお、スレッドの生成に必要な資源が不足する場合には、スレッドＳＬｄ２の生成を一時的に保留してもよい。なお、この際、１つの参照の毎に１つのスレッドＳＬｄ２を生成してもよいし、複数（例えば所定数）の参照の毎に１つのスレッドＳＬｄ２を生成してもよい。
　Ｓ２６で、プロセッサ１０１は、入力データセット＃ｄ１に更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、Ｓ２１を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドＳＬｄ１を終了させる。
　一方、Ｓ２４及び後述するＳ３１でスレッドＳＬｄｋ-1から生成されたスレッドＳＬｄｋは、プロセッサ１０１によって実行される。ここにｋは２以上の自然数を表し、例えばｋ＝２の場合にはＳＬｄｋ－１はＳＬｄ１を、ＳＬｄｋはＳＬｄ２を、ＳＬｄｋ＋１はＳＬｄ３を表すものとする。プロセッサ１０１が、スレッドＳＬｄｋを実行することにより、ステップＳ２７～ステップＳ３５の処理を実行する。なお、本実施例では、プロセッサ１０１は、複数のスレッド（スレッドＳＬｄ１、スレッドＳＬｄｋ等）を並行して実行することができる。計算ノード１００は複数のプロセッサ１０１を備えており、あるプロセッサ１０１で生成したスレッドが別のプロセッサ１０１で実行されてもよい。なお、並行実行可能なスレッドの数は、計算ノード１００の資源等によって制限がある。
　Ｓ２７で、プロセッサ１０１は、入力データセット＃ＳＬｄｋ-1のレコードの参照及びこの参照を用いて入力データセット＃ＳＬｄｋを参照するための参照方式１１０ｏに基づいて、入力データセット＃ＳＬｄｋのレコードを取得する。
　Ｓ２８で、プロセッサ１０１は、書式１１０ｆ（書式＃ｄｋ）に基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件１１０ｎに含まれる入力データセット＃ｄｋのレコードに対する条件を適用することにより、当該レコードが必要であるか否かを判定し、必要であれば、Ｓ２９に進む一方、必要でなければ、図示しないがＳ３５に進む。Ｓ２８では条件１１０ｎの一部が適用されてもよい。条件１１０ｎが規定されていない場合はそのままＳ２９に進んでもよい。
　Ｓ２９で、プロセッサ１０１は、更に入力データセット＃ｄｋ＋１へのアクセスを要するか否かを判断する。この判断の結果が肯定的であれば、Ｓ３０を行う一方、この判断の結果が否定的であれば、Ｓ３３に進む。例えば、図１Ｂのステージ＃１プロセスでは、入力レコード＃１からレコードを取得し、当該レコード中の参照に従い入力レコード＃２からレコードを取得し、更に当該レコード中の参照に従い入力レコード＃３からレコードを取得し、更に当該レコード中の参照に従い入力レコード＃４からレコードを取得する必要がある。よって、ｋ＝２で生成されたスレッドＳＬｄｋ（ＳＬｄ２）で実行されるＳ２９では、入力データセット＃３へのアクセスを更に要するため、この判断は肯定的であり、ｋ＝３で生成されたスレッドＳＬｄｋ（ＳＬｄ３）で実行されるＳ２９では、入力データセット＃４へのアクセスを更に要するため、この判断は肯定的であり、ｋ＝４で生成されたスレッドＳＬｄｋ（ＳＬｄ４）で実行されるＳ２９では、更なる入力データセットへのアクセスを要しないため、この判断は否定的となる。
　Ｓ３０で、プロセッサ１０１は、取得したレコードに、入力データセット＃ｄｋ＋１への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ３１を行う一方、この判断の結果が否定的であれば、Ｓ３５を行う。
　Ｓ３１で、プロセッサ１０１は、取得したレコードの入力データセット＃ｄｋ＋１への１つの参照について、入力データセット＃ｄｋ＋１からレコードを取得して処理を行うためのスレッドＳＬｄｋ＋１を生成する。
　Ｓ３２で、プロセッサ１０１は、取得したレコードに、更に入力データセット＃ｄｋ＋１への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ３１を行う一方、この判断の結果が否定的であれば、Ｓ３５を行う。これにより、取得したレコードに、入力データセット＃ｄｋ＋１への参照が複数あれば、Ｓ３１によって、参照の数に応じたスレッドＳＬｄｋ＋１が生成されることとなる。なお、スレッドの生成に必要な資源が不足する場合には、スレッドＳＬｄｋ＋１の生成を一時的に保留してもよい。なお、この際、１つの参照の毎に１つのスレッドＳＬｄｋ＋１を生成してもよいし、複数（例えば所定数）の参照の毎に１つのスレッドＳＬｄｋ＋１を生成してもよい。
　Ｓ３３で、プロセッサｓ１０１は、取得したレコードと、ビルド方式１１０ｐとに基づいて、所定の形式のレコードをビルド（生成）する。
　Ｓ３４で、プロセッサ１０１は、ビルドしたレコードに対して、ステージ演算１１０ｊを適用することにより、所定の処理を実行し、その実行結果を出力する。この際、プロセッサ１０１はスレッドＳＬｄｋにおいてＳ３３を実行した後にＳ３４を実行する代わりに、一旦、ビルドしたレコードを、主記憶１０５の演算キューに格納し、演算キューから１つのレコードを取得し、Ｓ３４を実行して当該レコードに対して、ステージ演算１１０ｊを適用することにより、レコードに対して所定の処理を実行し、その実行結果を出力してもよい。この際、プロセッサ１０１はＳ３４をＳＬｄｋとは別のスレッドにおいて実行してもよい。Ｓ３４を実行するスレッドは１つであってもよく、複数であってもよい。演算キューから一括して複数のレコードを取得してステージ演算１１０ｊを適用してもよい。
　Ｓ３５で、ＣＰＵ１０１は、入力データセット＃ｄｋの参照で示される範囲に更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、Ｓ２７を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドＳＬｄｋを中止する。
　なお、図４Ｂでは、入力データセット＃ｄｋ－１からレコードを読み込み、その処理を行うスレッドＳＬｄｋ－１と、入力データセット＃ｄｋからレコードを読み込み、その処理を行うスレッドＳＬｄｋを別に設けているが、スレッドＳＬｄｋ－１がスレッドＳＬｄｋを生成せずにそのままＳ２７からＳ３５までに相当する処理を行ってもよい。また、所定の数のスレッドＳＬｄ１を生成して、当該スレッドＳＬｄ１によって入力データセット＃１からレコードを読み込み、その処理を行ってもよい。更には、Ｓ２６もしくはＳ３５で更にレコードがあると判断した際に、新たにＳＬｄ１もしくはＳＬｄｋを生成して、Ｓ２１からＳ２６までに相当する処理もしくはＳ２７からＳ３５までに相当する処理を行ってもよい。
　図５Ａは、実施例１に係る入力データ及び入力データに対する処理を説明するための図である。
　入力データセット＃２は、「Ｄａｔｅ　＆　ｔｉｍｅ」、「Ｕｓｅｒ」、「Ｐｒｏｄｕｃｔ」、「Ｃｏｍｍｅｎｔ」を含む１以上のレコードを格納する。
　入力データセット＃１は、「Ｐｒｏｄｕｃｔ」と、「Ｒｅｆｅｒｅｎｃｅ」との項目を有する１以上のレコードが、年月ごとにまとめられて管理されている。即ち、入力データセット＃１は年月によって分割されている。例えば、スーパバイザプロセスは、このまとめられた部分（分割部分）の毎に、マップタスク等を割り当てることにより、並列データ処理を行う。この際、１つのマップタスクが複数の分割部分を担当してもよい。
　「Ｐｒｏｄｕｃｔ」には、入力データセット＃２におけるレコードの検索に使用する鍵となる項目（「Ｐｒｏｄｕｃｔ」）の値が格納される。「Ｒｅｆｅｒｅｎｃｅ」には、入力データセット＃２における当該レコードに対応する年月のレコードであって、当該レコード中の「Ｐｒｏｄｕｃｔ」の値と同一の値を格納するレコード（参照先レコード）の物理的な格納位置を示す参照が格納される。なお、入力データセット＃２に、複数の参照先レコードがある場合には、「Ｒｅｆｅｒｅｎｃｅ」には、複数の参照先レコードへの参照が格納される。なお、入力レコード＃２はある鍵によってレコードを検索可能な構造（例えば、Ｂ木）を有してもよく、当該鍵の値を「Ｒｅｆｅｒｅｎｃｅ」に格納する参照としてもよい。ある１つの参照に複数のレコードが対応することがあってもよい。
　入力データセット＃１のレコードの書式は、書式＃１に記述されている。
　また、入力データセット＃２のレコードの書式は、書式＃２に記述されている。また、入力データセット＃１の「Ｒｅｆｅｒｅｎｃｅ」を用いて、入力データセット＃２のレコードを参照する方法については、参照方式＃１に記述されている。
　図１Ａに示すジョブ実行モデルにおけるマッププロセスにおいては、プロセッサ１０１はマップ関数１２１を実行することにより、入力データセット＃１のレコードを読み込み、書式＃１により、レコードにおけるＰｒｏｄｕｃｔと、Ｒｅｆｅｒｅｎｃｅとを把握する。そして、マップ関数１２１は、Ｐｒｏｄｕｃｔの値に基づいて、所定の条件に合致するか否かを判断し、条件を満たすレコードのＲｅｆｅｒｅｎｃｅを特定する。そして、プロセッサ１０１はマップ関数１２１を実行することにより、参照方式＃１と、Ｒｅｆｅｒｅｎｃｅとに基づいて、入力データセット＃２のレコードを取得する。
　図５Ｂは、実施例１に係る書式及び参照を説明するための図である。
　書式＃１は、入力データセット＃１のレコードの書式に関する情報であり、本実施例では、入力データセット＃１のレコードを解釈する手続きが記述されている。書式＃１には、入力レコード（すなわち、入力データセット＃１のレコード）をバイナリ形式で解釈し、入力レコードの各カラムを、Ｔｅｘｔ型、Ｌｏｎｇ型、Ｉｎｔ型、Ｉｎｔ型として解釈すること、第1（０）のカラムを検索鍵とすることが記述されている。ここでは、カラムの型はＪａｖａ（登録商標）言語における型宣言を用いて標記しているが、本発明はこれに限定されるものではない。
　書式＃２は、入力データセット＃２のレコードの書式に関する情報であり、本実施例では、入力データセット＃２のレコードを解釈する手続きが記述されている。書式＃２には、入力レコード（すなわち、入力データセット＃２のレコード）をテキスト形式（文字列形式）で解釈することが記述されている。また、レコードにおけるカラム間の区切り文字は、カンマであり、第1（０）のカラムは、ＤａｔｅＴｉｍｅ型であり、「Ｄａｔｅ　＆　Ｔｉｍｅ」と名付け、第２（１）のカラムは、Ｔｅｘｔ型であり、「Ｕｓｅｒ」と名付け、第３（２）のカラムは、Ｔｅｘｔ型であり、「Ｐｒｏｄｕｃｔ」と名付け、第４（３）のカラムは、Ｔｅｘｔ型であり、「Ｃｏｍｍｅｎｔ」と名付け、これらに基づいて入力カラムを解釈することが記述されている。
　参照方式＃１は、入力データセット＃１の「Ｒｅｆｅｒｅｎｃｅ」を用いて、入力データセット＃２のレコードを参照する方法についての手続きであり、入力レコード（書式＃1に対応するレコード）の第２カラムをオフセットとし、第３カラムを長さとし、第４カラムをノードＩＤとして、物理参照により参照を行ってレコードを取得することが記述されている。ここで、物理参照は、指定されたノードＩＤが管理するストレージの指定されたオフセット（番地）を始点として、指定された長さ分のバイト列を、参照先のレコードとすることを意味する。
　図５Ｃは、スレッド生成及びスレッドの実行を説明する模式図の一例である。図５Ｃの上側には、単一のスレッドによりプロセスを実行する場合の例を示し、図５Ｃの下側には、実施例１に係るスレッドを動的に生成し、複数スレッドを並行して実行する例を示す。なお、図５Ｃの表記は、次のルールに従う。
（＊）横軸は、時刻を表す。
（＊）図中の横に長い角丸四角形は、１つのスレッドによる一連の処理を意味する。角丸四角形の左端はスレッドによる処理を開始する時刻を表し、角丸四角形の右端は当該スレッドによる処理を終了する時刻を表す。
（＊）角丸四角形の内部の値は、スレッドに対応した処理に伴って読み込まれるレコードを示す情報（例えば、レコードの先頭のカラムの値）を表す。
　ここで、図５Ｃは、図５Ａに示す２０１２年の２月（２０１２－Ｆｅｂ）に対応する入力データセット＃１の各レコードを取得して、処理を実行する例を示している。
　図５Ｃの上側の図に示すように、単一スレッドにより実行する場合においては、プロセッサは、入力データセット＃１の２０１２年の２月（２０１２－Ｆｅｂ）に対応する上から２番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＡＸ　Ｓｋｉｒｔ）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の値に基づいて、入力データセット＃２の７番目のレコード（「２０１２－Ｆｅｂ－０７　・・・」）を参照し、入力データセット＃１の上から３番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＢＢ　Ｂｏｏｋ」）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の値に基づいて、入力データセット＃２の８番目のレコード（「２０１２－Ｆｅｂ－０８　・・・」）を参照し、さらに、「Ｒｅｆｅｒｅｎｃｅ」の値に基づいて、入力データセット＃２の１０番目のレコード（「２０１２－Ｆｅｂ－０８　・・・」）を参照し、さらに、「Ｒｅｆｅｒｅｎｃｅ」の値に基づいて、入力データセット＃２の１１番目のレコード（「２０１２－Ｆｅｂ－０８　・・・」）を参照して処理を行っていく。即ち、ストレージからのレコードの読み込みとそれに対する処理は、逐次的に行われていく。
　一方、本実施例においては、図５Ｃの下側の図に示すように、マップ関数１２１は、先ずスレッド５ａにより、入力データセット＃１の２０１２年の２月（２０１２－Ｆｅｂ）に対応する上から２番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＡＸ　Ｓｋｉｒｔ）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の値に基づいて、入力データセット＃２の７番目のレコード「２０１２－Ｆｅｂ－０７　・・・」）を参照するためのスレッド５ｂを生成して実行する。
　次いで、マップ関数１２１は、スレッド５ａにより、２０１２－Ｆｅｂに対応する入力データセット＃１の上から３番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＡＸ　Ｓｋｉｒｔ）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の４つの値に基づいて、入力データセット＃２の８番目のレコード（「２０１２－Ｆｅｂ－０８　・・・」）を参照するためのスレッド５ｃ、入力データセット＃２の１０番目のレコード（「２０１２－Ｆｅｂ－０８　・・・」）を参照するためのスレッド５ｄ、入力データセット＃２の１１番目（「２０１２－Ｆｅｂ－０８　・・・」）のレコードを参照するためのスレッド５ｅ、及び入力データセット＃２の１２番目のレコード（「２０１２－Ｆｅｂ－０９　・・・」）を参照するためのスレッド５ｆを順次生成して実行する。
　次いで、マップ関数１２１は、スレッド５ａにより、入力データセット＃１の２０１２－Ｆｅｂに対応する上から４番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＢＣ　Ｂｉｋｅ）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の２つの値に基づいて、入力データセット＃２の６番目のレコードを参照するためのスレッド５ｇ、入力データセット＃２の９番目のレコードを参照するためのスレッド５ｈを生成して実行する。
　次いで、マップ関数１２１は、スレッド５ａにより、２０１２－Ｆｅｂに対応する入力データセット＃１の上から５番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＢＤ　Ｆｌｏｗｅｒ）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の１つの値に基づいて、入力データセット＃２の５番目のレコード（「２０１２－Ｆｅｂ－０３　・・・」）を参照するためのスレッド５ｉを生成して実行する。
　図５Ｃの下側図に示すように、スレッドを動的に生成し、当該スレッドにおいてレコードを読み込んで処理を行い、複数のスレッドを並行して実行することにより、単一のスレッドを実行する場合に比して、処理の実行時間を短縮することができる。　図５Ｄは、実施例２に係る入力データ及び入力データに対する処理を説明するための第１の図である。図５Ｅは、実施例２に係る入力データ及び入力データに対する処理を説明するための第２の図である。
　実施例２に係るジョブ実行プランにおいては、入力データセット＃２のレコードの値を用いて、更に、入力データセット＃３のレコードを参照する。したがって、図５Ｄに示すように、アプリケーション１１０には、入力データセット＃２のレコードの値（「Ｕｓｅｒ」の値）に基づいて、入力データセット＃３を参照するための参照方式＃２が更に備えられる。ここで、「Ｕｓｅｒ」の値は、当該値に対応する入力データセット＃３のレコードの物理的な位置を示す参照ではなく、論理的な位置を示す（その値によって検索可能である）参照である。
　図５Ｅには、入力データセット＃３と、入力データセット＃４とを示す。
　入力データセット＃４は、「Ｕｓｅｒ」、「Ｇｅｎｄｅｒ」、「Ｚｉｐ」、「Ａｄｄｒｅｓｓ」を含む１以上のレコードを格納する。
　入力データセット＃３は、「Ｕｓｅｒ」と、「Ｒｅｆｅｒｅｎｃｅ」との項目を有する１以上のレコードが、所定の範囲ごとにまとめられて管理されている。「Ｕｓｅｒ」には、入力データセット＃４におけるレコードの検索に使用する鍵となる項目の値が格納される。「Ｒｅｆｅｒｅｎｃｅ」には、入力データセット＃４における当該レコード中の「Ｐｒｏｄｕｃｔ」の値と同一の値を格納するレコード（参照先レコード）の物理的な格納位置を示す参照が格納される。なお、入力データセット＃３に、複数の参照先レコードがある場合には、複数の参照先レコードへの参照が格納される。なお、入力レコード＃３はある鍵によってレコードを検索可能な構造（例えば、Ｂ木）を有してもよく、当該鍵の値を「Ｕｓｅｒ」に格納する参照としてもよい。ある１つの参照に複数のレコードが対応することがあってもよい。
　入力データセット＃３のレコードの書式は、書式＃３に記述されている。また、入力データセット＃４のレコードの書式は、書式＃４に記述されている。また、入力データセット＃３の「Ｒｅｆｅｒｅｎｃｅ」を用いて、入力データセット＃４のレコードを参照する方法については、参照方式＃３に記述されている。また、取得したレコードに基づいて、後続に出力するレコードを生成する手続きがビルド方式に記述されている。
　図１Ｂに示すジョブ実行モデルにおけるステージ＃１プロセスにおいては、プロセッサ１０１が一般化ステージ関数１２４を実行することにより、入力データセット＃１のレコードを読み込み、書式＃１により、レコードにおける「Ｐｒｏｄｕｃｔ」と、「Ｒｅｆｅｒｅｎｃｅ」とを把握する。そして、一般化ステージ関数１２４は、「Ｐｒｏｄｕｃｔ」の値に基づいて、所定の条件に合致するか否かを判断し、条件を満たすレコードの「Ｒｅｆｅｒｅｎｃｅ」を特定する。そして、一般化ステージ関数１２４は、参照方式＃１と、「Ｒｅｆｅｒｅｎｃｅ」とに基づいて、入力データセット＃２のレコードを取得する。
　次いで、プロセッサ１０１が一般化ステージ関数１２４を実行することにより、書式＃２により、読み込んだ入力データセット＃２のレコードの「Ｕｓｅｒ」、「Ｐｒｏｄｕｃｔ」、「Ｃｏｍｍｅｎｔ」を把握する。そして、一般化ステージ関数１２４は、「Ｕｓｅｒ」の値と、参照方法＃２とに基づいて、入力データセット＃３のレコードを取得する。
　プロセッサ１０１が一般化ステージ関数１２４を実行することにより、書式＃３により、取得した入力データセット＃３のレコードにおける「Ｒｅｆｅｒｅｎｃｅ」を把握する。そして、一般化ステージ１２４は、参照方式＃３と、「Ｒｅｆｅｒｅｎｃｅ」とに基づいて、入力データセット＃４のレコードを取得する。
　次いで、プロセッサ１０１が一般化ステージ関数１２４を実行することにより、書式＃４により、読み込んだ入力データセット＃４のレコードの「Ｕｓｅｒ」、「Ｇｅｎｄｅｒ」、「Ｚｉｐ」、「Ａｄｄｒｅｓｓ」を把握する。そして、プロセッサ１０１が一般化ステージ関数１２４を実行することにより、ビルド方式に基づいて、「Ｕｓｅｒ」，「Ｐｒｏｄｕｃｔ」、「Ｃｏｍｍｅｎｔ」、「Ｇｅｎｄｅｒ」、「Ｚｉｐ」を含むレコードを構築して出力する。
　図５Ｆは、実施例２に係る書式を説明するための図である。
　書式＃３は、入力データセット＃３のレコードの書式に関する情報であり、本実施例では、入力データセット＃３のレコードを解釈する手続きが記述されている。書式＃３には、入力レコード（すなわち、入力データセット＃３のレコード）をバイナリ形式で解釈し、入力レコードの各カラムを、Ｔｅｘｔ型、Ｌｏｎｇ型、Ｉｎｔ型、Ｉｎｔ型として解釈すること、第1（０）のカラムを検索鍵とすることが記述されている。
　書式＃４は、入力データセット＃４のレコードの書式に関する情報であり、本実施例では、入力データセット＃４のレコードを解釈する手続きが記述されている。書式＃４には、入力レコード（すなわち、入力データセット＃４のレコード）をテキスト形式（文字列形式）で解釈することが記述されている。また、レコードにおけるカラム間の区切り文字は、カンマであり、第1（０）のカラムは、Ｔｅｘｔ型であり、「Ｕｓｅｒ」と名付け、第２（１）のカラムは、Ｔｅｘｔ型であり、「Ｇｅｎｄｅｒ」と名付け、第３（２）のカラムは、Ｔｅｘｔ型であり、「Ｚｉｐ」と名付け、第４（３）のカラムは、Ｔｅｘｔ型であり、「Ａｄｄｒｅｓｓ」と名付け、これらに基づいて入力カラムを解釈することが記述されている。
　図５Ｇは、実施例２に係る参照方式を説明するための図である。
　参照方式＃２は、入力データセット＃２のレコードの値を用いて、入力データセット＃３のレコードを参照する方法についての手続きであり、入力レコード（書式＃２に対応するレコード）の第２カラムを参照鍵とし、論理参照により参照を行ってレコードを取得することが記述されている。ここで、論理参照は、指定された鍵の値によって、参照先のデータセットを検索して、参照先のレコードを同定することを意味する。
　参照方式＃３は、入力データセット＃４の「Ｒｅｆｅｒｅｎｃｅ」を用いて、入力データセット＃６のレコードを参照する方法についての手続きであり、入力レコード（書式＃５に対応するレコード）の第２カラムをオフセットとし、第３カラムを長さとし、第４カラムをノードＩＤとして、物理参照により参照を行ってレコードを取得することが記述されている。ここで、物理参照は、指定されたノードＩＤが管理するストレージの指定されたオフセット（番地）を始点として、指定された長さ分のバイト列を、参照先のレコードとすることを意味する。
　図５Ｈは、実施例２に係るカタログの一例を示す。
　本実施例においては、書式や、参照方式については、例えば、プログラムコードで記述されている。したがって、この書式や参照方式をユーザが用意することとなると、ユーザ自身がプログラムコードを作成できる必要がある。しかしながら、全てのユーザがプログラムコードを作成できるとは限らない。そこで、本実施例では、ユーザが、アプリケーションにおいて、プログラムコードよりも容易なカタログを記述することにより書式や、参照方式など、ジョブ情報の一部を規定できるようにし、そのカタログに基づいて、並列データ処理システムがデータ処理のジョブを実行するようにする。なお、この際、並列データ処理システムは、カタログを一旦、書式や参照方式に変換してからジョブを実行してもよいし、カタログを以って直接ジョブを実行してもよい。
　図５Ｈに示すカタログは、例えば、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）で記述されており、４つのデータ構造体に関する記述部５０ａ～５０ｄを含む。
　記述部５０ａには、入力データセット＃２に対応する「ｕｓｅｒ＿ｃｏｍｍｅｎｔ」のデータセットは、テキストをカラム分割した形式であり、第１（０）カラムをＤａｔｅＴｉｍｅ型で解釈し、これを分割鍵とし、カラム間の区切り文字をカンマとしていることが記述されている。
　また、記述部５０ｂには、入力データセット＃１に対応する「ｕｓｅｒ＿ｃｏｍｍｅｎｔ．ｐｒｏｄｕｃｔ．ｉｎｄｅｘ」のデータセットは、「ｕｓｅｒ＿ｃｏｍｍｅｎｔ」に対応した局所的な二次索引としての形式であり、「ｕｓｅｒ＿ｃｏｍｍｅｎｔ」に基づいて、カラムの区切り文字をカンマとした際における第３（２）カラムをＴｅｘｔ型で解釈し、これを索引鍵とすることが記述されている。なお、記述部５０ｃ、５０ｄについても、上記記述部と同様な記述となっている。なお、カタログには必要なジョブ情報の一部を全て明示的に規定する必要はなく、明示的に規定されていないものについてはシステムモジュール等が所定の規定に沿って、並列データ処理を行ってもよい。例えば、この例では、「ｕｓｅｒ＿ｃｏｍｍｅｎｔ．ｐｒｏｄｕｃｔ．ｉｎｄｅｘ」については明示的に分割鍵を指定していないが、「ｕｓｅｒ＿ｃｏｍｍｅｎｔ．ｐｒｏｄｕｃｔ．ｉｎｄｅｘ」は局所的な二次索引として規定されていることから、その基となる「ｕｓｅｒ＿ｃｏｍｍｅｎｔ」と同じ分割が行われ、即ち、「ｕｓｅｒ＿ｃｏｍｍｅｎｔ」の分割部分の毎に二次索引としての「ｕｓｅｒ＿ｃｏｍｍｅｎｔ．ｐｒｏｄｕｃｔ．ｉｎｄｅｘ」が構成してもよい。
　図６Ａは、実施例１に係るレコード取得を説明するための模式図の一例である。なお、以下、図６Ａ～図９Ｃの説明は、実施例１についての説明であるが、実施例１に限らず実施例２にも適用される説明である。
　計算ノード１００のプロセッサ１０１がスレッドを実行して、そのスレッドにより、レコードを取得する際に、レコードが自身の計算ノード１００のストレージ１０４に格納されているレコードである場合には、そのストレージ１０４からレコードを取得する。一方、レコードが他の計算ノード１００のストレージ１０４に格納されている場合には、計算ノード１００から他の計算ノード１００へ、例えばローカルエリアネットワーク２００を介して、レコードを取得するためのレコード取得要求を送信し、計算ノード１００は当該レコード取得要求に従い他の計算ノード１００がそのストレージ１０４から取得したレコードを受信することにより、レコードを取得する。この際、計算ノード１００と他の計算ノード１００との間にはセッションが張られる。複数のスレッドを実行している場合には、スレッド毎に発生されるレコード取得要求毎に、セッションが張られることとなる。この場合には、スレッド数が多くなればなるほど、張られるセッション数が増加することとなり、セッションの管理や制御に係る処理が増大してその効率が低下する。
　これに対して、以下に示すように、複数のレコード取得要求をまとめたブロック毎にセッションを張るようにしてもよい。
　図６Ｂは、実施例２に係るデータ取得時のブロック化を説明するための模式図の一例である。
　計算ノード１００のプロセッサ１０１は、複数のスレッドにより発生される複数のレコード取得要求を、１つのブロック（ブロック化レコード取得要求）にまとめ、当該ブロックを単位として計算ノード１００と、他の計算ノード１００との間にセッションを張る。これにより、計算ノード１００間に張られるセッション数を低減することができ、処理効率の低下を防止することができる。
　図７Ａは、実施例１に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。
　このレコード取得処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理に対応する。
　Ｓ４１で、データ読み書き器１４０は、システムモジュール１２０から指示されたレコードの読み込み（取得）が、自身の計算ノード１００のストレージ１０４からのレコードの取得、すなわち、ローカルレコードの取得であるか否かを判断する。この判断の結果が肯定的であれば、Ｓ４２を行う一方、この判断の結果が否定的であれば、Ｓ４４を行う。
　Ｓ４２で、データ読み書き器１４０は、ストレージマネージャ１６０により、ＯＳ１７０ならびにＨＢＡ１０３を経由して、ストレージ１０４に対して、レコードの取得に必要なデータを読み込むためのデータ読み込み要求を発行させる。具体的には、ストレージマネージャ１６０は、データ読み込み要求管理表７００（図７Ｃ参照）にデータ読み込み要求の情報を格納するとともに、計算ノード１００の主記憶１０５の要求キュー７４０に対して、データ読み込み要求を追加する。ＯＳ１７０は、要求キュー７４０からデータ読み込み要求を取得して、ＨＢＡ１０３によってストレージ１０４に発行する。
　Ｓ４３で、データ読み書き器１４０は、自スレッドを保留状態とし、処理を終了する。
　Ｓ４４で、データ読み書き器１４０は、ネットワークマネージャ１５０により、ＯＳ１７０ならびにＮＩＣ１０２を経由して、他の計算ノード１００に対して、レコード取得要求メッセージを送信させる。具体的には、ネットワークマネージャ１５０は、リモートレコード取得要求管理表７１０（図７Ｃ参照）にレコード取得要求メッセージの情報を格納するとともに、計算ノード１００の主記憶１０５の送信キュー７２０に対して、レコード取得要求メッセージを追加する。
　Ｓ４５で、データ読み書き器１４０は、自スレッドを保留状態とし、処理を終了する。
　一方、計算ノード１００のストレージ１０４は、要求キュー７４０から発行されたデータ読み込み要求を受信して、当該データ読み込み要求に対応するデータを読み込んで、ＨＢＡ１０３に送信する。ＯＳ１７０は、ＨＢＡ１０３より読み込んだ当該データを主記憶１０５の完了キュー７５０に追加する。
　その後、Ｓ４６で、データ読み書き器１４０は、完了キュー７５０からデータ読み込み要求に対応するデータを取得し、当該データからレコードを抽出する。レコード
　Ｓ４７で、データ読み書き器１４０は、データ読み込み要求管理表７００に基づいて、受け取ったレコードを使用するスレッドを特定し、当該スレッドを再開し、レコード取得処理を終了する。
　一方、送信キュー７２０に格納されたレコード取得要求メッセージは、ＮＩＣ１０２により送信先の計算ノード１００に送信される。また、他の計算ノード１００から送信されるレコード取得要求メッセージに対する取得完了メッセージは、ＮＩＣ１０２により受信キュー７３０に格納される。
　Ｓ４８で、ネットワークマネージャ１５０は、受信キュー７３０の取得完了メッセージからレコードを抽出し、システムモジュール１２０に渡す。
　Ｓ４９で、データ読み書き器１４０は、リモートレコード取得要求管理表７１０に基づいて、受け取ったレコードを使用するスレッドを特定し、当該スレッドを再開し、レコード取得処理を終了する。
　図７Ｂは、実施例１に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。
　レコード取得要求メッセージの送信先の計算ノード１００においては、ＮＩＣ１０２がレコード取得要求メッセージを取得し、ＯＳ１７０が主記憶１０５の受信キュー７６０に格納する。
　Ｓ５０で、送信先の計算ノード１００のネットワークマネージャ１５０は、受信キュー７６０からレコード取得要求メッセージを取得し、データ読み書き器１４０に渡す。
　Ｓ５１で、データ読み書き器１４０は、レコード取得要求メッセージに基づいて、ストレージマネージャ１６０により、ＯＳ１７０ならびにＨＢＡ１０３を経由して、ストレージ１０４に対して、レコードの取得に必要なデータを読み込むためのデータ読み込み要求を発行させ、処理を終了する。具体的には、ストレージマネージャ１６０は、計算ノード１００の主記憶１０５の要求キュー７８０に対して、データ読み込み要求を追加する。ＯＳ１７０は、ＨＢＡ１０３により、要求キュー７４０からデータ読み込み要求を取得して、ストレージ１０４に発行する。
　ストレージ１０４は、要求キュー７８０から発行されたデータ読み込み要求を受信し、当該データ読み込み要求に対応するレコードを読み込んで、ＨＢＡ１０３に送信する。ＯＳ１７０は、ＨＢＡ１０３による読み込んだ当該レコードを主記憶１０５の完了キュー７９０に追加する。
　その後、Ｓ５２で、データ読み書き器１４０は、完了キュー７９０からデータ読み込み要求に対応するデータからレコードを抽出する。
　Ｓ５３で、データ読み書き器１４０は、受け取ったレコードを取得完了メッセージに含め、ネットワークマネージャ１５０により、レコード取得要求メッセージの送信元の計算ノード１００に対して取得完了メッセージを送信し、処理を終了する。具体的には、ネットワークマネージャ１５０は、計算ノード１００の主記憶１０５の送信キュー７６０に対して、取得完了メッセージを追加する。
　送信キュー７６０に格納された取得完了メッセージは、ＮＩＣ１０２によりレコード取得要求メッセージの送信元の計算ノード１００に送信される。この取得完了メッセージは、送信元の計算ノード１００において、ＮＩＣ１０２により受信キュー７３０に格納する。
　図７Ａに図示する処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理を行うスレッド（ＳＬ１、ＳＬ２、ＳＬｄ１、ＳＬｄ２、ＳＬｄｋ、ＳＬｄｋ＋１等）において実行してもよい。例えば、ＣＰＵ１０１がスレッドＳＬ１においてＳ１０のデータ取得処理を実行することにより、ＣＰＵ１０１がＳ４１からＳ４５までに相当する手続きを同じスレッドＳＬ１で実行してもよい。また、図７Ａに図示する処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理を行うスレッド（ＳＬ１、ＳＬ２、ＳＬｄ１、ＳＬｄ２、ＳＬｄｋ、ＳＬｄｋ＋１等）とは別のスレッドにおいて実行してもよい。例えば、ＣＰＵ１０１がスレッドＳＬ１においてＳ１０のデータ取得処理を実行することにより、ＣＰＵ１０１がＳ４１からＳ４５までに相当する手続きを別のスレッドで実行してもよい。この際、Ｓ４１からＳ４５までに相当する手続き、Ｓ４６からＳ４７までに相当する手続き、Ｓ４８からＳ４９までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。また、Ｓ４６からＳ４７までに相当する手続き、Ｓ４８からＳ４９までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー７５０ならびに受信キュー７３０に対してＨＢＡ１０３ならびにＮＩＣ１０２が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
　図７Ｂに図示する処理については、Ｓ５０からＳ５１までに相当する手続き、Ｓ５２からＳ５３までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。また、Ｓ５２からＳ５３までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー７９０に対してＨＢＡ１０３が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
　図７Ｃは、実施例１に係るデータ読み込み要求管理表及びリモートレコード取得要求管理表の構成を示す。
　データ読み込み要求管理表７００は、データ読み込み要求毎の情報として、スレッドＩＤ７０１、要求発行時刻７０２、及びデータ読み込み要求７０３を有する。データ読み込み要求７０３は、装置ＩＤ７０４、オフセット番地７０５、読み込み長７０６、及びバッファ番地７０７を有する。各種情報は、下記の通りである。
（＊）スレッドＩＤ７０１は、データ読み込み要求を発行させたスレッドを識別するためのＩＤを示す。
（＊）要求発行時刻７０２は、データ読み込み要求を発行した時刻を示す。
（＊）データ読み込み要求７０３は、データ読み込み要求の内容を示す。
（＊）装置ＩＤ７０４は、データ読み込み要求の送信先のストレージ１０４の装置ＩＤを示す。
（＊）オフセット番地７０５は、データ読み込み要求対象のレコードが格納されるストレージ１０４におけるアドレス（オフセット番地）を示す。
（＊）読み込み長７０６は、読み込むレコードのデータ長（バイト長）を示す。
（＊）バッファ番地７０７は、データ読み込み要求対象のレコードを格納する主記憶１０５上の領域（バッファ）のアドレスを示す。
　リモートレコード取得要求管理表７１０は、レコード取得要求毎の情報として、スレッドＩＤ７１１、要求発行時刻７１２、及びレコード取得要求７１３を有する。レコード取得要求７１３は、計算ノードＩＤ７１４、レコード参照７１５、バッファ番地７１６を有する。各種情報は、下記の通りである。
（＊）スレッドＩＤ７１１は、レコード取得要求を発行させたスレッドを識別するためのＩＤを示す。
（＊）要求発行時刻７１２は、レコード取得要求を発行した時刻を示す。
（＊）レコード取得要求７１３は、レコード取得要求の内容を示す。
（＊）計算ノードＩＤ７１４は、レコード取得要求の送信先の計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）レコード参照７１５は、レコード取得要求の対象となるレコードへの参照情報を示す。
（＊）バッファ番地７１６は、データ読み込み要求対象のレコードを格納する主記憶１０５上の領域（バッファ）のアドレスを示す。
　次に、実施例１の変形例に係るレコード取得処理を説明する。
　図７Ｄは、実施例１の変形例に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。
　このレコード取得処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理に対応する。
　Ｓ６１で、データ読み書き器１４０は、システムモジュール１２０から指示されたレコードの読み込み（取得）が、自身の計算ノード１００のストレージ１０４からのレコードの取得、すなわち、ローカルレコードの取得であるか否かを判断する。この判断の結果が肯定的であれば、Ｓ６２を行う一方、この判断の結果が否定的であれば、Ｓ６４を行う。
　Ｓ６２で、データ読み書き器１４０は、ストレージマネージャ１６０により、ストレージ１４０に対して、データ読み込み要求を発行させる。なお、具体的な処理は、図７ＡにおけるＳ４２と同様である。
　Ｓ６３で、データ読み書き器１４０は、自スレッドを保留状態とし、処理を終了する。
　Ｓ６４で、データ読み書き器１４０は、各計算ノード１００に対するレコード取得要求メッセージを、主記憶１０５の各計算ノード１００のそれぞれに対応して設けられているブロック化キュー８００、８１０、８２０の中の、このレコード取得要求メッセージの送信先の計算ノード１００に対応するブロック化キューに追加し、当該レコード取得要求メッセージをブロック化リモートレコード取得要求管理表８３０に追加する。ここで、ブロック化リモードレコード取得要求管理表８３０においては、同一の計算ノード１００を送信先とする複数のレコード取得要求メッセージが１つの要求（ブロック化リモートレコード取得要求）にまとめられる。
　Ｓ６５で、データ読み書き器１４０は、自スレッドを保留状態とし、処理を終了する。
　Ｓ６６で、ネットワークマネージャ１５０は、各ブロック化キュー８００、８１０、８２０のそれぞれから、複数のレコード取得要求メッセージを含むブロック化リモートレコード取得要求を抽出する。
　Ｓ６７で、ネットワークマネージャ１５０は、ブロック化リモートレコード取得要求メッセージをＯＳ１７０ならびにＮＩＣ１０２を介して送信し、処理を終了する。具体的には、ネットワークマネージャ１５０は、ブロック化リモートレコード取得要求メッセージを主記憶１０５の送信キュー８４０に格納し、ＮＩＣ１０２が送信キュー８４０からブロック化リモートレコード取得要求メッセージを送信先の計算ノード１００に送信する。このように、複数のレコード取得要求を１つのブロック化リモートレコード取得要求メッセージとするとので、通信時に張られるセッション数を低減することができる。
　この後、ＯＳ１７０は、ＮＩＣ１０２により、他の計算ノード１００から送信されるブロック化レコード取得完了メッセージを受信し、受信キュー８５０に格納する。
　Ｓ６８で、ネットワークマネージャ１５０は、受信キュー８５０からブロック化レコード取得完了メッセージを取得し、ブロック化レコード取得完了メッセージから複数のレコードを抽出し、システムモジュール１２０に渡す。
　Ｓ６９で、データ読み書き器１４０は、ブロック化リモートレコード取得要求管理表８３０に基づいて、受け取ったレコードを使用するスレッドを特定し、当該スレッドを再開し、レコード取得処理を終了する。
　図７Ｅは、実施例１の変形例に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。
　ブロック化リモートレコード取得要求メッセージの送信先の計算ノード１００においては、ＮＩＣ１０２がブロック化リモートレコード取得要求メッセージを取得し、主記憶１０５の受信キュー８６０に格納する。
　Ｓ７０で、送信先の計算ノード１００のネットワークマネージャ１５０は、受信キュー８６０からブロック化リモートレコード取得要求メッセージを取得し、ブロック化リモートレコード取得要求メッセージから複数のレコード取得要求を抽出してデータ読み書き器１４０に渡す。
　Ｓ７１で、データ読み書き器１４０は、複数のレコード取得要求メッセージに基づいて、ストレージマネージャ１６０により、ＨＢＡ１０３を経由して、ストレージ１０４に対して、複数のレコードの取得に必要なデータを読み込むための複数のデータ読み込み要求を発行し、処理を終了する。具体的には、ストレージマネージャ１６０は、計算ノード１００の主記憶１０５の要求キュー８８０に対して、複数のデータ読み込み要求を追加する。ＨＢＡ１０４は、要求キュー７８０からデータ読み込み要求を取得して、ストレージ１０４に発行する。
　ストレージ１０４は、要求キュー８８０から発行されたデータ読み込み要求を受信し、当該データ読み込み要求に対応するレコードを読み込んで、ＨＢＡ１０３に送信し、ＨＢＡ１０３が読み込んだ当該データを主記憶１０５の完了キュー８９０に追加する。
　その後、Ｓ７２で、ストレージマネージャ１６０は、完了キュー８９０からデータ読み込み要求に対応する複数のレコードを取得し、当該データからレコードを抽出し、システムモジュール１２０に渡す。
　Ｓ７３で、データ読み書き器１４０は、受け取った複数のレコードをブロック化取得完了メッセージに含め、ネットワークマネージャ１５０により、ブロック化リモートレコード取得要求メッセージの送信元の計算ノード１００に対してブロック化取得完了メッセージを送信させ、処理を終了する。具体的には、ネットワークマネージャ１５０は、計算ノード１００の主記憶１０５の送信キュー８７０に対して、ブロック化取得完了メッセージを追加する。送信キュー８７０に格納されたブロック化取得完了メッセージは、ＮＩＣ１０２によりブロック化リモートレコード取得要求メッセージの送信元の計算ノード１００に送信される。このブロック化取得完了メッセージは、送信元の計算ノード１００において、ＮＩＣ１０２により受信キュー８５０に格納される。
　図７Ｄに図示する処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理を行うスレッド（ＳＬ１、ＳＬ２、ＳＬｄ１、ＳＬｄ２、ＳＬｄｋ、ＳＬｄｋ＋１等）において実行してもよい。例えば、ＣＰＵ１０１がスレッドＳＬ１においてＳ１０のデータ取得処理を実行することにより、ＣＰＵ１０１がＳ６１からＳ６５までに相当する手続きを同じスレッドＳＬ１で実行してもよい。また、図７Ｄに図示する処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理を行うスレッド（ＳＬ１、ＳＬ２、ＳＬｄ１、ＳＬｄ２、ＳＬｄｋ、ＳＬｄｋ＋１等）とは別のスレッドにおいて実行してもよい。例えば、ＣＰＵ１０１がスレッドＳＬ１においてＳ１０のデータ取得処理を実行することにより、ＣＰＵ１０１がＳ６１からＳ６５までに相当する手続きを別のスレッドで実行してもよい。この際、Ｓ６１からＳ６５までに相当する手続き、Ｓ６６からＳ６７までに相当する手続き、Ｓ６８からＳ６９までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。また、Ｓ６６からＳ６７までに相当する手続き、Ｓ６８からＳ６９までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー７５０ならびに受信キュー７３０に対してＨＢＡ１０３ならびにＮＩＣ１０２が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
　図７Ｅに図示する処理については、Ｓ７０からＳ７１までに相当する手続き、Ｓ７２からＳ７３までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。例えば、Ｓ７０で取得したブロック化レコード取得要求メッセージに従い、複数のスレッドを生成し、その各々のスレッドにおいてＳ７１を実行してデータ読み込み要求を実行してもよい。この際、当該メッセージに含まれるレコード取得要求の数と同じ数のスレッドを生成してもよいし、また、所定の数のスレッドを生成してもよい。Ｓ７２からＳ７３までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー７９０に対してＨＢＡ１０３が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
　図７Ｆは、変形例に係るブロック化リモートレコード取得要求管理表の構成を示す。
　ブロック化リモートレコード取得要求管理表８３０は、ブロック化リモートレコード取得要求毎の情報として、要求発行時刻８３２、要求の数８３３、及び１以上のレコード取得要求８３４を有する。レコード取得要求８３４は、スレッドＩＤ８３１、計算ノードＩＤ８３５、レコード参照８３６、バッファ番地８３７、完了フラグ８３８を有する。各種情報は、下記の通りである。
（＊）要求発行時刻８３２は、ブロック化リモートレコード取得要求を発行した時刻を示す。
（＊）要求の数８３３は、ブリック化リモートレコード取得要求に含まれるレコード取得要求の数を示す。
（＊）レコード取得要求８３４は、レコード取得要求の内容を示す。
（＊）スレッドＩＤ８３１は、レコード取得要求を発行したスレッドを識別するためのＩＤを示す。
（＊）計算ノードＩＤ８３５は、レコード取得要求の送信先の計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）レコード参照８３６は、レコード取得要求の対象となるレコードへの参照情報を示す。
（＊）バッファ番地８３７は、レコード取得要求の対象となるレコードを格納する主記憶１０５上の領域（バッファ）のアドレスを示す。
（＊）完了フラグ８３８は、レコード取得要求に対応するレコードを取得したか否かを示すフラグである。
　なお、上記においては、本発明の特徴的な点に焦点を絞って、並列データ処理を行うジョブにおいて、レコード取得する手続きを説明したが、当該手続きには多様な実装形態が考えられる。
　データセットからレコードを抽出するためには、データセット中でレコードがどのように配置されているかの情報が不可欠である。例えば、テキストファイルをデータセットとし、そのうちの１行をレコードとして取り扱う場合においては、レコードとレコードは改行コードによって区切られる。当該テキストファイルからレコードを取り出すためには、レコードが改行コードによって区切られているという情報が欠かせない。また、別の例としては、データセットがＢ木等の構造を有する場合、幾つかのレコードはストレージ上のアクセスの単位であるページの中に適当なデータ構造によって詰め込まれている場合がある。そのような構造からレコードを取り出すためには、当該構造（ページの長さ、ページのヘッダ・フッタ構造、ページ中におけるレコードのヘッダ・フッタ構造等）の情報が欠かせない。更には、データセットが圧縮や暗号化されている場合には、当該データセットからレコードを取得するためには復号のための手続き情報が欠かせない。このようにレコードを取得するためのデータセットの構成に関する情報は、書式等に同様に、ジョブ情報の一部としてアプリケーションによって規定されてもよい。もしくは、データセットの構成に関する情報は、その全てをアプリケーションが明示的に規定しなくてもよい。アプリケーションによって規定されていないデータセットの構成に関しては、システムモジュール等が所定の構成が規定されているものと見做して、ジョブを実行してもよい。この際、システムモジュール等は、データセットに関する情報やデータセットに基づいて、データセットの構成を判断してもよい。例えば、アプリケーションが明示的にデータセットの構成を規定していないものの、データセットがテキストファイルであると判断される場合には、レコードが改行コードによって区切られているものとしてジョブを実行してもよい。なお、この際に、アプリケーションが規定するデータセットの構成に関する情報は、システムモジュールを介して、データ読み書き器に通知されてもよい。
　システムモジュール等は、データセットからレコードを抽出する際に、データセットの一部のデータを主記憶等にキャッシュし、ストレージへのアクセスを減らすようにしてもよい。例えば、テキストファイルを走査してレコードを取得する場合、レコードの毎にストレージにアクセスするのではなく、一度に１メガバイト等の単位でテキストファイルからデータを読み込んで主記憶に格納し、そのデータの中からレコードを取り出すようにしてもよい。
　図８Ａは、実施例１に係るノードレベルの資源制約管理表の構成を示す。
　図８Ａの上側のノードレベルの資源制約管理表９００は、各計算ノード１００を統括する統括スーパバイザプロセスにより管理される。
　ノードレベルの資源制約管理表９００は、計算ノード毎の情報として、計算ノードＩＤ９０１、資源制約９０２を有する。資源制約９０２は、スレッド数９０３と、主記憶割当て９０４とを有する。各種情報は、下記の通りである。
（＊）計算ノードＩＤ９０１は、計算ノードのＩＤを示す。
（＊）資源制約９０２は、計算ノードＩＤ９０１に対応する計算ノードにおける資源の制約を示す。
（＊）スレッド数９０３は、計算ノードＩＤ９０１に対応する計算ノードにおいて、生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９０４は、計算ノードＩＤ９０１に対応する計算ノードにおいて、割当て可能な主記憶の最大の記憶量を示す。
　図８Ａの下側のノードレベルの資源制約管理表９１０は、各計算ノード１００におけるスーパバイザプロセスにより管理される。
　ノードレベルの資源制約管理表９１０は、自身の計算ノードの情報として、計算ノードＩＤ９１１、資源制約９１２、及び資源利用９１３を有する。資源制約９１２は、スレッド数９１４と、主記憶割当て９１５とを有する。資源利用９１３は、スレッド数９１６と、主記憶割当て９１７とを有する。各種情報は、下記の通りである。
（＊）計算ノードＩＤ９１１は、自身の計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９１２は、自身の計算ノードにおける資源の制約を示す。
（＊）資源利用９１３は、自身の計算ノードにおいて利用している資源を示す。
（＊）スレッド数９１４は、自身の計算ノードにおいて、生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９１５は、自身の計算ノードにおいて、割当て可能な主記憶の最大の記憶量を示す。
（＊）スレッド数９１６は、自身の計算ノードにおいて、実際に生成しているスレッドの数を示す。
（＊）主記憶割当て９１７は、自身の計算ノードにおいて、実際に割当てている主記憶の記憶量を示す。
　図８Ｂは、実施例１に係るジョブレベルの資源制約管理表の構成を示す。
　図８Ｂの上側のジョブレベルの資源制約管理表９２０は、統括スーパバイザプロセスにより管理される。
　ジョブレベルの資源制約管理表９２０は、ジョブ毎の情報として、ジョブＩＤ９２１、計算ノードＩＤ９２２、資源制約９２３を有する。資源制約９２３は、スレッド数９２４と、主記憶割当て９２５とを有する。各種情報は、下記の通りである。
（＊）ジョブＩＤ９２１は、ジョブのＩＤ（ジョブＩＤ）を示す。
（＊）計算ノードＩＤ９２２は、ジョブＩＤ９２１のジョブを実行する計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９２３は、計算ノードＩＤ９２２の計算ノードにおけるジョブＩＤ９２１のジョブに対する資源の制約を示す。
（＊）スレッド数９２４は、計算ノードＩＤ９２２の計算ノードにおけるジョブＩＤ９２１のジョブに対する生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９２５は、計算ノードＩＤ９２２の計算ノードにおけるジョブＩＤ９２１のジョブに対する割当て可能な主記憶の最大の記憶量を示す。
　図８Ｂの下側のノードレベルの資源制約管理表９３０は、各計算ノード１００におけるスーパバイザプロセスにより管理される。
　ノードレベルの資源制約管理表９３０は、自身の計算ノードにおける各ジョブに対する情報として、ジョブＩＤ９３１、計算ノードＩＤ９３２、資源制約９３３、及び資源利用９３４を有する。資源制約９３３は、スレッド数９３５と、主記憶割当て９３６とを有する。資源利用９３４は、スレッド数９３７と、主記憶割当て９３８とを有する。各種情報は、下記の通りである。
（＊）ジョブＩＤ９３１は、ジョブのＩＤ（ジョブＩＤ）を示す。
（＊）計算ノードＩＤ９３２は、自身の計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９３３は、自身の計算ノード１００におけるジョブＩＤ９３１のジョブに対する資源の制約を示す。
（＊）資源利用９３４は、自身の計算ノード１００においてジョブＩＤ９３１のジョブに対して利用している資源を示す。
（＊）スレッド数９３５は、自身の計算ノード１００におけるジョブＩＤ９３１のジョブに対する、生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９３６は、自身の計算ノード１００におけるジョブＩＤ９３１のジョブに対する、割当て可能な主記憶の最大の記憶量を示す。
（＊）スレッド数９３７は、自身の計算ノード１００においてジョブＩＤ９３１のジョブに対して、実際に生成しているスレッドの数を示す。
（＊）主記憶割当て９３８は、自身の計算ノード１００においてジョブＩＤ９３１のジョブに対して、実際に割当てている主記憶の記憶量を示す。
　図８Ｃは、実施例１に係る統括するスーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。
　プロセスレベルの資源制約管理表９４０は、統括スーパバイザプロセスにより管理される。
　プロセスレベルの資源制約管理表９４０は、プロセス毎の情報として、プロセスＩＤ９４１、ジョブＩＤ９４２、計算ノードＩＤ９４３、資源制約９４４を有する。資源制約９４４は、スレッド数９４５と、主記憶割当て９４６とを有する。各種情報は、下記の通りである。
（＊）プロセスＩＤ９４１は、プロセスのＩＤ（プロセスＩＤ）を示す。
（＊）ジョブＩＤ９４２は、ジョブＩＤを示す。
（＊）計算ノードＩＤ９４３は、ジョブＩＤ９２１のジョブのプロセスＩＤ９４１のプロセスを実行する計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９４４は、計算ノードＩＤ９４３の計算ノードにおけるジョブＩＤ９４２のジョブのプロセスＩＤ９４１のプロセスに対する資源の制約を示す。
（＊）スレッド数９４５は、計算ノードＩＤ９４３の計算ノードにおけるジョブＩＤ９４２のジョブのプロセスＩＤ９４１のプロセスに対する生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９４６は、計算ノードＩＤ９４３の計算ノードにおけるジョブＩＤ９４２のジョブのプロセスＩＤ９４１のプロセスに対する割当て可能な主記憶の最大の記憶量を示す。
　図８Ｄは、実施例１に係る各ノードのスーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。
　プロセスレベルの資源制約管理表９５０は、各計算ノード１００におけるスーパバイザプロセスにより管理される。
　プロセスレベルの資源制約管理表９５０は、自身の計算ノードにおける各ジョブにおける各プロセスに対する情報として、プロセスＩＤ９５１、ジョブＩＤ９５２、計算ノードＩＤ９５３、資源制約９５４、及び資源利用９５５を有する。資源制約９５４は、スレッド数９５６と、主記憶割当て９５７とを有する。資源利用９５５は、スレッド数９５８と、主記憶割当て９５９とを有する。各種情報は、下記の通りである。
（＊）プロセスＩＤ９５１は、プロセスのＩＤを示す。
（＊）ジョブＩＤ９５２は、ジョブのＩＤを示す。
（＊）計算ノードＩＤ９５３は、自身の計算ノード１００のＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９５４は、自身の計算ノード１００におけるジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対する資源の制約を示す。
（＊）資源利用９５５は、自身の計算ノード１００においてジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対して利用している資源を示す。
（＊）スレッド数９５６は、自身の計算ノード１００におけるジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対する、生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９５７は、自身の計算ノード１００におけるジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対する、割当て可能な主記憶の最大の記憶量を示す。
（＊）スレッド数９５８は、自身の計算ノード１００においてジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対して、実際に生成しているスレッドの数を示す。
（＊）主記憶割当て９５９は、自身の計算ノード１００においてジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対して、実際に割当てている主記憶の記憶量を示す。
　図８Ｅは、実施例１に係る統括スーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。
　タスクレベルの資源制約管理表９６０は、統括スーパバイザプロセスにより管理される。
　タスクレベルの資源制約管理表９６０は、タスク毎の情報として、タスクＩＤ９６１、プロセスＩＤ９６２、ジョブＩＤ９６３、計算ノードＩＤ９６４、資源制約９６５を有する。資源制約９４４は、スレッド数９４５と、主記憶割当て９４６とを有する。各種情報は、下記の通りである。
（＊）タスクＩＤ９６１は、タスクのＩＤ（プロセスＩＤ）を示す。
（＊）プロセスＩＤ９６２は、プロセスのＩＤ（プロセスＩＤ）を示す。
（＊）ジョブＩＤ９６３は、ジョブＩＤを示す。
（＊）計算ノードＩＤ９６４は、ジョブＩＤ９６３のジョブのプロセスＩＤ９６２のプロセスのタスクＩＤ９６１のタスクを実行する計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９６５は、計算ノードＩＤ９６４の計算ノードにおけるジョブＩＤ９６３のジョブのプロセスＩＤ９６２のプロセスのタスクＩＤ９６１のタスクに対する資源の制約を示す。
（＊）スレッド数９６６は、計算ノードＩＤ９６４の計算ノードにおけるジョブＩＤ９６３のジョブのプロセスＩＤ９６２のプロセスのタスクＩＤ９６１のタスクに対する生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９６７は、計算ノードＩＤ９６４の計算ノードにおけるジョブＩＤ９６３のジョブのプロセスＩＤ９６２のプロセスのタスクＩＤ９６１のタスクに対する割当て可能な主記憶の最大の記憶量を示す。
　図８Ｆは、実施例１に係る各ノードのスーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。
　タスクレベルの資源制約管理表９７０は、各計算ノード１００におけるスーパバイザプロセスにより管理される。
　タスクレベルの資源制約管理表９７０は、自身の計算ノードにおける各ジョブにおける各プロセスの各タスクに対する情報として、タスクＩＤ９７１、プロセスＩＤ９７２、ジョブＩＤ９７３、計算ノードＩＤ９７４、資源制約９７５、及び資源利用９７６を有する。資源制約９７５は、スレッド数９７７と、主記憶割当て９７８とを有する。資源利用９７６は、スレッド数９７９と、主記憶割当て９８０とを有する。各種情報は、下記の通りである。
（＊）タスクＩＤ９７１は、タスクのＩＤを示す。
（＊）プロセスＩＤ９７２は、プロセスのＩＤを示す。
（＊）ジョブＩＤ９７３は、ジョブのＩＤを示す。
（＊）計算ノードＩＤ９７４は、自身の計算ノード１００のＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９７５は、自身の計算ノード１００におけるジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対する資源の制約を示す。
（＊）資源利用９７６は、自身の計算ノード１００においてジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対して利用している資源を示す。
（＊）スレッド数９７７は、自身の計算ノード１００におけるジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対する、生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９７８は、自身の計算ノード１００におけるジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対する、割当て可能な主記憶の最大の記憶量を示す。
（＊）スレッド数９７９は、自身の計算ノード１００においてジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対して、実際に生成しているスレッドの数を示す。
（＊）主記憶割当て９８０は、自身の計算ノード１００においてジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対して、実際に割当てている主記憶の記憶量を示す。
　図８Ｇは、実施例１に係る統括資源制約管理処理の流れを示す。
　Ｓ８１で、各計算ノード１００のスーパバイザプロセスを統括する計算ノード１００における統括スーパバイザプロセスは、新たにタスクを割り当てる際に、当該新たなタスクに対する資源制約を計算する。なお、ユーザが指定した資源制約としてもよいし、ユーザが指定したポリシーに基づいて資源制約を計算（例えば、比例配分）してもよい。
　Ｓ８２で、統括スーパバイザプロセスは、図８Ｅに示すようなタスクレベルの資源制約管理表９６０に、新たなタスクに対するレコードを追加し、当該レコードの資源制約に対して計算した資源制約を格納する。また、統括スーパバイザプロセスは、資源制約の範囲でタスクを実行可能な計算ノード１００を選択し、当該計算ノード１００に対して、計算ノードに関わる資源制約を送信する。
　Ｓ８３で、統括スーパバイザプロセスは、選択した計算ノード１００に対して、タスクを割り当てて、処理を終了する。
　Ｓ８４で、タスクを割当てられた計算ノード１００のスーパバイザプロセスは、ステップＳ８２で送信された資源制約を受信し、当該資源制約を図８Ｆに示すようなタスクレベルの資源制約管理表９７０に登録する。
　Ｓ８５で、タスクを割当てられた計算ノード１００のシステムモジュール１２０は、割り当てられたタスクを実行する。
　図８Ｈは、実施例１に係る各計算ノードにおける資源制約管理処理の流れを示す。
　資源制約管理処理は、例えば、システムモジュール１２０がタスクを実行することにより、実現される。図８Ｈの左上の処理（ステップＳ９０～Ｓ９４）は、タスクにおいて、スレッドを生成しようとする際に実行される処理である。これは、例えば、図４ＡのＳ１３、図４ＢのＳ２４、Ｓ３１において実行される処理である。
　Ｓ９０で、システムジュール１２０（具体的には、マップ関数１２１）は、スレッドを生成するのに十分な資源があるか否かを判断する。ここで、スレッドを生成するのに十分な資源があるか否かについては、タスクレベルの資源制約管理表９７０、プロセスレベルの資源制約管理表９５０、ジョブレベルの資源制約管理表９３０、及びノードレベルの資源制約管理表９１０のそれぞれを参照し、各レベルにおいて資源制約の範囲内で利用可能な資源が、スレッドを生成するのに十分な資源以上であるか否かにより判断することができる。
　そして、この判断の結果が肯定的であれば、Ｓ９１を行う一方、この判断の結果が否定的であれば、Ｓ９３を行う。
　Ｓ９１で、システムモジュール１２０は、スレッドマネージャ１３３によりスレッドを生成させて、当該スレッドに資源を割当てさせ、割当結果を各資源制約管理表（９１０、９３０、９５０、及び９７０）の資源利用に反映させる。
　Ｓ９２で、システムモジュール１２０は、スレッドの実行を開始し、資源制約管理処理を終了する。
　Ｓ９３で、システムモジュール１２０は、スレッドを生成するために参照するスレッド生成情報をスレッド生成保留管理表９９０に退避する。
　Ｓ９４で、システムモジュール１２０は、自スレッドをスレッドの生成を保留している保留状態として処理を終了する。
　スレッド生成保留管理表９９０は、スレッドの生成を保留しているスレッドの情報として、タスクＩＤ９９１、親スレッドＩＤ９９２、子スレッドＩＤ９９３、時刻９９４、及びスレッド生成情報９９５を有する。各種情報は、下記の通りである。
（＊）タスクＩＤ９９１は、タスクのＩＤを示す。
（＊）親スレッドＩＤ９９２は、他のスレッドを生成する親となるスレッド（親スレッド）のＩＤを示す。
（＊）子スレッドＩＤ９９３は、スレッドから生成される子となるスレッド（子スレッド）のＩＤを示す。
（＊）時刻９９４は、スレッドの生成を保留した時刻を示す。
（＊）スレッド生成情報９９５は、スレッドを生成する際に必要な情報（例えば、子スレッドで参照するレコードを示す参照を含む情報）である。
　図８Ｈの右上の処理（ステップＳ９５～Ｓ９６）は、スレッドにより実行する処理が終了した際に、スレッドを停止させる処理である。
　Ｓ９５で、システムモジュール１２０は、実行している自スレッドを停止する。
　Ｓ９６で、システムモジュール１２０は、自スレッドに割り当てられている資源を解放する。すなわち、システムモジュール１２０は、資源制約管理表９１０等の資源利用で管理されている資源量（スレッド数、主記憶割当て量）から、自スレッドに割当てられていた資源の量を削除する。これにより、自スレッドに割り当てられていた資源を、他のスレッドに割当てることができるようになる。
　図８Ｈの右下の処理（ステップＳ９７～Ｓ９９）は、例えば、資源制約管理表９１０に基づいて、スレッドを生成するのに十分な資源があることを判定した場合に実行される処理である。この手続きは、例えば、Ｓ９６によって資源が解放されたことに伴い、割り込みやシグナルなどの手段により、駆動されてもよい。
　Ｓ９７で、システムモジュール１２０は、スレッド生成保留管理表９９０に管理されているスレッド生成情報を選択する。選択するスレッド生成情報としては、例えば、最古に保留されたスレッド生成情報であってもよい。
　Ｓ９８で、システムモジュール１２０は、選択したスレッド生成情報によりスレッドを生成する親スレッドを再開する。
　Ｓ９９で、システムモジュール１２０は、スレッド生成情報に基づいて、子スレッドの生成を再び実行する。この処理により、スレッドを生成するのに十分な資源がある場合に、生成を保留していたスレッドを生成することができる。
　図９Ａは、実施例１に係るタスクの第１の例を示す。
　図９Ａは、マップ・リデュースジョブ＃１（図１Ａのジョブ実行プランに対応）のマッププロセス＃１１１のマップタスク＃１１１１を示している。ここで、入力データセット＃１の＃１００１のレコードには、入力データセット＃２の＃２００１～＃２０１０までの１０個のレコードに対する参照が含まれているものとする。また、マップタスク＃１１１１は、入力データセット＃１の＃１００１のレコードを取得し、入力データセット＃２のレコードを取得するものとする。
　計算ノード１００が、マップタスク＃１１１１を実行すると、入力データセット＃１の＃１００１のレコードを参照し、当該レコードが所定の条件を満たしているとすると、当該レコードに含まれている参照を用いて、入力データセット＃２の＃２００１～＃２０１０のレコードを取得する。
　図９Ｂは、第１の例に示すタスクにおけるスレッドの生成の一例を示す。図９Ｂは、図９Ａに示すタスク＃１１１１を実行する際において、図８Ｈに示す資源制約管理処理を行わない場合におけるスレッドの生成を示している。なお、図９Ｂの表記は、次のルールに従う。
（＊）横軸は、時刻を表す。
（＊）図中の横に長い角丸四角形は、１つのスレッドによる一連の処理を意味する。角丸四角形の左端はスレッドによる処理を開始する時刻を表し、角丸四角形の右端は当該スレッドによる処理を終了する時刻を表す。
（＊）角丸四角形の内部の値は、スレッドに対応した処理に伴って読み込まれるレコードを示す情報（例えば、レコードＩＤ）を表す。
（＊）レコードを取得するスレッドについての同時に実行可能なスレッド数は、「８」とする。
　図８Ｈに示す資源制約管理処理を行わない場合においては、入力データセット＃１の＃１００１のレコードを取得して処理を行うスレッド１０ａが実行されると、スレッド１０ａにより、＃１００１のレコードが取得され、当該＃１００１のレコードに含まれている参照に基づいて、入力データセット＃２の＃２００１のレコードを取得して処理を行うスレッド１０ｂが生成されて実行され、入力データセット＃２の＃２００２のレコードを取得して処理を行うスレッド１０ｃが生成されて実行され、同様にして、スレッド１０ｄ、スレッド１０ｅ、スレッド１０ｆ、スレッド１０ｇ、スレッド１０ｈが生成されて実行される。この時点においては、同時に実行可能なスレッド数である「８」と同数のスレッドが実行されることとなる。
　この後、更に、スレッド１０ａにより、入力データセット＃２の＃２００８のレコードを取得して処理を行うスレッド１０ｉ、入力データセット＃２の＃２００９のレコードを取得して処理を行うスレッド１０ｊ、及び入力データセット＃２の＃２０１０のレコードを取得して処理を行うスレッド１０ｋが生成されて実行されることとなる。利用可能な量の主記憶を超えて主記憶の割り当てが行われ、スラッシングが発生してしまい、結果としてこれらスレッドに対する実行時間が長時間となってしまう。
　図９Ｃは、実施例１に係る第１の例に示すタスクにおけるスレッドの生成の一例を示す。図９Ｃは、図９Ａに示すタスク＃１１１１を実行する際において、図８Ｈに示す資源制約管理処理を行う場合におけるスレッドの生成を示している。なお、図９Ｃの表記は、図９Ｂのルールと同様である。
　計算ノード１００において、入力データセット＃１の＃１００１のレコードを取得して処理を行うスレッド１０ａが実行されると、スレッド１０ａにより、＃１００１のレコードが取得され、当該＃１００１のレコードに含まれている参照に基づいて、入力データセット＃２の＃２００１のレコードを取得して処理を行うスレッド１０ｂが生成されて実行され、入力データセット＃２の＃２００２のレコードを取得して処理を行うスレッド１０ｃが生成されて実行され、同様にして、スレッド１０ｄ、スレッド１０ｅ、スレッド１０ｆ、スレッド１０ｇ、スレッド１０ｈが生成されて実行される。この時点においては、同時に実行可能なスレッド数である「８」と同数のスレッドが実行されることとなる。
　この後、資源制約管理処理のステップＳ９０で十分な資源がないと判定されるので、スレッド１０ａは、新たなスレッドを生成することなく、自スレッドが保留状態となる。そして、スレッド１０ｂの実行が終了した場合には、新たに１つのスレッドが実行可能となるので、ステップＳ９８でスレッド１０ａの実行が再開されて、ステップＳ９９で入力データセット＃２の＃２００８のレコードを取得して処理を行うスレッド１０ｉが生成される。同様にして、スレッド１０ｃの実行が終了した場合には、スレッド１０ａの実行が再開されて、入力データセット＃２の＃２００９のレコードを取得して処理を行うスレッド１０ｊが生成されて実行され、スレッド１０ｄの実行が終了した場合には、スレッド１０ａの実行が再開されて、入力データセット＃２の＃２０１０のレコードを取得して処理を行うスレッド１０ｋが生成されて実行される。
　この結果、複数のスレッドの実行時に、利用可能な主記憶の量の範囲内で主記憶を割り当てることが可能となり、スラッシングが発生することを防止でき、タスク全体の実行時間を、図９Ｂに示す場合と比較して、短縮することができる。
　次に、複数のタスクが並行して実行される場合におけるスレッドの生成について説明する。
　図９Ｄは、実施例２に係るタスクの第２の例を示す。
　図９Ｄは、マップ・リデュースジョブ＃１のマッププロセス＃１１１のマップタスク＃１１１１と、マップ・リデュースジョブ＃２のマッププロセス＃２１１のマップタスク＃２１１１とを示している。マップタスク＃１１１１と、マップタスク＃２１１１とは、並行して実行されるものとする。
　入力データセット＃１の＃１００１のレコードには、入力データセット＃２の＃２００１～＃２０１０までの１０個のレコードに対する参照が含まれているものとする。また、マップタスク＃１１１１は、入力データセット＃１の＃１００１のレコードを取得し、このレコードに対応する入力データセット＃２のデータを取得するものとする。
　システムモジュール１２０は、マップタスク＃１１１１を実行すると、入力データセット＃１の＃１００１のレコードを参照し、当該レコードが所定の条件を満たしているとすると、当該レコードに含まれている参照を用いて、入力データセット＃２の＃２００１～＃２０１０のレコードを取得する。
　また、入力データセット＃５の＃５００１のレコードには、入力データセット＃６の＃６００１～＃６０１０までの１０個のレコードに対する参照が含まれているものとする。また、マップタスク＃２１１１は、入力データセット＃５の＃５００１のレコードを取得し、このレコードに対応する入力データセット＃６のレコードを取得するものとする。
　システムモジュール１２０は、マップタスク＃２１１１を実行すると、入力データセット＃５の＃５００１のレコードを参照し、当該レコードが所定の条件を満たしているとすると、当該レコードに含まれている参照を用いて、入力データセット＃６の＃６００１～＃６０１０のレコードを取得する。
　図９Ｅは、実施例１に係る第２の例に示すタスクにおけるスレッドの生成の一例を示す。図９Ｅは、図９Ｄに示すタスク＃１１１１と、タスク＃２１１１とを並行して実行する際において、図８Ｈに示す資源制約管理処理を行う場合におけるスレッドの生成を示している。ここで、タスク＃１１１１で利用可能な主記憶の領域は、５スレッド分であり、タスク＃２１１１で利用可能な主記憶の領域は、３スレッド分であるとする。なお、図９Ｅの表記は、図９Ｂのルールと同様である。
　計算ノード１００において、入力データセット＃１の＃１００１のレコードを取得して処理を行うスレッド１１ａが実行されると、スレッド１１ａにより、＃１００１のレコードが取得され、当該＃１００１のレコードに含まれている参照に基づいて、入力データセット＃２の＃２００１のレコードを取得して処理を行うスレッド１１ｂが生成されて実行され、入力データセット＃２の＃２００２のレコードを取得して処理を行うスレッド１１ｃが生成されて実行され、同様にして、スレッド１０ｄ、スレッド１０ｅが生成されて実行される。この時点においては、タスク＃１１１１で利用可能な主記憶の５スレッド分の領域が使用されることとなる。
　この後、資源制約管理処理のステップＳ９０で十分な資源がないと判定されるので、スレッド１１ａは、新たなスレッドを生成することなく、自スレッドが保留状態となる。そして、スレッド１１ｂの実行が終了した場合には、新たに１つのスレッドが実行可能となるので、ステップＳ９８でスレッド１１ａの実行が再開されて、ステップＳ９９で入力データセット＃２の＃２００５のレコードを取得して処理を行うスレッド１１ｆが生成される。同様にして、スレッド１１ｃの実行が終了した場合には、スレッド１１ａの実行が再開されて、入力データセット＃２の＃２００６のレコードを取得して処理を行うスレッド１１ｇが生成されて実行され、スレッド１１ｄの実行が終了した場合には、スレッド１１ａの実行が再開されて、入力データセット＃２の＃２００７のレコードを取得して処理を行うスレッド１１ｈが生成され、スレッド１１ｄの実行が終了した場合には、スレッド１１ａの実行が再開されて、入力データセット＃２の＃２００８のレコードを取得して処理を行うスレッド１１ｉが生成され、スレッド１１ｆの実行が終了した場合には、スレッド１１ａの実行が再開されて、入力データセット＃２の＃２００９のレコードを取得して処理を行うスレッド１１ｊが生成され、スレッド１１ｇの実行が終了した場合には、スレッド１１ａの実行が再開されて、入力データセット＃２の＃２０１０のレコードを取得して処理を行うスレッド１１ｋが生成される。
　一方、入力データセット＃５の＃５００１のレコードを取得して処理を行うスレッド１２ａが並行して実行されると、スレッド１２ａにより、＃５００１のレコードが取得され、当該＃５００１のレコードに含まれている参照に基づいて、入力データセット＃６の＃６００１のレコードを取得して処理を行うスレッド１２ｂが生成されて実行され、入力データセット＃６の＃６００２のレコードを取得して処理を行うスレッド１２ｃが生成されて実行される。この時点においては、タスク＃２１１１に利用可能な主記憶の３スレッド分の領域が使用されることとなる。
　この後、資源制約管理処理のステップＳ９０で十分な資源がないと判定されるので、スレッド１２ａは、新たなスレッドを生成することなく、自スレッドが保留状態となる。そして、スレッド１２ｂの実行が終了した場合には、新たに１つのスレッドが実行可能となるので、ステップＳ９８でスレッド１２ａの実行が再開されて、ステップＳ９９で入力データセット＃６の＃６００３のレコードを取得して処理を行うスレッド１２ｄが生成される。同様にして、スレッド１２ｃの実行が終了した場合には、入力データセット＃６の＃６００４のレコードを取得して処理を行うスレッド１２eが生成され、スレッド１２ｄの実行が終了した場合には、入力データセット＃６の＃６００５のレコードを取得して処理を行うスレッド１２ｆが生成され、スレッド１２ｅの実行が終了した場合には、入力データセット＃６の＃６００６のレコードを取得して処理を行うスレッド１２ｇが生成され、スレッド１２ｆの実行が終了した場合には、入力データセット＃６の＃６００７のレコードを取得して処理を行うスレッド１２ｈが生成され、スレッド１２ｇの実行が終了した場合には、入力データセット＃６の＃６００８のレコードを取得して処理を行うスレッド１２ｉが生成され、スレッド１２ｈの実行が終了した場合には、入力データセット＃６の＃６００９のレコードを取得して処理を行うスレッド１２ｊが生成され、スレッド１２ｉの実行が終了した場合には、入力データセット＃６の＃６０１０のレコードを取得して処理を行うスレッド１２ｋが生成される。このように、複数のタスクを並行して実行させることができる。
　この結果、複数のタスクにおいて複数のスレッドの実行時に、各々のタスクで利用可能な主記憶の量の範囲内で主記憶を割り当てることが可能となり、スラッシングが発生することを防止でき、タスク全体の実行時間がスラッシングにより長時間化することを防ぐことができる。
　上記では、資源の制約として、スレッド数、主記憶の例を示したが、本発明はこの例に限定されるものではない。例えば、プロセッサ実行時間、ストレージとの入出力スループット、ネットワークの伝送スループット等に関しても、同様に資源の制約を行うことにより、同様の効果を期待することができる。
　以上、幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
　並列データ処理を実行する際に動的に生成するスレッドとしては、多様な実装形態が考えられ、例えば、プロセスであってもよいし、カーネルレベルのスレッド（ネイティブＰＯＳＩＸスレッドや軽量プロセス等、オペレーティングシステムのカーネルが管理するスレッド）であってもよいし、ユーザレベルのスレッド（ファイバ等のユーザプログラムやライブラリが管理するスレッド）であってもよいし、他と並行して実行することができるように管理される一定の手続きの集まり（例えば、関数ポインタを適当な構造体で管理するもの）であってもよいし、これらを組み合わせたものであってもよい。
　本明細書では、並列データ処理が扱うデータの単位をレコードとしているが、レコードは任意のデータであってよい。例えば、一定個数のカラムの集まりであってもよいし、可変個数のカラムの集まりであってもよいし、単なるテキストであってもよいし、バイト列であってもよいし、画像や音声等のマルチメディアコンテンツであってもよいし、これらの集まりであってもよい。
　１００…計算ノード、１１０…アプリケーション、１２０…システムモジュール

Claims (17)

  1. 　複数の計算機で並行してデータ処理を実行する計算機システムにおける１つの計算機が有する並列データ処理システムであって、
    　複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群からデータを読み込んで処理を実行する並列データ処理実行部
    を有し、
    　前記並列データ処理実行部は、
    　（Ａ）前記第１データ群から、前記第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、前記第１データから第１の値を取得し、
    　（Ｂ）前記アプリケーションから取得した第１参照情報に基づき、前記第１の値に対応する１以上の前記第２データのそれぞれを前記第２データ群から読み込むための１以上のスレッドを生成し、
    　（Ｃ）前記（Ａ）～前記（Ｂ）を、前記第１データ群の１以上の第１データに対して実行し、
    　（Ｄ）複数の前記スレッドを並行して実行する
    　並列データ処理システム。
  2. 　前記並列データ処理実行部は、
    　（Ｅ）前記（Ｄ）でスレッドを実行することにより前記第２データを読み込み、アプリケーションから取得した第２書式情報に基づいて、前記第２データから第２の値を取得する
    請求項１に記載の並列データ処理システム。
  3. 　前記並列データ処理実行部は、
    　前記第２の値により、前記アプリケーションから取得した第２条件を評価する
    請求項２に記載の並列データ処理システム。
  4. 　前記並列データ処理実行部は、
    　１つ以上の前記第２データから取得した前記第２の値から、出力データを生成する
    請求項２に記載の並列データ処理システム。
  5. 　前記並列データ処理実行部は、
    　前記第１の値により、前記アプリケーションから取得した第１条件を評価し、当該第１条件が満たされる場合に前記（Ｂ）を実行する
    請求項１に記載の並列データ処理システム。
  6. 　前記第１参照情報は、前記第２データ群において前記第２データが格納されている物理的な位置を特定する情報を含む
    請求項１に記載の並列データ処理システム。
  7. 　前記第１参照情報は、前記第２データ群において前記第２データを検索するための情報を含む
    請求項１に記載の並列データ処理システム。
  8. 　前記第２データ群の少なくとも一部の第２データは、ネットワークを介して接続される別の計算機の記憶装置に格納されており、
    　前記並列データ処理実行部は、
    　前記スレッドを実行して、前記ネットワークを介して接続された前記別の計算機から前記第２データを取得する際に、前記別の計算機に対して、取得要求を送信して、前記記憶デバイスから前記第２データを取得する
    請求項１に記載の並列データ処理システム。
  9. 　前記並列データ処理実行部は、
    　複数のスレッドの実行により生成される同一の計算機に対する複数の取得要求を１つにまとめたブロック化取得要求を前記別の計算機に送信することにより、複数の前記第２データを取得する
    請求項８に記載の並列データ処理システム。
  10. 　前記第１書式情報は、プログラムコードであり、
    　前記並列データ処理実行部は、
    　ユーザから所定のマークアップ言語で記述される第１書式情報の作成に必要なカタログ情報を受け付け、
    　前記カタログ情報に基づいて、前記第１書式情報を作成する
    請求項１に記載の並列データ処理システム。
  11. 　前記並列データ処理実行部は、前記並列データ処理実行部を有する計算機におけるスレッドの生成に関する資源制約情報に基づいて、新たなスレッドを生成すると、自身を構成する前記計算ノードにおけるスレッドの実行に利用される資源量が制約を超えると判断した場合には、前記スレッドの生成を保留する
    請求項１に記載の並列データ処理システム。
  12. 　前記並列データ処理実行部は、並列データ処理における一部の段階を担当するプロセスにおけるスレッドの生成に関する資源制約情報に基づいて、新たなスレッドを生成すると、前記プロセスにおけるスレッドの実行に利用される資源量が制約を超える場合には、当該スレッドの生成を保留する
    請求項１に記載の並列データ処理システム。
  13. 　処理の指示をアプリケーションから受け付ける受付部を更に有し、
    　前記アプリケーションからの前記指示は、手続を規定しており、
    　前記並列データ処理実行部は、前記指示を受けて、前記（Ａ）乃至（Ｄ）を実行することにより、前記指示が、前記手続を規定していても、前記手続に依存しない非順序の処理を実行する、
    請求項１に記載の並列データ処理システム。
  14. 　複数の計算機で並行してデータ処理を実行する計算機システムにおける計算機であって、
    　前記計算機システムにおける別の計算機と通信するための通信インタフェースデバイスと、
    　前記通信インタフェースデバイスに接続されており、複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群からデータを読み込んで処理を実行する制御デバイスと
    を有し、
    　前記制御デバイスは、
    　（Ａ）前記第１データ群から、前記第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、前記第１データから第１の値を取得し、
    　（Ｂ）前記アプリケーションから取得した第１参照情報に基づき、前記第１の値に対応する１以上の前記第２データのそれぞれを前記第２データ群から読み込むための１以上のスレッドを生成し、
    　（Ｃ）前記（Ａ）～前記（Ｂ）を、前記第１データ群の１以上の第１データに対して実行し、
    　（Ｄ）複数の前記スレッドを並行して実行する
    計算機。
  15. 　複数の計算機で並行してデータ処理を実行する計算機システムでの並列データ処理方法であって、
    　（Ａ）複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群のうちの前記第１データ群から、前記第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、前記第１データから第１の値を取得し、
    　（Ｂ）前記アプリケーションから取得した第１参照情報に基づき、前記第１の値に対応する１以上の前記第２データのそれぞれを前記第２データ群から読み込むための１以上のスレッドを生成し、
    　（Ｃ）前記（Ａ）～前記（Ｂ）を、前記第１データ群の１以上の第１データに対して実行し、
    　（Ｄ）複数の前記スレッドを並行して実行する
    並列データ処理方法。
  16. 　複数の計算機を有し、
    　各計算機が、
    　複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群からデータを読み込んで処理を実行する並列データ処理システム
    を有し、
    　各計算機の並列データ処理システムは、
    　（Ａ）前記第１データ群から、前記第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、前記第１データから第１の値を取得し、
    　（Ｂ）前記アプリケーションから取得した第１参照情報に基づき、前記第１の値に対応する１以上の前記第２データのそれぞれを前記第２データ群から読み込むための１以上のスレッドを生成し、
    　（Ｃ）前記（Ａ）～前記（Ｂ）を、前記第１データ群の１以上の第１データに対して実行し、
    　（Ｄ）複数の前記スレッドを並行して実行する
    計算機システム。
  17. 　複数の計算機で並行してデータ処理を実行する計算機システムでの計算機が実行するコンピュータプログラムであって、
    　（Ａ）複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群のうちの前記第１データ群から、前記第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、前記第１データから第１の値を取得し、
    　（Ｂ）前記アプリケーションから取得した第１参照情報に基づき、前記第１の値に対応する１以上の前記第２データのそれぞれを前記第２データ群から読み込むための１以上のスレッドを生成し、
    　（Ｃ）前記（Ａ）～前記（Ｂ）を、前記第１データ群の１以上の第１データに対して実行し、
    　（Ｄ）複数の前記スレッドを並行して実行する
    ことを前記計算機に実行させるコンピュータプログラム。
PCT/JP2012/064149 2012-05-31 2012-05-31 並列データ処理システム、計算機および並列データ処理方法 WO2013179451A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US14/404,550 US9841989B2 (en) 2012-05-31 2012-05-31 Parallel data processing system, computer, and parallel data processing method
EP12878202.6A EP2857975A4 (en) 2012-05-31 2012-05-31 PARALLEL DATA PROCESSING SYSTEM, COMPUTER, AND METHOD FOR PARALLEL DATA PROCESSING
JP2014518181A JP5881025B2 (ja) 2012-05-31 2012-05-31 並列データ処理システム、計算機および並列データ処理方法
PCT/JP2012/064149 WO2013179451A1 (ja) 2012-05-31 2012-05-31 並列データ処理システム、計算機および並列データ処理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/064149 WO2013179451A1 (ja) 2012-05-31 2012-05-31 並列データ処理システム、計算機および並列データ処理方法

Publications (1)

Publication Number Publication Date
WO2013179451A1 true WO2013179451A1 (ja) 2013-12-05

Family

ID=49672705

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/064149 WO2013179451A1 (ja) 2012-05-31 2012-05-31 並列データ処理システム、計算機および並列データ処理方法

Country Status (4)

Country Link
US (1) US9841989B2 (ja)
EP (1) EP2857975A4 (ja)
JP (1) JP5881025B2 (ja)
WO (1) WO2013179451A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015157338A1 (en) * 2014-04-08 2015-10-15 RedPoint Global Inc. Data transformation system and method
CN111651489A (zh) * 2020-06-05 2020-09-11 厦门理工学院 一种大数据处理服务器系统

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9501483B2 (en) 2012-09-18 2016-11-22 Mapr Technologies, Inc. Table format for map reduce system
JP5939123B2 (ja) * 2012-10-09 2016-06-22 富士通株式会社 実行制御プログラム、実行制御方法および情報処理装置
US10114674B2 (en) * 2014-03-06 2018-10-30 International Business Machines Corporation Sorting database collections for parallel processing
CN107329846B (zh) * 2017-07-11 2020-06-12 深圳市信义科技有限公司 基于大数据技术的大指数据比对方法
US10489348B2 (en) 2017-07-17 2019-11-26 Alteryx, Inc. Performing hash joins using parallel processing
US10552452B2 (en) * 2017-10-16 2020-02-04 Alteryx, Inc. Asynchronously processing sequential data blocks
US10558364B2 (en) 2017-10-16 2020-02-11 Alteryx, Inc. Memory allocation in a data analytics system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010092222A (ja) * 2008-10-07 2010-04-22 Internatl Business Mach Corp <Ibm> 更新頻度に基づくキャッシュ機構
US7756919B1 (en) 2004-06-18 2010-07-13 Google Inc. Large-scale data processing in a distributed and parallel processing enviornment
JP2011170774A (ja) * 2010-02-22 2011-09-01 Nippon Telegr & Teleph Corp <Ntt> 決定木生成装置、決定木生成方法、及びプログラム
WO2012049794A1 (ja) * 2010-10-14 2012-04-19 日本電気株式会社 分散処理装置及び分散処理システム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070198979A1 (en) * 2006-02-22 2007-08-23 David Dice Methods and apparatus to implement parallel transactions
US9170848B1 (en) * 2010-07-27 2015-10-27 Google Inc. Parallel processing of data
US8782053B2 (en) * 2011-03-06 2014-07-15 Happy Cloud Inc. Data streaming for interactive decision-oriented software applications
US9720708B2 (en) * 2011-08-19 2017-08-01 Advanced Micro Devices, Inc. Data layout transformation for workload distribution

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7756919B1 (en) 2004-06-18 2010-07-13 Google Inc. Large-scale data processing in a distributed and parallel processing enviornment
JP2010092222A (ja) * 2008-10-07 2010-04-22 Internatl Business Mach Corp <Ibm> 更新頻度に基づくキャッシュ機構
JP2011170774A (ja) * 2010-02-22 2011-09-01 Nippon Telegr & Teleph Corp <Ntt> 決定木生成装置、決定木生成方法、及びプログラム
WO2012049794A1 (ja) * 2010-10-14 2012-04-19 日本電気株式会社 分散処理装置及び分散処理システム

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
JEFFREY DEAN; SANJAY GHEMAWAT: "MapReduce: Simplified Data Processing on Large Clusters", PROCEEDINGS OF OSDI 2004, 2004, pages 137 - 15
MICHAEL ISARD; MIHAI BUDIU; YUAN YU; ANDREW BIRRELL; DENNIS FETTERLY: "Dryad: distributed data-parallel programs from sequential building blocks", PROCEEDINGS OF EUROSYS, 2007, pages 59 - 72
See also references of EP2857975A4
TAKANORI UEDA ET AL.: "QueueLinker: A Distributed Framework for Pipelined Applications", DAI 2 KAI FORUM ON DATA ENGINEERING AND INFORMATION MANAGEMENT -DEIM 2010- RONBUNSHU, 25 May 2010 (2010-05-25), XP055179049, Retrieved from the Internet <URL:http://db-event.jpn.org/deim2010/proceedings/files/E1-3.pdf> [retrieved on 20120802] *
VINAYAK R. BORKAR; MICHAEL J. CAREY; RAMAN GROVER; NICOLA ONOSE; RARES VERNICA: "Hyracks: A flexible and extensible foundation for data-intensive computing", PROCEEDINGS OF ICDE 2011, 2011, pages 1151 - 1162, XP031868515, DOI: doi:10.1109/ICDE.2011.5767921

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015157338A1 (en) * 2014-04-08 2015-10-15 RedPoint Global Inc. Data transformation system and method
CN111651489A (zh) * 2020-06-05 2020-09-11 厦门理工学院 一种大数据处理服务器系统

Also Published As

Publication number Publication date
EP2857975A4 (en) 2016-03-02
US9841989B2 (en) 2017-12-12
JPWO2013179451A1 (ja) 2016-01-14
EP2857975A1 (en) 2015-04-08
JP5881025B2 (ja) 2016-03-09
US20150113535A1 (en) 2015-04-23

Similar Documents

Publication Publication Date Title
JP5881025B2 (ja) 並列データ処理システム、計算機および並列データ処理方法
Padhy Big data processing with Hadoop-MapReduce in cloud systems
Abbasi et al. Extending i/o through high performance data services
US20200034484A1 (en) User-defined analysis of distributed metadata
Sim et al. Analyzethis: an analysis workflow-aware storage system
Skiadopoulos et al. DBOS: a DBMS-oriented Operating System
KR101765725B1 (ko) 대용량 방송용 빅데이터 분산 병렬처리를 위한 동적 디바이스 연결 시스템 및 방법
Aggarwal et al. Small files’ problem in Hadoop: A systematic literature review
Shan et al. KubeAdaptor: a docking framework for workflow containerization on Kubernetes
Sundarakumar et al. A comprehensive study and review of tuning the performance on database scalability in big data analytics
Salehian et al. Comparison of spark resource managers and distributed file systems
Fukutomi et al. GPUhd: Augmenting YARN with GPU resource management
KR100983479B1 (ko) 분산 스페이스를 이용하여 분산 프로그래밍 환경을 제공하기 위한 방법, 시스템 및 컴퓨터 판독 가능한 기록 매체
JP6097910B2 (ja) 並列データ処理システム、計算機および並列データ処理方法
Al-Kiswany et al. A cross-layer optimized storage system for workflow applications
Zhao et al. Gpu-accelerated cloud computing for data-intensive applications
Pan The performance comparison of hadoop and spark
JP6210501B2 (ja) データベース管理システム、計算機、データベース管理方法
CN103631648A (zh) 一种任务处理方法及系统
Ho et al. A mapreduce programming framework using message passing
Mian et al. Managing data-intensive workloads in a cloud
Kaur et al. Omr: Out-of-core mapreduce for large data sets
JP5031538B2 (ja) データ分配方法、データ分配プログラム、及び並列データベースシステム
Ludwig Research trends in high performance parallel input/output for cluster environments
Wadhwa Scalable Data Management for Object-based Storage Systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12878202

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014518181

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14404550

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2012878202

Country of ref document: EP