JP2016515228A - 低レイテンシデータアクセス用のデータストリーム分割 - Google Patents

Abstract

データストリームを分割することによってログデータ処理を促進し加速するための技術が、本明細書で開示される。フロントエンドクラスタは、大量のログデータをリアルタイムで生成し、ログデータを集約クラスタに転送する。集約クラスタは、異なるフロントエンドサーバ及びクラスタからの着信ログデータストリームを集約するように設計される。集約クラスタは更に、データストリームが受信アプリケーションに並列に送信されるように、ログデータを複数のデータストリームに分割する。一実施形態において、ログデータは、ログデータが分割データストリームに均等に分配されることを保証するように、ランダムに分割される。別の実施形態において、分割データストリームを受信するアプリケーションは、どのようにログデータを分割するかを決定する。

Description

本発明は、概して、データ取り込み及び処理システムに関し、特に、データを多数のデータストリームに分割することが可能なデータ取り込み及び処理システムに関する。

コンピュータ及びネットワーク技術の発達は、大量のデータ記憶を必要とするアプリケーションをもたらした。例えば、何千万ものユーザが、ウェブページを作成し、ソーシャルメディアウェブサイトに画像及びテキストをアップロードすることができる。その結果、ソーシャルメディアウェブサイトは、毎日大量のデータを蓄積し、従って、データを記憶し処理するために非常にスケーラブルなシステムを必要とする可能性がある。かかる大量のデータ記憶を容易にするための様々なツールが存在する。

これらのソーシャルメディアウェブサイトのフロントエンドクラスタは、ユーザ活動を監視し、且つソーシャルメディアユーザの活動に基づいてログデータを作成する。フロントエンドクラスタは、集中型記憶フィラー又はデータウェアハウスにログデータを送信する。集中型記憶フィラー又はデータウェアハウスは、受信したログデータを編成し、データ処理アプリケーションからの要求に応える。大量のログデータを収容するために、大規模データウェアハウスが、ログデータを記憶し、且つデータ処理アプリケーションからのデータ集約的な照会に応えるために、一般に用いられる。

アプリケーションが、何千ものコンピュータ（ノードとも呼ばれる）のクラスタ及びペタバイトのデータと対話できるようにすることによって、大規模なデータ集約型分散アプリケーションを支援するフレームワークが存在する。例えば、ハドゥープ（Ｈａｄｏｏｐ）と呼ばれるフレームワークが、ハドゥープクラスタにおけるデータノード（子ノードとも呼ばれる）間で大量のデータ量を分配するためにハドゥープ分散ファイルシステム（ＨＤＦＳ：Hadoop Distributed File System）と呼ばれる、分配され且つスケーラブルでポータブルなファイルシステムを利用する。データノードの停電又はネットワーク障害（スイッチ故障を含む）の悪影響を低減するために、ＨＤＦＳにおけるデータは、典型的には、異なるデータノードに複写される。

オープンソースデータウェアハウスシステムであるハイブ（Ｈｉｖｅ）は、ハドゥープクラスタ上を走るために開発されている。ハイブは、ハイブＱＬと呼ばれる、スクリプト照会言語（ＳＱＬ：scripted query language）のような宣言型言語で表現されたデータ照会を支援する。次に、ハイブシステムは、ハイブＱＬで表現された照会を、有向非巡回グラフの数学的形式において、ハドゥープクラスタ上で実行できるマップリデュースジョブにコンパイルする。ハイブＱＬ言語は、基本型、アレイ及びマップなどのコレクション、並びに入れ子にした型合成を含むテーブルを支援する型システムを含む。更に、ハイブシステムは、データ探索及び照会の最適化に有用な、スキーム及び統計を含むハイブメタストアと呼ばれるシステムカタログを含む。

ハドゥープクラスタと結合されると、ハイブシステムは、ソーシャルネットワーキングシステム用の大量のデータを記憶し分析することができる。例えば、ハイブシステムは、ユーザがソーシャルネットワーキングシステムを追い続けるという話をランク付けするために、ユーザ間の接続程度を分析することができる。ハイブシステムは、アプリケーション開発者、ページ管理者、及び広告主が、開発及びビジネスの決定を行うのを助けるために、ソーシャルネットワーキングシステムのサービスがどのように利用されているかに対する洞察力を得るように活動ログを分析することができる。ハイブシステムは、ソーシャルネットワーキングシステムのユーザに示される広告を最適化するために、複雑なデータマイニングプログラムを実行することができる。ハイブシステム、更に、ソーシャルネットワーキングシステムのスパム及び乱用を識別するために、使用ログを分析することができる。

ハイブシステムは、プログラミング能力のない人々がハイブクエリをオーサリングして実行するための、複雑なデータパイプラインをオーサリングし、デバッギングし、スケジューリングするための、且つハイブシステム、並びにＭｙＳＱＬ及びオラクルなどの他の関係データベースに記憶されたデータ基づいて報告を作成するためのウェブベースのツールを含む。

しかしながら、フロントエンドクラスタは、リアルタイムではなく周期的に、取り込んだログデータを集中型データウェアハウスに送信する。更に、データウェアハウスが、これらのログデータに対するデータ照会に応答できる前に、データウェアハウスが、受信したログデータを編成するには時間がかかる。従って、データウェアハウスにおけるログデータは、ログデータが取り込まれてから或る期間後に利用できるだけである。その期間は、１時間又は１日にさえなる可能性がある。データ処理及び消費アプリケーションは、ログデータにアクセスできるまでに著しい待ち時間（レイテンシ）がかかるだけである。

更に、集中型データウェアハウスは、連続的にログデータを受信するために、フロントエンドサーバとの接続を維持する必要がある。現在のソーシャルネットワークにおいて、フロントエンドサーバの数は、数千又はそれを超える可能性がある。データウェアハウスは、接続を維持する著しい負担を担う。接続を維持するかかる負担は、データウェアハウスの全体的性能に影響する。

本明細書で導入される技術は、低レイテンシでのログデータアクセス及び処理の利点を提供する。特に、本明細書で導入される技術は、大量のログデータをリアルタイムで生成し、且つログデータを集約クラスタに転送するフロントエンドクラスタを含む。集約クラスタは、異なるフロントエンドサーバ及びクラスタからの着信ログデータストリームを集約するように設計される。集約クラスタは、更に、データストリームが受信アプリケーションに並列に送信されるように、ログデータを複数のデータストリームに分割する。一実施形態において、集約クラスタは、ログデータが、分割データストリームに均等に分配されることを保証するように、ログデータをランダムに分割する。別の実施形態において、分割データストリームを受信するアプリケーションは、どのようにログデータを分割するかを決定する。

