背景

我們先分析一下小紅書的一些業(yè)務(wù)背景。

小紅書是典型UGC內(nèi)容平臺(tái)，很多公司都有類似的業(yè)務(wù)場(chǎng)景。從業(yè)務(wù)背景上，小紅書當(dāng)前的主要業(yè)務(wù)場(chǎng)景是處理用戶行為日志（如瀏覽、點(diǎn)贊、收藏），覆蓋推薦、搜索、電商等核心場(chǎng)景，數(shù)據(jù)增量日軍千億級(jí)別。

算法需要進(jìn)行分鐘級(jí)的調(diào)參，并且實(shí)驗(yàn)指標(biāo)需要進(jìn)行全量計(jì)算，且要求實(shí)時(shí)和離線指標(biāo)實(shí)現(xiàn)最終一致（差異＜1%）。

所以從背景和需求上來(lái)看，當(dāng)前業(yè)務(wù)場(chǎng)景核心的業(yè)務(wù)訴求有兩個(gè)：

1. 時(shí)效性，要求分鐘級(jí)；
2. 全量計(jì)算，且保證數(shù)據(jù)準(zhǔn)確。

當(dāng)前遇到的問(wèn)題

在采用湖倉(cāng)和增量計(jì)算前，小紅書也是采用了經(jīng)典的Lamda架構(gòu)，也就是離線和實(shí)時(shí)兩條鏈路。在這個(gè)過(guò)程中遇到了非常經(jīng)典的問(wèn)題：

1. 成本很高

Flink任務(wù)作為常駐任務(wù)，消耗超過(guò)5000core，且因?yàn)槌髷?shù)據(jù)量導(dǎo)致?tīng)顟B(tài)很大（如大開(kāi)窗聚合），內(nèi)存壓力很大，并且資源成本隨流量增長(zhǎng)線性上升。

這是經(jīng)典的Flink處理超大流量數(shù)據(jù)，并且需要狀態(tài)計(jì)算帶來(lái)的問(wèn)題，資源消耗是一方面，另外一方面就是穩(wěn)定性問(wèn)題。

2. 兩條鏈路帶來(lái)的高復(fù)雜度

Lamda架構(gòu)的痛點(diǎn)之一，實(shí)時(shí)鏈路（Flink+Redis+ClickHouse）與離線鏈路（Spark+Hive）邏輯割裂，維表更新、指標(biāo)計(jì)算一致性難以保障。

并且在這個(gè)過(guò)程中因?yàn)樾枰ㄟ^(guò)維度表拓維，實(shí)時(shí)鏈路依賴的 KV 存儲(chǔ)成為瓶頸。

3. 開(kāi)發(fā)成本和風(fēng)險(xiǎn)高

超大數(shù)據(jù)規(guī)模下的大窗口(如7天)，狀態(tài)膨脹嚴(yán)重，所以需要縮小時(shí)間窗口，但是帶來(lái)的數(shù)據(jù)質(zhì)量問(wèn)題。

并且因?yàn)閷?shí)驗(yàn)指標(biāo)頻繁變更，schema變更導(dǎo)致任務(wù)開(kāi)發(fā)迭代周期較長(zhǎng)。

解決方案和技術(shù)細(xì)節(jié)

最終采用的方案是：

• Iceberg+Paimon實(shí)現(xiàn)數(shù)據(jù)存儲(chǔ)和消費(fèi)
• Spark分鐘級(jí)調(diào)度產(chǎn)出分鐘級(jí)匯總數(shù)據(jù)
• StarRocks讀取湖數(shù)據(jù)實(shí)現(xiàn)加速查詢

架構(gòu)圖來(lái)自官方分享：

圖片

我們稍微展開(kāi)詳細(xì)分析：

關(guān)于湖框架的技術(shù)選型，這里小紅書選擇了Iceberg作為基座，Paimon作為維度表，當(dāng)然因?yàn)椴煌镜募夹g(shù)棧不同，用戶可以靈活選擇自己公司當(dāng)前在用的框架。Iceberg采用append only模式寫入數(shù)據(jù)，同時(shí)提供給離線和實(shí)時(shí)兩條鏈路使用（因?yàn)橄掠问荢park的分鐘級(jí)調(diào)度，其實(shí)只有準(zhǔn)實(shí)時(shí)這一條鏈路了）；

