阿里妹導讀：爲了應對衆多業務部門千變萬化的數據需求和高時效性的要求，阿里巴巴首次提出了數據中臺的概念，經過衆多項目的實踐已經沉澱出了標準化的流程和方法論。如何構建一個數據中臺？一個好的數據中臺需要具備哪些功能？原盒馬在線數據平臺研發負責人歡伯向大家分享新零售企業如何基於DataWorks構建數據中臺的經驗心得，從商業模式及業務的設計，到數據中臺的架構設計與產品選型，再到數據中臺構建的最佳實踐，最後利用數據中臺去反哺業務，輔助人工與智能的決策。

文末福利：七天玩轉MongoDB訓練營來了！

一 新零售的商業模式

一家新零售企業如果要做數據中臺的話，首先很重要的一點就是一定要懂業務。之前有位同學問過我，說數據中臺很難建。在我看來，數據跟業務是息息相關的，在構建整個數據中臺的時候，首先要對業務有一個非常深刻的理解。

新零售企業會有各種各樣的業務形態，例如線上電商平臺、線下門店、官方APP、分銷渠道、供應鏈等等，我們沒必要在一開始就要求把所有渠道的數據都收集起來，做大一統，就是做數據中臺了。我們在最開始需要了解的是整個企業的商業模式是什麼，基於商業模式，我們再來定義需要做的業務形態，最後的事情纔是開始規劃企業新零售數據中臺的建設。在這裏可以給大家舉個例子。

例如比較多的新零售企業原先是以線下門店爲主的，現在會做一些線上APP或者電商業務，但是它線上的庫存和線下的庫存是不同步，或者電商的款和線下的款是不一樣的。那他的商業模式其實還是傳統的零售業務，只不過開了另外一條線上的業務。數據中臺首先需要的是打破企業原先的商業模式，設計一個真正線上線下融合的業務形態，所以我們經常說數據中臺是企業一把手工程。

確定了商業模式之後，新零售企業的業務形態也有很多，大家都在做不同的嘗試，例如一些生鮮業務會有XX分鐘限時達、有線下門店的企業會把線下流量導入到線上，同時把線下門店當做線上入口的一個倉、也有企業線上購買後可以到線下門店提貨，保證線上線下同款同價等等。當確定了這些業務形態後，我們再來聊數據中臺如何去支撐這些業務，通過數據的打通來完成整個商業模式的閉環。

二 新零售企業產品技術架構設計

業務產品技術架構圖

確定業務模式後，接下來需要做純產品技術架構的設計。這時候許多零售的企業會比較糾結，因爲發現做零售、門店、商超，很多傳統的軟件廠商有一個現成的軟件體系，比如說ERP、WMS，對於企業來說是不是買一套就可以了？

現在傳統的ERP軟件或者是物流軟件，有一些也做了數字化，但是很重要區別是，數據中臺做的數字化不只是爲了簡單的數字化、把數據結構化，更重要的是爲上層策略層做一個非常重要的支撐，讓數據中臺對流量、物流履約、流程優化、財務策略做一個非常好的智能化的支持。在這裏可以稍微分享一個例子，我們之前也調研過一些線下有門店的大型零售商超企業，他們也做線上的APP，但他們的庫存線上線下是隔離的，如果總共有100條魚，APP內會預先分配好，線上只賣10條，賣完之後線上就沒有了，而擁有數據數據中臺之後，這100條魚線上和線下先到先得，同時可以通過算法預測做庫存預警、做折扣、做交叉銷售、做供應鏈調整等等，比起粗暴地分成兩撥，數據中臺通過這種策略模式，基本上就把整個線下線上的數據和商品全部打通，也重構了一些業務形態，所以我們說數據中臺不是簡單地把數據結構化。