本明細書で導入される技術によれば、データストリームを分割するための方法が提供される。方法は、リアルタイムのユーザ活動に基づくログデータを生成すること、ログデータを集約サーバに送信すること、ログデータを集約サーバにおいて集約すること、ログデータを複数のログデータストリームに分割すること、およびログデータストリームを少なくとも１つのバックエンドサーバに並列に供給することを含む。

本明細書で導入される技術によれば、データストリームを分割するためのコンピュータ実行システムもまた提供される。コンピュータ実行システムは、複数のフロントエンドサーバ及び少なくとも１つの集約サーバを含む。フロントエンドサーバは、リアルタイムのユーザ活動に基づくログデータを生成するように構成される。集約サーバは、フロントエンドサーバの少なくとも幾つかから受信されたログデータを集約するように構成される。集約サーバは、ネットワークを介して、フロントエンドサーバの少なくとも幾つかと接続される。集約サーバは、ログデータをステージングするように構成されたデータステージングエリアを含む。集約サーバは、１つ又は複数のバックエンドサーバがログデータストリームを並列に検索できるように、ログデータを複数のログデータストリームに分割するように更に構成される。

本明細書で導入される技術によれば、ログデータをステージングするための集約サーバもまた提供される。集約サーバは、プロセッサ、ネットワークインターフェース、データ記憶装置及びメモリを含む。ネットワークインターフェースはプロセッサに結合され、このネットワークインターフェースを介して、集約サーバは複数のフロントエンドサーバと通信することができる。フロントエンドサーバは、リアルタイムのユーザ活動に基づくログデータを生成する。データ記憶装置は、データステージングエリアを含む。メモリは、プロセッサによって実行された場合に以下を含む処理、すなわち、フロントエンドサーバから、フロントエンドサーバによって生成されたリアルタイムのユーザ活動に基づくログデータを受信すること、ログデータを集約すること、データステージングエリアにおいてログデータをステージングすること、１つ又は複数のバックエンドサーバがログデータストリームを並列に検索できるようにログデータを複数のログデータストリームに分割することを含む処理を集約サーバに実行させる命令を記憶する。

本発明の実施形態において、特に、ソーシャルネットワーキングシステム若しくはその一部の、第三者システムの、又はクライアントシステムの無許可の使用を防ぐために、ソーシャルネットワーキングシステムの、第三者システムの、又はクライアントシステムのユーザを認証するための方法が提供される。

本発明の実施形態において、方法は、
複数のフロントエンドサーバにおいて、リアルタイムのユーザ活動に基づくログデータを生成すること、
ログデータを集約サーバに送信すること、
集約サーバにおいてログデータを集約すること、
ログデータを複数のログデータストリームに分割すること、
ログデータストリームを少なくとも１つのバックエンドサーバに並列に供給すること、
を含む。

上記分割するステップは、
ログデータが複数のログデータストリームに均等に分配されるようにログデータをランダムに分割することを含むことができる。

上記方法は、
データステージングエリアにおいてログデータをステージングすることを更に含むことができる。

上記方法は、
ログデータをどのように複数のログデータストリームに分割するかに関しての命令を、バックエンドサーバから受信することを更に含むことができる。

ログデータは複数のログデータエントリを含むことができ、各ログデータエントリはアプリケーション識別及びカテゴリフィールドを含むことができる。
上記方法は、
ログデータの各エントリ用に、バケットの合計数を法（modulo）として、アプリケーション識別及びカテゴリフィールドのハッシュ関数によってバケット番号を計算することであって、バケットの合計数が複数のログデータストリームの合計数であることと、
ログデータのそのエントリを、バケット番号によって識別されたログデータストリームに割り当てること、
を更に含むことができる。

カテゴリフィールドは、ログデータエントリの意図された宛先の高レベルの記述を含むことができる。
アプリケーション識別は、ログデータエントリを処理するためのデータ消費アプリケーションを識別することができる。

ログデータは、複数のログデータエントリを含むことができる。
上記方法は、
各ログデータエントリ用に、１からバケットの合計数までの整数をランダムに生成することであって、バケットの合計数が複数のログデータストリームの合計数であることと、
そのログデータエントリを、バケット番号によって識別されたログデータストリームに割り当てること、
を更に含むことができる。

バケットの合計数は、ログデータストリームを受信するために利用可能なバックエンドサーバの数、及び各バックエンドサーバが扱うことができる接続部の数によって決定することができる。

バケットの合計数は、少なくとも１つのバックエンドサーバ上を走るデータ消費アプリケーションによって指示することができる。
バックエンドサーバがログデータストリームを受信して処理する場合に、バックエンドサーバには等しく負荷をかけることができる。

上記方法は、
ログデータのエントリの接頭部を検査して、エントリが割り当てられるログデータストリームを決定することを更に含むことができる。

上記方法は、
ログデータをデータウェアハウスに送信すること、
データウェアハウスが、処理したログデータに基づいてデータ照会に応答することができるように、データウェアハウスにおいてログデータを処理すること、
を更に含むことができる。

本発明の実施形態において、コンピュータ実行システムは、
リアルタイムのユーザ活動に基づいてログデータを生成するように構成された複数のフロントエンドサーバと、
フロントエンドサーバの少なくとも幾つかから受信されたログデータを集約するように構成された少なくとも１つの集約サーバであって、ネットワークを介してフロントエンドサーバの少なくとも幾つかと接続される集約サーバと、
を含み、
集約サーバは、ログデータをステージングするように構成されたデータステージングエリアを含み、集約サーバは、１つ又は複数のバックエンドサーバが、ログデータストリームを並列に検索できるように、ログデータを複数のログデータストリームに分割するように構成される。

ログデータは複数のログデータエントリを含むことができ、各ログデータエントリはアプリケーション識別及びカテゴリフィールドを含むことができ、集約サーバは更に、
ログデータの各エントリ用に、バケットの合計数を法として、アプリケーション識別及びカテゴリフィールドのハッシュ関数によってバケット番号を計算し、ここで、バケットの合計数は複数のログデータストリームの合計数であり、
ログデータのそのエントリを、バケット番号によって識別されたログデータストリームに割り当てる、
ように構成することができる。

