簡介：從數據倉庫、數據湖的優劣勢，湖倉一體架構的應用和優勢等多方面深度解析Lakehouse架構。

作者：張泊

Databricks 軟件工程師

Lakehouse由lake和house兩個詞組合而成，其中lake代表Delta Lake（數據湖），house代表data warehouse（數據倉庫）。因此，Lakehouse架構就是數據湖和數據倉庫的結合。數據倉庫和數據湖各自都存在著很多不足，而Lakehouse的出現綜合了兩者的優勢，彌補了它們的不足。

數據倉庫從上世紀 80 年代開始發展和興起，它的初衷是為了支持BI系統和報表系統，而它的優勢也就在于此。結構化的數據可以通過ETL來導入數據倉庫，用戶可以方便地接入報表系統以及BI系統。同時，它的數據管控能力也比較強。

數據倉庫對于數據 schema 的要求非常嚴格，很多數據倉庫甚至也實現了 acid 事務等能力。但是數據倉庫對于半結構化數據比如時序數據和日志，以及非結構化數據比如圖片、文檔等的支持是非常有限的，因此它不適用于類似于機器學習的應用場景。而且一般情況下，數據倉庫都是專有系統，使用成本比較高，數據遷移和同步的靈活性比較低。

因此，為了解決上述問題，數據湖的架構應運而生。

數據湖架構的基礎是將原始數據以文件的形式存儲在像阿里云OSS、AWS S3 和 Azure blob storage 等對象存儲系統上。相比于數據倉庫使用的專有系統，使用這些對象存儲的成本比較低。數據湖的另一個優勢是能夠對半結構化和非結構化的數據提供非常好的支持。因為數據可以以文件的形式直接存儲在數據湖之中，所以數據湖在機器學習等場景中的應用就比較廣泛。但是它對于 BI 和報表系統的支持比較差，通常情況下需要通過ETL將數據轉存到實時數據庫或數據倉庫中，才能支持 BI 和報表系統，而這對于數據的實時性和可靠性都會產生負面的影響。

綜上，不論是數據倉庫還是數據湖，都無法完全滿足用戶的需求。

因此，在很多實際使用場景中，用戶會將兩者組合起來使用，但是這導致需要構建很多不同的技術棧來支持所有場景。

比如對于數據分析，需要將結構化的數據輸入到數據倉庫，然后建立數據市場，對數據分析和 BI 提供支持；對于數據科學和機器學習的場景，需要把不同的數據比如結構化、半結構化以及非結構化的數據存儲到數據湖中，經過數據清理，用來支持機器學習和數據科學等場景；而對于流式數據源，需要通過流式數據引擎存儲到實時數據庫中，同時還需要對數據湖里的數據進行 ETL 提取、轉換和加載，來保證數據的質量。

這導致需要很多不同的系統、不同的工具來支持各種架構，同時為了數據的互通（上圖紅線），還需要處理不同的專有數據格式之間的差異，以上流程都會大大影響整個系統的效率。

而且，由于所有技術棧都是互相獨立的，導致了維護和使用這些系統的團隊也是分散的。比如，數據分析師主要使用數據倉庫系統，而數據科學家主要使用數據湖系統，同時數據工程師也需要維護整個系統的不同團隊，溝通成本比較高。此外，系統中維護了很多不同格式的數據副本，沒有統一的管理數據模型，不同團隊的數據很有可能會產生差異。

因此，這種復雜的組合型數據系統不是一個好的解決方案。基于此，databricks提出了Lakehouse。Lakehouse的設計基于一個原則：實現一個適用于所有場景的統一平臺。

解決的辦法是綜合數據湖與數據倉庫的能力——基于數據湖使用的對象存儲，構建數據倉庫擁有的數據管控能力。而這一切的關鍵就是其中的結構化事務層。

此前，數據湖主要存在以下幾個痛點：

讀寫并行，就算是追加寫的模式也會產生很多問題。用戶的期望是所有寫操作能夠事務性地被同時讀到或者同時沒有讀到，而這是難以實現的，因為在分布式的對象存儲上寫多個文件，設置一個文件，數據的一致性都是不能完全被保證的。

數據的修改。由于安全合規等原因，用戶會有強制性地修改已有數據的需求，特別是有時候需要根據過濾結果細粒度地修改某些數據。由于數據湖在數據管控能力上的不足，在數據湖上實現此需求往往需要使用全部掃描再重寫的方式，成本比較高，速度也比較慢。

如果一個作業中途失敗，而它產生的部分數據已經存入到數據庫中，這也會導致數據的損壞。

批流混合輸入。由于數據在批和流系統中都存在，可能會造成數據在兩套系統中不一致，導致讀取結果不一致。

存數據歷史。有些用戶需要保證數據查詢的可重復性，方案之一是為了這個需求做很多重復的數據快照，但這會導致數據的存儲和計算成本都大幅上升。

處理海量的元數據。大型數據湖元數據的數據量非常大，經常能夠達到大數據的級別。很多數據湖采用的數據目錄系統無法支持如此大量的元數據，這也限制了數據湖的擴展性。

大量小文件的問題。在數據不斷輸入的過程中，數據湖內會產生大量小文件，隨著時間的推移，小文件的數量可能會越來越多，這會嚴重影響數據湖的讀取性能。

性能問題。在數據湖上達到高性能不是一件容易的事。有的時候為了達到一定的性能要求，用戶需要手動做一些性能的優化，比如數據分區等，而這些手動的操作又比較容易出錯。

