小紅書在大數(shù)據(jù)處理領(lǐng)域引入了邏輯數(shù)據(jù)集和物化視圖技術(shù)，解決了傳統(tǒng)架構(gòu)中 APP 表復(fù)用度低、單表BI數(shù)據(jù)集可擴(kuò)展性不足、寬表數(shù)據(jù)集看板查詢性能差等問題。這些技術(shù)通過優(yōu)化數(shù)據(jù)處理流程，平衡了數(shù)據(jù)通用性和查詢性能，有效提升了數(shù)據(jù)處理效率和查詢響應(yīng)速度。文章詳細(xì)介紹了邏輯數(shù)據(jù)集和物化視圖的配置、運(yùn)維、查詢改寫以及ETL任務(wù)生成與調(diào)度等關(guān)鍵技術(shù)手段。

通過這些創(chuàng)新實(shí)踐，小紅書在數(shù)據(jù)集收斂程度、看板查詢性能方面取得了顯著提升，為未來數(shù)倉智能化建設(shè)奠定了堅(jiān)實(shí)基礎(chǔ)。

01背景

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

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

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

1.1 問題分析

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

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

SQL 數(shù)據(jù)集一般是一個主表關(guān)聯(lián)多張維表，其性能下降多數(shù)是來自于關(guān)聯(lián)操作。雖然 StarRocks 相對于 Clickhouse 來說Join性能會好很多，但是隨著 Join 的維表的數(shù)量增加，其性能依然會下降很明顯。尤其是當(dāng)用戶的查詢?nèi)绻簧婕暗街鞅碜侄蔚臅r候，SQL 數(shù)據(jù)集沒辦法做到查詢裁切，會比單表查詢更慢。

如上圖所示，SQL1 里只包含Table1 的字段，那么就只應(yīng)該查詢 Table1。SQL2 只包含 Table1 和 Table2 的字段，就應(yīng)該查詢 Table1 和 Table2 的關(guān)聯(lián)結(jié)果。對于 SQL3，因?yàn)樯婕暗?Table2 和 Table3 的維度字段，所以應(yīng)該查詢 Table1，Table2 和 Table3 的關(guān)聯(lián)結(jié)果。因此如果我們可以對查詢做到裁切，就可以有效減少無意義的計(jì)算，提高查詢效率。

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

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

02 數(shù)倉開發(fā)新范式

2.1 總體方案

經(jīng)過上述的分析，數(shù)據(jù)集變?yōu)閷挶?維表的模式。寬表定義了一個數(shù)據(jù)集可以查詢的粒度和指標(biāo)，維表定義了可以拆解的維度。這樣一來，每一個業(yè)務(wù)都會只會產(chǎn)出有限的數(shù)據(jù)集，數(shù)據(jù)集個數(shù)得到極大收攏，指標(biāo)的定義也會更加清晰。

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

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

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

下圖是我們的實(shí)際技術(shù)架構(gòu)。

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

在這層之上就是 RedBI（小紅書內(nèi)部的BI平臺）中的邏輯數(shù)據(jù)集，邏輯數(shù)據(jù)集是數(shù)倉對外的“產(chǎn)品”。

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

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

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

下面著重介紹邏輯數(shù)據(jù)集和物化視圖兩大內(nèi)容。

2.2 邏輯數(shù)據(jù)集

2.2.1 執(zhí)行流程

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

我們使用圖形化界面對數(shù)據(jù)集進(jìn)行配置，界面中的節(jié)點(diǎn)是一個數(shù)據(jù)集或者是一個 SQL，節(jié)點(diǎn)與節(jié)點(diǎn)中間按照關(guān)聯(lián)鍵進(jìn)行連接。配置可以告訴系統(tǒng)只能沿著關(guān)聯(lián)鍵進(jìn)行裁切，而不可以對節(jié)點(diǎn)內(nèi)部進(jìn)行裁切。

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

1. 節(jié)點(diǎn)與節(jié)點(diǎn)之間是 LEFT-JOIN 連接
2. 右表關(guān)聯(lián)鍵不存在重復(fù)值

其中，右表連接鍵唯一性的判斷，會在數(shù)據(jù)預(yù)覽步驟中進(jìn)行，和預(yù)覽結(jié)果一起返回。調(diào)用數(shù)據(jù)預(yù)覽接口時處理如下：

