Lakehouse 還是 Warehouse?(1/2)

Onehouse 創始人/首席執行官 Vinoth Chandar 於 2022 年 3 月在奧斯汀數據委員會發表了這一重要演講。奧斯汀數據委員會是“世界上最大的獨立全棧數據會議”,這是一個由社區驅動的活動,包括數據科學、數據工程、分析、機器學習 (ML)、人工智能 (AI) 等。

Vinoth Chandar 在 Uber 工作期間發起了數據湖倉一體架構,他是 Apache Hudi 項目的項目管理委員會 (PMC) 主席。Hudi 最初被描述爲“事務性數據湖”,現在被認爲是 Databricks 在 2020 年引入該術語後的第一個,也是三個領先的數據湖倉一體項目之一。

在本次演講中 Vinoth 比較了數據倉庫、數據湖和數據湖倉一體的過去、現在和未來用途。最後呼籲採用開放的、湖倉一體優先的架構,大多數工作負載直接由統一的數據湖倉一體提供服務。在此體系結構中,湖倉一體服務於多個不同的引擎,這些引擎專注於報告、商業智能、預測分析、數據科學和 ML/AI 等領域。

我們將演講分爲兩篇博文:

  • 第一篇博文(這篇文章)描述了數據倉庫和數據湖倉一體的演變,並指出了兩者之間的架構差異。
  • 第二篇文章比較了數據倉庫和數據湖倉一體架構的功能和性價比特徵。最後描述一種面向未來的、湖倉一體優先的架構。

目標

Hudi 是我在 Uber 工作時開始的一個項目,在過去的五年裏一直在與 Apache 軟件基金會一起發展社區。有了 Onehouse,我們做了更多與我在 Uber 工作時相同的分佈式數據倉庫/數據庫類型的工作。
Hudi 有很多很好的材料,我們總是可以通過 Hudi Slack 進行連接。今天不談 Hudi,而是列出每個人都熟悉的數據倉庫與數據湖和數據湖倉一體之間的區別,後者較新。我將描述整體架構,如何思考問題,以及應該留在當前的架構中還是繼續演進。
演講的目標包括:

  • 描述數據倉庫和數據湖的融合
  • 澄清常見問題和爭論點
  • 指出細微但重要的技術差異

那麼爲什麼現在要做這樣的演講呢?幾個原因:

  • 多元化的背景。數據社區擁有具有非常多樣化背景的人。我有一個更面向數據庫的背景;我相信你們中的許多人都來自 Spark 世界、流、Flink、Python 等。
  • 很多選擇。現代數據基礎架構有很多選擇,其中包括數據倉庫,然後是數據湖,以及最近的數據湖倉一體。
  • 瞭解權衡取捨。這給了我們一個很好的機會來了解我們如何挑選,以及我們如何一起理解權衡。

首先,我們將勾勒出這些技術的演變以及我們是如何走到這一步的弧線。然後我們將嘗試從這三個不同的方面來理解和研究它們:架構、功能和性價比。最後我將給大家描述我所看到的模式,提煉我在 Hudi 社區中看到的模式,以一種更平衡、更面向未來的方式來構建核心數據基礎設施和架構。

以更平衡、更面向未來的方式來構建核心數據基礎架構和架構

技術的演變

本地數據倉庫(下面幻燈片中的第一個弧線)現在可以看作是用於分析的專用數據庫。很長一段時間以來這就是我們所擁有的一切。然後2012年推出了BigQuery(無服務器查詢),現在圍繞倉儲領域發生了許多創新。

在我看來 Redshift 確實使雲倉庫成爲主流,因爲雲而獲得了很大的發展勢頭。當然 Snowflake 以分離存儲和計算而聞名並且具有出色的可用性,因此今天雲倉儲非常成熟,它們爲分析需求提供了穩定的資源。

如果看一下另一個弧線,數據湖實際上最初是一種架構模式,而不是可以下載和使用的有形軟件,就像RDBMS或數據倉庫一樣。數據湖從支持搜索和社交開始:大規模數據用例。

