導讀：本次分享主要從三個方面介紹京東流量場下的數(shù)據(jù)處理方案，同時也會結合京東實際場景案例，介紹京東在流量場下的一些數(shù)據(jù)應用和實踐。

全文會圍繞以下三方面內(nèi)容展開：

京東零售流量數(shù)倉架構

京東零售場景的數(shù)據(jù)處理

數(shù)據(jù)處理架構未來探索

01京東零售流量數(shù)倉架構

1. 京東零售——流量簡介

① 什么是流量？

簡單來說，流量就是用戶作用在京東頁面上，產(chǎn)生一系列行為數(shù)據(jù)的集合。

② 流量數(shù)據(jù)的來源

數(shù)據(jù)來源主要是移動端和PC端，以及線下店、外部采買、合作商的數(shù)據(jù)等。

這些數(shù)據(jù)是如何流轉到數(shù)倉的呢？

2. 京東零售——流量數(shù)據(jù)處理架構

由架構圖可以看出，對不同的終端采取不同的采集模式；例如，對APP原生頁面采取SDK的采集模式，對于PC、H5頁面是JS采集，數(shù)據(jù)采集后按照實時和離線雙寫，離線直接寫到CFS分布式文件系統(tǒng)中，每小時從CFS拉取數(shù)據(jù)文件，同時對數(shù)據(jù)文件大小、采集ip進行監(jiān)控，防止數(shù)據(jù)丟失；實時是以白名單的方式動態(tài)配置，寫到kafka中，最后將數(shù)據(jù)入倉。

3. 京東零售——流量數(shù)倉分層介紹

數(shù)據(jù)流轉到數(shù)倉會進行一些統(tǒng)一化的管理，數(shù)倉是如何分層的呢？

受京東業(yè)務復雜度和數(shù)據(jù)體量的影響，整體分層較細，分為：數(shù)據(jù)緩沖層（BDM）、貼源數(shù)據(jù)層（FDM）、基礎數(shù)據(jù)層（GDM）、公共數(shù)據(jù)層（ADM）、應用數(shù)據(jù)層（APP）五層。

① BDM層

是源業(yè)務系統(tǒng)的一些數(shù)據(jù)，會進行永久性保存。

② FDM層

主要是從報文日志轉化成業(yè)務格式，對業(yè)務字段進行拆解、排序和數(shù)據(jù)回寫等，例如用戶逛京東時前期未登錄，最終下單時才登陸，那對用戶全鏈路回寫便是在這一層進行。

③ GDM層

按照主題域進行標準化封裝，整體會屏蔽生產(chǎn)系統(tǒng)干擾，同時會處理數(shù)據(jù)回灌事情。

④ ADM層

ADM是公共數(shù)據(jù)層，面向主題、面向業(yè)務過程的數(shù)據(jù)整合，目前劃分成兩層：ADM-D、ADM-S。

ADM-D負責統(tǒng)一的數(shù)據(jù)口徑封裝，提供各主題統(tǒng)一維度和指標的最細粒度數(shù)據(jù)；

ADM-S提供各主題統(tǒng)一維度和指標的聚合數(shù)據(jù)， 為各業(yè)務方提供統(tǒng)一口徑的共享數(shù)據(jù)。

⑤ APP層

數(shù)據(jù)看板的數(shù)據(jù)整合，也可以進行一些跨主題的聚合數(shù)據(jù)處理。

⑥ 維度層

DIM層主要就是一些通用的維度數(shù)據(jù)。

基于以上的數(shù)倉分層方案，來看下京東流量數(shù)倉架構在離線和實時上別分是如何處理的。

4. 京東零售-流量離線數(shù)倉架構

① 基礎數(shù)據(jù)層

離線數(shù)倉最下面一部分是基礎數(shù)據(jù)，主要面向實體模型建設，按照數(shù)據(jù)渠道和不同類型做數(shù)據(jù)整合，例如渠道：app、pc、m等；日志類型：瀏覽、點擊、曝光等。

② 公共數(shù)據(jù)層

這一層也是大家應用比較廣泛的一層，上面也提到了adm面向業(yè)務過程的模型建設，這層也是分成了明細和匯總兩層。在明細層，我們會把所有的業(yè)務口徑沉淀到adm明細中，封裝各種業(yè)務標識，保障數(shù)據(jù)口徑統(tǒng)一管理，避免口徑二義性，同時，為數(shù)據(jù)可視化管理，提供源數(shù)據(jù)依賴。

③ 應用數(shù)據(jù)層

應用層主要是面向數(shù)據(jù)看板的建設，提供預計算和OLAP兩種方式服務模式，這一層整體上會很薄，重點解決數(shù)據(jù)引擎查詢效率問題，高頻訪問的維度提供預計算、低頻應用的數(shù)據(jù)由OLAP方式提供數(shù)據(jù)服務。

