愛鋒貝

標(biāo)題: 王晶晶：京東零售海量日志數(shù)據(jù)處理實(shí)踐 [打印本頁]
作者: 芳芳搞機(jī)    時(shí)間: 2022-10-6 01:39
標(biāo)題: 王晶晶：京東零售海量日志數(shù)據(jù)處理實(shí)踐
(, 下載次數(shù): 11)
導(dǎo)讀：本次分享主要從三個(gè)方面介紹京東流量場(chǎng)下的數(shù)據(jù)處理方案，同時(shí)也會(huì)結(jié)合京東實(shí)際場(chǎng)景案例，介紹京東在流量場(chǎng)下的一些數(shù)據(jù)應(yīng)用和實(shí)踐。
全文會(huì)圍繞以下三方面內(nèi)容展開：
01 京東零售流量數(shù)倉架構(gòu)

1. 京東零售——流量簡(jiǎn)介

① 什么是流量？
簡(jiǎn)單來說，流量就是用戶作用在京東頁面上，產(chǎn)生一系列行為數(shù)據(jù)的集合。
② 流量數(shù)據(jù)的來源
數(shù)據(jù)來源主要是移動(dòng)端和PC端，以及線下店、外部采買、合作商的數(shù)據(jù)等。

(, 下載次數(shù): 10)

這些數(shù)據(jù)是如何流轉(zhuǎn)到數(shù)倉的呢？
2. 京東零售——流量數(shù)據(jù)處理架構(gòu)

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

(, 下載次數(shù): 11)

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



(, 下載次數(shù): 10)

數(shù)據(jù)流轉(zhuǎn)到數(shù)倉會(huì)進(jìn)行一些統(tǒng)一化的管理，數(shù)倉是如何分層的呢？
受京東業(yè)務(wù)復(fù)雜度和數(shù)據(jù)體量的影響，整體分層較細(xì)，分為：數(shù)據(jù)緩沖層（BDM）、貼源數(shù)據(jù)層（FDM）、基礎(chǔ)數(shù)據(jù)層（GDM）、公共數(shù)據(jù)層（ADM）、應(yīng)用數(shù)據(jù)層（APP）五層。
① BDM層
是源業(yè)務(wù)系統(tǒng)的一些數(shù)據(jù)，會(huì)進(jìn)行永久性保存。
② FDM層
主要是從報(bào)文日志轉(zhuǎn)化成業(yè)務(wù)格式，對(duì)業(yè)務(wù)字段進(jìn)行拆解、排序和數(shù)據(jù)回寫等，例如用戶逛京東時(shí)前期未登錄，最終下單時(shí)才登陸，那對(duì)用戶全鏈路回寫便是在這一層進(jìn)行。
③ GDM層
按照主題域進(jìn)行標(biāo)準(zhǔn)化封裝，整體會(huì)屏蔽生產(chǎn)系統(tǒng)干擾，同時(shí)會(huì)處理數(shù)據(jù)回灌事情。
④ ADM層
ADM是公共數(shù)據(jù)層，面向主題、面向業(yè)務(wù)過程的數(shù)據(jù)整合，目前劃分成兩層：ADM-D、ADM-S。
⑤ APP層
數(shù)據(jù)看板的數(shù)據(jù)整合，也可以進(jìn)行一些跨主題的聚合數(shù)據(jù)處理。
⑥ 維度層
DIM層主要就是一些通用的維度數(shù)據(jù)。
基于以上的數(shù)倉分層方案，來看下京東流量數(shù)倉架構(gòu)在離線和實(shí)時(shí)上別分是如何處理的。
4. 京東零售-流量離線數(shù)倉架構(gòu)



(, 下載次數(shù): 11)

