JP5922805B2 - 進化的な分析のためのシステム - Google Patents

Description

本明細書は仮出願でなく、２０１２年６月２７日に出願された仮出願シリアルＮｏ．６１６６４９７１の優先権を主張し、その内容は参照により組み込まれる。

本発明は、進化的な（evolutionary）分析に関する。

知識主導型の企業は、彼らのビジネスのあらゆる側面を計測する積極的な戦略を導入し、収集された大量の生データから従業員が価値を見出すことを奨励している。データ主導型の意思決定（ＤＤＤ）は、データ中にそれをサポートする十分な証拠がある限り、変化の影響を受けない知識主導型の企業のどの部分もそのままにはしておかない。組織は、データを、未知の価値を有するかもしれないログとして収集し、このため、抽出−変換−書き出し（ＥＴＬ：Extract−Transform−Load）を行うことは、ＥＴＬの高い費用のため現実的でない。ＥＴＬは、高価であり、データがどのようであるか、値がどこに存在するものであるかの先験知識を必要とする正式なプロセスを要求する。そのログは、一般的に大きく、フラットであり、構造が完全に予め定義されたデータベース設計を要求するために、一般的なデータベースに対してＥＴＬの複雑さを追加する低構造（low-structure）を有している。これらの理由のために、データの多くが十分に評価されることなく、データアナリストは、近代的な組織が収集する、増え続けるデータを分析して、すぐに使用可能な見識を生成することを必要とする。予期されるように、このタイプの分析は、本質的に探索的であり、データアナリストが、データ上で初期クエリを開始し、結果を試験し、そしてクエリを再公式化して（reformulate）追加のデータソースにもたらす、などのインタラクティブなプロセスを伴う。典型的には、クエリは、データタイプおよび分析の目的、例えば、ツイート上で感情分析を行う、または大きなソーシャルネットワーク内のノードそれぞれの影響を計算することにリンクされている、高機能な、ドメイン特有の動作を伴う。

MapReduce（MR）およびHadoopのような大規模システムは、耐障害性をサポートするために、中間ジョブ結果の積極的な実体化を行う。ジョブが、データアナリストによって発行された探索的なクエリに対応するとき、これらの実体化は、典型的には、同じアナリストからの一連のクエリの中から、またはむしろ類似した仮定をテストする異なるアナリストのクエリに渡って、共通の計算をキャプチャする実体化ビューの大規模なセットを生み出す。驚くことではないが、MapReduceはそれをオリジナルのフレームワークとし、そのオープンソースの形であるHadoop、または宣言型のクエリ言語を提供するPigおよびHiveのような派生システムは、このタイプの分析のデファクトツールとなっている。大規模なデータセットにスケーラビリティを提供することに加えて、ＭＲは、先行スキーマを定義しデータをインポートする必要がないように、新規データソースを導入することを促進し、そして、データ上に適用することができるユーザ定義関数（ＵＤＦｓ）のメカニズムを通じて拡張性を提供する。

ＵＤＦｓは、ＳＱＬのような、リレーショナルデータベースおよび記憶部で利用可能な標準的な操作の範囲外のものである。典型的なＵＤＦの例は、分類関数である。これは、入力として、user_idおよびいくつかのテキストを必要とし、このテキストからいくつかのエンティティ（オブジェクト、固有名詞）を抽出し、そしてそれらのエンティティについて、ポジティブまたはネガティブな感情として、ユーザの周囲のテキストを分類する。データの値は不明であるため、アナリストは、通常、当初はデータについて完全に理解できておらず、最初のクエリ（ワークフロー）をポーズして、最終的な望ましい結果に向けて、現在の答えが次のクエリの進化を知らせるようにそれを改良する。さらにＵＤＦｓのような複雑な関数は、多くの場合、トライアンドエラーを通して経験的に調整される必要があり、アナリストは、多くの場合、データ上でその答えに満足するまで、分析的なタスクを何度も繰り返し改良する必要があるであろう。

単一のＭＲジョブの計算範囲は制限されているため、科学者たちは、一般的に、互いにデータをフィードするＭＲジョブの集合としてクエリを実装する。かなり頻繁に、そのようなクエリは、宣言型のクエリ言語、例えば、HiveQLまたはPigLatinを用いて書かれ、自動的にＭＲジョブのセットに変換される。

ＭＲシステムの人気にも関わらず、クエリパフォーマンスは、データアナリストが仮説を検証し、結論に収束することができる「スピード」に順番に直接影響する重要な課題である。一部のゲインは、ＭＲのオーバーヘッドを低減することによって達成することができるが、パフォーマンスへの大きな障害は、大規模なデータセットを取り込み、実際には共通のクラスの複数のＭＲジョブに及ぶクエリの先天的な複雑さである。例えば、データを再構成または前処理することによる事前調整は、予備分析の流動性および不確実性に起因して、大変困難である。

一実施形態によれば、進化的分析のためのシステムは、システムで実行される以前のワークフロー実行結果の一部として実体化された回答を用いることによって、より効率的にするために、ワークフローをリライトすることによって、３つの側面（分析ワークフロー、ユーザ、およびデータ進化）をサポートする。

他の実施形態によれば、進化的分析のためのシステムは、システムで実行される以前のワークフロー実行結果の一部として実体化された回答を用いることによって、より効率的にするために、ワークフローをリライトすることを通じて、３つの側面をサポートする。システムは、アナリストたちによって用いられている既存のクエリ実行エンジンとクエリリライト部とを統合する。最適化部は、いくつかの宣言型の言語で記述されたクエリを取得し、それをＭＲジョブで構成された実行プランに変換する。ターゲット実行エンジンは、実体化ビューメタデータ蓄積部１６だけでなくリライト部１４も統合することによって、拡張される。

上記のシステムの実装は、以下の１または複数を含むことができる。クエリは、大規模なログである基本データに対して表されており、クエリはＵＤＦｓを含んでいる。ＭＲジョブのそれぞれは、安定したストレージ（例えば、Ｈａｄｏｏｐ中のＨＤＦＳ）への出力を実体化する。一実施形態において、最適化部は、システムに許容されたＵＤＦｓに対するコスト見積りを提供することができる。リライト部にターゲットエンジンの最適化部と通信させるために、最適化部は、各計画ノード上の２種類の注釈（annotations）と共に、プランを生成するように拡張される。（１）その計算の論理式（２）推定実行コスト
リライト部は、ノードの出力のためのリライトを探索するとき、注釈中の論理式を用いる。数式は、関係演算子またはＵＤＦｓから構成されている。探索中に見つかったリライトのそれぞれでは、リライト部は最適化部を利用して、プランおよび推定コストを取得している。クエリ実行の間、クエリ処理の全ての副産物は、日和見主義的な（opportunistic）実体化ビューとして維持され、システム中で記憶されて、日和見主義的なの物理設計構造の一部となる。実体化ビューメタデータ蓄積部は、ビュー定義のような、現在のシステムにおける実体化ビューに関する情報と、クエリ最適化において用いられる標準データ統計値とを含む。

