データ受信並列処理のチューニング
（1 ） 時間（例えばカフカ、水路などの）ネットワークを介してデータを受信し、データは、デシリアライズスパークとメモリに格納されます。システムのデータ受信がボトルネックと呼ばれている場合は、受信パラレルデータを検討してください。 各入力は、受信機がデータストリームを受信ワーカー執行、上のDSTREAM受信を開始します。DSTREAMは複数作成することによって入力することができ、それらはコンフィギュレーション受信 異なるデータパーティションのデータソースを、複数のデータストリームを受信する効果を達成します。例えば、二つのDSTREAM入力、それぞれに分割される2つのDSTREAMカフカトピックを受信するための入力は、それぞれ受信 トピックのデータを。これは、2レシーバを作成し、それによりスループットを向上させる、パラレルデータの受信します。DSTREAM複数組合オペレータがそれによってDSTREAMを形成し、重合のために使用することができます。次いで、 重合後DSTREAMのための1つの後続の変換オペレータ操作。 int型 NumStreams = 5。; リスト <JavaPairDStream <文字列、文字列>> kafkaStreams = 新しい新しいのArrayList <JavaPairDStream <文字列、文字列>> （NumStreams）; のため（int型 I = 0;私はNumStreamsを<; I ++を）{ kafkaStreams.add（KafkaUtils.createStream（...））; } JavaPairDStream unifiedStream = streamingContext.union <文字列、文字列>（。kafkaStreams.get（0）、kafkaStreams.subList（1 、kafkaStreams.size（）））; unifiedStream。プリント（）; （ 2 ） データ受信チューニング並列、レシーバ入力DSTREAM以上を作成することに加えて、また、調整可能なブロックの間隔と考えることができます。パラメータによって、spark.streaming.blockIntervalは、あなたがブロックの間隔を設定することができ、 デフォルトは200msのです。受信機はほとんどの場合、BlockManagerスパークに受信したデータを保存する前に、ブロックのデータにカットされます。各バッチにおけるブロックの数が、次に決定 パーティションRDDの数がバッチに対応し、作成した変換操作を実施するためときにタスクの数RDD。番号に対応する各タスクのバッチは約推定、すなわち間隔バッチ / ブロックインターバルザ。 例えば、バッチ間隔が2S、200ミリ秒のブロック間隔である、と言う、10タスクを作成します。タスクは、各マシンのCPUコアの数よりも低くなっている各バッチ、あまりにも少量であると考えられる場合は、それは、バッチタスクの数が表示さ すべてのCPUリソースを十分に利用することができないため、十分ではありません。バッチの数ブロックを増やすには、そのブロックの間隔を減らします。この値より小さい場合は、推奨される最小ブロック間隔は50ミリ秒であり、 その後、起動時間の多数のタスクは、パフォーマンス・オーバーヘッド・ポイントになる可能性があります。 （ 3 ） 並列的に受信することに加えて、2つのデータを前記上記持ち上げる方法があり、それが明示的に再パーティション入力データストリームに、です。使用inputStream.repartition（ <パーティション数> ）へ。 これはマシンの指定された数は、さらなるアクションにわたって分布受信のバッチを、可能にします。
第二に、タスクがチューニングを開始します
毎秒タスクの開始が多すぎる場合には、例えば、スタートにつき50は、その後、ワーカーノードのタスクパフォーマンス・オーバーヘッドのエグゼキュータに送信することは比較的大きくなり、今回は遅延基本ミリ秒を達成することは困難です。 このオーバーヘッド性能減少させるために以下の手順を使用 。1 、タスクの配列：タスクをシリアル化するための使用Kryoのシリアル化メカニズムを、タスクがそれによって各ノードキュータワーカーにタスクを送信するための時間を短縮、小型化を図ることができます。 2 、実行モード：スタンドアロンモードでのスパークラン、あなたはあまりタスクの開始時間を達成することができます。 上述した実施形態では、100ミリ秒の各バッチの処理時間を短縮することができるかもしれません。これによりミリ秒にダウンセカンドレベル。
第三に、データ処理の並列チューニング
計算のいずれかの段階で使用される同時タスクの数が十分でない場合、クラスタリソースが十分に活用されていません。例えば、分散低減動作のために そのようなreduceByKeyとreduceByKeyAndWindow、デフォルトは、並列タスクの数である。スパークデフォルト.parallelismパラメータが決定します。あなたは、操作のようにreduceByKeyことができ 、全体的なスパークを調整することができ、手動操作の並列度を指定するには、二番目のパラメータを渡す。デフォルト .parallelismパラメータを。
第四に、データのシリアライズ曲
（1 ） 直列化データが得られるオーバーヘッドは最適化されたシーケンスの形式によって減少させることができます。フロー・コンピューティングのシナリオでは、データの2種類がありますシリアル化する必要があります。 図1に示すように、入力データ：デフォルトでは、入力データを受信し、執行レベルのために使用される永続的なメモリに格納されているStorageLevel.MEMORY_AND_DISK_SER_2あります。これは、ということを意味 データはGCオーバーヘッドバイトを低減するようにシリアライズされ、失敗したFTエグゼキュータにコピーされます。そのため、データが第1のメモリに格納され、そして時にディスクにメモリ不足に波及するだろう 、必要なすべてのデータを保存するために計算ストリーミングされます。ここでデシリアライズデータ--Receiverシリアライズ著しい性能オーバーヘッドは、ネットワークから受信し、その後、シーケンスデータスパークのシーケンスフォーマットを使用しなければなりません。 図2は、永続RDD算出フロー生成動作：ストリームが永続的計算動作RDDを生成し、メモリに持続することができます。データは、以降の例では、デフォルトでは、永続メモリ内の作動ウィンドウデータとなり 、後に複数のウィンドウで使用され、複数回処理することができます。デフォルトのスパークコア持続性レベルとは異なり、StorageLevel.MEMORY_ONLY、デフォルトRDDストリーミングコンピューティング操作が永続的に生成しかし、 レベルがStorageLevel.MEMORY_ONLY_SERで、デフォルトでは、オーバーヘッドGCを削減することになります。 （ 2 ） 上記のシナリオでは、配列ライブラリーの使用は、KryoのCPUとメモリのパフォーマンス・オーバーヘッドを低減することができます。Kryoを使用している場合、我々は、カスタムクラスの登録を検討し、必要がある と、対応する基準（spark.kryo.referenceTracking）のトラッキングを無効にします。 このようなアプリケーションをストリーミングするためのデータ量を維持する必要性など、いくつかの特別なシナリオでは、非永続的に多くはない、おそらくシリアル化されたデータ、それによって削減直列化とCPUのオーバーヘッドのデシリアライズ、ある と彼らはあまりにも高価なGCのオーバーヘッドがありません。あなたはバッチ間隔の数秒で、操作ウィンドウを使用しない場合たとえば、あなたは永続的な無効時に提供される明示的持続性レベルを考慮することを望むかもしれない データをシリアライズされます。これは、直列化およびCPUのパフォーマンスのオーバーヘッドのデシリアライズを低減し、GCのオーバーヘッドのあまりを負いません使用することができます。
五、バッチ間隔チューニング（重要）
あなたが安定させることができるスパークストリーミング・アプリケーションのクラスタ上で実行したい場合、それは可能な限り迅速に受信したデータを処理しなければなりません。換言すれば、バッチを生成した後、できるだけ速やかに廃棄されるべきです。 アプリケーションの場合、これは問題ではありません、それはスパークUI上のバッチ処理時間を観察することによって設定することができます。バッチ処理時間は、時間間隔のバッチよりも小さくなければなりません。 流れの性質に基づいて算出し、バッチ間隔巨大な衝撃は、クラスタリソースの固定された条件下で、アプリケーションデータ受信レートを維持することができ、そこであろう。例えば、WORDCOUNT例では、特定のための データ受信率、アプリケーションサービスではなく、500msごとの、2秒に1回の印刷単語を数える保証することができます。したがって、バッチ間隔は、データ受信率は本番環境で保持することが期待されるように設定する必要があります。 個々のアプリケーションに適切なバッチサイズを計算するためのより良い方法は、例えば、バッチ非常に保守的な間隔である。5〜テストデータを受信するためのゆっくりとした速度で10秒、。アプリケーションがデータ・レートに追いつくためにかどうかを確認するには、 次の各バッチの時間遅延処理を確認することができ、処理時間は、バッチ間隔と基本的に一致している場合、アプリケーションは安定しています。バッチスケジューリング遅延が成長を続けそうでない場合、それはアプリケーションが追いつくことができないことを意味し 、不安定であるこのレート、。ですから、安定した形状を持つようにしたい、あなたはデータ処理の速度を向上させる、またはバッチ間隔を長くしようとすることができます。覚えておいて、一時的なデータの増加への成長が一時的に遅れによる、 それは限り遅延が短時間で回復することができるよう、合理的です。
第六に、メモリー・チューニング
（1 ） メモリの使用とアプリケーションスパークGC動作を最適化、チューニングスパークコア、それはについて話されました。ここではスパークストリーミングアプリケーションに関連するチューニングパラメータについて話をします。 スパークストリーミングアプリケーションは、メモリ・クラスタ・リソースを必要とする、形質転換は、使用される操作の種類によって決定されます。あなたは、ウィンドウのオペレータ10分の窓長を使用したい場合たとえば、 その後、クラスタは、10分以内にデータを保持するのに十分なメモリを持っている必要があります。あなたは多くのキーの状態を維持するためにupdateStateByKey使用したい場合は、お使いのメモリー・リソースが十分に大きくなければなりません。逆に、 あなたが簡単な地図行いたい場合 -filter- ストアオペレーションを、あなたは非常に少ないメモリを使用する必要があります。 一般的に言えば、受信機によって受信されたデータは、記憶のためStorageLevel.MEMORY_AND_DISK_SER_2永続レベルを使用するので、データはメモリに保存することができないディスクにオーバーフローします。 ディスクに書き込まオーバーフローが、それはアプリケーションのパフォーマンスが低下します。そのため、通常はそれがアプリケーションのために必要十分なメモリリソースを提供することをお勧めします。メモリの現場でのテストと評価を少量のことをお勧めします。 （ 2 ） 同調メモリガベージコレクタの別の態様。ストリーミングアプリケーションのために、あなたは低レイテンシーを取得したい場合は、確かにJVMのガベージコレクションので原因長い遅延を持っている必要はありません。メモリ使用量とオーバーヘッドGCを減らすことができ、多くのパラメータがあります 。1 「データのシリアル・チューニング」の項で述べたのと同じように、そして特定の操作の中間入力データRDD生産、デフォルトの永続:,永続性DSTREAMそれはバイトにシリアライズされます。メモリオーバーヘッドとGCを低減する非直列化された方法と比較。 さらに、メモリ使用量とGCのオーバーヘッドを減らすことができKryoシリアル化メカニズムを使用してください。さらに、メモリ使用量を減らすために、データが圧縮されてもよい、（デフォルトはfalse）spark.rdd.compressパラメータによって制御されます。 2古いデータをクリーンアップします。デフォルトでは、操作DSTREAM変換永続RDDによって生成されたすべての入力データとは、自動的にクリアされます。データをクリーンアップする際に火花ストリーミングは、決定する 変換操作の種類に応じました。時間が経過した後たとえば、あなたは10分以内に窓長ウィンドウ操作を使用している、スパークは、10分以内にデータを保持しますが、それは古いデータをクリーンアップします。しかし、いくつかの特別な場面で 、このようなスパークSQLとして、バッチRDDのSpark SQLクエリの実行を使用して、非同期のオープンスレッドで使用した場合の統合をストリーミングスパーク。そして、あなたは最後までSQLクエリをスパーク、長い期間スパークのためのデータを取得する必要があります。 これはstreamingContext.remember（）メソッドを使用して実施することができます。 3、CMSのガベージコレクタ：パラレルMARK-使用スイープガベージコレクション機構は、オーバーヘッドの低いGCを維持するために、推奨されます。並列GCは、スループットを低下させるが、それを使用することが推奨されるが 、バッチ処理時間を短縮する（GC処理時のオーバーヘッドを低減します）。あなたが使用したい場合は、ドライバ側の端部とエグゼキュータを開く必要があります。スパークで --driver-Javaベース-submit使用して提供されるオプション、 spark.executor.extraJavaOptionsパラメータ設定を使用します。-XX：+ UseConcMarkSweepGCを。