Apache Kyuubi Committer VinoYang: 展望 Flink SQL Engine

語言: CN / TW / HK

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 孵化器進行孵化。所以,現在正是開源的黃金年代。

2021 年 5 個源自中國的新專案進入 ASF 專案孵化器

(圖表來自 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 主頁:https://kyuubi.apache.org/

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