摘要：京東零售十年交易額快速增長的背后，不僅是京東零售高速發展的十年，也是數據倉庫技術架構演進創新的十年，EB級數據如何進行資產化沉淀和治理？如何支撐業務高速發展、精細化運營、規模化創新的不同階段？在未來更加復雜多變的環境下，將如何持續演進？

尹翔，京東零售數據倉庫技術負責人，負責數倉體系的建設，2013年加入京東，一路伴隨京東大數據的發展，在這個過程中，數據倉庫也經歷了幾次升級。本文主要介紹京東零售數據倉庫建設上的發展歷程與一些實踐。

今天的分享主要分為三個部分，首先回顧一下大數據在國內的發展歷程，第二部分，會介紹隨著京東的快速發展，大數據在內部經歷的幾個主要階段，重點是第三部分，京東零售數倉核心能力和場景實踐。

本文根據尹翔老師在2021年10月20日【第十二屆中國數據庫技術大會(DTCC2021)】現場演講內容整理而成。

大數據的發展，大體來講可以分為三個階段：

第一階段，2010年之前，是企業級數據倉庫的時代，也叫EDW，以關系型數據庫為主。當時Oracle、Teradata等傳統軟件廠商占據了大部分市場，基本上提供了數據倉庫建設從硬件、軟件到實施一體化的解決方案，建設成本非常高，當時主要集中在金融、電信、保險等行業，數據倉庫的主要應用場景是提供報表，用于經營決策。

第二個階段，大概在2010年前后，隨著移動互聯網的高速發展、數據量暴增，很多互聯網公司開始基于hadoop生態搭建大數據平臺，來應對大數據量的處理。數據應用的場景也更加豐富，比如互聯網廣告、精準營銷、供應鏈管理、abtest等

第三個階段，大概從5年前，也就是15、16年前后，業界開始提出數據中臺的概念，通過大中臺、小前臺的模式，驅動業務創新和提效。數據中臺組件化、智能化的方式，將通用的數據開發場景和工具進行沉淀，來提升開發效率，再通過數據的資產化、服務化的方式提升業務數據使用效率，讓業務更加聚焦在數據應用和業務創新上，而不是花費大量的精力進行數據能力的重復建設

從數倉的視角下，來看數據中臺的技術架構，是伴隨著數據的采集、存儲、計算、管理、應用這些環節延展開的。

從這里可以看到，數據中臺的技術生態是非常復雜的，這里涉及到非常多元的技術和產品，而且這些技術也在高速發展階段，每年基本都會涌現大量的新產品和技術，這些特點就給企業實施數據中臺帶來了很高的技術門檻，如果技術路線不清晰，很可能會造成很大的風險和隱患

我們回顧京東零售大數據的發展歷程，也經歷了幾個重要的階段，從最開始的野蠻生長，到后來的精細化運營、以及現在的數據驅動業務，從過去的大數據平臺階段也升級到了現在的數據中臺階段。

第一階段，在17年之前，是野蠻生長的階段。當時的特點是煙囪式開發，業務發展很快，靠中心化的團隊很難支撐所有業務需求，因此在大數據平臺之上，每個業務線需求都是閉環的數據團隊在支持。

但到后來這種煙囪式開發，導致了數據不互通、重復造輪子、研發效率低的問題，光數據集市就上百個，相似的數據產品也有非常多，占用了大量的存儲和計算資源，數據口徑也無法對齊，內部溝通和管理成本變得很高。于是就到了第二階段，在17、18開始精細化運營，建設數據中臺，打通各集市間的數據，更加注重數據資產的沉淀，也開始圍繞業務場景，去搭建場景化服務的能力，去支撐業務的精細化運營場景。

第三階段，是數據驅動業務的階段，也是現在我們所處的階段，精細化運營可以看作是專家經驗的沉淀，中臺也在考慮怎么進一步釋放產能，降低研發門檻，以智能化的方式進行數據生產、管理和應用。比如低代碼的開發平臺，以及像智能選品和用戶增長這些應用。

以上，我們簡單回顧了一下京東大數據發展的幾個階段。

經過這些年，目前在數據中臺已經沉淀了覆蓋京東全鏈路業務場景的全域數據資產。我們基于對零售業務的深度理解，將業務場景抽象成數據模型體系，來描繪業務之間的關系，同時也會考慮到如何存儲、計算、管理這些數據，這些都非常考驗數據中臺團隊的業務能力、技術能力和數據治理能力。最終我們將沉淀的數據資產，應用到全鏈路的業務場景中，比如用戶增長、營銷策略制定、供應鏈管理、倉儲布局規劃、配送路徑規劃等等，在這些場景中得到驗證和反饋，形成正向的循環，不斷地將數據資產體系建設得更加完善。