④ 數(shù)據(jù)服務層

面向多維數(shù)據(jù)分析場景，進行指標和維度的統(tǒng)一管理，以及服務接口的可視化管理，對外提供統(tǒng)一的數(shù)據(jù)服務。

5. 京東零售——流量實時數(shù)倉架構

實時數(shù)倉與離線數(shù)倉的建設理念是基本一致的。

RDDM是分渠道、分站點、分日志類型的實時數(shù)據(jù)流，構建過程中主要考慮解耦，如果只消費部分數(shù)據(jù)，依然需要全量讀取，對帶寬、i/o都是一種浪費。同時，也方便下游按照業(yè)務實際情況進行數(shù)據(jù)融合。

RADM面向業(yè)務場景，在RDDM的基礎上進行整體封裝整合，例如商詳、來源去向、路徑樹等業(yè)務場景。

在整體封裝后，數(shù)據(jù)會接入到指標市場，按照統(tǒng)一的接口協(xié)議和元數(shù)據(jù)管理規(guī)范進行錄入，對外提供統(tǒng)一的數(shù)據(jù)服務。

以上主要介紹了京東流量場景的數(shù)據(jù)處理架構，接下來我們結合一個京東實際案例，講述京東特殊場景下的數(shù)據(jù)處理方案。

02京東零售場景的數(shù)據(jù)處理

1. 京東零售——流量挑戰(zhàn)

首先是數(shù)據(jù)爆炸式的增長。2015年至今，整體的數(shù)據(jù)量翻了約十幾倍，但資源情況并沒有相應成比例的增長。其次，業(yè)務的復雜度升高，包括新增了小程序、開普勒、線下店的一些數(shù)據(jù)以及并購的企業(yè)的數(shù)據(jù)等，因此整體的數(shù)據(jù)格式以及完備度上還是存在較大差異的。再次，隨著業(yè)務發(fā)展，流量精細化運營的場景增多，但數(shù)據(jù)服務的時效并沒有較大變化，需要我們在有限時間內(nèi)處理一些更多更大體量的數(shù)據(jù)，以滿足更多場景化應用。特別是京東刷崗這樣的場景，對數(shù)據(jù)的范圍、需要處理的數(shù)據(jù)量，以及數(shù)據(jù)時效都是一個比較大的挑戰(zhàn)。

2. 海量數(shù)據(jù)更新實踐——刷崗

什么是刷崗？將發(fā)生在該SKU的歷史事實數(shù)據(jù)，按照最新的SKU對應運營人員、崗位、部門等維度信息，進行歷史數(shù)據(jù)回刷。

刷崗在京東也經(jīng)歷了多個階段，從最初數(shù)據(jù)量較小，采取全量刷崗的模式，后續(xù)逐漸升級成增量的刷崗。后續(xù)采取OLAP的刷崗模式，也就是將數(shù)據(jù)寫到CK中，通過Local join進行關聯(lián)查詢。目前我們通過iceberg+olap的方式來實現(xiàn)數(shù)據(jù)刷崗。

首先構建iceberg表；其次、對流量商品表的更新處理，將所有會發(fā)生變化的字段拼接做MD5的轉化，后續(xù)每天做這種差異化的判斷，如果有變化就做upsert操作；最后，生成的流量商品表與事實表進行merge into，進而得到刷崗更新后的數(shù)據(jù)；同時在此數(shù)據(jù)基礎上，針對不同應用頻率的數(shù)據(jù)，采取了預計算和OLAP兩種數(shù)據(jù)服務模式。

通過數(shù)據(jù)湖的方式來實現(xiàn)數(shù)據(jù)更新，相比于hive存儲格式，支持多版本并發(fā)控制，同時支持ACID事務語義，保障他的一致性，數(shù)據(jù)在同一個批次內(nèi)提交，要么全對，要么全錯，不會更新一部分。另外，支持增量數(shù)據(jù)導入和更新刪除能力，支持upsert操作，整天數(shù)據(jù)處理的復雜度要降低很多，同時在資源的消耗和性能以及數(shù)據(jù)處理范圍上較hive端模式都有了極大的提升。

基于數(shù)據(jù)湖的模式進行刷崗目前還面臨數(shù)據(jù)傾斜的問題需要解決。

3. 數(shù)據(jù)傾斜治理方案

① 數(shù)據(jù)傾斜的原因及處理方式

