WO2011158387A1 - データ処理の障害回復方法、システムおよびプログラム - Google Patents

データ処理の障害回復方法、システムおよびプログラム Download PDF

Info

Publication number
WO2011158387A1
WO2011158387A1 PCT/JP2010/064288 JP2010064288W WO2011158387A1 WO 2011158387 A1 WO2011158387 A1 WO 2011158387A1 JP 2010064288 W JP2010064288 W JP 2010064288W WO 2011158387 A1 WO2011158387 A1 WO 2011158387A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
data processing
recovery
execution state
failure recovery
Prior art date
Application number
PCT/JP2010/064288
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 US13/701,847 priority Critical patent/US9037905B2/en
Publication of WO2011158387A1 publication Critical patent/WO2011158387A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data

Definitions

  • the present invention relates to a data processing failure recovery technique, and more particularly to a reproduction data storage technique required for failure recovery in stream data processing.
  • Stream data processing is attracting attention in order to analyze a large amount of continuously generated data in real time, such as automated stock trading, advanced traffic information processing, and analysis of sensor information obtained from multiple points.
  • Stream data processing is a general-purpose middleware technology that can be applied to real-time processing of various types of data. Therefore, while responding to sudden changes in the business environment that cannot be achieved by building a system for each individual project, The world data can be reflected in business in real time.
  • the principle and implementation method of this stream data processing are disclosed in Non-Patent Document 1.
  • the stream data processing is a real-time processing of a large amount of data as described above, a large amount of output data as a processing result is generated continuously. Therefore, it is required to shorten the time required for recovery from the occurrence of a failure as much as possible.
  • the execution state of the recovered server is an initial state, it is necessary to reproduce the execution state in which the execution state before the failure occurs is also reproduced on the recovered server.
  • the first method for reproducing the execution state is to back up the input stream during normal operation and re-execute the backup data on the standby server and add it to the execution state of the active server at the time of recovery.
  • the storage capacity such as a disk or memory required for backup increases, but it can be assumed that the capacity falls within a certain range for the following reason.
  • Non-Patent Document 3 For example, when an aggregation operation for calculating an average is applied to data cut out by a window operation with a time width of 1 minute, an operation for calculating a moving average for 1 minute is performed. In this example, if data continues to flow for 1 minute, the data in the window will be renewed. Therefore, the data for the most recent 1 minute is processed at the time of recovery starting from the initial state, and the same as before the occurrence of the failure. Enters the running state. As described above, in the Upstream Backup method, it is assumed that the storage capacity for backup falls within a certain range by assuming that the range of data to be retained advances to the future as the processing proceeds. it can.
  • the following methods exist as the second method for reproducing the execution state.
  • the server in operation is periodically suspended to make the execution state static, and the execution state is saved as a replica (snapshot). Then, the execution state is reproduced from the snapshot saved when the failure occurs and is recovered.
  • the method of storing a snapshot after quiescing is a method widely used in databases and transaction systems.
  • a reproduction method using staticization in an in-memory database is disclosed in Patent Document 1.
  • the starting point of the data range to be retained does not advance, so that the storage capacity necessary for retaining the data increases without limit and eventually overflows.
  • the problem to be solved by the present invention is to realize the use of all window operations, not limited to the time window, while minimizing the storage capacity necessary for acquiring backup data in reproducing the execution state of stream data processing. It is.
  • an object of the present invention is to provide a data processing failure recovery method, system, and program capable of solving the above-described problems.
  • a failure recovery method for stream data processing using a computer wherein the computer is a recovery point for each of the operators holding the execution state among the operators constituting the stream data processing.
  • the capacity of the stream data from the earliest time of the operator holding the execution state having the recovery point after the recovery point, and the duplication of the operator holding the execution state having the recovery point before the recovery point Provides a recovery method for stream data processing that acquires the data capacity, calculates the recovery point that minimizes the sum of the stream data capacity and the replicated data capacity, and records the stream data and the replicated data at the calculated recovery point To do.
  • a stream data processing failure recovery system is executed by a computer including a processing unit and a storage unit, and the processing unit of the computer corresponds to a query.
  • the operator that holds the execution state the query analysis unit that analyzes the recovery point, and the recovery point that is later than the recovery point based on each recovery point that is analyzed by the query analysis unit
  • a backup data management unit to provide a fault recovery system for recording an execution state of the stream data processing in the storage unit in the determined recovery point.
  • a failure recovery program executed by a processing unit of a computer that executes stream data processing based on a query, the processing unit including stream data processing corresponding to the query.
  • the processing unit including stream data processing corresponding to the query.
  • the execution state is reproduced by the following procedure in order to solve the above-mentioned problems.
  • the operator who holds the execution state of all the windows included in the stream data processing is the most necessary for reproducing the current state regardless of time, number, type, etc.
  • the time when old data is input is managed as a recovery point that can be reproduced by the Upstream Backup method.
  • an Upstream Backup method that holds backup data for the operator that holds the execution state of a window having a recovery point after that recovery point.
  • a method of obtaining a replica is used to calculate the size of the storage area required to reproduce the execution state. to manage.
  • the recovery point with the smallest capacity is selected from the sum of the storage areas necessary for reproducing the execution state at all the recovery points calculated. Then, the backup data of the stream data after the recovery point is held, and at the same time, a copy (snapshot) of the window having the recovery point before the recovery point is acquired.
  • the present invention in reproducing the execution state of stream data processing, it is possible to use an operator that holds all execution states, not limited to the time window, while minimizing the storage capacity necessary for acquiring backup data. More specifically, it is possible to select whether the storage area is smaller by comparing whether a snapshot should be acquired for each operator holding the execution state or by reproducing using the Upstream Backup method.
  • the operator includes various window operations in addition to the scan operator, the filter operator, and the like.
  • a stream data processing server 100 and computers 101, 102, 103 are connected to a network 104.
  • the stream data processing server 100 receives data 108 from the computer 102 on which the data source 107 operates via the network 104 and transmits processing result data 110 to the result use application 109 on the computer 103.
  • a query registration command execution interface 105 operates on the computer 101.
  • the stream data processing server 100 is composed of computers 200 and 210.
  • the computers 200 and 210 are memories 202 and 212 that are storage units, and a central processing unit (Central Processing Unit: CPU) that is a processing unit. ) 201 and 211, network interfaces (I / F) 204 and 214, storages 203 and 213 which are storage units, and buses 205 and 215 that couple them.
  • a stream data processing system 206 that defines a logical operation of stream data processing is arranged on the memory 202.
  • the stream data processing system 206 is an execution image that can be interpreted and executed by the CPU 201 as described in detail later.
  • computers 200 and 210 constituting the stream data processing server 100 are connected to an external network 104 via network I / Fs 204 and 214.
  • the stream data processing system When the computer 200 constituting the stream data processing server 100 receives the query 106 defined by the user via the query registration command execution interface 105 operating on the computer 101 connected to the network 104, the stream data processing system.
  • a query graph capable of executing stream data processing in accordance with this definition is configured within itself. Thereafter, when the computer 200 that constitutes the stream data processing server 100 receives the data 108 transmitted by the data source 107 operating on the computer 102 connected to the network 104, the data 108 is processed according to the query graph, and the result data 110 is processed. Is generated and transmitted to the result use application 109 operating on the computer 103.
  • the storage 203 stores the query 106 received once in addition to the stream data processing system 206.
  • the stream data processing system 206 can load this definition from the storage 203 at the time of start-up to construct a query graph.
  • the memory 212 constituting the computer 210 stores a backup storage system (BSS) 216 for recovery when a failure occurs in the stream data processing system 206.
  • BSS backup storage system
  • either or both of the memory 212 and the storage 213 constituting the computer 210 hold reproduction data 217 and 218 necessary for recovery when a failure occurs in the stream data processing system 206.
  • the configuration of the stream data processing server of this embodiment described here is an example, and the computers 200 and 210 are one computer, and the CPUs 201 and 211 as processing units are two processors on the same computer. It does not matter. Alternatively, there may be two calculation cores in one multi-core CPU. Further, the memories 202 and 212, the network I / Fs 204 and 214, and the storages 203 and 213 are each one and connected to one computer, or connected to two computers and shared. It does not matter. In this specification, the computer includes any case, and the processing unit and the storage unit are the same.
  • the query 300 is a query that defines two input streams sa and sb and three queries q1, q2, and q3.
  • the stream data processing system upon receiving the definition of the query 300, the stream data processing system generates a query graph composed of operators 400 to 410 on the query execution work area 420 secured in its execution area. .
  • This operator includes various windows 401, 404, and 408 in addition to scan operators 400 and 403, filter operators 402 and 405, a combination operator 406, a stream calculation operator 407, and the like. It is.
  • the operator 400 is a Scan operator that receives the input stream sa from the data source
  • the operator 403 is a Scan operator that receives the input stream sb from the data source.
  • Both the streams sa and sb are a series of data composed of two columns: a character string type column id and an integer type column val.
  • Operators 401, 402, 404, 405, 406, and 407 are operators that constitute a partial query graph corresponding to the query q1.
  • the operator 401 is a group distinct number window (PARTITION BY id ROWS 2) applied to the stream sa, and cuts out the latest two pieces of data by column id.
  • the operator 404 is a time window (RANGE 5 MINUTES) applied to the stream sb, and cuts out data within the last 5 minutes.
  • the operator 402 is a filter operator (sa.val> 100) applied to the data cut out in the window 401, and allows only data having a column val value greater than 100 to pass through.
  • the operator 405 is a filter operator (sb.val ⁇ -1) applied to the data cut out in the window 404, and allows data other than the value of the column val to pass through.
  • the operator 407 is a stream operation that normalizes the query result.
  • Operators 408 and 409 are an operator group constituting a partial query graph corresponding to the query q2.
  • the operator 408 is a permanent window (UNBOUNDED) and holds all the result data of the query q1.
  • the operator 409 is an aggregation operator, and sa. val and sb. The maximum value of val is calculated.
  • the operator 410 is a stream operation operator that forms a partial query graph corresponding to the query q3.
  • Temporary storage areas (Temporal Stores) 411 and 412 are areas that hold the execution states of the join operator 406 and the aggregation operator 409, respectively.
  • the temporary holding area 411 holds data that is alive in each of the left input and right input of the operator 406. These are the partners of the data that arrives at the opposite input.
  • the temporary holding area 412 holds the aggregation result data one by one for each group.
  • the window calculation is an operator that holds the execution state.
  • the lifetime is defined for each input data, and the live data is held.
  • other operators such as a filter operator, a projection operator, a stream calculation operation, and a Scan operator, it is not necessary to maintain the execution state.
  • FIG. 4 shows a state in which data 501 to 506 are held in the window calculation W1 401 and data 511 to 517 are held in the window calculation W2 404.
  • the long ellipse of each data represents the time stamp of the data
  • the left square represents the value of the column id
  • the right square represents the value of the column val.
  • the group-specific window 401 holds a maximum of two pieces of data for each column id.
  • the time window 404 holds data with time stamps from 9:55 to 9:59.
  • the temporary holding area W3 411 holds the live data 501, 503, 504, and 505 in the left input, and the live data 512, 513, 514, 516, and 517 in the right input.
  • the filter condition sa Of the data sets held in the window operation 401, the filter condition sa.
  • the filter condition sb Of the data set satisfying val> 100 and the data set held in the window operation 404, the filter condition sb. A set of data satisfying val ⁇ >-1.
  • the join condition is an equality condition related to the column id
  • the column id value is indexed as a key, and is grouped and held according to the column id value.
  • the temporary holding area W5-412 holds data obtained by grouping the data held in the window calculation 408 by grouping by column id, one for each group. Data 541, 542, and 543 are held for column ids a, b, and c, respectively.
  • the temporary holding area W5-412 can be set to hold the average value, maximum value, minimum value, etc. of each group for each column id. In the case of FIG. 5, the temporary holding area W5-412 is set to hold the maximum value.
  • the thick line block schematically shows various software functions executed by the CPU
  • the thin line block schematically shows various data storage areas formed on the memory when the software is executed.
  • a stream data processing system 206 is based on data in an input data receiving unit 601 that receives input data 108, a query execution work area 420 that holds a query graph and an execution state of an operator, and a query execution work area 420, respectively.
  • a query execution unit 602 that executes a query and an output data transmission unit 605 that outputs a query execution result 110.
  • the operator execution state holding areas 621 to 623 for holding the execution state for each operator and the operator execution state holding areas 621 to 623 are used for the internal state of each operator.
  • Operator recovery point storage areas 624 to 626 are recorded in which the recovery points indicating the time of the oldest input data and the storage amounts when these are recorded as snapshots are recorded.
  • the stream data processing system 206 includes a query analysis unit 606 that analyzes the query 106 and generates a query graph on the query execution work area.
  • the query analysis unit 606 includes a snapshot target selection unit 607 that selects an operator who acquires an execution state snapshot in the operator group on the query graph.
  • the operator group selected by the snapshot target selection unit 607 is stored in the snapshot target list storage area 608.
  • the stream data processing system 206 transmits a copy of the input data 108 received by the input data receiving unit 601 to the backup storage system 216, or receives the recovery copy input data sent from the backup storage system 216.
  • the replication data communication unit 609 that receives and transmits the input data to the input data reception unit 601, the recovery request transmission unit 610 that requests to transmit recovery data from the backup storage system 216, and the backup request transmitted from the backup storage system 216.
  • the backup notification receiving unit 611 to receive, the operator execution state and the copy buffer area 612 for temporarily storing the snapshot target list, the operator execution state and the backup storage system 216
  • a work area data communication unit 613 for transmitting and receiving a snapshot target list.
  • the query execution unit 602 copies the stored contents of the operator execution state holding areas 621 to 623 to the copy buffer area 612 according to the snapshot target list storage area 608 and the copy state to the copy buffer area 612.
  • An execution state writing unit 604 is provided for copying certain held contents to the held contents of the operator execution state holding areas 621 to 623.
  • the backup storage system 216 includes a replication data communication unit 657 that exchanges the input data 108 with the storage data processing system 206, a recovery request reception unit 658 that receives a recovery request sent from the storage data processing system 206, and backup processing.
  • the backup notification transmission unit 659 requesting the storage data processing system 206, the copy buffer area 660 for temporarily storing the operator execution state and the snapshot target list, the operator execution state and the snapshot target for the storage data processing system 206
  • a work area data communication unit 661 for transmitting and receiving the list is provided.
  • the backup storage system 216 stores an input data storage area 655 for storing the copied input data, a snapshot target list storage area 656 for storing a snapshot target list, and a snapshot storage area 654 for storing a snapshot.
  • the snapshot storage area 654 includes operator execution state storage areas 671 to 673.
  • the backup storage system 216 includes a backup data management unit 652.
  • the backup data management unit 652 includes an input data capacity management unit 653 that monitors the capacity of the input data storage area 655.
  • FIGS. 7 and 8 show an example of the backup data update processing flow in this embodiment.
  • FIG. 7 shows a flow when a backup request is transmitted from the backup storage system 216, the backup data is transmitted from the stream data processing system 206, and the backup data held by the backup storage system 216 is updated.
  • the input data capacity management unit 653 transmits a backup request to the backup notification transmission unit 659 for reasons such as “the input data capacity has reached a specified value”, “a certain time has elapsed since the previous backup”, or the like.
  • the backup notification transmission unit 659 transmits a backup request to the stream data processing system 206.
  • the stream data processing system 206 that has received the backup request by the backup notification receiving unit 611 selects the snapshot target operator from the operators holding the execution state by the snapshot target selection unit 607.
  • the snapshot and recovery point data of the operator selected by the stream data processing system 206 are transmitted to the backup storage system 216.
  • the backup storage system 216 saves the snapshot and deletes the duplicated input data before the sent recovery point.
  • FIG. 8 shows details of the above-described processing 702.
  • steps 800, 801, 812, and 813 steps 802 to 811 are repeated until the operator sequence number I reaches the number of target operators.
  • steps 800, 801, 812, and 813 steps 802 to 811 are repeated until the operator sequence number I reaches the number of target operators.
  • process 816 it is checked whether or not the operator of the operator sequence number I holds the execution state. If it is held, the recovery point I of the operator sequence number I is read from the operator recovery point storage area in step 802. Subsequently, in the process 803, the storage capacity of the input data after the recovery point I is inquired of the input data capacity management unit 653 and set as the initial value of the necessary storage capacity I.
  • process 817 it is checked whether the operator serial number J holds the execution state. If it is held, the recovery point J of the operator serial number J is read from the operator recovery point storage area in process 806. In processing 807, the recovery point I of the operator serial number I is compared with the recovery point J of the operator serial number J. If the recovery point I is closer to the current time than the recovery point J, the processing proceeds to processing 810, otherwise processing proceeds to processing 808. move on. In process 808, the operator serial number J is designated as a snapshot target when the recovery point I is selected. Subsequently, in processing 809, the storage amount of the snapshot of the operator serial number J is added to the necessary storage amount I. The processes 806 to 809 are repeated for all operator serial numbers J. This is repeated for all operator serial numbers I.
  • process 814 the smallest necessary storage capacity is selected for all operator serial numbers, and the recovery point K is determined. Subsequently, the snapshot target at the recovery point K is stored in the snapshot target list storage area 608.
  • FIG. 9 shows a query graph composed of 400 to 412 shown in FIG. 4, and the execution status of each operator shown in FIG. This is illustrated by adding the storage amount and the recovery point.
  • the storage amount indicates the number of pieces of stream data.
  • the present invention is not limited to this, and it goes without saying that the storage amount may be the storage capacity of a memory for storing each data.
  • the stream data processing system executes processing from time 6:30 and performs backup processing when the current time 950 is 10:00.
  • the storage amount 911 of W2 404 is 6, the recovery point 912 is 9:55, the storage amount 921 of W3 411 is 9, and the recovery point 922 is 9:50. Since W4 408 is a permanent window, all data sent to W4 since the start of the stream data processing system is recorded.
  • FIG. 10 shows the backup of the input data 108 recorded in the input data storage area 655 and the number of data after the recovery point of the execution state in each operator shown in FIG.
  • the data group sa1001 is a data group input to the Scan 400 and is composed of data 501 to 506, data 1020 to 1023, and the like.
  • the data group sb1002 is a data group input to the Scan 430 and is composed of data 511 to 517 and data 1030 to 1035. When this is recorded at each recovery point, when saving from 6:30 which is the recovery point 932 of W4 408, the number of stored data 1010 is 1000.
  • the number of data 1011 to be stored is 900, and in the case of 9:48 which is the recovery point 902 of W1401, the number of data 1012 is 17, recovery of W3 411
  • the point 922 is 9:50
  • the number of data 1013 is 14, and when the recovery point 912 of W2 ⁇ 404 is 9:55, the number of data 1014 is 9.
  • FIG. 11 shows a summary of the results of performing processes 800 to 813 using these pieces of information.
  • the recovery point of W2 is 9:55
  • the recovery point of W3 is 9:50
  • W1, W2, and W3 are in an execution state from backup of input data. Can be reproduced.
  • the recovery points of W4 and W5 are older than W1, they cannot be reproduced from the backup of the input data. Therefore, W4 and W5 require snapshots.
  • the necessary storage capacity 1101 in this case is 120, which is the total of the storage amounts 931 and 941 of the snapshots W4 and W5, which is the number of input data backups 1012 at the recovery point 902 of W1. If the same processing is performed, the required storage capacity 1102 at the time of W2 recovery point selection is 127, the required storage capacity 1103 of W3 is 123, the required storage capacity 1103 of W4 is 1000, and the required storage capacity 1104 of W5 is 1000.
  • FIG. 12 shows a list of recovery points and operators to be reproduced with snapshots when the recovery point of W1 having the smallest necessary storage capacity is selected by the processes 814 and 815.
  • the recovery point 1201 is the W1 recovery point 9:48
  • the operator 1202 reproduced from the backup of the input data is W1, W2, W3
  • the operator 1203 reproduced from the snapshot is W4, W5.
  • 13A and 13B respectively show a backup 1300 and a snapshot 1310 of recorded input data in this specific example.
  • the backup 1300 of the input data records data after 9:48 which is the recovery point, and the snapshot 1310 records the execution state of W4 and W5.
  • FIG. 14 is used to show a flowchart of a procedure for reproducing the execution state from the backup and snapshot of the input data to the initial stream data processing system in the present embodiment.
  • the recovery request transmission unit 610 of the stream data processing system 206 transmits a recovery request to the backup storage system 216.
  • the backup storage system 216 transmits the backup and snapshot of the input data to the stream data processing system 206.
  • the stream data processing system 206 to which the backup and snapshot of the input data are sent in the process 1402 restores the execution state before the failure.
  • processing is continued from the input data after the failure.
  • FIG. 15 shows details of the process 1402 of FIG.
  • process 1500 the backup of input data from the recovery point to the backup data acquisition time is processed by the stream data processing system 206 in the initial state.
  • steps 1501 to 1504 the execution state of the snapshot is copied to all operators who have acquired the snapshot.
  • the backup of input data from the acquisition of the backup data to immediately before the occurrence of the failure is processed by the stream data processing system 206.
  • the backup data 1300 of the input data from the recovery point of the processing 1500 to the time of backup data acquisition is input to the stream data processing system in the initial state.
  • Fig. 17 shows the result.
  • the execution state of 10:00 which is the backup data acquisition time 1750
  • W1 401, W2 404, and W3 411 that can reproduce the execution state from the backup of the input data.
  • W4 408 since W4 408 originally stores data from 6:30, the amount of data is insufficient from 9:48 data, and W5 412 stores the maximum value of data from 6:30.
  • the data 1701 to 1703 which are the maximum values from 48 are different from the original values.
  • FIG. 18 shows an example in which processing 1501 to 1504 is performed on the state of FIG.
  • the execution state For the execution state of W4 408 and W5 412 that cannot be reproduced from the backup 1300 of the input data, the execution state is copied from the snapshot 1310.
  • the execution state at the time of backup data acquisition similar to that in FIG. 9 is reproduced for all operators including W4 408 and W5 412.
  • the snapshot acquisition process may be performed automatically at regular intervals or when the input data backup capacity reaches a certain value.
  • GUI 1900 is used to check whether or not the backup data acquisition optimization function is used 1901, time 1902 at regular intervals, the limit value 1903 of the capacity of backup data, and the like. You may comprise so that it can set.
  • Reference numeral 1094 denotes an “optimization execution” button used for the user to immediately perform optimization at an arbitrary time desired.
  • the present invention relates to a failure recovery technique in stream data processing, and is particularly useful as a storage technique for reproduction data necessary for failure recovery.
  • Recovery request transmission unit 611 ... Backup notification reception unit 612, 660 ... Copy buffer area 613, 661 ... Work area data communication unit 652 ... Backup data management unit 655 ... Input data storage area 658 ... Recovery request receiving unit 659 ... Backup notification transmission units 621, 622, 623 ... Operator execution state holding areas 624, 625, 626 ... Operator recovery point recording areas 671, 672, 673 ... Operator execution state storage areas 501 to 50 511 to 517, 521 to 531, 541 to 543, 1020 to 1023, 1030 to 1035, 1701 to 1703 ... data 901, 911, 921, 931, 941 ... snapshot storage amounts 902, 912, 922, 932, 942 ... Recovery point 1300 ... input data backup 1301 ... snapshot data 1900 ... backup method setting GUI.

