中通快遞數據治理實踐

導讀： 本次分享的內容是中通快遞在數據治理方面的實踐，主要會從如下四個方面展開：

• 中通簡介

• 數據治理驅動力 & 目標

• 數據治理實踐

• 未來規劃

分享嘉賓｜薛世敏 中通快遞 資深架構師

編輯整理｜盧卡

出品社區｜DataFun

01 中通簡介

中通快遞成立已經有將近 20  年時間，是一家以快遞爲主的大型綜合物流服務企業。除了快遞之外，還有國際、快運、雲倉等等的一系列業務。根據今年二季度的數據來看，目前日均單量近 7000 萬，市場份額已經達到了 23%，位居行業第一。

除了及時把這麼多包裹送到客戶手中，客戶滿意度在 “通達系” 中也名列前茅。菜鳥統計各承運淘系貨物的快遞公司的綜合能力的指標，包括服務質量、時效、信息完整等方面，中通也是表現非常優異。

 快遞行業的主要業務流程包括收、發、到、派、籤五個環節。用戶下單後，快遞小哥會上門收快件，再由網點統一把件交到轉運中心。轉運中心做分揀之後，再通過合理的路由把件轉運到末端末中心，末中心再將件分配到網點，然後由快遞小哥進行派件，最後由客戶進行簽收，這樣一個流程基本就結束了。

02 據治理驅動力 & 目標

隨着物流行業也由傳統行業向數字化、智能化新模式的轉變，中通爲了在激烈競爭的市場環境中保持領先的地位，也在積極地進行數字化轉型，在這個過程中對數據的依賴程度會越來越高。

業務人員在日常使用數據過程中還是有一些痛點的，主要的表現：

第一，數據資產缺乏盤點。當前核心系統的主要數據已經採集到數據倉庫，但是在日常的業務分析中經常需要向業務系統瞭解需要用到的數據在哪裏。總得來看對數據資產還是缺乏整體盤點，公司主要有哪些數據，都分佈在哪些系統中，哪些數據已經採集到數倉，哪些還沒有入庫，還有待進一步梳理。

第二，數據標準化建設不足。數據標準會貫穿數據管理的全流程，雖然我們制定了一系列規範文檔、制度文檔、流程文檔等，但有了標準並不代表數據標準化已經落實了，像指標數據的標準化、主數據的標準化等方面還需要進一步的提升。

第三，數據質量問題。數據質量是數據的生命線，差的數據質量嚴重影響數據分析的結論，有的可能對決策產生誤導，如髒數據、維度數據缺失或變更等一系列問題，都需要進行治理，比如掃描信息缺失，導致運單路由軌跡不準確；數據維度值變化，統計某個渠道業務量陡增或驟降。

第四，數據模型待完善。目前已經建設了一批公共寬表，但是隨着業務發展，有些時候業務方需求比較急，開發直接從基礎明細表取數，導致寬表複用度降低；爲了追求開發效率，團隊內部也存在煙囪式開發現象，導致一些 ST 層共有邏輯沒有下沉。

除了上述問題，快遞公司還會積累大量收件人、發件人的地址、姓名、電話等信息，這些信息都需要進行有效的管理。此外，國家也出臺了《數據安全法》、《個人信息保護法》等法律法規，需要我們做好數據分級分類和對數據合規安全的訪問，同時保障數據保密性、完整性和可用性。

數據治理的核心是希望把數據變爲數據資產，讓數據資產在數據驅動業務過程中發揮價值。最主要期望能夠實現的目的是：

1. 提升數據質量

2. 解決數據孤島問題，實現數據匯聚聯接

3. 掌握數據資產現狀

4. 保障數據安全合規

5. 逐漸釋放業務價值，如在降本增效、提升客戶滿意度等方面發揮作用

根據物流行業的發展趨勢以及公司數據化轉型的要求，基於打造數字綜合物流服務的戰略規劃，我們也建立了一套比較成熟的數據治理體系，主要包括戰略、機制、專題和平臺等等方面。

（1）機制層面

公司近年陸續組建了順應數字化團隊協作模式的組織架構，基於一把手工程思路，專門成立了數字化支撐團隊，並在各業務部門設置專門的崗位，清晰明確了的各部門的數據管理責任; 同時爲規範推行數字化工作開展，有章可循，我們 IT 部門組織各業務部門共同編寫數據管理政策、制度、細則、手冊共 4 個梯度的數據管理辦法文檔，目前正在推廣執行中。 

