數據湖元數據管理體系：需求剖析、功能架構與未來展望

摘" "要：隨著全球數據產量呈現指數級增長，傳統數據管理系統正面臨數量龐大、多樣化和實時性要求的挑戰。數據湖作為大型原始數據存儲庫，已成為有效處理各種類型和規模數據的關鍵工具。為了防止數據湖演變為數據沼澤，必須重視元數據的有效管理。文章聚焦數據湖數據生命周期，探究數據湖元數據管理需求，歸納數據湖元數據類型；綜合分析各領域的元數據架構，梳理數據湖元數據系統功能，揭示其在整個數據湖系統中的關鍵作用，并提出了數據湖元數據管理發展方向。探討了數據湖的運作機制以及數據湖元數據管理邏輯，為應對不斷增長的數據挑戰提供了有力支持。

關鍵詞：數據湖；元數據管理；元數據系統

中圖分類號：TP311.3；G353.1" "文獻標識碼：Ａ" "DOI：10.11968/tsyqb.1003-6938.2025011

Metadata Management System for Data Lakes：Requirements Analysis， Functional Architecture， and Future Directions

Abstract As global data production grows exponentially， traditional data management systems are increasingly challenged by demands for handling massive， diverse， and real-time data. Data lakes， serving as extensive repositories for raw data， have emerged as essential tools for managing data of varying types and scales. To prevent data lakes from deteriorating into data swamps， effective metadata management is crucial. Focusing on the data lifecycle within data lakes， this paper explores metadata management requirements， categorizes types of metadata in data lakes， and provides a comprehensive analysis of metadata architectures across various fields. The study further synthesizes current metadata architectures in data lakes and outlines the core functionalities of metadata management systems， highlighting their critical role in data lake ecosystems. This discussion of data lake operation mechanisms and metadata management logic aims to support the growing data management challenges.

Key words data lake; metadata management; metadata system

隨著數字化時代的發展，數據不斷增長和多樣化，傳統的數據倉庫體系在滿足日益復雜的數據需求方面顯得力不從心。數據湖（Data Lake）作為一種具有高度靈活性和可擴展性的數據存儲方式，逐漸成為數據管理領域的熱點。數據湖是一種能夠存儲各種類型數據，并通過靈活的訪問和分析工具提供全面數據管理能力的集中式存儲庫，為用戶提供更大的靈活性和自由度，以便從海量的數據中發現有價值的信息并進行深入的分析。在學術界和工業界，數據湖都是一種比較流行的數據存儲分析解決方案，許多公司都部署了數據湖，如亞馬遜AWS、微軟Azure、華為數據湖以及阿里巴巴數據湖等。目前，國內外學者對數據湖的概念和定義、數據湖與數據倉庫結合方法、數據湖元數據管理以及數據湖固有問題等內容進行了論述，對商業數據、政府數據、醫療數據、科學數據等領域的數據湖構建進行了研究，并取得了一定的成果。數據湖中的數據沒有明確的模式，在沒有高效元數據系統的情況下，數據湖很容易變成數據沼澤。本文從數據湖元數據需求與類型、數據湖元數據系統功能、數據湖元數據未來發展方向三個層面分析數據湖元數據管理。

1" "研究現狀

數據湖的概念最初由工業界提出。2010年，Dixon提出了“數據集市就像是一家提供經過凈化包裝水的商店，供應經過處理、方便消費的數據。相比之下，數據湖是一個自然狀態下的大水體，來自不同源頭的數據源不斷流入湖中，用戶可對數據進行自主檢查、分析或取樣”［1］。2011年，Woods在其發表的《Big Data Requires a Big New Architecture》一文中論述了“Data Lake”一詞，數據湖的概念開始廣為傳播。Woods指出數據倉庫存在的局限：為優化存儲，支撐特定分析，數據倉庫的數據在集成時就會被預先分類［2］。但在大數據時代，從源系統抽取數據時無法明晰數據的價值，因此無法給出最優的存儲方式。自2014年以來，學術界開始研究數據湖，認為數據湖具備以下特征：以低成本的原生形式存儲各種類型的數據，僅利用時轉換數據，允許識別或消除數據，為用戶提供有關數據來源的信息［3］。其中，重要關鍵詞是“按需應變”，只有在數據訪問時，才會執行模式定義、集成或索引等。IBM紅皮書認為數據湖是一組集中式的存儲庫，包含大量的原始數據，由元數據描述、組織成可識別的數據集，并可根據需要采用［4］。Gartner同樣指出數據湖由各種數據資產的存儲實例集合組成，以源格式存儲［5］。數據湖由元數據源索引管理，以保證數據質量，由規則、工具和流程控制，實現數據治理。部分數據僅限于數據科學家或數據統計學家訪問，以確保數據安全、數據隱私和合規性。Kottursamy等提出數據湖基于自我需求進行編目、索引和元數據管理，并為數據利用和計算分析提供信息［6］。數據湖是所有數據源或數據集的邏輯視圖，其原始格式可供數據科學家或統計學家使用，以尋找新的見解［7］。2019年，Ravat和Zhao綜合了其他人的數據湖定義，提出了一個包括數據湖的輸入、過程、輸出和治理的定義［8］。約翰和米斯拉也指出數據湖是一個存儲企業的各種各樣原始數據的大型倉庫，其中的數據可供存取、處理、分析及傳輸［9］。國內學者林擁軍提出數據湖以“存儲一切、分析一切、創建所需”為目標，以“建湖、引水、水資源利用”為發展路徑［10］。

