如何为组织业务提供帮助

1)基于MultipartUpload的FileOutputFormat实现

针对Spark访问OSS的特点，我们全新实现了Hadoop FileOutputFormat接口，如上图所示。算法的改进重点在优化合并操作，合并的核心是解决文件何时可见的问题。OSS提供MultipartUpload接口，也就是断点续传功能，文件可以分片上传，上传没有结束，分片文件是不可见的。借助该特性，我们可以让Task直接将数据写入到最终目录，只有作业成功才让文件最终可见，该方法不用先写入临时目录，也就大大减少了元数据的操作。对于执行失败的Task写入的临时分片，我们在作业结束时，执行Abort操作，就可以将其删除，这也就降低了空间占用。

针对Spark典型ETL Benchmark Terasort，在1TB输入数据量的情况下，DLA FileOutputFormat执行时间缩短62%，性能提升163%。而针对动态分区场景，社区算法1运行失败，算法2可以执行成功，DLA FileOutputFormat算法相比算法2性能还要进一步提升124%。

(2)OSS元数据Cache

Spark读取OSS的过程中，在ResolveRelation阶段，Spark会遍历OSS的目录，解析表结构和分区结构，以及解析Schema，该过程中同样会有大量元数据操作，并且同一个OSS 对象的元数据会被访问多次。针对该问题，我们实现了对OSS元数据的缓存，第一次访问到的OSS对象元数据就会被缓存到本地，后续如果访问该对象直接读取本地缓存。这种方式可以最大限度降低对OSS元数据的访问。Cache机制可以让ResolveRelation有1倍左右的性能提升，针对典型的Spark查询场景，该机制整体可以提升60%的性能。

2 多租户UI服务

UI服务对于开发者来说至关重要，开发人员依赖UI服务进行作业调试，以及生产作业的问题排查。好的UI服务可以很好地加速研发效率。

HistoryServer的痛点

Spark社区提供HistoryServer提供对Spark历史作业的UI和日志服务，在实际应用中遇到诸多痛点，典型如下：

(1)Eventlog空间开销大

HistoryServer依赖Spark引擎将运行中的Event信息全部记录到FileSystem中，然后后台回放并绘出UI页面。对于复杂作业和长作业Eventlog量较大，可以达到百GB甚至TB级别。

(2)复杂作业和长作业不支持

复杂作业或者长作业的Eventlog很大，HistoryServer会解析失败，甚至OOM。再加上空间开销大的原因，用户一般都只能关闭Eventlog。

(3)Replay效率差，延迟高

HistoryServer采用后台Replay Eventlog的方式还原Spark UI，相当于把Spark引擎的事件全部重放一遍，开销大，会有延迟。特别是作业较多或者较复杂的情况下，延迟可达分钟甚至十分钟级别。

DLA多租户SparkUI
 

3 高吞吐网络带宽

访问OSS服务是通过高吞吐的带宽服务。

使用ENI技术访问自持VPC，跟在自持VPC内ECS上部署计算引擎访问自持VPC内数据一样，带宽同样是VPC内网带宽。

四 Serverless Spark服务的技术挑战

Apache Spark是目前社区最为流行的开源引擎，不但具备流、SQL、机器学习以及图等计算能力，也可以连接丰富的数据源。但是，面对数据湖场景，传统集群版Spark方案，除了面临前面提到的数据管理困难、运维成本、计算资源弹性能力不足、企业级能力弱等问题外，还面临访问OSS的性能不佳、复杂作业难以调试等问题。

借助于第二章节提到的数据湖管理机制，可以很好地解决数据管理难题。借助于第三章节提到的多租户安全平台，DLA Spark实现了全新的云原生Serverless产品形态，很好地解决了弹性问题、运维成本问题以及企业级需求问题。本章节对Spark访问OSS的性能优化以多租户UI服务做进一步展开。

1 Spark访问OSS优化

社区版本的问题

开源版Spark访问OSS数据默认采用Hadoop FileFormat接口直接对接OSSFileSystem实现。该方法在实践中发现存在性能差，一致性难以保证等问题。

(1)Spark访问OSS性能差

核心原因在于OSS KV模型跟HDFS文件树模型的差异。FileFormat算法最初设计是基于HDFS文件系统，然而对象存储如OSS，为了解决扩展性，本质上采用的是KV模型。KV模型相对于HDFS文件系统差异较大，比如RenameDirectory接口，在HDFS中只是指针操作，但在KV中，需要将所有子文件和目录的KV执行Rename，性能开销很大，并且保证不了原子性。Hadoop FileOutputFormat在写入数据的时候先写到临时目录，最后写入最终目录，临时目录到最终目录的过程中需要做文件树合并，合并过程中有大量Rename操作。

(2)一致性难保证

FileFormat v1算法中，合并文件树操作全部在AppMaster单点执行，效率非常低，尤其是动态分区场景。为了解决AppMaster单点，社区提供了算法2，其核心思路是将合并过程并行到Task中执行，在性能上会有一定的提高，但是，如果Job执行失败，部分成功的Task会将数据写入最终数据目录，导致脏数据问题。

Spark OSS访问优化

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!