标签：

Spark集群环境配置

我们有2个节点，每个节点是一个worker，每个worker上启动一个Executor，此中Driver也跑在master上。每个Executor可使用的核数为2，可用的内存为2g，集群中所有Executor最大可用核数为4。

conf/spark-defaults.conf 部分参数配置如下：

spark.master spark://Master:7077 spark.executor.memory 2g spark.executor.cores 2 spark.cores.max 4

在提交jar包的时，凭据需求分配executor的核数和memory数给差此外应用,若某个应用占用了所有的核和内存，剩下的应用只能期待这个措施执行完毕释放资源后才可执行。

conf/spark-env.sh 部分参数配置如下：

export SPARK_WORKER_CORES=2 export SPARK_WORDER_INSTANCES=1 export SPARK_WORKER_MEMORY=2g 执行节点负载均衡问题

好比启动四个节点，，但是在措置惩罚惩罚数据的时候负载不均衡，只有两个节点的使用率很高。可以猜测与分区数有关，测试数据集为267MB，hdfs中默认的数据分片巨细为128MB，约有两个分区。猜测只有两个分区能拿到数据进行计算，所以将hdfs的数据分片巨细改为64MB，这样约有4个分区，与集群中的Executor数目相符。经测试证明，负载不均衡的问题得到解决。

改削配置文件hdfs-site.xml，将block size设置为64MB

<property> <name>dfs.block.size</name> <value>67108864</value> 说明：64M=64*1024*1024 </property> 8080

如上图所示，此页面自上而下包孕：

spark版本信息，

spark master 的URL（worker用来连接此master的URL）

worker的数量：4

所有worker节点中可用和在用的core（检察资源的使用情况，参考是否适合再启动一个应用等）

所有worker节点中可用和在用的memory（如上）

正在运行和已经完成的应用数量

master当前状态

workers部分

展示集群中每个worker的位置，到当前状态，内核使用情况，内存使用情况

（通过检察内核和内存的用量情况确定是否足够运行一个新的应用）

点击workerID进入worker的detail页面会显示与该worker更详细的信息

（抱负情况下，所有worker节点使用的内核数和内存应该是不异的，如果呈现使用率差此外情况，说明集群资源未平均分配，应用未最佳化运行，需遏制所有应用从头启动集群）

Running/Completed Application部分

分袂展示在运行和已经运行完的应用信息，包孕名称，获得的资源，开始时间，所有者，已运行时间，目前状态（RUNNING/FINISHED/结束原因）

（若state显示WAITING，则说明Spark对付应用没有足够的内存或内核，将连结期待直到有足够资源可用，有几种情况，一是直到已经在运行的一个应用完成运行，二是增加分配给spark worker的资源，三是将少应用的请求资源）

点击ApplicationID进入detail页面会显示看到关于该应用运行时的详细信息，包孕参预的worker/使用的资源数/日志等

（如果一个任务掉败或抛出了异常，可以检察stderr文件来调试问题）

4040

localhost:4040（当应用在运行中的时候可以访谒，一旦应用执行结束该端口封锁不成访谒）

如下图，显示根基的运行时间，调理模式（FIFO为先进先出），不状态中功课的统计量，并显示正在运行/已经完成/运行掉败的spark功课较为详细的信息列表，例如，Job的提交时间/运行时间/目前为止每个Job完成的Stage和Task数量等
（从运行时间项可以不雅察看到，若某一个Job花费时间异常，可以把问题缩小到该Job下的Stage或者Task）

点击某JobID，进入detail页面显示如下信息：
该Job当前状态

活跃/延迟/已完成的Stage数量

该Job的事件时间线
[spark为该Job生成的DAG的可视化泛起]

表格部分的信息有助于定位性能问题，查抄Duration列是否存在运行时间异常的Stage，Tasks表白一个Stage内的并行量（按照集群巨细，太少或太多可能导致性能问题）。数据Shuffle会对应用性能造成负面影响，所以要最小化Shuffle Read和Write数量。

DGA可视化

Stage

点击某Stage，进入detail页面显示如下信息。

Summary 部分：

若任务连续时间在任一个四分位处过高，则说明有问题。可能是分隔太大，也可能是数据Shuffle的负面效应。也可以查抄GC勾当是否影响性能。

Executor的聚合信息部分：

可以有效找来由理迟缓的任务，查抄GC时间

Locality Level（数据的区域级别）：