Abstract

　ストリームデータ処理の障害発生後の実行状態再現において、バックアップデータ取得に必要な記憶容量を最小限にとどめた上で、全てのウィンドウ演算の利用を実現する。クエリ解析部は、クエリに対応するストリームデータ処理を行うオペレータ中、ウィンドウなどの実行状態を保持するオペレータと、その回復ポイントを解析する。バックアップデータ取得時に、バックアップデータ管理部は、解析された回復ポイントのスナップショット取得に必要な容量を管理し、各々の回復ポイントまでの入力データのバックアップに必要な記憶領域の記憶容量と、それで再現できないウィンドウに対してスナップショットを取得した場合に必要な記憶領域の記憶容量を算出し、これらに必要な記憶容量の合計値が最も小さくなる回復ポイントを選択して、実行状態の記録を行う。

Description

データ処理の障害回復方法、システムおよびプログラム
　本発明は、データ処理の障害回復技術に関し、特に、ストリームデータ処理における障害回復に必要な再現データの保存技術に関する。
　自動株取引、高度な交通情報処理、多地点から得たセンサ情報の解析といった、継続的に発生する多量のデータをリアルタイムに解析し即座に対応ために、ストリームデータ処理が注目されている。ストリームデータ処理は、様々な形式のデータのリアルタイム処理に適用可能な汎用ミドルウェア技術であるため、個別案件ごとにシステムを構築するのでは間に合わないようなビジネス環境の急激な変化にも応えつつ、実世界のデータをリアルタイムにビジネスに反映することを可能とする。このストリームデータ処理の原理、実現方式は非特許文献１に開示されている。
　ストリームデータ処理は、前述のように多量のデータのリアルタイム処理であるため、処理結果の出力データも多量かつ継続的に発生することになる。従って、障害が発生してから復旧までに要する時間は、可能な限り短くすることが求められる。このとき、復旧されたサーバの実行状態は初期状態であるため、障害発生前の実行状態を復旧後のサーバにも再現する、実行状態再現が必要とされている。
　実行状態再現の一つ目の方法として、正常動作中から入力ストリームをバックアップしておき、復旧時にはバックアップデータを待機系サーバで再実行して現用系サーバの実行状態に追付かせる、Ｕｐｓｔｒｅａｍ　Ｂａｃｋｕｐ方式が非特許文献２に開示されている。処理時間が長くなるほど、バックアップに必要なディスクやメモリなどの記憶容量は増大するが、次の理由で容量は一定以内に収まることが仮定できる。
　ストリームデータ処理では、データ系列から直近の一部分を切り出すウィンドウ演算を利用することが可能である。ウィンドウ演算の定義は非特許文献３に開示されている。例えば、時間幅１分のウィンドウ演算によって切り出したデータに対して平均を算出する集約演算を適用すると、１分間の移動平均を算出する動作となる。この例においては、１分間データを流し続けるとウィンドウ内のデータが刷新されることになるため、初期状態から開始する復旧時においても直近１分間のデータを処理することで、障害発生前と同じ実行状態になる。このように、Ｕｐｓｔｒｅａｍ　Ｂａｃｋｕｐ方式においては、保持しておくべきデータの範囲が処理の進行に伴って未来に進むことを前提とすることで、バックアップのための記憶容量が一定以内に収まることを仮定できる。
　実行状態再現の二つ目の方法として、次のようなものが存在する。まず、運用中のサーバを定期的に一時停止して実行状態を静止化し、その実行状態を複製（スナップショット）として保存する。そして、障害が発生し、復旧した時に保存したスナップショットから実行状態を再現する。静止化してスナップショットを保存する方法は、データベースやトランザクションシステムで広く利用されている方法である。インメモリデータベースにおける静止化を利用した再現方法が、特許文献１に開示されている。
特開２００９－１５７７８５号公報
Ｂ．Ｂａｂｃｏｃｋ、Ｓ．Ｂａｂｕ、Ｍ．Ｄａｔａｒ、Ｒ．Ｍｏｔｗａｎｉ　ａｎｄ　Ｊ．Ｗｉｄｏｍ、"Ｍｏｄｅｌｓ　ａｎｄ　ｉｓｓｕｅｓ　ｉｎ　ｄａｔａ　ｓｔｒｅａｍ　ｓｙｓｔｅｍｓ"、Ｉｎ　Ｐｒｏｃ．　ｏｆ　ＰＯＤＳ　２００２、　ｐｐ．１－１６．（２００２） Ｊ．Ｈ．Ｈｗａｎｇ、Ｍ．Ｂａｌａｚｉｎｓｋａ、Ａ．Ｒａｓｉｎ、Ｕ．Ｃｅｔｉｎｔｅｍｅｌ、Ｍ．Ｓｔｏｎｅｂｒａｋｅｒ　ａｎｄ　Ｓ．Ｂ．Ｚｄｏｎｉｋ、"Ｈｉｇｈ－Ａｖａｉｌａｂｉｌｉｔｙ　Ａｌｇｏｒｉｔｈｍｓ　ｆｏｒ　Ｄｉｓｔｒｉｂｕｔｅｄ　Ｓｔｒｅａｍ　Ｐｒｏｃｅｓｓｉｎｇ"、Ｉｎ　Ｐｒｏｃ．　ｏｆ　ＩＣＤＥ　２００５、　ｐｐ．７７９－７９０．（２００５） Ａ．Ａｒａｓｕ、Ｓ．Ｂａｂｕ　ａｎｄ　Ｊ． Ｗｉｄｏｍ. "Ｔｈｅ　ＣＱＬ　Ｃｏｎｔｉｎｕｏｕｓ　Ｑｕｅｒｙ　Ｌａｎｇｕａｇｅ： Sｅｍａｎｔｉｃ 　Ｆｏｕｎｄａｔｉｏｎｓ　ａｎｄ　Ｑｕｅｒｙ　Ｅｘｅｃｕｔｉｏｎ"、（２００５）
　前述のＵｐｓｔｒｅａｍ　Ｂａｃｋｕｐ方式による実行状態再現において次のようの問題がある。ストリームデータ処理システムが処理するウィンドウ演算としては、前述の時間ウィンドウ（Ｒａｎｇｅウィンドウ）以外にも、個数ウィンドウ（Ｒｏｗｓウィンドウ）、グループ別個数ウィンドウ（Ｐａｒｔｉｔｉｏｎウィンドウ）、永続ウィンドウ（Ｕｎｂｏｕｎｄｅｄウィンドウ）などが存在する。時間ウィンドウとは異なり、これらのウィンドウでは時間の経過のみではウィンドウが刷新されない可能性がある。例えば、証券取引の分析において銘柄毎に直近１００件の出来高統計を算出する処理は、グループ別個数ウィンドウの利用により容易に定義できる。このとき、取引が低調な銘柄が存在すると、その銘柄の取引データがウィンドウに残り続けることになる。また、分析開始から全取引の集計を算出するといった処理は、永続ウィンドウを利用することで容易に定義できるが、同ウィンドウには処理開始以降の全てのデータが残り、全く刷新されない。
　このようなケースにＵｐｓｔｒｅａｍ　Ｂａｃｋｕｐ方式を適用すると、保持しておくべきデータ範囲の起点が進行しないため、データの保持に必要な記憶容量が際限なく増大し、いずれオーバフローすることになる。
　一方で、スナップショットを利用する実行状態再現方式では、全てのウィンドウ演算を利用可能である。但し、動作中のサーバを静止化する期間、結果の出力が停止するため、アプリケーションに対して処理の停止として影響を与えてしまうことになる。実行状態に「過去数分間に送られた全データ」といった非常にサイズの大きなものが複数含まれていた場合、スナップショットの取得に非常に大きな記憶容量を必要とする。
　本発明の解決すべき課題は、ストリームデータ処理の実行状態再現において、バックアップデータ取得に必要な記憶容量を最小限にとどめた上で、時間ウィンドウに限らず全てのウィンドウ演算の利用を実現することである。
　すなわち、本発明の目的は、上記の課題を解決できるデータ処理障害回復方法、システムおよびプログラムを提供することにある。
　上記の目的を達成するため、本発明においては、計算機を用いたストリームデータ処理の障害回復方法であって、計算機は、ストリームデータ処理を構成するオペレータ中、実行状態を保持するオペレータ各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得しストリームデータの容量と複製データの容量の合計値が最少となる回復ポイントを算出し、算出した回復ポイントにおいてストリームデータと複製データを記録するストリームデータ処理の障害回復方法を提供する。
　また、上記の目的を達成するため、本発明においては、処理部と記憶部とを備えた計算機により実行されるストリームデータ処理の障害回復システムであって、計算機の処理部は、クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、その回復ポイントを解析するクエリ解析部と、クエリ解析部が解析した、各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、各回復ポイントにおける、ストリームデータの容量と複製データの容量との合計値が最少となる回復ポイントを決定するバックアップデータ管理部とを備え、決定した回復ポイントにおいてストリームデータ処理の実行状態を記憶部に記録する障害回復システムを提供する。
　更に、上記の目的を達成するため、本発明においては、クエリに基づきストリームデータ処理を実行する計算機の処理部で実行される障害回復プログラムであって、処理部を、クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、その回復ポイントを解析し、解析した、各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、各回復ポイントにおける、ストリームデータの容量と複製データの容量との合計値が最少となる回復ポイントを決定し、決定した回復ポイントにおいてストリームデータ処理の実行状態を記録するよう動作させる障害回復プログラムを提供する。
　また更に、本発明の好適なデータ処理の障害回復方式においては、前述の課題を解決するために以下の手順で実行状態を再現する。
　（１）ストリームデータ処理の中に含まれる全てのウィンドウ等の実行状態を保持するオペレータは、時間・個数・グループ別などの種類を問わず、それぞれが現在の状態を再現するために必要な最も古いデータが入力された時刻をＵｐｓｔｒｅａｍ　Ｂａｃｋｕｐ方式で再現可能な回復ポイントとして管理する。
　（２）全てのウィンドウ等の実行状態を保持するオペレータの回復ポイント各々について、その回復ポイントより以降の回復ポイントを持つウィンドウ等の実行状態を保持するオペレータについては、バックアップデータを保持するＵｐｓｔｒｅａｍ　Ｂａｃｋｕｐ方式、その回復ポイントより前の回復ポイントを持つウィンドウ等の実行状態を保持するオペレータについては複製（スナップショット）を取得する方式で、実行状態を再現するために必要な記憶領域の大きさを計算し管理する。
　（３）計算した全ての回復ポイントにおける実行状態再現に必要な記憶領域の総和の中で、容量がもっとも小さい回復ポイントを選択する。そして、その回復ポイント以降のストリームデータのバックアップデータを保持すると同時に、その回復ポイントより前の回復ポイントを持つウィンドウの複製（スナップショット）を取得する。
　（４）障害回復のための実行状態再現時において、まず当該回復ポイントからデータを流し込み、その部分の処理が終わったら複製（スナップショット）のあるウィンドウはスナップショットからデータを上書きし、その後にバックアップデータ取得後のストリームの処理を始める。
　本発明により、ストリームデータ処理の実行状態再現において、バックアップデータ取得に必要な記憶容量を最小限にとどめた上で、時間ウィンドウに限らず全ての実行状態を保持するオペレータが利用可能となる。より具体的には、実行状態を保持するオペレータンごとにスナップショットを取得すべきかＵｐｓｔｒｅａｍ　Ｂａｃｋｕｐ方式により再現するかを比較し、より記憶領域が小さくなる方を選択することが可能となる。
第１の実施例のストリームデータ処理サーバが利用される計算機環境の構成を示す図である。 第１の実施例のストリームデータ処理サーバの構成の一例を示す図である。 第１の実施例に係る、データ処理定義の一例を示す図である。 図３に示すデータ処理定義をクエリグラフに変換した結果を示す図である。 第１の実施例に係る、図４に示すクエリグラフの例における、実行状態の例を示す図である。 第１の実施例に係る、ストリームデータ処理における実行状態記録方式の例を示す図である。 第１の実施例に係る、バックアップ要求がされた際の動作を示すフローチャートを示す図である。 第１の実施例に係る、スナップショット対象の選定がされる際の動作を示すフローチャートを示す図である。 第１の実施例に係る、バックアップデータ取得時刻における各オペレータの実行状態と記憶量、回復ポイントを例示する図である。 第１の実施例に係る、ストリームデータ処理システム起動直後からバックアップデータ取得時刻までの入力データと各オペレータの回復ポイント時のデータ量を例示する図である。 第１の実施例に係る、各オペレータの回復ポイント選択時のバックアップに必要な記憶容量の一覧を例示する図である。 第１の実施例に係る、選択された回復ポイントと入力データから実行状態を再現するオペレータとスナップショットから実行状態を再現するオペレータのリストを例示する図である。 第１の実施例に係る、再現用のバックアップデータを例示する図である。 第１の実施例に係る、再現用のバックアップデータを例示する図である。 第１の実施例に係る、ストリームデータ処理システムにより復旧要求がされた場合の動作を示すフローチャートを示す図である。 第１の実施例に係る、復旧要求時にストリームデータ処理システムの実行状態をバックアップデータから再現する動作を示すフローチャートを示す図である。 第１の実施例に係る、初期状態のストリームデータ処理システムに対して入力データのバックアップを処理させる動作を例示する図である。 第１の実施例に係る、入力データのバックアップを処理した後の実行状態を例示する図である。 第１の実施例に係る、入力データのバックアップ後にスナップショットをコピーする動作を例示する図である。 第１の実施例に係る、バックアップデータ取得におけるパラメータを設定するＧＵＩを例示する図である。
　以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。また、後で説明するように、本明細書において、オペレータには、Ｓｃａｎオペレータ、フィルタオペレータ等に加え、各種のウィンドウ演算も含まるので、留意されたい。
　まず、図１および図２を用いて、第１の実施例に係る、ストリームデータ処理システムの基本構成を説明する。
　図１に示すように、ネットワーク１０４にストリームデータ処理サーバ１００と計算機１０１、１０２、１０３が接続されている。ストリームデータ処理サーバ１００は、ネットワーク１０４を介して、データソース１０７が動作する計算機１０２からデータ１０８を受け取り、処理結果のデータ１１０を計算機１０３上の結果利用アプリケーション１０９に送信する。また、計算機１０１上では、クエリ登録コマンド実行インタフェース１０５が動作する。
　図２に示すように、ストリームデータ処理サーバ１００は、計算機２００および２１０から構成され、計算機２００および２１０は、記憶部であるメモリ２０２および２１２、処理部である中央処理部（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ：ＣＰＵ）２０１および２１１、ネットワークインタフェース（Ｉｎｔｅｒｆａｃｅ：Ｉ／Ｆ）２０４および２１４、記憶部であるストレージ２０３および２１３、およびそれらを結合するバス２０５および２１５によって構成される。メモリ２０２上に、ストリームデータ処理の論理動作を定義する、ストリームデータ処理システム２０６を配置する。ストリームデータ処理システム２０６は、後で詳述するようにＣＰＵ２０１によって解釈実行可能な実行イメージである。
　図２に示すように、ストリームデータ処理サーバ１００を構成する計算機２００および２１０は、ネットワークＩ／Ｆ２０４および２１４を介して外部のネットワーク１０４に接続される。
　ネットワーク１０４に接続された計算機１０１上で動作する、クエリ登録コマンド実行インタフェース１０５を介して、ユーザによって定義されたクエリ１０６を、ストリームデータ処理サーバ１００を構成する計算機２００が受取ると、ストリームデータ処理システム２０６は、この定義に従ってストリームデータ処理を実行可能なクエリグラフを自身の内部に構成する。この後、ネットワーク１０４に接続された計算機１０２上で動作するデータソース１０７によって送信されるデータ１０８を、ストリームデータ処理サーバ１００を構成する計算機２００が受取ると、このクエリグラフに従って処理し、結果データ１１０を生成し、計算機１０３上で動作する結果利用アプリケーション１０９に送信する。ストレージ２０３は、ストリームデータ処理システム２０６の他、一度受取ったクエリ１０６を保存する。ストリームデータ処理システム２０６は、起動時にストレージ２０３からこの定義をロードし、クエリグラフを構成することも可能である。
　計算機２１０を構成するメモリ２１２には、ストリームデータ処理システム２０６に不具合が発生した際の復旧用にバックアップ用ストレージシステム（ＢＳＳ）２１６が記憶されている。また、計算機２１０を構成するメモリ２１２およびストレージ２１３のいずれかもしくは双方は、ストリームデータ処理システム２０６に不具合が発生した際に復旧させるために必要な再現用データ２１７および２１８を保持している。
　なお、ここで説明した本実施例のストリームデータ処理サーバの構成は一例であり、計算機２００と２１０は一台の計算機であって、処理部であるＣＰＵ２０１および２１１は、同一計算機上の二つのプロセッサであっても構わない。あるいは、一つのマルチコアＣＰＵにおける二つの計算コアであっても構わない。また、メモリ２０２および２１２、ネットワークＩ／Ｆ２０４および２１４、ストレージ２０３および２１３は、それぞれが一つであって、一つの計算機に接続されるのであっても、あるいは二つの計算機に接続されて共有されるのであっても構わない。本明細書において、計算機とはいずれの場合も含み、処理部、更に記憶部も同様である。
　次に、図３および図４を用いて、本実施例のストリームデータ処理におけるクエリとクエリグラフの一例を説明する。
　図３に示すように、クエリ３００は、２つの入力ストリームｓａおよびｓｂ、３つのクエリｑ１、ｑ２およびｑ３を定義するクエリである。
　図４に示す通り、ストリームデータ処理システムは、クエリ３００の定義を受取ると、自身の実行領域中に確保したクエリ実行ワークエリア４２０上に、オペレータ４００～４１０によって構成される、クエリグラフを生成する。このオペレータには、スキャン（Ｓｃａｎ）オペレータ４００、４０３、フィルタ（Ｆｉｌｔｅｒ）オペレータ４０２、４０５、結合オペレータ４０６、ストリーム化演算オペレータ４０７などに加え、各種のウィンドウ（Ｗｉｎｄｏｗ）４０１、４０４、４０８等も含まれる。オペレータ４００は入力ストリームｓａをデータソースから受取るＳｃａｎオペレータ、オペレータ４０３は入力ストリームｓｂをデータソースから受取るＳｃａｎオペレータである。ストリームｓａおよびｓｂは共に、文字列型のカラムｉｄと、整数型のカラムｖａlの二つのカラムから構成されるデータの系列である。
　オペレータ４０１、４０２、４０４、４０５、４０６および４０７は、クエリｑ１に対応する部分クエリグラフを構成するオペレータ群である。オペレータ４０１は、ストリームｓａに対して施されるグループ別個数ウィンドウ（ＰＡＲＴＩＴＩＯＮ　ＢＹ　ｉｄ　ＲＯＷＳ　２）であり、カラムｉｄ別に最新２個のデータを切り出す。オペレータ４０４は、ストリームｓｂに対して施される時間ウィンドウ（ＲＡＮＧＥ　５ ＭＩＮＵＴＥＳ）であり、直近５分以内のデータを切り出す。オペレータ４０２は、ウィンドウ４０１で切り出したデータに対して施されるフィルタオペレータ（ｓａ．ｖａｌ　＞　１００）であり、カラムｖａｌの値が１００より大きいデータのみを通過させる。オペレータ４０５は、ウィンドウ４０４で切り出したデータに対して施されるフィルタオペレータ（ｓｂ．ｖａｌ　＜＞　－１）であり、カラムｖａｌの値が－１以外のデータを通過させる。オペレータ４０６は、結合オペレータ（ｓａ．ｉｄ　＝　ｓｂ．ｉｄ）であり、オペレータ４０２および４０５を通過したデータにおいて、カラムｉｄが一致する組合せを生成する。オペレータ４０７は、クエリの結果を正規化するストリーム化演算である。
　オペレータ４０８および４０９は、クエリｑ２に対応する部分クエリグラフを構成するオペレータ群である。オペレータ４０８は、永続ウィンドウ（ＵＮＢＯＵＮＤＥＤ）であり、クエリｑ１の結果データを全て保持する。オペレータ４０９は集約オペレータであり、カラムｉｄ別にｓａ．ｖａｌとｓｂ．ｖａｌの最大値を算出する。また、オペレータ４１０は、クエリｑ３に対応する部分クエリグラフを構成するストリーム化演算オペレータである。
　一時保持領域（Ｔｅｍｐｏｒａｌ　Ｓｔｏｒｅ）４１１および４１２は、それぞれ結合オペレータ４０６および集約オペレータ４０９の実行状態を保持する領域である。一時保持領域４１１は、オペレータ４０６の左入力と右入力それぞれにおける、生存中のデータを保持する。これらは、反対側の入力に到来したデータの結合相手となる。一時保持領域４１２は、グループ別に集約結果のデータを一つずつ保持する。
　前述したように、一時保存領域を持つ結合オペレータ、集約オペレータ以外に、ウィンドウ演算も、実行状態を保持するオペレータである。ウィンドウ演算は、個々の入力データに対して生存期間を定義し、生存中のデータを保持する。これら以外の、フィルタオペレータ、射影オペレータ、ストリーム化演算、Ｓｃａｎオペレータ等のオペレータについては、実行状態を保持する必要はない。
　次に、図５を用いて、図４のクエリグラフの例における実行状態の一例を説明する。ウィンドウ演算Ｗ１ ４０１にデータ５０１～５０６を保持し、ウィンドウ演算Ｗ２ ４０４にデータ５１１～５１７を保持している状態を表している。各データの長楕円はデータのタイムスタンプを表し、左側の四角はカラムｉｄの値を、右側の四角はカラムｖａｌの値を表している。グループ別ウィンドウ４０１は、カラムｉｄ別に、最大２個のデータを保持している。時間ウィンドウ４０４は、タイムスタンプが９：５５～９：５９までのデータを保持している。
　一時保持領域Ｗ３ ４１１は、左入力における生存中のデータ５０１、５０３、５０４、５０５、および右入力における生存中のデータ５１２、５１３、５１４、５１６、５１７を保持している。それぞれ、ウィンドウ演算４０１に保持しているデータ集合のうち、フィルタ条件ｓａ．ｖａｌ＞１００を満たすデータの集合、およびウィンドウ演算４０４に保持しているデータ集合のうち、フィルタ条件ｓｂ．ｖａｌ＜＞－１を満たすデータの集合である。また、結合条件がカラムｉｄに関する等号条件であるため、カラムｉｄの値をキーとして索引付けしており、カラムｉｄの値別にグループ分けして保持している。
　ウィンドウ演算Ｗ４ ４０８は、一時保持領域４１１に保持する、左入力のデータ集合と右入力のデータ集合の直積において、結合条件ｓａ．ｉｄ＝ｓｂ．ｉｄを満たす組合せデータ５２１～５３１を保持している。これらのデータのタイムスタンプは、組合せた左右データのうち遅い方のタイムスタンプをとる。ウィンドウ演算４０８は永続ウィンドウであるため、処理を開始した時刻から全てのデータを保持している。そのため、組合せデータ５２１のように非常に古いデータもウィンドウ内に存在する。
　一時保持領域Ｗ５ ４１２は、ウィンドウ演算４０８に保持しているデータをカラムｉｄ別にグループ分けして集約したデータを、各グループにつき一つずつ保持している。カラムｉｄがａ、ｂおよびｃそれぞれについて、データ５４１、５４２、および５４３を保持している。ここで一時保持領域Ｗ５ ４１２には、カラムｉｄ別に各グループの平均値、最大値、最小値等を保持するよう設定することが可能である。図５の場合、一時保持領域Ｗ５ ４１２には最大値が保持されるよう設定されている。
　続いて、図６を用いて本実施例のストリームデータ処理を実現するソフトウェアのブロック構成の一例を説明する。なお、同図において、太線のブロックはＣＰＵで実行される各種のソフトウェア機能を、細線のブロックはソフトウェアの実行の際、メモリ上に形成される各種のデータの保存領域を模式的に示している。
　同図において、ストリームデータ処理システム２０６は、それぞれ、入力データ１０８を受信する入力データ受信部６０１、クエリグラフとオペレータの実行状態を保持するクエリ実行ワークエリア４２０、クエリ実行ワークエリア４２０のデータに基づいてクエリを実行するクエリ実行部６０２、クエリ実行結果１１０を出力する出力データ送信部６０５を備える。クエリ実行ワークエリア４２０には、それぞれ、オペレータ毎の実行状態を保持するオペレータ実行状態保持領域６２１～６２３および各オペレータ実行状態保持領域６２１～６２３に対して各オペレータにおいてその内部状態に使用されている最古の入力データの時刻を示す回復ポイントとそれらをスナップショットとして記録したときの記憶量を記録したオペレータ回復ポイント記憶領域６２４～６２６を確保する。
　さらに、ストリームデータ処理システム２０６は、クエリ１０６を解析してクエリ実行ワークエリア上にクエリグラフを生成するクエリ解析部６０６を備える。クエリ解析部６０６は、クエリグラフ上のオペレータ群において、実行状態のスナップショットを取得するオペレータを選定する、スナップショット対象選定部６０７を含む。スナップショット対象選定部６０７で選定したオペレータ群は、スナップショット対象リスト記憶領域６０８に記憶する。
　加えて、ストリームデータ処理システム２０６は、入力データ受信部６０１で受信した入力データ１０８の複製をバックアップ用ストレージシステム２１６に送信する、もしくはバックアップ用ストレージシステム２１６から送られた復旧用の複製入力データを受信し入力データ受信部６０１に送信する複製データ通信部６０９、復旧用のデータをバックアップ用ストレージシステム２１６から送信するよう要求する復旧要求送信部６１０、バックアップ用ストレージシステム２１６から送信されたバックアップ要求を受信するバックアップ通知受信部６１１、オペレータの実行状態とスナップショット対象リストを一時的に保存するコピーバッファ領域６１２、バックアップ用ストレージシステム２１６に対しオペレータの実行状態およびスナップショット対象リストを送受信するワークエリアデータ通信部６１３を備える。
　ここで、クエリ実行部６０２は、各オペレータ実行状態保持領域６２１～６２３の保持内容をスナップショット対象リスト記憶領域６０８に従いコピーバッファ領域６１２にコピーする実行状態書出部６０３と、コピーバッファ領域６１２にある保持内容を各オペレータ実行状態保持領域６２１～６２３の保持内容にコピーする実行状態書込部６０４を備える。
　一方、バックアップ用ストレージシステム２１６はストレージデータ処理システム２０６と入力データ１０８の複製を授受する複製データ通信部６５７、ストレージデータ処理システム２０６から送られた復旧要求を受信する復旧要求受信部６５８、バックアップ処理をストレージデータ処理システム２０６に要求するバックアップ通知送信部６５９、オペレータの実行状態とスナップショット対象リストを一時的に保存するコピーバッファ領域６６０、ストレージデータ処理システム２０６に対しオペレータの実行状態およびスナップショット対象リストを送受信するワークエリアデータ通信部６６１を備える。
　さらに、バックアップ用ストレージシステム２１６は複製された入力データを保存しておく入力データ記憶領域６５５、スナップショットの対象リストを記憶するスナップショット対象リスト記憶領域６５６、スナップショットを記憶するスナップショット記憶領域６５４を備える。ここで、スナップショット記憶領域６５４はオペレータ実行状態記憶領域６７１～６７３を備える。
　加えて、バックアップ用ストレージシステム２１６はバックアップデータ管理部６５２を備える。バックアップデータ管理部６５２は入力データ記憶領域６５５の容量を監視する入力データ容量管理部６５３を備える。
　次に、図７、図８において、本実施例におけるバックアップ用データの更新処理フローの一例を示す。
　まず、図７はバックアップ用ストレージシステム２１６からバックアップ要求を送信し、バックアップ用データがストリームデータ処理システム２０６から送信され、バックアップ用ストレージシステム２１６の保持するバックアップ用データを更新する際のフローである。
　処理７００では入力データ容量管理部６５３が「入力データ容量が規定値に達した」、「前のバックアップから一定時間が経過した」、等を理由にバックアップ要求をバックアップ通知送信部６５９に送信する。続いて処理７０１ではバックアップ通知送信部６５９がバックアップ要求をストリームデータ処理システム２０６に送信する。次いで処理７０２ではバックアップ通知受信部６１１でバックアップ要求を受信したストリームデータ処理システム２０６がスナップショット対象選定部６０７で、実行状態を保持するオペレータの中から、スナップショット対象のオペレータを選定する。処理７０３でストリームデータ処理システム２０６が選定されたオペレータのスナップショットと回復ポイントデータをバックアップ用ストレージシステム２１６に送信する。最後に処理７０４ではバックアップ用ストレージシステム２１６でスナップショットを保存するとともに、送られた回復ポイント以前の複製された入力データを削除する。
　続いて、図８は上述の処理７０２の詳細である。まず、処理８００、８０１、８１２、８１３でオペレータ通番Ｉが対象オペレータの数に達するまで処理８０２～８１１の処理を繰り返す。まず処理８１６で、オペレータ通番Ｉのオペレータが実行状態を保持しているかをチェックし、保持している場合、処理８０２ではオペレータ通番Ｉの回復ポイントＩをオペレータ回復ポイント記憶領域から読み出す。続いて、処理８０３では回復ポイントＩ以降の入力データの記憶容量を、入力データ容量管理部６５３に問い合わせそれを必要記憶容量Ｉの初期値とする。
　次いで、処理８０４、８０５、８１０、８１１でオペレータ通番Ｊが対象オペレータの数に達するまで処理８０６～８０９の処理を繰り返す。まず、処理８１７では、オペレータ通番Ｊが実行状態を保持しているかをチェックし、保持している場合、処理８０６でオペレータ通番Ｊの回復ポイントＪをオペレータ回復ポイント記憶領域から読み出す。処理８０７でオペレータ通番Ｉの回復ポイントＩとオペレータ通番Ｊの回復ポイントＪを比較し、回復ポイントＩの方が回復ポイントJより現在時刻に近い場合は処理８１０に進み、そうでない場合は処理８０８に進む。処理８０８ではオペレータ通番Jを回復ポイントＩ選択時のスナップショット対象に指定する。続いて処理８０９ではオペレータ通番Ｊのスナップショットの記憶量を必要記憶量Ｉに加算する。全てのオペレータ通番Ｊに対して処理８０６～８０９を繰り返す。そして、これを全てのオペレータ通番Ｉに対して繰り返す。
　処理８１４において全てのオペレータ通番に対して最も小さい必要記憶容量を選択し、その回復ポイントＫを決定する。続いて回復ポイントＫ時のスナップショット対象を スナップショット対象リスト記憶領域６０８に記憶する。
　続いて図９、図１０、図１１、図１２、図１３Ａ、図１３Ｂを用いて、本実施例におけるスナップショット対象の選定の具体的な動作例を示す。
　まず、図９は、図４で示した４００～４１２で構成されるクエリグラフ、図５で示した各オペレータの持つウィンドウの実行状態をもとに、それぞれのウィンドウの実行状態にスナップショット取得時の記憶量と回復ポイントを加えて図示したものである。図９において、記憶量はストリームデータのデータ数を示しているが、これに限定するものでなく、各データを記憶するメモリの記憶容量などであって良いことはいうまでもない。
　この例では、ストリームデータ処理システムが時刻６：３０から処理を実行し、現在時刻９５０が１０：００のときにバックアップ処理を実施するものとする。このとき、ウィンドウＷ１ ４０１においてデータは５０１～５０６の６つ存在し、最も時刻の古いデータは「時刻９：４８、ＩＤ＝ｂ、ＶＡＬ＝９７」のデータ５０２である。そのため、ウィンドウＷ１ ４０１のスナップショットに必要な記憶量９０１は６、回復ポイント９０２は９：４８となる。同様にＷ２ ４０４の記憶量９１１は６、回復ポイント９１２は９：５５、Ｗ３ ４１１の記憶量９２１は９、回復ポイント９２２は９：５０となる。Ｗ４ ４０８は永続ウィンドウであるためストリームデータ処理システムが起動してからＷ４に送られたデータすべてを記録している。
　そのため、記憶量９３１は１００と大きく、回復ポイント９３２も最古のデータである５２１と合わせて６：３０と非常に前の時刻となっている。Ｗ５ ４１２ではそれぞれのＩＤの最大値を記録しているため、記憶量９４１は３と小さいが、そのＩＤ＝ｂの最大値データ５４２の由来となるデータは６：４５に入力されたデータ５２２であるため、回復ポイント９４２は５２２と同じ６：４５となる。このように各オペレータの持つウィンドウの実行状態の記憶量、回復ポイントが決められる。
　続いて図１０は入力データ記憶領域６５５に記録された入力データ１０８のバックアップと、図９で示した各オペレータにおける実行状態の回復ポイント以降のデータ数を示している。
　データ群ｓａ１００１はＳｃａｎ４００に入力されるデータ群でデータ５０１～５０６およびデータ１０２０～１０２３等から構成されている。データ群ｓｂ１００２はＳｃａｎ４３０に入力されるデータ群でデータ５１１～５１７およびデータ１０３０～１０３５から構成されている。これを各回復ポイントで記録する場合、Ｗ４ ４０８の回復ポイント９３２である６：３０から保存する場合、記憶するデータ数１０１０は１０００となる。同様にＷ５ ４１２の回復ポイント９４２である６：４５から保存する場合、記憶するデータ数１０１１は９００となり、Ｗ１４０１の回復ポイント９０２である９：４８の場合はデータ数１０１２が１７、Ｗ３ ４１１の回復ポイント９２２の９：５０の場合、データ数１０１３は１４、Ｗ２ ４０４の回復ポイント９１２の９：５５の場合はデータ数１０１４が９となる。
　図１１ではこれらの情報を用いて処理８００～８１３を行った結果をまとめたものを示した。Ｗ１の回復ポイント９０２である９：４８を選択した場合は、Ｗ２の回復ポイントが９：５５、Ｗ３の回復ポイントが９：５０であるため、Ｗ１、Ｗ２、Ｗ３は入力データのバックアップから実行状態を再現できる。一方、Ｗ４とＷ５の回復ポイントはＷ１より古いため、入力データのバックアップから再現できない。そこで、Ｗ４とＷ５はスナップショットが必要となる。
　その結果、この場合の必要記憶容量１１０１はＷ１の回復ポイント９０２での入力データバックアップのデータ数１０１２である１７とＷ４とＷ５のスナップショットの記憶量９３１、９４１の合計である１２０となる。同様の処理をするとＷ２の回復ポイント選択時の必要記憶容量１１０２は１２７、Ｗ３の必要記憶容量１１０３は１２３、Ｗ４の必要記憶容量１１０３は１０００、Ｗ５の必要記憶容量１１０４は１０００となる。
　図１２では処理８１４、８１５により必要記憶容量の最も少ないＷ１の回復ポイントが選択された時の回復ポイントとスナップショットで再現するオペレータのリストである。
　このときの回復ポイント１２０１はＷ１の回復ポイントである９：４８、入力データのバックアップから再現するオペレータ１２０２はＷ１、Ｗ２、Ｗ３、スナップショットから再現するオペレータ１２０３はＷ４、Ｗ５となる。
　図１３Ａ、図１３Ｂそれぞれが、本具体例における、記録される入力データのバックアップ１３００とスナップショット１３１０を示している。入力データのバックアップ１３００は回復ポイントである９：４８以降のデータ、スナップショット１３１０はＷ４とＷ５の実行状態を記録している。
　続いて図１４を用いて、本実施例における、入力データのバックアップとスナップショットから初期状態のストリームデータ処理システムに実行状態を再現する手順のフローチャートを示す。
　処理１４００においてストリームデータ処理システム２０６の復旧要求送信部６１０がバックアップ用ストレージシステム２１６に復旧要求を送信する。それを受けて処理１４０１においてバックアップ用ストレージシステム２１６が入力データのバックアップとスナップショットをストリームデータ処理システム２０６に送信する。処理１４０２において入力データのバックアップとスナップショットを送られたストリームデータ処理システム２０６は障害前の実行状態を復旧する。最後に処理１４０３において障害後の入力データから処理を継続する。
　図１５に図１４の処理１４０２の詳細を示した。最初に処理１５００において回復ポイントからバックアップデータ取得時刻までの入力データのバックアップを初期状態のストリームデータ処理システム２０６で処理する。続いて処理１５０１～１５０４においてスナップショットを取得しているオペレータ全てにスナップショットの実行状態をコピーする。最後にバックアップデータ取得後から障害発生直前までの入力データのバックアップをストリームデータ処理システム２０６で処理する。
　図１６、図１７、図１８を用いて、図１３で取得したスナップショットから初期状態のストリームデータ処理システムに対して図１５のフローチャートに示した手順でバックアップデータ取得時の実行状態を再現する例を示す。
　図１６では初期状態のストリームデータ処理システムに対し処理１５００の回復ポイントからバックアップデータ取得時までの入力データのバックアップ１３００を入力している。
　図１７がその結果である。この場合、入力データのバックアップから実行状態の再現できるＷ１ ４０１、Ｗ２ ４０４、Ｗ３ ４１１の３つはバックアップデータ取得時刻１７５０である１０：００の実行状態が再現されている。一方、Ｗ４ ４０８は本来６：３０からのデータを保存していたため９：４８のデータからではデータ量が足りず、Ｗ５ ４１２は６：３０からのデータの最大値を記憶していたため、９：４８からの最大値であるデータ１７０１～１７０３は本来のものと値が異なっている。
　図１８で図１７の状態に対し処理１５０１～１５０４を行う例を示す。入力データのバックアップ１３００から再現できないＷ４ ４０８、Ｗ５ ４１２の実行状態についてスナップショット１３１０から実行状態をコピーする。その結果、Ｗ４ ４０８、Ｗ５ ４１２を含め全てのオペレータに対し図９と同様のバックアップデータ取得時の実行状態が再現される。
　この後は処理１５０５にあるようにバックアップデータ取得後の入力データのバックアップを処理すれば障害直前の実行状態が再現される。
　ここまでで、スナップショットの取得の処理は一定間隔、または入力データのバックアップの容量が一定値に達した場合に自動で行われてもかまわない。
　また、図１９に示すように（Ｇｒａｐｈｉｃ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ：ＧＵＩ）１９００を用いて、バックアップデータ取得化の最適化機能の使用の有無１９０１、一定間隔の時刻１９０２、バックアップデータの容量の限界値１９０３などを設定できるよう構成しても良い。なお、１０９４はユーザが、所望する任意の時間に、直ちに最適化を実行するために用いる「最適化実施」ボタンを示す。
　以上の詳述した本発明の処理手順により、最小限の記憶領域でストリームデータ処理システムの実行状態を再現する手段が実現できる。
　本発明は、ストリームデータ処理における障害回復技術に関し、特に、障害回復に必要な再現データの保存技術として有用である。
１００…ストリーム処理サーバ
１０１、１０２、１０３、２００、２１０…計算機
１０４…ネットワーク
２０１、２１１…ＣＰＵ
２０２、２１２…メモリ
２０３、２１３…ストレージ装置
２０４、２１４…ネットワークＩ／Ｆ
２０５、２１５…計算機内部バス
２０６…ストリームデータ処理システム
２１６…バックアップ用ストレージシステム（ＢＳＳ）
２１７、２１８…再現用バックアップデータ
４００～４１０…オペレータ
４１１、４１２…一時保持領域
６０１…入力データ受信部
６０２…クエリ実行部
６０５…出力データ送信部
６０６…クエリ解析部
６０８、６５６…スナップショット対象リスト記憶領域
６０９、６５７…複製データ通信部
６１０…復旧要求送信部
６１１…バックアップ通知受信部
６１２、６６０…コピーバッファ領域
６１３、６６１…ワークエリアデータ通信部
６５２…バックアップデータ管理部
６５５…入力データ記憶領域
６５８…復旧要求受信部
６５９…バックアップ通知送信部
６２１、６２２、６２３…オペレータ実行状態保持領域
６２４、６２５、６２６…オペレータ回復ポイント記録領域
６７１、６７２、６７３…オペレータ実行状態記憶領域
５０１～５０６、５１１～５１７、５２１～５３１、５４１～５４３、１０２０～１０２３、１０３０～１０３５、１７０１～１７０３…データ
９０１、９１１、９２１、９３１、９４１…スナップショット記憶量
９０２、９１２、９２２、９３２、９４２…回復ポイント
１３００…入力データバックアップ
１３０１…スナップショットデータ
１９００…バックアップ方式設定ＧＵＩ。

