JP5818263B2

JP5818263B2 - データの分散管理システム及び装置及び方法及びプログラム

Info

Publication number: JP5818263B2
Application number: JP2012108849A
Authority: JP
Inventors: 后宏水谷; 修明石; 健介福田
Original assignee: Nippon Telegraph and Telephone Corp; Inter University Research Institute Corp Research Organization of Information and Systems
Current assignee: Nippon Telegraph and Telephone Corp; Inter University Research Institute Corp Research Organization of Information and Systems
Priority date: 2012-05-10
Filing date: 2012-05-10
Publication date: 2015-11-18
Anticipated expiration: 2032-05-10
Also published as: JP2013235515A

Description

本発明は、データの分散管理システム及び装置及び方法及びプログラムに係り、特に、複数のメタデータ（行動履歴、RFID(Radio Frequency Identification)、センサ情報）を分散管理する構造化オーバレイネットワーク上において、時系列データなどの連続データの効率的な管理と、当該連続データの解析の並列性を最大化するためのデータの分散管理システム及び装置及び方法及びプログラムに関する。

近年、ビッグデータと呼ばれる莫大なWebの情報やセンサ情報を解析することで、Webの閲覧履歴から検索広告のパーソナライゼーションを行ったり、自動車のセンサ情報を集約し解析することで渋滞を予想することが可能になった（例えば、非特許文献1参照）。しかし、ビッグデータはあまりに膨大なため、単一計算機での解析は不可能とされている。従って、ビッグデータを効率的に解析するためには、分散処理が不可欠となり、多くの分散処理モデルが提案されている（例えば、非特許文献2，3参照）。その中でもMapReduceと呼ばれる概念は、規模拡張性に優れ、実装の容易さや分散処理を行うためのスキームの定義が柔軟であるという点から、ビッグデータの解析に幅広く応用されるようになった（例えば、非特許文献4，5参照）。MapReduceは、大きくMapとShuffleとReduceの処理に分かれており、各処理における動作は互いに独立しているため、並列的に解析を行うことができる。Map処理ではビッグデータをある計算単位に分割し、Shuffle処理では分割したデータを任意のノード（計算機資源）に統合し、Reduce処理では集約したデータの統計処理などを行う。

しかし、既存のMapReduceを用いた情報解析システムには大きな問題が二つある。一つは、Map処理によって分割されたデータのハッシュ値を用いて、Shuffle処理を行うことにより、分割されたデータの連続性を消失してしまう点である。MapReduceでは、連続性があるデータが、特定のノードに対して集中する可能性を考慮し、各データのハッシュ値を用いてShuffleを行う事で、後のReduce作業における処理の偏りを解消する狙いがある。このため連続性のあるデータを集約して、前後関係を参照するような解析をすることは難しい。

もう一つの問題は、再帰的なMapReduceを行うことが難しいことである。MapReduceによって、データを集約・解析を行った結果を再度、他のノードに対してMapReduceを行う際には、解析結果を集約するための集約ノードの選定を行わなければならない。再帰的なMapReduceの計算効率（並列性）を最大化するためには、全てのノードが平衡木の集約構造を維持しなければならない。しかし、平衡木の集約構造を持たせることで、再帰的な解析を行う際の負荷をノード間で均一化することができるが、平衡木のメンテナンスコストは非常に高くなるという問題がある。具体的には、平衡木を構築する際に、木の左右のバランスをとるために、何度も木を再構築しなければならないという問題点がある。

以下では、MapReduceを用いた既存の情報解析システムの中でも、MapReduceを再帰的に行うことが可能な"Jubatus"（登録商標）と構造化オーバレイを用いて規模拡張性に優れた情報解析システムを達成している"ddd"について述べ、各システムが再帰的な解析と連続データの管理を同時に満たすことができない理由を述べる（例えば、非特許文献７，８参照）。

"Jubatus"（登録商標）はOpen Sourceとして提供されているMapReduceを用いた情報解析システムである。"Jubatus"（登録商標）のアーキテクチャを図１に示す。"Jubatus" （登録商標）では、Map機能を行うクライアントに対して、"JubaKeeper"というMap機能とShuffle機能を提供している。クライアントが、形態素解析などのジョブを"JubaKeeper"に送ると、"JubaKeeper"はMap処理とShuffle処理を行い、Reduceを担当する"JubaKeeper"に対して、データを転送する。"Jubatus"（登録商標）では、"JubaClassifier"における解析スキームをクライアントが記述することができるため、"JubaClassifier"間でReduce結果を集約（MIX処理）する事で、再帰的な解析ができる。なお、MIX処理を行う際には、全てのノードにおける一貫性や保守を一元管理している"ZooKeeper"を通して、MIX処理の対象となるノードの資源をロックした上で、データのMIX処理を行う。なおロック中に、当該ノードに対して送られてきたデータは破棄される。"Jubatus"（登録商標）における集約ノードの管理は、"ZooKeeper"に一任しているため、"ZooKeeper"が単一障害点になりえてしまうという問題点があり、規模拡張性は薄い。また、解析データとして連続データを扱うことも可能であるが、連続データに対してMIX処理を行う際の集約ノードの選定は、クライアントの解析スキームに依存する。また、各ノードの状態やKeyの全体の分布などが判明しない限りは、集約構造を平衡木として扱うことは難しく、解析の並列性を最大化できるとは限らない。