好ましい実施形態の利点は、下記のうち１または複数を含むことができる。システムがそれほど複雑でない。ユーザの観点から−リライトは、ユーザのガイダンスまたはヒントなしで自動的に行われる。システムの観点から−物理設計が自動化され、継続的にプロバイダのガイダンスなしで調整される。システムは、アルゴリズム的に最適なリライトを作業効率のよい方法で見つける。また、より高速な動作が達成される。ユーザおよびシステムの観点から−方法は、システム内の既存の成果物を使用して、システムがアナリストクエリの最低価格の可能な（最適な）リライトを提供することを保証している。アルゴリズム的観点から−アルゴリズムは、ＯＰＴＣＯＳＴによる最適なリライトを見つけるために、ソリューション空間の最小量を探索し、これは、ソリューション空間を削ることなく行われる。ワークフローリライト技術は、ワークフロー実行時間を低減するために、システム中の全ての利用可能なアーチファクト（artifact：中間生成物）を用いるリライトを生成することによって、進化的ワークフローの最適なリライトを、作業効率のよい方法で探索する。これは、ユーザの視点からより早いパフォーマンスと、システムプロバイダの視点からクエリに応答するために消費されるシステムリソース量の減少をもたらす。楽観的なコスト関数ＯＰＴＣＯＳＴの使用は、ワークフローリライトアルゴリズムが、システムが最適なリライトを見つけるために必要なソリューション空間の最小量を生成（explode：爆発的に増やす）および探索することを可能にするリライト空間を徐々に探索することを可能にする。ＵＤＦのグレーボックスモデルは、リライトをまだもたらす表現である。グレーボックスアプローチは、少ない労力で、ユーザが、システムにＵＤＦを追加することを許容する。これは、システムがＵＤＦのリライトのために探索することを許容し、如何なる他のアナリストもそのＵＤＦを使用することを許容する。さらに、システムオペレータは、また、ＵＤＦを含むように、リライト言語を選択して拡張することができるが、より多くの労力を必要とする。このモデルは、単独のヒントよりも、より一般的であり、より表現豊かである。

進化の３つの側面を同時にサポートすることができるフレキシブルなシステムを示している。 制御フローを示すシステムフレームワークの例示的でありハイレベルな概要を示している。 システム内のワークフローおよび新規データセットの進化をサポートする例示的なプロセスを示している。 システム内の新規ユーザの進化のための例示的なプロセスを示している。 リライトのための例示的なプロセスを示している。 効果的かつ効率的な進化をサポートするために、ワークフローを内部的に処理して維持する例示的なシステムを示している。 空間を削るための例示的なプロセスを示している。

図１は、進化の３つの側面---ワークフロー、ユーザ、およびデータを同時にサポートすることができるフレキシブルなシステムを示している。我々は、これを進化的システムと呼ぶ。進化的クエリワークフローは、アナリストによって、彼らが反復的にデータを探索するように記述されたものである。ユーザは、クエリに彼／彼女の意図を翻訳することができるようにデータを十分に理解できていないため、進化的ワークフローＷの結果は、最初は望んだ結果を生成できないことがある。典型的には、Ｗは、新規ワークフローＷ’として再定式化され、このプロセスが繰り返される。ワークフローの進化は、ワークフローの結果がアナリストの意図により沿って一致するために、単一のアナリストがワークフローを調整し、変更し、再目的化することによって定義される。ユーザの進化は、それが新規ワークフローと共にシステムを検索し始める、新規アナリストの登場として、定義される。データの進化は、アナリストが新規データソース（例えば、ログ）をシステムに加えるプロセスとして定義される。

このシステムにおいて、ワークフローの進化は、ワークフローの結果がアナリストの意図に一致するようによりよく整列するために、単一のアナリストが、ワークフローを調整し、変更し、再目的かすることによって定義される。ユーザの進化は、新規ワークフローと共にシステムを検索し始める新規アナリストの登場として定義される。データの進化は、アナリストが新規データソース（例えば、ログ）をシステムに加えるプロセスとして定義される。

システムは、新規クエリの実行時間を低減する、システム内の以前のクエリ／ワークフロー実行結果からのアーチファクト（中間回答および最終回答）をシームレスに維持することおよび再利用することによって、ワークフローをより効率的にするためにリライトすることを通じて、これらの３つの側面をサポートする。これらのアーチファクトは、実体化ビューと呼ぶことができる。

我々のユースケースにおけるアナリストは、典型的には、以前の結果を調べて元のワークフローを変更することによって、ワークフローを複数回修正する。この方法のアナリストは、彼らの望む解答に向けて動くような方向において、彼らの知識（intuition）を探索する自由がある。ワークフローの変更は、新規データソースの追加、サブゴールの変更、パラメータの変更、またはワークフロー中のいくつかの動作をＵＤＦで置き換えることを含むことができる。一実施形態は、これらのタイプの変更を我々のマイクロベンチマーク内でキャプチャーする。アナリストは、新規ＵＤＦをシステムに加えることによってワークフローの言語を拡張することができ、そしてＵＤＦは全ての他のアナリストに利用可能となる。

サービスプロバイダはシステム内において他のプレイヤであり、プラットフォームマネージャとして良好なシステムパフォーマンスを確保したい。プロバイダは、ユーザのコミュニティのパフォーマンスに対する単一のユーザのパフォーマンスの最大化の間のトレードオフを考慮しなければならない。プロバイダは、より多くのＵＤＦｓを追加することによって、リライトの言語を拡張することができる。ＵＤＦを用いてリライト言語を拡張することは、よりよいリライトを見つけることによって、アナリストに利益をもたらすが、リライトの探索空間を拡大し、より良いリライトを見つけるためにかかる時間を増大する。リライト言語が豊富で拡張可能な変換のセットを含んでいたとしても、リライトの言語はワークフローの言語よりも表現豊かでないことが予想される。プロバイダはまた、保持する実体化ビューを決定する必要がある。ストレージ空間は無限でないため、ガーベッジコレクタが必要とされる。

