資料湖從前世到今身的演進與選型探索

當我們回顧資料湖的前世時，資料湖的概念在2010年由James Dixon提出，它打破了傳統資料管理的正規化，提供了一種新的方式來儲存、處理和分析資料。與傳統的資料倉儲相比，資料湖更加靈活和容易擴充套件，能夠接收各種型別和格式的資料，包括結構化、半結構化和非結構化資料。

資料湖的興起得益於大資料技術和雲端計算的發展。Hadoop分散式檔案系統(HDFS)等技術為資料湖提供了高可擴充套件性和容錯性。同時，雲端計算提供了便捷的儲存和計算資源，使得構建和管理資料湖變得更加簡單和經濟。

隨著時間的推移，資料湖已經成為組織中儲存和管理資料的重要組成部分。它在資料分析和業務決策方面發揮著關鍵作用。資料湖的優點包括：原始資料的保留，消除資料預定義的需求，支援靈活的資料分析和探索，以及適應不斷變化的資料需求。本文探討如下幾個觀點。

什麼是資料湖?

資料湖有哪些特徵?

資料湖為什麼需要被管理?

資料湖有哪些開源元件可以被利用?

01

—

什麼是資料湖

資料湖的起源

資料湖最早是由Pentaho的創始人兼CTO， 詹姆斯·迪克森，在2010年10月紐約Hadoop World大會上提出來的。當時Pentaho剛剛釋出了Hadoop的第一個版本。在這樣的一個大背景下，可以合理的猜測，當時James Dixon提出資料湖的概念，是為了推廣自家的Pentaho產品以及Hadoop的。

Pentaho是個BI分析元件。當時的BI分析主要是基於資料集市(Data Mart)的。資料集市的建立需要事先識別出感興趣的欄位、屬性，並對資料進行聚合處理。這樣BI分析面臨兩個問題：

(1)只使用一部分屬性，這些資料只能回答預先定義好(pre-determined)的問題。

(2)資料被聚合了，最低層級的細節丟失了，能回答的問題被限制了。

而基於Hadoop的BI分析，可以解決這個問題——把所有資料都原樣存在Hadoop中，後面需要的時候再來取用。如果說資料集市、資料倉儲裡面是瓶裝的水——它是清潔的、打包好的、擺放整齊方便取用的;那麼資料湖裡面就是原生態的水——它是未經處理的，原汁原味的。資料湖中的水從源頭流入湖中，各種使用者都可以來湖裡獲取、蒸餾提純這些水(資料)。

資料湖的定義

維基百科上對資料湖的定義是：資料湖是指一個儲存大規模、原始和未經處理的資料的儲存系統或儲存庫。資料湖具有以下特點：不需要預先定義模式，可以容納多種結構和格式的資料，包括結構化、半結構化和非結構化資料;資料以其原始形式儲存，不需要轉換或轉換為特定格式;支援批處理和實時資料處理，以及各種資料分析和挖掘技術。資料湖的目標是為資料科學家、分析師和業務使用者提供一箇中心化的資料儲存和查詢平臺，以支援資料驅動的決策和業務需求。

在AWS(亞馬遜雲端計算服務)上，資料湖是一種基於雲的資料儲存和分析解決方案。AWS提供了一系列服務和工具，用於構建和管理資料湖環境。

AWS資料湖的定義包括以下關鍵元件：

1、儲存層：AWS提供了多個儲存服務，如Amazon S3(簡單儲存服務)，用於儲存資料湖中的原始資料。Amazon S3是一個高可用性、可擴充套件性和耐久性的物件儲存服務，可以容納大規模的結構化和非結構化資料。

2、資料提取和轉換：AWS Glue是一項託管的ETL(抓取、轉換和載入)服務，用於將原始資料提取到資料湖中，並進行轉換和資料格式化。它提供了自動化的資料抽取、模式轉換和目錄定義功能。

3、資料編目和管理：AWS提供了AWS Glue Data Catalog，用於對資料湖中的資料進行編目和管理。Glue Data Catalog可以指定資料表、架構和模式，為查詢和分析提供後設資料和資料目錄功能。

4、資料分析和查詢：AWS提供了一系列的分析工具和服務，如Amazon Athena、Amazon Redshift和Amazon EMR，用於在資料湖上進行靈活和高效的資料分析和查詢。這些服務支援使用SQL查詢語言、大資料處理和機器學習等技術進行資料分析。

透過這些元件和服務，AWS資料湖提供了一個強大的基礎設施，用於構建和管理大規模資料湖環境，以支援資料驅動的分析和決策過程。