（2）專題方面

聚焦數據標準、質量、元數據管理、安全及生命週期等一共 8 個專項服務，全面提供數據支撐業務；在具體實施層面，我們會圍繞 “盤”、“規”、“治”、“用” 四個方面展開。

• 盤：發現業務痛點，調研業務部門，梳理業務流程，分析數據問題，數據盤點，收集數據字典與數據規範；

• 規：定義數據標準，確認核心系統，定義數據模型，確定數據流向，制定數據質量規則

• 治：跨數據域的數據整合拉通，形成單一數據視圖，進行數據質量檢核，並對數據質量實時監控和預警；

• 用：爲業務部門提供生產經營指標分析服務，提供數據快速檢索與數據資產全景可視服務；

專題主要包括我們經常會提到的數據標準、數據質量、模型、主數據等八大塊內容。

（3）平臺層面

數據治理離不開平臺的支撐， 公司也通過自研包括元數據、數據質量、大數據等平臺等來支撐治理工作的展開。

數據治理工作需要組織架構來保證。在管理層面有數據治理委員會，數據管理辦公室負責實際開展工作，主要負責標準規範的制定、協調某些需要升級的數據質量問題。接下來的執行層面有數據架構組、數據質量組等等，他們負責具體的治理工作。

03 數據治理實踐

上邊提到數據治理主要包括八大塊內容，實際工作中每一塊我們都有涉及。由於時間關係，重點挑其中三塊：數據質量、模型、元數據做介紹。

1. 數據質量治理

 數據質量是數據治理的核心，也是基礎工作。數據質量通常會從及時性、真實性、唯一性、完整性、有效性、一致性等六個維度來衡量。

日常工作中涉及到數據質量的問題通常會有數據重複、波動值過大、異常值、操作不規範、數據未採集等。

舉一個實際工作中遇到的運單掃描的例子。在收、發、到、派、籤的整個環節，一般是要求都要業務人員都要掃描，但實際操作可能不規範導致某些掃描環節缺失，那就會導致運單的路由軌跡不準確，進而影響到數據分析。

種種數據質量問題會引起業務方對數據不信任、無法做出正確決策、不能精細化運營等問題，這就需要有一套數據質量解決方案。我們的方案包括四方面：

第一，數據質量問題發現。藉助數據質量管理平臺，對數據從入庫到後續加工的整個鏈路進行監控，來發現業務系統、開發加工過程中的一系列問題。另外還需要通過下游使用數據的環節來發現一些深層次的數據質量問題，如通過業務專題分析來發現數據質量問題。之後再以業務驅動的方式推動數據質量問題的解決。

第二，評估分析。主要是分析問題產生的原因。在解決問題的時候不能僅停留在表象，需要分析問題產生的根本原因，從源頭解決數據質量問題。當評估數據質量問題需不需要去解決時，還需要考慮治理成本和收益。

第三，數據質量問題的解決。數據質量問題通常來說會考慮從業務、技術、流程等方面去考慮推動解決。

第四，數據質量驗收。即驗證相關問題是否得到解決。

對於數據質量的監控，主要包括三個環節：

第一，結合數據質量衡量的六個維度及日常工作中發現的數據質量問題，配置相關規則。

第二，在數據加工的各個環節設置檢查點，比如從 ODS 到 DW，從 DW 到 DM 等環節。如在 ODS 的檢查點設置中，可能會包括數據源抽取記錄的檢查；在基礎層會有空值、編碼值、一致性、重複性等問題的檢查 。

第三，輸出異常結果，進行告警處理。

看一個具體的監控案例。當用數據質量監控平臺對一張表進行監控時，我們可以選擇配置相關規則，可以直接採用預置的規則模版，也可以自定義規則。也可以設置檢查規則的屬性，比如是強規則還是弱規則，此外對告警的屬性也可以進行設置。規則配置完成以後在實際檢測過程中，如果某個檢測規則違反了強規則，則其會阻斷下游任務的執行。

告警升級機制方面，強規則一般會提供電話告警。如果說由於疏忽或其他情況導致任務負責人未及時處理，那麼會升級到 leader 來推進問題的解決。

告警信息是點對點，我們對告警信息會進行聚合，形成質量全貌信息。比如每天早上來上班，我就可以打開質量全貌信息，看一下當天執行了多少檢查規則，有多少是有問題的。如果有問題可以繼續分辨哪些是真有問題，哪些是沒問題，有問題的是否已經解決。如果檢查規則設置不合理，我們會進行優化，逐漸使得告警規則更準確，形成質量監控全面、準確的閉環。

