一、背景及問題

模型建設(shè)的要求主要有三個方面：效率快、成本省、質(zhì)量穩(wěn)。

• 模型要能夠快速地開發(fā)和使用，因為數(shù)據(jù)具有實效性，如果數(shù)據(jù)不能快速地產(chǎn)出和消費，它帶來的價值就會受到影響；
• 模型設(shè)計要考慮數(shù)據(jù)成本帶來的影響，近幾年有很多企業(yè)在做成本治理，模型也有節(jié)省成本的訴求；
• 數(shù)據(jù)質(zhì)量要有保障，包括數(shù)據(jù)的準(zhǔn)確性和穩(wěn)定性等。

結(jié)合多年的數(shù)據(jù)模型開發(fā)和管理經(jīng)驗，總結(jié)了四個“1”：

一套規(guī)范體系，要有一套方法論來支撐如何構(gòu)建模型、如何使用模型。

一套評估體系，要衡量數(shù)據(jù)的價值是比較難的，但模型構(gòu)建的好壞要有一套評估體系去支持我們了解模型的現(xiàn)狀以及它構(gòu)建的健康程度。

一個增量管控，在模型的開發(fā)和管理過程中要有管控措施保證模型能夠健康、快速地上線。

一個存量治理能力，模型經(jīng)過一段時間之后需要進行迭代，所以存量治理能力非常重要。

大淘寶為什么要做模型治理？有兩個關(guān)鍵的時間點：

第一個節(jié)點是2020年，大淘寶做了很多數(shù)字化運營的工作，在工作過程中有很多角色參與進來，早期只有核心用數(shù)據(jù)的人員：數(shù)據(jù)開發(fā)和分析師，后來很多工程、算法、產(chǎn)品、運營等人員都參與到數(shù)據(jù)的開發(fā)和使用中，角色變多了；

另一個關(guān)鍵節(jié)點是2022年，我們在2020~2022年做了很多的成本治理工作，但是2022年大淘寶還是出現(xiàn)了幾個問題：

• 數(shù)據(jù)規(guī)模始終在膨脹。
• 出現(xiàn)了一些穩(wěn)定性問題，因為很多數(shù)據(jù)需要強保障，其穩(wěn)定的產(chǎn)出和較高的質(zhì)量是比較重要的。
• 我們發(fā)現(xiàn)隨著數(shù)據(jù)量的增長，模型的消費效率在逐漸降低。

基于上述背景，我們啟動了大淘寶模型治理。

模型具體出現(xiàn)的問題包括：

① 上圖中可以看到大淘寶在2020-2022年數(shù)據(jù)規(guī)模的增長，有一個比較大的跳變。

② 很多數(shù)據(jù)是無效數(shù)據(jù)，線上使用過程中我們發(fā)現(xiàn)有很多數(shù)據(jù)90天都沒有訪問，另外一些線上節(jié)點也是沒有消費的。如果其占比太高就會帶來很多問題，例如成本、運維問題，另外規(guī)模過大的情況下找到高質(zhì)量的數(shù)據(jù)也會存在很大挑戰(zhàn)。

③ 很多模型在迭代過程中無人負責(zé)，未歸屬表占比高達16%，如果其中大部分都是無效表其實還好，但是我們發(fā)現(xiàn)這些未歸屬表中有12% 仍在使用。

④ 很多非數(shù)據(jù)研發(fā)角色的同學(xué)在數(shù)據(jù)模型的開發(fā)和使用過程中出現(xiàn)了不規(guī)范的問題。

集團內(nèi)部數(shù)倉分為三層：

① 第一層是來源表即貼源層，數(shù)據(jù)從底層的MySQL、HBase等數(shù)據(jù)庫直接同步到計算平臺ODPS。

② 第二層是最核心的公共層，它承載的使命就是復(fù)用的數(shù)據(jù)，例如交易、會員等，它的維表、事實表、匯總表都會沉淀下來，以幫助下游更好地實現(xiàn)消費和口徑的統(tǒng)一。

③ 第三層是應(yīng)用層，偏向分析和使用場景，比如一些分析決策場景及產(chǎn)品數(shù)據(jù)，所以應(yīng)用層是面向終端消費的。

其中的問題如下：

① 公共層的引用不足，應(yīng)用層大量自建中間表。我們用兩個核心指標(biāo)去看：