"Jubatus"（登録商標）に対して"ddd"は、全てのノードを構造化オーバレイによって管理することにより、MapReduceの規模拡張性を向上させている。"ddd"のアーキテクチャを図２に示す。"ddd"では、ハッシュ化したデータに対してShuffle処理を行い、Consistent Hashing法に基づく構造化オーバレイ上のノードに配置するため、連続データを扱うことができない（例えば、非特許文献９参照）。ただ、"ddd"にて連続データを扱うことは可能である。連続データを扱う際には、データによって負荷が偏ってしまう問題がある。この問題を解決するために、"ddd"ではノード間で発生する負荷の偏りを、バーチャルノードを用いて解決している。バーチャルノードを用いた負荷分散は、構造化オーバレイ上の各ノードが、自身の仮想的なノードを多数生成し、構造化オーバレイ上のID空間を仮想ノードで埋め尽くす事によって、各ノードに対する負荷を均一化する。バーチャルノードによる負荷分散を用いた場合、入力データが連続データであったとしても、構造化オーバレイ上で負荷を均一にすることができる。ただ、バーチャルノードの数は予め決める必要があるため、連続データの分布によっては、必ずしも負荷が平均化されるわけではない。さらに、再帰的なReduce処理を行う際には、ユーザがReduceの再帰処理を記述しなければならないため、"Jubatus"（登録商標）と同様の理由により、平衡木構造を構築することが難しい。

S4 Project, http://incubator.apache.org/s4/ Leslie G Valiant, "A Bridging Model for Parallel Computation," Communications of the ACM, Volume 33 Issue 8, Aug. 1990. http://www.cs.berkeley.edu/matei/spark/ Hadoop, http://lucene.apache.org/hadoop/, 2007. J. Dean and S. Ghemawat, "MapReduce: Simplified Data Processing on Large Clusters," in OSDI 2004: 6th Symposium on Operating Systems Design and Implementation, 2004. P. William, "Skip Lists: A Probabilistic Alternative to Balanced Trees," Communications of the ACM, 1990. Jubatus, http://jubat.us/ ddd, http://www.iij.ad.jp/development/tech-activities/detail/ddd.html D. Karger, et al, "Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web," in Proc. ACM Symposium on Theory of Computing, 1997.

このように、MapReduceにおける規模拡張性や再帰的なReduce処理に関する基礎検討は行われているが、これらの処理の最適化手法には言及されていない。つまり、規模拡張性や並列性に富み、連続データに対しても効率的な運用管理を達成できる情報解析システムを構築することは既存技術では困難と考えられる。

本発明は、上記の点に鑑みなされたもので、構造化オーバレイ上における、解析時間の短縮と連続データの解析が可能なデータの分散管理システム及び装置及び方法及びプログラムを提供することを目的とする。

上記の課題を解決するため、本発明（請求項１）は、複数のノードが複数のメタデータを分散管理する構造化オーバレイネットワークにおけるデータの分散管理システムであって、
前記ノードは、
構造化オーバレイ管理手段と、MapReduce処理管理手段と、を有し、
前記構造化オーバレイ管理手段は、
複数の前記ノードが持つデータをノード間で負荷が均一化するように制御する負荷分散手段と、
前記負荷分散手段によって前記制御がなされたデータを解析するために、各ノード間の接続が平衡木となるように構造化する構造化手段と、を有し、
前記MapReduce処理管理手段は、
前記構造化オーバレイネットワークに対して発信されるデータを蓄積するデータ蓄積手段と、
前記データ蓄積手段に蓄積されたデータを解析するための解析スキームを管理する解析管理手段と、
前記解析スキームによる解析結果を他ノードに対して送信するとともに、他ノードから解析結果を受信して組み合わせる解析結果統合手段と、を有する。

また、本発明（請求項２）は、前記MapReduce処理管理手段において、
ノード間の接続関係を平衡木の木構造として維持し、該平衡木の木構造にしたがって、複数のメタデータを計算単位のデータに分割するMap処理、分割したデータを担当するノードに転送するShuffle処理、各ノード装置の解析結果を集約して処理するReduce処理を行うMapReduce処理手段を含む。

