小紅書在大數據處理領域引入了邏輯數據集和物化視圖技術，解決了傳統架構中 APP 表復用度低、單表BI數據集可擴展性不足、寬表數據集看板查詢性能差等問題。這些技術通過優化數據處理流程，平衡了數據通用性和查詢性能，有效提升了數據處理效率和查詢響應速度。文章詳細介紹了邏輯數據集和物化視圖的配置、運維、查詢改寫以及ETL任務生成與調度等關鍵技術手段。

通過這些創新實踐，小紅書在數據集收斂程度、看板查詢性能方面取得了顯著提升，為未來數倉智能化建設奠定了堅實基礎。

01背景

2004年谷歌發表了一篇《Mapreduce》的文章，從此開啟了大數據處理的時代。隨后的二十年，中國移動互聯網逐步發展壯大，數據的分析和處理在互聯網公司中的地位越來越重要。移動互聯網產生了海量的埋點日志，大數據技術在這樣的數據體量下得到了快速的迭代與發展。在這個過程中，各大公司逐步形成了一套標準的數據處理架構。從邏輯層面，數據處理流程可以分為數據收集、數據處理和數據展示3個過程。數據處理流程分為5層ODS、DWD、DWS、DM、APP。從引擎角度，數據處理基本都是在spark 批處理中完成，而對外的數據應用基本依賴的是 OLAP 引擎。產品層面，數據處理一般由離線調度平臺來負責，數據應用會包含公司內部的數據產品和BI分析工具。

小紅書數倉在此基礎上，向產品運營分析師推廣了自助數據集的使用。核心目的就是收攏數據的出口方式，規范化指標定義，提升數倉數據集的權威性和覆蓋度。這個過程中我們遇到兩個問題：

1. 單表BI數據集可擴展性不足。比如相同業務下不同方向的分析師、產品和運營往往需要從不同的角度做數據分析。不同的角度也就對應了不同的實體維度，如果將所有維表字段都放到寬表當中，會造成寬表字段信息過分冗余，難以維護和檢索，此外每次新增分析場景或者修改維度定義，也勢必需要數倉工程師對表進行修改。隨著一個數據集的使用場景越來越多，數倉工程師的壓力也會增大。
2. 基于寬表數據集的看板查詢性能較差。大量查詢遷移到核心數據集之后，越來越多的業務會基于核心數據集直接搭建看板，由于核心數據集本身的數據量較大，并且看板指標通常會查詢較長周期的數據，因此相比于APP表，直接通過寬表數據集搭建看板的這種方式查詢性能更差。

1.1 問題分析

受限于當前的標準處理模型，數倉很難保證同時滿足數據通用性和查詢性能的要求。隨著小紅書業務的快速發展，數倉對外出口的數據集越來越多，為了收斂指標定義、降低數倉的運維成本。我們開始考慮如何在不降低查詢性能的前提下，提高數據集的通用性。

當前的 RedBI 平臺，兩種主要的數據集，一種是單表數據集，另一種是 SQL 數據集。SQL數據集類似于一種邏輯視圖，用戶在 RedBI 查詢 SQL 數據集的時候會將這段 SQL 當作一張表進行查詢，因此 SQL 數據集的查詢比較復雜，查詢性能相對于單表會差一些。

SQL 數據集一般是一個主表關聯多張維表，其性能下降多數是來自于關聯操作。雖然 StarRocks 相對于 Clickhouse 來說Join性能會好很多，但是隨著 Join 的維表的數量增加，其性能依然會下降很明顯。尤其是當用戶的查詢如果只涉及到主表字段的時候，SQL 數據集沒辦法做到查詢裁切，會比單表查詢更慢。

如上圖所示，SQL1 里只包含Table1 的字段，那么就只應該查詢 Table1。SQL2 只包含 Table1 和 Table2 的字段，就應該查詢 Table1 和 Table2 的關聯結果。對于 SQL3，因為涉及到 Table2 和 Table3 的維度字段，所以應該查詢 Table1，Table2 和 Table3 的關聯結果。因此如果我們可以對查詢做到裁切，就可以有效減少無意義的計算，提高查詢效率。

