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
- IstioCon 回顧 | 網易數帆的 Istio 推送效能優化經驗
- 有數BI大規模報告穩定性保障實踐
- 資料標準在網易的實踐
- 馴服 Kubernetes!網易數帆雲原生運維體系建設之路
- Curve 基於 Raft 的寫時延優化
- 您的聲音我們關心 | 網易數帆有數產品Q1季報
- Slime 2022 展望:把 Istio 的複雜性塞入智慧的黑盒
- 網易數帆王佰平:我的 Envoy Maintainer 之路
- 首屆 DIVE 精彩回顧丨踐行企業數字化,基礎軟體如何創新
- 首屆 DIVE 精彩回顧丨踐行企業數字化,基礎軟體如何創新
- 為什麼你應該瞭解 Loggie
- 網易數帆資料生產力技術體系
- 汪源做客阿里雲大咖說,論道 PolarDB 資料庫開源與儲存生態
- 網易數帆資料生產力方法論
- T3 出行 Apache Kyuubi Flink SQL Engine 設計和相關實踐
- eBay 基於 Apache Kyuubi 構建統一 Serverless Spark 閘道器的實踐
- 雲原生日誌架構實踐:網易數帆開源Loggie的三生三世
- 網易X工行:雲原生日誌系統Loggie正式開源!
- 破浪人丨找資料如何更準更快?這個95年小哥哥有奇招~
- 馴服 Kubernetes!網易數帆雲原生運維體系建設之路