JP5818394B2

JP5818394B2 - 大量データプラットフォームを操作するシステム及び方法

Info

Publication number: JP5818394B2
Application number: JP2014541254A
Authority: JP
Inventors: 貞之古橋; 裕誠芳川; 一樹太田
Original assignee: Treasure Data Inc
Current assignee: Treasure Data Inc
Priority date: 2011-11-10
Filing date: 2012-11-08
Publication date: 2015-11-18
Anticipated expiration: 2032-11-08
Also published as: JP2015501976A; WO2013070873A1; US20160246824A1; US9582528B2; US20130124483A1

Description

[関連出願のクロスリファレンス]
本出願は、２０１１年１１月１０日に出願された米国暫定特許出願第６１／５５８，３９５号の利益を請求する。この出願は、全体が参照により組み込まれている。

本出願は、一般的に、データ集約型分散システムフィールドに関し、特に、分散システムフィールドにおける大量データプラットフォームを操作する新規で有用なシステム及び方法に関する。

技術の開発は、取扱い可能なデータ量の増加をもたらした。このようなデータは、多くの有用なアプリケーションを有しており、多くの企業がそのデータを分析できるという利点がある。大規模データセットを扱うための特殊なシステムが開発されている。Ｈａｄｏｏｐは、ＭａｐＲｅｄｕｃｅを利用する大規模データセット用に設計されたプラットフォームの一例である。しかしながら、ウェブサイトやアプリケーションの多くは、大量のデータをうまく利用できるものとはかけ離れたシステム基盤の上に構築されている。Ｈａｄｏｏｐなどのプラットフォームをうまく利用するには、システムを新しいプラットフォーム用に設計し直さなければならない。このような基盤の変更は時間がかかり、費用が高い。更に、大規模データセット用に設計されたプラットフォームは、専門性が高く知識に精通した者を必要とする。既存のウェブサイトやアプリケーションを開発している人々のほとんどは、このようなスキルを持っていない。したがって、大規模データ集約型分散システムのフィールドでは、データ集約型基盤と一体化する新規で有用なシステムと方法を作ることが求められている。本発明は、このような新規かつ有用なシステムと方法を提供する。

図１は、本発明の好ましい実施例のシステムを表す図である。図２は、本発明の好ましい実施例のシステムの実装を示す例示的な図である。図３は、クライアントのアプリケーションを一体化したデータエージェントの一例を詳細に示す図である。図４は、リアルタイム及びアーカイブストレージに使用する列及び行フォーマットへのユーザデータの変換を示す図である。図５は、コマンドラインインターフェースの例示的サンプルを示す図である。図６は、本発明の好ましい実施例の方法を示す図である。図７は、本発明の好ましい実施例のリアルタイムストレージシステムとアーカイブストレージシステムに協調的に問い合わせを行う変形例を示す図である。

本発明の好ましい実施例についての以下の記載は、本発明をこれらの好ましい実施例に限定しようとするものではなく、当業者に本発明を作成して使用できるようにするものである。

１．大量データプラットフォームの操作システム
図１に示すように本発明の好ましい実施例の大量データプラットフォームを操作するシステム１００は、離散イベントチャネルと一体化したクライアントデータエージェント１１０と、遠隔分散型ストレージシステム１２０と、問い合わせ処理クラスタ１３０と、問い合わせインターフェース１４０を具える。遠隔分散ストレージシステムは、更に、リアルタイムストレージシステム１２２とアーカイブストレージシステム１２４を具える。このシステムは、あらゆる基盤にアプリケーションを構築できるように機能して、特殊かつ専門的な基盤のデータ処理能力から利益を得ている。このシステムは、クライアントのアプリケーションから独立して機能するので、大量のデータ処理の要求が、クライアントの単純なインターフェースに取り込まれる。このシステムは、好ましくは、分散した計算環境に配置した列ベースのアーカイブストレージシステム１２４とデータ集約型問い合わせ処理クラスタ１３０を使用して、拡張可能なシステム上で迅速なデータの相互作用を可能にしている。このシステムは、更に、マルチテナントサービスとして機能するように構成して、様々なクライアントがシステムを同時に使用できるようにしてもよい。様々なユーザのデータは、好ましくは安全に、他のユーザデータから隔離されたフォーマットで保管される。問い合わせ処理クラスタは、好ましくは、マルチテナント基盤のユーザが共用する。システム１００は、テラバイト、ペタバイト、あるいはより大きなデータサイズで測定されるデータセットなど、大量のデータセットに使用するのに適している。このシステムは、アプリケーションを操作するときに周期的に直面する一般的な分散された組織化されていないデータを使用し、このような組織化されていないデータを大量のデータセットから組織化されたデータに変換するときに利点がある。関連する利点として、このシステムは、既存のアプリケーションとデータソースを、大量データプラットフォームから容易にかつ有機的に利益を享受させることができる。このことは、大量のデータ処理について考慮することなく設計された既存のアプリケーションとデータソースにも当てはまる。言い換えれば、このシステムによって、伝統的なアプリケーションが、非伝統的なデータマネージメントツールを必要とするデータの分析から利益を享受することができる。図２に示すように、このシステムは、好ましくは、Ｈａｄｏｏｐと、いくつかのベースコンポーネントについてのクラウドホスティングサービスを利用して構築できる。このシステムは、代替的に、適宜のコンポーネントを具えていてもよく、あるいは適宜の基盤に構築することもできる。

