JP6542785B2 - 第一クラスデータベース要素としての半構造データの実装 - Google Patents

Description

[関連出願に対する参照]
本出願は、２０１４年２月１９日に出願された“Ａｐｐａｒａｔｕｓ ａｎｄ ｍｅｔｈｏｄ ｆｏｒ ｅｎｔｅｒｐｒｉｓｅ ｄａｔａ ｗａｒｅｈｏｕｓｅ ｄａｔａ ｐｒｏｃｅｓｓｉｎｇ ｏｎ ｃｌｏｕｄ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ”と題された米国仮出願整理番号６１／９４１，９８６の利益を享受する権利を主張し、米国仮出願整理番号６１／９４１，９８６の開示は、その全体において参照によって本明細書に組み入れられる。

本開示は、データストレージおよびコンピューティングリソースを管理するリソース管理システムおよび方法に関する。

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

別の既存のデータストレージおよび検索システムは、“シェアード・ナッシング・アーキテクチャ（ｓｈａｒｅｄ−ｎｏｔｈｉｎｇ ａｒｃｈｉｔｅｃｔｕｒｅ）”と称される。このアーキテクチャにおいては、データは、複数の処理ノードにわたって分散し、各ノードは、全データベース内のデータのサブセットを格納する。新しい処理ノードが追加、または除去されると、シェアード・ナッシング・アーキテクチャは、複数の処理ノードにわたってデータを再配列しなければならない。このデータの再配列は時間を消費し、データ再配列中に実行されるデータ読み出しおよび書き込み動作に対して混乱を生じさせ得る。また、特定のノードに対するデータのアフィニティは、一般的なデータに対するデータクラスタ上に“ホットスポット（ｈｏｔ ｓｐｏｔｓ）”を生成し得る。さらに、各処理ノードは、ストレージ機能も実施するため、このアーキテクチャは、データを格納するために少なくとも一つの処理ノードを必要とする。このように、シェアード・ナッシング・アーキテクチャは、全ての処理ノードが除去される場合にはデータを格納するのに失敗する。さらに、シェアード・ナッシング・アーキテクチャにおけるデータの管理は、多くの異なる処理ノードにわたるデータの分散によって複雑である。

本明細書に記述されるシステムおよび方法は、既存のシステムの上記で特定された制限を軽減するデータストレージおよびデータ検索に対する改良されたアプローチを提供する。

本開示の非限定かつ非包括的な実施形態は、以下の図面を参照して記述され、類似の参照番号は、そうでないと特に断らない限りは、種々の図面を通して類似の部分のことを称する。
半構造データの処理を示す情報フローおよび関係図を示す。 本明細書に開示される方法の実装を示すプロセスフロー図である。 本開示の教示によるオペレーティング環境の一実施形態を示すブロック図を示す。 本開示の教示によるリソースマネージャの実装の一例を示すブロック図を示す。 本開示の教示による実行プラットフォームの実装の一例を示すブロック図を示す。 本開示の教示による例示的コンピューティングデバイスを示すブロック図を示す。

半構造データ（半構造化データ）を管理するための方法、装置およびシステムが本明細書に開示される。例えば、半構造データを管理するための方法の実装は、半構造データソースから半構造データ要素を受信し、データベースに半構造データ要素が加えられると、半構造データ要素の集合に対して統計解析を実施してもよい。さらに、半構造データ内から共通のデータ要素が特定され、共通性の閾値によって、ファーストクラスデータおよび／またはより低いクラスのデータとして割り当てられてもよい。実装は、キャッシュメモリ内に格納された個別の擬似列に、半構造データソースからの共通データ要素を更に組み合わせ、その後、コンピュータベースのクエリジェネレータに対して利用可能なファーストクラスデータの擬似列に対応するメタデータおよび統計を作成してもよい。

以下の記述においては、本明細書の一部を形成する添付の図面に対する参照が行われ、その中では、本開示が実践され得る特定の例示的実施形態の例示として示される。これらの実施形態は、本明細書に開示された概念を当業者が実施することを可能にするために十分詳細に記述され、本開示の範囲から逸脱することなく、種々の開示された実施形態に対する改変が行われてもよく、他の実施形態が使用されてもよいことを理解されたい。したがって、以下の詳細な記述は、限定する意味で解釈されるべきではない。

本明細書中の“一実施形態（ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ）”、“ある実施形態（ａｎ ｅｍｂｏｄｉｍｅｎｔ）”、“一例（ｏｎｅ ｅｘａｍｐｌｅ）”または“ある例（ａｎ ｅｘａｍｐｌｅ）”に対する言及は、実施形態または例に関連して記述される特定の特徴、構造または特性が本開示の少なくとも一実施形態に含まれることを意味する。このように、本明細書中の種々の位置における“一実施形態においては（ｉｎ ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ）”“ある実施形態においては（ｉｎ ａｎ ｅｍｂｏｄｉｍｅｎｔ）”、“一例”または“ある例”という句の出現は、必ずしもすべて同一の実施形態または同一の例に対して言及するものではない。さらに、本明細書に提供される図面は、当業者に対して説明する目的のためのものであって、図面は必ずしも同一の縮尺で描かれているとは限らないことを理解されたい。

