特許 7431902 リソース管理システム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-02-06

(45)【発行日】2024-02-15

(54)【発明の名称】リソース管理システム及び方法

(51)【国際特許分類】

   G06F 16/172 20190101AFI20240207BHJP

【ＦＩ】

G06F16/172

【請求項の数】 14

(21)【出願番号】P 2022129785

(22)【出願日】2022-08-17

(62)【分割の表示】P 2019211737の分割

【原出願日】2015-02-18

(65)【公開番号】P2022166198

(43)【公開日】2022-11-01

【審査請求日】2022-08-17

(31)【優先権主張番号】61/941,986

(32)【優先日】2014-02-19

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】14/518,884

(32)【優先日】2014-10-20

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】516245999

【氏名又は名称】スノーフレーク インク．

(74)【代理人】

【識別番号】100121083

【弁理士】

【氏名又は名称】青木 宏義

(74)【代理人】

【識別番号】100138391

【弁理士】

【氏名又は名称】天田 昌行

(74)【代理人】

【識別番号】100074099

【弁理士】

【氏名又は名称】大菅 義之

(72)【発明者】

【氏名】ダジュヴィル，ブノワット

(72)【発明者】

【氏名】クルアネス，ティエリー

(72)【発明者】

【氏名】ズコウスキー，マーシン

【審査官】吉田 誠

(56)【参考文献】

【文献】特開２００９－０１５５３４（ＪＰ，Ａ）

【文献】特開２０１２－０４３０９８（ＪＰ，Ａ）

【文献】特開２００２－２９７４２８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００ － １６／９５８

(57)【特許請求の範囲】

【請求項1】

メモリと、
前記メモリに動作可能に結合された処理デバイスと、
を備えるシステムであって、
前記処理デバイスは、
複数の実行ノードを提供することであって、各実行ノードはキャッシュ及びプロセッサを含み、各実行ノードはストレージプラットフォームに通信可能に結合される、ことと、
受信されたクエリを処理することに関連付けられた少なくとも１つのタスクが前記ストレージプラットフォームに記憶されたデータベースデータを参照すると判定することと、
前記受信されたクエリを処理することに関連付けられた前記少なくとも１つのタスクを処理するために、前記複数の実行ノード内に新たな実行ノードを作成することと、
を行う、システム。

【請求項2】

前記ストレージプラットフォームは複数のストレージデバイスを含み、
前記複数の実行ノードの各々は、前記複数のストレージデバイスのサブセットに通信可能に結合される、請求項１に記載のシステム。

【請求項3】

前記処理デバイスは、更に、前記複数の実行ノードのそれぞれの前記キャッシュ内にキャッシュされた、前記データベースデータの部分を判定する、請求項１に記載のシステム。

【請求項4】

前記少なくとも１つのタスクは、第１のタスク及び第２のタスクを含み、
前記処理デバイスは、
前記複数の実行ノードのうちの第１の実行ノードの前記キャッシュに記憶された前記データベースデータの第１の部分を前記第１のタスクが参照すると判定したことに応答して、前記受信されたクエリの前記第１のタスクを前記第１の実行ノードに割り当てることと、
前記受信されたクエリの前記第２のタスクを前記新たな実行ノードに割り当てることと、
を更に行う、請求項１に記載のシステム。

【請求項5】

前記複数の実行ノードのうちの複数の実行ノードのそれぞれの前記キャッシュが、前記データベースデータの同じ部分を同時にキャッシュする、請求項１に記載のシステム。

【請求項6】

複数の実行ノードを提供することであって、各実行ノードはキャッシュ及びプロセッサを含み、各実行ノードはストレージプラットフォームに通信可能に結合される、ことと、
受信されたクエリを処理することに関連付けられた少なくとも１つのタスクが前記ストレージプラットフォームに記憶されたデータベースデータを参照すると判定することと、
前記受信されたクエリを処理することに関連付けられた前記少なくとも１つのタスクを処理するために、処理デバイスによって、前記複数の実行ノード内に新たな実行ノードを作成することと、
を含む方法。

【請求項7】

前記ストレージプラットフォームは複数のストレージデバイスを含み、
前記複数の実行ノードの各々は、前記複数のストレージデバイスのサブセットに通信可能に結合される、請求項６に記載の方法。

【請求項8】

前記複数の実行ノードのそれぞれの前記キャッシュ内にキャッシュされた、前記データベースデータの部分を判定すること、を更に含む、請求項６に記載の方法。

【請求項9】

前記少なくとも１つのタスクは、第１のタスク及び第２のタスクを含み、
前記方法は、
前記複数の実行ノードのうちの第１の実行ノードの前記キャッシュに記憶された前記データベースデータの第１の部分を前記第１のタスクが参照すると判定したことに応答して、前記受信されたクエリの前記第１のタスクを前記第１の実行ノードに割り当てることと、
前記受信されたクエリの前記第２のタスクを前記新たな実行ノードに割り当てることと、
を更に含む、請求項６に記載の方法。

【請求項10】

前記複数の実行ノードのうちの複数の実行ノードのそれぞれの前記キャッシュが、前記データベースデータの同じ部分を同時にキャッシュする、請求項６に記載の方法。

【請求項11】

命令を記憶した非一時的コンピュータ可読媒体であって、前記命令は、処理デバイスによって実行された時に、
複数の実行ノードを提供することであって、各実行ノードはキャッシュ及びプロセッサを含み、各実行ノードはストレージプラットフォームに通信可能に結合される、ことと、
受信されたクエリを処理することに関連付けられた少なくとも１つのタスクが前記ストレージプラットフォームに記憶されたデータベースデータを参照すると判定することと、
前記受信されたクエリを処理することに関連付けられた前記少なくとも１つのタスクを処理するために、前記処理デバイスによって、前記複数の実行ノード内に新たな実行ノードを作成することと、
を前記処理デバイスに行わせる、非一時的コンピュータ可読媒体。

【請求項12】

前記ストレージプラットフォームは複数のストレージデバイスを含み、
前記複数の実行ノードの各々は、前記複数のストレージデバイスのサブセットに通信可能に結合される、請求項１１に記載の非一時的コンピュータ可読媒体。

【請求項13】

前記少なくとも１つのタスクは、第１のタスク及び第２のタスクを含み、
前記処理デバイスは、
前記複数の実行ノードのうちの第１の実行ノードの前記キャッシュに記憶された前記データベースデータの第１の部分を前記第１のタスクが参照すると判定したことに応答して、前記受信されたクエリの前記第１のタスクを前記第１の実行ノードに割り当てることと、
前記受信されたクエリの前記第２のタスクを前記新たな実行ノードに割り当てることと、
を更に行う、請求項１１に記載の非一時的コンピュータ可読媒体。

【請求項14】

前記複数の実行ノードのうちの複数の実行ノードのそれぞれの前記キャッシュが、前記データベースデータの同じ部分を同時にキャッシュする、請求項１１に記載の非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

＜関連出願への参照＞
この出願は、２０１４年２月１９日出願の“Apparatus and method for enterprise data warehouse data processing on cloud infrastructure”という名称の米国仮出願第６１／９４１，９８６号の利益を主張し、その開示内容の全体は、ここに、参照によって組み込まれる。

【0002】

＜技術分野＞
本開示は、データストレージ及びコンピューティングリソースを管理する、リソース管理システム及び方法に関する。

【背景技術】

【0003】

今日、多くの既存のデータ格納・取得（retrieval）システムが利用可能である。例えば、共有ディスクシステムにおいては、すべてのデータは、データクラスタ内のすべての処理ノードからアクセス可能な共有ストレージデバイス上に格納される。この種類のシステムにおいては、すべてのデータ変更は、データクラスタ内のすべての処理ノードが、整合性のあるバージョンのデータにアクセスすることを保証するために、共有ストレージデバイスに書き込まれる。共有ディスクシステムにおいて、処理ノードの数が増加するに連れて、共有ストレージデバイス（及び、処理ノードと共有ストレージデバイスとの間の通信リンク）は、データの読み取り動作及びデータの書き込み動作を遅くするボトルネックとなる。このボトルネックは、更なる処理ノードを追加するに連れて、更に悪化する。従って、既存の共有ディスクシステムには、このボトルネック問題により、限定的なスケーラビリティしかない。