① 基礎(chǔ)數(shù)據(jù)層
離線數(shù)倉最下面一部分是基礎(chǔ)數(shù)據(jù)，主要面向?qū)嶓w模型建設(shè)，按照數(shù)據(jù)渠道和不同類型做數(shù)據(jù)整合，例如渠道：app、pc、m等；日志類型：瀏覽、點(diǎn)擊、曝光等。
② 公共數(shù)據(jù)層
這一層也是大家應(yīng)用比較廣泛的一層，上面也提到了adm面向業(yè)務(wù)過程的模型建設(shè)，這層也是分成了明細(xì)和匯總兩層。在明細(xì)層，我們會(huì)把所有的業(yè)務(wù)口徑沉淀到adm明細(xì)中，封裝各種業(yè)務(wù)標(biāo)識(shí)，保障數(shù)據(jù)口徑統(tǒng)一管理，避免口徑二義性，同時(shí)，為數(shù)據(jù)可視化管理，提供源數(shù)據(jù)依賴。
③ 應(yīng)用數(shù)據(jù)層
應(yīng)用層主要是面向數(shù)據(jù)看板的建設(shè)，提供預(yù)計(jì)算和OLAP兩種方式服務(wù)模式，這一層整體上會(huì)很薄，重點(diǎn)解決數(shù)據(jù)引擎查詢效率問題，高頻訪問的維度提供預(yù)計(jì)算、低頻應(yīng)用的數(shù)據(jù)由OLAP方式提供數(shù)據(jù)服務(wù)。
④ 數(shù)據(jù)服務(wù)層
面向多維數(shù)據(jù)分析場(chǎng)景，進(jìn)行指標(biāo)和維度的統(tǒng)一管理，以及服務(wù)接口的可視化管理，對(duì)外提供統(tǒng)一的數(shù)據(jù)服務(wù)。
5. 京東零售——流量實(shí)時(shí)數(shù)倉架構(gòu)

實(shí)時(shí)數(shù)倉與離線數(shù)倉的建設(shè)理念是基本一致的。
RDDM是分渠道、分站點(diǎn)、分日志類型的實(shí)時(shí)數(shù)據(jù)流，構(gòu)建過程中主要考慮解耦，如果只消費(fèi)部分?jǐn)?shù)據(jù)，依然需要全量讀取，對(duì)帶寬、i/o都是一種浪費(fèi)。同時(shí)，也方便下游按照業(yè)務(wù)實(shí)際情況進(jìn)行數(shù)據(jù)融合。
RADM面向業(yè)務(wù)場(chǎng)景，在RDDM的基礎(chǔ)上進(jìn)行整體封裝整合，例如商詳、來源去向、路徑樹等業(yè)務(wù)場(chǎng)景。
在整體封裝后，數(shù)據(jù)會(huì)接入到指標(biāo)市場(chǎng)，按照統(tǒng)一的接口協(xié)議和元數(shù)據(jù)管理規(guī)范進(jìn)行錄入，對(duì)外提供統(tǒng)一的數(shù)據(jù)服務(wù)。
以上主要介紹了京東流量場(chǎng)景的數(shù)據(jù)處理架構(gòu)，接下來我們結(jié)合一個(gè)京東實(shí)際案例，講述京東特殊場(chǎng)景下的數(shù)據(jù)處理方案。

(, 下載次數(shù): 13)

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

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

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

(, 下載次數(shù): 11)

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

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

(, 下載次數(shù): 11)

