盒馬基于DataWorks 搭建數據中臺的實踐是怎樣的

盒馬基于DataWorks 搭建數據中臺的實踐是怎樣的，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

一、盒馬的商業模式

大家做數據的話，首先很重要的一點就是一定要懂業務。之前有位同學問我，說數據中臺很難建。在我們看來，數據是跟業務息息相關的，我們去構建整個數據中臺的時候，首先要對業務有一個非常深刻的理解。盒馬是近兩三年阿里出現的一個新的業務，有一些同學應該體驗過，包括北京、上海等中國一線二線的城市都覆蓋了盒馬鮮生的門店。

上圖就是盒馬商業模式的架構圖，業務圍繞主要是兩點，一個是線上，一個是線下。盒馬的業務雖然叫做O2O，但是比較有意思的一個點是，盒馬的O2O跟早期的O2O是不一樣的。以前O2O叫 Online to Offline，盒馬的O2O是什么？是Offline to Online，目標要把線下的流量引入到線上，用線下的體驗去讓用戶愿意到線上去購買，并且保證線下的品質跟線上的品質是一樣的，不會出現線上是一個電商特供版，看似很便宜，但是你拿到的東西和線下是不一樣的。

基于我們O2O的業務架構，同時盒馬的客戶群體是很有意思的。他們大部分是以家庭為單位的，就像我買盒馬的時候，我的女兒、我的父母也都喜歡盒馬，我是一個線上客戶，可以在線上下單。那像老一輩他不會去用APP購物的時候，他就會到線下去購買，他買的東西是跟我一樣的，包括我女兒，她可能不會購物，但是盒馬有餐飲，她很喜歡去盒馬吃海鮮，通過這種業務的閉環與傳承性，來保證業務的發展與口碑。

盒馬定了這種商業模式之后，需要開始構建它的業務架構，那么這個架構應該是什么樣子？第一它要做線上線下的一體化，保證020的目標。同時確認了這是一個生鮮電商的業務，生鮮電商基本上跟傳統的標品電商做了一個差異化的區分。第三個是多功能門店，能夠融合銷售展示、倉儲、分揀、線上等業務形態。第四是限時配送：三公里30分鐘，其實打破了之前電商平臺引以為豪的當日達跟次日達這種物流，直到目前盒馬這種限時配送在業界還是屬于比較領先的。第五就是盒馬的外賣，今天你非常想吃一個東西，但是你又不會做飯，盒馬會幫你把這個東西做好，或者你會做菜，但是你不會殺魚，或者是殺雞之類的，盒馬會幫你把這個做好，然后再幫你送過去。最后還有很重要一點，因為我們提到了門店的價值，盒馬的門店不是傳統的購物，它有一個倉的設置，剛才說的可以做線上和線下，你線下去看的是門店，對于線上來說他就是個倉。

二、盒馬技術架構與原型

確定業務模式后，我們要做技術架構的設計。其實早期盒馬有過一定的糾結，因為發現做零售，做門店，做商超，很多傳統的軟件廠商有一個現成的軟件體系，比如說ERP、WMS。那我們是不是買一套就可以了？但是當時盒馬是堅定了所有的產品技術的業務系統，包括數字化系統都要自建。因為盒馬需要對很多傳統業務做了一個全面的數字化，包括交易、門店、倉儲、運配、采購、供應鏈、勞動力等等。

現在傳統的ERP軟件或者是物流軟件，它也做了數字化，但是很重要區別是，我們做數字化不是只是為了簡單的數字化，把數據結構化，更重要的是為上層策略層進行一個非常重要的支撐，我們對流量、物流履約、流程優化、財務策略進行了一個非常好的智能化的支持。在這里我可以稍微分享一下，我們之前也調研過一些線下有門店的大型零售商超企業，他們也做線上的APP，但他們的庫存線上線下是隔離的，如果你總共有100條魚，他會預先分配好，線上只賣10條，賣完之后線上就沒有了，而盒馬這100條是線上和線下先到先得，不會去分兩撥。通過這種策略模式，基本上就把整個線下線上的數據和商品全部打通。

