6

デバイスのプロパティが変更されるたびにイベント ログを収集しています。この目的のために、私は使用することにしました:

  1. Logstash - エージェント IoT アプリケーションがログを JSON 形式で送信する場所
  2. Elasticsearch - データ (ログ) の保存用、
  3. Kibana - データの視覚化用。

ログ付きの JSON は定期的に送信されており、その形式は次のとおりです。

{"deviceEventLogs":[{"date":"16:16:39 31-08-2016","locationName":"default","property":"on","device":"Lamp 1","value":"
false","roomName":"LivingRoom"}, ... ,]}

Elasticsearch の単一イベント エントリの例は次のようになります。

 {
            "_index": "logstash-2016.08.25",
            "_type": "on",
            "_id": "AVbDYQPq54WlAl_UD_yg",
            "_score": 1,
            "_source": {
               "@version": "1",
               "@timestamp": "2016-08-25T20:25:28.750Z",
               "host": "127.0.0.1",
               "headers": {
                  "request_method": "PUT",
                  "request_path": "/deviceEventLogs",
                  "request_uri": "/deviceEventLogs",
                  "http_version": "HTTP/1.1",
                  "content_type": "application/json",
                  "http_user_agent": "Java/1.8.0_91",
                  "http_host": "127.0.0.1:31311",
                  "http_accept": "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2",
                  "http_connection": "keep-alive",
                  "content_length": "34861"
               },
               "date": "2016-08-08T14:48:11.000Z",
               "device": "Lamp 1",
               "property": "on",
               "locationName": "default",
               "roomName": "LivingRoom",
               "value_boolean": true
            }
 }

私の目標は、分析されたデータを適切な時間 (数分で許容できるはずです) で表示する、ある種のダッシュボードを備えた Web サイトを作成することです。

  • エネルギー消費の履歴を表示し、機能で消費を予測する
  • エネルギー消費の異常、または照明や暖房の使用などのその他の要因の検出
  • 洗練されていないある種の統計に基づいて推奨事項を表示します。つまり、「特定のデバイスを場所 1 から場所 2 に移動できます。場所 1 でより必要とされている (他の場所よりも集中的に使用されているため)」などです。

最後のポイントは非常に些細なことですが、Elasticsearch で単純なクエリまたは集計を使用して、しきい値と比較できますが、最初の 2 つのポイントでは、機械学習やデータ マイニングなどの詳細な分析が必要です。

今のところ、システムには平均 10 秒ごとにステータスを更新する約 50 のデバイスが装備されています。将来的には、デバイスの数は 50,000 まで増加する可能性があります。1 つのイベント ログに 100 バイトを想定すると、Elasticsearch では年間約 15 テラバイトのデータにつながる可能性があります。

一般的な質問は、そのようなシステムの合理的なソリューション/テクノロジー/アーキテクチャーとは何でしょうか?

  1. すべてのログを Elasticsearch に保存することは妥当なスタートですか?
  2. 私は es-hadoop ライブラリが Elasticsearch を Apache Spark と一緒に使用して、Spark で Mlib を使用してデータを処理できるようにすることを検討しています - それは妥当な方向性ですか?
  3. Elasticsearch のみを使用してすべてのデータを格納し、Spark と Mlib のみを使用して詳細な分析を提供できますか? それとも、Elasticsearch をスピード レイヤーとして扱う、いわゆる「ラムダ アーキテクチャ」の実装を検討する必要がありますか? Kafka、Apache Storm が使用されたさまざまな構成について少し赤字にしましたが、それが必要かどうかはよくわかりません。プロジェクトは 1 か月以内に完了する必要があり、私は初心者なので、複雑さと実装に必要な時間が心配です。
  4. データ負荷が 10 分の 1 になるとしたら (年間約 1.5 テラバイト)、答えは同じでしょうか?
4

1 に答える 1

1

これは非常に手の込んだ質問です。分解してみましょう。

考えるべき質問

  • クエリでデータを利用できるようになるまでのエンド ツー エンドの待機時間は? リアルタイムで必要ですか、それとも遅れても大丈夫ですか?
  • 許容できるデータ損失はどの程度ですか?
  • 検討している分析/ML アルゴリズムの精度はどの程度ですか? 非常に正確な結果が必要ですか、それとも多少の不正確さは問題ありませんか?
  • 完成したときだけ結果が必要ですか、それとも投機的な結果が必要ですか?

これらの質問と、スペースの制約やデータ負荷が増加したときの待ち時間などの常連の問題は、適切なソリューションを決定するのに役立ちます。

一般に、これらの問題は、取り込み -> 処理 -> プレゼンテーションと見なすことができます。

取り込み - メッセージ バスの必要性

一般に、人々は Kafka のようなメッセージ バスを選択して、低速のダウンストリーム コンシューマーからのバック プレッシャーを処理し、(ディスクに永続化することによって) 信頼性を提供してデータ損失を防ぎます。Kafka には、Spark ストリーミング、Druid firehose サポート、ES プラグインなどの統合に関して、優れたコミュニティ サポートもあります。

処理 - スケーラブルなコンピューティング レイヤーの必要性

ここで、リアルタイム処理とバッチ処理、該当するデータ損失、正確な結果と投機的な結果などを決定する必要があります。ストリーミングに関する Tyler Akidau の記事 ( https://www.oreilly.com/ideas/the ) を参照してください。詳細な説明については、-world-beyond-batch-streaming-101を参照してください。

人々はリアルタイムのユースケースに Spark ストリーミングを選択し、単純な M/R ジョブがバッチ ジョブのトリックを実行するはずです。ジョブのストリーミングを計画している場合、イベントのウィンドウ化とセッションによって事態がさら​​に複雑になる可能性があります。

プレゼンテーション - インタラクティブなクエリと迅速な応答の必要性

これは、正面向きのアプリが統合される場所であり、予想されるクエリの種類と必要な応答の精度に最適なツールを選択することは理にかなっています.

ES のようなツールは、検索、フィルタリング、およびファセット処理では非常に優れたパフォーマンスを発揮しますが、複雑な数学的集計が必要な場合は失敗します。AFAIK ES は、Druid のように HyperLogLog のような確率構造をサポートしていません。

レトロフィット

次に、上記の各レイヤーで必要な要件をマッピングする必要があります。

エネルギー消費の履歴を表示し、機能で消費を予測する

エネルギー消費の異常、または照明や暖房の使用などのその他の要因の検出

あなたが言及したように、機械学習ライブラリが明らかに必要です。MLib をサポートする Spark は非常に優れています。

洗練されていないある種の統計に基づいて推奨事項を表示します。つまり、「特定のデバイスを場所 1 から場所 2 に移動できます。場所 1 でより必要とされている (他の場所よりも集中的に使用されているため)」などです。

Spark で MLib を使用してこれを行うこともでき、ES または Kafka トピックの別のインデックスにレコメンデーションを送り込むこともできます。これをさらに HDFS または ES に下げることができます。ここでのガベージ コレクションには注意が必要です。これはデータの爆発につながる可能性があり、ここでの保持については積極的に取り組む必要があるためです。また、推奨事項を事前に計算することで、アラート、プッシュ通知、さらには UI からのクエリなどの反応的な処理が高速になります。

1 つのイベント ログに 100 バイトを想定すると、Elasticsearch では年間約 15 テラバイトのデータにつながる可能性があります。

これらは、どのストレージ システムでもプロビジョニングする際の通常の問題です。ここでは、履歴データの具体化されたビューを計算することで最適化できますが、時期尚早の最適化につながる可能性があるため、その決定を少し後で行うことができます。最初にクエリのストレージと待機時間を測定してから、容量の遡及分析を行うことをお勧めします。

すべてのログを Elasticsearch に保存することは妥当なスタートですか?

あなたのユースケースを考えると、非常にそうです。ただし、Spark ストリーミング/MLib またはバッチ MR ジョブを使用する場合は、ほとんどの計算が事前に行われるため、ダム データ ストアを使用することもできます。

私は es-hadoop ライブラリが Elasticsearch を Apache Spark と一緒に使用して、Spark で Mlib を使用してデータを処理できるようにすることを検討しています - それは妥当な方向性ですか?

バッチ処理を決定したようです。その場合、標準の MR または Spark バッチを MLib と共に使用できます。リアルタイムが必要な場合は、Kafka のようなものが必要で、spark ストリーミングを使用します。データ損失に問題がない場合は、ウィンドウ処理/スライド間隔などを決定するときに、保持について積極的にすることができます。結果が不正確であっても問題ない場合は、確率的データ構造 (ブルームなど) を使用できます。 filter、hyperloglog - druid はこれをサポートしています) 結果を表します。

Elasticsearch のみを使用してすべてのデータを格納し、Spark と Mlib のみを使用して詳細な分析を提供できますか? それとも、Elasticsearch をスピード レイヤーとして扱う、いわゆる「ラムダ アーキテクチャ」の実装を検討する必要がありますか?

ES から Spark ジョブにデータをストリーミングできるかどうかはわかりません。また、ラムダ アーキテクチャは誇張されすぎており、リアルタイム レイヤーが不正確であり、データの損失や不正確さを処理できないことが確実にわかっている場合にのみ役立ちます。それ以外の場合は、Kafka からデータを読み取り、ES にポンピングする単純な Spark ストリーミング ジョブで十分です。運用コスト (コードの重複、維持するインフラストラクチャの増加など) が高くなる可能性があるため、Lambda のような精巧なアーキテクチャを決定する前に、データ損失の測定を検討してください。

データ負荷が 10 分の 1 になるとしたら (年間約 1.5 テラバイト)、答えは同じでしょうか?

私はまだ同じアーキテクチャ (Kafka+Spark ストリーミング (MLib)+ES/Druid) を好むでしょう。これは実装が簡単で、保守も簡単です。

于 2016-08-31T18:57:56.540 に答える