數據湖架構描述了數據在數據湖中的概念組織方式，通過定義特定用途所需的條件（如原始數據或處理數據），可以找到數據的位置來促進數據湖的使用。分析數據湖中不同數據源的存儲方式、數據流的處理過程以及數據的組織和管理方式，能夠根據需求設計和實施適當的元數據管理模型和生成策略，以確保數據湖中的數據可靠、準確、可發現和可利用。基于不同的視角，學者對數據湖架構的分類方法有所不同。Sawadogo和Darmont將數據湖架構分為功能架構、數據成熟度架構、混合架構三組［11］。功能架構根據功能的不同來定義數據組織方式，包括用于連接到數據源的數據攝入功能、保存原始和精煉數據的數據存儲功能、數據處理功能、允許查詢原始和精煉數據的數據訪問功能。數據成熟度架構組件根據數據細化級別定義，混合架構的組件取決于數據湖功能和數據細化。根據數據成熟度的不同，數據湖架構可以分為原始數據層、用于增強的每日數據層、用于第三方信息的數據層三個獨立層。此外，根據數據湖的生命周期劃分為三個分區：小于6個月的數據、較久遠但仍活躍的數據、存檔不再使用但需要保留的數據。數據湖架構又可以分為以數據存儲為中心的架構和以數據處理為中心的架構。以數據存儲為中心的結構，根據數據的處理深度和安全級別來組織數據，其優勢在于提供了一種在數據湖內組織數據的方法，但預定義的數據組織方式忽略了數據處理、元數據管理等。以數據處理為中心的架構是一個完全集成的平臺，用于收集、存儲、轉換和分析數據以進行知識提取。其中，數據湖比較常見的劃分方式包括區域架構和池塘架構。恩門提出的池塘架構將數據湖分為五個不相交的池：初始數據池、模擬信號數據池、應用程序數據池、文本數據池和歸檔數據池［12］。在任何給定時間，數據始終只能在上述池塘之一中獲得，數據在通過池塘時進行處理。池塘架構數據經過預處理，可以輕松分析，但當數據離開原始數據池時，數據將發生改變并且其原始格式會丟失，與數據湖的概念相矛盾。區域架構存在許多不同的變體，在區域數量、支持的用戶組以及側重點方面也有很大差異。每個區域定義了數據必須具有的某些特征，不同的區域包含不同處理程度的數據，如原始數據或已處理數據。通常包括三區域、四區域、五區域，最多六區域。其中，Cravero等所提出的三區域模型中，第一個區域存儲原始數據，第二個區域存儲來自第一個區域的已處理數據，第三個區域是訪問區［13］。也有學者在此基礎上添加了數據治理區域［14］。與池塘架構相比，區域架構是有相交的，數據可以從一個區域復制到另一個區域，或者一個區域可能包含來自不同區域的數據，其優點是即使數據以轉換和預處理的格式提供，仍然可以作為原始區域中的原始數據進行訪問。然而，關于區域的數量和特點，現有研究觀點各不相同，也未有研究表明哪些區域是必需的，哪些區域是可選的。

在池塘和區域結構中，數據都是經過預處理的，能夠快速簡單地進行分析，原始數據在傳輸到其他池塘時會被刪除，會出現數據丟失的問題。多區域架構的缺點在于數據流跨多個區域，可能導致數據產生多個副本，難以控制數據沿襲。在混合架構中，數據科學家必須根據兩種不同的邏輯進行交叉分析，數據分析總體上更加困難［15］。為了克服池塘和區域分類的矛盾，基于功能的混合架構被廣泛使用［16］。另外一個比較典型的混合架構是Lambda架構［17］，支持單獨的批處理和實時處理。傳入數據被復制到兩個不同的分支，在一個分支上，數據永久存儲，并定期批量處理，在另一個分支上，實時處理傳入的數據以快速提供結果。在實踐中，Lambda架構經常被調整，且產生很多變體。

總的來說，數據湖是一個大數據分析解決方案，從各種來源攝取異構原始數據，并以其原生格式集中化存儲所有數據源，提供可用數據目錄，進行數據治理以確保數據質量和數據安全，支持不同類型的用戶不同需求類型的數據分析，從而提高數據的可重用性和價值。顯然，數據湖架構有多種可替代的方案，其中區域架構在文獻中被提及的頻率相對較高，但對各個區域的定義存在顯著差異。目前，關于不同數據湖架構的評估或比較的文獻研究相對較少。

數據湖按原樣存儲結構化和非結構化數據，數據具有多樣性、高冗余性和復雜性，沒有良好的元數據管理支持，數據湖將會變成數據沼澤。元數據在數據整個生命周期中的數據發現、跟蹤（沿襲）、存儲和歸檔、組織和管理、隱私保護、查詢和檢索中扮演著非常關鍵的角色。有效的元數據管理能夠幫助用戶更好地理解數據，提高數據發現的效率，降低數據分析的復雜性，從而增強數據應用效能并提升決策質量。然而，由于數據湖的開放性和靈活性，元數據管理面臨著許多挑戰。學者對數據湖元數據的研究包括以下幾個方面：首先是元數據的功能和類型以及元數據通用模型研究；其次是數據湖中各種類型數據和處理步驟的元數據管理研究，如數據內容元數據管理、數據處理元數據管理、文本文件的元數據管理、面向分析的元數據管理等；最后是元數據生成與擴充方法研究，如數據湖元數據的提取與生成方法、數據湖元數據擴充機制，元數據的可視化等。