我々のシナリオ内のクエリは、ＵＤＦｓのように表現された複雑な分析操作を含む可能性がある。我々のシステム内の以前の計算を効果的に再利用するために、我々は、ＵＤＦｓを意味的にモデル化する方法を必要とする。

ＵＤＦｓをモデリングする可能性は、オーバヘッドとシステムに対する複雑さとの様々なレベルを有する、ホワイトボックス、グレーボックス、またはブラックボックスアプローチを含むことができる。ホワイトボックスアプローチは、システムがＵＤＦが入力を変換する方法を理解するように、ＵＤＦの完全な記述を必要とする。このアプローチは、新規ＵＤＦをシステムに追加するときに、アナリストにとって高いオーバーヘッドを有する。ブラックボックスアプローチは、アナリストのための非常に低いオーバーヘッドを有しているが、システムにとって全く不可解な出力を生成するため、結果の再利用という我々の目的には適していないかもしれない。ＵＤＦｓは、データ上のかなり複雑な操作を伴うことがあるため、我々のシステムは、ＵＤＦによって実行されるエンドツゥーエンドの変換のみをキャプチャするグレーボックスアプローチを採用している。エンドツゥーエンドの変換によって、我々のＵＤＦモデルは計算の詳細は何も知らないが、我々は、我々のモデルが入力タプルと出力タプルとの間の細粒度の依存関係をキャプチャすることができることを示唆している。これは、新規ＵＤＦを追加するときに、グレーボックスモデルを提供するための追加の労力を必要とするが、まだシステムに便利な方法で、ＵＤＦの変換を理解させることができる。ブラックボックスモデルは、一方で、全体としての入力および出力の間の粗粒度の依存関係を追跡することができるのみである。

我々のグレーボックスモデルにおけるＵＤＦは、ローカル関数の合成として記述される。ローカル関数は、単一のタプルまたは単一のグループのタプル上で操作する関数を指す。一実施形態は、ローカル関数を以下の動作を実行するものに制限する。
１．属性を破棄または追加
２．フィルタを適用することによってタプルを破棄
３．タプルのグルーピングを実行

グレーボックスモデルは、ローカル関数それぞれにより与えられた変換を理解しているが、複数のローカル関数によって実行される変換の本質を理解していない。ＵＤＦのエンドツゥーエンドの変換は、ＵＤＦ内の各ローカル関数によって実行される動作を構成することによって得ることができる。

グレーボックスモデルに従って、プラン内の全てのノードの入力および出力は、３つのプロパティ：属性Ａ、フィルタＦ、および分類Ｇによってキャプチャされる。Ｆは、入力データに適用する全てのフィルタの組み合わせであり、Ｇは現在適用されているグルーピングであり、Ａはスキーマをキャプチャする。ＵＤＦのエンドツゥーエンドの変換は、ローカル関数の組み合わせを用いた、入力の出力への変換として表現することができる。組み合わせは、３つの動作を用いて、エンドツゥーエンドの変換の意味をキャプチャするが、実際の計算ではなく、内部手続を記述するためではないことに留意せよ。これらをグルーピングと組み合わせることによって、モデルは、select（選択）、project（提案）、join（加入）、group-by（分類）、およびaggregation（集約）のような関係演算子と同様に、リッチなＵＤＦｓを表現する。“joins”は、複数の関係を共通のキー上でグループ化する、MapReduce内で標準の方法でモデル化される。

図２は、制御フローを示す、システムフレームワークのハイレベルな概要を例示的に示している。システムは、システム内における以前のワークフロー実行結果の一部として実体化された回答を用いることによって、より効率的にするために、ワークフローのリライトを通じて、これらの３つの側面をサポートする。システムは、クエリリライト部を、アナリスト１０によって使用される既存のクエリ実行エンジンと統合する。最適化部１２は、宣言型の言語で記述されたクエリを取得し、それをＭＲジョブから構成される実行プラン内に変換する。クエリは、大規模なログである基本データに対して表現されており、クエリは、ＵＤＦｓを含む。ＭＲジョブのそれぞれは、安定したストレージ（例えば、Ｈａｄｏｏｐ内のＨＤＦＳ）への出力を実体化する。この実施形態において、最適化部は、システムに適用されるＵＤＦｓに対するコスト推定値を提供することができる。ターゲット実行エンジンは、実体化ビューメタデータ蓄積部１６だけでなくリライト部１４を統合することによって拡張される。リライト部１４に、ターゲットエンジンの最適化部と通信させるために、最適化部１２は、２つのタイプの注釈を各プランノード上に生成するように拡張される。（１）計算の論理式（２）推定実行コスト。リライト部は、ノードの出力のためのリライトを探索するとき、注釈中の論理式を用いる。式は、関係演算子またはＵＤＦｓから構成される。探索中に見つかったリライトのそれぞれでは、リライト部は、プランおよび推定コストを得るために最適化部を利用する。クエリ実行の間、クエリ処理の全ての副産物は、日和見主義的な実体化ビューとして維持され、システム内で記憶されて、日和見主義的な物理設計構造の一部となる。実体化ビューメタデータ蓄積部は、ビュー定義のような現在のシステムにおける実体化ビューに関する情報と、クエリ最適化において用いられる標準データ統計値とを含む。

システムは、ＭＲの組み込みの耐障害性のメカニズムを日和見主義的な物理設計として活用することで、クエリパフォーマンスを劇的に改善することができる。ＭＲジョブのそれぞれは、障害回復を目的とした、中間結果（マッピング部（mapper）の出力、低減部（reducer）の入力、および低減部の出力）の実体化を含む。より一般的には、PigまたはHiveによって生成されたもののような多段階のジョブは、そのような実体化をいくつか含むであろう。我々は、これらの実体化の結果をクエリ実行のアーチファクトと呼び、それらがクエリ実行の副産物として自動的に生成されることに注目する。

データ探索の進化の本質を考えると、各クエリは、同じアナリストによる以前のクエリと類似性を有している可能性があり、同じデータを調べる他のアナリストのクエリとさえも類似性を有している可能性がある。例えば、複数のデータアナリストは、感情分析を特定のツイートのクラス（例えば、特定の地理的エリア）上で、しかし異なる仮定を念頭に置いて、実行することができる。そのため、システム内の以前のクエリにより実行される計算は、生成されたアーチファクト中でキャプチャされるように、新規クエリに関連するかもしれない。