企業如果有一定技術能力的話，建議所有核心業務系統都採用自研的形式，因爲新零售企業需要對很多傳統業務要做一個全面的數字化，包括交易、門店、倉儲、運配、採購、供應鏈、勞動力等等。如果外部採購的話，基於商業模式出發，一定要讓系統形成閉環，從交易門店、倉儲運費、採購供應鏈、勞動力等等，不要APP、門店、電商都不同的系統，那樣你做數據中臺的時候，數據本身的壁壘就已經很高了。

完成整個閉環中非常重要的一點就是最右側的數據層，除了業務系統的設計，如果沒有統一的數據中臺建設，是很難去支撐整個企業工程的，這也是今天會重點跟大家介紹的部分。

新零售數據中臺團隊介紹

在我們看來，數據中臺不僅是一種解決方案，也是一個團隊的職能。企業應該建設一個獨立的數據中臺團隊來支持業務。對於企業來說，數據和商品、會員以及設備一樣，是非常重要的資產。企業數據中臺團隊的同學，是資產的建設者、管理者和運營者，通過這些資產去驅動整個零售供應鏈全鏈路、智能化的升級。通過採集、管理、建設數據，讓數據更好地運用到業務上。

新零售數據中臺整體架構

上圖是比較通用的數據中臺的整體架構，這部分會有一定的特殊性，也有一些通用性。

首先介紹一下通用性，整個基礎設施的建設基本採用的是阿里雲的基礎設施，阿里雲上的DataWorks+MaxCompute十一年來一直支持阿里巴巴集團數據中臺的建設。在整個數據分層這邊，源數據層基本上來自於業務系統，接入層相對來說會比較複雜一點，很多企業現在講全渠道覆蓋，包含APP，線下，甚至一些企業還有自己的配送員、電動車，以及門店的一些IOT設備數據，人力資源等，所以這裏面就會出現很多結構化和非結構化的數據。通過數據加工層把非結構化的數據進行一定的加工，最終會形成非常重要的數據資產層。

數據資產層構建之後就會有一定的業務含義，這部分數據是可以直接被業務使用的。但是在數據資產層上我們會定一層數據服務層，讓數據使用起來更方便，開箱即用。到了服務這一層，可能還是無形的，從業務方來看，肯定希望業務用戶能直接去用數據，而不是去到很多表裏面查數據。所以在數據服務層之上，數據應用層數據中臺團隊可以建立很多數據產品，通過產品化的方式給到業務，提供真正的數據使用。產品形式也會比較多，在不同的端，包括PC、釘釘、掌中寶，還有很多IOT的小設備，可能就是一個小的黑白屏幕，都會有數據的透傳。並且在最右側數據中臺會有一套管理體系，通過這種管理體系，讓企業整個運營和運維可以有效地執行起來。這個架構圖，就是我們理解的一個偏業務型的數據中臺分層架構圖。

新零售數據中臺技術架構

基於剛纔提到這種業務型的數據中臺分層架構，我們需要繼續設計一套數據中臺的技術架構。大家如果做過大數據的話，在數據採集的時候經常會碰到，同時有離線和實時的計算該怎麼辦？離線計算我們推薦阿里雲上的MaxCompute，阿里巴巴幾乎所有的離線數據都放在MaxCompute上，2020年雙11 MaxCompute每日數據處理量達到1.7EB級。實時計算我們推薦Flink，峯值每秒處理消息規模達到40億條，計算的性能也非常強大。除了計算，還要去做數據的存儲，比如實時計算Flink的數據彙總加工後，可以存儲到MaxCompute交互式分析（Hologres），來構建我們的實時數據倉庫，MaxCompute交互式分析（Hologres）可以支持峯值寫入速度達到5.96億條，同時支持PB級數據的亞秒級查詢，以及在線搜索Elasticsearch，並且這些存儲都會變成一個個數據服務。數據服務會有指標明細，還有特徵、標籤等等，這些數據可以推廣到運營最常使用的一些設備、運營平臺、釘釘移動辦公、智能化管理等，這些更多是runtime層面的。在整個數據集市運營層面，還有元數據、數據質量、容災管控、數據治理等等。這個技術架構圖，更多的是當成一個技術需求架構圖，是新零售企業技術團隊在做數據中臺的時候需要去做的一些事情。

