一個理想的資料湖應具備哪些功能？

從資料庫到資料倉儲，最後到資料湖，隨著資料量和資料來源的增加，資料格局正在迅速變化。資料湖市場預計增長近 30%，將從 2020 年的 37.4 億美元增長到 2026 年的 176 億美元。此外從 2022 年資料和人工智慧峰會來看，資料湖架構顯然是資料管理和治理的未來。由於 Databricks釋出了 Delta 2.0，該趨勢可能會增長，該平臺的所有 API 都將是開源的。此外Snowflakes在其峰會上宣佈了一些改變遊戲規則的功能，使資料湖成為該行業的支柱。治理、安全性、可擴充套件性以及對分析和交易資料的無縫分析，將會推動該領域創新。

資料湖基本剖析

根據 Hay、Geisler 和 Quix(2016 年)的說法，資料湖的三個主要功能是從多個資料來源提取原始資料，將其儲存在安全的儲存庫中，並允許使用者透過直接查詢資料湖來快速分析所有資料。資料湖由三個部分[7]組成。資料儲存、資料湖檔案格式和資料湖表格式。所有這些都有助於實現上述功能，並作為資料湖的基石。 資料湖架構[8]透過其資料儲存元件儲存來自各種來源的資料，例如傳統資料庫、Web 伺服器和電子郵件。資料湖檔案格式用作資料處理單元，其中資料來源以面向列的格式壓縮以最佳化查詢和探索。最後資料湖表格式透過將所有資料來源聚合到一個表中來幫助進行資料分析。因此更新一個資料來源將更新所有其他資料來源，就好像它們都在一個表中一樣。典型的資料儲存平臺包括 AWS S3、Google Cloud Storage 和 Azure資料湖。Apache Parquet 或 Avro 是一些通用的資料湖檔案格式，Apache Hudi、Apache Iceberg 和 Delta Lake是眾所周知的資料湖表格式。

理想的資料湖功能列表

資料湖已成為必需品，而不是可有可無的東西。但這並不意味著組織會盲目地對其進行投資。不同的情況需要不同的功能集。下面列出了理想情況下資料湖應具備的所有功能。

擴充套件後設資料的能力

高效的後設資料管理對於資料湖保持資料質量至關重要，以便更廣泛的使用者可以輕鬆理解不同資料集並從中獲得見解。Darmont 和 Sawadogo (2021) 指出，資料湖中的資料沒有明確的格式，這意味著如果沒有後設資料來描述相關模式，它會很快成為浪費的資產。資料湖系統應具有的三個級別的後設資料。首先它應該提供業務級別的資訊以增強對資料集的理解;其次操作後設資料應涵蓋資料處理過程中產生的資訊，而技術後設資料應明確描述模式。

支援 ACID 事務

不支援 ACID 事務的資料湖可能會給資料治理帶來相當大的麻煩。ACID 代表 Atomicity、Consistency、Isolation 和 Durability 的首字母縮寫詞。

• 原子性確保只有完成的資料程式才會影響資料來源。因此如果更新中途失敗，則不會新增任何行

• 一致性透過施加唯一識別符號、支票賬戶中的正餘額等約束來維護資料完整性

• 隔離可防止併發操作互動

• 永續性有助於即使在系統出現故障後也能保持最新的資料狀態

支援 DML 操作

資料庫操作語言 (DML)[16]是一組命令，可讓使用者運算元據庫中的資料。例如 SQL 是一種 DML，允許使用者編寫 SELECT、INSERT、DELETE、UPDATE 和 MERGE 等命令來對資料執行特定操作。支援 DML 的資料湖透過讓使用者輕鬆保持源表和目標表之間的一致性，簡化了治理和審計以及變更資料捕獲 (CDC)。例如使用者可以使用 UPDATE 命令以根據特定過濾器將源表中檢測到的變更傳遞到目標表。

構建和維護模式的靈活性

資料湖相對於資料倉儲的優勢之一是資料湖提供了模式演變的靈活性[17]。資料倉儲在儲存特定資料集之前需要預定義的模式，而資料湖不需要這樣的模式。有效的資料湖具有資料儲存系統，可以自動從儲存的結構化和非結構化資料來源中推斷模式。這種推斷通常稱為讀取時模式而不是寫入時模式，後者適用於資料倉儲的嚴格模式結構。

跟蹤行級表更改

Delta Lake 和 Snowflake等資料湖允許使用者在行級別跟蹤和捕獲對錶所做的更改。該功能是 CDC 的一部分，其中資料湖在單獨的日誌中記錄由於 UPDATE、DELETE 或 INSERT 事件對源表所做的任何更改。這種跟蹤在多個用例中都有幫助，例如透過僅處理更改來最佳化 ETL 過程，僅使用新資訊而不是整個表更新 BI 儀表板，以及透過將所有更改儲存在更改日誌中來幫助審計。

維護審計日誌、回滾和時間旅行