また、本発明（請求項３）は、前記負荷分散手段において、
自ノードが根ノードである場合に、前記平衡木の木構造に従って集約した各ノードの負荷情報に基づいて、所定の判別式により負荷が低いノードと負荷が高いノードを判別し、負荷が高いノードが管理するID空間の中からノード間で負荷が均一になるようなハッシュIDを選択し、負荷が低いノードに対して選択したハッシュIDを追加する手段を含む。

上記のように本発明によれば、規模拡張性や並列性に富むと共に、時系列データなどの連続データに対しても、各ノード装置が持つデータ量を均一化することができ、効率的な運用管理を達成できる情報解析システムが実現できる。

"Jubatus"(登録商標)のアーキテクチャである。 "ddd"のアーキテクチャである。本発明の一実施の形態におけるSkipListを用いた構造化オーバレイ上におけるMapReduceの動作概要である。本発明の一実施の形態におけるノード構成図である。本発明の一実施の形態における解析データの集約構造である。本発明の一実施の形態におけるルーティングテーブルの構築処理のシーケンスチャートである。本発明の一実施の形態における負荷分散手法の概要である。本発明の一実施の形態における負荷分散のシーケンスチャートである。本発明の一実施の形態におけるShuffle処理の検索手順である。本発明の一実施の形態における解析スキームの配布と実行手順を示す図である。本発明の一実施の形態における負荷の均一化処理のシーケンスチャートである。本発明の一実施の形態における解析プロセスのシーケンスチャートである。

以下、図面と共に本発明の実施の形態を説明する。

本発明は、Publisher/Subscriberシステムと類似している。Publisher/Subscriberシステムとは、メールマガジンなどの配信サービスで用いるシステムであり、クライアント（Subscriber）がサーバ（Publisher）に対して購読登録用インタフェースを通して、購読したいメールマガジンを登録しておく。サーバがメールマガジンを発行する際には、当該メールマガジンの購読者に対して、Push型配信を用いてメールマガジンを発行する。Publisher/Subscriberシステムを本発明に当てはめると、様々なセンサやモニタから定常的に発信（Publish）されるデータをSkipListを用いた構造化オーバレイ上で蓄積（Shuffle）し続ける。ユーザが蓄積したデータに対して何らかの解析を行う時、ユーザは自身が記述した解析スキームをSkipListに対してSubscribe（発行）することによって、一時的・定期的に並列解析を行った結果を得ることができる。

図３にSkipListを用いた構造化オーバレイ上におけるMapReduceの動作概要を示す。SkipList上で動作するノードに対して、大量のデータが到着し、当該データをSkipList上でShuffle（蓄積）を行う。さらに、蓄積されたデータを、SkipListにおける平衡木に従って再帰的にReduce処理を行う。

また、図４にSkipListを用いたMapReduceを達成するために必要な装置構成を示す。

MapReduce処理管理部(MapReduce処理の管理モジュール)１００はユーザが発行する解析スキームを保存するアナリシススキームバッファ（Analysis Scheme Buffer）１１０、解析結果の同期部（Analysis Scheme Coordinator）１２０、連続データを蓄積するデータバッファ（Data Buffer）１３０が実装されている。なお、MapReduce処理管理部１００から発行される解析スキームの伝搬には構造化オーバレイ管理部２００が提供するAPI（Scatter API）を利用する。

構造化オーバレイ管理部(構造化オーバレイの管理モジュール)２００では、SkipListの構築や維持を行う機能を有するSkipListマネージャ（SkipListManager）２１０やSkipList上で負荷分散を行う機能を有する負荷分散部（Load Balancing Executor）２２０が実装されている。なお、通信部３００ではTCPプロトコルを用いたデータの送信部（Sender）３１０や受信部（Receiver）３２０が実装されている。なお、通信部３００はOSに実装されているTCP Socketを利用しデータの送受信を行うためだけのモジュールなので、説明は省略する。

以下では、SkipListを用いた集約構造とその構築手順を説明し、連続データに対する負荷の均一化手法についても述べる。また、解析スキームをSubscribeする方法についても簡潔に述べる。

最初に、構造化オーバレイ管理部２００について説明する。

構造化オーバレイ管理部２００は、SkipListマネージャ（SkipList Manager）２１０と負荷分散部２２０を有する。

SkipListマネージャ２１０は、ルーティングバッファ２１１を具備している。

SkipListは平衡木の一種で、AVL木やB木などと異なり、木の深さを一定にするための処理（木の再構成）を行わない（例えば、非特許文献６参照）。そのため、容易に平衡木を構築することができるため、MapReduceを用いた解析の並列性を容易に向上させることができる。本構造をノード間の集約構造に適用するために、まず各ノードに対して2つのIDを持たせる。一つは、ハッシュ値となっており、"ddd"と同様にConsistent Hashingを行うために利用する。もう一つのIDはレベルというもので、このレベルに従ってノードの集約構造を階層化し、ノード同士の関係性を木構造にする。例えば、平衡N分木を構築する場合、各ノードがレベルiに存在する確率は(1/N)ⁱとなり、ｉ以下のレベルにも同時に属する。従って、各ノードのレベルは乱数RAND（0≦RAND＜1）を用いて、