三 基於DataWorks的新零售數據中臺解決方案

當企業的商業模式，業務產品技術架構，以及數據中臺的技術需求整理之後，我們就要開始做一個數據中臺的技術選型與技術調研，什麼樣的產品什麼樣的系統可以去支撐新零售企業整套的技術架構。之前說到企業的業務系統我們建議是自研，但整個數據中臺的技術其實是可以不自研的，因爲阿里雲上已經有非常成熟的產品體系讓我們的新零售企業去構建自己的數據中臺。剛纔我們說到了大數據計算引擎的選型，離線數倉可以選擇MaxCompute，實時數倉可以選擇實時計算Flink+MaxCompute交互式分析（Hologres），這三個產品同時可以無縫組合構建一套完整的實時離線一體化數據倉庫，構建數據中臺的數據開發與治理工具可以選擇DataWorks，DataWorks服務了阿里巴巴集團幾乎所有的業務部門，每天集團內部有數萬名運營小二/產品經理/數據工程師/算法工程師/研發等都在使用DataWorks，同時還服務大量阿里雲上的用戶，下面就是DataWorks的整體架構圖：

DataWorks的整體架構圖

數據集成是構建數據中臺的第一步，DataWorks對外提供了數據集成的能力，它有很多批量、增量、實時、整庫的數據集成，能夠支持企業多種且複雜的數據源，目前DataWorks數據集成離線同步支持50+種數據源，實時同步支持10+種數據源，無論數據源在公網、IDC、VPC內等環境，都可以做到安全、穩定、靈活、快速地數據集成。DataWorks還有一套元數據統一管理服務，支持統一的任務調度、同時提供了非常豐富的一站式的數據開發工具，覆蓋了數據開發的整個生命週期，可以極大地提高企業的數據開發效率。上層還包括了數據治理、數據服務等，並且它提供了很重要的開放平臺。因爲對於絕大部分企業來說，它的業務系統可能是自研/採購的產品，通過DataWorks OpenAPI可以對很多功能做二次的加工以及和各種自研系統、項目系統的集成，例如報警信息可以推送到企業自己的監控告警系統，目前DataWorks提供的100多個OpenAPI可以讓企業非常簡單地去實現這個需求。

基於DataWorks構建新零售數據中臺

當我們把這個數據中臺技術需求圖與DataWorks做一個比對時，數據採集部分對應了DataWorks提供的數據集成，基本上左邊的這些數據同步的需求DataWorks都可以滿足。在數據開發層，DataWorks通過它的DataStudio、HoloStudio和StreamStudio可以同時完成企業離線、在線、實時的數據開發，並且它還提供了數據服務跟開放接口的能力，可以通過OpenAPI的方式跟企業現有的系統和產品做一個集成。還有很關鍵的一點，DataWorks提供了數據地圖和數據治理的能力，這兩個功能看似是邊緣功能，但是在整個企業構建數據中臺時起到了一個非常關鍵的作用，這塊後面會繼續展開。

數據中臺的目標

前面更多地可以看成是數據中臺的準備過程，瞭解企業的業務，做了產品系統的設計，並且做了一個技術選型，接下來我們需要確定企業數據中臺建設的目標，目標不代表KPI，它也有可能是使命或者初衷。數據中臺建設的目標是，要建立一個數據豐富（全鏈路、多維度）、質量可靠（口徑標準，結果準確），運行穩定（產出及時、無故障）的一箇中間層。很多人會說這是數據集市，沒關係，它就是個中間層。還有一點是數據中臺要爲上層業務提供可靠的數據服務、數據產品及業務應用。這就限定了它不是一個簡單的數據倉庫，也不是一個簡單的數據集市，而是一個數據中臺，是可被業務去不斷使用的數據中臺。如果企業只是把數據同步加工，放到MaxCompute或者開源的Hadoop或者一個數據庫裏面，那它還只是個倉。我們定義的數據中臺是可被業務直接去使用的，甚至是要給業務帶來業務價值的，才叫數據中臺。