本開示による実施形態は、装置、方法またはコンピュータプログラム製品として具現化されてもよい。したがって、本開示は、全体としてハードウェア構成実施形態、全体としてソフトウェア構成実施形態（ファームウェア、レジデントソフトウェア、マイクロコードなどを含む）または“回路”“モジュール”もしくは“システム”として本明細書で全て一般的に称され得るソフトウェアおよびハードウェア態様を組み合わせる実施形態の形式をとってもよい。さらに、本開示の実施形態は、媒体中で具現化されるコンピュータ利用可能なプログラムコードを有する表現の任意の有形媒体内で具現化されるコンピュータプログラム製品の形式をとってもよい。

一つ以上のコンピュータ利用可能またはコンピュータ可読媒体の如何なる組み合わせが使用されてもよい。例えば、コンピュータ可読媒体は、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）デバイス、リードオンリーメモリ（ＲＯＭ）デバイス、消去可能なプログラマブルリードオンリーメモリ（ＥＰＲＯＭまたはフラッシュメモリ）デバイス、ポータブルコンパクトディスクリードオンリーメモリ（ＣＤＲＯＭ）、光学ストレージデバイス、磁気ストレージデバイスのうちの一つ以上を含んでもよい。本開示の動作を実行するためのコンピュータプログラムコードは、一つ以上のプログラミング言語の任意の組み合わせで書き込まれてもよい。このようなコードは、コンピュータ可読アセンブリ言語に対するソースコードまたはコードが実行されるであろうデバイスもしくはコンピュータに対して適切なマシンコードからコンパイルされてもよい。

実施形態は、クラウドコンピューティング環境内でも実装されてもよい。この記述および以下の請求項においては、“クラウドコンピューティング（ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ）”とは、仮想化によって迅速にセットアップでき、最小の管理努力またはサービスプロバイダ相互作用でリリースすることができ、その後それによってスケーリングすることができる、構成可能なコンピューティングリソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーションおよびサービス）の共有されたプールに対して、ユビキタスで簡便なオンデマンドネットワークアクセスを可能にするためのモデルとして定義されてもよい。クラウドモデルは、種々の特性（例えば、オンデマンドセルフサービス、ブロードネットワークアクセス、リソースプーリング、迅速な柔軟性（rapid elasticity）およびメジャードサービス）、サービスモデル（例えば、ソフトウェア・アズ・ア・サービス（“ＳａａＳ”）、プラットフォーム・アズ・ア・サービス（“ＰａａＳ”）およびインフラストラクチャ・アズ・ア・サービス（“ＩａａＳ”））および展開モデル（例えば、プライベートクラウド、コミュニティクラウド、パブリッククラウドおよびハイブリッドクラウド）で構成することができる。

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

本明細書に記述されたシステムおよび方法は、新しいデータ処理プラットフォームを使用するフレキシブルかつスケーラブルなデータウェアハウスを提供する。幾つかの実施形態においては、記述されたシステムおよび方法は、クラウドベースストレージリソース、コンピューティングリソースなどをサポートするクラウドインフラストラクチャを利用する。例示的なクラウドベースのストレージリソースは、低コストで、オンデマンドで利用可能なかなりのストレージ容量を提供する。さらに、これらのクラウドベースストレージリソースは、フォールト・トレラントかつ高いスケーラビリティを有してもよく、個人的なデータストレージシステム内で実現するためには高価であり得る。例示的なクラウドベースのコンピューティングリソースは、オンデマンドで利用可能であり、リソースの実際の利用レベルに基づいて値段設定されてもよい。典型的には、クラウドインフラストラクチャは、迅速な方法で動的に展開され、再構成され、閉鎖される。

記述されたシステムおよび方法においては、データストレージシステムは、半構造ベースのリレーショナル（関係）データベースを利用する。しかしながら、これらのシステムおよび方法は、任意のデータストレージアーキテクチャを利用し、データベース内のデータを格納して検索するために任意の言語を利用する任意の種類のデータベースに対して適用可能である。本明細書で用いられるように、半構造データとは、リレーショナルデータベースに関連づけられるデータモデルの典型的な形式的構造とは一致しないが、それにもかかわらず、意味的要素を分離し、データ内のレコードおよびフィールドの階層を強制するためのタグまたは他のマーカを含む構造データの形式を伝達することを意味する。本明細書に記述されるシステムおよび方法は、異なるカスタマー／クライアント間、および同一のカスタマー／クライアント内の異なるユーザ間でコンピューティングリソースおよびデータの分離をサポートするマルチテナントシステムをさらに提供する。

大量の半構造データを扱うデータベースおよびデータウェアハウスシステムの性能を顕著に改善する方法およびシステムが本明細書に開示される。既存のデータベースシステムは、リレーショナル（即ち、ＳＱＬデータベース）またはキー値ストアのいずれかである。

リレーショナルデータベースは、クエリデータアクセスプルーニング（テーブルの特定の列に格納された値について集約されたメタデータに基づいて、検索からデータベースの一部を排除すること）によって効率的なクエリを実施することができる。しかしながら、これは、半構造データを表すために使用することができないデータの厳格な表フォーマットを必要とする。

一方、キー値ストアは、よりフレキシブルであるが、プルーニングの欠如によって深刻な性能のペナルティを導入する。既存の製品および研究プロジェクトにおけるリレーショナルデータベースに対して半構造データの取り扱いを追加するための多数の方法が存在する。

