一、元數(shù)據(jù)管理平臺(tái)介紹

背景介紹

1. 貨拉拉大數(shù)據(jù)體系

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

本次分享的重點(diǎn)是元數(shù)據(jù)管理平臺(tái)，該平臺(tái)作為大數(shù)據(jù)體系的元數(shù)據(jù)中心，其核心職責(zé)涵蓋了元數(shù)據(jù)管理、數(shù)據(jù)資產(chǎn)管理以及成本治理三大方面。

2. 元數(shù)據(jù)管理平臺(tái)

當(dāng)大數(shù)據(jù)體系發(fā)展到一定規(guī)模時(shí)，必然會(huì)遇到一系列挑戰(zhàn)，例如：所需數(shù)據(jù)究竟在何處？如何清晰梳理這些數(shù)據(jù)之間的上下游關(guān)系？數(shù)據(jù)治理靠什么來驅(qū)動(dòng)？以及數(shù)據(jù)資產(chǎn)是如何管理的？為解決這些難題，元數(shù)據(jù)管理平臺(tái)應(yīng)運(yùn)而生。接下來將重點(diǎn)圍繞這四個(gè)核心議題，介紹貨拉拉針對(duì)這些問題所制定的解決方案及實(shí)踐經(jīng)驗(yàn)。通過這些內(nèi)容，您將更加全面地了解我們?nèi)绾卫迷獢?shù)據(jù)管理平臺(tái)來保證數(shù)據(jù)的可尋、可溯、可治，進(jìn)而提升數(shù)據(jù)的價(jià)值。

3. 元數(shù)據(jù)管理平臺(tái)建設(shè)過程

元數(shù)據(jù)管理平臺(tái)的發(fā)展軌跡緊密貼合業(yè)務(wù)需求的演進(jìn)，其發(fā)展歷程可以劃分為三個(gè)階段。

早期（21 年之前）：在這一時(shí)期，業(yè)務(wù)場(chǎng)景相對(duì)簡(jiǎn)單，數(shù)據(jù)資產(chǎn)的規(guī)模也不大，主要依賴 Hive ETL 工具進(jìn)行處理。因此，對(duì)于元數(shù)據(jù)的需求也停留在基礎(chǔ)層面，簡(jiǎn)單的查詢功能便足以滿足業(yè)務(wù)需求。

發(fā)展階段（21 年至 22 年）：隨著業(yè)務(wù)的迅猛增長(zhǎng)，數(shù)據(jù)表和任務(wù)的資產(chǎn)規(guī)模急劇擴(kuò)張，用戶對(duì)“找數(shù)”和“找關(guān)系”的需求日益凸顯。為應(yīng)對(duì)這一變化，我們構(gòu)建了元數(shù)據(jù)管理系統(tǒng)，支持通過資產(chǎn)名稱和描述信息進(jìn)行搜索，還支持了數(shù)據(jù)血緣能力。

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

發(fā)展到現(xiàn)階段，元數(shù)據(jù)管理平臺(tái)的能力趨近于完善。

4. 元數(shù)據(jù)管理平臺(tái)系統(tǒng)架構(gòu)

元數(shù)據(jù)管理平臺(tái)的系統(tǒng)架構(gòu)如上圖所示，其核心由采集層、服務(wù)層、存儲(chǔ)層以及平臺(tái)數(shù)倉層構(gòu)成。在此架構(gòu)的兩側(cè)，分別對(duì)接了多元化的接入方和豐富的應(yīng)用層。

接入方：涵蓋了大數(shù)據(jù)生態(tài)中的基礎(chǔ)設(shè)施、各類平臺(tái)工具以及業(yè)務(wù)系統(tǒng)，它們是元數(shù)據(jù)管理平臺(tái)數(shù)據(jù)來源的基石。

采集層：作為架構(gòu)中的關(guān)鍵一環(huán)，采集層負(fù)責(zé)適配并對(duì)接生產(chǎn)方，采集各類元數(shù)據(jù)。

服務(wù)層：該層提供了查詢與分析的服務(wù)。

平臺(tái)數(shù)倉層：平臺(tái)數(shù)倉層專注于加工與成本治理相關(guān)的數(shù)據(jù)。通過對(duì)底層計(jì)算與存儲(chǔ)資源的消耗數(shù)據(jù)的深度挖掘與分析，為企業(yè)的成本控制和治理決策提供有力支持。