【0004】

他の既存のデータ格納・取得システムは、「シェアドナッシング（無共有型）アーキテクチャ（shared-nothing architecture）」と呼ばれる。このアーキテクチャにおいては、各ノードがデータベース全体のうちのデータの部分集合を格納するように、データが複数の処理ノードに渡って分散される。新規の処理ノードが追加あるいは除去されるとき、シェアドナッシングアーキテクチャは、複数の処理ノードに渡って、データを再配置しなければならない。このデータの再配置は、時間がかかるものとなったり、データ再配置の間に実行されるデータ読み書きの動作を妨害したりする可能性がある。そして、データの特定のノードに対する親和性は、良く使われるデータに関して、データクラスタ上で、「ホットスポット」を形成しうる。更に、各処理ノードがストレージ機能も実行するので、このアーキテクチャは、少なくとも１つの処理ノードがデータを格納することを要する。従って、シェアドナッシングアーキテクチャは、すべての処理ノードが取除かれると、データを格納することが出来ない。更に、シェアドナッシングアーキテクチャにおけるデータの管理は、多くの異なる処理ノードに渡るデータの分散のせいで、複雑である。

【発明の概要】

【0005】

ここに記述されるシステム及び方法は、既存のシステムの上記制限を軽減する、データ格納及びデータ取得に対する改善された手法を提供する。そのための本発明の一態様に係るシステムは、メモリと、前記メモリに動作可能に結合された処理デバイスと、を備えるシステムであって、前記処理デバイスは、複数の実行ノードを提供することであって、各実行ノードはキャッシュ及びプロセッサを含み、各実行ノードはストレージプラットフォームに通信可能に結合される、ことと、受信されたクエリを処理することに関連付けられた少なくとも１つのタスクが前記ストレージプラットフォームに記憶されたデータベースデータを参照すると判定することと、前記受信されたクエリを処理することに関連付けられた前記少なくとも１つのタスクを処理するために、前記複数の実行ノード内に新たな実行ノードを作成することと、を行う。また、本発明の一態様に係る方法は、複数の実行ノードを提供することであって、各実行ノードはキャッシュ及びプロセッサを含み、各実行ノードはストレージプラットフォームに通信可能に結合される、ことと、受信されたクエリを処理することに関連付けられた少なくとも１つのタスクが前記ストレージプラットフォームに記憶されたデータベースデータを参照すると判定することと、前記受信されたクエリを処理することに関連付けられた前記少なくとも１つのタスクを処理するために、処理デバイスによって、前記複数の実行ノード内に新たな実行ノードを作成することと、を含む。

【図面の簡単な説明】

【0006】

本開示の非限定的且つ非網羅的な実施形態が、以下の図面を参照して記述され、図面においては、同様な参照番号は、特に断らない限り、様々な図面の全体に渡って、同様な部分を指す。

【0007】

【図1】ここに記述するシステム及び方法の例示的実施形態を図示するブロック図である。

【図2】リソースマネージャの実施形態を図示するブロック図である。

【図3】実行プラットフォームの実施形態を図示するブロック図である。

【図4】複数の仮想ウェアハウスを介して複数のデータベースにアクセスする複数のユーザがいる、例示的動作環境を図示するブロック図である。

【図5】ロードバランサと、仮想ウェアハウスグループに含まれる複数の仮想ウェアハウスとを介して、複数のデータベースにアクセスする複数のユーザがいる、他の例示的動作環境を図示するブロック図である。

【図6】複数の分散した仮想ウェアハウスと仮想ウェアハウスグループとを有する他の例示的動作環境を図示するブロック図である。

【図7】データ格納・取得動作を管理する方法の実施形態を図示するフロー図である。

【図8】例示的コンピューティングデバイスを図示するブロック図である。

【発明を実施するための形態】

【0008】

ここに記述されるシステム及び方法は、既存のシステムが直面する問題なしに、データを格納し、取得するための、新規のプラットフォームを提供する。例えば、この新規のプラットフォームは、シェアドナッシングアーキテクチャによって要求されるようなデータファイルの再配置の必要なしに新規のノードを追加することをサポートする。更に、共有ディスクシステムにおいて一般的なボトルネックを作り出すことなく、ノードをプラットフォームに追加することが可能である。この新規のプラットフォームは、たとえノードのうちのいくつかが、メンテナンスのためにオフラインであったり、または障害に見舞われたりしている場合でも、データ読み取り動作及びデータ書き込み動作のために、常に利用可能である。記述されるプラットフォームは、専用コンピューティングリソースの使用を必要とせずにデータを格納することができるように、データストレージリソースをコンピューティングリソースから分離する。これは、すべてのコンピューティングリソースが除去されるとデータを格納することが出来ない、シェアドナッシングアーキテクチャに対する、改善点である。従って、新規のプラットフォームは、たとえコンピューティングリソースがもはや利用できない、あるいは、他のタスクを実行している場合であっても、データを格納し続ける。

【0009】

以下の記述においては、その一部をなす添付図面を参照し、添付図面においては、例示として、本開示を実施しうる特定の例示的実施形態を示す。これらの実施形態は、当業者が、ここに開示のコンセプトを実施することが出来るように、十分に詳細に記述されており、また、本開示の範囲を外れることなく、様々な開示された実施形態への変更をすることができ、他の実施形態が利用可能であることを理解されたい。従って、以下の詳細な記述は、限定的な意味に取られるべきではない。

【0010】

この明細書全体に渡って、「一実施形態」、「実施形態」、「一例」あるいは「例」への言及は、その実施形態あるいは例に関連して記述される特定のフィーチャ、構造、あるいは、特性が、少なくとも、本開示の１つの実施形態に含まれることを意味する。従って、この明細書全体に渡る様々な場所における「一実施形態において」、「実施形態において」、「一例」あるいは「例」といった語句の出現は、必ずしも全てが同一の実施形態あるいは例を示すわけではない。更に、ここに提供する図面は、当業者への説明目的のものであり、図面は、必ずしも同一スケールでは描かれていない、ということがよく理解されるべきである。

【0011】

本開示による実施形態は、装置、方法、あるいは、コンピュータプログラム製品として実体化され得る。従って、本開示は、本明細書においてはどれも一般的に「回路」、「モジュール」あるいは「システム」と呼ばれることがある、完全にハードウェアで構成された実施形態、完全にソフトウェアで構成された実施形態（ファームウェア、常駐ソフトウェア、マイクロコード、などを含む）、あるいは、ソフトウェアとハードウェアの側面を組み合わせた実施形態、という形態を取ることが出来る。更に、本開示の実施形態は、媒体内に具現化されたコンピュータ利用可能なプログラムコードを有する、任意の有形的表現媒体に具現化された、コンピュータプログラム製品の形態を取ることが出来る。

【0012】

１以上のコンピュータ利用可能、あるいは、コンピュータ読み取り可能な媒体の、任意の組み合わせが利用されてもよい。例えば、コンピュータ読み取り可能な媒体は、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（RAM）デバイス、リードオンリーメモリ（ROM）デバイス、消去可能プログラマブルリードオンリーメモリ（EPROMあるいはフラッシュメモリ）デバイス、ポータブルコンパクトディスクリードオンリーメモリ（CDROM）、光ストレージデバイス、及び、磁気ストレージデバイスのうちの１つ以上を含むことが出来る。本開示の動作を実行するためのコンピュータプログラムコードは、１以上のプログラミング言語の任意の組み合わせで書かれてもよい。そのようなコードは、ソースコードから、コードが実行されるであろう装置またはコンピュータに適した、コンピュータ読み取り可能なアセンブリ言語またはマシンコードに、コンパイルされてもよい。

