如上文Apache Spark on ACK介绍，Spark on Kubernetes能给我们带来诸多优点，但社区版的解决方案还不是那么完善，存在以下几个关键问题：
- Shuffle流程，按照目前的Shuffle方式，我们是没办法打开动态资源特性的。而且还需要挂载云盘，云盘面临着Shuffle数据量的问题，挂的比较大会很浪费，挂的比较小又支持不了Shuffle Heavy的任务。
- 调度和队列管理问题，调度性能的衡量指标是，要确保当大量作业同时启动时，不应该有性能瓶颈。作业队列这一概念对于大数据领域的同学来说应该非常熟悉，他提供了一种管理资源的视图，有助于我们在队列之间控制资源和共享资源。
- 读写数据湖相比较HDFS，在大量的rename，list等场景下性能会有所下降，同时OSS带宽也是一个不可避免的问题。
为了让在ACK上更好的运行Spark工作负载，阿里云EMR和ACK团队做了大量优化工作，在架构、性能、稳定性、易用性方面都有着很大的提升。
EMR Spark on ACK解决方案
EMR Spark
EMR Spark是运行在阿里云平台上的大数据处理解决方案，在开源版Apache Spark的基础上做了大量性能、功能以及稳定性方面的改造，并且在和阿里云基础服务的适配上做了非常多的工作。主要有以下核心技术：
- 实现SparkSQL事务功能，支持update、delete语句。
- 实现PK、FK、NOT NULL等SQL Constraint，并应用在SQL优化中。
- 实现Relational Cache：SparkSQL的物化视图。
- 实现多租户高可用的SparkSQL JDBC Server。
- SparkSQL部分性能优化列表：
-
- 支持Runtime Filter。
- 使用Adaptive Execution，可在运行时调整作业行为。
- CBO Join Reorder进一步优化，支持遗传算法。
- Shuffle流程优化，构建异步非阻塞的Shuffle IO。
Remote Shuffle Service
Spark on kubernetes时会面临shuffle的问题，按照目前的shuffle方式，是没办法打开动态资源特性的。而且还需要挂载云盘，面临着shuffle数据量的问题，挂的大会很浪费，挂的小又支持不了shuffle heavy的任务。针对这个问题，我们设计了shuffle读写分离的架构，称为Remote Shuffle Service，对现有的shuffle机制做了比较大的优化，解决了计算存储分离和混合架构下的shuffle稳定性和性能问题。可以总结为以下3点：
- Shuffle数据通过网络写出，中间数据计算与存储分离架构。
- DFS 2副本，消除fetch failed引起的重算，shuffle heavy作业更加稳定。
- Reduce阶段顺序读磁盘，避免现有版本的随机IO，大幅提升性能。
JindoFS
计算存储分离已经成为云计算的一种发展趋势。在计算存储分离之前，普遍采用的是传统的计算存储相互融合的架构，但是这种架构存在一定的问题，比如在集群扩容的时候会面临计算能力和存储能力相互不匹配的问题。用户在某些情况下只需要扩容计算能力或者存储能力，而传统的融合架构不能满足用户的这种需求，进行单独的扩充计算或者存储能力；其次在缩容的时候可能会遇到人工干预，人工干预完后需要保证数据在多个节点中同步，而当有多个副本需要同步时候，可能会造成的数据丢失。计算存储分离架构则可以很好的解决这些问题，使得用户只需要关心整个集群的计算能力，但同时也会引入读写数据网络延迟的问题。
JindoFS是一种云原生的文件系统，结合OSS和本地存储，成为EMR产品的新一代存储系统，为上层计算提供了高效可靠的存储。JindoFS 提供了块存储模式（Block）和缓存模式（Cache）的存储模式， 采用了本地存储和OSS的异构多备份机制，Storage Service提供了数据存储能力，首先使用OSS作为存储后端，保证数据的高可靠性，同时利用本地存储实现冗余备份，利用本地的备份，可以加速数据读取，解决了网络延迟的问题；另外，JindoFS的元数据通过本地服务Namespace Service管理，从而保证了元数据操作的性能（和HDFS元数据操作性能相似）。
性能评测
为了验证EMR Spark在ACK上的性能，我们通过TPC-DS进行对比评测。TPC-DS测试基准是TPC组织推出的一个决策支持系统测试基准，TPC-DS采用星型、雪花型等多维数据模式。它包含7张事实表，17张纬度表平均每张表含有18列。其工作负载包含99个SQL查询，覆盖SQL99和2003的核心部分以及OLAP。这个测试集包含对大数据集的统计、报表生成、联机查询、数据挖掘等复杂应用，测试用的数据和值是有倾斜的，与真实数据一致。可以说TPC-DS是与真实场景非常接近的一个测试集，也是难度较大的一个测试集。
测试环境
首先准备测试环境，在ACK上新建一个标准版集群或标准专有集群，安装依赖的组件。
集群配置
ACK集群说明
| 集群配置 | 参数 |
|---|---|
| 集群类型 | ACK标准集群 |
| 集群版本 | 1.16.9-aliyun.1 |
| ECS实例 | ECS规格：ecs.d1ne.6xlarge操作系统：CentOS 7.7 64位CPU: 24核内存：96G数据盘：5500GB HDD x 12 |
| Worker Node个数 | 20 |
ecs.d1ne.6xlarge 大数据机型，默认带了12块5500GB的HDD数据盘，需要mount一下才能使用。
组件配置
ack-spark-operator
在ACK应用目录中安装，用来提交SparkApplicaiton作业。
ack-spark-history-server （非必要）
在ACK应用目录中安装，记录Spark执行任务过程中的event-log，并提供UI界面，方便排查问题。
JindoFS
在ACK应用目录中安装，用来实现数据的分布式缓存加速。
EMR Spark
在社区版Apache Spark深度优化的版本。
Remote Shuffle Service
Shuflle读写分离架构。
注意：EMR Spark 和 Remote Shuffle Service 可通过文章结尾处的钉钉群联系我们获取安装方式。
测试数据
基于TPC-DS生成的1TB和10TB测试数据，生成数据的情况可参考TPC-DS生成数据。
测试结果
1. EMR Spark vs Apache Spark
测试数据：10TB
纵轴单位：秒
在10TB数据上测试，EMR Spark相比社区版本Spark约有57%的性能提升，详细测试过程参考使用EMR Spark运行Spark工作负载。
2. EMR Spark vs EMR Spark + EMR Shuffle Service
测试数据：10TB
纵轴单位：秒
在10TB数据上，增加Remote Shuffle Service后，相比直接使用EMR Spark，约有16%的性能提升。详细测试过程请参考使用EMR Spark + Remote Shuffle Service运行Spark工作负载。
3. EMR Spark vs EMR Spark + JindoFS
测试数据：1TB
纵轴单位：秒
在1TB数据上，使用JindoFS做数据分布式缓存后，相比直接使用EMR Spark，得到约15%性能提升。详细测试过程请参考使用EMR Spark + JindoFS运行Spark工作负载。
测试总结
通过上面几组对比可以看到，EMR Spark相比社区版Spark有大幅度的性能提升，而通过Remote Shuffle Service和JindoFS也分别解决了存储计算分离架构带来的Shuffle和数据本地化问题。另外，需要说明的是Remote Shuffle Service和JindoFS在比较适用于数据量大的场景，用户可以根据自己的需要灵活组合使用。
展望
对于Spark on ACK的后续发展，我们一方面是要达到运维一体化，另一方面主要希望做到更好的性价比，主要有以下几点工作：
- 可以将k8s计算资源分为固定集群和Serverless集群的混合架构，固定集群主要是一些包年包月、资源使用率很高的集群，Serverless是做到按需弹性。
- 可以通过调度算法，灵活的把一些SLA不高的任务调度到Spot实例上，就是支持抢占式ECI容器，这样可以进一步降低成本。
- 由于提供了Remote Shuffle Service集群，充分让Spark在架构上解耦本地盘，只要Executor空闲就可以销毁。配合上OSS提供的存算分离，必定是后续的主流方向。
- 对于调度能力，这方面需要特别的增强，做到能够让客户感受不到性能瓶颈，短时间内调度起来大量的作业。同时对于作业队列管理方面，希望做到更强的资源控制和资源共享。
欢迎加入钉钉群沟通交流。
