一、元數據管理平臺介紹

背景介紹

1. 貨拉拉大數據體系

首先來介紹一下貨拉拉大數據體系的整體架構，這一體系自底向上構建，其中基礎層與接入層，這兩層主要承載著最基礎的存儲能力、計算能力以及數據接入功能。向上是平臺和數倉層，這里集成了數據研發平臺、數據治理平臺，以及數據資產管理。再向上是服務層，這層面向多樣化服務場景，開發的大數據一系列應用，涵蓋數據應用支撐、各類服務工具、數據服務工具，以及數據智能所需的支撐工具。最上層是應用層，聚集了輔助決策類應用和賦能業務類應用，它們直接服務于公司的決策制定與業務優化。整個大數據體系中呈現出一種相互依存、相互支持的緊密關系。

本次分享的重點是元數據管理平臺，該平臺作為大數據體系的元數據中心，其核心職責涵蓋了元數據管理、數據資產管理以及成本治理三大方面。

2. 元數據管理平臺

當大數據體系發展到一定規模時，必然會遇到一系列挑戰，例如：所需數據究竟在何處？如何清晰梳理這些數據之間的上下游關系？數據治理靠什么來驅動？以及數據資產是如何管理的？為解決這些難題，元數據管理平臺應運而生。接下來將重點圍繞這四個核心議題，介紹貨拉拉針對這些問題所制定的解決方案及實踐經驗。通過這些內容，您將更加全面地了解我們如何利用元數據管理平臺來保證數據的可尋、可溯、可治，進而提升數據的價值。

3. 元數據管理平臺建設過程

元數據管理平臺的發展軌跡緊密貼合業務需求的演進，其發展歷程可以劃分為三個階段。

早期（21 年之前）：在這一時期，業務場景相對簡單，數據資產的規模也不大，主要依賴 Hive ETL 工具進行處理。因此，對于元數據的需求也停留在基礎層面，簡單的查詢功能便足以滿足業務需求。

發展階段（21 年至 22 年）：隨著業務的迅猛增長，數據表和任務的資產規模急劇擴張，用戶對“找數”和“找關系”的需求日益凸顯。為應對這一變化，我們構建了元數據管理系統，支持通過資產名稱和描述信息進行搜索，還支持了數據血緣能力。

成熟階段（22 年之后）：在這一階段，大數據領域的開源組件與自研平臺紛紛登場，元數據管理平臺需要承接更多種類的資產類型，并應對更為復雜且時效性要求更高的數據血緣鏈路。為此，我們升級了元數據管理平臺，實現了字段級別的實時血緣追蹤能力，以滿足上述需求。同時，面對存儲與計算資源的緊張，成本治理體系也提上日程。此外，隨著資產量的劇增和研發團隊的擴大，找數場景也越來越復雜，我們結合大模型將檢索能力演進為 AI 智能檢索，提供了對話式的找數體驗。

發展到現階段，元數據管理平臺的能力趨近于完善。

4. 元數據管理平臺系統架構

元數據管理平臺的系統架構如上圖所示，其核心由采集層、服務層、存儲層以及平臺數倉層構成。在此架構的兩側，分別對接了多元化的接入方和豐富的應用層。

接入方：涵蓋了大數據生態中的基礎設施、各類平臺工具以及業務系統，它們是元數據管理平臺數據來源的基石。

采集層：作為架構中的關鍵一環，采集層負責適配并對接生產方，采集各類元數據。

服務層：該層提供了查詢與分析的服務。

平臺數倉層：平臺數倉層專注于加工與成本治理相關的數據。通過對底層計算與存儲資源的消耗數據的深度挖掘與分析，為企業的成本控制和治理決策提供有力支持。

應用層：最終，這一架構支撐起了一系列應用場景，包括但不限于找數、找關系、資產管理等。這些應用充分利用了元數據管理平臺的能力，為用戶提供便捷、高效的數據服務體驗。

