JP2016509294A - 分散型データベースクエリ・エンジン用のシステムおよび方法 - Google Patents

Abstract

低レイテンシのデータベース・クエリ処理を実行することができるシステム用の技術を本明細書に開示する。システムは、ゲートウェイ・サーバおよび複数のワーカ・ノードを含む。ゲートウェイ・サーバは、複数のデータ・ノードを有する分散型ストレージ・クラスタに記憶されているデータを格納しているデータベースに対して、データベース・クエリを複数の部分クエリに分割し、複数の中間結果に基づきクエリ結果を構築するように構成されている。複数のワーカ・ノードの各ワーカ・ノードは、複数の部分クエリのそれぞれの部分クエリを、分散型ストレージ・クラスタの少なくとも１つのデータ・ノード上に記憶されているそれぞれの部分クエリに関係しているデータを走査することによって処理するように、かつ、ワーカ・ノードのメモリに記憶されている複数の近似の中間結果を生成するように構成されている。

Description

本発明は、一般にデータベースに関し、低クエリ・レイテンシ・データベース分析用の分散型データベースクエリ・エンジンに関する。

コンピュータおよびネットワーク技術における発展によって、大量のデータ・ストレージを必要とするアプリケーションが出現している。例えば、何千万ものユーザが、ウェブ・ページを作成したり、ソーシャル・メディア・ウェブサイトにイメージおよびテキストをアップロードしたりすることができる。結果として、ソーシャル・メディア・ウェブサイトは、毎日大量のデータを蓄積し、したがって、データを記憶および処理するために高度にスケーラブルなシステムを必要とする。様々なツールが、そうしたマスデータ・ストレージを可能とするために存在する。アプリケーションが何千ものコンピュータ（ノードとも呼ばれる）や数ペタバイトのデータのクラスタと対話することを可能とすることによって大規模なデータ集約的分散型アプリケーションをサポートする、フレームワークが存在する。例えば、Ｈａｄｏｏｐと呼ばれるフレームワークは、Ｈａｄｏｏｐ分散型ファイルシステム（ＨＤＦＳ）と呼ばれる分散型、スケーラブル、かつポータブルなファイルシステムを利用して、Ｈａｄｏｏｐクラスタ中のデータ・ノード（スレーブ・ノードとも呼ばれる）間に大量のデータを分散させる。データ・ノードの停電またはネットワーク障害（スイッチ故障を含む）の悪影響を減少させるため、ＨＤＦＳにおけるデータは、典型的には、様々なデータ・ノード上に複製される。

Ｈｉｖｅ（オープン・ソースのデータ・ウェアハウス・システム）は、Ｈａｄｏｏｐクラスタ上で動作するように開発された。クエリ言語（ＳＱＬ）により表現されるＨｉｖｅサポート・データ・クエリは、ＨｉｖｅＱＬと呼ばれる宣言型言語に似ている。Ｈｉｖｅシステムは、次いで、ＨｉｖｅＱＬにより表現されているクエリをＨａｄｏｏｐクラスタ上で実行可能なマップ縮小（ｍａｐ ｒｅｄｕｃｅ）ジョブにコンパイルする（有向非巡回グラフの数学形式による）。ＨｉｖｅＱＬ言語は、プリミティブ型と、配列およびマップなどのコレクションと、ネストされたコンポジションのタイプとを格納しているテーブルをサポートする、タイプ・システムを含む。加えて、Ｈｉｖｅシステムは、スキームおよび統計を格納するシステム・カタログ（Ｈｉｖｅ Ｍｅｔａｓｔｏｒｅと呼ばれる）を含み、これはデータの探査（ｅｘｐｌｏｒａｔｉｏｎ）およびクエリの最適化に有用である。

Ｈａｄｏｏｐクラスタと結合されると、Ｈｉｖｅシステムは、ソーシャル・ネットワーキング・システムの大量のデータを記憶して分析することが可能である。例えば、Ｈｉｖｅシステムは、ユーザがソーシャル・ネットワーキング・システム上でフォローするストーリのランクを決定するべく、ユーザ間のつながりの程度を分析することが可能である。Ｈｉｖｅシステムは、ソーシャル・ネットワーキング・システムのサービスがアプリケーション開発者、アドミニストレータ、および広告主が開発および経営判断を行うのを助けるためにどのように用いられているかに関する洞察を得るべく、アクティビティ・ログを分析することが可能である。Ｈｉｖｅシステムは、ソーシャル・ネットワーキング・システムのユーザに対し示される広告を最適化する複雑なデータ・マイニング・プログラムを動作させることができる。Ｈｉｖｅシステムは、さらに、ソーシャル・ネットワーキング・システムのスパムおよび中傷（ａｂｕｓｅ）を識別するべく、利用ログを分析する。

Ｈｉｖｅシステムは、プログラミング能力を有しない人が、複雑なデータ・パイプラインの承認、デバッグ、およびスケジューリングを行うため、またＨｉｖｅシステムおよび
他のリレーショナル・データベース（ＭｙＳＱＬおよびＯｒａｃｌｅなど）に記憶されているデータに基づく報告を生成するべくＨｉｖｅクエリを承認および実行するためのウェブ・ベースのツールを含む。

しかしながら、Ｈｉｖｅシステム用のクエリ・レイテンシは通常では大きい。大量のデータおよびＨａｄｏｏｐクラスタのマップ縮小スキームのため、最も単純なクエリであっても、完了には数秒から数分を要する。これは特に、対話型分析において、オペレータが一連のクエリのうちの次のクエリを決定するために現在のクエリの結果を必要とするときに問題である。レイテンシの問題は、アナリストの生産性に著しく影響する（アナリストは、現在のクエリの結果を待機する場合、次のクエリを決定することができないので）。

１つの可能な代替のソリューションは、Ｈｉｖｅからの集約データを、ＭｙＳＱＬおよびＯｒａｃｌｅなど、他のタイプのリレーショナル・データベース管理システム（ＲＤＢＭＳ）にロードするデータ・パイプラインを作成することである。次いで、オペレータは、対話型分析を行い、それらのＲＤＢＭＳを用いて報告を作成（ビルド）する。しかしながら、各ＲＤＢＭＳは、個別のデータ・パイプラインを必要とする。また、データ・パイプラインがＨｉｖｅから他のＲＤＢＭＳまで集約データを転送するのにも時間を要する。したがって、この代替の処理は、依然として厄介かつ不便である。

本明細書において導入される技術は、システム・カタログ（例えば、Ｈｉｖｅメタストア）にメタデータを記憶する大規模ストレージ・クラスタ（例えば、Ｈａｄｏｏｐクラスタ）に記憶されている極めて大量のデータに対する低レイテンシのクエリという利点を提供する。特に、本明細書において導入される技術は、サービング（ｓｅｒｖｉｎｇ）木計算フレームワークに基づく分散型クエリ・エンジンを含む。分散型クエリ・エンジンは、ゲートウェイ・サーバおよび複数のワーク・ノードを含む。ゲートウェイ・サーバは、１つのクエリ・タスクを部分タスクに分割する。エンジンの各ワーカ・ノードは、部分タスクを扱い、メモリにおける中間のクエリ結果を生成する。中間のクエリ結果は、関連するデータの一部を走査することによって生成される近似の中間結果となることができる。ゲートウェイ・サーバは、この中間のクエリ結果を受信し、その中間のクエリ結果に基づきクエリ・タスクに対するクエリ結果を構築する。

本明細書において導入される技術により、したがって、データベースに対するデータベース・クエリを処理するためのシステムが提供される。システムは、ゲートウェイ・サーバおよび複数のワーカ・ノードを含む。ゲートウェイ・サーバは、複数のデータ・ノードを有する分散型ストレージ・クラスタに記憶されているデータを格納しているデータベースに対して、データベース・クエリを複数の部分クエリに分割し、複数の中間結果に基づきクエリ結果を構築するように構成されている。複数のワーカ・ノードの各ワーカ・ノードは、複数の部分クエリのそれぞれの部分クエリを、分散型ストレージ・クラスタの少なくとも１つのデータ・ノード上に記憶されているそれぞれの部分クエリに関係しているデータを走査することによって処理するように、かつ、ワーカ・ノードのメモリに記憶されている複数の近似の中間結果を生成するように構成されている。