好ましい実施例のクライアントデータエージェント１１０は、クライアントのシステムと一体化して、データの小部分を遠隔分散ストレージシステムに通信するように機能する。イベントチャネル又はインターフェースによって、ウェブサイト、アプリケーション、サービス、又は適宜のネットワークプログラムがイベントデータを供給することができる。クライアントデータ（例えば、イベントデータ）は、好ましくは分散イベントデータである。分散イベントデータは、好ましくは、イベントの時間、イベントの種類、及び／又は、適宜の追加イベント特性に関連性がある。イベントチャネルは、データベースログ、アプリケーションログ、システムログ、センサデータストリーム、ウエブコンテンツ、あるいは適宜のデータソースである。通常は、アプリケーションが、アプリケーションのユーザの行為に応じてクライアントデータを生成し、クライアントデータは、その行為の情報を含んでいる。好ましくは、クライアントデータは、複数のキー値対としてフォーマットされている。一連のクライアントデータは、好ましくは、行フォーマットに組織化されている。代替的に、クライアントデータは、適宜のフォーマットを有していてもよい。クライアントデータエージェント１１０は、好ましくは、テータ集約型基盤へのゲートウエイを提供するデーモンである。クライアントデータエージェントは、好ましくはプラグインである。例えば、クライアントデータエージェントは、ｒｕｂｙｇｅｍであってもよいが、代替的に、ウエブサービス、ライブラリィ、スクリプト、アプリケーションプログラミングインターフェース（ＡＰＩ）、又はクライアントシステムへのインターフェースとストレージシステム１２０への通信チャネルを有する適宜のエージェントであってもよい。更に、データエージェントは、図３に示すように、アプリケーションの複数部分に一体化することもできる。クライアントデータエージェント１１０は、好ましくは、ネットワーキングインターフェースを具えており、ストレージシステム１２０と周期的に通信する。クライアントデータエージェントは、更に、ストレージシステム１２０と通信を行う前にイベントデータを圧縮するよう機能するデータコンプレッサ１１２を具えていてもよい。データコンプレッサ１１２は、好ましくは、データバイナリ直列化回路であり、好ましくはデータをＭｅｓｓａｇｅＰａｃｋあるいは適宜のデータ交換フォーマットに変換する。ＭｅｓｓａｇｅＰａｃｋは、ＪＳＯＮのようなシンタックスを伴う小さくコンパクトなバイナリ直列化フォーマットである。更に、クライアントデータエージェント１１０は、クライアント、ユーザアカウント、あるいは遠隔ストレージシステムと通信するときはアプリケーションを認識するコンフィギュレーションを具えていてもよい。秘密鍵を用いてイベントデータを独自に認識し、イベントデータをマルチテナントシステムを使用している他のクライアントから区別するようにしてもよい。

クライアントデータエージェント１１０は、更に、プラグ可能なアーキテクチュアを具え、クライアントデータエージェント内で任意のデータソースを使用できるようにしてもよい。プラグ可能なアーキテクチュアは、好ましくは、入力プラグインインターフェースと、出力プラグインインターフェースを具える。入力プラグインインターフェースは、好ましくは、第３パーティのデベロッパあるいは適宜のエンティティからのプラグインを展開させて、適宜のソースからデータを引き出すように構成してもよい。例えば、入力プラグインは、特定のサイトからデータを引き出すように書き込むことができる。出力プラグインインターフェースは、好ましくは、第３パーティのデベロッパあるいは適宜のエンティティからのプラグインを展開させて、クライアントデータエージェントからのデータの出力をカスタマイズするように構成してもよい。出力プラグインは、データを転送し、データの送信をカスタマイズし、あるいはクライアントデータエージェント１１０の出力用にカスタマイズした機能を提供することができる。一実施例では、出力プラグインが、データユニット又は言語を変換できる。別の実施例では、出力プラグインを用いて、データを複数の宛先に送信することができる。

好ましい実施例の遠隔分散型ストレージシステム１２０は、イベントデータを記憶するよう機能する。分散型ストレージシステムに入ってくるイベントデータは、好ましくは分散しており（時間ベースのイベントで組織化されている）、実質的に組織化されていない。問い合わせ処理クラスタと組み合わせたストレージシステム１２０は、組織化された大量データの分析をシステムから出力させることができる。大量データは、テラバイトのデータ、ペタバイトのデータ、あるいは適宜のサイズより大きい特徴がある。一の例示的アプリケーションでは、大量データは、１０億回のウエブクリックを記憶している１テラバイトのデータより大きいとの特徴があるが、代替的に、適宜のサイズのデータで特徴づけてもよい。ストレージシステムは、好ましくは、Ａｍａｚｏｎ’ｓＳ３／ＥＣ２などの分散されたクラウドストレージシステムをホストとするものであるが、代替的に、適宜の基盤であってもよい。このデータは、好ましくは圧縮フォーマット（例えば、ＭｅｓｓａｇｅＰａｃｋフォーマット）で保存される。遠隔分散型ストレージシステムは、好ましくは、リアルタイム問い合わせと、大木バッチデータ問い合わせの両方のデータを記憶するように機能するが、代替的に、適宜の方法で、データを区分してグループ化してもよい。