還有一些深層次的數據質量問題可能通過我們常規的檢查手段並不一定能發現，這時就需要藉助下游數據使用來解決，一般我們會結合業務專題分析推動數據治理。在專題分析過程中，可能會發現種種數據質量問題，比如數據未線上化、數據採集不完整等，之後我們會針對具體問題制定有效措施，同業務方、業務系統的產品研發共同把問題解決。

以業務驅動方式推進數據質量建設取得了若干成果：

• 推動 100% 計費政策數據線上化，結算時效提升至 T-1

• 推動業務系統採集關鍵操作環節數據，支持更細粒度的業務分析

• 協調業務部門細化各類操作規範，操作數據質量進一步提升

• 完善業務系統功能

2. 數據模型治理

簡要先介紹一些快遞的業務特點。快遞屬於服務性行業，非常注重運營，最主要關注的是時效、服務、質量三方面。行業的情況會導致數據有如下特徵：

• 數據生命週期比較長

核心運單流程生命週期短則 1 天，長則 3-5 天，異常單可能會更長。財務類週期結算長，涉及政策財經類數據計算回刷時間 1～3 個月；

• 業務流程複雜

運單核心流程從下單到簽收涉及業務流程較爲複雜及運單攬派籤主流程外，還涉及結算、客服等額外流程；

• 對象多數據大

數據由不同業務對象如快遞員、客服、分級員等多角色產生，非常依賴他們操作的規範性。另外，我們日均單量七千萬，每一單都需要經過收發到派籤的操作，數據量級可想而知；

• 數據精細化運營

當前快遞行業競爭激烈，在此背景下更需要精細化運營，因此對數據依賴非常強。公司通過數據化運營進行成本管控，運單時效管控，服務質量管控，已成爲公司日常運營常態，因此對數據準確性，時效性要求很高。

接下來介紹一下我們數倉的當前現狀。首先，我們按照業務板塊劃分出運單、財經、客服等 27 個一級主題域。其次，核心數據集中在 DW 和 DM 層，爲下游提供通用的公共服務。第三，當前我們是 PB 級數據規模，計算任務 1 萬多，通過上千臺集羣的規模支撐了集團全領域業務線。

隨着業務持續發展，項目也在快速迭代。數據建設不規範等方面的原因導致了複用性不高、時效不穩定等，自然而然也會引起資源危機等問題。

爲此我們制定了一整套的方案，主要包括三方面：

第一，制定規範。制定諸如開發規範、分層使用規範，並嚴格要求各類數據開發和使用團隊遵守；

第二，過程管控。以需求爲驅動，將設計、開發、上線等數據建設各個階段進行過程管控；

第三，模型分級。根據應用的重要程度來反推、梳理哪些是重要的模型和應用，將重要性高的模型和應用納入重點治理範圍，重點關注他們的複用性、實效性。

複用度治理方面，主要包括三塊：

第一，流程規範的制定。我們會制定相關規範來要求數據參與者都遵守。通過制定規範，應用開發團隊和數倉團隊進行分工，且在業務需求評審環節要求數倉團隊介入，可以更早地評估是否需要設計相關模型來支持應用團隊的數據開發；

第二，過程線上管控。在數據使用、模型設計、任務上線等環節都進行線上管控，由 leader 審批把關；

第三，核心數據識別。最主要是識別出四類核心數據，最主要關注核心模型和核心應用，並對這類數據我們重點關注、重點保障，優先保障其核心鏈路上數據的準確性和及時性。

在數據複用度治理方面還需要關注時效、引用度、需求響應及時性之間的平衡問題。我們不能爲了提高模型的複用度就任意的增加維度、指標，否則可能會導致下游應用產出障礙的問題。也不能說某個指標下游飲用不多就增加到寬表中來，一定要考慮平衡性的問題。

除此之外，我們還需要考慮響應的及時性。在流程上我們希望儘量做到規範，希望應用層都飲用模型、寬表的數據。在實際工作中，有時爲了保證 “業務需求第一” 的原則，有可能允許應用層先從明細層取數進行開發，模型同步進行迭代優化，後續再讓應用層把需求切換回來。

數據模型的治理也達成了一些成效，主要包括四個方面：

第一，研發效能更密集，核心領域寬表使用佔比較高，數據研發時效比原來提效不少。

