ダイレクトモード受信機の最適化からストリーミングスパーク

著者：プッシュデータR＆Dエンジニアの先輩

1つの事業の背景

バッチ処理のMapReduceフレームワークは、ビジネス、分析、意思決定のためのリアルタイムデータ処理結果を必要とする場面の多くを満たすことができないオフラインビッグデータ、より複雑なビジネスシナリオの急速な発展に伴い。スパークストリーミングビッグデータは、分散リアルタイムシステムのフレームワークは、彼はフォールトトレラントデータ処理は、ユーザーの行動分析だけで達成することができないストリーミング、ダイナミック、高スループットを提供するだけでなく、金融、世論の分析、ネットワーク監視でありますおよび他の態様は、役割を果たしています。プッシュ開発サービス-運用ユーザーの洗練を達成するための正確なリアルタイムトリガメッセージプッシュLBSジオフェンシング技術を活かしながら、「時折プッシュを」メッセージングプッシュは、大規模な集団ベースのプロパティデータを分析するための技術をストリーミングスパークの適用です。また、ときプッシュアプリケーションスパークストリーミングはカフカ、リアルタイム処理データを行うリソースの最適化を実現し、安定性プログラムを強化するために、手段に代わりレシーバモードのダイレクトモードを使用します。

あなたの解釈をプッシュ練習を組み合わせたモードカフカスパークストリーミングデータの取得から、この記事で、ダイレクトモードに受信機から原則と受信機とのダイレクトモードの特性、およびコントラストの最適化モード。

原理2と2つのモード間の差

レシーバモード

1.レシーバーモードで実行されているアーキテクチャ

1）InputDStream：ストリーミングデータソースから入力データを受信します。

2）受信機：データストリームを受信し、責任は、ローカルにデータを書き込みます。

3）ストリーミングコンテキスト：代表SparkStreaming、タスクスケジューリングストリーミングレベルの責任は、ジョブは、エンジンの処理をスパークするために送ら生成します。

4）スパークコンテキスト：スケジューリングバッチレベル、スパークエンジンジョブの実際の実装を担当スパークコアの代表、。

工程2. Receiverはカフカからデータをプル

このモードでは：

1）エグゼキュータから受信機で受信され、スパークカフカ実行部に格納されたデータは、データを処理するためのバッチジョブのトリガ後の時間は、受信し、受信機は、コアを占有します。

2）データのようなサード・パーティ・システムにバックアップ（書き込むために、受信したデータを受信機なる、WAL機構をオンにする必要が失わないために：HDFS）を、

内部3）受信データを消費するカフカ高レベルAPIを使用して、自動的にオフセットを更新しました。

ダイレクトモード

1.ダイレクトモードで実行されているアーキテクチャ

モードは、カフカのように異なるプルからのNO受信実行プログラム、コンポーネント、データ点を除いて、受信機と同様です。

2.直接プロセスカフカからデータをプル

このモードでは：

1）受信機は、常にデータを受信するが、定期的にチェックし、最新のカフカの各パーティションのオフセットは、各バッチオフセット範囲と現在のクエリの最後の処理を引っ張るための付加的なコアなしでオフセットしていませんデータ処理。

2）地上せずに、データのバックアップを、データを失うことが、唯一の手動オフセットを保存する必要がないようにするために。

消費データへ3）内部使用のカフカ簡単なレベルのAPI、手動でオフセットを維持する必要性、自動的にカフカのZKに更新されませんオフセット。

レシーバのダイレクトモードの違い

前者キュータにおいて受信データを受け付け、受信コアを占める; NO受信機は、後者、それは一時的なコアを使用しないであろう。

2.前者はカフカのトピックパーティションのパーティション番号の数ですInputDStreamパーティションnum_receiver * batchInterval / blockInteral、です。num_receiver設定モード受信機は、不当に性能や資源の浪費に影響を与え、あまりにも設定されている場合、リソースの無駄になります。小さすぎる設定されている場合、並列度は、全体の受信データがボトルネックリンクになり、十分ではありません。

3.前者用途オフセットそれ自身を維持する必要がある、オフセットを維持するために消費者を飼育係。

4.何もデータが失われないことを確実にするためには、かつての必要性は、後者は必要ありませんが、単に成功したオフセット消費データを更新プログラムでは、WALメカニズムを開き、その後、終了します。

ダイレクトモードに変身3レシーバ

プッシュカフカを使用してストリーミングスパーク行うデータのリアルタイム処理、以前使用モード受信機。

受信機は、次の特性があります。

1.受信機モードでは、各受信機は、別個のコアを占有する必要があります。

2.何もデータが失われないことを確実にするためには、チェックポイントを使用して状態を保存するためにWALメカニズムを開く必要があります。

前記受信機は、データレートがデータのバックログ、その結果、データ処理速度よりも大きくなると、最終的にプログラムがハングすることができる受信します。

これらの特徴により、次の受信モードは、リソースの一部の廃棄物が発生します。受信機は数を設定していない場合や、ポイントの下3受信モードはに少ない安定したプログラムを引き起こし;、あなたが使用できないチェックポイントを発生するプログラムをアップグレードする必要がある状態を保存するためのチェックポイントを使用します合理的にも受信機でのパフォーマンスのボトルネックの原因となります。リソースプログラム安定性を最適化するために、ダイレクトモード受信モードに転換されなければなりません。