• 公共層復(fù)用率存量不足40%，新增不足20%，也就是說模型對下游的復(fù)用是不夠高的。
• 公共層覆蓋率非常低，只有15%，覆蓋率是把公共層作為一個整體單元來服務(wù)整個下游應(yīng)用層及一些探查類數(shù)據(jù)的，所有服務(wù)的下游表的總量消費公共層表的占比，代表公共層對下游的服務(wù)能力。
• 再看應(yīng)用層，它的開發(fā)應(yīng)該依賴公共層的一些數(shù)據(jù)，但是我們發(fā)現(xiàn)重要的DWS，其覆蓋率存量不足30%，新增不足10%，很多應(yīng)用層的關(guān)鍵數(shù)據(jù)沒有引用公共層開發(fā)的數(shù)據(jù)。
• 應(yīng)用層引用底層來源表的占比是24%，比例非常高，而公共層只有15%，很多是直接基于最源頭的數(shù)據(jù)開發(fā)的。
• 應(yīng)用層自建中間表高達46%，它不直接被下游消費，只是中間過程表，意味著有很多重復(fù)的構(gòu)建和一些該下沉的數(shù)據(jù)沒有下沉。

② 來源表也有一些問題：

• 來源表在幾百個空間里都有分布，其實應(yīng)該收斂到一些可控的空間里；
• 來源表會被重復(fù)導(dǎo)入，理論上底層的這些數(shù)據(jù)只需要同步一份就好，但是我們發(fā)現(xiàn)因為工具的便捷性，導(dǎo)致大量重復(fù)同步。其實我們也設(shè)計了一個TBODS空間，目的是把整個淘寶的ODS數(shù)據(jù)收斂起來，但是我們發(fā)現(xiàn)只有9%的來源表，收斂比例是非常低的。

在決策看數(shù)、業(yè)務(wù)洞察、數(shù)據(jù)產(chǎn)品幾大核心板塊里，缺乏統(tǒng)一的數(shù)據(jù)架構(gòu)規(guī)范，例如數(shù)據(jù)的分層占比、命名規(guī)范引用情況都不是很理想；公共層早期偏向于支持決策型數(shù)據(jù)，缺乏對業(yè)務(wù)分析型數(shù)據(jù)的建設(shè)，數(shù)據(jù)的消費效率不高。

二、解決方案

針對上述問題，要找到治理模型的解決方案，首先要分析一下問題原因。

• 一部分是因為規(guī)范的機制沒有保障，例如數(shù)據(jù)交接應(yīng)該做哪些流程管控，也沒有對于非數(shù)研同學(xué)或者其他角色的規(guī)范。
• 在數(shù)據(jù)建設(shè)過程中也忽略了一個核心點就是我們建的數(shù)據(jù)到底好不好，一方面我們建的公共層運營不足，另一方面它偏向于穩(wěn)定，所以迭代不夠，導(dǎo)致下游消費時很多團隊自己去建設(shè)。
• 另外，數(shù)據(jù)導(dǎo)入缺乏管控，無效表無人治理，缺乏有效的產(chǎn)品工具提效。

我們的解決方案的基礎(chǔ)是前文提到的四個“1”的治理能力，包括數(shù)據(jù)體系規(guī)范、模型評估體系、模型管控，以及模型治理四大方面。

基于這四大能力，我們的核心治理策略為：

• 提高優(yōu)質(zhì)數(shù)據(jù)供給，包括規(guī)范培訓(xùn)推廣，讓大家更好地理解和使用；構(gòu)建完數(shù)據(jù)后通過專輯的方式使其能夠快速上架，讓下游看到數(shù)據(jù)；專輯配備好說明和引導(dǎo)以幫助大家更好的理解。
• 消費提效方面，對核心數(shù)據(jù)做專輯的上下架和運營宣講；檢索數(shù)據(jù)時快速推薦高質(zhì)量數(shù)據(jù)，同時做一些引導(dǎo)，比如在申請權(quán)限時，申請的是一張底層表，而公共層已經(jīng)有比較高質(zhì)量的表，就可以在權(quán)限審批時引導(dǎo)他去申請更好用的表；還可以啟動一些專項治理，比如網(wǎng)格化的垂直專題治理。
• 優(yōu)質(zhì)供給和消費提效解決的是數(shù)據(jù)的生產(chǎn)關(guān)系問題，我們判斷模型的復(fù)雜度有兩個核心點，一個是規(guī)模，規(guī)模越大復(fù)雜度就越高，另外一個是數(shù)據(jù)消費關(guān)系，消費關(guān)系越復(fù)雜越趨于網(wǎng)狀結(jié)構(gòu)其復(fù)雜度越高，所以在規(guī)?？刂粕衔覀儠鰺o效表下線、同源導(dǎo)入的管控。

基于這些治理策略，我們組合一些領(lǐng)域?qū)ｎ}包括：

• 公共層的增厚，通過網(wǎng)格化的專項把模型做得更好。
• 應(yīng)用層做提效操作，構(gòu)建復(fù)用邏輯保證消費效率。
• 無效表下線、同源導(dǎo)入治理和數(shù)據(jù)交接等。