二、元數據管理平臺實踐

1. 數據血緣

（1）數據鏈路介紹

數據血緣作為元數據基礎設施中的核心要素，其實現與演進過程至關重要。下面，我將詳細闡述我們是如何構建和不斷完善這一關鍵環節的。

首先，從宏觀視角來看，我們的數據整體鏈路清晰地劃分為采集、存儲、計算以及應用四大層面。這一流程始于數據采集階段，我們采集來自日志、埋點以及訂單業務等多個維度的數據，并將這些數據匯聚至大數據平臺。

隨后，這些數據被妥善存儲在大數據平臺中，為后續的處理與分析奠定堅實基礎。然后通過實時和離線鏈路分別構建的數倉體系，對數據進行加工處理，加工好的數據提供給各類應用服務進行使用，比如各類報表、看板、用戶畫像等。這些應用依托高質量的數據支持，為企業決策提供了有力依據。

在這個過程中，數據血緣鏈路貫穿始終，它詳盡地記錄了上游數據從采集、存儲、加工到最終應用于出口的每一個環節。這種全面的血緣追蹤能力不僅有助于我們更好地理解數據的來龍去脈，還能在數據出現問題時迅速定位問題源頭，從而保障數據的質量與準確性。

（2）架構演進

在早期（1.0 版本），我們的業務場景較為簡單，血緣關系的需求也相對基礎。因此我們構建了一個基礎的血緣追蹤系統。

數據源與血緣追蹤：

• 數據源：血緣數據主要來源于研發平臺和指標報表等系統。
• 執行引擎：數據通過 Hive、Spark 等大數據處理引擎進行執行。
• 血緣捕獲：通過 hook 機制，我們在 SQL 執行過程中捕獲并解析輸入輸出表的信息，隨后將這些血緣信息推送到下游系統供其使用。
• 非 SQL 鏈路處理：針對 MySQL 到 Hive、Hive 到下游終端等非 SQL 數據鏈路，我們預先定義了一套標準的格式，要求各業務系統按照此格式將他們的血緣關系推送到離線血緣數據倉庫中。

數據處理與存儲：

• 數據存儲：采集到的血緣數據通過定時調度進行解析，并存儲至 MySQL 數據庫中。
• 血緣更新：我們以產生血緣的調度任務為單位進行血緣的更新。當新版本血緣生成時，舊版本血緣將被替換。

隨著血緣能力在研發場景中的價值逐漸被認可，我們對系統提出了更高的要求，特別是血緣的時效性和字段級血緣的支持。為此，我們在 1.0 版本的基礎上對系統架構進行了優化和升級。

實時血緣解析：

• 增量更新機制：我們新增了一個實時血緣解析模塊，該模塊替代了原有的定時更新機制，實現了近實時的增量更新。
• 調度任務變更上報：由于大多數血緣信息是由調度任務產生的，我們引入了調度任務變更上報機制。當任務發生下線或 SQL 更新時，這些信息能夠及時反映到血緣數據中，提高了血緣更新的時效性。

存儲升級：

• 圖數據庫 Neo4J：為了支撐更大量級的字段級血緣查詢，我們將存儲從 MySQL 升級為 Neo4J 圖數據庫。Neo4J 的強大性能支持了 10 層以上的節點查詢，這對許多分析類場景至關重要。

通過上述升級，我們的血緣追蹤系統不僅提升了數據的時效性和準確性，還大大增強了處理復雜血緣關系的能力，為研發場景提供了更為強大的支持。

（3）存儲模型

在業界主要有兩種設計思路。第一種方案是將任務作為節點，通過這些節點來關聯不同表之間的關系。這種方式在涉及以任務為切入點進行血緣查詢時更加靈活。然而，當查詢表之間的關聯，尤其是需要進行多層表關系查詢時，這種方案可能會增加查詢和維護的復雜度，尤其是在節點數量較多的情況下。