と計算できる。[]はガウス記号で、[a]はaを超えない最大の整数を意味する。なお以下では[a， b]や[a， b)のような表現が頻出するが、[a， b]はa以上b以下を意味し、[a， b)はa以上bより小さいを意味する。さらに、(a， b]はaより大きくb以下を意味し、(a， b)はaより大きくbより小さいことを意味する。

レベルiのノードpのハッシュＩＤ（HashID: p）は、レベルi以下の各レベルにて、時計回り・反時計回りの隣接ノードをSuccessor、Predecessorとして当該ノード情報（HashIDとIP Address）をルーティングバッファ２１１内のルーティングテーブルに記録する。以下では、ノードpのレベルk（0≦k≦i）におけるSuccessorのHashIDをs_p，kとし、レベルkのPredecessorのHashIDをp_p，kとする。また、ノードpが担当するID空間は、p_p，0＜pを満たす時、(p_p，0， p]とする。また、p＜p_p，0を満たす時、ノードpが担当するID空間は(p_p，0， L)、[0， p]とする（LはID空間全体のサイズであり、HashID: LはHashID: 0と同値となっており、ID空間はリング型の構造になっている）。なお、以下では上記の範囲を纏めて、(p_p，0， p]とする。

なお、ノードpが担当するID空間とは、Shuffle処理の際に配置されるデータのHashIDの範囲を意味する。例えば、ノードpが担当するID空間が10から100とする。この時、HashIDが45や76のデータはノードpが保持することになる。

さらに、レベルk（1≦k≦i）にて、HashIDが[p， s_p，k)を満たすレベルk-1のノード群を子ノードとして当該ノード情報を保持し、レベルiで自身のHashIDであるpを子として保持しているノードを親としてノード情報をルーティングバッファ２１１に保持する。なお、ノードpが担当するID空間と子ノードのID空間を逆方向に定める理由は、子ノードが担当するID空間とノードpが担当するID空間が重って冗長になることを避けるためである。ノード数をN^q（0＜N、0≦q）とした時、LEVEL＞qを満たす場合、レベルはqとする。なお、レベルqのノードを根ノードとし、SkipList上の分散計算を統括する役割を果たす。レベルqに属する根ノードが複数存在する場合、レベルqにおけるSuccessorのHashIDが自身のHashIDよりも小さいと判断したノードが、レベルq+1に所属することにし、レベルqのノード群を子に持つ。なお、これらの子ノード、親ノード、ルーティングテーブル（SuccessorとPredecessorノードの情報）はルーティングバッファ２１１に保存される。

上記のような解析データの集約構造の例を図５に示す。

図５では、10台のノードから構成されるSkipList構造を示しており、各ノードの番号はHashIDを表している。ノード2はレベル0にてノード1，3を、レベル1も同様にノード0，4をSuccessor、Predecessorノードとしてルーティングテーブルに記録している。さらに、ノード2はレベル0のノード3を子ノードとして記録しており、レベル2のノード0を親ノードとして記録している。ノード2と同様に、ノード0もルーティングテーブル、親ノード、子ノードの情報を保持している。なお、レベル2において、ノード0と隣接するノードが存在しないため、当該ノードが根ノードとなっている。

次に、SkipListの具体的な構築方法を述べる。なお、ノードがSkipList構造に加入する処理のことを"Join処理"と定義する。Join処理は、ノードpが担当するID空間を決定し、親ノード、子ノードを決定し、ルーティングバッファ２１１内にルーティングテーブルを構築するための手順を意味する。

図６は、本発明の一実施の形態におけるルーティングテーブルの構築処理のシーケンスチャートである。

まず、ノードP のSkipListマネジャ２１０(P)は、自身のHashIDであるpを、SkipList上に存在している任意のノードに対して、pを担当するノードを探索するメッセージ（Joinメッセージ）を送る（ステップ１０１）。当該メッセージを受けたレベルaのノードbのSkipListマネージャ２１０(ａ)は、自身のルーティングテーブルに記録している全てのSuccessorのノード情報に対して、[b， s_{b, i})（0≦i≦a）の範囲にpが含まれているかどうかを調べる（ルーティングテーブルの上位から調べる）（ステップ１０２）。[b， s_{b, i})にpが含まれていた場合、当該範囲の子ノードの中で、pに最も近く、pを超えないHashIDを持つ子ノードに対して、当該メッセージを転送する（ステップ１０３）。含まれていない場合、親ノードに対して、当該メッセージを転送し、親ノードに対してJoin処理を委託する（ステップ１０４）。

