一、大數據演進歷程

大數據演進歷程到目前分為三個階段：

第一階段

21世紀的第一個10年，企業級數據倉庫從萌芽到發展，“IOTteradata” 占據了大部分市場，提供數據倉庫建設從硬件、軟件到實施的整體方案。

第二階段

2010年-2020年，大數據平臺階段，移動互聯網的飛速發展，帶動大數據的發展，其中Hadoop生態技術開始大規模使用，基于Hadoop 分布式計算框架，使用相對廉價的PC服務器就能搭建大數據集群。

第三階段

就是我們當前所處的階段，經過前10年不斷的積累，大數據在方法和組織的變革上也有了新的沉淀，主要體現在：

1）數據資產化

通過數據地圖與數據血緣實現360°數據全鏈路追蹤。

2）數據服務化

提供標準的數據服務，支持數據產品的靈活調用。

3）工具組件化

數據在采、存、算過程中涉及多業務線條、多場景，將這些場景與工具進行組件化沉淀，避免重復建設。

4）數據智能化

通過人工智能實現大數據的智能化應用。

在行業中，數據中臺有非常多的開源技術可供選擇，尤其是Hadoop生態圈，從數據整體流向來看各大層級的選型：

傳輸層

原始數據的抽取，Scribe和Flume作為非結構化日志接入，DataX作為結構化數據離線抽取，Kafka作為流式數據總線。

存儲層

Hadoop文件系統HDFS，Alluxio基于內存的分布式文件系統。

計算層

離線計算主要是Hive、Spark、MR：多維分析引擎一般基于現有Clickhouse、Doris和ES：實時計算前些年Storm、Spark Streaming比較流行，現在基本都轉到Flink。

調度

基于Airflow、Oozie或者開源的Dolphin-scheduler。

平臺層

包括數據開發的基本運行環境和各類工具的組合，如ETL工具，模型設計工具，腳本開發工具，線上日志工具等等。

服務層

主要將公共數倉的公共模型數據對外包裝并提供服務，包括數據服務平臺，多維分析平臺，即席查詢平臺。

應用層

基于數據服務的數據產品，另外數據安全、數據質量和數據治理總是貫穿始終。

二、京東零售大數據的發展過程

1、發展階段

京東零售大數據發展的幾個階段如下：

1）第一階段

業務驅動數據技術發展，業務野蠻生長，以解決業務痛點為核心，導致煙囪式誕生了一些小數據平臺。

2）第二階段

業務精細化運營，數據平臺將多業務線條、多場景的能力進行沉淀，形成數據資產。

3）第三階段

數據中臺化建設已完成，數據驅動業務，通過數據挖掘、分析和人工智能，規模化的賦能業務，經過3個階段的發展，百家爭鳴的數據平臺也逐步過渡到百花齊放的數據中臺。

2、業務場景

京東有最全的線上零售全鏈路業務場景：

始于用戶，平臺提供訂單、營銷、流量場、財務結算、供應鏈及商品管理，后端有倉儲和配送。

基于整個零售業務，構建全域的數據資產體系，使業務數據化，數據業務化，沉淀業務模型資產，反哺于業務。

3、面臨的挑戰

數倉建設過程中面臨如下挑戰：

煙囪式的開發，各自顧各自的業務，模型重復建設，口徑不統一，給業務造成困擾也浪費了資源；

數據爆炸式的增長，硬件成本增長的邊際效應越來越低；

海量數據，如何評估數據的價值，如何治理海量數據；

業務復雜度高，全渠道多業態帶來的數據拓展的新挑戰；

實時數據需求多，實時開發門檻高周期長；

數據時效性保障，數據指數級增長，但是時效不能增長。

4、核心需求

解決以上的挑戰，我們需要有以下4個維度構建數倉核心能力：

1）數倉架構

從煙囪式的數據開發到統一的數倉分層架構，將煙囪式的通用數據模型層按職責重新劃分為:維度層、基礎數據層和公共數據層。

維度層

用戶來分析數據的窗口，維度表中包含事實表中記錄的特性。

基礎數據層

數倉的核心層，負責統一的數據清洗、整合，實現各主題模型標準化，屏蔽業務系統干擾，保障基礎數據的高可用。

公共數據層

數倉中使用率最高的：

-D：統一口徑封裝，提供各主題統一維度和指標的明細數據；

-S：統一口徑封裝，提供各主題統一維度和指標的聚合數據。

2）數據建模

提供統一的數據建模方法論和工具，規范建模過程，統一維度和指標管理。

數倉建模分兩類視角，包括業務域視角和主題視角；

數據業務域根據零售的具體業務進行劃分，層次和分類相對靈活，數據主題也就是咱們經常提到的數倉主題，如商品、流量、交易、用戶等等；