相比之下，第二種方案將任務作為邊的屬性，而表和表之間則建立直接的關聯。這種設計在查詢和維護方面更為直觀和簡便。考慮到我們當前的實際業務需求中，暫時沒有需要通過任務作為切入點進行查詢的場景，我們決定采納第二種方案作為實現方式。這樣做不僅簡化了查詢路徑，還優化了系統的維護效率，更貼合我們當前的業務需求。

（4）解析

接下來是血緣的解析，目前我們以 Hive 作為主引擎，因此接下來主要講解 Hive 類的血緣解析方式。

在我們開發平臺中，Hive 任務形式多樣，包括純 SQL、Python 程序及腳本類任務，這增加了解析的復雜性。

當前，業界主要討論兩種解析方法：一是通過 Hive hook 實現，即在任務執行時從 Hive hook 的上下文中捕獲輸入輸出信息，這種方式無需關心 SQL 的提交方式，但可能存在滯后，因為血緣的更新僅在任務執行后才能生效；另一種是靜態 SQL 解析，一般利用開源的語法解析工具在任務提交前進行，雖能即時反映 SQL 變更，但對 Python 或腳本任務的 SQL 提取較為復雜。

因此綜合考慮背景和實現復雜度，我們選擇了 Hive hook 作為實現方式。

然而，這一過程中也面臨了幾個挑戰：

①血緣與任務關系打通：由于 Hive hook 本身無法直接獲取任務信息，我們推動研發平臺進行了改造，要求在提交 SQL 時將任務信息一并放入 hiveConf 中，以便在 hook 中能夠關聯這些信息并傳遞給下游系統使用。

②任務更新與血緣同步：為確保血緣信息的時效性，我們采用了研發平臺主動上報任務下線和更新的機制。這樣，當下線或更新任務時，相應的血緣信息也會得到及時更新。

③臨時表處理：對于包含臨時表的 SQL，如 CREATE TEMPORARY TABLE T1 AS SELECT ... FROM a; INSERT INTO b SELECT * FROM T1;，直接解析會產生不必要的臨時節點和關系，影響后續使用。因此，我們在實現中引入了一個緩存機制，構建血緣關系樹，并在新血緣到來時進行合并判斷。只有當臨時表的使用能夠合并為正式表之間的直接血緣關系時（如 a 寫 b），才會進行下一步的對比、更新和入庫操作。

通過這些措施，我們成功實現了基于 Hive hook 的血緣解析，既滿足了業務需求，又有效解決了實施過程中遇到的問題。

（5）應用場景

在數據應用方面，我們聚焦于三個核心場景：數據開發效率提升、數倉開發優化、以及數據治理與安全保障。

這里列舉了大數據凌晨值班時，鏈路出問題，需要降級，數據血緣能力在里面起到的一些作用。

在大數據值班的場景中，偶爾會遇到鏈路故障，導致某些重要數據表當日的數據無法按時產出。此時，為了保障數據供應的連續性，可能需要進行降級處理，比如使用前一日（T+2）的數據作為替代。然而，這一決策并非輕率之舉，它要求迅速評估降級操作對下游數據使用方的具體影響范圍，并據此做出及時通知。

在這一緊急響應過程中，字段級的數據血緣能力顯得尤為重要。它能夠直接追溯到受影響的最下游終端，特別是那些標記為 P0 或 P1 優先級的數據出口應用，幫助值班人員快速、準確地評估影響面。這種能力不僅提升了決策的效率和準確性，還有效防止了影響范圍的擴大或因降級不當而引發的潛在故障，乃至經濟損失。

此外，為了加速信息傳遞，我們還提供了一鍵拉群功能，使得值班人員能夠迅速將相關團隊和人員拉入緊急溝通群組，實現問題的即時通報與協同解決。

2. AI 智能檢索

