六、火花 - 点火チューニング

[TOC]

I.はじめにスパークチューン

1.1スパークチューニングとは何ですか

ようにCPU、ネットワーク帯域幅、メモリ、および：計算エッセンススパークは、アプリケーションのパフォーマンスは、次のようなクラスタ内の任意の要因によって影響される、計算分配されます。通常の状況、メモリが十分に大きい場合、パフォーマンスに影響を与える、他の要因の下で。次にチューニングは、状況が十分ではありませんので、それはリソースの使用を規制することが必要となるリソースをより効率的に使用する多くのリソースを必要と表示されます。例えば、メモリは、メモリの消費量を削減するために調整する、すべてのデータを保持するのに十分なタイト（10億）、メモリ使用量が必要である場合

1.2スパークチューニングの主方向

メモリ使用量、チューンのSparkパフォーマンスの最適化、作業の大半を、。一般的に、スパークを処理するプログラムデータの量は限りネットワークは、通常、一般的に重大なパフォーマンス上の問題ではないとして、使用に小さな、十分なメモリです。大量のデータ（データ・スパート）について計算したときしかし、アプリケーション・パフォーマンスの問題スパークがしばしば起こります。多くの場合、これは現在の環境を満たしていないが、それはクラスターの崩壊につながる可能性があります。
メモリチューニングに加えて、パフォーマンスを最適化するためにいくつかの手段があります。たとえば、MySQLとの対話型を使用するプロセスをスパーク、それを考慮にチューニングパフォーマンスの問題は、MySQL、この時間を取る必要があります。

主な技術的手段1.3スパークチューニング

1、高性能シリアライズライブラリ。シリアル化されたデータの大きさの時間および配列減らす目的
図2に示すように、データ構造の最適化。メモリフットプリント低減の目的
持続（RDDキャッシュ）、チェックポイントのための複数の使用のため3、RDDを
4、持続レベルのシーケンスを使用：。MEMORY_ONLYないシリアライズ、MEMORY_ONLY_SERシリアライゼーション。
MEMORY_ONLY_SERよりMEMORY_ONLYは、より多くのメモリ空間を占有します。
ただし、シリアライズCPU使用率がとても良い重さ、コストが増加します
5、Java仮想マシンのガベージコレクションのチューニングを。
6、シャッフルチューニング、問題の90％はシャッフルするリードしている（これは深刻な問題、2.xバージョンの1.1バージョンは、基本的な公式サイトが最適化されたとき、2.xバージョンので、この問題は無視することができます）

他の方法のパフォーマンスの最適化：
計算の並列処理の改善
ブロードキャストを共有データ

以下は、この6時00チューニング手段のために分析されます

第二に、診断スパークメモリ使用量

2.1メモリの支出（支出ターゲットメモリ）

1、每个 java/scala对象，由两部分组成，一个是对象头，占用16字节，主要包含对象的一些元信息，比如指向它的类的指针。另一个是对象本身。如果对象比较小，比如int，它的对象头比自己对象本身都大。

2、String对象，会比他内部的原始数据，多出40个字节，用于保存string类型的元信息
String内部使用char数组来保存字符串序列，并且还要保存诸如数组长度之类的信息。String使用UTF-16编码，所以每个字符会占用2个字节。
比如：包含10个字符的String，占用 2*10 + 40 个字节。

3、集合类型，比如HashMap和LinkedList，内部使用链表数据结构，对链表中的每个数据，使用Entry对象包装。Entry对象，不光有对象头，还有指向下一个Entry的指针，占用8个字节。所以一句话就是，这种内部还包含多个对象的类型，占用内存更多。因为对象多了，除了对象本身数据占用内存之外，更多对象也就会有更多对象头，占用了不少内存空间。

4、基本数据类型的集合，比如int集合，内部会使用对象的包装类 Integer来存储元素。

2.2取得スパークプログラムメモリ使用

ログを実行しているログディレクトリを表示するには、ドライバの下で

less ${spark_home}/work/app-xxxxxx/0/stderr
观察到类似如下信息：
INFO MemoryStore: Block broadcast_1 stored as values in memory (estimated size 320.9 KB, free 366.0 MB)
        19/07/05 05:57:47 INFO MemoryStore: Block rdd_3_1 stored as values in memory (estimated size 26.0 MB, free 339.9 MB)
        19/07/05 05:57:47 INFO Executor: Finished task 1.0 in stage 0.0 (TID 1). 2212 bytes result sent to driver
        19/07/05 05:57:48 INFO MemoryStore: Block rdd_3_0 stored as values in memory (estimated size 26.7 MB, free 313.2 MB)