遠隔分散型ストレージシステムは、好ましくは、リアルタイムストレージシステム１２２とアーカイブストレージシステム１２４を具える。遠隔分散型ストレージシステム１２０は、好ましくは、まず、クライアントデータエージェント１１０から送られてきた分散型データをリアルタイムストレージシステム１２２に記憶させて、時間的遅延の後、アーカイブストレージシステム１２４に記憶させるデータを、データコンバータが統合あるいは作成する。図４に示すように、リアルタイムストレージシステム１２２は、好ましくはクライアントデータを行データとして記憶して、アーカイブストレージシステム１２４は、好ましくは、どのデータを行データフォーマットで記憶する。データは、好ましくは、ＭａｐＲｅｄｕｃｅのジョブを用いて統合してコラムスタイルに変換する。行ファイルフォーマットは、新しい行を付加する、新しいキーを加えるのが容易であるという利点があり、データの書き込みに適している。列ファイルフォーマットは、不要なキーと値をスキップさせることができるという利点があり、一貫性があるため、圧縮しやすく、アーカイブと読取に適している。列データフォーマットは、更に、アーカイブストレージシステムの大量データセットを問い合わせる際に、最適化と効率化を提供することができる。システムが、マルチテナントアプリケーション用に実装されている場合は、アカウント識別子に応じてデータを更に記憶することができる。このデータは、更に暗号化する、あるいは適宜に保全することができる。様々なユーザについてのデータは、好ましくは、他の認証されていないユーザアカウントからのアクセスから切り離しておく。

好ましい実施例の問い合わせ処理クラスタ１３０は、問い合わせインターフェースを通じて通信された問い合わせ指示をデータ処理方法に変換する。問い合わせ指示に従って、リアルタイムデータ及び／又はアーカイブデータを処理することができる。問い合わせ処理クラスタ１３０は、好ましくは、Ａｍａｚｏｎ’ｓＥｌａｓｔｉｃＣｏｍｐｕｔｅＣｌｏｕｄなどの遠隔分散型計算基盤上に構成されている。問い合わせ処理クラスタ１３０は、好適に分散されたバーチャル又はフィジカルな複数の処理ユニットを適宜集めたおものでもよい。これらは同一場所に配置してもよいが、適宜のコンフィグレーションに配置してもよい。システムのマルチテナント実装においては、複数の異なるユーザアカウントからの問い合わせが、問い合わせ処理クラスタ１３０の共通リソース間に配置されていることが好ましい。問い合わせ処理クラスタ１３０は、Ｈａｄｏｏｐなどのデータ集約型処理クラスタであることが好ましい。データ集約型処理クラスタは、好ましくはデータマッピングと問い合わせデータの削減工程を実行するように構成されている。より好ましくは、問い合わせ処理クラスタ１３０は、ＭａｐＲｅｄｕｃｅ処理を実装したＨａｄｏｏｐクラスタである。単一の問い合わせ処理モジュールは、好ましくは、リアルタイムストレージシステム１２２とアーカイブストレージシステム１２４に問い合わせを行う。より好ましくは、問い合わせ処理クラスタ１３０の問い合わせ処理モジュールが、共働かつ統合してリアルタイムストレージシステム１２２とアーカイブストレージシステム１２４に問い合わせを行って、リアルタイムデータとアーカイブデータを取り入れて統一されたまとまった問い合わせ結果を返信する。

代替の実施例では、問い合わせ処理クラスタ１３０が、リアルタイム問い合わせモジュールとバッチ問い合わせモジュールと具えている。リアルタイム問い合わせモジュールは、リアルタイムストレージシステムに問い合わせを行って、時間関連の分析を提供することが好ましい。リアルタイム問い合わせモジュールは、問い合わせを行うためにリアルタイムで最適化したＨａｄｏｏｐベースを使用することができる。バッチ問い合わせモジュールは、アーカイブストレージシステム１２４に大量データの問い合わせを行うように機能する。バッチ問い合わせモジュールは、Ｈａｄｏｏｐ基盤を用いて、大量データでの作業を容易にしている。アーカイブストレージシステムは、問い合わせ処理に効率のよいフォーマットで大量のデータを提供するよう最適化されている。