１．シリアライズエンコード。半構造データ記録は、シリアライズ表現として、列にして格納される。幾つかのフィールドの値が利用されると常に、その値が抽出されて、基本タイプに変換される。この方法はフレキシブルであるが、このプルーニングによって改善されるべきデータに対するアクセスを行う。シリアライズ表現からの抽出はコストが高く、通常のリレーショナルデータで動作するよりも顕著に多くのＣＰＵ時間を必要とする。全てのシリアライズデータの記録は、それらのうちのごくわずかな部分のみ（単一要素など）がクエリ内で使用される場合でさえも、持続性ストレージから読み出され、処理されなければならない。

２．取り込みにおける変換。半構造データは、取り込みにおいて、リレーショナルデータに変換される。これは、任意の他のリレーショナルデータに対するアクセスと同程度に迅速に、このデータにアクセスするが、取り込みにおいてデータ構造の厳格な仕様を必要とし、対応するデータベーススキーマが事前に完全に特定されることを必要とする。データベーススキーマを変更する必要があるため、この方法は、変化する構造を有するデータの取り扱いのコストを非常に高くする。ある記録から記録へと変化する構造を有するデータは、この方法を利用して扱うことが不可能である。変換方法は、事前に特定されなければならず、あらゆる重要な変化は、元の半構造データを再度取り込むことを必要とする。

３．従来のリレーショナルデータベースに格納されたオブジェクト属性値三つ揃え表現に等価な構造データのリレーショナル様表現。この方法はフレキシブルであるが、実用上、データサブコンポーネントに対するアクセス用のジョイン演算を必要とし、それは、データに依存して非常に遅く成り得る。

４．ソースデータの階層反映構造内で異なる濃度を有する列がリンクすることを可能とする、リレーショナルデータモデルに対する非伝統的拡張。このようなデータ表現のためのクエリ生成方法は、十分理解されていない（効率的なクエリ生成は、本技術分野の現在の状態で不可能である）。この方法は、厳格な（とはいっても表ではない）スキーマに一致する入力データを必要とし、このため、任意の半構造データを扱うほど十分フレキシブルではない。

必要とされるのは、効率的で低コストかつ反応の速い半構造データと動作するためのシステムおよび方法である。なぜなら、それは、より伝統的なデータ構造と同様に処理してクエリすることができる、少なくとも擬似的な列内のデータを管理しながら、半構造データの意味を保存するからである。

以下の開示の実装においては、データは、ファイル、ファイルの要素、ファイルの一部などの形式で入力されてもよい。ファイルは、ドキュメントの集合を含んでもよく、データの一部は、ファイル、接続由来の複数のドキュメントおよび／またはドキュメントの一部を含んでもよい。さらに、実装においては、メタデータは、ファイル、ファイルの一部、データの一部に関連付けられてもよい。

本明細書で用いられるように、“共通データ要素”とは、同一グループに属するデータ要素および論理的に類似の要素の集合を意味することを意図される。

図１は、半構造データを処理し、クエリに対するアクセスを増加させるためにデータ要素に対するクラス指定を割り当てるコンピュータシステムにおける半構造データフローの概略を図示する。図面からわかるように、半構造データ１１０は、その中に、共通および非共通データ要素を含んでもよい。半構造データから共通データを抽出するために、解析統計１２２は、半構造データに対して実行されてもよく、共通のデータ要素および非共通データ要素を決定し、各データ要素に対して割り当てられるべきクラス指定を生成する。さらに、ユーザの関心およびユーザの要求１２４は、共通データ要素のためのクラス指定を決定するために使用されてもよいことに留意されたい。図面に示されるように、共通データは、擬似列１２０と呼ばれる一時的な列構造にして格納されてもよく、クラス指定に従ってさらに格納されてもよく、ファーストクラスデータ要素は、クエリのためのより良好なアクセスのために格納される。共通であることを判定されなかったデータ要素は、“オーバーフロー”シリアライズデータ１４０にしてシリアルに格納されてもよい。最終的に、ユーザは、ファーストクラスデータ要素からより迅速かつ正確に折丁に対する結果１３０を受信するだろう。

実装においては、必要とされるデータ要素が擬似列１２０内にない場合、それは“オーバーフロー”シリアライズデータ１４０から抽出されてもよく、全体の半構造データ記録１５０が再構成されることを要求される場合、それは擬似列１２０内のファーストクラスデータ、擬似列１２０内のより低いデータおよび“オーバーフロー”データ１４０から再構成され、元の形式へと再度シリアライズされてもよい。