如果資料湖缺乏版本控制系統，管理大資料將是一項挑戰。如果存在實時資料攝取，這意味著新資料不斷湧入，這將變得特別麻煩。如果一些壞資料進入資料流，清理這麼大的資料量會非常困難。因此資料湖必須支援自動版本控制[21]，允許使用者跟蹤並在需要時回滾到以前的版本，從而允許時間旅行，並簡化資料管道的管理以保持資料的完整性和質量。

資料(表)恢復

當今的企業經常將大量資料從一個環境遷移到另一個環境，以使用經濟高效的資料解決方案。但是在資料湖上進行此類臨時遷移可能會導致不可逆轉的挫折，從而導致企業失去寶貴的資料資產。因此資料湖應該具有內建的恢復功能，讓使用者可以透過簡單的命令使用安全備份恢復相關表的先前狀態。

自動調整檔案大小

在處理大型檔案系統(如大資料應用程式中的檔案系統)時，檔案大小會迅速增長。基於 Hadoop 資料叢集的傳統資料湖無法根據資料量調整檔案大小。結果會導致系統建立很多檔案，每個檔案的大小都比較小，從而佔用了大量不必要的空間。高效的資料湖應根據傳入資料量自動調整檔案大小。例如 Delta Lake/Apache Hudi 允許使用者指定目標表的檔案大小，或者讓系統根據工作負載和表的整體大小自行調整大小。較大的表保證較大的檔案大小，以便系統建立較少的檔案。

託管清理服務

大多數資料湖架構中缺乏有效的資料清理機制是一個明顯的弱點，會導致資料湖迅速變成資料沼澤。由於資料湖在沒有預定義模式的情況下攝取資料，因此隨著資料量和型別的增加，資料發現會變得複雜。因此，像 Snowflake這樣的資料湖平臺在資料攝取階段施加了一定的約束，以確保傳入的資料沒有錯誤或不一致，否則可能會在以後導致分析不準確。

索引管理

索引表可以使資料湖加速查詢執行，使用索引而不是遍歷整個資料集來提供結果。在 SQL 查詢中應用過濾器時，索引特別有用，因為它簡化了搜尋。後設資料管理也可以發揮作用，因為它定義了資料表的特定屬性以便於搜尋。但是像 Snowflake 這樣的資料湖不使用索引，因為在龐大的資料集上建立索引可能很耗時[27]。相反，它計算表的列和行的特定統計資訊，並將這些資訊用於查詢執行。

託管資料攝取服務

資料湖中的資料攝取功能有時沒有明確的優先順序，因為資料湖的工作原則是“現在儲存，以後分析”[29] 然而這很快就會成為瓶頸，資料湖將變成資料沼澤而無法進行資料分析。因此資料湖應該有一些機制來提供資料的早期視覺化，讓使用者瞭解資料在攝取過程中包含的內容。

支援批次載入

雖然不是必須的，但當資料需要偶爾大量載入到資料湖時，批次載入非常有必要。與增量載入資料不同，批次載入有助於加快流程並提高效能。然而更快的速度有時可能只是一件好事，因為批次載入可能會忽略確保只有乾淨資料進入湖中的約束。

支援併發

本地資料架構的問題之一是它們無法提供高併發性，這意味著同時為多個使用者提供服務是一件麻煩事。雲平臺解決了這個問題，但由於資料倉儲的限制，高併發仍然是一個問題。以大資料分析著稱的Apache Spark等開源平臺無法支援高併發。然而 Databricks 等資料湖解決方案是為數不多的支援高併發的解決方案之一，儘管它們在低延遲(響應使用者請求所需的時間)方面還可以繼續改進。

支援資料共享

隨著數字化步伐的不斷加快，資料共享已成為當下的需求。由於資料被不同的團隊用於多個用例，透過資料目錄系統進行無縫資料共享對於資料驅動的決策制定和防止業務領域之間的孤島是必要的。資料湖不僅應該提供跨平臺無縫共享資料的方法，而且還應該安全可靠地這樣做，因為由於訪問控制薄弱，資料安全可能成為一個問題。

資料分割槽

資料分割槽為跨多個表或站點分佈資料以加速查詢處理並簡化資料管理。AWS 等 Lakehouse平臺建議對資料進行分割槽以實現可擴充套件性和安全性，因為分割槽可以防止單個資料來源佔用大量空間並將敏感資料與非敏感資料分開。

資料安全

由於資料湖依賴於低成本的開源技術並儲存半結構化和非結構化資料，因此敏感資料可能會被誤用。因此資料湖應該允許集中控制，其粒度甚至可以擴充套件到行級別的控制訪問，以確保符合監管標準。

資料分析

資料湖是一種大資料分析解決方案，它以各種格式攝取資料併為資料科學家等不同使用者提供服務，用於機器學習和商業智慧等用例，同時確保資料質量和安全性。因此資料湖的目標之一是幫助使用者執行高階分析並構建可推動業務能力發展的人工智慧系統。

資料治理

有效的資料治理對於資料湖儲存有價值的資料至關重要。事實上組織需要構建一個資料湖解決方案，在資料訪問和資料控制之間提供基礎。隨著資料共享成為跨多個平臺的常態，資料湖架構必須具有維護資料質量和完整性的流程。對於多個使用者同時訪問不同型別資料的雲資料湖，這些流程變得特別有用。