SQL 數據集的性能差的另一個原因是數據集太大。如果要保證達到和 APP 層表一樣的性能，那么就需要生成類似實體表的加速數據--物化視圖。雖然物化視圖和App表都是為了查詢性能創建的數據集，但是物化視圖和 APP 表相比，其優勢主要體現在，物化視圖不會增加模型的數量，只是查詢到原始數據集的查詢會路由到物化視圖，而App表會增加模型，用戶在查詢的時候必須得指定 APP 表。所以物化視圖可以在保證模型通用性的前提下提高數據集的查詢性能。

由于業務的查詢大部分遵循某種規律，搭建必要的緩存，也可以大幅度降低查詢的時間。

02 數倉開發新范式

2.1 總體方案

經過上述的分析，數據集變為寬表+維表的模式。寬表定義了一個數據集可以查詢的粒度和指標，維表定義了可以拆解的維度。這樣一來，每一個業務都會只會產出有限的數據集，數據集個數得到極大收攏，指標的定義也會更加清晰。

這種寬表+維表的數據集，我們稱之為邏輯數據集。邏輯數據集相對于 SQL 數據集來說加入了查詢裁切的功能，一般情況下不同目的的查詢都只會使用到寬表+部分維表，一個數據集適用的分析場景由維表數量決定，但是查詢性能只和當前的分析需要有關。在保證使用范圍的情況下，保證了最小的查詢范圍，無額外性能損耗。

但是隨著數據集的通用性提升，越來越多的數據集開始應用于看板制作，相對于自助查詢，看板查詢的性能要求會更高，并且并發也會更大。自助查詢用戶會的查詢比較靈活，所以對查詢的耗時容忍度也更高，一般可以接受20s以內的查詢性能。但是對于看板來說，一個看板中可能涉及到幾十個圖表，每個圖表又會涉及到多個查詢，相當于同時有上百個查詢打到 OLAP 引擎，如果一個查詢的耗時還是20s，那整個看板展現出來的時間必然很漫長。此外很多看板查詢的顯示周期很久，可能達到1年以上，直接查詢底表大概率會導致查詢失敗。

因此，我們需要針對數據集建立對應的物化視圖，物化視圖基本可以覆蓋看板中的絕大多數查詢，由于物化視圖的數據量較少，所以可以將單個查詢的執行時間壓縮到4s以內，并且可以將之前查詢失敗的報表查詢出來。

下圖是我們的實際技術架構。

DWS 層的數據是進入BI工具的最后一層，這一層我們使用Iceberg存儲。Iceberg 作為一種數據湖存儲格式，可以使用Spark進行讀寫，并且也可以使用StarRocks讀。實驗已經證明，相同資源情況下，StarRocks on Iceberg 的查詢性能在絕大場景下和 Clickhouse 相當甚至更優，并且Iceberg 不和 OLAP 引擎深度耦合，其擴展性能也更好，完全可以做到存算分離，解決存儲焦慮。

在這層之上就是 RedBI（小紅書內部的BI平臺）中的邏輯數據集，邏輯數據集是數倉對外的“產品”。

在邏輯數據集之上就是查詢加速層，查詢加速層中的第一層是物化視圖，一個邏輯數據集可以建立多個物化視圖，需要保證覆蓋大多數的看板查詢。相對于傳統CUBE類型的APP表，物化視圖的優勢主要體現在兩個方面：

1. 計算復雜度低。CUBE計算本質上需要將數據復制n份（依據CUBE個數），然后進行聚合操作，如果CUBE眾多，那么中間的數據膨脹會相當嚴重，甚至會引發執行超時和報錯。而物化視圖本質上是對寬表的聚合，所以不存在中間數據膨脹，執行性能會更好。
2. 通用性高。CUBE表一般屬于APP表，和BI寬表數據集本身沒有綁定關系，那么這個CUBE表很可能只能服務于特定的看板，當有另外的看板在用到類似的維度分析時，如果沒有數倉工程師憑借豐富經驗做推薦，大概率不會復用該APP表。而物化視圖本身是綁定到數據集的，所以只要可以命中物化視圖的查詢格式，那么不論查詢來自哪里，都可以進行復用。

查詢加速層的第二層是緩存，尤其是在固定查詢的場景下，緩存可以極大緩解對集群的查詢壓力。