現有文獻多從特定問題出發，提出元數據系統功能，構建元數據框架，少見對元數據管理的全流程進行系統性的研究。

2" "數據湖中元數據管理需求分析

2.1" " 數據湖數據生命周期中元數據角色

數據多樣性是數據湖常態，匹配特定存儲需求的多范式儲存系統較為常見。基于數據湖內涵與架構的分析，數據存儲在三個區域中：數據攝入的原始數據區域、數據處理的中間數據區域和數據訪問的可用數據區域。數據攝入是指將各種來源的數據導入到數據湖中，包括結構化、半結構化和非結構化數據；數據處理是指根據需求對數據湖中的數據進行各種處理操作，如數據清洗、數據轉換、數據整合、數據加工等；數據訪問是指從數據湖中提取數據進行查詢、分析和可視化，洞察數據價值。元數據的目的是識別、評估和跟蹤資源，對信息資源的選擇、組織、互操作和集成、唯一標識符識別、數據歸檔和保存等方面都有重要作用。

2.1.1" "數據攝入

數據攝入是數據湖中數據生命周期的第一階段，負責將來自異構源的數據導入數據湖系統中，無論源數據的格式為何，數據以其原始格式加載并存儲在系統中。數據攝入包括流式處理和定期攝取，若數據源為系統生成，則必須使用流式處理技術進行實時引入。若數據源的信息是靜態的或者不是實時必需的，則可以進行定期數據收集［18］。數據攝入的系統工具包括Apache Nifi、Apache Flume以及Apache Sqoop等。數據攝入工具各有特點，可結合使用，如可利用Apache Sqoop處理各種應用程序存儲在關系數據庫中的海量數據，利用Apache Flume進行操作更頻繁但是數據量相對較小的微批處理操作。O'Leary使用不同的AI和眾包應用程序整合不同的數據源，促進主數據管理并分析數據質量［3］。

數據湖中有多個不同的數據源，存在數據重復、數據冗余和數據不一致等潛在風險和問題。在數據攝入階段，應收集所有攝入數據集的信息性和描述性元數據，生成不同類型的元數據，包含攝入過程的元數據、攝入數據集的元數據、數據準確性的元數據、數據安全的元數據、數據集關系的元數據。大多數數據攝入工具也可用于提取數據攝入過程中的元數據，如在文件路徑和名稱中嵌入元數據信息。元數據是隨著時間的推移被添加到數據源中的，攝入階段可使用自定義或預定義標記元數據對數據進行注釋。此外，元數據能夠對攝入數據的內容進行淺層數據視圖分析，基于元數據的數據視圖可用于演化過程中數據集的重復檢測和多版本控制，維護數據集的基本組織結構。

2.1.2" nbsp;數據處理

數據處理過程中，數據管理者或用戶根據自身需求轉換、分析數據，并將所有中間轉換的數據進行存儲，在此過程中數據以不同的方式進行操作，原始數據的上下文和預期用途可能會受到影響。數據處理包括批處理和實時處理，批處理的源數據集是數據湖中攝入的數據集，而實時處理的源數據集是外部數據集，元數據在批處理和實時處理中對數據進行實例化。在數據湖中，數據處理通常使用由Apache Hadoop提供的并行數據處理范式MapReduce執行，但處理實時數據的效率較低。因此，Apache Spark成為最出名的替代處理框架，其不使用文件系統來存儲中間結果，適合實時處理。同樣，Apache Flink和Apache Storm也適用于實時數據處理，兩種方法可以在數據湖中同時實現。

為確保用戶能夠找到數據是如何處理和存儲在數據湖中的，元數據提供了描述數據處理過程的信息。元數據能夠跟蹤數據何時傳入、如何格式化，以及如何在處理的后期階段使其可用，包括誰、何時以及做了什么的流程基本信息，解釋流程的上下文、含義和目標的流程定義，涉及源代碼和執行信息的技術信息，讓用戶了解流程的部署方式，并能夠修改或重用流程，用戶可以更好地理解和利用數據湖中的數據。此外，為了便于數據分析，需要考慮數據定義的元數據，從數據中提取可用信息，并根據該知識作出決策。定義元數據幫助用戶了解數據集的性質，查找現有的分析及其使用的模型，輸出和評估等，以便用戶可以選擇最合適的方法來更有效地分析數據。數據分析可確保現有流程的可發現性、可訪問性、可互操作性和可重用性，以簡化數據湖中的數據探索并使其更具交互性。

2.1.3" "數據訪問

數據訪問區存儲所有可用數據并提供數據訪問，該區域允許用戶訪問不同分析程度的數據，如報告、統計分析、商業智能分析、機器學習算法等。Apache Spark提供了各種API和工具，如Spark SQL和Spark Streaming，可以用于查詢和處理數據湖中的數據。CKAN和Socrata提供了API來訪問開放數據和相關元數據目錄，用于數據檢索和從Web傳輸到數據湖。

為了進一步使用存儲在湖中的數據，應提取數據特征和描述性元數據，以方便數據導航和提取利于決策的信息。通過元數據，用戶能夠查詢可用的數據集、數據集的來源和更新頻率，以及數據的字段和數據類型等信息。查詢數據湖還將涉及一個探索過程，以檢測與所需的特定信息相關的數據源。此外，帶注釋的元數據不僅能夠用于查詢，還能進一步豐富關于如何在查詢中使用數據源的信息。元數據提供關于數據質量的信息，如數據完整性、準確性和一致性等，了解數據的質量指標，評估數據的可信度和可靠性，并決定是否使用某個數據集進行分析或決策。元數據記錄數據的訪問權限和安全規則，通過元數據可以確定哪些用戶或團隊有權訪問數據，并對數據進行相應的授權控制，確保數據的安全性，并遵守適用的數據隱私法規和政策。