アーチファクトは、日和見主義でつくられた実体化ビューとして取り扱われ、それらは、システム内で新規クエリをリライトするために用いられる。この技術の日和見主義的な本質は、いくつかの良い特性を有している：実体化ビューは、クエリ実行の副産物として生成される。すなわち、追加のオーバヘッドを必要としない。複数のビューのセットは、自然に、現在のワークロードに合わせて調整される。大規模な分析システムは通常大量のクエリを発行することを考えると、等しく大量の実体化ビューがあり、このため新規クエリに対する良好なリライトを探索する良いチャンスがあるであろうということになる。産業用のデータ分析システムの内部のこの技術の実装の結果は、クエリ実行時間を劇的に節約することが可能であることを示している。リライトは、最高で２ケタの大きさの実行時間を低減することができる。

クエリリライト技術は、ＭＲシステム中の日和見主義的な実体化ビューのシナリオをターゲットとしている。アルゴリズムは、候補となるリライトの巨大な空間を積極的に削減し、最適なリライトを効率的な方法で生成するために、空間データベース（具体的には、距離空間における最近隣探索）から発送を得た技術を採用している。システムは、単純であるがＵＤＦｓの多くの共通タイプをキャプチャするのに十分表現豊かなグレーボックスＵＤＦモデルを用いる。これは、以前の結果の効果的な再利用を可能にするために、我々にＵＤＦｓの限られた理解を与える。リライトプロセスは、入力としてクエリと複数のビューのセットとを取り込み、最適なリライトを出力する。この技術は、最適なリライトを一定の仮定の下で見つけるために必要なビューの最小セットを考慮する場合、作業効率がよい。この方法を適用した実験結果は、実世界のデータと現実的な複雑なクエリとを使用して、最高で２ケタの大きさの実行時間の改善をもたらす。この方法による節約は、移動するデータが大幅に少なくなり、可能な場合、生のログから再読み込みすることの高い労力（expense）を回避し、ＵＤＦｓを含む長時間実行の計算結果を再利用／再目的化することによるものである。

クエリリライトプロセスは、２つの主な課題：リライトの大空間を探索する方法、および、ＵＤＦｓ（大規模データ分析における共通の特徴）を含むビューを推論する方法に対処している。最小コストのリライトを見つけたアルゴリズムは、非距離空間における最近隣探索から発想を得ている。我々は、Ｈｉｖｅに基づいたプロトタイプデータ分析システムを用いた、実世界のデータセット上の広範な実験的研究を紹介する。結果は、アプローチが、複雑なデータ分析クエリ上の劇的なパフォーマンスの改善をもたらすことができ、平均で６１％であり、最大で２ケタの大きさのトータル実行時間を低減することを実証している。

図３は、システム内におけるワークフローおよび新規データセットの進化をサポートする例示的なプロセスを示している。アナリストは、１または複数の進化的なワークフロー１００を記述する。システムは、１２０で新規ＵＤＦを取得し、システムは、１２２で新規データセットを追加する。システムは、１２４でワークフローをリライトし、進化的ワークフローが１１０で実行される。システムは、１２６で実体化ビューを分類する。プロバイダは、１２８でシステムに実体化ビューをドロップさせることができる。あるいは、システムは、１３０で言語をリライトすることによって、拡張することができる。

図４は、システム内の新規ユーザの進化のための例示的なプロセスを示している。当初は、新規アナリストは、このシステムを用いる。アナリストは、１４０でワークフローＷを書き込む。システムは、１４２でワークフローを順にリライトして、１４４でワークフローを実行する。アナリストは、１４６で結果を試験し、もし彼／彼女が満足しない場合、アナリストはワークフローを見直して、１４０に戻ることができる。あるいは、もしアナリストが満足する場合、プロセスは終了する。

図５は、ワークフローをリライトするための例示的なプロセスを示している。プロセスは、１６０で、入力として、ワークフローＷと、１または複数の既存の実体化ビューＶとを受信する。プロセスは、１６２で、Ｗをｎ個のサブワークフローに分割する。プロセスは、１６４で最良のリライトをサブワークフローのそれぞれについて見つける。プロセスは、１６６で、Ｗに対するリライトを見つけるために、複数のリライトを組み合わせる。

図６は、効果的かつ効率的な進化をサポートするために、ワークフローを内部的に処理および維持する例示的なシステムを示している。１７０において、プロセスは、入力として、ワークフローＷおよび既存の実体化ビューＶを受信する。プロセスは、１７２で、Ｗをｎ個のサブワークフローに分割する。プロセスは、１７４で、全てのｎ個のサブワークフローについて同時にリライトを列挙する。１７６において、プロセスは、コストｃでリライトを見つけなかった場合、サブワークフローのサーチを取り除く。プロセスは、１７８で、今までで最良のリライトを維持する。次に、プロセスは、１８０で全てのサーチ問題が取り除かれたか否かを確認する。もし取り除かれていない場合、プロセスは、１７４に戻り、そうでない場合、プロセスは、Ｗについて最良のリライトを１８２で返す。

図７は、空間を削るための例示的なプロセスを示している。このプロセスにおいて、新規ユースケースが、１９０で、分析システムのために選択される。システムは、１９２で、進化の３つの側面（ワークフロー、ユーザ、およびデータ）を同時にキャプチャする。プロセスは、１９４で、リライトにつながるグレーボックスＵＤＦモデリング技術を適用する。このプロセスはまた、１９６で、最適かつ仕事効率のよいワークフローリライトを実行する。OptCost関数は、１９８で、約束する候補のビューの増分を列挙することを可能にするために用いられる。プロセスは、そして、サーチ問題をリライトし、その問題を、サーチ空間を削るために２００で用いられる、ｎサーチ問題として型変換する（cast）。

一実施形態において、仕事効率クエリリライトアルゴリズムは、ビューを使用してリライトするコストの下限によって順序付けられたターゲットのそれぞれで空間をサーチする。これは計算上高価であるため、下限は、有効なリライトを見つけることを要求するべきでない。我々は、候補ビューｖおよびターゲットＷ_ｉを入力として取り込み、ｖを用いてＷ_ｉのリライトｒ_ｉの下限を提供する、楽観的なコスト関数OptCost（Ｗ_ｉ,ｖ）を定義する。ｒ_ｉは、候補ビューｖを用いる、Ｗ_ｉのリライトである。下限の特性は、OptCost(Ｗ_ｉ,ｖ)≦Cost(ｒ_ｉ)である。下限コストを用いることは、オブジェクト間の計算距離が計算上高価であり、このため、常に実際の距離以下である望ましい特性を計算することが容易である、代わりの距離関数を好む、距離空間の最近隣探索問題から発想を得ている。