ログデータは、複数のログデータエントリを含むことができ、集約サーバは更に、
各ログデータエントリ用に、１からバケットの合計数までの整数をランダムに生成し、ここで、バケットの合計数は複数のログデータストリームの合計数であり、
そのログデータエントリを、バケット番号によって識別されたログデータストリームに割り当てる、
ように構成することができる。

バケットの合計数は、１つ又は複数のバックエンドサーバ上を走るデータ消費アプリケーションデータによって指示することができ、バケットの合計数は、ログデータストリームを受信するために利用可能なバックエンドサーバの数、及び各バックエンドサーバが扱うことができる接続部の数によって決定することができる。

本発明の実施形態において、集約サーバは、
プロセッサと、
プロセッサに結合され、集約サーバが複数のフロントエンドサーバと通信することを可能にするネットワークインターフェースと、
データステージングエリアを含むデータ記憶装置と、
プロセッサによって実行されることで集約サーバが以下を含む処理を行うことを可能にする命令を格納するメモリと、
を備え、当該処理が、
フロントエンドサーバからログデータを受信することであって、フロントエンドサーバがリアルタイムのユーザ活動に基づいてログデータを生成することと、
ログデータを集約すること、
データステージングエリアにおいてログデータをステージングすること、
１つ又は複数のバックエンドサーバがログデータストリームを並列に検索できるように、ログデータを複数のログデータストリームに分割すること、
を含む。

ログデータは複数のログデータエントリを含むことができ、各ログデータエントリはアプリケーション識別及びカテゴリフィールドを含むことができ、上記処理は、
ログデータの各エントリ用に、バケットの合計数を法として、アプリケーション識別及びカテゴリフィールドのハッシュ関数によってバケット番号を計算することであって、バケットの合計数が複数のログデータストリームの合計数であることと、
ログデータのそのエントリを、バケット番号によって識別されたログデータストリームに割り当てること、
を更に含むことができる。

ログデータは複数のログデータエントリを含むことができ、上記処理は、
各ログデータエントリ用に、１からバケットの合計数までの整数をランダムに生成することであって、バケットの合計数が複数のログデータストリームの合計数であることと、
そのログデータエントリを、バケット番号によって識別されたログデータストリームに割り当てること、
を更に含むことができる。

本発明の更なる実施形態において、１つ又は複数のコンピュータ可読非一時的記憶媒体が、本発明による方法又は上記の実施形態のいずれかを実施するように実行された場合に動作可能なソフトウェアを具現化する。

本発明の更なる実施形態において、システムは、１つ又は複数のプロセッサと、プロセッサによって実行可能な命令を含む、プロセッサに結合されたメモリであって、プロセッサが、本発明による方法又は上記の実施形態のいずれかを実施する命令を実行する場合に動作可能であるメモリと、を含む。

本明細書で導入される他の態様は、添付の図面及び以下に続く詳細な説明から明らかになる。本発明の上記した目的や他の目的、機構及び特徴は、全てが本明細書の一部を形成する、添付の特許請求の範囲及び図面と共に以下の詳細な説明の検討から、当業者には一層明らかになる。

オンラインデータ収集システムの例を示す。 ログデータストリームを分割できる集約クラスタの例を示す。 ログデータエントリの例示的な構造を示す。 集約サーバの多層を有するオンラインデータ収集システムの別の例を示す。 ログデータを集約しステージングするための例示的な処理を示す。 ログデータをステージングし分割するための例示的な処理を示す。 本明細書で説明される任意のノード又はサーバを表し得るコンピュータサーバのアーキテクチャの例を示す高レベルブロック図である。

本明細書において、「一実施形態」等への言及は、特定の機構、機能、又は特徴が、本発明の少なくとも一実施形態に含まれることを意味する。この記載におけるかかる句の出現は、全てが必ずしも同じ実施形態を指すわけでもなく、それらが必ずしも相互に排他的であることでもない。

図１は、オンラインデータ収集システムの例を示す。オンラインデータ収集システム１００は、複数のフロントエンドクラスタ１１０を含む。各フロントエンドクラスタ１１０は、多数の相互接続されたフロントエンドサーバ１１２を含む。一実施形態において、フロントエンドクラスタ１１０は、５０００〜３００００のフロントエンドサーバ１１２を含むことができる。フロントエンドクラスタは、ウェブトラフィックを扱い、且つオンラインデータ収集システム１００によって監視されたユーザ活動に基づいて、リアルタイムでログデータを作成する。一実施形態において、フロントエンドクラスタ１１０は、更に、ＨＴＴＰサービスを含む、システム１００のユーザにユーザインターフェースを提供する責任を負う。

オンラインデータ収集システム１００は、ログデータを集約するための、即ち、効率的なネットワークデータ伝送用にログデータを収集及びバッファリングするための責任を負う複数の集約クラスタ１２０を更に含む。フロントエンドクラスタ１１０のそれぞれは、集約クラスタ１２０が利用可能であるかどうかを決定するために、集約クラスタ１２０の少なくとも１つに要求を送信する。集約クラスタ１２０が利用可能な場合に、フロントエンドクラスタ１１０は、取り込んだログデータを集約クラスタ１２０へリアルタイムで流す。集約クラスタ１２０のそれぞれは、多数のサーバからストリーミングログデータを受信し、ログデータを集約する。一実施形態において、ログデータの集約は、ファイル及びディレクトリを組み合わせる観点で、ログデータを再編成することを含む。集約されたログデータファイルは、着信ログデータファイルと必ずしも一対一のマッピングを有しない。集約クラスタ１２０は、非常に多数のサーバノードに対してスケーリングするように、且つネットワーク及びノード障害に対して堅牢なように設計される。一実施形態において、集約クラスタ１２０は、集約されたログデータを圧縮することを含む、集約されたログデータに対する追加処理を実行する。別の実施形態において、集約クラスタ１２０は、集約されたログデータに対して追加処理を実行しない。

次に、集約クラスタ１２０は、ハドゥープクラスタに対して実現されるハイブデータウェアハウスなどのデータウェアハウス１３０に、集約されたログデータを周期的にコピーする。幾つかの実施形態において、ハイブデータウェアハウスは、ペタバイトのデータを記憶することができる。他の幾つかの実施形態において、集約クラスタ１２０は、集約されたログデータを１つ又は複数のＮＦＳフィラーに送信する。

