背景

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

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

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

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

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

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

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

1. 成本很高

Flink任務(wù)作為常駐任務(wù)，消耗超過5000core，且因為超大數(shù)據(jù)量導(dǎo)致狀態(tài)很大（如大開窗聚合），內(nèi)存壓力很大，并且資源成本隨流量增長線性上升。

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

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

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

并且在這個過程中因為需要通過維度表拓維，實時鏈路依賴的 KV 存儲成為瓶頸。

3. 開發(fā)成本和風(fēng)險高

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

并且因為實驗指標(biāo)頻繁變更，schema變更導(dǎo)致任務(wù)開發(fā)迭代周期較長。

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

最終采用的方案是：

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

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

圖片

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

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

同時利用Paimon強大的維度表能力，選擇Paimon作為維度表存儲，減少對KV存儲的依賴。

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

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

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

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

2. 實時維度表

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

3. Shema設(shè)計

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

4. 維度表設(shè)計

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

收益

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

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

在滿足業(yè)務(wù)需求的前提下，時效變?yōu)榉昼娂墸⑶铱梢詣討B(tài)調(diào)整計算周期，平衡不同場景下的時效性與資源消耗。

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

2. 計算和迭代成本上

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

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

3. 查詢性能上

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

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