OptCost関数を考慮すると、リライトアルゴリズムは、この問題を２つの部分に分割することによって、Ｗの最適なリライトｒ^*を見つける。
１．ＢｆＲｅｗｒｉｔｅは、Ｗ中の全てのターゲットについてのリライトの効率的なサーチを実行し、Ｗ_ｎについての全体的に最適なリライトを出力する。
２．ＶｉｅｗＦｉｎｄｅｒは、単一のターゲットについての候補ビューを、それらがターゲットの低コストのリライトを生成する能力に基づいて列挙し、ＢｆＲｅｗｒｉｔｅによって利用される。

ＢｆＲｅｗｒｉｔｅアルゴリズムは、Ｗ中の複数のターゲットで見つかった複数のリライトから構成され得る、Ｗのリライトｒを生成する。計算されたリライトｒ^*は、同じクラス内の全てのリライトの候補のうち最低コストを有する可能性がある。さらに、アルゴリズムは、仕事効率がよい：Cost(r^*)が先天的に知られていないとしても、最適なコストCost(r^*)よりも高い候補ビューをOptCostと共に試験することはない。直感的には、アルゴリズムは、証拠を示して、最適なリライトを発見するために必要とされるサーチ空間の一部のみを探索する。

アルゴリズムは、プランについての最良のリライトであるＷ自身から始まる。その後、Ｗ中の複数のターゲットそれぞれにおいて、ｎ個の同時サーチの問題を生成し、よりよりリライトを見つけるために、繰り返して動作する。各繰り返しにおいて、アルゴリズムは、１つのターゲットＷ_ｉを選択し、Ｗ_ｉにおける候補ビューを試験する。アルゴリズムは、Ｗ中の他のターゲットのサーチ空間を削ることを支援するために、このステップの結果を利用する。仕事効率を上げるために、アルゴリズムは、次に試験する候補ビューを正確に選択しなければならない。我々が下記に示すように、OptCost関数は、絞り込む次のターゲットを選択するために、重要な役割を果たしている。

ＢｆＲｅｗｒｉｔｅは、各ターゲットにおいてリライトの空間をサーチするために、ＶｉｅｗＦｉｎｄｅｒの例を用いている。ＶｉｅｗＦｉｎｄｅｒは、以下の複数の関数を提供するブラックボックスである。（１）Ｉｎｉｔは、候補ビューのサーチ空間をそれらのＯｐｔＣｏｓｔに従って生成する。（２）Ｐｅｅｋは、次の候補ビューのＯｐｔＣｏｓｔを提供する。（３）Ｒｅｆｉｎｅは、次の候補ビューを用いるターゲットのリライトを見つけようとする。Ｒｅｆｉｎｅの１つの重要な特性は、以下の通りである：Ｐｅｅｋの値よりも小さいコストを有する対応するターゲットについて見つかる残りのリライトが存在しないこと。

ＶｉｅｗＦｉｎｄｅｒの重要な特徴は、ＢｆＲｅｗｒｉｔｅによって、順に空間を探索し、セクション４．１．中に示されるように不要なサブ空間を削るために用いられる、そのＯｐｔＣｏｓｔ関数である。上述したように、ビューを用いるリライトクエリは、困難な問題として知られている。伝統的に、ＳＰＪＧクエリのクラスに対するビューを用いるリライトクエリのための方法は、２段階のアプローチを用いる。削減（prune）段階は、どのビューがクエリに関連しているかを決定し、関連する複数のビューの中から、要求されたジョイン述語の全てを含むものは「完全な（complete）ソリューション」と呼ばれ、そうでなければ、「部分的な（partial）ソリューション」と呼ばれる。これは、典型的には、追加の関連ビューを形成するために、全ての可能な等価ジョイン方法を用いる部分的なソリューションにジョインする統合（merge）段階が続く。アルゴリズムは、クエリに応じるために有用なビューが残っている限り、繰り返す。

我々は、部分的なソリューションおよび完全なソリューションを特定するという点で類似したアプローチを採用し、統合段階に続く。ViewFinderは、ターゲットのリライトを探索するとき、候補ビューＣを考慮する。Ｃは、標準ビュー統合手順の実装である統合関数を用いるＶ中において複数の「統合」ビューにより形成される複数のビューを含むのと同様に、Ｖ中において、複数のビューを含む。伝統的なアプローチは、全ての部分的なソリューションを統合して完全なソリューションを作り出し、部分的なソリューションが残らなくなるまで継続する。これは、候補ビューの空間を指数関数的に爆発的に増やす。このアプローチは、必要に応じて、空間を爆発的に増やすことを可能にし、考慮されているよりもずっと少ない候補ビューをもたらす。

早期終了条件を用いずに、既存のアプローチは、全てのターゲットにおいて徹底的に空間を探索するであろう。このため、我々は、空間を列挙し、要求に応じてのみ段階的に探索し、ＢｆＲｅｗｒｉｔｅにより要求されると、頻繁に、サーチを停止および再開することができるリライトアルゴリズムを望んでいる。我々は、ターゲットに対する等価リライトが存在する可能性があるが、ＶｉｅｗＦｉｎｄｅｒはそれを見つけるように依頼されないかもしれないことに注意する。

ＶｉｅｗＦｉｎｄｅｒは、アルゴリズム４中に示されている。ハイレベルにおいて、ＶｉｅｗＦｉｎｄｅｒは、ステートフルであり、ＢｆＲｅｗｒｉｔｅに各ターゲットでのインクリメンタルサーチを開始、停止および再開させることが可能である。ＶｉｅｗＦｉｎｄｅｒは、候補ビューの優先度キューを用いて、状態を維持する。ＶｉｅｗＦｉｎｄｅｒは、我々が次に説明する３つの関数Ｉｎｉｔ、Ｐｅｅｋ、およびＲｅｆｉｎｅを実装する。

Init関数は、ターゲットＷｉ（Ｗｉは集合Ｗに属する）の論理表現であるクエリおよびシステム内に存在する実体化ビューＶのセットと共に、ViewFinderのインスタンスを作成する。次に、クエリは、ｑに割り当てられ、Ｖ内の各ビューは、ＯｐｔＣｏｓｔ（ｑ，ｖ）をソーティングキーとして用いて、優先度キューに加えられる。Ｉｎｉｔの最後において、ＰＱ内の候補ビューは、Ｖ内のビューのみを含む。