同時(shí)利用Paimon強(qiáng)大的維度表能力，選擇Paimon作為維度表存儲(chǔ)，減少對(duì)KV存儲(chǔ)的依賴。

其次，利用StarRocks作為查詢引擎，直接查詢結(jié)果數(shù)據(jù)進(jìn)行聚合，這也是我們?cè)跀?shù)據(jù)開(kāi)發(fā)上經(jīng)常用到的使用StarPocks、Doris等直接讀取離線數(shù)據(jù)進(jìn)行加速查詢的場(chǎng)景。

技術(shù)細(xì)節(jié)上：

1. 分鐘級(jí)的DWS設(shè)計(jì)

在模型設(shè)計(jì)層面，設(shè)計(jì)了<分鐘，user_id> 粒度的數(shù)據(jù)，把明細(xì)日志轉(zhuǎn)化成了5分鐘+用戶粒度的DWS層數(shù)據(jù)，同時(shí)在分鐘級(jí)調(diào)度任務(wù)中關(guān)聯(lián)用戶維表，整體數(shù)據(jù)規(guī)模大幅度縮小。

2. 實(shí)時(shí)維度表

用戶實(shí)時(shí)Kafka數(shù)據(jù)對(duì)維度表進(jìn)行分鐘級(jí)更新；天級(jí)更新的維度，通過(guò)離線調(diào)度寫入。通過(guò)判斷表中的時(shí)間戳，實(shí)現(xiàn)按需更新。

3. Shema設(shè)計(jì)

每當(dāng)有指標(biāo)增減，會(huì)涉及寬表的schema evolution，會(huì)導(dǎo)致上下游表結(jié)構(gòu)的訂正。采用JSON結(jié)構(gòu)存儲(chǔ)算法指標(biāo)，實(shí)現(xiàn)用戶在JSON列中自助增減指標(biāo)，提升開(kāi)發(fā)效率。

4. 維度表設(shè)計(jì)

當(dāng)前這個(gè)場(chǎng)景，通過(guò)UDF中更新用戶實(shí)驗(yàn)維度表。并且設(shè)計(jì)了用戶實(shí)驗(yàn)維表的格式為<user_id,exp_ids>，exp_ids的數(shù)據(jù)結(jié)構(gòu)為array，并且對(duì)exp_ids建立倒排索引，查詢效率大幅提升。

收益

最終增量計(jì)算+實(shí)時(shí)湖倉(cāng)的方式，當(dāng)前場(chǎng)景下效果顯著：

1.時(shí)效和數(shù)據(jù)質(zhì)量上

在滿足業(yè)務(wù)需求的前提下，時(shí)效變?yōu)榉昼娂?jí)，并且可以動(dòng)態(tài)調(diào)整計(jì)算周期，平衡不同場(chǎng)景下的時(shí)效性與資源消耗。

鏈路上從原來(lái)Lambda兩條鏈路演變成湖倉(cāng)一條鏈路，數(shù)據(jù)差異大幅降低至＜1%。

2. 計(jì)算和迭代成本上

近實(shí)時(shí)鏈路資源消耗上降低明顯(為原來(lái)的36%)，預(yù)聚合的方式將數(shù)據(jù)量從數(shù)千億條日志壓縮至數(shù)億條，存儲(chǔ)成本同比下降約90%。

此外采用JSON半結(jié)構(gòu)化建模，不需要修改表結(jié)構(gòu)，開(kāi)發(fā)效率提升50%+。

3. 查詢性能上

通過(guò)分鐘級(jí)DWS層(5分鐘+用戶粒度聚合),將明細(xì)查詢轉(zhuǎn)換為聚合結(jié)果查詢，查詢P90延遲從分鐘級(jí)優(yōu)化至＜10秒。

以上就是本次學(xué)習(xí)和分享的內(nèi)容，希望對(duì)大家有幫助。