図２は、半構造データを取り扱い、データストレージの優先順位を決定するためのデータクラスを割り当てるための方法２００のフロー図を図示する。図面からわかるように、２１０において、半構造データ要素は、半構造データソースまたは複数の半構造データソースから受信される。データ要素が受信されると、それらは共通データ要素および非共通データ要素として割り当てられてもよい。これは、２２０において、半構造データの集合がデータベースに追加されるときに該半構造データの集合の統計解析を実施することによって達成されてもよい。統計解析に基づいて、２３０において共通データ要素が特定されてもよい。２４０において、共通データ要素は、所望のまたは繰り返し生じるデータに対するファーストクラス指定や、それほど望ましくなく、かつそれほど生じないデータ要素に対するより低いクラス指定など、クラス指定を割り当てられてもよい。方法２００の命令を実施するシステムは、さらに、２５０において、共通性の閾値に従った２４０での半構造データからのファーストクラスデータ要素のストレージを、個別の擬似列へとまとめる一方で、非共通データ要素は“オーバーフロー”シリアライズストレージにして格納されてもよい。共通性の閾値は、例えば、半構造データ内にデータ要素が何回現れるかに基づいてもよく、または、ユーザのクエリがデータを何回検索するかに基づいてもよい。これらの要素は、半構造データから抽出されてもよく、ユーザに対して見えない列のフォーマットで個別に格納されてもよい。２６０において、ファーストクラスデータは、その望ましさのゆえに、素早くアクセス可能なキャッシュメモリ内に擬似列にして格納されてもよく、これらの擬似列のメタデータおよび統計（最小値および最大値、個別値の数など）は、その後、２７０においてクエリジェネレータに利用可能にされてもよいことを理解されたい。個別の集合（即ち、個別のファイル内に格納されたテーブルの一部）は、抽出されたデータ要素の異なるサブセットを有してもよいことに留意されたい。

図２からわかるように、共通性の指定およびデータ要素に対するクラスの割り当ては、半構造データ要素のデータベースがクエリに対して最新のものに維持されることを保証するために繰り返されてもよい。

実装においては、データを抽出するとき、共通データ要素の値が必要とされる場合、効率的な列アクセスを利用して、対応する擬似列から直接取得されてもよい。

実装においては、共通データ要素は、何時でもファーストクラス指定に追加されてもよいし、同様に、データ要素は、それほど望ましくない、またはそれほど表現していないことが分かったときに、ファーストクラス指定を失うことがある。

ユーザにとって、この方法は、シリアライズされた記録を格納することと区別がつかないことがあり、個々のデータ記録の構造に対して何の制約も課さない。しかしながら、大部分の共通データ要素が、従来のリレーショナルデータと同一の方法で格納されるため、それらに対するアクセスが提供されてもよく、全体の半構造記録の読み出しおよび抽出を必要としない。それによって、従来のリレーショナルデータベースの速度の利点を得る。

（同一のテーブル由来の）半構造記録の異なる集合は、抽出されたデータ要素の異なる組を有し得るため、クエリジェネレータおよびプルーニングは、部分的に利用可能なメタデータで動作することが可能であるべきである（即ち、テーブルの一部は、特定のデータ要素に対して利用可能なメタデータおよび統計を有してもよいが、他の部分はそれを欠いていてもよい）。

従来技術に対する利点は、（それほど共通ではない要素のシリアライズストレージおよび共通要素の列ストレージの双方として）ハイブリッドデータストレージ表現を利用するための方法によって提供される性能である。これは、従来のリレーショナルデータベースによって提供されるデータクエリのシリアライズ表現と高性能とを利用して、システムの任意の半構造データを格納するための柔軟性および性能の双方をユーザが達成することを可能とする。

任意のデータ処理プラットフォームが半構造データを扱うためにこのアプローチを利用することができることが当業者には理解されるだろう。それは、ＳＱＬを実行するＤＢＭＳシステムに限定される必要がない。

図３に図示されるのは、本明細書に開示された方法を実行するためのコンピュータシステムである。図３に図示されるように、リソースマネージャ３０２は、複数のユーザ３０４、３０６および３０８に結合される。特定の実装においては、リソースマネージャ３０２は、データ処理プラットフォーム３００にアクセスを望むあらゆる数のユーザをサポートすることができる。ユーザ３０４−３０８は、例えば、データストレージおよび検索要求を提供するエンドユーザと、本明細書に記述されたシステムおよび方法、データベースと相互作用するソフトウェアアプリケーションおよびリソースマネージャ３０２と相互作用する他のコンポーネント／デバイスを管理するシステム管理者と、を含んでもよい。リソースマネージャ３０２は、データ処理プラットフォーム３００内の全システムおよびコンポーネントの動作をサポートする種々のサービスおよび機能を提供する。リソースマネージャ３０２は、メタデータ３１０にも結合され、メタデータ３１０は、データ処理プラットフォーム３００中に格納されたデータ全体と関連付けられる。リソースマネージャは、ファイルの組に対応するメタデータと結合されるため、メタデータは、ユーザクエリを生成するために使用されてもよい。幾つかの実施形態においては、メタデータ３１０は、ローカルキャッシュから利用可能なデータと同様に、遠隔データストレージシステム内に格納されたデータの要約を含む。さらに、メタデータ３１０は、遠隔データストレージシステムおよびローカルキャッシュ内で如何にしてデータが組織化されるかに関する情報を含んでもよい。メタデータ３１０は、ストレージデバイスから実際のデータをロードまたはアクセスすることなく、一片のデータが処理される必要があるか否かをシステムおよびサービスが判定することを可能にする。