下面著重介紹邏輯數據集和物化視圖兩大內容。

2.2 邏輯數據集

2.2.1 執行流程

邏輯數據集核心包含兩部分：數據集配置和查詢裁切。

我們使用圖形化界面對數據集進行配置，界面中的節點是一個數據集或者是一個 SQL，節點與節點中間按照關聯鍵進行連接。配置可以告訴系統只能沿著關聯鍵進行裁切，而不可以對節點內部進行裁切。

開啟查詢裁剪需要同時滿足以下兩個條件：

1. 節點與節點之間是 LEFT-JOIN 連接
2. 右表關聯鍵不存在重復值

其中，右表連接鍵唯一性的判斷，會在數據預覽步驟中進行，和預覽結果一起返回。調用數據預覽接口時處理如下：

2.2.2 查詢裁切步驟

1. 從數據集元信息中，獲取可以進行裁剪的節點列表。

2. 根據 DSL 中的維度、指標、篩選等字段，把本次查詢用到的所有字段展平，把字段對應的節點 id 排除，從而得到本次查詢可裁剪的節點列表。

3. 所有的節點列表去掉可裁剪的節點，得到優化后的節點列表。

4. 然后根據連接條件把相關的表 Join 起來，作為一個整體數據集執行BI查詢。

2.3 物化視圖的技術手段

2.3.1 工具選擇

StarRocks 和其他 OLAP 引擎一樣，也具備物化視圖的功能。StarRocks 的物化視圖分為同步物化視圖和異步物化視圖。同步物化視圖可以保證數據集的一致性，異步物化視圖需要設置刷新周期。但是在應用到生產環境的時候，就會發現物化視圖的調度對集群會造成很大的壓力，并且也無法滿足很多業務訴求。

1. 同步物化視圖的開銷較大，數據只要發生變化就會進行刷新，這樣在數據集每條導入的過程中就會涉及大量的新增操作，導致大量物化更新，進一步會對集群造成巨大的壓力，甚至導致集群崩潰。
2. 而異步物化視圖必須設置刷新周期，對于BI數據集來說，數據基本是天級就緒，而且每天數據的就緒時間并不固定，異步物化視圖要么需要設置較短的刷新周期，要么天級刷新，但是刷新時間較晚，這樣無法滿足業務查詢性能的訴求。
3. 此外 StarRocks 是一個 OLAP 引擎，和 Spark 不一樣的是，不存在類似于 Yarn 的作業調度管理。那么當大量的物化視圖開始調度的時候，很難去合理安排物化視圖的調度順序，也無法根據當前的資源情況給不同的物化作業分配不同的資源，因此在先前的 StarRocks ETL 處理中，我們會遇到因為資源搶占導致的作業失敗現象。隨著物化視圖越來越多，物化視圖的調度成功率必然也會劣化。
4. 對于 UV 類的計算來說，需要物化成 BITMAP 類型，這就需要對消重字段進行編碼，StarRocks 中沒有很緊湊的編碼方式，官方也建議用戶自己映射編碼，一方面 StarRocks 中的物化視圖無法對 UV 進行物化，另一方面無法得知用戶的編碼表。

因此我們在 RedBI 中完成了物化視圖的功能，相比于原生的物化視圖：

1. RedBI 的物化視圖可以充分利用數據平臺已有的作業調度能力。
2. 此外，看板也是在RedBI上搭建的，RedBI 本身可以獲取到查詢的所有信息。
3. RedBI 可以使用數倉的編碼表生成對應的 BITMAP，進而完成對uv類指標的物化。

2.3.2 實現方案

當前業界在設計物化視圖功能的時候，都聚焦在了查詢的改寫能力方面，盡可能保證物化視圖可以適應越來越多的查詢場景。但是實際在生產環境中我們發現物化視圖的配置和運維流程會更加重要。和物化視圖相關的整套產品功能包括以下幾類：物化視圖配置、物化 ETL 任務生成與調度、物化查詢改寫、物化治理。

