具體將圍繞以下4部分展開

• 模型背景&問題
• 2問題分析
• 3治理方案
• 4未來規(guī)劃

模型背景&問題

1.整體情況

首先介紹一下淘系的整體數(shù)據(jù)背景。

淘系的數(shù)據(jù)中臺成立至今已有7年左右，一直未作數(shù)據(jù)治理，整體數(shù)據(jù)生成構成比為：人工創(chuàng)建（22%）+機器生成78%。其中活躍數(shù)據(jù)占比：9%，不規(guī)范數(shù)據(jù)占比：21%。

數(shù)據(jù)活躍以倒三角形狀分布，整體分布比例為ads:dws:dwd:dim=8:2:1:1，分布還算合理。

上圖中下半部分是模型的生命周期，增長和留存情況。淘系的業(yè)務還屬于快速變化中，模型變化比較快。模型生命周期為25個月，模型年增長比例30%，模型留存44%。

2.公共層

公共層兩大核心問題為：

• 首先，公共層表復用性不高。在2014年的時候公共層還比較規(guī)范，但可持續(xù)性不強。隨著時間流逝，業(yè)務增長和變化，復用性就逐年降低。因為大部分的數(shù)據(jù)是應用層做的，他們會開發(fā)自己的公共層，復用性降低，大部分都是無效表。
• 另外，公共數(shù)據(jù)表在各個團隊分布不合理。這是由于數(shù)據(jù)團隊多，為了滿足業(yè)務開發(fā)效率，每個團隊都有自己的公共表，容易出現(xiàn)公共表復用占比低，重復建設的場景。其中淘寶數(shù)據(jù)團隊負責最多的公共數(shù)據(jù)表。

3.應用層分析

應用層的主要問題包括：

• 第一，公共層建設不足或公共層透出不足。隨著時間增長，公共層的指標不能滿足ads層的業(yè)務需要，ads復用指標邏輯沒有下層，引用cdm層的ads表占比逐年降低，引用ads的ads表占比逐年增高。
• 第二，較多的ads表共性邏輯未下沉，統(tǒng)計顯示超過17.63%ads表被下游ads復用。
• 第三，跨集市依賴嚴重，統(tǒng)計顯示，整體跨集市依賴占比為30%，特別是大進口和淘寶數(shù)據(jù)跨集市依賴達到了40%，影響模型的穩(wěn)定性，影響了模型的下線、修改。

問題分析

1.問題匯總

以上這副圖是簡化后的數(shù)據(jù)模型，我們可以發(fā)現(xiàn)存在很多不規(guī)范問題影響了模型的穩(wěn)定性。業(yè)務在快速發(fā)展的情況下，為了快速響應業(yè)務需求，產(chǎn)生模型問題是必然的。日常工作中，數(shù)據(jù)研發(fā)流程大致如下，接到業(yè)務需求，直接引用ODS層表開發(fā)ADS數(shù)據(jù)，待數(shù)據(jù)需要復用的時候就把邏輯沉淀到公共層，同理指標也會有類似情況。主要問題可以歸納為七點：

• 系統(tǒng)臨時表多，只增不刪，對于消費側(cè)影響較大，因為表量巨大，有效比例低，很難檢索到；
• 命名不規(guī)范；
• 公共層過度設計；
• ADS重復建設；
• ADS跨集市依賴；
• ADS共性未下沉；
• ADS穿透依賴ODS。

2.原因分析

從問題分類上看，主要有三大類問題：規(guī)范性問題，公共層復用性問題和應用層復用性問題。

從問題原因上看，主要有四大類原因：架構規(guī)范，流程機制，產(chǎn)品工具，以及研發(fā)能力。

3.模型治理的問題

模型治理的挑戰(zhàn)：

1. 業(yè)務價值不明顯，治理帶來的是長期價值，短期對業(yè)務影響不大。
2. 治理協(xié)作復雜，治理需要ODS、CDM、ADS層多人多團隊協(xié)作
3. 問題治理難根治，容易出現(xiàn)新模型依賴有問題模型
4. 模型平均生命周期不長（25個月）

綜上所述，模型治理的ROI比較低，我們的問題就是如何模型治理才最高效？

治理方案

1.整體方案

基于以上的問題原因分析，我們制定了如下治理方案。

核心策略為以下三點：

1：盤點存量，掌握數(shù)據(jù)的整體情況

2：規(guī)范增量，避免新增模型走老路，重復出現(xiàn)相同問題，考慮到數(shù)據(jù)的生命周期，歷史數(shù)據(jù)可以先不管。