なお、本転送は、時計回り方向に対して行われる。この転送処理をノード間で再帰的に繰り返すことにより、pを担当するノードに当該メッセージが到達する。pを管理するノードをノードmとした時、ノードmはノードpに対して自身の親、子ノード、ルーティングテーブルの情報を転送すると同時に、pを自身のルーティングテーブル、親、子ノードの情報に対して転送することにより反映する。以上の手順によって、各ノードがSkipList構造に対してJoin処理を完了し、SkipList構造が構築される。

次に、負荷分散部２２０について説明する。

構造化オーバレイ上で連続データの負荷分散を行うために各ノードがオーバレイ上をランダムウォークするクエリ（Sampling Query）を投げ、オーバレイ上のノードをランダムに選択しつつ、当該ノードの負荷情報を集めて、全体の負荷を推定する方法がある（例えば、A. R. Bharamde, M. Agrawal, and S. Sechan, "Mercury: Scalable Routing for Range Queries," in ACM SIGCOMM, 2004.参照）。この手法における問題点として、規模に応じて、Sampling Queryの送信回数を適切に指定する必要があり、集めた負荷情報を元にした全体の推定精度に影響を与える可能性がある。

既存技術に対して、本発明の負荷推定技術は、SkipListの集約構造を用いることで規模に依存せず全体の負荷の推定を的確に行うことが可能になっている。図７に負荷分散手法の概要を示す。具体的には、各ノードの構造化オーバレイ管理部２００の負荷分散部２２０が自身の負荷情報を親ノードに対して送信し、親ノードの負荷分散部２２０は負荷のランキングを作成する。ランキングは、子ノードから送信されてきた負荷情報から、負荷の高い順にノード情報をソートし、上位R（1≦R）番目までのノード情報と下位R（1≦R）番目までのノード情報を抽出する処理を根ノードまで再帰的に繰り返し転送する。根ノードの負荷分散部２２０は、負荷情報を参考に負荷の低いノードに負荷の高いノードが管理するID空間の中から負荷が均一になるようなHashIDをルーティングバッファ２１１のルーティングテーブルから選択し、当該負荷の低いノードに対してHashIDを追加するように指示する。さらに、当該ノードに負荷の高いノードに対して追加したHashIDを用いてJoinメッセージを送信するよう命令し、負荷の均一化を図る。なお、負荷の高いノードと負荷の低いノードを区別する判別式を以下に示す。根ノードが受け取ったランキングのi（1≦i≦R）番目の負荷情報をL_i、全体の負荷の平均値をAVG、ランキングのi番目の負荷値をQ_iとし、定数α（0＜α＜1）を用いて、Q_iは、

と表すことにする。なお、以下で説明するランキングとは、集約した上位・下位のランキングを一体化した、1から2Rまでの順位を持つランキングと見なす。

図８に負荷分散の動作のシーケンスチャートを示す。根ノードの構造化オーバレイ管理部２００の負荷分散部２２０において、式（２）を用いて、まずランキング1位の負荷情報L₁とランキング2R位の負荷情報L_2Rの負荷値Q₁，Q_2Rを求め、Q₁＝1、Q_2R＝0を満たす場合、根ノードは、L₁のノード（以下「ノード1」と記す）に対して、L_2Rのノード（以下、「ノード2R」と記す）がID空間の分割要求を行うように、ノード2Rに命令する（ステップ２０１）。その結果、ノード2Rの負荷分散部２２０は、ノード1のIPアドレスを根ノードから教えてもらい、ノード1に対して、自身の負荷情報L_2Rを通知する（ステップ２０２）。L_2Rを知ったノード1は、負荷分散部２２０において、自身の負荷L₁'が (L₁＋L_2R)/2となる様に、自身のID空間を分割し（ステップ２０３）、ノード2Rに対して分割したID空間と当該ID空間に関連するデータ群を、ノード2Rに送信し、ノード2Rは、MapReduce処理管理部１００のデータバッファ１３０に蓄積する（ステップ２０４）。

なお、根ノードはノード1およびノード2Rのノードに対してID空間の分割要求を通知した後、次はノード2とノード2R-1に対しても同様の処理を行う。本処理は負荷の高いノードと負荷の低いノードの負荷値が1，0とならなくなるまで繰り返す。各負荷値が1、0とならない場合、根ノードは負荷分散を終了し、全体の負荷分散が完了する。なお、この負荷分散の処理は、根ノードにて一定時間間隔で行われるものとし、負荷情報を各ノードの親ノードに対して送信する命令を根ノードから送信し、各ノードの親ノードから子ノードに対して発行されるStabilizationメッセージに付加され、上層から下層のノードに転送されていく。これにより、負荷分散処理に必要なメッセージ数を抑制することができる。

