數(shù)據(jù)處理效率一直是大數(shù)據(jù)時(shí)代的核心話題，它推動(dòng)著各類數(shù)據(jù)執(zhí)行引擎持續(xù)迭代產(chǎn)品。從早期的 MapReduce，到今天的 Spark，各行業(yè)正不斷演進(jìn)其離線數(shù)倉(cāng)技術(shù)架構(gòu)。

現(xiàn)有以 Spark 為核心的數(shù)倉(cāng)架構(gòu)在處理大規(guī)模數(shù)據(jù)回刷方面已取得進(jìn)展，但在資源和時(shí)間消耗上仍面臨挑戰(zhàn)。為了突破這些限制，小紅書數(shù)據(jù)倉(cāng)庫(kù)團(tuán)隊(duì)將 StarRocks 融入到離線處理流程，替換掉部分 Spark 處理的任務(wù)，并優(yōu)化較為耗時(shí)的 Cube 計(jì)算，大幅度提高了數(shù)據(jù)的執(zhí)行效率。

實(shí)踐證明，經(jīng)過改造的離線處理鏈路，可以有效降低任務(wù)資源消耗，提前數(shù)據(jù)產(chǎn)出時(shí)間。將作業(yè)執(zhí)行時(shí)間從小時(shí)級(jí)壓縮至分鐘級(jí)，計(jì)算資源使用量降低 90% 以上，日數(shù)據(jù)產(chǎn)出時(shí)間提前 1.5 小時(shí)，回刷時(shí)間減少 90%，回刷成本減少 99% 以上。

一、離線數(shù)倉(cāng)技術(shù)架構(gòu)

為了更好地管理和使用數(shù)據(jù)，離線數(shù)倉(cāng)一般會(huì)通過分層設(shè)計(jì)，確保數(shù)據(jù)高效利用。

• ODS 層（操作數(shù)據(jù)存儲(chǔ)層）：收集來自客戶端和服務(wù)端數(shù)據(jù)的原始日志。其中，服務(wù)端數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)與線上表結(jié)構(gòu)保持一致。
• DWD 層（事實(shí)明細(xì)層）：ODS 層數(shù)據(jù)在此層進(jìn)行清洗和整合，經(jīng)歷必要的數(shù)據(jù)轉(zhuǎn)換和計(jì)算，從而形成一個(gè)詳細(xì)的、一致的、歷史的和集成的數(shù)據(jù)集。
  
• DWS 層（數(shù)據(jù)聚合層）：該層匯總 DWD 層數(shù)據(jù)，分為輕度匯總和匯總。輕度匯總維度較多，便于上卷，形成匯總層。數(shù)據(jù)一般為當(dāng)天的計(jì)算或加總。
  
• DM 層（數(shù)據(jù)寬表層）：這一層有確定的核心實(shí)體或者場(chǎng)景，可能跨數(shù)據(jù)域。根據(jù)業(yè)務(wù)需求，基于某個(gè)分析主題進(jìn)行數(shù)據(jù)加工，對(duì) DWS 層數(shù)據(jù)進(jìn)一步地加工處理，形成各種豐富的數(shù)據(jù)模型。與 DWS 層的主要區(qū)別在于：度量值中是否包含“一天以外的加工數(shù)據(jù)”，如近 7 日，近 30 日，近 90 日等多日聚合指標(biāo)。
  
• APP 層（數(shù)據(jù)應(yīng)用層）：在這里，DM 層的數(shù)據(jù)結(jié)果會(huì)被轉(zhuǎn)化為直觀的報(bào)表、動(dòng)態(tài)的大屏、和便捷的數(shù)據(jù)服務(wù)，以支持決策和業(yè)務(wù)洞察。為了提升查詢效率，數(shù)倉(cāng)會(huì)預(yù)先計(jì)算 Cube（即不同維度組合下的指標(biāo)），將其存儲(chǔ)在表中。
• DIM 層（公共維度層）：這一層用于存儲(chǔ)各類實(shí)體的維度數(shù)據(jù)，為數(shù)據(jù)分析提供多角度的視野。

