导读：当下，企业越来越重视数据资产的价值，并以此作为提高行业竞争力的重要支撑。海量、多源的数据处理是实现其数据价值的必备能力。以Hadoop/Spark为核心的大数据处理技术已经成为现代企业数据平台的标准。为应对业务用户对工作负载自助分析的期望，eBay大数据团队开发出一套面向管理员和业务用户的Workload Analytics System。
互联网科技发展蓬勃兴起，人工智能时代来临，抓住下一个风口。为帮助那些往想互联网方向转行想学习，却因为时间不够，资源不足而放弃的人。我自己整理的一份最新的大数据进阶资料和高级开发教程，大数据学习群： 740041381就可以找到组织学习 欢迎进阶中和进想深入大数据的小伙伴加入
eBay一直倡导数据驱动业务。数据处理和分析的及时与深入与否，直接影响了业务的效益。因此，一站式的工作负载自助分析工具对数据处理工程师和平台的运维人员显得尤为重要。
“为什么处理作业要比平时运行得慢？”
“最近有哪些作业失败了？它们为什么失败？”
“哪个作业占用了平台最多的资源？”
”平台上是不是还能支撑更多的工作负载？“
这是数据处理工程师以及分析师和数据平台管理员之间经常发生的对话。我们亟需一个智能化的工作负载管理引擎提供自助分析体验使得管理员能轻松驾驭这些日常的问题，从而达到：
-
帮助用户更快地进行应用程序排错
-
对于应用程序的性能问题，可以很快给出有效建议
-
通过应用程序优化，提高集群的整体利用率
在一个多租户的Hadoop环境中，首要解决的问题是如何有效实现系统资源的隔离和共享，并能最大化利用系统的资源。在提供Workload Analytics System能力之前，我们尝试了其他各种方法来解决集群的性能问题，但终究无法让我们深入了解集群。Workload Analytics System为我们解决问题提供了详细的数据支撑，细粒度的作业、平台指标监控 - 给管理员、开发者、业务运维工程师提供近乎实时的平台运行洞察。
下面将从集群资源监控和用户作业监控两方面入手详细阐述eBay大数据团队行之有效的Workload Analytics System解决方案。
集群资源监控
首先，Workload Analytics System提供的实时资源监控可以让管理员和普通用户了解整个集群的资源使用状况，或者是对应的资源池的资源使用情况，以便了解到集群通常的的闲置或者繁忙时段，那么相关的作业调度可以做适当的调整。在闲置时间的调度，可以让计算资源得到该有的保证；在繁忙时段的资源调度会出现大量的争用情况。集群的普通用户偶尔会发现自己的批处理作业似乎运行变慢了，首先要查看的是资源的调度情况是不是有变坏的迹象，然后再去查看是不是有其他的原因导致。
对于集群的管理员或者一个资源池的所属者，他不仅仅要知道集群或者队列的整体繁忙情况，通常也要针对繁忙的情况给集群或者队列的使用者合理的说明，哪些作业在某个时间段占用了集群绝大多数的资源。Workload Analytics System提供了深度资源使用分析能力，可以让管理员很快地获取这些信息。如图例：
每个重要的集群都有资源的使用视图，不用的资源池占用的集群资源以不同的颜色标注，用户也可以选择不同粒度的资源池查看。在资源的使用视图上（Memory Usage）任意选择一个点，在下方的列表中就会显示在这个时间片段内使用资源最多的作业有哪些，默认是5分钟的间隔，用户可以根据自己的作业运行时长选择不同的时间段查看。
所有的资源表述都遵循HCU（Hadoop Compute Unit，1 HCU=1 GB*Sec）的定义。每个集群在某个时间段的资源总量可以用HCU来衡量，每个作业运行所消耗的资源也可以用HCU来衡量。
在这个资源使用视图下方，Workload Analytics System还提供了一些直观的准实时资源等待分析，包括有多少应用在等待被提交到YARN; 对于已经提交在运行或者还未提交应用，还有多少资源请求尚未被提供。
总之，在Workload Analyitics System的资源使用视图中，管理员可以概览资源的实时使用状况，以及那些应用有可能过度占用了集群的资源，对于这些应用，我们可以快速进入它们的详细资源使用分析，以确定相应的优化方案，这部分我们稍后会有详细介绍。
用户作业监控
除了提供集群的资源使用分析外，Workload Analytics System方便了用户的自助式排错或者优化体验，对作业的运行数据提供了全方位的分析，可以快速诊断作业的错误或者性能问题。
在eBay内部，ETL的作业仍然占用了绝对多数的资源，而且从我们长期的监测结果来看，Memory是系统的瓶颈所在，所以我们目前采用了Memory*Second来描述具体的资源。不管是MapReduce框架（包含Hive)，还是Spark作业，都是从YARN来分配资源的，每一个作业都有对应的资源（Memory）请求描述，已经占用资源的总体时间。
Workload Analytics System的作业仪表盘是一个自助式的程序性能管理门户，它从管理员或者用户对作业的错误和性能问题出发，为开发人员提供了用于故障排除和优化应用程序性能的统一视图。这个统一视图，使大多数开发者能够在一个地方或者相关的应用信息，性能建议，以便开发人员轻松快速的提高应用性能，有效利用集群的资源，提供更好的多租户管理使用体验。如图例:
从问题出发，作业仪表盘分析了用户过去一天总共有多少应用失败，有多少应用占用了绝大多数的集群资源，有多少应用向系统申请的资源要远比实际使用的要多，有多少应用有严重的作业性能问题。Workload Analytics System还呈现了资源使用的趋势图，以了解过去一段时间的作业优化对资源使用的优化结果，或者资源的异常使用情况，并作出下一步的详细分析。下面就作业错误诊断、作业性能分析、作业资源优化三个方面详细阐述。
【作业错误诊断】
Hadoop和Spark的分布式作业处理提供了大规模数据处理的便利性，但与此同时也给作业诊断带来了一定的挑战。分布式计算的任务被分配到了大量不同的计算节点上，任务运行时的作业也都分不到不同的节点上。一旦发生应用程序的任务错误，分布式框架并没有把任务的运行日志集中进行分析。用户如果要知道一些具体的原因，通常要查看大量的任务运行日志，以确定问题的错误根源。作业错误诊断功能旨在提供快速的错误分析能力，尽量避免让用户去查看大量的原始日志信息，从而加快任务排错。如图例：
从作业仪表盘的错误应用视图出发，可以详细的罗列所有问题作业，包含它们的作业名，用户名（包括个人用户或者批处理账号）,作业使用的资源池名称，等等。
互联网科技发展蓬勃兴起，人工智能时代来临，抓住下一个风口。为帮助那些往想互联网方向转行想学习，却因为时间不够，资源不足而放弃的人。我自己整理的一份最新的大数据进阶资料和高级开发教程，大数据学习群： 740041381就可以找到组织学习 欢迎进阶中和进想深入大数据的小伙伴加入
进入作业的具体信息页面，Workload Analytics System展现了最有可能的直接错误原因。诚然，这个错误诊断能力并不能完全分析出所有的错误直接原因，比如，应用经常会出现的TimeoutException或者InterruptedException，但我们希望95%的错误应用都可以通过错误诊断功能直接找到原因，还有一些错误，还需要用户综合多方面的日志信息，进行线下分析。高度自动的错误诊断能力着实降低了用户排错Hadoop/Spark任务的门槛，也极大压缩了错误诊断的时间，加快了应用的上线的频率。
【作业性能分析】
严重的作业性能问题不仅影响了作业自身的SLA，同时也会影响集群或者同一资源池中其他作业的运行，或者是整个集群的性能，比如说作业的过量RPC操作降低了NN的RPC吞吐。在作业仪表盘视图中，Workload Analytics System也突出了性能问题的应用，进入之后，我们为用户高亮了所有有待改善的应用程序列表，以及性能问题的严重性。如图例：
我们默认只显示了包含有严重级别以上的提示的作业，进入每一个具体的严重问题之后，Workload Analytics System显示了详细的性能问题类别以及优化建议，同时给了了对应优化项的具体说明。
【作业资源优化】
在作业仪表盘中另外两个问题都和集群的资源使用相关，对每个应用，Workload AnalyticsSystem都计算了它们的HCU消耗，包括实际使用的HCU消耗，以及申请的HCU。
默认情况下，对于绝对资源使用超过集群0.1%的作业，我们认为是过大的，这类作业是需要做针对性的优化的，比如是不是作业的任务数太多，任务的请求的资源过多，或者大量任务的执行时间过长。集群是一个多租户环境，每天都大几万个批处理在执行，任何一些大资源占用作业的运行都可能会影响集群的多租户能力提供。
对于绝对资源的使用我们要严格控制，这类作业通常要在业务逻辑上进行优化；另外我们也要控制资源的浪费，就是申请的HCU必须和实际的HCU使用值相近，因为YARN的资源分配是按照申请值来分配的，浪费的越多会造成系统的吞吐下降。默认情况下，对于资源的浪费比例超过40%，并且浪费的绝对值超过集群整体万分之五的作业也是需要用户去做针对性优化的。
综上，Workload Analytics System是我们追求卓越运营的必然产物，一方面增强了平台用户体验，自动排错诊断，性能预警；另一方面也降低了集群资源使用浪费的现象。