好ましい実施例の問い合わせインターフェース１４０は、保存したデータにユーザアクセスを提供するよう機能する。問い合わせインターフェース１４０は、好ましくは、ユーザが使用して、クライアントデータエージェント１１０によって捕捉されたデータに関する情報を得るのに使用される。問い合わせインターフェース１４０は、情報をリクエストするのに使用できるが、データベースやテーブルを作る、重要データを作る、問い合わせをスケジューリングする、データ用スキームを設定する、あるいは適宜の動作を行うなど、データの相互作用に使用することもできる。問い合わせインターフェースは、ユーザの動作を取り入れて、好ましくはそのデータを問い合わせ処理クラスタ１３０に通信する。一変形例では、問い合わせインターフェースが、コマンドラインインターフェースである。コマンドラインインターフェースは、好ましくは、ユーザが、関連するデータベース様の問い合わせコマンドを発行して、データと相互作用することができる。コマンドラインインターフェースは、好ましくは、バックエンド基盤が大幅に異なっていたとしても、ＭｙＳＱＬなどの関連データベースと作用するインターフェースと同様になるようにモデル化されている。これは、データ集約型基盤（例えば、Ｈａｄｏｏｐ）に深い知識がないユーザでも、図５に示すような良く知られたコマンドを用いてデータの制御及び相互作用を行うことができるように機能する。第２の変形例では、問い合わせインターフェース１４０が、ウエブコンソールインターフェースである。ウエブコンソールは、好ましくは、グラフィカルユーザインターフェースを提供するウエブサイト又はアプリケーションである。データの視覚化、分析レポート、及び適宜のデータ表示フォームは、このようなインターフェースの一部であってもよい。第３の変形例では、問い合わせインターフェース１４０が、第３者アプリケーションによって使用されているＡＰＩである。第４の変形例では、問い合わせインターフェース１４０が、ビジネスインテリジェンスツールドライバであってもよい。例えば、ＪａｖａＤａｔａｂａｓｅＣｏｎｎｅｃｔｉｖｉｔｙ（ＪＤＢＣ）又は、ＯｐｅｎＤａｔａｂａｓｅＣｏｎｎｅｃｔｉｖｉｔｙ（ＯＤＢＣ）インターフェースは、ＪａｓｐｅｒＳｏｆｔ、Ｔａｂｌｅａｕ，Ｅｘｃｅｌ、Ｐｅｎｔａｈｏ、又は適宜のツールといった様々なビジネスインテリジェンスツールからアクセス可能である。上述の変形例のいずれか、あるいはその他の適宜の問い合わせインターフェースを、適宜組み合わせて使用することができる。

２．データ集約型基盤と一体化する方法
図６に示すように、好ましい実施例のデータ集約型基盤と一体化する方法には、離散したクライアントデータを読み出すステップＳ１１０と；遠隔ストレージシステムに離散したクライアントデータを保存するステップＳ１２０とを具え；このデータを保存するステップが、クライアントデータをリアルタイムストレージシステムに保存するステップＳ１２２と；列フォーマットのクライアントデータをアーカイブストレージシステムに保存するステップＳ１２４と；ユーザインターフェースを介してデータリクエストを受信するステップＳ１３０と；リアルタイムストレージシステムとアーカイブストレージシステムからのデータと選択的に更新するステップＳ１４０と；を具える。この方法は、いずれかの基盤に構築したアプリケーションが、大量データに特化した基盤のデータ処理能力から利益を受けられるように機能する。この方法は、好ましくは、列ベースで分散されたアーカイブストレージシステムとデータ集約型処理クラスタ（例えば、Ｈａｄｏｏｐ）を利用して、迅速かつ拡張可能なデータ分析及びサービスを提供する。この方法は、広範囲にわたるクライアントタイプの非組織化された分散イベント記録を取り、このデータを問い合わせ可能に組織化されたデータに変換する。この方法は、大量データアプリケーション（例えば、テラバイトより大きいデータセット、又は、いくつかのケースではペタバイト）に好ましく使用される。この方法は、データ処理サービスプロバイダに好ましく利用される。サービスプロバイダは、好ましくは、マルチテナント環境で複数クライアントがこの基盤を利用できるようにする。この方法は、好ましくは上述のシステムに実装されるが、代替的に適宜のシステムにこの方法を実装するようにしてもよい。