リソースマネージャ３０２は、実行プラットフォーム３１２にさらに結合され、実行プラットフォーム３１２は、以下により詳細に議論されるように、種々のデータストレージおよびデータ検索タスクを実行する複数のコンピューティングリソースを提供する。実行プラットフォーム３１２は、ストレージプラットフォーム３１４の一部である複数のデータストレージデバイス３１６、３１８および３２０に結合される。３つのデータストレージデバイス３１６、３１８および３２０が図３に図示されるが、実行プラットフォーム３１２は、あらゆる数のデータストレージデバイスと通信することが可能である。幾つかの実施形態においては、データストレージデバイス３１６、３１８および３２０は、一つ以上の地理的位置に配置されたクラウドベースのストレージデバイスである。例えば、データストレージデバイス３１６、３１８および３２０は、パブリッククラウドインフラストラクチャの一部またはプライベートクラウドインフラストラクチャであってもよい。データストレージデバイス３１６、３１８および３２０は、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、ストレージクラスタまたは任意の他のデータストレージ技術であってもよい。さらに、ストレージプラットフォーム３１４は、（Ｈａｄｏｏｐ分散ファイルシステム（ＨＤＦＳ）などの）分散ファイルシステム、オブジェクトストレージシステムなどを含んでもよい。

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

図３に図示されるように、データストレージデバイス３１６、３１８および３２０は、実行プラットフォーム３１２に関連付けられたコンピューティングリソースから切り離される。このアーキテクチャは、データ処理プラットフォーム３００にアクセスするユーザおよびシステムのニーズの変化と同様に、データストレージ／検索ニーズの変化に基づいて、データ処理プラットフォーム３００に対する動的な変化をサポートする。動的変化のサポートによって、データ処理プラットフォーム３００内のシステムおよびコンポーネントに対する需要の変化に迅速に応じて、データ処理プラットフォーム３００をスケーリングすることを可能にする。データストレージデバイスからのコンピューティングリソースの切断は、対応する大量のコンピューティングリソースを必要とすることなく、大量のデータのストレージをサポートする。同様に、このリソースの切断は、利用可能なデータストレージリソース内で対応する増加を必要とすることなく、特定の時刻に使用されるコンピューティングリソース内の顕著な増加をサポートする。

リソースマネージャ３０２、メタデータ３１０、実行プラットフォーム３１２およびストレージプラットフォーム３１４は、個々のコンポーネントとして図３に図示される。しかしながら、リソースマネージャ３０２、メタデータ３１０、実行プラットフォーム３１２およびストレージプラットフォーム３１４の各々は、分散システム（例えば、複数の地理的位置において、複数のシステム／プラットフォームにわたって分散される）として実装されてもよい。さらに、リソースマネージャ３０２、メタデータ３１０、実行プラットフォーム３１２およびストレージプラットフォーム３１４の各々は、ユーザ３０４−３０８から受信された要求の変化およびデータ処理プラットフォーム３００のニーズの変化によって（互いに独立して）拡張または縮小することができる。このように、記述された実施形態においては、データ処理プラットフォーム３００は動的であって、現在のデータ処理ニーズに見合うように規則的な変化をサポートする。

図４は、リソースマネージャ３０２の一実施形態を図示するブロック図である。図３に図示されるように、リソースマネージャ３０２は、データストレージデバイス４０６に結合されたアクセスマネージャ４０２とキーマネージャ４０４とを含む。アクセスマネージャ４０２は、本明細書に記述されたシステムに対する認証および承認タスクを扱う。キーマネージャ４０４は、認証および承認タスク中に、使用されるキーのストレージおよび認証を管理する。要求処理サービス４０８は、受信されたデータストレージ要求およびデータ検索要求を管理する。管理コンソールデバイス４１０は、管理者および他のシステムマネージャによる種々のシステムおよびプロセスに対するアクセスをサポートする。

リソースマネージャ３０２は、ＳＱＬコンパイラ４１２、ＳＱＬオプティマイザ４１４およびＳＱＬエグゼキュータ４１０も含む。ＳＱＬコンパイラ４１２は、ＳＱＬクエリを解析し、クエリのための実行コードを生成する。ＳＱＬオプティマイザ４１４は、処理される必要があるデータに基づいてクエリを実行するための最良の方法を決定する。ＳＱＬエグゼキュータ４１６は、リソースマネージャ３０２によって受信されるクエリのためのクエリコードを実行する。クエリスケジューラおよびコーディネータ４１８は、コンパイル、最適化および実行プラットフォームに対するディスパッチのために適切なサービスまたはシステムに対して、受信されたクエリを送信する。仮想ウェアハウスマネージャ４２０は、実行プラットフォーム内で実装される複数の仮想ウェアハウスの動作を管理する。

さらに、リソースマネージャ３０２は、構成およびメタデータマネージャ４２２を含み、これは、遠隔データストレージデバイス内およびローカルキャッシュ内に格納されたデータに関する情報を管理する。監視および作業負荷アナライザ４２４は、リソースマネージャ３０２によって実施されるプロセスを監視し、実行プラットフォーム内の仮想ウェアハウスおよび実行ノードにわたるタスク（例えば、作業負荷）の分散を管理する。構成およびメタデータマネージャ４２２と、監視および作業負荷アナライザ４２４は、データストレージデバイス４２６に結合される。

