深度解析資料湖儲存方案Lakehouse架構
簡介：從資料倉庫、資料湖的優劣勢，湖倉一體架構的應用和優勢等多方面深度解析Lakehouse架構。
作者：張泊
Databricks 軟體工程師
資料倉庫從上世紀 80 年代開始發展和興起，它的初衷是為了支援BI系統和報表系統，而它的優勢也就在於此。結構化的資料可以通過ETL來匯入資料倉庫，使用者可以方便地接入報表系統以及BI系統。同時，它的資料管控能力也比較強。
因此，為了解決上述問題，資料湖的架構應運而生。
綜上，不論是資料倉庫還是資料湖，都無法完全滿足使用者的需求。
比如對於資料分析，需要將結構化的資料輸入到資料倉庫，然後建立資料市場，對資料分析和 BI 提供支援；對於資料科學和機器學習的場景，需要把不同的資料比如結構化、半結構化以及非結構化的資料儲存到資料湖中，經過資料清理，用來支援機器學習和資料科學等場景；而對於流式資料來源，需要通過流式資料引擎儲存到實時資料庫中，同時還需要對資料湖裡的資料進行 ETL 提取、轉換和載入，來保證資料的質量。
這導致需要很多不同的系統、不同的工具來支援各種架構，同時為了資料的互通（上圖紅線），還需要處理不同的專有資料格式之間的差異，以上流程都會大大影響整個系統的效率。
而且，由於所有技術棧都是互相獨立的，導致了維護和使用這些系統的團隊也是分散的。比如，資料分析師主要使用資料倉庫系統，而資料科學家主要使用資料湖系統，同時資料工程師也需要維護整個系統的不同團隊，溝通成本比較高。此外，系統中維護了很多不同格式的資料副本，沒有統一的管理資料模型，不同團隊的資料很有可能會產生差異。
解決的辦法是綜合資料湖與資料倉庫的能力——基於資料湖使用的物件儲存，構建資料倉庫擁有的資料管控能力。而這一切的關鍵就是其中的結構化事務層。
- 讀寫並行，就算是追加寫的模式也會產生很多問題。使用者的期望是所有寫操作能夠事務性地被同時讀到或者同時沒有讀到，而這是難以實現的，因為在分散式的物件儲存上寫多個檔案，設定一個檔案，資料的一致性都是不能完全被保證的。
- 資料的修改。由於安全合規等原因，使用者會有強制性地修改已有資料的需求，特別是有時候需要根據過濾結果細粒度地修改某些資料。由於資料湖在資料管控能力上的不足，在資料湖上實現此需求往往需要使用全部掃描再重寫的方式，成本比較高，速度也比較慢。
- 如果一個作業中途失敗，而它產生的部分資料已經存入到資料庫中，這也會導致資料的損壞。
- 批流混合輸入。由於資料在批和流系統中都存在，可能會造成資料在兩套系統中不一致，導致讀取結果不一致。
- 存資料歷史。有些使用者需要保證資料查詢的可重複性，方案之一是為了這個需求做很多重複的資料快照，但這會導致資料的儲存和計算成本都大幅上升。
- 處理海量的元資料。大型資料湖元資料的資料量非常大，經常能夠達到大資料的級別。很多資料湖採用的資料目錄系統無法支援如此大量的元資料，這也限制了資料湖的擴充套件性。
- 大量小檔案的問題。在資料不斷輸入的過程中，資料湖內會產生大量小檔案，隨著時間的推移，小檔案的數量可能會越來越多，這會嚴重影響資料湖的讀取效能。
- 效能問題。在資料湖上達到高效能不是一件容易的事。有的時候為了達到一定的效能要求，使用者需要手動做一些效能的優化，比如資料分割槽等，而這些手動的操作又比較容易出錯。
- 資料的查詢管控。由於資料湖的開放性，確保查詢許可權合規也是需要解決的問題。
- 質量問題。前面很多點都會導致資料質量的問題。在大資料場景下，如何確保資料的正確性也是一個普遍的問題。
而Delta Lake能夠為Lakehouse帶來資料質量、可靠性以及查詢效能的提升。
如上圖，某次寫操作在某個表中添加了很多資料，這些資料被轉換成了parquet格式的兩個檔案file1和file2。有了事務日誌，讀操作的時候就能夠保證要麼讀不到這條日誌，要麼同時讀到這兩條記錄，這樣就保證了讀取的一致性，解決了讀寫並行的問題。
針對第三點中途失敗的作業，Delta Lake寫入的事務效能夠保證不完整的資料不會被成功寫入。
對於批流混合的輸入資料，由於Spark天然支援批流一體，在寫入時可以將批和流的資料寫入到同一張表，避免了資料冗餘及不一致性。
由於事務日誌儲存了所有操作的歷史記錄，我們可以對之前某個時間點的歷史資料進行查詢。具體實現方法是：Delta Lake可以查到歷史某個時間點對應的事務日誌，並且根據歷史的事務日誌進行資料重放，得到該時間點的資料狀態。這個能力被稱為“時間旅行”。
那麼，Delta Lake是怎樣處理海量元資料的呢？答案很簡單，使用 Spark 來處理。所有Delta Lake的元資料均以開源parquet的格式儲存，資料與元資料總是相伴相生，無需進行同步。使用 Spark 處理元資料，使得Delta Lake的元資料可以在理論上進行無限的擴充套件。
為了解決大量小檔案的問題，Delta Lake還可以在後臺定期對資料佈局進行自動優化。如果儲存的小檔案過多，會自動的將他們合併成大檔案，這解決了資料湖中小檔案越來越多的問題。
總的來說，Delta Lake是在資料湖儲存之上，實現了資料倉庫擁有的ACID事務特性、高效能資料治理能力以及資料質量保證。同時它是基於開放的儲存格式，其本身也是開源的。此外，Delta Lake在架構設計上採用了多層的資料模型來簡化設計，一層層逐步提高資料質量。
可以看到，在Delta Lake架構中，資料質量是在不斷提升的。相比於lambda 架構，它的設計優勢在於在每一層都可以使用PDO統一的資料管道，以事務性的操作對錶進行更新，還可以減少資料冗餘，從而優化儲存和計算的開銷。
總體而言，Lakehouse的架構優勢有以下幾個方面：
- Delta Lake的計算和儲存天然分離，使用者可以進行更靈活的資源排程。
- Lakehouse依賴於可以無限擴容的物件儲存服務，其元資料的處理也依賴於高擴充套件性的 Spark 作業，使用者無須關心儲存容量的問題。
- 開放的資料格式可以讓資料在不同系統之間的遷移更加順暢。
- 與資料湖相同，Lakehouse同時支援結構化、半結構化與非結構化的資料。
- 批流一體。與 lambda 架構不同，Lakehouse能夠做到真正的批流一體，從而簡化資料的架構。
本文為阿里雲原創內容，未經允許不得轉載。