本明細書において導入される技術では、Ｈａｄｏｏｐクラスタなど大規模ストレージ・クラスタに記憶されているデータの大きな集約に対し、低レイテンシのクエリ処理を行うことができる。これは特に、対話型の分析において有益である（オペレータは、次のクエリの決定を完了するために現在のクエリの結果を待機する必要がないので）。この分散型クエリ・システムは、関連するデータの一部を走査することによって、さらに近似の結果
を生成することができる。システムのオペレータは、一連のクエリの有効性をテストするために、関連するデータの全集合に対して一連のクエリを処理する前に、その一連のクエリのラッピッド・プロトタイプを受信することができる。

本発明による実施形態は、システム、記憶媒体、および方法に係る添付の特許請求の範囲により特に開示されており、１つのクレーム・カテゴリー（例えば、システム）において言及される特徴は、別のクレーム・カテゴリ（例えば、方法）においても同様に請求される。

本発明の一実施形態では、システムは、複数のデータ・ノードを有する分散型ストレージ・クラスタに記憶されているデータを格納しているデータベースに対するデータベース・クエリから複数の部分クエリを生成するように、かつ、複数の中間結果に基づきクエリ結果を構築するように構成されているゲートウェイ・サーバと、複数のワーカ・ノードとを備え、前記複数のワーカ・ノードの各ワーカ・ノードは、前記複数の部分クエリのそれぞれの部分クエリを、前記それぞれの部分クエリに関係し前記分散型ストレージ・クラスタの少なくとも１つのデータ・ノード上に記憶されているデータを走査することによって処理するように構成されており、前記複数のワーカ・ノードの各ワーカ・ノードは、そのワーカ・ノードのメモリに記憶されている前記複数の中間結果のうちの１つの中間結果を生成するようにさらに構成されている。

前記複数のワーカ・ノードの各ワーカ・ノードは、前記複数の部分クエリの前記それぞれの部分クエリを、前記分散型ストレージ・クラスタの前記少なくとも１つのデータ・ノード上に記憶されている前記それぞれの部分クエリに関係している前記データの一部を走査することによって処理するように、かつ、ワーカ・ノードの前記メモリに記憶されている近似の中間結果を生成するようにさらに構成され得る。

前記ゲートウェイ・サーバは、少なくとも１つの近似の中間結果に基づき近似のクエリ結果を構築するようにさらに構成され得る。
前記ゲートウェイ・サーバは、前記複数の中間結果の一部に基づき近似のクエリ結果を構築するようにもさらに構成され得る。

前記ゲートウェイ・サーバは、散在するワーカ・ノードを識別し、前記散在するワーカ・ノードに割り当てられている部分クエリを複数の下位の部分クエリにさらに分割し、前記複数の下位の部分クエリを前記複数のワーカ・ノードの一部に割り当てるように、またさらに構成され得、ここで、前記散在するワーカ・ノードは、前記ゲートウェイ・サーバに進行割合を報告しないか、所定期間の後に所定値未満の前記進行割合を前記ゲートウェイ・サーバに報告するワーカ・ノードである。

前記複数のワーカ・ノードの各ワーカ・ノードは、前記分散型ストレージ・クラスタ内のそれぞれのデータ・ノードを動かすサービスであり得る。
システムは、前記データベースのテーブル・レベル・メタデータおよび前記分散型ストレージ・クラスタのファイル・レベル・メタデータをキャッシュするように構成されているメタデータ・キャッシュをさらに備え得る。

前記メタデータ・キャッシュは、前記データベース・クエリ用に以前のデータベース・クエリからキャッシュされたメタデータを保持するように構成され得る。
前記複数のワーカ・ノードの各ワーカ・ノードは、そのワーカ・ノードによる部分クエリ処理の状態を報告するために、前記ゲートウェイ・サーバにハートビート・メッセージを周期的に送ることが可能である。

前記ゲートウェイ・サーバは、近似のクエリ結果を返すかまたは前記データベース・クエリの処理を終了する命令をクライアント・デバイスから受け取るようにさらに構成され得る。

前記ゲートウェイ・サーバは、前記ワーカ・ノードに対し、近似の中間結果を直ちに返し、クライアント・デバイスに対する前記近似の中間結果に基づき、近似のクエリ結果を返すようにもさらに構成され得る。

前記データベース・クエリは、近似のクエリ結果の要求を含み得る。
前記クエリ結果は、前記クエリ結果について走査されたデータ・ノードに記憶されている関連するデータの一部を示す標識を伴うことが可能である。

前記データベースは、Ｈｉｖｅデータ・ウェアハウス・システムであり、前記分散型ストレージ・クラスタはＨａｄｏｏｐクラスタであり得る。
本発明のさらなる一実施形態では、方法は、本発明または上記において言及した実施形態のいずれかによるシステムを用いる。

本発明のさらなる一実施形態では、方法は、クライアント・デバイスから複数のデータ・ノードを有する分散型ストレージ・クラスタに記憶されているデータを格納しているデータベースに対するデータベース・クエリを受信する工程と、前記データベース・クエリを複数の部分クエリに分割する工程と、複数のワーカ・ノードのそれぞれのワーカ・ノードに前記部分クエリの各々を送信する工程であって、各ワーカ・ノードは前記分散型ストレージ・クラスタのデータ・ノード上で動くサービスである、部分クエリ送信工程と、前記ワーカ・ノードから前記部分クエリに対する複数の中間結果を取り出す工程であって、各中間結果は前記ワーカ・ノードのそれぞれのワーカ・ノードが該それぞれのワーカ・ノードが動いているデータ・ノードに記憶されている関連するデータを走査することによって処理される、中間結果の取出工程と、前記複数の中間結果に基づきクエリ結果を生成する工程と、を備える。

方法は、前記クライアント・デバイスに前記クエリ結果および部分インジケータを返す工程であって、前記部分インジケータは、前記クエリ結果に対して走査された前記データ・ノードに記憶されている関連するデータの部分を示す工程をさらに含み得る。

方法は、また、前記ワーカ・ノードに対し近似のクエリ結果を直ちに返すように命令する工程をさらに含むことが可能であり、ここで、取出工程は、前記ワーカ・ノードから前記部分クエリに対する複数の近似の中間結果を取り出す工程であって、各近似の中間結果は前記ワーカ・ノードのそれぞれのワーカ・ノードが該それぞれのワーカ・ノードが動いているデータ・ノードに記憶されている関連するデータの一部を走査することによって処理される。

方法は、各部分クエリについて、前記部分クエリに関連するデータを記憶するデータ・ノードに関するメタデータを取り出す工程をさらに備えてもよく、送信する工程は、前記メタデータに基づき複数のワーカ・ノードのそれぞれのワーカ・ノードに前記部分クエリの各々を送信する工程を含む。

本発明のさらなる一実施形態（これも請求され得る）では、方法は、クライアント・デバイスから複数のデータ・ノードを有する分散型ストレージ・クラスタに記憶されているデータを格納しているデータベースに対するデータベース・クエリを受信する工程と、前記データベース・クエリを複数の部分クエリに分割する工程と、複数のワーカ・ノードのそれぞれのワーカ・ノードに前記部分クエリの各々を送信する工程であって、各ワーカ・
ノードは前記分散型ストレージ・クラスタのデータ・ノード上で動くサービスである、工程と、散在するワーカ・ノードを識別する工程と、前記散在するワーカ・ノードに割り当てられている部分クエリを複数の下位の部分クエリに分割し、前記複数の下位の部分クエリを前記複数のワーカ・ノードの一部に割り当てる工程と、前記ワーカ・ノードから前記部分クエリに対する複数の中間結果を取り出す工程であって、各中間結果は前記ワーカ・ノードのそれぞれのワーカ・ノードが該それぞれのワーカ・ノードが動いているデータ・ノードに記憶されている関連するデータを走査することによって処理される、中間結果の取出工程と、前記複数の中間結果に基づきクエリ結果を生成する工程と、を備える。

識別する工程は、前記ワーカ・ノードが周期的に送信するハートビート・メッセージを監視することによって散在するワーカ・ノードを識別する工程であって、前記散在するワーカ・ノードは、前記散在するワーカ・ノードからのハートビート・メッセージが所定期間のあいだ受信されないとき、あるいは前記散在するワーカ・ノードから、前記散在するワーカ・ノードによる部分クエリ処理の状態を表す、閾値未満である数を含むハートビート・メッセージが受信されるときに識別される、工程を含み得る。

本発明のさらなる一実施形態（これも請求され得る）では、１つ以上の非一時的なコンピュータ可読記憶媒体はソフトウェアを具現し、該ソフトウェアは実行時、本発明または上記において言及した実施形態のいずれかによるシステムにおいて実行するように構成されている。

