現代資料架構支援數量和種類不斷增加的業務用例。產品創建、客製化客戶體驗、詐欺偵測、法規遵循和資料貨幣化都是一些例子。
為了實現此類用例，資料驅動型企業需要現代解決方案來存取、管理和處理資料。其中之一是資料湖，這是一個用於儲存、處理和保護大量結構化、半結構化和非結構化資料的集中儲存庫。
這裡要考慮的關鍵問題之一是元
資料以及如何管理它。由於資料湖不是資料庫，因此它提供的元資料量遠低於從資料庫獲得的元資料量。
這只是團隊在管理資料湖中的元資料時遇到的幾個挑戰之一。
資料湖中的元資料管理：為什麼如此棘手？
元資料為資料集的內容 提供上下文，是使資料在應用程式中易於理解和存取的關鍵組成部分。
然而，由於原始資料經常被
輸入資料湖，許多組織未能納入驗證資料或對其應用組織資料標準所需的程序。由於缺乏有效的元資料管理，資料湖中的資料對分析的幫助不大。
為了有效管理資料湖中的數據，您需要一個用於記錄技術、操作和業務數據的框架，以便您可以識別和利用多個用例的數據。
資料湖管理平台是自動化元
資料管理的一種方法。此類平台可以在執行轉換時自動收集到達的元數據，並將其與特定含義（例如企業業務詞典中的含義）相關聯，從而確保所有用戶根據一組規則和概念一致地讀取相同的數據——並且它可以隨著您的資料變化而自動更新。
可靠的元資料管理功能簡化並自動
化了日常資料管理。糟糕的元資料架構可能會阻止資料湖從具有有限資料集和一個用例的分析沙箱或概念驗證 (POC) 發展為具有許多用戶和多個用例的生產就緒型企業級資料平台 – 即，現代數據架構。它還會極大地影響使用資料 土耳其 WhatsApp 號碼數據 湖中儲存的資料集進行任何資料分析的效能。
讓我們深入探討管理資料湖中的元資料的挑戰，並看看幫助團隊解決問題的潛在方法。
管理資料湖中元資料的 4 個挑戰
1. 數據孤島化
在許多組織中，團隊將資料保存在單獨的儲存桶中，並且這些儲存桶根據資料的路徑進行分區。這同樣適用於元資料。
團隊通常缺乏能夠有效使用元資料的檔案系統功能或層次結構。將資料保存在不對齊的單獨孤島中會對組織利用元資料來支援其最重要用例的能力產生嚴重影響。
2. 不變性與可變性雖然資料湖是不
可變的但資料本身卻不是。數據的本質是瞬態的，因為它不斷變化。更改資料的範例有：
回填操作數據，
由於機器學習模型或其他演算法的改進而重新處理數據，
或者只是描述世界的數據，例如感測器數據，這些數據會隨著世界的變化而變化。
考慮一張地圖或一組患 在結果畫面上可以套用多個篩選 者數據隨著時間的推移——它們必然會發生變化。
需要元資料來管理資料集隨時間的變化的追蹤以及資料的不同版本以允許並發。為此，團隊需要一層元數據，將目前使用的數據集與正在累積的變更隔離開來，並以原子操作將變更公開給消費者。
3. 版本控制由於資料集隨著時間的
推移而變化，並且組織管理大量資料集，因此需要元資料來管理多個資料集隨時間的變化（如不變性部分中所述），而是維護所有資料之間的一致性在資料湖中攝取和導出的集合。
版本是資料湖中高效能元資料管理的基本要求。資料版本控制可確保一致性，並為完全可重複性和稽核打開大門。
如果沒有資料版本控制，就很難找到特定分析中涉及的資料集（如分析時的資料集）。
4. 需要抽象層
資料湖是透過使用物件儲存來實現的。物件儲存管理文件，甚至不將它們視為文件，而是將其視為物件。資料湖資料的使用者通常是使用 SQL 的資料工程師，他們習慣於查詢資料庫中的表。
我們如何在資料湖中為他們提 清潔新聞 供良好的服務？在管理可以以表格形式呈現的資料時，團隊需要一個抽象，讓他們像存取資料庫中的表格一樣存取一組文件。將一組檔案轉換成一個表格是對元資料的處理。
解決資料湖中資料管理挑戰的 4 種方法
1. 元存儲
元資料包括有關資料集結構、資料類型的技術元資料以及有關每列中的值的統計資料。您需要這些資料來組裝和執行 SQL 語句等分析查詢。
在討論資料湖時，技術元資料尤其重要。這是因為，與包含內建技術元資料的 RDBMS 等整合資料庫儲存庫不同，技術元資料是資料湖中的獨特元件，團隊必須刻意設定和維護。使用元儲存可以幫助解決上面列出的結構化資料的第一個和第四個挑戰。
使用最廣泛的元儲存介面是Hive Metastore，並且廣泛的大數據查詢和處理引擎和函式庫都支援它。 Hive Metastore 中的資料與資料湖中的資料一樣重要，必須同樣對待。這意味著其元資料必須保持永久、高度可訪問，並包含在任何災難復原配置中。