Apache Kyuubi 在 T3 出行的深度實踐

網易數帆發表於2021-11-12
Apache
  • 支撐了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 建表語句

Apache Kyuubi 在 T3 出行的深度實踐

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/incubator-kyuubi

相關文章