eBay Hadoop/Spark 自助分析系统实践

来源：eBay技术荟

eBay 一直倡导数据驱动业务。数据处理和分析的及时与深入与否，直接影响了业务的效益。因此，一站式的工作负载自助分析工具对数据处理工程师和平台的运维人员显得尤为重要。

“为什么处理作业要比平时运行得慢?”

“最近有哪些作业失败了?它们为什么失败?”

“哪个作业占用了平台最多的资源?”

”平台上是不是还能支撑更多的工作负载?“

这是数据处理工程师以及分析师和数据平台管理员之间经常发生的对话。我们亟需一个智能化的工作负载管理引擎提供自助分析体验使得管理员能轻松驾驭这些日常的问题，从而达到：

♦ 帮助用户更快地进行应用程序排错

♦ 对于应用程序的性能问题，可以很快给出有效建议

♦ 通过应用程序优化，提高集群的整体利用率

在一个多租户的 Hadoop 环境中，首要解决的问题是如何有效实现系统资源的隔离和共享，并能最大化利用系统的资源。在提供 Workload Analytics System 能力之前，我们尝试了其他各种方法来解决集群的性能问题，但终究无法让我们深入了解集群。Workload Analytics System 为我们解决问题提供了详细的数据支撑，细粒度的作业、平台指标监控 - 给管理员、开发者、业务运维工程师提供近乎实时的平台运行洞察。

下面将从 集群资源监控 和 用户作业监控 两方面入手详细阐述 eBay 大数据团队行之有效的解决方案。

集群资源监控

首先，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 的分布式作业处理提供了大规模数据处理的便利性，但与此同时也给作业诊断带来了一定的挑战。分布式计算的任务被分配到了大量不同的计算节点上，任务运行时的作业也都分不到不同的节点上。一旦发生应用程序的任务错误，分布式框架并没有把任务的运行日志集中进行分析。用户如果要知道一些具体的原因，通常要查看大量的任务运行日志，以确定问题的错误根源。作业错误诊断功能旨在提供快速的错误分析能力，尽量避免让用户去查看大量的原始日志信息，从而加快任务排错。如图例：

 

 

从作业仪表盘的错误应用视图出发，可以详细的罗列所有问题作业，包含它们的作业名，用户名(包括个人用户或者批处理账号), 作业使用的资源池名称，等等。

 

 

进入作业的具体信息页面，Workload Analytics System 展现了最有可能的直接错误原因。诚然，这个错误诊断能力并不能完全分析出所有的错误直接原因，比如，应用经常会出现的 TimeoutException 或者 InterruptedException，但我们希望 95% 的错误应用都可以通过错误诊断功能直接找到原因，还有一些错误，还需要用户综合多方面的日志信息，进行线下分析。高度自动的错误诊断能力着实降低了用户排错 Hadoop/Spark 任务的门槛，也极大压缩了错误诊断的时间，加快了应用的上线的频率。

【作业性能分析】

严重的作业性能问题不仅影响了作业自身的 SLA，同时也会影响集群或者同一资源池中其他作业的运行，或者是整个集群的性能，比如说作业的过量 RPC 操作降低了 NN 的 RPC 吞吐。在作业仪表盘视图中，Workload Analytics System 也突出了性能问题的应用，进入之后，我们为用户高亮了所有有待改善的应用程序列表，以及性能问题的严重性。如图例：

 

 

我们默认只显示了包含有严重级别以上的提示的作业，进入每一个具体的严重问题之后，Workload Analytics System 显示了详细的性能问题类别以及优化建议，同时给了了对应优化项的具体说明。

 

 

【作业资源优化】

在作业仪表盘中另外两个问题都和集群的资源使用相关，对每个应用，Workload Analytics System 都计算了它们的 HCU 消耗，包括实际使用的 HCU 消耗，以及申请的 HCU。

默认情况下，对于绝对资源使用超过集群 0.1% 的作业，我们认为是过大的，这类作业是需要做针对性的优化的，比如是不是作业的任务数太多，任务的请求的资源过多，或者大量任务的执行时间过长。集群是一个多租户环境，每天都大几万个批处理在执行，任何一些大资源占用作业的运行都可能会影响集群的多租户能力提供。

 

 

对于绝对资源的使用我们要严格控制，这类作业通常要在业务逻辑上进行优化;另外我们也要控制资源的浪费，就是申请的 HCU 必须和实际的 HCU 使用值相近，因为 YARN 的资源分配是按照申请值来分配的，浪费的越多会造成系统的吞吐下降。默认情况下，对于资源的浪费比例超过 40%，并且浪费的绝对值超过集群整体万分之五的作业也是需要用户去做针对性优化的。

综上，Workload Analytics System 是我们追求卓越运营的必然产物，一方面增强了平台用户体验，自动排错诊断，性能预警;另一方面也降低了集群资源使用浪费的现象。

标签： Hadoop Spark 

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。