我曾經在LinkedIn工作,當時我們使用所有這些方法來處理大量數據並構建數據驅動的產品。Spark 不斷髮展壯大徹底改變了數據處理方式。雲增長 – 對於許多工作負載,雲存儲無處不在。數據湖逐漸成爲雲存儲之上的文件的代名詞。

在 2016 年的 Uber 我們試圖構建一個教科書式的數據架構:一個數據湖架構,我們可以從數據庫中獲取運營數據,並將一些外部資源流式傳輸到原始層,然後能夠進行任何類型的 ETL 或後處理,並從中派生出更多數據集。

需要的事務處理核心能力在數據湖上缺失

我們發現構建這種教科書式的架構幾乎是不可能的,因爲數據湖上缺乏我們需要的核心功能,例如事務,Hudi項目就是在這樣的背景下誕生的。

我們添加了更新、刪除、事務;我們甚至在數據湖之上添加了數據庫 CDC 樣式的變更流,這就是我們所說的事務性數據湖。

湖倉一體現已在技術上得到驗證,包括以下公司用例:

技術基礎 - 湖倉一體技術在現有數據湖之上添加的內容已經得到了充分的證明。因此只要通過這個鏡頭來觀察 Apache Hudi 社區就可以看到這些是日常的服務,在這裏可以看到大型企業,如果你把它們加在一起會看到EB級別數據是使用Apache Hudi等湖倉一體技術管理的。

使用 Apache Hudi 等湖倉一體技術管理 EB 級別數據

作爲一個從觀察數據庫大戰開始職業生涯的人發現一些有趣的頭條新聞:

如何理解這一切?數據倉庫已經非常容易理解也已經很成熟了。而從2018年到2020年,數據湖一直處於低谷。

而圍繞數據工程有很多挫敗感,那裏有太多的移動部件。湖倉一體是一個新興的類別,它可以通過添加我所描述的一些核心缺失功能來挽回數據湖。

但我們需要謹慎,因爲這不是我們第一次看到解決所有問題的靈丹妙藥,不幸的是經歷了Hadoop時代的承諾(Hadoop企業數據倉庫將接管數據倉庫)。

對我來說它有點超前於時代,重點不再是解決核心用戶問題。在我看來像Hudi這樣的東西應該早寫五年。因此我們需要以謹慎樂觀的態度對待這個問題。

因此我將分享我對當今情況的誠實評估以及如何看待演變。我們將涵蓋三個方面:

  • 體系結構設計注意事項。主要工作負載是什麼?我們還將討論開放性,因爲每當談論架構時,都會經常提到這一點。
  • 核心技術能力。這些東西的平臺化程度如何;管理層是什麼樣的?應該在團隊建設中規劃多少基礎設施,而已經內置了多少基礎設施?需要多大的靈活性,而解決方案中有多少是預構建的?諸如此類的事情。如今在DevOps和運營精益數據組織方面,這一點非常重要。
  • 成本/性能槓桿。有各種各樣的工作負載,工作負載的類型、設計選擇以及它們在所有棧上的位置。

比較數據倉庫和數據湖倉一體:體系結構

讓我們快速瞭解一下基礎知識,首先是:什麼是本地倉庫?

有一堆有強大的磁盤和CPU的節點,運行SQL,它在節點上運行並訪問本地數據;它只是一個集羣數據庫架構。同樣很難真正描繪封閉系統的架構 - 但我認爲從高層次上講,它們看起來像這樣,另一方面擁有可無限擴展的雲存儲。
本地倉庫的問題在於存儲和計算是耦合的,因此無法獨立擴展它們。但是在雲倉庫模型中他們很好地解決了這個問題 - 可以在雲存儲上存儲任意數量的數據,隨後可以啓動按需計算。

這些是託管服務、平臺服務,例如優化查詢、事務管理、元數據,這些有助於服務更具彈性,可以做很多全局最優的處理,可能正在同一張表上啓動虛擬倉庫,並且可以通過這種方式進行大量交叉優化。這就是我們所看到的架構。

