背景

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

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

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

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

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

當前遇到的問題

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

1. 成本很高

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

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

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

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

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

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

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

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

解決方案和技術細節(jié)

最終采用的方案是：

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

架構圖來自官方分享：

圖片

我們稍微展開詳細分析：

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

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

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

技術細節(jié)上：

1. 分鐘級的DWS設計

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

2. 實時維度表

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

3. Shema設計

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

4. 維度表設計

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

收益

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

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

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

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

2. 計算和迭代成本上

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

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

3. 查詢性能上

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

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