0

私が対処しようとしている問題は些細なことのようです。イベントの膨大なコレクションがあります(実際にはモバイルアプリからのものなので、モバイルイベントです)。各イベントは、いくつかの属性によって記述されます。

 operating_system create_time version resolution model brand network_type etc.

これらのイベントを hdfs に保存しています。解決しようとしている問題は、ユーザーがこれらのイベントをほぼリアルタイムで分析できるようにすることです。分析とは、特定の列、興味深い日付範囲のみを選択し、さまざまな電話モデルから発生したイベントの数を確認できることを意味します. たとえば、次のデータセットがあるとします。

 os1 2015-07-30 v1 200x200 model1 brand1 provider1
 os1 2015-07-30 v1 200x200 model1 brand1 provider1
 os1 2015-07-30 v1 200x200 model1 brand1 provider2
 os1 2015-07-30 v1 200x200 model1 brand2 provider2
 os1 2015-07-29 v1 200x200 model1 brand1 provider1
 os2 2015-07-30 v1 200x200 model1 brand1 provider1
 os1 2015-06-30 v1 200x200 model1 brand1 provider1

また、ユーザーが 2015 年 7 月からのさまざまな電話からのイベントの数を知りたいと仮定します。彼が探している答えは次のようになります。

 os1 2015-07-30 v1 200x200 model1 brand1 provider1 4
 os1 2015-07-30 v1 200x200 model1 brand1 provider2 1
 os1 2015-07-30 v1 200x200 model1 brand2 provider2 1

イベントの数が膨大なので、集計を計算して cassandra に保存しようとしました。集計は 1 日ごとに計算され、前の例のデータセットを使用すると、集計は次のようになります。

 os1 2015-06-30 v1 200x200 model1 brand1 provider1 1
 os1 2015-07-29 v1 200x200 model1 brand1 provider1 1
 os1 2015-07-30 v1 200x200 model1 brand1 provider1 3
 os1 2015-07-30 v1 200x200 model1 brand1 provider2 1
 os1 2015-07-30 v1 200x200 model1 brand2 provider2 1

問題は、それらがまだ多すぎることです。要求された日付範囲から集計を合計するためにオンデマンド タスクを実行するには、まだ Spark が必要です。遅く、多くのネットワーク転送が必要です。HyperLogLog やその他の同様のアルゴリズムについてよく読んでいますが、ここでそれらをどのように使用できるかわかりません。正確な結果はあまり気にしません。見積もりは私にとってはかなり良いです。誰かが私にできることを提案できますか?

4

1 に答える 1

0

データにフィールドを追加します。この追加フィールドは、データをより小さなデータのブリックに分割します (これをデータのビニングと呼びます)。たとえば、1000 レコードで 1 つのビンが与えられます。次に、各ビン内で集計を行います。お気に入り:

1 os1 2015-06-30 v1 200x200 model1 brand1 provider1 1
1 os1 2015-07-29 v1 200x200 model1 brand1 provider1 1
1 os1 2015-07-30 v1 200x200 model1 brand1 provider1 3
.
.
2 os1 2015-07-30 v1 200x200 model1 brand1 provider2 1
2 os1 2015-07-30 v1 200x200 model1 brand2 provider2 1
.

これにより、シャッフルが大幅に削減され、おおよその結果が得られます。完全な結果を得るには、ビンからの結果を集計する追加の手順を実行します。

于 2015-07-31T08:57:49.647 に答える