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

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

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

升级架构设计

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

实践方案

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

• SQL 审计

作为统一代理层，需要对所有 SQL 和连接进行详细的记录，包括用户、SQL、执行时间、执行结果等。这样的数据并非实时使用，而是用于后续回溯查找问题，或者进行用户操作习惯的统计分析。幸运的是，Kyuubi 提供了 EventHandler 的方式，收集了非常完整的信息。在 Kyuubi1.6.1 中，支持使用下列参数将相关记录落在本地日志中：

kyuubi.backend.server.event.json.log.path
kyuubi.backend.server.event.loggers

本地日志并不方便统计分析，我们需要更灵活的方式。最终我们选择仿照原生 JsonLoggingEventHandler 类，继承 EventHandler 自定义将所需日志写入 Kafka 中。后续再通过大数据平台的功能，落地到 Hive 或其他引擎中用于回溯分析。

• 实时监控

当前即席查询的使用情况如何、连接数量、失败原因等，都需要实时监控查看。Kyuubi 提供了非常完整的指标监控能力，我们也复用内部运维平台的监控体系，选用了 Prometheus + Grafana 作为实时监控的载体。

相关参数：

kyuubi.metrics.reporters

• 限流

不同平台和用户的使用方式不同，容易导致连接数爆发，从而影响 Kyuubi 服务的稳定性。因此，限流是必须要纳入考虑的。Kyuubi 提供了部分参数进行限流：

kyuubi.server.limit.connections.per.user
kyuubi.server.limit.connections.per.ipaddress

虽然这些参数限制到了单用户的连接数，甚至单用户单 IP 的连接数，但是这些参数是对所有用户统一的，而且 Kyuubi 服务启动后不能动态修改。就我们的使用经验来看，支持针对不同用户动态设置不同的连接限制将是一种更灵活的方式。但当前的功能也能基本满足限流管控要求，最终决定针对这个场景我们不做代码修改，期待社区未来能够提供更精细的管控功能。

• 参数动态传递

线上环境缺乏合适的方式进行参数传递，这个遗憾在新的架构中得以弥补。通过 Kyuubi 提供的自定义动态参数传递方式，实现 SessionConfAdvisor 类后对接配置中心。参数将在每次启动 Session 的时候动态拉取，也能较好的满足不同用户不同资源分配的场景：

kyuubi.session.conf.advisor

当然，为了减少对不同环境参数的自定义 jarb 包管理，我们调整了传入该类的参数，添加了 KyuubiConf，这样不同环境部署的 Kyuubi 自动可以传入对应的配置中心路径等信息，自定义的 jar 包也可以环境无关，减少代码运维的复杂度。