這篇博文包括 Onehouse 首席執行官 Vinoth Chandar 於 2022 年 3 月在奧斯汀數據委員會發表的重要演講的後半部分。本文是第 2 部分，比較了架構的功能和性價比特征。最後，它描述了一個面向未來的、湖倉一體的架構。

數據倉庫和Lakehouse：功能對比

對於核心讀寫：湖倉一體和倉庫都可以支持更新、刪除、事務、統計、排序、批量加載、審計、回滾、時間旅行這些基本功能。倉庫具有更完整的關系或數據庫功能，例如多表事務、聚簇等。在Lakehouse中大多數技術都是以庫的形式提供。例如在 Hudi 中從一開始就支持主鍵，因為在 Uber 時，唯一鍵約束對我們來說是一個非常困難的要求。

Lakehouse 的設計選擇更多地反映了更大規模的數據需求

有些能力是專有的，有些是開放的，然後有一些圍繞流式更新和所有這些東西的特定設計選擇。通常會看到湖倉一體設計選擇更多地反映了更大規模的數據需求，而倉庫則貼近它們開始時使用的數據庫源。

不僅僅是高效寫入數據，還需要優化表的核心服務以確保真正良好的性能。可以看到例如聚類或排序以獲得良好的性能，空間回收。當數據變得臟時，如何管理它？在它們的自動化管理方式方面，或者是否需要將其中一些庫放在Lakehouse上運行，這兩者之間存在巨大差異。像文件大小這類信息在數倉中是隱藏的文件，但它們仍然暴露在湖倉一體中，如果不能很好地管理它們可能會影響性能。一些框架具有自動強制執行功能，有些是DIY的。在 Hudi 中也有這些功能，但仍然需要自我管理。Hudi 可以進行聚簇，但需要自己運行聚簇作業。而如果隻是使用托管服務，這些都是在內部管理。數倉中的緩存是透明加速的，Lakehouse可使用或不用。

數據庫更改數據捕獲 （CDC）、引入日志事件等內容。許多使用雲（現代數據棧或雲數據倉庫）的人都擁有托管的零操作攝取服務，他們更喜歡使用這些服務來獲取數據並構建表。但是在湖上開發者使用Debezium或框架並與Hudi庫捆綁在一起以構建一個端到端的系統。因此如果想建造一個Lakehouse並投入使用，這確實需要一些時間，必須通過觀察所有這些不同的問題並找到解決方案，這提供了極大的靈活性，但需要一些時間才能將其付諸實施。

數據倉庫和Lakehouse：性價比

這是一個非常有趣的話題：價格/性能。首先考慮不同工作負載，當談論性價比時會看到以 TPC-DS 的基準測試報告。

實際上至少需要有四種不同類型的工作負載，並且並非所有工作負載都需要高級引擎，例如 SQL 優化不一定能幫助進行數據攝取，因為非常受 I/O 限制。不同工作負載具有不同的性價比特征，在湖上仍然需要做大量工作來管理表，可以選擇為每個用例選擇合適的引擎。因此對於某些人來說也許會選擇開源版本，而對於某些人來說會選擇雲產商的產品。

對於 TPC-DS ，我們將做一些不同的事情並嘗試剖析查詢。首先是Lakehouse或倉庫中的性能差異從何而來？一個是獲取元數據。可以查看表元數據、架構、統計信息以及了解如何規劃查詢所需的任何內容。目前Lakehouse要麼存儲在像 Hive 這樣的元存儲中，要麼存儲在存儲有關表的統計信息的文件中。然後倉庫主要使用數據庫存儲，當數據量很大時數據庫在很多方面都優於文件。因此Lakehouse現在還處於早期階段，必須在此基礎上發展Lakehouse的統計管理。查詢計劃很大程度上取決於引擎和供應商。查詢優化是一個非常困難的問題，隨著花費的時間增加，它會變得更好，需要一個更成熟的優化器，這是一個不斷發展的格局。有了查詢計劃進行執行時，Lakehouse采用開放的文件格式，而數倉使用封閉的文件格式，但很多性能差異來自文件格式本身，而更像是運行時的差異 - 如果做一個分組查詢，假設必須對數據進行洗牌，引擎是怎麼做到的？即使在Lakehouse引擎內部，也存在巨大的差異。

像 Spark 會更有彈性地洗牌、重試；但像 Presto 希望保持交互式查詢性能和更低的延遲。因此它可能會失敗，並且在洗牌數據和響應查詢時會做出不同的選擇。TPC-DS 固然很好，但更需要的是運行自身的工作負載，當運行工作負載時可能發現差距不是那麼大，建議使用前五個查詢或類似的查詢，然後進行分析。