為了做這些治理，我們也需要更好的產(chǎn)品和工具來支持，我們和DataWorks團隊深度合作，構(gòu)建了基于數(shù)據(jù)開發(fā)的治理產(chǎn)品，比如：

智能建模，它解決的核心問題就是模型設(shè)計和模型開發(fā)問題，從設(shè)計環(huán)節(jié)保證它的高效性和規(guī)范性；開發(fā)環(huán)節(jié)即開發(fā)模型寫代碼的環(huán)節(jié)，會直接把我們的優(yōu)化建議和發(fā)布管控在開發(fā)側(cè)產(chǎn)品化。

• 數(shù)據(jù)地圖，在展示數(shù)據(jù)的產(chǎn)品中我們開發(fā)了專輯功能，數(shù)據(jù)通過專輯上架的方式展示給下游；通過引導(dǎo)推薦讓大家更好地發(fā)現(xiàn)高質(zhì)量的數(shù)據(jù)。
• 構(gòu)建數(shù)據(jù)治理中心的能力，比如優(yōu)雅下線，快速將無效表下線；數(shù)據(jù)治理中心管控的配置化，使其快速分發(fā)至各個產(chǎn)品。

以上就是整體的解決方案。我們在統(tǒng)一規(guī)范、公共層的覆蓋率提升、無效表的下線、產(chǎn)品的能力等方面制定了治理目標(biāo)。

三、模型治理

接下來分享一下具體的模型治理實踐。

1、無效表下線和ODS同源導(dǎo)入治理

首先看一下無效表下線和ODS同源導(dǎo)入，兩者都是控制數(shù)據(jù)規(guī)模的。很多時候數(shù)據(jù)開發(fā)同學(xué)上數(shù)據(jù)是比較快的，但是很少去下數(shù)據(jù)，只要做完就很少主動去下線。我們要下線數(shù)據(jù)有兩個方案，一個是用識別的方式通過平臺或工具推送給表負責(zé)人，讓他確認逐個手動下線，這個過程我們覺得沒有太多意義，大家主動下線的意愿不高，給數(shù)據(jù)Owner 帶來的價值也不明顯，所以我們選擇的方案是自動化下線，它有幾個核心環(huán)節(jié)：

• 要提高元數(shù)據(jù)的識別準(zhǔn)確度，即能夠比較準(zhǔn)確地識別哪些是無效表，準(zhǔn)確度要提升到95%以上；
• 要保證自動化下線沒有風(fēng)險，可以快速恢復(fù)。我們對表執(zhí)行rename的操作，如果沒有問題就可以把它下線，如果有問題在觀察期就可以快速恢復(fù)。對于節(jié)點的下線，先進行凍結(jié)，邏輯跟表重命名是一樣的，有了這幾個動作后，我們通過下線通知的方式可以快速的幫助大淘寶做一些自動化治理，減少大家的投入，這里我們的應(yīng)用效果也比較明顯，只花了近一人月的時間，下線了幾十萬張無效表和無效節(jié)點，無效表占比降到了5%以下，我們對大淘寶所有的空間覆蓋部署了自動化下線能力，部署占比85%。

同源導(dǎo)入治理這塊相對比較流程化：

• 我們能夠快速識別出同源導(dǎo)入的數(shù)據(jù)，準(zhǔn)確度可以達到99%以上；
• 我們會針對識別的數(shù)據(jù)做業(yè)務(wù)歸屬，因為很多時候同步的數(shù)據(jù)從底層庫到下游的使用都有歸屬的業(yè)務(wù)團隊，我們先確認清楚數(shù)據(jù)的歸屬；
• 之后我們就可以把導(dǎo)入的映射關(guān)系構(gòu)建起來，有了映射關(guān)系我們的管控規(guī)則就可以在產(chǎn)品里快速配置上線，這樣下一次導(dǎo)入的時候，如果出現(xiàn)重復(fù)導(dǎo)入，就會提示數(shù)據(jù)已經(jīng)導(dǎo)入過。另外歸屬的核心業(yè)務(wù)團隊空間可以只執(zhí)行這些業(yè)務(wù)數(shù)據(jù)的導(dǎo)入，就可以保持業(yè)務(wù)數(shù)據(jù)跟管理空間是一致的，數(shù)據(jù)同步的過程中會有比較好的引導(dǎo)和攔截；
• 另外我們也在做多空間合并，暫時還沒有完全實行，在開發(fā)過程中為了方便申請了新的空間，但這些空間可能是沒有必要的或者是重復(fù)的，我們想把這些空間做自動化合并，后續(xù)會把它完全實施下來。

2、數(shù)據(jù)交接