• 視圖配置：通過RedBI中的物化配置 UI 界面完成視圖配置。
• 物化運維： 監控物化視圖當前的新鮮度，保證物化視圖的定義依然可以被大部分查詢命中。
• 查詢改寫： 對查詢參數進行校驗，將符合物化規則的查詢請求路由到合適的物化視圖表并完成查詢改寫。
• ETL 任務生成與調度：生成物加速 ETL 任務，實現數據預計算并存儲，將數據固化為更小的物化視圖表。

視圖配置

大多數的 OLAP 引擎的物化視圖功能都假設用戶已經對物化視圖的結構有了清晰的設想。那這樣的物化視圖從根本上來說依然是數倉在建設APP表的思路，即先有模型設計，然后才會產生物理模型。但是這樣的物化視圖本質上并沒有減輕數倉的工作量，也沒有改變數倉的工作方式。如果要最大可能消滅APP層，物化視圖的模型設計就不能強依賴數倉的模型設計能力。因此我們的物化視圖主要是通過數據集的看板和自助分析模版來生成。

理想的狀態下，物化視圖可以按照數據集的看板和模版自動生成。但是完成自動化生產物化視圖的過程中，我們首先要解決用戶手動創建的難點。用戶手動創建物化視圖依賴的核心功能包括

1. 需要物化的內容。在我們的場景下，就是看板和自主分析模版。看板和自主分析模版的查詢熱度作為輔助指標可以使用戶知曉哪些看板的物化更有價值。

2. 調試過程。用戶不大可能一次性就可以創建出沒有任何問題的物化視圖，物化視圖要想發揮價值，必然需要保證性能和命中率兩個方面。

• 物化視圖的命中率是我們依賴歷史查詢進行的分析生成的。如果物化視圖的命中率太低，那么對于查詢性能的改變就微乎其微。此外，通過看板和自主分析模版生產的物化視圖結構可能因為功能不支持或者物化周期的原因命中率低，需要用戶進行手動調整。
• 物化視圖的數據量要有限制。如果用戶將所有看板和自主分析模版都加入物化，必然可以保證很高的命中率，但是這樣的物化視圖也接近于明細了，那物化視圖的查詢就會變慢，物化視圖查詢加速的能力也就喪失了。因此調試過程中需要顯示物化視圖的數據量，以保證物化視圖的性能。

提需過程

我們需要在什么時候決定要對什么內容創建物化視圖進行加速呢？僅僅依賴數倉的經驗肯定是不靠譜的，因為數據集的使用方可能是分析師、產品和運營。這些使用方往往會根據自己的需求去搭建看板，數倉是完全不清楚業務具體是怎么使用的。

數倉建設APP表的流程如下圖所示。業務方（一般是分析師或產品）首先提出數據需求，然后需要和數倉進行需求對齊，使數倉可以理解業務的訴求，數倉確認需求之后就會涉及對應的 APP 模型。建設好 APP 表之后還需要和業務方進行調試，保證指標符合預期，這個過程如果不符合預期，得多次和業務方進行溝通對齊。

如果物化視圖依然沿用這一思路，對于數倉和業務方來說，物化視圖和 APP 表就沒有任何差別，因為根本上沒有降低其中的溝通成本。

業務方對于看板的樣式以及指標是最清楚的，一旦涉及到溝通，必然存在信息損耗。因此我們將提需流程改為了如下方式。可以看出新的提需流程是先由業務創建出看板，然后將需要物化的內容提需給數倉，數倉完成對應的物化需求。這個過程中，需求文檔不再是一個充滿文字和表格的文檔，也不需要人工講解，而是一個真實的看板圖表。配合物化視圖的配置功能，可以輕松完成物化視圖的搭建。

物化運維

物化視圖并不是一成不變的，物化視圖的變動一般來自于三個方面：

1. 數據集中的表發生了變更，進行了數據回刷。這種情況下，物化視圖本身不需要進行更改，只需要回刷即可。當上游數據集完成回刷的時候，我們會自動調度起下游的物化視圖任務，回刷對應日期的實例。
2. 看板和模版發生修改，可能會導創建的物化視圖失效。這種情況下平臺一方面會提醒修改人圖表是否無法命中物化，另一方面會通知到數倉發生變更的看板和模版，數倉需要重新測試物化視圖對這些看板模版的命中率，并且更新物化視圖結構，以保證物化視圖命中率。
3. 數據集字段定義發生變更。RedBI 數據集中除了表的原始字段外，還有很多依賴原始字段生成的計算字段，這些計算字段如果發生變更，那么按照之前字段定義創建的物化視圖也可能失效。因此當數據集的字段定義發生變更的時候，平臺會提示數據負責人失效的物化視圖和影響的看板圖表，另一方面也會通知數倉更新物化視圖。