離線數(shù)倉(cāng)一般以 Spark 引擎作為主力，它負(fù)責(zé)數(shù)據(jù)的清洗、關(guān)聯(lián)和聚合，完成所有數(shù)據(jù)模型的建設(shè)。隨后，通過 DTS 任務(wù)將 APP 層的數(shù)據(jù)導(dǎo)入到 OLAP 集群中。小紅書主流的 OLAP 引擎包括 StarRocks 和 ClickHouse，它們憑借 OLAP 引擎的查詢能力，為數(shù)據(jù)產(chǎn)品、分析看板和業(yè)務(wù)工具提供數(shù)據(jù)查詢服務(wù)。

二、面臨的問題

雖然 Spark 引擎以其強(qiáng)大的吞吐量和穩(wěn)定性在離線數(shù)倉(cāng)中被廣泛使用，但它在數(shù)據(jù)查詢優(yōu)化方面存在局限。Spark 并不直接管理數(shù)據(jù)的分布、存儲(chǔ)格式或元信息，無法結(jié)合數(shù)據(jù)存儲(chǔ)格式和數(shù)據(jù)元信息進(jìn)行查詢優(yōu)化。此外，為了確保穩(wěn)定性，Spark 在跨節(jié)點(diǎn)數(shù)據(jù)傳輸時(shí)需要將數(shù)據(jù)寫入磁盤，這在大規(guī)模數(shù)據(jù)回刷時(shí)會(huì)導(dǎo)致資源消耗巨大和處理周期延長(zhǎng)。

從本質(zhì)上來看，Spark 僅僅是一個(gè)數(shù)據(jù)處理引擎，而不是一個(gè)理想的數(shù)據(jù)倉(cāng)庫(kù)分析引擎。在實(shí)際應(yīng)用中，這種性能瓶頸尤為明顯，開銷較大。例如，以交易運(yùn)營(yíng)行業(yè)為例，若要回刷兩年的數(shù)據(jù)，則需要占用相當(dāng)于 7 萬臺(tái)機(jī)器近 30 天的資源，成本高達(dá)上百萬元。這種定期數(shù)據(jù)回刷產(chǎn)生的巨額成本，已經(jīng)成為數(shù)據(jù)倉(cāng)庫(kù)團(tuán)隊(duì)不得不面臨的問題。

三、技術(shù)選型

與 Spark 這類數(shù)據(jù)處理引擎不同，基于 MPP 架構(gòu)的 OLAP 引擎在數(shù)據(jù)查詢方面是更具優(yōu)勢(shì)的。市面上常見的 OLAP 引擎主要有兩個(gè)：ClickHouse 和 StarRocks。

ClickHouse 是一個(gè)開源的列式數(shù)據(jù)庫(kù)管理系統(tǒng)，可用于 OLAP 分析。它采用列式存儲(chǔ)，與傳統(tǒng)的行式存儲(chǔ)相比，這種設(shè)計(jì)在處理分析型查詢時(shí)更為高效，因?yàn)樗軌蚩焖僮x取和聚合列數(shù)據(jù)，無需加載整個(gè)行。ClickHouse 的 MPP 架構(gòu)允許查詢?nèi)蝿?wù)被拆分為多個(gè)子任務(wù)，并在集群的多個(gè)節(jié)點(diǎn)上并行執(zhí)行。每個(gè)節(jié)點(diǎn)都配備獨(dú)立的的處理器和存儲(chǔ)資源，使得系統(tǒng)能夠充分利用集群的計(jì)算和存儲(chǔ)能力，大幅提升查詢速度和系統(tǒng)吞吐量。此外，ClickHouse 的 MPP 架構(gòu)還支持?jǐn)?shù)據(jù)復(fù)制和分片，提高數(shù)據(jù)的可用性和查詢性能。即使某個(gè)節(jié)點(diǎn)發(fā)生故障，其他節(jié)點(diǎn)也能迅速接管任務(wù)，確保服務(wù)的連續(xù)性。ClickHouse 是用 C++ 編寫的，它在單核性能上進(jìn)行了深度優(yōu)化。

