作者：阿裡雲MVP 徐季秋
1.項目背景
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取數脫離被動的根據業務人員的指揮,業務人員可以從中台直接取到大部分名額資料;第二個是資料應用的建設脫離了從零起步,能夠直接基于中台的結果快速建設所需的資料應用。
更多雲計算、大資料、實戰架構等優質、熱門内容，微信搜尋“拜托了王教授”公衆号添加關注擷取～
更有優質技術交流社群、技術大牛一對一接觸機會等衆多福利等你來撩～