小紅書基於StarRocks實現數據服務平臺統一化

2025-05-03 21:31:25

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

一、OLAP引擎在小紅書的演進史

第一階段，在2017年之前，數據總量還不是特別大，這個階段使用AWS的Redshift，此時數倉體系還沒有完全建立，很多數據需求的實現都是用短平快、煙囪式開發的方式來滿足。數據ETL、數倉模型到最後報表端展現，在Redshift中一站式完成。

但隨著業務複雜度不斷提升，以及數據量的快速增長，這種模式很快遇到了瓶頸。主要有以下問題：

·Redshift無法在不影響線上查詢性能的前提下彈性擴展，一旦涉及到擴容，就會涉及到數據重分布，從而影響集群的性能以及可用性。

·ETL任務嚴重影響集群可用性。在Redshift中同時進行ETL任務的時候，會大量搶佔資源，從而影響數據分析的效率，導致查詢超時甚至因為集群負載過大後整個集群崩潰不可用。

·沒有良好的存算分離，數據存儲容量存在瓶頸，無法滿足隨業務而快速增長的數據量存儲需求。

第二階段，隨著數據倉庫在Hadoop/Hive體系上搭建和完善，ETL任務全部轉移至Hadoop集群，這個階段使用Presto完成OLAP分析。Presto天然和Hive共享元數據信息，且共同使用物理數據存儲，即插即用。大量的對數倉表的靈活查詢使用Presto完成。

第三階段，業務實時性增強，對查詢性能的要求不斷升高，同時許多數據應用產生。這個階段引入了ClickHouse，用來建設性能更強悍，響應時間更短的數據分析平臺以滿足實時性要求。

第四階段，小紅書大數據團隊進行了實時數倉的整體設計和搭建，同時為統一對各業務團隊提供數據接口而構建了數據服務平臺，外接了多個內部或者To B服務的應用系統。既需要做低延時的複雜查詢，同時對並發量也有很高的要求。這個階段我們又根據場景引入了StarRocks，以滿足以上各類需求。

二、小紅書數據分析體系架構

1、小紅書OLAP體系現狀

小紅書的整個數據分析體系，由數據採集、數據存儲加工/數據共享和應用層組成。

1）數據採集

伺服器日誌或者App日誌通過Flume收集埋點日誌，數據同時分發到離線存儲S3和實時存儲kafka；線上業務資料庫通過Canal實時採集MySQL binlog等信息。

2）數據存儲加工

離線數據處理：利用Hive/Spark高可擴展的批處理能力承擔所有的離線數倉的ETL和數據模型加工的工作。

實時數據處理：Flink完成實時側數據的ETL（包括維度豐富，雙流Join，實時匯總）；離線表通過調度平臺同步到ClickHouse/StarRocks，Flink實現了ClickHouse和StarRocks的sink connector，落地到StarRocks或ClickHouse。

3）數據共享

數據共享層的主要提供對外服務的底層數據存儲,離線或者實時的數據寫入相關的資料庫組件中，面向多種服務，不同場景提供查詢能力。

數據共享層主要有TiDB/Hbase/ClickHouse/StarRocks。通過StarRocks和ClickHouse提供的高速OLAP查詢能力，在應用側承接了報表平臺，提供即席分析的平臺，對開發側提供數據接口，以及實現多個數據產品（比如流量分析平臺，用戶標籤平臺）。

4）應用層

應用層主要為面向管理和運營人員的報表，具有並發、延遲、需求更新頻繁等要求，面向數據分析師的即席查詢，要求支持複雜sql處理、海量數據查詢等能力。

2、各OLAP分析工具選型比較

1）Clickhouse：

優點：

很強的單表查詢性能，適合基於大寬表的靈活即席查詢。

包含豐富的MergeTree Family，支持預聚合。

非常適合大規模日誌明細數據寫入分析。

缺點：

不支持真正的刪除與更新。

Join方式不是很友好。

並發能力比較低。

MergeTree合併不完全。

2）StarRocks：

優點：

單表查詢和多表查詢性能都很強，可以同時較好支持寬表查詢場景和複雜多表查詢。

支持高並發查詢。

支持實時數據微批ETL處理。

流式和批量數據寫入都能都比較強。

兼容MySQL協議和標準SQL。

缺點：

周邊生態比較不完善。

部分SQL語法不支持。

3）TiDB/TiFlash：

優點：

支持更新/刪除。

兼顧了OLTP的需求。

支持Flink ExactlyOnce語意，支持冪等。

缺點：

查詢性能弱，無法較好支持OLAP查詢場景。

不支持實時預聚合。

TiFlash暫時不支持所有的SQL寫法以及函數。

三、StarRocks在廣告數據中心的應用實踐

1、業務場景概述

廣告業務的核心數據有兩大塊：一個是廣告的曝光點擊流，即所有廣告單元的展點銷信息；第二個是廣告效果歸因數據，比如說在小紅書站內的訂單轉化，相關表單提交，筆記的點讚、收藏、加關注等參與程度。

基於這些數據，根據不同的業務場景需求，實時匯總出相關業務統計指標，對外提供查詢分析服務。

2、原有解決方案

1）技術架構

在引入StarRocks之前，是用大量Flink任務進行寫入MySQL/Redis/HDFS/ClickHouse，以達到數據的落地。

Flink中核心處理邏輯有幾類：