在深入探討了數據血緣的重要性之后，接下來將介紹我們的元數據檢索系統的演進過程。起初，我們采用的是傳統的基于關鍵字的檢索方式，這種方式以其快速響應和直接返回匹配結果集列表的特點，滿足了基本的檢索需求。然而，隨著數據使用場景的日益多樣化，用戶對檢索功能的需求也變得更加復雜和精細。

具體而言，傳統的關鍵字檢索在面對多關鍵字組合查詢、查詢數據表含義、詢問數據口徑以及業務咨詢等場景時，顯得力不從心。這些需求要求檢索系統能夠更深層次地理解用戶的查詢意圖，并返回更加精準和全面的結果。

為了應對這些挑戰，我們緊跟技術發展的步伐，特別是在 AIGC（人工智能生成內容）技術蓬勃發展的背景下，我們探索性地將大模型的自然語言處理能力引入到了元數據檢索的實際生產場景中。這一創新舉措旨在通過大模型對自然語言的深刻理解，來更好地捕捉用戶的查詢意圖，從而提供更加智能化、個性化的檢索服務，以滿足用戶多樣化的需求。

為了應對大模型在實際企業應用中面臨的本地知識庫匱乏及更新時效性問題，我們選擇了業界廣泛采用的 RAG（Retrieval-Augmented Generation）方案來落地元數據檢索場景。

RAG 方案的核心在于，它不僅僅依賴于大模型自身訓練時獲取的靜態知識（這通常主要來源于互聯網上的公開信息，且難以實時更新），而是通過引入外部數據源的檢索機制，為大模型提供實時的上下文信息。這一機制允許大模型在回答企業專業領域的問題時，能夠結合最新的、特定于企業的數據，從而大大提升了答案的準確性和時效性。

具體來說，RAG 方案首先會利用檢索技術從外部數據源中檢索與用戶查詢相關的上下文信息，然后將這些信息與用戶的原始查詢一同輸入到大模型中。大模型在接收到這些信息后，會綜合考慮檢索到的上下文內容和自身的知識庫，生成更加精準、全面的回答。這種方式不僅解決了大模型在本地知識庫上的局限性，還避免了因直接暴露企業內部數據給大模型而可能引發的數據安全問題。

因此，通過采用 RAG 方案，我們能夠更好地將大模型的自然語言處理能力應用于企業的實際生產場景中，為用戶提供更加智能、高效的元數據檢索服務。

在 RAG 方案的實現中，我們的中間服務層（rag）聚焦于四大核心流程：數據提取、檢索、索引與生成。首先，業務知識被接入并分塊處理，隨后灌入向量數據庫中，以便進行高效的向量相似度檢索。檢索結果隨后被送入大模型，結合定制的 prompt 生成最終響應。模型層則靈活適配多種模型，支持找數、口徑查詢、業務咨詢等多樣化場景。

針對庫表源數據的檢索，我們采用的切片策略，是以單個字段為單位進行切割。這種方式確保每個字段獨立成塊，并在塊中保留必要的表信息，優化向量數據庫中的存儲與檢索效率。相較于整表切割，字段級切片有效避免了檢索結果超出大模型處理 token 限制的問題。

問答流程簡述如下：用戶問題首先經過增強處理，并轉化為向量化表示；隨后通過檢索系統獲取相關結果，并進行智能重排序；優化后的檢索結果結合 prompt 工程進行精細組裝，最終由大模型生成準確答案。這一過程確保了問答系統的高效、準確與靈活性。

在實現過程中，我們遭遇了檢索漏召、大模型表現不穩定、響應速度慢及測評難題等挑戰。針對這些問題，我們采取了以下優化措施：

（1）檢索漏召問題

• 問題增強：在向量化檢索前，對復雜問題進行拆分或語義增強，以捕捉更多相關信息。例如，將“訂單寬表中，這兩個字段，哪個字段表示司機實際收入”這個問題拆分為多個子問題分別檢索，從而提高信息覆蓋率和回答準確性。
• 重排序優化：通過引入輕量級模型對檢索結果進行重排序，篩選出與用戶問題匹配度最高的前 N 條記錄（如 TOP10）再送入大模型處理，以減少大模型處理時間，同時避免信息過載。

