1.1 行業背景

物流行業已走過規模增長時期，正在進入傳統企業不斷進化，新物種全面崛起，互聯網巨頭爭相入局的競爭新時代——政策利好與黑科技促進完善能力基底，商流變革倒逼物流升級，也由此迎來最好也是最艱難的時代。

隨著新興企業的積極入局，“互聯網+物流”模式得以快速興起，作為行業的新鮮血液，這些新進入者在資本的助力下，依托其創新的商業模式、積極靈活的市場拓展過程確實對傳統物流企業帶來一定沖擊，也進一步推動了整個物流產業生態的豐富和發展。

阿里巴巴推出的數據中臺強調兩個概念：業務數據化和數據業務化。正是新興互聯網企業以技術和業務為抓手賦能行業的切入點。

1.2 傳統物流公司信息化的困境和傳統解決方案

從粗放式經營到精細化管理，物流公司信息化建設是企業變革關鍵核心。在互聯網時代物流企業信息化建設面臨的主要問題有：

圖1.1企業信息化面臨的問題

針對企業信息化的挑戰，傳統解決方案是企業級數據治理。數據治理是一套持續改善管理機制，涵蓋了人員，流程和技術，是一系列改變數據使用行為的過程。
但是傳統數據治理是一個冗長的，復雜的過程，而且需要大量人力和資源投入。有很大的缺陷如：

1.實施周期長
2.達至預期目標的不確定性
3.對相關人員素質（技術，對數據資產認知等）依賴過高
4.過長的實施周期，無法適應短平快的互聯網競爭等。
5.每一次數據治理都是對企業所有信息系統的一次重構和整合
6.脫離業務場景從標準層面的數據治理，無法直接產生業務價值。

而數據中臺技術是通過一序列信息技術，特別是數據處理技術進行數據的采集、加工、整合后，形成企業內部一套標準統一的可復用共享數據集合，最后高效的把數據封裝成服務提供給業務或是下游系統使用，從而實現D2V的理念。數據中臺強調數據的整合復用及共享，可以建立在不對原有系統推倒重建的基礎上構建共享數據服務。

1.3 駐云科技數據中臺方案的優勢

阿里云作為數據中臺的概念輸出者，是很多客戶構建數據中臺的第一選擇。駐云是阿里云的最大合作伙伴之一，具有豐富全面的數據中臺構建方法論及實施經驗。如阿里云與駐云科技合作構建某物流企業的數據中臺。
該物流企業是業界領先的零擔物流平臺。最早由區域合伙、聯盟發展而來，目前主營業務是全國公路零擔物流網絡服務，致力于為客戶提供高性價比的綜合物流服務。
該物流企業建立數據中臺效能：幫助企業建立完善的信息化解決方案，全面支撐公司業務發展，規范作業流程、提高工作效率,減少重復勞動，保障數據的準確性，通過數據分析，為管理提供有價值的決策依據。

2. 數據中臺實施

數據中臺實施全流程概覽。

圖2.1 數據中臺實施流程

2.1 需求和業務調研

需求調研是個漫長又不特別明確的階段,因為客戶對于自己想要的東西,不是通過調研就清晰的,而是隨著交付的過程慢慢清晰的. 所以當前階段最關鍵的工作內容是通過調研清楚具體的業務情況,數據情況,進而明確整個項目的交付邊界,而不是弄清楚交付細節.
需求和業務調研中間產出的交付件是數據資產調研表。
包含但不限于以下信息

調研信息項  說明

信息資源表名稱               企業內所有表資源名稱    

信息資源表所屬系統        對應的系統名稱    

信息資源表提供部門        表信息資源的提供部門    

信息資源表的更新周期    表的更新周期    

是否支持增量更新           是否有業務時間字段提供    

信息資源表的保密級別    跟數據資源的表的可訪問級別相關    

表字段說明                     數據字典    

信息資源表維護人           表的指定維護方聯系人    

信息資源表維護人聯系方式    表的指定維護方聯系方式    

需求和業務調研中間需要產出一個客戶業務全局文檔及相關指標體系作為內部實施核心文檔。全局業務文檔主要內容包含但不限于：