第二塊是數(shù)據(jù)交接的治理實踐。基于元數(shù)據(jù)和治理流程，有一些關(guān)鍵動作：首先我們有一個自動化評估的策略，就是數(shù)據(jù)會主動觸發(fā)一個交接流程，比如轉(zhuǎn)崗或離職，觸發(fā)后會對他名下的數(shù)據(jù)或者要交接的數(shù)據(jù)自動做一些評估，包括模型質(zhì)量、穩(wěn)定性等多方面的診斷，給出一個評估報告以及一些治理建議。如果數(shù)據(jù)存在問題，需要治理后才能進行交接，治理后會評估治理的效果，在得到被交接人認可或者是團隊認可后，這個流程才可以完成。

這里面不僅是數(shù)據(jù)的治理，還包括業(yè)務(wù)的描述和一些文檔的描述，通過這個過程我們就可以保證數(shù)據(jù)有很好的繼承和交接，避免只交接數(shù)據(jù)，不交接業(yè)務(wù)和文檔，同時可以把治理在交接過程中也直接處理掉。治理之后我們實現(xiàn)了交接評估的自動化，比如現(xiàn)在只要有任一個交接流程發(fā)起，就可以快速、自動地完成評估。另外我們后續(xù)考慮把交接的流程嵌入到工作流里，比如在發(fā)起轉(zhuǎn)崗或者離職流程時，直接嵌入進去。

3、公共層專項運營及治理

第三塊是公共層專項運營和治理，這是我們的一個重要的提效手段。因為我們經(jīng)過評估體系的診斷分析之后發(fā)現(xiàn)，大淘寶有三塊場景在重復(fù)度或消費側(cè)有很大的提升空間，它包括用戶分析、商家分析和匹配分析三部分。因為匹配分析相對比較離散，所以我們針對用戶和商家兩個專題做了專項治理。

我們把專題數(shù)據(jù)比擬成商品，快速圈選出這些數(shù)據(jù)形成一個體系，即用戶體系，快速在數(shù)據(jù)地圖的官方專輯里上架，成為體系化的數(shù)據(jù)。然后我們就可以評估其復(fù)用率和覆蓋率，評估后，因為有了這些數(shù)據(jù)的展示門戶，我們就可以做用戶的專項運營，因為這些數(shù)據(jù)有下游的服務(wù)團隊和消費團隊，可以看到他們使用數(shù)據(jù)的狀況。對使用率比較低但確實有真實訴求的情況，會做一些專項的運營，告訴他們我們有哪些數(shù)據(jù)，這些數(shù)據(jù)有哪些核心的保障，這些數(shù)據(jù)應(yīng)該怎么用，并且更新其使用的知識文檔，這些知識文檔可能是基于前人經(jīng)驗做的沉淀，也可能是基于問答生成的自動化知識。然后就可以讓下游快速的知道我們這些數(shù)據(jù)，同時我們的診斷體系也可以基于下游的消費狀況識別出哪些數(shù)據(jù)可以沉淀到這個體系里去，因為很多模型構(gòu)建是基于前置經(jīng)驗和后驗經(jīng)驗去做的，這個專題就可以把消費側(cè)的經(jīng)驗快速識別出來，哪些數(shù)據(jù)是高頻度的數(shù)據(jù)，我們可以快速把它沉淀到我們的體系里去，從而實現(xiàn)增厚的效果。

專輯運營也是迭代的。以前在做數(shù)據(jù)的時候很少去關(guān)注數(shù)據(jù)的消費和運營，在做專題的過程中發(fā)現(xiàn)很多時候不是下游不愿意用我們的數(shù)據(jù)，而是他們不知道我們有哪些數(shù)據(jù)，即使找到數(shù)據(jù)后也不知道如何使用。我們在運營過程中達到了非常好的效果。在商家專項里，增量覆蓋率從6%提升到了56%，用戶專項從18%提升到了63%，治理之后數(shù)據(jù)使用率直線上升。我們基于兩個很成功的經(jīng)驗，啟動了其他的專題，這些專題有直播、短視頻、用戶決策，后續(xù)還有更多專題去啟動。因為我們認識到很多時候我們構(gòu)建的模型，通過垂直化領(lǐng)域的推廣和治理效果會更好，比一體化運作的效果更直觀更明顯。

4、增量管控

再來看一下增量管控，我們會把基于評估體系和模型治理的規(guī)則先沉淀出來，比如前文提到的同源導(dǎo)入、發(fā)布管控和交接管控的規(guī)則都配置出來，再通過數(shù)據(jù)治理中心把規(guī)則作為檢查項分發(fā)到各個鏈路里去。比如同源導(dǎo)入，我們會把規(guī)則分發(fā)到我們的數(shù)據(jù)集成產(chǎn)品里去，當(dāng)有同源導(dǎo)入時就會觸發(fā)檢查和引導(dǎo)。在開發(fā)數(shù)據(jù)的時候，比如引用了一些表，可以通過推薦數(shù)據(jù)把它直接分發(fā)到開發(fā)頁面里，告知有些字段存儲比較大，是不是可以不選擇，或者有一個更好的表，是不是可以換成另外一張表去開發(fā)。