3：日常治理保健康，以數(shù)據(jù)化驅(qū)動長期治理

2.機制規(guī)范

架構分層標準

往年我們關注的是數(shù)據(jù)視角，今年關注的是業(yè)務視角，業(yè)務視角核心訴求主要有四點，交付效率、產(chǎn)出時效、質(zhì)量可靠、成本可控。過去OneData定義了每一層的作用，但每個層次的分工定位不清晰，針對這些問題重新做了清晰的定義。

應用層核心是專注支持業(yè)務，需要考慮研發(fā)效率、交付數(shù)據(jù)口徑一致性和穩(wěn)定性。

通過集市規(guī)范來控制復雜度，通過輕度聚合的中間層確?？趶浇y(tǒng)一，通過扁平化設計確保穩(wěn)定。

公共層的核心是抽象復用來提升效率，需要考慮易用性和穩(wěn)定性。通過規(guī)范和冗余寬表提升復用性，通過解耦來確保穩(wěn)定性。

ODS層的核心是合規(guī)高效，需要考慮接入效率和性能穩(wěn)定。通過工具化提升效率、優(yōu)化治理確保性能的穩(wěn)定。特別是在數(shù)據(jù)達到一定量之后要考慮采用merge的方式接入數(shù)據(jù)。

集市劃分規(guī)范

數(shù)據(jù)集市，是用來滿足特定部門或者用戶的需求，按照多維的方式進行存儲。通過對相似數(shù)據(jù)業(yè)務場景內(nèi)聚進行抽象分類，以降低ADS層重復建設和數(shù)據(jù)管理復雜度，讓應用研發(fā)更聚焦更高效。

集市劃分的原則有以下兩點：

原則一：以業(yè)務場景或者服務對象作為劃分原則，對相似數(shù)據(jù)業(yè)務場景內(nèi)聚抽象進行分類。

原則二：集市劃分需要統(tǒng)一標準，盡量符合MECE原則。

公共層共建機制

在建設公共層的建設過程中，我們通常會遇到以下兩個痛點：

• 應用研發(fā)的痛點：公共層相應效率低。
• 公共層研發(fā)的痛點：如果統(tǒng)一承接開發(fā)工作，涉及的業(yè)務很廣泛，研發(fā)資源不足。

為了解決以上兩個痛點，我們通過以下核心原則來解決：

原則一：公共層開放共建，事后審計治理

應用開發(fā)整理需求，把需要下沉的公共維度提給公共層研發(fā)，公共開發(fā)需求評估。

原則二：以應用需求驅(qū)動，設計開發(fā)共建 以需求為驅(qū)動，拆分出核心模型和非核心模型，核心模型公共研發(fā)負責，非核心模型由業(yè)務開發(fā)進行，共同開發(fā)以提高效率。

原則三：公共層研發(fā)統(tǒng)一運維保障

非核心模型上線并完成相關測試（準確性、確定性、治理）后轉(zhuǎn)交給公共層研發(fā)，由公共層統(tǒng)一運維。

3.智能建模

在數(shù)據(jù)治理中有數(shù)據(jù)規(guī)范與共建機制依然是不夠的，還需要結合自動化工具來提升效率、保障規(guī)范。我們是從以下4個方面入手的（詳情可以體驗DataWorks的產(chǎn)品）：

• 數(shù)據(jù)體系目錄結構化
• 模型設計線上化
• 打通研發(fā)流程（自動化生成簡代碼）
• 對接地圖數(shù)據(jù)專輯

數(shù)據(jù)目錄體系結構化

形成數(shù)據(jù)體系目錄有利于了解掌握數(shù)據(jù)，分門別類的方式降低了大家的使用成本。

首先要對表命名做一些管控，我們做了可視化的表命名檢測器，來確保規(guī)范性。另外，淘系不是一個單空間的數(shù)據(jù)體系，因此要解決跨多個空間的復雜數(shù)據(jù)體系的統(tǒng)一建模問題。

模型設計線上化

改變模型設計方式，由線下設計遷移到線上，通過一些自動化工具，提升效率，保證規(guī)范。

打通研發(fā)流程（自動化生成簡代碼）

模型遷移到線上后，打通研發(fā)流程自動生成簡代碼，生成代碼框架，建表語句，顯著提高了研發(fā)效

對接地圖數(shù)據(jù)專輯

形成相應的地圖數(shù)據(jù)專輯，方便其他用戶使用數(shù)據(jù)。

4.模型治理

打分模型

