小紅書是年輕人的生活記錄、分享平臺,用戶可以通過短視頻、圖文等形式記錄生活點滴,分享生活方式。在2023年后,隨著業務類型和用戶體量的爆炸式增長,各類數據分析的需求以及應用系統的數據需求快速出現,例如:商業智能分析,數據應用報表,用戶行為分析、算法策略數據等。為了滿足業務需求,小紅書使用過多種 OLAP 數據分析系統。StarRocks 采用了全面向量化計算技術,是性能非常強悍的新一代 MPP 數據庫。通過引入 StarRocks,小紅書構建了全新的統一數據服務平臺,大大降低了數據鏈路開發復雜性,提升了高并發極速查詢能力。

“ 作者:季錢飛,

小紅書數據流團隊負責人 ”

小紅書 OLAP 演進史

小紅書 OLAP 演進可以分為四個階段。第一階段,在2023年之前,數據總量還不算非常大,這個階段主要使用 AWS 的 Redshift。此階段數倉體系還沒有完全建立,很多數據需求的實現都是用短平快、煙囪式開發的方式來滿足。數據 ETL、數倉模型到最后報表端展現,在 Redshift 中一站式完成。但隨著業務復雜度不斷提升,以及數據量的快速增長,這種模式很快遇到了瓶頸。

第二階段,基于 Hadoop 生態構建了小紅書的數倉體系,基于 Hive 和 Presto 構建數據分析平臺。

第三階段,隨著數據實時性的要求越來越高,業務方對整個數據分析的性能要求也越來越高,所以在2023年左右引入了 ClickHouse。通過 ClickHouse 強悍的分析能力,構造了一個準實時的交互式的分析平臺,來支撐公司內包括用戶行為分析、實驗平臺等一系列的場景。

第四階段,隨著實時數倉體系的設計和建設不斷的推進,越來越多內部包括外部的數據應用也對數據分析要求越來越高。除了要求超低延遲的響應要求,同時還可能有比較高的 QPS 要求,ClickHouse 在這方面就不能夠很好的滿足業務的需求。所以在2023年底的時候,我們嘗試了 StarRocks,并且目前已經在公司內多個業務場景中落地推廣。

業務背景

小紅書的廣告場景大概可以分為兩類,一種是搜索廣告,一種是效果廣告。搜索廣告主要會利用實時計算出來一些統計指標,來對廣告的部分召回進行推薦。

效果廣告主要是會根據用戶的一些展點銷的信息,統計出的實時指標,再結合一些投放的實驗進行智能廣告的投放。同時,廣告平臺會根據各種業務的統計指標,產生實時或者離線的數據報告,供廣告主進行分析運營使用。

初試 StarRocks:搜索廣告場景

歷史架構與痛點

搜索業務場景主要包括三個方面的業務特征:第一個是要計算的特征的數量特別多,并且組合維度也非常的靈活。第二個是統計指標的時間粒度跨度非常廣,可能有小時級別、6小時、12小時,也有一天、兩天甚至一個月的這種時間力度。第三個是所有的維度組合統計的時間粒度,它的變更在后續可能會非常的頻繁。

在之前的架構中,主要是通過一個 Flink Java 程序去實現的。在這個 Java 程序當中,實現了所需要的所有維度組合時間粒度統計。這種架構現在來看其實是有很明顯的弊端的:首先整個架構的靈活性是非常差的。如果要做一些變更,不僅需要進行一些開發和測試,還涉及到上線發版停服的問題。第二個因為所有的業務邏輯加工都是在這個 Java 代碼中實現的,整個開發過程當中非常容易出錯。所以開發完成之后,對數據質量的校驗要花非常多的時間,導致整個業務變更的周期也會拉得很長。第三個是整個架構的擴展性是比較差的。隨著維度增長,整個 Flink 集群的性能和穩定性會受到比較大的影響。

當前架構

經過一系列的分析調研以及充分的測試,綜合考慮穩定性和性能上的優勢,我們決定基于 StarRocks 在搜索廣告場景下做一次完整的 POC。通過引入 StarRocks,將整個搜索廣告數據流的鏈路設計如圖所示:

通過 Flink 將這種前端的實時廣告打點信息,通過 Flink SQL 做了一些字段補全之后寫入到 StarRocks,然后基于 StarRocks 創建多個邏輯視圖,用來統計各個需要的特征指標。后面通過調度平臺,定期將這些特征指標再緩存到 RedKV(也是小紅書內部實現的一個分布式的 Redis 系統),下游的業務系統就可以直接進入 RedKV 進行數據的消費使用。

在這套數據鏈路設計完之后,在表結構設計的時候也經過了一些考量和選擇。最開始想的是因為數據維度組合是非常的靈活不確定的,就希望在數據經過 ETL 寫入 StarRocks 時,按照我們業務方的需要進行轉換,然后能夠動態的去調整。

