一、背景及問題

模型建設的要求主要有三個方面：效率快、成本省、質量穩。

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

結合多年的數據模型開發和管理經驗，總結了四個“1”：

一套規范體系，要有一套方法論來支撐如何構建模型、如何使用模型。

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

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

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

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

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

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

• 數據規模始終在膨脹。
• 出現了一些穩定性問題，因為很多數據需要強保障，其穩定的產出和較高的質量是比較重要的。
• 我們發現隨著數據量的增長，模型的消費效率在逐漸降低。

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

模型具體出現的問題包括：

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

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

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

④ 很多非數據研發角色的同學在數據模型的開發和使用過程中出現了不規范的問題。

集團內部數倉分為三層：

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

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

③ 第三層是應用層，偏向分析和使用場景，比如一些分析決策場景及產品數據，所以應用層是面向終端消費的。

其中的問題如下：

① 公共層的引用不足，應用層大量自建中間表。我們用兩個核心指標去看：

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

② 來源表也有一些問題：

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

在決策看數、業務洞察、數據產品幾大核心板塊里，缺乏統一的數據架構規范，例如數據的分層占比、命名規范引用情況都不是很理想；公共層早期偏向于支持決策型數據，缺乏對業務分析型數據的建設，數據的消費效率不高。

二、解決方案

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

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

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

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

• 提高優質數據供給，包括規范培訓推廣，讓大家更好地理解和使用；構建完數據后通過專輯的方式使其能夠快速上架，讓下游看到數據；專輯配備好說明和引導以幫助大家更好的理解。
• 消費提效方面，對核心數據做專輯的上下架和運營宣講；檢索數據時快速推薦高質量數據，同時做一些引導，比如在申請權限時，申請的是一張底層表，而公共層已經有比較高質量的表，就可以在權限審批時引導他去申請更好用的表；還可以啟動一些專項治理，比如網格化的垂直專題治理。
• 優質供給和消費提效解決的是數據的生產關系問題，我們判斷模型的復雜度有兩個核心點，一個是規模，規模越大復雜度就越高，另外一個是數據消費關系，消費關系越復雜越趨于網狀結構其復雜度越高，所以在規模控制上我們會做無效表下線、同源導入的管控。

基于這些治理策略，我們組合一些領域專題包括：

• 公共層的增厚，通過網格化的專項把模型做得更好。
• 應用層做提效操作，構建復用邏輯保證消費效率。
• 無效表下線、同源導入治理和數據交接等。

為了做這些治理，我們也需要更好的產品和工具來支持，我們和DataWorks團隊深度合作，構建了基于數據開發的治理產品，比如：

智能建模，它解決的核心問題就是模型設計和模型開發問題，從設計環節保證它的高效性和規范性；開發環節即開發模型寫代碼的環節，會直接把我們的優化建議和發布管控在開發側產品化。

• 數據地圖，在展示數據的產品中我們開發了專輯功能，數據通過專輯上架的方式展示給下游；通過引導推薦讓大家更好地發現高質量的數據。
• 構建數據治理中心的能力，比如優雅下線，快速將無效表下線；數據治理中心管控的配置化，使其快速分發至各個產品。

以上就是整體的解決方案。我們在統一規范、公共層的覆蓋率提升、無效表的下線、產品的能力等方面制定了治理目標。

三、模型治理

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

1、無效表下線和ODS同源導入治理

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

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

同源導入治理這塊相對比較流程化：

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

2、數據交接

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

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

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

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

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

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

4、增量管控

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

這樣我們可以實現更加精準的管控，同時因為我們使用的數據治理中心和DataWorks各個產品是聯動的，可以根據管控規則所涉及的產品環節快速實現全面漏斗分發。

5、產品化

接下來看一下模型治理產品化的幾個產品。

第一個是用于模型設計的智能建模，我們早期的規范標準其實設計是沒有問題的，但是在實施過程中很多模型設計和開發沒有一個很好的工具去承接，很多時候是做離線的模型設計，然后做線下評審，評審完再去手寫代碼提交到線上。這個過程很難管控設計規范，另外也比較低效。

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

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

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

6、能力沉淀

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

首先是一個規范體系。早期我們的模型規范涉及的環節比較少，只有一個比較粗的方法論，我們需要把實踐過程中的經驗也體現在這里。

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

7、總結

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

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

四、未來規劃

最后介紹一下后續的一些規劃。

1、供給消費提效

從供給側提升模型設計、開發和上架的效率，能夠快速把優質內容開發出來；另外在消費側也要做提效，包括數據的運營推薦。

2、架構規范管控

提升規范管控能力，將更多管控規則通過產品化分發到各個研發環節。

3、評治一體

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

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

五、Q&A

Q1：消費關系是什么？

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

Q2：模型優雅下線的優雅體現在哪里？如何實現？

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

Q3：同源導入的識別率，準確度高是因為元數據完整還是在一處配置的，還是有其他的方法？

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

Q4：模型的管理與治理與業務的敏捷查數用數是怎樣平衡的？

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

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

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

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

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

還有我們現在開發數據還是相對比較低效的。我們先了解需求和業務，然后去做模型設計，開發。將來是不是有一種方式，只要通過結構化的表達把數據描述清楚，代碼或者指標就可以快速計算出來，如果能夠實現，那么后續的治理就不需要了。只需要從底層的機器層面就可以實現代碼統一和邏輯最優，不再需要投入很多人力成本或設計去做下線和口徑調整遷移。但是因為大模型本身需要時間迭代，所以我們也要看它的效果。

Q7：一鍵遷移是怎么實現的？是用來做什么的？

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

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

Q8：阿里或其他公司內部有很多的數據產品，比如大淘寶業務部門和阿里云的數據部門 都會做很多數據產品，如何協調重復建設？

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

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

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