StarRocks 也是一款高性能分析型數(shù)據(jù)倉(cāng)庫(kù)，可實(shí)現(xiàn)多維、實(shí)時(shí)、高并發(fā)的數(shù)據(jù)分析。StarRocks 采用了向量化、MPP 架構(gòu)、CBO 優(yōu)化器、智能物化視圖和列式存儲(chǔ)引擎等先進(jìn)技術(shù)，因此與同類產(chǎn)品相比，在查詢效率上具有較大優(yōu)勢(shì)。StarRocks 能夠高效地從各類實(shí)時(shí)和離線數(shù)據(jù)源導(dǎo)入數(shù)據(jù)，并直接分析數(shù)據(jù)湖中的多種格式數(shù)據(jù)。StarRocks 兼容 MySQL 協(xié)議，常用 BI 工具能輕松接入。此外，StarRocks 支持水平擴(kuò)展，確保了高可用性、可靠性和易于維護(hù)。

在小紅書內(nèi)部，StarRocks 版本以存算一體架構(gòu)為主，其中前端（FE）負(fù)責(zé)元數(shù)據(jù)管理和構(gòu)建執(zhí)行計(jì)劃，而后端（BE）則負(fù)責(zé)數(shù)據(jù)存儲(chǔ)和計(jì)算。這種架構(gòu)使得查詢能夠直接在 BE 節(jié)點(diǎn)上本地執(zhí)行，避免數(shù)據(jù)傳輸與拷貝開銷，從而實(shí)現(xiàn)極速的查詢分析性能。存算一體架構(gòu)還支持?jǐn)?shù)據(jù)的多副本存儲(chǔ)，提升了集群在高并發(fā)環(huán)境下的查詢能力和數(shù)據(jù)可靠性。

StarRocks 對(duì)算子和函數(shù)進(jìn)行了向量化加速，并通過 Pipeline 調(diào)度框架，充分利用多核計(jì)算能力，提升查詢性能。雖然 StarRocks 和 ClickHouse 在單表查詢性能上相近，但 ClickHouse 在查詢并發(fā)和不支持分布式 Join 的局限性，使其不適合作為生產(chǎn)數(shù)倉(cāng)模型的查詢加速引擎。因此，我們選擇了 StarRocks 替換原有的 Cube 計(jì)算，期望在數(shù)據(jù)處理和分析方面達(dá)到更高的性能和效率。

四、架構(gòu)改造

為了提升離線數(shù)倉(cāng)的產(chǎn)出效率，我們對(duì)架構(gòu)進(jìn)行如下優(yōu)化：

• 直接導(dǎo)入：將 DM 表、DWS 表和常變維度的 DIM 表直接導(dǎo)入 StarRocks 中，簡(jiǎn)化數(shù)據(jù)處理流程。
• Cube 表建模：在 StarRocks 中完成計(jì)算密集型的 Cube 表建模，以提高數(shù)據(jù)處理速度。

計(jì)算 UV 的一般方式是使用 count distinct ，它能夠保留原始數(shù)據(jù)的明細(xì)，有較高的靈活性。然而，由于在查詢執(zhí)行的過程中需要進(jìn)行多次 shuffle（跨節(jié)點(diǎn)通過網(wǎng)絡(luò)傳輸數(shù)據(jù)），會(huì)導(dǎo)致查詢性能隨著數(shù)據(jù)量增大而直線下降。

以下面的 SQL 為例，示例 1 ：

select
seller_level,
count(distinct if(buy_num>0, user_id,null)) buy_uv,
count(distinct if(imp_num>0, user_id,null)) imp_uv,
count(distinct if(click_num>0, user_id,null)) click_uv
from
tb
group by seller_level

其執(zhí)行過程中，首先會(huì)構(gòu)建一個(gè)中間表 tb1，并擴(kuò)展出三個(gè)虛擬維度：c1、c2 和 c3。

• c1:  if(buy_num>0, user_id,null)
• c2:  if(imp_num>0, user_id,null)
• c3:  if(click_num>0, user_id,null)

因?yàn)橛腥齻€(gè) count distinct 的維度，數(shù)據(jù)也會(huì)擴(kuò)展為三倍。隨后經(jīng)歷三輪 shuffle 才能得出結(jié)果。該過程中數(shù)據(jù)會(huì)膨脹，因此 shuffle 的數(shù)據(jù)量會(huì)比較大。