次に、Shuffle処理について説明する。

センサやモニタから発行されたデータn（HashID: n）がノードpに到着したとする。データnに対してShuffle処理を行う際、ノードpは当該データを担当するノードに当該データを転送しなければならない。転送方法は図６で示した構築方法と同様の転送方法を用いる。

具体的な検索手順を図９を用いて説明する。ID空間が10台のノード（０〜９）によって管理されており、各ノードが反時計回りに隣接するノード（Predecessor）間のIDを管理するものとする。さらに、当該ID空間は時間をIDにしたトラヒックデータを管理するものとし、時刻3:45のデータはノード4が管理し、時刻5:54のデータはノード6が管理するものとする。この時、ノード4に対して、時刻8:37のデータが到着し、当該データを管理するノードに転送（Shuffle）する処理の手順を考える。

まず、ノード4のSkipListマネージャ２１０(4)は自身のルーティングテーブルを参照し、8:47が4と自身の経路情報全ての間に含まれるかどうか当該ルーティングテーブルの上位から調べる。この時、ルーティングテーブル上のどのSuccessorの間にも8:47が属さないと判断することができる。ノード4のSkipListマネージャ２１０(4)は親ノードであるノード0に対して、8:47のデータを管理するノードを探索するためのLookUpメッセージを転送することにする。LookUpメッセージを受信したノード0は、LookUpメッセージの宛先である8:47を読み取り、自身のルーティングテーブルの上位から、8:47を含むSuccessorを調べた結果、8:47を管理するノードを発見できなかったとする。次に、親、子ノードから8:47を管理するノードがあるかどうかを調べ、ノード8が管理していると判断し、ノード8に対して、当該LookUpメッセージを転送する。当該LookUpメッセージを受け取った、ノード8は自身のルーティングテーブルを上位から調べ、ノード9が8:47のデータを管理していると確定することができ、当該メッセージの送信元であるノード4に対して、ノード9のIPアドレスを伝達する。ノード9のIPアドレスを知ったノード4は8:47のデータをノード9に対して転送することによって、Shuffle処理が完了する。なお、Shuffle処理が完了すると、当該データはノード9のSkipListマネージャ２１０(9)Managerから上層のMapReduce処理管理部１００の中のデータバッファ１３０に対して自動的に蓄積される。

なお、センサやモニタから発行されたデータに対してShuffle処理を行う際の通信回数は、ノード数をnとすると1データあたり2log(n)となっており、ノード数が増えたとしてもShuffle処理を行う際の通信コストの増加率は低いため、規模拡張性に優れたShuffleを実現していることがわかる。

次に、SkipListマネージャ２１０における、SkipListの維持するための方法について説明する。

SkipListを維持するために、各ノードのSkipListマネージャ２１０が各レベルのSuccessor、Predecessor、および親ノードに対して定期的にStabilizationメッセージを送信し、ノードの生存・離脱を確認する。応答がない場合は、離脱と判定し、SuccessorやPredecessor、Parentの候補となるノードを再度検索し、代替ノードの情報を得ることで、SkipList構造を更新する。

この手順以外にも、SuccessorとPredecessorの数を増やすことで、容易にSkipList構造を維持することが可能になる。具体的には、各ノードが自身のSuccessorのSuccessorの情報やPredecessorのPredecessorの情報を持つということである。こうすることで、Successorが離脱しても、瞬時に、当該SuccessorのSuccessorに対して接続関係を結ぶだけで、SkipListの構造を維持することができる。

次に、MapReduce処理管理部１００の処理を説明する。

SkipListに対して、解析スキームと呼ばれるユーザが定義する解析内容の反映方法を述べる。図１０に解析スキームの配布と実行手順の概要を示す。解析スキームは任意のノードに対して投入することができ、ユーザは、解析スキームに解析スキームの識別子（AID）を付けて投入する。解析スキームを全ノードに反映するために当該MapReduce処理管理部１００は、Scatter（AnalysisScheme）という構造化オーバレイ管理部２００が提供するAPIを用いる。Scatter APIを用いて、解析スキームの配布を構造化オーバレイ管理部２００に対して依頼すると、まず解析スキームを投入されたノードのSkipListマネージャ２１０は根ノードを探索する。根ノードを発見すると、当該根ノードに対して、ScatterAnalizerメッセージを転送し、根ノードが自身の子ノードに対して当該メッセージを転送する。ScatterAnalizerメッセージはユーザが定義した解析スキームと共にSkipListの木構造に従って、各ノードに対して再帰的に転送される。ScatterAnalizerメッセージを受け取った各ノードは、自身の同期部１２０（Scheme Coordinator）に対して、当該スキームのAIDと当該スキームを登録する。同期部１２０は、登録されている解析スキームの保存や、解析スキームの実行時において、子ノードからの解析結果の同期を行う。