Ｐｅｅｋ関数は、ＢｆＲｅｗｒｉｔｅによって、ＰＱ内の先頭アイテムのＯｐｔＣｏｓｔを取得するために用いられる。Ｒｅｆｉｎｅ関数は、ＢｆＲｅｗｒｉｔｅがＶｉｅｗＦｉｎｄｅｒに次の候補ビューを試験するように依頼したときに起動される。この段階では、ＶｉｅｗＦｉｎｄｅｒは、先頭アイテムｖをＰＱからポップする。ＶｉｅｗＦｉｎｄｅｒは、そして、ｖを以前ポップした候補ビュー（すなわち、Ｓｅｅｎ中のビュー）と統合して、その結果、候補ビューの空間を順に爆発的に増加させることによって、新規候補ビューのセットＭを生成する。Ｓｅｅｎは、ｖのＯｐｔＣｏｓｔ以下のＯｐｔＣｏｓｔを有する候補ビューを含むことに注意せよ。Ｍは、Ｓｅｅｎ内にすでになく、ＰＱ中に挿入された候補だけを維持している。後に定理として提供されるＯｐｔＣｏｓｔの特性は、Ｍ内の候補ビューは、ｖのＯｐｔＣｏｓｔよりも大きいＯｐｔＣｏｓｔを有し、これらのビューは、ｖより前に試験されていない必要がある。この特性は、候補ビューの空間の漸進的な爆発的増加を可能にする。そして、ｖがＳｅｅｎに加えられる。

もしｖが完全であると推測される場合、我々は、ＲｅｗｒｉｔｅＥｎｕｍ関数を起動することによって、ｖを用いてｑのリライトを見つけようとする。ＲｅｗｒｉｔｅＥｎｕｍによって見つかった複数のリライトのうち、最も安価なリライトがＢｆＲｅｗｒｉｔｅに結果として返される。ビューｖがクエリｑについて部分的であるか完全であるかを決定するために、我々は、楽観的なアプローチを採用する。このアプローチは、ｖを用いる完全なリライトが存在するという推測を示している。これらの条件は、ｖを用いる等価リライトの存在を確認するために十分ではないが、推測は、ビューがｑのリライトに参加するために満たさなければならない、以下の必要条件を要求する。
（ａ）ｖは、ｑによって要求される全ての特性を含む、またはｖ中にないｑ中の特性を生み出すために必要な全ての特性を含む。
（ｂ）ｖは、ｑよりも弱い選択述語を含んでいる。
（ｃ）ｖは、ｑよりも凝集度が低い。

関数ＧｕｅｓｓＣｏｍｐｌｅｔｅ（ｑ，ｖ）は、これらのチェックを実行し、ｖがｑに関する特性を満たしている場合、trueを返す。有効なリライトが存在していることを特定するための要件を指定したこれらの条件下では、推測は、偽陽性となることがあるが、偽陰性になることは決してない。

ＲｅｗｒｉｔｅＥｎｕｍアルゴリズムは、完全であると推測されるビューを用いて、クエリの有効なリライトを生成しようとする。返されるリライトは、ｖを用いる全ての可能なｑの等価リライトの中で最も安価なものを示している。リライトのコストは、Ｃｏｓｔ関数によって評価され、そのリライトを実装する最も安価な実行プランに対応している。評価は、リライトおよびクエリが同じ特性、フィルタ、および分類を含むことを確認することによって決定される。

我々は、Ｌ_Ｒを用いて、完全であると推測されるビューｖに補償を適用することによって、ｑの等価リライトを列挙する。我々は、要求された補償の全ての配列を生成し、等価の試験を行うことによって、これを実行し、Ｌ_Ｒを与えられる全ての可能なリライトの総当たりの列挙となる。これは、Ｌ_Ｒの絶対値を小さく維持するシステムのためのケースを作る。Ｌ_Ｒがオペレータの既知の固定セットに制限されているとき、それは、分類を含む単純な統合の特定のケースとして、［？］中にあるように、多項式数のリライトの試みを試験するのに十分であるかもしれない。そのようなアプローチは、全体的なシステムの利益となる場合、システムがＬ_ＷからＵＤＦｓを用いてＬ_Ｒを拡張するフレキシビリティを有するべきであるようなケースに適用することができない。

有効なリライトを見つける計算コストを考慮して、ＢｆＲｅｗｒｉｔｅは、２つのストラテジーを用いて、ＲｅｗｒｉｔｅＥｎｕｍアルゴリズムの起動を制限する。まず１つ目に、我々は、上述した３つの特性に基づいて、ビューの完全性を推測する全ての候補ビュー上にＲｅｗｒｉｔｅＥｎｕｍを適用することを避ける。２つ目に、我々は、ｖを用いて、リライトのコストの下限値を決定することによって、ＲｅｗｒｉｔｅＥｎｕｍを全ての完全なビューに適用することを遅らせる。下限値について、我々は、次のセクションで説明されるＯｐｔＣｏｓｔを用いる。

システムは、それらが低コストリライトを提供する能力に基づいた候補ビューの列挙を実行する。ＯｐｔＣｏｓｔは、下限値に到達するために、Ｃｏｓｔ関数の“non-subsumable”なコスト特性に依存している。ｖがｑに関して完全であると推測されることを考慮すると、ｑおよびｖの属性、フィルタ、および分類の表現間の差異は、fixとされる。Fixは、ｑの表現内のｖの表現を変えることができる架空のローカル関数を示す。そのようなローカル関数を含むＵＤＦは、実際には存在しないであろうことに注意せよ。我々は、Ｌ_Ｒからの補償を含むリライトを生成するRewriteEnumを起動しなければならない。補償中のローカル関数の組み合わせは、ｖの表現をｑに変換する。最後に、完全であると推測されることが偽陽性をもたらし得るのと同じ理由で、fixの存在は、ｖが有効なリライトをもたらすことを保証することに注意せよ。どちらも、要求された補償動作が互いに独立してｖに適用することができると仮定する。

ＯｐｔＣｏｓｔ関数は、ＲｅｗｒｉｔｅＥｎｕｍ（ｑ，ｖ）により返されたプランのコストの下限値であり、計算が安価であるという、２つの特性を有する。ｖが実体化ビューである場合、ｃ_１は、ｖにアクセスするコストと等価である。それ以外の場合は、ｖがビューの統合の結果である場合、ｃ_１は、ｖの構成ビューにアクセスするための合計コストである。我々は、ｖが既に実体化されていない場合、ｃ_２を、ｖ内の構成ビューを統合するコスト（すなわち、作成コスト）とし、そうでなければ、既に実体化されている場合、ｃ_２＝０である。我々は、ｃ_３を、ｖ上のｆｉｘ内の動作のそれぞれを実行するコストを取得するために、Ｃｏｓｔを起動することによって得られた、ｖ上のfix内で最も安価な動作を適用するコストとする。ｘはｆｉｘ内の動作であり、ｃ_３はｍｉｎ（Ｃｏｓｔ（ｘ，ｖ））により得られる。

