詳細な説明
以下の記載では、説明を目的として、いくつかの発明実施形態を完全に理解できるようにするために特定の詳細が記載される。しかしながら、これらの具体的な詳細がなくてもさまざまな実施形態が実施され得ることは明らかであるだろう。添付の図面および以下の説明は限定的であるよう意図されたものではない。
本開示は、概して、対話型アドホックデータベースクエリなどの分析クエリを効率的に実行するための技術に関する。SQLアドホッククエリなどのクエリの場合、クエリのために生成されたクエリプランが最適化されるとともに高度化されることで、最適化クエリプランまたは高度化クエリプランとして書換えられる。高度化クエリプランは、実行時に、用いるCPUサイクルがオリジナルの非最適化クエリプランよりも少ないので、オリジナルのクエリプランよりも高速で実行される。結果として、高度化クエリプランが生成されるクエリは、得られた結果またはクエリされているデータを損なうことなく、より高速で実行される。特定の実施形態では、最適化クエリプランまたは高度化クエリプランはまた、実行時に、用いるメモリリソースがオリジナルの非最適化クエリプランよりも少ない。
特定の実施形態では、オリジナルのクエリプランは、オリジナルのクエリプランにおける1つ以上のファクトスキャンオペレーション/オペレータのセットを識別し、次いで、書換えられた高度化クエリプランにおいて、次元コンテキストをファクトスキャンオペレーションのセットのうちの1つ以上に関連付けることによって最適化される。特定の実施形態では、次元コンテキストは、次元コンテキストに対応する1つ以上の述語条件(次元コンテキスト述語条件とも称される)をファクトスキャンオペレーションに関連付けることによって、ファクトスキャンオペレーションに関連付けられる。ファクトスキャンオペレーションは、ファクトレコードのソース(ファクトソースとも称される)からファクト(ファクトレコードまたはファクト行とも称される)をスキャンするかまたは読取るように構成されたクエリプランにおけるオペレーションである。高度化クエリプランにおける述語条件とファクトスキャンオペレーションとの関連付けはまた、ファクトスキャンオペレーションへの述語条件の伝搬、または、ファクトスキャンオペレーションが動作するファクトソースへの述語条件の伝搬とも称される。関連付けまたは伝搬されているので、高度化クエリプランにおけるファクトレコードのスキャン/読取りおよび/または処理の全体的コストはオリジナルのクエリプランと比較すると非常に少ない。結果として、高度化クエリプランは、実行時に、用いるCPUサイクルがオリジナルの非最適化クエリプランよりも少ないので、オリジナルのクエリプランよりも高速で実行される。
特定の実施形態では、クエリプランを最適化するプロセスは、クエリプラン内でどの1つ以上のファクトスキャンオペレーションが述語条件伝搬の候補であるかを識別することと、各々の候補ファクトスキャンオペレーションに関連付けられるべき1つ以上の述語条件を識別することと、さらに、当該関連付けを用いてクエリプランを書換えることとを含み得る。クエリについてのクエリプランは、当該関連付けを用いて実行される。この処理を実行するために、本明細書中に開示される多種多様な技術が用いられてもよい。
多種多様な技術を用いて、ファクトスキャンオペレーションに関連付けられるべき述語条件が識別され得る。たとえば、オリジナルのクエリプランの一部分からの述語条件は、書換えられた高度化クエリプランにおけるクエリプランの別の部分におけるファクトスキャンオペレーションに伝搬されてもよい。一例として、クエリプランの一部分における次元テーブルに適用される次元述語条件が伝搬されて、クエリプランの別の部分におけるファクトスキャンオペレーションに関連付けられてもよい。他のいくつかの事例では、特定の述語条件をファクトスキャンオペレーションに関連付けるのではなく、クエリプラン内の特定の述語条件またはオリジナルの述語条件から新しい述語条件が推論される(特定の述語条件の新しい述語条件への変換またはマッピングとも称される)とともに、新しい述語条件が特定のまたは述語条件ではなくファクトスキャンオペレーションに関連付けられる。新しい述語条件は、新しい述語条件でファクトスキャンオペレーションを実行するコスト(たとえば、実行時間)が特定の述語条件またはオリジナルの述語条件でファクトスキャンオペレーションを実行するコストよりも小さくなるような条件である。いくつかの事例では、クエリにおいて参照されるファクトテーブルからファクトレコードをスキャンするのではなく、OLAPインデックス、事前集約された実体化されたビューなどの他の物理的なファクト構造(ファクトソース)がスキャンの実行のために用いられてもよい。
上述したように、高度化クエリプランは、実行時に、用いるCPUサイクルがオリジナルの非最適化クエリプランよりも少ないので、オリジナルのクエリプランよりも高速で実行される。これを達成し得るさまざまな方法がある。場合によっては、クエリプランにおいて述語条件とファクトスキャンオペレーションとが関連付けられていることにより、書換えられたクエリプランによって処理されるファクトレコードの数はオリジナルのクエリプランと比較して低減される。たとえば、述語条件をファクトスキャンオペレーションに関連付けた結果、述語条件を満たすファクトレコードだけがクエリプランにおけるファクトスキャンオペレーションから次の下流オペレーションに提供される。これにより、高度化クエリプランにおける下流オペレーション(たとえば、ファクトテーブルと次元テーブルとの間の結合オペレーション)に提供されるとともに当該下流オペレーションによって処理されなければならないファクトレコードの数が低減される。これにより、高度化クエリプランにおける下流オペレーションの実行に関連付けられた演算オーバーヘッドが低減される。述語条件に基づくファクトレコードのこのフィルタリングにより、クエリプランによるファクトレコードの不要な重複処理が低減される。クエリプランによって処理されるファクトレコードの数が減ると、クエリプランとこれによりクエリプランが生成されるクエリ自体とについて実行時間がより高速になる。クエリプランによって処理されるファクトレコードの数が減ると、書換えられたクエリプランを実行するために用いられるメモリリソースも、より少なくなり得る。上述のように、特定の実施形態では、特定の述語条件から推論されるかまたは変換される新しい述語条件は、特定の述語条件ではなくファクトスキャンオペレーションに関連付けられてもよい。新しい述語条件は、新しい述語条件でファクトスキャンオペレーションを実行するコスト(たとえば、実行時間)が、特定の述語条件でファクトスキャンオペレーションを実行するコストよりも低くなるような条件である。たとえば、特定の述語条件に関連するファクトスキャンオペレーションは実行するのに2秒かかる可能性がある一方で、新しい述語条件に関連する同じファクトスキャンオペレーションは実行するのに1秒しかかからない可能性がある。述語条件を推論または変換することで、高度化クエリプランを非最適化クエリプランよりも高速で実行させる。さらに、特定の実施形態では、より高速の実行時間は、OLAPインデックスなどの利用可能な代替的なファクト表現に対して、当該ファクト表現のスキャン能力を活用するようにファクトスキャンを実行することによって達成される。たとえば、何らかの述語「P」に関してOLAPインデックススキャンに変換することにより、その組合わせがOLAPインデックスの迅速な述語評価およびスキップスキャンを活用することができるようになり、結果として、場合によってはファクトスキャン処理が桁違いに低減されることとなる。
性能の観点から、高度化クエリプランは、非高度化クエリプランよりも高速で実行され得るとともに、場合によっては、より少ないリソースを用い得る。本明細書中に開示される教示に基づいて実行されるかなりの数のクエリは、非高度化クエリプランでのクエリよりも10倍、25倍、100倍速く、またはさらに桁違いに高い速度で実行され得る。これは、ファクトテーブルが次元テーブルよりも桁違いに大きく、このため、ファクトレコードの処理に関連するスキャンコストを低減することが、大幅な性能向上につながるからである。たとえば、一例では、アドホッククエリのクエリ実行時間は206秒から16秒に短縮された。クエリは、大きなデータセット(たとえば、テラバイトデータセット)上でサブ秒で実行することができる。
多種多様な情報を用いることで、本明細書中に記載されるクエリプラン最適化が容易になり得る。特定の実施形態では、データベースクエリのために生成されるクエリプランは、クエリの構造、クエリのために生成されるクエリプランの構造、クエリされているデータベースに関連するスキーマ情報、およびクエリプランオプティマイザおよび/またはエンハンサが利用できるセマンティクス情報に基づいて最適化および高度化されてもよい。たとえば、ビジネスセマンティクスまたはビジネスインテリジェンス(business intelligence:BI)セマンティクス情報を用いて、クエリプランを書換えてもよい。セマンティクス情報は、実世界のプロセス、組織構造などに基づいてリッチ値および構造セマンティクスを有するビジネスデータを含み得る。セマンティクス情報は、データ中のビジネス階層および機能依存性のようなビジネスモデルについての情報を含み得る。たとえば、依存性情報は、データベースデータのさまざまなフィールド(たとえば、列)間の関係(たとえば、階層的または非階層的)を記述する情報を含み得る。たとえば、依存性メタデータは、「市」列の値と「州」列の値との間の階層関係を記述する情報(たとえば、サンフランシスコはカリフォルニアという州内の市である)を含み得る。階層の例は、時間の階層(たとえば、日、週、月、四半期、年など)、地理的階層(たとえば、市、州、国)などを含む。セマンティクス情報は、データキューブモデルセマンティクス情報を含み得る。特定の実施形態では、クエリプランの高度化のために用いられるメタデータは、分析されているデータが如何に物理的に格納されているかについての情報と、データ間の関係を識別する論理情報とを含み得る。特定の実施形態では、セマンティクス情報は、いかなるユーザ入力もなしに、分析されているデータを格納するデータベースの構造およびスキーマについての情報を分析することによって判断されてもよい。このような分析から導き出される推論は、最適化されるとともに高度化されたクエリプランを生成するようにクエリプランを書換えるために用いられてもよい。
たとえば、クエリのために生成されたクエリプランは、ファクトソースに対するファクトスキャンオペレーションを識別するために分析されてもよい。次いで、セマンティクス情報(たとえば、ファクトおよび次元コンテキストテーブルの結合オペレーション、データベースの列間の機能依存性、ファクトの物理的実体化)を用いて、書換えられた最適化クエリプランにおけるファクトスキャンオペレーションについての次元コンテキスト条件を能動的に識別してプッシュし得る。これは、書換えられたクエリプラン内のファクトレコードを処理するのに必要なコスト(たとえば、時間)の大幅な削減につながる。したがって、書換えられたクエリプランはより高速で実行される(たとえば、より少ないCPUサイクルを用いる)とともに、多くの場合用いるメモリリソースが非最適化クエリプランよりも少ないくなり得る。これにより得られるクエリについては、より高速で実行されるとともに場合によってはより少ないメモリリソースを用いるクエリプランが生成されることとなる。
図1Aは、例示的な実施形態を組込んだ分析プラットフォームまたはインフラストラクチャ100の簡略ブロック図である。分析プラットフォーム100は、1つ以上の通信ネットワークを介して互いに通信可能に連結された複数のシステムを含み得る。図1Aのシステムは、1つ以上の通信ネットワークを介して互いに通信可能に連結された処理システム150およびストレージシステム106を含む。通信ネットワークは、図1Aに示すさまざまなシステム間の通信を容易にし得る。通信ネットワークは、さまざまなタイプのネットワークであり得るとともに、1つ以上の通信ネットワークを含み得る。このような通信ネットワークの例は、インターネット、ワイドエリアネットワーク(wide area network:WAN)、ローカルエリアネットワーク(local area network:LAN)、イーサネット(登録商標)ネットワーク、パブリックまたはプライベートネットワーク、有線ネットワーク、無線ネットワークなど、およびこれらの組合わせを含むが、これらに限定されない。IEEE802.XXプロトコルスイート、TCP/IP、SAN、Apple Talk(登録商標)、Bluetooth(登録商標)、および他のプロトコルなどの有線プロトコルおよび無線プロトコルの双方を含むさまざまな通信プロトコルを用いて通信を容易にしてもよい。通信ネットワークは、図1Aに示すさまざまなシステム間の通信を容易にする任意のインフラストラクチャを含み得る。
図1Aに示す分析プラットフォーム100は、単なる一例にすぎず、主張される実施形態の範囲を必要以上に限定することを意図するものではない。プラットフォームは、クエリされているデータのサイズの変化および作業負荷の変化(たとえば、並列またはそれ以外の態様で実行されているクエリの数)に対処するために必要に応じて弾性的にスケールアウトすることができる。当業者であれば、多くの実現可能な変形例、代替例および変更例を認識するであろう。たとえば、いくつかの実現例では、分析プラットフォーム100は、図1Aに示されるよりも多いかもしくは少ないシステムもしくはコンポーネントを有していてもよく、2つ以上のシステムを組合わせてもよく、または、異なる構成または配置のシステムを有していてもよい。さらに、図1Aに示されるとともに本明細書中に説明されるインフラストラクチャは、スタンドアロンまたはクラスタの実施形態を含む多種多様な環境において、オンプレミスまたはクラウド環境(プライベート、パブリックおよびハイブリッドのクラウド環境を含むさまざまなタイプのクラウドであり得る)、オンプレミス環境、ハイブリッド環境など、として実現され得る。
特定の実施形態では、分析またはクエリされるべきデータは、ストレージシステム106によって格納されてもよい。ストレージシステム106に格納されるデータは、1つまたは複数のデータソースから得られてもよい。データは、コンピューティングノード上のディスクにおけるように、オブジェクト店舗、ブロック店舗、ただのディスクの束(jbod)など、およびそれらの組合わせなどのさまざまな形態で編成および格納され得る。ストレージシステム106は、データを格納するための揮発性メモリおよび/または不揮発性メモリを備えてもよい。たとえば、ストレージシステム106は、分析されるべきビジネスデータを格納するデータベースを含み得る。ビジネスデータは一般に多次元であり、セマンティックにリッチである。ストレージシステム106は、データを維持する物理的ストレージコンポーネント(たとえば、回転ハードディスク、SSD、メモリキャッシュなど)を含む分析プラットフォーム100のストレージ層を表すとともに、特定のクエリ作業負荷に最適に役立つ態様でリレーショナルデータ/空間データ/グラフデータを格納するための無数のデータ構造を提供するソフトウェアも含む。ストレージシステム106内のデータは、すべて1つの場所に配置されている必要はなく、分散して格納されていてもよい。データは、データレーキ、データウェアハウス、Hadoopクラスタなどのさまざまなストレージ/コンピューティング環境において編成および格納され得る。
ストレージシステム106および処理システム150のメモリリソースは、システムメモリおよび不揮発性メモリを含み得る。システムメモリは、1つ以上のプロセッサのためのメモリリソースを備えてもよい。システムメモリは、典型的には揮発性ランダムアクセスメモリ(random access memory:RAM)(たとえば、ダイナミックランダムアクセスメモリ(dynamic random access memory:DRAM)、シンクロナスDRAM(Synchronous DRAM:SDRAM)、ダブルデータレートSDRAM(Double Data Rate SDRAM:DDR SDRAM))の形態である。オペレーティングシステムに関連する情報および1つ以上のプロセッサによって実行されるアプリケーションまたはプロセスはシステムメモリに格納され得る。たとえば、実行時、オペレーティング・システム/カーネルをシステムメモリにロードしてもよい。加えて、実行時、サーバコンピュータによって実行される1つ以上のアプリケーションに関連するデータがシステムメモリにロードされ得る。たとえば、サーバコンピュータによって実行されているアプリケーションがシステムメモリにロードされて、1つ以上のプロセッサによって実行されてもよい。サーバコンピュータは複数のアプリケーションを並列に実行可能であってもよい。
不揮発性メモリを用いて、持続すべきデータを格納してもよい。不揮発性メモリは、ハードディスク、フロッピー(登録商標)ディスク、フラッシュメモリ、ソリッドステートドライブまたはディスク(SSD)、USBフラッシュドライブ、メモリカード、メモリスティック、テープカセット、ジップカセット、コンピュータハードドライブ、CD、DVD、ネットワーク接続ストレージ(network-attached storage:NAS)、ストレージエリアネットワーク(storage area network:SAN)を介して提供されるメモリストレージなどのさまざまな形態を取る可能性もある。いくつかの事例では、アプリケーションがサーバコンピュータに配備されるかまたはサーバコンピュータにインストールされるとき、アプリケーションに関連する情報が不揮発性メモリに格納されてもよい。
特定の実施形態では、ストレージシステム106内のデータは、1つ以上のスタースキーマとして論理的に構造化されるテーブル内の関係データベースに格納され得るか、または、多次元アレイ(一般に多次元キューブとも称される)などの専用ストレージ構造を備えたシステムに格納され得る。スタースキーマは、任意の数の次元テーブルを参照する中央ファクトテーブルを含む。各ファクトテーブルは、ファクトレコードの形でファクトまたはメトリックを格納する。ファクトテーブルは、ファクトをそれらのコンテキストに関連付ける次元テーブルにリンクされ得る。次元テーブルは、ファクトテーブル行に格納されたメトリックデータを記述するコンテキスト情報を格納している。ファクトテーブルは通常多くの次元に関連付けられているので、構造は図式的に星のように見え、このためそのような名称が付けられている。一般に、ファクトの数と一意の次元値の数との間に桁違いの差があり、ファクトの数が次元の数を大幅に上回っている。たとえば、企業の場合には何億もの販売ファクトレコードがあり得るが、販売されている店舗、州などのわずか数次元(たとえば、数千)の場合もある。結果として、ファクトテーブルのサイズは一般に非常に大きく、次元テーブルよりも桁違いに大きい。
スタースキーマという語は、ここでは、多くの次元テーブル行を有するファクト行間の論理関係を取込むために、その最も一般的な形態で用いられる。このため、スノーフレークスキーマのような変形例がまた、示唆されるともに本開示で用いられるスタースキーマという語の下に含まれる。スノーフレークスキーマは、ファクト行と次元との間の関係が間接的であり得る(直接的な関連付け以上のものを必要とする;たとえば、販売ファクト行は顧客・アドレス行にリンクする顧客行にリンクする)点でスタースキーマと区別される。
分析データを調べる別の方法としてn次元キューブがある。典型的な分析では、この大規模な多次元空間のいくつかの任意の部分空間(スライスとも称される)に焦点を合わせる。特定の任意の分析の焦点は、複数の次元および活動にわたり得るとともに、複数のステップを有し得るとともに、エンティティとそれらの活動との間に任意のリンクを含み得る。リレーショナルワールドでは、データキューブはスタースキーマとしてモデル化され得る。
リレーショナルデータベースにおいて、イベントまたはトランザクション(たとえば、製品の販売)は、多くの次元テーブルに結合する大きなファクトテーブルに取込まれてもよい。分析ソリューションは、ファクトテーブルが共通の次元セットを有する多くのこのようなスタースキーマを含み得る。図4は、店舗への返品のためのトランザクションに関連するデータに対応する例示的なスタースキーマ400を示す。スキーマ400は、店舗返品トランザクションを取込むとともに、ファクトレコードと次元レコードとの間の1対多の関係を記述する。図4に示されるスキーマ400によれば、Store_Returnは、店舗返品トランザクションに関連するメトリック情報を含むファクトレコードを格納する(強調された境界線を用いて示される)ファクトテーブルであり、他のテーブル(Date(日付)、Store(店舗)、Item(商品)、Customer(顧客)、Customer_Address)は、ファクトレコードについてのコンテキスト情報を格納する次元テーブルである。各々の返品トランザクションは、店舗識別子、市および州を含む返品がなされた店舗についての情報と、商品を復帰した顧客についての情報と、トランザクションの時間情報(月、日、年)とを含む関連付けられたコンテキストと共に記録される。スタースキーマ400は、店舗への返品が、Date(日付け)、Customer(顧客)、Item(商品)、Store(店舗)およびCustomer_Addressの次元レコードによって次元化され、Store_Returnsファクトレコードと結合され得ることを示す。
図2は、ファクトテーブル202と、図4に示されるスタースキーマ400に対応するファクトテーブル202にそれぞれ関連する複数の次元テーブル204~208とを備える例示的なデータベースデータ200を示す。ファクトテーブル202は、テーブル204の一次キー列218、テーブル206の一次キー列226、およびテーブル208の一次キー列230とそれぞれ結合して、行ではなく列をファクトテーブル202に追加することができる外部キー列210、212および214を含む。図2は、データベースデータ200をテーブルとして示しているが、当該データベースデータ200がインデックス、実体化されたビューおよび/またはタプルの他の任意のセットとして表現され得ることが認識されるはずである。
図2の例では、ファクトテーブル202はさらに、ファクトメトリック列216(return_amt)を格納するファクトレコードを含む。外部キー列210、212および214は、次元列220、222、224、228、232および234などの1つ以上の次元列の観点からファクトメトリック列216を分析することを可能にする。一般に、図2に示されるように、典型的には、次元レコードよりも多くのファクトレコードが存在する。たとえば、ファクトレコードの数は数百万になり得る一方で、次元レコードの数は数千となり得る。
処理システム150は、ストレージシステム106によって格納されたデータの分析を可能にするように構成されてもよい。分析は、SQLクエリなどの分析クエリを用いて実行されてもよい。処理システム150は1つ以上のクエリ130を受信するように構成されてもよい。特定の使用事例において、クエリ130は、処理システム150によって提供されるインターフェイスを用いてユーザによって入力され得る。他の場合、クエリ130は、他のアプリケーション、システムまたはデバイスから処理システム150によって受信されてもよい。いくつかの使用事例において、処理システム150はそれ自体のクエリを生成し得る。
特定の実施形態では、クエリに対して、処理システム150は、クエリに対する高度化クエリプランを生成するように構成される。以下においてより詳細に説明される多種多様な技術を用いて、高度化クエリプランが生成され得る。次いで、処理システム150は、ストレージシステム106によって格納されたデータに対して高度化クエリプランを実行し、結果セットを生成し得る。次いで、処理システム150は、結果セットを、受信されたクエリに対する応答として出力し得る。
図1Aに示される実施形態と同様に、リレーショナルデータベース内のファクトソースからファクトを非常に高速でスキャン/読取りするために、OLAPインデックス付け126(たとえば、OLAPインデックス)が提供されてもよい。特定の実施形態では、処理システム150は、OLAPインデックス126のうち1つ以上を生成するように構成されてもよい。
特定の実施形態では、図1Aに示す分析プラットフォーム100は、1つ以上のコンピュータのクラスタ上で実行され得る。たとえば、分析プラットフォーム100は、Apache SparkまたはApache Hadoopによって提供される分散型コンピューティングフレームワークを用いて実現されてもよい。各コンピュータは、1つ以上のプロセッサ(または中央処理ユニット(central processing unit:CPU))、メモリ、記憶装置、ネットワークインターフェイス、I/Oデバイスなどを備え得る。このようなコンピュータの例が図16に示されるとともに以下に説明される。1つ以上のプロセッサは、シングルコアまたはマルチコアのプロセッサを備え得る。1つ以上のプロセッサの例は、関連メモリに格納されたソフトウェアの制御下で動作する、Intel(登録商標)、AMD(登録商標)、ARM(登録商標)、Freescale Semiconductor、Inc.などによって提供されるような汎用のマイクロプロセッサを含み得るが、これらに限定されない。分析プラットフォーム100のソフトウェアコンポーネントは、オペレーティングシステム上のアプリケーションとして動作してもよい。サーバコンピュータによって実行されるアプリケーションは1つ以上のプロセッサによって実行され得る。
処理システム150によって生成される高度化クエリプランの結果として、高度化クエリプランが生成されるクエリの実行がより高速にされる。これにより、クエリのための応答時間がより高速となる。これらの高速の応答時間は、分析されている結果またはデータを損なわずに、対話的に、ストレージシステム106に格納された多次元データの分析を可能にする。対話型クエリは、たとえば、機械学習技術、クリックストリームおよびイベント/時系列に関連付けられたデータに対して、より一般的には、サイズおよび複雑さが急速に増大する可能性のある任意のデータセットに対して、実行されてもよい。
さらに、クエリは、ストレージシステム106内のデータベースに格納されたデータに対して直接実行されるが、事前集約されたデータに対しては実行されない。したがって、クエリは、事前集約データまたは抽出物を作成する必要なしに、所定の位置で大きなデータセットに対して実行することができる。代わりに、クエリは実際の元の生データ自体に対して実行され得る。特定の実施形態では、クエリは、本明細書中で説明するとおり、述語条件を用いるとともに、完全分散型演算エンジンでのメモリ内OLAPインデックスを用いることによって、より高速で行われる。これにより、分析プラットフォーム100が、事前集約されたデータに対して実行することができないアドホッククエリを促進することが可能となる。アドホッククエリは、事前に定義されていないクエリである。アドホッククエリは、一般に、情報が利用可能になると当該情報を分析するために作成される。本明細書で説明される分析プラットフォーム100は、非常に大きな(テラバイト以上の)多次元データ(たとえば、データレーキに格納されたデータ)に対して対話型アドホッククエリを、非常にコスト効率良く、実行する能力を提供する。従来の技術を用いて過去に非常に大きな(テラバイト以上の)多次元データに対してこのような対話型アドホッククエリを実行することは、法外な費用がかかるものであって、スケーリングしていなかった。
さらに、Apache Sparkを用いる分析プラットフォームの実装により、本質的に、クエリを大規模に実行することが可能になる。コンピュータおよびストレージ(たとえば、新しいデータが分析のために利用可能である)が独立してスケーリング可能である弾性環境が提供される。
分析プラットフォーム100では、クエリされるべきデータは、1つ以上のさまざまな分析ツールを用いて分析することができる中央位置に格納されている。さまざまなツールにより可能化すべきデータを固有に準備する必要はない。さまざまなユーザが、PythonまたはRを実行するZeppelinまたはJupyterノートブック、TableauのようなBIツール等を含む選択されたツールでデータにアクセスすることができる。
大量の多次元データの場合、対話型のクエリを大規模に実行することは困難である。これは、対話型のクエリが高速の応答時間を必要とするからである。大量の多次元データの場合、データの量(たとえば、テラバイトのデータ)が増加するにつれて、かつデータセットにアクセスしようとするユーザの数が増加するにつれて、クエリ性能が低下する。さらに、ファクトテーブルと次元テーブルとの間の結合は、付加的な性能ボトルネックを引起こす可能性がある。これまで、この問題を軽減するために事前集約技術が用いられてきた。多次元データの分析を容易にするために、たとえば、OLAPキューブ、抽出物、および実体化された事前集約型テーブルが用いられてきた。
事前集約されたデータ(集約データまたは集約物とも称する)は、1つ以上の事前集約(または集約)技術を用いていくつかの基礎となるデータ(元データまたは生データと称する)から生成されたデータである。データ集約または事前集約技術は、データが集計形式で表現される任意のプロセスを含む。事前集約されたデータは、予め演算されたデータまたは集計されたデータを含み得るとともに、事前集約されたテーブル、抽出物、OLAPキューブなどに格納され得る。ファクトが集約される場合、これは次元性を排除することによって、またはファクトをロールアップされた次元に関連付けることによって行われる。したがって、事前集約されたデータは、事前集約されたデータ生成の基となる元データまたは生データからの詳細をすべて含むわけではない。
しかしながら、事前集約はいくつかの欠点を有する。すべての事前集約技術は粒度の損失をもたらす。事前集約では、特定の予め定められた事前集約物だけが提供されるので、データの詳細が失われてしまう。たとえば、元データセットまたは生データセットは販売情報を日単位で記録し得る。このデータに対して月単位の事前集約が実行されると、日単位または日ごとの情報が失われてしまう。すべての次元およびメトリックからなるすべての組合わせに対して事前集約データセットまたはキューブを構築することは非現実的である。このように、事前集約はアドホックのクエリを実行する能力を制限してしまう。なぜなら、より高いレベルの事前集約された集計(たとえば、1月当たりの情報)の背後にあるキー情報(たとえば、1日当たりの情報)が利用できないからである。クエリは事前集約されたデータに対して実行されるが、事前集約の生成の基となった元データまたは生データに対して実行されるものではない。したがって、集約は、分析が実行され得るグレインを変化させる。ファクトのグレインは、イベントが記録される最低レベルを指している。たとえば、製品の販売は、販売時間およびタイムスタンプを用いて記録されてもよい。販売の集約は、チャネルおよび製品ごとの収入、またはカテゴリ、製品、店舗、州ごとの収入など、複数のレベルにわたってなされてもよい。複数の粒度および次元でデータを調査する能力が重要となる。事前集約のための正しい粒度は予め予測するのが困難である。したがって、事前集約されたキューブおよび実体化された集計テーブルは、ビッグデータ分析の場合には上手く機能しない。
分析プラットフォーム100によれば、事前集約ベースの分析技術に関連付けられたさまざまな欠点が回避される。分析プラットフォーム100は、大規模かつ高速でさまざまな粒度および寸法の多次元データのデータ分析を実行するためのフレームワークを提供する。
本願の目的のために、「事前集約されていないデータ」という語は、事前集約されたデータまたは事前演算されたデータを含まないデータを指すのに用いられる。特定の実施形態では、分析プラットフォーム100は、ストレージシステム106に格納された事前集約されていないデータに対してクエリが実行されることを可能にする。これにより、ストレージシステム106に格納された事前集約されていないデータに対してアドホックのクエリを行うことが可能となる。加えて、処理システム150によって提供されるクエリプランが高度化されているので、クエリのための応答時間が劇的に減少し、これにより、対話型クエリの実行が可能となる。本明細書に記載される分析プラットフォーム100は、非常に大きな(テラバイト以上の)多次元データ(たとえば、データレーキに格納されたデータ)に対して対話型アドホッククエリを、非常にコスト効率良く、実行する能力を提供する。従来の技術を用いて過去に非常に大きな(テラバイト以上の)多次元データに対してこのような対話型アドホッククエリを実行することは、法外な費用がかかるものであって、スケーリングしていなかった。
図1Bは、特定の実施形態に従った、図1Aに示す分析プラットフォーム100のより詳細な図を示す簡略ブロック図である。図1Bに示す分析プラットフォーム100は、単なる一例にすぎず、限定するように意図されるものではない。当業者であれば、多くの実現可能な変形例、代替例および変更例を認識するであろう。たとえば、いくつかの実現例では、データ分析プラットフォーム100は、図1Bに示されるよりも多くのコンポーネントもしくは少ないコンポーネントを有していてもよく、2つ以上のコンポーネントを組合わせてもよく、または、異なる構成または配置のコンポーネントを有していてもよい。さらに、図1Bに示されるとともに本明細書中に説明されるインフラストラクチャは、スタンドアロンの実施形態を含む多種多様な環境、クラウド環境(プライベート、パブリック、ハイブリッドのクラウド環境を含むさまざまなタイプのクラウドであり得る)、オンプレミス環境、ハイブリッド環境などで、実現され得る。
図1Bの例では、図1Aに示す処理システム150は、データ分析システム102およびデータベース管理システム(DBMS)104を備える。データ分析システム102およびデータベース管理システム(DBMS)104は互いに、かつストレージシステム106にも通信可能に連結され得る。いくつかの実施形態では、データ分析システム102、DBMS104、およびストレージシステム106は、OLAPデータベースシステムのさまざまな論理層を表わし得る。いくつかの実施形態では、データ分析システム102、DBMS104、およびストレージシステム106は物理的に別個のシステムであり得る。他の実施形態では、これらは1つのシステムに組合わされてもよい。DBMS104およびデータ分析システム102はともに、ビジネスインテリジェンス技術をApache Sparkの能力と組合わせる強力な分析プラットフォームを提供する。
ストレージシステム106は、分析されるべきデータをファクトテーブルおよび次元テーブルに格納し得る。図1Bに示されるように、ファクトテーブル124、OLAPインデックス126、実体化されたビュー128および/または他のソースを含むファクトレコードの複数のソース108が存在し得る。ファクトテーブル124は1つ以上の行および1つ以上の列を備え得る。この場合、各々の行はファクトレコードを表わし得るとともに、列はレコードのフィールドを表わし得る。いくつかの実施形態では、ストレージシステム106は、環境100内で分散および/または仮想化されてもよい。
ストレージシステム106はまた、1つ以上の次元レコードを格納する1つ以上の次元テーブル110として、ファクトレコードに関連付けられたコンテキストを格納し得る。典型的には、ファクトレコードは、次元テーブル110内の次元レコードに関して分析することができるメトリックの値を格納する。たとえば、ファクトレコードは売上高を含み得るとともに、次元レコードは日付け値を含み得る。この日付け値に従って、売上高が集約、フィルタリングまたは分析され得る。ファクトレコードソース108(たとえば、ファクトテーブル、OLAPインデックス、および実体化されたビュー)ならびに次元テーブル110およびレコードについては以下でより詳細に説明する。
ストレージシステムはメタデータ109を格納し得る。メタデータ109は、テーブル、列、ビューなどのリレーショナルアーチファクトについての情報を含み得る。
図1Bの例では、ストレージシステム106は、スキーマ情報116および統計情報112などのデータベース管理システムに関連付けられた他の情報をさらに格納し得る。スキーマ情報116は、データベースに関連付けられたテーブル、インデックスおよび他のアーチファクトの構造を識別し得る。たとえば、スタースキーマの場合、スキーマ情報116は、ファクトレコードと次元レコードとの間の関係を記述する情報を含み得る。たとえば、スキーマ情報116は、販売データが時間次元および地理的領域次元に従って問合わされ得ることを判断するために用いられてもよい。特定の実施形態では、スキーマ情報116は、ドメインエキスパートまたはアナリストによって定義されてもよい。スキーマ情報116は、図4および図9に示されるスキーマなどのスタースキーマを定義し得る。
統計112は、ファクトレコードまたは次元レコードについての情報、ならびにデータベース管理システム104のクエリプランおよび性能関連属性に関する他の情報を含み得る。たとえば、統計112は、テーブルレベル統計(たとえば、テーブル中の行の数、テーブルのために用いられるデータブロックの数、もしくはテーブルの平均行長)および/または列レベル統計(たとえば、列中の別個の値の数、または列中に発見される最小値/最大値)を含み得る。
DBMS104は、1つ以上のデータベースを作成すること、データベースにデータを追加すること、データベースに格納されたデータを更新および/または削除すること、ならびに、データベースおよび格納されたデータを管理することに関連する他の機能、を可能にする機能を提供するように構成され得る(たとえば、1つ以上のプロセッサによって実行されたときに機能を可能にするソフトウェアを備え得る)。DBMS104はまた、ストレージシステム106に格納されたデータを分析するための1つ以上のクエリ130を受信し、クエリに対応する分析を実行し、クエリ結果132を出力するように構成され得る。クエリ130は、構造化クエリ言語(Structured Query Language:SQL)などのさまざまな形態および言語であってもよい。
クエリ130は、DBMS104のユーザなどの1つ以上のソースや別のシステムなどから受信され得る。たとえば、図1Bに示される実施形態では、特定の事例において、クエリは、データ分析システム(data analytics system:DAS)102から受信されてもよい。DAS102は、ストレージシステム106に格納されたデータの分析を実行するように構成され得る。DAS102は、ストレージシステム106によって格納されたデータに対してDBMS104によって実行される分析クエリを生成するように構成されたソフトウェアを含み得る。たとえば、ストレージシステム106が販売レコードを格納している場合、DAS102は、販売レコードを分析するためのクエリ(たとえば、販売傾向を分析するためのクエリ、広告キャンペーンを分析するためのクエリ、およびビジネス活動に関する見通しを得るかまたは有用なパターンを抽出するための他のクエリ)を生成して、DBMS104に送信してもよい。特定の実施形態では、DAS102は、分析クエリを生成するために、ストレージシステム106に格納された情報(たとえば、スキーマ情報116)を用い得る。たとえば、スタースキーマ116を用いて、販売データが時間次元および地理的領域次元に従って問合わせされ得ることを判断してもよい。DAS102から受信したクエリに対応するとともにDBMS104によって検索された結果は、DBMS104によってDAS102に提供され得る。
図1Bに示されるように、DBMS104は、クエリ130を受信するためのインターフェイス122を提供し得る。パーサ120は、受信されたクエリの構文分析およびセマンティックス分析を実行するように構成され得る。たとえば、SQLクエリの場合、パーサ120は、クエリ中のSQLステートメントが正しい構文であるかどうかチェックするとともに、クエリ中で参照されるデータベースオブジェクトおよび他のオブジェクト属性が正しいかどうかをチェックするように構成され得る。
クエリが、パーサ120によって実行される構文チェックおよびセマンティックチェックにパスした後、オプティマイザ114は、クエリを効率的に実行するためのクエリプランを決定するように構成され得る。オプティマイザ114は、クエリを最適に実行するためのクエリプランを出力し得る。特定の実施形態では、実行プランは、実行されるべきオペレーション/オペレータの連なりまたはパイプラインを含む。実行プランは、個々のオペレーション/オペレータを表すツリーまたはグラフのノードを備えたルートツリーまたはグラフによって表されてもよい。クエリプラングラフは、一般に、グラフのリーフから始まってルートに向かって進むように実行される。クエリプランのリーフは、典型的には、ファクトレコードまたは行がファクトテーブルなどのファクトソースからスキャンまたは読取られるファクトスキャンオペレーションを表す。クエリプランにおける任意のリレーショナルオペレータの出力は、演算されたデータセットである。クエリプランにおけるオペレーションによって返される演算されたデータセット(たとえば、行またはレコードのセット)は、クエリプランパイプラインにおける次のオペレーション(親オペレーションまたは下流オペレーションとも称される)への入力として提供され、次のオペレーションによって消費される。クエリプランパイプラインにおける最後のオペレーション(クエリプラングラフのルート)において、ファクト行がSQLクエリの結果として返される。したがって、クエリプランにおける特定のオペレーションによって返される行は、クエリプランパイプラインにおける次のオペレーション(特定のオペレーションの親オペレーションまたは下流オペレーション)への入力行となる。オペレーションによって返される行のセットはしばしば行セットと称され、行セットを生成するクエリプラン内のノードは行ソースと称される。したがって、クエリプランは、あるオペレーションから別のオペレーションへの複数の行ソースの流れを表す。クエリプランの各オペレーションは、データベースから行を検索するか、または1つ以上の他の子オペレーションもしくは上流オペレーション(もしくは行ソース)から行を受け入れる。
特定の実施形態では、オプティマイザ114は、クエリプランを生成するためにコストベースの最適化を実行し得る。いくつかの実施形態では、オプティマイザ114は、I/O、CPUリソース、およびメモリリソース(最適なスループット)を含む最小量のリソースを用いてクエリを実行することができる、クエリのためのクエリプランを生成しようとしてもよい。オプティマイザ114は、クエリプランを生成するために、ファクトソース108、スキーマ情報116、ヒント、および統計112についての情報などのさまざまな情報を用いてもよい。特定の実施形態では、オプティマイザ114は、潜在的なプランのセットを生成し、各プランに対するコストを推定し得る。この場合、プランのためのコストは、プランを実行するのに必要な予想されるリソース使用に比例する推定値である。プランのためのコストは、アクセス経路、プランにおけるオペレーション(たとえば、結合オペレーション)に基づいていてもよい。アクセス経路は、データがデータベースから検索される手段である。ファクトテーブル内の行またはレコードは、フルテーブルスキャン(たとえば、スキャンによって、ファクトテーブル内のすべての行/レコードが読取られ、選択基準を満たさないものがフィルタリングによって除去される)により、インデックス(たとえば、インデックス付けされた列値を用いて、インデックスを詳細に検討することによって行が検索される)を用いて、実体化されたビューまたは行id(rowid)スキャンを用いて、検索され得る。次いで、オプティマイザ114は、プランのコスト同士を比較し、最低コストのプランを選択し得る。
特定の実施形態では、エンハンサ103は、オプティマイザ114によって選択されたクエリプランをさらに高度化/最適化し、高度化されて最適化されたクエリプランを生成するように構成される。エンハンサ103によって生成される高度化クエリプランはオプティマイザ114によって生成されるクエリプランよりも優れている。なぜなら、この高度化クエリプランは、非高度化クエリプランよりも高速で実行されるとともに、多くの場合、非高度化クエリプランよりも少ないメモリリソースを使用し得るからである。
エンハンサ103によって生成された最適化された高度化クエリプランは、次いで、ストレージシステム106に格納されたデータに対してクエリプランを実行するように構成されたエグゼキュータサブシステム105に提供されてもよい。エンハンサ103から受信されたクエリプランを実行することによりエグゼキュータ105によって得られた結果は、次いで、入力クエリに対する結果応答としてDBMS104によって返されてもよい。エグゼキュータ105は実行時プロセスの実行層を表わしている。実行時プロセスの実行層は、実行時プロセスに提供された高度化クエリプランに基づいてクエリを処理する。これらは、データタプルストリームに対して動作するとともにこれらを特定の方法で変換するオペレータ/オペレーションの実現例(たとえば、SQL、Graph、Spatialなど)を含み得る。
エンハンサ103は、オプティマイザ114によって生成されたクエリプランから高度化クエリプランを生成するためにさまざまな技術を用い得る。特定の実施形態では、エンハンサ103は、DAS102によって格納されるメタデータ/セマンティクス情報117を用いて、オプティマイザ114によって生成されるクエリプランをさらに最適化および高度化し得る。たとえば、スタースキーマのために利用可能な(たとえば、スタースキーマセマンティックモデルからの)セマンティクス情報に基づいて、エンハンサ103は、オプティマイザ114によって生成されるクエリプラン中の、ファクトレコードのソースのスキャンオペレーション中に適用可能である次元コンテキスト/述語条件を推論するように構成されてもよい。この推論された情報は、オプティマイザ114によって生成されたクエリプランをさらに最適化するためにエンハンサ103によって用いられてもよい。特定の実施形態では、エンハンサ103は、(たとえば、スタースキーマまたはキューブのセマンティックモデルにおける)セマンティックデータにおいて定義されたフィールド/列機能依存を利用して、ファクトレコードのソースに対するスキャンオペレーションについての適用可能な述語条件として、推論された次元コンテキスト/述語を変換する方法を実行する。いくつかの事例では、エンハンサ103は、インデックス内のデータ構造を活用するファクトレコードのインデックスソース(たとえば、OLAPインデックスファクトソース)についての、推論された次元コンテキスト/述語条件を適用してもよい。
一般に、本願の目的のために、ファクトソースという語は、ファクトレコードのソースを指すために用いられる。ファクトソースは、(たとえばファクトレコードの)ファクトのソースである任意の関係であり得る。ファクトソースは、元ファクトテーブルまたは複数ファクトについての他の何らかの実体化であり得る。一般的な実体化技術は、事前集約されたビューおよびキューブ表現、たとえばOLAPインデックスなどを含む。たとえば、ファクトソースは、ファクトテーブル(たとえば、スタースキーマに基づくリレーショナルデータベースにおけるファクトテーブル)、インデックス(たとえば、多次元空間の任意のサブ領域についてのファクトに直ちにアクセスする能力を提供する事前結合インデックスなどの、スタースキーマまたはキューブ上のOLAPインデックス)、または、実体化されたビュー(たとえば、スタースキーマのための何らかの集約レベルでの実体化されたビュー)であり得る。ファクトソースは、ファクトレコード(たとえば、ビジネスファクト)のソースである任意のデータセットまたはテーブルを表す。ファクトは特定の次元グレインであり得る。
上述したように、エンハンサ103は、次元コンテキスト/述語条件を推論するためにメタデータ/セマンティクス情報117を用い得る。セマンティクス情報117は、ビジネスインテリジェンス情報を含み得る。たとえば、セマンティクス情報117は、実世プロセス、組織構造、キューブ情報などに基づくリッチ値および構造セマンティクスを有するビジネスデータを含み得る。セマンティクス情報は、データ中のビジネス階層および機能依存性のようなビジネスモデルに関する情報を含み得る。この階層および依存性情報は、高度化クエリプランを生成するためにエンハンサ103によって用いられ、結果として、クエリの実行が高速化されることとなる。たとえば、依存性メタデータ情報は、データベースデータのさまざまなフィールド(たとえば、列)間の関係(たとえば、階層的または非階層的)を記述する情報を含み得る。たとえば、依存性メタデータは、「市」フィールド列の値と「州」フィールド列の値との間の階層関係を記述する情報(たとえば、サンフランシスコはカリフォルニアという州の市である)を含み得る。エンハンサ103は、クエリサブプランの結果の粒度と共に依存性メタデータを用いて、クエリサブプラン内のファクトソーススキャンに関する述語条件適用性を推論してもよい。特定の実施形態では、セマンティクス情報は、ユーザ入力なしに、クエリによって分析されているデータを格納するデータベースの構造およびスキーマに関する情報を分析することによって判断されてもよい。
クエリプランを高度化するためにエンハンサ103によって用いられるセマンティクス情報は、複数のソースから利用可能であり得るかまたは確認され得る。一例として、セマンティクス情報は、ビジネスインテリジェンス(BI)データソースから利用可能であり得る。たとえば、図1Bに示される実施形態に示されるように、DAS102は、セマンティクス情報117を含むBI情報を格納するさまざまなデータソースを含み得るかまたはそれらにアクセスし得る。他の実施形態では、セマンティクス情報は、分析されるデータの構造であり得るとともにデータを格納するのに用いられるデータ構造であり得る。たとえば、分析されるデータを格納するデータベースの場合、データベースについてのスキーマ情報116を用いてセマンティクス情報を判断してもよい。エンハンサ103は、スキーマ情報116を用いて、入力されたクエリ内の述語に基づいて述語条件アプリケーションと、さらに別の述語条件とを推論してもよい。
オプティマイザ114およびエンハンサ103は、図1Bでは別個のサブシステムとして示されているが、これは限定を意図したものではない。代替的な実施形態では、エンハンサ103はオプティマイザ114の一部であってもよい。このような実施形態では、オプティマイザ114は、クエリプランを選択し、次いで、本開示で説明する技術を用いてクエリプランを高度化する。特定の実施形態では、エンハンサ103は、DBMS104ではなくDAS102の一部であってもよい。このようなシナリオでは、DBMS104は、DAS102と協働的に機能して、高度化クエリプランを生成し得る。特定の実施形態では、パーサ120、オプティマイザ114、エンハンサ103およびエグゼキュータ105は、DBMS104のクエリエンジンと総称されてもよい。
上述のように、図2に示される例などのデータレコードを格納するデータベースが、SQLクエリなどの分析クエリを用いてさらに分析され得る。典型的なクエリは、次元テーブルと組合わされるとともに互いに組合わされる1つ以上のファクトソースを含み得る。特定の実施形態では、本明細書に開示されるように、エンハンサ103は、各ファクトソーススキャンの観点から、クエリについて、オプティマイザによって生成されたクエリプランを分析するとともに、処理されるファクト行の数が著しく減少するように、および/またはスキャンオペレーションを実行する全体的コストが削減されるように、ファクト行に適用され得る次元コンテキスト(たとえば、次元フィルタ)を推論しようと試みる。スター結合(ファクトソースとそれらの次元コンテキストとの組合せを表す結合)の場合、以下のものを用いることで、推論されるとともにファクトソースに適用されるべきさまざまな次元コンテキストを識別することができる。
・ スタースキーマのエッジに沿った結合が無損失分解の組合せを表す(したがって、新しいファクトが導入されない)というファクトを利用することができる。
・ スタースキーマのセマンティックモデルにおける関数依存性を利用することができる。
・ OLAPインデックスファクトソースの場合、書換えを行うことができる。
ファクトソースがそれぞれの次元でファクトを事前結合することができるため、スタースキーマにおける結合は、ファクトソースのコンテキストにおけるファクトソース結合として分類される。スタースキーマ結合は、ファクトソースを形成する際に詳細に検討される結合である。
データベース200に格納されたデータを分析するために、分析クエリが、データベースデータ200に対して実行されるべく受信され得る。このようなクエリの例がクエリAとして以下に示される。
クエリA
クエリAと同等の自然言語は、「「問題となる」顧客と店舗との関係を識別するためのものである。ここで「問題となる」とは、店舗の平均の20%を超える返品量を有するものとして定義されている」。質問は、顧客とこれら顧客が訪問した店舗との関係に関するものであって、顧客行動全体に関するものではない。さらに、テネシー州(Tennessee)についての分析が行われる。
上述のクエリAなどのクエリを受信すると、データベース管理システムは、クエリをパースし、次いで、クエリについてのクエリプランを生成するように構成される。次いで、クエリプランが、格納されたデータレコードに対してデータベース管理システムによって実行されて、クエリに関する結果が得られる。図3は、クエリAのために生成され得るクエリプラン300の論理ツリーまたはグラフ図である。クエリプラン300はオプティマイザ114によって生成されて選択されるクエリプランを表わしている。クエリプラン300は、関係性テーブル内のデータがどのように演算されるかについての論理フローグラフを表す。前述したように、クエリプランは、クエリプランパイプラインにおける或るオペレーションから別のオペレーションへの行ソースの流れを表す。クエリプランの各オペレーションは、データベースから行を検索するか、または1つ以上の他のオペレーション(または行ソース)から行を受取る。
クエリプラン300は、ファクトテーブルまたは次元テーブルを表す4つのリーフノードを含む。クエリプランにおける非リーフノードはさまざまなリレーショナルオペレータを表す。図3に示す例は、フィルタオペレータ、結合オペレータ、集約オペレータ、プロジェクトオペレータを含む。非リーフノードは、その子ノードが出力した行を入力とし、非リーフノードが出力した行を非リーフノードの親ノードへの入力として提供されるものとするか、または、非リーフノードがルートノードであれば、ルートノードが出力した行またはレコードをクエリ実行の結果として提供する。たとえば、図3において、ノード310は、ノード308および304によって出力される行を入力とし、ノード308は、ノード306によって出力される行を入力とし、ノード304は、店舗テーブルのスキャンによって返される行またはレコードを入力とする。
クエリプラン300では、左側の集約サブプラン302は、Customer(顧客)グレインおよびStore(店舗)グレインでの返品量を演算することを含み、右側の集約サブプラン312は、Store(店舗)グレインでの返品量を演算する。次いで、これらを結合して、返品量が対応する店舗平均を20%上回っているCustomer(顧客)とStore(店舗)との組合わせについての情報を抽出する。この後、行は、テネシー州にある店舗に対してフィルタリングされる。
クエリは一般に複数の層を含み、そのうちのいくつかは、未処理のファクトから値を演算する構築ブロック層である。たとえば、分析クエリは、セットの上からn個/下からn個を結合、集合、順序付け、および採用するといったオペレーションによって組合わされる多次元計算の層と考えることができる。クエリAによって提示される比較的単純な質問であっても、クエリプラン300に示されるように、店舗返品スタースキーマに対して複数のAggregate(集約)-Join(結合)パスを実行することを伴う。Aggregate(集約)-Join(結合)は各々は、非常に大型のファクトテーブルをスキャンすることを含むとともに、1つ以上の次元テーブルと結合する。この場合、次元テーブルの大部分はファクトテーブルと比べて小さい。
図3に示すクエリプラン300は、クエリAのライン2~8におけるサブクエリに対応するサブプラン302を含む。図3の例では、サブプラン302はサブクエリに対応するが、クエリサブプランはサブクエリに限定されないことが認識されるはずである。むしろ、クエリサブプランは、データベースクエリのいずれの部分にも対応し得る。
サブプラン302は、クエリAのライン7における述語を評価するためのフィルタオペレーションおよび結合オペレーションを含む。プラン300によれば、述語条件「年=2000」は、「Date(日付け)」次元レコードに対して評価され、これによりこれら「Date(日付け)」次元レコードをフィルタリングするためのものである。その後、「Store_Returns」ファクトレコードをフィルタリングされた「Date(日付け)」次元レコードと結合することによって、述語条件「sr.date_key = d.date_key」が評価される。しかしながら、結合オペレーションを実行することは、典型的には多数の(たとえば、数百万の)ファクトレコードの処理を伴うので、計算集約的であり得る。
サブプラン302に接続されていないクエリプラン300の別個のブランチにおいて、プラン300は、クエリAのライン16に対応するフィルタオペレーション304(州=「TN」に対するフィルタ)をさらに含む。プラン300によれば、フィルタオペレーション304はサブプラン302のオペレーションとは別個に実行されることとなる。その後、フィルタリングされた「Store(店舗)」次元レコードは、ノード306および308を通過した後にサブプラン302におけるオペレーションを実行する結果のうちいくつかと結合されることとなる。
プラン300は、ファクトテーブルStore_Returns上の2つのファクトスキャンを含む。しかしながら、クエリ全体のコンテキストは、テネシーという州および年2000である。しかしながら、プラン300では、ファクトソースStore_Returnsのスキャンを含むサブプラン302は、州がテネシーであるものにしかレコードを制限しない。結果として、テネシー以外のレコードも、処理のために、サブプラン302における結合オペレーションに対して、かつ、サブプラン302から結合オペレーション306に対して提供される。したがって、これらのファクトレコード(すなわち、すべての州についての2000年の店舗返品)がオペレーション306、308および310に不必要に送り進められることとなるだろう。なぜなら、310において、TNにはないこれらのファクトレコードが結合されず除外されることとなるからである。また、306、308および310を通じてこれらの不要なレコードを伝達することは、クエリプランで送り進められるレコードの数に起因してクエリプラン300の実行に必要とされるリソースの観点から見れば無駄であり、かつ、クエリプラン300の実行に必要な時間を増やしてしまう(すなわち、クエリの実行により多くの時間がかかる)。この結果、演算リソースが著しく無駄になり、実行時間が長くなってしまう。
特定の実施形態では、エンハンサ103は、クエリプランの一部からTNフィルタ条件を推論するとともに、クエリプランの別の無関係な部分に推論条件が適用されるようにクエリプランを変更し、これにより、クエリプラン全体の実行中に搬送されるファクトレコードの数を低減するように、および/または、スキャンオペレーションを実行するコスト全体を削減するように構成されている。クエリプランの書換えは、不必要な処理とファクトレコードを送り進めることとを回避するのに役立つ。クエリプラン300は、スタースキーマ情報116および/またはセマンティクスメタデータ117から導き出された推論を用いて書換えられてもよい。エンハンサ103は、スタースキーマ116および/またはセマンティクスメタデータ117を用いてクエリプラン300を書換えてもよい。
たとえば、図4に示されるように、スタースキーマ400は、「Store(店舗)」次元レコードが「Store_Returns」ファクトレコードと結合され得ることを示す。したがって、エンハンサ103は、「Store(店舗)」次元レコードをフィルタリングするための述語条件を用いて「Store_Returns」ファクトレコードをフィルタリングすることもできると推論することができる。
スタースキーマ116および/またはセマンティクスメタデータ117から導き出された推論に基づいて、エンハンサ103は、クエリプラン内の述語条件をクエリプラン内のクエリサブプランの外側からクエリサブプランの内側へ伝搬することによって、クエリプラン300を書換えて高度化してもよい。クエリプランのサブプランまたはサブ部分に接続されていない述語条件は、書換え後にサブプランから出力されるファクトレコードの数が書換え前にサブプランから出力されるファクトレコードの数よりも少なくなるように、および/または、サブプランにおけるスキャンオペレーションを実行するコスト全体が削減されるように、かつ、クエリ実行から得られるクエリ結果全体に影響をおよぼすことなく、サブプランまたはサブ部分に挿入されるかまたは関連付けられる。このような態様では、書換えの結果、オリジナルのクエリプランにおける後半のオペレーション中に除去されることとなる無関係なファクトレコードがこのとき、書換えの結果、クエリプランの前半のうちに除去され、これにより、クエリプランの実行時に送り進めるべきファクトレコードの数が減らされ、その後の不要な処理が回避される。上述したように、ファクトレコードの数は数百万にも上る可能性がある。したがって、クエリプランパイプラインにおいて、クエリプラン中の或るオペレーションからクエリプラン中の別のオペレーションへと送り進めなければならないファクトレコードの数をこのように減らすことにより、全体的なクエリ実行を著しく改善させ(すなわち、より高速にし)、かなりの量の演算リソース(たとえば、I/Oリソース、処理(たとえば、CPU)リソース、およびメモリリソース)の無駄を低減させる。
図5は、特定の実施形態に従った、クエリAを実行するためにエンハンサ103によって生成され得る書換え済みの高度化クエリプラン500の論理ツリーまたはグラフ図である。プラン500は、図3に示すプラン300を書換えたバージョンを表わしている。プラン500はサブプラン502を含み、サブプラン502はクエリAのライン2~8のサブクエリに対応する。図5では、図3のサブプラン302がサブプラン502として書換えられている。サブプラン302と比較すると、書換えられたサブプラン502は、「年=2000」条件を有するだけでなく、追加条件「州=TN」も有している。このような態様では、クエリプラン300におけるオペレーション304からの「州=TN」述語条件は、追加条件(年=2000に加えて)としてサブプラン502におけるフィルタオペレーションに伝搬されている。両方の条件を備えたこの書換えられたフィルタオペレーション504は、「Store_Returns」ファクトテーブルからスキャンされたファクトレコードに適用される。こうして、サブプラン302(またはより具体的には、フィルタオペレーション304)は、フィルタ条件を図3のフィルタオペレーション304からサブプラン502中のフィルタオペレーション504に伝搬させることによって、エンハンサ103によりサブプラン502として書換えられている。
同様の態様で、図5では、図3のサブプラン312がサブプラン512として書換えられている。サブプラン312と比較すると、書換えられたサブプラン512は、「年=2000」条件を有するだけでなく、付加的な条件「州=TN」も有している。このような態様では、クエリプラン300におけるオペレーション304からの「州=TN」述語条件が、(年=2000に加えて)追加の条件としてサブプラン512におけるフィルタオペレーションに伝搬されている。両方の条件を備えたこの書換えられたフィルタオペレーション506は、「Store_Returns」ファクトテーブルからスキャンされたファクトレコードに適用される。したがって、サブプラン312(またはより具体的には、フィルタオペレーション304)は、フィルタ条件を図3のフィルタオペレーション304からサブプラン512のフィルタオペレーション506に伝搬させることによって、エンハンサ103によりサブプラン512に書換えられている。
上述の態様でクエリプランを書換えることにより、テネシーに無関係なファクトソースStore_Returnsから任意のファクトレコードをフィルタリングして除去することが可能となり、これにより、このような無関係なファクトレコードをさらに処理する際に演算リソースが無駄にならない。サブプラン302と比較すると、フィルタオペレーション504およびサブプラン502によって出力されるとともにプロジェクトプラン500におけるさらなるオペレーション(たとえば、結合オペレーション508)に利用可能にされるファクトレコードの数は、サブプラン302によって(具体的には、サブプラン302における結合オペレーションによって)出力されるとともにクエリプラン300における次のオペレーションに利用可能にされるレコードの数よりも大幅に少ない。これは、TN条件に合致するレコードのみが、フィルタオペレーション504およびサブプラン502によって、プラン500内の下流オペレーション(たとえば、サブプラン502によって出力されるファクトレコードを得る結合オペレーション)に出力されるからである。テネシー以外のレコードはフィルタリングして除去される。同様の態様で、サブプラン312と比較すると、フィルタオペレーション506およびサブプラン512によって出力されるとともにプロジェクトプラン500におけるさらなるオペレーション(たとえば、結合オペレーション508)にとって利用可能にされるファクトレコードの数は、サブプラン312によって(具体的には、サブプラン312における結合オペレーションによって)出力されるとともにクエリプラン300における次のオペレーションにとって利用可能にされるレコードの数よりも大幅に少ない。これは、TN条件に合致するレコードのみが、フィルタオペレーション506およびサブプラン512によって、プラン500内の下流オペレーション(たとえば、サブプラン512によって出力されるファクトレコードを得る結合オペレーション508)に出力されるからである。テネシー以外のレコードはフィルタリングして除去される。これにより、結果として、結合オペレーションに提供されるレコードの数が大幅に削減され得る。ファクトテーブルのサイズに応じて、100倍と同程度またはそれ以上、ファクトレコードの数が減少する。サブプラン502および512によって出力されるファクトレコードの数がこのように減少した結果、プラン500と、これにより、クエリプラン500が生成される対応するクエリとが(より少ないCPUサイクルだけで実行できるので)より高速で実行され、多くの場合、用いるメモリリソースが非高度化クエリプラン300よりも少なくなり得るが、同じデータを分析するとともに同じクエリを返し得る。
図3および図5に示される例では、クエリプランの一部分から条件がクエリプランの別の部分に伝搬される。この例では、述語条件(State(州)=TNに基づくフィルタ)は、クエリプランの一部分から(たとえば、図3のフィルタオペレーション304から)クエリプランの別の部分(たとえば、図5のフィルタオペレーション504および506)に伝搬される。この例においては、述語条件が伝搬されるクエリプラングラフのオペレーションまたは部分は、ツリーのうち述語条件が伝搬される部分の子孫でも先祖でもない。すなわち、フィルタオペレーション504および506は、クエリプラン300または500におけるフィルタオペレーション304の子孫でも先祖でもない。
図5の例では、フィルタオペレーション304からの述語条件がサブプラン302および312に伝搬されて、書換えられたサブプラン502および512が生成されるが、これは単なる一例に過ぎないことが認識されるはずである。一般に、クエリプラングラフにおける第1のオペレーションからの述語条件が伝搬されて、クエリプラン内の別の部分またはオペレーションに関連付けられて、最適化されて高度化された書換え済みクエリプランが生成され得る。これは利用可能なデータ構造(たとえば、実体化されたビュー)に依存し得る。
特定の実施形態では、クエリプラン300の分析の一環として、エンハンサ103は、Aggregate(集約)、Join(結合)、Project(プロジェクト)、Filter(フィルタ)またはScan(スキャン)のオペレータ/オペレーションのみを含むクエリプラン全体内のサブプランであるAggregate(集約)-Join(結合)サブプランに焦点を合わせている。これらの例は図3に示されるサブプラン302および312である。エンハンサ103の目的は、これらのサブプラン内のファクトソース関係のスキャンにプッシュされ得る述語条件またはフィルタを見出すことである。
特定の実施形態では、エンハンサ103が探索する一般的なパターン(パターンA)は、以下のとおりである。
- ファクトソーススキャン(fs)と他の何らかのテーブルスキャン(ot)との間の結合条件を定義するJoin(結合)オペレーション(「結合ノード」)を表すクエリプラン内のノード。結合条件は、ファクトソースの列と他のテーブルの列との間の同等性チェックのリストとして表され得る(fs.coll=ot.collおよびfs.col2=ot.col2、など)。
- ファクトソース側はヌル供給であるべきではない。すなわち、ファクトソーススキャンから検討中の結合(j1)までの経路に沿って、ファクトソース側がヌル供給となる別の結合(j2)があってはならない(すなわち、fsはj2の子c1の子孫ではあり得ない。ここで、j2は外側の結合であり、c1はj2のヌル供給側である)。
パターンAを以下に示す。パターンAのライン2および4は、Aggregate/Join/Project/Filterオペレーションの任意の組合わせの代わりとなる。
1.Join(結合)(fs.col1 = ot.col1およびfs.col2 = ot.col2、など)
2.project/filter/aggregateオペレーション
3.ファクトソーススキャン(fs)
4.project/filter/aggregateオペレーション
5.OtherTableスキャン(ot)
上記パターンAと一致するクエリプラン全体におけるサブプランが見つかれば、「semiJoin」制限をファクトソースの結合列に適用することができる(パターンAにおけるfs.col1、fs.col2、…)。ファクトソース行は、(ot.col1、ot.col2…上の)OtherTable内の何らかの行と一致する結合列値を有するものに限定され得る。さらに、OtherTableが実質的に何らかのフィルタを有する場合、以下のとおり、ファクトソース関係スキャンを書換えることができる:
1.Left-Semi Join(左側のセミ結合)(fs.coll = ot.coll、fs.col2 = ot.col2、…)。
2.ファクトソーススキャン(fs)
3.別個のot.col1、ot.col2、…を選択
4.フィルタ
5.OtherTableスキャン(ot)
この書換えの潜在的な利点は、クエリプランパイプラインの後続のオペレータにおいて処理されるファクトソース行が減少することである。ファクトソース行の減少は、OtherTable上のフィルタの選択性に非公式に依存する。フィルタの選択性が高ければ高いほど(たとえば、多数の別個の値を有する列上の同等性条件)、ファクトソース行の減少が大きくなる可能性が高くなる。スタースキーマ結合の場合、結合は無損失分解であり(結合によって新しいファクトが追加されない)、このため、スキャンされるファクトに対する次元フィルタの利点がフィルタの選択性に正比例する可能性が非常に高くなる。
この書換えのコストはセミ結合オペレーションが如何に実行されるかに基づいている。一般的な場合、これは、典型的には物理的な結合プランを伴うであろうLeft Semi-Join(左側のセミ結合)オペレータを用いて行われる。
クエリプラン内で述語条件を効率的に伝搬するために利用可能なさまざまな技術がある。用いられる特定の技術は、推定される演算節約分および/または特定のデータ構造の利用可能性を含むがこれらに限定されないさまざまな要因に基づいて選択され得る。
1つの技術は、ファクトレコードと次元レコードとの間でセミ結合オペレーションを実行することを含む。これは、述語条件を満たす次元キーのセットを決定するために述語条件を次元レコードに対して評価することに基づいて達成され得る。この次元キーのセットは、本明細書では「リスト内のキー(key in-list)」と称される。
図6は、クエリAを効率的に評価するために用いることができるリスト内のキー602および604を生成するための例示的な処理600を示す。より具体的には、述語条件「年=2000」は、リスト内のキー602を決定するために次元テーブル204に対して評価され、述語条件「州=「TN」」は、リスト内のキー604を決定するために次元テーブル208に対して評価される。リスト内のキーは、述語条件を満たす次元テーブルにおける次元レコードからの外部キーのリストである。たとえば、Date(日付)次元テーブル204の場合、「年=2000」は、図6に示される最初のレコードによって満たされ、date_key=1は、そのレコードからの外部キーである。リスト内のキー602および604を用いて、ファクトレコードをスキャンおよびフィルタすることができ、これにより、述語条件をファクトレコードに伝搬することができる。
しかしながら、セミ結合オペレーションを実行することは、かなりの量の演算オーバーヘッドを引起こす可能性がある。ファクトレコードのスキャンは、典型的には多数のファクトレコードが存在するので計算集約的となる可能性がある。さらに、リスト内のキーを生成することにより、セミ結合オペレーションを実行する演算オーバーヘッドが増大する。このオーバーヘッドは、有意義なものにするためには、不必要に処理される可能性のあるファクトレコード(たとえば、テネシーとは無関係のファクトレコード)の低減によって超過されなければならない。したがって、エンハンサ103は、セミ結合オペレーションを含むようにクエリプランを書換える前に演算節約分を推定し得る。
複数の述語条件の場合、クエリエンハンサ103は、セミ結合オペレーションを連続的に実行する場合の増加節約分を分析してもよい。これは、各々の述語条件を別個に適用することに起因するであろう演算節約分の高いものから順に述語条件を配置することを含み得る。次いで、エンハンサ103は、この順序で述語条件を分析して、述語条件を連続して適用することによる増加節約分を推定し得る。したがって、増加節約分が重要でない限り、連続的な述語条件を適用するためのセミ結合オペレーションが指定され得る。
述語条件をファクトレコードに効率的に伝搬するための別の技術は、次元値と結合されたファクト値(たとえば、ファクトテーブルからのファクトメトリック値または他の任意の値)の表形式表現を含む。また、実体化されたビューに含まれる次元値のメモリ位置への効率的なアクセスを可能にする1つ以上のインデックス(たとえば、反転されたインデックス)が含まれる。集合的に、1つ以上のインデックスを有する表形式表現は、本明細書中では「OLAPインデックス」と称される。典型的には、OLAPインデックスは、スキャン最適化された列符号化、メモリ最適化された列形式レイアウト、ベクトル化されたスキャンオペレーションなどの技術を用いる、提供される述語条件に基づいて行の任意のサブセットをスキャンするために最適化される単一の複合データレイアウトフォーマットである。述語評価もまた、たとえばビットセットオペレーションのセットとして高度に最適化される。これらの特徴は、OLAPインデックスをアドホック分析用作業負荷に理想的に適合させる。
図7は、次元インデックス704および706を備える例示的なOLAPインデックス700を示す。OLAPインデックス700はさらに、ファクトテーブル202を次元テーブル204および208と結合することによって得られるデータを含むテーブル702を含む。図7に示されるように、OLAPインデックスは、次元値上の1つ以上の反転インデックスと共にデータを列形式で含む。次元値ごとに、位置ビットマップが維持される。
多くのデータベースでは、フィールド(たとえば、列708または710)内の値は、メモリアドレスの範囲内で連続的に格納されている。たとえば、データがストレージからシステムメモリに読出されると、列710の値は、効率的にアクセスされ得る列指向データベースデータとして揮発性メモリに連続的に格納され得る。特定の列値にアクセスする効率を高めるために、インデックス(たとえば、次元インデックス)は、フィールド値とメモリ位置との間のマッピングを格納し得る。図7の例では、次元インデックス704は、列710の「州」次元値712についてのメモリ位置714を示し、次元インデックス706は、列708の「年」次元値716のメモリ位置718を示す。
したがって、OLAPインデックスは、演算リソースの節約を可能にする。OLAPインデックスは次元値を含んでいるので、述語条件は、リスト内に生成することなくOLAPインデックスに対して直接評価され得る。さらに、次元値ビットマップは、次元値から、次元値を有するファクト行のサブセットへのマッピングを表わしている。各々の次元述語条件は、ビットマップまたはビットマップの組合わせにマッピングされ得る。たとえば、State(州)=「TN」は、「TN」値ビットマップ内のファクト行であり、State(州)>「TN」は、>「TN」であるすべてのState(州)値についてのすべてのビットマップをORによって組合わせることによって得られるビットマップ内のファクト行である。複数の次元述語条件のさらなる評価はまた、実際のファクトデータをスキャンする必要なしに、AND、OR、NOTのような超高速ビットマップ組合せ関数として評価され得る。図7に示すようなインデックスは、「州=「テネシー」」および「日付け=「2000」」などの述語条件を高速で演算することを可能にする。OLAPインデックス実体化は、非常に効率的な「スキップスキャン」の実行を可能にする。述語条件の評価(たとえば、州=「テネシー」または日付け=「2000」)により、結果として行識別子のリストが得られ、述語条件に一致するデータを有するファクト行が識別される。たとえば、行識別子1、4、5、7、9、10、13、15、17、19、20、23、および24は、「州=「テネシー」」の条件が満たされているファクトレコードに対応する。別の例として、行識別子1、2、3、4、5、6、7、および8は、「日付=「2000」」の条件が満たされているファクトレコードに対応する。行id(rowid)リストは、ファクトスキャンオペレーション中に多数のファクトレコード行をスキップするために用いることができる。典型的には、分析クエリは、広大な多次元空間のうちの小さな領域に焦点を合わせており、このため、スキップスキャンが、すべてのファクトレコード(またはファクト行)をスキャンしてフィルタ述語条件を満たさないものを除去するよりも、著しく高速で実行される。したがって、OLAPインデックスを述語条件と共に用いることにより、ファクトスキャンオペレーションがさらに一層高速になる。
図7は、明確にするためにメモリ位置714および718を10進値として示しているが、メモリ位置714および718が2進値、16進値などと表現され得ることが認識されるはずである。いくつかの実施形態では、メモリ位置714および718は、位置ビットマップとして維持されてもよく、これにより、計算上安価で高速なビットマップAND演算が可能となって、複数の述語条件がファクトレコードに同時に伝搬され得る。さらに、図7は、明確にするために、メモリ位置714および718を相対アドレス(たとえば、バイトオフセット)として示しているが、いくつかの実施形態では、メモリ位置714および718が絶対アドレスとして表現され得ることが認識されるはずである。
一般に、OLAPインデックスに対して述語条件を評価する利点は、演算コストをいずれも常に上回るものでなければならない。したがって、エンハンサ103は、費用便益分析を実行する必要がない。しかしながら、適切なOLAPインデックスが常に利用可能とならない可能性もある。たとえば、述語条件「州=「TN」」が評価され得る対象となる「州」次元値を含むOLAPインデックスが存在しない可能性もある。
述語条件をファクトレコードに効率的に伝搬するためのさらに別の技術は、前述の技術の組合せを含み、本明細書では「インデックス・セミ結合」技術と称される。この名称によって示唆されるように、インデックス・セミ結合オペレーションは、OLAPインデックスを含む特定のタイプのセミ結合オペレーションであるが、OLAPインデックスは述語条件を直接評価するのに不適切である。
図8Aは、テーブル802および次元インデックス804を含む例示的なOLAPインデックス800を示す。テーブル802は、ファクトテーブルStore_Returns202を次元Store(店舗)テーブル208と結合した結果得られるデータを含む。列806の値は、列指向データベースデータとして揮発性メモリに連続的に格納されてもよく、次元インデックス804は、特定の列値に効率的にアクセスするために用いられてもよい。より具体的には、次元インデックス804は、「市」次元値808をテーブル内のメモリ位置810にマッピングする。
図8Aは、明確にするためにメモリ位置810を10進値として示しているが、メモリ位置810が2進値、16進値などと表現され得ることが認識されるはずである。いくつかの実施形態では、メモリ位置810は、位置ビットマップとして維持されてもよく、これにより、計算上安価で高速なビットマップAND演算が可能となり、複数の述語条件がファクトレコードに同時に伝搬され得る。さらに、図8Aは、明確にするためにメモリ位置810を相対アドレス(たとえば、バイトオフセット)として示しているが、いくつかの実施形態では、メモリ位置810が絶対アドレスとして表現され得ることが認識されるはずである。
しかしながら、次元インデックス804は、述語条件「州=「TN」」を直接評価するのに適していない。これは、次元インデックス804が「州」値ではなく「市」値に基づいているからである。
それにも関わらず、次元インデックス804は依然として、インデックス・セミ結合オペレーションに基づいて述語条件「州=「TN」」をファクトレコードに伝搬するために用いられてもよい。これは、述語条件を満たすとともに次元インデックス804に含まれている次元値(たとえば、非キー値)のセットを決定するために述語条件を次元レコードに対して評価することを含み得る。この次元値のセットは、本明細書では「リスト内の値(value in-list)」と称される。
図8Bは、次元インデックス804に対する述語条件「州=「TN」」を評価するのに用いることができるリスト内の値822を生成するための例示的な処理820を示す。より具体的には、述語条件「州=「TN」」は、1つ以上の「市」値を含むリスト内の値822を決定するために次元テーブル208に対して評価される。図8Bの例では、これは単一の市値「ナッシュビル(Nashville)」を返す。次いで、リスト内の値822(たとえば、「ナッシュビル」)を用いて、テーブル802内の関連レコードに対応するメモリ位置(たとえば、ナッシュビルについての位置1、4、5、7、9、10、13、15、17、19、20、23、および24)についての次元インデックス804をスキャンし、これにより、それらのすべてをスキャンすることなく、テーブル802のレコードをフィルタリングすることができる。
インデックスセミ結合オペレーションを実行することで、すべてのファクトレコードのスキャンを回避することによって演算リソースが節約されるが、リスト内の値を生成することに関連する演算オーバーヘッドが生じる。このオーバーヘッドは、有意義なものにするために、不必要に処理される可能性のあるファクトレコード(たとえば、テネシーとは無関係なファクトレコード)の低減によって超過されなければならない。したがって、エンハンサ103は、インデックスセミ結合オペレーションを含むようにクエリプランを書換える前に演算節約分を推定し得る。
複数の述語条件の場合、エンハンサ103は、インデックスセミ結合オペレーションを連続的に実行する場合の増加節約分を分析してもよい。これは、各々の述語条件を別個に適用することに起因し得る演算節約分の高いものから順に述語条件を配置することを含み得る。次いで、エンハンサ103は、この順序で述語条件を分析して、述語条件を連続して適用することによる増加節約分を推定し得る。したがって、増加節約分が重要でない限り、連続的な述語条件を適用するためのインデックスセミ結合オペレーションが指定され得る。
上述のように、推論はスタースキーマ情報116から導き出され得るだけでなく、セマンティクスメタデータ117からも導き出され得る。セマンティクスメタデータ117から導き出される推論は、ファクトレコードに伝搬され得るように述語条件を変換するのに用いることができる。たとえば、セマンティクスメタデータ117は、週、月、四半期などの観点から表わされる時間値の間の階層関係を示す情報を含み得る。次いで、この情報を用いて、述語条件「四半期=2」などの条件を「4と6と間の月(month BETWEEN 4 AND 6)」に変換することができ、これにより、述語条件が「月」の値に対して評価され得る。なぜなら、図2に示すDate(日付け)次元テーブル204は、月、日、および年のフィールドを含むが、四半期のフィールドは含まないからである。このような態様で、次元テーブル内の列ではない値に基づく述語条件を、次元テーブル内の列である値に変換することができる。
図9は、特定の実施形態に従った、機能依存性に基づいて述語条件をファクトレコードに伝搬するための例900を示す。図9の例では、「四半期=2」は、テーブル908および次元インデックス910を含む、図9に示されるOLAPインデックス909への伝搬のために識別され得る未変換の述語条件904である。しかしながら、テーブル908の列912、914、916、または918はいずれも「4半期」の列ではないので、OLAPインデックス910に対して述語条件904を評価するのは困難である。
それにもかかわらず、セマンティクスメタデータ901は、インデックス910における次元属性に基づいて述語条件904を述語条件906に変換するために用いられ得る依存性メタデータを含み得る。より具体的には、セマンティクスメタデータ901は日付け階層902(たとえば、月から四半期、四半期から年)を含み得る。この日付け階層902は、述語条件「四半期=2」を月ベースの述語条件「4と6との間の月(month BETWEEN 4 AND 6)」に変換するために用いることができる。その後、変換済みの述語条件906は、月値920をメモリ位置922にマッピングする次元インデックス910に対して評価することができる。この例では、4、5および6の月が述語条件を満たしており、それらのメモリ位置(または行id)にマッピングされる。図9は、OLAPインデックスを必要とする例示的な処理900を示すが、変換された述語条件が本明細書中に記載される任意の適切な技術を用いてファクトレコードの任意のソースに伝搬され得ることが認識されるはずである。
図9に示されるとともに上述された例では、4半期に基づく述語条件は、月に基づく制約述語条件と置換えられる。制約述語条件の置換えは、オリジナルの述語条件と等価である必要はなく、単に、置換する述語条件によって返されるすべての行(ファクトレコード)を返さなければならないだけである。レベルベースの階層のために、同等性条件および範囲条件(=、!=、<、>、≦、≧、内(in)、間(between))に関する置換え戦略が用いられる。妥当なサイズの階層のために、階層のメモリ内表現が、エンハンサ103によって維持および使用されて、高度化クエリプランの生成中に置換え述語条件が演算され得る。
その目標は、クエリプランの実行によって処理されるファクトレコードの数を低減すること、および/または、クエリプランにおいてスキャンオペレーションを実行する全体的コストを削減することであるので、述語条件の適用はこの目標を達成するのに重要な役割を果たす。図9に示されるとともに上述された例では、クエリにおいて提供される述語条件(「四半期=2」)は、提供された述語条件を置換える述語条件(「4と6との間の月」)とは異なっている。2つの述語条件が異なっていても、置換述語条件を適用することで、供給された述語条件によって返されるいずれの行も置換述語条件によって返されることが確実にされる。これは、クエリプランおよびクエリの性能の点で大きな利点を提供する。置換述語条件は、機能依存性を詳細に検討することによって推論することができる。従って、4半期→月→週の日付けという階層において、1週間についての述語条件を有する場合、週列がファクトソースにプッシュ可能ではない場合、ファクトソースは4半期の述語条件を処理することができ、たとえば、対応する4半期述語条件をプッシュすることができる。週=1が4半期=1としてプッシュされ得るとともに、週>25が4半期>2としてプッシュされ得る等々である。述語条件の変換は、列同士の間の依存性を定義する関係ツリーを詳細に検討することに基づいている。これらのツリーがメモリ内構造として維持される場合、変換は非常に高速となり、計画に多くのオーバーヘッドが追加されなくなるだろう。これは、メモリ内データ構造を通じてメンバーナビゲーションをサポートすることが一般的である階層の場合に確実に該当する。
図9は、未変換の述語条件904において指定されるフィールドと変換済み述語条件906において指定されるフィールドとの間の階層関係を含む例を示しているが、本明細書で説明する技術は階層関係を呈するフィールドに限定されないことが認識されるはずである。たとえば、セマンティクスメタデータ901は、述語条件の変換を実行するために用いられ得る他の種類の情報を含んでいてもよい。たとえば、セマンティクス情報は、南部の店舗では冬用衣類を販売しないことを示す情報を含んでいてもよく、これにより、冬用衣類の用語で表現される述語条件を地理的地域の用語で表現される述語条件に変換することが可能となり得る。
本開示で説明する技術のいずれかを用いて、述語条件をファクトレコードに伝搬し得る。述語条件を伝搬することは、述語条件がファクトレコードと直接結合されない可能性がある次元レコードからファクトレコードに伝搬され得るという点で、推移特性を示す。たとえば、述語条件は、複数の次元テーブルにわたって、または別のファクトテーブルにわたって伝搬されてもよい。
いくつかの実施形態では、述語条件は、次元レコードの第1のセットから次元レコードの第2のセットにわたってファクトレコードのセットに伝搬され得る。これは、図10Aに示される例を参照しつつ説明することができる。図10Aは、簡略バージョンの「Store_Returns"」ファクトテーブル202と、「顧客(Customer)」次元テーブル1002と、「Customer_Address」次元テーブル1004とを含む例示的なデータベースデータ1000を示す。「Store_Returns"」ファクトテーブル202は、列212および1006に基づいて「顧客(Customer)」次元テーブル1002と直接結合することができ、「顧客(Customer)」次元テーブル1002は、列1008および1010に基づいて「Customer_Address」次元テーブル1004と直接結合することができる。しかしながら、図10Aの例では、「Store_Returns」ファクトテーブル202を「Customer_Address」次元テーブル1004と直接結合するために用いることができる列は存在しない。
それにも関わらず、エンハンサ103は、スタースキーマ情報116を用いて、述語条件「州=「TN」」が「Customer_Address」次元テーブル1004から「Store_Returns」ファクトテーブル202に伝搬され得ることを推論し得る。なぜなら、これらは各々が「顧客(Customer)」次元テーブル1002に関連しているからである。この推論に基づいて、エンハンサ103は、「Store_Returns」ファクトテーブル202の列を「Customer_Address」次元テーブル1004の列に関連付けるテーブル(またはファクトレコードの任意の他のソース)をチェックしてもよい。
図10Bは、このようなテーブル1020のみを示す。図10Bの例では、テーブル1020は、列212および列1006を用いる「Store_Returns」ファクトテーブル202および「Customer_Address」次元テーブル1004を含むとともに、列1008および列1010を用いる「顧客(Customer)」次元テーブル1002と「Customer_Address」次元テーブル1004との間における結合オペレーションから得られたデータを含む。したがって、テーブル1020は、「Customer_Address」次元テーブル1004の「州」列1012に対応する「州」列1022を含む。
本明細書で説明する技術のいずれかを用いて、述語条件「州=「TN」」をテーブル1020に伝搬し得る。たとえば、テーブル1020中の列1022の値についての反転インデックスが存在する場合、述語条件は、「州=「TN」」述語条件を満たすファクト行をスキャンするためだけにテーブル1020をフィルタリングするために、反転インデックスに対して評価され得る。
図10Aおよび図10Bに示す例の場合、以下の条件が満たされれば述語条件を伝搬させることができる。
・ 次元テーブルCustomer(顧客)1002(T1)のフィルタに基づいてStore_Returnsテーブル202(FS1)を削減できることが既に推論されている。
・ FS1とT1との間の結合は、スタースキーマにおけるスタースキーマJoin(結合)である。これは、この結合オペレーションにより、結合に対する任意の入力ファクトレコードの追加または除去がなされないことを示唆している。
・ T1と次元テーブルCustomer_Address1004(T2)との結合が、
- T1側でヌル供給ではなく、
- FS1.StarSchemaにおけるスタースキーマJoin(結合)である。
さらに、結合T1-T2におけるT1の列jcを結合するT1ごとに、FS1において同等の列eciが存在する場合、FS1のeci列にsemiJoin制限を適用することができる。
いくつかの実施形態では、述語条件の評価は、次元レコードのセットから(次元テーブルDTから)ファクトレコードの第1のセット(ファクトソース1「FS1」)にわたってファクトレコードの第2のセット(ファクトソース2「FS2」)に伝搬され得る。たとえば、これは、スタースキーマがファクトレコードの複数のセットを含む場合に可能であり得る。図11はこのようなスキーマ1100の例を示す。スキーマ1100は、(強調された境界線で示される)2つのファクトテーブル、すなわち、「Store_Returns」ファクトレコードテーブル1102および「Store_Sales」ファクトレコードテーブル1104、を含む。他のテーブル(Date(日付け)、Store(店舗)、Item(商品)、Customer(顧客)、Customer_Address)は、ファクトレコードについてのコンテキスト情報を格納する次元テーブルである。2つのファクトテーブルは各々、「Store(店舗)」次元レコードテーブル1106などの次元テーブルと結合することができる。
図12Aは、スキーマ1100に記述され得る例示的なデータベースデータ1200を示す。データベースデータ1200は、「Store_Returns」ファクトテーブル1202、「Store(店舗)」次元テーブル1204、および「Store_Sales」ファクトテーブル1206を含む。図12は、データベースデータ1200をテーブルとして示しているが、データベースデータ1200がインデックス、実体化されたビューおよび/またはタプルの他の任意のセットとして表現され得ることが認識されるはずである。
「Store_Returns」ファクトテーブル1202および「Store(店舗)」次元テーブル1204は、外部キーと一次キーとの関係を示す列1208および列1210に基づいて結合することができる。したがって、列1212および列1214のいずれかを伴う述語条件(たとえば、「州=「TN」」)は、本明細書で説明する技術のいずれかを用いて、「Store(店舗)」次元テーブル1204から「Store_Returns」ファクトテーブル1202に伝搬され得る。
しかしながら、「Store_Sales」ファクトテーブル1206は、「Store(店舗)」次元テーブル1204と結合することもできる。これは、列1216および列1210も外部キーと一次キーとの関係を示しているからである。したがって、図11に示すスキーマ1100に基づいて、エンハンサ103は、本明細書で説明する技術のいずれかを用いて「Store_Returns」ファクトテーブル1202の任意のフィルタリングを「Store_Sales」ファクトテーブル1206にも適用することができると推論し得る。
図12Bは、クエリサブプラン1222、1224、および1226を備える例示的な論理クエリプラン1220を示す。クエリプラン1220に従うと、サブプラン1222におけるオペレーションの実行結果とサブプラン1224におけるオペレーションの実行結果との間の結合オペレーション1230が実行される。さらに、プラン1220は、結合オペレーション1230の実行結果とサブプラン1226におけるオペレーションの実行結果との間の結合オペレーション1232の実行を指定する。
フィルタオペレーション1228はサブプラン1222に含まれるが、フィルタオペレーション1228はサブプラン1224および1226には含まれない。この結果、結合オペレーション1230を実行するとき、「Store_Returns」ファクトテーブル1202からのすべてのファクトレコードについて相当量の不要な処理が行われる可能性がある。同様に、サブプラン1226からの「Store_Sales」ファクトテーブル1206から返されるすべてのファクトレコードに対して結合オペレーション1232を実行するとき、相当量の不要な処理が実行される可能性がある。この不要な処理は、クエリプラン1220を実行するのにかかる合計時間を大幅に増やしてしまう可能性がある。
図12Cは、クエリプランによって処理されるファクトレコードの数を減らすためにクエリプラン1220に基づいて書換えられた例示的な書換え済み高度化クエリプラン1240を示す。プラン1240に従うと、フィルタオペレーション1228における述語条件「州=TN」は、フィルタオペレーション1242としてサブプラン1224に伝搬されるだけでなく、フィルタオペレーション1244としてサブプラン1226にも伝搬される。この結果、サブプラン1224によって出力されるとともに結合オペレーション1230に提供されるファクトレコードの数が、(州がTNでないレコードをStore_Returnsテーブルが保持していると想定すると)クエリプラン1220における結合オペレーション1230に提供されるファクトレコードよりも少なくなる。これは、プラン1240において、「州=「TN」」述語条件を満たすファクトテーブルStore_Returnsからのファクトレコードのみが、プラン1220内のすべてのファクトレコードの代わりに、結合オペレーション1230に提供されるからである。同様に、サブプラン1226によって出力されるとともに結合オペレーション1232に提供されるファクトレコードの数は、(州がTNでないレコードをStore_Salesテーブルが保持すると想定すると)クエリプラン1220における結合オペレーション1232に提供されるファクトレコードよりも少ない。これは、プラン1240において、「州=「TN」」条件を満たすファクトテーブルStore_Salesからのファクトレコードのみが、プラン1220内のすべてのファクトレコードの代わりに、結合オペレーション1232に提供されるからである。この結果、次元述語条件「州=「TN」」を満たさない「Store_Returns」ファクトテーブル1202および「Store_Sales」ファクトテーブル1206のいずれかの行を最初にフィルタリングして除去することによって、結合オペレーション1230および1232を実行する演算オーバーヘッドが大幅に低減され得る。したがって、クエリプラン1240は、非高度化クエリプラン1220よりもはるかに高速で実行される(たとえば、より少ないCPUサイクルを使用する)とともに、多くの場合、より少ないメモリリソースを用い得る。
上述のように、特定の実施形態では、同じファクト(或るファクトの複数のグレインの分析を伴うクエリ)または異なるファクト(たとえば、さまざまな活動の比較/組合わせを伴うクエリ)を含むサブクエリにわたってコンテキストの推移伝搬のための技術が開示される。特定の実施形態では、これらの技術は、以下の条件が成り立つ場合に適用され得る。
・ 次元テーブルDTに基づくファクトソースFS2に対する次元コンテキスト適用が決定されている。
・ DTのキー列上に別のファクトソースFS1とFS2との結合が存在しており、DTもFS2のスタースキーマにおける次元テーブルである。
上述の条件が成立した場合、DTからの次元コンテキストをFS1に適用することができる。
図13Aは、特定の実施形態に従った高度化クエリプランを生成する方法を示す簡略フローチャート1300である。処理1300は、それぞれのシステムの1つ以上の処理ユニット(たとえばプロセッサ、コア)によって実行されるソフトウェア(たとえばコード、命令、プログラム)、ハードウェア、またはそれらの組合わせで実現され得る。ソフトウェアは非一時的な記憶媒体(たとえばメモリデバイス)に格納されてもよい。図13に示されるとともに以下で説明される方法は、限定ではなく例示を意図している。図13は特定のシーケンスまたは順序で行われるさまざまな処理ステップを示すが、これは限定を意図したものではない。特定の代替的実施形態において、ステップはいくつかの異なる順序で実行されてもよく、いくつかのステップは並列に実行されてもよい。
1302において、第1またはオリジナルのクエリプランが受信され得る。オリジナルのクエリプランは、図1Aおよび図1Bに示される分析プラットフォーム100に提供されるデータベースクエリ(たとえば、SQLクエリ)のために生成されるプランであってもよい。クエリは、データベースに格納された事前集約されていないデータに対して実行されるアドホッククエリであってもよい。図1Bに示す実施形態を参照すると、オリジナルのクエリプランは、オプティマイザ114によって生成されてもよい。
オリジナルのクエリプランは、オペレーション(またはオペレータ)のパイプラインを含み得る。オペレーション(オペレータ)は、たとえば、ファクトスキャン(単にスキャンオペレーションと称されることもある)、フィルタ、結合、集約、計画、および他のオペレーションを含み得る。オリジナルのクエリプランにおけるオペレーションは、オペレーションの出力が他の下流オペレーションへの入力として提供されるようにパイプラインにおいて階層的に編成されてもよい。クエリプランは、親ノードおよび子ノードを含むルートツリーとして階層的に表現され得る。このような表現では、オペレーションは、ツリーのリーフノードによって表されるオペレーションから実行される。次いで、リーフノードからの出力が親ノードに与えられ、親ノードからの出力がそれらの親ノードに与えられる等の処理が、ルートノードからの出力が与えられるルートノードがクエリプランが生成されるクエリの結果になるまで、同様に続けられる。たとえば、1302において受信されるオリジナルのクエリプランは図3および/または図12Bに示す通りであり得る。
オリジナルのクエリプランにおける1つ以上のオペレーションは、サブプランを形成するためにグループ化され得る。たとえば、オリジナルのクエリプランは、ファクトレコードのソース(たとえば、ファクトテーブル)をスキャンすることを伴うファクトテーブルスキャンオペレーションを含む第1のサブプランを含み得る。第1のサブプランはまた、フィルタオペレーション、結合オペレーション、集約オペレーション、計画オペレーションなどの他のゼロ以上のオペレーションを含み得る。たとえば、図3に示されるサブプラン302、および図12Bに示されるサブプラン1222、1224および1226がある。オリジナルのクエリプランにおいて、第1のサブプランによって出力される(すなわち、第1のサブプランにおいて実行されるオペレーションの結果として第1のサブプランから出力される)ファクトレコードは、オリジナルのクエリプランパイプラインにおける親オペレーションへの入力として提供される。
1304において、オリジナルのクエリプランを書換えることによって高度化クエリプランが生成される。書換えの結果、結果として得られる高度化クエリプランにおいて、少なくとも1つの次元述語条件の評価が、高度化クエリプランにおけるファクトスキャンオペレーションに伝搬されて、それに関連付けられる。ここで、述語条件は、オリジナルのクエリプランにおける同じファクトスキャンオペレーションには関連付けられていなかった。たとえば、述語条件は第1のサブプランに挿入されて、第1のサブプランにおける少なくとも1つのファクトスキャンオペレーションに関連付けられてもよい。高度化クエリプランでは、述語条件の評価は、述語条件をファクトテーブルに伝搬することに基づいてサブプランの一部として行われる。述語条件を伝搬して第1のサブプランおよびファクトスキャンオペレーションと関連付けた結果、高度化クエリプランはオリジナルのクエリプランよりも高速で実行される。たとえば、場合によっては、述語条件をファクトスキャンオペレーションに関連付けた結果、オリジナルのクエリプランと比べて、より少ないファクト行/レコードが高度化クエリプランによって処理される。これは、述語条件を満たすそれらのファクトレコードだけがクエリプランパイプラインにおける親オペレーションまたは下流オペレーションのために提供される一方で、述語条件を満たさないファクトレコードはフィルタリングして除去されて、たとえば結合オペレーションであり得る親オペレーションには提供されないからである。この結果、クエリプランパイプラインにおける次のオペレーションおよび後続のオペレーションに提供されているファクトレコードの数が少なくなる。これにより、クエリプランパイプラインにおける結合オペレーションおよび他の後続オペレーションをその後実行することに関連する演算オーバーヘッドを低減させる。クエリプランパイプラインにおいてより少ないファクトレコードが処理されて送り進められる必要があるので、高度化クエリプランは、オリジナルのクエリプランよりも高速で実行されるとともに、より少ないリソース(たとえば、処理リソース、メモリリソース)を用いる。
他のいくつかの例では、ファクトスキャンオペレーションに関連付けられた述語条件は、クエリプランパイプラインにおけるファクトスキャンオペレーションから下流オペレーションに出力されるファクトレコードの総数が減らされない可能性があっても、ファクトスキャンオペレーションの実行に関連するコスト(たとえば、ファクトスキャンオペレーションを実行するのに必要なCPUサイクルまたは時間)がオリジナルのクエリプランにおける同じファクトスキャンオペレーションと比べて削減されるような条件である。
結果として、1304で書換えられた高度化クエリは、1302で受信されたオリジナルのクエリプランよりも高速で実行される。その結果、高度化クエリプランが生成されるクエリは、より高速で実行され、場合によってはより少ないメモリリソースを用いる。したがって、高度化クエリプランは、オリジナルのクエリプランと比べて高度化および改善されている。図1Bに示される実施形態では、1304における処理はエンハンサ103によって実行されてもよい。
1306において、1304で生成された高度化クエリプランが実行され得る。上述のように、クエリプランでは1つ以上の述語条件を1つ以上のオペレーションに伝搬するので、高度化クエリプランは、より高速で(すなわち、より短い時間を用いて)実行されるとともに、多くの場合、オリジナルの非高度化クエリプランよりも少ないメモリリソースを使用し得る。
1308において、1306で高度化クエリプランを実行した結果データベースから取り出されたファクトレコードは、オリジナルのクエリプランおよび高度化クエリプランが生成されたクエリに対する応答として出力され得る。図1Bに示す実施形態では、1306および1308の処理はエグゼキュータ105によって実行され得る。
図13Bは、特定の実施形態に従った高度化クエリプランを生成する方法を示す簡略フローチャート1320である。図13Bの処理は、それぞれのシステムの1つ以上の処理ユニット(たとえばプロセッサ、コア)によって実行されるソフトウェア(たとえばコード、命令、プログラム)、ハードウェア、またはそれらの組み合わせで実現することができる。ソフトウェアは非一時的な記憶媒体(たとえばメモリデバイス)に格納されていてもよい。図13Bに示されるとともに以下で説明される方法は、限定ではなく例示を意図している。図13Bは特定のシーケンスまたは順序で行われるさまざまな処理ステップを示すが、これは限定を意図したものではない。特定の代替的実施形態において、ステップはいくつかの異なる順序で実行されてもよく、いくつかのステップは並列に実行されてもよい。
特定の実施形態では、図13Bに示す処理は、図13Aの1304において実行される処理の一部として実行されてもよい。図1Bに示される実施形態について、図13Bに示される処理はエンハンサ103によって実行されてもよい。エンハンサ103への入力は、クエリのために生成されたオリジナルのクエリプラン、たとえば、SQLクエリのために生成されたSQLクエリプラン、を含む。エンハンサ103はまた、リレーショナルスキーマ、スタースキーマ定義、テーブルの列間の機能依存性、スタースキーマ上のOLAPインデックスなどのデータの利用可能な物理的構造などについての情報などのメタデータ情報およびスキーマ情報にアクセスできる。図13Bおよび付随する説明のために、メタデータおよびスキーマ情報はメタ店舗に格納されているものと想定される。図13Bに示される処理の出力は、オリジナルのクエリプランよりも高速で実行されるとともに、多くの場合、オリジナルのクエリプランよりも少ないリソースを用いる一方で、オリジナルのクエリプランと同じ結果を返す高度化クエリプランである。上述したように、高度化クエリプランは、オリジナルのクエリプランよりも少ない数のファクトレコードを処理するのでオリジナルのクエリプランよりも高速で実行され、および/または、高度化クエリプランにおけるファクトレコードを処理するコストは、ファクトレコードがより効率的に処理されるのでオリジナルのクエリプランよりも少なくなる。
図13Bに示されるように、1322において、オリジナルのクエリプランを分析して、オリジナルのクエリプランにおけるファクトテーブルを識別する。これは多種多様な技術を用いて実行され得る。たとえば、オリジナルのクエリプランにおけるファクトテーブルは、クエリレベルまたはセッション/接続レベルにおけるユーザヒント、および他の技術を通じて、オリジナルのクエリプランにおけるテーブルをメタ店舗におけるファクトテーブルと照合することによって識別されてもよい。
1324において、1322において識別された各ファクトテーブルごとに、オリジナルのクエリプランにおいて、識別されたファクトテーブル上のすべてのファクトスキャンオペレータに対して、クエリプランウォークが実行されて、このファクトスキャンオペレータとの確認結合のセットを演算するとともに、任意の適用可能な次元コンテキスト述語条件を識別/推論する。特定の実施形態では、オリジナルのクエリプランにおけるファクトテーブルスキャンオペレータのウォークは、ファクトスキャンオペレータから開始され、オリジナルのクエリプランのルートノードに到達するまでオリジナルのクエリプランを詳細に検討することを含む。たとえば、図3に示すクエリプランの場合、サブプラン302におけるStore_Returnsファクトテーブルスキャンオペレーションのウォークは、このノード320から開始され、その祖先ノードのすべて(ノード322、ノード324、ノード306からルートノード326まで)を訪問することを含む。
ウォーク中にファクトテーブルのためのファクトスキャンオペレーションについての適用可能な次元コンテキスト述語条件を識別/推論するために、エンハンサ103は、訪問された各々のノードオペレーション/オペレータの出力の「グレイン」を維持する。クエリプランにおける任意のリレーショナルオペレータの出力は演算されたデータセットである。任意のテーブル(ベースデータセット)または演算されたデータセットの「グレイン」はそのスキーマにおける次元列のセットである。ファクトテーブルの場合、そのグレインは、関連付けられたすべての次元キーを含む。たとえば、図4において、Store_Returnsのグレインは、Date_key、Item_key、Store_key、Customer_keyである。さらに、すべての次元について、すべての属性は、キー属性によって機能的に決定可能であるので、ファクトテーブルのグレインにおいて有効である。従って、たとえば、Year(年)、Quarter(四半期)、Month(月)等は、Date_keyによって決定可能であるので、Store_Returnsグレインにおいて有効である。同様の論拠を適用すると、図4のすべての次元列はStore_Returnsテーブルのグレインにおいて有効である。
ここで図3において、アグリゲータオペレーション/オペレータ324は、Customer_key、Store_keyによる行を出力し、このため、オペレーション324によって定義されるデータセットのグレインはStore_key、Customer_keyである。しかし、ここでも、機能依存性により、すべてのCustomer(顧客)列およびStore(店舗)列は、そのグレインにおいて有効である。したがって、ファクトテーブルStore_Returnsの場合、スキーマ:(Cust_Name,Item_Category,Store_Name,Qty)を用いて図4に示すスタースキーマに関して定義されたデータセットは、(Cust_Name, Stream_Category,Store_Name)のグレインを有し得る。
ウォークの開始時に、ファクトスキャンオペレーションのためのファクトテーブルについてのグレインは、ファクトテーブルの関連する次元におけるすべての属性である。したがって、図3では、サブプラン302におけるStore_Returnsについて、これは、Date(日付け)、Item(商品)、Store(店舗)、およびCustomer(顧客)の次元テーブルからのすべての列となる可能性があるとともに、Customer_Address次元テーブルからの副次的なCustomer(顧客)属性が含まれている。これは、図4のファクトテーブルについて定義されているスタースキーマに基づいている。
1324におけるウォーク中、Join(結合)オペレーションに対応するノードに遭遇すると、特別な処理が実行される。これは、ファクトテーブルとの確認結合を捕捉することと、Join(結合)の「他方側」からファクトスキャンオペレーション側または「ファクト側」に伝搬され得る適用可能なコンテキストを推論しようと試みることとを伴う。たとえば、図3において、Join(結合)オペレーションノード322の場合、ファクト側がStore_Returnsノード320であり得るとともに、他方側がFilter(フィルタ)オペレーションノード328であり得る。別の例として、図3において、ノード306の場合、ファクト側は左側のサブツリー302であり、他方側は右側のサブツリー312である。
確認結合は、結合がファクト側のグレインを変化させないことを暗示している。たとえば、最も一般的な確認パターンの一つとして、スタースキーマにおけるエッジについての条件と同じ結合条件がある。したがって、図4に示すスタースキーマを伴うクエリの場合、結合は、Store_ReturnsとStore_keyについてのStore(店舗)との間、または、Store_ReturnsとCustomer_keyとの間などでなければならない。対照的に、非確認結合の例は、Store_Returns実体化(実体化されたビューまたはOLAPインデックスなど)とcustomer_nameについてのCustomer(顧客)との間、または、Store_Returnsとstore_nameについてのStore_Rentテーブルとの間の結合を含み得る。このStore_Rentはスタースキーマの一部ではない。
確認結合に遭遇すると、推論論理は次に、確認結合についのて以下の追加条件をチェックする。ファクト側グレインは、結合されている次元グレインを含んでいなければならない。これに該当する場合、結合グレインによって機能的に決定される結合の他方側の任意のコンテキスト(述語条件)は、ファクト側、したがってファクトテーブルに適用可能である。たとえば、図3に示されるクエリプランの場合、最も左側の「Join on Date Key」ノード322の場合、Join(結合)オペレータの左側のファクト側サブツリーは、グレイン「Customer(顧客),Item(商品),Date(日付け),Store(店舗)」を有しており、他方側の結合はDate(日付け)次元にある。従って、これは、Date Keyのグレインでの確認結合である。すべてのDate(日付け)属性は、Date_keyによって決定することができるので、Year(年)についての述語は、ノード320によって表現されるファクトテーブルStore_Returnsについてのファクトスキャンオペレーションに伝搬することができる。同様の分析を、サブプラン312におけるStore_Returnsについてのファクトスキャンオペレーションのために実行することができる。
適用可能なグレインに関する情報は、ウォーク中に維持されて更新される。初めに、グレインにおけるすべてのDimension(次元)属性が識別される。集約オペレーション/オペレータ(たとえば、図3におけるノード324および330)を詳細に検討すると、グレインがグループ分けの列に変化する。たとえば、図3において、ノード324において集約オペレーション/オペレータを詳細に検討すると、グレインは(Customer_key,Store_key)になる。特定の実施形態では、クエリプランにおいて見出されるさまざまな種類のリレーショナルオペレーション/オペレータを詳細に検討してグレインがどのように修正されるかについてのルールが構成されて維持される。
1324におけるウォークの一部として、各ファクトテーブルスキャンオペレータごとに、関与する結合テーブルとの確認結合のリスト、そのファクトスキャンオペレーションのために識別または推論された適用可能な1つ以上の次元コンテキスト述語条件のリストを含む情報がエンハンサ103によって維持される。ファクトスキャンオペレーションのためのウォークの終了時に、ウォークされているファクトスキャンオペレータは、適用可能な1つ以上の次元コンテキスト(述語条件)および確認結合の候補リストを有している。
1326において、述語条件の推移的なファクト間の推論が実行される。この処理は、同じファクトまたは異なるファクトにわたる述語条件の推移的推論を伴う。ファクトスキャンオペレータの対(たとえば「fs1」(ファクトテーブルft1についてのファクトスキャン)および「fs2」(ファクトテーブルft2についてのファクトスキャン))ごとに、エンハンサ103は、D1がft1およびft2の両方のスタースキーマにあるように、結合条件が結合属性D1.jaを有する次元D1に対するものになるような結合オペレータを捜す。
たとえば、図12Bにおいて、
- fslは、Store_Retunsスキャン(ボックス1224)であり、
- fs2は、Store_Salesスキャン(ボックス1226)であり、
- 2つのファクトテーブルを結合する結合はノード1232であり、
- 共通次元D1はStore(店舗)次元であり、
- 結合はStore(店舗)のStore_key属性にある。
このようなパターンを見つけると、関与する両方のファクトテーブルが結合属性Dl.jaのグレインにある場合、エンハンサ103は、fs1からfs2への(逆の場合も同様に可能)結合グレインによって機能的に決定される次元D1についての任意の推論された次元コンテキストを伝搬することができる。したがって、図12Bでは、Store_Returnsスキャン(ボックス1224)からの推論されたコンテキスト述語条件「State(州)=TN」は、ボックス1232におけるStore_keyについての結合によりStore_Salesスキャン(ノード1226)に伝搬され得る。このようなファクト間の推論は推移的であるので、次元コンテキストは、fs1(ft1上)からfs2(ft2上)に、さらにはf3(ft3上)等に伝搬することができる。
1328において、述語条件の推移的な次元とファクトとの間の推論が実行される。スタースキーマはスノーフレークスキーマであり得るので、スタースキーマにおける次元テーブルからファクトテーブルまでの結合経路の長さは1以上であり得る。1328における処理は、図17に示されるスキーマ1700を用いて説明され得る。図17において、Store_Returnsはファクトテーブルであり、他のテーブルはすべての次元テーブルである(なお、スキーマ1700は、図4に示されるスキーマ400をわずかに変形させた例であることに留意されたい)。図4において、Income_Bandは、4テーブル結合(Income_Band join Customer_Demographics join Customer join Store_Returns)を通じてのみStore_Returnsに関連付けられている。Income_Band属性を含むStore_Returnsの物理的表現、たとえば、income_upper_bound属性を含むStore_ReturnsについてのOLAPインデックス、が存在する場合、income_upper_bound述語をこれに適用することも可能であり得る。OLAPインデックスファクトソースに対するincome_upper_boundコンテキスト(述語)の適用をエンハンサ103が推論するために、これは、Income_Band次元テーブルをファクトテーブルに接続する3つの結合(Income_Band join Customer_Demographic, Customer_Demographic join Customer, Customer join Store_returns)によって伝搬しなければならない。これは、ファクトスキャンオペレータの確認結合のリストを再帰的に構築することによって行われてもよく、新しい適用可能な確認結合に遭遇するたびに、1324と同様に他方側から任意の利用可能な次元コンテキストを伝搬する試みが行われる。
1330において、1つ以上の推論された次元コンテキスト述語条件が適用され、ファクトスキャンオペレーションに関連付けられる。このポイントにより、適用可能であれば、オリジナルのクエリプランにおいて識別される各ファクトテーブルスキャンオペレーション/オペレータ(または一般に、ファクトソーススキャンオペレーション)が、1つ以上の適用可能な次元コンテキスト述語条件のリストまたはセットに関連付けられる。1330における処理の一環として、ファクトスキャンオペレーションごとに識別された述語条件は、それらの純便益に基づいて順序付けられる。この場合、述語条件に関する純便益は、述語条件を適用した後にファクト行を処理するコストから述語条件を適用するコストを差引いた減少分である。
したがって、1330の一環として、ファクトスキャンオペレーションごとに、そのファクトスキャンオペレーションのために決定された適用可能な述語条件のリスト内の各述語条件について、エンハンサ103によって純便益メトリックが演算され得る。エンハンサ103は、純便益メトリックを演算するため、および以下のような順序付けを実行するために、いくつかの要因を考慮に入れてもよい。
- OLAPインデックスにおけるファクトおよび列についてのOLAPインデックスの利用可能性などのファクトの利用可能な物理的表現。なお、すべての次元列がOLAPインデックスにある必要はないことに留意されたい。
- 推論された次元コンテキストの選択性;選択性の高い述語は選択性の低い述語よりも好ましい。
- 次元コンテキスト述語条件を適用するコスト。たとえば、OLAPインデックススキャンへの述語のプッシュは、追加のコストをほとんど引起こさないので好ましい;Index Semi Join(インデックスセミ結合)は従来のSemi-Join(セミ結合)よりも好ましい。なぜなら、Index Semi Join(インデックスセミ結合)は、インデックススキャンオペレーション/オペレータにおいて非常に効率的なスキップスキャンを行う能力を活用するからである。
1330の一環として、順序付けの後、ファクトスキャンオペレーションごとに、述語条件のリストからの1つ以上の述語条件が、順序付けに基づいてファクトスキャンに関連付けるために決定される。特定の実施形態では、ファクトスキャンオペレーションのために、最適なプラスの純便益を提供するリストからの述語条件がファクトスキャンオペレーションに関連付けられるように選択される。
特定の実施形態では、ファクトスキャンオペレーションのために、そのファクトスキャンオペレーションについての述語条件の順序付けられたリストからの2つ以上の述語条件がファクトスキャンオペレーションに関連付けられてもよい。このようなシナリオでは、最高の純便益を提供する述語条件がファクトスキャンオペレーションに関連付けられた後、順序付けられたリストにおける追加の述語条件ごとに、次に最適な純便益を提供する述語条件から開始して、純便益分析が行われるが、この分析は、追加の述語条件がファクトスキャンオペレーションに関連付けられるべきかどうかを判断するために、当該追加の述語条件と、そのファクトスキャンオペレーションについての事前に関連付けられたすべての述語条件との関連付けを考慮して行なわれる。複数の述語条件がファクトスキャンオペレーションに関連付けられると、追加の述語条件を適用することの利点が、典型的には、関連付けられる述語条件の数と共に減少する。
1330における処理の後、特定のファクトスキャンオペレーションのために、そのファクトスキャンオペレーションに適用可能であると識別された1つ以上の述語条件がいずれも純便益を提供しない可能性がある。この場合、そのファクトスキャンオペレーションにはどの述語条件も関連付けられない可能性がある。
1332において、エンハンサ103は、ファクトスキャンオペレーションに関連付けられた既存の述語条件に基づいてクエリプランにおける1つ以上のファクトスキャンオペレーションについての新しいいずれかの1つ以上の述語条件を推論することによって、クエリプランの実行がさらに最適化され得るかどうかを判断する処理を実行する。ファクトスキャンオペレーションについての既存の述語条件は、オリジナルのクエリプランにおけるファクトスキャンオペレーションに関連付けられた述語条件(オリジナルの述語条件)、および/または、1330で実行された処理後のファクトスキャンオペレーションに関連付けられた述語条件であってもよい。したがって、1332において実行される処理の一環として、エンハンサ103は、新しい述語条件がオリジナルの述語条件よりもファクトスキャンオペレーションのためにより高い純便益を提供する場合、ファクトスキャンオペレーションに関連付けられたオリジナルの述語条件に基づいて新し変換済みの述語条件を見つけ出そうと試みてもよい。同様に、1330におけるファクトスキャンオペレーションに関連付けられた述語条件に関して、エンハンサ103は、新しい述語条件の方が1330におけるファクトスキャンオペレーションに関連付けられた述語条件よりもファクトスキャンオペレーションのためにより高い純便益を提供する場合、関連付けられた述語条件に基づいて新しい変換済みの述語条件を見つけ出そうとを試みてもよい。
特定の実施形態では、1322の一環として、エンハンサ103は、次元属性間の機能依存性に基づいて、識別された/推論された述語から暗示される述語を見つけ出そうと試みる。たとえば、図3に示されるクエリプランの場合、図5のボックス502において、左側のStore_Returnsに対する述語条件「State(州)=TN」の適用が示される。この「State(州)=TN」の適用は、場合によっては利用可能なOLAPインデックスがState(州)属性を持たなかったせいで、コスト効率が良くなかったと想定される。この場合、エンハンサ103は、以下のメタデータ情報を用いて新しい述語条件を推論し得る。
- State(州)列およびCity(市)列が階層にあり、
- 「TN」がデータベースに列挙された2つの市だけを有し、
- City(市)列がOLAPインデックスにある。
上述の情報を用いることで、「State(州)=TN」次元コンテキストが「City(市)=Memphis(メンフィス)またはCity(市)=Nashville(ナッシュビル)」として適用され得ることが推論される可能性があり得る。この場合、推論された述語条件の適用は、非常に高速のOLAPインデックススキャンを伴う。この推論された述語条件の適用は、高度化クエリプラン全体の実行に対する純便益を提供することができる。変換済みの述語条件の別の例が、図9に示されるとともに上述されている。
特定の実施形態では、1322における処理は、以下の場合にのみクエリプランにおけるファクトスキャンオペレーションのために実行される。以下の場合とは、すなわち、ファクトスキャンオペレーションに関連付けられたオリジナルの述語条件が(すなわち、オリジナルのクエリプランに)ない場合、少なくとも1つの述語条件が、1324、1326および1328において実行される処理に基づいてファクトスキャンオペレーションとの関連付けに適格な述語条件のリストにおいて識別された場合、ならびに、1330で実行された処理に基づいて、ファクトスキャンオペレーションについて判断されたリスト内の述語条件がいずれもプラスの純便益を提供せず、このため、1330においてファクトスキャンオペレーションに関連付けられなかったと判断された場合、を含む。このようなシナリオでは、このような変換済みの新しい述語条件のいずれかがファクトスキャンオペレーションに対してプラスの純便益を提供するかどうかを調べるために、エンハンサ103は、ファクトスキャンオペレーションのために識別される述語条件のリスト内の1つ以上の述語条件に対して1332における処理を実行してもよい。このような変換済みの新しい述語条件が見つけ出された場合、この条件が、1332において、エンハンサ103によってファクトスキャンオペレーションに関連付けられてもよい。しかしながら、これは限定するよう意図されたものではない。他のいくつかの実施形態では、1332における処理は、1330におけるファクトスキャンオペレーションに関連付けられた任意のオリジナルの述語条件および/または任意の述語条件のために実行されてもよい。
1334において、高度化クエリプランは、1つ以上のファクトスキャンオペレーションに関連付けられた1つ以上の述語条件を有するオリジナルのクエリプランに基づいて、生成される。特定の実施形態では、高度化クエリプランにおいて、1つ以上のファクトスキャンオペレーションに関連付けられるように識別された1つ以上の述語条件がファクトスキャンオペレーションに実際に関連付けられるように、オリジナルのクエリプランが高度化クエリプランとして書換えられる。したがって、高度化クエリプランが1308においてクエリ実行の一環として実行されると、関連付けられた述語条件は、それらが関連付けられるファクトスキャンオペレーションに対して評価される。
本明細書中に開示される教示に基づいて生成される高度化クエリプランは、従来の技術に勝るいくつかの利点を提供する。上述のように、SQLクエリなどの分析クエリは、典型的には、複数の次元に対する計算を含み、次元の関連付けをナビゲートすることによって組合わされる1つ以上のファクトテーブルに対する計算の複数層を伴う。一例として、次元の関連付けの一般的な例は、Year(年)-Quarter(四半期)-Month(月)またはCountry(国)-State(州)-City(市)などのような階層である。図3に示される例において、サブプラン302は、各Store(店舗)におけるCustomer(顧客)のStore Returns(店舗への返品)についての計算を含み、サブプラン312は、Store(店舗)のすべてのCustomer(顧客)のためにStore(店舗)における集約返品についての計算を含む。ノード306では、これらの2つが組合わされて、「問題」となる顧客を発見する。テラバイト(さらにはそれ以上)の規模での、データベースを超えるこのような多層計算は、極めて計算集約的であり、「think-time」内に任意のクエリに応答することは非常に難しい。本明細書中に開示されるさまざまな発明技術は、OLAPインデックス付け、およびスケールアウト・シェアードナッシング・アーキテクチャを含むがこれらに限定されない、このようなスケールでのアドホッククエリのための対話型経験を可能にする分析プラットフォームを提供する。本明細書中で説明される分析プラットフォームは、非常に大きな(テラバイト以上の)多次元データ(たとえば、データレーキに格納されたデータ)に対して、非常にコスト効率良く、対話型アドホッククエリを実行する能力を提供する。従来の技術を用いて過去に非常に大きな(テラバイト以上の)多次元データに対してこのような対話型アドホッククエリを実行することは、法外な費用がかかるものであって、スケーリングしていなかった。
クエリの場合、しばしば、アナリストの意図は、広大な多次元空間の小さな領域に焦点を合わせることである。たとえば、図3では、分析の焦点はテネシーの州に合わされている。しかし、SQLのようなクエリ言語では、この分析コンテキストは不明瞭になる可能性がある。なぜなら、関係代数オペレータを用いてこのような多次元計算を書き込むことは厄介であるからである。さらなるSQL書き込みは、しばしば、SQLジェネレータツールを介して、またはドメインエキスパートではないデータエンジニアによって行われる。これらの目標は、正しい回答を与えるSQLを生成することである。これらは、不要なファクト処理を回避するクエリプランをSQLクエリエンジンが生成することを容易にする態様で「テネシーの州」についての分析のようなセマンティック情報を搬送することには関係していない。従来のリレーショナルクエリオプティマイザはリレーショナルスキーマで動作するものであって、このため、分析質問がどのように表現されるかに基づく非常に有益な多次元キューブセマンティックモデルについての知識に欠けている。すべてのアナリストは自身の頭の中にこのモデルを記憶している。本明細書に開示される分析プラットフォームは、多次元キューブセマンティックモデルにおいて定義される関係を活用することによって、エンジニアに、分析のコンテキストをクエリプランの構造から反転させる処理を実行する。多くの場合、これにより、ファクトを処理するのに必要なリソースを大幅に削減する適用可能な次元コンテキスト(述語条件)が推論されることとなる。サイズが大きいデータスケール(たとえば、テラバイトスケール)では、さらにこれを超える大きさでは、ファクト処理コストの削減は、この明細書中で説明するように、アドホッククエリを対話的に処理する能力に大きな影響を及ぼす。
上述したように、分析クエリをより効率的に実行するための分析プラットフォームが提供される。特定の実施形態では、Apache Sparkネイティブ分析プラットフォームが提供される。分析クエリ(たとえば、SQLクエリ)のために生成されるクエリプランは、最適化されるとともに高度化されたクエリプランを作成するように最適化される。ビジネスデータおよびビジネスインテリジェンスデータなどのセマンティクス情報は、高度化クエリプランを生成するために用いられる。ドメインセマンティクスは、より効率的なクエリプランを生成するために用いられる。ビジネスセマンティクスは、クエリ実行最適化に用いられる。
性能の観点から、高度化クエリプランは、(実行を完了するために必要なCPUサイクルがより少ないため)より高速で実行され、多くの場合、非高度化クエリプランよりも、用いるメモリリソースが少なくて済む可能性がある。クエリプランを書換えた結果、対応するクエリは、書換え前よりも桁違い(たとえば、10倍、25倍、100倍など)に高速で実行することができる。これは、ファクトテーブルが次元テーブルよりも桁違いに大きく、したがって、ファクトレコードを処理することに関連するスキャンコストを削減することで、性能利得が莫大になるからである。
前述したように、本明細書中に記載される分析プラットフォームは、Sparkクラスタを用いてApache Sparkネイティブソリューションとして実現され得る。したがって、Apache Sparkおよびそのエコシステム、たとえば、コアコンポーネント、スケールイン・アウトメモリランタイム、触媒コンポーネント、JDBC、メタ店舗等のパワーを十分に利用している。
本明細書中に説明されるように、高度化クエリプランによってファクトレコードを処理およびスキャンするコストが非高度化クエリプランと比較して削減される最適化クエリプランを生成するための技術が説明される。分析活動は、しばしば、データセット全体ではなく、特定のサブ集団またはサブコンテキストに焦点を合わされている。セマンティクス情報からクエリに適用可能なコンテキストを推論し、(たとえば、コンテキストまたは述語条件伝搬によって)当該コンテキストをクエリプランに適用することにより、クエリプランと、結果として当該クエリプランが生成されるクエリとの実行について大幅な性能向上をもたらし得る。分析ドメインまたは分析活動に拘わらず、分析のコンテキストを判断するために識別され得る共通のパターンが存在する。特定の実施形態では、これらのパターンを識別するとともに、最適化された高度化クエリプランを生成するための技術が提供される。
図14は、ある実施形態を実現するための分散型システム1400の簡略図を示す。図示される実施形態において、分散型システム1400は、1つ以上の通信ネットワーク1410を介してサーバ1412に結合された1つ以上のクライアントコンピューティングデバイス1402、1404、1406、および1408を含む。クライアントコンピューティングデバイス1402、1404、1406、および1408は、1つ以上のアプリケーションを実行するように構成され得る。
さまざまな実施形態において、サーバ1412は、上述の分析クエリの実行を可能にする1つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。
特定の実施形態では、サーバ1412はまた、非仮想環境および仮想環境を含み得る他のサービスまたはソフトウェアアプリケーションを提供し得る。いくつかの実施形態では、これらのサービスは、クライアントコンピューティングデバイス1402、1404、1406および/または1408のユーザに対して、サービスとしてのソフトウェア(Software as a Service:SaaS)モデルのようなウェブベースのサービスまたはクラウドサービスとして提供され得る。クライアントコンピューティングデバイス1402、1404、1406および/または1408を操作するユーザは、1つ以上のクライアントアプリケーションを利用してサーバ1412とやり取りすることで、これらのコンポーネントによって提供されるサービスを利用し得る。
図14に示される構成では、サーバ1412は、サーバ1412によって実行される機能を実現する1つ以上のコンポーネント1418、1420および1422を含み得る。これらのコンポーネントは、1つ以上のプロセッサ、ハードウェアコンポーネント、またはそれらの組合わせによって実行され得るソフトウェアコンポーネントを含み得る。分散型システム1400とは異なり得る多種多様なシステム構成が可能であることが認識されるはずである。したがって、図14に示される実施形態は、実施形態のシステムを実現するための分散型システムの一例であり、限定するよう意図されたものではない。
ユーザは、クライアントコンピューティングデバイス1402、1404、1406および/または1408を用いて、本開示の教示に従って分析クエリを提出してもよい。クライアントデバイスは、当該クライアントデバイスのユーザが当該クライアントデバイスと対話することを可能にするインターフェイスを提供し得る。クライアントデバイスはまた、このインターフェイスを介してユーザに情報を出力してもよい。たとえば、クエリ結果は、クライアントデバイスによって提供されるインターフェイスを介してユーザに出力され得る。図14は4つのクライアントコンピューティングデバイスだけを示しているが、任意の数のクライアントコンピューティングデバイスがサポートされ得る。
クライアントデバイスは、ポータブルハンドヘルドデバイス、パーソナルコンピュータおよびラップトップのような汎用コンピュータ、ワークステーションコンピュータ、ウェアラブルデバイス、ゲームシステム、シンクライアント、各種メッセージングデバイス、センサまたはその他のセンシングデバイスなどの、さまざまな種類のコンピューティングシステムを含み得る。これらのコンピューティングデバイスは、さまざまな種類およびバージョンのソフトウェアアプリケーションおよびオペレーティングシステム(たとえばMicrosoft Windows(登録商標)、Apple Macintosh(登録商標)、UNIX(登録商標)またはUNIX系オペレーティングシステム、Linux(登録商標)またはLinux系オペレーティングシステム、たとえば、各種モバイルオペレーティングシステム(たとえばMicrosoft Windows Mobile(登録商標)、iOS(登録商標)、Windows Phone(登録商標)、Android(登録商標)、BlackBerry(登録商標)、Palm OS(登録商標))を含むGoogle Chrome(登録商標)OS)を含み得る。ポータブルハンドヘルドデバイスは、セルラーフォン、スマートフォン(たとえばiPhone(登録商標))、タブレット(たとえばiPad(登録商標))、携帯情報端末(PDA)などを含み得る。ウェアラブルデバイスは、Google Glass(登録商標)ヘッドマウントディスプレイおよびその他のデバイスを含み得る。ゲームシステムは、各種ハンドヘルドゲームデバイス、インターネット接続可能なゲームデバイス(たとえばKinect(登録商標)ジェスチャ入力デバイス付き/無しのMicrosoft Xbox(登録商標)ゲーム機、Sony PlayStation(登録商標)システム、Nintendo(登録商標)が提供する各種ゲームシステムなど)を含み得る。クライアントデバイスは、各種インターネット関連アプリケーション、通信アプリケーション(たとえばEメールアプリケーション、ショートメッセージサービス(SMS)アプリケーション)のような多種多様なアプリケーションを実行可能であってもよく、各種通信プロトコルを使用してもよい。
ネットワーク1410は、利用可能な多様なプロトコルのうちのいずれかを用いてデータ通信をサポートできる、当該技術の当業者には周知のいずれかの種類のネットワークであればよく、上記プロトコルは、TCP/IP(伝送制御プロトコル/インターネットプロトコル)、SNA(システムネットワークアーキテクチャ)、IPX(インターネットパケット交換)、AppleTalk(登録商標)などを含むがこれらに限定されない。単に一例として、ネットワーク1410は、ローカルエリアネットワーク(LAN)、Ethernet(登録商標)に基づくネットワーク、トークンリング、ワイドエリアネットワーク(WAN)、インターネット、仮想ネットワーク、仮想プライベートネットワーク(VPN)、イントラネット、エクストラネット、公衆交換電話網(PSTN)、赤外線ネットワーク、無線ネットワーク(たとえば電気電子学会(IEEE)802.11プロトコルスイートのいずれかの下で動作する無線ネットワーク、Bluetoothおよび/または任意の他の無線プロトコル)、および/またはこれらおよび/または他のネットワークの任意の組み合わせを含み得る。
サーバ1412は、1つ以上の汎用コンピュータ、専用サーバコンピュータ(一例としてPC(パーソナルコンピュータ)サーバ、UNIX(登録商標)サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む)、サーバファーム、サーバクラスタ、またはその他の適切な構成および/または組み合わせで構成されてもよい。サーバ1412は、仮想オペレーティングシステムを実行する1つ以上の仮想マシン、または仮想化を伴う他のコンピューティングアーキテクチャを含み得る。これはたとえば、サーバに対して仮想記憶装置を維持するように仮想化できる論理記憶装置の1つ以上のフレキシブルプールなどである。各種実施形態において、サーバ1412を、上記開示に記載の機能を提供する1つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合させてもよい。
サーバ1412内のコンピューティングシステムは、上記オペレーティングシステムのうちのいずれかを含む1つ以上のオペレーティングシステム、および、市販されているサーバオペレーティングシステムを実行し得る。また、サーバ1412は、HTTP(ハイパーテキスト転送プロトコル)サーバ、FTP(ファイル転送プロトコル)サーバ、CGI(コモンゲートウェイインターフェイス)サーバ、JAVA(登録商標)サーバ、データベースサーバなどを含むさまざまなさらに他のサーバアプリケーションおよび/または中間層アプリケーションのうちのいずれかを実行し得る。例示的なデータベースサーバは、Oracle(登録商標)、Microsoft(登録商標)、Sybase(登録商標)、IBM(登録商標)(International Business Machines)などから市販されているものを含むが、それらに限定されない。
いくつかの実現例において、サーバ1412は、クライアントコンピューティングデバイス1402、1404、1406および1408のユーザから受信したデータフィードおよび/またはイベントアップデートを解析および整理統合するための1つ以上のアプリケーションを含み得る。一例として、データフィードおよび/またはイベントアップデートは、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール(たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション)、クリックストリーム解析ツール、自動車交通モニタリングなどに関連するリアルタイムのイベントを含んでもよい、1つ以上の第三者情報源および連続データストリームから受信される、Twitter(登録商標)フィード、Facebook(登録商標)アップデートまたはリアルタイムのアップデートを含み得るが、それらに限定されない。サーバ1412は、データフィードおよび/またはリアルタイムのイベントをクライアントコンピューティングデバイス1402、1404、1406および1408の1つ以上の表示デバイスを介して表示するための1つ以上のアプリケーションも含み得る。
分散型システム1400はまた、1つ以上のデータリポジトリ1414、1416を含み得る。特定の実施形態において、これらのデータリポジトリを用いてデータおよびその他の情報を格納することができる。たとえば、データリポジトリ1414、1416のうちの1つ以上を用いて、データベースデータ、メタデータなどを格納することができる。データリポジトリ1414、1416は、さまざまな場所に存在し得る。たとえば、サーバ1412が使用するデータリポジトリは、サーバ1412のローカル位置にあってもよく、またはサーバ1412から遠隔の位置にあってもよく、ネットワークベースの接続または専用接続を介してサーバ1412と通信する。データリポジトリ1414、1416は、異なる種類であってもよい。特定の実施形態において、サーバ1412が使用するデータリポジトリは、データベース、たとえば、Oracle Corporation(登録商標)および他の製造業者が提供するデータベースのようなリレーショナルデータベースであってもよい。これらのデータベースのうちの1つ以上を、SQLフォーマットのコマンドに応じて、データの格納、アップデート、およびデータベースとの間での取り出しを可能にするように適合させてもよい。
特定の実施形態では、データレポジトリ1414、1416のうちの1つ以上は、アプリケーションデータを格納するためにアプリケーションによって用いられてもよい。アプリケーションが使用するデータリポジトリは、たとえば、キー値ストアリポジトリ、オブジェクトストアリポジトリ、またはファイルシステムがサポートする汎用ストレージリポジトリのようなさまざまな種類のものであってもよい。
特定の実施形態において、本開示に記載される機能により提供される分析プラットフォームは、クラウド環境を介してサービスとして提供され得る。図15は、特定の実施形態に係る、各種サービスをクラウドサービスとして提供し得るクラウドベースのシステム環境の簡略化されたブロック図である。図15に示される実施形態において、クラウドインフラストラクチャシステム1502は、ユーザが1つ以上のクライアントコンピューティングデバイス1504、1506および1508を用いて要求し得る1つ以上のクラウドサービスを提供し得る。クラウドインフラストラクチャシステム1502は、サーバ1412に関して先に述べたものを含み得る1つ以上のコンピュータおよび/またはサーバを含み得る。クラウドインフラストラクチャシステム1502内のコンピュータは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他任意の適切な配置および/または組み合わせとして編成され得る。
ネットワーク1510は、クライアント1504、1506、および1508と、クラウドインフラストラクチャシステム1502との間におけるデータの通信および交換を容易にし得る。ネットワーク1510は、1つ以上のネットワークを含み得る。ネットワークは同じ種類であっても異なる種類であってもよい。ネットワーク1510は、通信を容易にするために、有線および/または無線プロトコルを含む、1つ以上の通信プロトコルをサポートし得る。
図15に示される実施形態は、クラウドインフラストラクチャシステムの一例にすぎず、限定を意図したものではない。なお、その他いくつかの実施形態において、クラウドインフラストラクチャシステム1502が、図15に示されるものよりも多くのコンポーネントもしくは少ないコンポーネントを有していてもよく、2つ以上のコンポーネントを組み合わせてもよく、または、異なる構成または配置のコンポーネントを有していてもよいことが、理解されるはずである。たとえば、図15は3つのクライアントコンピューティングデバイスを示しているが、代替実施形態においては、任意の数のクライアントコンピューティングデバイスがサポートされ得る。
クラウドサービスという用語は一般に、サービスプロバイダのシステム(たとえばクラウドインフラストラクチャシステム1502)により、インターネット等の通信ネットワークを介してオンデマンドでユーザにとって利用可能にされるサービスを指すのに使用される。典型的に、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なる。クラウドサービスプロバイダのシステムは、クラウドサービスプロバイダによって管理される。よって、顧客は、別途ライセンス、サポート、またはハードウェアおよびソフトウェアリソースをサービスのために購入しなくても、クラウドサービスプロバイダが提供するクラウドサービスを利用できる。たとえば、クラウドサービスプロバイダのシステムはアプリケーションをホストし得るとともに、ユーザは、アプリケーションを実行するためにインフラストラクチャリソースを購入しなくても、インターネットを介してオンデマンドでアプリケーションをオーダーして使用し得る。クラウドサービスは、アプリケーション、リソースおよびサービスに対する容易でスケーラブルなアクセスを提供するように設計される。いくつかのプロバイダがクラウドサービスを提供する。たとえば、ミドルウェアサービス、データベースサービス、Java(登録商標)クラウドサービスなどのいくつかのクラウドサービスが、カリフォルニア州レッドウッド・ショアーズのOracle Corporation(登録商標)から提供される。
特定の実施形態において、クラウドインフラストラクチャシステム1502は、ハイブリッドサービスモデルを含む、サービスとしてのソフトウェア(SaaS)モデル、サービスとしてのプラットフォーム(PaaS)モデル、サービスとしてのインフラストラクチャ(IaaS)モデルなどのさまざまなモデルを使用して、1つ以上のクラウドサービスを提供し得る。クラウドインフラストラクチャシステム1502は、各種クラウドサービスのプロビジョンを可能にする、アプリケーション、ミドルウェア、データベース、およびその他のリソースのスイートを含み得る。
SaaSモデルは、アプリケーションまたはソフトウェアを、インターネットのような通信ネットワークを通して、顧客が基本となるアプリケーションのためのハードウェアまたはソフトウェアを購入しなくても、サービスとして顧客に配信することを可能にする。たとえば、SaaSモデルを用いることにより、クラウドインフラストラクチャシステム1502がホストするオンデマンドアプリケーションに顧客がアクセスできるようにし得る。Oracle Corporation(登録商標)が提供するSaaSサービスの例は、人的資源/資本管理のための各種サービス、カスタマー・リレーションシップ・マネジメント(CRM)、エンタープライズ・リソース・プランニング(ERP)、サプライチェーン・マネジメント(SCM)、エンタープライズ・パフォーマンス・マネジメント(EPM)、解析サービス、ソーシャルアプリケーションなどを含むがこれらに限定されない。
IaaSモデルは一般に、インフラストラクチャリソース(たとえばサーバ、ストレージ、ハードウェアおよびネットワーキングリソース)を、クラウドサービスとして顧客に提供することにより、柔軟な計算およびストレージ機能を提供するために使用される。各種IaaSサービスがOracle Corporation(登録商標)から提供される。
PaaSモデルは一般に、顧客が、環境リソースを調達、構築、または管理しなくても、アプリケーションおよびサービスを開発、実行、および管理することを可能にするプラットフォームおよび環境リソースをサービスとして提供するために使用される。Oracle Corporation(登録商標)が提供するPaaSサービスの例は、Oracle Java Cloud Service(JCS)、Oracle Database Cloud Service(DBCS)、データ管理クラウドサービス、各種アプリケーション開発ソリューションサービスなどを含むがこれらに限定されない。
クラウドサービスは一般に、オンデマンドのセルフサービスベースで、サブスクリプションベースで、柔軟にスケーラブルで、信頼性が高く、可用性が高い、安全なやり方で提供される。たとえば、顧客は、サブスクリプションオーダーを介し、クラウドインフラストラクチャシステム1502が提供する1つ以上のサービスをオーダーしてもよい。次いで、クラウドインフラストラクチャシステム1502は、処理を実行することにより、顧客のサブスクリプションオーダーで要求されたサービスを提供する。たとえば、システム1502は、この開示に記載されるように分析クエリのために機能するように機能する。クラウドインフラストラクチャシステム1502を、1つまたは複数のクラウドサービスを提供するように構成してもよい。
クラウドインフラストラクチャシステム1502は、さまざまなデプロイメントモデルを介してクラウドサービスを提供し得る。パブリッククラウドモデルにおいて、クラウドインフラストラクチャシステム1502は、第三者クラウドサービスプロバイダによって所有されていてもよく、クラウドサービスは一般のパブリックカスタマーに提供される。このカスタマーは個人でも企業でもよい。その他の特定の実施形態において、プライベートクラウドモデルでは、クラウドインフラストラクチャシステム1502がある組織内で(たとえば企業組織内で)機能してもよく、サービスはこの組織内の顧客に提供される。たとえば、この顧客は、人事部、給与部などの企業のさまざまな部署であってもよく、企業内の個人であってもよい。その他の特定の実施形態において、コミュニティクラウドモデルでは、クラウドインフラストラクチャシステム1502および提供されるサービスは、関連コミュニティ内のさまざまな組織で共有されてもよい。上記モデルの混成モデルなどのその他各種モデルが用いられてもよい。
クライアントコンピューティングデバイス1504、1506、および1508は、異なるタイプであってもよく(たとえば図14に示されるデバイス1402、1404、1406および1408)、1つ以上のクライアントアプリケーションを操作可能であってもよい。ユーザは、クライアントデバイスを用いることにより、クラウドインフラストラクチャシステム1502が提供するサービスを要求することなど、クラウドインフラストラクチャシステム1502とのやり取りを行い得る。
いくつかの実施形態において、クラウドインフラストラクチャシステム1502が、クラウドサービスを提供するために実行する処理は、ビッグデータ解析を含み得る。この解析は、大きなデータセットを使用し、解析し、処理することにより、このデータ内のさまざまな傾向、挙動、関係などを検出し可視化することを含み得る。この解析は、1つ以上のプロセッサが、場合によっては、データを並列に処理し、データを用いてシミュレーションを実行するなどして、実行してもよい。この解析に使用されるデータは、構造化データ(たとえばデータベースに格納されたデータもしくは構造化モデルに従って構造化されたデータ)および/または非構造化データ(たとえばデータブロブ(blob)(binary large object:バイナリ・ラージ・オブジェクト))を含み得る。
図15の実施形態に示されるように、クラウドインフラストラクチャシステム1502は、クラウドインフラストラクチャシステム1502が提供する各種クラウドサービスのプロビジョンを容易にするために利用されるインフラストラクチャリソース1530を含み得る。インフラストラクチャリソース1530は、たとえば、処理リソース、ストレージまたはメモリリソース、ネットワーキングリソースなどを含み得る。
特定の実施形態において、異なる顧客に対しクラウドインフラストラクチャシステム1502が提供する各種クラウドサービスをサポートするためのこれらのリソースを効率的にプロビジョニングし易くするために、リソースを、リソースのセットまたはリソースモジュール(「ポッド」とも処される)にまとめてもよい。各リソースモジュールまたはポッドは、1種類以上のリソースを予め一体化し最適化した組み合わせを含み得る。特定の実施形態において、異なるポッドを異なる種類のクラウドサービスに対して予めプロビジョニングしてもよい。たとえば、第1のポッドセットをデータベースサービスのためにプロビジョニングしてもよく、第1のポッドセット内のポッドと異なるリソースの組み合わせを含み得る第2のポッドセットをJavaサービスなどのためにプロビジョニングしてもよい。いくつかのサービスについて、これらのサービスをプロビジョニングするために割り当てられたリソースをサービス間で共有してもよい。
クラウドインフラストラクチャシステム1502自体が、クラウドインフラストラクチャシステム1502の異なるコンポーネントによって共有されるとともにクラウドインフラストラクチャシステム1502によるサービスのプロビジョニングを容易にするサービス1532を、内部で使用してもよい。これらの内部共有サービスは、セキュリティ・アイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウィルススキャン・ホワイトリストサービス、高可用性、バックアップリカバリサービス、クラウドサポートを可能にするサービス、Eメールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されない。
クラウドインフラストラクチャシステム1502は複数のサブシステムを含み得る。これらのサブシステムは、ソフトウェア、またはハードウェア、またはそれらの組み合わせで実現され得る。図15に示されるように、サブシステムは、クラウドインフラストラクチャシステム1502のユーザまたは顧客がクラウドインフラストラクチャシステム1502とやり取りすることを可能にするユーザインターフェイスサブシステム1512を含み得る。ユーザインターフェイスサブシステム1512は、ウェブインターフェイス1514、クラウドインフラストラクチャシステム1502が提供するクラウドサービスが宣伝広告され消費者による購入が可能なオンラインストアインターフェイス1516、およびその他のインターフェイス1518などの、各種異なるインターフェイスを含み得る。たとえば、顧客は、クライアントデバイスを用いて、クラウドインフラストラクチャシステム1502がインターフェイス1514、1516、および1518のうちの1つ以上を用いて提供する1つ以上のサービスを要求(サービス要求1534)してもよい。たとえば、顧客は、オンラインストアにアクセスし、クラウドインフラストラクチャシステム1502が提供するクラウドサービスをブラウズし、クラウドインフラストラクチャシステム1502が提供するとともに顧客が申し込むことを所望する1つ以上のサービスについてサブスクリプションオーダーを行い得る。このサービス要求は、顧客と、顧客が申しむことを所望する1つ以上のサービスを識別する情報を含んでいてもよい。
図15に示される実施形態のような特定の実施形態において、クラウドインフラストラクチャシステム1502は、新しいオーダーを処理するように構成されたオーダー管理サブシステム(order management subsystem:OMS)1520を含み得る。この処理の一部として、OMS1520は、既に作成されていなければ顧客のアカウントを作成し、要求されたサービスを顧客に提供するために顧客に対して課金するのに使用する課金および/またはアカウント情報を顧客から受け、顧客情報を検証し、検証後、顧客のためにこのオーダーを予約し、各種ワークフローを調整することにより、プロビジョニングのためにオーダーを準備するように、構成されてもよい。
適切に妥当性確認がなされると、OMS1520は、処理、メモリ、およびネットワーキングリソースを含む、このオーダーのためのリソースをプロビジョニングするように構成されたオーダープロビジョニングサブシステム(OPS)1524を呼び出し得る。プロビジョニングは、オーダーのためのリソースを割り当てることと、顧客オーダーが要求するサービスを容易にするようにリソースを構成することとを含み得る。オーダーのためにリソースをプロビジョニングするやり方およびプロビジョニングされるリソースのタイプは、顧客がオーダーしたクラウドサービスのタイプに依存し得る。たとえば、あるワークフローに従うと、OPS1524を、要求されている特定のクラウドサービスを判断し、この特定のクラウドサービスのために予め構成されたであろうポッドの数を特定するように構成されてもよい。あるオーダーのために割り当てられるポッドの数は、要求されたサービスのサイズ/量/レベル/範囲に依存し得る。たとえば、割り当てるポッドの数は、サービスがサポートすべきユーザの数、サービスが要求されている期間などに基づいて決定してもよい。次に、割り当てられたポッドを、要求されたサービスを提供するために、要求している特定の顧客に合わせてカスタマイズしてもよい。
クラウドインフラストラクチャシステム1502は、要求されたサービスがいつ使用できるようになるかを示すために、レスポンスまたは通知1544を、要求している顧客に送ってもよい。いくつかの例において、顧客が、要求したサービスの利益の使用および利用を開始できるようにする情報(たとえばリンク)を顧客に送信してもよい。
クラウドインフラストラクチャシステム1502はサービスを複数の顧客に提供し得る。各顧客ごとに、クラウドインフラストラクチャシステム1502は、顧客から受けた1つ以上のサブスクリプションオーダーに関連する情報を管理し、オーダーに関連する顧客データを維持し、要求されたサービスを顧客に提供する役割を果たす。また、クラウドインフラストラクチャシステム1502は、申し込まれたサービスの顧客による使用に関する使用統計を収集してもよい。たとえば、統計は、使用されたストレージの量、転送されたデータの量、ユーザの数、ならびにシステムアップタイムおよびシステムダウンタイムの量などについて、収集されてもよい。この使用情報を用いて顧客に課金してもよい。課金はたとえば月ごとに行ってもよい。
クラウドインフラストラクチャシステム1502は、サービスを複数の顧客に並列に提供してもよい。クラウドインフラストラクチャシステム1502は、場合によっては著作権情報を含む、これらの顧客についての情報を格納してもよい。特定の実施形態において、クラウドインフラストラクチャシステム1502は、顧客の情報を管理するとともに管理される情報を分離することで、ある顧客に関する情報が別の顧客に関する情報からアクセスされないようにするように構成された、アイデンティティ管理サブシステム(IMS)1528を含む。IMS1528は、アイデンティティサービス、たとえば情報アクセス管理、認証および許可サービス、顧客のアイデンティティおよび役割ならびに関連する能力などを管理するためのサービスなどの、各種セキュリティ関連サービスを提供するように構成されてもよい。
図16は、特定の実施形態を実現するために用いられ得る例示的なコンピュータシステム1600を示す。たとえば、いくつかの実施形態では、コンピュータシステム1600は、図1Aおよび図1Bに示されるシステムのいずれかを実現するために用いられ得る。図16に示されるように、コンピュータシステム1600は、バスサブシステム1602を介して他のいくつかのサブシステムと通信する処理サブシステム1604を含むさまざまなサブシステムを含む。これらの他のサブシステムは、処理加速ユニット1606、I/Oサブシステム1608、ストレージサブシステム1618、および通信サブシステム1624を含み得る。ストレージサブシステム1618は、記憶媒体1622およびシステムメモリ1610を含む非一時的なコンピュータ読取り可能記憶媒体を含み得る。
バスサブシステム1602は、コンピュータシステム1600のさまざまなコンポーネントおよびサブシステムに意図されるように互いに通信させるための機構を提供する。バスサブシステム1602は単一のバスとして概略的に示されているが、バスサブシステムの代替実施形態は複数のバスを利用してもよい。バスサブシステム1602は、さまざまなバスアーキテクチャのうちのいずれかを用いる、メモリバスまたはメモリコントローラ、周辺バス、ローカルバスなどを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、このようなアーキテクチャは、業界標準アーキテクチャ(Industry Standard Architecture:ISA)バス、マイクロチャネルアーキテクチャ(Micro Channel Architecture:MCA)バス、エンハンストISA(Enhanced ISA:EISA)バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション(Video Electronics Standards Association:VESA)ローカルバス、およびIEEE P1386.1規格に従って製造されるメザニンバスとして実現可能な周辺コンポーネントインターコネクト(Peripheral Component Interconnect:PCI)バスなどを含み得る。
処理サブシステム1604は、コンピュータシステム1600の動作を制御し、1つ以上のプロセッサ、特定用途向け集積回路(ASIC)、またはフィールドプログラマブルゲートアレイ(FPGA)を含み得る。プロセッサは、シングルコアまたはマルチコアプロセッサを含み得る。コンピュータシステム1600の処理リソースを、1つ以上の処理ユニット1632、1634などに組織することができる。処理ユニットは、1つ以上のプロセッサ、同一のまたは異なるプロセッサからの1つ以上のコア、コアとプロセッサとの組み合わせ、またはコアとプロセッサとのその他の組み合わせを含み得る。いくつかの実施形態において、処理サブシステム1604は、グラフィックスプロセッサ、デジタル信号プロセッサ(DSP)などのような1つ以上の専用コプロセッサを含み得る。いくつかの実施形態では、処理サブシステム1604の処理ユニットの一部または全部は、特定用途向け集積回路(ASIC)またはフィールドプログラマブルゲートアレイ(FPGA)などのカスタマイズされた回路を使用して実現することができる。
いくつかの実施形態において、処理サブシステム1604内の処理ユニットは、システムメモリ1610またはコンピュータ読取り可能記憶媒体1622に格納された命令を実行することができる。さまざまな実施形態において、処理ユニットはさまざまなプログラムまたはコード命令を実行するとともに、同時に実行する複数のプログラムまたはプロセスを維持することができる。任意の所定の時点で、実行されるべきプログラムコードの一部または全部は、システムメモリ1610および/または潜在的に1つ以上の記憶装置を含むコンピュータ読取り可能記憶媒体1622に常駐していてもよい。適切なプログラミングを介して、処理サブシステム1604は、上述のさまざまな機能を提供することができる。コンピュータシステム1600が1つ以上の仮想マシンを実行している例において、1つ以上の処理ユニットが各仮想マシンに割り当ててもよい。
特定の実施形態において、コンピュータシステム1600によって実行される全体的な処理を加速するように、カスタマイズされた処理を実行するために、または処理サブシステム1604によって実行される処理の一部をオフロードするために、処理加速ユニット1606を任意に設けることができる。
I/Oサブシステム1608は、コンピュータシステム1600に情報を入力するための、および/またはコンピュータシステム1600から、もしくはコンピュータシステム1600を介して、情報を出力するための、デバイスおよび機構を含むことができる。一般に、「入力デバイス」という語の使用は、コンピュータシステム1600に情報を入力するためのすべての考えられ得るタイプのデバイスおよび機構を含むよう意図される。ユーザインターフェイス入力デバイスは、たとえば、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを伴う音声入力デバイス、マイクロフォン、および他のタイプの入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、ユーザが入力デバイスを制御しそれと対話することを可能にするMicrosoft Kinect(登録商標)モーションセンサ、Microsoft Xbox(登録商標)360ゲームコントローラ、ジェスチャおよび音声コマンドを用いる入力を受信するためのインターフェイスを提供するデバイスなど、モーションセンシングおよび/またはジェスチャ認識デバイスも含んでもよい。ユーザインターフェイス入力デバイスは、ユーザから目の動き(たとえば、写真を撮っている間および/またはメニュー選択を行っている間の「まばたき」)を検出し、アイジェスチャを入力デバイス(たとえばGoogle Glass(登録商標))への入力として変換するGoogle Glass(登録商標)瞬き検出器などのアイジェスチャ認識デバイスも含んでもよい。また、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを介して音声認識システム(たとえばSiri(登録商標)ナビゲータ)と対話することを可能にする音声認識感知デバイスを含んでもよい。
ユーザインターフェイス入力デバイスの他の例は、三次元(3D)マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびにスピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ3Dスキャナ、3Dプリンタ、レーザレンジファインダ、および視線追跡デバイスなどの聴覚/視覚デバイスも含んでもよいが、それらに限定されない。また、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影、磁気共鳴撮像、ポジションエミッショントモグラフィー、および医療用超音波検査デバイスなどの医療用画像化入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、たとえば、MIDIキーボード、デジタル楽器などの音声入力デバイスも含んでもよい。
一般に、出力デバイスという語の使用は、コンピュータシステム1600からユーザまたは他のコンピュータに情報を出力するための考えられるすべてのタイプのデバイスおよび機構を含むことを意図している。ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、インジケータライト、または音声出力デバイスなどのような非ビジュアルディスプレイなどを含んでもよい。ディスプレイサブシステムは、陰極線管(CRT)、液晶ディスプレイ(LCD)またはプラズマディスプレイを使うものなどのフラットパネルデバイス、計画デバイス、タッチスクリーンなどであってもよい。たとえば、ユーザインターフェイス出力デバイスは、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力デバイスおよびモデムなどの、テキスト、グラフィックスおよび音声/映像情報を視覚的に伝えるさまざまな表示デバイスを含んでもよいが、それらに限定されない。
ストレージサブシステム1618は、コンピュータシステム1600によって使用される情報およびデータを格納するためのリポジトリまたはデータストアを提供する。ストレージサブシステム1618は、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構成を格納するための有形の非一時的なコンピュータ読取り可能記憶媒体を提供する。処理サブシステム1604によって実行されると上述の機能を提供するソフトウェア(たとえばプログラム、コードモジュール、命令)が、ストレージサブシステム1618に格納されてもよい。ソフトウェアは、処理サブシステム1604の1つ以上の処理ユニットによって実行されてもよい。ストレージサブシステム1618はまた、本開示の教示に従って使用されるデータを格納するためのリポジトリを提供してもよい。
ストレージサブシステム1618は、揮発性および不揮発性メモリデバイスを含む1つ以上の非一時的メモリデバイスを含み得る。図16に示すように、ストレージサブシステム1618は、システムメモリ1610およびコンピュータ読取り可能記憶媒体1622を含む。システムメモリ1610は、プログラム実行中に命令およびデータを格納するための揮発性主ランダムアクセスメモリ(RAM)と、固定命令が格納される不揮発性読取り専用メモリ(ROM)またはフラッシュメモリとを含む、いくつかのメモリを含み得る。いくつかの実現例において、起動中などにコンピュータシステム1600内の要素間における情報の転送を助ける基本的なルーチンを含むベーシックインプット/アウトプットシステム(basic input/output system:BIOS)は、典型的には、ROMに格納されてもよい。典型的に、RAMは、処理サブシステム1604によって現在操作および実行されているデータおよび/またはプログラムモジュールを含む。いくつかの実現例において、システムメモリ1610は、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)などのような複数の異なるタイプのメモリを含み得る。
一例として、限定を伴うことなく、図16に示されるように、システムメモリ1610は、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム(RDBMS)などのような各種アプリケーションを含み得る、実行中のアプリケーションプログラム1612、プログラムデータ1614、およびオペレーティングシステム1616を、ロードしてもよい。一例として、オペレーティングシステム1616は、Microsoft Windows(登録商標)、Apple Macintosh(登録商標)および/またはLinuxオペレーティングシステム、市販されているさまざまなUNIX(登録商標)またはUNIX系オペレーティングシステム(さまざまなGNU/Linuxオペレーティングシステム、Google Chrome(登録商標)OSなどを含むがそれらに限定されない)、および/または、iOS(登録商標)、Windows(登録商標) Phone、Android(登録商標) OS、BlackBerry(登録商標) OS、Palm(登録商標) OSオペレーティングシステムのようなさまざまなバージョンのモバイルオペレーティングシステムなどを、含み得る。
コンピュータ読取り可能記憶媒体1622は、いくつかの実施形態の機能を提供するプログラミングおよびデータ構成を格納することができる。コンピュータ読取り可能記憶媒体1622は、コンピュータシステム1600のための、コンピュータ読取り可能命令、データ構造、プログラムモジュール、および他のデータのストレージを提供することができる。処理サブシステム1604によって実行されると上記機能を提供するソフトウェア(プログラム、コードモジュール、命令)は、ストレージサブシステム1618に格納されてもよい。一例として、コンピュータ読取り可能記憶媒体1622は、ハードディスクドライブ、磁気ディスクドライブ、CD ROM、DVD、Blu-Ray(登録商標)ディスクなどの光ディスクドライブ、またはその他の光学媒体のような不揮発性メモリを含み得る。コンピュータ読取り可能記憶媒体1622は、Zip(登録商標)ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス(USB)フラッシュドライブ、セキュアデジタル(SD)カード、DVDディスク、デジタルビデオテープなどを含んでもよいが、それらに限定されない。コンピュータ読取り可能記憶媒体1622は、フラッシュメモリベースのSSD、エンタープライズフラッシュドライブ、ソリッドステートROMなどのような不揮発性メモリに基づくソリッドステートドライブ(SSD)、ソリッドステートRAM、ダイナミックRAM、スタティックRAMのような揮発性メモリに基づくSSD、DRAMベースのSSD、磁気抵抗RAM(MRAM)SSD、およびDRAMとフラッシュメモリベースのSSDとの組み合わせを使用するハイブリッドSSDも含み得る。
特定の実施形態において、ストレージサブシステム1618は、コンピュータ読取り可能記憶媒体1622にさらに接続可能なコンピュータ読取り可能記憶媒体リーダ1620も含み得る。リーダ1620は、ディスク、フラッシュドライブなどのようなメモリデバイスからデータを受け、読取るように構成されてもよい。
特定の実施形態において、コンピュータシステム1600は、処理およびメモリリソースの仮想化を含むがこれに限定されない仮想化技術をサポートし得る。たとえば、コンピュータシステム1600は、1つ以上の仮想マシンを実行するためのサポートを提供し得る。特定の実施形態において、コンピュータシステム1600は、仮想マシンの構成および管理を容易にするハイパーバイザなどのプログラムを実行し得る。各仮想マシンには、メモリ、演算(たとえばプロセッサ、コア)、I/O、およびネットワーキングリソースを割り当てられてもよい。各仮想マシンは通常、他の仮想マシンから独立して実行される。仮想マシンは、典型的には、コンピュータシステム1600によって実行される他の仮想マシンによって実行されるオペレーティングシステムと同じであり得るかまたは異なり得るそれ自体のオペレーティングシステムを実行する。したがって、潜在的に複数のオペレーティングシステムがコンピュータシステム1600によって同時に実行され得る。
通信サブシステム1624は、他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム1624は、他のシステムとコンピュータシステム1600との間のデータの送受のためのインターフェイスとして機能する。たとえば、通信サブシステム1624は、コンピュータシステム1600が、1つ以上のクライアントデバイスとの間で情報を送受信するために、インターネットを介して1つ以上のクライアントデバイスへの通信チャネルを確立することを可能にし得る。
通信サブシステム1624は、有線および/または無線通信プロトコルの両方をサポートし得る。たとえば、ある実施形態において、通信サブシステム1624は、(たとえば、セルラー電話技術、3G、4GもしくはEDGE(グローバル進化のための高速データレート)などの先進データネットワーク技術、WiFi(IEEE802.XXファミリー規格、もしくは他のモバイル通信技術、またはそれらのいずれかの組み合わせを用いて)無線音声および/またはデータネットワークにアクセスするための無線周波数(RF)送受信機コンポーネント、グローバルポジショニングシステム(GPS)受信機コンポーネント、および/または他のコンポーネントを含み得る。いくつかの実施形態において、通信サブシステム1624は、無線インターフェイスに加えてまたはその代わりに、有線ネットワーク接続(たとえばEthernet(登録商標))を提供することができる。
通信サブシステム1624は、さまざまな形式でデータを受信および送信することができる。たとえば、いくつかの実施形態において、通信サブシステム1624は、他の形式に加えて、構造化データフィードおよび/または非構造化データフィード1626、イベントストリーム1628、イベントアップデート1630などの形式で入力通信を受信してもよい。たとえば、通信サブシステム1624は、ソーシャルメディアネットワークおよび/またはTwitter(登録商標)フィード、Facebook(登録商標)アップデート、Rich Site Summary(RSS)フィードなどのウェブフィード、および/または1つ以上の第三者情報源からのリアルタイムアップデートなどのような他の通信サービスのユーザから、リアルタイムでデータフィード1626を受信(または送信)するように構成されてもよい。
特定の実施形態において、通信サブシステム1624は、連続データストリームの形式でデータを受信するように構成されてもよく、当該連続データストリームは、明確な終端を持たない、本来は連続的または無限であり得るリアルタイムイベントのイベントストリーム1628および/またはイベントアップデート1630を含んでもよい。連続データを生成するアプリケーションの例としては、たとえば、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール(たとえばネットワークモニタリングおよびトラフィック管理アプリケーション)、クリックストリーム解析ツール、自動車交通モニタリングなどを挙げることができる。
通信サブシステム1624は、コンピュータシステム1600からのデータを他のコンピュータシステムまたはネットワークに伝えるように構成されてもよい。このデータは、構造化および/または非構造化データフィード1626、イベントストリーム1628、イベントアップデート1630などのような各種異なる形式で、コンピュータシステム1600に結合された1つ以上のストリーミングデータソースコンピュータと通信し得る1つ以上のデータベースに、伝えられてもよい。
コンピュータシステム1600は、ハンドヘルドポータブルデバイス(たとえばiPhone(登録商標)セルラーフォン、iPad(登録商標)コンピューティングタブレット、PDA)、ウェアラブルデバイス(たとえばGoogle Glass(登録商標)ヘッドマウントディスプレイ)、パーソナルコンピュータ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、さまざまなタイプのうちの1つであればよい。コンピュータおよびネットワークの性質が常に変化しているため、図16に示されるコンピュータシステム1600の記載は、具体的な例として意図されているに過ぎない。図16に示されるシステムよりも多くのコンポーネントまたは少ないコンポーネントを有するその他多くの構成が可能である。当業者であれば、本明細書における開示および教示に基づいて、さまざまな実施形態を実現するための他の態様および/または方法を認識するだろう。
特定の実施形態について説明したが、さまざまな変形、変更、代替構成、および均等物が可能である。たとえば、いくつかの例をSQLクエリを用いて説明してきたが、これは限定するよう意図したものではない。代替的な実施形態では、本明細書中に記載される教示は、SQLクエリ以外のクエリにも適用することができる。実施形態は、特定のデータ処理環境内の動作に限定されず、複数のデータ処理環境内で自由に動作させることができる。さらに、実施形態を特定の一連のトランザクションおよびステップを使用して説明したが、これが限定を意図しているのではないことは当業者には明らかであるはずである。いくつかのフローチャートは動作を逐次的プロセスとして説明しているが、これらの動作のうちの多くは並列または同時に実行できる。加えて、動作の順序を再指定してもよい。プロセスは図に含まれない追加のステップを有し得る。上記実施形態の各種特徴および局面は、個別に使用されてもよく、またはともに使用されてもよい。
さらに、特定の実施形態をハードウェアとソフトウェアとの特定の組み合わせを用いて説明してきたが、ハードウェアとソフトウェアとの他の組み合わせも可能であることが理解されるはずである。特定の実施形態は、ハードウェアでのみ、またはソフトウェアでのみ、またはそれらの組み合わせを用いて実現されてもよい。本明細書に記載されたさまざまなプロセスは、同じプロセッサまたは任意の組み合わせの異なるプロセッサ上で実現できる。
デバイス、システム、コンポーネントまたはモジュールが特定の動作または機能を実行するように構成されると記載されている場合、そのような構成は、たとえば、動作を実行するように電子回路を設計することにより、動作を実行するようにプログラミング可能な電子回路(マイクロプロセッサなど)をプログラミングすることにより、たとえば、非一時的なメモリ媒体に格納されたコードもしくは命令またはそれらの任意の組み合わせを実行するようにプログラミングされたコンピュータ命令もしくはコード、またはプロセッサもしくはコアを実行するなどにより、達成され得る。プロセスは、プロセス間通信のための従来の技術を含むがこれに限定されないさまざまな技術を使用して通信することができ、異なる対のプロセスは異なる技術を使用してもよく、同じ対のプロセスは異なる時間に異なる技術を使用してもよい。
本開示では具体的な詳細を示すことにより実施形態が十分に理解されるようにしている。しかしながら、実施形態はこれらの具体的な詳細がなくとも実施し得るものである。たとえば、周知の回路、プロセス、アルゴリズム、構造、および技術は、実施形態が曖昧にならないようにするために不必要な詳細事項なしで示している。本明細書は例示的な実施形態のみを提供し、他の実施形態の範囲、適用可能性、または構成を限定するよう意図されたものではない。むしろ、実施形態の上記説明は、各種実施形態を実現することを可能にする説明を当業者に提供する。要素の機能および構成の範囲内でさまざまな変更が可能である。
したがって、明細書および図面は、限定的な意味ではなく例示的なものとみなされるべきである。しかしながら、請求項に記載されているより広範な精神および範囲から逸脱することなく、追加、削減、削除、ならびに他の修正および変更がこれらになされ得ることは明らかであろう。このように、具体的な実施形態を説明してきたが、これらは限定を意図するものではない。さまざまな変形例および同等例は添付の特許請求の範囲内にある。