分散型クエリ・エンジンを作成可能なＨａｄｏｏｐクラスタの一例を示す図。 ＭａｐＲｅｄｕｃｅタスクを管理するＪｏｂＴｒａｃｋｅｒを有するＨａｄｏｏｐクラスタの一例を示す図。 分散型クエリ・エンジン、Ｈａｄｏｏｐ分散型ファイルシステム（ＨＤＦＳ）、Ｈｉｖｅデータ・ウェアハウス、およびストレージ・クラスタの間の関係を示す図。 一例の分散型クエリ・エンジンの高位ブロック図。 散在するワーカ・ノードを識別し、さらに部分クエリを分割するサンプル処理を示す図。 データベース・クエリの近似処理を行うためのサンプル処理を示す図。 本明細書に記載の任意のクラスタ・ノードを表すコンピュータ・ノードのアーキテクチャの一例を示す高位ブロック図。

本明細書において導入される技術の他の態様は、添付の図面から、また以下の詳細な説明から明らかとなる。
本発明のこれらのおよび他の目的、特徴、および特性は、本出願の一部をなす添付の特許請求の範囲および図面とともに以下の詳細な説明の検討から、当業者には、より明らかとなるだろう。

本記載における「一実施形態」、「１つの実施形態」などに対する参照は、記載の特定の特徴、機能、または特性が本発明の少なくとも１つの実施形態に含まれることを意味する。本記載においてそうした句が見られる場合、必ずしもすべてが同じ実施形態を参照している訳でも、それらの句が相互に排他的である訳でもない。

現代のソーシャル・ネットワーキング・システムは、毎日大量のデータを蓄積し、したがって、データを記憶し分析するために高度にスケーラブルなシステムを必要とする。特に、大量のデータに対する効率的な対話型分析には、データ・クエリの処理に関し、低レ
イテンシで高速に応答する手法が必要である。本発明では、インメモリサービング木ベースの計算フレームワークを近似クエリ処理と組み合わせることによって可能となる分散型クエリ・エンジンを開示する。この分散型クエリ・エンジンは、さらなるインメモリ処理のために、クエリ・タスクを複数の部分タスクに分割し、部分タスクをワーカ・ノードに対し分散させる。この分散型クエリ・エンジンは、データの走査された部分に基づきワーカ・ノードに近似の中間結果を要求することによって、クエリ処理中の任意の時に近似の結果を生成することが可能である。従来のＨａｄｏｏｐクラスタのマップ縮小スキームと異なり、ワーカ・ノードは部分タスクを処理し、処理時間を減少させ全レイテンシを改良するべく、メモリに全中間結果を記憶する。中間結果（その元になるデータではなく）のみが結果の構築のために転送され、転送されるデータの量および転送時間を著しく減少させる。

一実施形態では、分散型クエリ・エンジンは、Ｈａｄｏｏｐ分散型ファイルシステム（ＨＤＦＳ）、Ｈｉｖｅデータ・ウェアハウス、およびＨｉｖｅメタストアを実行する、Ｈａｄｏｏｐクラスタの上に作成されることが可能である。分散型クエリ・エンジンは、Ｈｉｖｅのデータフォーマットおよびメタデータと互換性を有し、ＨｉｖｅＱＬ言語のサブセットをサポートすることができる。分散型クエリ・エンジンを用いるオペレータは、Ｈｉｖｅデータ・ウェアハウスによって管理されるデータにおける統計パターンを効率的に発見することができる。分散型クエリ・エンジンは、近似結果を生成備えるによって、一連のクエリの迅速な分析および迅速なプロトタイピングを行なうことができる。加えて、分散型クエリ・エンジンは、関連するデータ集合体（ａｇｇｒｅｇａｔｅ）全体を走査することによって、フル分析を実行することができる。

図１は、分散型クエリ・エンジンを作成可能なＨａｄｏｏｐクラスタの一例を示す。図１では、Ｈａｄｏｏｐクラスタ１００は、メタデータ・ノード１１０Ａと、複数のデータ・ノード１１０Ｂ、１１０Ｃ、１１０Ｄとを含む。それらのノードは、相互接続１２０を通じて互いに通信可能である。相互接続１２０は、例えばローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、都市内ネットワーク（ＭＡＮ）、インターネットなどのグローバル・エリア・ネットワーク、ファイバ・チャンネル・ファブリック、またはそうした相互接続の任意の組み合わせであってよい。幾つかの実施形態では、相互接続１２０は、ＴＣＰ／ＩＰを含むネットワーク・プロトコル下のノード間におけるデータの処理及びルーティング用のネットワーク・スイッチを含むことが可能である。クライアント１３０Ａおよび１３０Ｂは、ネットワーク１４０（例えば、インターネット、ＬＡＮ、他のタイプのネットワークまたはネットワークの組み合わせ）を介してＨａｄｏｏｐクラスタ１００と通信を行ってもよい。クライアントの各々は、例えば、従来のパーソナルコンピュータ（ＰＣ）、サーバ・クラス・コンピュータ、ワークステーション、ハンドヘルド計算／通信装置であってよい。幾つかの実施形態では、Ｈａｄｏｏｐクラスタは、コモディティ・クラス・サーバの１つ以上のラックを用いて実装される。

ファイルおよびデータは、Ｈａｄｏｏｐ分散型ファイルシステム（ＨＤＦＳ）においてＨａｄｏｏｐクラスタ１００の複数のノードを通じて分散して記憶される。クライアント１３０Ａおよび１３０Ｂを含むクラスタ１００のクライアントに対し、ＨＤＦＳは従来の階層的ファイルシステムの機能を提供する。ファイルおよびファイルのデータ・ブロックが、ＨＤＦＳにおいて作成、削除、または移動されることが可能である。ＨＤＦＳ内にメタデータ・サービス（ファイルシステムの名前空間を維持し外部クライアントによるアクセスを制御することを含む）を提供するべくメタデータ・ノード１１０Ａ上で動作中のネーム・ノード（ＮａｍｅＮｏｄｅ）サービス１５０が存在する。ＮａｍｅＮｏｄｅサービスは、メタデータ・ノードにおいてＦｓイメージ（ＦｓＩｍａｇｅ）と呼ばれるファイル１６０にファイルシステム・インデックス（ファイルおよびファイルシステム・プロパティに対するブロックのマッピングを含む）を記憶することが可能である。幾つかの実施形
態では、第２のＮａｍｅＮｏｄｅサービスを動作させている第２のメタデータ・ノードが存在してもよい。この第２のメタデータ・ノードは、メタデータ・ノードが故障する場合、バックアップとして働く。

各データ・ノード１１０は、ＨＤＦＳのためのファイルを記憶することを担う。ＨＤＦＳに記憶されているファイルは、サブセット（本明細書では「ブロック」と呼ぶ）に分割される。一実施形態では、ブロックのサイズは６４ＭＢである。ブロックは、通常、複数のデータ・ノードに複製される。したがって、Ｈａｄｏｏｐクラスタ１００におけるＨＤＦＳは、必須ではないが、データ信頼性を達成するために従来のＲＡＩＤアーキテクチャを用いることが可能である。ファイル動作は、メタデータ・ノード１１０Ａ上で動作するＮａｍｅＮｏｄｅサービス１５０によって制御される。幾つかの実施形態では、データ・ノード１１０Ｂ、１１０Ｃ、１１０Ｄはラックに編成され、そこですべてのノードがネットワーク・スイッチを介して接続される。１つのラック内のノード間のネットワーク速度は、異なるラックのノード間のネットワーク速度より高速になり得る。Ｈａｄｏｏｐクラスタは、タスクを割り当てる際、この事実を考慮してもよい。ＤａｔａＮｏｄｅサービス１７０は、ブロックの読取および書込要求に応答するために各データ・ノード上で動作する。ＤａｔａＮｏｄｅサービス１７０は、また、ブロックの作成、削除、および複製を行うため、メタデータ・ノードからの要求に応答する。

幾つかの実施形態では、データ・ノード１１０Ｂ、１１０Ｃ、１１０Ｄは、メタデータ・ノード１１０Ａに対し、ブロック報告を含む定期的なハートビート・メッセージを送信する。メタデータ・ノード１１０Ａは、この定期ブロック報告を用いて、そのブロック・マッピングおよび他のファイルシステム・メタデータを有効とする。

