編 輯：何會會
整理：xiaomei
最近忙到原地起飛！白天忙完，晚上開會，一刻都不停歇。前兩天有個哥們問我是不是資料地圖的高手，我本來想把之前寫的資料地圖的文章發給他，結果一忙，就忘記了。
今晚突然想起來了，結果忘記哥們是哪位了
不管如何，也響應一下吧。
今天請有贊的何老師來分享一下有贊在資料地圖方面的實踐，内容絕對詳實，簡直可以拿去直接開發了！
内容主要分為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報表。名額庫，提供給外界商家用的資料，顯示商家背景有哪些名額，這些名額用了哪些表，都是從名額庫配置的。
如數倉核心表出了問題，可快速定位到它的影響面。有故障産出時，通過建立溝通群的方式，産品經理比較在意的商家資料恢複時間問題上，有贊有預估産出時間功能，可秒級回複商家資料什麼時候恢複的問題，采用這種方式實作各團隊配合。
文章看完了，我是老彭。怎麼樣？何老師是不是非常nice？内容是不是賊幹？趕緊點個贊感謝一下何老師吧~~~
最後，把何老師的美照奉上！