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

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

在本次演講中 Vinoth 比較了數(shù)據(jù)倉庫、數(shù)據(jù)湖和數(shù)據(jù)湖倉一體的過去、現(xiàn)在和未來用途。最后呼吁采用開放的、湖倉一體優(yōu)先的架構，大多數(shù)工作負載直接由統(tǒng)一的數(shù)據(jù)湖倉一體提供服務。在此體系結構中，湖倉一體服務于多個不同的引擎，這些引擎專注于報告、商業(yè)智能、預測分析、數(shù)據(jù)科學和 ML/AI 等領域。

我們將演講分為兩篇博文：

• 第一篇博文（這篇文章）描述了數(shù)據(jù)倉庫和數(shù)據(jù)湖倉一體的演變，并指出了兩者之間的架構差異。
• 第二篇文章比較了數(shù)據(jù)倉庫和數(shù)據(jù)湖倉一體架構的功能和性價比特征。最后描述一種面向未來的、湖倉一體優(yōu)先的架構。

目標

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

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

那么為什么現(xiàn)在要做這樣的演講呢？幾個原因：

• 多元化的背景。數(shù)據(jù)社區(qū)擁有具有非常多樣化背景的人。我有一個更面向數(shù)據(jù)庫的背景；我相信你們中的許多人都來自 Spark 世界、流、Flink、Python 等。
• 很多選擇�，F(xiàn)代數(shù)據(jù)基礎架構有很多選擇，其中包括數(shù)據(jù)倉庫，然后是數(shù)據(jù)湖，以及最近的數(shù)據(jù)湖倉一體。
• 了解權衡取舍。這給了我們一個很好的機會來了解我們?nèi)绾翁暨x，以及我們?nèi)绾我黄鹄斫鈾嗪狻?

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

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

技術的演變

本地數(shù)據(jù)倉庫（下面幻燈片中的第一個弧線）現(xiàn)在可以看作是用于分析的專用數(shù)據(jù)庫。很長一段時間以來這就是我們所擁有的一切。然后2012年推出了BigQuery（無服務器查詢），現(xiàn)在圍繞倉儲領域發(fā)生了許多創(chuàng)新。

在我看來 Redshift 確實使云倉庫成為主流，因為云而獲得了很大的發(fā)展勢頭。當然 Snowflake 以分離存儲和計算而聞名并且具有出色的可用性，因此今天云倉儲非常成熟，它們?yōu)榉治鲂枨筇峁┝朔�(wěn)定的資源。

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

我曾經(jīng)在LinkedIn工作，當時我們使用所有這些方法來處理大量數(shù)據(jù)并構建數(shù)據(jù)驅(qū)動的產(chǎn)品。Spark 不斷發(fā)展壯大徹底改變了數(shù)據(jù)處理方式。云增長 – 對于許多工作負載，云存儲無處不在。數(shù)據(jù)湖逐漸成為云存儲之上的文件的代名詞。

在 2016 年的 Uber 我們試圖構建一個教科書式的數(shù)據(jù)架構：一個數(shù)據(jù)湖架構，我們可以從數(shù)據(jù)庫中獲取運營數(shù)據(jù)，并將一些外部資源流式傳輸?shù)皆�始層，然后能夠進行任何類型的 ETL 或后處理，并從中派生出更多數(shù)據(jù)集。

需要的事務處理核心能力在數(shù)據(jù)湖上缺失

我們發(fā)現(xiàn)構建這種教科書式的架構幾乎是不可能的，因為數(shù)據(jù)湖上缺乏我們需要的核心功能，例如事務，Hudi項目就是在這樣的背景下誕生的。

我們添加了更新、刪除、事務；我們甚至在數(shù)據(jù)湖之上添加了數(shù)據(jù)庫 CDC 樣式的變更流，這就是我們所說的事務性數(shù)據(jù)湖。

湖倉一體現(xiàn)已在技術上得到驗證，包括以下公司用例：

• Uber
• Robinhood
• Amazon
• Bytedance
• Walmart
• Disney
• GE

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

使用 Apache Hudi 等湖倉一體技術管理 EB 級別數(shù)據(jù)

作為一個從觀察數(shù)據(jù)庫大戰(zhàn)開始職業(yè)生涯的人發(fā)現(xiàn)一些有趣的頭條新聞：

• Databricks 創(chuàng)下官方數(shù)據(jù)倉庫性能記錄
• Snowflake 聲稱與 Databricks 具有相似的性價比，但沒有那么快！ - databricks
• 行業(yè)標桿和誠信競爭 - Snowflake

如何理解這一切？數(shù)據(jù)倉庫已經(jīng)非常容易理解也已經(jīng)很成熟了。而從2018年到2020年，數(shù)據(jù)湖一直處于低谷。

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

但我們需要謹慎，因為這不是我們第一次看到解決所有問題的靈丹妙藥，不幸的是經(jīng)歷了Hadoop時代的承諾（Hadoop企業(yè)數(shù)據(jù)倉庫將接管數(shù)據(jù)倉庫）。

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

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

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

比較數(shù)據(jù)倉庫和數(shù)據(jù)湖倉一體：體系結構

讓我們快速了解一下基礎知識，首先是：什么是本地倉庫？

有一堆有強大的磁盤和CPU的節(jié)點，運行SQL，它在節(jié)點上運行并訪問本地數(shù)據(jù)；它只是一個集群數(shù)據(jù)庫架構。同樣很難真正描繪封閉系統(tǒng)的架構 - 但我認為從高層次上講，它們看起來像這樣，另一方面擁有可無限擴展的云存儲。
本地倉庫的問題在于存儲和計算是耦合的，因此無法獨立擴展它們。但是在云倉庫模型中他們很好地解決了這個問題 - 可以在云存儲上存儲任意數(shù)量的數(shù)據(jù)，隨后可以啟動按需計算。

這些是托管服務、平臺服務，例如優(yōu)化查詢、事務管理、元數(shù)據(jù)，這些有助于服務更具彈性，可以做很多全局最優(yōu)的處理，可能正在同一張表上啟動虛擬倉庫，并且可以通過這種方式進行大量交叉優(yōu)化。這就是我們所看到的架構。

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

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

從本質(zhì)上講，我們添加了一個事務管理層，一堆可以優(yōu)化表的東西，類似于在倉庫中找到的東西，比如對表進行聚簇，架構管理或統(tǒng)計信息，只是跟蹤表的更具可擴展性的文件級統(tǒng)計信息，架構的其余部分幾乎相同�？梢詮脑苽}庫模型和湖倉一體模型中了解體系結構如何相互接近。

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

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

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

數(shù)據(jù)服務是關鍵差異所在

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

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

如果看一下數(shù)據(jù)湖就會發(fā)現(xiàn)這些湖支持可擴展的 AI。這真正意味著它們是經(jīng)過掃描優(yōu)化的，他們可以掃描大量數(shù)據(jù)，因為它們都在云存儲上——也就是說沒有中間服務器，所以它們可以直接訪問云存儲。開放格式意味著我們剛才在主題演講中談到的那種生態(tài)系統(tǒng)，這些生態(tài)系統(tǒng)可以發(fā)展得更快，因為可以出現(xiàn)更小的項目，它們可以建立在這些數(shù)據(jù)之上，而且很容易做到，作為一個社區(qū)發(fā)展和迭代。

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