·客戶所有業務部門及其業務介紹
·客戶核心業務流程介紹
·客戶全局數據來源和流向介紹
·客戶所有業務系統及其功能介紹且標出重復建設部分

根據該物流企業核心業務流程我們在需求和業務調研階段總結出物流企業常見業務流程如圖2.2

圖2.2物流企業常見業務流程

根據該物流企業運營指標庫，我們歸納物流行業關注的幾個核心運營指標主題如圖2.3

圖2.3 物流核心指標主題

2.2 數據域定義

數據域是指面向業務分析，將業務過程或者維度進行抽象的集合。其中， 業務過程可以概為一個個不可拆分的行為事件，在業務過程之下，可以定義指標; 維度是指度量的環境，如買家下單事件，買家是維度 。
阿里巴巴的OneData體系是一整套數據整合及管理的方法體系和工具。阿里巴巴的工程師在這一體系下，構建統一、規范、可共享的全域數據體系，避免數據的冗余和重復建設，規避數據煙囪和不一致性。借助這一統一化數據整合及管理的方法體系，我們構建了阿里巴巴的數據公共層，并可以幫助相似大數據項目快速落地實現。
借助OneData體系，根據物流行業具體的業務全局及其數據資源調研表，我們遵循高內聚低耦合的架構設計策略。設計企業數據域也即公共數據中心。主要包含：

根據現有已分數據域，我們可將數據資產根據具體的業務劃分到所歸屬的數據域中，為底層數據架構建立標準。

2.3 主數據定義

主數據是指高業務價值的，可以在企業內跨越各個業務部門被重復使用的數據，是單一，準確，權威的數據來源。主數據具有以下特征：

·特征一致性
·識別唯一性
·長期有效性
·業務穩定性

主數據是面向應用層面劃分，我門遵循自上而下的設計策略，以客戶需求場景為主來提取客戶核心關注的主數據。
從物流行業應用場景來看，我們總結出如下物流行業主數據：

·用戶
·商家
·訂單
·車輛
·位置

阿里巴巴OneID體系基于行為中心數據，綜合人口學、社會學理論知識及業界標簽分類體系，構建用戶社會學標簽及業務場景標簽，對“ID”進行全方位刻畫，更生動的了解用戶，更好的服務及觸達用戶。在對外賦能的過程中，不僅應用在to C 場景中對消費者的刻畫，也可以應用在to B 場景中對租戶等的刻畫。

結合阿里巴巴OneID方法論我們為上文中提到的某物流企業構建用戶，商家，訂單，車輛，位置的統一ID為上層應用提供便捷數據服務。

2.4 架構設計

根據物流企業的業務和需求調研我們構建了，物流企業的數據域和主數據架構體系。如圖2.4

圖2.4 架構設計

數據中臺的數據資產層共分為三個層：第一層是采集層，即垂直數據中心。在采集層，更多的工作是通過采集和同步工具，將業務系統的業務數據同步到數據中臺，并形成一個個垂直數據，在此過程中，并不會做數據的清洗和處理。傳統DW稱此層為ODS層。

第二層是公共層，即公共數據中心。所有的數據的清洗、加工、處理都將在公共層完成。首先公共層橫向劃分為公共明細層和公共匯總層，其中公共明細層是按照不同維度生成的明細數據，公共匯總層是根據上層業務應用的輸入，對數據進行輕度匯總。同時公共層又會縱向的，根據不同的業務主題劃分為不同的數據域，每個數據域又劃分不同的業務過程，每個業務主題的數據都會在各自的數據域進行加工和處理。

第三層是應用層，應用層會分為萃取數據中心和主題中心，其中萃取中心是以各個業務對象為核心的標簽體系，主題數據中心是根據不同的上層應用，通過公共匯總層的模型構建出來的面向各個應用的應用層數據模型。最上層的業務應用都會通過統一的數據服務，從應用層調取數據。

2.5 數據倉庫模型設計與規范定義

數據倉庫模型設計全局一覽如圖

圖2.5 數據倉庫模型設計與規范定義

模型設計的基本原則主要有

· 高內聚低耦合：
將業務相近或者相關、粒度相同的數據設計為一個邏輯或者物理模型，將高概率同時訪問的數據放一起 ，將低概率同時訪問的數據分開存儲。