2.2.2 查詢裁切步驟

1. 從數(shù)據(jù)集元信息中，獲取可以進(jìn)行裁剪的節(jié)點(diǎn)列表。

2. 根據(jù) DSL 中的維度、指標(biāo)、篩選等字段，把本次查詢用到的所有字段展平，把字段對應(yīng)的節(jié)點(diǎn) id 排除，從而得到本次查詢可裁剪的節(jié)點(diǎn)列表。

3. 所有的節(jié)點(diǎn)列表去掉可裁剪的節(jié)點(diǎn)，得到優(yōu)化后的節(jié)點(diǎn)列表。

4. 然后根據(jù)連接條件把相關(guān)的表 Join 起來，作為一個整體數(shù)據(jù)集執(zhí)行BI查詢。

2.3 物化視圖的技術(shù)手段

2.3.1 工具選擇

StarRocks 和其他 OLAP 引擎一樣，也具備物化視圖的功能。StarRocks 的物化視圖分為同步物化視圖和異步物化視圖。同步物化視圖可以保證數(shù)據(jù)集的一致性，異步物化視圖需要設(shè)置刷新周期。但是在應(yīng)用到生產(chǎn)環(huán)境的時候，就會發(fā)現(xiàn)物化視圖的調(diào)度對集群會造成很大的壓力，并且也無法滿足很多業(yè)務(wù)訴求。

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

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

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

2.3.2 實(shí)現(xiàn)方案

當(dāng)前業(yè)界在設(shè)計(jì)物化視圖功能的時候，都聚焦在了查詢的改寫能力方面，盡可能保證物化視圖可以適應(yīng)越來越多的查詢場景。但是實(shí)際在生產(chǎn)環(huán)境中我們發(fā)現(xiàn)物化視圖的配置和運(yùn)維流程會更加重要。和物化視圖相關(guān)的整套產(chǎn)品功能包括以下幾類：物化視圖配置、物化 ETL 任務(wù)生成與調(diào)度、物化查詢改寫、物化治理。

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

視圖配置

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

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

1. 需要物化的內(nèi)容。在我們的場景下，就是看板和自主分析模版?？窗搴妥灾鞣治瞿０娴牟樵儫岫茸鳛檩o助指標(biāo)可以使用戶知曉哪些看板的物化更有價值。

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

• 物化視圖的命中率是我們依賴歷史查詢進(jìn)行的分析生成的。如果物化視圖的命中率太低，那么對于查詢性能的改變就微乎其微。此外，通過看板和自主分析模版生產(chǎn)的物化視圖結(jié)構(gòu)可能因?yàn)楣δ懿恢С只蛘呶锘芷诘脑蛎新实?，需要用戶進(jìn)行手動調(diào)整。
• 物化視圖的數(shù)據(jù)量要有限制。如果用戶將所有看板和自主分析模版都加入物化，必然可以保證很高的命中率，但是這樣的物化視圖也接近于明細(xì)了，那物化視圖的查詢就會變慢，物化視圖查詢加速的能力也就喪失了。因此調(diào)試過程中需要顯示物化視圖的數(shù)據(jù)量，以保證物化視圖的性能。

提需過程

我們需要在什么時候決定要對什么內(nèi)容創(chuàng)建物化視圖進(jìn)行加速呢？僅僅依賴數(shù)倉的經(jīng)驗(yàn)肯定是不靠譜的，因?yàn)閿?shù)據(jù)集的使用方可能是分析師、產(chǎn)品和運(yùn)營。這些使用方往往會根據(jù)自己的需求去搭建看板，數(shù)倉是完全不清楚業(yè)務(wù)具體是怎么使用的。

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

如果物化視圖依然沿用這一思路，對于數(shù)倉和業(yè)務(wù)方來說，物化視圖和 APP 表就沒有任何差別，因?yàn)楦旧蠜]有降低其中的溝通成本。