幾つかの実施形態において、集約クラスタ１２０は、２レベル構造として実現することができる。集約クラスタの１つは、親集約クラスタと呼ばれる。集約クラスタの残りは、レベル２集約クラスタである。親集約クラスタは、フロントエンドクラスタ１１０からログデータを受信し、且つ受信したログデータをレベル２集約クラスタに分配する責任を負う。バックエンドサーバ上を走るデータ消費アプリケーションは、レベル２集約クラスタからログデータをリアルタイムで検索する。集約クラスタのこの２レベル構造は、バックエンドサーバが集約クラスタからログデータを引き出すための大きな帯域幅を提供する。他の幾つかの実施形態において、バックエンドサーバ上を走るデータ消費アプリケーションは、親集約クラスタから直接にリアルタイムでログデータを検索する。

ひとたびデータウェアハウス１３０が、関連するログデータを受信し処理すると、バックエンドサーバ１４０は、オフラインデータ分析用に照会要求をデータウェアハウス１３０に送信することができる。より高速なログデータアクセスのために、集約クラスタ１２０のそれぞれは、データステージングエリア１２２を含む。データステージングエリア１２２は、集約されたログデータを、処理の前に一時的に記憶するための集約クラスタ１２０内の中間記憶エリア（パーキングとも呼ばれる）である。一実施形態において、データステージングエリア１２２は、集約クラスタ１２０のサーバにわたって拡張することができる。バックエンドサーバ１４０は、リアルタイム又はほぼリアルタイムでのログデータ供給のために、データステージングエリア１２２に直接アクセスすることができる。データステージングエリア１２２に記憶されたログデータは、所定の期間後に削除されても良い。例えば、一実施形態において、ログデータは、ログデータが取り込まれた３日後に削除される。一実施形態において、バックエンドサーバ１４０は、オンラインデータ収集システム１００の一部である。別の実施形態において、バックエンドサーバ１４０は、オンラインデータ収集システム１００とは別個である。

幾つかの実施形態において、フロントエンドクラスタ１１０のサーバ１１２は、レベル１プラスステージングエリア１１５を含む。例えば、フロントエンドクラスタ１１０におけるフロントエンドサーバ１１２は、その対応する集約クラスタ１２０が利用不可能であることを通知される。現在利用不可能な集約クラスタ１２０にログデータを流す代わりに、フロントエンドサーバ１１２は、レベル１プラスステージングエリア１１５にログデータを一時的に記憶する。レベル１プラスステージングエリア１１５は、バックエンドサーバによって直接アクセスすることができる。換言すれば、バックエンドサーバ１４０は、集約クラスタ１２０にもデータウェアハウス１３０にもアクセスする必要なしに、レベル１プラスステージングエリア１１５からログデータを直接流すことができる。他の幾つかの実施形態において、フロントエンドクラスタ１１０は、レベル１プラスステージングエリアがあってもなくても、システム内の任意のレベルからサーバによって直接アクセスできるレベル０ステージングエリアを更に含むことができる。

一実施形態において、オンラインデータ収集システムは、データを多数の優先層に分割することによって、ログデータに優先順位をつけることができる。例えば、トップ層のログデータは、データウェアハウス及びバックエンドサーバに送信される、より高い優先権を有する。トップ層のログデータはまた、データがステージングエリアにパーキングしている場合に、より長い保持時間を有することができる。より低い層のログデータは、トップ層のログデータより短い保持期間後に、より早く削除される。幾つかの実施形態において、優先権を設定する命令は、ポリシーシステムで実行することができる。データ消費アプリケーションが提示された場合に、それが必要とするデータカテゴリ用に、優先層と同様に帯域幅に関してポリシーを指定することができる。ポリシーは、更に、要求されたログデータが、ステージングエリアから、アプリケーションが走るバックエンドサーバへとリアルタイムで直接送信されるべきかどうかということ、要求されたログデータが、データウェアハウスから送信されるべきかどうかということ、又は要求されたログデータが、レベル１プラスステージングエリア、又は集約サーバにおけるステージングエリア上でステージングされるべきかどうかということを更に指定することができる。

ログデータの処理を加速するために、集約クラスタは、ログデータストリームが、バックエンドサーバ上を走るデータ消費アプリケーションに並列に送信されるように、ログデータを多数のログデータストリームに分割することができる。図２は、ログデータストリームを分割できる集約クラスタの例を示す。集約クラスタ２１０は、分割ログデータストリーム２１２（バケット（bucket）とも呼ばれる）に均等に且つランダムに分配されるログデータを保証するために、ログデータのエントリを検査することによってログデータを分割する。図３は、ログデータエントリの例示的な構造を示す。ログデータのエントリ３００は、アプリケーションＩＤ３１０を含み、アプリケーションＩＤ３１０は、そのログデータエントリを消費し処理しようとしているデータ消費アプリケーションを識別する。一実施形態において、アプリケーションＩＤ３１０は、開発者ＩＤである。エントリ３００は、更に、カテゴリ３２０を含む。カテゴリ３２０は、メッセージの意図した宛先の高レベルの記述である。エントリ３００は、更に、メッセージ３３０を含む。メッセージ３３０は、ログデータエントリの実際の内容を含む。

一実施形態において、集約サーバは、アプリケーションＩＤ及びカテゴリを読み取り、次に、アプリケーションＩＤ及びカテゴリのハッシュ関数を計算する。例えば、ハッシュ関数は、３２ビット又は１２８ビットのハッシュ値を生じるＭｕｒｍｕｒＨａｓｈ３ハッシュ関数とすることができる。集約サーバは、更に、バケットの合計数によるハッシュ関数の値を法（modulo）とする。結果は、ログデータエントリが割り当てられるバケット番号である。換言すれば、ログデータエントリは、そのバケット番号を有するログデータストリームに含まれることになる。ハッシュ関数は、エントリがバケット（即ち、分割ログデータストリーム）間で均等に且つランダムに分配されるように、ログデータのエントリを入れ替える。エントリへのバケット番号の割り当ては、エントリが生成されるときにも又はエントリのアプリケーションＩＤとも相関を有しない。幾つかの実施形態において、バケット番号は、アプリケーションＩＤに加えてログデータエントリのデータフィールドの関数とすることができる。例えば、ハッシュ関数は、バケット番号を決定するためのハッシュ値を生成するために、ログデータエントリのアプリケーションＩＤ及び別のデータフィールドを用いることができる。

