7

次のツールを使用して Lambda アーキテクチャを実装しようとしています: すべてのデータポイントを受信する Apache Kafka、バッチ処理 (ビッグ データ) 用の Spark、リアルタイム (Fast Data) 用の Spark ストリーミング、結果を保存する Cassandra。

また、受信するすべてのデータポイントはユーザー セッションに関連しているため、バッチ処理では、セッションが終了した時点でデータポイントを処理することにのみ関心があります。したがって、私は Kafka を使用しているため、これを解決する唯一の方法 (すべてのデータポイントが同じトピックに格納されていると仮定) は、バッチがトピック内のすべてのメッセージを取得し、セッションに対応するメッセージを無視することです。まだ終わっていません。

そこで、お聞きしたいのは次のことです。

  • これは Lambda アーキテクチャを実装するための適切なアプローチですか? それとも、代わりに Haddop と Storm を使用する必要がありますか? (バッチ処理、Map Reduce に Kafka と Apache Spark を使用している人の情報が見つかりません)
  • ユーザーセッションの問題を解決するためのより良いアプローチはありますか?

ありがとう。

4

3 に答える 3

5

これは良いアプローチです。スピードレイヤーとバッチレイヤーの両方に Spark を使用すると、一度ロジックを記述して両方のコンテキストで使用できます。

セッションの問題に関しては、バッチ モードでそれを行っているため、Kafka から HDFS または Cassandra にデータを取り込み、そこに完全なセッションのクエリを記述してみませんか? これを行うには、Spark Streaming の Kafka への「直接接続」を使用できます。

于 2015-07-09T21:52:19.780 に答える
0

Dean Wampler のメモを繰り返しますが、これは特に、Batch レイヤーと Speed レイヤーの両方で選択するツールとして Spark から遠ざけるような特定の要件がない場合に適したアプローチです。たす：

トピックで行っていること (リダクション) が連想操作であると仮定して、トピックを処理する前に、セッションのすべてのデータをトピックから再利用する必要はありません。関連付けられていなくても (Unique Users のように)、Hyper Log Log のように反復計算できる非常に正確な見積もりで問題ない場合があります。ある種のステートフル アグリゲーションを使用する可能性があります。Spark では、updateStateByKey を使用するか、できれば mapWithState 関数を使用してそれを行うことができます。

特にあなたが言及したテクノロジーとユースケースに関する具体的な例を探している場合は、Pluralsight コースを紹介します。Pluralsight コースでは、そのすべてについて学び、実践することができます。Spark 、Kafka、および Cassandra を使用したラムダ アーキテクチャの適用

また、あなたがやっていることはかなり簡単で、すでに Kafka を使用しているので、HDFS の永続性には Kafka Connect を、ストリーミングには Kafka Streams を検討することをお勧めします。Kafka Streams を使用してデータを直接 Kafka にストリーミングし、Kafka Connect を使用して Cassandra や ElasticSearch などの複数の宛先にパイプアウトすることもできます。Kafka Streams について言及するのは、メモリ内に何らかの状態を保持し、単純なストリーミング操作を実行する機能も備えているためです。

幸運を！

于 2016-11-18T11:56:13.607 に答える
0

私は現在、同じ実装に取り​​組んでいます。Kafka、HBase、Spark、および Spark Streaming を使用しています。

これらのテクノロジーを使用する際には、考慮すべきことがたくさんありますが、おそらく簡単な答えはありません。

Spark Streaming の主なポイントは、ストリーム データに対して 100 ミリ秒の最小レイテンシが得られることと、ストリーミング ジョブによって消費されるデータの順序がめちゃくちゃになることです。潜在的なストラグラーの組み合わせにより、少なくとも部分的な順序でデータを処理しているという確信が完全に失われます (少なくとも私の知る限りでは)。Storm はこれらの問題を解決すると思われますが、私は使用していないので保証できません。

バッチ レイヤーに関しては、Spark の方が高速で柔軟性があるため、MapReduce よりも確実に優れています。

次に、バッチ ジョブのデータが停止した場所で速度が継続することを知るという点で、バッチと速度の間の同期に関する問題が発生します。この問題は、処理を行う前にデータを HBase に格納するスピード レイヤーも持つことで解決します。

これは単なるランダムなポイントの集まりです。それらのいくつかが役立つことを願っています.

于 2016-03-18T15:43:17.747 に答える