應(yīng)用層：最終，這一架構(gòu)支撐起了一系列應(yīng)用場(chǎng)景，包括但不限于找數(shù)、找關(guān)系、資產(chǎn)管理等。這些應(yīng)用充分利用了元數(shù)據(jù)管理平臺(tái)的能力，為用戶提供便捷、高效的數(shù)據(jù)服務(wù)體驗(yàn)。

二、元數(shù)據(jù)管理平臺(tái)實(shí)踐

1. 數(shù)據(jù)血緣

（1）數(shù)據(jù)鏈路介紹

數(shù)據(jù)血緣作為元數(shù)據(jù)基礎(chǔ)設(shè)施中的核心要素，其實(shí)現(xiàn)與演進(jìn)過程至關(guān)重要。下面，我將詳細(xì)闡述我們是如何構(gòu)建和不斷完善這一關(guān)鍵環(huán)節(jié)的。

首先，從宏觀視角來看，我們的數(shù)據(jù)整體鏈路清晰地劃分為采集、存儲(chǔ)、計(jì)算以及應(yīng)用四大層面。這一流程始于數(shù)據(jù)采集階段，我們采集來自日志、埋點(diǎn)以及訂單業(yè)務(wù)等多個(gè)維度的數(shù)據(jù)，并將這些數(shù)據(jù)匯聚至大數(shù)據(jù)平臺(tái)。

隨后，這些數(shù)據(jù)被妥善存儲(chǔ)在大數(shù)據(jù)平臺(tái)中，為后續(xù)的處理與分析奠定堅(jiān)實(shí)基礎(chǔ)。然后通過實(shí)時(shí)和離線鏈路分別構(gòu)建的數(shù)倉體系，對(duì)數(shù)據(jù)進(jìn)行加工處理，加工好的數(shù)據(jù)提供給各類應(yīng)用服務(wù)進(jìn)行使用，比如各類報(bào)表、看板、用戶畫像等。這些應(yīng)用依托高質(zhì)量的數(shù)據(jù)支持，為企業(yè)決策提供了有力依據(jù)。

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

（2）架構(gòu)演進(jìn)

在早期（1.0 版本），我們的業(yè)務(wù)場(chǎng)景較為簡(jiǎn)單，血緣關(guān)系的需求也相對(duì)基礎(chǔ)。因此我們構(gòu)建了一個(gè)基礎(chǔ)的血緣追蹤系統(tǒng)。

數(shù)據(jù)源與血緣追蹤：

• 數(shù)據(jù)源：血緣數(shù)據(jù)主要來源于研發(fā)平臺(tái)和指標(biāo)報(bào)表等系統(tǒng)。
• 執(zhí)行引擎：數(shù)據(jù)通過 Hive、Spark 等大數(shù)據(jù)處理引擎進(jìn)行執(zhí)行。
• 血緣捕獲：通過 hook 機(jī)制，我們?cè)?SQL 執(zhí)行過程中捕獲并解析輸入輸出表的信息，隨后將這些血緣信息推送到下游系統(tǒng)供其使用。
• 非 SQL 鏈路處理：針對(duì) MySQL 到 Hive、Hive 到下游終端等非 SQL 數(shù)據(jù)鏈路，我們預(yù)先定義了一套標(biāo)準(zhǔn)的格式，要求各業(yè)務(wù)系統(tǒng)按照此格式將他們的血緣關(guān)系推送到離線血緣數(shù)據(jù)倉庫中。

數(shù)據(jù)處理與存儲(chǔ)：

• 數(shù)據(jù)存儲(chǔ)：采集到的血緣數(shù)據(jù)通過定時(shí)調(diào)度進(jìn)行解析，并存儲(chǔ)至 MySQL 數(shù)據(jù)庫中。
• 血緣更新：我們以產(chǎn)生血緣的調(diào)度任務(wù)為單位進(jìn)行血緣的更新。當(dāng)新版本血緣生成時(shí)，舊版本血緣將被替換。