クライアント１３０Ａまたは１３０ＢがＨａｄｏｏｐクラスタ１００にファイルを書き込もうとするとき、クライアントはメタデータ・ノード１１０Ａにファイル生成要求を送信する。メタデータ・ノード１１０Ａは、１つ以上の割り当てられたデータ・ノードの識別子とファイルのブロックの宛先ロケーションとを有するクライアントに応答する。クライアントは、割り当てられたデータ・ノードに対し、ファイルのデータ・ブロックを送信し、したがって、クラスタは、１つ以上のデータ・ノード上のデータ・ブロックを複製することが可能である。全てのブロックが送信されると、メタデータ・ノードは、そのメタデータ（そのＦｓＩｍａｇｅファイルを含む）にファイル生成を記録する。

Ｈａｄｏｏｐクラスタは、ＭａｐＲｅｄｕｃｅと呼ばれるフレームワークに基づく並列データ処理エンジンとして働く。Ｈａｄｏｏｐクラスタは、ＭａｐＲｅｄｕｃｅ機能を実装するためにＪｏｂＴｒａｃｋｅｒを含む。図２に示されているように、ＪｏｂＴｒａｃｋｅｒは、Ｈａｄｏｏｐクラスタ２００内に専用サーバ（ジョブ・トラッカ（ＪｏｂＴｒａｃｋｅｒ）ノード２１０Ａ）として実装されることが可能である。Ｈａｄｏｏｐクラスタ２００は、スイッチ２２６を介して相互接続されている２つのラック２４２および２４４を含む。ラック２４２は、ラック２４２以内のノードを相互接続するために、ＪｏｂＴｒａｃｋｅｒノード２１０Ａ、メタデータ・ノード２１０Ｂ、データ・ノード２１０Ｃ、２１０Ｄ、およびスイッチ２２２を含む。ラック２４４は、ラック２４２内のノードを相互接続するために、データ・ノード２１０Ｅ、２１０Ｈ、およびスイッチ２２４を含む。他の幾つかの実施形態では、ＪｏｂＴｒａｃｋｅｒは、同じメタデータ・ノードをＮａｍｅＮｏｄｅサービスと共有するサービスとして実装可能である。メタデータ・ノード２１０Ｂ（名前ノードとも呼ばれる）は追跡のためにＮａｍｅＮｏｄｅサービスを動作させ、クラスタを通じてデータが保持される。ＪｏｂＴｒａｃｋｅｒノード２１０Ａ（ＭａｐＲｅｄｕｃｅジョブ制御の専用）は、クライアント２３０から要求を受信してＭａｐＲｅｄｕｃｅジョブを起動させる。ＭａｐＲｅｄｕｃｅジョブ（ＭａｐＲｅｄｕｃｅアプリケーションまたはＭａｐＲｅｄｕｃｅタスクとも呼ばれる）がＪｏｂＴｒａｃｋｅｒ２１０Ａ
に対し提出されると、ＪｏｂＴｒａｃｋｅｒ２１０Ａは、ジョブ用のＨＤＦＳにおいて、入出力ファイル、ディレクトリ、またはその両方を識別する。ＭａｐＲｅｄｕｃｅタスク用の入力ファイルは、ＭａｐＲｅｄｕｃｅタスクのための入力データを格納している複数の入力ファイル・ブロックを含むことが可能である。ＪｏｂＴｒａｃｋｅｒ２１０Ａは、いくつの従タスクが作成されるか決定するために、入力ファイル・ブロック（ブロックの物理量およびどこにブロックが位置するのか）についての知識を用いる。ＭａｐＲｅｄｕｃｅアプリケーションは、入力ファイル・ブロックが存在する処理ノード毎にコピーされる。各割り当てられた処理ノードについて、ＪｏｂＴｒａｃｋｅｒ２１０Ａは少なくとも１つの従タスクを作成する。各割り当てられた処理ノード上で、ＴａｓｋＴｒａｃｋｅｒサービスは、そのノード上の従タスクの状態を監視し、状態および中間物出力をＪｏｂＴｒａｃｋｅｒに報告する。Ｈａｄｏｏｐクラスタ２００は、ファイル・ブロックについての知識に基づき従タスクを分配する。したがって、処理ロケーションにストレージを移動させることに代えて、Ｈａｄｏｏｐクラスタは処理タスクをストレージ・ロケーションに移動させる。

ノード２１０Ａ−２１０Ｈは図２において単一のユニットとして示されているが、各ノードが分散型アーキテクチャを有することも可能である。例えば、ノードは、複数のコンピュータの組み合わせとして設計可能であり、それら複数のコンピュータは互いから物理的に離れていてもよく、また物理的な相互接続を通じて互いと通信を行ってもよい。そのようなアーキテクチャでは、相互接続を通じて互いと通信を行うことが可能なコンピュータを配備することなどによって、簡便なスケーリングが可能となる。

一実施形態では、分散型クエリ・エンジンは、Ｈａｄｏｏｐ分散型ファイルシステム（ＨＤＦＳ）、およびＨｉｖｅデータ・ウェアハウスを実行する、Ｈａｄｏｏｐクラスタの上に作成される。図３は、分散型クエリ・エンジン３００、Ｈｉｖｅデータ・ウェアハウス、ＨＤＦＳ、およびストレージ・クラスタの間の関係を示す。分散型クエリ・エンジン３００は、Ｈｉｖｅデータ・ウェアハウスおよびＨＤＦＳの上に作成され、これが今度はストレージ・クラスタにより動作する。Ｈａｄｏｏｐクラスタ３１０は、大量のデータの記憶を担う複数のノード３１２を含む。Ｈａｄｏｏｐクラスタ３１０は、さらにメタデータ・ノード３１４を含む。Ｈａｄｏｏｐ分散型ファイルシステム（ＨＤＦＳ）３２０は、ノード３１２の間におけるデータの分配および管理を行うべくＨａｄｏｏｐクラスタ３１０上で動作する。データ・ノード（ＤａｔａＮｏｄｅ）サービス３２２は、ノード３１２におけるローカル・データ・ストアを管理するべくノード３１２上で動作する。データおよびファイルはブロックに分割され、Ｈａｄｏｏｐクラスタ３１０のノード３１２に記憶される。ＮａｍｅＮｏｄｅサービス３２４は、Ｈａｄｏｏｐクラスタ内にメタデータ・サービス（ファイルシステムの名前空間を維持し外部クライアントによってアクセスを制御することを含む）を提供するべく、メタデータ・ノード３１４上で動作する。

Ｈｉｖｅデータ・ウェアハウス・システム３３０は、Ｈａｄｏｏｐクラスタ３１０およびＨＤＦＳ３２０の上に作成される。Ｈｉｖｅデータ・ウェアハウス・システム３３０は、データベース・インターフェースとして働く。Ｈｉｖｅデータ・ウェアハウス・システム３３０は、ＳＱＬに似た宣言型言語、ＨｉｖｅＱＬにより表現されるデータ・クエリをサポートする。Ｈｉｖｅシステム用のデータベース・クエリを処理するＨａｄｏｏｐクラスタのマップ縮小スキームに依存することに代えて、中止のクエリ・エンジンは、データベース・クエリを並列に処理するために複数のワーカ・ノード３４２を含む。分散型クエリ・エンジン３００は、さらにゲートウェイ３４８を含む。一実施形態では、ワーカ・ノード３４２は、Ｈａｄｏｏｐクラスタ３１０のノード３１２上で動作するサービスとして実装される。別の実施形態では、ワーカ・ノード３４２は、Ｈａｄｏｏｐクラスタ３１０のノード３１２に相互連結される専用サーバとして実装される。

幾つかの実施形態では、ワーカ・ノード３４２は、ＨｉｖｅＱＬにより表現される部分タスクをＨＤＦＳ３２０のＤａｔａＮｏｄｅサービス３２２が実行可能な命令へとコンパイルすることを担う。

分散型クエリ・エンジンは、クライアントからクエリ・タスクを受信し、このクエリ・タスクを複数の部分タスクに分割する。図４は、一例の分散型クエリ・エンジン４００の高位ブロック図を示す。分散型クエリ・エンジン４００のオペレータは、クライアント４８０の入力インタフェース４８６を介してクエリ・タスクを提供することが可能である。一実施形態では、入力インタフェース４８６は、コマンドライン・インタフェース４８２およびグラフィック・インタフェース４８４の両方を含んでいる。コマンドライン・インタフェース４８２を用いると、オペレータは、データベース・クエリ言語（ＳＱＬまたはＨｉｖｅＱＬなど）により直接表現されるプログラムとして、クエリ・タスクを提供することが可能である。グラフィック・インタフェース４８４を用いることによって、オペレータは４８４のグラフィック・インタフェース要素を用いることによって、クエリ・タスクを提供することが可能である。一実施形態では、グラフィック・インタフェース４８４は入力ウェブ・ページとして実装される。オペレータは、入力ウェブ・ページ上の要素と対話し、オプションを選択し、入力データを投入することによって、クエリ・タスクを提供することが可能である。グラフィック・インタフェース４８４は、オペレータの選択および入力をデータベース・クエリ言語により表現される対応するプログラムに翻訳することが可能である。入力インタフェース４８６は、コマンドライン・インタフェース４８２またはグラフィック・インタフェース４８４のいずれかから受信されたプログラムを、クエリ・タスクとして分散型クエリ・エンジン４００のゲートウェイ４１０に送信する。

