湖倉一體雷聲大雨點小?這三點需要關注

語言: CN / TW / HK

本期單口開源我們請到馬進來和大家聊一聊 “湖倉一體”。

馬進:網易數帆大資料實時計算技術專家湖一體專案負責人

 大家好,我是來自網易數帆的馬進,今天跟大家聊聊湖倉一體。

湖倉一體是個舶來詞,英文名稱叫 Lakehouse,最早由 Databricks 公司在 2020 年提出。在 Databricks 的理念中,傳統資料湖在批計算、AI、機器學習等領域有豐富的資源和實踐,但是在流計算、資料質量和資料治理方面相較於傳統數倉有較大不足。

為此,Databricks 提供了 Lakehouse 平臺,基於資料湖之上,可以提供不弱於傳統數倉的能力,也能享受資料湖在 AI、機器學習、批計算上的積累。

Databricks 作為一家商業化公司,講述的 Lakehouse 的故事必然有營銷的成分在,但必須承認的是,Lakehouse 這個概念已經深入人心。包括 Databricks 的老對手 Snowflake 也將自己標榜為 Lakehouse。在 Databricks 的故事裡,Delta 是 Lakehouse 的儲存底座,目前開源社群中,Iceberg 和 Hudi 也是和 Delta 對標的產品。所以現在行業內普遍會把 Lakehouse 與 Delta、Hudi 以及 Iceberg 關聯到一起。

過去兩年,我們與很多同行一起致力於將新型資料湖的技術應用到生產實踐中。我們將這些專案的能力拆為兩部分,第一部分是對現有方案的平替,比如說資料湖的 CDC 代替訊息佇列,基於資料湖的 Upsert 和讀時合併代替 Kudu 這類實時數倉方案;第二部分是現有方案不具備的功能,比如時間旅行、資料回退、模式演進。

對第一部分而言,遇到最大的挑戰是純粹拿 Lakehouse 的理念去平替訊息佇列或者其他實時數倉的選型,在成熟度和效能上會有挑戰;對第二部分的功能,比如時間旅行,對現有的使用者規範或者使用者的使用方式中很難起到非常大的收益。

所以,不少同行可能會有這樣的感受,資料湖這個方向的技術雖然很熱,但是實際上能落地的場景卻不多,或者落地後能講清楚的價值不多。

我們怎麼來看待這個問題?

首先我們要相信,Lakehouse 指向的願景,本身是非常有價值的。這個問題需要自頂向下地看。

回顧前十年的發展,在 2010 年到 2015 年間,Hadoop、Hive 這套資料湖體系在使用者體量上有非常大的增長,現在基本成為離線數倉的事實標準。而圍繞 Hadoop、Hive 以及在雲端物件儲存構建的資料研發的工作流,資料安全、資料地圖、指標系統、模型以及支撐這套資料建設的方法論,大概是在 2015 年之後才逐漸成熟。

目前我們的使用者基於這套資料建設的方法論,在構建離線數倉時已經形成了非常清晰的規範,使用者的體量本身也會很大,但是對流和實時的場景,由於 Hive 在流事務能力上的缺失,行業內普遍採用 Kafka、Flink、Kudu、Doris,甚至一些資料庫來做實時數倉的選型。而這些流程目前在資料建設的主流程裡,其實是沒有覆蓋到的,需要使用者自己去學習、理解和使用這些不同的系統。這裡面會帶來成本、人效、語義二義性等諸多問題。而 Lakehouse 的目標應當是將資料建設的方法論從離線拓展到流和實時,同時通過開放的表和檔案格式、流批統一的資料加工流程,更好支援到AI、機器學習等領域。

從上面的分析我們可以得出三個結論:

  • 使用者使用 Delta、Iceberg、Hudi 這些技術的時候,要理解這三個專案,目前更多是 TableFormat 的定位,是對資料湖表格式的一層元資料封裝,不等價於Lakehouse。Databricks 自己也沒有說過,Delta 就是 Lakehouse。但是這三個專案所引領的表格式的功能是構建 Lakehouse的基礎,而這個基礎距離領先的Lakehouse實踐。還差一層管理系統或者Lakehouse服務,這套服務應當在基礎軟體層為使用者解決流式處理、資料優化、流批一體封裝的問題。
  • 使用者在實踐 Lakehouse 時,在關注新功能的同時,不應當把他當做 Hive 或者已有資料湖之外的一套東西,應當考慮怎麼將現有的體系擴充套件到新的TableFormat之上,讓現有的離線使用者通過統一的互動和規範可以直接將離線產品拓展到實時和更多AI場景。在這個過程中,體系建設者要考慮相容性問題、架構的共存問題,尤其對一些已有的離線業務去拓展實時場景,需要架構師去考慮怎麼在對現有業務更小侵入的前提下把實時的方案構建出來,這樣天然就是流批一體的。

 

  • Lakehouse 的技術,目前還有很多不成熟的地方,比如實時寫入會產生很多小檔案,怎樣為業務提供透明無感的資料優化服務,生產可用的讀時合併應當怎麼度量資料新鮮度,效能怎樣保障等。

針對上面提出的問題,經過兩年的探索、研發和實踐,我們團隊在7月底開源了流式湖倉服務 Arctic 這個專案。Arctic 是基於開源 TableFormat 之上的湖倉管理服務。對上面提出的問題,我們在這個專案中都提供瞭解決方案,歡迎大家來關注。

剛才提到從Hadoop生態的應用到上層建築的完善,其實中間有至少3-5年的時間,而Lakehouse目前還處於非常早期的階段,我們期待與行業內更多的小夥伴
一起構建領先的Lakehouse實踐,歡迎大家關注和參與到我們這個專案。