定義這樣一個目標之後，我們要開始做一個分步拆解，一些業務團隊在提業務需求的時候，只會告訴數據團隊要一個銷售額的數據，但是這個銷售額還有限制條件，例如在什麼時間段？是否包含退款？是否限制地域等等，所以數據中臺首先要做一個指標體系的設計，並且這個指標體系應該在中臺團隊產品化，第二步因爲業務去使用的不是一個表的字段，所以需要一個數據模型設計的支撐，讓企業把數據變得更標準，第三步基於我們設計好的模型，我們還要去做數據處理任務的開發。最後我們要把這些數據通過數據服務的方式開放出去，讓業務去使用，數據服務的形式不限於 Table、API和Report，甚至可以是一個產品或者其他的任何一個東西。

數據集市整體模型架構 - 總體分層

數據集市整體模型架構 - 功能定位

上圖是大家在網上看到比較多的關於數據模型或者數據集市構建的分層圖——ODS、DWD、DWS和ADS。雖然有很多概念和理念，但是每個人對這幾層的理解是不一樣的，我們要對這幾層有非常嚴格清晰的定義，每一層要有每層自己的特點和職責。在我們看來，簡單概述地說：

ADS一定要是面向業務的，不是面向開發的，這部分數據讓業務能最短的時間去理解，甚至直接使用。

DWS必須是指標，也是剛纔前面講的指標體系的一個承載體，都由DWS去做，DWS彙總基本上就是ADS的支撐。

DWD就是明細層，明細層怎麼建呢？我們建議採用的是維度建模的方式，企業有維表，有事實表，維表也有很多層級維度，比如枚舉維度，事實表有周期快照。當然在這裏有一個點就是DWD的字段必須是可被直接理解的，不要有二義性，一旦有二義性的時候，DWS使用的時候會有問題，會導致整個上游應用都有問題。

ODS基本上大家理解應該都保持一致，就是業務數據直接同步過來。但是現在有一些架構的演變，大家喜歡在ODS做一個初步的ETL處理，這樣會導致ODS的數據跟企業業務的數據不一致。其實我們建議是不這樣做，原因很簡單，我們要保證ODS跟業務庫保持一致，這樣當出現問題的時候，我們能很快定位到問題的原因。一旦做了ETL，有可能ETL的過程是有bug的，會導致兩邊數據不一致。所以如果企業是嚴格要求從業務庫的數據到ODS不允許做任何的邏輯的處理，那麼出現問題的時候，只能是中間件或者是其他的任何存儲出了問題導致的，不應該是業務邏輯導致的。

四 基於DataWorks構建新零售數據中臺

DataWorks數據開發平臺

前面更多講述數據中臺建設的一些思想、設計、架構、目標及要求，接下來我和大家聊一下如何使用DataWorks構建數據中臺以及使用DataWorks平臺的一些心得。DataWorks這個平臺不僅僅服務阿里雲上的客戶，從2009年開始就同時服務阿里巴巴集團幾乎所有的業務部門。所以它的整體產品設計很多是偏向於開放的、通用的、靈活的。這個時候企業在使用DataWorks時會由於過於靈活或者是沒有標準等而出現一系列的問題，接下來的內容就會針對我們的一些經驗和大家分享一些心得。

數據開發 - 數據同步

建議所有業務庫的數據都是統一同步hm_ods項目進行統一存儲管理

從節約存儲考慮，同一份數據只能同步一份。

從數據回溯與審計需要考慮，數據生命週期設置爲永久保存。