ゲートウェイ４１０は、クライアント４８０からクエリ・タスクを受信し、このクエリ・タスクのパースを行う。ゲートウェイ４１０は、クエリ・タスクに基づきＨｉｖｅメタストア４４０に問い合わせを送信する。Ｈｉｖｅメタストア４４０は、クエリ・タスクが動作することを必要とするデータについて、データテーブル・メタデータとＨＤＦＳファイル識別とを、ゲートウェイ４１０に返す。次いで、ゲートウェイ４１０は、ＨＤＦＳファイル識別に基づき、ＨＤＦＳ ＮａｍｅＮｏｄｅ４６０から対応するＨＤＦＳブロックのロケーションを取り出す。

一実施形態では、ゲートウェイ４１０は、対応するＨＤＦＳブロックに基づき、クエリ・タスクを複数の部分クエリに分割する。ゲートウェイ４１０は、対応するＨＤＦＳブロック内の１つのＨＤＦＳブロックにおいて実行される個々の部分クエリを割り当てる。他の実施形態では、当業者によって想到され得るように、ゲートウェイ４１０は、他の方法によりクエリ・タスクを部分クエリに分割することが可能である。

ゲートウェイ４１０は、ローカル処理のために、ワーカ４１２に部分クエリの各々を送る。一実施形態では、ワーカ４１２は、Ｈｉｖｅテーブル・データを記憶するＨａｄｏｏｐクラスタ上にオーバレイされる。各ワーク４１２は、Ｈａｄｏｏｐクラスタ・ノード４３２上のサービスとして動作する。部分クエリは、各ワーカ４１２が、その特定のワーカ４１２が動作させるノード４３２上の処理データ・ストアに対する部分クエリを担うように、生成される。ワーカ４１２は、そのワーカ４１２と同じクラスタ・ノード４３２上で動作するＤａｔａＮｏｄｅサービス４２２と直接連絡を行う。ワーカ４１２は、単一のクラスタ・ノード４３２内のデータを要求することによって、部分クエリについて低レイテンシのデータ読取を達成することができる。

クラスタ・ノード４３２は、サービスの実装を行うために、リモート・プロシージャ・コール（ＲＰＣ）フレームワークを用いることが可能である。例えば、一実施形態では、クラスタ・ノード４３２は、ワーカ・サービス４１２を高度にスケーラブルかつ高性能の
サーバサービスとして定義および作成するために、Ａｐａｃｈｅ Ｔｈｒｉｆｔフレームワークなど、ＲＰＣフレームワークを用いる。

一実施形態では、ワーカ・ノード３４２は、Ｈａｄｏｏｐクラスタ３１０のノード３１２上で動作するサービスとして実装される。別の実施形態では、ワーカ・ノード３４２は、Ｈａｄｏｏｐクラスタ３１０のノード３１２に相互連結される専用サーバとして実装される。

ワーカ４１２は、ゲートウェイ４１０に周期的に状態更新（「ハートビート」と呼ばれる）を返して、部分クエリ処理のプロセスを示す。一実施形態では、ハートビートを返すことを止めるか、すなわち、進行を示さない、割り当てられたワーカが存在する場合、ゲートウェイ４１０は、そのワーカが故障しているので、その部分クエリを別のワーカに再スケジューリグする、と決定する。各ワーカ４１２は、１つ以上のクラスタ・ノード４３２上に記憶されているそれぞれの部分クエリに関係するデータを走査し、その部分クエリについての中間結果を生成する。一実施形態では、ワーカ４１２は、そのワーカ４１２が動作するクラスタ・ノードのメモリにおいて部分クエリを完全に処理する。ワーカ４１２は、そのメモリに中間結果を記憶する。部分クエリの処理の終わりに、ワーカ４１２は中間結果をゲートウェイ４１０に送る。幾つかの実施形態では、ワーカ４１２は、Ａｐａｃｈｅ Ｔｈｒｉｆｔ呼出など、ＲＰＣ呼出を介して中間結果を送る。

ゲートウェイ４１０は、ワーカ４１２から中間結果をすべて受信し、中間結果をクエリ・タスクのための答えとしてのクエリ結果へと組み合わせる。次いで、ゲートウェイ４１０は、クエリ結果をクライアント４８０に返す。一実施形態では、クライアント４８０は随意でディスプレイ構成要素にクエリ結果を表示する。

ＭｅｔａＣａｃｈｅ（メタ・キャッシュ）４１４は、Ｈｉｖｅテーブル・レベルおよびＨＤＦＳファイル・レベル・メタデータの両方をキャッシュしてクエリ・レイテンシを減少させるべく、ゲートウェイ４１０上で動作する。幾つかの実施形態では、ＭｅｔａＣａｃｈｅ４１４は、ゲートウェイ４１０に相互接続されているスタンドアロン・サーバとして実装されることが可能である。ＭｅｔａＣａｃｈｅ４１４は、以前のクエリからのキャッシュされているデータを保持することができる。例えば、オペレータがＨｉｖｅテーブルのデータを対話的に分析している場合、そのオペレータは同じＨｉｖｅテーブル上で複数の連続するクエリを動作させる。以前のクエリからのキャッシュされているデータを保護することによって、ＭｅｔａＣａｃｈｅ４１４は、Ｈｉｖｅメタストア４４０およびＨＤＦＳ ＮａｍｅＮｏｄｅ４６０からメタデータを反復的にフェッチするのではなく、キャッシュされているメタデータを再使用することができる。

ＭｅｔａＣａｃｈｅ４１４のキャッシュ・ヒット率は高いが、これは典型的なＨｉｖｅテーブルにおけるデータは一度書き込まれると、さらなる変更なしに何度も読み取られるからである。一実施形態では、ＭｅｔａＣａｃｈｅ４１４は、Ｈｉｖｅシステムの監査ログのリアル・タイム・フィードを取り出し、Ｈｉｖｅシステムにおけるパーティション用のキャッシュされているデータにおけるエントリ（Ｈｉｖｅクエリまたは他の操作によって変更されている場合がある）を無効とすることができる。別の実施形態では、ＭｅｔａＣａｃｈｅ４１４は、所定の期間（例えば、１時間）のあいだ、クエリが行われていないキャッシュされているデータにおけるエントリを自動的に除去する。そうする際、ＭｅｔａＣａｃｈｅ４１４は、メモリ利用における任意の増大を防止し、キャッシュ・エラーを最小化する。

ワーカ４１２が動作する各クラスタ・ノード４３２の仕事量は異なり得る。また、クラスタ・ノード４３２およびワーカ・サービス４１２は、様々な理由で故障し得る。ゲート
ウェイ４１０が妥当な期間に大多数のワーカ４１２から中間結果を受信することが可能である一方、ノードまたはサービスの故障または遅延により中間結果を送達できないワーカ４１２が存在する。これらのワーカは、部分クエリの分配から所定時間後に所定のパーセンテージ未満の進行速度を報告するか、または単にゲートウェイ４１０に進行を回答しない。それらのワーカは散在するワーカであると識別される。ゲートウェイ４１０は、散在するワーカを識別すると、部分クエリの割当を取り消すために、散在するワーカにメッセージを送る。散在するワーカが中間結果を送達しなかった各々の未完成の部分クエリについて、ゲートウェイ４１０は、部分クエリを複数の下位の部分クエリにさらに分割し、この下位の部分クエリを一部のワーカ４１２に割り当てる。一実施形態では、ゲートウェイ４１０は、ワーカ４１２の現在の仕事量に基づき下位の部分クエリの割当を決定する。他の実施形態では、ゲートウェイ４１０は、当業者によって想定され得るように、他の方法により割当を決定することができる。この追加の並行化処理は、未完了の部分クエリの再試行のスピードを上げ、したがって散在するワーカによって引き起こされるクエリ・レイテンシを減少させる。