隨著血緣能力在研發(fā)場(chǎng)景中的價(jià)值逐漸被認(rèn)可，我們對(duì)系統(tǒng)提出了更高的要求，特別是血緣的時(shí)效性和字段級(jí)血緣的支持。為此，我們?cè)?1.0 版本的基礎(chǔ)上對(duì)系統(tǒng)架構(gòu)進(jìn)行了優(yōu)化和升級(jí)。

實(shí)時(shí)血緣解析：

• 增量更新機(jī)制：我們新增了一個(gè)實(shí)時(shí)血緣解析模塊，該模塊替代了原有的定時(shí)更新機(jī)制，實(shí)現(xiàn)了近實(shí)時(shí)的增量更新。
• 調(diào)度任務(wù)變更上報(bào)：由于大多數(shù)血緣信息是由調(diào)度任務(wù)產(chǎn)生的，我們引入了調(diào)度任務(wù)變更上報(bào)機(jī)制。當(dāng)任務(wù)發(fā)生下線或 SQL 更新時(shí)，這些信息能夠及時(shí)反映到血緣數(shù)據(jù)中，提高了血緣更新的時(shí)效性。

存儲(chǔ)升級(jí)：

• 圖數(shù)據(jù)庫 Neo4J：為了支撐更大量級(jí)的字段級(jí)血緣查詢，我們將存儲(chǔ)從 MySQL 升級(jí)為 Neo4J 圖數(shù)據(jù)庫。Neo4J 的強(qiáng)大性能支持了 10 層以上的節(jié)點(diǎn)查詢，這對(duì)許多分析類場(chǎng)景至關(guān)重要。

通過上述升級(jí)，我們的血緣追蹤系統(tǒng)不僅提升了數(shù)據(jù)的時(shí)效性和準(zhǔn)確性，還大大增強(qiáng)了處理復(fù)雜血緣關(guān)系的能力，為研發(fā)場(chǎng)景提供了更為強(qiáng)大的支持。

（3）存儲(chǔ)模型

在業(yè)界主要有兩種設(shè)計(jì)思路。第一種方案是將任務(wù)作為節(jié)點(diǎn)，通過這些節(jié)點(diǎn)來關(guān)聯(lián)不同表之間的關(guān)系。這種方式在涉及以任務(wù)為切入點(diǎn)進(jìn)行血緣查詢時(shí)更加靈活。然而，當(dāng)查詢表之間的關(guān)聯(lián)，尤其是需要進(jìn)行多層表關(guān)系查詢時(shí)，這種方案可能會(huì)增加查詢和維護(hù)的復(fù)雜度，尤其是在節(jié)點(diǎn)數(shù)量較多的情況下。

相比之下，第二種方案將任務(wù)作為邊的屬性，而表和表之間則建立直接的關(guān)聯(lián)。這種設(shè)計(jì)在查詢和維護(hù)方面更為直觀和簡(jiǎn)便。考慮到我們當(dāng)前的實(shí)際業(yè)務(wù)需求中，暫時(shí)沒有需要通過任務(wù)作為切入點(diǎn)進(jìn)行查詢的場(chǎng)景，我們決定采納第二種方案作為實(shí)現(xiàn)方式。這樣做不僅簡(jiǎn)化了查詢路徑，還優(yōu)化了系統(tǒng)的維護(hù)效率，更貼合我們當(dāng)前的業(yè)務(wù)需求。

（4）解析

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

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

當(dāng)前，業(yè)界主要討論兩種解析方法：一是通過 Hive hook 實(shí)現(xiàn)，即在任務(wù)執(zhí)行時(shí)從 Hive hook 的上下文中捕獲輸入輸出信息，這種方式無需關(guān)心 SQL 的提交方式，但可能存在滯后，因?yàn)檠壍母聝H在任務(wù)執(zhí)行后才能生效；另一種是靜態(tài) SQL 解析，一般利用開源的語法解析工具在任務(wù)提交前進(jìn)行，雖能即時(shí)反映 SQL 變更，但對(duì) Python 或腳本任務(wù)的 SQL 提取較為復(fù)雜。

因此綜合考慮背景和實(shí)現(xiàn)復(fù)雜度，我們選擇了 Hive hook 作為實(shí)現(xiàn)方式。

然而，這一過程中也面臨了幾個(gè)挑戰(zhàn)：