2.2" " 元數據類型劃分

從上述數據湖數據生命周期中可以看出元數據定義了數據、流程、應用程序和技術之間的關系，包括數據結構、數據管理、數據集成、規范值、數據質量、數據安全、數據訪問、內容管理、技術架構、技術清單等信息［19］。國際標準化組織（National Information Standards Organization，NISO）將元數據分為簡化信息檢索或發現的描述性元數據、描述數據模式的結構性元數據、用于存儲與互操作的管理元數據以及允許存儲數據語義結構的標記語言四類［20］。有學者整合了數據生命周期中涉及的元數據，對其進行了進一步的區分，將專用于數據湖的元數據分為功能元數據和結構元數據兩種主要類型。對于功能元數據，根據收集方式分為業務元數據、操作元數據以及技術元數據三類元數據［21］，但有學者認為由于不同來源不同類型的數據被攝入并存儲在一個數據湖中，沒有預先定義的需求，業務元數據對于數據湖并不是必要的，且三類元數據之間存在交叉，如數據字段由業務用戶在數據模式中定義，與業務和技術元數據都相關，同樣，數據格式可以被視為技術和操作元數據。對于結構元數據，結構元數據的分類可以被視為功能元數據分類的擴展和概括，基于對象的概念分為對象內、對象間和全局元數據三類。此外，元數據可以按元數據間和元數據內進行分類，元數據間描述了數據之間的關系，根據數據集來源、邏輯集群和內容相似性等進行分類［22］。元數據內指定每個單個數據集，根據數據特征、定義、導航、活動、譜系等進行分類［23］，此種分類不僅涉及每個數據集的信息，還包含數據集之間的關系。也有學者根據不同的數據湖分區將元數據類型分為了數據攝入過程、數據處理過程以及數據分析過程的元數據。

數據攝入是提取元數據的最先考慮階段，在數據處理過程和訪問階段產生的信息也有價值。正如在數據湖功能架構的示例中可以看到的，攝取區存儲不同類型的數據集，流程區可以通過多個步驟處理不同的數據集，訪問區可以確保原始數據集以及處理過的數據集的可用性。基于此，總結數據湖各區域中元數據需求，根據元數據的創建模式及其在信息系統管理中的作用，對其進行分類（見圖1）。

在數據湖功能架構中，攝入區存儲不同類型的數據集，流程區可以通過多個步驟處理不同的數據集，訪問區可以確保原始數據集以及處理過的數據集的可用性。元數據類別主要分為六種類型（具體含義與元素示例見表1）。其中，特征元數據用于描述和管理數據湖中的各種特征，為數據科學家和分析師提供了清晰的數據視圖；定義元數據提供對數據湖中數據結構和架構的詳細描述，確保數據一致性和可理解性；譜系元數據記錄數據湖中數據的源頭和變更歷史，為數據溯源和可信度提供支持；質量元數據用于評估和監控數據湖中數據的質量，維護數據可靠性和準確性；安全元數據關注數據湖中數據的安全性和隱私保護，保障數據合規性和安全存儲；導航元數據提供對數據湖中數據的索引和檢索功能，使用戶能夠更輕松地發現和訪問所需的數據資源。這六種元數據共同構建了一個完整的數據湖管理框架，促進了數據湖的有效管理、分析和利用。

每種元數據類型都有助于提高數據湖的可理解性和可發現性。通過維護元數據，能夠更好地理解數據的含義、來源、質量狀況以及訪問控制等關鍵信息，從而更有效地利用數據湖中的信息資源。

3" "數據湖元數據系統功能與架構

3.1" " 元數據系統功能

元數據是現代數據架構的核心，與其他數據一樣，元數據也必須進行管理，元數據管理是針對元數據的數據管理。數據湖旨在攝取各種結構的原始數據，元數據管理在數據湖信息系統中能夠最大限度地提高數據的價值，建立一個通用、可擴展、靈活的元數據系統（MetaData Management System，MDMS），對數據湖至關重要。用于數據湖的元數據系統應該具備處理不同數據模型中元數據的能力，包括對數據預處理信息的記錄、采用語義方法匹配數據類型、表示元數據條目之間的映射，并支持元數據的演化。總的來說，元數據系統支持元數據提取和維護、架構演變處理、發現系統的全局本體與表示數據源的本地架構的元數據之間的映射［24］。

不同的元數據系統來自不同的領域，代表不同的觀點，因此在功能方面有所不同。通用元數據模型應該適應任何數據湖，元數據模型支持的功能越多就越通用，學者對通用元數據系統的功能進行了總結。Sawadogo和Darmont確定了數據湖元數據系統理想情況下應實現的六個功能：語義豐富、數據索引、鏈接生成、數據多態性、數據版本控制以及使用跟蹤［11］。Eichler在此基礎上確定了另外三個特性：元數據屬性、區域元數據和多粒度級別支持［25］。考慮到以上兩組特征都是相關的，Scholly等建議將兩者結合起來比較元數據模型的通用性，將數據多態性與區域元數據合并，將鏈接生成分為相似性鏈接和分類，并去掉了數據索引［26］。本文基于數據湖數據的生命周期，將元數據系統的功能總結為語義豐富、屬性定義、多粒度描述、數據分類、語義鏈接、多態數據支持、版本管理、使用跟蹤以及數據索引（見表2），統計了數據湖系統的不同元數據系統可用的所有功能。

