企业大数据实战：Kyuubi 与 Spark ThriftServer 的全面对比分析

网易数帆旗下易数大数据团队开源的 Kyuubi，和 Spark 社区的Spark Thrift Server，都是通过纯 SQL 语言和 JDBC 接口的方式降低大数据使用门槛的项目。本文从企业大数据应用场景关注的问题出发，对比了 Kyuubi 与 Spark Thrift Server 的差异与优劣，并引入HiveServer2 进行全面的分析。

1 Spark Thrift Server 介绍

Spark Thrift Server 是Apache Spark社区基于HiveServer2实现的一个Thrift服务，旨在无缝兼容HiveServer2。它通过JDBC接口将Spark SQL的能力以纯SQL的方式提供给终端用户。这种“开箱即用”的模式可以最大化地降低用户使用Spark的障碍和成本。我们先从传统的 Spark 作业提交方式入手，谈谈 Spark Thrift Server 具备的优势。

1.1 传统作业方式

在没有 Spark Thrift Server 的情况下，Spark 作为大数据处理工具，可能并不是对所有人都那么“友好”。

1.1.1 门槛高

用户通过Spark提供的 Scala/Java/Python 等接口使用 Spark时都需要一定的编程基础。同时，用户需要具备良好的大数据背景。举例来说，用户需要知道他们的程序最终提交哪个平台上，YARN、Kubernetes或者是别的平台？用户也需要知道如何去配置他们所提交作业的资源使用，需要多少的 Executor 数，每个 Executor 该配置多少的内存和CPU？他们自己又该知道怎么去合理的使用集群上的资源呢？用多了，会不会对其他关键任务造成影响？用少了，集群的资源是不是闲置浪费？成千上百的配置如何去设置？动态资源调度，自适应查询，推测执行，这些关键特性该如何无成本的应用到各个任务中去？

1.1.2 不安全

用户通过代码的方式访问元数据和数据，数据安全性无法保证，“删库跑路”轻而易举。所有的客户端配置需要直接或者间接的交到用户手中。一方面，这些配置本身就可能包含一些敏感信息；另一方面，后台的服务也基本上“裸露”在用户的面前。很多企业使用 Spark 的时候都会魔改加入一些适配自己场景的特性。例如在数据安全方面，可能大家都用过或者参考过网易开源出来 spark-authorizer 插件通过 Apache Ranger 来实现细粒度的 SQL Standard Based Authorization。但这种安全特性，通过 Spark 代码提交作业的方式，在会写代码的程序员面前，只是约束力不强的“君子协定”。

1.1.3 兼容性

客户端兼容性难以保证。一个用户的 Spark 作业最终被调度到集群上运行，面临着客户端环境和集群环境不一致，用户作业依赖和 Spark 或 Hadoop 依赖冲突等问题。如果团队选择维护一个内部魔改的 Spark 或者 Hadoop 版本，在这些版本的开发过程中，需要时刻注意是否能保持用户接口的兼容性。在各底层版本服务端的升级换代过程中，也需要尽可能的完成用户客户端的升级，这时候就可能引入许多不必要的兼容性测试工作，而且很容易出现测试覆盖不全的问题。

1.1.4 延时高

Spark Application的启动延时。按作业的生命周期维度分类，我们可以简单的将 Spark 任务简单的分为两种，常驻类型和非常驻类型。常驻类型作业的特点就是 Application的启动时间相对于总任务运行时长来讲忽略不计或者和计算过程完全解绑，如 Spark Structed Streaming任务，计算过程只有 Task 线程级别的调度，低延时快响应。而非常驻类型的作业，每次都需要启动 Spark 程序。相对而言，这个过程是非常耗时的，特别对于一些秒级分钟级的计算任务负担较重。

1.2 Spark ThriftServer 方式

Spark Thr