Claims (15)

  1. 計算機を用いたストリームデータ処理の障害回復方法であって、
    前記計算機は、
    ストリームデータ処理を構成するオペレータ中、実行状態を保持するオペレータ各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ前記実行状態を保持するオペレータの、最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ前記実行状態を保持するオペレータの複製データの容量を取得し、前記ストリームデータの容量と前記複製データの容量の合計値が最少となる前記回復ポイントを算出し、算出した前記回復ポイントにおいて前記ストリームデータと前記複製データを記録する、
    ことを特徴とするストリームデータ処理の障害回復方法。
  2. 請求項１に記載のデータ処理の障害回復方法であって、
    前記容量の指標が前記ストリームデータのデータ数である、
    ことを特徴とするデータ処理の障害回復方法。
  3. 請求項１に記載のデータ処理の障害回復方法であって、
    前記計算機は、
    前記実行状態の記録を、任意の時間に実行する、一定時間ごとに実行する、あるいは前回の記録から一定量の入力データが与えられたときに実行する、
    ことを特徴とするデータ処理の障害回復方法。
  4. 請求項１に記載のデータ処理の障害回復方法であって、
    前記実行状態を保持するオペレータが、時間ウィンドウ、個数ウィンドウ、あるいは永続ウィンドウである、
    ことを特徴とするデータ処理の障害回復方法。
  5. 請求項１に記載のデータ処理の障害回復方法であって、
    前記計算機は、
    障害回復のための実行状態再現時において、算出した前記回復ポイントから前記ストリームデータを流し込み、その後、前記複製データを記録した、前記実行状態を保持するオペレータに前記複製データを上書きし、その後、バックアックデータ取得後のストリームデータ処理を行う、
    ことを特徴とするデータ処理の障害回復方法。
  6. 処理部と記憶部とを備えた計算機により実行されるストリームデータ処理の障害回復システムであって、
    前記計算機の処理部は、
    クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、回復ポイントを解析するクエリ解析部と、
    前記クエリ解析部が解析した、各々の前記回復ポイントに対し、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、前記回復ポイント各々における、前記ストリームデータの容量と、前記複製データの容量との合計値が最少となる回復ポイントを決定するバックアップデータ管理部とを備え、
    前記バックアップデータ管理部が決定した回復ポイントにおいてストリームデータ処理の実行状態を前記記憶部に記録する、
    ことを特徴とずる障害回復システム。
  7. 請求項６に記載のデータ処理の障害回復システムであって、
    前記容量の指標が前記ストリームデータのデータ数である、
    ことを特徴とするデータ処理の障害回復システム。
  8. 請求項６に記載のデータ処理の障害回復システムであって、
    前記処理部は、
    前記実行状態の記録を、任意の時間に実行する、一定時間ごとに実行する、あるいは前回の記録から一定量の入力データが与えられたときに実行する、
    ことを特徴とするデータ処理の障害回復システム。
  9. 請求項６に記載のデータ処理の障害回復システムであって、
    前記実行状態を保持するオペレータが、時間ウィンドウ、個数ウィンドウ、あるいは永続ウィンドウである、
    ことを特徴とするデータ処理の障害回復システム。
  10. 請求項６に記載のデータ処理の障害回復システムであって、
    前記処理部は、
    障害回復のための実行状態再現時において、算出した前記回復ポイントから前記ストリームデータを流し込み、その後、前記複製データを記録した、前記実行状態を保持するオペレータに前記複製データを上書きし、その後、バックアックデータ取得後のストリームデータ処理を行う、
    ことを特徴とするデータ処理の障害回復システム。
  11. クエリに基づきストリームデータ処理を実行する計算機の処理部で実行されるデータ処理の障害回復プログラムであって、
    前記処理部を、
    クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、回復ポイントを解析し、
    解析した前記回復ポイント各々に対し、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、
    前記回復ポイント各々における、前記ストリームデータの容量と、前記複製データの容量との合計値が最少となる回復ポイントを決定し、
    決定した回復ポイントにおいてストリームデータ処理の実行状態を記録する、
    よう動作させる、
    ことを特徴とずるデータ処理の障害回復プログラム。
  12. 請求項１１に記載のデータ処理の障害回復プログラムであって、
    前記容量の指標が前記ストリームデータのデータ数である、
    ことを特徴とするデータ処理の障害回復プログラム。
  13. 請求項１１に記載のデータ処理の障害回復プログラムであって、
    前記処理部を、
    前記実行状態の記録を、任意の時間に実行する、一定時間ごとに実行する、あるいは前回の記録から一定量の入力データが与えられたときに実行させる、
    よう動作させる、
    ことを特徴とするデータ処理の障害回復プログラム。
  14. 請求項１１に記載のデータ処理の障害回復プログラムであって、
    前記実行状態を保持するオペレータが、時間ウィンドウ、個数ウィンドウ、あるいは永続ウィンドウである、
    ことを特徴とするデータ処理の障害回復プログラム。
  15. 請求項１１に記載のデータ処理の障害回復プログラムであって、
    前記処理部を、
    障害回復のための実行状態再現時において、算出した前記回復ポイントから前記ストリームデータを流し込み、その後、前記複製データを記録した、前記実行状態を保持するオペレータに前記複製データを上書きし、その後、バックアックデータ取得後のストリームデータ処理を行う、
    よう動作させることを特徴とするデータ処理の障害回復プログラム。