【0013】

実施形態は、また、クラウドコンピューティング環境に実装されてもよい。本明細書及び以下の請求項においては、「クラウドコンピューティング」は、仮想化によってすぐに提供可能であり、かつ、最小の管理負担あるいはサービスプロバイダとの最小の相互作用だけでリリースすることが出来、その後で然るべく規模の変更が出来るような、コンフィギュラブルなコンピューティングリソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、及びサービスなど）の共有プールへの、ユビキタスで、便利で、オンデマンド方式のネットワークアクセスを可能にするためのモデルとして、規定されることがある。クラウドモデルは、様々な特性（例えば、オンデマンド方式のセルフサービス、広範なネットワークアクセス、リソースプーリング、迅速な柔軟性、及び、測定されるサービス（measured service）など）、サービスモデル（例えば、ソフトウェアアズアサービス（“SaaS”）、プラットフォームアズアサービス（“PaaS”）、及び、インフラストラクチャアズアサービス（“IaaS”）など）、並びに、展開モデル（例えば、プライベートクラウド、コミュニティクラウド、パブリッククラウド、及び、ハイブリッドクラウドなど）で構成され得る。

【0014】

添付の図面中のフロー図、及び、ブロック図は、本開示の様々な実施形態による、システム、方法、及び、コンピュータプログラム製品の、可能な実装の、アーキテクチャ、機能、及び、動作を図示する。この点について、フロー図あるいはブロック図における各ブロックは、コードの、モジュールかセグメントか又は一部を表すことがあり、そのコードとは、特定された論理機能を実装するための１以上の実行可能な命令を含むものである。ブロック図及び／またはフロー図の各ブロックや、ブロック図及び／またはフロー図におけるブロックの組み合わせは、指定された機能または動作を実行する専用ハードウェアベースのシステムによって実装されてもよく、あるいは、専用ハードウェアとコンピュータ命令との組み合わせによって実装されてもよい、ということにも注意されたい。これらのコンピュータプログラム命令も、特定の方法で機能するようコンピュータあるいは他のプログラマブルなデータ処理装置に対して命令することのできるコンピュータ読み取り可能な媒体に格納されることがあり、その結果、コンピュータ読み取り可能な媒体に格納された命令は、フロー図及び／またはブロック図の一つのブロックあるいは複数のブロックにおいて指定される機能／動作を実装する命令手段を含む製造製品を作り出す。

【0015】

ここに記述されるシステム及び方法は、新規のデータ処理プラットフォームを用いたフレキシブル且つスケーラブルなデータウェアハウスを提供する。幾つかの実施形態においては、記述されたシステム及び方法は、クラウドベースのストレージリソースやコンピューティングリソースなどをサポートするクラウドインフラストラクチャを活用する。例示的なクラウドベースのストレージリソースは、低価格で、オンデマンドで利用可能な、相当量のストレージ容量を提供する。更に、これらのクラウドベースのストレージリソースは、フォールトトレラントでもあり得るし、高度にスケーラブルでもあり得るが、そうしたことは、プライベートなデータストレージシステムでは達成するのに高くつく可能性がある。例示的なクラウドベースのコンピューティングリソースは、オンデマンドで利用でき、また、リソースの実際の使用レベルに基づいて、課金されてもよい。典型的には、クラウドインフラストラクチャは、迅速な方法で、動的に、展開、再構成、及び、解体される。

【0016】

記述したシステム及び方法においては、データストレージシステムは、SQL （Structured Query Language）ベースのリレーショナルデータベースを利用する。しかし、これらのシステム及び方法は、任意のデータストレージアーキテクチャを用いて、また、データ格納・取得プラットフォーム内でデータを格納・取得するための任意の言語を用いて、任意のタイプのデータベース及び任意のタイプのデータ格納・取得プラットフォームに適用可能である。ここに記述されるシステム及び方法は、更に、異なる顧客／クライアント間、及び、同一の顧客／クライアント内の異なるユーザ間でのコンピューティングリソース及びデータの隔離をサポートする、マルチテナントシステムを提供する。

【0017】

図１は、新規のデータ処理プラットフォーム１００の例示的実施形態を図示するブロック図である。図１に示されるように、リソースマネージャ１０２は、複数のユーザ１０４、１０６、及び１０８に結合される。特定の実装においては、リソースマネージャ１０２は、データ処理プラットフォーム１００にアクセスしたい任意の人数のユーザをサポートすることが出来る。ユーザ１０４～１０８は、例えば、データ格納・取得の要求を与えるエンドユーザや、ここで記述するシステム及び方法を管理するシステム管理者や、リソースマネージャ１０２と相互作用する他のコンポーネント／デバイスなどを含むことが出来る。リソースマネージャ１０２は、データ処理プラットフォーム１００内のすべてのシステム及びコンポーネントの動作をサポートする、様々なサービス及び機能を提供する。本明細書で用いられるように、リソースマネージャ１０２は、本明細書で議論するような様々な機能を実行する「グローバルサービスシステム」と呼ばれることもある。

【0018】

リソースマネージャ１０２は、また、データ処理プラットフォーム１００全体に渡って格納されたデータ全体に関連付けられた、メタデータ１１０にも結合される。幾つかの実施形態においては、メタデータ１１０は、ローカルキャッシュから得られるデータについてだけはでなく、リモートデータストレージシステムに格納されたデータについての概要も含む。更に、メタデータ１１０は、データがどのようにリモートデータストレージシステムとローカルキャッシュにおいて組織化されるかについての情報を含むことが出来る。メタデータ１１０により、システム及びサービスは、ある１つのデータをロードせずに入手する必要があるのか、それとも、ストレージデバイスから実際のデータを入手するのかを、判定することが出来る。

【0019】

リソースマネージャ１０２は、更に実行プラットフォーム１１２に結合され、これは、以下により詳しく議論するように、様々なデータ格納タスク及びデータ取得タスクを実行する複数のコンピューティングリソースを提供する。実行プラットフォーム１１２は、ストレージプラットフォーム１１４の一部である、複数のデータストレージデバイス１１６、１１８、１２０に結合される。３つのデータストレージデバイス１１６、１１８、及び１２０が、図１に示されているが、実行プラットフォーム１１２は、任意の数のデータストレージデバイスと通信することが出来る。幾つかの実施形態においては、データストレージデバイス１１６、１１８、及び１２０は、１箇所以上の地理的場所に配置されたクラウドベースのストレージデバイスである。例えば、データストレージデバイス１１６、１１８、及び１２０は、パブリッククラウドインフラストラクチャあるいはプライベートクラウドインフラストラクチャの一部とすることが出来る。データストレージデバイス１１６、１１８、及び１２０は、ハードディスクドライブ（HHD）、ソリッドステートドライブ（SSD）、ストレージクラスタ、Amazon S3（商標）ストレージシステム、あるいは、任意の他のデータストレージ技術とすることが出来る。更に、ストレージプラットフォーム１１４は、分散ファイルシステム（Hadoop Distributed File Systems (HDFS)など）、オブジェクトストレージシステムなどを含むことが出来る。

【0020】

特定の実施形態においては、リソースマネージャ１０２と、ユーザ１０４～１０８やメタデータ１１０や実行プラットフォーム１１２との間の通信リンクは、１以上のデータ通信ネットワークを介して、実装される。同様に、実行プラットフォーム１１２とストレージプラットフォーム１１４内のデータストレージデバイス１１６～１２０との間の通信リンクは、１以上のデータ通信ネットワークを介して、実装される。これらのデータ通信ネットワークは、任意の通信プロトコル及び任意のタイプの通信媒体を利用することが出来る。幾つかの実施形態においては、データ通信ネットワークは、相互に結合した２以上のデータ通信ネットワーク（あるいは、サブネットワーク）の組み合わせである。別の実施形態においては、これらの通信リンクは、任意のタイプの通信媒体及び任意の通信プロトコルを用いて実装される。