在建設全域數據資產的過程中，數倉扮演了非常重要的角色，期間也面臨了非常多的挑戰。

像煙囪式開發，資源重復浪費，而且因為數據缺少打通和合理架構的規劃，業務需求的迭代變得越來越慢。數據量在京東這幾年也是呈幾何級、爆發式的增長，單純地依靠增加服務器，也已經很難解決存儲和計算的難題！

隨著數據資產建設的日益豐富，對于那些已經存在了幾十萬張的數據模型，如何有效地進行管理，便捷地找到數據？

另外，京東的業務復雜度也非常高，從最初的線上自營和第三方模式，全品類的商品，拓展到線下業務，以及全渠道、多個業態場景，組織變化也非常的快，帶來數據資產的挑戰。

在實時方面。業務越來越來越極致，過去從天、到小時、再到分鐘，以及現在秒級的數據，而實時開發的門檻相比離線也比較高，周期也很長。

時效性方面。不管數據量和計算量怎么增長，業務對于時效性的追求確實越來越高。

我們是從四個維度，構建核心起來數倉的核心能力，來解決前面提到的這些問題。

包括統一的數倉架構、規范化的數據建模，數據質量的保障，以及數據資產的管理，來建設統一、標準、高質量的數據資產體系，提升數據服務化的水平，支撐業務價值實現。

我們是基于hive構建的數倉，架構上，我們從過去垂直煙囪式的開發，形成了現在統一的數倉分層架構。目前主要分為6層，每一層的定位、目標以及建設方法都不相同：

首先是BDM緩沖數據層，是用來緩存來自業務系統的數據庫、消息、日志等臨時數據，他的表結構與業務系統保持一致，并且只為FDM貼源數據層提供服務。

接著是FDM貼源數據層，這一層主要是存儲全量業務系統的數據，并且能夠支持還原業務系統的數據快照，按照業務系統數據變更的特性，一般會用拉鏈或者增量流水的方式存儲，一般情況也不對外開放。

再往上的GDM、ADM和DIM是數倉的核心層，會開始按照業務特性，搭建各主題模型，主要是基于維度建模理論，去搭建公共的維度、實時數據、以及相應的寬表。

DIM維度層，主要是對通用的維度，進行統一標準化定義，進行維度復用。

接下來是GDM和ADM，都會去按照業務劃分主題，也都會做數據的清洗和整合，只不過一個面向生產一個面向業務，GDM是面向生產，去做技術口徑的封裝，對生產系統的數據，進行清洗、整合，屏蔽生產系統的干擾，保障基礎數據的高可用，ADM則面向業務，做業務口徑的封裝，去形成統一的維度和指標，消除口徑的二義性。

ADM公共數據層，會劃分兩層，adm d 和s，adm-d主要負責統一的數據口徑封裝，提供最細顆粒度的維度和實時數據，同時封裝各種口徑的標識，adm-s會基于adm-d 進行各種維度場景的聚合和指標匯總。

最后是app 應用數據層，它主要是面向業務場景，提供具體場景的數據加工，直接提供給數據應用。

有了統一的數倉分層架構作為基礎，我們也從過去開放式的數據開發，逐步形成了統一的數據建模方法論，來規范數據建模的過程，最后我們落地成了工具，來保證方法論和規范的落地。這張圖就是我們內部數據建模工具，描繪了我們從業務板塊的劃分數據域、到一些規范的管理，再到規范化建模的過程。

在模型體系設計上，我們構建了數據總線矩陣，劃分了業務域、主題和業務單元這三層，實現頂層設計的清洗完整。業務域是我們內部相對獨立運營的的業務板塊，比如線上零售、互聯網醫療、B2B這些都是獨立的業務域，在每一個業務域下，會根據業務特點，劃分成多個主題。比如零售業務，會按用戶的照購物旅程，拆分成流量、交易、客服等多個主題。每個主題下，會劃分多個業務單元，每個業務單元會對應一個或者多個業務事件。比如在交易主題下，會拆分成下單、支付這些業務單元，業務單元就等同于概念模型，它最終會被映射成邏輯模型和物理模型。

在數據模型的構建上，我們主要是基于維度建模的思想去設計和開發模型。我們會定義統一的維度，并物化成維表，形成維度市場，供各個事實表去復用。業務單元會基于事實和維度數據，設計成大寬表，便于下游應用。

在指標管理和開發上，基于規范化的數據模型，我們可以進行指標的定義，我們將指標拆解成原子指標和派生指標，這樣最大程度去復用原子指標的定義和邏輯，來消除指標口徑的二義性。