リソースマネージャ３０２は、トランザクション管理およびアクセス制御モジュール４２８も含み、これは、種々のタスクと、データストレージ要求およびデータアクセス要求の処理に関連付けられる他のアクティビティとを管理する。例えば、トランザクション管理およびアクセス制御モジュール４２８は、複数のユーザまたはシステムによる、データに対する一貫し、かつ同期したアクセスを提供する。複数のユーザ／システムは、同時に同一のデータにアクセスしてもよいため、データに対する変更は、現在のバージョンのデータを各ユーザ／システムが扱うことを確実にするために同期されなければならない。トランザクション管理およびアクセス制御モジュール４２８は、リソースマネージャ３０２内の単一の中央に集中した位置において、種々のデータ処理アクティビティの制御を提供する。

図５は、実行プラットフォームの一実施形態を図示するブロック図である。図５に図示されるように、実行プラットフォーム５１２は、複数の仮想ウェアハウス５０２、５０４および５０６を含む。各仮想ウェアハウスは、各々がキャッシュとプロセッサとを含む複数の実行ノードを含む。図５に図示された各仮想ウェアハウス５０２−５０６は３つの実行ノードを含むが、特定の仮想ウェアハウスは、如何なる数の実行ノードを含んでもよい。さらに、仮想ウェアハウス内の実行ノードの数は動的であり、さらなる需要が存在するときには新しい実行ノードが生成され、もう必要とされないときには既存の実行ノードが消去される。

各仮想ウェアハウス５０２−５０６は、図３に図示されたデータストレージデバイス３１６−３２０のうちの任意のデバイスにアクセスすることが可能である。したがって、仮想ウェアハウス５０２−５０６は、必ずしも特定のデータストレージデバイス３１６−３２０に割り当てられるわけではなく、その代わりに、データストレージデバイス３１６−３２０のうちの任意のデータストレージデバイスからデータにアクセスすることができる。同様に、図５に図示される実行ノードの各々は、データストレージデバイス３１６−３２０のうちの任意のデータストレージデバイスからデータにアクセスすることができる。幾つかの実施形態においては、特定の仮想ウェアハウスまたは特定の実行ノードは、特定のデータストレージデバイスに一時的に割り当てられてもよいが、仮想ウェアハウスまたは実行ノードは、その後、他の如何なるデータストレージデバイスからデータにアクセスしてもよい。

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

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

図５に図示された実行ノードは、１つのキャッシュと１つのプロセッサとを各々含むが、別の実施形態は、如何なる数のプロセッサと如何なる数のキャッシュとを含む実行ノードを含んでもよい。さらに、キャッシュは、異なる実行ノードの間でサイズが変化してもよい。図５に図示されたキャッシュは、ストレージプラットフォーム３１４（図３）内の一つ以上のデータストレージデバイスから検索されたデータをローカル実行ノードに格納する。このように、キャッシュは、遠隔ストレージシステムから常にデータを検索するプラットフォーム内で生じるボトルネック問題を軽減するか、または排除する。遠隔ストレージデバイスからデータに繰り返しアクセスする代わりに、本明細書に記述されたシステムおよび方法は、有意により高速であって、上記で議論されたボトルネック問題を回避する実行ノード内のキャッシュからデータにアクセスする。幾つかの実施形態においては、キャッシュは、キャッシュされたデータに対する素早いアクセスを提供する高速メモリデバイスを利用して実装される。各キャッシュは、ストレージプラットフォーム３１４内のストレージデバイスのうちの任意のストレージデバイスからデータを格納することができる。

さらに、キャッシュリソースおよびコンピューティングリソースは、異なる実行ノードの間で変化してもよい。例えば、一つの実行ノードは、多くのコンピューティングリソースと最小のキャッシュリソースとを含んでもよく、多くのコンピューティングリソースを必要とするタスクに対してその実行ノードを有用にする。別の実行ノードは、多くのキャッシュリソースと、最小のコンピューティングリソースとを含んでもよく、大量のデータをキャッシュすることを必要とするタスクに対してこの実行ノードを有用にする。幾つかの実施形態においては、実行ノードによって実施されるべき期待されるタスクに基づいて実行ノードが生成されると、特定の実行ノードに関連付けられたキャッシュリソースとコンピューティングリソースとが決定される。

さらに、特定の実行ノードに関連付けられたキャッシュリソースとコンピューティングリソースとは、実行ノードによって実施されるタスクの変化に基づいて、時間につれて変化してもよい。例えば、特定の実行ノードは、実行ノードによって実施されるタスクがプロセッサをより集中的に使用するものになる場合に、より多くの処理リソースが割り当てられてもよい。同様に、実行ノードは、実行ノードによって実施されるタスクがより大きいキャッシュ容量を必要とする場合に、より多くのキャッシュリソースが割り当てられてもよい。

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

さらに、各仮想ウェアハウスは、複数の実行ノードを有するものとして、図５に図示される。各仮想ウェアハウスに関連付けられる複数の実行ノードは、複数の地理的位置において複数のコンピューティングシステムを利用して実装されてもよい。例えば、仮想ウェアハウス５０２の具体的な例は、特定の地理的位置における一つのコンピューティングプラットフォーム上で実行ノード５０８および５１０を実装し、別の地理的位置において異なるコンピューティングプラットフォームにおける実行ノード５１２を実装する。実行ノードを実装するために特定のコンピューティングシステムを選択することは、（例えば、処理リソース要件およびキャッシュ要件などの）特定の実行ノードに対して必要とされるリソースのレベル、特定のコンピューティングシステムで使用可能なリソース、地理的位置内または地理的位置間でのネットワークの通信容量、どのコンピューティングシステムが仮想ウェアハウス内の他の実行ノードを既に実装しているか、などの種々の要因に依存し得る。実行プラットフォーム３１２もまた、フォールト・トレラントである。例えば、一つの仮想ウェアハウスが機能しない場合、その仮想ウェアハウスは、異なる地理的位置において異なる仮想ウェアハウスと素早く置換される。