【0021】

図１に示されるように、データストレージデバイス１１６、１１８、及び１２０は、実行プラットフォーム１１２に関連付けられたコンピューティングリソースから分離されている。このアーキテクチャは、データ処理プラットフォーム１００にアクセスするユーザ及びシステムの変化するニーズだけでなく、変化するデータ格納／取得ニーズにも基づいて、データ処理プラットフォーム１００に対するダイナミックな変更をサポートする。ダイナミックな変更のサポートにより、データ処理プラットフォーム１００は、データ処理プラットフォーム１００内のシステムとコンポーネントへの変化する要求に応じて、迅速に規模を変更することが出来る。コンピューティングリソースのデータストレージデバイスからの分離は、対応する大量のコンピューティングリソースを必要とせずに大量のデータを格納することを、サポートする。同様に、リソースのこの分離は、利用可能なデータストレージリソースの対応する増加を必要とせずに、特定の時刻において利用されているコンピューティングリソースを著しく増加させることを、サポートする。

【0022】

リソースマネージャ１０２、メタデータ１１０、実行プラットフォーム１１２、及びストレージプラットフォーム１１４は、図１において、個別のコンポーネントとして図示されている。しかし、リソースマネージャ１０２、メタデータ１１０、実行プラットフォーム１１２、及びストレージプラットフォーム１１４のぞれぞれは、分散システムとして実装されてもよい（例えば、複数の地理的場所にある複数のシステム／プラットフォームに渡って分散される、などでもよい）。更に、リソースマネージャ１０２、メタデータ１１０、実行プラットフォーム１１２、及びストレージプラットフォーム１１４のそれぞれを、ユーザ１０４～１０８から受信する要求の変化、及びデータ処理プラットフォーム１００の変化するニーズに応じて、（相互に独立に）スケールアップまたはスケールダウンすることが出来る。従って、記述された実施形態においては、データ処理プラットフォーム１００は、ダイナミックであり、現在のデータ処理ニーズを満たすための定期的変更をサポートする。

【0023】

典型的な動作の間、データ処理プラットフォーム１００は、任意のユーザ１０４～１０８から受信される複数のクエリ（あるいは要求）を処理する。これらのクエリは、いつ、及び、どのように、これらのクエリを実行するかを決定するために、リソースマネージャ１０２によって管理される。例えば、リソースマネージャ１０２は、どのデータが、クエリを処理するために必要とされるかを判定してもよく、更に、実行プラットフォーム１１２内のどのノードがクエリを処理するのにもっとも向いているかを判定してもよい。幾つかのノードが、クエリを処理するのに必要なデータを既にキャッシュに持っていることもあり、従って、そのクエリを処理するための良い候補となる。実行プラットフォーム１１２内のどのノードが、クエリを処理するのに必要なデータの少なくとも一部を既にキャッシュに持っているかを、リソースマネージャ１０２が判定する上で、メタデータ１１０が役立つ。実行プラットフォーム１１２内の１以上のノードは、当該ノードによってキャッシュされたデータと、必要なら、ストレージプラットフォーム１１４から取得されたデータとを用いて、クエリを処理する。典型的には、ストレージプラットフォーム１１４からデータを取得するよりもずっと取得速度が速いので、できるだけ多くのデータを実行プラットフォーム１１２内のキャッシュから取得することが望ましい。

【0024】

図１に示されるように、データ処理プラットフォーム１００は、ストレージプラットフォーム１１４から実行プラットフォーム１１２を分離する。この配置においては、実行プラットフォーム１１２内の処理リソースとキャッシュリソースは、ストレージプラットフォーム１１４内のデータストレージリソース１１６～１２０と独立に動作する。従って、コンピューティングリソースとキャッシュリソースは、特定のデータストレージリソース１１６～１２０には限定されない。むしろ、すべてのコンピューティングリソースとすべてのキャッシュリソースは、ストレージプラットフォーム１１４内のデータストレージリソースの任意のものからデータを取得し得るし、そこへデータを格納することが出来る。更に、データ処理プラットフォーム１００は、ストレージプラットフォーム１１４に対して何も変更を要求しないで、実行プラットフォーム１１２へ新規のコンピューティングリソースとキャッシュリソースを追加することを、サポートする。同様に、データ処理プラットフォーム１００は、実行プラットフォーム１１２内のノードに何も変更を要求することなく、ストレージプラットフォーム１１４へデータストレージリソースを追加することを、サポートする。

【0025】

図２は、リソースマネージャ１０２の実施形態を図示するブロック図である。図２に示されるように、リソースマネージャ１０２は、データストレージデバイス２０６に結合した、アクセスマネージャ２０２とキーマネージャ２０４とを含む。アクセスマネージャ２０２は、ここに記述するシステムのための認証・認可タスクを扱う。キーマネージャ２０４は、認証・認可タスクの間に用いられるキーの、格納と認証を管理する。例えば、アクセスマネージャ２０２とキーマネージャ２０４は、リモートストレージデバイス（例えば、ストレージプラットフォーム１１４内のデータストレージデバイス）内に格納されたデータにアクセスするために用いられるキーを管理する。本明細書で用いられるように、リモートストレージデバイスは、また、「永続的ストレージデバイス（persistent storage device）」と呼ばれることもある。要求処理サービス２０８は、受信されたデータ格納要求とデータ取得要求（例えば、データベースクエリ）を管理する。例えば、要求処理サービス２０８は、受信されたデータ格納要求あるいはデータ取得要求を処理するのに必要なデータを決定してもよい。必要なデータは、（以下により詳細に議論するように）実行プラットフォーム１１２内のキャッシュに格納されていることもあり得るし、あるいは、ストレージプラットフォーム１１４内のデータストレージデバイス内に格納されていることもあり得る。管理コンソールサービス２１０は、管理者（administrators）及び他のシステム管理者（system managers）による、様々なシステム及びプロセスへのアクセスをサポートする。更に、管理コンソールサービス２１０は、クエリを発行してシステムの作業負荷を監視せよという、ユーザ１０４～１０８からの要求を受信することがある。幾つかの実施形態においては、特定のユーザは、自分の特定のクエリがシステムに課す作業負荷を監視することを求める要求を、発行することがある。

【0026】

リソースマネージャ１０２は、また、SQLコンパイラ２１２、SQLオプティマイザ２１４、及びSQLエグゼキュータ２１０を含む。SQLコンパイラ２１２は、SQLクエリを構文解析し、そのクエリのための実行コードを生成する。SQLオプティマイザ２１４は、処理される必要のあるデータに基づいて、クエリを実行するための最良の方法を決定する。SQLオプティマイザ２１４は、また、SQLクエリを実行する速度と効率を改善するための、様々なデータ刈り込み演算と他のデータ最適化技術を扱う。SQLエグゼキュータ２１６は、リソースマネージャ１０２によって受信されたクエリ用のクエリコードを実行する。

【0027】

クエリのスケジューラ兼コーディネータ２１８は、受信したクエリを、コンパイル、最適化、及び、実行プラットフォーム１１２へのディスパッチのために、適切なサービスあるいはシステムに送信する。例えば、クエリは、優先順位がつけられてもよく、その優先順位で処理されてもよい。幾つかの実施形態においては、クエリのスケジューラ兼コーディネータ２１８は、実行プラットフォーム１１２内の特定のノードを、特定のクエリを処理するために、特定し、あるいは、割り当てる。仮想ウェアハウスマネージャ２２０は、実行プラットフォーム１１２に実装される複数の仮想ウェアハウスの動作を管理する。以下に議論されるように、各仮想ウェアハウスは、それぞれがキャッシュとプロセッサを含む、複数の実行ノードを含む。

【0028】