· 核心模型與拓展模型分離：
建立核心模型與擴展模型體系，核心模型包括的字段支持常用的核心業務，擴展模型包括的字段支持個性化或少量應用的需要 ，不能讓擴展模型的字段過度侵人核心模型，以免破壞核心模型的架構簡潔性與可維護性。

· 公共處理邏輯下沉及單一：
越是底層公用的處理邏輯越應該在數據調度依賴的底層進行封裝與實現，不要讓公用的處理邏輯暴露給應用層實現，不要讓公共邏輯多處同時存在。

· 成本與性能平衡：
適當的數據冗余可換取查詢和刷新性能，不宜過度冗余與數據復制。

規范定義

構建企業的指標體系，指標體系：原子指標，派生指標，修飾類型，修飾詞，時間周期組成體系之間的關系。

圖2.6指標體系

2.6 開發過程管理與規范定義

1) 代碼開發

將設計階段產出的ETL設計文檔、數據探查報告，結合開發自己的數據探查結果，同時根據自身對業務和數據的理解，轉化為具體的代碼。根據設計階段產出的設計文檔里關于工作流節點的設計和調度設計文檔，在DIDE里新建工作流節點。

工作流節點類型包含：CHECK(蟲洞)、同步中心、虛擬節點、ODPS SQL、ODPS PL、SHELL、ODPS MR、EXSTORE。根據需要，UDF、UDAF、UDTF類型還需要新建資源和注冊函數。根據設計階段產出的設計文檔里關于需求與設計實現的闡述，轉化成具體的代碼；針對不同的功能設計，需要編寫SQL、SHELL、JAVA、PERL、PATHON、MR等代碼。

代碼開發完成，提交的同時將根據預設好的掃描規則對工作流節點進行相關的檢查(禁用關鍵字檢查、命名規范檢查、數據引用規范檢查、注釋規范檢查等等)，檢查結果分為：通過、警告但通過、警告不通過。

2) 單元測試

代碼開發完成之后，開發人員需要對代碼進行單元測試，單元測試階段需要進行：規范性檢查、代碼質量/BUG檢查、數倉特殊需求檢查、指標特性檢查。測試完成之后開發同學還需要整理發布操作文檔,以便后面進行發布工作。輸出代碼、單元測試報告、發布操作文檔。。

3) CODE REVIEW

單元測試完成之后，需要由其它開發人員進行CODE REVIEW。CODE REVIEW階段需要進行：數據一致性檢查、數據完整性檢查、指標間邏輯檢查。CODE VIEW完成之后開發階段的工作即完結，由開發人員通知測試人員進行測試階段的工作。此處需要提供CODE REVIEW模板，輸出CODE REVIEW報告。

2.7數據質量管理

開發完成后的數據運營過程需要持久的數據質量管理，用來保證數據的質量持續可用。如圖2.7

圖2.7 數據質量管理

3. 數據中臺應用

經過數據中臺的數據梳理和指標體系的建立，可以為運營分析提供直接有效的服務。如數據大屏和BI報表

3.1 數據大屏應用

經過數據中臺產出指標體系，某物流公司大屏效果展示

3.1數據大屏應用

3.2 自動化BI報表

根據成熟的指標體系構建商業智能BI分析報表，如結合阿里云quick BI產品構建部門運營分析報表。可由業務人員直接在數據門戶中通過拖拉拽的方式實現業務運營分析。

3.3 數據服務

用戶也可構建一套數據運營平臺兼具門戶功能，為企業內部提供一個可視化的數據共享服務。數據運營平臺通過OneService服務來統一對接管理數據中臺提供的上層數據應用服務。

4.總結與回顧

數據中臺的建設節奏是個前松再緊后又松的過程,而且是隨著業務的變化而變化的漫長的過程,建成的標志我們認為有兩個: 第一個是指標的復用性,BI取數脫離被動的根據業務人員的指揮,業務人員可以從中臺直接取到大部分指標數據;第二個是數據應用的建設脫離了從零起步,能夠直接基于中臺的結果快速建設所需的數據應用。