关于java:Apache-Kyuubi-在小米大数据平台的应用实践

导读：明天分享的主题是《Kyuubi 在小米大数据平台的利用实际》，次要分为四局部内容：

• Kyuubi 在小米的落地过程 
• 打造易用和高可用的 Kyuubi 服务 
• 基于 kyuubi 的改良
• kyuubi 的一些新个性在业务场景的利用

01 Kyuubi 在小米的落地过程

第一个主题：对于 Kyuubi 在小米的大数据平台落地过程和施行门路的分享。

1. 背景介绍

先介绍一下背景，小米的大数据体系在不断更新和迭代，随着业务架构、组织架构和技术架构的调整，外部大数据平台逐步呈现一些情况：

• 呈现了多个基于 SQL 的大数据平台服务，服务于各个业务部门，各自定位又有肯定的差别，这样就给用户带来了困扰，到底抉择哪个平台好，而且咱们在用户反对的过程中发现，同一业务可能须要跨多个数据服务平台，流程繁琐。
• 对于底层表资源的应用存在多套账号和权限体系：
  a. MySQL/Doris: 零碎的自有的 User&Password 认证和权限体系
  b. Hive/Kudu 基于 Kerberos 认证和 Sentry 的权限体系
  c. Talos 是基于小米外部平台组织和团队的认证与受权体系
• 给用户应用和治理上带来了麻烦，没有对立的资源管理和权限治理视角，并且底层零碎服务账号会间接裸露给用户，还会存在平安危险。

2. 构建一站式的大数据开发平台

上述景象间接导致了如下问题：
①对用户：

• 多个平台和多体系给用户体验较差，开发数据流程长，不能疾速上手。
• 开发管理效率老本高，资源老本结算和工作治理没有对立的视图。

②对平台：

• 各自的侧重点不同，都不能齐全笼罩大数据场景下的能力需要，同时还有能力反复建设问题，导致资源节约。
• 呈现问题排查和保护艰难，须要堆人力解决。

面对数据平台难用的状况，提出了构建对立易用的大数据服务平台整体指标。整体架构能力围绕数据链路解决方案、数仓解决方案、数据服务解决方案来进行建设，提供对立的元数据管理和权限管理体系。
在这个大背景和动机下，对立的数据入口服务成为了一个十分重要的能力，它次要解决：

• 用户的易用性（统一的入口体验）
• SQL 流量治理（代理多引擎）
• 数据拜访的安全性管控（入口收敛和升高平安危险）

3. 小米 SQL 服务历史倒退状况

从下面的背景问题中能够看到，小米外部有几套大数据处理的 SQL 服务入口，总体还是围绕经典的 SQL On Hadoop 架构体系来构建，逐渐从 ThriftServer 演进到向上形象一层的 SQL Proxy 服务，在底层集成了 Hive/Spark/Doris 等引擎为 ETL 作业、Ad-Hoc 查问提供反对。

抽离的 SparkThriftServer 的实现模块作为独立的 SQL Proxy 服务，提供：

• ETL 场景下的 HiveServer 和 Spark APP 代理（十分驻）
• Ad-Hoc 场景下的 STS、Kylin、Druid 代理

从这里能够看到 SQL Proxy 和 Kyuubi Server 的定位十分类似，然而存在很多有余：
a. SQL Proxy 没有齐全剥离 STS 的实现，通过反射的形式进行复用，代码耦合很高，依赖 Spark 特定版本，降级艰难
b. 底层引擎代理层没有对立形象，与其余引擎适配艰难，对底层引擎扩展性差
c. 无奈本地调试，依赖 hadoop 配置，在办公和服务环境网络隔离状况下，必须在开发机上实现残缺的功能测试和调试，开发和部署门路长

4. 基于 Kyuubi 构建对立 SQL 入口

(1) 为什么抉择 Kyuubi

通过下面的剖析，咱们发现在业务和架构上都存在着一些问题须要解决。
① 业务上：

