COSCon‘21 精彩回顾 | Apache Kyuubi 在 T3 出行的深度实践

• 支撑了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 可以为企业级数据湖探索提供标准化的接口，赋予用户调动整个数