總體來說，資料湖是一種儲存和管理大規模資料的架構和概念。它是一個集中式的儲存庫，可以容納各種型別和格式的結構化、半結構化和非結構化資料。與傳統的資料倉儲相比，資料湖不需要事先定義資料的結構和模式，可以接收任意原始資料，並保留資料的原始形式。資料湖的設計目標是提供靈活性、可伸縮性和高效能，支援批處理和實時資料處理，支援各種資料分析和挖掘任務。透過資料湖，組織可以將資料聚集起來，構建資料資產庫，方便資料科學家、分析師和業務人員進行資料探索、發現洞察和進行決策。

02

—

資料湖有哪些特徵?

資料湖的特徵

資料湖是一種基礎設施，用於儲存、處理和分析大資料。它具有以下關鍵特徵：

1、儲存：資料湖提供大規模的儲存能力，可儲存企業或組織中的所有資料。

2、資料型別：資料湖能夠儲存各種型別的資料，包括結構化、半結構化和非結構化資料。

3、原始資料：資料湖儲存的是業務資料的完整副本，保留了資料在業務系統中的原貌。

4、資料管理：資料湖具備完善的資料管理能力，包括後設資料管理，如資料來源、資料格式、連線資訊、資料架構和許可權管理等。

5、多樣化的分析能力：資料湖支援批處理、流式計算、互動式分析和機器學習等多種分析方式，並提供任務排程和管理能力。

6、資料生命週期管理：資料湖能夠管理資料的整個生命週期，不僅儲存原始資料，還儲存各種分析處理的中間結果，並記錄資料的處理過程，方便使用者追溯資料的產生和轉換過程。

7、資料獲取和釋出：資料湖支援各種資料來源，能夠獲取全量或增量資料，並將分析處理結果釋出到適當的儲存引擎中，滿足不同應用的訪問需求。

8、大資料支援：資料湖提供超大規模儲存和可擴充套件的大規模資料處理能力。

綜上，資料湖是一個不斷演進、可擴充套件的大資料儲存、處理和分析基礎設施，以資料為核心，實現從任意來源、任意速度、任意規模、任意型別的資料獲取和儲存，支援多種處理方式，並管理資料的整個生命週期，同時與各種外部資料來源進行互動整合，以支援企業級應用需求。

03

—

資料湖的資料為什麼需要被管理?

資料湖的資料用途

資料湖的資料為什麼需要被管理主要從用途來分析說明，主要有以下幾個方面的用途。

1、資料分析和洞察：資料湖中的資料可以用於進行各種分析和洞察，幫助組織理解業務狀況、識別趨勢和模式，並支援決策制定。資料湖可以整合大量的結構化和非結構化資料，包括交易記錄、感測器資料、日誌檔案、社交媒體資料等，為資料科學家、分析師和業務使用者提供豐富的資料資源。

2、資料探勘和機器學習：資料湖中儲存的資料可以用於進行資料探勘和機器學習演算法的訓練和建模。透過分析和挖掘資料湖中的資料，可以發現隱藏的模式、關聯和趨勢，並構建預測模型和智慧應用。

3、實時資料處理：資料湖可以接收和儲存來自各種實時資料來源的資料，如感測器資料、流資料和日誌資料等。這些實時資料可以被實時處理引擎用於監測、警報和實時決策，支援業務連續性和運維的需要。

4、資料共享和協作：資料湖可以作為一個資料中心，為不同團隊和部門共享和協作提供統一的資料資源。透過資料湖，團隊可以更輕鬆地訪問、共享和交換資料，促進跨部門的資料協作和整合。

透過以上分析，資料湖的主要用途是用來做資料清洗，加工，資料分析，資料共享和機器學習的訓練資料，如果要對這些資料進行以上方面的使用，就必須對資料湖的資料進行管理，管理功能主要包含以下幾個方面：

1、資料質量控制：資料湖中的資料來自多個來源，以不同的格式和質量。管理資料湖的資料可以確保資料的質量，包括資料的準確性、完整性、一致性和可靠性。透過資料質量控制，可以提高資料分析和決策的準確性和可靠性。

2、資料發現和訪問：資料湖中的資料量龐大且多樣化，需要有系統地管理和組織資料，使得使用者能夠方便地發現和訪問所需的資料。資料管理可以透過後設資料管理、目錄管理等方式來實現，提供資料搜尋、標籤化、分類、許可權控制等功能，提高資料的可發現性和可訪問性。

3、資料安全和隱私：資料湖中可能包含敏感資訊和個人隱私資料，需要對資料進行保護和安全管理。透過資料管理，可以採取控制措施，如資料加密、身份認證和訪問控制，以確保資料的安全性和隱私性，符合相關的安全和隱私法規要求。

