分享嘉賓：何會會?有贊?數據開發工程師

編輯整理：xiaomei

出品平臺：DataFunTalk

導讀：今天和大家分享一下數據地圖相關知識，以及有贊在數據地圖方面的實踐。主要分為4個部分：

數據地圖的背景

數據地圖是什么

有贊數據地圖實踐

總結和展望

01數據地圖的背景

1. 數據地圖背景

每個企業都有和數據相關的工作過程，如數據采集、數據開發、數據搜索、數據管理、數據分析、數據挖掘，還有故障排查、鏈路優化等，這些都是和數據相關的。在這些工作過程中通常會遇到很多痛點：

數據流轉鏈路不清晰，想找數據時找不到想要的數據；

管理數據時，無法高效地進行數據管理；

發生故障時，故障排查效率比較低；

想優化一條鏈路時，比較困難。

數據地圖是以解決這些痛點為基礎研究開發的。

2. 數據地圖的目標

數據地圖主要是解決以下幾個問題：

讓用戶能夠高效地能找到想要的數據；

能夠方便地查看多種多樣的數據血緣信息；

能夠實現高效的數據管理；

高效地應對故障，比如在故障排查時能夠快速評估故障的影響面以及恢復時間；

能夠根據用戶不同需求場景看到不同的鏈路視角。

02數據地圖是什么

為什么叫數據地圖？數據地圖其實就是“數據+地圖”。地圖大家都不陌生，如高德地圖，具有找地點、路徑分析、搜索周邊相關、地點管理等能力。數據也具備獨立特征，包括類型全、數據是流通的不是孤立的、數據生命周期比較長。

數據的特征加上地圖的普遍能力，就構成了數據地圖的獨有能力，包括：數據搜索，用戶可以搜索想要的任何數據；數據高效管理，可以高效的管理數據；數據分析能力，數據路徑分析的能力，比如血緣查看、關鍵路徑排查。

03有贊數據地圖實踐

接下來，從數據全鏈路、數據搜索、數據管理、數據鏈路分析四個方面介紹一下有贊數據地圖實踐。

1. 數據全鏈路

之所以稱為數據全鏈路，是因為其覆蓋數據類型、任務類型、平臺類型、元數據類型、血緣類型都比較全。其中，元數據包含了基礎元數據，技術元數據，趨勢源數據、血緣信息；血緣類型實現了表表血緣、表任務血緣、字段血緣。基于強大的基礎采集能力，構建了上層的數據搜索、數據管理、鏈路分析等應用。有贊數據地圖對各個平臺采集的數據進行抽象，抽象成表和任務模型進行統一管理，完成了從業務到業務的閉環。

2. 數據搜索

數據采集、全鏈路構建完成后，就要對數據進行高效搜索構建。數據搜索的目標是使找數據更精確、更容易。

如何做到找數據更容易？找數據是技術人員和業務人員經常會面對的場景，之前是根據關鍵字和技術元數據直接找數據，但業務人員不懂，找數據就不方便。因此從業務的角度，如業務過程、業務實體方面，如何讓業務人員更容易找數據。

解決數據更精確的問題，首先匹配的內容是比較廣泛的，包括表、任務、標簽、業務指標、文檔、商業智能的報表等都是有贊匹配的內容，見截圖。在匹配內容符合基本查詢條件后，把最想找的數據優先排在前面。實現數據優先排序，是根據搜索結果項進行打分，分數較高的排在前面。打分會包含加分項和減分項。加分項包括當前owner、下游數越多、質量分越高、訪問次數越多、公共層的表，均是作為加分項優先展示；減分項則包含設置了替換表（該表后續不再維護或會被新表替代）、臨時表，均為不推薦表，作為一個減分項。每項均設置一個相對應的權重，最終得出分數進行排序，將分數高的優先呈現給用戶，實現找數據更精確，更匹配用戶搜索的訴求，這是有贊對于數據搜索的優化。

3. 數據管理

有贊采用數據專輯的方式進行數據管理，類似歌曲專輯一樣，按不同維度對數據進行劃分，實現對數據的分類管理。用數據專輯對數據進行管理有4個好處：

結構化管理數據的方式，解決Word、文本編輯器、webExcel、shimo等非結構化數據管理方式后期使用不方便的問題；

協作更加方便，可進行點贊、分享、實時添加/刪除數據、多人協作；

管理維度多樣化，可從業務維度、優先級維度、重要性維度、治理維度、用途維度、其他特征維度等對數據專輯進行劃分；

數據專輯對表批量管理，可對表設置權限、下線、核心表鏈路保障、業務拆分實現專輯表數據的拆分。數據專輯是在不同場景下非常好的數據管理模式。