這樣我們可以實現(xiàn)更加精準(zhǔn)的管控，同時因為我們使用的數(shù)據(jù)治理中心和DataWorks各個產(chǎn)品是聯(lián)動的，可以根據(jù)管控規(guī)則所涉及的產(chǎn)品環(huán)節(jié)快速實現(xiàn)全面漏斗分發(fā)。

5、產(chǎn)品化

接下來看一下模型治理產(chǎn)品化的幾個產(chǎn)品。

第一個是用于模型設(shè)計的智能建模，我們早期的規(guī)范標(biāo)準(zhǔn)其實設(shè)計是沒有問題的，但是在實施過程中很多模型設(shè)計和開發(fā)沒有一個很好的工具去承接，很多時候是做離線的模型設(shè)計，然后做線下評審，評審?fù)暝偃ナ謱懘a提交到線上。這個過程很難管控設(shè)計規(guī)范，另外也比較低效。

智能建模的作用包括：第一是可以把設(shè)計規(guī)劃直接沉淀下來，比如數(shù)據(jù)劃分、維度定義等；第二，數(shù)據(jù)標(biāo)準(zhǔn)也可以快速呈現(xiàn)出來，比如省市區(qū)劃分可以很快展示出來；第三是維度建模，支持可視化維度建模；第四是指標(biāo)管理，可以通過畫板或自動的智能化識別快速生成。

剛才也提到數(shù)據(jù)治理中心有傳統(tǒng)的健康評估和治理，但是我們的模型治理要利用到一些很新的能力，比如無效表下線就需要數(shù)據(jù)治理中心去承接。另外我們在數(shù)據(jù)治理和運維過程中有一個很大的痛點，就是一些老的數(shù)據(jù)要遷移，下游很難去變更和遷移，我們需要一鍵遷移的能力，降低遷移的成本。

第三個產(chǎn)品是數(shù)據(jù)地圖，它是供給和消費側(cè)數(shù)據(jù)展示和檢索的門戶。重點是構(gòu)建數(shù)據(jù)專輯，把數(shù)據(jù)通過專輯的形式展示給大家，提供一個專門看數(shù)據(jù)的門戶。門戶也會有運營動作，針對對應(yīng)主題的專輯做對應(yīng)的運營，同時把我們的經(jīng)驗知識和結(jié)構(gòu)化數(shù)據(jù)運營起來，通過機器人的方式快速答疑完成找數(shù)據(jù)的工作。

6、能力沉淀

我們對前文中提到的四個“1“的能力也進行了沉淀。

首先是一個規(guī)范體系。早期我們的模型規(guī)范涉及的環(huán)節(jié)比較少，只有一個比較粗的方法論，我們需要把實踐過程中的經(jīng)驗也體現(xiàn)在這里。

另外一個是我們的評估體系。以前我們在評估方面也做了很多工作，包括早期的血緣分析，以及后面提出的模型分，但這些評估都是一些散點，所以我們升級的評估體系核心包括幾個環(huán)節(jié)，第一是通過一些指標(biāo)評估出模型的質(zhì)量，第二是做一些診斷，不僅發(fā)現(xiàn)數(shù)據(jù)不好，也會告訴你為什么不好，以及應(yīng)該做哪些動作，最后治理效果也可以展示出來。升級后的評估體系不僅包括指標(biāo)，還包括診斷和治理策略，同時也可以展示治理效果。

7、總結(jié)

我們在多年的模型治理中積累了許多經(jīng)驗，可以總結(jié)為以下幾方面：