①血緣與任務(wù)關(guān)系打通：由于 Hive hook 本身無法直接獲取任務(wù)信息，我們推動(dòng)研發(fā)平臺(tái)進(jìn)行了改造，要求在提交 SQL 時(shí)將任務(wù)信息一并放入 hiveConf 中，以便在 hook 中能夠關(guān)聯(lián)這些信息并傳遞給下游系統(tǒng)使用。

②任務(wù)更新與血緣同步：為確保血緣信息的時(shí)效性，我們采用了研發(fā)平臺(tái)主動(dòng)上報(bào)任務(wù)下線和更新的機(jī)制。這樣，當(dāng)下線或更新任務(wù)時(shí)，相應(yīng)的血緣信息也會(huì)得到及時(shí)更新。

③臨時(shí)表處理：對(duì)于包含臨時(shí)表的 SQL，如 CREATE TEMPORARY TABLE T1 AS SELECT ... FROM a; INSERT INTO b SELECT * FROM T1;，直接解析會(huì)產(chǎn)生不必要的臨時(shí)節(jié)點(diǎn)和關(guān)系，影響后續(xù)使用。因此，我們?cè)趯?shí)現(xiàn)中引入了一個(gè)緩存機(jī)制，構(gòu)建血緣關(guān)系樹，并在新血緣到來時(shí)進(jìn)行合并判斷。只有當(dāng)臨時(shí)表的使用能夠合并為正式表之間的直接血緣關(guān)系時(shí)（如 a 寫 b），才會(huì)進(jìn)行下一步的對(duì)比、更新和入庫操作。

通過這些措施，我們成功實(shí)現(xiàn)了基于 Hive hook 的血緣解析，既滿足了業(yè)務(wù)需求，又有效解決了實(shí)施過程中遇到的問題。

（5）應(yīng)用場(chǎng)景

在數(shù)據(jù)應(yīng)用方面，我們聚焦于三個(gè)核心場(chǎng)景：數(shù)據(jù)開發(fā)效率提升、數(shù)倉開發(fā)優(yōu)化、以及數(shù)據(jù)治理與安全保障。

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

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

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

此外，為了加速信息傳遞，我們還提供了一鍵拉群功能，使得值班人員能夠迅速將相關(guān)團(tuán)隊(duì)和人員拉入緊急溝通群組，實(shí)現(xiàn)問題的即時(shí)通報(bào)與協(xié)同解決。

2. AI 智能檢索

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

具體而言，傳統(tǒng)的關(guān)鍵字檢索在面對(duì)多關(guān)鍵字組合查詢、查詢數(shù)據(jù)表含義、詢問數(shù)據(jù)口徑以及業(yè)務(wù)咨詢等場(chǎng)景時(shí)，顯得力不從心。這些需求要求檢索系統(tǒng)能夠更深層次地理解用戶的查詢意圖，并返回更加精準(zhǔn)和全面的結(jié)果。

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

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

RAG 方案的核心在于，它不僅僅依賴于大模型自身訓(xùn)練時(shí)獲取的靜態(tài)知識(shí)（這通常主要來源于互聯(lián)網(wǎng)上的公開信息，且難以實(shí)時(shí)更新），而是通過引入外部數(shù)據(jù)源的檢索機(jī)制，為大模型提供實(shí)時(shí)的上下文信息。這一機(jī)制允許大模型在回答企業(yè)專業(yè)領(lǐng)域的問題時(shí)，能夠結(jié)合最新的、特定于企業(yè)的數(shù)據(jù)，從而大大提升了答案的準(zhǔn)確性和時(shí)效性。

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

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

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

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

問答流程簡(jiǎn)述如下：用戶問題首先經(jīng)過增強(qiáng)處理，并轉(zhuǎn)化為向量化表示；隨后通過檢索系統(tǒng)獲取相關(guān)結(jié)果，并進(jìn)行智能重排序；優(yōu)化后的檢索結(jié)果結(jié)合 prompt 工程進(jìn)行精細(xì)組裝，最終由大模型生成準(zhǔn)確答案。這一過程確保了問答系統(tǒng)的高效、準(zhǔn)確與靈活性。