基于統一維度市場選取模型維度，標準化的描述指標及派生指標邏輯，消除指標口徑的二義性，從開放式的數據開發到規范建模。

3）數據資產管理

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

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

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

4）數據質量保障

主要包括3個角度，準確性、及時性和一致性。

事前預警：按照標準化的開發流程，生產與開發隔離，對打包、預發和上線流程進行檢查和驗證。

事中監控：全鏈路監控，任務運行時效告警監控,出現問題能快速發現。

事后恢復：快速定位快速恢復，時效性高的任務可通過快跑通道一鍵快跑 。并且自動對事故進行記錄、分類，便于復盤。

三、京東零售數倉核心能力和場景實踐

1、離線：海量數據快速更新實踐

1）場景

舉一個刷崗的場景，什么是刷崗?就是將發生在該SKU的歷史事實數據變更，需要按照最新的SKU崗位等維度信息，進行歷史數據回溯，刷崗面臨的挑戰：

數據量級大；

維度組合爆炸，刷完明細模型還要刷匯總模型；

刷新的頻率高，SKU的維度信息每天都會更新。

2）解決方案

我們的解決方案如下：

全量刷新，數據量小的場景適用；

增量刷新，數據量大的場景，只處理變更的字段，關聯最新的維表分區，相較于全量，效率高一些；

借助OLAP，基于Clickhouse，在CK中刷崗，事實明細、字典維表按同一字段分片，更新增量變動分片數據，效率高，成本較低；

融合數據刷新服務，融合OLAP+Spark預計算方案，基于Iceberg的增量更新，成本低，效率高。

2、實時：基于Flink的實時數倉架構演進

實時數倉，傳統的建模方式與離線類似，按貼源層、明細層、匯總層等分層模式進行建模，但這樣會造成數據鏈路長，降低了數據的實時性，同時實時中沒有用到的指標也需要計算，導致資源開銷大吞吐增加、時延增加。

因此我們通過解耦邏輯模型構建和物理執行過程，通過邏輯模型搭建實時數倉體系，同時通過智能物化縮短物理執行鏈路，節約計算存儲資源。

3、批流一體：基于Iceberg的實時數據湖架構

1）Lambda架構痛點

Lambda本來是為了在處理大規模數據時，同時發揮流處理和批處理的優勢，但是lambda架構也有痛點，如：

需要維護實時、離線兩套引擎；

需要維護兩套業務邏輯相同的代碼；

因為兩條不同的數據鏈路，容易造成數據不一致；

數據更新成本高，需要重跑兩個鏈路；

實時數據受限于消息隊列的存儲，回溯能力弱。

因為lambda架構有顯而易見的缺點，所以我們也在嘗試基于flink+iceberg 的實時數據湖批流一體的方案。

我們調研了 Delta、Hudi、Iceberg 三個開源項目，Delta 和 Hudi 跟 Spark 綁定太深，而Iceberg支持更多的分析引擎：不綁定特定的計算引擎，目前支持的計算引擎有 Spark、Flink、Presto 以及 Hive。

Iceberg 正在朝著流批一體的數據湖存儲層發展，而我們知道 Flink 已經是 一個流批一體的計算引擎，可以說這二者的長遠規劃完美匹配，未來二者將合力打造流批一體的數據湖架構。相較于數據倉庫，數據湖有如下特征：

ACID 語義保證；

支持數據更新，提供了upsert能力，可以極大地縮小數據入庫延遲；

高效 Table Schema 的變更；

同時支持流批讀寫，不會出現臟讀等現象。

實時的數據通過 Flink 寫入 Iceberg 表中，近實時鏈路可以通過Flink/Spark 計算增量數據，離線鏈路也可以通過 Flink/Spark批計算讀取某個快照做全局 分析，得到對應的分析結果，供不同場景下的用戶讀取和分析。經過這種改進之后，我們把計算引擎統一成 Flink/Spark，把存儲組件統一成 了 Iceberg，整個系統的維護開發成本大大降低。

四、未來展望

站在當下看未來，在數據湖的發展過程中，湖倉一體數據架構被推上了風口浪尖。湖倉一體架構的出現結合了傳統數據倉庫和數據湖的優勢，將數據倉庫和數據湖進行了打通，兼具靈活存儲的同時極大地降低了數據管理、計算和存儲成本。

湖倉一體有一些關鍵特性，如事務支持，Schema支持，端到端的流式支持，計算存儲分離等。使得數據的存儲變得更加廉價和具有彈性，并且在提升數據質量上有長足的進步。

再往前看一步，云原生數倉已破繭而出，支持批量計算與交互分析的MPP高性能分析型能力，實時數據處理能力和在線交互查詢能力，可視化數據建模，規范化指標構建能力，基于這些能力之上的業務價值和商業價值，就如同云原生架構將重構整個IT基礎設施一樣，云原生數倉必將在數倉領域帶來一場巨變。