在數據湖數據生命周期的早期階段，元數據系統通過語義豐富和屬性定義為原始數據采集提供了關鍵的上下文和理解。語義豐富通過語義注釋或語義分析已知的內容生成對數據上下文的描述，如向數據添加標簽以便準確地理解和解釋數據的含義、結構和關系。屬性定義表示數據源的描述性元數據，元數據系統記錄了關于數據的各種屬性。隨著數據存儲，元數據系統在多個粒度級別上收集元數據，從而在元數據的詳細級別和分配方面保持靈活性，為數據管理奠定了基礎。大多數元數據是在特定數據元素上收集的，數據元素按區域進行組織，元數據應該可以跨區域區分，從而在分配元數據時獲得靈活性。支持各種不同的數據格式和類型，包括結構化數據、非結構化數據和半結構化數據，存儲相同數據的多個表示，適應不同數據的存儲和處理需求。

在數據處理和分析階段，數據分類和語義鏈接功能幫助用戶更好地理解和利用數據的關聯關系。語義鏈接定義兩個或多個數據源之間的關系類型，識別和集成數據湖之間的鏈接，建立不同數據源之間的關聯，并生成鏈接，有助于發現和分析數據之間的關系，支持更全面的數據分析和洞察。數據分類用于將在不同存儲庫中的相關數據聚集在一起，對數據集進行分類描述數據和數據的位置，還可以定義如何訪問數據，允許數據分析人員定位其分析所需的數據。元數據系統的版本管理支持用戶追蹤數據的演變過程，使用跟蹤功能記錄數據的實際使用情況，允許管理同一數據源版本，支持數據轉換后的頻繁更改。跟蹤和記錄用戶對數據的使用情況，如創建、讀取和更新等操作，允許透明地跟蹤數據對象的演變，通過解釋數據不一致或通過入侵檢測來實現數據安全，提供審計和合規性的支持。

在數據應用階段，數據索引構建加速了數據的檢索和全球范圍內的應用。這一系列功能貫穿于整個數據湖數據生命周期，為組織提供了全面的數據管理和應用支持，最大化了數據湖的潛力。

3.2" " 元數據系統架構

元數據架構是指構建和組織元數據的整體結構和框架，定義了元數據的存儲、訪問、管理和維護的策略和機制。需要根據不同的功能需求來設計和組織元數據，以確保元數據能夠滿足關鍵功能的要求。

目前已經提出了許多為數據湖量身定制的元數據模型和系統，大多數數據湖元數據系統的架構都基于圖形方法，如有向來源圖、基于相似度的無向圖以及來源和相似度結合的數據網絡圖等。此外，也有學者提出使用數據保管庫（Data vault）的形式對元數據進行管理。

（1）有向來源圖。遵循數據的生命周期，從功能角度創建一個專門用于元數據的區域，旨在成為所有元數據的保存點，允許在原始的上下文中重用這些數據，包括數據攝入、處理、分析的元數據。主要管理元數據有關活動，數據對象和與特定對象交互的用戶的信息，跟蹤數據對象的譜系。該類架構可視為一個來源圖，即有向無環圖，其中節點表示用戶、角色或對象等實體，邊緣用于表達和描述實體之間的交互。數據來源跟蹤記錄數據源、考慮結構化和非結構化數據集、在數據湖中完成的所有工作、存儲每個數據集的信息、不同數據集之間的關系，以及數據集的質量、敏感性和訪問控制［39］。因此，該類架構可用于檢測、解釋和修復數據中的不一致之處，通過版本管理確保數據湖中流程的可重復性，通過入侵檢測保護敏感數據。

（2）基于相似度的無向圖。基于相似度的圖架構將元數據架構描述為無向圖，側重于檢測和表示數據集之間的相似性。其中節點是數據對象，邊表示對象之間的相似性，數據集之間相似性可以通過加權邊或非加權邊來指定［40］，加權邊顯示了相似性強度。Brackenbury等以數據本質、起源、當前特征等維度提出了相似性比較框架，為數據相似性發現提供了研究基礎［41］。以相似度為中心的圖形設計能夠對數據湖進行網絡分析，如計算節點的中心性，從而計算數據在湖中的重要性。數據集間的元數據以圖形化的方式表示，能夠分析數據集之間的可連接性和親和性，可連接性衡量共同值的相互百分比，而親和性則根據外部知識衡量關系的語義強度。數據相似性能夠自動向用戶推薦與當前檢索到的數據相關的數據。在相似性識別方面，收集匯總數據集內容的整體元特征，包括有關所有屬性的總體統計數據、找到的屬性類型和實例總數，有效地預測用于模式匹配預過濾的相關數據集，如實例數、每個屬性類型的屬性數、維度和缺失值數。對于在數據集中的每個屬性，通過計算適當的特征根據其類型對其進行分析［42］，可以有效地預測具有相似模式和存儲信息的相關數據集。

（3）數據網絡圖。將每個數據對象分解為多個固有元素，幫助用戶瀏覽數據，還可用作檢測對象之間連接的基礎。Diamantini等使用簡單的字符串度量，通過比較異構對象各自的標簽來檢測數據之間的聯系。將數據湖中的每個數據對象（如單個文檔）建模為RDF圖，根據數據對象之間的關系將這些較小的圖形組合成總體數據湖圖［34］。HANDLE模型根據利用率對元數據進行建模，元數據模型為元數據對象創建元數據屬性，以反映最多樣化的信息，模型支持數據湖多區域描述，并且支持在各種粒度級別上收集元數據。MEDAL模型采用基于超圖、嵌套圖和屬性圖概念的邏輯元數據表示。通過包含各種元素（版本和表示、屬性等）的超節點來表示對象，超節點可以鏈接在一起（相似性、親子關系等）。也有學者利用本體來構建元數據管理知識圖譜［43］。