在實(shí)現(xiàn)過程中，我們?cè)庥隽藱z索漏召、大模型表現(xiàn)不穩(wěn)定、響應(yīng)速度慢及測(cè)評(píng)難題等挑戰(zhàn)。針對(duì)這些問題，我們采取了以下優(yōu)化措施：

（1）檢索漏召問題

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

（2）測(cè)評(píng)問題

建立更完善的測(cè)評(píng)體系，包括自動(dòng)化測(cè)試和人工審核，確保系統(tǒng)性能與用戶體驗(yàn)持續(xù)提升。

此外，我們認(rèn)識(shí)到最終表現(xiàn)效果還受到底層知識(shí)完備率的影響，因此加強(qiáng)與數(shù)倉等部門的合作，共同構(gòu)建和完善專業(yè)知識(shí)庫，為系統(tǒng)提供堅(jiān)實(shí)的數(shù)據(jù)支撐。

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

3. 支撐成本治理場(chǎng)景

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

為應(yīng)對(duì)上述挑戰(zhàn)，我們構(gòu)建了大數(shù)據(jù)成本治理體系，該體系以元數(shù)據(jù)為核心驅(qū)動(dòng)力，通過以下策略實(shí)現(xiàn)持續(xù)降本：

• 資產(chǎn)可視化度量：利用元數(shù)據(jù)構(gòu)建資產(chǎn)全景圖，實(shí)現(xiàn)成本在資產(chǎn)層面的可視化展示，清晰呈現(xiàn)成本分布與流向。
• 輔助治理能力：針對(duì)存儲(chǔ)和計(jì)算層面的資源浪費(fèi)，提供一系列技術(shù)能力，幫助減少資源使用。
• 健康度導(dǎo)向的成本運(yùn)營(yíng)：建立成本健康度評(píng)估體系，定期監(jiān)測(cè)成本水位，確保成本使用合理且高效，同時(shí)指導(dǎo)成本優(yōu)化策略的制定與實(shí)施。

數(shù)據(jù)資產(chǎn)度量體系旨在量化大數(shù)據(jù)資產(chǎn)的消耗與成本，并提供強(qiáng)大的查詢與統(tǒng)計(jì)分析功能。以下是該體系的框架概述：

我們聚焦于任務(wù)產(chǎn)出的核心資產(chǎn)，如表、報(bào)表、看板指標(biāo)等，從底層存儲(chǔ)與計(jì)算引擎精準(zhǔn)采集其消耗數(shù)據(jù)。這些數(shù)據(jù)隨后通過平臺(tái)數(shù)倉的精細(xì)加工，轉(zhuǎn)化為按個(gè)人及部門維度劃分的成本數(shù)據(jù)，使用戶能直觀了解各自名下資產(chǎn)的消耗情況。

此外，系統(tǒng)還能自動(dòng)生成部門級(jí)別的成本賬單，為資源優(yōu)化、任務(wù)調(diào)度優(yōu)化、存儲(chǔ)治理及成本運(yùn)營(yíng)等關(guān)鍵場(chǎng)景提供堅(jiān)實(shí)的數(shù)據(jù)支撐，助力企業(yè)實(shí)現(xiàn)更加精準(zhǔn)與高效的成本管理。

第二部分聚焦于輔助治理能力，特別針對(duì)貨拉拉大數(shù)據(jù)中占據(jù)主導(dǎo)地位的離線存儲(chǔ)成本。鑒于大數(shù)據(jù)環(huán)境中普遍存在的“冰數(shù)據(jù)”現(xiàn)象，即大量數(shù)據(jù)雖占用資源卻鮮少被訪問，我們致力于優(yōu)化存儲(chǔ)效率。

首先，我們面對(duì)的挑戰(zhàn)在于如何界定冷熱數(shù)據(jù)，因業(yè)界標(biāo)準(zhǔn)不一且難以直接套用于我司業(yè)務(wù)。為此，我們借鑒了美團(tuán)的數(shù)據(jù)分類方法（基于 90 天內(nèi)訪問頻次），并結(jié)合云廠商的歸檔存儲(chǔ)費(fèi)用模型，進(jìn)行了深入的分析與調(diào)整。