以下に、解析例を示す。

全てのノードに対して、1日のトラヒックデータが保存されているとする。トラヒックデータは時系列データであり、昼間のトラヒックデータは少ないが、夜間のトラヒックデータは莫大に存在しているものとする。これらのデータがShuffle処理によって、各データの担当ノードに対して転送され、各担当ノードは当該トラヒックデータを管理しているものとする。なお、トラヒックデータは時刻と通信端末のIPアドレスから構成しているものとする。このトラヒックデータから、通信回数が最も多い100位までの通信端末のIPアドレスを特定するといった内容の解析スキームをSkipList上のノードに反映していたとする。

・負荷の均一化
ここでは、負荷の高いノードと低いノードのID空間の負荷の均一化について説明する。

図１１は、本発明の一実施の形態における負荷の均一化処理のシーケンスチャートである。

一定時間間隔で、根ノードの構造化オーバレイ管理部２００のSkipListマネージャ２１０は、自身の子ノードに対して負荷情報の転送を依頼する（ステップ３０１）。その後、子ノードは自身の子ノードに対して当該依頼を転送する（ステップ３０２）。これらの処理を再帰的に行うことによって、レベル0のノード群に対して負荷情報の転送依頼が到達する(ステップ３０３)。レベル0のノードは、自身の負荷情報としてトラヒックデータの総量を親ノードに伝達する（ステップ３０４）。各親ノードから負荷情報を受信した親ノードは、負荷情報のランキングを作成し（ステップ３０５）、再度、自身の親ノードに対して転送する（ステップ３０６）。この処理を再帰的に行うことによって、根ノードにランキングが伝達される(ステップ３０７)。ランキングを受け取った根ノードは、負荷文ｓ何部２２０において、負荷の低いノードを負荷の高いノードが担当するID空間に対して、Join処理を行うように命令する（ステップ３０８）。例えば、負荷の高いノードの負荷が100、負荷の低いノードの負荷が10としたとき、負荷の低いノードは10と100の中間である55の負荷になるように、負荷の高いノードからID空間を分けてもらい、分けてもらったID空間に対してJoin処理を行う。これを繰り返すことによって、連続データの負荷の隔たりを解消することができる。

・解析プロセス
MapReduce処理管理部１００における当該解析プロセスの動作を図１２に示す。

まず、各ノードが自身のMapReduce処理管理部１００の中のデータバッファ１３０内で管理するトラヒックデータから、通信端末のIP毎の通信回数のランキングを作成し（ステップ４０１）、上位100位までの通信端末のIPとその端末の通信回数を親ノードに転送する（ステップ４０２）。各親ノードは自身が管理する全ての子ノードから、ランキングが送られてくるまで待機し（ステップ４０３）、ランキングの結果が揃ったところで（ステップ４０４，４０５）、再度、100位までのランキングを受信データから作成し（ステップ４０６）、自身の親ノードに対してランキングを転送する(ステップ４０７)。このランキングの作成を再帰的に行うことによって、根ノードに対してランキングが到着する。根ノードにてランキングを再度構成した後に（ステップ４０８）、AIDに登録されている解析を依頼したノードに対して解析結果を転送する(ステップ４０９)。この時、各ノードの計算量は、負荷分散部２２０によって連続データであるトラヒックデータの負荷の偏りが平滑化されており、さらに各解析が平衡木の構造を持つ構造化オーバレイ上で再帰的に行われることにより、解析の並列性を最大化することができる。

なお、上記の図４に示すノードのMapReduce処理管理部１００、構造化オーバレイ管理部２００、通信部３００の各構成要素を、それぞれソフトウェア（プログラム)として構築し、MapReduce処理管理モジュール、構造化オーバレイ管理モジュール、通信モジュールとし、ノードとして利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させること可能である。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。

１００ MapReduce処理管理部
１１０ Analysis Schemeバッファ
１２０同期部（Analysis Scheme Coordinator）
１３０データバッファ
２００構造化オーバレイ管理部
２１０ Shipマネージャ
２１１ルーティングバッファ
２２０負荷分散部(Load Balancing Executor)
３００通信部
３１０送信部
３２０受信部

Claims

