共计 4673 个字符，预计需要花费 12 分钟才能阅读完成。
* 撑持了 80% 的离线作业，日作业量在 1W+
* 大多数场景比 Hive 性能晋升了 3 - 6 倍
* 多租户、并发的场景更加高效稳固
T3 出行是一家基于车联网驱动的智慧出行平台，领有海量且丰盛的数据源。因为车联网数据的多样性，T3 出行构建了以 Apache Hudi 为根底的企业级数据湖，提供强有力的业务撑持。而对于负责数据价值开掘的终端用户而言，平台的技术门槛是另一种挑战。如果能将平台的能力统合，并一直地优化和迭代，让用户可能通过 JDBC 和 SQL 这种最广泛最通用的技术来应用，数据生产力将能够失去进一步的晋升。
T3 出行抉择了基于网易数帆主导开源的 Apache Kyuubi（以下简称 Kyuubi）来搭建这样的能力。在 2021 中国开源年会 (COSCon’21) 上，T3 出行高级大数据工程师李心恺具体解读了抉择 Kyuubi 的起因，以及基于 Kyuubi 的深度实际和实现的价值。
引入 Kyuubi 前的技术架构
T3 出行整个数据湖体系，由数据存储与计算、数据查问与剖析和应用服务层组成。其中数据计算分为离线和实时。
数据存储
OBS 对象存储，格式化数据存储格局以 Hudi 格局为主。
数据计算
离线数据处理：利用 Hive on Spark 批处理能力，在 Apache Dolphin Scheduler 上定时调度，承当所有的离线数仓的 ETL 和数据模型加工的工作。
实时数据处理：建设了以 Apache Flink 引擎为根底的开发平台，开发部署实时作业。
数据查问与剖析
OLAP 层次要为面向治理和经营人员的报表，对接报表平台，查问要求低时延响应，需要多变疾速响应。面向数据分析师的即席查问，更是要求 OLAP 引擎能反对简单 SQL 解决、从海量数据中疾速甄选数据的能力。
应用服务层
数据应用层次要对接各个业务零碎。离线 ETL 后的数据写入不同业务不同数据库中，面向上游提供服务。
现有架构痛点
跨存储
数据分布在 Hudi、ClickHouse、MongoDB 等不同存储，须要写代码关联剖析减少数据处理门槛和老本。
SQL 不对立
Hive 不反对通过 upsert、update、delete 等语法操作 Hudi 表，同时 MongoDB、ClickHouse 等语法又各不相同，开发转换老本较高。
资源管控乏力
Hive on Spark、Spark ThriftServer 没有较好的资源隔离计划，无奈依据租户权限做并发管制。
选型 Apache Kyuubi
Apache Kyuubi 是一个 Thrift JDBC/ODBC 服务，对接了 Spark 引擎，反对多租户和分布式的个性，能够满足企业内诸如 ETL、BI 报表等多种大数据场景的利用。Kyuubi 能够为企业级数据湖摸索提供标准化的接口，赋予用户调动整个数据湖生态的数据的能力，使得用户可能像解决一般数据一样解决大数据。我的项目已于 2021 年 6 月 21 号正式进入 Apache 孵化器。于 T3 出行而言，Kyuubi 的角色是一个面向 Serverless SQL on Lakehouse 的服务。
Apache Kyuubi 架构
HiveServer 是一个广泛应用的大数据组件。因传统的 MR 引擎解决效率曾经较为落后，Hive 引擎替换为了 Spark，然而为了和本来的 MR 及 TEZ 引擎共存，Hive 保留了本人的优化器，这使得 Hive Parse 性能在大多数场景下都落后于 Spark Parse。
STS（Spark Thrift Server）反对 HiveServer 的接口和协定，容许用户间接应用 Hive 接口提交 SQL 作业。然而 STS 不反对多租户，同时所有 Spark SQL 查问都走惟一一个 Spark Thrift 节点上的同一个 Spark Driver，并发过高，并且任何故障都会导致这个惟一的 Spark Thrift 节点上的所有作业失败，从而须要重启 Spark Thrift Server，存在单点问题。
比照 Apache Kyuubi 和 Hive、STS，咱们发现，Kyuubi 在租户管制，工作资源隔离，引擎降级对接，性能等方面领有诸多劣势。详情见下图。
Apache Kyuubi 劣势
Apache Kyuubi 在 T3 出行场景
AD-HOC 场景
Hue 整合 Kyuubi，代替 Hive 为分析师和大数据开发提供服务。
咱们在 hue_safety_valve.ini 配置文件中，减少如下配置：
[notebook]
[[interpreters]]
[[[cuntom]]]
name=Kyuubi
interface=hiveserver2
[spark]
sql_server_host=Kyuubi Server IP
sql_server_port=Kyuubi Port而后重启 Hue 即可。
ETL 场景
DS 配置 Kyuubi 数据源，进行离线 ETL 作业。因为 Kyuubi Server 的接口、协定都和 HiveServer2 完全一致，所以 DS 只须要数据源中 Hive 数据源类型配置为 Kyuubi 多数据源，就能够间接提交 SQL 工作。
目前，Kyuubi 在 T3 出行撑持了 80% 的离线作业，日作业量在 1W+。
联邦查问场景
公司外部应用多种数据存储系统，这些不同的零碎解决了对应的应用场景。除了传统的 RDBMS（比方 MySQL）之外，咱们还应用 Apache Kafka 来获取流和事件数据，还有 HBase、MongoDB，以及数据湖对象存储和 Hudi 格局的数据源。
咱们晓得，要将不同存储起源的数据进行关联，咱们须要对数据进行提取，并放到同一种存储介质中，比方 HDFS，而后进行关联操作。这种数据割裂，会给咱们的数据关联剖析带来很大的麻烦，如果咱们可能应用一种对立的查问引擎别离查问不同数据源的数据，而后间接进行关联操作，这将带来微小的效率晋升。
所以，咱们利用 Spark DatasourceV2 实现了对立语法的跨存储联邦查问。其提供高效，对立的 SQL 拜访。这样做的劣势如下：
* 单个 SQL 方言和 API
* 对立安全控制和审计跟踪
* 对立管制
* 可能组合来自多个起源的数据
* 数据独立性
基于 Spark DatasourceV2，对于读取程序，咱们只需定义一个 DefaultSource 的类，实现 ReadSupport 相干接口，就能够对接内部数据源，同时 SupportsPushDownFilters、SupportsPushDownRequiredColumns、SupportsReportPartitioning 等相干的优化，实现了算子下推性能。由此咱们能够将查问规定下推到 JDBC 等数据源，在不同数据源层面上进行一些过滤，再将计算结果返回给 Spark，这样能够缩小数据的量，从而进步查问效率。
现有计划是通过建设内部表，利用 HiveMeta Server 治理内部数据源的元信息，对表进行对立多权限治理。
例如：MongoDB 表映射
CREATE EXTERNALTABLE mongo_test
USING com.mongodb.spark.sql
OPTIONS (
spark.mongodb.input.uri "mongodb:// 用户名: 明码 @IP:PORT/ 库名?authSource=admin",
spark.mongodb.input.database "库名",
spark.mongodb.input.collection "表名",
spark.mongodb.input.readPreference.name "secondaryPreferred",
spark.mongodb.input.batchSize "20000"
);后续降级 Spark3.X，引入了 namespace 的概念后，DatasouceV2 可实现插件模式的 Multiple Catalog 模式，这将大大提高联邦查问的灵便度。
Kyuubi 性能测试
咱们基于 TPC-DS 生成了 500GB 数据量进行了测试。选用局部事实表和维度表，别离在 Hive 和 Kyuubi 上进行性能压测。次要关注场景有：
* 单用户和多用户场景
* 聚合函数性能比照
* Join 性能比照
* 单 stage 和多 stage 性能比照
压测后果比照，Kyuubi 基于 Spark 引擎大多数场景比 Hive 性能晋升了 3 - 6 倍，同时多租户、并发的场景更加高效稳固。
T3 出行对 Kyuubi 的改良与优化
咱们对 Kyuubi 的改良和优化次要包含如下几个方面：
* Kyuubi Web：启动一个独立多 web 服务，监控治理 Kyuubi Server。* Kyuubi EventBus：定义了一个全局的事件总线。* Kyuubi Router：路由模块，能够将专有语法的 SQL 申请转发到不同的原生 JDBC 服务上。* Kyuubi Spark Engine：批改原生 Spark Engine。* Kyuubi Lineage：数据血统解析服务，将执行胜利多 SQL 解析存入图数据库，提供 API 调用。Kyuubi Web 服务性能
* 以后运行的 SparkContext 和 SQL 数量
* 各个 Kyuubi Server 实例状态
* Top 20: 1 天内最耗时的 SQL
* 用户提交 SQL 排名（1 天内）* 展现各用户 SQL 运行的状况和具体语句
* SQL 状态分为：closed，cancelled，waiting 和 running。其中 waiting 和 running 的 SQL 可勾销
* 依据治理租户引擎对应队列和资源配置、并发量
* 能够在线查看、批改 Kyuubi Server、Engine 相干配置
Kyuubi EventBus
Server 端引入了 RESTful Service。
在 Server 利用过程中，事件总线监听了包含利用进行工夫、JDBC 会话敞开、JDBC 操作勾销等事件。引入事件总线的目标，是为了在单个利用中和不同的子服务间进行通信。否则不同的子服务对象须要蕴含对方的实例依赖，服务对象的模型会非常复杂。
Kyuubi Router
减少了 Kyuubi JDBC Route 模块，JDBC 连贯会先打向此服务。
该服务依据既定策略转发到不同服务。下图为具体策略。
Kyuubi Spark Engine
* 将 Kyuubi-Spark-Sql-Engine 的 Spark 3.X 版本改成了 Spark 2.4.5，适配集群版本，后续集群降级会跟上社区版本交融
* 减少了 Hudi datasource 模块，应用 Spark datasource 打算查问 Hudi，进步对 Hudi 的查问效率
* 集成 Hudi 社区的 update、delete 语法，新增了 upsert 语法和 Hudi 建表语句
Kyuubi Lineage
基于 ANTLR 的 SQL 血统解析性能。现有提供了两个模式，一个是定时调度，解析肯定工夫范畴内的执行胜利的 SQL 语句，将解析后果存储到 HugeGraph 图库中，用于数据治理零碎等调用。另一个模式为提供 API 调用，查问时用户间接调用，SQL 简单时能够直观理清本人的 SQL 逻辑，不便批改和优化本人的 SQL。
基于 Kyuubi 的解决方案
总结
T3 出行大数据平台基于 Apache Kyuubi 0.8，实现了数据服务统一化，大大简化了离线数据处理链路，同时也能保障查问时延要求，之后咱们将用来晋升更多业务场景的数据服务和查问能力。最初，感激 Apache Kyuubi 社区的相干反对。后续打算降级到社区的新版本跟社区放弃同步，同时基于 T3 出行场景做的一些性能点，也会陆续回馈给社区，独特倒退。也冀望 Apache kyuubi 作为 Serverless SQL on Lakehouse 引领者越来越好！
作者：李心恺，T3 出行高级大数据工程师
Kyuubi 主页：
https://kyuubi.apache.org/
Kyuubi 源码：
https://github.com/apache/inc…