數據同步是構建數據中臺的第一步，如果數據進不了倉，數據中臺就沒辦法構建。我們在做數據同步的時候，會有幾個要求，比如企業的所有業務數據都是統一同步到一個項目，並且只同步一份，不允許重複同步，這樣的話方便管理，減少成本，同時保證了數據不要有二義性。數據源出問題了，那後邊數據就都有錯，所以數據中臺一定要保證數據源100%正確。然後從數據回溯與審計考慮，數據生命週期設置的是一個永久保存，哪怕業務系統因爲一些線上庫的流量問題，會有一些歸檔、刪除，但當他們想再使用歷史數據的時候，可以通過ODS這層原封不動地再還原回去。

數據開發 - 數據加工代碼開發

數據處理過程就是業務邏輯的實現過程。

既要保證業務邏輯的正確性，又要保證數據產出的穩定性、時效性。

第二就是數據開發，數據開發這部分是很考驗個人能力的，基本上大家都是使用SQL。我們自己對於數據開發這部分的心得簡單來說就是數據處理過程是業務邏輯的實現，既要保證業務邏輯的正確性，也要保證數據產出的穩定性、時效性和合理性。DataWorks進行數據開發的編輯器，除了提供比較好的coding能力以外，也提供了一些處理流程的可視化的方式，幫助企業去做一些code review，甚至部分校驗，這個功能在我們日常使用中是非常有幫助的。

數據開發 - 代碼功能示例

業務邏輯會盡量收口在數據明細層，目的是保證了數據的一致性，也簡化了下游的使用。

源頭上的變化，也可以通過代碼或格式等的轉換保證明細層結構的穩定性，避免給下游帶來過多的變更。

好的模型，也需要與上游業務系統協同開發，一要業務系統有合理的設計，二是變更能及時的感知。

整個數據開發的過程，因爲我本身也是做Java的，每一種編程都有一定的編程範式，在整個數據開發的過程中也去抽象了幾個步驟。

首先是代碼轉換，這個代碼轉換主要是幹什麼用的？剛纔講過業務系統很多是爲了完成一個業務流程，會有很多個性化的處理，尤其是大家做互聯網業務的時候，爲了解決一些性能問題或者是filter的問題，會做一些Json字段、媒體字段、分隔符等等，這樣的內容會出現二義性。我們在開發中會有代碼轉換，比如說把一些枚舉的東西轉成一個實際看得懂的東西，0到底是什麼？2是什麼？或者a是什麼？還有個格式轉換，企業有一些業務系統，它很難標準，譬如說時間，有的用的是timestamp，有的是存字符串，有的是存yymm這些，雖然它們都代表時間，但是格式不一樣，在數據集市的構建過程中，它要求裏面的數據格式必須是一致的，我們會去把非標準的數據格式通過格式轉換的方式變成一個標準的格式。

第二是業務判斷，業務判斷這裏邊基本上就是通過條件的方式得出一個業務結果。舉個例子，年輕人在業務系統裏面肯定不會有一個叫“年輕人”這樣的字段或業務邏輯，如果有年齡數據，在梳理的時候可以判斷小於30歲的人叫年輕人，這個就是我們說的業務判斷。

第三是數據連接，基本上很簡單，就是一個表關聯去補數據。

第四是數據聚合，企業在做DWS的時候會大量用到數據聚合的這部分

第五是數據過濾，我們經常會碰到一些無效的數據，我們通過數據過濾這個方式把這些無效的數據給處理掉。

第六是條件選擇，這個條件選擇基本上也就是一些where的東西，跟數據過濾稍微有點相似。