通過分析最近 90 天內(nèi)的數(shù)據(jù)訪問次數(shù)與歸檔收益的關(guān)系，我們發(fā)現(xiàn)訪問次數(shù)為 0 的數(shù)據(jù)占比最高且歸檔收益顯著，而訪問次數(shù)極少的數(shù)據(jù)歸檔收益則相對(duì)較低。基于這一發(fā)現(xiàn)，我們制定了數(shù)據(jù)溫度的打標(biāo)策略，將數(shù)據(jù)明確劃分為不同熱度等級(jí)。

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

理論上，數(shù)據(jù)隨時(shí)間推移會(huì)逐漸失去活躍性，即“冷卻”。為此，我們?yōu)閿?shù)據(jù)表設(shè)定了生命周期與歸檔周期兩大屬性，以實(shí)現(xiàn)對(duì)超出特定存活期限數(shù)據(jù)的自動(dòng)化滾動(dòng)清理與歸檔。在圖示中，該表的生命周期被設(shè)定為180 天，歸檔周期為 90 天。這意味著，超過 180 天的數(shù)據(jù)將被系統(tǒng)刪除以釋放資源，而介于 90 天至 180 天之間的數(shù)據(jù)則會(huì)被自動(dòng)歸檔至更低成本的存儲(chǔ)介質(zhì)中。

前述技術(shù)輔助能力為業(yè)務(wù)成本治理提供了有力支持，但要激發(fā)業(yè)務(wù)團(tuán)隊(duì)的主動(dòng)參與，還需構(gòu)建一套完善的成本運(yùn)營(yíng)能力。該體系能夠自動(dòng)偵測(cè)數(shù)據(jù)資產(chǎn)在計(jì)算與存儲(chǔ)層面的成本浪費(fèi)問題，生成治理點(diǎn)并即時(shí)通知相關(guān)用戶，促其采取主動(dòng)治理措施。治理點(diǎn)涵蓋未配置生命周期的存儲(chǔ)與計(jì)算資源、未歸檔的冗余數(shù)據(jù)、長(zhǎng)期未訪問的數(shù)據(jù)或任務(wù)等。

結(jié)合成本消耗數(shù)據(jù)，我們?cè)O(shè)計(jì)了一套健康分模型，以量化評(píng)估治理效果。此模型不僅為個(gè)人及部門提供成本健康狀態(tài)的直觀展示，還輔以獎(jiǎng)懲機(jī)制與紅黑榜排名，激勵(lì)用戶持續(xù)優(yōu)化存儲(chǔ)與計(jì)算成本，共同維護(hù)成本水位處于健康狀態(tài)。圖示展示了當(dāng)前資產(chǎn)健康分的評(píng)估結(jié)果，涵蓋個(gè)人與部門兩個(gè)維度，以及治理效果的排行榜，確保每位用戶及其領(lǐng)導(dǎo)層都能及時(shí)獲得反饋，共同推動(dòng)成本治理工作的深入進(jìn)行。

經(jīng)過一系列存儲(chǔ)優(yōu)化策略的實(shí)施，包括生命周期管理、數(shù)據(jù)歸檔、文件壓縮、格式算法升級(jí)以及深度專項(xiàng)治理等，我們?nèi)〉昧孙@著的成效。上圖展示了存儲(chǔ)成本的優(yōu)化成果：在優(yōu)化前，存儲(chǔ)成本呈現(xiàn)快速線性增長(zhǎng)趨勢(shì)；而優(yōu)化后，存儲(chǔ)成本在八個(gè)月內(nèi)實(shí)現(xiàn)了零增長(zhǎng)，并持續(xù)走低，累計(jì)節(jié)省了高達(dá) 54% 的存儲(chǔ)成本，成效頗為可觀。

4. 數(shù)據(jù)安全場(chǎng)景

元數(shù)據(jù)服務(wù)離不開分級(jí)打標(biāo)，分級(jí)主要是法律法規(guī)的要求，二是權(quán)限控制的需要，三是方便管理與審計(jì)，這方面的工作會(huì)借助安全定級(jí)系統(tǒng)，由其負(fù)責(zé)對(duì)元數(shù)據(jù)進(jìn)行分類定級(jí)打標(biāo)，打標(biāo)完成后會(huì)針對(duì) C4 以上的個(gè)人敏感信息進(jìn)行信息加密并打標(biāo)以實(shí)現(xiàn)敏感的管控，降低數(shù)據(jù)泄露的風(fēng)險(xiǎn)。