刷崗在京東也經(jīng)歷了多個(gè)階段，從最初數(shù)據(jù)量較小，采取全量刷崗的模式，后續(xù)逐漸升級(jí)成增量的刷崗。后續(xù)采取OLAP的刷崗模式，也就是將數(shù)據(jù)寫到CK中，通過Local join進(jìn)行關(guān)聯(lián)查詢。目前我們通過iceberg+olap的方式來實(shí)現(xiàn)數(shù)據(jù)刷崗。
首先構(gòu)建iceberg表；其次、對(duì)流量商品表的更新處理，將所有會(huì)發(fā)生變化的字段拼接做MD5的轉(zhuǎn)化，后續(xù)每天做這種差異化的判斷，如果有變化就做upsert操作；最后，生成的流量商品表與事實(shí)表進(jìn)行merge into，進(jìn)而得到刷崗更新后的數(shù)據(jù)；同時(shí)在此數(shù)據(jù)基礎(chǔ)上，針對(duì)不同應(yīng)用頻率的數(shù)據(jù)，采取了預(yù)計(jì)算和OLAP兩種數(shù)據(jù)服務(wù)模式。
通過數(shù)據(jù)湖的方式來實(shí)現(xiàn)數(shù)據(jù)更新，相比于hive存儲(chǔ)格式，支持多版本并發(fā)控制，同時(shí)支持ACID事務(wù)語義，保障他的一致性，數(shù)據(jù)在同一個(gè)批次內(nèi)提交，要么全對(duì)，要么全錯(cuò)，不會(huì)更新一部分。另外，支持增量數(shù)據(jù)導(dǎo)入和更新刪除能力，支持upsert操作，整天數(shù)據(jù)處理的復(fù)雜度要降低很多，同時(shí)在資源的消耗和性能以及數(shù)據(jù)處理范圍上較hive端模式都有了極大的提升。
基于數(shù)據(jù)湖的模式進(jìn)行刷崗目前還面臨數(shù)據(jù)傾斜的問題需要解決。

(, 下載次數(shù): 13)
3. 數(shù)據(jù)傾斜治理方案


(, 下載次數(shù): 11)

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

(, 下載次數(shù): 12)

② 數(shù)據(jù)傾斜的解決方案
基于此，我們?cè)谔剿鞯倪^程中建立了一套智能監(jiān)測(cè)傾斜的任務(wù)。
首先，利用實(shí)時(shí)的數(shù)據(jù)，提前對(duì)數(shù)據(jù)進(jìn)行監(jiān)測(cè)，針對(duì)數(shù)據(jù)分布特點(diǎn)，通過3倍標(biāo)準(zhǔn)差確定離群點(diǎn)，離群點(diǎn)即傾斜閾值。
其次，根據(jù)傾斜閾值計(jì)算分桶數(shù)量。
最后，按照對(duì)列資源在不同時(shí)段的健康度進(jìn)行作業(yè)編排。
③ 如何尋找熱點(diǎn)key及傾斜閾值
熱key尋找的核心思想，就是根據(jù)數(shù)據(jù)的分布特點(diǎn)，通過3倍標(biāo)準(zhǔn)差確定離群點(diǎn)，離群點(diǎn)即傾斜閾值，如下圖所示，整體的數(shù)據(jù)是呈右偏分布，我們通過兩次3倍標(biāo)準(zhǔn)差得到最后的傾斜閾值X2。
第二步計(jì)算分桶的數(shù)量，根據(jù)整體的數(shù)據(jù)分布情況看，第一階段的拒絕域面積與第二階段的拒絕域面積相等。根據(jù)積分原理，頻率絕對(duì)數(shù)與頻次絕對(duì)數(shù)呈反比，因概率密度分布曲線未知，所以用兩次離群點(diǎn)的頻次均值比例，代表兩次抽樣數(shù)據(jù)量比例，進(jìn)而得到分桶數(shù)。

(, 下載次數(shù): 12)

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

(, 下載次數(shù): 10)
--
03 數(shù)據(jù)處理架構(gòu)未來探索

1. 未來探索方向