4. 數據鏈路分析

① 血緣查看

可以自由查看數據的血緣。數據血緣的種類比較豐富，包含表表血緣、表任務血緣、字段血緣。表的上游或下游個數都會很多，這種情況下想要找到用戶比較關注的上下游就會比較困難。有贊做了很多優化的體驗，最上游&最下游的快捷方式，為用戶提供只看ODS層、業務層最上游的表或只看最下游的表；聚合查看，滿足當上游或下游個數非常多的情況下，按照庫、owner、數據類型、表類型進行聚合，快速查看用戶關注的表；節點搜索，針對節點進行關鍵詞搜索；節點排序，按照表名的字典順序進行排序，有助于用戶快速定位表。

② 異常分析

異常分析，當目標表或業務表出現異常時，需要排查原因，就可以用到異常分析的場景。當前異常會分三種情況，電話告警、表未產出、規則失敗。在發生異常時，需要以目標表為源頭，向上溯源找到所有有異常的表；以有異常的表為源頭，經過一些列的剪枝優化，將相對簡單的異常路徑展示出來。

剪枝優化是在血緣匯總信息上下游數量比較多的情況下，如果將所有的點全都展示出來會很混亂，要對異常節點到目標表的所有的路徑進行剪枝。

剪枝的目的是，減少圖中非必要節點和邊的數量，這樣異常路徑看清來會很清晰。

優化剪枝的2個關鍵步驟：

找到要剪枝的起點；

下游選擇的策略，包含上游個數最多的節點策略和最靠近目標表的策略。當前有贊的選擇策略是上游個數最多的節點。

針對有贊當前下游選擇的策略，異常分析剪枝算法為：

找到上游所有有源頭的表，看是否有下游，如果沒有下游即為目標表，直接返回；如有下游且下游個數為1，返回該下游；如有下游個數大于1，查看下游節點是否有異常節點，如有異常節點，返回下游節點異常集合；如果下游節點都為正常節點，則查看是否有待剪枝的節點，如有則返回下游待剪枝節點集合；如無則找出下游節點里面上游最多的節點，查看是否成環，如未成環則表明正常直接返回；如成環則將該下游節點從下游集合中拿掉，再找出下游節點里上游最多的節點，如此往復，直到不成環返回。

基于該策略目前效果是明顯的，可從1000多個節點剪枝到幾十個。

當前策略是以減少節點個數為目標，而最靠近目標表的策略是以減少邊個數為目標，兩個策略側重點不同。

③ 影響分析&產出時間預估

影響分析&產出時間預估實踐，其場景是當核心表出現故障時，需要快速評估一個表的影響面和恢復時間。其核心流程是向下評估影響面，向上預估產出時間，根據上游表的產出時間預估出本表的產出時間，其算法在下面詳細介紹。

首先解釋一下運行時長的概念，有贊中運行時長取的是最近7天的中位數，來減少特殊情況造成的不準確問題。

其預估產出時間算法為：

如果當前節點任務已經完成，預計完成時間=當前節點實際完成時間；如果當前節點尚未完成，則查看當前節點關聯的任務是否正在運行，如果關聯任務在運行中且時長嚴重超出歷史運行時長，則預計完成時間=當前時間+歷史運行時長+1h處理恢復時間，作為該表的預計完成時間，該公式是由有贊經常處理故障的數倉及其他人員共同商討總結的算法；如果當前運行時長正常，則預計完成=實際開始時間+歷史運行時長；如果當前節點已運行過但運行失敗，無法預估產出時間，返回-1，需要人工重啟；如果當前節點任務沒有失敗，并且不在運行中，表明該節點任務尚未運行，則查看是否存在上游節點，如果有上游，獲取其上游所有節點的預計產出時間，如果上游有不可預估的情況，那么產出時間無法預估，返回-1；如果上游預計產出時間都可預估，則該節點的預計完成時間=Max（上游產出時間，歷史開始時間，當前時間）+歷史運行時長；如果沒有上游，說明該節點為源頭節點，如果當前時間＞歷史開始時間，說明節點未正常啟動，無法預估產出時間，返回-1，需要人工啟動發起調度；如果當前時間＜歷史開始時間，說明節點未調度，則預估完成時間=歷史完成時間。

預估產出時間算法雖然復雜，但在有贊實踐過程中發現，預估產出時間與最終產出時間是很接近的，目前是有贊比較好的一個預估產出時間的算法。

④ 鏈路優化

對數據產生的鏈路優化實踐，在表成本太大、鏈路太長、產出時間太晚等情況下需要進行鏈路優化。有贊目前已針對優化表產出時間場景開展了相關實踐，其鏈路優化步驟為：

