导读：在滴滴SQL任务从Hive迁移到Spark后，Spark SQL任务占比提升至85%，任务运行时间节省40%，运行任务需要的计算资源节省21%，内存资源节省49%。在迁移过程中我们沉淀出一套迁移流程， 并且发现并解决了两个引擎在语法，UDF，性能和功能方面的差异。

一、迁移背景

Spark自从2010年面世，到2020年已经经过十年的发展，现在已经发展为大数据批计算的首选引擎，在滴滴Spark是在2015年便开始落地使用，不过主要使用的场景是更多在数据挖掘和机器学习方向，对于数仓SQL方向，主要仍以Hive SQL为主。

下图是当前滴滴内部SQL任务的架构图，滴滴各个业务线的离线任务是通过一站式数据开发平台DataStudio调度的，DataStudio把SQL任务提交到HiveServer2或者Spark两种计算引擎上。两个计算引擎均依赖资源管理器YARN和文件系统HDFS。

在迁移之前我们面临的主要问题有：

• SQL任务运行慢：迁移前SQL任务运行的平均时间是20分钟，主要原因是占比高达83%的Hive SQL任务运行时间长，Hive任务执行过程中会启动多个MR Job，Job间的中间结果存储在HDFS，所以同一个SQL， Hive比Spark执行的时间更长；
• Hive SQL稳定性差：一个HS2会同时执行多个用户的Hive SQL任务，当一个异常任务导致HS2进程响应慢甚至异常退出时，运行在同一个实例的SQL任务也会运行缓慢甚至失败。而异常任务场景各异。我们曾经遇到的异常任务有多个大SQL加载过多的分区元数据导致HS2 FullGC，加载UDF时导致HS2进程core dump，UDF访问HDFS没有关闭流导致HS2机器端口被打满，这些没有通用解法， 问题很难收敛；
• 人力分散：两个引擎需要投入双倍的人力，在人员有限的情况下，对引擎的掌控力会减弱；

所以为了SQL任务运行更快，更稳，团队人力聚焦，对引擎有更强的掌控力，我们决定把Hive SQL迁移到Spark SQL。

二、迁移方案概要设计

Hive SQL迁移到Spark SQL后需满足以下条件：

• 保证数据一致性，也就是相同的SQL使用Spark和Hive执行的结果应该是一样的；
• 保证用户有收益，也就是使用Spark执行SQL后应该节省资源，包括时间，cpu和memroy；
• 迁移过程对用户透明；

为了满足以上三个条件， 一个很直观的思路就是使用两个引擎执行用户SQL，然后对比每个引擎的执行结果和资源消耗。

为了不影响用户线上数据，使用两个引擎执行用户SQL有两个可选方案：

复用现有的SQL任务调度系统，再部署一套SQL任务调度系统用来迁移，这个系统与生产环境物理隔离；