2

私は現在、大量のログを保存する Hadoop クラスターを使用しており、集計分析を計算するためのピッグ スクリプトを実行しています。また、本番データを保存する Mongo クラスターもあります。

私は最近、多くの 1 回限りの分析クエリを実行するか、他の人がそれらを実行できるようにする必要がある立場に置かれています。これらのクエリでは、運用データとログ データの両方を頻繁に使用する必要があるため、何をするにしてもすべてを 1 か所にまとめたいと考えています。私のログ データは json 形式で、prod データの約 10 倍のサイズです。私が見ているMongoとHBaseの長所/短所は次のとおりです。

Mongo の長所 / HBase の短所:

  1. ログ データは JSON 形式であるため、Mongo に非常に簡単に取り込むことができます。また、FluentD などを介して取り込まれるので、これをリアルタイムで行うことができます。
  2. 私が一緒に仕事をしているほとんどの人は、製品データを扱う必要があることから Mongo クエリを作成した経験があるため、Mongo で分析データベースを作成することは、誰にとっても非常に簡単です。
  3. Hbase については Mongo ほど詳しくありません。
  4. JSON で、または Mongo から Hbase にデータを取得することがどれほど簡単か難しいかわかりません。これはそれほど悪くないと思いますが、ドキュメントはあまりありません。

HBase の長所/Mongo の短所:

  1. ログ データは製品データよりもはるかに大きいため、hadoop と mongo の両方にログ データを格納すると、製品データを Hadoop と mongo の両方に格納するよりもはるかにコストがかかります。
  2. すでに実行中の Hadoop クラスターの上に HBase を構築し、余分なマシンを追加せずに製品データをそこに収めることができます。Mongo を使用する場合、まったく新しい Mongo クラスターが必要になります。
  3. Hbase の上に Phoenix を使用して、単純な SQL 構文ですべてのデータにアクセスできるようにすることもできますが、これがマルチレベルのドキュメントベースのデータにとってどれほど扱いにくいものになるかはわかりません。

現在、私は Hbase についてほとんど知りません。自分自身を Mongo の専門家とは考えていないため、多くのことを見逃している可能性があります。

それで、私は何が欠けていて、どれが私の状況に適していますか?

4

2 に答える 2

2

まず、すでに処理できるものを使用する必要があります。したがって、Mongo DB は、特にデータが既に json 形式である場合に適しています。

一方、私はかなり長い間 HBase を使用しており、行数が多いにもかかわらず読み取りパフォーマンスは驚くべきものであり、Mongo DB と Hadoop との優れた高速統合があるかどうかは本当にわかりません。HBase は Hadoop データベースであるため、Hadoop と一緒に動作するように設計されています。

ログを (HBase Rowkey で) インデックス付けできる場合:

producing_program_identifier, timestamp, ...

HBase は、このクエリ パターンに対して非常にうまく機能します。しかし、HBase を使用することに決めた場合は、 phoenix フレームワークを使用すると、jdbc や SQL に似たクエリなどの使い慣れたインターフェイスを使用して時間を節約できます。また、十分な単純な集計関数 (count、avg、max、min) も提供します。

于 2013-09-26T07:36:15.080 に答える
0

あなたが言っていることから、mongoDB ベースのソリューションが最適に機能するようです。

HBase は非常に汎用性が高く、製品のニーズと分析のニーズの両方に対応できますが、汎用 SQL 機能 (Phoenix、Cloudera の Impala など) はまだ初期段階にあり、HBase の標準的な方法で高いクエリ パフォーマンスを実現しています。 (読み取り用のデータ構造の設計) には多くの労力がかかります (特に、HBase の経験がないため)。

ちなみに、map/reduces の事前集計データを使用してから MongoDB にロードし、どちらの方法でも変更するのではなく、現在のセットアップ ベットを利用することが適切な場合があります。

于 2013-05-15T08:05:43.330 に答える