（4）數據保管庫。有學者提出使用數據保管庫對數據湖中的數據進行建模［44］。數據保管庫源自數據倉庫上下文，提供了一種靈活而簡單的數據建模方法。雖然存在將半結構化數據集成到數據保管庫中的方法，但尚未涵蓋集成非結構化數據。將為數據倉庫中的維度數據模型實現星形架構或雪花型架構［45］。星形架構易于理解和實現，中間將有一個實時數據表，被多個維度表包圍。事實數據表使用主鍵和外鍵連接到各種維度表。對于雪花架構，中心仍然會有一個實時數據表，但它不僅會被維度表包圍，還會被子維度表包圍。數據保管庫允許輕松的模式演變。數據保管庫建模涉及三種類型的實體：中心表示業務概念，連接表示兩個或多個中心之間的關系，衛星包含與集線器或鏈路關聯的描述性信息。Nogueira等提出了一種數據湖的元數據庫模型來代替多維模型［46］。在ArchaeoDAL中采用的goldMEDAL模型在概念、邏輯和物理級別建模，其中包括四個主要的元數據概念：數據實體、分組、鏈接和過程，概念完全相互作用以支持數據湖元數據管理需求，分組的概念支持各區域的數據湖組織，允許管理多個處理的數據粒度級別。

除了上述架構模式外，有學者也提出了其他類型的框架，如用于描述數據字典的元數據架構（Ontology-Agnostic Metadata Schema，OIMS）以及將數據湖中的所有實體表示為FAIR數字對象等方式［47］。總體而言，目前的元數據系統架構各有優劣，根據具體的需求和場景，可以選擇適合的元數據系統來優化數據湖元數據管理的效果。

4" "數據湖元數據管理發展方向

4.1" " 構建智能化元數據管理系統

在數據湖中，元數據不僅是數據的附屬信息，更是實現高效數據管理和價值挖掘的關鍵。數據湖元數據管理系統應引入人工智能與機器學習技術，構建具有自適應與自學習能力的元數據管理體系。利用智能化手段使元數據的自動生成、更新、分類和標注成為可能，從而大幅減少人為干預，提升數據處理的效率與準確性。

傳統元數據管理系統多以靜態描述為主，難以滿足數據湖動態變化的需求。動態元數據管理意味著系統能夠實時追蹤數據集變化并更新元數據。當數據集更新或發生結構性變化時，元數據系統將自動記錄并展示變化，確保元數據與實際數據保持一致性，提供更及時的元數據支持，使用戶更便捷地獲取最新數據狀態，從而提升數據分析的準確性與決策質量。為此，需要建立精細化的元數據分類和索引機制，使用戶能夠快速識別、理解并利用數據湖中的數據資源。

在智能元數據生成與推薦方面，元數據系統應結合數據挖掘與模式識別技術，識別不同數據類型的特征并自動生成描述性、管理性與技術性元數據。通過機器學習算法分析數據集特征并提取關鍵詞和標簽，實現快速分類與檢索。此外，智能元數據推薦功能將成為未來系統的亮點。通過分析用戶行為、數據使用歷史及相似數據集的模式，自動推薦相關數據集，輔助用戶快速篩選所需數據，有效減少人工篩選時間，提高數據利用效率。

4.2" " 推動跨平臺互操作性與開放標準

在實際應用中，數據湖系統往往分布在多個平臺上，因此元數據管理系統需要兼顧跨平臺兼容性與互操作性。數據湖應用場景廣泛，不同行業與組織對數據湖的需求各不相同，跨平臺兼容性是實現數據湖價值最大化的關鍵之一。未來的研究將重點關注元數據標準化設計，通過制定并推廣開放標準，增強不同數據湖平臺之間的互操作性，使數據能在不同環境中更加順暢地共享與整合。開放的元數據標準將促進各平臺間的兼容性，使數據跨平臺流動無縫銜接，從而提高多源數據整合與分析效率，同時為跨領域的數據協作創造空間。基于共享的元數據標準，實現數據的共同建設和共享，推動多領域創新發展，提升數據湖的靈活性與擴展性，以應對未來業務需求的不斷變化。

跨平臺互操作性在不同組織間的數據共享中尤為重要。通過兼容性設計，企業、政府和研究機構等多方可實現數據互通，擴大數據湖的應用潛力。元數據的標準化和跨平臺兼容性是數據共享的基石，有助于數據湖在多領域應用中的發展。

4.3" " "增強隱私保護和合規性支持

在大規模數據存儲中，數據安全與隱私保護始終是核心關注點。系統不僅需要記錄數據的訪問權限和加密狀態，還應具備自動化的合規性檢測功能，以確保數據安全使用。通過數據訪問權限元數據，系統實時管理數據訪問權限，確保僅授權用戶能訪問特定數據集；系統還可記錄數據的加密狀態，以確保敏感數據在傳輸和存儲過程中的安全性。此外，系統可依據不同隱私保護政策設置相應合規性檢查，確保數據使用與共享符合法律法規。系統通過自動化檢測工具，實時監控數據的合規狀態，并在檢測到潛在違規時及時通知用戶或采取保護措施，提升數據湖系統的安全性，顯著降低管理成本。