最後是業務解析。業務解析是企業最經常用到的，因爲現在NoSQL或者MySQL也支持了，甚至有一些業務團隊用了Mongo，那一個大字段裏邊有很多業務表示。我們這幾年在數據集市做DWD的時候，一定要把這種Json字段或者map字段的格式全部解析成固定的列字段。因爲我們剛纔說過它的內容必須要一致的，讓用戶直接可以看到。在這裏面分享個心得，就是業務邏輯會盡量收口在數據明細層，目的是保證數據的一致性，簡化下游使用。源頭上的變化，也可以通過代碼或格式等轉換，保證明細層結構的穩定性，避免給下游帶來更多的變化。好的模型也需要上游業務系統協同開發，一要業務系統有合理的設計，二要變更能及時地感知，所以說數據中臺的建設不是數據團隊一個團隊的事情，也要跟業務團隊去做聯動和共創。

數據開發 - 任務調度配置

剛纔講的這些部分更多的是開發階段，如果DataWorks只完成這些的話，我們認爲它就是一個IDE，但是DataWorks作爲一站式大數據開發治理的平臺，核心的一點是要去保證平臺的運行，如何去保證企業做數據開發的代碼能運行起來？那就是通過DataWorks的任務調度。一個企業的新零售業務是非常複雜的，生鮮有30分鐘送達、電商有次日達、三日達，還有一些預售預購等等。這些如果是簡單的調度系統可能就支持不了，DataWorks比較好的一點是，它提供了非常靈活的任務調度週期選擇，比如說月、周、日，並且能夠支持雙11每日1500萬任務的穩定調度，從調度週期靈活性和穩定性來看都非常好。最開始我們設計企業的新零售業務是一個閉環，它每個業務是有相關性的，反過來說企業的數據任務也是有相關性的，這個時候整個的任務調度鏈路是非常複雜的。

在整個過程裏面，我們也有很多嘗試、創新，也踩過了很多坑，這邊就跟大家分享一下。DataWorks任務節點未起調或者在錯誤的時間起調都可能出現數據缺失或者是錯誤，這裏就要保證企業數據開發對於每個線上任務的任何問題都要及時處理，因爲每個問題都會造成一個數據的問題。合理的調度策略既可以保障數據產出的正確性，也可以保障數據產出的及時性，我們希望一天產出，那就不要把它變成每小時產出，產生12次，就按一天就可以了，如果是三天我們就設置三天的調度。

數據運維&治理 - 數據質量監控

數據質量監控的目的是保障數據資產產出的正確性。

監控的範疇包括表大小變化、錶行數變化、字段枚舉值變化（如新增“外賣”類務類型）、主鍵衝突（同一SKU出現兩行）、非法格式（如email格式）等。

異常值會觸發報警或中斷數據處理過程，讓值班人員有機會介入。

通過這幾步，正常情況下，我們的一個項目或者一個需求，按照這種方式去完成，我們就認爲一個數據開發工程師的任務結束了。但是一般情況下不是這個樣子，因爲數據中臺是一個偏商業化的事情，所以說它一旦出問題，影響是特別大的。如果說集團有集團核心系統、部門核心系統，業務線有核心繫統、非核心繫統，不同的核心繫統需要有不同的保障，還有p1、p2、p3、p4的方式去定義故障等級，數據業務也同理。數據業務跟正常業務系統不太一樣的是，數據中臺團隊是依託了DataWorks來做整個線上大數據業務任務的穩定性保障。其中DataWorks這邊提供了很重要的一個模塊，就是數據質量監控。數據質量監控可以讓企業更及時地去發現一些問題，當業務有影響的時候，保證我們第一時間就知道（因爲有的時候業務使用還是有一定的延遲性的，數據團隊經常遇到的就是業務出現問題過來找你才知道）。數據質量的監控，目的是保障數據產出的正確性，並且監控範圍一定要比較全，不僅限於表大小的變化，函數的變化，字段枚舉值和一些主鍵的衝突，甚至一些非法格式，並且異常值會觸發報警或中斷數據處理過程，這時候值班人員要第一時間介入。

數據運維&治理 - 業務基線管理

基線的目的是保障數據資產產出的及時性。

優先級決定了系統硬件資源的保障力度，也決定了運維人員值班的保障力度。

