Apache Kyuubi 新晋 Committer VinoYang，为我们带来了参与大数据开源社区的心路历程，以及对 Kyuubi Flink SQL Engine 的展望。

大家好，我是杨华（VinoYang），是 Apache Kyuubi的新晋 Committer，同时也是 Apache Hudi PMC 以及 Apache Kylin 的 Committer。我目前就职于 T3 出行，是 T3 出行大数据平台的负责人。与 Apache Kyuubi（以下简称Kyuubi）社区结缘并参与贡献，是因为 T3 出行早在 2020 年起就开始在生产环境中重度使用它，并对它做了一些定制开发，详情可以参考我们之前的一篇技术分享《Apache Kyuubi 在 T3 出行的深度实践》。

融入开源的黄金时代

由于工作需要，我自2017年开始参与 Apache Flink 社区贡献，然后由于兴趣或工作方向变动等原因，又参与了 Kylin、Hudi、Kyuubi 社区。作为一个开源爱好者，我切身体会到“Apache Way”对中国开发者的影响越来越深，也越来越广。回想我刚接触开源的时候，国内开源的氛围远没现在这么浓厚，很多东西都是自己一点点摸索着来，无论是提 PR 还是在社区中与别人沟通都走了不少弯路。而现在，只是五年不到的光景，参与开源社区的小伙伴越来越多，仅去年就有包含 Kyuubi 在内的多个来自中国的项目加入 Apache 孵化器进行孵化。所以，现在正是开源的黄金年代。

（图表来自 ALC Beijing 社区）

T3 出行使用 Kyuubi 很长一段时间了，但在这之前的一年多时间里，我们跟 Kyuubi 社区并没有太多的互动，只是在内部围绕旧版本做了很多的工作。但如今的 Kyuubi 社区要比我们起步阶段活跃太多，架构上也有很大的改进，这就让我们面临一个抉择：是继续在旧版本上迭代下去，走跟社区完全不一样的路，还是想办法逐步跟社区接轨？其实，哪种选择代价都不小，相信很多社区或团队都面临过。例如我们当时也对 Flink 很老的版本做了不小的改动，类似阿里的 Blink，这些改动都要耗费很大的精力才能跟 Flink 社区新版本完全融合。

但跟社区接轨是更符合未来发展趋势的选择，借助于开源的优势，我们可以获得更多优秀的功能与特性，更多来自群体智慧的产物。而与此同时，我们自己也可以参与其中，将一些变更反馈给社区以让大众获益。

看好 Kyuubi 的新愿景

除此之外，我很看好 Kyuubi rebranding 之后的新愿景：Serverless SQL on Lakehouse。这是我推动内部尽快与社区融合的主要原因。我们可以拆解来看，Kyuubi 正在以及未来如何继续深刻践行这个新愿景。

• Lakehouse

2020 年初，Databricks 在一篇论文中正式提出了“Lakehouse”的概念。Lakehouse 是一个存算分离的架构，存储与计算解耦，各自 scale-out。从存储层来看，借助于纠删码技术、对象存储使得数据的 TCO（总体拥有成本）得到进一步的降低。从计算层来看，借助于弹性算力，计算资源从以前的长期租赁，变成了按需使用、按需计费的方式，从而成本、灵活性、资源利用率都能得到优化。

Databricks 论文同期，三大开源数据湖框架（Apache Hudi/Iceberg/DletaLake OS 版）逐步进入了大家的视野。由于 Databricks 的 Lakehouse 以 DeltaLake 作为核心 Table Format，这三个开源数据湖框架自然而然变成了构建 Lakehouse 架构的选择之一。在过去的一年我们见证了这三个数据湖框架的蓬勃发展，围绕它们构建的 Lakehouse 架构正被越来越多的企业所接受并付诸实践。

截止到目前，Kyuubi 对三大数据湖开源框架都已完成了集成，且在业界有落地的案例（参见：《Apache Kyuubi 在 T3 出行的深度实践》）。

• Serverless

对于 Serverless，众所周知，K8s 已经是构建云原生基础设施事实上的标准。这个体系跟大数据计算引擎的整合，为大数据带来了弹性计算的能力。而 Lakehouse 存算分离的架构体系是顺应云原生大趋势下的细分场景的落地。Kyuubi 为计算引擎 on K8s 的场景做了友好的支持，与此同时，它对一些还没有这么前卫的架构体系，例如仍然沿用YARN来做资源管理的场景一样能提供很好的支持。

• SQL

SQL 作为数据处理最通用的语言，它仍是事实上的标准。虽然业界对 SQL 或关系模型一直存在不同的声音，但目前它的地位依然无可动摇。Lakehouse 架构在兼容传统 Hive 表格式的同时又额外带来了：layout 优化，索引，事务 ACID 语义，低延迟更新等功能。 在存算都维持低成本的前提下，数据的新鲜度从过去的 T+1，变成了现在的分钟级的时延。有了这些能力，增量计算会发挥更多的价值以及会有更多对原生数据的AD Hoc场景，这些都离不开SQL能力的支撑。 Kyuubi 已经很成熟地对 Spark SQL 提供了支持，而对于 Flink SQL 以及 Trino 引擎的支持正在快速迭代中。

2022，推动 Kyuubi Flink SQL Engine 普及

在 2021 年，我推动了 Kyuubi Flink SQL Engine 的基础框架落地。挥别 2021，憧憬 2022，我们还有很多工作要做，我希望这个可用的基于 Kyuubi 的 Flink SQL Engine，逐渐变成业界提交 Flink SQL 的常规选择之一。 我们知道这个特性还有不小的优化空间，但希望推动社区持续迭代它，以在 2022 年达成这一目标。

除此之外，我们也会思考在这些既有的 Feature 之外，还有哪些新的能力可以拓展。总之，新的一年社区的发展是值得期待的。

Kyuubi 主页：https://kyuubi.apache.org/

Kyuubi 源码：https://github.com/apache/incubator-kyuubi