（2）測評問題

建立更完善的測評體系，包括自動化測試和人工審核，確保系統性能與用戶體驗持續提升。

此外，我們認識到最終表現效果還受到底層知識完備率的影響，因此加強與數倉等部門的合作，共同構建和完善專業知識庫，為系統提供堅實的數據支撐。

這是我們上線的一版庫表智能檢索產品的示意圖。用戶提出查詢需求，尋找特定字段信息。系統首先利用大模型進行智能總結回答，直接呈現給用戶一個概括性的結果。隨后，系統進一步挖掘并展示與該字段相匹配或相關的庫表信息，以滿足用戶的深入查詢需求。

3. 支撐成本治理場景

在探討貨拉大數據成本治理面臨的挑戰時，我們注意到，未經有效治理前，成本與單均成本均呈現快速上漲趨勢，且缺乏有效管控手段。具體而言，存在三大問題：一是成本分配不明，難以追蹤至具體資產及責任人；二是成本使用效率存疑，是否存在浪費現象難以評估；三是成本水位健康狀況模糊，缺乏清晰判斷標準。

為應對上述挑戰，我們構建了大數據成本治理體系，該體系以元數據為核心驅動力，通過以下策略實現持續降本：

• 資產可視化度量：利用元數據構建資產全景圖，實現成本在資產層面的可視化展示，清晰呈現成本分布與流向。
• 輔助治理能力：針對存儲和計算層面的資源浪費，提供一系列技術能力，幫助減少資源使用。
• 健康度導向的成本運營：建立成本健康度評估體系，定期監測成本水位，確保成本使用合理且高效，同時指導成本優化策略的制定與實施。

數據資產度量體系旨在量化大數據資產的消耗與成本，并提供強大的查詢與統計分析功能。以下是該體系的框架概述：

我們聚焦于任務產出的核心資產，如表、報表、看板指標等，從底層存儲與計算引擎精準采集其消耗數據。這些數據隨后通過平臺數倉的精細加工，轉化為按個人及部門維度劃分的成本數據，使用戶能直觀了解各自名下資產的消耗情況。

此外，系統還能自動生成部門級別的成本賬單，為資源優化、任務調度優化、存儲治理及成本運營等關鍵場景提供堅實的數據支撐，助力企業實現更加精準與高效的成本管理。

第二部分聚焦于輔助治理能力，特別針對貨拉拉大數據中占據主導地位的離線存儲成本。鑒于大數據環境中普遍存在的“冰數據”現象，即大量數據雖占用資源卻鮮少被訪問，我們致力于優化存儲效率。

首先，我們面對的挑戰在于如何界定冷熱數據，因業界標準不一且難以直接套用于我司業務。為此，我們借鑒了美團的數據分類方法（基于 90 天內訪問頻次），并結合云廠商的歸檔存儲費用模型，進行了深入的分析與調整。

通過分析最近 90 天內的數據訪問次數與歸檔收益的關系，我們發現訪問次數為 0 的數據占比最高且歸檔收益顯著，而訪問次數極少的數據歸檔收益則相對較低。基于這一發現，我們制定了數據溫度的打標策略，將數據明確劃分為不同熱度等級。

針對不同溫度的數據，實施差異化的治理措施：對于冰數據（長期未訪問的數據），建議用戶優先刪除以釋放存儲資源；對于冷數據（偶爾被訪問的數據），則推薦用戶進行歸檔處理，以平衡存儲成本與數據可訪問性。這一策略旨在最大化存儲效益，減少不必要的資源浪費。