• 首先，我們需要決策層支持，因為模型治理是數(shù)據(jù)提效、架構(gòu)升級和數(shù)據(jù)消費的重要手段，我們看模型不能看單點的一些數(shù)據(jù)，應(yīng)該把它理解為本質(zhì)上是提高數(shù)據(jù)開發(fā)和消費效率的，要幫助業(yè)務(wù)快速產(chǎn)生價值的事情，所以決策支持非常重要。我們在模型治理的過程中的數(shù)據(jù)一號位也提供了很多的支持，這是很重要的。
• 第二，模型治理是長期的事情，我們的模型架構(gòu)會迭代升級，業(yè)務(wù)也會變化，治理策略也會隨之變化。做計存治理可能相對比較簡單，通過TOP計存分析，做一些壓縮、刪表就可以快速拿到很好的結(jié)果，但模型治理是長期的，也需要有匠心精神，因為要理解模型往往會涉及到各個環(huán)節(jié)，包括數(shù)據(jù)研發(fā)、下游消費、質(zhì)量保障等等。
• 第三，數(shù)據(jù)即產(chǎn)品，我們要把數(shù)據(jù)當(dāng)作產(chǎn)品去看，不能認為數(shù)據(jù)開發(fā)完之后就可以了，要把它作為一個產(chǎn)品去交付，去看下游的消費，是不是有人愿意用你的數(shù)據(jù)。
• 最后是持續(xù)的演進。以前我們每過1-2年都會做一次大規(guī)模的人工投入治理，我們發(fā)現(xiàn)效率很低，成本很高，我們的業(yè)務(wù)支撐是比較慢的，所以我們應(yīng)該以業(yè)務(wù)增量價值去推動，一邊支持好業(yè)務(wù)，一邊做治理。另外我們要結(jié)合一些新的方法論和技術(shù)手段不斷去演進治理手段。

四、未來規(guī)劃

最后介紹一下后續(xù)的一些規(guī)劃。

1、供給消費提效

從供給側(cè)提升模型設(shè)計、開發(fā)和上架的效率，能夠快速把優(yōu)質(zhì)內(nèi)容開發(fā)出來；另外在消費側(cè)也要做提效，包括數(shù)據(jù)的運營推薦。

2、架構(gòu)規(guī)范管控

提升規(guī)范管控能力，將更多管控規(guī)則通過產(chǎn)品化分發(fā)到各個研發(fā)環(huán)節(jié)。

3、評治一體

模型治理從評估到治理有一個流程，但是很多企業(yè)或團隊，偏向于評估之后讓各個Owner去做治理，第一效率不高，第二本身我們的評估如果足夠準(zhǔn)確足夠高效，可以直接和產(chǎn)品打通，這是我們后續(xù)的一個努力方向。

另外我們要結(jié)合一些新的技術(shù)，比如主動元數(shù)據(jù)、大模型等，還有自動代碼生成、自動血緣切換等能力，實現(xiàn)治理的簡單化、自動化。

五、Q&A

Q1：消費關(guān)系是什么？

A：我們的數(shù)據(jù)開發(fā)完之后要被下游使用，比如表是不是被配置到看板里，是不是被配置到產(chǎn)品里，這些都是數(shù)據(jù)消費。消費關(guān)系就是在使用這些數(shù)據(jù)時，引用的是哪些數(shù)據(jù)，是公共層的數(shù)據(jù)，還是最原始層的數(shù)據(jù)，又或是應(yīng)用層的數(shù)據(jù)。消費關(guān)系決定了模型的復(fù)雜度，消費關(guān)系越復(fù)雜，網(wǎng)狀結(jié)構(gòu)越深，就代表我們要想去理解或者追溯的難度就越大，治理的難度也就越大。

Q2：模型優(yōu)雅下線的優(yōu)雅體現(xiàn)在哪里？如何實現(xiàn)？

A：優(yōu)雅指的是不需要投入很多人工去確認，可以直接自動化下線，它體現(xiàn)在幾個方面，第一就是能夠精準(zhǔn)識別出無效數(shù)據(jù)，比如沒有下游訪問的，沒有下游的依賴關(guān)系，或者一直重復(fù)同步相同的數(shù)據(jù)。第二是識別出無效數(shù)據(jù)、無效節(jié)點之后，可以快速下線，不需要人工再去確認，也不需要寫下線語句，從而避免下游的人為成本和治理成本。

Q3：同源導(dǎo)入的識別率，準(zhǔn)確度高是因為元數(shù)據(jù)完整還是在一處配置的，還是有其他的方法？

A：同源導(dǎo)入的識別率高是因為我們的元數(shù)據(jù)做的比較好，因為同源導(dǎo)入需要配置，比如要配置映射關(guān)系，它的原始庫是什么，目標(biāo)庫是什么，這些數(shù)據(jù)在整個同步過程中都會被記錄下來，有了這些記錄，我們可以非常精準(zhǔn)地識別出是不是同一個庫的同一張表被導(dǎo)入了兩次，其依賴就是血緣解析，所以它的精準(zhǔn)度提升是元數(shù)據(jù)本身的一個保障。

Q4：模型的管理與治理與業(yè)務(wù)的敏捷查數(shù)用數(shù)是怎樣平衡的？