所以我們設計了一套動態表結構,這個表結構里面主要會包含兩列,一個是叫 Metric Name 就是維度名稱,還有一個是維度值。在進行數據寫入到 StarRocks 時,我們在 Flink 中做了一個動態列轉行的操作。

如上圖所示,在這個原始表中有三種特征:性別、城市和年齡。下游業務消費可能需要兩種維度的組合,比如一個是性別,還有一個是性別和城市的組合。那么這3條數據經過 Flink 列轉行之后,會生成下面的5條數據。

這樣一個動態表結構的設計是有一些好處的。首先這樣能夠充分利用 StarRocks 的預聚合的能力,下游在指標獲取的時候直接轉化成點查,同時整個數據寫入之后,實時性會更好。但是這個鏈路的缺點也是比較明顯的。一是整個 Flink 的寫入程序是相對比較復雜的。第二是在這個過程當中,數據膨脹也是比較厲害的,尤其在維度帶有搜索詞的場景中,數據膨脹非常嚴重。第三是隨著維度的增加,也會影響整個 Flink 的程序的性能和穩定性,整個架構的擴展性也會受到影響。所以在包含搜索詞的場景中,我們就考慮通過一種靜態表的結構來實現業務統計的需求。通過這個靜態表,Flink 端只要做簡單的 ETL 把明細數據寫到 StarRocks 就行了。通過這種方式可以大大簡化入庫程序,同時也有效避免了數據膨脹的問題,但是這個方式帶來的風險就是下游需要基于明細表去按照自己的需求做統計分析,它的性能能不能滿足業務的需求。

在搜索這個場景開發完成之后做了一系列的測試,發現基于 StarRocks 明細數據做統計分析的性能是非常好的,完全能夠滿足我們的業務需求。現在線上有三種時間力度的統計:分鐘級別、小時級以及天級,在這三種粒度的時間范圍內的統計都能夠很好的滿足我們的業務需求。

基于這樣一個新的數據鏈路,我們在接到業務變更之后,會經過以下幾個操作步驟:首先基于明細表,創建一個新的邏輯視圖;然后在數據交換平臺上配置一個新的邏輯視圖到 RedKV 的導數鏈路,配置完之后,任務調度平臺會根據配置,定期的去實現導數。當這個數據到 RedKV 之后,業務下游的數據應用就可以直接使用。

上線效果

在做完這樣一個 POC 之后,短期內就上線了20 多個特征維度的指標,以及10多個時間粒度的指標。而且通過 StarRocks 我們統一了整個指標計算的口徑,大大提升了數據的質量。在上線了這么多指標,這么長時間內沒有出現任何的數據質量問題。

同時基于這樣一個新的鏈路,業務的發版再也不需要對 Flink 任務進行變更、停服、發版操作。整個的需求從開發、驗證、上線,大大縮小了周期,現在可以在小時級別完成這樣一個變更操作。同時,利用 StarRocks 的動態擴容能力,可以很好的去適應業務或維度的快速增長。

全面推廣:廣告數據中心

歷史架構與痛點

考慮到上一階段搜索廣告業務的上線的效果是比較理想的,所以我們在想是不是可以有更多的業務場景來嘗試 StarRocks。于是我們就想到了此前使用 ClickHouse 來構造的數據應用或平臺,但是又存在一些問題的場景,可以嘗試用 StarRocks 來改造。我們的廣告數據中心其實就是 ClickHouse 的重度使用者,并且在過去一段時間也暴露出了一些使用上或性能穩定性上的問題,所以就進一步的對現有的廣告的數據鏈路做了一個詳細的系統分析。

目前廣告數據中心主要的數據來源,分為兩大塊。一個是實時廣告的展示、點擊數據流,也就是包含了廣告數據的展點銷的信息。第二個是我們實時廣告的轉化歸因數據,比如說小紅書內的廣告轉化,筆記的互動、點贊、轉發的參與程度等等。

在過去的數據鏈路建設當中,為每一個業務需求去開發一個獨立的 Flink 任務。這些 Flink 任務產生的數據,有的是要回流到線上的 MySQL 當中,進一步提供線上服務,還有的可能就是落入 HDFS。但是最終這些數據都需要再回流到 ClickHouse 當中,為廣告主提供這些數據的報告和分析。因為業務場景多,數據交換鏈路多,所以整個的數據鏈路是非常復雜的,運維成本也非常的高,同時變更代價也會很大,周期比較長。另外有些功能比如 MySQL 線上數據實時同步到 ClickHouse 就沒辦法很好的支持。

因為以上的這些鏈路復雜的原因,所以整個系統的可用性沒辦法得到有效的保障。所以我們也希望通過架構上的優化來降低整個鏈路的復雜性,同時來提升整個鏈路的可用性。所以我們就考慮通過 StarRocks 來解耦數據 ETL 和下游數據業務加工邏輯的平臺。

當前架構

通過 StarRocks 的引入,在 Flink 側做的事情就比較簡單,主要負責這些實時和離線數據的載入,然后通過 StarRocks 來為下游的這些廣告算法策略、實時計費,還有投放端的數據報告,提供一個統一的數據加工分析平臺。改造之后的數據鏈路就如圖所示:

在這個鏈路當中,數據載入會包括兩方面:第一個是實時的數據載入,在這里面我們主要還是用 Flink SQL 來完成的。有兩方面的考慮,一是通過 StarRocks Connector 來實現 Exactly Once 語義,保證數據不丟不重。同時,跟小紅書內的數據交換平臺集成,可以很方便的去管理這些實時載入的任務。第二個是離線報表的數據載入,我們這里選擇的是 Broker Load 載入方式,因為相比于 Stream Load,開啟向量化的數據導入之后,Broker Load 的性能大概有10倍的提升。可以很好的滿足我們這種數據報告高 SLA 的要求。

在表模型選擇上,這個業務當中,90%以上的表都是聚合表。除了聚合表之外,我們還用了明細表模型。主要的使用場景就是用來展示這種 T + 1 的離線報表數據。雖然它是明細表,配合導數的后置數據質量校驗工具,可以有效的保障數據的正確性。如果涉及到大量的歷史數據的 Backfill, 也有非常好的表現。

另外就是 Unique 模型表的使用。我們在將 MySQL 維度表實時同步到 StarRocks 中時,主要采用的是這種模式。在引入 StarRocks 之前,當時我們是起了一個定時調度任務,每3分鐘去刪除 ClickHouse 里面的維度數據,然后再從 MySQL 里面全量的導入一遍。這個方式也運行了很長的一段時間沒出過問題,直到有一天業務方提了一個表變更的需求。當我們在做變更的時候,正在刪 MySQL 的維度數據,然后又觸發了 ClickHouse 的一個 bug,就是當多個 DDL 在進行操作的時候,可能會從這死鎖。所以在那個時候我們就出現了一段時間的數據的不可用,導致廣告主那邊看到的數據報告是不準確的。現在使用 StarRocks 引擎,我們通過 Flink 實時消費 MySQL 的 Binlog,然后直接插入到一個 Unique 表當中。這樣的數據鏈路一方面大大提升了數據更新的時效性,另外一方面也提升了整個架構的可靠性。

上線效果

廣告數據中心建設到現在已經上線了很長一段時間了,目前每天會有超過百萬次的查詢分析,然后在高峰的時段查詢的 QPS 達到數幾百條,當然這遠遠沒有達到 StarRocks 的性能上限。我們做過一個性能測試,單 FE 的 QPS 能達到2000,單集群的 QPS 能達到10000以上,可以有效地支撐我們未來的業務增長。并且整個查詢的延遲是非常低的,我們整體的 P99 的查詢耗時在 200毫秒以內,絕大部分時候都在100毫秒以內。

系統高可用

當然,廣告數據中心除了性能之外,整個系統的可用性也非常重要,因為是核心的系統。通過 StarRocks 簡化了數據鏈路之后,在可用性上可以操作的空間也比較大了。目前線上做了主備雙鏈路的建設,包括 Flink 任務,還有 StarRocks 集群。

這個雙鏈路有幾方面的好處:第一個是在業務做變更的時候,對下游的服務是無感知的。比如要做一個字段的變更,現在操作流程就變成了先將下游的業務系統切到備庫上,然后對主庫做變更,變更完了之后,把系統切回到主庫,再做備庫的這樣一個變更。同時借助 StarRocks 彈性擴展的能力,如果業務量或是請求量有增加,也可以動態的去擴容來滿足需求。基于這樣一個雙鏈路,還可以做一個數據的自校驗,來保證整個數據的質量。同時將兩個 StarRocks 的集群注冊到 Consul 里面,配合上數據庫團隊提供的 Myhub Client,能夠實現服務的自動發現,同時也可以在上面做一個健康檢查,當出現故障之后能夠實現秒級的自動故障切換。

另外一個就是 StarRocks 提供了一套高效的運維管理平臺,通過這套平臺一方面可以提高我們日常的運維效率,可以有效地避免一些人為操作帶來的故障或事故,同時還提供 Query Profile 的功能。如果發現有一些慢查詢,通過 Query Profile 可以有效地指導我們進行 Query 的調優,進而去保障整個系統的穩定性。

未來規劃

對于未來,首先可以持續的在公司內部進行一些業務的推廣,包括電商、社區業務的數據中心的建設等。第二個就是我們可以嘗試用 StarRocks 替代現在報表系統底層的 OLAP 引擎。另外一方面,因為 StarRocks 目前開放了源代碼,我們也希望更多的參與到整個社區的產品和生態的建設當中。從我們使用下來的角度來看,還有幾個方面可以繼續優化:第一個是在性能優化上還是要持續的投入,比如說千億這樣一個量級的數據分析的性能優化上,還需要進一步的提升。然后在 Stream Load 的數據導入上,性能還是要進一步的優化。另外一方面,因為小紅書整體的架構都是建設在公有云之上的,所以我們也希望跟社區一起去建設一套存算分離的云原生 OLAP 引擎。