重要任務都納入了基線管理；核心任務優先級爲最高級別8級。

上面講的是監控的問題，但是一旦監控多了就會導致監控氾濫，會有很多預警報警出來，DataWorks也提供了另一種能力，就是任務基線的管理。我剛纔講過業務有分級，企業的數據業務也有一些重要和非重要的任務，我們通過這種基線的方式去把這些任務進行一個隔離。基線這塊我們的經驗就是：基線是保障數據資產的及時產出，優先級決定了系統硬件資源的保障力度，也決定了運營人員值班的保障力度，最重要的業務一定要放8級基線，這樣會保證你的最重要的任務第一時間產出。另外DataWorks有一個很好的功能——回刷工具，當我的基線出問題或者破線的時候，可以通過回刷工具快速地把數據回刷出來。並且如果你設置了DataWorks的智能監控，這個功能會通過一些基線下目前的任務狀態和歷史的運行時長等，通過算法的形式去幫你提前預估出是否存在破線的風險，比如一個數據正常是晚上12點產出的，在這之前有個數據應該是晚上6點產出，設置完智能監控之後，如果之前晚上6點產出數據的任務在今晚7點都未產出，並且系統通過算法判斷晚上12點依舊無法正常產出，智能監控在7點的時候就會發出一個告警，讓技術同學進行提前干預，不用等到晚上12點數據真正產出延時時纔開始干預，這種智能化的監控與風險的預估對於企業業務的穩定性來說是非常有用的。

數據運維&治理 - 數據資產治理

主要目標是優化存儲與計算，降低成本，提升資源利用效率。

技術團隊有多個project，治理需要技術團隊一起配合完成。

手段有無用應用下線，表生命週期管理、重複計算治理、暴力掃描治理等手段。

做好數據質量的監控與基線，基本上就保證了企業的大數據任務和業務的穩定、正常地運行，還有就是數據資產的治理。阿里巴巴是提倡數據的公司，它做轉變的一個非常大的里程碑就是阿里巴巴在數據方面存儲和計算的硬件成本超過了業務系統的硬件成本。這也導致了阿里巴巴的CTO會去把數據資產治理作爲非常核心的任務。DataWorks是整個阿里巴巴集團數據使用的體量最大的平臺，甚至是一個唯一的平臺，也提供了數據資產的模塊叫UDAP，這裏面基本上是可以通過多方面多維度，從項目到表甚至到個人，全局查看今天整體資源使用情況是什麼樣的，並且給使用者提供了一個健康分的概念。這個健康分可以綜合地看到每個業務部門內每個個人的排名情況。做治理最簡單的方式就是先把頭部打掉，我們先治理頭部健康分最低的，然後把健康分拉上來，整個水平就下來了。同時UDAP提供了很多數據可視化的工具，可以讓你很快地看到治理的效果，在這方面我也有一些心得分享給大家。

首先主要目標是優化存儲與計算，降低成本，提升資源使用率；技術團隊會自己建很多項目空間，數據中臺團隊需要與技術團隊共建，一起去完成數據治理。一些比較好用的手段就是無用的應用要下線、表生命週期管理、重複計算治理、還有很重要的是計算資源暴力掃描，是需要被嚴格禁止的。UDAP裏面的一些功能目前在DataWorks的資源優化模塊也能夠實現，比如一些重複表、重複數據開發與數據集成任務的治理等等。

數據運維&治理 - 數據安全管理

數據安全有四層保障：平臺(Maxcompute)級、項目(Project)級、表級、字段級。

外包人員除了安全規章學習與考試外，還需要特別審批及籤保密協議。

員工離職權限會自動進行權限回收。

