JP4600847B2 - トランザクションの意味規則を用いた連続データストリームのセグメント化および処理 - Google Patents

Description

【０００１】
関連出願
Lawrence A. Bookmanらによる『SEGMENTATION AND PROCESSING OF CONTINUOUS DATA STREAMS USING TRANSACTIONAL SEMANTICS（トランザクションのセマンティクス（以下、意味規則ともいう）を用いた連続データストリームのセグメント化および処理）』と題した１９９９年６月１８日出願の同時係属中の米国特許仮出願番号第６０／１４０，００５号。
Lawrence A. Bookmanらによる『SEGMENTATION AND PROCESSING OF CONTINUOUS DATA STREAMS USING TRANSACTIONAL SEMANTICS（トランザクションの意味規則を用いた連続データストリームのセグメント化および処理）』と題した２０００年２月２９日出願の同時係属中の米国特許仮出願番号第６０／１８５，６６５号。
【０００２】
背景技術
コンピュータに基づくトランザクションシステムは、それらのシステムを用いて実現されるトランザクションに関連するデータを発生する。トランザクションに関連するこのようなデータは、トランザクションの特性を識別するために解析される。このような特性から、トランザクションおよび／または関連マーケティングに対する修正が提案される場合もあれば、または他の経営的意思決定が成される場合もある。
【０００３】
トランザクションに関連するデータを解析するためのコンピュータシステムは一般に、データベースに格納されるデータにアクセスする。データが一定の期間収集された後、収集されたデータが、単独のトランザクションにおいてデータベースに追加される。上述したように、データベースに格納されるデータが解析され、結果が与えられる。解析から得られた結果は一般に、データベースに格納されるデータの集合を表す。次に、これらの結果が、たとえば、さまざまな経営的意思決定の基準として用いられ、データベースに格納されることも多い。
【０００４】
場合によっては、トランザクションに関連する生データは、処理後、データベースに保持されていない。トランザクションに関連するデータのこのような処理は一般に、バッチ処理の形態である。バッチ処理において、データのすべてが処理されるまで結果は出力されない。たとえば、バッチに関連する各レコードが個々のトランザクションにおいてデータベースに格納されていた場合には、著しい量のオーバーヘッドがデータベースに関連するデータベース管理システムによって生ずるであろう。同様に、データを解析することができるようにするために、大容量のデータが単独のトランザクションにおいてデータベースから読み出される。多くの場合、トランザクションの発生とトランザクションに関するデータを用いた結果の生成との間の時間は、数日または数週間に及ぶ可能性がある。
【０００５】
発明の概要
トランザクションに関連するデータが連続的にトランザクションシステムによって生成される場合には、または解析の結果を受信するための望ましい時間フレームがバッチ処理を実行するために必要な時間より短い場合には、このようなバッチ処理技法を用いることはできない。トランザクションの使用者の挙動が頻繁に変化する可能性がある場合には、解析の結果を生じる際の遅延は望ましくないことが多い。たとえば、頻繁な変化を有する実時間におけるシステムアクセス情報を追跡するためのデータベースシステムにおいて、安全性または性能に関する理由から、にアクセス解析の周期的な利用を容認することはできない可能性がある。
【０００６】
トランザクションに関連するデータの連続的なソースを仮定すると、トランザクションデータをセグメント化し、任意には並列にデータフロー配列において処理することができる。中間データベースにデータを格納することなく、データを処理することができる。データはセグメント化され、個別に操作されるため、複数のソースからのデータを並列に処理することができる。また、セグメント化は、集合体出力を生じることができる点であってかつチェックポイントを確立する場所を定義することができる。データをセグメントに分割し、セグメント化に基づいてチェックポイントを定義することによって、それぞれ定義されたチェックポイントで処理を再開することができる。このようにすれば、特定のセグメントのためにデータの処理が失敗する可能性があっても、別のセグメントの処理に影響を及ぼすことがない。したがって、特定のセグメントに関するデータの処理が失敗した場合には、問題のセグメントに対応する作業を行うことができなくなるが、他のセグメントで実行される作業ができなくなることはない。たとえば、リレーショナルデータベースシステムでこの点検作業を行うことができる。点検作業は、リレーショナルデータベースシステムを再開可能なクエリーを実行することができるため、データベースの性能を向上させる。これは、成功の可否がシステムの性能に左右されるデータベースベンダおよびユーザに利益をもたらす。一般化するために、データストリームを分割することができることから、チェックポイントの処理および回復を実現することができる。
【０００７】
これらおよびその他の利点は、以下に述べられる。
【０００８】
一態様によれば、データの連続ストリームを処理するための方法が提案される。この方法は、トランザクションの意味規則の指示を受信するステップと、データの連続ストリームのセグメントを識別するためにトランザクションの意味規則をデータの連続ストリームに適用するステップと、セグメントに関する結果を生成するために、データの連続ストリームの各セグメントにおけるデータを処理するステップと、データの連続ストリームの各セグメントにおけるデータが処理された後、問題のセグメントに関して生成された結果を与えるステップと、を含む。
【０００９】
一実施形態によれば、データは複数のレコードを含み、各レコードは複数のフィールドを含み、トランザクションの意味規則は、データの１つ以上のレコードの１つ以上のフィールドの関数によって定義される。別の実施形態によれば、この方法は、識別されたセグメントによるデータの連続ストリームを分割するステップをさらに含む。別の実施形態によれば、分割ステップは、データの連続ストリームに２つのセグメントの間の境界を指すレコードを挿入するステップを含む。別の実施形態によれば、レコードは、境界のみを表すマーカレコードである。別の実施形態によれば、レコードは、トランザクションの意味規則に関連する情報を表す意味レコードである。
【００１０】
別の実施形態によれば、データの連続ストリームは、サーバへ送出される要求に関する情報のログであり、適用ステップは、ログから要求に関連する情報を読み出すステップと、トランザクションの意味規則を読み出した情報に適用するステップと、を含む。別の実施形態によれば、トランザクションの意味規則が１つ以上の要求に関連する１つ以上のフィールドの関数によって定義される場合には、各要求に関連する情報は、複数のフィールドを含む。別の実施形態によれば、この情報は、要求がサーバに送出された時間を含み、トランザクションの意味規則が一定の時間を定義する。別の実施形態によれば、この方法は、１つ以上の要求に関連する情報を削除するためにログをフィルタリングするステップをさらに含む。別の実施形態によれば、フィルタリングステップは、トランザクションの意味規則を生じるステップの前に実行される。別の実施形態によれば、フィルタリングステップは、スパイダに関連する要求に関する情報を削除するステップを含む。別の実施形態によれば、この方法は、データの連続ストリームからデータを削除するために、データの連続ストリームのフィルタリングするステップをさらに含む。
【００１１】
別の実施形態によれば、この方法は、セグメントに関する結果を生成するために、データの連続ストリームの各セグメントにおいてデータを処理する追加ステップをさらに含み、結果が問題のセグメント用に生成されるのであれば、処理の追加ステップ中に、データの連続ストリームの各セグメントのデータが処理される。別の実施形態によれば、処理ステップは、複数の並列パーティションとして各セグメントにおけるデータを分割するステップと、各パーティションに関する中間結果を生成するために、パーティションのそれぞれを並列に処理するステップと、を含む。別の実施形態によれば、この方法は、セグメントに関する結果を生成するために、各パーティションの中間結果を組合せるステップをさらに含む。別の実施形態によれば、データの連続ストリームにおけるデータは、シーケンスを有し、データの連続ストリームの複数のソースが存在する。この方法は、データの連続ストリームにおけるデータがシーケンスの中にあるかどうかを決定し、データがシーケンス外であると決定された場合には、処理ステップを中断し、トランザクションの意味規則によるセグメントにデータを挿入し、セグメントを再処理し、処理ステップを継続することをさらに含む。別の実施形態によれば、この方法は、データが処理されるべきセグメントの永続的指示を保存し、処理ステップにおける失敗が検出された場合には、被選択セグメントに関する処理ステップによって生成される任意の結果を廃棄し、保存された永続的指示に対応する被選択セグメントを再処理し、処理ステップが失敗することなく終了した場合には、出力として生成された出力を生じ、次のセグメントを選択するステップをさらに含む。
【００１２】
別の態様によれば、コンピュータシステムにおける処理エレメントによってデータの連続ストリーム上の動作を点検するためのプロセスが提供される。このプロセスは、トランザクションの意味規則の指示を受信するステップとと、データの連続ストリームを処理エレメントによって処理するためのセグメント分割するためにトランザクションの意味規則をデータの連続ストリームに適用するステップと、セグメントのうちの１つを選択するステップと、被選択セグメントの永続的指示を保存するステップと、結果を生成するために処理エレメントによって被選択セグメントを処理するステップと、処理エレメントの故障が検出された場合には、被選択セグメントに関する処理エレメントによって生成された任意の結果を廃棄するステップと、保存された永続的指示に対応する被選択セグメントを再処理するステップと、処理エレメントによる処理が失敗することなく終了した場合には、出力として処理エレメントによって生成された出力を生じるステップと、処理エレメントによって処理されるべき次のセグメントを選択するステップと、を含む。別の実施形態によれば、適用ステップは、データのセグメント間の境界を示すデータをデータの連続ストリームの中に挿入することを含む。
【００１３】
別の態様によれば、コンピュータシステムは、コンピュータシステムにおけるデータの連続ストリーム上の操作を点検するために提供される。このコンピュータシステムは、トランザクションの意味規則の指示を受信するための手段と、データをセグメントに分割するためにトランザクションの意味規則をデータの連続ストリームに適用するための手段と、セグメントのうちの１つを選択するための手段と、被選択セグメントの永続的指示を保存するための手段と、結果を生成するために被選択セグメントを処理する処理エレメントと、処理エレメントの故障が検出された後に動作する被選択セグメントに関する処理エレメントによって生成された任意の結果を廃棄するための手段と、保存された永続的指示に対応する被選択セグメントを再処理するために処理エレメントに命令するための手段と、処理エレメントによる処理が失敗することなく終了した後に動作する出力として処理エレメントによって生成された結果を与えるための手段と、処理エレメントによって処理されるべき次のセグメントを選択するための手段と、を含む。別の実施形態によれば、適用するための手段は、データのセグメント間の境界を示すデータをデータの連続ストリームの中に挿入することを含む。
【００１４】
別の態様によれば、データの連続ストリームを処理するための方法が提供される。この方法は、トランザクションの意味規則の指示を受信することと、データの連続ストリームのセグメントを識別するためにトランザクションの意味規則をデータの連続ストリームに適用することと、データの連続ストリームの識別されたセグメント間の境界を示すデータをデータの連続ストリームに挿入することを含む。
【００１５】
本発明のさらなる特徴および利点のほか、本発明のさまざまな実施形態の構造および動作は、添付の図面に関連して以下に詳細に説明される。図面において、同様の参照符号は、同様または機能的に類似の構成エレメントを示している。さらに、参照符号の最も左側の１つまたは２つの数字は、参照符号が最初に現れた図面を識別する。
【００１６】
詳細な説明
以下の詳細な説明は、添付された図面と共に読まれたい。尚、類似の参照符号は類似の構造物を示している。本願明細書に引用されたすべての参照文献は、参照によって特に本願明細書に引用されるものとする。
【００１７】
いま図１を参照すると、連続データソース１０１は、いくつかのトランザクションの意味規則１０３による結果１０８を与えるために、データ処理アプリケーション１０７によって処理されるデータの連続ストリーム１０２を生じる。これらのトランザクションの意味規則１０３は、ストリーム１０２がどのようにセグメント化されるべきかを決定する情報であってもよい。意味規則１０３は、たとえば、ストリーム１０２上で操作するときにシステムの一定の必要条件に左右される場合もあり、データを解析するためのビジネスの必要条件に左右される場合もある。データ処理アプリケーション１０７において、セグメント化されたデータ１０５を生じるために、トランザクションの意味規則１０３に応じてセグメンタ１０４によってデータをセグメント化する。データ処理オペレータ１０６は、各セグメントに関する結果１０８を与えるために、セグメント化されたデータ１０５の各セグメント内のデータを処理する。これらのプロセスは、たとえば、連続データストリーム１０２における１つ以上の部分のデータの読み出したり更新したりしてもよい。
【００１８】
連続データソース１０１は、一般に、トランザクションシステムからトランザクションに関連するデータを生じる。トランザクションシステムは一般に、ユーザがトランザクションを形成することができるようにするために、一定の時間動作していることから、このソースは連続している。たとえば、連続データソースは、ウェブサーバに送出される要求に関する情報のログを出力するウェブサーバであってもよい。このような要求は、ウェブサーバによってサーバログの中にログレコードとして格納されてもよい。データの連続ストリームのソースの他の例としては、予約システム、販売時点情報管理システム、現金自動預金支払機、銀行業務システム、クレジットカードシステム、検索エンジン、映像または音声配信システムまたはデータの連続ストリームを生成する他のシステムが挙げられる。また、データの１つ以上の連続ストリームを生じる１つ以上の連続データソースであってもよく、アプリケーション１０７は、これらのストリームの上で動作するように構成されてもよい。
【００１９】
トランザクションに関連するデータは一般に、各トランザクション用のレコードを含み、レコードは、トランザクションを説明する情報の１つ以上のフィールドを含む。レコードは、複数の異なる形式のいずれであってもよい。トランザクションに関連するデータは、たとえば、可変長または固定長のいずれであってもよく、タグ付きまたはタグなしのいずれであってもよく、区切られていても区切られていなくてもよい。トランザクションに関連するデータは、たとえば、ＳＧＭＬ、ＨＴＭＬ、ＸＭＬなどのマークアップ言語形式または他のマークアップ言語に含まれていてもよい。連続データソース１０１からデータ処理アプリケーション１０７へのデータの伝送のための構造体の例には、文字列、配列またはファイルに格納された構成体、データベースレコード、名前付き（named）パイプ、ネットワークパケット、フレーム、セルまたは他の形式が含まれる。一態様によれば、データの連続ストリーム１０２はサーバログであり、トランザクションに関連するデータの例には、ユーザ識別子、クライアントプログラムおよび／またはシステム識別子、タイムスタンプ、ページまたは広告識別子、どのくらいページまたは広告がアクセスされたかを示すインジケータ、レコードタイプおよび／またはトランザクションに関する他の情報を含んでもよい。
【００２０】
トランザクションの意味規則１０３は、データの連続ストリーム１０２の１つ以上のレコードの１つ以上のフィールドの関数を定義する。たとえば、トランザクションの意味規則１０３は一定の時間、たとえば１時間を定義し、１時間の期間内にすべてのデータが１つのセグメントに配置されるようにする。トランザクションの意味規則１０３はまた、時間などの１つのレコードの関数ではなく、たとえば、総売上げ高などの複数のレコードの集合体関数を定義する。そのようなトランザクションの意味規則１０３はまた、データの解析から得られるべき情報を示すビジネス上のリールから導出されてもよい。トランザクションの意味規則１０３はまた、一定のシステムの必要条件に左右される場合もある。たとえば、経営的意思決定を行うことができるように、セグメントごとの基準でこのような解析を行う場合もある。
【００２１】
トランザクションの意味規則１０３は、データの連続ストリーム１０２におけるセグメントを識別するために、データの連続ストリーム１０２にセグメンタ１０４によって適用される。これらの識別されたセグメントに基づいて、さまざまな方法でデータの連続ストリーム１０２を分割することができる。たとえば、データのストリームにおける２つのセグメント間の境界を表すレコードをデータの連続ストリーム１０２の中に挿入することができる。このレコードは、境界のみを表すマーカレコードであってもよい。たとえば、マーカレコードがタグに関する１つの値を有し、データレコードがタグに関する別の値を有するように、タグは、すべてのレコードに配置されてもよい。あるいは、レコードは、トランザクションの意味規則それ自体などのトランザクションの意味規則に関連する情報または一定の時間の仕様などトランザクションのセグメントをデータに適用することによって得られた一定の情報を含む意味レコードであってもよい。さらに、アプリケーション１０７は、データに格納されたトランザクションの意味規則に応じて、複数のデータ処理オペレータ１０６をデータセグメントにアクセスさせることができるようにしてもよい。任意の種類の情報は、データのストリーム１０２における分割を表すために用いられてもよい。
【００２２】
また、異なる処理を実行することができるデータの異なるセグメント化された連続ストリーム１０５を生成するために、複数のセグメンタ１０４を用いてもよい。あるいは、セグメント化されたデータの連続ストリーム１０５に異なる解析を実行するために、複数のデータ処理オペレータ１０６を並行して用いてもよい。
【００２３】
データ処理オペレータ１０６によって実行されることができる操作にはさまざまな種類がある。たとえば、レコードの総数、レコード内の変数の和、さまざまなデータフィールドの平均値、最大値、最小値などの統計的な値などのデータ集合体を、各データセグメントごとに算出してもよい。データの連続ストリームがサーバログであるアプリケーションにおいて、たとえば、情報の各項目が各セグメントまたはセグメントの組合せにおいてサーバによって提供された有意数のユーザを算出することができる。多種多様な異なる結果１０８を生成するために、データ処理アプリケーション１０７からさまざまなデータ処理オペレータ１０６を追加してもよく、または削除してもよい。
【００２４】
Torrent Systems社製のオーケストレート（Orchestrate）並列フレームワークを用いて、データ処理アプリケーション１０７を実行してもよい。これについては、Michael J.Beckerleらによる「Apparatuses and Methods for Programmable Parallel Computers」と題した１９９６年３月２５日に出願の米国特許出願番号第０８／６２７，８０１号、Allen M.Razdowらによる「Apparatuses and Methods for Monitoring Performance of Parallel Computing」と題した１９９７年２月２４日出願の米国特許出願番号第０８／８０７，０４０号、Michael J.Beckerleらによる「Computer System and Process for Checkpointing Operations on Data in a Computer Systerm by Partitioning the Data」と題した１９９８年６月２４日出願の米国特許出願番号第０９／１０４，２８８号およびAnthony Passeraらによる「A Computer System and Computerized Method for Partitioning Data for Parallel Processing」と題した１９９９年６月１日公開の米国特許第５，９０９，６８１号に記載されている。
【００２５】
そのようなシステムにおいて、並列データソースは、複数のプロセッサ上でデータフロー配列に処理される。具体的には、セグメント化またはデータ解析などの図１で実行されるべき各操作をオーケストレート並列処理フレームワークのオペレータとして実現されてもよい。並列アプリケーションフレームワークを用いて、データ処理オペレータによって処理されるデータが、複数の並列パーティションに分割される。これらの並列パーティションのそれぞれはデータ処理オペレータの異なるインスタンスによって並列に処理され、その個別のパーティションに関する中間結果を生じる。集合関数を実行するオペレータによってセグメントに関する集合結果を形成するために、これらの中間結果を組合せてもよい。
【００２６】
さらに、オーケストレート並列処理フレームワークを用いる並列データストリームの処理において、さまざまなオペレータがこれらの並列データストリームを処理するために構成されてもよく、複数の入力オペレータが、単一のデータストリームを形成するために、２つのデータストリームを組合せるために用いられる。単一のデータストリームはまた、さまざまなオペレータによって操作、格納、伝送されてもよく、または他のデータ操作がデータストリーム上で実行されてもよい。
【００２７】
複数の方法でデータ処理オペレータ１０６を実現することができる。具体的には、一般に１０６で表されるデータ処理オペレータは、バッチモードまたは連続モードのいずれかでデータを処理することができる。データ処理オペレータ１０６がバッチ処理を行う場合には、バッチ入力に関連するデータのすべてを処理するまでデータを出力しない。セグメントごとの基準に基づき、データをオペレータに与える連続ループを実行するプログラムによって、オペレータ１０６を制御することができる。このプログラムは、データの終りが各セグメントの境界に達したことをオペレータに確認することによって、オペレータ１０６がセグメントに関する結果を出力する。あるいは、、オペレータ１０６に各セグメント境界で結果を出力させるステップを含む連続オペレータを用いてもよい。
【００２８】
セグメント化されたデータの連続ストリーム１０５はまた、さまざまな形態のいずれであっても、オーケストレート並列フレームワークにおいて並列データセットとして格納されてもよい。並列データセットは一般に、名前、データが実際に、ハードウェア、ディスク、中央処理装置などの構成情報などの情報を定義し、データが格納される場所を示す永続的なフォーム、スキーマ、メタデータ（データに関連するデータ）に格納される場所に対するポインタを含む。１つのデータセットが複数のセグメントを表すために用いられてもよく、または個々のデータセットが各セグメントのために用いられてもよい。
【００２９】
オーケストレート並列アプリケーションフレームワークなどのシステムが、データ処理アプリケーションのために用いられる場合には、記憶装置の形態からアプリケーションフレームワークのデータセットにデータの連続ストリーム１０２を読み込んでもよく、連続データソース１０１がデータの連続ストリーム１０２を生成する。一例として、連続データソース１０１は、受信される要求に関連するデータを生成するＨＴＴＰＤサーバであってもよく、このサーバは、このデータをログに保存する。ログマネージャと一般に呼ばれる個々のアプリケーションは、定期的に新たなログファイルを作成し、そのログファイルにＨＴＴＰＤサーバがデータを書き込む。
【００３０】
たとえば、新たなログファイルを毎日作成してもよい。ログマネージャがどの程度ログファイルを作成したかに関する情報は、オーケストレートアプリケーションフレームワークにおいてデータセットをデータの連続ストリームとしてログファイルのセットを読み出すインポートオペレータなどのデータ処理オペレータ１０６に提供される。１つ以上のインポートオペレータまたは並列に処理する同一の（ログファイルを並列に操作する）オペレータの１つ以上のインスタンスが、存在してもよい。また、インポートオペレータの複数のインスタンスによって並列に処理することができる複数のログファイルのソースが存在してもよい。たとえば、複数のＨＴＴＰＤサーバは、並列に同一のログファイルに書き込むことができる。すなわち、複数のＨＴＴＰＤプロセスは、１つ以上の入力オペレータによって処理されるデータの並列ストリームを生成する。追加のオペレータが操作してもよいこれらのデータストリームを単一のデータストリームに組合せるために、複数の入力オペレータを用いてもよい。
【００３１】
今度は、データ処理アプリケーション１０７によって行われるインポートプロセス２００の操作を示すフローチャートが、図２に関連して説明される。インポートプロセス２００は、ステップ２０１に受信されるソース識別情報に左右される。この識別情報は、データファイル、名前付きパイプまたはデータの連続ソース１０１によって用いられる他の構造体のための命名規則を識別する。次に、名前付き構造体が、受信されるソース識別情報に基づいてステップ２０２において選択される。任意の次のデータレコードが、ステップ２０３において名前付き構造体から読み出される。検証ステップはまた、構造体が識別情報を含む場合に、正しい名前付き構造体がアクセスされたことを確認するために行われてもよい。ステップ２０４において決定されるときに、ステップ２０３において行われた読み出し操作がデータを返す場合には、データはステップ２０８において次のオペレータに提供される。次のオペレータは、フィルタリング操作、セグメント化または処理にさらに適した別の形式にデータレコードを変換する操作であってもよく、またはセグメントタであってもよい。ステップ２０３において複数のデータを読み出すことによって、処理が継続する。このように、連続データソースとデータ処理アプリケーションとの間に一定のバッファ方式が存在するのであれば、インポータは、指定された連続データソースからデータを連続的に読み出す。
【００３２】
ステップ２０４において決定されるときに、読み出し操作が行われるときにデータが利用可能でない場合には、サーバがステップ２０５において作動中であるかどうかがまず決定される。サーバがステップ２０５において作動中でない場合には、システムは、ステップ２０９において待機し、待機後、ステップ２０３において再びデータの読み出しを試みる。待機期間は、たとえば、乱数、所定数またはそれらの組合せであってもよい。サーバが作動中であって、ステップ２０６において決定されるときにファイル終りラベルに達していない場合には、トランザクションシステムは正常に作動中であると推定されることができ、単にトランザクションに関連するデータを生成するために用いられていないことになる。ステップ２０６の後、インポータ処理２００は、一定の時間待機してもよく、および／またはステップ２０３で再びデータの読み出しを試みる前に、ステップ２１０で示されるようにダミーレコードを次のオペレータに送出してもよい。ステップ２０６で決定されるときに、ファイル終りラベルに達している場合には、次のファイル（または他の名前付き構造体）がステップ２０７においてソース識別情報に基づいて選択され、その後にステップ２０３へ処理が戻る。このプロセス２００は、データを連続的にデータ処理アプリケーション１０７に与えるために中断することなく作動するように設計されてもよい。
【００３３】
データの連続ストリーム１０２のセグメント化はまた、操作の点検を一般に行うことができる機能を生じる。具体的には、処理対象のセグメントの永続的指示は、オペレータ１０６によって保存されることができる。オペレータ１０６によって行われている処理中に失敗が検出された場合には、被選択セグメントに関してオペレータ１０６によって生成されたいずれの結果をも廃棄することができる。次に、処理対象であるセグメントの保存されている永続的指示を用いて、セグメントに再処理を施すことができる。オペレータ１０６が失敗することなく処理を終了する場合には、次のセグメントが処理される前に、オペレータ１０６によって生成された出力を出力することができる。操作を点検するためにセグメントをこのように用いることによって、データの連続ストリームをセグメントに分割するトランザクションの意味規則を用いて、データの連続ストリーム上の操作を点検することができる。点検用のパーティションを定義するために、セグメント化を用いることができ、１９９４年１２月発行のSigmod RecordによるＶｏｌ．２３，Ｎｏ，４，ｐ．７２−８３の「Loading Databases Using Dataflow Parallelism」およびMichael J. Beckerleらによる「Computer System and Process for Checkpointing Operations on Data in a Computer Systerm by Partitioning the Data」と題した１９９８年６月２４日出願の米国特許出願第０９／１０４，２８８号に記載されている方法で行うことができる。また、トランザクションの意味規則に基づくセグメント化以外の異なる分割法を用いて、点検を行ってもよい。
【００３４】
オーケストレートアプリケーションフレームワークにおいて、図２に関連して上述したインポート操作およびセグメンタは、データの連続ストリームのインポートから結果の出力まで、データ処理アプリケーション全体を点検することができる複合オペレータとして実現されてもよい。また、トランザクションの意味規則に基づいて、インポートプロセスの点検を行ってもよい。たとえば、時間フィールドが用いられる場合には、１時間、３０分などの定期的な基準でステップ全体を点検することができる。
【００３５】
一部のアプリケーションでは、たとえば、失敗または他の理由からデータの連続ソースを中断することができ、予期されたシーケンス外のデータを生成することができる。一部のアプリケーションでは、シーケンス外のデータを廃棄することができる。しかし、一部の解析では、シーケンス外のデータが有用である場合もある。そのようなアプリケーションでは、シーケンス外のデータが識別され、適切なセグメントに挿入され、問題のセグメントが再処理される。たとえば、データの連続ソース１０１の状態を監視することによって、シーケンス外のデータを検出することができる。以前は有効でなかったデータのソース１０１が有効になっている場合には、別のセグメントの処理が中断され、新たに有効になったソースからのシーケンス外のデータが処理される。次に、データのこのような連続ソースからのデータが、属するデータセットの終りに追加される。次いで、終了後、システムの連続操作が再開される。また、点検と類似の方法で、セグメントからのデータのそのような中断および再処理を行ってもよい。
【００３６】
上述したように、データ処理アプリケーション１０７は、並列の方法で複数の連続データストリーム１０２を処理するように構成されてもよい。図３は、データ処理アプリケーション１０７と関数において類似であるデータ処理アプリケーション３０８を示しており、多数の異なるデータソース３０２〜３０４から並列連続データストリーム３０５〜３０７を受信する。データ処理アプリケーション３０８は、これらの個別のストリーム３０５〜３０７で作動し、１つ以上の結果３１０を生成するように構成されている。具体的には、結果３１０は、たとえば、入力 ストリーム３０５〜３０７の関数としてデータの統合されたストリームであってもよい。具体的には、結果３１０は、データベースに格納することができるレコードの実時間ストリームであってもよい。一実施形態によれば、データベースはリレーショナルデータベースであり、リレーショナルデータベースはデータベースにおいてレコードを並列にアクセスすることができてもよい。
【００３７】
図３に示されているようなシステム３０１は、複数の並列データソースを処理するシステムの一例である。具体的には、これらのソースは、ログファイルデータのストリームを生成するＨＴＴＰＤサーバであってもよい。このようなアーキテクチャ３０１が存在しない場合には、複数のソースからログファイル情報を統合し、次いで逐次的な方法で処理しなければならないか、または複数の処理がデータの個々のストリームを個別に処理しなければならない。前者の場合には、逐次ボトルネックに挿入されるため、スループットが減少する。後者の場合には、プログラマが個別のストリームを処理する個々の並列プロセスを十分に管理し、個別のストリームデータを統合する。
【００３８】
システム３０１は、並行処理の複数の次元を支援することができる。具体的には、システム３０１は、並列にデータストリームのパーティションで操作することができる。さらに、システム３０１は、並列パイプラインを用いてデータの１つ以上のストリームで操作してもよい。具体的には、図１に示されているように、セグメンタ１０４は、１つ以上の連続データストリーム１０２を受け入れることができ、並列にそれらの上で操作することができ、データの個別のストリーム上で動作する多数のデータ処理オペレータ１０６であってもよい。
【００３９】
図４は、データフローを示しており、複数の連続データソースがそれぞれ、複数の連続データストリームを生成する。ステップ４０１で、プロセス４００が開始される。ステップ４０２〜４０４で、システム３０１が複数のログファイルを読み込むことができる。このような読み込みプロセスは、並列に行うことができ、このような読み込みプロセスの結果は、１つ以上のデータ処理オペレータ１０６に伝送されることができ、ステップ４０５〜４０７でログファイルに処理を施す。３つのデータストリームが示されているが、システム３０１は、任意の数の並列データストリームを処理することができ、任意の数の並列パイプラインを含むことができる。このような読み込みプロセスの結果は、データストリームに再分割することができ、データストリームの異なる部分を異なるデータ処理オペレータ１０６に再割当てすることができる。
【００４０】
ステップ４０５〜４０７で、これらのログファイルは、システム３０１のプロセッサの実行の異なるスレッドによって、並列方式で処理される。行うことができる処理は、入力データストリームのエレメントに整列操作または併合操作を含むことができる。このような整列プロセスおよび併合プロセスは、類似のデータを関連することができる場合もあれば、または別の方法で意味規則１０３または予め定義された規則に基づいてデータを再編成することができる場合もある。ステップ４０８〜４１０で、各ストリームがそれぞれ、たとえばデータ処理オペレータ１０６によって処理される。このようなデータオペレータは、データ検出、浄化、増加を初めとする関数を実行することができる。入力データストリームは不良データを含む可能性があるため、システム３０１は、データの検出および拒否を行うことができる場合がある。データストリーム内の有効レコードの始まりを示す特定のバイトパターンまたは当業界で周知であるような他のエラー検出機能および補正機能に基づいて、このような検出を行うことができる。ＨＴＴＰＤプロセスによって経験されるすべてのインターネットトラフィックの３分の１程度がスパイダによって生成されるため、入ってくるデータストリームの１つ以上の部分が、「浄化」（cleansed）されてもよい。具体的には、データストリームにおけるレコードのフィルタリングおよび修正のために汎用構成要素が存在してもよい。このような構成要素は、たとえば、図５に関して以下に説明される管理システム５０５を通じて、ユーザによって設定された予め定義された規則に基づいて作動してもよい。
【００４１】
さらに、データストリームにおける項目は、他の情報と共に増大してもよい。たとえば、ウェブサイトのアクティビティは、１対１マーケティングアプリケーションを構築するために、営業部、商品、顧客支援からなどの他のトランザクションのソースから実時間でデータと併合されることができる。したがって、システム３０１は、たとえば、インメモリ表索引およびデータベース索引に基づいて、データストリームを増加させることができる場合がある。たとえば、与えられた広告に関連するすべての広告主に関してデータストリームを増加させることによって、ユーザは、広告ごとの広告収益を詳細な解析を行うことができる。別のタイプのデータの増加を行うことも可能である。
【００４２】
ステップ４１１〜４１３で、複数のストリームに関するデータを集計することができる。具体的には、システム３０１は、複数のストリームからのデータを解析して統合する複数のグルーピングオペレータを与えることができる。これは、たとえば、複数の独立した次元を横切るデータを効率的にグループ化し、解析することによってウェブアクティビティを解析することができる。さらに詳細には、データの正確な評定を得るために必要な情報は、複数のソースからのデータの解析を必要とする可能性がある。ステップ４１４〜４１６で、集計されたストリームデータは、１つ以上の位置に格納される。具体的には、データは、集計されて、リレーショナルデータベースに格納されることができる。一実施形態によれば、システム３０１は、リレーショナルデータベースに並列な方式で情報を格納することができる。
【００４３】
システム３０１は、たとえば、１つ以上の コンピュータシステムで実行するプログラムとして実現されてもよい。このようなコンピュータシステムは、たとえば当業界で周知であるような汎用コンピュータシステムであってもよい。さらに詳細には、汎用コンピュータは、当業界で公知であるようなプロセッサ、メモリ、記憶装置および入出力装置を含む。汎用コンピュータシステムは、コンピュータプログラミング言語を用いて１つ以上のシステムを設計することができるようなオペレーティングシステムを実行してもよい。オペレーティングシステムの例としては、マイクロソフト社から入手可能なＷｉｎｄｏｗｓ９５、９８またはＷｉｎｄｏｗｓ ＮＴのオペレーティングシステム、サン・マイクロシステムズ、ヒューレット・パッカード、レッド・ハット・コンピューティングおよびさまざまなプロバイダからそれぞれ入手可能なＳｏｌａｒｉｓ、ＨＰＵＸ、Ｌｉｎｕｘまたは他のＵｎｉｘに基づくオペレーティングシステムまたは現在または将来周知である任意の他のオペレーティングシステムが挙げられる。
【００４４】
図５は、クライアント５０１およびサーバ５０３として機能する複数の汎用コンピュータを示している。一実施形態において、データ処理アプリケーション１０７は、サーバ５０３で実行する１つ以上のプロセスとして機能してもよい。具体的には、連続データストリーム１０２上の１つ以上の操作を行うサーバプログラム５１０であってもよい。一実施形態において、サーバ５０３は、サーバプログラム５１０の処理を制御するためにプログラマによって用いられることができるアプリケーションプログラミングインターフェースとして作用するオブジェクトフレームワーク５０９を含む。クライアント５０１はオブジェクトフレームワーク５０９を含むことができ、それによって、ユーザは、サーバプログラム５１０の管理機能を実現するために、入出力５０２を行う。管理アプリケーション５０５は、サーバプログラム５１０がどのような動作するかを決定する構成データを表示し、受け入れるように構成されたグラフィカルユーザインターフェース５０６を含むことができる。管理アプリケーション５０５はまた、ユーザ情報を管理し、ユーザ情報をサーバプログラム５１０に与える基本的なクライアントプログラム５０７を含んでもよい。クライアント５０１とサーバ５０３との間の通信は、ネットワーク５０４を通じたクライアント通信５０８とサーバ通信５１１によって実現される。クライアント通信５０８およびサーバ通信５１１は、たとえば、ＴＣＰ／ＩＰなどのネットワーキングプロトコルを含んでもよく、ネットワーク５０４は、イーサネット、ＩＳＤＮ、ＡＤＳＬまたはシステム間で情報を通信するために用いられる他の任意の種類のネットワークであってもよい。クライアント−サーバネットワーク通信は、コンピュータおよびネットワーク化の当業界では公知である。
【００４５】
サーバ５０３は、たとえば、サーバ５０３に関連する１つ以上のデータベース５１２に結果１０８を格納してもよい。一実施形態において、データベース５１２は、並列リレーショナルデータベースである。サーバ５０３はまた、サーバプログラム５１０がどのように動作されるかを示す複数のユーザ構成ファイル５１３を格納することができる。
【００４６】
説明したように、データ処理アプリケーション１０７は、クライアント−サーバに基づくアーキテクチャであってもよい。このアーキテクチャは、ＪＡＶＡ、Ｃ＋＋および他のプログラミング言語を初めとする１つ以上のプログラミング言語で設計されてもよい。一実施形態によれば、データ処理アプリケーション１０７はＣ＋＋でプログラムされ、Ｃ＋＋フレームワークはデータストリームのデータを処理するための構成要素またはオブジェクトを含むように定義されている。これらのオブジェクトは、オブジェクトフレームワーク５０９の一部であってもよい。たとえば、データを分割、併合、結合、フィルタリングおよびコピーするための構成要素であってもよい。サーバプログラム５１０は、ユーザ構成ファイル５１３に基づいて、データ処理アプリケーション１０７の実行を管理する。この構成ファイル５１３は、処理ノードのネットワーク名などの基本的なコンピュータシステムリソースおよびディスク空間およびメモリなどのコンピュータシステムコンピュータシステムを示す。データベース５１２は、データレイアウトを示すスキーマ、任意のユーザによって定義された構成要素およびプログラムを初めとするメタデータなどの関連アプリケーション情報を格納するために用いられてもよい。
【００４７】
図６は、データ処理アプリケーション１０７を実行することができるフレームワークのアーキテクチャ６０１を示している。たとえば、アーキテクチャ６０１を含む複数の層であってもよい。たとえば、アーキテクチャ６０１は、単一のプログラム挙動を生成する原因となるコンダクタプロセス６０２を含んでもよい。具体的には、プロセス６０２は、データ処理アプリケーション１０７のインスタンスを確立する。コンダクタプロセス６０２はまた、セクションリーダプロセス６０３，６０４を生じてもよい。一実施形態において、コンダクタプロセス６０２は、遠隔コマンドを実行する公知のＵｎｉｘコマンド「ｒｓｈ」を用いて、異なるシステム中の同じ部分でセクションリーダプロセス６０３，６０４を生じる。一実施形態において、セクションリーダプロセスは、物理的なコンピュータシステムごとに１つ生じる。各セクションリーダプロセス６０３〜６０４は、プレーヤプロセスを生じ、公知のフォーク（）コマンドによってデータフローにおいて各データ処理オペレータ１０６ごとに１つのプレーヤプロセスを生じる。コンダクタは、たとえば、セクションリーダおよび／またはプレーヤプロセス６０５〜６１０として同一または個別のコンピュータで実行されてもよい。
【００４８】
コンダクタプロセス６０２は、制御情報を送信し、接続６１１，６１２に沿ってそれぞれ状態メッセージを受信することによって、セクションリーダプロセス６０３〜６０４と通信を行う。同様に、セクションリーダプロセス６０３〜６０４は、制御情報を送出し、状態およびエラーメッセージを受信することによって、プレーヤプロセス６０５〜６１０と通信を行う。一般に、コンダクタプロセス６０２は、メッセージトラフィックを統合し、円滑なプログラム操作を保証する。プレーヤプロセス６０５〜６１０に支障が生じた場合には、セクションリーダプロセス６０３〜６０４は、プログラム操作を援助して制御されたプレーヤプロセスを終了し、同様のことを行うために他のセクションリーダに通知する。
【００４９】
データ処理アプリケーション１０７は、フレームワーク全体にわたってデータを管理するための入出力マネージャに関連していてもよい。入出力マネージャは、たとえば、アーキテクチャ全体にわたってデータフローを処理するために、コンダクタプロセス（またはオペレータ）と通信を行うことができ、結果データを格納するために責任を担うデータマネージャに情報を伝送してもよい。
【００５０】
入出力マネージャは、１つ以上の以下の機能を提供してもよい。
・フレームワーク全体にわたるデータの移動のためのブロックバッファ付き転送・入出力マネージャはデータマネージャにブロックを渡すといった、データマネージャにブロック入出力サービス
・たとえば、データマネージャによって指定されたファイルのブロックを格納することによるフレームワークのための永続的な記憶サービス
・デッドロック回避のためのバッファ方式およびフロー制御
【００５１】
一実施形態において、入出力マネージャは、データマネージャにポートインターフェースを生じることができる。ポートは、論理接続を表すことができる。ポートは、たとえば入力ポート（「インポート」）または出力ポート（「アウトポート」）であってもよく、仮想的または物理的なエンティティであってもよい。アウトポートは、単一のアウトバウンドストリームを表し、永続的なデータセットの各出力パーティションに関して生成される。仮想的なポートの場合には、プロセスマネージャ（コンダクタ）は、プレーヤプロセス間の接続を生成する。一実施形態によれば、特定のプレーヤプロセスの任意の仮想的な出力ポートは、下流のプレーヤプロセスへの単独の接続を備えることができる。同様の方式において、インポートは、単一のインバウンドストリームを表し、１つの入力ポートは、各インバウンドデータストリームに関して生成されてもよい。仮想的なポートに入力するためのインバウンドデータストリームは、決定的ではない方法でデータブロックの単一ストリームに併合されてもよい。データブロックの順序付けは、所与のパーティションに保持されてもよいが、パーティションの中に順序付けを必ず含むというわけではない。パーティションの中に順序付けを必ず含むというわけではないため、デッドロック状態を回避することができる。
【００５２】
図７は、２つのノード１，２の間に確立されることができる一連の論理接続を示しており、それぞれのノードは、オペレータＡ，Ｂの個別のインスタンスを有する。具体的には、ノード１はプレーヤオペレータ（またはプロセス）Ａ７０１およびプレーヤオペレータＢ７０２を含み、オペレータＡは処理のためにオペレータＢに逐次的にデータを与える。さらに、ノード２のオペレータＡ７０３はまた、ノード１のプレーヤオペレータＢ７０２に逐次的に情報を与えることができる。同様に、プレーヤオペレータＡ７０１は、ノード２のプレーヤオペレータＢ７０４によって処理するためのデータを与えることができる。オペレータ７０１〜７０４の間の１つ以上の論理接続設定は、このデータ転送を容易にすることができる。このように、並列パイプライン式プロセス間の通信を行うことができる。
【００５３】
ここで、少数の実施形態を示してきたが、上述の事項は単なる例示に過ぎず、限定ではなく、例としてのみ示されたことを当業者は十分に理解すべきである。さまざまな修正および他の実施形態は、当業界の範囲を逸脱することなく行われる。
【００５４】
たとえば、データの連続ストリーム１０２のセグメント化の前に、データの解析を援助しないレコードまたは偏っている可能性があるレコードまたはそれ以外にデータの解析に影響を及ぼすレコードを除去するために、データをフィルタリングしてもよい。たとえば、データの連続ストリームが、サーバに送出される要求に関する情報を除去するための情報のログである場合には、１つ以上の要求に関してログをフィルタリングしてもよい。除去することができる情報の種類は、「スパイダ」（spiders）、「クローラ」（crawlers）または「ロボット」（robots）と呼ばれるコンピュータプログラムを初めとするさまざまなエンティティに関連する要求についての情報を含む。コンピュータネットワーク上のファイルサーバにアクセスするために、このようなプログラムは検索エンジンによって実行され、インデクス化のためにそれからファイルを収集する。スパイダ、クローラ、ロボットによって送出されるこれらの要求はまた、サーバに対する他の要求と同様に記録される。このようなプログラムは、既知である場合もあるホスト名およびエージェント名を有する。フィルタリング操作は、既知のスパイダ、クローラまたはロボットの名前を有するユーザからの任意の要求をフィルタリングすることができる。サーバはまた、スパイダ、クローラおよびロボットによってサーバ上でいずれのファイルをアクセスすることができるかを指定する予め決定された名前のファイルを備えていてもよい。スパイダ、クローラまたはロボットのホストまたはエージェント名を識別するためにこれらのファイルへのアクセスを用いることができ、次にこれらのエンティティからの他のアクセスをフィルタリングするための用いることができる。プログラムは、そのようなスパイダ、クローラおよびロボットを検出するためにたやすく利用することができる。さらに、複製データレコードの除去または他のデータ浄化操作が適している場合もある。そのようなフィルタリングは一般に、トランザクションの意味規則をデータの連続ストリームのセグメントに適用する前に実行されるが、データがセグメント化された後に実行されてもよい。これらおよび他の修正は、本発明の範囲を逸脱することなく考慮される。
【図面の簡単な説明】
【図１】 本発明の一実施形態による連続データを処理するシステムを示しているデータの流れ図である。
【図２】 どのようにデータの連続ソースから並列アプリケーションフレームワークにデータを読み込むことができるかの動作を説明しているフローチャートである。
【図３】 複数のデータストリームを処理するシステムを示している別のデータの流れ図である。
【図４】 複数のパイプラインシステムによってデータをどのように処理することができるかを説明しているフローチャートである。
【図５】 本発明のさまざまな実施形態を実行するのに適したクライアント−サーバシステムのブロック図である。
【図６】 データを処理するために用いられる処理アーキテクチャのブロック図である。
【図７】 並列で通信を行うオペレータを有する２ノードシステムのブロック図である。