特定の実行プラットフォーム３１２は、あらゆる数の仮想ウェアハウス５０２−５０６を含んでもよい。さらに、追加の処理および／またはキャッシュリソースが必要とされるときには新しい仮想ウェアハウスが生成されるように、特定の実行プラットフォーム内の仮想ウェアハウスの数は動的である。同様に、既存の仮想ウェアハウスは、仮想ウェアハウスに関連付けられたリソースがもう必要ではない場合には消去されてもよい。

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

コンピューティングデバイス６００は、一つ以上のプロセッサ６０２、一つ以上のメモリデバイス６０４、一つ以上のインターフェイス６０６、一つ以上のマスストレージデバイス６０８、一つ以上の入力／出力（Ｉ／Ｏ）デバイス６１０を含み、その全ては、バス６１２に結合される。（複数の）プロセッサ６０２は、（複数の）メモリデバイス６０４および／または（複数の）マスストレージデバイス６０８に格納された命令を実行する一つ以上のプロセッサまたはコントローラを含む。（複数の）プロセッサ６０２は、キャッシュメモリなどの種々の種類のコンピュータ可読媒体も含んでもよい。

（複数の）メモリデバイス６０４は、揮発性メモリ（例えば、ランダムアクセスメモリ（ＲＡＭ））および／または不揮発性メモリ（例えば、リードオンリーメモリ（ＲＯＭ））などの種々のコンピュータ可読媒体を含む。（複数の）メモリデバイス６０４は、フラッシュメモリなどの再書き込み可能なＲＯＭも含んでもよい。

（複数の）マスストレージデバイス６０８は、磁気テープ、磁気ディスク、光ディスク、ソリッドステートメモリ（例えば、フラッシュメモリ）などの種々のコンピュータ可読媒体を含む。種々のドライブは、種々のコンピュータ可読媒体からの読み出しおよび／または種々のコンピュータ可読媒体への書き込みを可能とするために、（複数の）マスストレージデバイス６０８に含まれてもよい。（複数の）マスストレージデバイス６０８は、リムーバブル媒体および／または非リムーバブル媒体を含む。

（複数の）Ｉ／Ｏデバイス６１０は、コンピューティングデバイス６００から、データおよび／または他の情報を入力または検索することを可能とする種々のデバイスを含む。例示的な（複数の）Ｉ／Ｏデバイス６１０は、カーソル制御デバイス、キーボード、キーパッド、マイク、モニタまたは他のディスプレイデバイス、スピーカ、プリンタ、ネットワークインターフェイスカード、モデム、レンズ、ＣＣＤまたは他の画像捕捉デバイスなどを含む。

（複数の）インターフェイス６０６は、他のシステム、デバイス、またはコンピューティング環境とコンピューティングデバイス６００が相互作用することを可能とする種々のインターフェイスを含む。例示的な（複数の）インターフェイス６０６は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、無線ネットワークおよびインターネットに対するインターフェイスなどの、あらゆる数の異なるネットワークインターフェイスを含む。

バス６１２は、バス６１２に結合された他のデバイスまたはコンポーネントと同様に、（複数の）プロセッサ６０２、（複数の）メモリデバイス６０４、（複数の）インターフェイス６０６、（複数の）マスストレージデバイス６０８および（複数の）Ｉ／Ｏデバイス６１０が互いに通信することを可能とする。バス６１２は、システムバス、ＰＣＩバス、ＩＥＥＥ１３９４バス、ＵＳＢバスなどの幾つかの種類のバス構造のうちの一つ以上を表す。

例示の目的のために、プログラムおよび他の実行可能なプログラムコンポーネントは、個別のブロックとして本明細書に図示されるが、このようなプログラムおよびコンポーネントは、様々な時点でコンピューティングデバイス６００の異なるストレージコンポーネントにおいて存在してもよく、（複数の）プロセッサ６０２によって実行されることを理解されたい。あるいは、本明細書に記述されたシステムおよび手順は、ハードウェア、またはハードウェアとソフトウェアおよび／またはファームウェアとの組み合わせで実装することができる。例えば、一つ以上の特定用途集積回路（ＡＳＩＣ）は、本明細書に記述されたシステムおよび手順のうちの一つ以上を実行するためにプログラムすることができる。

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

Claims (22)

1. 半構造データを格納するための方法であって、
   データソースから半構造データ要素を受信することと、
   前記半構造データ要素の集合がデータベースに追加されると、前記半構造データ要素の前記集合に対して統計解析を実施することと、
   前記半構造データの中から共通データ要素を特定することと、
   前記共通データ要素を、共通性の閾値に依存するファーストクラスデータおよびより低いクラスのデータとして割り当てることと、
   前記データソースからの前記共通データ要素をまとめて個別の擬似列にすることと、
   キャッシュメモリ内にファーストクラスデータを擬似列にして格納し、前記ファーストクラスデータ要素の前記擬似列に対応するメタデータおよび統計を、コンピュータベースのクエリジェネレータに利用可能にすることと、
   を含む、方法。