バケットの合計数は、様々な方法で決定することができる。一実施形態において、バックエンドサーバの合計数は、各バックエンドサーバが扱うことができる推定合計データ量及びデータ帯域幅によって決定される。バケットの数は、システムが、より多くのバックエンドサーバを含むようにスケールアップできるために、バックエンドサーバの数より大きな数として決定される。例えば、バケットの数が１０２４である場合に、それは、システムが、ストリーム分割において変更を行う必要なしに、１０２４のバックエンドサーバまでスケールアップできることを意味する。複数のバックエンドサーバが、分割データストリームを並列にリアルタイムで処理するために利用され得る。ストリームが均等に分割されるので、バックエンドサーバは、等しく負荷をかけられる。別の実施形態において、データ消費アプリケーションを提示する場合に、ログデータストリームを並列処理するためのバケット数を含むデータ消費アプリケーション用のポリシーを指定することができる。

別の実施形態において、各ログデータエントリに割り当てられるバケット番号は、乱数によって決定される。集約サーバは、バケットの合計数の範囲内でランダム整数を生成し、その生成された整数を、割り当てられたバケット番号としてログデータエントリに割り当てる。

更に別の実施形態において、データ消費アプリケーションは、バケット番号を割り当てるための関数又は方法を指定することができる。例えば、データ消費アプリケーションは、エントリの或るＩＤに基づいてバケット番号を割り当てることができる。データ消費アプリケーションは、エントリのユーザＩＤの第１の範囲を第１のバケット番号に割り当てることができ、エントリのユーザＩＤの第２の範囲を第２のバケット番号に割り当てることができる等である。

一実施形態において、オンラインデータ収集システムは、図１の集約サーバに似た中間サーバにおける１を超える層を有することができる。図４は、集約サーバの多層を有するオンラインデータ収集システムの別の例を示す。オンラインデータ収集システム４００は、複数のフロントエンドクラスタ４１０を含む。各フロントエンドクラスタ４１０は、多数の相互接続されたフロントエンドサーバ４１２を含む。フロントエンドクラスタ４１０は、オンラインデータ収集システム１００によって監視されたユーザ活動に基づいてリアルタイムでログデータを生成する。一実施形態において、フロントエンドクラスタ１１０におけるサーバ４１２は、バックエンドサーバ４５０によって直接アクセスされ得るレベル１プラスステージングエリア４１５を更に含むことができる。

オンラインデータ収集システム４００は、フロントエンドクラスタ４１０から送信されたログデータを集約する責任を負う複数の第１のレベルの集約クラスタ４２０を更に含む。更に、オンラインデータ収集システム４００は、第１のレベルの集約クラスタ４２０から送信されたログデータを集約する責任を負う１つ又は複数の第２のレベルの集約クラスタ４３０を含む。次に、第２のレベルの集約クラスタ４３０は、集約されたログデータを、ハドゥープクラスタ上に実現されたハイブデータウェアハウスなどのデータウェアハウス４４０に周期的にコピーする。

第１のレベルの集約クラスタ４２０は、第１のレベルのデータステージングエリア４２２を含み、第２のレベルの集約クラスタ４３０は、第２のレベルのデータステージングエリア４３２を含む。バックエンドサーバ４５０は、第１のレベルのデータステージングエリア４２２又は第２のレベルのデータステージングエリア４３２からログデータを直接検索することができる。一実施形態において、バックエンドサーバ４５０は、それが、ネットワークトポロジに基づいて第１のレベルのステージングエリア又は第２のレベルのステージングエリアからログデータを検索するかどうかを決定することができる。例えば、ネットワークトポロジの点で、バックエンドサーバ４５０が、第１のレベルの集約クラスタ４２０より第２のレベルの集約クラスタ４３０に一層近い場合に、バックエンドサーバ４５０は、第２のレベルのデータステージングエリア４３２からログデータを検索することを決定する。

例えば、一例において、ログデータは、ユーザの活動データであり、データ消費アプリケーションは、ニュースフィードアプリケーションである。或る期間後にデータウェアハウス上で利用可能なオフラインログデータを待つのではなく、ニュースフィードアプリケーションは、どちらの集約クラスタが、ネットワークトポロジにおいてニュースフィードアプリケーションのバックエンドサーバに一層近いかに依存して、第１又は第２のレベルのステージングエリアから、関連するユーザ活動のログデータをリアルタイムで検索するように要求することができる。ニュースフィードアプリケーションは、非常に低いレイテンシでユーザ活動のログデータを引き出し、且つできるだけ早くログデータを処理しニュースフィード結果を格納することができる。

一実施形態において、多重レベルの集約クラスタを備えたオンラインデータ収集システムが、レベル１プラスステージング能力を備えたフロントエンドクラスタを含む。集約クラスタが利用不可能な場合に、フロントエンドクラスタは、バックエンドサーバログデータを供給し続けるために、自らのレベル１プラスステージング能力を用いることができる。別の実施形態において、オンラインデータ収集システムは、データステージング能力を備えた２を超えるレベルの集約クラスタを含むことさえできる。

多重レベルのステージング能力を有するかかるオンラインデータ収集システムは、ログデータ集約の各ステージにおいてリアルタイムでログデータを供給することができる。システムは、ログデータが中央データリポジトリ（例えばデータウェアハウス）からまだ入手可能でない場合に、各ステージにおけるデータ消費照会に応じて、低レイテンシのデータ供給を提供することができる。バックエンドサーバは、ネットワークトポロジの点から、ステージログデータを検索するために、より近いクラスタを選択することができる。バックエンドサーバのデータストリームは、ネットワークにおいて、より少数のノード及びシステム通って移動する。従って、送信中にログデータを失うか又はログデータを破損する公算は、より少ない。従って、多重レベルのステージングシステムは、ログデータ送信の耐久性及び信頼性を向上させる。

図５は、ログデータを集約してステージングするための例示的な処理を示す。ステップ５１０において、フロントエンドサーバは、リアルタイムのユーザ活動に基づいてログデータを生成する。一実施形態において、フロントエンドサーバは、更に、ウェブコンテンツをユーザに提供する。一実施形態において、フロントエンドサーバは、ログデータを複数の優先層に分割し、それら優先層のうちのトップ層のログデータだけを集約サーバに送信する。

ステップ５１４において、フロントエンドサーバは、集約サーバが利用可能かどうかをチェックする。集約サーバが利用不可能な場合に、フロントエンドサーバは、ステップ５１６において、複数のフロントエンドサーバの少なくとも１つにおけるレベル１プラスステージングエリアにおいてログデータをステージングする。ステップ５１８において、フロントエンドサーバは、バックエンドサーバが要求した場合に、レベル１プラスステージングエリアからバックエンドサーバにログデータをリアルタイムで供給する。集約サーバが利用可能な場合に、ステップ５２０において、フロントエンドサーバは、ログデータを集約サーバに送信する。