ｑに関するｖのＯｐｔＣｏｓｔは、ｃ＝ｃ_１＋ｃ_２＋ｃ_３によって得られる。ｃは、ｖを用いるリライトのどのプランのコストよりも小さい。ｖがｑに関して部分的である場合、どのような補償も適用されないため、ｃ_３＝０である。

最適化部は、それを実体化する前に、候補ビューｖ中に補償がプッシュされ得るプランを生成することができる。この場合、ＯｐｔＣｏｓｔは、ｖの全ての構成ビューにアクセスするコスト（ｃ_１）に加えて、ｖの任意の構成ビュー上に、または、ｖを生成するプロセス中で生成され得る中間ビュー上に、ｆｉｘ中で最も安価な動作を適用する最小コストｃ’_３だけを考慮できるように、弱い下限を提供することができる。ｖがｑに関して部分的である場合、ＯｐｔＣｏｓｔは、ｃ_１のみを含む。一般的に、ｃは、存在する場合、ｖを用いたｑの等価リライトｒにより生み出される任意のプランのコストの下限である。最低コストｒを見つけるために、ＲｅｗｒｉｔｅＥｎｕｍは、等価リライトを達成するために、補償動作の全ての配列を適用する。いくつの動作が補償に用いられたかに関わらず、定義１によって、補償を適用するコストは、少なくとも、ｆｉｘ中で最も安価な動作ｃ_３と同じくらい高価である。

次に、ＯｐｔＣｏｓｔ関数は、補償のプッシュダウンを含むケースについて分析される。この場合、ｖの構成ビューの統合の順序も、適用可能な補償も両方まだ知られていない。下限は、ｒの任意のプラン（すなわち、ｃ’_３）中の任意の補償オペレータの位置だけでなく、ｖ中の（すなわち、ｃ_１を用いることによって）構成ビューの順序についていかなる仮定もつくらないように、維持する。Ｓｅｅｎ中に存在しないＭ中の全ての候補ビューのＯｐｔＣｏｓｔは、ｖのＯｐｔＣｏｓｔ以上である。

アルゴリズム１−４のための疑似コードを以下に示す。

上記の方法は、日和見主義的な実体化ビューにとって、大規模なデータ分析システムにおいて、クエリを大幅に高速化するという利点を有する。仕事効率は良好であるが、ＵＤＦモデルおよび下限ＯｐｔＣｏｓｔ関数を活用して、ＢｆＲｅｗｒｉｔｅアルゴリズムは、最適なリライトを生成する。現実的なシナリオと、平均６１％で、２ケタ以上の大きさで、実証された劇的なパフォーマンス改善についての様々な進化的なクエリ。システムは、保持するために最も有益なビューを識別することができる。ビューを保持するストラテジーは、これらの決定がビューメンテナンスコストにより影響を受けていることを考慮して、全体的なシステムの利益の観点から、開発され得る。

本発明は、ハードウェア、ファームウェア、またはソフトウェア中で、或いは、この３つの組み合わせにより、実装することができる。好ましくは、本発明は、プロセッサ、データストレージシステム、揮発性および非揮発性メモリおよび／またはストレージエレメンツ、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを有する、プログラム可能なコンピュータ上で実行される、コンピュータプログラム中で実装される。

一例として、このシステムをサポートするコンピュータのブロック図が次に説明される。コンピュータは、好ましくは、プロセッサ、ランダムアクセスメモリ（ＲＡＭ）、プログラムメモリ（好ましくは、フラッシュＲＯＭのような、書き込み可能なリードオンリーメモリ（ＲＯＭ））およびＣＰＵバスによって接続された入力／出力（Ｉ／Ｏ）コントローラを含む。コンピュータは、必要に応じて、ハードディスクおよびＣＰＵバスに接続されたハードドライブコントローラを含んでもよい。ハードディスクは、本発明のような、アプリケーションプログラムおよびデータを格納するために用いることができる。代わりに、アプリケーションプログラムは、ＲＡＭまたはＲＯＭに格納されてもよい。Ｉ／Ｏコントローラは、Ｉ／Ｏバスを用いてＩ／Ｏインタフェースに接続される。Ｉ／Ｏインタフェースは、アナログまたはデジタルの形で、シリアルリンク、ローカルエリアネットワーク、無線リンク、およびパラレルリンクのような通信リンク上でデータを受信し、送信する。必要に応じて、ディスプレイ、キーボード、およびポインティングデバイス（マウス）がまたＩ／Ｏバスに接続されてもよい。代わりに、別個のコネクション（別個のバス）がＩ／Ｏインタフェース、ディスプレイ、キーボード、およびポインティングデバイスのために用いられてもよい。プログラム可能なプロセッシングシステムは、予めプログラムされていてもよいし、他のソース（例えば、フロッピーディスク、ＣＤ−ＲＯＭ、または他のコンピュータ）からプログラムをダウンロードすることによって、プログラム（および再プログラム）されてもよい。

各コンピュータプログラムは、記憶媒体またはデバイスがここに記述された手順を実行するために、コンピュータに読み込まれたときに、コンピュータの動作を構成し、制御するために、実体的に、一般的なまたは特定の目的のプログラム可能なコンピュータによって読み込み可能な、機械可読記憶媒体またはデバイス（例えば、プログラムメモリまたは磁気ディスク）中に明白に格納される。本発明のシステムはまた、コンピュータプログラムを用いて構成され、コンピュータ可読記憶媒体中で具現化され、記憶媒体がそのように構成されるため、コンピュータは特定の所定の方法で、ここに記述された機能を実行するように動作する。

当業者は、本発明の広範な教示が多様な形態で実現することができることを、上述の説明から理解することができる。理解できるように、開示され、特許請求された方法のステップは、本発明の精神から逸脱することなく、ここに開示され、特許請求された順序とことなる順序で実行することができる。したがって、本発明は、特定の例に関連して説明されてきたが、図面、明細書、および下記の特許請求の範囲を検討すれば、他の修正が、当業者に明らかとなるであろうため、本発明の真の範囲は、そのように限定されるべきでない。