理論上，數據隨時間推移會逐漸失去活躍性，即“冷卻”。為此，我們為數據表設定了生命周期與歸檔周期兩大屬性，以實現對超出特定存活期限數據的自動化滾動清理與歸檔。在圖示中，該表的生命周期被設定為180 天，歸檔周期為 90 天。這意味著，超過 180 天的數據將被系統刪除以釋放資源，而介于 90 天至 180 天之間的數據則會被自動歸檔至更低成本的存儲介質中。

前述技術輔助能力為業務成本治理提供了有力支持，但要激發業務團隊的主動參與，還需構建一套完善的成本運營能力。該體系能夠自動偵測數據資產在計算與存儲層面的成本浪費問題，生成治理點并即時通知相關用戶，促其采取主動治理措施。治理點涵蓋未配置生命周期的存儲與計算資源、未歸檔的冗余數據、長期未訪問的數據或任務等。

結合成本消耗數據，我們設計了一套健康分模型，以量化評估治理效果。此模型不僅為個人及部門提供成本健康狀態的直觀展示，還輔以獎懲機制與紅黑榜排名，激勵用戶持續優化存儲與計算成本，共同維護成本水位處于健康狀態。圖示展示了當前資產健康分的評估結果，涵蓋個人與部門兩個維度，以及治理效果的排行榜，確保每位用戶及其領導層都能及時獲得反饋，共同推動成本治理工作的深入進行。

經過一系列存儲優化策略的實施，包括生命周期管理、數據歸檔、文件壓縮、格式算法升級以及深度專項治理等，我們取得了顯著的成效。上圖展示了存儲成本的優化成果：在優化前，存儲成本呈現快速線性增長趨勢；而優化后，存儲成本在八個月內實現了零增長，并持續走低，累計節省了高達 54% 的存儲成本，成效頗為可觀。

4. 數據安全場景

元數據服務離不開分級打標，分級主要是法律法規的要求，二是權限控制的需要，三是方便管理與審計，這方面的工作會借助安全定級系統，由其負責對元數據進行分類定級打標，打標完成后會針對 C4 以上的個人敏感信息進行信息加密并打標以實現敏感的管控，降低數據泄露的風險。

場景支撐：元數據作為數據管理平臺的底層基座，支撐庫表安全和數據下載兩大安全應用場景。

• 庫表安全場景：依賴自研的庫表權限系統可進行權限的申請與查詢，實現有效期的管理；后臺任務方面使用的底層策略是 Rager，鑒權服務方面已經實現劣跡鑒權的應用。
• 數據下載場景：依托自研的大數據研發平臺，可以進行 SQL 查詢與數據下載，同時 ETL 的離線任務也在此平臺實現。

數據的分類分級標準與規范

數據的分類分級結合了公司的業務場景，主要從數據的敏感性與價值性出發，同時參考了金融數據安全分類分級標準《金融數據安全數據安全分級指南》，將貨拉拉的數據安全等級分為四大等級：

• 公開數據（C1）：已通過正規渠道正式對外發布的數據，不會對公司造成影響的數據；這部分數據基本無價值，可外部公開
• 限制數據（C2）：不適合對外公開，但是對內部人員訪問基本無限制的數據，一旦發生泄露，不會對數據主體造成直接損害；這部分數據有低價值，公司內部可基本無限制訪問
• 商業秘密（C3）：公司專有或公司保密的，一旦發生泄露，將顯著影響相關業務的開展，對數據主體造成直接或者間接損害；這部分數據有中價值間接利用，公司內部限于相關人員按規使用
• 核心秘密（C4）：具有最高安全屬性要求，一旦發生泄露，可能導致公司法律或商業上造成重大影響和損失；這部分數據最重要關乎用戶敏感數據，高價值可直接利用，限于公司重要部門特定人員授權使用

庫表的分類分級

庫表的分類分級分為增量數據與存量數據，二者類別采用不同的分級達標方案；