estimated size 320.9 KB：当前使用的内存大概大小
free 366.0 MB：剩余空闲内存大小

タスクがメモリを使用している場合ので、あなたは知ることができます

三、スパークチューニング手法

2.1高性能シリアライズライブラリ

2.1.1スパーク利用のシリアライズ

分散システム、および他の分散システムとして、シリアル化を必要とするスパーク。分散システムのいずれかが、一部の配列は非常に重要です。直列化技術は、操作が遅い場合は、直列化されたデータは、大規模な分散システムは、パフォーマンスの低下、多くのアプリケーションにつながるです。だから、最初のステップスパークのパフォーマンスの最適化は、シリアル化のパフォーマンスを最適化することです。
いくつかの場所での火花は、Javaの直列化機構前の話は、そのようなシャッフルが、利便性と性能のトレードオフ、便宜上スパークの火花は、デフォルトのJava直列化機構を使用するときのように、シリアライズを使用します。 、パフォーマンスがシリアライズ大規模データの後に高い、遅い連載ではありません。したがって、一般的な製造、好ましくは修飾された点火用シリアル化メカニズム

シリアル化するために使用2.1.2コンフィギュレーション・スパークkryo

これは、直列化を達成するために、スパークkryoの使用をサポートしています。kryo javaの速いシーケンスの速度、小さなフットプリントよりも、10倍小さい程度。しかし、比較的少ない便利に使用します。
スパーク利用kryoの設定：

spark在读取配置时，会读取conf目录下的配置文件，其中有一个 spark-defaults.conf 文件就是用来指定spark的一些工作参数的。

vim spark-defaults.conf
spark.serializer        org.apache.spark.serializer.KryoSerializer

这就配置了使用kryo，当然也可以在spark程序中使用 conf对象来来设置
conf.set("spark.serializer","org.apache.spark.serializer.KryoSerializer")

2.1.3 kryoライブラリの最適化

キャッシュサイズの（1）最適化
連載カスタム型特に大きな自身を登録した場合、100以上のフィールドが含まれているような、大きすぎるシリアライズされたオブジェクトにつながります。この時点で、我々はKYRO自身のために最適化する必要があります。KYRO内部キャッシュ自体は、このような大規模なオブジェクトを格納するのに十分ではありませんので。

设置：spark.kryoserializer.buffer.max  参数值调大，即可。

予め登録（2）カスタムタイプ
：好ましくようなクラスをシリアル化するための事前必要に登録されている高性能のためKryoを使用して、

在sparkConf 对象中注册
conf.registerKryoClasses(Array(classof[Student],classof[Teacher]))

注：これは、カスタムクラスのための基本的で、そしてスカラ座でのスパークプロジェクトの準備は、実際には、Javaのとは違って、あまりにも多くのカスタムクラスを含みません

2.2最適化データ構造

2.2.1概要

最適化されたデータ構造は、主にシンタックスプロパティによって引き起こされる余分なメモリのオーバーヘッドを回避します。
コアは：内部関数の最適化アルゴリズムは、外部のローカルデータまたはサブデータ数を使用します。
目的：メモリ消費量と占有率を減らすために。

2.2.2特定のツール

（1）文字列好ましく使用されるアレイではなく、コレクション。

即：优先使用array，而不是ArrayList，LinkedList，hashMap
使用int[] 比 List<Integer> 节省内存。

前面也说过，集合类包含更多的额外数据，以及复杂的类结构，所以占用内存多。此举就是为了将结构简单化，满足使用的情况下，越简单越好

（2）文字列にオブジェクトを変換します。

在企业中，将HashMap，List这种数据，统一使用String拼接成特殊格式的字符串。
举例：
Map<Integer,Person> persons = new HashMap<>()
优化为：
id:name,address,idCardNum,family......|id:name,address,idCardNum,family......

（3）は、複数のネストされたオブジェクト構造の使用を回避します。

public class Teacher{private List<Student> students = new ArrayList<>()}
以上例子不好，因为Teacher类的内部又嵌套了大量的小的Student对象。
改进：
转成json，处理字符串
{"teacherId":1,....,students[{"studentId":1,.....}]}