Claims (21)

1. 進化的なクエリをサポートする方法であって、
   以前のクエリまたはワークフロー実行結果である実体化ビューから、アーチファクトを保持することと、
   ユーザ定義関数（ＵＤＦ）のリライトのサーチをサポートするために、前記ＵＤＦのグレーボックスモデルを提供することと、
   ワークフロー実行時間を低減するために、アーチファクトを用いるリライトを自動的に生成することと、
   リライトの空間を徐々にサーチして、候補ビューの空間をより大きくし、最適なリライトを見つけるためのソリューション空間の最小量をサーチすることと、を含む方法。
2. 請求項１に記載の方法であって、
   ワークフローの進化、ユーザの進化、およびデータの進化を含む、３つの側面に沿った同時進化をサポートすることを含む、方法。
3. 請求項１に記載の方法であって、
   前記ＵＤＦを含むようにリライト言語を拡張することを含む、方法。
4. 請求項１に記載の方法であって、
   ｒ_ｉが候補ビューｖを用いるＷ_ｉのリライトであり、下限の特性が、ＯｐｔＣｏｓｔ（Ｗ_ｉ，ｖ）≦Ｃｏｓｔ（ｒ_ｉ）として決定される場合に、候補ビューｖおよびターゲットＷ_ｉを入力として取得し、ｖを用いるＷ_ｉのリライトｒ_ｉの下限を提供する、最適コスト関数ＯｐｔＣｏｓｔ（Ｗ_ｉ，ｖ）を決定すること、を含む方法。
5. 請求項４に記載の方法であって、
   ＯｐｔＣｏｓｔによって順序付けられた複数の候補ビューのサーチ空間を生成することと、
   次の候補ビューのＯｐｔＣｏｓｔを提供することと、
   前記次の候補ビューを用いて前記ターゲットのリライトを決定することと、を含む方法。
6. 請求項１に記載の方法であって、
   Ｗ内の全てのターゲットについてリライトの効率的なサーチを実行し、Ｗ_ｎについて全体的に最適なリライトを出力し、
   単一のターゲットについて、１または複数の候補ビューを、それらが前記ターゲットの低コストリライトを生成する能力に基づいて列挙することによって、
   Ｗの前記最適なリライトｒ^*を決定することを含む方法。
7. 請求項１に記載の方法であって、
   Ｗ内の複数のターゲットにおいて見つかった複数のリライトからなるＷのリライトｒ^*を生成することを含み、その間に、計算されたリライトｒ^*が同じクラス内の複数のリライトのうち最小コストを有する、方法。
8. 請求項１に記載の方法であって、
   Ｗをプランに対するリライトとして用いることと、
   ｎ個の同時サーチ問題をＷ内の各ターゲットにおいて生成して、より良いリライトを繰り返し探索することと、その間に、各繰り返しが１つのターゲットＷｉを選択し、Ｗｉにおける候補ビューを試験し、
   Ｗ内の他のターゲットの探索空間を削る結果、前記より良いリライトを用いることと、を含む方法。
9. 請求項１に記載の方法であって、
   非構造化データセット上でＵＤＦｓの実行を最適化することを含む方法。
10. 請求項１に記載の方法であって、
    ユーザワークフローの進化について最適化することを含む方法。
11. 進化的な分析クエリをサポートするシステムであって、
    クエリを受信し、前記クエリを実行プランに変換する最適化部と、
    ワークフローの進化、ユーザの進化、およびデータの進化を含む３つの側面に沿った同時進化をサポートするために前記最適化部と接続されたクエリリライト部と、
    前記クエリリライト部と接続され、クエリ最適化において用いられる、ビュー定義および標準データ統計値を含む実体化ビューに関する情報を収容する実体化ビューメタデータ格納部と、
    前記クエリを実行するために前記クエリリライト部と接続されたクエリ実行エンジンと、を有するシステム。
12. 請求項１１に記載のシステムであって、
    クエリは、大規模なログと、ＵＤＦｓを含むクエリとを含む基本データに対して表現される、システム。
13. 請求項１１に記載のシステムであって、
    前記最適化部は、システムに認められたＵＤＦｓについてのコスト推定値を提供する、システム。
14. 請求項１１に記載のシステムであって、
    前記最適化部は、各プランノードにおける２つのタイプの注釈：（１）計算の論理表現および（２）推定された実行コストを有するプランを生成する、システム。
15. 請求項１４に記載のシステムであって、
    前記リライト部は、ノードの出力に対するリライトを探索するとき、前記注釈中の前記論理表現を用いる、システム。
16. 請求項１５に記載のシステムであって、
    前記論理表現は、ＵＤＦｓの関係オペレータからなる、システム。
17. 請求項１５に記載のシステムであって、
    前記ノードの出力に対するリライトの探索の間に見つかったリライトのそれぞれについて、前記リライト部はプランおよび推定コストを取得するために前記最適化部を利用する、システム。
18. 請求項１１に記載のシステムであって、
    クエリ実行の間のクエリ処理の副産物が、日和見主義的な実体化ビューとして維持され、日和見主義的な物理設計構造として格納される、システム。
19. 請求項１１に記載のシステムであって、
    候補ビューｖおよびターゲットＷｉを入力として取得し、Ｗｉのリライトｒｉの下限をｖを用いて提供し、ｒｉが、前記候補ビューｖを用いるＷｉのリライトであり、前記下限の特性がＯｐｔＣｏｓｔ（Ｗｉ，ｖ）≦Ｃｏｓｔ（ｒｉ）として決定される楽観的コスト関数Ｏｐｔを決定するためのコンピュータコードを含む、システム。
20. 請求項１９に記載のシステムであって、
    前記ＯｐｔＣｏｓｔによって順序付けられた複数の候補ビューの探索空間を生成し、次の候補ビューの前記ＯｐｔＣｏｓｔを提供し、前記次の候補ビューを用いて前記ターゲットのリライトを決定するためのコンピュータコードを含む、システム。
21. 請求項１１に記載のシステムであって、
    Ｗをプランに対するリライトとして用い、
    ｎ個の同時サーチ問題をＷ内の各ターゲットにおいて生成して、より良いリライトを繰り返して探索し、その間に、各繰り返しが１つのターゲットＷｉを選択し、Ｗｉにおける候補ビューを試験し、
    他のターゲットの探索空間を削る結果、前記より良いリライトを用いるためのコンピュータコードを含むシステム。
    
    

Images