A：這是一個好問題，我們剛才也提到在治理的過程中更應(yīng)該關(guān)注的是增量，先保障增量，不要投入太多精力去治理歷史數(shù)據(jù)，因為數(shù)據(jù)是有生命周期的，幾個月后可能它就變得不那么重要了，只有一些核心模型才需要做存量的治理。但是增量在業(yè)務(wù)使用過程中，它消費的是不是比較高質(zhì)量的數(shù)據(jù)，它開發(fā)的數(shù)據(jù)是不是能夠很好的被下游理解，能夠很好地分發(fā)到下游去，這是我們最關(guān)注的。所以首先要幫助業(yè)務(wù)快速滿足其自身需求，另外把存量治理的動作通過產(chǎn)品和自動化的方式去解決，這樣就可以平衡性能。因為業(yè)務(wù)團隊是非常忙碌的，做需求的時候再去推動很多治理動作是不合適的，所以一方面可以通過產(chǎn)品快速進行存量治理，另一方面通過提供優(yōu)質(zhì)的數(shù)據(jù)供給，提高需求的開發(fā)效率。

Q5：可視化建模是指ER圖嗎? 只是用來查看的視圖還是有別的能力？

A：我們在開發(fā)一個表的時候，想做一張明細表或維表，邏輯是先設(shè)計原始數(shù)據(jù)是哪幾張表，業(yè)務(wù)過程有哪些，字段有哪些，把它放到哪個主題域里。這個設(shè)計以前是線下的操作，但是智能建?？梢暬前涯Ｐ驮O(shè)計體現(xiàn)出來，它不只是一個可視化的ER關(guān)系，還包含設(shè)計邏輯、歸屬邏輯，以及屬于哪些數(shù)據(jù)域，粒度是什么，業(yè)務(wù)過程是什么等等。這些是可以在智能建模里快速導(dǎo)入和錄入的，設(shè)計完后我們也會做模型評審，因為每個集市或主題都會有對應(yīng)的模型師，他可以快速的看到有哪些人提交了模型，可以快速的做評審。另外模型設(shè)計完之后，因為有底層表和關(guān)聯(lián)關(guān)系，可以快速的生成代碼，也就是說我們不僅可以做模型設(shè)計，還可以快速生成代碼，例如簡單的主鍵關(guān)聯(lián)、匯總或group by，這些代碼會自動生成，生成后可以快速進行調(diào)整，快速上架。所以智能建模不僅包括設(shè)計ER關(guān)系或者模型關(guān)系，還包含模型的歸屬以及快速的代碼生成。

Q6：考慮到用chatgpt結(jié)合模型管理嗎？有什么場景可以用到？

A：這個是有考慮的，我了解到產(chǎn)品團隊也在使用大模型去做一些訓(xùn)練，第一個是我們選擇大模型或者了解這些主動元數(shù)據(jù)，而不是跟風(fēng)，因為我們發(fā)現(xiàn)有很多以前模型的問題解決不了，比如實現(xiàn)邏輯復(fù)用的識別，相似表、相似字段，我們以前的識別率是比較低的，低到無法投入使用，比如我們要做血緣追溯或者重復(fù)數(shù)據(jù)的遷移，我們不知道哪些表相似，就沒法做這些工作，所以需要利用比如底層代碼的分析和識別去真正準(zhǔn)確的識別出相似的數(shù)據(jù)。另外我們的口徑，比如指標(biāo)加工的口徑是統(tǒng)一的，但是下游消費的時候，因為命名導(dǎo)致可能重復(fù)命名的指標(biāo)，我們也識別不出來這些數(shù)據(jù)是不是重復(fù)加工的，如果我們用大模型的方法，比如把我們集群里的所有代碼全部學(xué)習(xí)一遍，看哪些邏輯是相似的，就可以快速把那些指標(biāo)用相同的口徑去實現(xiàn)。

還有我們現(xiàn)在開發(fā)數(shù)據(jù)還是相對比較低效的。我們先了解需求和業(yè)務(wù)，然后去做模型設(shè)計，開發(fā)。將來是不是有一種方式，只要通過結(jié)構(gòu)化的表達把數(shù)據(jù)描述清楚，代碼或者指標(biāo)就可以快速計算出來，如果能夠?qū)崿F(xiàn)，那么后續(xù)的治理就不需要了。只需要從底層的機器層面就可以實現(xiàn)代碼統(tǒng)一和邏輯最優(yōu)，不再需要投入很多人力成本或設(shè)計去做下線和口徑調(diào)整遷移。但是因為大模型本身需要時間迭代，所以我們也要看它的效果。

Q7：一鍵遷移是怎么實現(xiàn)的？是用來做什么的？

A：我們在模型治理過程中有一個很大的痛點，就是發(fā)現(xiàn)下游消費的數(shù)據(jù)不準(zhǔn)或者使用的表沒有保障，我們有一張更好的表可以替代它，但是因為下游消費已經(jīng)形成了消費關(guān)系，所以切換需要投入很多的成本，比如要改成新表，還要去改依賴關(guān)系，改基線保障，同時要做數(shù)據(jù)測試來和之前對比是不是符合預(yù)期，這個動作從前期的通知告訴大家要遷移到改造，到上線涉及到很多環(huán)節(jié)。