4、資料生命週期管理：資料湖的資料會隨著時間不斷積累和變化，需要進行合理的資料生命週期管理。包括資料的採集、儲存、備份、歸檔和清理等過程，以確保資料的可持續性和高效的資料管理。

綜上所述，對資料湖中的資料進行管理可以提高資料質量，方便資料的發現和訪問，保護資料的安全和隱私，以及實現資料的生命週期管理。這樣可以更好地利用和價值化資料湖中的資料，支援業務決策和創新。

資料湖的資料寫入的原子性

原子性是指一個操作要麼全部執行成功，要麼全部失敗，不會出現部分成功部分失敗的情況。在資料湖中進行寫入操作的原子性難以保證，意味著在寫入資料時，無法保證資料的完全一致性和可靠性。這是因為資料湖是一個儲存大量原始、未經加工的資料的儲存系統，允許各種各樣的資料型別和格式。由於資料湖不對資料應用任何特定的資料模式、結構或約束，因此在進行寫入操作時，往往會面臨以下挑戰：

1、資料衝突：由於資料湖允許多個資料流以並行的方式寫入資料，因此可能會出現多個資料流同時修改同一資料的情況，導致資料衝突和不一致性。

2、資料更新：資料湖中的資料是原始、未經加工的，如果需要修改或更新已存在的資料，可能需要執行復雜的操作，並且無法保證所有相關的資料都能被同時更新。

3、資料丟失：在寫入資料時，存在資料寫入失敗或中斷的可能性，尤其是在高併發的寫入操作中。這可能導致部分資料未能成功寫入，從而造成資料丟失。

由於上述挑戰，資料湖的寫入操作難以實現嚴格的原子性，因此需要在實現資料湖架構時採取額外的措施來確保資料的一致性和可靠性。

資料湖的管理功能有哪些?

資料湖的管理功能涵蓋了以下三個方面：

1、用於支援資料湖的資料使用的功能，例如資料處理功能、資料分析功能、資料共享、資料探索功能

2、用於支援資料湖的資料儲存功能，例如資料整合，資料儲存

3、用於支援資料湖的資料管理功能，例如後設資料管理、資料質量、資料規範、資料安全、資料許可權、資料生命週期管理

核心的管理功能：

1、資料質量控制：由於資料湖中的資料來自多個源頭，可能存在不同格式、不完整、冗餘、錯誤或低質量的資料。資料湖的管理功能包括資料清洗、轉換和標準化等，以確保資料的準確性、一致性和完整性。

2、資料探索：資料湖中儲存了大量的資料，如何快速準確地找到所需的資料並進行訪問是關鍵問題。資料湖的管理功能提供後設資料管理、資料目錄和搜尋等功能，幫助使用者快速發現、理解和使用資料。

3、資料安全和隱私：資料湖中的資料往往包含敏感資訊，如個人身份資訊、財務資料等。資料湖的管理功能需要確保資料的安全性和隱私保護，包括訪問控制、資料加密、身份認證和審計等措施。

4、資料生命週期管理：資料湖中的資料具有不同的價值和使用期限，需要根據不同的需求進行儲存、備份、清理和歸檔等管理。資料湖的管理功能包括資料儲存策略、資料生命週期管理和資料歸檔等，以確保資料的可用性和成本效益。

5、後設資料管理：後設資料是描述資料的資料，包括資料的結構、定義、來源等資訊。資料湖的管理功能涵蓋了後設資料的收集、儲存、管理和維護，以提供資料的全面描述和理解。

04

—

資料湖的管理的開源元件有哪些?

Hive表作為資料湖儲存的確存在一些問題，主要包括以下幾點：

1、資料可靠性和一致性：Hive在批次寫入資料時，缺乏事務性支援，因此無法保證資料的原子性和一致性。當多個操作同時發生時，可能會導致資料的不一致性。如果同時存在 讀-寫，寫-寫 任務時，無法保證任務的一致性，會發生莫名其妙的錯誤，或剛寫入的資料被其它任務覆蓋了。

2、資料更新和增量計算：hive表不支援刪除，更新表等操作，Hive無法直接進行實時資料更新和增量計算。對於需要頻繁更新的資料，Hive需要執行全量寫操作，並覆蓋已有資料，導致效能低下。

3、後設資料管理：Hive的後設資料管理機制相對簡單，對於資料的版本管理和回溯能力有限。Hive 表的 schema 集中儲存在 metastore 中，metastore 很容易成為效能瓶頸，同時也會帶來分庫分表等運維成本。