PCT/JP2010/064288 2010-06-15 2010-08-24 データ処理の障害回復方法、システムおよびプログラム WO2011158387A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/701,847 US9037905B2 (en) 2010-06-15 2010-08-24 Data processing failure recovery method, system and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010136099A JP5308403B2 (ja) 2010-06-15 2010-06-15 データ処理の障害回復方法、システムおよびプログラム
JP2010-136099 2010-06-15

Publications (1)

Publication Number Publication Date
WO2011158387A1 true WO2011158387A1 (ja) 2011-12-22

Family

ID=45347807

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/064288 WO2011158387A1 (ja) 2010-06-15 2010-08-24 データ処理の障害回復方法、システムおよびプログラム

Country Status (3)

Country Link
US (1) US9037905B2 (ja)
JP (1) JP5308403B2 (ja)
WO (1) WO2011158387A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9298788B1 (en) * 2013-03-11 2016-03-29 DataTorrent, Inc. Checkpointing in distributed streaming platform for real-time applications
US9542397B1 (en) 2013-03-14 2017-01-10 EMC IP Holding Company LLC File block addressing for backups
KR20140134379A (ko) * 2013-05-14 2014-11-24 엘에스산전 주식회사 데이터 수집 장치
US9477571B2 (en) * 2014-01-20 2016-10-25 International Business Machines Corporation Streaming operator with trigger
TWI530808B (zh) * 2014-12-04 2016-04-21 知意圖股份有限公司 即時提供信息查詢的資訊系統與方法
KR101632824B1 (ko) 2015-01-12 2016-06-22 인제대학교 산학협력단 휠체어의 휠퍼
US9772910B1 (en) * 2015-12-07 2017-09-26 EMC IP Holding Co. LLC Resource optimization for storage integrated data protection
CN107665155B (zh) 2016-07-28 2021-07-09 华为技术有限公司 处理数据的方法和装置
US10346272B2 (en) 2016-11-01 2019-07-09 At&T Intellectual Property I, L.P. Failure management for data streaming processing system
US10439917B2 (en) * 2016-11-15 2019-10-08 At&T Intellectual Property I, L.P. Recovering a replica in an operator in a data streaming processing system
US20180268001A1 (en) * 2017-03-16 2018-09-20 International Business Machines Corporation Managing a database management system using a set of stream computing data

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006338432A (ja) * 2005-06-03 2006-12-14 Hitachi Ltd ストリームデータ処理システムのクエリ処理方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8813079B1 (en) * 2006-06-07 2014-08-19 Ca, Inc. Thread management to prevent race conditions in computer programs
JP5192226B2 (ja) 2007-12-27 2013-05-08 株式会社日立製作所 待機系計算機の追加方法、計算機及び計算機システム
JP5091894B2 (ja) * 2009-03-13 2012-12-05 株式会社日立製作所 ストリーム回復方法、ストリーム回復プログラム、および、障害回復装置
JP5439014B2 (ja) * 2009-04-10 2014-03-12 株式会社日立製作所 データ処理システム、その処理方法、及び計算機
US8726076B2 (en) * 2011-05-27 2014-05-13 Microsoft Corporation Operator state checkpoint markers and rehydration

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006338432A (ja) * 2005-06-03 2006-12-14 Hitachi Ltd ストリームデータ処理システムのクエリ処理方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GABRIELA JACQUES-SILVA ET AL.: "Language-Level Check pointing Support for Stream Processing Applications", PROCEEDINGS OF 2009 IEEE/IFIP INTERNATIONAL CONFERENCE ON DEPENDABLE SYSTEMS AND NETWORKS, 2 July 2009 (2009-07-02), pages 145 - 154 *
JEONG-HYON HWANG ET AL.: "A Comparison of Stream-Oriented High-Availability Algorithms", TECHNICAL REPORT CS-03-17, September 2003 (2003-09-01), pages 1 - 13 *
JEONG-HYON HWANG ET AL.: "A Cooperative, Self- Configuring High-Availability Solution for Stream Processing", PROCEEDINGS OF 2007 IEEE 23RD INTERNATIONAL CONFERENCE ON DATA ENGINEERING, 20 April 2007 (2007-04-20), pages 176 - 185 *