再一個很重要的一點，剛才講的一些業務，你會發現在阿里的很多業務團隊是分開的，比如菜鳥只負責物流，淘寶只負責營銷和交易，目前整個經濟體的業務都在走向融合。但是盒馬為了去完成自己的業務閉環，所有的系統從交易門店、倉儲運費、采購供應鏈、勞動力全部是自建，并且能讓他們通過一個協同層把所有的業務打通，我們有生意計劃、供應鏈管理、協同管理、全渠道多業態，并且提供了一個閉環的解決方案。

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

我們說到數據中臺，其實在阿里巴巴，數據中臺不僅是一個解決方案，它也是一個團隊的職能，在盒馬是有一個獨立的數據中臺團隊去支持這塊業務的。我們是把數據作為一種資產，跟盒馬的商品、會員，包括設備是同樣重要的。盒馬數據中臺的同學，他們是資產的建設者、管理者和運營者，并且要通過這些資產去驅動整個零售供應鏈全鏈路、智能化的升級。其中最主要的是我們會去采集、管理、建設這份數據，并且能讓這份數據在業務上能更好的使用起來。

上圖是盒馬的數據平臺的一個整體架構，這部分會有一定的特殊性，也有一些通用性。

首先說一下通用性，我們整個基礎設施是跟阿里巴巴集團所有的部門是一樣的，采用的是阿里云的基礎設施，并且在整個數據分層這邊，我們有源數據，源數據基本上都是來自于業務系統。接入層這邊相對來說盒馬會比較復雜一點，剛才說的盒馬是全渠道，我們有APP，有線下，還有我們配送員的電動車，還有盒馬內部的一些懸掛鏈、iot、APP、人力資源等，所以這里面就會出現很多結構化和非結構化的數據，我們通過數據加工層去把我們非結構化的數據進行一定的加工，最終會形成非常重要的數據資產層。

數據資產層構建之后就會有一定的業務含義，這部分數據是可以直接被業務去使用的。但是我們在這個數據資產層上又會去定一層數據服務，讓數據使用起來會更方便，就是開箱即用。還有一塊，到了服務這一層，他可能還是個無形的，之前有同學也問我，說今天我們希望業務用戶能直接去用數據，而不是說去到很多表里面去查數據，這方面盒馬用的是數據應用層，我們會建立很多數據產品，通過產品化的方式給業務去提供真正的數據使用。最后我們盒馬這邊產品形式會特別多，我們在不同的端通過PC、釘釘、掌中寶，還有很多iot的小設備，深圳可能就是一個小的黑白的屏幕，都會有數據的透傳。并且在最右側我們有一套管理體系，通過這種管理體系，讓我們整個運營和運維可以有效地執行起來。那么這種架構圖，就是盒馬理解的一個偏業務型的數據中臺分層架構圖。

那么基于這種業務型的數據中臺分層架構，我們又設計了一套數據中臺技術架構。其實大家做過大數據的話，在數據采集的時候經常會碰到，我同時有離線和在線的計算，那么離線計算我們基于MaxCompute，阿里巴巴幾乎所有的離線數據都放在MaxCompute上，2020年雙11 MaxCompute每日數據處理量超過1000PB，達到EB級。實時計算我們是基于Flink，計算的性能也非常強大。還有一塊是我們要去做數據的存儲，存儲里面其實盒馬這邊會比較重地依賴在線存儲，譬如說Lindorm就是kv，還有MMaxCompute交互式分析（Hologres）以及在線搜索Elasticsearch，并且我們會把這些存儲變成一個個數據服務。數據服務的話就會有指標明細，還有特征、標簽等等，這些數據我們會推廣到運營最常使用的一些設備、運營平臺、釘釘移動辦公、智能化管理等，這些更多是runtime層面的。我們在整個集市運營層面，有元數據、數據質量、容災管控、數據治理等等。這個技術架構圖，我們更多的是當成一個技術需求架構圖，是我們技術團隊在做數據中臺的時候需要去做的一些事情。

三、盒馬基于DataWorks的數據中臺方案