2. 前記半構造データの中から共通データ要素を再度特定することと、追加の共通データ要素をファーストクラスデータとして割り当てることと、キャッシュメモリ内に前記追加の共通データ要素を保存することと、をさらに含む、請求項１に記載の方法。
3. 前記共通性の閾値よりも下まで低下したファーストクラスデータ要素を特定することと、前記特定されたデータ要素に、より低いクラスを割り当てることと、キャッシュメモリから除去することと、をさらに含む、請求項２に記載の方法。
4. 前記共通性の閾値は、如何なる頻度で前記データ要素が前記半構造データに生じるかに関する計数である、請求項１に記載の方法。
5. 前記共通性の閾値は、如何なる頻度でデータ要素がユーザによって要求されるかである、請求項１に記載の方法。
6. より低いクラスのデータをディスクストレージ上に擬似列にして格納することをさらに含む、請求項１に記載の方法。
7. 非共通半構造データ要素をオーバーフローシリアライズ列にして格納することをさらに含む、請求項２に記載の方法。
8. 前記ファーストクラスデータ要素および前記より低いクラスのデータ要素および前記非共通半構造データをまとめることによって、半構造データを元の形式に再構成することをさらに含む、請求項７に記載の方法。
9. 現在の擬似列構造および内容を表すアップデートで、集約されたメタデータを維持することをさらに含む、請求項７に記載の方法。
10. メインメモリ内に、より低いクラスのデータ要素を格納することをさらに含む、請求項１に記載の方法。
11. コンピュータプロセッサと、キャッシュメモリと、ディスクストレージと、コンピュータ命令とを含む、半構造データを集約するためのシステムであって、
    データソースから半構造データ要素を受信するように構成された受信モジュールと、
    前記半構造データ要素の集合がデータベースに追加されると、前記半構造データ要素の前記集合に対応する統計解析データを導出するように構成された統計解析モジュールと、
    前記半構造データの中から共通データ要素を特定するように構成され、共通データ要素を、共通性の閾値に依存するファーストクラスデータおよびより低いクラスデータとして割り当てるように構成された特定モジュールと、
    前記データソースからの共通データ要素をまとめて個別の擬似列にするように構成された集約モジュールと、
    をさらに含み、
    前記集約モジュールは、ファーストクラスデータを擬似列にしてキャッシュメモリ内に格納するように構成され、かつ、前記ファーストクラスデータ要素の前記擬似列のメタデータおよび統計を、コンピュータベースのクエリジェネレータに利用可能にするように構成される、システム。
12. 前記特定モジュールは、前記半構造データの中から共通データ要素を再度特定するようにさらに構成され、かつ、追加の共通データ要素をファーストクラスデータとして割り当て、前記追加の共通データ要素をキャッシュメモリ内に保存するようにさらに構成される、請求項１１に記載のシステム。
13. 前記特定モジュールは、前記共通性の閾値よりも下まで低下したファーストクラスデータ要素を特定し、前記特定されたデータ要素に、より低いクラスを割り当て、キャッシュメモリから除去するようにさらに構成される、請求項１２に記載のシステム。
14. 前記共通性の閾値は、前記半構造データ内に前記データ要素が如何なる頻度で生じるかに関する計数である、請求項１１に記載のシステム。
15. 前記共通性の閾値は、データ要素が如何なる頻度でユーザによって要求されるかである、請求項１１に記載のシステム。
16. より低いクラスのデータはディスクストレージ上に擬似列にして格納される、請求項１１に記載のシステム。
17. 非共通半構造データ要素は、オーバーフローシリアライズ列にして格納される、請求項１１に記載のシステム。
18. 半構造データは、ファーストクラスデータ要素およびより低いクラスデータを再度まとめることによって、元の形式に再構成される、請求項１７に記載のシステム。
19. 半構造データを集約するための装置であって、
    データソースから半構造データ要素を受信するように構成された受信モジュールと、
    前記半構造データ要素の集合がデータベースに追加されると、前記半構造データ要素の前記集合に対応する統計解析データを導出するように構成された統計モジュールと、
    前記半構造データの中から共通データ要素を特定し、共通データ要素を、共通性の閾値に依存するファーストクラスデータおよびより低いクラスデータとして割り当てる集約手段であって、前記集約手段は、更に、前記データソースからの共通データ要素をまとめて個別の擬似列にし、前記集約手段は、更に、キャッシュメモリ内にファーストクラスデータを擬似列にして格納する、集約手段と、
    を含む、装置。
20. 前記集約手段は、更に、前記半構造データの中から共通データ要素を再度特定し、更に、追加の共通データ要素をファーストクラスデータとして割り当て、キャッシュメモリ内に前記追加の共通データ要素を保存する、請求項１９に記載の装置。
21. 前記集約手段は、更に、前記共通性の閾値よりも下まで低下したファーストクラスデータ要素を特定し、更に、前記特定されたデータ要素に、より低いクラスを割り当て、キャッシュメモリから除去する、請求項２０に記載の装置。
22. 前記集約手段は、更に、現在の擬似列構造および内容を表すアップデートで実質的に継続して、集約されたメタデータを維持する、請求項１９に記載の装置。