更に、リソースマネージャ１０２は、設定とメタデータのマネージャ２２２を含み、これは、リモートデータストレージデバイスとローカルキャッシュ（つまり、実行プラットフォーム１１２内のキャッシュ）に格納されているデータに関連した情報を管理する。以下により詳しく議論するように、設定とメタデータのマネージャ２２２は、特定のクエリを処理するためのデータを取得するにはどのデータファイルにアクセスする必要があるかを判定するために、メタデータを用いる。モニタ兼作業負荷アナライザ２２４は、リソースマネージャ１０２によって実行されるプロセスを監視し、実行プラットフォーム１１２内の仮想ウェアハウスと実行ノード全体に渡っての、タスク（例えば、作業負荷）の分配を管理する。モニタ兼作業負荷アナライザ２２４は、また、データ処理プラットフォーム１００全体に渡る、変化する作業負荷に基づいて、必要に応じて、タスクを再分配する。設定とメタデータのマネージャ２２２と、モニタ兼作業負荷アナライザ２２４は、データストレージデバイス２２６に結合される。図２のデータストレージデバイス２０６と２２６は、データ処理プラットフォーム１００内の任意のデータストレージデバイスを表す。例えば、データストレージデバイス２０６と２２６は、実行プラットフォーム１１２内のキャッシュ、ストレージプラットフォーム１１４内のストレージデバイス、あるいは、任意の他のストレージデバイスを表すことが出来る。

【0029】

リソースマネージャ１０２は、また、トランザクション管理とアクセス制御のモジュール２２８も含み、これは、データ格納要求とデータアクセス要求の処理に関連した、様々なタスクと他の活動とを管理する。例えば、トランザクション管理とアクセス制御のモジュール２２８は、複数のユーザあるいはシステムによる、整合性が取れていて且つ同期された、データへのアクセスを提供する。複数のユーザ／システムは、同一のデータに同時にアクセスすることがあり得るので、データへの変更は、各ユーザ／システムが現在のバージョンのデータを使って作業しているということを保証するために、同期されなくてはならない。トランザクション管理とアクセス制御のモジュール２２８は、リソースマネージャ１０２内の単一の一元化された場所において、様々なデータ処理活動を制御する。幾つかの実施形態においては、トランザクション管理とアクセス制御のモジュール２２８は、SQLエグゼキュータ２１６によって実行されている様々なタスクの管理をサポートするために、SQLエグゼキュータ２１６と相互作用する。

【0030】

図３は、実行プラットフォーム１１２の実施形態を図示するブロック図である。図３に示されるように、実行プラットフォーム１１２は、複数の仮想ウェアハウス３０２、３０４、及び３０６を含む。各仮想ウェアハウスは、それぞれがデータキャッシュとプロセッサを含む、複数の実行ノードを含む。仮想ウェアハウス３０２、３０４、及び３０６は、複数の実行ノードを用いることにより、並列に、複数のクエリ（及び他のタスク）を実行することが出来る。ここに議論するように、実行プラットフォーム１１２は、システムとユーザの現在の処理ニーズに基づいて、リアルタイムに、新規の仮想ウェアハウスを追加したり、既存の仮想ウェアハウスを取り外したりすることが出来る。この柔軟性により、実行プラットフォーム１１２は、大量のコンピューティングリソースを、もはや必要でなくなったときにはそれらのコンピューティングリソースに支払いを続けることを強いられることなく、必要なときに迅速に展開することが出来る。すべての仮想ウェアハウスは、任意のデータストレージデバイス（例えば、ストレージプラットフォーム１１４内の任意のストレージデバイス）からデータを入手することが出来る。

【0031】

図３に示される各仮想ウェアハウス３０２～３０６は、３つの実行ノードを含んでいるが、特定の仮想ウェアハウスは、任意の数の実行ノードを含むことが出来る。更に、仮想ウェアハウス内の実行ノードの数はダイナミックであり、追加の需要がある場合には新規の実行ノードが作成されるように、かつ、既存の実行ノードは、もはや必要でなくなったときには削除されるようになっている。

【0032】

各仮想ウェアハウス３０２～３０６は、図１に示されるデータストレージデバイス１１６～１２０のいずれにもアクセスすることが出来る。従って、仮想ウェアハウス３０２～３０６は、必ずしも特定のデータストレージデバイス１１６～１２０に割り当てられるわけではなく、むしろ、データストレージデバイス１１６～１２０のいずれからもデータを入手することが可能である。同様に、図３に示される実行ノードのそれぞれは、データストレージデバイス１１６～１２０のいずれからもデータを入手することが出来る。幾つかの実施形態においては、特定の仮想ウェアハウスあるいは特定の実行ノードが、特定のデータストレージデバイスに一時的に割り当てられてもよいが、その仮想ウェアハウスあるいは実行ノードは、後に、任意の他のデータストレージデバイスからデータを入手してもよい。

【0033】

図３の例においては、仮想ウェアハウス３０２は、３つの実行ノード３０８、３１０、及び３１２を含む。実行ノード３０８は、キャッシュ３１４とプロセッサ３１６を含む。実行ノード３１０は、キャッシュ３１８とプロセッサ３２０を含む。実行ノード３１２は、キャッシュ３２２とプロセッサ３２４を含む。各実行ノード３０８～３１２は、１つ以上のデータ格納タスク及び／またはデータ取得タスクを処理することに関連付けられている。例えば、特定の仮想ウェアハウスが、特定のユーザあるいは顧客に関連付けられたデータ格納タスク及びデータ取得タスクを扱ってもよい。他の実装においては、特定の仮想ウェアハウスが、特定のデータストレージシステムあるいは特定のカテゴリのデータに関連付けられたデータ格納タスク及びデータ取得タスクを扱ってもよい。

【0034】

上記した仮想ウェアハウス３０２と同様に、仮想ウェアハウス３０４は、３つの実行ノード３２６、３２８、及び３３０を含む。実行ノード３２６は、キャッシュ３３２とプロセッサ３３４を含む。実行ノード３２８は、キャッシュ３３６とプロセッサ３３８を含む。実行ノード３３０は、キャッシュ３４０とプロセッサ３４２を含む。更に、仮想ウェアハウス３０６は、３つの実行ノード３４４、３４６、及び３４８を含む。実行ノード３４４は、キャッシュ３５０とプロセッサ３５２を含む。実行ノード３４６は、キャッシュ３５４とプロセッサ３５６を含む。実行ノード３４８は、キャッシュ３５８とプロセッサ３６０を含む。

【0035】

幾つかの実施形態においては、図３に示される実行ノードは、その実行ノードがキャッシュしているデータについてステートレスである。例えば、これらの実行ノードは、実行ノードについての状態情報、あるいは、特定の実行ノードによってキャッシュされているデータについての状態情報を、格納もしていないし、他の方法で保持してもいない。従って、実行ノード障害の場合、障害の生じたノードを透過的に他のノードに置き換えることが出来る。障害の生じた実行ノードに関連付けられた状態情報が無いので、新規の（置き換えの）実行ノードは、特定の状態を重ねて作ってしまうという心配なしに、障害の生じたノードを容易に置き換えることが出来る。

【0036】

図３に示される実行ノードは、それぞれ、１つのデータキャッシュと１つのプロセッサを含むが、別の実施形態は、任意の数のプロセッサと任意の数のキャッシュを含む実行ノードを含むことが出来る。更に、キャッシュは、異なる実行ノードの間で、サイズにバラツキがあってもよい。図３に示されるキャッシュは、ストレージプラットフォーム１１４（図１）内の１つ以上のデータストレージデバイスから取得されたデータを、ローカル実行ノード内に格納している。従って、キャッシュは、リモートストレージシステムから整合的にデータを取得するプラットフォームにおいて発生するボトルネック問題を、軽減あるいは消去する。本明細書に記述するシステム及び方法は、リモートストレージデバイスからデータを繰り返し入手するのではなく、実行ノード内のキャッシュからデータを入手しており、そうしたやり方は大幅に高速なものであって、かつ、上記したボトルネック問題を避けたものである。幾つかの実施形態においては、キャッシュは、キャッシュされたデータへの高速アクセスを提供する高速メモリデバイスを用いて実装される。各キャッシュは、ストレージプラットフォーム１１４内の任意のストレージデバイスからのデータを格納することが出来る。