場(chǎng)景支撐：元數(shù)據(jù)作為數(shù)據(jù)管理平臺(tái)的底層基座，支撐庫表安全和數(shù)據(jù)下載兩大安全應(yīng)用場(chǎng)景。

• 庫表安全場(chǎng)景：依賴自研的庫表權(quán)限系統(tǒng)可進(jìn)行權(quán)限的申請(qǐng)與查詢，實(shí)現(xiàn)有效期的管理；后臺(tái)任務(wù)方面使用的底層策略是 Rager，鑒權(quán)服務(wù)方面已經(jīng)實(shí)現(xiàn)劣跡鑒權(quán)的應(yīng)用。
• 數(shù)據(jù)下載場(chǎng)景：依托自研的大數(shù)據(jù)研發(fā)平臺(tái)，可以進(jìn)行 SQL 查詢與數(shù)據(jù)下載，同時(shí) ETL 的離線任務(wù)也在此平臺(tái)實(shí)現(xiàn)。

數(shù)據(jù)的分類分級(jí)標(biāo)準(zhǔn)與規(guī)范

數(shù)據(jù)的分類分級(jí)結(jié)合了公司的業(yè)務(wù)場(chǎng)景，主要從數(shù)據(jù)的敏感性與價(jià)值性出發(fā)，同時(shí)參考了金融數(shù)據(jù)安全分類分級(jí)標(biāo)準(zhǔn)《金融數(shù)據(jù)安全數(shù)據(jù)安全分級(jí)指南》，將貨拉拉的數(shù)據(jù)安全等級(jí)分為四大等級(jí)：

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

庫表的分類分級(jí)

庫表的分類分級(jí)分為增量數(shù)據(jù)與存量數(shù)據(jù)，二者類別采用不同的分級(jí)達(dá)標(biāo)方案；

• 增量數(shù)據(jù)：針對(duì)單個(gè)庫表分級(jí)達(dá)標(biāo)，用戶可以通過元數(shù)據(jù)服務(wù)進(jìn)行建表，建表后通過審批，審批后進(jìn)行元數(shù)據(jù)更新，這一批更新的元數(shù)據(jù)會(huì)異步發(fā)布到 Kafka，通過定級(jí)系統(tǒng)進(jìn)行消費(fèi)數(shù)據(jù)，并進(jìn)行算法打標(biāo)，打標(biāo)主要依據(jù)字段名稱以及字段備注信息進(jìn)行打標(biāo)，打標(biāo)完成后將此批數(shù)據(jù)返回給 Kafka，然后在元數(shù)據(jù)服務(wù)系統(tǒng)進(jìn)行 Kafka 服務(wù)，以進(jìn)行元數(shù)據(jù)更新；
• 存量數(shù)據(jù)：設(shè)置定時(shí)任務(wù)每天進(jìn)行全表掃描，后發(fā)送給 Kafka，經(jīng)定級(jí)系統(tǒng)進(jìn)行消費(fèi)數(shù)據(jù)，并進(jìn)行算法打標(biāo)，打標(biāo)后返回 Kafka，并在元數(shù)據(jù)服務(wù)系統(tǒng)進(jìn)行 Kafka 服務(wù)，以更新元數(shù)據(jù)。

針對(duì)算法打標(biāo)的誤判，也支持人工修正，主要由有安全經(jīng)驗(yàn)的安全人員來進(jìn)行判斷并修正。

分級(jí)分類安全場(chǎng)景

分類分級(jí)在庫表的具體應(yīng)用場(chǎng)景，貨拉拉采用按照人員類別以及入職天數(shù)開放不同權(quán)限的數(shù)據(jù)安全策略。

針對(duì)以下的情形采用不同的安全權(quán)限策略：

• 入職多少天內(nèi)不能申請(qǐng)任何數(shù)據(jù)；
• 入職不滿多少天，嚴(yán)格限制了申請(qǐng) C3 及以上等級(jí)的數(shù)據(jù)，只能申請(qǐng) C1、C2 等級(jí)的數(shù)據(jù)；
• 外包、實(shí)習(xí)生、兼職類別人員只能申請(qǐng) C1、C2 的數(shù)據(jù)，不能申請(qǐng) C3 及以上數(shù)據(jù)權(quán)限。