• 在从新打造对立的大数据体系的推动下，构建对立的 SQL 入口服务势在必行。
• 须要更快的剖析引擎，这里咱们抉择了 Trino。
• 一套易用、高可用并能够继续演进的服务架构，晋升大数据研发的生产力。

SQLProxy 架构须要降级：

• 齐全兼容 HiveThrift 协定。
• 松耦合的实现，基于 STS 实现的齐全剥离。
• 灵便可扩大的代理多引擎的适配。

Kyuubi 的劣势在于：

• 与 STS 和 HS2 的齐全兼容统一
• 高可用和资源隔离
• 清晰简洁的架构，可测试、可保护、可扩大
• 社区高质量实现和业界生产环境大量使用

SQLProxy 和 Kyuubi 的架构十分类似，切换成本低。在业务需要和架构降级的双重推动下，咱们抉择了 Kyuubi。

（2）架构降级

降级过程和成果与咱们的预期统一，能够看到架构相比 SQLProxy 更加简洁，扩大底层引擎非常容易，而且本地可测试可调试，极大晋升了开发效率。从开发到上线新架构两周工夫就实现了平滑迁徙。

降级新架构带来的成果也非常明显，相比之前的架构不管代码品质、服务稳定性、可维护性和可扩展性上都有了重大晋升：

• 多引擎的代理能力（次要反对 Spark/Trino/Hive/Doris）。
• 基于数据平台 workspace 的体系在 Kyuubi Server 端实现了权限验证和资源隔离。
• 更加规范化的 Hive Thrift API 反对，各种生态可视化工具（Redash/Datagrip 等）完满兼容。

(3) 对立 SQL 服务的现状

通过半年的迁徙推动，每日 SQL 无效处理量从 5W 晋升到当初的 50W 规模，曾经占据了整个 SQL 流量的 80%。特地是 SparkSQL 的流量半年新增到 30W。大体流量散布：Spark 36w/ Trino 12w / Hive 2.5w

各个引擎申请耗时：

• Spark 和 Trino 持平，均匀延时 30 秒左右，P50 在 5 秒左右
• Hive 的执行效率显著低于以上两个引擎，跟 Hive 的大工作无关，ETL 偏多
  目前 Kyuubi Server 承载实在的 SQL 流量日均 100w 左右，可用性依然可达 99.9% 以上，十分稳固。

02  打造易用易保护高可用的 Kyuubi 服务

1. 构建合乎业务需要的 Kyuubi
   (1) 整体架构

整体架构和流程，次要分为入口服务、认证和权限适配、底层引擎治理及服务的可观测性：
Kyuubi Server 为根底构建了 SQL 对立入口服务 
Kyuubi Engine 作为 Spark SQL 执行引擎层 
独立 Engine Manager 服务治理各类计算引擎
Kyuubi Server 层集成 Ranger 服务，反对基于数据平台的对立权限验证
扩大适配 Trino/Hive/Doris 引擎服务指标和审计日志的可视化

(2) 用户应用交互

以工作空间（workspace）粒度来保计算资源的隔离的存储资源（表）平安，与 Kyuubi Group 的多租户相似，咱们这里扩大到了其余引擎。

一次实现交互过程：
WorkspaceA 上面的用户应用平台发放的 Token，抉择各类客户端工具，向引擎提交 SQL 查问，Kyuubi Server 会主动将用户 SQL 提交到该空间所属的计算引擎下来，来保障用户应用资源的隔离性。
与其余 workspace 用户虽是同一入口，然而资源的应用上是隔离的。Kyuubi Server 服务并不具体执行 SQL，同一的入口服务不会有太大压力。

2. 晋升用户侧的易用性

(1) 对立认证和表坐标的对立
去 Kerberos 化，采纳平台对立 Token 形式，解决:

