Apache Kyuubi Committer VinoYang: 展望 Flink SQL Engine

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 主頁：http://kyuubi.apache.org/

Kyuubi 原始碼：http://github.com/apache/incubator-kyuubi