查詢改寫

改寫流程：

改寫采用了基于 SPJG（SELECT-PROJECT-JOIN-GROUP-BY）模式的結構信息來進行透明改寫的算法，即將原表的sql查詢替換成物化視圖的查詢。物化視圖的改寫基于 LodQuery，改寫時基于物化配置中存儲的字段表達式列表進行匹配和替換。下面是改寫步驟：

• 用戶發起查詢時，BI 界面的查詢配置會轉化為 QueryDSL，QueryDSL 經過解析 Lod 表達式、字段拆解等，然后轉化為 LodQuery 對象。

LodQuery抽象

RedBI抽象的 LodQuery 大致包括以下部分：

? dimensions：查詢維度，指定了需要查詢的聚合粒度

? measures：查詢度量，指定了在聚合粒度為 dimensions 時需要查詢的度量字段

? from：查詢表信息，指定了多張原始表、自定義SQL表、邏輯數據集對應的主表和多張維表的定義及關聯方式，存在嵌套結構。

?dimensionFilters：維度篩選，指定了對明細數據的篩選方式，需要指定Pill和FilterPredicate

? measureFilters：度量篩選，指定了對聚合后數據的篩選方式，需要指定Pill和FilterPredicate

? orderBy：排序，指定了查詢需要按哪些字段進行排序

? offset：查詢偏移量，指定了結果需要偏移多少行數據

?limit：查詢數據量，指定了結果集的數據量上限

• 基于數據集物化配置獲取對應物化視圖列表，并根據優先級排序進行物化命中的校驗。
• 命中物化則將 LodQuery 改寫為物化查詢的 MaterializedQuery。
• 對 MaterializedQuery 進一步優化，包括謂詞下推、開窗函數處理，引擎特定函數處理等，轉換為為 TableQuery(抽象語法樹)。

選擇基于 LodQuery 而非 TableQuery 進行物化改寫的原因在于雖然 TableQuery 和 LodQuery 結構大體一致，但 LodQuery 作為 RedBI 的抽象,具有更豐富的元信息。例如LodQuery 將維度(dimensions)和度量(measures)明確分離,而TableQuery則不區分 dimensions 和 measures。此外,在 LodQuery 轉換為 TableQuery 之前,尚未進行各項查詢優化，例如謂詞下推、窗口函數處理、引擎特定函數處理等，數據結構更加精簡，這為物化改寫提供了更大的靈活性和可操作空間。

• 基于 TableQuery 生成SQL， 發送到 StarRocks 進行數據查詢，并返回數據。

物化ETL任務生成與調度

物化配置信息確定之后，通過 LodQuery 可以直接確定需要聚合的維度和指標，針對 SUM、COUNT、MAX、MIN 類型的指標可以直接計算，針對比值類型的指標需要分為分子分母分別進行計算，針對UV類型的指標需要將UV類的指標轉化為BITMAP。

UV 計算問題：

看板中會涉及到不少UV的計算，物化視圖中要實現精確的 UV 計算，就需要建立對應的 BITMAP。為了保證 BITMAP 存儲大小和查詢性能，消重字段的對應的數字 id 不能太零散。緊湊的編碼可以提升 BITMAP 的壓縮率和查詢效率。

Bitmap 背后的實現基于 Roaring Bitmap，這是一種用于保存聚合后明細數據的數據結構。它通過兩級索引來保存明細數據，簡而言之，通過兩級索引定位到具體的 container，container 中存放著聚合后的明細數據的低16位，它有三種類型：純數組類型的 Array container、位圖類型的 Bitset container 和 RunLen 編碼的位圖 RunLen container。

size 小于 4096用Array container， 當 size 大于 4096 的時候，顯然使用 Bitset Container 更省空間。所以當整個 size 大于 4096 的時候，Container 會從 Array Container 轉成 Bitset Container，再通過 Runlen 編碼后能否減少空間決定是否要轉為最終存儲格式 RunLen Container。