ステップＳ１１０は、離散したクライアントデータを読み出すステップを具えており、クライアントアプリケーションからクライアントデータの小片を受信するよう機能する。離散したクライアントデータは、好ましくはプラグイン、ライブラリ、あるいはアプリケーションプログラミングインターフェースによって回収され、クライアントアプリケーションと一体化する。クライアントデータは、好ましくは、クライアントデータのパラメータに関連する時間スタンプを具えるイベントデータである。クライアントデータは、好ましくは、分散ストレージシステムで受信される。より好ましくは、データ輸入モジュールが、アプリケーションプログラミングインターフェース（ＡＰＩ）を介してクライアントデータエージェントからデータを受信し、そのクライアントデータを適宜ストレージシステムに加える。クライアントアプリケーションと一体化したクライアントエージェントは、好ましくはデータソースからイベントを取り出し、より好ましくは、そのイベントはイベントが生じたときに取り出される。クライアントデータは、代替的に、適宜のデータフォームであってもよい。クライアントのアプリケーションは、このようなクライアントエージェントと、アプリケーションのシステムレベルを変更することなく、容易に一体化できることが好ましい。ＲｕｂｙｏｎＲａｉｌｓアプリケーションの場合は、データエージェントジェムを加えるステップと、スキームを特定するなど、いくつかの初期設定を実行するステップを具える。データエージェントは、したがって、適宜の情報を中継することができる。離散したクライアントデータを読み取るステップは、クライアントデータエージェントで、ログを読み取るステップ、アプリケーションの関連するデータベースを変換するステップ、イベント通知を受信するステップ、オンラインデータを読み取るステップ、センサデータを読み取るステップ、及び／又は、データを取得するための好適なアクションを実行するステップを具える。クライアントデータは、さらに、入力プラグインとインターフェースを取るようにしてもよい。入力プラグインは、適宜のフォームのデータを読み取るように構成されている。いくつかの場合、複数のソースを用いて、離散したクライアントデータを読み取っている。クライアントイベントデータは、保存するイベント又は対象を特徴づけている、キー値対データであることが好ましい。

更に、クライアントイベントデータを読み取るステップは、クライアントイベントデータを圧縮するステップを具えていてもよい。圧縮ステップは、好ましくは、イベントデータを直列化するステップを具え、このステップは、ヒトが読み取り可能なフォーマットから、ＪＳＯＮのようなフォーマットの読み取り可能なバイナリ直列化信号に変換するステップを具える。ＭｅｓｓａｇｅＰａｃｋライブラリは、一つの好適なデータ交換フォーマットである。データエージェントは、イベントデータをストレージシステムに通信する際に、データエージェントが更に通信をバッファに格納して、ストレージシステムのデータ輸入システムが過負荷にならないようにしてもよい。この方法は更に、動的クスキーマを可能にすることができる。動的スキーマは、データスキーマを機動的に設定できるように機能する。一つの利点は、クライアントデータのスキーマ情報が、データを加える間に不要であることである。一般的なスキーマは、デフォルトによってデータに適用することができる。データのスキーマは、データ問い合わせ要求とデータとの相互作用を介して更新され、連続的な問い合わせのパフォーマンスを強化することができる。

ステップＳ１２０は、離散したクライアントデータを遠隔ストレージシステムに保存するステップを具えており、アプリケーションからのデータを大量データに特化したシステムのストレージ基盤に転送するよう機能する。クライアントエージェントは、周期的にクライアントイベントデータをストレージシステムに通信することが好ましい。代替的に、クライアントエージェントは、連続的にクライアントイベントデータをストレージシステムに通信するようにしてもよい。上述したように、イベントデータは、通信用に圧縮フォーマットにしてもよい。ストレージシステムにイベントデータを保存するステップは、イベントデータを最適化した分析用に組織化できるようにするのが好ましい。クライアントデータは、時系列データとして保存するのが好ましい。このデータは、好ましくは、データ回収用、リアルタイムストレージシステムへの保存用、アーカイブストレージシステムへの保存用の時間スタンプ、あるいは適宜の時間スタンプを具えている。

二つの好ましいサブステップとして、クライアントイベントデータを保存するステップは、更に、クライアントイベントデータをリアルタイムストレージシステムに保存するステップＳ１２２と、列フォーマットのクライアントデータをアーカイブストレージシステムに保存するステップＳ１２４を具え、これらのステップがリアルタイムアプリケーションと、大量データアプリケーションに適したそれぞれのフォーマットのデータを保存するように機能する。ストレージシステムは、好ましくは最初にイベントデータをリアルタイムストレージシステムに保存する。好ましくは、時間的遅れの後に、データをリアルタイムストレージシステムからアーカイブストレージシステムに移動させる。これらの二つのサブストレージシステムに保存するステップにより、異なるアプリケーション用にデータをフォーマットすることができる。リアルタイムデータは、イベント全体を見るのにより多くの問い合わせがあるであろう。イベントデータは、好ましくは、そのデータに新しい行を加えるステップ、新しいキーを加えるステップを簡単にするとともに、好ましくは書き込みに適している。リアルタイムストレージに初めに保存するステップは、データが合わさるとき、あるいはアーカイブストレージに適した構造に変換されるときに、更に、バッファとして作用する。イベントデータは、好ましくは、ＭａｐＲｅｄｕｃｅフォーマットに変換されて、アーカイブイベントデータをバッチ問い合わせに対してよりアクセスしやすくするよう機能するアーカイブストレージシステムに保存される。ＭａｐＲｅｄｕｃｅフォーマットに変換するときに、イベントデータは、列フォーマットで保存することが好ましい。列フォーマットは、好ましくは、読取時に不要なキーと値をスキップさせる。列フォーマットは更に、改良された圧縮レートを有しており、アーカイブと読取に適している。ＭａｐＲｅｄｕｃｅフォーマットへの変換は、ストレージシステム内で行われ、クライアントが難しい変換処理を実行することを緩和することが好ましい。