數據的查詢管控。由于數據湖的開放性，確保查詢權限合規也是需要解決的問題。

質量問題。前面很多點都會導致數據質量的問題。在大數據場景下，如何確保數據的正確性也是一個普遍的問題。

而Delta Lake能夠為Lakehouse帶來數據質量、可靠性以及查詢性能的提升。

上述前五個問題都是關于數據可靠性，它們都可以通過Delta Lake的 acid 事務能力來解決。在Delta Lake上，每一個操作都是事務的，即每一個操作都是一個整體，要么整體成功，要么整體失敗。如果 一個操作在中途失敗，Delta Lake會負責將其寫入的不完整數據清理干凈。具體的實現方式是Delta Lake維護了包含所有操作的一個事務日志，能夠保證數據與事務日志的一致性。

如上圖，某次寫操作在某個表中添加了很多數據，這些數據被轉換成了parquet格式的兩個文件file1和file2。有了事務日志，讀操作的時候就能夠保證要么讀不到這條日志，要么同時讀到這兩條記錄，這樣就保證了讀取的一致性，解決了讀寫并行的問題。

此外，有了事務日志后也可以對已有數據做細粒度的修改。比如下一次寫操作對表中的某些數據進行修改，在事務日志中就會出現刪除原有文件file1和添加修改后文件file3這樣兩條記錄。同樣，在讀取的時候，這兩條記錄也會被同時讀到或者忽略，使讀取的一致性得到保證。

針對第三點中途失敗的作業，Delta Lake寫入的事務性能夠保證不完整的數據不會被成功寫入。

對于批流混合的輸入數據，由于Spark天然支持批流一體，在寫入時可以將批和流的數據寫入到同一張表，避免了數據冗余及不一致性。

由于事務日志保存了所有操作的歷史記錄，我們可以對之前某個時間點的歷史數據進行查詢。具體實現方法是：Delta Lake可以查到歷史某個時間點對應的事務日志，并且根據歷史的事務日志進行數據重放，得到該時間點的數據狀態。這個能力被稱為“時間旅行”。

那么，Delta Lake是怎樣處理海量元數據的呢？答案很簡單，使用 Spark 來處理。所有Delta Lake的元數據均以開源parquet的格式存儲，數據與元數據總是相伴相生，無需進行同步。使用 Spark 處理元數據，使得Delta Lake的元數據可以在理論上進行無限的擴展。

Delta Lake還采用索引的機制來優化性能，它采用分區和不同過濾器等的機制，可以跳過數據的掃描。還采用了Z-ordering的機制，可以在對某個列進行優化的同時，使其他列性能犧牲最小化。

為了解決大量小文件的問題，Delta Lake還可以在后臺定期對數據布局進行自動優化。如果存儲的小文件過多，會自動的將他們合并成大文件，這解決了數據湖中小文件越來越多的問題。

對于數據查詢的管控，Delta Lake實現了表級別的權限控制，也提供了權限設置 API，可以根據用戶的權限動態對視圖進行脫敏。

最后，Delta Lake實現了schema的驗證功能來保證數據質量。存在Delta Lake表中的所有數據都必須嚴格符合其對應的schema，它還支持在數據寫入時做schema 的合并演化。當輸入數據的 schema 發生變化的時候，Delta Lake可以自動對表的schema進行相應的演化。

總的來說，Delta Lake是在數據湖存儲之上，實現了數據倉庫擁有的ACID事務特性、高性能數據治理能力以及數據質量保證。同時它是基于開放的存儲格式，其本身也是開源的。此外，Delta Lake在架構設計上采用了多層的數據模型來簡化設計，一層層逐步提高數據質量。

剛剛進入Delta Lake的數據表，完全對應著數據的原始輸入，數據質量比較低的，被稱為Bronze表。Bronze表的數據保留也可以設置得長一些，以便從這些表中回溯歷史數據。Bronze表中的數據經過過濾清理，就可以得到下一層的Silver表，可以使其與其他表或者維度表進行創意操作，進行數據的擴展。再往下一層，可以根據業務的需求對已經清理過濾好的數據進行聚合，得到Gold表，可以直接支持業務分析、報表等應用。

可以看到，在Delta Lake架構中，數據質量是在不斷提升的。相比于lambda 架構，它的設計優勢在于在每一層都可以使用PDO統一的數據管道，以事務性的操作對表進行更新，還可以減少數據冗余，從而優化存儲和計算的開銷。

總體而言，Lakehouse的架構優勢有以下幾個方面：

Delta Lake的計算和存儲天然分離，用戶可以進行更靈活的資源調度。

Lakehouse依賴于可以無限擴容的對象存儲服務，其元數據的處理也依賴于高擴展性的 Spark 作業，用戶無須關心存儲容量的問題。

開放的數據格式可以讓數據在不同系統之間的遷移更加順暢。

與數據湖相同，Lakehouse同時支持結構化、半結構化與非結構化的數據。

批流一體。與 lambda 架構不同，Lakehouse能夠做到真正的批流一體，從而簡化數據的架構。

Databricks公司與阿里云聯手打造了全新的產品 databricks 數據洞察，簡稱DDI。

Databricks 獨家優化了databricks runtime引擎，也可以理解為Apache Spark的加強版，它與Delta Lake 融合進阿里云的整套生態系統中，與ECS、OSS、JindoFS進行了很好的結合，提供了全托管高性能的企業級 Spark平臺，能夠同時支持企業的商業洞察分析以及機器學習訓練等。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

?

總結

以上是生活随笔為你收集整理的深度解析数据湖存储方案Lakehouse架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。