在增強隱私保護背景下，數據訪問控制和權限管理是元數據管理系統的重要組成部分。系統可通過記錄數據訪問權限元數據，幫助管理者掌握數據訪問權限，便于實現更嚴格的數據訪問控制。對包含敏感信息的數據集，系統可設定嚴格訪問權限，限制訪問范圍；此外，系統還可基于訪問記錄進行權限審計，以便管理者更好地監控數據使用情況。在多方合作的數據共享中，數據訪問控制也十分重要。通過精細化的權限管理，數據湖系統可確保敏感信息僅限授權人員訪問，并支持動態權限調整以滿足項目需求。動態權限管理提升了數據共享的安全性與靈活性，使數據湖在敏感數據處理與合規性管理中更具優勢。

5" "結語

數據湖作為一種大數據存儲和處理范式，整合多種數據源，并提供各種分析和查詢功能。在數據湖中，元數據扮演著關鍵的角色，描述數據的架構、內容，以及數據湖中包含的數據的屬性、結構和上下文信息，確保數據湖的數據可發現、可理解、可訪問和可管理。

數據湖中的數據是異構多樣的，如何對數據進行準確的描述和分類是重要的議題，數據的分散性和去中心化特點也對元數據管理提出了新的要求和挑戰。本文關注數據湖中元數據管理的關鍵問題和解決方案，從數據湖的架構與技術出發，探討數據湖對元數據的需求以及元數據類型，對數據湖元數據的架構與系統功能進行了論述，并提出了未來數據湖元數據系統的發展發現，為數據應用和決策提供有力支持。數據湖的數據量龐大，傳統的手工管理方法無法滿足其快速增長的需求，未來需要借助自動化和智能化的手段來提高元數據管理的效率和精確度。

參考文獻：

［1］" Dixon J.Pentaho，Hadoop，and data lakes［EB/OL］.［2024-09-10］.https：//jamesdixon.wordpress.com/2010/10/14/pentaho-hadoop-and-data-lakes/.

［2］" Woods D.Big data requires a big，new architecture［EB/OL］.［2024-09-10］.https：//www.forbes.com/ sites/ciocentral/2011/07/21/big-data-requires-a-big-new-architecture/.

［3］" O'leary D E.Embedding AI and crowd sourcing in the big data lake［J］.IEEE Intelligent Systems，2014，29（5）：70-73.

［4］" Chessell M，Scheepers F，Strelchuk M，et al.The journey continues from data lake to data-driven organization［EB/OL］.［2023-10-13］.https：//www.redbooks.ibm.com/redpapers/pdfs/ redp5486.pdf.

［5］" Gartner Glossary.Data lake［EB/OL］.［2024-10-13］.https：//www.gartner.com/en/information -technology/glossary/data-lake.

［6］" Kottursamy K，Raja G，Padmanabhan J，et al.An improved database synchronization mechanism for mobile data using software-defined networking control［J］.Computers amp; Electrical Engineering，2017，57：93-103.

［7］" Hai R，Koutras C，Quix C，et al.Data lakes： a survey of functions and systems［J］.IEEE Transactions on Knowledge and Data Engineering.2023，35（12）：12571-12590.

［8］" Ravat F，Zhao Y.Metadata management for data lakes［C］//New Trends in Databases and Information Systems.Berlin： Springer，2019：37-44.

［9］" ［印］湯姆斯·約翰（Tomcy John），潘卡·米斯拉（Pankaj Misra）.企業數據湖［M］.張世武，李想，張浩林，譯.北京：機械工業出版社，2019：18-35.

［10］" 林擁軍.數據湖——新時代數字經濟基礎設施［M］.北京：中共中央黨校出版社，2019：63-95.

［11］" Sawadogo P，Darmont J.On data lake architectures and metadata management［J］.Journal of Intelligent Information Systems，2021，56（1）：97-120.

［12］" ［美］比爾·恩門（Bill Inmon）.數據湖架構［M］.吳文磊，譯.北京：人民郵電出版社，2017：36-43.

［13］" Cravero A，Lefiguala I，Tralma R，et al.Data lake architecture proposal for the analysis directorate of a regional university［C］//2020 39th International Conference of the Chilean Computer Science Society（SCCC）.Coquimbo，Chile，2020：1-5.

［14］" Zhao Y，Megdiche I，Ravat F，et al.A Zone-based data lake architecture for IoT，small and big data［C］//The 25th International Database Engineering amp;amp.New York： ACM Press，2021：94-102.

［15］" Mathis C.Data lakes［J］.Datenbank-Spektrum，2017，17（3）：289-293.

［16］" Ren P，Mao Z，Li S，et al.Intelligent visualization system for big multi-source medical data based on data lake［C］//Web Information Systems and Applications.Berlin：Springer，2021：706-717.

［17］" Warren J，Marz N.Big data-principles and best practices of scalable real-time data systems［M］.New York：Simon and Schuster，2015：284-301.

［18］" Benayas F，Carrera ？魣，Amado M G.A semantic data lake framework for autonomous fault management in SDN environments［J］.Transactions on Emerging Telecommunications Technologies，2019，30（9）：1-9.

［19］" Laurent D，Laurent A.Data lakes［M］.Wiley-ISTE，2020：21-39.

［20］" Riley J.Understanding metadata：What is metadata，and what is it for？［EB/OL］.［2024-10-18］.https：//groups.niso.org/apps/group_public/download.php/17446/Understanding%20Metadata.pdf.