限制人員若需要申請(qǐng)相應(yīng)庫表權(quán)限，需通過郵件申請(qǐng)白名單。在具體的庫表審批方面，會(huì)針對(duì) C3、C4 敏感等級(jí)數(shù)據(jù)自動(dòng)進(jìn)行標(biāo)紅處理，提醒審批人員對(duì)此部分?jǐn)?shù)據(jù)的權(quán)限進(jìn)行更加嚴(yán)格的審批，確保權(quán)限不會(huì)被錯(cuò)誤授權(quán)。

加密字段的打標(biāo)方案

加密字段打標(biāo)方案主要依賴于元數(shù)據(jù)服務(wù)和數(shù)據(jù)研發(fā)平臺(tái)。

通過元數(shù)據(jù)服務(wù)會(huì)設(shè)置定時(shí)任務(wù)定時(shí)掃描敏感數(shù)據(jù)，像掃描到 C3、C4 數(shù)據(jù)，會(huì)進(jìn)行 select 列 from 表 limit 多少條數(shù)據(jù)后執(zhí)行 SQL 查詢，返回獲取這些樣例數(shù)據(jù)，然后根據(jù)數(shù)據(jù)的規(guī)則進(jìn)行打標(biāo)，具體的達(dá)標(biāo)規(guī)則會(huì)對(duì)數(shù)據(jù)進(jìn)行長(zhǎng)度檢測(cè)和字符規(guī)則檢測(cè)。

通過自研的數(shù)據(jù)研發(fā)平臺(tái)，執(zhí)行 SQL 查詢，后臺(tái)解析此 SQL 查詢包含哪些表、哪一些字段，后向元數(shù)據(jù)服務(wù)申請(qǐng)調(diào)用得到相關(guān)的元數(shù)據(jù)，后通過數(shù)據(jù)研發(fā)平臺(tái)查詢此部分?jǐn)?shù)據(jù)的 Hive 結(jié)果。若需要下載，會(huì)根據(jù)元數(shù)據(jù)的加密以及敏感等級(jí)走不同的審批流。

具體的審批策略針對(duì)敏感數(shù)據(jù)和非敏感數(shù)據(jù)采用不同的方式：

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

加密打標(biāo)應(yīng)用場(chǎng)景

加密打標(biāo)的應(yīng)用場(chǎng)景：數(shù)據(jù)下載。

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

數(shù)據(jù)安全更多的應(yīng)用場(chǎng)景：

• 安全等級(jí)打標(biāo)傳染：通過血緣的傳染能力給它的下游數(shù)據(jù)進(jìn)行打標(biāo)，提高庫表分級(jí)的準(zhǔn)確率；
• 數(shù)據(jù)加密治理：對(duì)存量敏感數(shù)據(jù)漏打標(biāo)情形進(jìn)行識(shí)別，如個(gè)人信息，并進(jìn)行批量打標(biāo)、加密，以保障數(shù)據(jù)安全；
• 數(shù)據(jù)災(zāi)備：通過元數(shù)據(jù)打標(biāo)，實(shí)現(xiàn)數(shù)據(jù)自動(dòng)災(zāi)備。

三、未來規(guī)劃

未來的規(guī)劃與建設(shè)重點(diǎn)包括更高效的檢索服務(wù)、數(shù)據(jù)血緣的標(biāo)準(zhǔn)化以及降本增效三個(gè)方面。

• 更高效的檢索服務(wù)：進(jìn)一步優(yōu)化和探索 AI 大模型在數(shù)據(jù)檢索領(lǐng)域的應(yīng)用，更好的識(shí)別用戶意圖并更好的回答。
• 數(shù)據(jù)血緣標(biāo)準(zhǔn)化：數(shù)據(jù)血緣建立標(biāo)準(zhǔn)的 SDK，減少重復(fù)造輪子；提高數(shù)據(jù)血緣質(zhì)量度量的準(zhǔn)確率，以便于數(shù)據(jù)分析。
• 自動(dòng)化成本治理：持續(xù)降本，盡可能多的步驟實(shí)現(xiàn)自動(dòng)化處理，減少一些不必要的成本。