針對(duì) Cube 表中的 id 消重指標(biāo)，如用戶數(shù)、商品數(shù)等，我們采用了 BitMap 技術(shù)。BitMap 基本原理是用一個(gè) bit 位來標(biāo)記某個(gè)元素對(duì)應(yīng)的 Value，而 Key 即是該元素。與傳統(tǒng)的 count distinct 方法相比，BitMap 消重在空間和時(shí)間上都顯示出顯著優(yōu)勢(shì)：

• 空間優(yōu)勢(shì): BitMap 通過一個(gè) bit 位標(biāo)記 id 的存在，可看作是對(duì)一個(gè)集合的壓縮結(jié)構(gòu)，大幅減少了存儲(chǔ)需求。比如對(duì) int32 去重，使用普通BitMap 所需的存儲(chǔ)空間只占傳統(tǒng)去重的 1/32。StarRocks 采用的 Roaring Bitmap，能進(jìn)一步降低稀疏數(shù)據(jù)的存儲(chǔ)空間。
• 時(shí)間優(yōu)勢(shì): BitMap 去重的計(jì)算操作，分為對(duì)給定下標(biāo)的 bit 置位和統(tǒng)計(jì) bitmap 的置位個(gè)數(shù)，時(shí)間復(fù)雜度分別為O(1)和O(n)，且后者可使用 clz、ctz 等指令高效計(jì)算。此外， BitMap 去重技術(shù)在 MPP 執(zhí)行引擎中還可以并行加速處理，每個(gè)計(jì)算節(jié)點(diǎn)獨(dú)立地生成其對(duì)應(yīng)的子 BitMap，然后通過 bitor 操作高效地將這些子 bitmap 合并為一個(gè)完整的去重結(jié)果。與傳統(tǒng)的基于排序（sort）或哈希（hash）的去重方法相比，bitor 操作不僅減少了數(shù)據(jù)的無條件依賴和依賴關(guān)系，還能夠?qū)崿F(xiàn)向量化處理，從而大幅提升去重操作的效率和性能。

BitMap 大小取決于最大 id 值，直接關(guān)系到查詢的穩(wěn)定性和性能。StarRocks內(nèi)置的編碼函數(shù)能夠?qū)⒆址愋偷?id 轉(zhuǎn)換為 64 位的數(shù)字 id，但這樣的轉(zhuǎn)換可能導(dǎo)致生成的數(shù)字 id非常大，影響性能和穩(wěn)定性。為了解決這個(gè)問題，我們引入了編碼表，它的作用是將字符串 id 映射到一個(gè)更小范圍的數(shù)字 id，隨后我們把數(shù)字 id 轉(zhuǎn)化為 BitMap。

編碼表的邏輯類似于數(shù)據(jù)庫(kù)的自增邏輯，即首個(gè) id 對(duì)應(yīng)的數(shù)字是 1，后續(xù)每新增一個(gè) id，對(duì)應(yīng)的數(shù)字 id 就自增 1。從而保證每個(gè)字符串 id 都會(huì)擁有一個(gè)唯一的數(shù)字 id，也有效縮小了 BitMap 占用的存儲(chǔ)。

那么經(jīng)過 BitMap 改造的任務(wù)，示例 1 中的 SQL 執(zhí)行過程就變成了下圖的執(zhí)行過程。shuffle 數(shù)據(jù)量等于原表數(shù)據(jù)量，并且只需要一輪 shuffle。

使用過程中，Cube 計(jì)算會(huì)占用大量的 CPU 資源和內(nèi)存資源。在我們的應(yīng)用場(chǎng)景中，需要處理的 Cube 數(shù)量多達(dá)上百個(gè)，這對(duì) StarRocks 來說，經(jīng)常會(huì)導(dǎo)致內(nèi)存溢出（OOM）的情況。StarRocks 在執(zhí)行 SQL 查詢時(shí)，一般會(huì)將所有數(shù)據(jù)置于內(nèi)存中，且計(jì)算過程中的數(shù)據(jù)不會(huì) Spill 到磁盤上。為解決資源瓶頸這一問題，我們從兩個(gè)方面進(jìn)行了優(yōu)化：