• 增量數據：針對單個庫表分級達標，用戶可以通過元數據服務進行建表，建表后通過審批，審批后進行元數據更新，這一批更新的元數據會異步發布到 Kafka，通過定級系統進行消費數據，并進行算法打標，打標主要依據字段名稱以及字段備注信息進行打標，打標完成后將此批數據返回給 Kafka，然后在元數據服務系統進行 Kafka 服務，以進行元數據更新；
• 存量數據：設置定時任務每天進行全表掃描，后發送給 Kafka，經定級系統進行消費數據，并進行算法打標，打標后返回 Kafka，并在元數據服務系統進行 Kafka 服務，以更新元數據。

針對算法打標的誤判，也支持人工修正，主要由有安全經驗的安全人員來進行判斷并修正。

分級分類安全場景

分類分級在庫表的具體應用場景，貨拉拉采用按照人員類別以及入職天數開放不同權限的數據安全策略。

針對以下的情形采用不同的安全權限策略：

• 入職多少天內不能申請任何數據；
• 入職不滿多少天，嚴格限制了申請 C3 及以上等級的數據，只能申請 C1、C2 等級的數據；
• 外包、實習生、兼職類別人員只能申請 C1、C2 的數據，不能申請 C3 及以上數據權限。

限制人員若需要申請相應庫表權限，需通過郵件申請白名單。在具體的庫表審批方面，會針對 C3、C4 敏感等級數據自動進行標紅處理，提醒審批人員對此部分數據的權限進行更加嚴格的審批，確保權限不會被錯誤授權。

加密字段的打標方案

加密字段打標方案主要依賴于元數據服務和數據研發平臺。

通過元數據服務會設置定時任務定時掃描敏感數據，像掃描到 C3、C4 數據，會進行 select 列 from 表 limit 多少條數據后執行 SQL 查詢，返回獲取這些樣例數據，然后根據數據的規則進行打標，具體的達標規則會對數據進行長度檢測和字符規則檢測。

通過自研的數據研發平臺，執行 SQL 查詢，后臺解析此 SQL 查詢包含哪些表、哪一些字段，后向元數據服務申請調用得到相關的元數據，后通過數據研發平臺查詢此部分數據的 Hive 結果。若需要下載，會根據元數據的加密以及敏感等級走不同的審批流。

具體的審批策略針對敏感數據和非敏感數據采用不同的方式：

• 敏感數據：針對 C3、C4 級的敏感數據使用，需要上級+大數據或安全部門人員進行審批；
• 非敏感數據：非敏感數據單日小于等于多少條是不需審批的；單日大于多少條數據，才采用上級+部門負責人審批的方式。

加密打標應用場景

加密打標的應用場景：數據下載。

數據下載需走審批程序，針對 C3、C4 敏感數據的下載，會有敏感數據下載標識進行提醒，數據下載詳情里會有解析到的敏感字段，如表名、字段名、注釋等，以供給審批人員參考。針對一些特別敏感的個人信息而且量多的情形，此時安全人員會找申請人員進行核對，以確保數據可以下載。

數據安全更多的應用場景：

• 安全等級打標傳染：通過血緣的傳染能力給它的下游數據進行打標，提高庫表分級的準確率；
• 數據加密治理：對存量敏感數據漏打標情形進行識別，如個人信息，并進行批量打標、加密，以保障數據安全；
• 數據災備：通過元數據打標，實現數據自動災備。

三、未來規劃

未來的規劃與建設重點包括更高效的檢索服務、數據血緣的標準化以及降本增效三個方面。

• 更高效的檢索服務：進一步優化和探索 AI 大模型在數據檢索領域的應用，更好的識別用戶意圖并更好的回答。
• 數據血緣標準化：數據血緣建立標準的 SDK，減少重復造輪子；提高數據血緣質量度量的準確率，以便于數據分析。
• 自動化成本治理：持續降本，盡可能多的步驟實現自動化處理，減少一些不必要的成本。