【0037】

更に、キャッシュリソース及びコンピューティングリソースは、異なる実行ノード間で異なっていてもよい。例えば、１つの実行ノードは、多くのコンピューティングリソースと最小のキャッシュリソースを含んでいてもよく、すると、その実行ノードを、多くのコンピューティングリソースを要求するタスクにとって有用なものとすることが出来る。他の実行ノードは、多くのキャッシュリソースと最小のコンピューティングリソースを含んでいてもよく、すると、この実行ノードを、大容量のデータのキャッシングを要求するタスクにとって有用なものとすることが出来る。更に他の実行ノードは、より高速な入出力動作を提供するキャッシュリソースを含んでいてもよく、すると、大容量のデータの高速なスキャンを要求するタスクにとって有用である。幾つかの実施形態においては、特定の実行ノードに付随するキャッシュリソースとコンピューティングリソースは、その実行ノードによって実行されるべき予測タスクに基づいて、その実行ノードが作成されるときに決定される。

【0038】

更に、特定の実行ノードに付随するキャッシュリソースとコンピューティングリソースは、その実行ノードによって実行される変化するタスクに基づいて、時間経過と共に変化してもよい。例えば、特定の実行ノードには、その実行ノードによって実行されるタスクがよりプロセッサ集約型になるとき、より多くの処理リソースを割り当ててもよい。同様に、実行ノードには、その実行ノードによって実行されるタスクがより多くのキャッシュ容量を要求するとき、より多くのキャッシュリソースを割り当ててもよい。

【0039】

仮想ウェアハウス３０２～３０６は、同一の実行プラットフォーム１１２に関連付けられているが、仮想ウェアハウスを、複数の地理的場所にある複数のコンピューティングシステムを用いて実装してもよい。例えば、仮想ウェアハウス３０２を、第１の地理的場所にあるコンピューティングシステムによって実装することができるが、一方、仮想ウェアハウス３０４と３０６は、第２の地理的場所にある他のコンピューティングシステムによって実装される。幾つかの実施形態においては、これらの異なるコンピューティングシステムは、１以上の異なる団体によって維持されるクラウドベースのコンピューティングシステムである。

【0040】

更に、各仮想ウェアハウスは、複数の実行ノードを有しているものとして、図３に示されている。各仮想ウェアハウスに関連付けられ複数の実行ノードは、複数の地理的場所にある複数のコンピューティングシステムを用いて実装されていてもよい。例えば、仮想ウェアハウス３０２の特定の例は、特定の地理的場所にある一つのコンピューティングプラットフォーム上に、実行ノード３０８と３１０を実装し、他の地理的場所にある異なるコンピューティングプラットフォームにおいて、実行ノード３１２を実装する。実行ノードを実装すべき特定のコンピューティングシステムの選択は、特定の実行ノードに必要とされるリソースのレベル（例えば、処理リソース要件とキャッシュ要件）、特定のコンピューティングシステムにおいて利用可能なリソース、地理的場所の内部あるいは地理的場所同士の間でのネットワークの通信性能、どのコンピューティングシステムが既に仮想ウェアハウス内で他の実行ノードを実装しているか、などの様々な要因に依存することがある。

【0041】

実行プラットフォーム１１２は、また、フォールトトレラントでもある。例えば、一つの仮想ウェアハウスで障害が発生すると、その仮想ウェアハウスは、異なる地理的場所にある異なる仮想ウェアハウスに迅速に置き換えられる。

【0042】

特定の実行プラットフォーム１１２は、任意の数の仮想ウェアハウス３０２～３０６を含むことが出来る。更に、特定の実行プラットフォームにおける仮想ウェアハウスの数は、ダイナミックであり、追加的な処理リソース及び／またはキャッシングリソースが必要となったときに、新規の仮想ウェアハウスが作成されるようになっている。同様に、既存の仮想ウェアハウスは、その仮想ウェアハウスに関連付けられたリソースがもはや必要ないとき、削除されてもよい。

【0043】

幾つかの実施形態においては、仮想ウェアハウス３０２、３０４、及び３０６は、ストレージプラットフォーム１１４内の同一のデータに対して動作することがあり得るが、各仮想ウェアハウスは、独立した処理リソース及びキャッシングリソースを有する、それ自身の実行ノードを有する。この構成により、異なる仮想ウェアハウスへの要求が、独立に、且つ、要求間での干渉なしに処理されることを可能とする。この独立した処理は、仮想ウェアハウスをダイナミックに追加、削除する機能と組み合わされて、既存のユーザによって観察される性能に影響を与えることなく新規のユーザ用の新規の処理能力を追加することをサポートする。

【0044】

図４は、複数の仮想ウェアハウスを介して複数のデータベースにアクセスする複数のユーザがいる例示的動作環境４００を図示するブロック図である。環境４００において、複数のユーザ４０２、４０４、及び４０６は、複数の仮想ウェアハウス４０８、４１０、及び４１２を介して、複数のデータベース４１４、４１６、４１８、４２０、４２２、及び４２４にアクセスする。図４には図示されていないが、ユーザ４０２、４０４、及び４０６は、リソースマネージャ１０２（図１）を介して、仮想ウェアハウス４０８、４１０、及び４１２にアクセスしてもよい。特定の実施形態においては、データベース４１４～４２４は、ストレージプラットフォーム１１４（図１）に含まれ、実行プラットフォーム１１２内に実装される任意の仮想ウェアハウスによってアクセス可能である。幾つかの実施形態においては、ユーザ４０２～４０６は、インターネットなどのデータ通信ネットワークを用いて、仮想ウェアハウス４０８～４１２の一つにアクセスする。幾つかの実装においては、各ユーザ４０２～４０６は、特定の時間において作業をするための特定の仮想ウェアハウス４０８～４１２を指定する。図４の例においては、ユーザ４０２は、仮想ウェアハウス４０８と相互作用し、ユーザ４０４は、仮想ウェアハウス４１０と相互作用し、ユーザ４０６は、仮想ウェアハウス４１２と相互作用する。従って、ユーザ４０２は、仮想ウェアハウス４０８を介して、データ取得要求及びデータ格納要求を送信する。同様に、ユーザ４０４と４０６は、それぞれ、仮想ウェアハウス４１０と４１２を介して、データ取得要求及びデータ格納要求を送信する。

【0045】

各仮想ウェアハウス４０８～４１２は、すべてのデータベース４１４～４２４の部分集合と通信するように構成される。例えば、環境４００において、仮想ウェアハウス４０８は、データベース４１４、４１６、及び４２２と通信するように構成される。同様に、仮想ウェアハウス４１０は、データベース４１６、４１８、４２０、及び４２４と通信するように構成される。そして、仮想ウェアハウス４１２は、データベース４１６、４２２、及び４２４と通信するように構成される。別の実施形態においては、仮想ウェアハウス４０８～４１２のうちの１つ以上が、データベース４１４～４２４のすべてと通信する。図４に示される配置により、個別のユーザは、単一の仮想ウェアハウスを介して、すべてのデータ取得要求及びデータ格納要求を送信することが出来る。その仮想ウェアハウスは、仮想ウェアハウス内の実行ノードのうちの一つの中の、キャッシュされたデータを用いて、データ取得タスク及びデータ格納タスクを処理するか、あるいは、適切なデータベースから必要なデータを取得（及びキャッシュ）する。仮想ウェアハウス間のマッピングは、論理マッピングであり、ハードウェアマッピングではない。この論理マッピングは、セキュリティとリソースアクセス管理設定とに関連した、アクセス制御パラメータに基づく。論理マッピングは、仮想ウェアハウスあるいはストレージリソースの再構成を要求することなく、容易に変更される。

【0046】