首先，目前我們基于Flink+Spark的方式來做流批一體的探索。圖中可以看到傳統(tǒng)的Lambda數(shù)據(jù)架構(gòu)有一個(gè)很大的特點(diǎn)：實(shí)時(shí)和離線是兩套不同的數(shù)據(jù)鏈路。整體的數(shù)據(jù)處理過程中，研發(fā)的運(yùn)維成本相對(duì)較高，而且兩條不同的數(shù)據(jù)鏈路，會(huì)容易導(dǎo)致數(shù)據(jù)口徑上的差異。
后續(xù)通過FlinkSQL+數(shù)據(jù)湖存儲(chǔ)實(shí)現(xiàn)同一套代碼兩種計(jì)算模式，同時(shí)保證計(jì)算口徑一致性。同時(shí)也會(huì)有一些挑戰(zhàn)，開發(fā)模式的改變，CDC（change data capture）延遲目前是分鐘級(jí)延遲，如果調(diào)整為秒級(jí)，頻繁提交，會(huì)生成很多小版本，對(duì)數(shù)據(jù)湖的吞吐量造成影響，總體來說，在部分應(yīng)用場(chǎng)景下存在一定局限性，但分鐘級(jí)延遲可以滿足大多數(shù)的實(shí)時(shí)應(yīng)用場(chǎng)景，對(duì)于研發(fā)成本和效率都會(huì)有較大提升，當(dāng)然，目前也在不斷的完成和探索。總體來說，目前在一些特殊場(chǎng)景下具有一定的局限性。

(, 下載次數(shù): 11)
--
04 問答環(huán)節(jié)

Q：分桶的應(yīng)用效果？
A：總結(jié)成幾個(gè)點(diǎn)就是：
Q：Spark的應(yīng)用在京東場(chǎng)景里最小的延遲是多少？
A：目前主要是基于小站點(diǎn)數(shù)據(jù)去做探索，數(shù)據(jù)處理量級(jí)比較小，目前延遲大概在分鐘級(jí)左右，如提交的頻率增大，對(duì)于io的性能會(huì)是一個(gè)很大的考驗(yàn)。
Q：Spark應(yīng)該是不支持行級(jí)別的upsert，京東這邊是怎么去解決這個(gè)問題的問題，分區(qū)和小文件的合并有哪些相關(guān)的經(jīng)驗(yàn)分享？
A：目前的版本可以支持行級(jí)更新，關(guān)于分區(qū)這部分主要還是結(jié)合業(yè)務(wù)特性，在設(shè)計(jì)分區(qū)時(shí)，盡量讓變化的數(shù)據(jù)都集中到少部分文件上，降低文件更新范圍。
今天的分享就到這里，謝謝大家。
閱讀更多技術(shù)干貨文章、下載講師PPT，請(qǐng)關(guān)注微信公眾號(hào)“DataFunTalk”。
分享嘉賓：王晶晶 京東 數(shù)據(jù)架構(gòu)師
編輯整理：張劍秋 火花思維
出品平臺(tái)：DataFunTalk
分享嘉賓：

(, 下載次數(shù): 10)
活動(dòng)推薦：

---【DataFunSummit2022：數(shù)據(jù)安全與隱私計(jì)算峰會(huì)】

2. 地點(diǎn)：DataFunTalk直播間
3. 報(bào)名：添加小助手報(bào)名觀看
誠邀各位粉絲朋友們參加本次直播峰會(huì)！峰會(huì)結(jié)束后我們會(huì)在公眾號(hào)【DataFunSummit】更新所有講師的PPT資料，屆時(shí)可回復(fù)關(guān)鍵字【20220709】免費(fèi)下載！
以下是本次峰會(huì)的【多方安全學(xué)習(xí)論壇】介紹：

(, 下載次數(shù): 12)
關(guān)于我們：
DataFun：專注于大數(shù)據(jù)、人工智能技術(shù)應(yīng)用的分享與交流。發(fā)起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會(huì)，已邀請(qǐng)超過2000位專家和學(xué)者參與分享。其公眾號(hào) DataFunTalk 累計(jì)生產(chǎn)原創(chuàng)文章700+，百萬+閱讀，14萬+精準(zhǔn)粉絲。
歡迎轉(zhuǎn)載分享評(píng)論，轉(zhuǎn)載請(qǐng)私信。

-----------------------------



歡迎光臨 愛鋒貝 (http://7gfy2te7.cn/) Powered by Discuz! X3.4