最終保障了，數據模型體系以及數據指標體系的規范性，也減少了重復建設。

數據資產管理方面，我們的思路是，圍繞數據的全生命周期，去構建豐富的元數據，基于元數據進行數據治理、并提供資產化的服務。整個過程鏈接了數據生產者和數據消費者兩端，我們涵蓋了從數據資產的規劃、建設、采集、盤點、評估、應用、銷毀等環節。

元數據分類上，我們切分了兩個維度，一方面包括了元數據的范圍，比如模型元數據、指標元數據、標簽元數據等，盡可能的豐富，另一方面從類型上，也劃分成技術元數據、業務元數據、管理元數據等，從更豐富的分析數據資產情況。

基于元數據的治理方面上，我們從數據生命周期管理、數據質量、數據安全共享、數據地圖、數據百科、數據血緣這幾個方面為數據治理提供更多的抓手，來保證數據資產的高質量，最后再將這些高質量的數據資產，通過服務化的方式提供給數據消費者，降低數據消費門檻。

質量保證方面，我們覆蓋了從數據開發過程、到上線后的日常保障，不管是數據質量，還是數據時效，我們從事前、事中、事后，都提供了高標準的保障能力。

事前，在開發階段，我們有標準的開發流程，并且做到了生產與開發隔離，部署了獨立的開發環境，對任務和腳本也都進行版本管理，并且能夠一鍵發布上線，發也支持一鍵回滾，能夠快速恢復。

事中，在上線后，我們的目標是快速發現問題，通過時間基線去管理任務時效，通過一些配置化的校驗規則，通過旁路數據質量，一旦發現時效和質量的異常情況，會電話到值班的同學去處理，而且對于不同等級的任務，有不通的預警策略，如果任務沒有被處理，會一直上升到leader，知道任務在處理。所以不管是數據質量的問題，還是時效性問題，都可以快速發現。

事后，也就是發生后問題后，我們通過快跑通道，來達到快速恢復的目標。夜間任務出現問題產生延遲時，會預測撞線的概率，去觸發隊列的一件快跑，和一鍵推遲的功能，給核心任務讓路，來保障時效。

接下來，我會介紹一下我們在離線、實時和批流一體上的場景實踐和探索。

首先是離線上，關于超大數據量快速更新的一個實踐，叫刷崗。什么叫做刷崗呢？簡單來說，就是刷新sku、崗位、業務人員的關系，來控制權限。他是京東零售內部非常典型的業務場景，京東上有幾百億的sku，成千上萬的品類，京東的采銷業務人員，管理商品的顆粒度非常細，在行業內基本都是按照類目、或者按照店鋪去管理，但是在京東特有的自營和pop模式的特點下，就需要按照sku的顆粒度去管理生意，并且控制權限，每個人只能看到自己管理的商品。這樣就需要建立sku 和 崗位和人的關系，比如采銷員可以看哪些sku，部門經理可以看哪些，總監可以看哪些都不一樣。但是，采銷業務經常會發生崗位調整，每次調整就需要去刷新sku 和崗位的關系。舉個例子，一個采銷員之前負責小米，今天負責華為，那么就需要按照華為對應的崗位，去更新歷史數據，這樣才能保障調整崗位之后，可以正常看到歷史數據。而且每天都有大量的崗位調整，小到采銷員，大到部門品類負責人，這就是刷剛的場景。

大概分成四個階段，最開始數據量并不大，我們就簡單粗暴的全量刷新。到后來，我們發現數據量增長的特別快，作業跑的越來越慢，而且經常跑不出來，所以后來我們想了一些辦法，對數據進行預處理，比如對事實表做一些列的裁剪、輕度聚合，對商品維表，只保留那些變化的信息，這樣可以大幅縮小數據量，我們把這個方案叫增量刷崗，刷完之后，進行各種維度的計算，存在hive里，再提供到業務。

第三個階段，我們發現業務看數據的視角越來越豐富，維度組合非常的多，甚至上千種，而且遇到uv、用戶數這種需要去重的指標，每種維度組合都需要計算出來結果，過去通過離線預計算的方式，不管是帶來的資源消耗、存儲消耗、以及人力投入都是巨大的，因此我們拆分出來一些細顆粒度的維度場景，把事實和維度都導入到olap中，我們使用的是ck，通過local join根據查詢需求隨時進行刷崗、聚合，大大降低了維護成本、以及資源成本。

到現在，我們已經形成了融合多種刷剛方案的服務，我們也在嘗試利用iceberg的事務更新的特性，進行優化，只更新有變化的那些條記錄，也能夠大幅減少數據量。