［21］" Oram A.Managing the data lake［M］.Sebastopol：O'Reilly，2015：1-18.

［22］" Halevy A Y，Korn F，Noy N F，et al.Managing Google's data lake：an overview of the Goods system［J］.IEEE Data Eng，2016，

39 （3）：5-14.

［23］" Bilalli B，Abelló A，Aluja-Banet T，et al.Towards intelligent data analysis：the metadata challenge［C］//Proceedings of the International Conference on Internet of Things and Big Data （IoTBD 2016），Roma，Italy，2016：331-338.

［24］" Alrehamy H，Walker C.SemLinker：automating big data integration for casual users［J］.Journal of Big Data，2018，5：1-26.

［25］" Eichler R，Giebler C，Gr？觟ger C，et al.Modeling metadata in data lakes—a generic model［J］.Data amp; Knowledge Engineering，2021，136：101931.

［26］" Scholly E，Sawadogo P，Liu P，et al.Coining goldMEDAL：a new contribution to data lake generic metadata modeling［A/OL］.［2023-12-29］.https：//arxiv.org/abs/2103.13155.

［27］" Hai R，Geisler S，Quix C.Constance：an intelligent data lake system［C］//Proceedings of International Conference on Management of Data.New York：ACM Press，2016：2097-2100.

［28］" Quix C，Hai R，Vatov I.Metadata extraction and management in data lakes with GEMMS［J］.Complex Systems Informatics and Modeling Quarterly，2016（9）：67-83.

［29］" Farid M，Roatis A，Ilyas I F，et al.CLAMS：Bringing quality to data lakes［C］//Proceedings of International Conference on Management of Data.New York：ACM Press，2016：2089-2092.

［30］" Singh K，Paneri K，Pandey A，et al.Visual bayesian fusion to navigate a data lake［C］//In 19th international conference on information fusion.Heidelberg，Germany，IEEE，2016：987-994.

［31］" Hellerstein J M，Sreekanti V，Gonzalez J E，et al.Ground：a data context service［C］//The 8th Biennial Conference on Innovative Data Systems Research.Chaminade，Canada，2017：1-12.

［32］" Maccioni A，Torlone R.KAYAK：a framework for just-in-time data preparation in a data lake［C］//Advanced Information Systems Engineering.Berlin：Springer，2018：474-489.

［33］" Beheshti A，Benatallah B，Nouri R，et al.CoreKG：a knowledge lake service［J］.Proc.VLDB Endow，2018，11（12）：1942-1945.

［34］" Diamantini C，Giudice P L，Musarella L，et al.A new metadata model to uniformly handle heterogeneous data lake sources［C］//New Trends in Databases and Information Systems.Berlin：Springer，2018：165-177.

［35］" Ravat F，Zhao Y.Data lakes：trends and perspectives［C］//Database and Expert Systems Applications.Berlin：Springer，2019：304-313.

［36］" Eichler R，Giebler C，Gr？觟ger C，et al.HANDLE-a generic metadata model for data lakes［J］.Data amp; Knowledge Engineering，2021（136）：73-88.

［37］" Cherradi M，El Haddadi A.DLDB-Service：An extensible data lake system［C］//International Conference on Networking，Intelligent Systems and Security.Cham：Springer International Publishing，2022：211-220.

［38］" 劉坤嶧.大氣環境監測數據湖數據資源目錄關鍵技術研究［D］.大慶：東北石油大學，2023.

［39］" Latreche O，Boukraa D.Self-service，on-demand creation of OLAP cubes over big data：a metadata-driven approach［C］//2020 IEEE International Conference on Big Data.Atlanta，America，2020：2907-2914.

［40］" Huang Fang.Managing data lakes in big data era：what's a data lake and why has it became popular in data management ecosystem［C］//IEEE International Conference on Cyber Technology in Automation，Control，and Intelligent Systems.Piscataway，NJ：IEEE Press，2015：820-824.

［41］" Brackenbury W，Liu R，Mondal M，et al.Draining the data swamp：a similarity-based approach［C］//Proceedings of the Workshop on Human-In-the-Loop Data Analytics.New York：ACM Press，2018：1-7.

［42］" Alserafi A，Abello A，Romero O，et al.Keeping the data lake in form：proximity mining for pre-filtering schema matching［J］.ACM Transactions on Information Systems，2020，38 （3）：1-30.

［43］" Stach C，Br？覿cker J，Eichler R，et al.Demand-driven data provisioning in data lakes［C］//The 23rd International Conference on Information Integration and Web Intelligence.New York：ACM Press，2021：187-198.

［44］" Topchyan A R.Enabling data driven projects for a modern enterprise［J］.Proceedings of the Institute for System Programming of RAS，2016，28（3）：209-230.

［45］" Zagan E，Danubianu M.From data warehouse to a new trend in data architectures-data lake［J］.IJCSNS International Journal of Computer Science and Network Security，2019，19（3）：30-35.

［46］" Nogueira I D，Romdhane M，Darmont J.Modeling data lake metadata with a data vault［C］//Proceedings of the 22nd International Database Engineering amp; Applications Symposium.New York：ACM Press，2018：253-261.

［47］" Kruseman G.A flexible，extensible，machine-readable，human-intelligible，and ontology-agnostic metadata schema（oims）［J］.Frontiers in Sustainable Food Systems，2022，6：767863.

作者簡介：張貴香，女，中國人民大學信息資源管理學院博士研究生；賈君枝，女，中國人民大學信息資源管理學院教授，博士生導師；薛鵬珍，女，中國人民大學信息資源管理學院博士研究生。