• Kerberos 接入流程繁琐
• 普通用户对 kerberos 机制难以了解，呈现问题排查艰难
• 用户治理不当，同一账号下用户收缩问题
• 审计和追踪不能精确定位到用户集体
  表资源命名的对立规范化，小米外部存在多区域和多类数据源，如果应用对立的 SQL 入口服务，须要对立 SQL 语句的表名标准来防止抵触和对立的治理：
• 采纳 Catalog.Schema.Table 三级表名
• 为惟一表名 Kyuubi Server 端反对 JDBC URL 预设 Catalog/Schema，兼容之前 SQL 中二级或者一级表名
• 联合 URL 和 SQL Table 生成残缺的三级表坐标，以供用户权限认证
  (2) Kyuubi Engine 公共资源池

引入 Kyuubi Engine 公共池次要解决用户首次进入空间提交 SparkSQL 的查问性能问题。下面提到的用户提交的 SQL 剖析统计，50% 的 SQL 查问延时都在 5 秒以下。在没有提前调配的资源的状况下，用户提交查问会冷启动一个 Kyuubi Engine，这是 Kyuubi 以后的机制。因为小米 Yarn 提交一个 APP 的延时在分钟级别，用户一个简略的秒级查问会提早到分钟级别，体感十分差。
因而，借助 Kyuubi Engine Pool 的实现，对没有提前配置和指定资源的 workspace 用户，会将 SQL 路由到曾经事后启动好的 Kyuubi Engine Pool，以放慢用户的查问速度，晋升 SQL 查问体验。

3. 降级 Spark2.X 到 Kyuubi Engine

Kyuubi Engine 目前只反对 Spark3 以上，之前咱们外部版本都是 Spark2，在降级到 Kyuubi Engine 之前做了相干比照测试，在 Kyuubi 架构和 SQLProxy 架构下，有显著的性能晋升：

• 在 TPC-DS 规范测试集上，P50 延时有 75% 的性能晋升，长尾根本和 SQLProxy 性能持平。
• 在实在的业务场景下，P50 延时也有 37% 的性能晋升，长尾也根本跟 SQLProxy 统一，也就是降级的 Kyuubi Engine 的性能在少数状况下要优于 Spark2，整体上不会比 Spark2 更差。

4. Kyuubi Server 的容器化