在實時數倉上的實踐，我們目前主要也是用業內主流的Flink+kafka的方案，來搭建數倉。原來的方式，我們會設計三層，每一層都物化成topic，發到kafka里，我們發現，這種方式建數倉，層級比較多，而且也很難像離線一樣建設大寬表，因為這樣會導致時延性增加，而且消耗的存儲和計算資源也比較多。因此我們也是借鑒視圖的思路，把實時數倉的建模過程全部邏輯化，將邏輯模型的定義、結構、處理邏輯片段等信息，存儲在元數據中，通過這種方式把邏輯模型體系搭建起來。

最后會跟據應用層需要的計算的數據，將使用到的邏輯模型的代碼片段，進行裁剪和優化，生成最優的執行計劃，并生成任務。并且呢，當我們也會識別數倉中的熱點路徑和關鍵模型節點，再進行數倉模型的物化。這樣我們在前期就可以參照離線模型體系，比較低成本的構建邏輯化的實時數倉模型。

從前面的分享也可以看到，我們現在還是非常典型的lambda架構，實時和離線分開去計算，使用的都是不同的存儲和計算框架，最后再放到統一的存儲引擎中，給上層應用提供給數據服務。

這種方案，目前看還是存在了一些痛點：1、需要同時維護了實時、離線兩套計算框架，運維的成本比較高，2、實時和離線數據口徑要對齊，因此在兩套開發框架上，要實現兩套業務邏輯相同的代碼，開發成本也很高，而且隨時時間的推移，鏈條鏈路上都在各自迭代，非常容易造成數據的不一致；3、另外，如果完全依賴實時數據，對消息隊列的存儲要求又很高，持久化存儲帶來的成本非常高，而且數據回溯的能力也不如離線。

因此，我們內部也在實踐流批一體的數據湖解決方案，在一些場景上去落地。數據湖和數倉有什么區別呢，基于hive 的數倉的方案上其實也是有些痛點，比如不支持事物，并發往數倉讀寫入數據，可能會存在一些問題，不支持數據的更新，數據修正的成本就比較大，需要重寫分區，schame變更的成本也比較大，變更了之后需要重寫數據，整體的數據時效也是比較長的。數據湖的特性，在一定程度上是可以解決這些問題，支持ACID的事物讀寫，這樣讀和寫就可以并發的進行，沒有提交的數據就不會被讀取到，支持upsertt，很方便的進行數據行級別的更新，table revolution，可以很低成本的變更schame，并且不需要重寫數據，同時批流的讀寫接口，可以增量讀取數據，來提升時效性。

我們最終是選取iceberg的方案，delta lake是深度綁定spark的，不支持其他計算引擎。hudi一開始也是深度綁定spark，底層直接使用spark的rdd，后來才重構的。iceberg一開始架構就比較獨立，有自己的數據類型和schema，不依賴其他計算引擎。

利用Iceberg 表的增量讀取更新，以及對批流都有友好的接口支持，來構建批流一體的實時數據湖。上游實時數據，經過Flink或者spark streaming的加工，存儲到Iceberg中，Iceberg又作為實時源，供下一層使用，最終通過hbase、ck這些引擎，給上層應用提供服務，整體的數據延遲，基本上是分鐘級的，而且每一層Iceberg表，也都是持久化的存儲，上面這些spark、flink等等計算引擎，也都是可以讀寫iceberg表。這種架構方案，在我們內部在逐步實踐，像一些流量日志數據的計算場景，以及庫房抽取數據的場景，以及刷崗的場景，在應用。

從未來的趨勢來看，流批一體、湖倉一體、云原生數倉這些技術，將會是未來的趨勢，現在這些方案也在業界被實踐和驗證。整體來說，還是希望能夠進一步提升資源利用率，以更加便捷、智能、安全的方式支撐業務。

流批一體：通過一套引擎（Flink），解決流、批割裂的問題，業務可針對不同場景需求智能化選擇流、批計算的能力，低成本、高效率的新開發模式，讓業務專注自身能力發展，加速迭代；

湖倉一體：基于開放標準的湖倉一體存儲架構，實現對異構數據統一、高效管理，兼具數據湖的擴展能力和高性價比、以及數據倉庫的易用性和高性能，支持對EB級數據近實時的存儲、更新和探查分析，業務可使用更全面的數據做深度洞察、實時分析和經營決策；

云原生數倉：基于云原生架構，實現OLAP系統的存儲計算分離，達成高效彈性擴縮容能力，實現云原生數倉；更加高效支撐核心業務的實時多維數據分析需求，成為業務實時經營分析、決策的發動機；