在基本的 EC2 成本之上，不同的引擎定價也不同。假設引擎收取 2 倍的費用，但完成該查詢的速度比凈值快 3 倍就會獲得性價比優勢。但是都需要快嗎？例如因為緩存也非常快，但它們需要花錢。如果在某些情況下可以負擔得起較慢的速度，那麼它也可以更便宜。

對自身的工作負載進行基準測試

最快並不是唯一的。還要看看數據倉庫的定價：有些是按查詢定價的，有些是針對不同虛擬實例類型的定價。因此主要還是對自身的工作負載進行基準測試。

ETL 工作負載在很多時候並沒有得到太多關註——盡管很多人在它們上花費了大量時間。實際上有一個用於數據集成的基準，TPC-DI，但很少看到有人報告任何關於它的內容。至少根據我們的經驗，如果看右邊的模式，有一個事實表、一個事件表和一些正在更新的維度表。可以看到更新模式確實非常不同，所有這些工作負載不都是一樣的，因此我們需要更好的標準化。

數據優化確實很重要。正如我們所看到的關於聚簇如何提高性能的研究。一個來自 Hudi，一個來自 AWS，一個來自我們自己的博客和開源。可以仔細控制數據佈局，但是如何在數百個表中做到這一點而不會產生副作用呢？如何通過數據佈局控制進行成本和全局優化？這些都是非常開放的問題，很多人今天不得不手動調整並花費大量時間從這些技術中榨取價值。

有了Lakehouse，相對而言隨著規模的擴大會更有性價比

總結一下：

• • 開放。數據倉庫通常是封閉的；Lakehouse是開放（但條件適用）。

• • 使用案例。數據倉庫是為 BI 設計的；數據湖倉一體具有更好的數據科學、分析和 ML/AI 支持。

• • 操作。數據倉庫往往是完全托管的；對於數據湖倉一體來說，可以DIY，更難管理。

• • 費用。使用數據倉庫時，費用會隨著規模的擴大而增加；有了Lakehouse，相對而言隨著規模的擴大會更有性價比。

使用Lakehouse優先、面向未來的架構

人們什麼時候會采用Lakehouse？

開始通常隻需復制運營數據，然後配置儀表盤。然後即使數據大小略有增長，也可以在倉庫上執行一些 ETL。最終要麼遇到成本限制，要麼公司足夠大，需要關心開放性、開放格式，以及前面討論的內容。使用Lakehouse，然後開始編寫一些 ETL，這些 ETL 需要從倉庫中提供一些數據。還可以復制從倉庫卸載的任何 ETL，同時也開始復制數據，數據沒有一個單一的事實來源。Lakehouse必須與外部系統能互操作，即使是倉庫。所有引擎中應該能夠以橫切方式訪問該數據。對於給定的引擎，通常可以在開源之間進行選擇；供應商提供的托管服務；和/或雲提供商產品。

將數據保存在湖上

這裡所說的“在湖上”是指開放數據格式。供應商起起落落，但數據就在那裡。在過去的五年中以開放格式將數據庫變更或所有原始運營數據直接復制到湖倉一體上，可以為未來做好準備。因為這些通常是最龐大的數據集。

以開放格式將數據庫變更或所有原始運營數據直接復制到 Lakehouse 上，為未來做好準備

即使在倉庫中，通常影響成本的也是第一層的原始 ETL，即將其放入倉庫，然後運行 dbt 來獲取表。

因此使用Lakehouse可以很好地做到這一點，而且總是可以重新計算任何東西，可以切換查詢引擎，可以重新計算，在這個架構中可以獲得非常大的靈活性。

最重要的是：它現在提供了一個單一的事實來源，這意味著相同的數據可以輸入到BI和數據科學團隊中。

在數據湖上管理

我們可以盡可能地在Lakehouse上管理很多東西，因為它不需要高級計算。其中許多管理服務更多地受 IO 約束或依賴於外部交互。我們看到了充分利用可互操作Lakehouse的三個最佳實踐：

• • 將大批量作業保留在Lakehouse中。在原始雲存儲上運行掃描。

• • 在方便的地方處理小型 ETL 作業。這些可以在Lakehouse或倉庫上運行。

• • 更傾向於增量更新。更多地轉向增量模型。

所有這些都提供了性價比的選擇，可以擁有具有成本效益的 ETL - 大大降低成本，而不會在重要的地方損失性能。

當一切都完成後看起來像這樣。對於Lakehouse，它是開放的並具有所有的互操作性，可以以一種經濟高效的方式編寫ETL，如果能夠快速將數據（甚至是 ETL 和 ETL 數據）放入倉庫或直接查詢，將獲得非常好的 BI 和報告性能。可以輕松探索 ML 或流式處理等方法。許多這些新興領域可以很好地整合，因為它同樣是一種開放格式，生態系統可以自行發展，而不受制於供應商。當然這已被證明可以支持數據科學和工程。