図５は、散在するワーカ・ノードを識別し、さらに部分クエリを分割するためのサンプル処理を示す。工程５０２にて、分散型クエリ・エンジンのゲートウェイは、複数のデータ・ノードを有する分散型ストレージ・クラスタに記憶されているデータを格納するデータベースについて、データベース・クエリをクライアント・デバイスから受信する。工程５０４では、ゲートウェイはデータベース・クエリを複数の部分クエリに分割する。その後、工程５０６では、ゲートウェイは、複数のワーカ・ノードのそれぞれのワーカ・ノードに部分クエリの各々を送る。各ワーカ・ノードは、分散型ストレージ・クラスタのデータ・ノード上で動作するサービスであることが可能である。

工程５０８にて、ゲートウェイ・サーバは散在するワーカ・ノードを識別する。ゲートウェイは、散在するワーカ・ノードに割り当てられている部分クエリを複数の下位の部分クエリに分割し、この複数の下位の部分クエリを複数のワーカ・ノードの一部に割り当てる。一実施形態では、ゲートウェイは、ワーカ・ノードが周期的に送るハートビート・メッセージを監視することによって散在するワーカ・ノードを識別する。散在するワーカ・ノードは、その散在するワーカ・ノードからのハートビート・メッセージが所定期間のあいだ受信されないときに識別される。別の実施形態では、散在するワーカ・ノードは、その散在するワーカ・ノードからのハートビート・メッセージが受信されるときに識別される。このハートビート・メッセージは、散在するワーカ・ノードによる部分クエリ処理の状態を表す、閾値未満である数を含む。

工程５１０では、ゲートウェイは、ワーカ・ノードから部分クエリに対する複数の中間結果を取り出す。各中間結果は、それらのワーカ・ノードのそれぞれのワーカ・ノードが該それぞれのワーカ・ノードが動作しているデータ・ノードに記憶されている関連するデータを走査することによって処理される。工程５１２では、ゲートウェイは、複数の中間結果に基づきクエリ結果を生成する。

一実施形態では、分散型クエリ・エンジンは、Ｈｉｖｅシステムのデータフォーマットおよびメタデータと互換性を有し、ＨｉｖｅＱＬ言語のサブセットまたは完全セットをサポートすることができる。また、ＨｉｖｅＱＬはＳＱＬに類似している宣言型言語である。ＨｉｖｅＱＬは、ＳＱＬの標準に厳密に従う必要がなく、ＳＱＬでは元々は規定されていない拡張を提供する。例えば、分散型クエリ・エンジンは、フィルタ、アグリゲート、トップｋ、百分位数、ＦＲＯＭ節による下位クエリ、ＵＮＩＯＮ ＡＬＬ、およびユーザ定義関数をサポートすることができる。

一実施形態では、分散型クエリ・エンジンのサポートするＴＡＢＬＥＳＡＭＰＬＥ節は
、走査される入力データの量を明示的に制限するために用いられる。別の実施形態では、分散型クエリ・エンジンのサポートするＷＩＴＨ節は、同じクエリにおいて複数回用いられるである複雑な表現について変数を宣言することによって、オペレータがより読みやすいクエリを書くことを可能とする。また、ＷＩＴＨ節では、実行中に共通する下位表現をオプティマイザが一度だけ評価するように、オペレータがオプティマイザに対してヒントを指定するための手段を提供することができる。

幾つかの実施形態では、クエリ処理全体が完了される前に、分散型クエリ・エンジンは近似のクエリ結果を供給することができる。分散型クエリ・エンジンは、最初のクエリ入力から所定期間後に、またはクエリの処理が所定条件（例えば、ある数のワーカが失敗する）を満たす場合に、自動的に近似のクエリ結果を供給することができる。また、分散型クエリ・エンジンは、オペレータ命令に応じて近似のクエリ結果を供給することができる。例えば、クエリ結果を待機しているオペレータは、Ｃｔｒｌ−Ｃを入力し、クエリ処理を止めるように分散型クエリ・エンジンに命令することができる。この命令を受け取ると、分散型クエリ・エンジンはクエリ処理を止め、近似のクエリ結果を返す。一実施形態では、分散型クエリ・エンジンは、さらにパーセンテージ・インジケータを供給し、近似のクエリ結果について走査されたデータのパーセンテージを示す。一実施形態では、分散型クエリ・エンジンは近似のクエリ結果を返し、正確なクエリ結果（すなわち、１００％のパーセンテージ・インジケータを有する）のためのクエリ処理を継続する。

特に、クエリがデータの書込または変更ではなくデータの探査を行うには、近似のクエリ結果はオペレータの分析には十分であることがある。実行時のエラー（ノード故障、入力データの損傷、さらにはユーザによる自信のクエリの消去など）は、すべての入力データが走査されてはいない状況として扱うことができる。故障がある場合、分散型クエリ・エンジンは、単にエラー・メッセージを返すのではなく、それまでの部分クエリの処理に基づき即座に近似のクエリ結果を返すことができる。一実施形態では、分散型クエリ・エンジンは、パーセンテージ・インジケータとともに近似のクエリ結果を返す。

別の実施形態では、オペレータは、さらに正確なクエリ結果が必要であることを自信のクエリ・タスクにおいて指定することができる。この場合、クエリ処理が失敗するときには、実行時エラーを返すことができる。

分散型クエリ・エンジンは、アグリゲーションに対しワンパス・アルゴリズムを用いて、すべての中間結果をメモリに記憶する。中間結果および最終クエリ結果のサイズは、比較的小さくなり得る。分散型クエリ・エンジンが近似のクエリ結果を返す能力によって、さらにサイズが低減される。例えば、クエリが指定されたカラム（例えば、ＯＲＤＥＲ ＢＹ節）によってデータ・レコードをソートするものである場合、分散型クエリ・エンジンは、関連するデータ・レコードの一部の走査のみをワーカに行わせることによって、近似の答えを生成することができる。同様に、分散型クエリ・エンジンは、クエリのタイプ（別個のエントリを数える、百分位数を計算するなど）について近似の答えを生成することもできる。

例えば、一実施形態では、分散型クエリ・エンジンのオペレータは、データ・レコードの特定のセットからのカントリー・カラムの別個の値の数のカウントを命令するクエリ・タスクを入力することができる。分散型クエリ・エンジンは、このクエリを受信し、クエリを部分クエリに分割し、それらの部分クエリを処理するためにワーカを割り当てる。この時から２０秒後、分散型クエリ・エンジンはタスクを開始し、オペレータは、クライアント・デバイスのキーボード上でＣＴＲＬ−Ｃを押下することによってタスクを終了させる。終了命令を受け取ると、分散型クエリ・エンジンは、近似の中間結果を返すよう、割り当てられたワーカに直ちに命令し、次いで、割り当てられたワーカは、それらの近似の
中間結果を組み合わせることによって近似の結果を返す。この近似の結果は、オペレータのクライアント・デバイスに返される。クライアント・デバイスは、総処理時間、用いられるワーカの数、走査されたデータ・レコードの行、走査されたデータの量、正確な結果のために走査されるデータの量、走査されたデータのパーセンテージ、および／または故障の数に関する情報を、さらに受信することができる。

別の実施形態では、分散型クエリ・エンジンは、故障の数が所定の閾値を超えた後、自動的に近似のクエリ結果を返すことができる。さらに別の実施形態では、オペレータは、正確な結果が必要であることをクエリ・タスクにおいて指定する。分散型クエリ・エンジンは、割り当てられたワーカによって関連するデータ・レコードがすべて走査されるまで処理を維持することになる。正確なクエリ結果をオペレータのユーザデバイスに返すことができる。クライアント・デバイスは、総処理時間、用いられるワーカの数、走査されたデータ・レコードの行、走査されたデータの量、走査されたデータのパーセンテージ（すなわち、１００％）、および／または故障の数に関する情報をさらに受信することができる。

