共计 6525 个字符，预计需要花费 17 分钟才能阅读完成。
在日前的 Apache SeaTunnel & Kyuubi 联结 Meetup 上，T3 出行大数据平台负责人、Apache Kyuubi committer 杨华和 T3 出行高级大数据工程师李心恺独特分享了 Apache Kyuubi(Incubating) 在 T3 出行的最新实际与利用，包含基于 Kyuubi 设计的 Flink SQL Engine，Kyuubi 与 Apache Linkis 的集成，以及在 T3 出行的落地实际。
JDBC 之于 Flink 的现状
首先咱们来聊一下 Apache Flink 社区 JDBC 的现状，Flink 在最后是一个流式计算（data flow）的模型，起初将批处理也引入了 data flow 上来，造成了“流批一体”的理念。
Flink 的批处理逐渐在倒退，但相比于一些成熟的离线计算引擎，比方 Hive、Spark SQL 而言，还不是很成熟，体现之一就是对 JDBC 标准的反对比拟欠缺。当然 Flink 社区为此也做出了一些致力，这里给大家分享两来自 Flink 的德国的母公司 Ververica 所开源的两个我的项目，一个叫做 Flink SQL Gateway，一个叫做 Flink JDBC Driver。
这两个我的项目联合起来是可能让 Flink 反对 JDBC 的，然而这两个我的项目曾经有一年多的工夫不太沉闷了，最初的一个奉献还停留在 2020 年。依据 Ververica 的现状预计，这两个我的项目再次沉闷的可能性并不大。
Flink SQL Gateway 和 Flink JDBC Driver 的设计和实现，这是我基于源码画出的，大抵的就是这两个组件联合起来，跟 Flink 交互提供对 JDBC 的反对。咱们能够分成三层来看，最底下的 JDBC Driver 外部是通过 RESTful API 跟 Flink SQL Gateway 的过程所提供的服务去交互，走的是一个 HTTP 的协定。Flink SQL Gateway 能够看作是一个围绕 flink-client 包装进去的服务，在外部引入了 Session 的概念，并且提供了 SessionManager，能够认为它对资源做了一些 share 或者 cache 的能力，主入口是 SQLGatewayEndpoint，外部也提供了很多 Operation 的实现。
这些 Operation 能够分为两大类，一类是本地的 Operation，在内存中对元数据进行治理，比如说 catalog 数据；另外一类是 JobOperation。这两类 Operation 去跟 Flink Cluster 交互，一个是 Insert，一个是 Selector，向 Flink 集群去提交作业。
咱们能够看到这两个设计和实现是专门针对 Flink 的。尽管 Flink 提出了流批一体的概念，但据咱们理解，目前只用 Flink 来把流和批处理的能力全副实现的公司并不多，绝大部分公司还处于 Spark 和 Flink 两个引擎共存的场面。所以对于一些通用能力，比如说多租户或者是对 JDBC 的反对，咱们心愿可能提供一个形象了的实现，可能同时 Flink 和 Spark 这样的引擎，将来可能反对更多的引擎，所以咱们的思考，就是间接基于 Kyuubi 来 Flink SQL Engine 的集成。
Flink SQL Engine 的设计与实现
上面介绍 Flink SQL Engine 的设计和实现。这是我画的一个高层形象的组件的交互图，也能够拆成三个档次。最底下是一些 JDBC 或者 REST 的 client，他们会间接跟 Kyuubi Server 来交互。Kyuubi Server 内局部了两层的实现，最前端是 frontend layer，提供了不同协定的 frontend 的实现，前面是 backend layer，再往后这个 backend 会去跟 Engine 的 frontend 去进行交互。
Engine 在 Kyuubi 外面的设计其实也分为 frontend 和 backend 两个档次。在 Flink Engine 的实现，咱们提供了 FlinkThrift Frontend Service，backend layer 咱们提供了一个 Flink SQL Backend Service，它会去跟 Flink SQL Manager 和 Operation Manager 去交互。
Kyuubi Flink Engine 在整个 Kyuubi 的生态外面所处的地位，是在纵向的第五排 Kyuubi Engine . 咱们也能够看到社区行将推出的对 Trino（Presto SQL）的反对，整体来看 Kyuubi 对其余技术的态度其实是很凋谢的，它并不要求咱们对其余组件去做很多的改变来适配这套体系，这在企业技术选型中，对异构的架构特地敌对。
Flink SQL QuickStart DEMO
接下来咱们来看 Flink SQL QuickStart 的 DEMO，第一步咱们是基于 Kyuubi 的源码来构建一个二进制的公布包，因为在 1.5.0 版本之前 release 的包外面，Flink SQL Engine 还没有被蕴含进去。（目前 Kyuubi 1.5.0 版本曾经公布，蕴含了 Flink SQL Engine (Beta) 的反对，详见
https://kyuubi.apache.org/rel…）
这是 Mac 本机的一个 DEMO，所以咱们须要 Hadoop classpath 增加到加到 PATH 环境变量，并启动一个 Flink 本地集群。下一步就能够启动 Kyuubi Server，再利用 Kyuubi 自带的 Beeline 去连上 Flink Engine。Kyuubi 会主动拉起一个 Flink Engine，它是一个 Java 过程。
进入到 Beeline 的交互式命令行外面去，抉择特定的数据库之后，就能够执行一些 DDL 和 DML 的操作。这里咱们的示例是创立一张表，而后调了一个 Insert 的语句。执行完结之后，咱们关上 Flink 的 WebUI，就能够看到一个 Insert 的 Job 被提交了，并且曾经执行实现。
这个 DEMO 比较简单，最近社区也有小伙伴提供了一个 on YARN 模式的 QuickStart 的反对和文档，有趣味的小伙伴也能够基于这个文档去理解 on YARN 的提交形式。
Flink SQL Engine 的实现离不开 Flink 社区大佬们的鼎力支持。这里感激一下阿里巴巴 Blink 团队的蒋晓峰同学，和网易游戏实时团队的林小柏同学，始终在社区外面比拟沉闷，奉献了很多 PR。
Flink SQL Engine 目前提供的性能，我大抵列了列了一些：
惯例的 DDL 和 DML 操作，基本上都是反对的
JDBC 标准的一些 Get 或者 Show 相干的办法也曾经反对
Flink 所实现的一些设置或者重置属性相干的办法
UDF 的反对
目前的反对的 deploy 模式 Flink Session Standalone / on YARN 模式
Flink SQL Engine 瞻望
Flink SQL Engine 将来的打算，首先它的 deploy mode 会有一个很大的变动，次要是往 Application 模式和 Session 模式去提供反对，业界曾经用得最多的，也是比拟成熟的 Per-Job 模式会被废除掉。Kyuubi 的 Flink Engine 将来应该次要是集中在 Application 模式，Session 模式也反对，但并不是第一抉择。
其余的一些布局，包含 Flink SQL Engine on YARN(application) 的反对，Flink SQL Engine on Kubernetes 的反对，另外是对 Kyuubi 共享级别的加强，还有一些应用上的晋升，比方反对 Session 外面的 JAR 的治理。当然还有一些可能是须要大家应用之后去反馈的，也欢送大家参加进来，一起奉献。
Why Kyuubi
上面介绍 Kyuubi 在 T3 出行的一些利用场景。
T3 出行是一个基于车联网驱动的平台，以车联网的数据为主，基于车联网数据的多样性，T3 出行构建了一个以 Apache Hudi 为根底的企业级数据湖的平台，而且在此之上构建了 BI 平台，任务调度，机器学习，数据品质等等一系列的平台，为业务提供了撑持。随着业务的倒退，平台越来越多，对于这些平台的对立治理也越来越简单，业务小伙伴的应用体验也变差。咱们通过一系列的调研选型，决定抉择了微众银行开源的 DSS（DataSphere Studio）作为一站式数据利用的交互治理平台，并且依据公司的理论场景进行了一些定制化的开发。
下图是 DSS 引入 Kyuubi 之前的架构，咱们是通过 Kafka 和 CANAL 来定位数据，而后数据进入对象存储，以 Hudi 的格局保留在数据湖之上，资源编排是 YARN，计算引擎次要是 Spark、Hive 和 Flink。计算引擎通过计算中间件 Linkis 来对立治理交互，同时和 DSS 之间做了一个买通，在 Linkis 计算中间件之上构建了 BI 平台和数据地图，数据开发，机器学习等等，这多种平台通过 DSS 这个一站式的入口来对立进入治理。
这个架构在理论应用中遇到了一些问题，比如说 跨存储 的问题，当初数据分布在 OBS 对象存储，Hudi 的格局存储，还有 ClickHouse、MongoDB 等不同的成熟数据，开发小伙伴就须要写各种代码进行关联剖析，或者 ETL 的导入，Linkis 对此解决还是比拟无限的。还有 SQL 语法的不对立，比方 Hive 或者原生的 Spark SQL 不反对 upsert、update、delete 等语法操作，还有 MongoDB、ClickHouse 等语法也各不相同，开发转换老本比拟高。同时 Linkis 和 Hive、Spark 版本是强耦合的，如果降级 Spark 版本，就须要批改一系列的源码，从新编译，降级的难度比拟大；同时 Linkis 中的 Spark 引擎对于 cluster 运行模式、AQE、动静资源等个性的反对还不欠缺，革新的老本都比拟大。
所以在此之上咱们引入 Apache Kyuubi，T3 出行应用了很长时间 Kyuubi，所以咱们决定调研一下，看是否把 Kyuubi 和 Linkis 相互买通。Kyuubi 是一个对立的 Thrift JDBC 的服务，对接了 Spark 引擎和 Flink 引擎，Trino 社区也做了一些对接，所以可能治理多种引擎，能够满足 BI、ETL、ad-hoc 的一些场景，同时曾经是进入了 Apache 孵化器，为企业级数据湖摸索提供了一个标准化的接口，赋予用户调动整个数据湖数据的一个能力，让用户可能像解决一般数据一样解决大数据，是一个 Serverless 的服务。
比照一下 Kyuubi 和 Linkis、Hive on Spark，如下表，Hive 和 Kyuubi 都是 JDBC 的接口，Linkis 本人提供了一些 HTTP 的 REST API，Linkis 次要基于 Spark 引擎或者 HiveQL 之类的语法，Kyuubi 次要是 Spark SQL 或者 Flink SQL 语法，Hive 还是本人的 HQL 语法。
SQL 解析 Hive 是 Server 端，Linkis 和 Kyuubi 都是 Engine 端。工作提交，Hive 拆分了多个 RemoteDriver 提交，Linkis 基于 Server 端进行的一个分布式的线程调度，Kyuubi 本人有一个资源隔离的机制，通过 USER、GROUP 或者 CONNECTION 的策略来隔离资源。
Linkis 和 Spark、Hive 的版本是绑定的，Kyuubi 就比拟灵便，反对多版本适配，它和 Server 端和引擎端是拆散的，比拟便于咱们降级和更新迭代。计算资源方面，Linkis 是基于本人的引擎治理，同时它应用的时候它是会把资源给锁住了，Kyuubi 是基于 YARN 和 Kubernetes 的资源调度，在此之上通过 Engine 的维度来进行资源的治理，比 Linkis 要灵便很多。
Linkis 集成 Kyuubi 实际过程
上面介绍 Linkis 和 Kyuubi 的集成流程，Linkis 反对新增一个自定义引擎的，反对多种的引擎类型，咱们抉择了其中的
ComputationExecutor: 这个类型，集成了它的办法，因为它是罕用的交互式引擎 Executor，可能解决交互式执行工作，并且具备状态查问、工作 kill 等交互式能力。而 Kyuubi 引擎是一个交互式引擎，所以在此之上实现这个 Execute 是比拟适合的。
实现这个引擎，次要是 com 文件要引入 Linkis 的一个相干包，具体能够看 Linkis 的官网文档《如何疾速实现新的底层引擎》。
咱们要实现这几个模块，KyuubiEngineConnPlugin 是启动引擎的一个连贯的入口；KyuubiEngineConnFactory 是实现一个引擎的治理，启动引擎的一个整体的逻辑；KyuubiEngineLaunchBuilder 模块用于封装引擎端治理，是解析启动命令的；理论执行的场景得是 KyuubiExecutor，它间接和 Kyuubi Server 来交互，实现计算逻辑的执行的单元。次要是这几大块的实现，大抵的代码架构如下图所示。
Linkis 启动和 Kyuubi 之间的交互次要是通过 Linkis 的 Gateway 转发引擎的一个治理治理模块，通过 Linkis 的引擎治理模块会启动引擎的连接器治理，连接器治理是多个的，对接不同的用户、不同的引擎，来启动执行 Kyuubi 引擎。Kyuubi 引擎再和 Kyuubi Server 之间建设会话，而后通过和 Kyuubi Server 之间交互，比如说查问或者是 DDL 操作，会把这些返回的后果存储到一个 HDFS 长期目录里，该长期目录会返回之前的查问后果给 Gateway，Gateway 再返回给用户的一个理论客户端。
引入 Kyuubi 之后整体架构如下图。次要的变动是计算中间件，是由 Kyuubi 和 Linkis 独特来实现，SQL 模块都交予 Kyuubi 来治理，其余的模块还是 Linkis 来治理，同时和任务调度、计算引擎之间都买通了。后续咱们心愿能把 Scala 或者 Flink 之类的工作也都集成在 Kyuubi 之上。
Kyuubi 在一站式平台应用场景
Kyuubi 在一站式平台的理论应用场景，能够看到 DSS 数据开发模块，咱们间接减少了一个 Kyyubi 的类型。Kyuubi 的类型间接对接 Kyuubi 服务，能够在下面通过一些 SQL 语句进行数据开发，并且实现一站式的开发和 CI/CD 的治理。
开发好的脚本能够工作编排，工作编排里集成了 Kyuubi 类型，能够间接把 Kyuubi 作为一个组件来进行工作编排，关联曾经编写好的脚本。这些编写好的脚本有一个公布的性能，这个公布性能是和 DSS 买通的，公布到 DSS 之上的时候相当于一个 SQL 模块，就是把曾经写好的一些脚本，应用 Kyuubi 的数据源就公布到公布到 DS 之上，这就造成了一整套 CI/CD 的过程。
之前 DSS 之上对 Linkis 有一系列的 WebUI 的监控治理，而 Kyuubi 在这方面是没有的，所以咱们在这根底上增强了 Kyuubi 的后盾治理性能，独自开发了一个 Kyuubi Web 的 Server 模块，通过 UI 对用户的操作进行对立的治理监控，次要是对 Kyuubi Server 端进行连接数、引擎数量、JVM 的监控。
还有对用户会话的 Session 能进行接通，这个 Session 间接是调用 Server 端 Session API 获取一些 Session 状态的接口，而后存到一个 MySQL 的长久化存储，同时也能够手动调 Server 端的 API 去敞开 Session。
此外对用户提交应用的一些语句也都能展现，或者对立治理，这样不便后盾管理员来管控用户的操作，同时回溯问题的时候也会比拟不便。
小结一下，T3 出行大数据平台引入 Apache Kyuubi 后，和 Linkis 性能互补，实现了代码开发、业务上线与调度零碎的买通，同时能够收口做到大数据开发 CI/CD 治理，帮忙业务部门低门槛上线大数据相干的需要，加重了数据开发的压力，向咱们一站式开发平台的指标更进了一步。也冀望 Apache kyuubi 和 Linkis 作为计算中间件的 引领者越来越好！
作者：杨华，李心恺
附视频回放及 PPT 下载：
T3 出行 Apache Kyuubi FlinkSQLEngine 设计和相干实际
延长浏览：
eBay 基于 Apache Kyuubi 构建对立 Serverless Spark 网关的实际
Apache Kyuubi 在 T3 出行的深度实际
Who is using Apache Kyuubi (Incubating)？
Kyuubi 我的项目主页
Kyuubi 代码仓库