環境４００は、データベース４１４～４２４の特定の部分集合と通信するように構成された仮想ウェアハウス４０８～４１２を示すが、その構成はダイナミックである。例えば、仮想ウェアハウス４０８は、仮想ウェアハウス４０８によって実行されるべき、変化するタスクに基づいて、データベース４１４～４２４の異なる部分集合と通信するように再構成されてもよい。例えば、仮想ウェアハウス４０８が、データベース４１８からデータを入手するように求める要求を受信したとすると、仮想ウェアハウス４０８は、データベース４１８とも通信するように再構成されてもよい。もし、その後になって、仮想ウェアハウス４０８がデータベース４１８からデータを入手する必要がもう無くなれば、仮想ウェアハウス４０８は、データベース４１８との通信を削除するように再構成されてもよい。

【0047】

図５は、ロードバランサと、仮想ウェアハウスグループに含まれる複数の仮想ウェアハウスとを介して、複数のデータベースにアクセスする複数のユーザがいる、他の例示的動作環境５００を図示するブロック図である。環境５００は、環境４００（図４）に似ているが、追加的に、仮想ウェアハウスリソースマネージャ５０８と、仮想ウェアハウスグループ５１６内に配置された複数の仮想ウェアハウス５１０、５１２、及び５１４を含む。仮想ウェアハウスリソースマネージャ５０８は、リソースマネージャ１０２に含まれていてもよい。特に、複数のユーザ５０２、５０４、及び５０６は、仮想ウェアハウスリソースマネージャ５０８と仮想ウェアハウスグループ５１６を介して、複数のデータベース５１８、５２０、５２２、５２４、５２６、及び５２８にアクセスする。幾つかの実施形態においては、ユーザ５０２～５０６は、インターネットなどのデータ通信ネットワークを用いて、仮想ウェアハウスリソースマネージャ５０８にアクセスする。図５には示されていないが、ユーザ５０２、５０４、及び５０６は、リソースマネージャ１０２（図１）を介して、仮想ウェアハウスリソースマネージャ５０８にアクセスしてもよい。幾つかの実施形態においては、仮想ウェアハウスリソースマネージャ５０８は、リソースマネージャ１０２内に実装される。

【0048】

ユーザ５０２～５０６は、データ取得要求及びデータ格納要求を仮想ウェアハウスリソースマネージャ５０８に送信してもよく、するとその仮想ウェアハウスリソースマネージャ５０８が、データ取得要求及びデータ格納要求を、仮想ウェアハウスグループ５１６内の適切な仮想ウェアハウス５１０～５１４にルーティングする。幾つかの実装においては、仮想ウェアハウスリソースマネージャ５０８は、仮想ウェアハウス５１０～５１４への、ユーザ５０２～５０６のダイナミックな割り当てを行う。データ取得要求あるいはデータ格納要求を送信するとき、ユーザ５０２～５０６は、その要求を処理するだろう特定の仮想ウェアハウス５１０～５１４を指定することなしに、その要求を処理すべき仮想ウェアハウスグループ５１６を指定してもよい。この配置により、仮想ウェアハウスリソースマネージャ５０８は、効率、利用可能なリソース、及び、仮想ウェアハウス５１０～５１４内のキャッシュされたデータの利用可能性に基づいて、仮想ウェアハウス５１０～５１４全体に渡って、複数の要求を分配することが出来る。データ処理要求をどのようにルーティングするかを決定するとき、仮想ウェアハウスリソースマネージャ５０８は、利用可能なリソース、現在のリソース負荷、現在のユーザの人数、などを考慮する。

【0049】

幾つかの実施形態においては、フォールトトレラントシステムが、仮想ウェアハウスの障害に応じて、新規の仮想ウェアハウスを作成する。新規の仮想ウェアハウスは、同一の仮想ウェアハウスグループ内にあってもよいし、異なる地理的場所にある、異なる仮想ウェアハウスグループ内に作成されてもよい。

【0050】

各仮想ウェアハウス５１０～５１４は、全てのデータベース５１８～５２８の部分集合と通信するように構成される。例えば、環境５００において、仮想ウェアハウス５１０は、データベース５１８、５２０、及び５２６と通信するように構成される。同様に、仮想ウェアハウス５１２は、データベース５２０、５２２、５２４、及び５２８と通信するように構成される。そして、仮想ウェアハウス５１４は、データベース５２０、５２６、及び５２８と通信するように構成される。別の実施形態においては、仮想ウェアハウス５１０～５１４は、データベース５１８～５２８のうち任意のもの（あるいは、全て）と通信してもよい。

【0051】

環境５００は、１つの仮想ウェアハウスグループ５１６を示すが、別の実施形態は、それぞれが任意の数の仮想ウェアハウスに関連付けられている、任意の数の仮想ウェアハウスグループを含んでいてもよい。特定の環境内の仮想ウェアハウスグループの数は、ダイナミックであり、環境内のユーザや他のシステムの、変化するニーズに基づいて、変化し得る。

【0052】

図６は、複数の分散した仮想ウェアハウスと仮想ウェアハウスグループとを有する他の例示的動作環境６００を図示するブロック図である。環境６００は、データ通信ネットワーク６０２を介して、仮想ウェアハウスグループ６０４及び６０６と通信するリソースマネージャ１０２を含む。ウェアハウスグループ６０４は、２つの仮想ウェアハウス６０８と６１０を含み、ウェアハウスグループ６０６は、他の２つの仮想ウェアハウス６１４と６１６を含む。リソースマネージャ１０２は、また、データ通信ネットワーク６０２を介して、仮想ウェアハウス６１２（仮想ウェアハウスグループの一部ではない）とも通信する。

【0053】

仮想ウェアハウス６１２と同様に、仮想ウェアハウスグループ６０４及び６０６は、データ通信ネットワーク６１８を介して、データベース６２０、６２２、及び６２４と通信する。幾つかの実施形態においては、データ通信ネットワーク６０２及び６１８は、同一のネットワークである。環境６００により、リソースマネージャ１０２は、データベース６２０～６２４内にデータを格納したり、データを取得したりするために、複数の仮想ウェアハウス６０８～６１６全体に渡って、ユーザのデータ格納・取得要求をコーディネートすることが出来る。仮想ウェアハウスグループ６０４と６０６は、同一の地理的領域に位置することが出来、あるいは、地理的に離れていることも出来る。更に、仮想ウェアハウスグループ６０４と６０６は、同一の団体、あるいは、異なる団体によって実装され得る。

【0054】

ここに記述するシステム及び方法により、データを、コンピューティング（あるいは、処理）リソースとは別箇なサービスとして、格納したり入手したりすることが出来る。コンピューティングリソースが、実行プラットフォームから割り当てられなかった場合でさえも、データは、リモートデータソースからの当該データの再ロードを必要とすることなく、仮想ウェアハウスにとって利用可能である。従って、データは、当該データに関連付けられたコンピューティングリソースの割り当てとは独立に利用可能である。記述されたシステム及び方法は、任意のタイプのデータに有用である。特定の実施形態においては、データは、構造化され最適化されたフォーマットで格納される。コンピューティングサービスからのデータ格納／入手サービスの分離は、また、異なるユーザ及びグループ間のデータの共有を簡単化する。ここに議論されるように、各仮想ウェアハウスは、他の仮想ウェアハウスが同一のデータにアクセスしているときとたとえ同時であってさえも、アクセス許可を有している任意のデータにアクセス可能である。このアーキテクチャは、ローカルキャッシュに格納されたいかなる実際のデータもなしにクエリを実行することをサポートする。ここに記述されるシステム及び方法は、透過的な動的データ移動が可能であり、それによってデータを、システムのユーザに対し透過的な方法で、必要に応じて、リモートストレージデバイスからローカルキャッシュへ移動させる。更に、このアーキテクチャは、任意の仮想ウェアハウスが、データストレージサービスのコンピューティングサービスからの分離により、任意のデータにアクセスすることができるので、事前のデータ移動なしでのデータ共有をサポートする。

【0055】