ステップＳ１３０は、ユーザインターフェースを介してデータリクエストを受信するステップを具え、ユーザ又はシステムの意図を表示する指示を取得するよう機能する。データリクエストは、好ましくは、インターフェースを介して取得され、次いで、Ｈａｄｏｏｐクラスタなどの問い合わせ処理クラスタに通信する。データリクエストは、好ましくは、コマンドラインインターフェース、ウエブコンソール、ＡＰＩ、ビジネスインテリジェンスツールインターフェース、などのユーザインターフェースを介して、あるいは、適宜のメカニズムを介して通信される。好ましくは、データリクエストは、問い合わせリクエストであり、ストレージシステムからの対応する構成のデータの応答を要求する。代替的に、データリクエストは、データベースやテーブルを作成する、スキーマを設定する、データを相互に輸入する、あるいは適宜のアクションを実行するなどによって、保存したデータに変形を行うことを要求する指示であってもよい。一変形例では、データリクエストをコマンドラインインターフェースを介して受信し、このリクエストを更に、関連するデータベース様問い合わせコマンドフォーマットから、データストレージと問い合わせ処理クラスタに互換性のあるフォーマットに変換している。例えば、ＳＱＬ様データベースコマンドは、Ｈａｄｏｏｐとの使用に適したＭａｐＲｅｄｕｃｅに変換することが好ましい。別の変形例では、データリクエストをビジネスインテリジェンスツールインターフェースを介して受信している。ビジネスインテリジェンスツールインターフェースは、好ましくは、ＪａｖａＤａｔａｂａｓｅＣｏｎｎｅｃｔｉｖｉｔｙ（ＪＤＢＣ）又はＯｐｅｎＤａｔａｂａｓｅＣｏｎｎｅｃｔｉｖｉｔｙ（ＯＤＢＣ）用のドライバである。このようなビジネスインテリジェンスツールインターフェースは、好ましくは、ＪａｓｐｅｒＳｏｆｔ、Ｔａｂｌｅａｕ、Ｅｘｃｅｌ、Ｐｅｎｔａｈｏ、あるいは適宜のツールといった様々なビジネスインテリジェンスツールからのデータアクセスと相互作用を可能にしている。

ステップＳ１４０は、リアルタイムストレージシステムとアーカイブストレージシステムからのデータと選択的に相互作用するステップを具え、データリクエストを実行するよう機能する。データ問い合わせ用に、問い合わせ処理クラスタは、リアルタイムストレージシステム及び／又はアーカイブストレージシステムに選択的に問合せをすることが好ましい。問い合わせがリアルタイム情報に関するものである時は、リアルタイムストレージシステムに問い合わせを行うことが好ましい。問い合わせがバッチ問い合わせである場合は、アーカイブストレージシステムに問い合わせる。アーカイブストレージシステムのデータは、列フォーマットで保存されているため、好ましくは、より早く、より効率よく処理される。好ましくは問い合わせのメカニズムによって、列データセット全体の問い合わせとは対照的に、データの部分を選択的に問い合わせることができる。例えば、列フォーマットとアーカイブデータの時系列コンフィグレーションを利用すると、クライアントイベントデータポイントの単一パラメータに関する問い合わせについてのレンジ取得操作を、行フォーマットに構成したこのデータを取り出すより、実質的に早く効率よく取り出すことができる。システムは、代替的に、列データセットをすべて選択する。問い合わせ処理クラスタは、更に、問い合わせリクエストを分析して、問い合わせがあったデータを制限することができる。このような問い合わせの管理は、パフォーマンスの改良を提供でき、好ましい。データリクエストがスキーマの設定である変形例では、問い合わせ処理クラスタが、特定したスキーマを用いてデータを認可することができるため好ましい。更に、問い合わせ処理クラスタは、ユーザに送達するために、データを解凍できる。例えば、データがＭｅｓｓａｇｅＰａｃｋを用いて圧縮されている場合、データは好ましくはオリジナルフォーマットに変換される。さらに、データリクエストの結果あるいはサブ計算を将来のデータリクエスト用に得ることができる。この方法は、構成したデータを返送するステップを具えていてもよく、これは、データ問い合わせの結果を返送するよう機能する。データ結果は、好ましくは、データリクエストを作成するのに使用した問い合わせインターフェースを介して通信される。この結果は、情報画像、テーブルスタイルのデータとしてのテキストベースの結果概要、スプレッドシート、ｃｓｖ−データファイル、あるいは適宜のデータフォーマットで表すことができる。