數(shù)據(jù)傾斜出現(xiàn)的一個主要原因是數(shù)據(jù)分布不均，出現(xiàn)熱點key。對于數(shù)據(jù)傾斜的處理方案，比較常見的有：優(yōu)化參數(shù)，如增加reduce的個數(shù)、過濾一些異常值、賦隨機值，或者按經(jīng)驗值設置固定閾值，把大于某閾值的數(shù)據(jù)單獨處理。賦隨機數(shù)的處理方式，當任務執(zhí)行過程中，某個節(jié)點異常，切換新節(jié)點重新執(zhí)行，隨機數(shù)據(jù)會發(fā)生變化，導致數(shù)據(jù)異常。通過這種經(jīng)驗值設定閾值的一個弊端是，在不同的場景下，不容易界定閾值大小，包括對于熱點key的識別，通常也只能事后發(fā)現(xiàn)處理。

② 數(shù)據(jù)傾斜的解決方案

基于此，我們在探索的過程中建立了一套智能監(jiān)測傾斜的任務。

首先，利用實時的數(shù)據(jù)，提前對數(shù)據(jù)進行監(jiān)測，針對數(shù)據(jù)分布特點，通過3倍標準差確定離群點，離群點即傾斜閾值。

其次，根據(jù)傾斜閾值計算分桶數(shù)量。

最后，按照對列資源在不同時段的健康度進行作業(yè)編排。

③ 如何尋找熱點key及傾斜閾值

熱key尋找的核心思想，就是根據(jù)數(shù)據(jù)的分布特點，通過3倍標準差確定離群點，離群點即傾斜閾值，如下圖所示，整體的數(shù)據(jù)是呈右偏分布，我們通過兩次3倍標準差得到最后的傾斜閾值X2。

第二步計算分桶的數(shù)量，根據(jù)整體的數(shù)據(jù)分布情況看，第一階段的拒絕域面積與第二階段的拒絕域面積相等。根據(jù)積分原理，頻率絕對數(shù)與頻次絕對數(shù)呈反比，因概率密度分布曲線未知，所以用兩次離群點的頻次均值比例，代表兩次抽樣數(shù)據(jù)量比例，進而得到分桶數(shù)。

④ 數(shù)據(jù)分桶作業(yè)

最后是作業(yè)編排，一次性起多個任務會出現(xiàn)資源獲取不到，一直處于等待狀態(tài)，同時對其他的任務也會產(chǎn)生較大影響，并發(fā)少了又會帶來資源浪費，針對這類問題，我按照對列資源的健康度，對執(zhí)行的任務做了編排，由整體串聯(lián)執(zhí)行和固化并發(fā)，調整為按資源健康度動態(tài)擴展，實現(xiàn)資源利用最大化。

03數(shù)據(jù)處理架構未來探索

1. 未來探索方向

首先，目前我們基于Flink+Spark的方式來做流批一體的探索。圖中可以看到傳統(tǒng)的Lambda數(shù)據(jù)架構有一個很大的特點：實時和離線是兩套不同的數(shù)據(jù)鏈路。整體的數(shù)據(jù)處理過程中，研發(fā)的運維成本相對較高，而且兩條不同的數(shù)據(jù)鏈路，會容易導致數(shù)據(jù)口徑上的差異。

后續(xù)通過FlinkSQL+數(shù)據(jù)湖存儲實現(xiàn)同一套代碼兩種計算模式，同時保證計算口徑一致性。同時也會有一些挑戰(zhàn)，開發(fā)模式的改變，CDC（change data capture）延遲目前是分鐘級延遲，如果調整為秒級，頻繁提交，會生成很多小版本，對數(shù)據(jù)湖的吞吐量造成影響，總體來說，在部分應用場景下存在一定局限性，但分鐘級延遲可以滿足大多數(shù)的實時應用場景，對于研發(fā)成本和效率都會有較大提升，當然，目前也在不斷的完成和探索?？傮w來說，目前在一些特殊場景下具有一定的局限性。

04問答環(huán)節(jié)

Q：分桶的應用效果？

A：總結成幾個點就是：

從事后處理轉變?yōu)槭虑氨O(jiān)測。

不同周期、不同場景下動態(tài)計算傾斜閾值和分桶數(shù)量。

根據(jù)對列資源健康度動態(tài)擴展任務并發(fā)數(shù)量，實現(xiàn)資源利用最大化。

Q：Spark的應用在京東場景里最小的延遲是多少？

A：目前主要是基于小站點數(shù)據(jù)去做探索，數(shù)據(jù)處理量級比較小，目前延遲大概在分鐘級左右，如提交的頻率增大，對于io的性能會是一個很大的考驗。

Q：Spark應該是不支持行級別的upsert，京東這邊是怎么去解決這個問題的問題，分區(qū)和小文件的合并有哪些相關的經(jīng)驗分享？

A：目前的版本可以支持行級更新，關于分區(qū)這部分主要還是結合業(yè)務特性，在設計分區(qū)時，盡量讓變化的數(shù)據(jù)都集中到少部分文件上，降低文件更新范圍。