• 控制 DM 表和 DWS 表的規(guī)模，這包括控制表的行數(shù)、列數(shù)、以及單字段大?。豢捎行p少數(shù)據(jù)表展用的資源。
• 優(yōu)化 SQL 寫法。Cube 計(jì)算的核心原理是將數(shù)據(jù)擴(kuò)展為 n 份（由 Cube 的數(shù)量決定），然后進(jìn)行聚合操作。為了減少在擴(kuò)展過程中產(chǎn)生的數(shù)據(jù)量，我們根據(jù)集群的規(guī)模和能力，將復(fù)雜的 SQL 查詢拆分成多個(gè)較小的批次。通過分批次提交這些查詢，巧妙地利用時(shí)間來?yè)Q取所需的計(jì)算空間，從而避免了一次性處理大量數(shù)據(jù)導(dǎo)致的資源不足問題。

為了提升查詢效率，數(shù)據(jù)倉(cāng)庫(kù)通常會(huì)在 APP 層創(chuàng)建多個(gè) Cube，從一張寬表派生出多個(gè)針對(duì)不同業(yè)務(wù)場(chǎng)景的 Cube 表。這些 Cube 表雖然優(yōu)化查詢效率，但并不承擔(dān)指標(biāo)定義的功能。在不降低查詢效率的前提下，StarRocks 提供了物化視圖簡(jiǎn)化數(shù)據(jù)模型。物化視圖本質(zhì)是預(yù)先計(jì)算并存儲(chǔ)在 StarRocks 中的數(shù)據(jù)，它對(duì)用戶透明，在查詢時(shí)自動(dòng)將請(qǐng)求重定向到已計(jì)算好的數(shù)據(jù)集，從而減少了數(shù)據(jù)處理量并加快了查詢速度。

例如，如下圖所示，未使用物化視圖的查詢（左側(cè)）需要從基礎(chǔ)底表中提取數(shù)據(jù)，而啟用物化視圖后（右側(cè)），查詢直接訪問優(yōu)化后的數(shù)據(jù)，物化視圖的數(shù)據(jù)是底表數(shù)據(jù)關(guān)聯(lián)聚合而來，可以顯著減少數(shù)據(jù)量和提升查詢速度。

對(duì)于離線數(shù)據(jù)的物化視圖，一般為定時(shí)調(diào)度，其調(diào)度類似于天級(jí)離線任務(wù)，因此其調(diào)度不會(huì)對(duì)資源造成過多占用。

在數(shù)據(jù)產(chǎn)品中，用戶的查詢往往遵循一定規(guī)則、靈活度受制于產(chǎn)品，這為物化視圖提供了優(yōu)化的機(jī)會(huì)。所有依賴同一張寬表的指標(biāo)都可以通過物化視圖得到加速，而無需在多個(gè)表中重復(fù)定義。這樣，物化視圖在后臺(tái)靜默地提高了查詢效率。

此外，StarRocks 通過 Colocation Join 功能進(jìn)一步加速表的連接操作。該功能將一組具有相同分布的表分片組織成一個(gè)集合，并確保這些 Table 的分桶副本位于同一組節(jié)點(diǎn)上。在執(zhí)行分桶列上的 Join 操作時(shí)，可以在本地節(jié)點(diǎn)上直接完成，減少數(shù)據(jù)在節(jié)點(diǎn)間的傳輸耗時(shí)。

五、應(yīng)用案例舉例

5.1 案例背景

業(yè)務(wù)運(yùn)營(yíng)團(tuán)隊(duì)的組織架構(gòu)調(diào)整導(dǎo)致行業(yè)類目不定期變更，多個(gè)數(shù)據(jù)產(chǎn)品如 OneDash（公司/業(yè)務(wù)經(jīng)營(yíng)看板）、鷹眼（電商運(yùn)營(yíng)平臺(tái)）、交易核心看板以及核心寬表都需要進(jìn)行數(shù)據(jù)回刷。傳統(tǒng)的 Spark 任務(wù)回刷成本高昂，迫切需要優(yōu)化。