図７は、データス格納・取得動作を管理する方法７００の実施形態を図示するフロー図である。最初、方法７００は、７０２において、ユーザから、ステートメント、要求、あるいはクエリを受信する。ステートメントは、データ関連の動作を実行するための、任意の要求あるいはコマンドである。例示的ステートメントは、データ取得要求、データ格納要求、データ転送要求、データクエリなどを含む。幾つかの実施形態においては、ステートメントは、SQLステートメントとして実装される。リソースマネージャは、受信したステートメントを管理するため、７０４において、クエリコーディネータを作成する。例えば、クエリコーディネータは、実行プラットフォーム及び１以上のデータストレージデバイスとの相互作用を含む、受信したステートメントを処理するために必要な様々なタスクを、管理する。幾つかの実施形態においては、クエリコーディネータは、受信したステートメントを管理するために特別に作成された一時的ルーチンである。

【0056】

リソースマネージャが、７０６において、受信したステートメントを処理するのに必要な複数のタスクを決定するとおり、方法７００は継続する。複数のタスクは、例えば、実行ノード内のキャッシュからデータを入手することや、リモートストレージデバイスからデータを取得することや、キャッシュ内のデータを更新することや、リモートストレージデバイスにデータを格納することなどを含んでいてもよい。リソースマネージャは、また、７０８において、実行プラットフォーム内の実行ノードに、複数のタスクを分配する。ここに議論するように、実行プラットフォーム内の実行ノードは、仮想ウェアハウス内に実装される。各実行ノードは、７１０において、割り当てられたタスクを実行し、リソースマネージャに、タスク結果を返送する。幾つかの実施形態においては、実行ノードは、タスク結果を、クエリコーディネータに返送する。リソースマネージャは、７１２において、複数のタスク結果を受信してステートメント結果を生成し、７１４において、ステートメント結果をユーザに伝達する。幾つかの実施形態においては、クエリコーディネータは、ステートメント結果がユーザに伝達された後、消去される。

【0057】

幾つかの実装においては、同一のファイルが、同時に、複数の実行ノードによってキャッシュされる。ファイルのこの多重キャッシングは、複数の実行ノードに渡るロードバランシング（例えば、データ処理タスクをバランスさせること）について助けとなる。更に、ファイルを複数の実行ノードにキャッシュすることは、かなりの量のデータが同一の通信リンクを通過しようとする場合に、潜在的なボトルネックを防止する助けとなる。この実装は、また、異なる実行ノードによる、同一データの並列処理をサポートする。

【0058】

ここに記述したシステム及び方法は、共有ディスクシステム及びシェアドナッシングアーキテクチャの両方の利点を利用する。データを格納・取得するための、前述されたプラットフォームは、一旦データがローカルにキャッシュされれば、シェアドナッシングアーキテクチャのようにスケーラブルである。これはまた、何の制限（例えば、０個からN個までといったもの）もなく、且つ、データのいかなる明示的なリシャッフルを要求することなく、処理ノードを追加及び除去することが出来る、共有ディスクアーキテクチャの利点のすべてを有している。

【0059】

図８は、例示的コンピューティングデバイス８００を図示するブロック図である。幾つかの実施形態においては、コンピューティングデバイス８００は、ここに記述したシステム及びコンポーネントのうちの一つ以上を実装するために、用いられる。例えば、ユーザあるいは管理者がリソースマネージャ１０２にアクセスすることを、コンピューティングデバイス８００によって可能としてもよい。更に、コンピューティングデバイス８００は、ここに記述されたシステム及びコンポーネントのうち任意のものと相互作用してもよい。従って、コンピューティングデバイス８００は、ここに議論したような、様々な手続き及びタスクを実行するために用いられることがある。コンピューティングデバイス８００は、サーバ、クライアント、あるいは、任意の他のコンピューティング装置として、機能することが出来る。コンピューティングデバイス８００は、デスクトップコンピュータ、ノートブックコンピュータ、サーバコンピュータ、ハンドヘルドコンピュータ、タブレットなどの広範な様々のコンピューティングデバイスのうち、任意のものとすることが出来る。

【0060】

コンピューティングデバイス８００は、１以上のプロセッサ８０２、１以上のメモリデバイス８０４、１以上のインタフェース８０６、１以上の大容量ストレージデバイス８０８、及び、１以上の入出力（I/O）デバイス８１０を含み、これらすべては、バス８１２に結合されている。プロセッサ８０２は、メモリデバイス８０４及び／または大容量ストレージデバイス８０８に格納されている命令を実行する、１以上のプロセッサまたはコントローラを含む。プロセッサ８０２は、また、キャッシュメモリなどの、様々なタイプのコンピュータ読み取り可能な媒体を含むことが出来る。

【0061】

メモリデバイス８０４は、揮発性メモリ（例えば、ランダムアクセスメモリ（RAM））及び／または不揮発性メモリ（例えば、リードオンリーメモリ（ROM））などの、様々なコンピュータ読み取り可能な媒体を含む。メモリデバイス８０４は、また、フラッシュメモリなどの、書き換え可能なROMを含むことが出来る。

【0062】

大容量ストレージデバイス８０８は、磁気テープ、磁気ディスク、光ディスク、固体メモリ(例えば、フラッシュメモリ）などの、様々なコンピュータ読み取り可能な媒体を含む。様々なコンピュータ読み取り可能な媒体からの読み取り、及び／または、これへの書き込みを可能にするために、大容量ストレージデバイス８０８に様々なドライブが更に含まれていてもよい。大容量ストレージデバイス８０８は、取り外し可能な媒体、及び／または、取り外し不可能な媒体を含む。

【0063】

I/Oデバイス８１０は、データ及び／または他の情報が、コンピュータデバイス８００へ入力され、あるいは、そこから取得されることを可能とする、様々なデバイスを含む。例示的I/Oデバイス８１０は、カーソル制御デバイス、キーボード、キーパッド、マイクロフォン、モニタあるいは他のディスプレイデバイス、スピーカ、プリンタ、ネットワークインタフェースカード、モデム、レンズ、CCDあるいは他の画像キャプチャデバイスなどを含む。

【0064】

インタフェース８０６は、コンピューティングデバイス８００が、他のシステム、デバイス、あるいは、コンピューティング環境と相互作用することを可能とする、様々なインタフェースを含む。例示的インタフェース８０６は、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN）、無線ネットワーク、及び、インターネットへのインタフェースなどの、任意の数の異なるネットワークインタフェースを含む。

【0065】

バス８１２により、プロセッサ８０２、メモリデバイス８０４、インタフェース８０６、大容量ストレージデバイス８０８、及びI/Oデバイス８１０は、相互に通信することが可能となり、また、バス８１２に結合された他のデバイスあるいはコンポーネントと通信することも可能となる。バス８１２は、システムバス、PCIバス、IEEE１３９４バス、USBバスなどの、幾つかのタイプのバス構造のうちの、一つ以上を表している。

【0066】

図示のために、プログラム及び他の実行可能なプログラムコンポーネントが、別々のブロックとして、ここに示されたが、そのようなプログラム及びコンポーネントは、様々な時点においてコンピューティングデバイス８００の異なるストレージコンポーネントに存在し得るし、プロセッサ８０２によって実行されるのだ、ということが理解される。あるいは、ここに記述されたシステム及び手続きを、ハードウェアで実装することも出来るし、あるいは、ハードウェア、ソフトウェア、及び／または、ファームウェアの組み合わせで実装することも出来る。例えば、１以上の特定用途向け集積回路（ASIC）を、ここに記述されたシステム及び手続きのうち一つ以上を実行するようにプログラムすることが出来る。

【0067】

本開示は、ある種の好適な実施形態の観点から記述されているが、この開示という恩恵が与えられれば、当業者にとっては、ここに述べた利点と特徴をすべて提供するわけではない実施形態も含めて、他の実施形態も明らかであろうし、それらの他の実施形態もまた、この開示の範囲内である。本開示の範囲を外れることなく他の実施形態を利用することもあり得る、ということを理解されたい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】