図６は、データベース・クエリの近似処理を行うためのサンプル処理を示す。工程６０２にて、分散型クエリ・エンジンのゲートウェイは、複数のデータ・ノードを有する分散型ストレージ・クラスタに記憶されているデータベースについて、データベース・クエリをクライアント・デバイスから受信する。工程６０４では、ゲートウェイはデータベース・クエリを複数の部分クエリに分割する。その後、工程６０６では、ゲートウェイは、複数のワーカ・ノードのそれぞれのワーカ・ノードに部分クエリの各々を送る。各ワーカ・ノードは、分散型ストレージ・クラスタのデータ・ノード上で動作するサービスであることが可能である。工程６０８では、部分クエリを送った後、ゲートウェイは、近似のクエリ結果を直ちに返すようにワーカ・ノードに命令することができる。一実施形態では、近似のクエリ結果を直ちに返すとは、非常に短い期間（１秒など）内に結果を返すことを意味する。この命令は、様々なイベントをトリガとしてもよい。例えば、ゲートウェイは、クライアント・デバイスからデータベース・クエリの処理を終了する命令を受け取ってもよく、あるいはゲートウェイは、所定期間後に正確なクエリ結果が利用可能でない場合、近似のクエリ結果を自動的に返すと決定してもよい。したがって、近似の結果は、クライアント・デバイスによって手動で要求されてもよく、ユーザの介入なしで分散型クエリ・エンジンによって自動的にトリガが行われてもよい。

工程６１０では、近似の中間結果のための命令の後、ゲートウェイは、ワーカ・ノードから部分クエリに対する複数の中間結果を取り出す。各近似の中間結果はワーカ・ノードのそれぞれのワーカ・ノードが該それぞれのワーカ・ノードが動いているデータ・ノードに記憶されている関連するデータの一部を走査することによって処理される。近似の中間結果を受け取ると、工程６１２では、ゲートウェイは、複数の近似の中間結果に基づき近似のクエリ結果を生成する。次いで工程６１４では、分散型クエリ・エンジンのゲートウェイは近似のクエリ結果を返す。一実施形態では、近似のクエリ結果はパーセンテージ・インジケータとともにクライアント・デバイスに対し返される。パーセンテージ・インジケータは、クエリ結果に対して走査されたデータ・ノードに記憶されている関連するデータのパーセンテージを示す。

上述において示した利点に加えて、本明細書において提示される技術には以下に説明するような利点が存在する。
分散型クエリ・エンジンは、Ｈｉｖｅシステムを単独で用いることによるクエリ・レイテンシと比べ、Ｈａｄｏｏｐクラスタなどのデータ・ストレージ・クラスタに記憶されているデータに対するクエリのレイテンシを著しく減少させる。分散型クエリ・エンジンのオペレータまたはユーザは、わずかな待機期間でアドホックな（ａｄ ｈｏｃ）クエリを
行うことができる。分散型クエリ・エンジンは、様々な状況において利用することができる。例えば、分散型クエリ・エンジンがない場合、オペレータまたはアナリストは、ＭｙＳＱＬまたはオラクルなどのデータベースにＨｉｖｅからのデータを明示的にロードし、次いで、ウェブ・ベースのデータ分析報告を動かすためにデータベースからデータをフェッチする必要がある。分散型クエリ・エンジンを用いると、オペレータは、Ｈｉｖｅシステムからデータを直接フェッチし、ウェブ・ベースのデータ分析報告を生成させることができる。

一実施形態では、オペレータがクエリ・タスクのオーサリングを行う（例えば、図４に示すグラフィック・インタフェース４８４を用いて）とき、分散型クエリ・エンジンは、データ・サンプルをフェッチして、グラフィック・インタフェース４８４上でデータのプレビューをオペレータに見せることができる。別の実施形態では、分散型クエリ・エンジンは、クエリ・レイテンシをさらに向上させるために、メモリにおいてポピュラーなデータセットのインデックスおよびピニングを行うことができる。

本明細書に提示される技術によって、データ・ストレージ・クラスタの上に作成可能な低レイテンシの分散型クエリ・エンジンが提供される。この分散型クエリ・エンジンは、Ｈｉｖｅシステムの既存のデータおよびメタデータと互換性を有することができる。この分散型クエリ・エンジンは、アドホック分析用の他のデータベース（例えば、ＭｙＳＱＬまたはオラクル）にデータをロードするパイプラインを必要とせずに、データ分析報告を行うために用いることができる。

図７は、本明細書に記載の任意のクラスタ・ノードを表すコンピュータ・ノードのアーキテクチャの一例を示す高位ブロック図である。ノード７００は、１つ以上のプロセッサ７１０と、相互接続７３０に結合されたメモリ７２０とを備える。図７に示される相互接続７３０は、１以上の任意の別個の物理バス、ポイント・ツー・ポイント接続、または適切なブリッジ、アダプタ、もしくはコントローラによって接続されたその両方を表す抽象的概念である。相互接続７３０は、したがって、例えば、システムバス、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスまたはＰＣＩ−Ｅｘｐｒｅｓｓバス、ハイパートランスポート（ＨｙｐｅｒＴｒａｎｓｐｏｒｔ）またはＩＳＡ（ｉｎｄｕｓｔｒｙ ｓｔａｎｄａｒｄ ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＳＣＳＩ（ｓｍａｌｌ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｉｎｔｅｒｆａｃｅ）バス、ＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）、ＩＩＣ（Ｉ２Ｃ）バス、または「ＦＩＲＥＷＩＲＥ（登録商標）」とも呼ばれるＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）標準１３９４バスを含んでもよい。

プロセッサ７１０は、ストレージ・コントローラ７００の中央処理装置（ＣＰＵ）であり、したがって、ノード７００の全動作を制御する。一定の実施形態では、プロセッサ７１０は、メモリ７２０に記憶されているソフトウェアまたはファームウェアを実行することによって、これを行う。プロセッサ７１０は、１以上のプログラマグル汎用または専用マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、プログラマブル・コントローラ、特定用途向けＩＣ（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）、ＴＰＭ（ｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ ｍｏｄｕｌｅ）など、またはそうしたデバイスの組み合わせであるか、またはそれらを含んでよい。

メモリ７２０は、ノード７００のメイン・メモリであるか、またはそれを含んでよい。メモリ７２０は、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、フラッシュ・メモリなど、またはそうしたデバイスの組み合わせであるか、またはそれらを含んでよい。使用時には、メモリ７２０は、本明細書に示される技術による命
令を含むコード７７０を格納してもよい。

また相互接続７３０を通じてプロセッサ７１０に接続されているのは、ネットワーク・アダプタ７４０およびストレージ・アダプタ７５０である。ネットワーク・アダプタ７４０は、ネットワークを通じてリモート・デバイスと通信を行う能力をノード７００に提供し、また、例えば、イーサネット（登録商標）・アダプタやファイバ・チャンネル・アダプタであってもよい。また、ネットワーク・アダプタ７４０は、クラスタ内の他のノードと通信を行う能力をノード７００に提供してもよい。幾つかの実施形態では、ノードは、クラスタの内外における通信を別個に扱う２以上のネットワーク・アダプタを用いてもよい。ストレージ・アダプタ７５０は、ノード７００が持続性のストレージにアクセスすることを可能とし、また、例えば、ファイバ・チャンネル・アダプタやＳＣＳＩアダプタであってもよい。

メモリ７２０に記憶されているコード７７０は、上述のアクションを実行するべくプロセッサ７１０をプログラムするためのソフトウェアおよび／またはファームウェアとして実装されてもよい。一定の実施形態では、そのようなソフトウェアまたはファームウェアは、最初にリモート・システムからノード７００を通じて（例えば、ネットワーク・アダプタ７４０を介して）ダウンロードされることによって、ノード７００に対し提供されてもよい。

本明細書に導入される技術は、例えば、ソフトウェアおよび／またはファームウェアによりプログラムされるプログラマブル回路（例えば、１以上のマイクロプロセッサ）によって、もしくは完全に特殊用途のハードワイヤード回路によって、またはそれらの形態の組み合わせによって、実装されることができる。特殊用途のハードワイヤードの回路は、例えば、１以上の特定用途向けＩＣ（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）の形態であってもよい。

本明細書に導入される技術を実装する際に使用されるソフトウェアまたはファームウェアは、機械可読記憶媒体上に記憶されてもよく、また１以上の汎用または特殊用途プログラマブル・マイクロプロセッサによって実行されてもよい。本明細書において用いられる用語「機械可読記憶媒体」は、機械によってアクセス可能な形態で情報を記憶可能な任意の機構を含む（機械は、例えば、コンピュータ、ネットワーク・デバイス、携帯電話、携帯情報端末（ＰＤＡ）、製造ツール、１以上のプロセッサを有する任意のデバイスなどであってよい）。例えば、機械アクセス可能記憶媒体は、記録可能／非記録可能な媒体（例えば、リード・オンリ・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイスなど）などを含む。

本明細書において用いられる用語「論理」は、例えば、特定のソフトウェアおよび／またはファームウェアによりプログラムされるプログラマブル回路、特殊用途のハードワイヤード回路、またはそれらの組み合わせを含んでよい。