ステップ５３０において、集約サーバは、ログデータを集約する。一実施形態において、集約は、集約サーバにおいてログデータのストリームを組み合わせることによって、ログデータを再編成することを含む。別の実施形態において、集約サーバは、更に、集約サーバにおいてログデータを圧縮する。

ステップ５４０において、集約サーバは、バックエンドサーバがログデータにリアルタイムでアクセスできるように、ログデータをステージングする。一実施形態において、１つのバックエンドサーバが、ログデータ用のデータステージング位置に関する命令を集約サーバ及びフロントエンドサーバに送信する。次に、集約サーバ及びフロントエンドサーバは、命令に従ってログデータをステージングするかどうかを決定する。ステップ５５０において、集約サーバは、集約サーバから直接バックエンドサーバにログデータをリアルタイムで供給する。

ステップ５６０において、集約サーバは、ログデータをデータウェアハウスに送信する。ステップ５７０において、データウェアハウスは、それが、処理されたログデータに基づいてデータ照会に応答できるように、ログデータを処理する。

ステップ５８０において、集約サーバは、所定の期間後に、集約サーバからログデータを削除する。フロントエンドサーバが、レベル１プラスステージングエリアにおいてログデータをステージングする場合に、フロントエンドサーバもまた、所定の期間後に、レベル１プラスステージングエリアからログデータを削除する。

図６は、ログデータをステージング及び分割するための例示的な処理を示す。ステップ６１０において、フロントエンドサーバは、リアルタイムのユーザ活動に基づいてログデータを生成する。一実施形態において、フロントエンドサーバは、更に、ウェブコンテンツをユーザに提供する。

ステップ６１４において、フロントエンドサーバは、集約サーバが利用可能かどうかをチェックする。集約サーバが利用不可能な場合に、フロントエンドサーバは、ステップ６１６において、複数のフロントエンドサーバの少なくとも１つにおけるレベル１プラスステージングエリアにおいてログデータをステージングする。

ステップ６１８において、フロントエンドサーバは、バックエンドサーバが要求した場合に、レベル１プラスステージングエリアからバックエンドサーバにリアルタイムでログデータを供給する。集約サーバが利用可能な場合に、ステップ６２０において、フロントエンドサーバは、ログデータを集約サーバに送信する。

ステップ６３０において、集約サーバは、ログデータを集約する。一実施形態において、集約は、集約サーバにおいてログデータのストリームを組み合わせることによって、ログデータを再編成することを含む。別の実施形態において、集約サーバは、更に、集約サーバにおいてログデータを圧縮する。

ステップ６４０において、集約サーバは、バックエンドサーバがログデータにリアルタイムでアクセスできるように、ログデータをステージングする。
一実施形態において、ログデータは、複数のログデータエントリを含む。各ログデータエントリは、アプリケーション識別及びカテゴリフィールドを含む。カテゴリフィールドは、ログデータエントリの意図された宛先の高レベルの記述を含む。アプリケーション識別は、ログデータエントリを処理するためのデータ消費アプリケーションを識別する。集約サーバは、ログデータのエントリの接頭部を検査して、アプリケーション識別及びカテゴリフィールドを認識する。

一実施形態ではステップ６５０において、ログデータの各エントリ用に、集約サーバは、バケットの合計数を法として、アプリケーション識別及びカテゴリフィールドのハッシュ関数によってバケット番号を計算する。バケットの合計数は、複数のログデータストリームの合計数である。一実施形態において、バケットの合計数は、ログデータストリームを受信するために利用可能なバックエンドサーバの数、及び各バックエンドサーバが扱うことができる接続部の数によって決定される。別の実施形態において、バケットの合計数は、少なくとも１つのバックエンドサーバ上を走るデータ消費アプリケーションによって指示される。その目的は、バックエンドサーバが、ログデータストリームを受信し処理する場合に、バックエンドサーバが等しく負荷をかけられるということである。ステップ６５２において、集約サーバは、ログデータのそのエントリを、バケット番号によって識別されたログデータストリームに割り当てる。

別の実施形態において、各ログデータエントリ用に、集約サーバは、１からバケットの合計数までの整数をランダムに生成する。次に、集約サーバは、そのログデータエントリを、バケット番号によって識別されたログデータストリームに割り当てる。

ステップ６５４において、集約サーバは、ログデータを複数のログデータストリームに分割する。一実施形態において、集約サーバは、ログデータをどのように複数のログデータストリームに分割するかに関する命令をバックエンドサーバから受信する。一実施形態において、フロントエンドサーバはまた、集約サーバがログデータを分割するのと似た方法で、ログデータを複数のログデータストリームに分割することができる。ステップ６６０において、集約サーバは、ログデータストリームを１つ又は複数のバックエンドサーバに並列に供給する。

ステップ６７０において、集約サーバは、ログデータをデータウェアハウスに送信する。ステップ６８０において、データウェアハウスは、それが、処理されたログデータに基づいてデータ照会に応答できるように、ログデータを処理する。

ステップ６９０において、集約サーバは、所定の期間後に、ログデータを集約サーバから削除する。フロントエンドサーバが、レベル１プラスステージングエリアにおいてログデータをステージングする場合に、フロントエンドサーバもまた、所定の期間後に、レベル１プラスステージングからログデータを削除する。

一実施形態において、バックエンドサーバは、それらが分割ログデータストリームを受信した後で、分割ログデータストリームを統合する。分割の前のログデータが複数のストリームに属すると仮定すると、ストリームのそれぞれは、バックエンドサーバの１つに割り当てられる。バックエンドサーバのいずれかが、分割ログデータストリームのメッセージを集約サーバから受信した場合に、それは、メッセージが属するストリーム用にどのバックエンドサーバが割り当てられるかを決定する。次に、バックエンドサーバは、割り当てられたバックエンドサーバ（オーナとも呼ばれる）にメッセージを転送する。一実施形態において、バックエンドサーバは、１つのカテゴリ用のログデータをキューに統合する。キューは、様々な方法で実現することができる。例えば、キューは、最後のファイルだけが潜在的なオープンファイルであるディレクトリにおけるファイルと類似した命名規則において実現することができる。キューを実現する別の方法は、２層システムを利用することである。