消重字段我們一般分為兩類：

1. 業務實體 id：比如用戶 id、商家 id、商品 id等。每個業務都有核心分析的業務實體，我們針對這類實體id建立了對應的編碼表，編碼表可以將字符串id映射為緊湊的數字id。大部分的 UV 指標可以通過這類字段進行計算。
2. 自定義消重字段：這類字段通常是通過維度+實體 id 拼接而成，比如搜索 id+搜索詞+用戶，這類字段的基數很大，也很靈活，很難用固定的編碼表進行映射。對于這種類型的字段，我們現在只能通過特定的sql改寫來解決，本文不做詳細討論。

但是含有 BITMAP 的物化視圖的性能并不總是比底表查詢性能好，因為底表查詢數據量雖然大，但是并發也高，傾斜的可能性較低。但是物化視圖按照一些維度聚合之后，可能會造成部分 BITMAP 存儲的id數量太多，太分散，從而導致 BITMAP 的 union 計算耗時增加。那針對這種情況，我們從兩個方面進行優化：

1. 增加物化視圖的數據條數，從而增加查詢并發。
2. 降低BITMAP的傾斜程度。

我們為id編碼增加分桶，比如1-100w分一個桶，100w-200w分一個桶，這樣一方面增加數據條數，另一方面可以減輕數據的傾斜，并且可以有效提升BITMAP的壓縮效率。

經過分桶之后的物化視圖，查詢性能平均可以提升5倍。

03 收益

邏輯數據集上線后，已經替代了大部分sql數據集。截止到發文，邏輯數據集部署100+個，查詢占比達到30%，已經超過SQL數據集。

部署物化視圖的數據集為40+個，涉及交易、直播、廣告等多個業務，平均查詢耗時降低80%，并且平均命中率為30%。

04 展望

當前邏輯數據集基本取代了 SQL 數據集，但是針對復雜的處理邏輯還無法覆蓋，比如對于直播業務，用戶通常會同時看主播的歷史數據和當天分維度數據，從數倉底層來說一般是兩種不同粒度的表，這種情況下分析師和產品期待的是可以使用一個數據集來完成分析，但是當前依賴 Join 的邏輯數據集顯然無法滿足這種查詢場景。未來我們會探索將不同粒度的表結合為一個邏輯數據集的場景，以進一步減少核心數據集的個數，提高用戶找數效率。

理想狀態是數倉只需要加工到寬表這一層，應用層完全可以根據業務需求做自動組裝，物化視圖本質上就是要實現從寬表到看板或自助查詢的自動化加速。不過物化視圖當前還有多個方面可以進行提升。

首先，針對大基數消重指標的支持問題，未來的物化視圖解決方案可能會引入更高效的數據處理算法和更強大的計算引擎。隨著硬件性能的提升和分布式計算技術的成熟，物化視圖或許能夠以更低的資源消耗來處理大規模數據集中的復雜消重操作。

在回刷和數據修改同步方面，未來的物化視圖功能可能會實現更智能、更高效的同步機制。一方面需要更智能實現物化依賴數據集的變化，有效識別出必須物化的場景，減少物化回刷頻次。另一方面針對物化同步的調度能力進行優化，保證物化的執行效率和集群穩定性。

針對物化視圖管理復雜性的問題，未來數倉系統可能會借助AI的能力集成更加自動化和智能化的管理工具。這些工具可以提供自動化的生命周期管理，幫助識別和清理過時或低效的物化視圖，甚至合并必要的物化視圖，減輕數據工程師的負擔。

在展望未來時，我們希望數倉工程師會更聚焦于寬表模型設計，物化視圖和邏輯數據集會將工程師從應用層建設中完全釋放出來。隨著技術的不斷進步，不斷去推進數倉智能化建設。

05 作者

黃猿（吳筱琦）

小紅書數據倉庫工程師，現負責渠道歸因和數據任務性能優化。

儒毅（夏翔）

小紅書分析平臺研發工程師，現負責 RedBI 平臺查詢網關的開發。

雨時（張克冰）

小紅書數據平臺研發工程師，現負責 RedBI 平臺的查詢能力建設。