Claims (18)

1. トランザクション・データの連続ストリーム上の操作を点検するための方法であって、コンピュータが、
   前記連続ストリームがどのようにセグメント化されるべきかを決定する情報であるトランザクション・セマンティクスを前記連続ストリームに適用して、当該連続ストリームを複数のセグメントに分割するステップと、
   前記分割された複数のセグメントのうちの１つのセグメントを選択するステップと、
   前記選択されたセグメントについての指示を保存するステップと、
   前記選択されたセグメントについての結果を生成するために、前記選択されたセグメントを処理するステップと、
   前記処理するステップにおいて失敗が検出された場合には、前記選択されたセグメントについて生成された結果を廃棄し、前記保存された指示を用いて前記選択されたセグメントを処理するステップと、
   前記処理するステップが失敗することなく終了した場合には、出力として前記生成された出力を供給し、次のセグメントを選択するステップと
   を実行することを含む、前記方法。
2. 前記適用することが、前記トランザクション・データのセグメント間の境界を示すレコードを前記連続ストリーム中に挿入するステップを含む、請求項１に記載の方法。
3. 前記連続ストリームが情報のログを含む、請求項２に記載の方法。
4. 前記連続ストリームが、サーバログ、又は、予約システム、販売時点情報管理システム、現金自動預金支払機、銀行業務システム、クレジットカードシステム、検索エンジン、映像または音声配信システム若しくはデータの連続ストリームを生成する他のシステムからの連続ストリームを含む、請求項２に記載の方法。
5. 前記トランザクション・データが複数のレコードを含み、各レコードが複数のフィールドを含み、前記トランザクション・セマンティクスが当該複数のフィールドのうちの少なく１つの関数によって定義される、請求項１に記載の方法。
6. 前記レコードが、前記境界のみを表すマーカー・レコードである、請求項４に記載の方法。
7. 前記レコードが、トランザクション・セマンティクスに関連する情報を含むセマンティクス・レコードである、請求項４に記載の方法。
8. 前記情報が、前記複数の要求の１つが前記サーバに送出された時間を含み、前記トランザクション・セマンティクスが一定の時間を定義する、請求項１に記載の方法。
9. 前記連続ストリームがサーバに送出される要求に関連する情報のログであり、
   前記適用するステップが、
   前記ログから要求に関連する情報を読み出すステップと、
   前記トランザクション・セマンティクスを前記読み出した情報に適用するステップと
   を含む、請求項１に記載の方法。
