SQL Proxy 角色重叠

在原有架构中，我们以最简单的方式引入 Kyuubi，为客户提供了另一种查询引擎的可能，但是这样的引入很明显存在其短板：

1. JDBC 链路太长

用户从发起的 JDBC 连接到最终开始执行 SQL，中间需要分别经过 UniSQL 和 Kyuubi 服务。多个连接池的管理提升了总体的连接管理复杂度，在报错时更是不易分析查找。有赖于 Kyuubi 和 UniSQL 的稳定，在实际使用中暂未发现因多个连接池连接导致的严重影响，但风险和隐患依旧存在。

2. SQL Proxy 角色重叠

同为 SQL Proxy，UniSQL 和 Kyuubi 的角色存在重叠，很明显这样冗余的设计并不利于未来架构的发展。

3. Spark 版本不统一

基于历史原因，现有架构中我们为用户提供的是 Spark 2.4.6 和 Spark 2.3.1 版本，但是 Kyuubi 是需要搭载 Spark 3.x 版本。引入 Spark SQL 查询，又不能贸然将之前的版本 “一刀切”，我们只好暂时单独为 Kyuubi 部署 Spark3.x 版本。这就造成现在集群中存在不统一的 Spark 版本，增加运维的难度。

4. Zookeeper 版本不统一

我们使用的 CDH 发行版版本为 5.16.2，搭载版本为 3.4.5 的 Zookeeper。Kyuubi 的 HA 同样需要依赖 ZooKeeper，但是经过我们测试，使用 3.4.5 的 Zookeeper 会出现删除节点失败的情况，从而导致 Kyuubi Server 自动关闭。经过分析，这一 BUG 在更高版本中修复完毕。最终，我们只好单独部署 3.6.1 版本的 Zookeeper 供 Kyuubi 使用。

5. Sentry 权限与 Spark 的对接不易

CDH 限定了集群的权限管理服务为 Sentry。众所周知，Sentry 的设计架构简单，缺失更细粒度的权限控制，包括视图、行、列等。而且 Spark 没有原生支持 Sentry 的权限管控方式。虽然我们开发了针对 Sentry 的 Spark Extension 进行权限管控，更细粒度的管控依旧是我们很头疼的地方。

存算分离架构下的统一 SQL Proxy 实践

架构背景

随着多点 DMALL 全面 To B 转型，为越来越多的 B 端客户提供零售全渠道解决方案，需要具备在多云部署环境下提供更具性价比、可复用的大数据底层基座和平台工具链。我们也终于等到了一个契机，彻底甩开历史包袱，设计搭建存算分离、轻量级、可扩展、云中立大数据集群架构。

幸运的是，Spark on K8s 的技术趋于成熟，我们得以全面拥抱云原生。在 K8s 的基座上，我们合并了大数据计算集群和业务服务集群，甩开 CDH 的版本限制，剥离 Hadoop 生态的强依赖，充分利用对象存储，简化运维和部署，降低用户使用成本。

考虑到上一版架构中的部分遗留问题，在升级架构设计中，经过详细的调研、分析和选型，Kyuubi 也正式替换 UniSQL 作为 SQL Proxy，负责多套查询引擎的统一代理服务。

升级架构设计

在升级架构中，我们充分考虑到之前版本不一致的情况，合并并简化了技术选型，使整体架构更轻量级和可扩展：

实践方案

使用 Kyuubi 作为统一 SQL Proxy，那么 Kyuubi 就需要满足之前 UniSQL 为代表的代理服务的全部辅助功能，包括审计日志、实时监控、限流、动态参数修改、权限管控等。因此我们深入学习了社区的实践经验和最优推荐，根据场景和需求，完善了 Kyuubi 的服务。以下为我们部分实践结果。