模型治理需要量化，如果沒有量化全靠專家經(jīng)驗效率是非常低的，我們通過模型的指標形成到表級別的模型分。通過多維度對模型進行打分。

打分機制

精細化的打分機制，針對團隊、數(shù)據(jù)域、核心進行打分，形成相應的標簽。

整體流程

以數(shù)據(jù)驅(qū)動，上圖左邊，以模型評估數(shù)據(jù)為出發(fā)點，通過各個維度對模型進行評估，得到各個域、各個團隊的評分，形成相應的問題標簽。

以產(chǎn)品驅(qū)動，上圖右邊，通過專家經(jīng)驗判斷新上線模型升級搜索權限、下線模型降權限，讓業(yè)務迅速感知數(shù)據(jù)變化，引導業(yè)務。

未來規(guī)劃

應用層效率

在整個數(shù)據(jù)體系中，應用層的數(shù)據(jù)體量是最大的，投入了大量的人力。OneData缺少對應用層的數(shù)據(jù)建設指導，集市高度耦合，給運維效率帶來了不少問題，如跨集市依賴、依賴深度的問題。過去都是以業(yè)務為主導，為了保障研發(fā)效率放棄了部分研發(fā)規(guī)范，以后要完善應用層的研發(fā)規(guī)范，同時通過工具做好研發(fā)效率與規(guī)范的平衡。

架構規(guī)范管控

基于分層標準落地，對研發(fā)過程規(guī)范完善，包括對設計、開發(fā)、運維、變更、治理等規(guī)范進行細化。

目前核心是表命名規(guī)范，對依賴規(guī)范、代碼規(guī)范、運維規(guī)范等管控能力尚不足。

產(chǎn)品工具提效

將繼續(xù)與Dataworks共建。

• 應用層智能建模能力還不能滿足研發(fā)效率要求，因此會繼續(xù)功能提效；
• 數(shù)據(jù)測試功能集成；
• 數(shù)據(jù)運維功能升級；
• 事中數(shù)據(jù)治理能力構建（開發(fā)助手）；
• 事后治理能力提效（批量刪除、主動推送優(yōu)化等)；
• 數(shù)據(jù)地圖，找數(shù)用數(shù)提效。

問答環(huán)節(jié)

1：核心公共層的建設是自頂向下還是自底向上？

采用的是兩者相結合的方式。以需求為驅(qū)動，沒有需求就會導致過渡設計，在應用層有復用之后再下沉到公共層，這是自頂向下的。 在公共層設計階段是面向業(yè)務過程的，這時是自底向上的。

2：多BU公共層是否需要統(tǒng)一規(guī)范？怎么去做？怎么量化價值？

需要做統(tǒng)一的規(guī)范，規(guī)范利于數(shù)據(jù)流通，才能體現(xiàn)數(shù)據(jù)價值 。但是具體怎么規(guī)范需要具體去看，如電商、本地生活，業(yè)務和目標不一樣，很難做到統(tǒng)一的規(guī)范

3：怎么判斷指標需要下沉到公共層？

公共層的開發(fā)是需要成本的，是否需要下沉到公共層核心是看是否需要復用，可以從兩個方面入手。

專家經(jīng)驗判斷：如電商交易環(huán)節(jié)數(shù)據(jù)，這類數(shù)據(jù)是核心數(shù)據(jù)，是要建設到公共層的。

事后判斷：如玩法之類的業(yè)務穩(wěn)定性不強，那一開始不需要下沉到公共層，避免過度設計，事后再去判斷是否需要下沉。

4：關于表、字段的命名規(guī)范，是否需要先定義好詞根再開發(fā)？

需要分開看。對于公共層設計到的業(yè)務過程是有限的，對于公共部分要先定義好再開發(fā)。對于應用層，維度采用的是總建架構所以還需要先定義，對于指標特別是派生指標是多的，不建議先定義在開發(fā)。

5：如何解決口徑一致命名不一致，或者口徑不一致或者命名一致的場景。

模型是演變的。對于應用層，80%都是自定義的，第一次出現(xiàn)的時候都是不標準的，這部分如果采用先定義后開發(fā)的方式，效率是很低的，只有在下沉到公共層的時候才能夠管控。對于公共層，能做的是保障核心指標90%的規(guī)范與定義統(tǒng)一，剩下的那部分也無法保證。

6：跨集市依賴下沉到公共層的必要性？

短期來看，是沒影響的，新增效率高。

長期來會給數(shù)據(jù)的運維、治理帶來很多影響，在數(shù)據(jù)下線、變更、治理過程中不得不考慮到下游依賴，會影響全流程的開發(fā)效率。