导读

唯品会离线平台SPARK2.3.2无缝升级到SPARK3.0.1版本，完全做到了对用户透明，目前正按着既定方案进行升级，新的版本SPARK CORE/SQL/PySpark进行了优化和BugFix，并且Merge了SPARK vip 2.3.2 重要Patch，在性能和易用性上比旧版本都有较大提升。这篇文章介绍了我们升级SPARK过程中遇到的挑战和思考，希望能给大家带来启发。

Spark应用现状

本次版本升级之前，唯品会大数据平台使用的主要版本为SPARK2.3.2，并且在社区版本上做了增强和BugFix，为用户提供SparkSQL/SparkJar/PySpark/SparkStream/Spark ML。现在集群有2300物理机，每天有1.2w SPARK 定时作业，8w个实例 在YARN上运行，Spark Adhoc日查询次数9000。

SPARK在公司推荐使用效果不错，作为批处理默认引擎。从下面图反映SPARK在唯品会大数据应用有半壁江山。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

SPARK3.0特性和升级背景

Spark SQL是3.0.1中最侧重组件。已解决ISSUE 46％用于Spark SQL。使基于SQL高级别的库（包括结构化流和MLlib）和更高级别的API包括SQL和DataFrames）受益。这也迎合我们现在的主要场景(我们现在90%是SQL)，同时也是优化痛点和主要功能点。

PySpark现在是Spark非常活跃的模块。此版本改善了功能和可用性，包括使用Python类型提示重新设计了Pandas UDF API，新的Pandas UDF类型以及更多的Python错误处理。这为我们新的战场比如推荐，特征工程，下一代AI平台等项目提供更好支持。

Spark 3.0中的功能亮点：自适应查询执行；动态分区修剪；符合ANSI SQL；Pandas API的重大改进；用于结构化流的新UI；加速器感知调度器；增强测试和SQL参考文档。达到了增效降本的目的。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

升级Vip SPARK3.0

主要升级节点(如下图)

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

合并HIVE VIP1.2.1 patch到2.3.7

合并SPARK VIP2.x patch到3.0.1

灰度上线spark3.0和bugfix

线上作业灰度计划

*注解p0/p1/p2/p3 为作业重要度级别，以此递减（下图为灰度作业流程）

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：过往记忆大数据

bugfix和兼容线上2.3.2

灰度线上作业发现BUG不少，但BUG分优先级，优先级高先处理。

灰度线上作业和不断bugfix是一个迭代过程，不断完善和修复因为SPARK3.0上线导致线上问题。

挑战和应对

内部 patch 如何兼容

挑战：Spark2.x 自研功能比如: 小文件合并；支持权限检验；STS 超时杀任务；Shuffle 文件动态清理等都是是基于2.x打的patch，但是3.0相比2.x整个核心变化比较大， merge到3.0难度增大，测试和灰度工作量增加。

应对：有些patch基于3.0是重新开发一次。

SQL 语法兼容

挑战：历史包袱， 线上用户SQL掌握熟练程度不一样，不规范的SQL大有存在，2.x对语法没有那么强制，但3.0默认相对2.x严格一点，这样对灰度线上作业阻力巨大，对保障SLA有冲击。比如: 表不存在删表；数据插入数据列类型和元数据字段是否检验；敏感日期格式化；SQL文件设置非SQL参数报错等。

应对：大部分是兼容2.x版本，少数修改作业兼容3.0.

新版本BUG不少

挑战：灰度线上作业出现十几个bug，比如: 注释后面分号无法识别；stage和推测task对应关系找不到；执行SQL文件，中间某段SQL报错，不会立刻退出整个执行，导致数据质量问题；metric 在application结束之后没有complete等。

应对：及时快速Bugfix。

线上作业灰度工作量大

挑战：线上作业类型(批处理、流处理、机器学习、adhoc、pyspark和sparkjar)多，作业量大(线上有1.2w个作业)，重要业务，核心全链路必须保障SLA 等情况下， 灰度作业压力不小。而且出现新的bug, 压力就倍增。

应对：必须停止灰度，快速BugFix再灰度。

总结

平滑升级，SPARK组件每次升级都需要做到尽量对用户毫无感知(后台修改spark_version切换)，升级，灰度，回滚，监控都是平台自动统一处理；

升级充分准备，对新版本的憧憬和敬畏都不可或缺，升级之前要对社区新版本的feature和BUG要有足够的认知，甚至对升级版本和最新版本之间的issue也要有足够的了解，因为后面版本issue很大一部分是对前面的版本进行优化和bugfix，这样才能做到心中有数，比如3.1已经修复不少3.0bug；

升级策略，社区重大版本一般与线上版本核心架构差异很大，比如3.0加入自适应导致spark sql模块和shuffle service服务发生重大变化，直接在2.3.2基础上 merge 3.0难度较大，风险也高，建议3.x基础之上merge 2.3.2的patch进行升级；

真理来源于实践，从2.1.1升级到2.3.2为本次2.3.2升级3.0积累不少的经验和套路，为本次升级少走弯路和保障SLA;

吸取社区，本次升级完3.0不是终点，Spark社区非常活跃，3.1已经出来了，中间有很多非常好的issue, 都需要merge vip SPARK 3.0, SPARK优化永无止境;

回馈社区，近期打算把VIP SPARK main Patch 比如: 小文件合并；支持权限检验；STS 超时杀任务；Shuffle 文件动态清理 等提交社区。

本文原文：唯品会 Apache Spark 3.0 升级之路