做完以上這些，我們認爲數據中臺該做的事情就差不多了，最後還有一點就是數據安全管理。隨着互聯網的發展，中國基本持續每一年都會出一個相關的網絡法，比如說電子商務法、網絡安全法等等，最近應該是草擬數據安全法。作爲一家企業，對法律的遵守是特別重要的。DataWorks作爲阿里大數據最統一的數據入口和出口，做了很多數據安全管理的手段。它可以從引擎層面進行一個管控、也可以通過項目層面進行管控，同時可以到表層面，甚至到字段層面。在字段層面，每個字段有等級，比如說有一些高等級字段的權限必須部門負責人或者是總裁層面審批纔可以使用的，再比如說有一些即使審批通過了，但還是有一定風險的數據，像身份證號碼，手機號碼等，DataWorks數據保護傘會提供一種技術叫數據脫敏，這些敏感、具有風險的數據被拿走是被脫敏過的，不影響使用者的統計或者分析，但是使用者是不可見的。

阿里巴巴集團有一套統一的數據管理方法，它跟組織架構是打通的，員工離職或者轉崗，他的權限會自動收回。在任何企業包括阿里，人員變動是非常頻繁的，通過這樣的功能與體系，企業能保證在數據安全的前提下更好地應用數據。

五 基於DataWorks構建數據中臺的價值

數據中臺如何支撐業務

之前講的都是基於DataWorks來構建新零售數據中臺，最早我們提到數據中臺一定要服務業務，現在我也介紹一下數據中臺如何爲業務服務的一些方式。一家企業它用數據的過程是由淺而深的過程，首先大家都一樣，最開始我們只是看數據，我有什麼數據，然後通過數據去看一些問題，做一些人工的輔助和決策，但是新零售的很多業務的擴張是特別快的，一年開100多家店，覆蓋全國200多個城市等等，當它的業務形態發生這樣的變化後，通過簡單的數據報表和數據可視化，是無法再支撐這個一年開100多家店的業務了。所以說企業這時候也可以做很多精細化的管控，比如說品類診斷、庫存健康，告訴這個業務你現在有哪些問題，而不是讓他們用報表去發現問題。

比如一些生鮮業務跟電商業務有一個非常不一樣的點，生鮮這種新零售業務受自然因素的影響特別大，譬如說天氣或者是節假日，甚至一個交通事故都會影響到生鮮的業務，因爲庫存問題導致貨損。針對這種情況，企業基於數據中臺可以做很多預測類的應用，比如銷量預測。生鮮的銷量預測可以要求到小時，每個小時都要做迭代，甚至還可以做一些仿真系統，當出現比如天氣突然發生變化的時候，通過仿真系統預測到或者感知到有什麼樣的風險，並做出一定調整。再到後面生鮮會有日日鮮的一些商品（商品當天就要賣出），每個運營人員、銷售人員每天有很多事情要做，這麼多門店的這麼多種日日鮮商品，靠人是絕對沒有辦法高效感知並做出調整的。如果我們把幾百張報表全部幹掉，把這些所有通過人看數據發現問題的場景，全部集中到業務系統裏面。當數據中臺發現日日鮮的商品已經賣不出去了，距離關門只有三個小時了，需要一個打折，這時候不需要人蔘與，通過數據中臺的數據的預測與算法自動觸發打折，把這個商品賣出去。這些BI跟AI結合在一起的應用是可以讓數據中臺真正產生價值，企業也可以根據目前不同的數據應用階段，設計不同的數據應用產品，讓數據真正賦能業務。

阿里雲和 MongDB 官方聯合打造

帶你七天玩轉 MongoDB

限時免費，七天玩轉 MongoDB 訓練營來了！每天40分鐘，和其他開發者一起學習由阿里雲技術專家、MongoDB原廠高級諮詢顧問及阿里雲MVP聯合出品的專業課程，掌握MongoDB生產環境開發的基礎技能，完成理論到實操的跨越。訓練營小助手會每天監督你學習，完成打卡並通過結營考試，可以獲得結營證書、MongoDB周邊(限量)甚至FILCO機械鍵盤(限量)等大獎。