5.2 鏈路改造

以交易核心看板和 OneDash 為例，原先的數(shù)據(jù)處理完全依賴于 Spark 引擎。出于性能考慮，商品行業(yè)的 Cube 表細(xì)分為兩個(gè)版本：一個(gè)包含行業(yè)新老客戶信息，另一個(gè)則不包含。然而，從業(yè)務(wù)需求出發(fā)，這兩個(gè)版本的 Cube 表實(shí)際上可以合并為一張。鑒于 Cube 表計(jì)算的執(zhí)行時(shí)間占比最大，可以將這一計(jì)算過程遷移至 StarRocks 平臺(tái)，提升效率。

如上圖所示，改造后的新鏈路經(jīng)過優(yōu)化，最終對(duì)外只開放兩個(gè) Cube 表：商品行業(yè)新老客 Cube 表、商家行業(yè) Cube 表。

• 商品行業(yè)新老客 Cube 表整合了老鏈路中的兩個(gè)獨(dú)立表——商品行業(yè)新老客 Cube 和商品行業(yè) Cube。新表直接依賴于一張綜合的商品行業(yè)用戶渠道寬表，該寬表包含了商品行業(yè)和新老客戶維度的關(guān)鍵信息以及多種指標(biāo)。這一合并減少了維護(hù)的復(fù)雜性。
• 商家行業(yè) Cube 表的鏈路也類似，它依賴于商家行業(yè)用戶渠道寬表，而這個(gè)寬表本身依賴于商品行業(yè)用戶渠道寬表產(chǎn)出。

這樣設(shè)計(jì)的原因：1）保證商品行業(yè) Cube 指標(biāo)和商家行業(yè) Cube 指標(biāo)的一致性；2）StarRocks 中的關(guān)聯(lián)操作可以使用 Colocate Join，效率比 Spark 要高。

分不同維度計(jì)算用戶數(shù)、商品數(shù)和商家數(shù)時(shí)，我們會(huì)先對(duì) user_id、spu_id 和 seller_id 進(jìn)行編碼，然后在中間表中構(gòu)建對(duì)應(yīng)的 BitMap。

5.3 回刷鏈路

面對(duì)行業(yè)變更，我們采取主備鏈路的策略來應(yīng)對(duì)涉及多個(gè)數(shù)據(jù)產(chǎn)品的復(fù)雜回刷任務(wù)。主鏈路負(fù)責(zé)持續(xù)為線上產(chǎn)品提供實(shí)時(shí)服務(wù)，而備鏈路則專門用于執(zhí)行數(shù)據(jù)的回刷操作。

• 在行業(yè)發(fā)生變更時(shí)，業(yè)務(wù)數(shù)據(jù)倉(cāng)庫(kù)會(huì)根據(jù)最新的行業(yè)映射信息，重新構(gòu)建備鏈路上的商品行業(yè)和商家行業(yè)維表。與此同時(shí)，主鏈路上的維表保持原行業(yè)映射不變，確保業(yè)務(wù)連續(xù)性。回刷過去兩年的數(shù)據(jù)，包括商家行業(yè)維表、行業(yè)新老客維表，以及最新一天的商品行業(yè)維表。
• 歷史數(shù)據(jù)的回刷通過將商家行業(yè)和行業(yè)新老客維表的數(shù)據(jù)導(dǎo)入到 StarRocks 中來完成，而對(duì)于商品行業(yè)維表，只需回刷最新一天的數(shù)據(jù)。
• 接著我們更新商品行業(yè)維表下游的維表依賴關(guān)系，使其指向最新日期的數(shù)據(jù)，并調(diào)度起各業(yè)務(wù)的 Cube 回刷鏈路，對(duì)近 2 年的數(shù)據(jù)進(jìn)行全面更新。這一整個(gè)過程都是通過 StarRocks SQL 任務(wù)來實(shí)現(xiàn)的。數(shù)據(jù)調(diào)度平臺(tái)則負(fù)責(zé)執(zhí)行回刷計(jì)劃，關(guān)鍵表會(huì)部署數(shù)據(jù)質(zhì)量檢測(cè)任務(wù)（DQC），保證回刷過程中的數(shù)據(jù)符合預(yù)期。
• 一旦所有的 Cube 回刷任務(wù)完成，我們便可以調(diào)度同步任務(wù)，利用 StarRocks 的外表導(dǎo)入功能，將備集群的更新結(jié)果同步到主集群中。這樣的同步操作確保了主鏈路數(shù)據(jù)的及時(shí)更新，同時(shí)也保障了數(shù)據(jù)的完整性和業(yè)務(wù)的連續(xù)運(yùn)行。