先找到關鍵路徑（在這里關鍵路徑是以當前表為葉子節點，向上找直接上游里最慢的節點，再找最慢節點組成的路徑，稱之為關鍵路徑），開展關鍵路徑節點的時間進行優化，表的產生時間會往前提；

如關鍵路徑找到后發現節點上游都沒有問題，則查看表自身任務的啟動時間是否合理，去優化表任務的啟動時間；

如發現表無法優化了，可考慮表是否可以替換。根據字段血緣來看，產出最晚的上游表的被使用了哪些字段，根據字段血緣來看目標表是否用到這些字段，如果未使用相關字段，則可創建一個新表，將產出時間最晚的字段去掉，從而要目標表去引用新表，將最影響產出的字段去掉，達到鏈路優化目的。

⑤ 數據監控保障

在上游發生變化時，如何通知下游？有贊有2個措施開展數據監控保障，包括定時任務和手動觸發：

定時任務是掃描數據開發平臺發布到調度中心的任務，檢測任務語法是否通過、任務使用的輸入表是否存在、輸入表使用的字段是否存在，提前預知并通知下游用戶，避免晚上起夜處理或對數據問題后知后覺。

手動觸發是在數據治理工作人員現有表要用新表或字段替換時，可手動觸發檢測表對下游任務、下游表或下游字段的影響，在確定沒有影響情況下，再改變現有表情況。

04總結和展望

1. 總結

交互體驗方面，解決頁面卡死問題，使頁面交互更加流程，接口RT99%以上均小于1s。

使用情況方面，增加了分析場景、開展日常運營工作，使得UV從90升到130、PV從2K升到了3.5K。

工作提效方面，提效1~3小時。

數據類型方面，當前支持29種數據類型、16種任務類型、覆蓋平臺數4個以上。

2. 展望

① 底層存儲方式重構

目前血緣關系存儲使用的是關系數據庫，后面會使用圖數據庫推理引擎能力對底層存儲進行重構，使鏈路分析場景，更高效、更準確。基于圖數據庫推理引擎，拓展數據地圖能力。

②??更多場景支持

數據地圖有更多的場景支持，比如，降本的工作；成本、質量、穩定性方面的鏈路優化，有更多場景來支撐；質量的保障，對下游應用的質量保障，可考慮使用數據專輯對數據地圖數據進行批量保障，支持更多的鏈路場景。

③ 模型可視化

引用更多豐富的可視化組件，使數據模型和業務模型更直觀地呈現出來，使理解數據和業務更加方便。業務模型可通過業務模型可視化實現對整個業務流程預覽，每個業務過程都有對應的事實表、維度表、負責人等信息，在看數據和理解數據更加方便。比如有贊入職的新同學，對微商城業務及具體產品流程不了解，可通過業務模型可視化了解到：商家先瀏覽-再下單-等待商家支付-等待賣家發貨-等待買家確認收貨-交易成功，這個為微商城核心業務流程的鏈路，新同學看到這個業務模型，對有贊業務理解更加方便。ER模型是MySQL庫模型的可視化。數據倉庫中最常見的星型模型&雪花模型，可通過圖形化的方式更加容易理解模型。

05精彩問答

Q：有贊中字段血緣關系的解析是怎么實現的？每個字段的標簽梳理是怎么做的？

A：有贊中團隊分工比較細，字段血緣的解析是由數據基礎平臺工作人員負責解析，有贊地圖工作人員負責調用離線服務獲取字段血緣。

Q：數據治理效果中提到數據開發同學的起夜率，是一個強考核指標嗎？該指標比重是多少？

A：數據治理要有一個效果指標來衡量工作的重要性，不是為做功能而做功能，而是真實的提供大家工作效率，減少一些起夜率，這些指標是有贊自己定義的。

Q：平臺業務人員主要是哪些內容來解決什么問題？平臺業務人員發現指標有錯，如何從血緣上追溯呢？如數據產品經理發現數據有問題，和數據團隊配合的鏈路是怎樣的？

A：關于平臺的問題，有贊數據血緣是接入了4種平臺，數據開發平臺、實時開發平臺、商業智能、指標庫。其中，數據開發平臺，開展日常的數據開發任務，包括離線、實時開發。商業智能，即BI報表。指標庫，提供給外界商家用的數據，顯示商家后臺有哪些指標，這些指標用了哪些表，都是從指標庫配置的。

如數倉核心表出了問題，可快速定位到它的影響面。有故障產出時，通過建立溝通群的方式，產品經理比較在意的商家數據恢復時間問題上，有贊有預估產出時間功能，可秒級回復商家數據什么時候恢復的問題，采用這種方式實現各團隊配合。