存算分离下写性能提升10倍以上，EMR Spark引擎是如何做到的？

腾讯云大数据

发布于 2020-10-16 11:10:21

1.4K0

发布于 2020-10-16 11:10:21

文章被收录于专栏：腾讯云大数据腾讯云大数据

引言

随着大数据技术架构的演进，存储与计算分离的架构能更好的满足用户对降低数据存储成本，按需调度计算资源的诉求，正在成为越来越多人的选择。相较 HDFS，数据存储在对象存储上可以节约存储成本，但与此同时，对象存储对海量文件的写性能也会差很多。

腾讯云弹性 MapReduce(EMR) 是腾讯云的一个云端托管的弹性开源泛 Hadoop 服务，支持 Spark、Hbase、Presto、Flink、Druid 等大数据框架。

近期，在支持一位 EMR 客户时，遇到典型的存储计算分离应用场景。客户使用了 EMR 中的 Spark 组件作为计算引擎，数据存储在对象存储上。在帮助客户技术调优过程中，发现了 Spark 在海量文件场景下写入性能比较低，影响了架构的整体性能表现。

在深入分析和优化后，我们最终将写入性能大幅提升，特别是将写入对象存储的性能提升了 10 倍以上，加速了业务处理，获得了客户好评。

本篇文章将介绍在存储计算分离架构中，腾讯云 EMR Spark 计算引擎如何提升在海量文件场景下的写性能，希望与大家一同交流。文章作者：钟德艮，腾讯后台开发工程师。

一、问题背景

Apache Spark 是专为大规模数据处理而设计的快速通用的计算引擎，可用来构建大型的、低延迟的数据分析应用程序。Spark 是 UC Berkeley AMP lab (加州大学伯克利分校的 AMP 实验室)所开源的类 Hadoop MapReduce 的通用并行框架，Spark 拥有 Hadoop MapReduce 所具有的优点。

与 Hadoop 不同，Spark 和 Scala 能够紧密集成，其中的 Scala 可以像操作本地集合对象一样轻松地操作分布式数据集。尽管创建 Spark 是为了支持分布式数据集上的迭代作业，但是实际上它是对 Hadoop 的补充，可以在 Hadoop 文件系统中并行运行，也可以运行在云存储之上。

在这次技术调优过程中，我们研究的计算引擎是 EMR 产品中的 Spark 组件，由于其优异的性能等优点，也成为越来越多的客户在大数据计算引擎的选择。

存储上，客户选择的是对象存储。在数据存储方面，对象存储拥有可靠，可扩展和更低成本等特性，相比 Hadoop 文件系统 HDFS，是更优的低成本存储方式。海量的温冷数据更适合放到对象存储上，以降低成本。

在 Hadoop 的生态中，原生的 HDFS 存储也是很多场景下必不可少的存储选择，所以我们也在下文加入了与 HDFS 的存储性能对比。另外我们也对比了腾讯云 CHDFS 提供的高可用高可靠的云端 HDFS 存储服务[1]。

回到我们想解决的问题中来，先来看一组测试数据，基于 Spark-2.x 引擎，使用 SparkSQL 分别对 HDFS、对象存储写入 5000 文件，分别统计执行时长：

从测试结果可以看出，写入对象存储耗时是写入 HDFS 的 29 倍，写入对象存储的性能要比写入 HDFS 要差很多。而我们观察数据写入过程，发现网络 IO 并不是瓶颈，所以需要深入剖析一下计算引擎数据输出的具体过程。

二、Spark数据输出过程剖析

1. Spark数据流

先通过下图理解一下 Spark 作业执行过程中数据流转的主要过程：

首先，每个 task 会将结果数据写入底层文件系统的临时目录 _temporary/task_[id]，目录结果示意图如下所示：

到此为止，executor 上的 task 工作其实已经结束，接下来将交由 driver，将这些结果数据文件 move 到 hive 表最终所在的 location 目录下，共分三步操作：

第一步，调用 OutputCommiter 的 commitJob 方法做临时文件的转存和合并：

通过上面示意图可以看到，commitJob 会将 task_[id] 子目录下的所有数据文件 merge 到了上层目录 ext-10000。

接下来如果是 overwrite 覆盖写数据模式，会先将表或分区中已有的数据移动到 trash 回收站。

在完成上述操作后，会将第一步中合并好的数据文件，move 到 hive 表的 location，到此为止，所有数据操作完成。

2. 定位分析根因

有了上面对 Spark 数据流的分析，现在需要定位性能瓶颈在 driver 端还是 executor 端？观察作业在 executor 上的耗时：

发现作业在 executor 端执行时长差异不大，而总耗时却差异却非常大，这说明作业主要耗时在 driver 端。

在 driver 端有 commitJob、trashFiles、moveFiles 三个操作阶段，具体是在 driver 的哪些阶段耗时比较长呢？

我们通过 spark-ui 观察 Thread dump (这里通过手动刷新 spark-ui 或者登录 driver 节点使用 jstack 命令查看线程堆栈信息)，发现这三个阶段都比较慢，下面我们来分析这三部分的源码。

3. 源码分析

（1）JobCommit阶段

Spark 使用的是Hadoop的FileOutputCommitter来处理文件合并操作， Hadoop 2.x 默认使用 mapreduce.fileoutputcommitter.algorithm.version=1，使用单线程 for 循环去遍历所有 task 子目录，然后做 merge path 操作，显然在输出文件很多情况下，这部分操作会非常耗时。

特别是对对象存储来说，rename 操作并不仅仅是修改元数据，还需要去 copy 数据到新文件。