京東零售資料倉庫演進之路

語言: CN / TW / HK

摘要:京東零售十年交易額快速增長的背後,不僅是京東零售高速發展的十年,也是資料倉庫技術架構演進創新的十年,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系統的儲存計算分離,達成高效彈性擴縮容能力,實現雲原生數倉;更加高效支撐核心業務的實時多維資料分析需求,成為業務實時經營分析、決策的發動機;

長按以識別二維碼,加入大資料微訊號群~ 

公眾號推送規則變了

點選上方公眾號名片, 收藏公眾號 ,不錯過精彩內容推送!