幾つかの実施形態において、ストリーム対サーバ割り当て情報を記録するために、バックエンドサーバは、割り当て情報用の分配マップを維持する。分配マップは、割り当て情報に変更がある場合、例えば、サーバが利用不可能な場合、又は新しいストリームが追加された場合に、更新される。バックエンドサーバは、低レイテンシでこれらの変更の通知を得る。

このストリーム対サーバの割り当て機構は、ストリームとバックエンドサーバとの間の関係を管理するための自動で動的な方法を提供する。バックエンドサーバの１つが故障した場合に、残りのバックエンドサーバは、故障したバックエンドサーバに割り当てられたストリームのオーナーシップを再分配することができる。幾つかのバックエンドサーバから他のバックエンドサーバへと幾つかのストリームのオーナーシップを移すことによって、この機構は、バックエンドサーバの仕事量のバランスを保つことができる。

図７は、サーバ７００のアーキテクチャの例を示す高レベルブロック図であり、サーバ７００は、フロントエンドサーバ、集約サーバ、データウェアハウスサーバ、及びバックエンドサーバのいずれを表しても良い。サーバ７００は、相互接続部７３０に結合された１つ又は複数のプロセッサ７１０及びメモリ７２０を含む。図７に示されている相互接続部７３０は、適切なブリッジ、アダプタ又はコントローラによって接続された任意の１つ若しくは複数の別個の物理バス、ポイントツーポイント接続部、又は両方を表す抽象概念である。従って、相互接続部７３０は、例えば、システムバス、周辺構成要素相互接続（ＰＣＩ）バス若しくはＰＣＩエクスプレスバス、ハイパートランスポート若しくは業界標準アーキテクチャ（ＩＳＡ）バス、小型コンピュータシステムインターフェース（ＳＣＳＩ）バス、ユニバーサルシリアルバス（ＵＳＢ）、ＩＩＣ（Ｉ２Ｃ）バス、又は「ＦｉｒｅＷｉｒｅ」（登録商標）とも呼ばれる電気電子技術者協会（ＩＥＥＥ）標準１３９４バスを含んでも良い。

プロセッサ７１０は、サーバ７００の中央処理装置（ＣＰＵ）であり、従って、サーバ７００の全体的動作を制御する。或る実施形態において、プロセッサ７１０は、これを、メモリ７２０に記憶されたソフトウェア又はファームウェアを実行することによって達成する。プロセッサ７１０は、１つ又は複数のプログラマブル汎用若しくは特定目的マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、プログラマブルコントローラ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理装置（ＰＬＤ）、トラステッドプラットホームモジュール（ＴＰＭ）等、又はかかる装置の組み合わせを含んでも含まなくても良い。

メモリ７２０は、サーバ７００のメインメモリであるか、又はそれを含む。メモリ７２０は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、フラッシュメモリ等、又はかかる装置の組み合わせの任意の形態を表す。使用において、メモリ７２０は、とりわけ、サーバ７００のオペレーティングシステムの少なくとも一部を具体化するコード７７０を含んでも良い。コード７７０はまた、本明細書で開示される技術を実行するための命令を含んでも良い。

相互接続部７３０を通してプロセッサ７１０に同様に接続されるのは、ネットワークアダプタ７４０及び記憶アダプタ７５０である。ネットワークアダプタ７４０は、他のフロントエンドサーバ、統合サーバ、データウェアハウスサーバ、又はバックエンドサーバなどの装置と、ネットワークを通じて通信する能力をサーバ７００に提供し、且つ例えばイーサネット（登録商標）アダプタ又はファイバチャンネルアダプタであっても良い。幾つかの実施形態において、サーバは、データ記憶クラスタ内及び外の通信に別々に対処するために、１を超えるネットワークアダプタを用いても良い。記憶アダプタ７５０は、サーバ７００が永続記憶装置にアクセスできるようにし、且つ例えばファイバチャンネルアダプタ又はＳＣＳＩアダプタであっても良い。

メモリ７２０に記憶されたコード７７０は、以下で説明される動作を実行するようにプロセッサ７１０をプログラムするためのソフトウェア及び／又はファームウェアとして実現されても良い。或る実施形態において、かかるソフトウェア又はファームウェアは、最初は、それをシステムからサーバ７００を通して（例えばネットワークアダプタ７４０を介して）ダウンロードすることによって、サーバ７００に提供されても良い。

本明細書で導入される技術は、例えば、ソフトウェア及び／若しくはファームウェアでプログラムされたプログラマブル回路（例えば１つ若しくは複数のマイクロプロセッサ）によってか、完全に特定目的ハードワイヤード回路においてか、又はかかる形態の組み合わせにおいて実行することができる。特定目的ハードワイヤード回路は、例えば、１つ又は複数の特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理装置（ＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）等の形態であっても良い。

本明細書で導入される技術の実行において使用するためのソフトウェア又はファームウェアは、機械可読記憶媒体上に記憶されても良く、且つ１つ又は複数の汎用又は特定目的プログラマブルマイクロプロセッサによって実行されても良い。「機械可読記憶媒体」は、その用語が本明細書で用いられているように、機械（機械は、例えば、コンピュータ、ネットワーク装置、携帯電話、携帯情報端末（ＰＤＡ）、製造用工具、１つ又は複数のプロセッサを備えた任意の装置等であっても良い）によってアクセス可能な形態で情報を記憶できる任意の機構を含む。例えば、機械アクセス可能な記憶媒体は、記録可能な／記録不能な媒体（例えば、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置等）などを含む。

用語「論理」は、本明細書で用いられているように、例えば、特定のソフトウェア及び／又はファームウェアでプログラムされたプログラマブル回路、特定目的のハードワイヤード回路、又はそれらの組み合わせを含むことができる。

上記の例に加えて、本発明の様々な他の変形形態及び変更形態が、本発明から逸脱せずに行われ得る。従って、上記の開示は、限定と見なされるべきではなく、添付の特許請求の範囲が、本発明の真の趣旨及び全範囲を包含すると解釈されるべきである。

Claims (20)

1. 複数のフロントエンドサーバにおいて、リアルタイムのユーザ活動に基づくログデータを生成すること、
   前記ログデータを集約サーバに送信すること、
   前記ログデータを前記集約サーバにおいて集約すること、
   前記ログデータを複数のログデータストリームに分割すること、
   前記ログデータストリームを少なくとも１つのバックエンドサーバに並列に供給すること、
   を備える方法。