·前端用戶廣告展示信息事件流和後端算法推薦流雙流關聯並去重，完善廣告信息。

·接入反作弊，清除作弊事件。

·按不同業務場景需求匯總結果寫入不同的資料庫組件中。

2）技術痛點

原有架構主要有以下問題：

·數據邏輯沒有很好做歸攏合併，維護工作量大，新需求無法快速響應。

·Clickhouse的並發能力不足以及擴容複雜度在可見未來會成為整體廣告系統瓶頸。

·因為Flink層邏輯散落，由大量小的Flink任務構成，因此導致整個架構無法滿足高可用要求，只要任何一個任務出現問題，都會影響線上業務。

3、基於StarRocks的解決方案

因此我們希望對原有體系進行優化，核心思路是利用一個OLAP引擎進行這一層的統一，對OLAP引擎的要求是比較高的：

·能支撐大吞吐量的數據寫入要求。

·可以支持多維度組合的靈活查詢，TP99在100ms以下。

·有實時匯總上卷的能力，提高查詢性能，支持qps達到上萬的要求。

·通過Binlog實時同步MySQL的數據，並及時對數據進行封裝。

·比較好的支持多表關聯。

經過大量調研，StarRocks比較契合廣告數據中心的整體要求。基於StarRocks本身高效的查詢能力，支持高QPS的特性，可以為廣告的算法策略、廣告實時計費、廣告平臺實時的數據報告提供一體化服務。

新架構具備以下優點：

·結構清晰，Flink專注於數據的清洗，業務邏輯計算從Flink遷到StarRocks內實現，·StarRocks就是數據業務邏輯的終點。

·可以維護統一的數據口徑，一份數據輸入，一套廣告統計口徑輸出。

·在底層實現StarRocks主備雙活，更好的支持高QPS場景。

1）數據表設計

數據模型設計

StarRocks本身提供三種數據模型：明細模型/聚合模型/更新模型。對小紅書廣告業務來說，三種數據模型各盡其用：

·廣告曝光點擊流寫入聚合模型，按照業務所需要的維度，如廣告主、廣告類型、創意，廣告單元，搜索詞，地域，用戶屬性等設計聚合的所有維度，根據所需要的指標進行聚合。

·廣告側後端有很多的線上MySQL，通過StarRocks更新模型接入MySQL進行實時的表更新。

·在Hadoop離線數倉中還定期統計了一些數據報告同步到StarRocks中，這些數據使用了StarRocks的明細模型。

數據分區/分桶

StarRocks提供的數據分區功能，可以很好的提升廣告場景下查詢的性能。例如，廣告側查詢常見的一種查詢場景，是查詢過去某一段時間內的數據，我們可以在StarRocks中根據時間進行分區，過濾掉不必要的分區數據。另外，廣告查詢會根據廣告主進行篩選，我們將廣告主ID作為排序鍵的最前列，就可以快速定位到廣告主的數據，StarRocks還支持按照廣告主ID進行Hash分桶，減少整個查詢的數據量進行快速定位，這對高並發場景也具有非常大的意義，儘量減少了查詢語句所覆蓋的數據範圍，提高了並發能力。

物化視圖

我們利用StarRocks物化視圖能夠實時、批量構建，靈活增加刪除以及透明化使用的特性，建立了基於廣告主粒度、基於用戶特徵粒度、基於廣告單元粒度、基於具體創意粒度的物化視圖。基於這些物化視圖，可以極大加速查詢。

2）數據導入

實時的數據導入分為兩種：

·有ETL處理需求的，會利用Flink進行ETL邏輯轉化，使用Flink StarRocksConnector寫入StarRocks。

·在實時數倉公共層的，配置Routine Load任務，將數據10s一個batch寫入StarRocks表中。離線數據報告導入StarRocks：

·在StarRocks提供的原生的Broker Load基礎上在小紅書數倉的調度平臺上封裝了導數模版，通過界面化配置的方式，將離線數倉的表導入到StarRocks中。

3）數據查詢

在我們的查詢場景中，廣告主業務查詢服務對查詢並發度要求很高。StarRocks採用的是MPP查詢架構，底層數據按照Range和Hash兩級分片，非常適合廣告主業務的查詢場景。

內部做的線上查詢壓測結果，每個FE能到2000左右的QPS，整個集群能提供上萬的QPS，TP99的查詢在100毫秒以下。

4）系統運維

廣告數據中心是非常核心的一個線上服務，因此對高可用及靈活擴容能力有非常高的要求。StarRocks支持fe/be多副本，沒有單節點問題，當有節點故障的時候也可以保證整個集群的高可用。另外，StarRocks在大數據規模下可以進行在線彈性擴展，在擴容時無需下線，不會影響到在線業務，這個能力也是我們非常需要的。

總結

小紅書從今年年初開始調研引入StarRocks，當前已經有五個StarRocks集群在穩定運行中，其中有兩個開始穩定提供線上服務，三個還在試運行。引入StarRocks後，實現了數據服務統一化，大大簡化了實時數據處理鏈路，同時也能保障較高的查詢並發和較低的響應延遲要求，之後將用來提升更多業務場景的數據服務和查詢能力。最後，感謝鼎石科技的大力支持，也期望StarRocks作為性能強悍的新一代MPP資料庫引領者越來越好！（「作者：吳浩亮 小紅書大數據團隊，數據倉庫架構師」）