第二，數據口徑更一致。

第三，資源整體可控。

第四，時效更加穩定，計算任務在 6 點前可以完成總體的 80%，關鍵任務完成 100%。日常任務時效能達到業務期望。

3. 元數據治理

我們的數倉中有上萬張表，無論是對數據開發者還是業務使用方，都會面臨無從下手的情況。他們在日常使用過程中的痛點最主要可以歸納爲有什麼、在哪裏、怎麼用三類。

比如一個運單，有收件人、發件人、運載軌跡、費用等各種信息，但具體有哪些表就不是很清楚了。在實際的工作中，分析師也經常會問有沒有哪塊的數據，在哪裏之類等等。哪怕是找到表之後，也會疑惑數據是如何加工的，如果要用的話有哪些限制條件等等問題。

基於對現狀的梳理及現階段要達成的目標，我們希望能實現數據表、報表、數據指標的聯動解鎖，所以最主要的就是梳理這三方面的信息。

數據表我們最關心的可能是主題、子主題、概要信息等。我們根據業務現狀及未來發展趨勢，對主題進行調整優化，細化了二級主題，然後對這些表分門別類地進行梳理。概要信息主要包括表的處理邏輯、重要字段等信息。

我們可能不僅僅只是梳理我們大數據產品的一些報表，也包含在業務系統中的各種報表。因爲在日常中，經常會遇到業務同學問業務系統中的某個報表對應的後臺表是哪個的問題，他們更希望可以把表拿過來後再加工，或者說做一些統計分析等等。

通過對這些報表的梳理，整理出系統、統計規則、主要用途、負責產品經理、對應數據表等等信息。

在指標信息梳理方面，也做了相關的信息梳理。

基於上述的梳理，我們可以依賴元數據應用平臺按主題了解數據全貌。

也可以按表、報表、指標等對象對數據進行檢索，並實現表、報表、指標的聯動。如通過對某個表名的查詢，可以得到概要信息、處理邏輯、重要字段的說明，大致瞭解這張表有什麼用。且不光可以呈現業務元信息，還可以呈現一些技術元信息，如消耗的計算資源、存儲資源、血緣關係等等。

除了上述信息，元數據應用還可以提供包括數據冷熱度分析、任務治理等內容。

04 未來規劃

關於未來的規劃，主要分爲三個方向。

第一，結合業務發展重點，持續開展數據質量治理，繼續提升數據質量；

第二，基於元數據，從資源消耗、價值等方面實現數據資產價值評估；

第三，聯動業務系統，開展數據架構治理，後續達到企業整體數據架構的統一。

05 問答環節

Q1：高管、運營同學關注的報表需要固定在早上幾點之前產出，他們依賴於此作相關決策。像這種關鍵任務的達成過程中是否有遇到過比較嚴重的問題，可否分享一些踩坑實踐？

A1：原因有幾方面。一，之前資源沒有分隊列的時候，確實出現過資源爭搶等情況導致關鍵任務出現延遲等情況，現在已通過將資源劃分隊列來解決。二，數據引擎對實效性的影響。通過從原來的 Hive 慢慢將任務切換到 Spark 來逐步解決。三，模型的複用性治理，不能爲了模型的複用性把所有東西都加到一個模型中，這時就需要做一些模型拆分、增加冗餘度的工作。

Q2：中通在數據標準落地方面做了什麼措施，怎樣保證制定好的數據標準可以得到有效遵守和執行？

A2：在數據標準落地方面，主要做了模型標準化、指標標準化等，如果保證制定好的數據標準可以得到有效遵守和執行確實需要值得關注，首先需要流程來規範，同時也需要藉助工具層面來保障。

Q3：在數據治理方面，構建類似數據地圖一樣的模型對數據業務的提升是否特別明顯？這樣的數據地圖模型對下游用戶來說，存在一定的學習成本，那麼成本和對他的幫助是個怎樣的關係？

A3：數據地圖更多的是降低數據使用門檻，讓使用方比較直觀、一目瞭然的知道我們到底有哪些數據。使用成本相對來說是比較低的，比如每一個主題域包括哪一類的數據，有什麼用途，我們相對都有比較明確的解釋，比較直觀的瞭解到這個主題是存放了哪些數據。

薛世敏

中通快遞 資深架構師

負責中通快遞數據倉庫建設及數據治理工作。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/KuztBzMyzPfutffIwcZSbw