次のように変更されました：

1. InputDStreamの変更を作成します。

の受信機：

val kafkaStream = KafkaUtils.createStream(streamingContext,
     [ZK quorum], [consumer group id], [per-topic number of Kafka partitions to consume])复制代码

直接変更：

val directKafkaStream = KafkaUtils.createDirectStream[
     [key class], [value class], [key decoder class], [value decoder class] ](
     streamingContext, [map of Kafka parameters], [set of topics to consume])复制代码

2.マニュアルメンテナンスオフセット

受信モードコード：

（レシーバモードはオフセットが、内部カフカに提出/カフカの消費者の高レベルAPIで保存ZK手動メンテナンスを必要としません）

kafkaStream.map {
           ...
 }.foreachRDD { rdd =>
    // 数据处理
    doCompute(rdd)
 }复制代码

ダイレクトモードコード：

directKafkaStream.map {
           ...
 }.foreachRDD { rdd =>
    // 获取当前rdd数据对应的offset
    val offsetRanges = rdd.asInstanceOf[HasOffsetRanges].offsetRanges
    // 数据处理
    doCompute(rdd)
    // 自己实现保存offset
    commitOffsets(offsetRanges)
 }复制代码

4つのその他の最適化のポイント

受信モードでは1：

1）それによって受信されたデータの並列処理を増加させる、レシーバーを高める、InputDStreamを分割します。

2）これにより、並列処理の度合いコア>ケースタスクの数（数）を増加させる、数タスクを増加させるために適切に低減blockIntervalを、調整します。

あなたはWALメカニズムを有効にした場合3）、データ・ストレージ・レベルはMOMERY_AND_DISK_SERに設定されています。

2.シリアル化データがKryoserializationl、使用するJava serializationl速く、シリアル化されたデータが比較小さいです。

3. GCオーバーヘッドを削減するためにCMSのガベージコレクタをお勧めします。

4.パフォーマンスのオペレータ選択（mapPartitions、foreachPartitions、aggregateByKeyなど）。

5.使用して配分：バッチ時間のようなプログラムをストリーミングは非常に短いので、データの量は、一般的に小さく、短い時間を再分割、理由による偏在topicpartitionへのデータの傾きデータのいくつかの問題を解決することができます。

6. SparkStreaming生産ジョブは、最終的sparkcore上で実行し、そのためsparkCoreを最適化することであることも重要。

7.バックプレッシャーフロー制御

1）なぜ背圧の導入がありますか？

ときに、バッチ処理時間batchintervalこれはあまりにも長い間継続>、それは、受信機メモリのオーバーフローやエグゼキュータ他の問題をもたらす、メモリ内のデータの蓄積をもたらすであろう。

2）背圧：動的に受信ジョブ実行情報jobschedulerのフィードバックに応じてデータレートを調整します。

3）使用するように構成：

spark.streaming.backpressure.enabled
含义： 是否启用 SparkStreaming内部的backpressure机制，
默认值：false ,表示禁用

spark.streaming.backpressure.initialRate
含义： receiver 为第一个batch接收数据时的比率

spark.streaming.receiver.maxRate
含义： receiver接收数据的最大比率，如果设置值<=0, 则receiver接收数据比率不受限制

spark.streaming.kafka.maxRatePerPartition
含义： 从每个kafka partition中读取数据的最大比率复制代码

8.投機メカニズム

おそらく特に遅いタスク、これらのタスクを殺す、と再スケジュールこれらのタスクの実行中にジョブを実行する、組み込みのメカニズム投機の火付け役。

デフォルトの投機のメカニズムがオフになって、次の設定パラメータを開きます。

spark.speculation=true复制代码

注：いくつかのケースでは、オープン憶測ではなく、のような良い結果：消費者向けプログラムの複数のトピックをストリーミングする場合、処理はカフカ、全く異なるの無再ゾーニングし、もしデータパーティションの量は、複数のトピックから直接データを読み込みますそれは、タスクの実行の正常な実行が遅いと考えられ、そして殺すために半分の方法だったことになるデータの大きい量につながる可能性がありますが、この場合にはバッチの長い処理時間につながる可能性があり、この問題は再分割することによって解決することができますが、再分配を測定します時間は、データの量は、一般的に小さいので、短時間に再分割、非常に短いバッチのようにプログラムをストリーミング、大規模なデータspark_batch異なり一度特に長い再分割されますので、最終的には特定の状況に応じて試験されます決断。

5まとめ

リソースの最適化を実現するダイレクトモードにレシーバーモード、プログラムの安定性を高めるため、欠点は、オフセット管理する必要があり、操作が比較的複雑です。次に、プッシュは、いくつかの位置の建設のためのリアルタイム保護を提供し、探求し、その強力なデータ処理能力を再生するには、スパークストリーミング技術を最適化していきます。

ます。https：//juejin.im/post/5d034a25f265da1bd3055605で再現