4、Hive表下的HDFS資料查詢非常慢：現在的計算引擎(Presto Spark)都是分散式執行的，以 Spark 為例，假如某個表有 100 個資料檔案，執行時一共有 10 個 Executor，在 Exector 執行前，Driver 會對資料檔案進行切分，最終每個 Executor 可能分配 10 個資料檔案。由於 Hive 表格式只儲存了資料檔案的目錄，所以在檔案切分前會使用檔案系統的 list 操作，列出所有的資料檔案。list 操作存在以下問題：HDFS 檔案系統下，如果頻繁大量的呼叫 list 操作會給 NameNode 的 RPC 帶來壓力;如果檔案數過多，list 會比較耗時，曾經就遇到一個這樣的例子，由於一個表使用了二級分割槽，生成了大量的分割槽和檔案，在執行全表掃描的時候，僅僅是檔案切分就花了10 分鐘。

物件儲存下 list 操作非常慢。如果將HDFS檔案系統替換成分散式儲存的檔案系統，由於 Hive 表格式只儲存了資料檔案的目錄，所以在 Executor 執行時，先把計算結果寫入臨時目錄，等待 Executor 全部執行完成後，Driver 端會把臨時檔案目錄 rename 到正式的檔案目錄，此操作依賴檔案系統的 rename 操作。在物件儲存中 rename 操作非常慢。

為了解決以上四個問題，於是產生了資料湖的管理元件：Iceberg、Hudi和Delta Lake。

以下是三款資料湖產品的功能對比：

現在來看一下Iceberg、Hudi和Delta Lake是如何解決這些問題的，並且它們的側重點有何不同：

Iceberg： 定位於高效能的分析與可靠的資料管理。它引入了事務性支援和多版本管理機制，透過支援原子更新操作和管理多個資料版本，確保資料湖中的資料可靠、一致，並提供了強大的資料版本回溯和查詢功能。Iceberg 透過檔案組織設計也能達到資料更新效果，但是每一次的 commit 都會產生新的檔案，如果寫入/更新頻繁，小檔案問題會比較嚴重。

Hudi：Hudi主要解決資料湖中實時資料更新和增量計算的問題。Hudi 憑藉檔案組+索引+主鍵的設計模式，能夠有效減少資料檔案的冗餘更新，提高資料更新效率。Hudi支援索引以提高查詢效能。

Delta Lake：旨在於流批一體的資料處理。主要是透過spark引擎進行資料更新操作，它透過實現ACID事務性支援和管理後設資料，解決了Hive的批次寫入不具備事務性和後設資料管理能力的問題。Delta Lake還提供了靈活的資料版本控制和資料一致性保證。

儘管Iceberg、Hudi和Delta Lake都致力於解決Hive作為資料湖儲存存在的問題，但它們的側重點略有不同。

三個元件各自的優勢：

1、Iceberg:

支援低延遲的讀取和高效的增量寫入，適用於對查詢效能要求較高的場景。

提供了強大的事務性保證，支援ACID操作和併發寫操作。

提供了高度可靠的後設資料管理，可以跟蹤和管理資料集的更改歷史。

支援表分割槽和資料分層，可以提高查詢效能和降低儲存成本。

2、Hudi (Hadoop Upserts Deletes and Incrementals):

支援資料的增量更新和刪除操作。

提供了類似於資料庫的寫操作介面，可以實現事務一致性。隨著資料不斷寫入，會有小檔案產生。對於這些小檔案，可以自動地觸發小檔案合併的任務。

在查詢方面，Hudi 支援 Hive、Spark、Presto。支援索引。Hudi 的另一大特色是支援 Copy On Write 和 Merge On Read。前者在寫入時做資料的 merge，寫入效能略差，但是讀效能更高一些。後者讀的時候做 merge，讀效能查，但是寫入資料會比較及時，因而後者可以提供近實時的資料分析能力。

3、Delta:

支援 update/delete/merge。由於出自 Databricks，spark 的所有資料寫入方式，包括基於 dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是支援的。但是delta的增量跟新和寫入都和Spark強繫結。

在查詢方面，開源 Delta 目前支援 Spark 與 Presto，但是查詢需要和spark進行強繫結。Delta 在資料 merge 方面效能不如 Hudi，在查詢方面效能不如 Iceberg，但是delta 和spark 引擎結合的很好。

從社群運營的角度來看，Delta 和hudi的專案在開源社群的建設和推進方面做的較好。

從技術選項的角度來講，需要結合應用場景進行技術選項，不同元件缺少的部分功能需要額外開發來彌補。