5.4 收益

通過將回刷鏈路部署到 StarRocks 集群中，我們實(shí)現(xiàn)了資源的高效利用，無需申請(qǐng)其他額外資源。同時(shí)，主鏈路的運(yùn)行依托于現(xiàn)有的線上集群，沒有額外消耗。這次鏈路改造帶來的主要收益可以分為兩大類：

• 回刷收益：以最近一輪的回刷為例，回刷 2022 年和 2023 年共計(jì)兩年的數(shù)據(jù)。我們對(duì)比了基于 Spark 和基于 StarRocks 的鏈路性能。結(jié)果顯示，StarRocks 鏈路在資源消耗和成本上都有顯著的減少，回刷時(shí)間節(jié)省 90%，回刷成本降低 99%。具體來說，資源消耗從上千萬 GBHour 降低到 幾十萬 GBHour，成本從上百萬元大幅下降到幾千元，回刷時(shí)間從一個(gè)月縮短到幾天。
• 日常收益：在日常數(shù)據(jù)處理方面，StarRocks 鏈路同樣展現(xiàn)出色。與 Spark 鏈路相比，StarRocks 沒有額外資源消耗，每天的數(shù)據(jù)產(chǎn)出時(shí)間提前了 1.5 小時(shí)以上，數(shù)據(jù)處理時(shí)間縮短至幾分鐘，這樣的改進(jìn)不僅加快數(shù)據(jù)處理速度，還提高整體的工作效率。

六、總結(jié)與展望

OLAP 引擎在實(shí)時(shí)數(shù)倉(cāng)建設(shè)方面已經(jīng)得到了廣泛的應(yīng)用。我們的實(shí)踐證明，結(jié)合業(yè)務(wù)特點(diǎn)，在處理中小規(guī)模數(shù)據(jù)量時(shí)，使用 StarRocks 等分布式 OLAP 引擎替換 Spark ，承擔(dān)更多的離線處理任務(wù)，可以顯著提高數(shù)據(jù)倉(cāng)庫(kù)產(chǎn)出的速度和效率，達(dá)到降本增效的目的。

展望未來，我們計(jì)劃進(jìn)一步探索 StarRocks 在湖倉(cāng)一體和存算分離的應(yīng)用場(chǎng)景，以構(gòu)建更加高效、靈活的數(shù)據(jù)生產(chǎn)鏈路和自助分析產(chǎn)品。我們期待通過這些創(chuàng)新實(shí)踐，能夠?yàn)楣編砀鼜?qiáng)大的數(shù)據(jù)處理能力，支持業(yè)務(wù)的持續(xù)增長(zhǎng)和決策的精準(zhǔn)性。

七、作者簡(jiǎn)介

• 黃猿(吳筱琦)

小紅書數(shù)據(jù)倉(cāng)庫(kù)工程師，現(xiàn)負(fù)責(zé)渠道歸因和數(shù)據(jù)任務(wù)性能優(yōu)化。

• 馬爾科(吳浩亮)

小紅書數(shù)據(jù)解決方案專家，現(xiàn)負(fù)責(zé)小紅書用戶增長(zhǎng)、搜推、基礎(chǔ)流量、電商、直播等多個(gè)業(yè)務(wù)領(lǐng)域數(shù)倉(cāng)建設(shè)。

• 凌波(李娟)

小紅書交易數(shù)據(jù)倉(cāng)庫(kù)開發(fā)，現(xiàn)負(fù)責(zé)小紅書交易 C 端的數(shù)據(jù)建設(shè)