7

並列化できるソリューションはありますが、hadoop / nosqlの経験が（まだ）なく、ニーズに最適なソリューションがわかりません。理論的には、CPUが無制限の場合、結果はすぐに返されるはずです。だから、どんな助けもいただければ幸いです。ありがとう！

これが私が持っているものです：

  • 数千のデータセット
  • データセットキー：
    • すべてのデータセットは同じキーを持っています
    • 100万キー（これは後で1000万または2000万になる可能性があります）
  • データセット列：
    • 各データセットには同じ列があります
    • 10〜20列
    • ほとんどの列は、集計する必要のある数値です（avg、stddev、およびRを使用して統計を計算します）
    • 特定のクエリでは特定のtype_idのみを含めたい場合があるため、いくつかの列は「type_id」列です。
  • ウェブアプリケーション
    • ユーザーは、関心のあるデータセットを選択できます（15から1000までのどこでも）
    • アプリケーションは次のものを提示する必要があります：各列のキーと集計結果（avg、stddev）
  • データの更新：
    • データセット全体を追加、削除、または置換/更新できます
    • 列を追加できると便利です。ただし、必要に応じて、データセット全体を置き換えることができます。
    • データセットに行/キーを追加しないでください-したがって、高速書き込みが多いシステムは必要ありません
  • インフラストラクチャー：
    • 現在、それぞれ24コアの2台のマシン
    • 最終的には、これをアマゾンでも実行できるようにしたい

集計値を事前に計算することはできませんが、各キーは独立しているため、これは簡単にスケーラブルにする必要があります。現在、このデータはpostgresデータベースにあり、各データセットは独自のパーティションにあります。

  • パーティションを簡単に追加/削除/置換できるので、パーティションは素晴らしいです
  • データベースはtype_idに基づくフィルタリングに適しています
  • データベースは並列クエリを書くのは簡単ではありません
  • データベースは構造化データに適していますが、私のデータは構造化されていません

概念実証として、Hadoopを試しました。

  • 特定のtype_idのデータセットごとにタブ区切りファイルを作成しました
  • hdfsにアップロード
  • マップ：各キーの値/列を取得しました
  • 削減：計算された平均と標準偏差

私の大まかな概念実証から、これはうまくスケーリングすることがわかりますが、hadoop / hdfsには遅延があることがわかります（結果を返すことは問題ありませんが、通常はリア​​ルタイムクエリには使用されないことを読みました） 5秒でユーザーに戻ります）。

私がこれにどのように取り組むべきかについての提案はありますか？次にHBaseを試して、その感触をつかむことを考えていました。代わりにHiveを見る必要がありますか？カサンドラ？ヴォルデモート？

ありがとう！

4

5 に答える 5

6

Hive や Pig は役に立たないようです。基本的に、それぞれが 1 つ以上の map/reduce ジョブにコンパイルされるため、応答が 5 秒以内になることはありません。

HBase は機能する可能性がありますが、最適なパフォーマンスを得るにはインフラストラクチャが少し小さくなります。各列の要約統計を事前に計算できない理由がわかりません。重い減量を行う必要がないように、実行中の平均を計算する必要があります。

http://en.wikipedia.org/wiki/Standard_deviationをご覧ください

stddev(X) = sqrt(E[X^2]- (E[X])^2)

これは、次のようにして AB の stddev を取得できることを意味します。

sqrt(E[AB^2]-(E[AB])^2)。E[AB^2] は (sum(A^2) + sum(B^2))/(|A|+|B|) です。

于 2011-07-26T22:10:01.117 に答える
4

あなたのデータはかなり均一に見えるので、私は間違いなくGoogle BigQueryを見てみたいと思います - MapReduce ステップなしで (あなたの側で) データを取り込んで分析することができます。あなたのクエリ。実際、アプリケーションの設計方法によっては、かなり「リアルタイム」なアプリケーションを作成できます。

于 2012-01-27T04:55:46.483 に答える
2

オープンソース空間ですぐに良い解決策がなければ、それは深刻な問題です。商用スペースでは、greenplum/netezzaのようなMPPデータベースで十分です。理想的には、GoogleのDremel（BigQueryの背後にあるエンジン）が必要です。オープンソースのクローンを開発していますが、しばらく時間がかかります...使用するエンジンに関係なく、ソリューションにはデータセット全体をメモリに保持することを含める必要があると思います。必要なクラスターのサイズがわかります。

于 2011-07-28T19:36:10.817 に答える
2

私があなたを正しく理解しており、一度に 1 つの列で集計するだけでよい場合は、HBase でより良い結果を得るために、データを別の方法で格納して、今日のセットアップではデータ列ごとのテーブルのようになり、フィルタリング フィールド (type_ids) 用の別の単一のテーブルのようになります) 今日のセットアップで各キーの行 - 効率的なフィルタリングのためにフィルター フィールドをキーに組み込む方法を考えたいと思うかもしれません - そうでなければ、今日のセットアップで各テーブルの列 (つまり、数千の列) を読み取る必要があります。列の数) HBase は、新しい列を追加してもかまわず、存在しない列のデータを保存しないという意味でスパースです. 行を読み取ると、関連するすべての値を取得できます. avg. などを非常に簡単に行う

于 2011-11-15T22:12:12.557 に答える
0

これには、単純な古いデータベースを使用することをお勧めします。トランザクションシステムを使用しているようには思えません。結果として、おそらく1つまたは2つの大きなテーブルを使用できます。大きなデータを結合する必要がある場合、SQLには問題があります。しかし、データセットは参加する必要があるようには聞こえないので、問題ないはずです。インデックスを設定してデータセットを検索し、SQLまたはアプリの計算で行うことができます。

于 2012-03-15T13:33:46.597 に答える