データの問い合わせを行うに当たり、選択した相互作用が、好ましくは、リアルタイムストレージシステムとアーカイブストレージシステムに協力して問い合わせを行うステップを具え、これが、複数ストレージシステムに亘って問い合わせを分配し、単一のまとまった問い合わせ結果を引き出すように機能する。問い合わせ処理クラスタは、リアルタイムストレージシステムとアーカイブストレージシステムの様々なクライアントデータの時間スタンプを利用して、非冗長なクライアントデータを問い合わせる。クライアントデータがまとまっている、あるいはアーカイブストレージシステムに保存するよう構成されている場合は、マージステータス情報が、何のクライアントデータがアーカイブストレージシステムに加えられたのかを表示することが好ましい。マージステータス情報は、マージログ、最後のマージブロックの表示、あるいはリアルタイムストレージとアーカイブストレージの間のデータ冗長性を表示できる適宜のパラメータであってもよい。好ましくは、これがマージを完了した時間ブロック、マージの進捗状況、及び又はマージの待ち、のログである。問い合わせクラスタは、図７に示すように、スキップしたデータがその他のストレージシステムにおいて割合を占めるであろうと思われる場合、好ましくはマージステータス情報とクライアントデータの時間スタンプを用いて、リアルタイムストレージ又はアーカイブストレージのいずれかからのデータを適宜スキップする。

大体の実施例では、好ましくは、コンピュータで読み取り可能な指示を保存したコンピュータで読み取り可能な媒体に、上記方法を実装することが好ましい。この指示は、好ましくは、コンピュータで実行可能な要素で、この悪しくはデータエージェント、ストレージシステム、問い合わせ処理ユニット、及びインターフェースと一体化された要素によって実行される。コンピュータで読み取り可能な媒体は、ＲＡＭｓ、ＲＯＭｓ、フラッシュメモリ、ＥＥＰＲＯＭｓ、光デバイス（ＣＤ又はＤＶＤ）、ハードドライブ、フロッピィドライブ、又は適宜のデバイスなど、適宜のコンピュータで読み取り可能な媒体に記憶させることができる。コンピュータで実行可能な構成要素は、プロセッサであることが好ましいが、指示は適宜の専用ハードウエアデバイスで代替的にあるいは追加で実行することができる。

この分野の当業者は、上述の詳細な説明から、また図面及び請求の範囲から認識するように、特許請求の範囲に規定された本発明の範囲から外れることなく、変形及び変更を本発明の好適な実施例に行うことができる。

Claims