Also Published As

Publication number Publication date
US9037905B2 (en) 2015-05-19
JP5308403B2 (ja) 2013-10-09
JP2012003394A (ja) 2012-01-05
US20130086418A1 (en) 2013-04-04

Similar Documents

Publication Publication Date Title
JP5308403B2 (ja) データ処理の障害回復方法、システムおよびプログラム
US11475038B2 (en) Automatic repair of corrupted blocks in a database
US20200012568A1 (en) Scalable log-based continuous data protection for distributed databases
US10353918B2 (en) High availability and disaster recovery in large-scale data warehouse
JP5331737B2 (ja) ストリームデータ処理障害回復方法および装置
US10216588B2 (en) Database system recovery using preliminary and final slave node replay positions
US20130346366A1 (en) Front end and backend replicated storage
US11042503B1 (en) Continuous data protection and restoration
US11860741B2 (en) Continuous data protection
US20130262389A1 (en) Parallel Backup for Distributed Database System Environments
WO2019109854A1 (zh) 分布式数据库数据处理方法、装置、存储介质及电子装置
US11748215B2 (en) Log management method, server, and database system
US20230110826A1 (en) Log execution method and apparatus, computer device and storage medium
US11494271B2 (en) Dynamically updating database archive log dependency and backup copy recoverability
US20230315713A1 (en) Operation request processing method, apparatus, device, readable storage medium, and system
US11966297B2 (en) Identifying database archive log dependency and backup copy recoverability
US9619506B2 (en) Method and system to avoid deadlocks during a log recovery
US11042454B1 (en) Restoration of a data source
Vasuja et al. Daemons of Hadoop: An Overview
US11468090B2 (en) Maintain constant load on global database after regionalization
US20240160531A1 (en) Continuous data protection
Korotkevitch et al. Troubleshooting Concurrency Issues

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: 10853266

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13701847

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10853266

Country of ref document: EP

Kind code of ref document: A1