所以我們提出一鍵遷移。比如有兩張表，我們會告訴它要切換的新表和老表的字段的關(guān)聯(lián)關(guān)系，通過這個關(guān)聯(lián)關(guān)系自動把下游所有依賴這個表的代碼全部改掉，改完后把血緣依賴也改掉，之后我們可以啟動數(shù)據(jù)測試，把遷移后的代碼跑一遍，從性能到數(shù)據(jù)準(zhǔn)確性的對比都可以產(chǎn)生出來，提交給Owner看切換的對比是否符合預(yù)期。如果點擊確認，代碼就直接發(fā)布上線，這就是一鍵遷移的原理和我們想實現(xiàn)的目標(biāo)，因為只有實現(xiàn)快速的遷移，下游治理才可能流暢。

Q8：阿里或其他公司內(nèi)部有很多的數(shù)據(jù)產(chǎn)品，比如大淘寶業(yè)務(wù)部門和阿里云的數(shù)據(jù)部門 都會做很多數(shù)據(jù)產(chǎn)品，如何協(xié)調(diào)重復(fù)建設(shè)？

A：從底層講我們的計算存儲用的都是阿里云的基礎(chǔ)設(shè)施，所以核心差異點就在指標(biāo)系統(tǒng)、治理平臺或者運維平臺等等是不是一樣的，我們關(guān)注和考慮是不是有重復(fù)開發(fā)這一塊，我理解各個業(yè)務(wù)團的本身做數(shù)據(jù)管理或治理，是有個性化的訴求的，比如我們這次模型治理，評估指標(biāo)雖然通用，但是和原來治理中心的評估是不太一樣的，它有很多我們經(jīng)驗性的東西在里面，需要慢慢轉(zhuǎn)化，所以我理解在不同階段各個業(yè)務(wù)團隊自己去建是沒有任何問題的，當(dāng)各個團隊構(gòu)建的時候，比如說阿里云的產(chǎn)品同學(xué)發(fā)現(xiàn)大家用的都是同樣的方式或者用的都是我的通用能力，他就可以快速把這個能力通過治理產(chǎn)品統(tǒng)一，一旦統(tǒng)一各個團隊發(fā)現(xiàn)產(chǎn)品是很高效很有用的，他就不愿意再投入很多人力去做重復(fù)開發(fā)和建設(shè)，畢竟各個團隊需要考慮成本和效率，如果下沉的產(chǎn)品做的好，后續(xù)就可以實現(xiàn)統(tǒng)一，這是我的理解。

Q9：您做模型治理的技術(shù)難點和亮點有哪些？

A：技術(shù)難點，模型這塊剛才也提到了一些點，第一個就是我們的識別準(zhǔn)確度，比如我們的元數(shù)據(jù)準(zhǔn)不準(zhǔn)，我們在做自動化下線的時候遇到很多阻力，很多下游同學(xué)有顧慮的，直接幫他把表下線，帶來問題怎么辦？這些難點可以通過元數(shù)據(jù)的方式解決。另外我們發(fā)現(xiàn)評估體系也是一個技術(shù)難點，大家可能會覺得這些不屬于技術(shù)，但是對模型的理解和評估本身就是很高門檻，需要很完善的經(jīng)驗在里面，同時有很多一線的實踐在里面才能做到。還有比如剛才提到一鍵遷移本身的技術(shù)難度是非常高的，它涉及到精準(zhǔn)的數(shù)據(jù)識別、自動代碼生成、數(shù)據(jù)測試，所以這些環(huán)節(jié)里難點都是有的。我理解模型治理的亮點是什么？第一個我們在實踐過程中發(fā)現(xiàn)數(shù)據(jù)要做為一個產(chǎn)品去運作，早期我們很少關(guān)注我們的數(shù)據(jù)，上線之后大家用的好不好，頂多感覺到別人說這個團隊建設(shè)的數(shù)據(jù)不好， 這是一個認知。另外我們通過運營的方式去發(fā)現(xiàn)運營動作是非常高效的，以前用了很多技術(shù)手段去推動，但發(fā)現(xiàn)效果并不明顯，但我們把數(shù)據(jù)用來運營的時候，它的效果是非常明顯的，大家接受度也比較高，所以我覺得這是一個亮點。還有我們很多動作管控的自動化，把數(shù)據(jù)做運營這個思路同時結(jié)合比如數(shù)據(jù)網(wǎng)格數(shù)據(jù)編織技術(shù)，轉(zhuǎn)化為治理手段，我理解這是我們做的比較好的點。