大量データプラットフォームを動作させる方法において：
当該方法が、コンピュータで読み取り可能な媒体に記憶された指示をコンピュータで実行可能な構成要素で実行することによって実施され、前記方法が、マルチテナントデータ分析プラットホームで、
離散したクライアントデータであって、独自の識別子を介して前記マルチテナントデータ分析プラットホームのユーザアカウントに関連するクライアントデータ、を受信するステップと；
ネットワークにアクセス可能な分散ストレージシステムに前記クライアントデータを保存するステップであって：
行フォーマットで前記クライアントデータをリアルタイムストレージシステムに保存するステップと；
前記クライアントデータを列ベースで分散したアーカイブストレージシステムに保存するステップであって、前記アーカイブデータストレージシステムに保存される前記クライアントデータが、前記クライアントデータに関連する前記ユーザアカウントに応じて分離される、ステップと；
を具えるステップと；
問い合わせインターフェースを介してデータ問い合わせを受信するステップと；
データマッピング処理と削減処理に従って前記リアルタイムストレージシステムとアーカイブストレージシステムからの前記クライアントデータと選択的にインターフェースを取ることによって前記データ問い合わせを処理するステップと；
を具えており、当該データ問い合わせを処理するステップが、
前記リアルタイムストレージシステムとアーカイブストレージシステムに協調的に問い合わせを行うステップと、
前記リアルタイムストレージシステムとアーカイブストレージシステムに亘って前記データ問い合わせを分散させて、単一のまとまった問い合わせ結果を引き出すステップと具えており、
前記クライアントデータを列ベースで分散したアーカイブストレージシステムに保存するステップが、
列フォーマットで前記アーカイブストレージシステムに前記クライアントデータを記憶するステップを具えており、
前記アーカイブストレージシステムからの前記クライアントデータとインターフェースを取ることが、
問い合わせ処理クラスタを用いることによって、前記マッピング処理と削減処理に前記データ問い合わせの少なくとも一部を変換するステップと、
前記問い合わせ処理クラスタを用いることによって、前記マッピング処理と削減処理を実行するステップと、
を具えることを特徴とする方法。
請求項１に記載の方法において、前記分散クライアントデータが動的スキーマで受信され保存されることを特徴とする方法。
請求項２に記載の方法において、前記データ問い合わせが、スキーマ定義を具え、前記クライアントデータと選択的にインターフェースを取るステップが、前記動的スキーマに前記スキーマ定義を適用するステップを具えることを特徴とする方法。
請求項１に記載の方法が更に、クライアントデータエージェントにおいて、クライアントデータを回収するステップと、前記データ分析プラットフォームに前記クライアントデータを転送するステップと、を具えることを特徴とする方法。
請求項４に記載の方法において、前記クライアントデータエージェントが、クライアントデータを回収するイベントチャネルに一体化されていることを特徴とする方法。
請求項５に記載の方法において、前記イベントチャネルが、システムログ、関連データベース、クラウドデータ、及びセンサデータからなるリストから選択されることを特徴とする方法。
請求項４に記載の方法が更に、前記クライアントデータエージェントにおいて、データを、前記データ分析プラットフォームに送信されたバイナリシリアル化データ交換にシリアル化するステップを具えることを特徴とする方法。
請求項４に記載の方法において、クライアントデータを回収するステップが、クライアントエージェントデータ入力プラグインを介して回収されることを特徴とする方法。
請求項１に記載の方法において、前記列ベースの分散アーカイブストレージシステムが、時系列順クライアントデータを保存し、クライアントデータと選択的にインターフェースを取るステップが、分散ストレージシステムからのデータを問い合わせるステップを具えることを特徴とする方法。
請求項１に記載の方法において、データ問合わせを受信するステップが、関連するデータベーススタイルの問い合わせを、大量データクラスタ問い合わせプロセスに変換するステップを具えることを特徴とする方法。
請求項１に記載の方法において、前記データ問い合わせを、インフォグラフィックスインターフェースを介して受信し、この方法が、前記選択的にインターフェースを取ったクライアントデータからインフォグラフィックを戻すステップを具えることを特徴とする方法。
請求項１に記載の方法において、データ問い合わせを受信するステップが、ビジネスインテリジェンスツールドライバを介して受信するステップを具え、この方法が、データ分析結果を前記ビジネスインテリジェンスツールドライバに戻すステップを具えることを特徴とする方法。
請求項１に記載の方法が更に、クライアントデータエージェントにおいて、クライアントデータを回収し、当該クライアントデータを前記データ分析プラットフォームに送信するステップを具え；前記列ベースの分散アーカイブストレージシステムが、動的スキーマを用いてクライアントデータを時系列順に保存し、クライアントデータと選択的にインターフェースを取るステップが、リアルタイムストレージシステムとアーカイブストレージシステムからまとまった問い合わせ結果を求めて、協調的にデータ問い合わせを行うステップを具えることを特徴とする方法。
請求項１３に記載の方法において、分散ストレージシステムが一ペタバイト以上のデータを具えることを特徴とする方法。
請求項１に記載の方法において、前記マッピング処理及び削減処理が、ＭａｐＲｅｄｕｃｅ処理であることを特徴とする方法。
請求項１に記載の方法において、前記問い合わせ処理クラスタが、ＭａｐＲｅｄｕｃｅ処理を実行するよう構築され、前記マッピング処理及び削減処理が、ＭａｐＲｅｄｕｃｅ処理であることを特徴とする方法。
請求項１に記載の方法において、前記問い合わせ処理クラスタが、ＭａｐＲｅｄｕｃｅ処理を実行するよう構築されるＨａｄｏｏｐ対応クラスタを有しており、前記マッピング処理及び削減処理が、ＭａｐＲｅｄｕｃｅ処理であることを特徴とする方法。
請求項１に記載の方法において、前記問い合わせ結果が構造化データを有することを特徴とする方法。
大量データプラットフォームを動作させる方法において、
当該方法が、コンピュータで読み取り可能な媒体に記憶された指示をコンピュータで実行可能な構成要素で実行することによって実施され、前記方法が、マルチテナントデータ分析プラットホームで、
離散したクライアントデータであって、独自の識別子を介して前記マルチテナントデータ分析プラットホームのユーザアカウントに関連するクライアントデータ、を受信するステップと、
リアルタイムストレージシステム及び列ベースの分散したアーカイブストレージシステムを有するネットワークにアクセス可能な分散ストレージシステムに前記クライアントデータを保存するステップであって、
行フォーマットで前記リアルタイムストレージシステムに前記クライアントデータを保存するステップと、
前記クライアントデータを列フォーマットで前記アーカイブストレージシステムに保存するステップであって、前記アーカイブデータストレージシステムに保存される前記クライアントデータが、前記クライアントデータに関連する前記ユーザアカウントに応じて分離される、ステップと、
を具えるステップと、
問い合わせインターフェースを介してデータ問い合わせを受信するステップと、
前記リアルタイムストレージシステム及びアーカイブストレージシステムからの前記クライアントデータと選択的にインターフェースを取ることによって前記データ問い合わせを処理するステップであって、当該データ問い合わせを処理するステップが、前記リアルタイムストレージシステムとアーカイブストレージシステムに協調的に問い合わせを行うステップと、前記リアルタイムストレージシステムとアーカイブストレージシステムに亘って前記データ問い合わせを分散させて、単一のまとまった問い合わせ結果を引き出すステップと具えており、
前記アーカイブストレージシステムからの前記クライアントデータとインターフェースを取ることが、
問い合わせ処理クラスタを用いることによって、前記ＭａｐＲｅｄｕｃｅマッピング処理とＭａｐＲｅｄｕｃｅ削減処理に前記データ問い合わせを変換するステップと、
前記問い合わせ処理クラスタを用いることによって、前記ＭａｐＲｅｄｕｃｅマッピング処理とＭａｐＲｅｄｕｃｅ削減処理を実行するステップと、
を具えており、
前記問い合わせ処理クラスタが、ＭａｐＲｅｄｕｃｅ処理を実行するよう構築されるＨａｄｏｏｐ対応クラスタを有することを特徴とする方法。