當我們盒馬的商業模式，業務產品技術架構，以及數據中臺的技術需求整理之后，我們要開始做一個數據中臺的技術選型，或者是做一個技術調研，什么樣的產品什么樣的系統可以去支撐我們整套技術架構。之前說到我們的業務系統是自研的，但我們整個數據中臺的技術盒馬最終選擇是不自研，因為阿里云上已經有非常成熟的產品體系讓我們去構建盒馬自己的數據中臺。大數據計算引擎我們使用的是集團一直在使用的MaxCompute，那么構建數據中臺的數據開發與治理工具我們做了調研，最終選擇了DataWorks，下面就是DataWorks的整體架構圖：

DataWorks對外提供了數據集成，它有很多這種批量、增量、實時、整庫的數據集成，能夠支持盒馬這么多且復雜的數據源，目前DataWorks數據集成離線支持50+種數據源，實時支持10+種數據源，無論數據源在公網、IDC、VPC內等環境，都可以做到安全、穩定。靈活、快速的數據集成。DataWorks還有一套元數據統一管理服務，支持統一的任務調度、同時提供了非常豐富的一站式的數據開發工具，覆蓋了數據開發的整個生命周期表，極大地提高了我們的數據開發效率。上層還包括了數據治理、數據服務等，并且它提供了很重要的開放平臺。因為之前說到盒馬是一個非常獨立、豐富的業務，很多業務系統都是自研的，有自己的研發團隊，我們需要通過DataWorks OpenAPI對很多功能做一個二次的加工以及和各種自研系統、項目系統的集成，目前DataWorks提供的100多個OpenAPI可以讓我們非常簡單地去實現這個需求。

那么我們再看一下這個數據中臺技術需求圖，我們去跟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，同時DataWorks還服務大量阿里云上的用戶。所以它的設計很多是偏向于開放的、通用的、靈活的。這個時候我們在使用的時會導致一些過于靈活或者是沒有標準出現等一系列的問題，后面的內容就會針盒馬的一些經驗和大家分享當時的一些心得。

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

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

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

還有一個是業務判斷，業務判斷這里邊基本上就是通過條件的方式得出一個業務結果。舉個例子，年輕人在業務系統里面肯定不會算一個叫“年輕人”這樣的字段或業務邏輯，如果有年齡數據，那么我們在梳理的時候會說小于30歲的我們叫年輕人等等，這個就是我們說的業務判斷。數據連接這塊，基本上很簡單，就是一個表關聯去補數據。另外一個數據聚合，我們在做DWS的時候會大量用到數據聚合的這部分。還有數據過濾，我們經常會碰到一些無效的數據，我們通過數據庫這個方式把這些無效的數據給處理掉。再一個是條件選擇，這個條件選擇基本上也就是一些when的東西，跟數據過濾稍微有點相似。最后是業務解析，其實業務解析是我們最經常用到的，因為現在NoSQL或者是MySQL也支持了，甚至有一些業務團隊用了Mongo，那一個大字段里邊有很多業務表示，我們這幾年在數據集市做DWD的時候，一定要把這種Json字段或者map字段的格式全部解析成固定的列字段。因為剛才我們說過它的內容必須要一致的，讓用戶直接可以看到。在這里面分享個心得，就是業務邏輯會盡量收口在數據明細層，目的是保證數據的一致性，簡化下游使用。源頭上的變化，也可以通過代碼或格式等轉換，保證明細層結構的穩定性，避免給下游帶來更多的變化。好的模型也需要上游業務系統協同開發，一要業務系統有合理的設計，二要變更能及時的感知，就是說數據中臺的建設不是數據團隊一個團隊的事情，也要跟業務團隊去做一個聯動和共創。

