背景

我們先分析一下小紅書的一些業務背景。

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

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

所以從背景和需求上來看，當前業務場景核心的業務訴求有兩個：

1. 時效性，要求分鐘級；
2. 全量計算，且保證數據準確。

當前遇到的問題

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

1. 成本很高

Flink任務作為常駐任務，消耗超過5000core，且因為超大數據量導致狀態很大（如大開窗聚合），內存壓力很大，并且資源成本隨流量增長線性上升。

這是經典的Flink處理超大流量數據，并且需要狀態計算帶來的問題，資源消耗是一方面，另外一方面就是穩定性問題。

2. 兩條鏈路帶來的高復雜度

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

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

3. 開發成本和風險高

超大數據規模下的大窗口(如7天)，狀態膨脹嚴重，所以需要縮小時間窗口，但是帶來的數據質量問題。

并且因為實驗指標頻繁變更，schema變更導致任務開發迭代周期較長。

解決方案和技術細節

最終采用的方案是：

• Iceberg+Paimon實現數據存儲和消費
• Spark分鐘級調度產出分鐘級匯總數據
• StarRocks讀取湖數據實現加速查詢

架構圖來自官方分享：

圖片

我們稍微展開詳細分析：

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

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

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

技術細節上：

1. 分鐘級的DWS設計

在模型設計層面，設計了<分鐘，user_id> 粒度的數據，把明細日志轉化成了5分鐘+用戶粒度的DWS層數據，同時在分鐘級調度任務中關聯用戶維表，整體數據規模大幅度縮小。

2. 實時維度表

用戶實時Kafka數據對維度表進行分鐘級更新；天級更新的維度，通過離線調度寫入。通過判斷表中的時間戳，實現按需更新。

3. Shema設計

每當有指標增減，會涉及寬表的schema evolution，會導致上下游表結構的訂正。采用JSON結構存儲算法指標，實現用戶在JSON列中自助增減指標，提升開發效率。

4. 維度表設計

當前這個場景，通過UDF中更新用戶實驗維度表。并且設計了用戶實驗維表的格式為<user_id,exp_ids>，exp_ids的數據結構為array，并且對exp_ids建立倒排索引，查詢效率大幅提升。

收益

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

1.時效和數據質量上

在滿足業務需求的前提下，時效變為分鐘級，并且可以動態調整計算周期，平衡不同場景下的時效性與資源消耗。

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

2. 計算和迭代成本上

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

此外采用JSON半結構化建模，不需要修改表結構，開發效率提升50%+。

3. 查詢性能上

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

以上就是本次學習和分享的內容，希望對大家有幫助。