![图片]
(https://static001.geekbang.or…)

在 Kyuubi Server 的高可用上利用容器化的形式替换了以后 Kyuubi Client 端通过 ZK 进行服务发现的高可用模式：

• 在 K8s 上部署 Kyuubi Server 服务，充分利用 K8s 的弹性能力保障高可用。
• Kyuubi Server 和 Kyuubi Engine 的部署彻底解耦，作为一个独自的 Thrift RPC 代理服务和 HTTP 服务，去除 Hadoop 相干的配置环境依赖，和一般业务服务一样应用 LVS 做流量负载平衡。
• 同时借助外部 K8s 平台的 CI/CD 能力，实现了 Kyuubi Server 服务的全自动灰度公布，反对一键降级和扩缩容。
• 基于 Workspace 的计算资源管理
  （1）Engine Manager

因为之前曾经实现了对 Spark Engine 的治理服务，咱们将 Kyuubi Engine 的治理间接从 Kyuubi Server 剥离，造成了独自的 Engine Manager 服务，负责 Engine 的生命周期治理，配置上下文治理，同时提供服务发现和负载平衡能力。

• 为治理入口提供引擎配置和生命周期治理。
• 为 Kyuubi Server 提供 SQL 路由的能力。
• 为运维提供可视化的监控能力，包含 Engine 的服务状态、资源占用以及忙碌水平等，便于疾速运维。

用户提交的 SQL 的流程：

• 首先通过 Kyuubi Server 入口的认证和权限验证。
• Kyuubi Server 向 EngineManager 可用的 Kyuubi Engine 地址。
• EngineManager 向 ZK 获取以后用户空间下可用的 Engine，而后统计以后可用 Engine 的忙碌指标，返回绝对闲暇的 Engine 给 Kyuubi Server。
• Kyuubi Server 将 SQL 提交到 EngineManager 倡议的 Engine 下来执行。

(2) 用户提交

图上是咱们的用户平台 SQL 查问入口，在 workspace 下的用户能够十分不便地启动一个 Kyuubi Engine。为升高用户的门槛，只裸露了资源相干和排队策略的配置。同时，用户还能够配置多个 Kyuubi Engine 实例，来保障以后 workspace 下的 SQL 执行的高可用。

(3) Engine 的高可用

为什么须要 Kyuubi Engine 的高可用？因为在理论环境中，Kyuubi Engine 是始终长时间运行的，Spark 的 SQL 执行过程非常复杂，工夫一长其稳定性就有了问题：

开启动静资源策略后丢事件的 Bug，导致资源无奈开释。
大工作占用工夫长，可能阻塞一些小工作的运行。
Driver 端 JVM Full GC 工夫过长和 OOM。
SQL 不合理导致的 Engine 频繁重启。

因而施行了一些高可用的保障策略：

• workspace 级别隔离 Engine 异样，防止影响其余用户。
• 观测 Engine 可用指标，通过忙碌和探活信息标记是否以后可用。
• 同一 workspace 下多个 Engine 实例（Kyuubi 的 Engine Pool 机制），晋升整体可用性，同时提供基于负载的散发。
• 发现异常及时主动重启。
• 频繁重启 Engine 通过告警机制，人工及时染指。

03 基于 Kyuubi 的革新

1. Trino 和 Doris 的代理

引入 Trino 和 Doris 次要解决 OLAP 场景的查问效率问题。

• Kyuubi 在 1.1.0 版本还未反对 Trino，咱们在 kyuubi Server 端应用 Trino-JDBC 实现了对 Trino 引擎的适配。
• Trino-JDBC 实现了流迭代器的模式，每次 nextResult 都会触发一次对 Trino 引擎的申请。
• 以后社区 Trino-Client 实现，会一次性的拉取所有后果集可能导致 OOM 的危险。

对于 Doris 的适配也采纳了 JDBC 的形式，因为 Doris 客户端自身反对 Mysql JDBC，MySQL JDBC 的实现形式是全量拉取模式，Kyuubi Server 端有 OOM 的危险。目前通过限度 Doris 查问的超时工夫来升高大后果集导致 OOM 的危险。
如果大家前面要扩大 Kyuubi 代理其余 JDBC 的数据库反对，肯定审慎解决。

2. SQL HTTP API 的反对
   对于 HTTP API 的反对一共实现了 V1 版本和 V2 版本，相比社区还是有一些区别。

① V1 版本

• 简化用户的交互过程，简化 Hive Thrift RPC 的调用流程，用户间接在下层应用程序中通过 HTTP 申请就能提交 SQL，对一些研发用户来说是十分敌对的。提交 SQL 依据 QueryID，一直轮询获取后果。
• 复用了 Thrift backend Service 的实现，程度扩大了一层 HTTP Fronted Service。底层实现跟 Thrift API 齐全保持一致。

然而也存在一些问题：

• Kyuubi Service 端是有 Session 状态的，Step1 和 Step2 必须路由的同一个实例能力获取到后果，采纳 IP Hash 不能齐全解决。
• 这样也导致 Kyuubi Server HTTP 服务无奈程度扩大和平滑降级。

②V2 版本

为了彻底解决 V1 的程度扩展性问题，在 V2 版本中将 Kyuubi HTTP Server 齐全无状态化，通过 Kyuubi Engine 间接提供 HTTP SQL API。Kyuubi Server 只起到出代理的作用。

另外的两点改良：

• 彻底解决大后果集的导致 Kyuubi Engine OOM 的问题，将查问类的后果间接长久化到 HDFS，不通过 Spark Driver 端。
• 用户在获取后果的时候不通过 Kyuubi Engine，间接从 HDFS 层流式获取后果集。

同时，也不必维持长链接，非常适合 ETL 的场景。

3. SQL 表列解析

咱们在 Kyuubi Server 端做了权限认证，须要获取用户 SQL 的实在表名，独自开发了一个纯 SQL 的解析模块：反对表列血缘关系和 SQL 类型的提取，反对 SparkSQL、Trino 两种语法。
具体解析后的格局如图，包含类型、输入输出表和队列的列。
后续在具体理论场景中该模块的也利用到了其业务场景，比方表血统审计日志，SQL 的统计申请剖析等平安品质场景，齐全复用了咱们的 SQL 表列提取的能力。

04 Kyuubi 新个性的利用

1. 小文件合并

解决用户写场景可能导致的小文件过多的问题。用户个别会提交两个 SQL：一个是业务解决 SQL，一个是合并 SQL，通过通过 workflow 形式串联起来，保护不变。
开启也非常简单，能够在 Kyuubi Engine 启动阶段，SQL 提交阶段开启开关。

2. 增量获取和获取后果集限度

• 次要是 JDBC 下用户有后果集的查问导致的 OOM 问题，开启增量模式。但有些场景下会有局部分区的后果太大，导致取后果过程阻塞，导致有不好的用户体验。举荐采纳 HTTP API 异步后果获取形式解决。
• 对用户一些预览数据的 SQL，如果拜访的表十分大，限度查问条数输入是一个十分好的性能，防止不必要的开销
• Z-Ordering

在咱们外部画像场景做相干的测试，Z-Ordering 有显著的晋升。

• 业务查问工夫
• 存储空间
• 查问扫描数据量
• 文件数量

在具体利用中，Z-Ordering 的排序规定须要依据理论业务表的数据做相应调整：

• 咱们画像场景查问频次高的列进行排序，成果显著
• 超过 3 个列后的优化并不现实
• 排序列应抉择基数较大且没有歪斜的列

Kyuubi Engine Z-Ordering 的实现十分奇妙，没有减少额定的列，间接复用了 parquet 的原生能力，所以一次生成能够反对多个引擎查问（只有该引擎反对 parequet 格局的读取）。

4. PlanOnly 模式

次要用于非 SQL 执行的 SQL 相干场景，比方：

• 为数据平台提供语法语义校验服务 SQL
• 提交前的查看 SQL
• 语法语义兼容性的查看（Spark2.X->Spark3.X 的降级）

PlanOnly 模式下 SQL 不会真正执行，只会输入解析后的 LogicalPlan/SparkPlan。目前为数据平台独自提供了语法语义校验服务，就是采纳 Kyuubi Engine 的 PlanOnly 模式。

这种利用场景也为咱们提供了一种新思路：将 Kyuubi Engine 作为 Yarn APP 的服务框架，提供其余场景的服务，比方校验服务、血缘关系提取服务和 SQL 的预计算服务等。

5. Scala mode

Scala Code 模式齐全解放了 Kyuubi Engine 能力，具备间接通过 JDBC 提交 Scala 代码的能力，专门解决一些简单逻辑的业务。

目前咱们的利用场景在运维这块做了一些尝试，次要解决咱们的运维效率。例如咱们要在运行时动静加载用户自定义的 jar 包，读取 Thrift 格式化的数据。相比之前登录到生产集群机器打包代码运行的流程大大简化。

05 将来布局和总结

布局：

• 基于业务场景、SQL 规定和执行代价事先预测，实现多引擎下的主动路由能力。
• HTTP API 代替 Thrift API 提交的 ETL 作业，异步化取代长连贯的形式。

总结：

• Kyuubi 是十分优良开源实际，曾经成为小米外部大 数据服务入口的重要基础架构服务。
• 非常感谢 Kyuubi 的社区的奉献，减速了咱们对立 SQL 服务的落地。
• 置信将来 Kyuubi 会成为大数据场景下的 SQL Gateway 标杆，与大家一起共建 Kyuubi 生态

明天的分享就到这里，谢谢大家。

分享嘉宾