剛才講的這些部分更多的是開發階段，如果DataWorks只完成這些的話，我們認為它就是一個IDE，但是DataWorks是一個一站式大數據開發治理平臺，開發平臺很重要一點是它要去保證它的運行，如何去保證我們做數據開發的代碼能運行起來？就是通過DataWorks的任務調度。盒馬的業務是非常復雜的，有30分鐘送達，還有次日達、三日達，還有一些預售預購等等。這些如果是簡單的調度系統可能就支持不了，DataWorks這邊比較好的一點是，它提供了非常靈活的任務調度的周期選擇，比如說月、周、日。盒馬的業務是一個閉環，他每個業務是有相關性的，那么反過來盒馬的數據任務也是有相關性的，這個時候整個盒馬的任務調度鏈路是非常復雜的。

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

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

上面講的是監控的問題，但是一旦監控很多就會導致監控泛濫，會有很多預警報警出來，那么DataWorks也提供了另一種能力，就是任務基線的管理。我剛才講過業務有分級，我們線上業務也有一些重要性和非重要性的任務，我們通過這種基線的方式去把這些任務進行一個隔離。基線這邊盒馬的經驗就是：基線是保障數據資產的及時產出，優先級決定了系統硬件資源的保障力度，也決定了運營人員值班的保障力度，最重要的業務一定要放8級基線，這樣會保證你的最重要的任務第一時間產出。并且DataWorks有一個很好的功能，DataWorks提供了一些回刷工具，當我的基線出問題或者破線的時候，可以通過回刷工具快速地把數據回刷出來，并且DataWorks智能監控功能會通過一些基線下的任務狀態和歷史的運行時長等，去幫你提前預估出是否存在破線的風險，這種智能化地監控與風險的預估還是非常有用的。

那么做好數據質量的監控跟基線，基本上就保證了我們的大數據任務和業務的穩定、正常地運行，但是還有很重要的一點就是數據資產的治理。阿里巴巴是提倡數據的公司，它做轉變的一個非常大的里程碑就是阿里巴巴在數據方面的存儲和計算的硬件成本超過了業務系統的硬件成本。這也導致了阿里巴巴的CTO會去把數據資產治理作為它的一個非常核心的任務。DataWorks是整個阿里巴巴集團數據使用的體量最大的平臺，甚至是一個唯一的平臺，而且也提供了數據資產的模塊叫UDAP，這里面基本上是可以通過多方面多維度，從項目到表甚至到個人，全局查看今天整個資源使用情況是什么樣的，并且很重要的一點是給你提供了一個健康分的概念。這個健康分可以綜合地看到每個業務部門內每個個人的排名情況。做治理最簡單的方式就是先把頭部打掉，阿里是這么做的，先治理頭部健康分最低的，然后把健康分拉上來，整個水平就下來了。并且它提供了很多數據可視化的工具，可以讓你很快的看到治理的效果。盒馬在這方面做的一些心得：主要目標是優化存儲與計算，降低成本，提升資源使用率；技術團隊會建很多項目空間，我們需要與技術團隊共建，一起去完成數據治理。盒馬一些比較好用的手段就是無用的應用要下線、表生命周期管理、重復計算治理、還有很重要的是計算資源暴力掃描，我們是嚴格禁止暴力掃描的。UDAP里面的一些功能我們現在在DataWorks的資源優化模塊也能夠實現，比如一些重復表、重復數據開發與數據集成任務等。

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

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

五、盒馬基于DataWorks構建數據中臺的價值

之前講的都是基于DataWorks來構建盒馬的數據中臺，最早提到數據中臺一定要是服務業務的，我現在也介紹一下盒馬的數據中臺是如何為業務服務。很有幸我跟首義是見證了盒馬從0到1再到N家店快速發展的一個過程，一家企業它用數據的過程也是這樣由淺而深的過程。首先大家都一樣，最開始我只是看數據，我有什么數據，然后通過數據去看一些問題，做一些人工的輔助和決策，但是盒馬它的擴張是特別快的，最多的時候一年開了100家店，當它的業務形態發生變化，通過簡單的數據報表和數據可視化，是無法再支撐這個業務了。所以說我們也做了很多精細化的管控，比如說品類診斷、庫存健康，告訴這個業務你現在有哪些問題，而不是讓他們用報表去做再去發現問題。

看完上述內容，你們掌握盒馬基于DataWorks 搭建數據中臺的實踐是怎樣的的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！