業(yè)務(wù)方對于看板的樣式以及指標(biāo)是最清楚的，一旦涉及到溝通，必然存在信息損耗。因此我們將提需流程改為了如下方式?？梢钥闯鲂碌奶嵝枇鞒淌窍扔蓸I(yè)務(wù)創(chuàng)建出看板，然后將需要物化的內(nèi)容提需給數(shù)倉，數(shù)倉完成對應(yīng)的物化需求。這個過程中，需求文檔不再是一個充滿文字和表格的文檔，也不需要人工講解，而是一個真實(shí)的看板圖表。配合物化視圖的配置功能，可以輕松完成物化視圖的搭建。

物化運(yùn)維

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

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

查詢改寫

改寫流程：

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

• 用戶發(fā)起查詢時，BI 界面的查詢配置會轉(zhuǎn)化為 QueryDSL，QueryDSL 經(jīng)過解析 Lod 表達(dá)式、字段拆解等，然后轉(zhuǎn)化為 LodQuery 對象。

LodQuery抽象

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

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

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

? from：查詢表信息，指定了多張?jiān)急?、自定義SQL表、邏輯數(shù)據(jù)集對應(yīng)的主表和多張維表的定義及關(guān)聯(lián)方式，存在嵌套結(jié)構(gòu)。

?dimensionFilters：維度篩選，指定了對明細(xì)數(shù)據(jù)的篩選方式，需要指定Pill和FilterPredicate

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

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

? offset：查詢偏移量，指定了結(jié)果需要偏移多少行數(shù)據(jù)

?limit：查詢數(shù)據(jù)量，指定了結(jié)果集的數(shù)據(jù)量上限

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

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

• 基于 TableQuery 生成SQL， 發(fā)送到 StarRocks 進(jìn)行數(shù)據(jù)查詢，并返回?cái)?shù)據(jù)。

物化ETL任務(wù)生成與調(diào)度

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

UV 計(jì)算問題：

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

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

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

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

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

但是含有 BITMAP 的物化視圖的性能并不總是比底表查詢性能好，因?yàn)榈妆聿樵償?shù)據(jù)量雖然大，但是并發(fā)也高，傾斜的可能性較低。但是物化視圖按照一些維度聚合之后，可能會造成部分 BITMAP 存儲的id數(shù)量太多，太分散，從而導(dǎo)致 BITMAP 的 union 計(jì)算耗時增加。那針對這種情況，我們從兩個方面進(jìn)行優(yōu)化：

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

我們?yōu)閕d編碼增加分桶，比如1-100w分一個桶，100w-200w分一個桶，這樣一方面增加數(shù)據(jù)條數(shù)，另一方面可以減輕數(shù)據(jù)的傾斜，并且可以有效提升BITMAP的壓縮效率。

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

03 收益

邏輯數(shù)據(jù)集上線后，已經(jīng)替代了大部分sql數(shù)據(jù)集。截止到發(fā)文，邏輯數(shù)據(jù)集部署100+個，查詢占比達(dá)到30%，已經(jīng)超過SQL數(shù)據(jù)集。

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

04 展望

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

理想狀態(tài)是數(shù)倉只需要加工到寬表這一層，應(yīng)用層完全可以根據(jù)業(yè)務(wù)需求做自動組裝，物化視圖本質(zhì)上就是要實(shí)現(xiàn)從寬表到看板或自助查詢的自動化加速。不過物化視圖當(dāng)前還有多個方面可以進(jìn)行提升。

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

在回刷和數(shù)據(jù)修改同步方面，未來的物化視圖功能可能會實(shí)現(xiàn)更智能、更高效的同步機(jī)制。一方面需要更智能實(shí)現(xiàn)物化依賴數(shù)據(jù)集的變化，有效識別出必須物化的場景，減少物化回刷頻次。另一方面針對物化同步的調(diào)度能力進(jìn)行優(yōu)化，保證物化的執(zhí)行效率和集群穩(wěn)定性。

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

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

05 作者

黃猿（吳筱琦）

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

儒毅（夏翔）

小紅書分析平臺研發(fā)工程師，現(xiàn)負(fù)責(zé) RedBI 平臺查詢網(wǎng)關(guān)的開發(fā)。

雨時（張克冰）

小紅書數(shù)據(jù)平臺研發(fā)工程師，現(xiàn)負(fù)責(zé) RedBI 平臺的查詢能力建設(shè)。