共计 4239 个字符，预计需要花费 11 分钟才能阅读完成。
计算资源 vcore 的优化不同于内存优化，vcore 重大影响着工作的运行效率。如何在保障工作运行效率不变甚至进步的状况下，能进一步优化 vcore 的利用率？咱们须要对工作做出全面的剖析，给出不同的优化策略。这篇文章次要围绕工作运行阶段，介绍工作全链路诊断针对工作不同查看项异样给予的优化策略，以及带来的收益。
对于大数据离线工作来说，因为流转服务节点较多、技术栈要求较高、数据采集难度大、指标简单难懂等一系列起因，造成业务方对工作的掌控力十分差：不分明异样呈现在哪；不确定工作是否能够优化、如何优化。
目前大数据基础设施组开发了一款 EasyEagle 产品，并通过其中的工作全链路诊断模块，帮忙用户去解决上述的问题。
本篇文章大抵介绍工作全链路诊断模块，通过局部案例和数据，帮忙用户更好的理解该功能模块能带来什么样的收益，以及如何简略的应用。本篇文章仅波及计算资源 vcore 的优化，对于异样定位会有其余文章进行介绍。
01 什么是工作全链路诊断？
工作全链路，指的是工作从提交到产出完结，整个生命周期内流转的各个服务、节点的汇合。
诊断，指的是将上述整个链路，依照已有的运维教训和特色进行形象划分，细分成不同查看项进行诊断定位。
总结起来就是：将工作从提交到产出完结（包含各个流转节点以及流转服务），形象并划分成不同阶段，并对上述各个阶段细分不同的查看项进行诊断定位，提供相干专业化的优化以及解决倡议，进步业务方对工作运行过程的掌控，包含工作运行效率的晋升以及资源利用率的晋升。
02 对业务能产生什么价值？
次要的价值其实就一点：减少业务方对工作的掌控能力。这里的掌控能力次要分以下几个方面：
资源：指的是资源申请和理论应用是否正当，利用率是否失常
效率：工作运行效率是否能够晋升，是否能够放慢产出
异样定位：异样在哪，如何解决
配置：配置是否正当，不合理的配置如何批改
在目前的零碎中，业务方提交工作之后，直至完结，对工作的整个运行齐全属于一个摸黑状态。工作全链路诊断就能解决这种摸黑状态，并且晋升业务方上述几个方面的掌控能力，达到降本增效的目标。
说到这里，可能有的小伙伴会问，这是真的吗🤔？那咱们就间接贴图以及数据来展现~
目前外部咱们针对音乐进行了一次工作计算资源的优化，优化工夫范畴为 0 - 7 点（业务高峰期），优化工作数量为前 200 的工作，总体统计数据均只蕴含该时间段（0- 7 点）。
整体优化成果如图：
在针对 0 - 7 点的前 200 工作优化后，vcore 的资源水位降落如上所示。
对于一个只有 5.3w 的 vcore 的集群而言，前 200 的工作占集群 43% 的资源，可能达到上述的优化成果，还是十分可观的，并且音乐业务方自身对于工作的优化状况就较好。
单个工作的优化成果如图：
单个工作的优化成果如上所示，显而易见。
看到这里，小伙伴对于工作全链路诊断这块对于业务方是否能带来收益，是否还有疑难？
03 工作全链路诊断咱们是怎么做的？
首先，咱们将工作生命周期大抵分为三个阶段，如下所示：
工作筹备阶段，次要是指资源的初始化、本地化等一系列的后期筹备。波及到 yarn 的调度、资源、本地节点、hdfs 等。
工作运行阶段，次要是指工作依照既定逻辑运行。
工作产出阶段，次要是指工作具体逻辑运行结束后，数据长久化或其余的一系列操作。波及到 hdfs、metastore 等。
针对每个阶段，咱们再依据外部运维相干教训以及特色，形象划分成不同的查看项对其进行诊断。如果诊断出异样，会附加相干的标签。标签会携带异样起因、异样表象、优化倡议等。
看到这里，大家可能会有个疑难：工作依据标签依照优化倡议优化后，就能放慢产出、进步资源的利用率吗？
答案是能够的。因为每个查看项的评判规范都是时长和资源，所有的优化最终的体现都能够通过时长和资源两个维度进行掂量。
上面咱们会具体阐明下各个阶段的查看项划分。
3.1 工作筹备阶段
针对这一阶段，咱们对其进行了形象划分，分为如下各个查看项：
该阶段，咱们通过对不同类型 container 的状态机变动的距离时长，进行查看项划分。上述的各个查看项，也能够关联相干节点和服务。
在这之前，这个阶段基本上对于所有的业务方来说，甚至开发，都是属于齐全不理解、不掌控的阶段。理论监控后，发现很多工作在该阶段都存在问题。
目前在产品中，咱们将其查看项提取成 4 组标签，展现如下：
上述查看项的优化，次要带来的是工作产出时长的优化。这里咱们简略的举一个例子来阐明下咱们是如何做的。
AM 调配耗时过长以 AM 调配耗时这个查看项为例，判断的根据如下：
获取工作该查看项的耗时;
与集群 AM 调配速率以及该工作此查看项的历史程度进行比照;
如发现不匹配集群的调配速率或超出历史统计模型设置的下限，则查看工作提交队列的资源水位;
如该队列资源水位已满，则告知业务方因为队列资源有余造成；如该队列资源水位失常，然而 AM 资源已满，则告知业务方因为 AM 资源有余造成，倡议批改 AM 资源配比
如该查看项异样，业务方能够依据给出的相干倡议进行解决，放慢工作的产出。
3.2 工作运行阶段
针对这一阶段，咱们也将 spark 工作进行了一个大略的形象，如下所示：
该阶段，咱们次要通过实时统计分析 spark 的 event 指标进行查看项的诊断。
以后此阶段查看项的划分还处于增长的状态，目前大抵已有 20 余项，局部查看项标签如下所示：
上述查看项的优化，为什么能带来资源利用率的晋升以及运行效率的晋升？咱们以几个简略的查看项来举例说明一下。
（1）Input Task 数量查看
该查看项次要是针对 input 阶段 task 数量过多，然而 input 数据量不大的状况（这里不大，是指的小于等于目前咱们诊断配置的阈值，个别默认为 128Mb）。
在目前生产环境中，咱们发现很多 input 阶段的 stage 存在 10W+ 的 task 在运行。这里很多人会认为，这些工作应该会很快产出，工作没啥问题。
然而咱们通过理论的数据分析后发现以下规定：
input 阶段的 stage 存在巨量的 task，个别会随同 GC 查看项异样，GC 耗时占整个 stage 运行时长超过 10% 以上
雷同工作雷同阶段的 task 解决数据量减少，并不会使 task 的运行时长出现等比例的增长。因为调度开销以及序列化会有局部耗费，另外 input 阶段网络以及磁盘 IO 对 task 运行时长的影响较大
这种含有巨量 task 的 stage，不可能一轮就能运行结束
因而针对 input 阶段的 stage，存在巨量的 task 运行并不是一个很好的主见。
针对该查看项，咱们个别会倡议用户将 spark.sql.files.maxPartitionBytes 配置进步，例如由默认的 128Mb 进步至 512Mb。咱们能够简略的计算下，大抵对于该阶段的 stage 资源以及时长能节约多少：
原先每个 task 解决数据量：128Mb
原先 input 阶段 stage 的 task 数量：16w
该工作同时最大 task 运行数量：2w
原先一轮 task 运行耗时：t
现每个 task 解决数据量：512Mb
现 input 阶段 stage 的 task 数量：4w
该工作同时最大 task 运行数量：2w
数据量增长后，task 耗时增长倍数：2.5(数据量晋升 4 倍后，大抵为 2 - 3 倍的耗时减少)
资源：
该阶段 vcore 资源降落比例：37.5% = (2w 16w/2w t – 2w 4w/2w 2.5t) / (2w 16w/2w t)
如果算上 GC 耗时的升高，该阶段 vcore 资源降落比例应为：40%+
时长：
该阶段运行时长降落比例：37.5% = (16w/2w t – 4w/2w 2.5t) / (16w/2w * t)
如果算上 GC 耗时的升高，该阶段运行时长同样降落比例应为：40%+
（2）ExecutorCores 空跑查看
该查看项次要是针对 Executor 只有大量的 core 在运行 task，其余大量的 core 在空跑的状况。
在目前的生产环境中，咱们发现一些工作存在 Executor 只有不到一半的 core 在运行 task，其余的 core 均在空跑。造成这个景象的起因，次要是 Spark 工作在运行过程中每个 Stage 的 task 数量均会变动，若某个 Stage 的 task 数量骤减，且该数量小于以后可用的 core 数量，在认为每个 task 占用一个 core 的状况下，会存在大量 Exeucotors 的 core 呈现空跑。因为在以后生产环境中，一个 Executors 常常会被调配 4 个 core，若其中只有一个 core 被占用，那么这个 executors 既不会被开释，且另外的 3 个 core 也处于空跑节约的状况。
该景象会造成工作大量的占用集群的 vcore 计算资源，然而却没有应用，升高工作以及该集群的资源利用率。
针对该查看项，咱们个别会倡议用户将 spark.executor.cores 升高一半，以及将 spark.locality.wait.process 配置调大以保障更多的 task 能调配至一个 executor 中。咱们也能够简略的计算下，该操作大抵对于该阶段的 stage 资源能节约多少：
原该 stage 运行的 executor 数量：2000
原每个 executor 配置的 vcore 数量：4
现该 stage 运行的 executor 数量：2000
现每个 executor 配置的 vcore 数量：2
资源：该阶段 vcore 资源降落比例：50% = (2000 4 – 2000 2) / (2000 * 4)
3.3 工作产出阶段
工作产出阶段，目前诊断的比较简单。次要通过数据量、时长的统计，来判断是否存在问题。如果存在问题，关联 hdfs 以及 metastore 进行问题的进一步定位。
在此不进一步进行介绍了。
04 业务方是怎么应用这块性能并优化的？
在目前的 EasyEagle 产品中，业务方进行上述的优化操作其实非常简单。依据工作运行概览中的可优化工作列表展现的优化倡议进行相干解决即可，如下所示：
该列表目前临时只能展现所选标签下的工作列表（已排序，依照该标签打分进行排序）。后续版本将会以工作维度，通过工作运行时长以及资源耗费排序展现工作全副异样标签。
业务方在点击具体 app id 时，能够跳转至工作的全链路诊断详情页面，该页面会将工作全副的异样查看项进行展现，并会历史相干数据进行比照展现。让用户也进一步理解优化前后的资源、时长状况。
05 背有余思考
业务方确实能够十分不便的通过可优化工作列表获取相干工作以及优化倡议，然而优化操作其实对于用户并不敌对，须要用户进行手动配置批改。平台侧对于周期提交的工作，是否能够通过目前咱们 EasyEagle 提供的优化倡议，进行主动的配置调优，而不依赖用户手动性的行为？