（4）の代わりにint型の文字列を使用しての、シーンのために回避することができます

虽然String性能比List高，但是int占用更少内存。
比如：数据库主键，id，推荐使用自增主键，而不是uuid。

2.3 RDDキャッシュ

これはRDDキャッシュを再び使用する場合、二重カウントを避けるために、メモリ内で複数回使用、主に、非常に簡単です。フロントスパークコア記事の実装を見て

2.4用途はキャッシュにシリアライズ

デフォルトでは、RDDキャッシュによって、RDDオブジェクトは永続的なレベルMEMORY_ONLYであること、シリアライズされていません。持続性の推奨MEMORY_ONLY_SER、この方法でも、少ないメモリ容量アップシリアライズされたテイクをシリアライズされますので。フロントスパークコア記事の実装を見て

2.5 JVMのチューニング

2.5.1背景

RDDの永続性、大量のデータの永続化時の場合は、ガベージコレクタのJava仮想マシンは、パフォーマンスのボトルネックになることがあります。定期的にJava仮想マシンのガベージコレクション、それはもはや新しいオブジェクトのための部屋を作るために、古いオブジェクトをクリーンアップ、ガベージコレクションで使用されているオブジェクトを見つけるために、Javaオブジェクトのすべて、および追撃を追跡します。
ガベージコレクションのパフォーマンス・オーバーヘッド、およびメモリ内のオブジェクトの数に比例しています。しかし、また、それは理にかなっているのJava仮想マシンのチューニングを行う前に、チューニングの必要性が上に他の作業を行うには、ことに注意すること。そのため上記のチューニング作業の、メモリコスト、メモリのより良い、より効率的な使用を節約するためです。得られメリットに比べて上記の最適化は、JVMのチューニングが非常に大きいでした。JVMのチューニングと良いではなく、優れた上位アプリケーションのメモリ使用量、最適化JVMもダメ。

2.5.2 GC原則

ここではこれを言及し、より多くの読者は、ここでそれを繰り返さないBaiduは見つけることができるものは何でもこの原則を、理解することができるようにすることです。

2.5.3検出ガベージコレクション

私たちはどのように多くの場合、ガベージコレクション、および各時間ガベージコレクションを費やした時間を含め、ガベージコレクションを監視することができます。
では、スクリプトをスパーク提出プロファイルを追加します。

--conf "spark.executor.extraJavaOptions=-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimesStamps"

注意：输出到worker的日志中，而不是driver日志。

/usr/local/spark-2.1.0-bin-hadoop2.7/work/app-20190705055405-0000/0
这是driver日志

/usr/local/spark-2.1.0-bin-hadoop2.7/logs
这是worker日志

2.5.4エグゼキュータメモリ最適化比

GCのチューニングのために、最も重要な調節、RDDキャッシュメモリ空間は、オブジェクト・スペースを作成するために使用されるメモリの割合を実行するために、操作者によって占められて。デフォルトでは、スパークは、タスクの実行中に作成されたオブジェクト、メモリ空間の40％だけストアオブジェクトに、キャッシュRDDにメモリ空間の各エグゼキュータ60％を使用しました。
この場合、最も可能性が高いため、対象タスクを作成するのに十分なメモリのメモリ空間の40％で、その結果、大きすぎると、トリガー、Java仮想マシンのガベージコレクションの操作には十分ではありません。極端な例では、頻繁にガーベッジコレクション動作がトリガされます。
実際の状況によると、オブジェクト・ストレージ・スペースが出現GCの道の確率を減らすために増加させることができます。

conf.set("spark.storage.memoryFraction",0.5)
将RDD缓存占用空间比例降低到50%

2.6シャッフル

シャッフルがある場合spark1.x以前のバージョンでは、各マップタスクは（また、タスクを低減するともいう）に応じてタスクをもたらす異なる結果タスク処理のそれぞれの数、パーティションマップの結果、、、各パーティションには、ファイルを生成します。高い数がマップすると、パフォーマンス上の問題を引き起こすことができるファイルの数が多いでしょう。
spark2.xにおいて、データマップタスクからの出力はファイルに配置され、次いで、したがって唯一のタスクを確実に、ファイル内のデータの異なるパーティションの場所を特定する、インデックスファイルを追加ファイルを生成します。これにより、圧力を低下させるIO