上述の例に加えて、本発明の様々な他の修正および変更が本発明から逸脱することなく行われる。したがって、上述の開示は限定として見なされるものではなく、添付の特許請求の範囲は本発明の真の趣旨および全範囲を包含するものとして解釈されるものである。

Claims (19)

1. 複数のデータ・ノードを有する分散型ストレージ・クラスタに記憶されているデータを格納しているデータベースに対するデータベース・クエリから複数の部分クエリを生成するように、かつ、複数の中間結果に基づきクエリ結果を構築するように構成されているゲートウェイ・サーバと、
   複数のワーカ・ノードと、を備え、前記複数のワーカ・ノードの各ワーカ・ノードは、前記複数の部分クエリのそれぞれの部分クエリを、前記それぞれの部分クエリに関係し前記分散型ストレージ・クラスタの少なくとも１つのデータ・ノード上に記憶されているデータを走査することによって処理するように構成されており、前記複数のワーカ・ノードの各ワーカ・ノードは、そのワーカ・ノードのメモリに記憶されている前記複数の中間結果のうちの１つの中間結果を生成するようにさらに構成されている、システム。
2. 前記複数のワーカ・ノードの各ワーカ・ノードは、前記複数の部分クエリの前記それぞれの部分クエリを、前記分散型ストレージ・クラスタの前記少なくとも１つのデータ・ノード上に記憶されている前記それぞれの部分クエリに関係している前記データの一部を走査することによって処理するように、かつ、ワーカ・ノードの前記メモリに記憶されている近似の中間結果を生成するようにさらに構成されており、
   好適には、前記ゲートウェイ・サーバは、少なくとも１つの近似の中間結果に基づき近似のクエリ結果を構築するようにさらに構成されている、請求項１に記載のシステム。
3. 前記ゲートウェイ・サーバは、前記複数の中間結果の一部に基づき近似のクエリ結果を構築するようにさらに構成されている、請求項１または２に記載のシステム。
4. 前記ゲートウェイ・サーバは、散在するワーカ・ノードを識別し、前記散在するワーカ・ノードに割り当てられている部分クエリを複数の下位の部分クエリにさらに分割し、前記複数の下位の部分クエリを前記複数のワーカ・ノードの一部に割り当てるように、さらに構成されており、前記散在するワーカ・ノードは、前記ゲートウェイ・サーバに進行割合を報告しないか、所定期間の後に所定値未満の前記進行割合を前記ゲートウェイ・サーバに報告するワーカ・ノードである、請求項１〜３のいずれか一項に記載のシステム。
5. 前記複数のワーカ・ノードの各ワーカ・ノードは、前記分散型ストレージ・クラスタ内のそれぞれのデータ・ノードを動かすサービスである、請求項１〜４のいずれか一項に記載のシステム。
6. 前記データベースのテーブル・レベル・メタデータおよび前記分散型ストレージ・クラスタのファイル・レベル・メタデータをキャッシュするように構成されているメタデータ・キャッシュをさらに備え、好適には、前記メタデータ・キャッシュは、前記データベース・クエリ用に以前のデータベース・クエリからキャッシュされたメタデータを保持するように構成されている、請求項１〜５のいずれか一項に記載のシステム。
7. 前記複数のワーカ・ノードの各ワーカ・ノードは、そのワーカ・ノードによる部分クエリ処理の状態を報告するために、前記ゲートウェイ・サーバにハートビート・メッセージを周期的に送る、請求項１〜６のいずれか一項に記載のシステム。
8. 前記ゲートウェイ・サーバは、近似のクエリ結果を返すかまたは前記データベース・クエリの処理を終了する命令をクライアント・デバイスから受け取るようにさらに構成されている、請求項１〜７のいずれか一項に記載のシステム。
9. 前記ゲートウェイ・サーバは、前記ワーカ・ノードに対し、近似の中間結果を直ちに返
   し、クライアント・デバイスに対する前記近似の中間結果に基づき、近似のクエリ結果を返すようにさらに構成されている、請求項１〜８のいずれか一項に記載のシステム。
10. 前記データベース・クエリは、近似のクエリ結果の要求を含む、請求項１〜９のいずれか一項に記載のシステム。
11. 前記クエリ結果は、前記クエリ結果について走査されたデータ・ノードに記憶されている関連するデータの一部を示す標識を伴う、請求項１〜１０のいずれか一項に記載のシステム。
12. 前記データベースは、Ｈｉｖｅデータ・ウェアハウス・システムであり、前記分散型ストレージ・クラスタはＨａｄｏｏｐクラスタである、請求項１〜１１のいずれか一項に記載のシステム。
13. 請求項１〜１２のいずれか一項に記載のシステムを用いる方法。
14. クライアント・デバイスから複数のデータ・ノードを有する分散型ストレージ・クラスタに記憶されているデータを格納しているデータベースに対するデータベース・クエリを受信する工程と、
    前記データベース・クエリを複数の部分クエリに分割する工程と、
    複数のワーカ・ノードのそれぞれのワーカ・ノードに前記部分クエリの各々を送信する工程であって、各ワーカ・ノードは前記分散型ストレージ・クラスタのデータ・ノード上で動くサービスである、部分クエリ送信工程と、
    前記ワーカ・ノードから前記部分クエリに対する複数の中間結果を取り出す工程であって、各中間結果は前記ワーカ・ノードのそれぞれのワーカ・ノードが該それぞれのワーカ・ノードが動いているデータ・ノードに記憶されている関連するデータを走査することによって処理される、中間結果取出工程と、
    前記複数の中間結果に基づきクエリ結果を生成する工程と、を備える方法。
15. 前記クライアント・デバイスに前記クエリ結果および部分インジケータを返す工程であって、前記部分インジケータは、前記クエリ結果に対して走査された前記データ・ノードに記憶されている関連するデータの部分を示す、工程をさらに備える、請求項１４に記載の方法。
16. 前記ワーカ・ノードに対し近似のクエリ結果を直ちに返すように命令する工程をさらに備え、
    前記中間結果取出工程は、前記ワーカ・ノードから前記部分クエリに対する複数の近似の中間結果を取り出す工程であって、各近似の中間結果は前記ワーカ・ノードのそれぞれのワーカ・ノードが該それぞれのワーカ・ノードが動いているデータ・ノードに記憶されている関連するデータの一部を走査することによって処理される、工程をさらに備える、請求項１４に記載の方法。
17. 各部分クエリについて、前記部分クエリに関連するデータを記憶するデータ・ノードに関するメタデータを取り出す工程をさらに備え、
    前記部分クエリ送信工程は、前記メタデータに基づき複数のワーカ・ノードのそれぞれのワーカ・ノードに前記部分クエリの各々を送信する工程を含む、請求項１４に記載の方法。
18. クライアント・デバイスから複数のデータ・ノードを有する分散型ストレージ・クラスタに記憶されているデータを格納しているデータベースに対するデータベース・クエリを
    受信する工程と、
    前記データベース・クエリを複数の部分クエリに分割する工程と、
    複数のワーカ・ノードのそれぞれのワーカ・ノードに前記部分クエリの各々を送信する工程であって、各ワーカ・ノードは前記分散型ストレージ・クラスタのデータ・ノード上で動くサービスである、部分クエリ送信工程と、
    散在するワーカ・ノードを識別するワーカ・ノード識別工程と、
    前記散在するワーカ・ノードに割り当てられている部分クエリを複数の下位の部分クエリに分割し、前記複数の下位の部分クエリを前記複数のワーカ・ノードの一部に割り当てる工程と、
    前記ワーカ・ノードから前記部分クエリに対する複数の中間結果を取り出す工程であって、各中間結果は前記ワーカ・ノードのそれぞれのワーカ・ノードが該それぞれのワーカ・ノードが動いているデータ・ノードに記憶されている関連するデータを走査することによって処理される、中間結果取出工程と、
    前記複数の中間結果に基づきクエリ結果を生成する工程と、を備える方法。
19. ワーカ・ノード識別工程は、前記ワーカ・ノードが周期的に送信するハートビート・メッセージを監視することによって散在するワーカ・ノードを識別する工程であって、前記散在するワーカ・ノードは、前記散在するワーカ・ノードからのハートビート・メッセージが所定期間のあいだ受信されないとき、または、前記散在するワーカ・ノードから、前記散在するワーカ・ノードによる部分クエリ処理の状態を表す、閾値未満である数を含むハートビート・メッセージが受信されるときに識別される、工程と、を備える請求項１８に記載の方法。