2. 前記分割するステップは、
   前記ログデータが複数のログデータストリームに均等に分配されるように前記ログデータをランダムに分割することを含む、請求項１に記載の方法。
3. 前記ログデータをどのように前記複数のログデータストリームに分割するかに関しての命令を前記バックエンドサーバから受信することを更に備える請求項１に記載の方法。
4. 前記ログデータが複数のログデータエントリを含み、各ログデータエントリがアプリケーション識別及びカテゴリフィールドを含む、請求項１に記載の方法。
5. 前記ログデータの各エントリ用に、バケット合計数を法として、前記アプリケーション識別及び前記カテゴリフィールドのハッシュ関数によってバケット番号を計算することであって、前記バケット合計数が前記複数のログデータストリームの合計数であることと、
   前記ログデータのそのエントリを、前記バケット番号によって識別されたログデータストリームに割り当てること、
   を更に備える請求項４に記載の方法。
6. 前記カテゴリフィールドが、前記ログデータエントリの意図された宛先の高レベルの記述を含む、請求項５に記載の方法。
7. 前記アプリケーション識別が、前記ログデータエントリを処理するためのデータ消費アプリケーションを識別する、請求項５に記載の方法。
8. 前記ログデータが複数のログデータエントリを含み、
   当該方法が、
   各ログデータエントリ用に、１からバケット合計数までの整数をランダムに生成することであって、前記バケット合計数が前記複数のログデータストリームの合計数であることと、
   そのログデータエントリを、バケット番号によって識別されたログデータストリームに割り当てること、
   を更に備える請求項４に記載の方法。
9. バケット合計数が、前記ログデータストリームを受信するために利用可能なバックエンドサーバの数及び各バックエンドサーバが扱うことができる接続部の数によって決定される、請求項４に記載の方法。
10. バケット合計数が、少なくとも１つのバックエンドサーバ上を走るデータ消費アプリケーションによって指示される、請求項４に記載の方法。
11. 前記バックエンドサーバが前記ログデータストリームを受信して処理する場合に、前記バックエンドサーバに等しく負荷がかけられる、請求項９に記載の方法。
12. 前記ログデータのエントリの接頭部を検査して、エントリが割り当てられる前記ログデータストリームを決定することを更に備える請求項１に記載の方法。
13. 前記ログデータをデータウェアハウスに送信すること、
    前記データウェアハウスが、処理したログデータに基づいてデータ照会に応答することができるように、前記データウェアハウスにおいて前記ログデータを処理すること、
    を更に備える請求項１に記載の方法。
14. コンピュータ実行システムであって、
    リアルタイムのユーザ活動に基づくログデータを生成するように構成された複数のフロントエンドサーバと、
    ネットワークを介して前記複数のフロントエンドサーバのうちの少なくとも幾つかと接続され、前記複数のフロントエンドサーバのうちの少なくとも幾つかから受信した前記ログデータを集約するように構成された少なくとも１つの集約サーバと、
    を備え、
    前記集約サーバが、前記ログデータをステージングするように構成されたデータステージングエリアを含み、前記集約サーバは、１つ又は複数のバックエンドサーバが複数のログデータストリームを並列に検索できるように前記ログデータを複数のログデータストリームに分割するように構成されている、コンピュータ実行システム。
15. 前記ログデータが複数のログデータエントリを含み、各ログデータエントリがアプリケーション識別及びカテゴリフィールドを含み、
    前記集約サーバは更に、
    前記ログデータの各エントリ用に、バケット合計数を法として、前記アプリケーション識別及び前記カテゴリフィールドのハッシュ関数によってバケット番号を計算し、ここで、前記バケット合計数は前記複数のログデータストリームの合計数であり、
    前記ログデータのそのエントリを、前記バケット番号によって識別されたログデータストリームに割り当てる、
    ように構成されている、請求項１４に記載のコンピュータ実行システム。
16. 前記ログデータが複数のログデータエントリを含み、
    前記集約サーバが更に、
    各ログデータエントリ用に、１からバケット合計数までの整数をランダムに生成し、ここで、前記バケット合計数は前記複数のログデータストリームの合計数であり、
    そのログデータエントリを、バケット番号によって識別されたログデータストリームに割り当てる、
    ように構成されている、請求項１４に記載のコンピュータ実行システム。
17. バケット合計数が、１つ又は複数のバックエンドサーバ上を走るデータ消費アプリケーションデータによって指示され、前記バケット合計数が、前記ログデータストリームを受信するために利用可能なバックエンドサーバの数、及び各バックエンドサーバが扱うことができる接続部の数によって決定される、請求項４に記載の方法。
18. 集約サーバであって、
    プロセッサと、
    前記プロセッサに結合され、当該集約サーバが複数のフロントエンドサーバと通信することを可能にするネットワークインターフェースと、
    データステージングエリアを含むデータ記憶装置と、
    前記プロセッサによって実行されることで当該集約サーバが以下を含む処理を行うことを可能にする命令を格納するメモリと、
    を備え、前記処理が、
    前記フロントエンドサーバからログデータを受信することであって、前記フロントエンドサーバが、リアルタイムのユーザ活動に基づいて前記ログデータを生成することと、
    前記ログデータを集約すること、
    前記データステージングエリアにおいて前記ログデータをステージングすること、
    １つ又は複数のバックエンドサーバがログデータストリームを並列に検索できるように、前記ログデータを複数のログデータストリームに分割すること、
    を含む、集約サーバ。
19. 前記ログデータが複数のログデータエントリを含み、各ログデータエントリがアプリケーション識別及びカテゴリフィールドを含み、
    前記処理が、
    前記ログデータの各エントリ用に、バケット合計数を法として、前記アプリケーション識別及び前記カテゴリフィールドのハッシュ関数によってバケット番号を計算することであって、前記バケット合計数が前記複数のログデータストリームの合計数であることと、
    前記ログデータのそのエントリを、前記バケット番号によって識別されたログデータストリームに割り当てること、
    を更に含む、請求項１８に記載の集約サーバ。
20. 前記ログデータが複数のログデータエントリを含み、
    前記処理が、
    各ログデータエントリ用に、１からバケット合計数までの整数をランダムに生成することであって、前記バケット合計数が前記複数のログデータストリームの合計数であることと、
    そのログデータエントリを、バケット番号によって識別されたログデータストリームに割り当てること、
    を更に含む、請求項１８に記載の集約サーバ。