10. 前記コンピュータが、
    前記連続ストリームからデータを除去するために、前記連続ストリームをフィルタリングするステップを実行することをさらに含む、請求項１に記載の方法。
11. 前記処理するステップが、
    複数の並列パーティションとして各セグメントにおけるデータを分割するステップと、
    前記パーティションのそれぞれを並列に処理して、各パーティションに関する中間結果を生成するステップと
    を含む、請求項１に記載の方法。
12. 前記コンピュータが、
    各パーティションの中間結果を結合して、前記セグメントに関する前記結果を生成するステップを実行することをさらに含む、請求項１１に記載の方法。
13. 前記連続ストリームの前記データがシーケンスを有し、前記データの連続ストリームの複数のソースが存在し、
    前記コンピュータが、
    前記トランザクション・データ中の特定の部分がシーケンス中にあるかどうかを決定するステップと、
    前記特定の部分がシーケンス外にあると決定された場合には、前記処理するステップを中断し、前記トランザクション・セマンティクスに基づいてセグメント内に前記特定の部分を挿入し、前記特定のセグメントを処理し、前記処理するステップを継続するステップと
    を実行することをさらに含む、請求項１に記載の方法。
14. 前記トランザクション・セマンティクスが、データの１つ以上のレコードの１つ以上のフィールドの関数によって定義される、請求項１に記載の方法。
15. 前記トランザクション・セマンティクスが、一定の期間を定義する、請求項１に記載の方法。
16. トランザクション・データの連続ストリーム上の操作を点検するためのコンピュータであって、
    前記連続ストリームがどのようにセグメント化されるべきかを決定する情報であるトランザクション・セマンティクスを前記連続ストリームに適用して、前記連続ストリームを複数のセグメントに分割する手段と、
    前記分割された複数のセグメントのうちの１つのセグメントを選択する手段と、
    前記選択されたセグメントについての指示を保存する手段と、
    前記選択されたセグメントについての結果を生成するために、前記選択されたセグメントを処理する手段と、
    前記処理するステップにおいて失敗が検出された場合には、前記選択されたセグメントについて生成された結果を廃棄し、前記保存された指示を用いて前記選択されたセグメントを処理する手段と、
    前記処理するステップが失敗することなく終了した場合には、出力として前記生成された出力を供給し、次のセグメントを選択する手段と
    を備えている、前記コンピュータ。
17. 前記適用する手段が、前記トランザクション・データのセグメント間の境界を示すデータを前記連続ストリーム中に挿入する手段を備えている、請求項１６に記載のコンピュータ。
18. コンピュータに、請求項１〜１３のいずれか一項に記載の方法の各ステップを実行させるコンピュータ・プログラム。

Images