複数のノードが複数のメタデータを分散管理する構造化オーバレイネットワークにおけるデータの分散管理システムであって、
前記ノードは、
構造化オーバレイ管理手段と、MapReduce処理管理手段と、を有し、
前記構造化オーバレイ管理手段は、
複数の前記ノードが持つデータをノード間で負荷が均一化するように制御する負荷分散手段と、
前記負荷分散手段によって前記制御がなされたデータを解析するために、各ノード間の接続が平衡木となるように構造化する構造化手段と、を有し、
前記MapReduce処理管理手段は、
前記構造化オーバレイネットワークに対して発信されるデータを蓄積するデータ蓄積手段と、
前記データ蓄積手段に蓄積されたデータを解析するための解析スキームを管理する解析管理手段と、
前記解析スキームによる解析結果を他ノードに対して送信するとともに、他ノードから解析結果を受信して組み合わせる解析結果統合手段と、を有する
ことを特徴とするデータの分散管理システム。
前記MapReduce処理管理手段は、
ノード間の接続関係を平衡木の木構造として維持し、該平衡木の木構造にしたがって、複数のメタデータを計算単位のデータに分割するMap処理、分割したデータを担当するノードに転送するShuffle処理、各ノード装置の解析結果を集約して処理するReduce処理を行うMapReduce処理手段を含む
請求項１記載のデータの分散管理システム。
前記負荷分散手段は、
自ノードが根ノードである場合に、前記平衡木の木構造に従って集約した各ノードの負荷情報に基づいて、所定の判別式により負荷が低いノードと負荷が高いノードを判別し、負荷が高いノードが管理するID空間の中からノード間で負荷が均一になるようなハッシュIDを選択し、負荷が低いノードに対して選択したハッシュIDを追加する手段を含む
請求項１記載のデータの分散管理システム。
複数のノードが複数のメタデータを分散管理する構造化オーバレイネットワークにおけるデータの分散管理システムが有する前記ノードとして機能するデータ分散管理装置であって、
構造化オーバレイ管理手段と、MapReduce処理管理手段と、を有し、
前記構造化オーバレイ管理手段は、
複数の前記ノードが持つデータをノード間で負荷が均一化するように制御する負荷分散手段と、
前記負荷分散手段によって前記制御がなされたデータを解析するために、各ノード間の接続が平衡木となるように構造化する構造化手段と、を有し、
前記MapReduce処理管理手段は、
前記構造化オーバレイネットワークに対して発信されるデータを蓄積するデータ蓄積手段と、
前記データ蓄積手段に蓄積されたデータを解析するための解析スキームを管理する解析管理手段と、
前記解析スキームによる解析結果を他ノードに対して送信するとともに、他ノードから解析結果を受信して組み合わせる解析結果統合手段と、を有する
ことを特徴とするデータ分散管理装置。
前記MapReduce処理管理手段は、
ノード間の接続関係を平衡木の木構造として維持し、該平衡木の木構造にしたがって、複数のメタデータを計算単位のデータに分割するMap処理、分割したデータを担当するノードに転送するShuffle処理、各ノード装置の解析結果を集約して処理するReduce処理を行うMapReduce処理手段を含む
請求項４記載のデータの分散管理装置。
前記負荷分散手段は、
自ノードが根ノードである場合に、前記平衡木の木構造に従って集約した各ノードの負荷情報に基づいて、所定の判別式により負荷が低いノードと負荷が高いノードを判別し、負荷が高いノードが管理するID空間の中からノード間で負荷が均一になるようなハッシュIDを選択し、負荷が低いノードに対して選択したハッシュIDを追加する手段を含む
請求項４記載のデータの分散管理装置。
複数のノードが複数のメタデータを分散管理する構造化オーバレイネットワークにおけるデータの分散管理システムが行うデータの分散管理方法であって、
前記ノードは、
構造化オーバレイ管理手段と、MapReduce処理管理手段と、を有し、
前記構造化オーバレイ管理手段が、複数の前記ノードが持つデータをノード間で負荷が均一化するように制御し、該制御がなされたデータを解析するために、各ノード間の接続が平衡木となるように構造化する構造化オーバレイ管理ステップと、
前記MapReduce処理管理手段が、前記構造化オーバレイネットワークに対して発信されるデータを蓄積し、該データ蓄積手段に蓄積されたデータを解析するための解析スキームを管理し、該解析スキームによる解析結果を他ノードに対して送信するとともに、他ノードから解析結果を受信して組み合わせるMapReduce処理管理ステップと、
を行うことを特徴とするデータの分散管理方法。
前記構造化オーバレイ管理ステップにおいて、複数の前記ノードが持つデータをノード間で負荷が均一化するように制御する際に、
自ノードが根ノードである場合に、前記平衡木の木構造に従って集約した各ノードの負荷情報に基づいて、所定の判別式により負荷が低いノードと負荷が高いノードを判別し、負荷が高いノードが管理するID空間の中からノード間で負荷が均一になるようなハッシュIDを選択し、負荷が低いノードに対して選択したハッシュIDを追加する
請求項７記載のデータの分散管理方法。
コンピュータを、
請求項４乃至６のいずれか１項に記載のデータの分散管理装置の各手段として機能させるためのデータの分散管理プログラム。