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

通過這些創(chuàng)新實踐，小紅書在數(shù)據(jù)集收斂程度、看板查詢性能方面取得了顯著提升，為未來數(shù)倉智能化建設(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)生了海量的埋點日志，大數(shù)據(jù)技術(shù)在這樣的數(shù)據(jù)體量下得到了快速的迭代與發(fā)展。在這個過程中，各大公司逐步形成了一套標準的數(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)度平臺來負責，數(shù)據(jù)應(yīng)用會包含公司內(nèi)部的數(shù)據(jù)產(chǎn)品和BI分析工具。

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

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

1.1 問題分析

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

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

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

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

SQL 數(shù)據(jù)集的性能差的另一個原因是數(shù)據(jù)集太大。如果要保證達到和 APP 層表一樣的性能，那么就需要生成類似實體表的加速數(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ù)集可以查詢的粒度和指標，維表定義了可以拆解的維度。這樣一來，每一個業(yè)務(wù)都會只會產(chǎn)出有限的數(shù)據(jù)集，數(shù)據(jù)集個數(shù)得到極大收攏，指標的定義也會更加清晰。

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

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

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

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

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

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

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

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

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

2.2.1 執(zhí)行流程

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

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

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

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

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

2.2.2 查詢裁切步驟

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

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

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

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

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

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

2.3.2 實現(xiàn)方案

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

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

視圖配置

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

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

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

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

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

提需過程

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

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

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

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

物化運維

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

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

查詢改寫

改寫流程：

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

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

LodQuery抽象

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UV 計算問題：

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

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

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

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

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

但是含有 BITMAP 的物化視圖的性能并不總是比底表查詢性能好，因為底表查詢數(shù)據(jù)量雖然大，但是并發(fā)也高，傾斜的可能性較低。但是物化視圖按照一些維度聚合之后，可能會造成部分 BITMAP 存儲的id數(shù)量太多，太分散，從而導(dǎo)致 BITMAP 的 union 計算耗時增加。那針對這種情況，我們從兩個方面進行優(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+個，查詢占比達到30%，已經(jīng)超過SQL數(shù)據(jù)集。

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

04 展望

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

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

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

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

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

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

05 作者

黃猿（吳筱琦）

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

儒毅（夏翔）

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

雨時（張克冰）

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