有趣的是傳統的數據湖總是有存儲和計算分離的。從字面上看他們就是這樣出生的,但傳統的數據湖上有很多文件,然後就混合了 JSON 和其他任何東西。有 SQL 引擎 - 本質上是一堆可以在它們之上執行 SQL 的節點 - 並且根據使用的引擎和供應商可能有緩存。
對於湖倉一體,我們真正做的是在中間插入一個層並跟蹤更多元數據。然後會看到它變得更加結構化。現在LakeHouse中的世界更加結構化。

可以看到這些架構是如何相互接近的

從本質上講,我們添加了一個事務管理層,一堆可以優化表的東西,類似於在倉庫中找到的東西,比如對錶進行聚簇,架構管理或統計信息,只是跟蹤表的更具可擴展性的文件級統計信息,架構的其餘部分幾乎相同。可以從雲倉庫模型和湖倉一體模型中瞭解體系結構如何相互接近。

開放性是一個很大的話題 - 它並不止於開放數據格式,遠遠超出了架構。因此開放數據格式當然是可互操作且面向未來的,但是數據倉庫或多或少使用專有數據格式。
互操作性是另一回事,如果解決方案真的很受歡迎,那麼很多工具都會集成,但是對於開放的文件和表格格式真正得到的是:生態系統可以自行發展。不必依賴供應商添加對 X、Y、Z 格式的支持。這就是擁有開放數據格式的關鍵力量。

不需要供應商增加對 X、Y、Z 格式的支持

數據位置和訪問實際上因供應商而異,甚至在倉庫之間也是如此。在某些情況下將數據存儲在倉儲供應商處,在某些方面它就像雲提供商/運營商倉庫,所以它各不相同。數據湖主要將數據存儲在自己的存儲桶中,但需要注意一些注意事項 - 如何在存儲桶上設置權限,以便可以保持已寫入對象的所有者。

數據服務是關鍵差異所在

數據服務是主要區別所在,在倉庫中維護或管理表的大多數東西都是專有的。即使在湖上也有一種模式可以保留開放數據格式,但將其他所有內容鎖定到供應商運行時,這是我們在 Hudi 項目上做得更好的地方,在那裏可以獲得攝取服務、表優化能力——所有這些服務都是開源的。至少在我們看來這種組合鎖定了開放性,因爲這樣一來格式就是一種被動的東西。問題是你用它做什麼?
那麼在代碼和社區方面,你能影響這個項目嗎?即使有一個團隊,大型企業也要與供應商的路線圖聯繫在一起。即使在數據湖上也因項目而異,無論是草根開源項目還是由一家公司驅動的供應商。
關於數據網格:很多人告訴我,“我正在構建一個網格,而不是一個數據湖”。這是一個非常正交的概念。如果你還記得我說過數據湖是一個架構概念。它主要討論如何組織數據,而不是數據基礎架構。如果你看一下關於這個主題的介紹性文章,它主張將數據基礎設施標準化作爲我們如何實現數據網格的關鍵點。

總結一下我們的架構討論:我今天看到的是數據倉庫實際上是爲商業智能 (BI) 而構建,其中的問題在於掃描儘可能少的數據量。那是因爲他們有高性能的元數據管理,長時間運行的服務器。通常數據倉庫旨在更好地支持這些更具交互性的工作負載。

如果看一下數據湖就會發現這些湖支持可擴展的 AI。這真正意味着它們是經過掃描優化的,他們可以掃描大量數據,因爲它們都在雲存儲上——也就是說沒有中間服務器,所以它們可以直接訪問雲存儲。開放格式意味着我們剛纔在主題演講中談到的那種生態系統,這些生態系統可以發展得更快,因爲可以出現更小的項目,它們可以建立在這些數據之上,而且很容易做到,作爲一個社區發展和迭代。

從某種意義上說 LakeHouse 試圖將兩者融合在一起,但挑戰也存在,這些進步是必要的。如果在谷歌上搜索任何“數據湖與數據倉庫”的比較,它會告訴你區別在於非結構化數據與結構化數據——但湖倉一體仍然主要處理結構化數據,還有很多標準化的數據管理工作要做,這些都是需要解決的挑戰。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章