**導讀：** Apache Doris 是小米集團內部應用最為廣泛的 OLAP 引擎之一，本文主要從資料的角度分析 A/B 實驗場景查詢的效能現狀，探討基於 Apache Doris 的效能最佳化的解決方案。經過一系列基於 Doris 的效能最佳化和測試，A/B 實驗場景查詢效能的提升超過了我們的預期。希望本次分享可以給有需要的朋友提供一些參考。

作者｜小米集團大資料工程師 樂濤

# 業務背景

A/B 實驗是網際網路場景中對比策略優劣的重要手段。為了驗證一個新策略的效果，需要準備原策略 A 和新策略 B 兩種方案。隨後在總體使用者中取出一小部分，將這部分使用者完全隨機地分在兩個組中，使兩組使用者在統計角度無差別。將原策略 A 和新策略 B 分別展示給不同的使用者組，一段時間後，結合統計方法分析資料，得到兩種策略生效後指標的變化結果，並以此判斷新策略 B 是否符合預期。

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5dcb0c3801d547dc8a93d9e7788ef30c~tplv-k3u1fbpfcp-zoom-1.image)

小米 A/B 實驗平臺是一款透過 A/B 實驗的方式，藉助實驗分組、流量拆分與科學評估來輔助完成科學的業務決策，最終實現業務增長的一款運營工具產品。其廣泛的應用於產品研發生命週期中各個環節：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cbc8ef09f18144f0837ee026d014d5bf~tplv-k3u1fbpfcp-zoom-1.image)

# 資料平臺架構

本文主要從資料的角度分析 A/B 實驗場景查詢的效能現狀，探討一下基於 Apache Doris 的效能最佳化的解決方案。A/B實驗平臺的架構如下圖所示：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/df1c3151f18a4dadb2105c194fa7569b~tplv-k3u1fbpfcp-zoom-1.image)

-   平臺使用的資料主要包含平臺自用的實驗配置資料、後設資料，以及業務方上報的日誌資料。
-   由於業務方引入 SDK，並與分流服務進行互動，日誌資料中包含其參與的實驗組 ID 資訊。
-   使用者在實驗平臺上配置、分析、查詢，以獲得報告結論滿足業務訴求。

鑑於 AB 實驗報告各個業務方上報資料的鏈路都大體類似，我們就拿**頭部業務方廣告業務**舉例，資料流程如下圖所示：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3dd1afba02114622820bd2ee05a047e4~tplv-k3u1fbpfcp-zoom-1.image)

從上圖可知，整個資料鏈路並不複雜，日誌資料傳入後，經過必要的資料處理和清洗工作進入 Talos（小米自研訊息佇列），透過 Flink 任務以明細資料的形式實時寫入到 Doris 表中，同時 Talos 資料也會同步到 Hive 表進行備份，以便問題排查和資料修復。

出於對高效寫入以及欄位增減需求的考慮，**Doris 明細表以 Duplicate 模型來建模**：

```
CREATE TABLE `dwd_xxxxxx` (
  `olap_date` int(11) NULL COMMENT "分割槽日期",
  `user_id` varchar(256) NULL COMMENT "使用者id",
  `exp_id` varchar(512) NULL COMMENT "實驗組ID",
  `dimension1` varchar(256) NULL COMMENT "",
  `dimension2` varchar(256) NULL COMMENT "",
  ......
  `dimensionN` bigint(20) NULL COMMENT "",
  `index1` decimal(20, 3) NULL COMMENT "",
  ......
  `indexN` int(11) NULL COMMENT "",

) ENGINE=OLAP
DUPLICATE KEY(`olap_date`, `user_id`)
COMMENT "OLAP"
PARTITION BY RANGE(`olap_date`)
(
PARTITION p20221101 VALUES [("20221101"), ("20221102")),
PARTITION p20221102 VALUES [("20221102"), ("20221103")),
PARTITION p20221103 VALUES [("20221103"), ("20221104"))
)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 300
;
資料現狀分析
```

在提速之前，小米 A/B 實驗平臺完成實驗報告查詢的 P95 時間為**小時級**，實驗報告使用資料的方式存在諸多的效能問題，直接影響業務部門做運營和決策的效率。

## **報告查詢基於明細**

當前報告查詢的資料來源為明細表，而明細表的資料量巨大：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0930be665be34ef7bdeba0e81b2dea68~tplv-k3u1fbpfcp-zoom-1.image)

而且，實驗報告的查詢條件中時間範圍常常橫跨多天。基於歷史查詢報告統計，查詢條件中時間範圍大於一天的報告佔比 69.1%，具體的時間跨度佔比分佈如下：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/941e6cc43f344dc29cfe43f19ac02cc1~tplv-k3u1fbpfcp-zoom-1.image)

明細資料的巨大掃描量給叢集帶來了不小的壓力，且由於報告查詢存在併發以及 SQL 的拆分，如果一個 SQL 請求不能快速的返回結果釋放資源，也會影響到請求的排隊狀況。因此在工作時間段內 Doris 叢集BE節點 CPU 負載狀況基本是持續滿載，磁碟 IO 也持續處於高負荷狀態，如下圖所示：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b5b7d2593f7f46758502bb87ca05d72d~tplv-k3u1fbpfcp-zoom-1.image)

BE節點CPU使用率

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9a5b015ff44141edb47838b8dc791869~tplv-k3u1fbpfcp-zoom-1.image)

BE節點磁碟IO

**個人思考：**

-   當前報告所有查詢基於明細資料，且平均查詢時間跨度為 4 天，查詢掃描資料量上百億。由於掃描資料量級大，計算成本高，給叢集造成較大壓力，導致資料查詢效率不高。
-   如果透過對資料進行預聚合處理，控制 Scan Rows 和 Scan Bytes，減小叢集的壓力，查詢效能會大幅提升。

## 欄位查詢熱度分層分佈

由於之前流程管控機制相對寬鬆，使用者新增的埋點欄位都會進入到明細表中，導致欄位冗餘較多。統計歷史查詢報告發現，明細表中常用的維度和指標只集中在部分欄位，且查詢熱度分層分佈：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f13a26d96a3c4bf381d5f36bdfec7e05~tplv-k3u1fbpfcp-zoom-1.image)

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1b77b0b97c67491492819e3c29b09b22~tplv-k3u1fbpfcp-zoom-1.image)

參與計算的指標也集中在部分欄位，且大部分都是聚合計算(sum)或可以轉化為聚合計算(avg)：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b57d1ab7552c45d4a0031f369d33f34f~tplv-k3u1fbpfcp-zoom-1.image)

**個人思考：**

-   明細表中參與使用的維度只佔 54.3%，高頻使用的維度只佔 15.2%，維度查詢頻次分層分佈。
-   資料聚合需要對明細表中維度欄位做取捨，選擇部分維度進行上卷從而達到合併的目的，但捨棄部分欄位必然會影響聚合資料對查詢請求的覆蓋情況。而維度查詢頻次分層分佈的場景非常適合根據維度欄位的熱度做不同層次的資料聚合，同時兼顧聚合表的聚合程度和覆蓋率。

## **實驗組 ID 匹配效率低**

當前明細資料的格式為：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fb5655d0051b46acae29c77a40c3b38c~tplv-k3u1fbpfcp-zoom-1.image)

明細資料中的實驗組 ID 以逗號分隔的字串形式聚攏在一個欄位中，而實驗報告的每條查詢語句都會使用到`exp_id`過濾，查詢資料時使用 LIKE 方式匹配，查詢效率低下。

**個人思考：**

-   將實驗組 ID 建模成一個單獨的維度，可使用完全匹配代替 LIKE 查詢，且可利用到 Doris 索引，提高資料查詢效率。
-   將逗號分隔的實驗組 ID 直接打平會引起資料量的急劇膨脹，因此需要設計合理的方案，同時兼顧到資料量和查詢效率。

## **進組人數計算有待改進**

進組人數查詢是實驗報告的必查指標，因此其查詢速度很大程度上影響實驗報告的整體查詢效率，當前主要問題如下：

-   當進組人數作為獨立指標計算時，使用近似計算函式`APPROX_COUNT_DISTINCT`處理，是透過犧牲準確性的方式提升查詢效率。
-   當進組人數作為複合指標的分母進行計算時，使用`COUNT DISTINCT`處理，此方式在大資料量計算場景效率較低。

**個人思考：**

-   AB實驗報告的資料結論會影響到使用者決策，犧牲準確性的方式提升查詢效率是不可取的，特別是廣告這類涉及金錢和業績的業務場合，使用者不可能接受近似結果。
-   進組人數使用的`COUNT DISTINCT`計算需要依賴明細資訊，這也是之前查詢基於明細資料的重要因素。必須為此類場景設計新的方案，使進組人數的計算在保證資料準確的前提下提高效率。

# 資料最佳化方案

基於以上的資料現狀，我們最佳化的核心點是將明細資料預聚合處理，透過壓縮資料來控制 Doris 查詢的 Scan Rows 和 Scan Bytes。與此同時，使聚合資料儘可能多的覆蓋報告查詢。從而達到，減小叢集的壓力，提高查詢效率的目的。

新的資料流程如下圖所示：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/57d5553100244922963cdda8f1f46ca6~tplv-k3u1fbpfcp-zoom-1.image)

整個流程在明細鏈路的基礎上增加聚合鏈路，Talos 資料一方面寫入 Doris 明細表，另一方面增量落盤到 Iceberg 表中，Iceberg 表同時用作回溯明細資料以及生成聚合資料，我們透過工場 Alpha（小米自研資料開發平臺）的實時整合和離線整合保證任務的穩定執行和資料的一致性。

## **選取高頻使用維度聚合**

在生成資料聚合的過程中，聚合程度與請求覆蓋率是負相關的。使用的維度越少，能覆蓋的請求就越少，但資料聚合程度越高；使用的維度越多，覆蓋的請求也越多，但資料粒度就越細，聚合程度也越低。因此需要在聚合表建模的過程中取得一個平衡。

**我們的具體做法是**：拉取歷史（近半年）查詢日誌進行分析，根據維度欄位的使用頻次排序確認進入聚合表的優先順序。在此基礎上得出聚合表的覆蓋率和資料量隨著建模欄位增加而變化的曲線，如下圖所示：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/424e6cb12a40429ba7be6c790a9f3cb3~tplv-k3u1fbpfcp-zoom-1.image)

其中覆蓋率根據歷史請求日誌代入聚合表計算得出。

我們的原則是：針對 OLAP 查詢，聚合表的資料量應儘可能的控制在單日 **1 億條**以內，請求覆蓋率儘可能達到 **80%以上**。

因此不難得出結論：選擇 14 個維度欄位對聚合表建模比較理想，資料量能控制到單日 **8 千萬**條左右，且請求覆蓋率約為 **83%** 。

## **使用物化檢視**

在分析報告歷史查詢日誌時，我們發現不同的維度欄位查詢頻次有明顯的分層：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e474e049415d4407bb5027259152b743~tplv-k3u1fbpfcp-zoom-1.image)

Top7 維度欄位幾乎出現在所有報告的查詢條件之中，對於如此高頻的查詢，值得做進一步的投入，使查詢效率儘可能的提升到最佳。**Doris 的物化檢視能夠很好的服務於此類場景。**

**什麼是物化檢視？**

物化檢視是一種特殊的**物理表**，其中儲存基於基表(base table)部分欄位進一步**上卷聚合**的結果。

雖然在物理上獨立儲存，但它是對**使用者透明**的。為一張基表配置好物化檢視之後，不需要為其寫入和查詢做任何額外的工作：

-   當向基表寫入和更新資料時，叢集會自動同步到物化檢視，並透過事務方式保證資料一致性。
-   當對基表進行查詢時，叢集會自動判斷是否路由到物化檢視獲取結果。當查詢欄位能被物化檢視完全覆蓋時，會優先使用物化檢視。

因此我們的查詢路由如下圖所示：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fef5e54272684d0485c6abe559a6c1dd~tplv-k3u1fbpfcp-zoom-1.image)

使用者的查詢請求會盡可能的路由到聚合表物化檢視，然後是聚合表基表，最後才是明細表。

如此使用**多梯度**的聚合模型的配合來應對**熱度分層**的查詢請求，使聚合資料的效能儘可能的發揮到最大。

## **精確匹配取代 LIKE 查詢**

既然物化檢視這麼好用，為什麼我們不是基於 Doris 明細表配置物化檢視，而是單獨開發聚合表呢？是因為明細資料中的實驗組ID欄位儲存和查詢方式並不合理，聚合資料並不適合透過明細資料直接上捲來得到。

上文中已經提到，`exp_id`（實驗組ID）在明細表中以逗號分隔的字串進行儲存，查詢資料時使用 LIKE 方式匹配。作為 AB 實驗報告查詢的**必查條件**，這種查詢方式無疑是**低效**的。

我們希望的聚合方式如下圖所示：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/846019d1281b475f9464ad4f889109c9~tplv-k3u1fbpfcp-zoom-1.image)

我們需要將`exp_id`欄位拆開，把資料打平，使用精確匹配來取代LIKE查詢，提高查詢的效率。

**控制聚合表資料量**

如果只做拆分打平的處理必然會導致資料量的激增，未必能達到正向最佳化的效果，因此我們還需要想辦法來壓縮`exp_id`打平後的資料量：

-   聚合表選取維度欄位建模的時候，除了上文提到的，以欄位的使用頻次熱度作為依據之外，也要關注欄位的**取值基數**，進行綜合取捨。如果取值基數過高的維度欄位進入聚合表，必然會對控制聚合表的資料量造成阻礙。因此，我們在保證聚合表請求覆蓋量的前提下，酌情捨棄部分**高基數**（取值有十萬種以上）的維度。
-   從業務的角度儘可能過濾無效資料（比如一個實驗組的流量為 0% 或者 100%，業務上就沒有對照的意義，使用者也不會去查，這樣的資料就不需要進入聚合表）。

經過這一系列步驟，最終聚合表的資料量被控制在單日約 8000 萬條，並沒有因為 `exp_id`打平而膨脹。

值得一提的是，`exp_id`欄位拆分後，除了查詢從LIKE匹配變為精確匹配，還額外帶來了兩項收益：

-   欄位從`String`型別變為`Int`型別，作為查詢條件時的比對效率變高。
-   能利用Doris的**字首索引**和**布隆過濾器**等能力，進一步提高查詢效率。

## **使用 BITMAP 去重代替** **COUNT DISTINCT**

要提速實驗報告查詢，針對進組人數（去重使用者數）的最佳化是非常重要的一個部分。作為一個對明細資料強依賴的指標，我們如何在不丟失明細資訊的前提下，實現像 Sum,Min,Max 等指標一樣高效的預聚合計算呢？**BITMAP 去重計算可以很好的滿足我們的需求。**

**什麼是BITMAP去重？**

BITMAP 去重簡單來說就是建立一種資料結構，表現形式為記憶體中連續的二進位制位(bit)，參與去重計算的每個元素（必須為整型）都可以對映成這個資料結構的一個 bit 位的下標，如下圖所示：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/930a9d6a58b54a6697c8821d766c40f5~tplv-k3u1fbpfcp-zoom-1.image)

計算去重使用者數時，資料以 `bit_or`的方式進行合併，以`bit_count`的方式得到結果。更重要的是，如此能實現去重使用者數的預聚合。BITMAP 效能優勢主要體現在兩個方面：

-   空間緊湊：透過一個 bit 位是否置位表示一個數字是否存在，能節省大量空間。以 Int32 為例，傳統的儲存空間為 4 個位元組，而在 BITMAP 計算時只需為其分配 1/8 位元組（1個 bit 位）的空間。
-   計算高效：BITMAP 去重計算包括對給定下標的 bit 置位，統計 BITMAP 的置位個數，分別為 O(1) 和 O(n) 的操作，並且後者可使用 CLZ，CTZ 等指令高效計算。此外，BITMAP 去重在 Doris 等 MPP 執行引擎中還可以並行加速處理，每個節點各自計算本地子 BITMAP，而後進行合併。

當然，以上只是一個簡化的介紹，這項技術發展至今已經做了很多最佳化實現，比如RoaringBitmap，感興趣的同學可以看看：<https:>

**全域性字典**

要實現 BITMAP 去重計算，必須保證參與計算的元素為 UInt32 / UInt64，而我們的`user_id`為`String`型別，因此我們還需設計維護一個全域性字典，將`user_id`對映為數字，從而實現 BITMAP 去重計算。

由於聚合資料目前只服務於離線查詢，我們選擇基於Hive表實現全域性字典，其流程如下：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/501ed8ef2903406e88bc5cdebed2a516~tplv-k3u1fbpfcp-zoom-1.image)

**指標聚合**

生成 Doris 聚合表時，將 `user_id`作為查詢指標以 BITMAP 型別來儲存，其他常規查詢指標則透過 COUNT/SUM/MAX/MIN 等方式聚合：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/263174085bbe4bd6b006745a9b5ef0ae~tplv-k3u1fbpfcp-zoom-1.image)

如此明細表和聚合表的指標計算對應關係如下：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/eb65d625fcaf4a838a221af0b682d388~tplv-k3u1fbpfcp-zoom-1.image)

# 最佳化效果

## **SQL視角**

查詢請求轉換成 SQL 之後，在明細表和聚合表的表現對比如下：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/902452d3ffd5442bb46850a4fa0b1f05~tplv-k3u1fbpfcp-zoom-1.image)

-   常規聚合指標查詢的效能提升自不必說（速度提升 **50~60** 倍）
-   進組人數查詢效能的提升也非常可觀（速度提升 **10** 倍左右）

## **叢集視角**

SQL 查詢的快進快出，使查詢佔用的資源能快速釋放，對叢集壓力的緩解也有正向的作用。

Doris 叢集 BE 節點 CPU 使用情況和磁碟IO 狀況的改變效果顯著：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c12eb5a3e08b431b9ab7ef261f702210~tplv-k3u1fbpfcp-zoom-1.image)

需要說明的是，叢集狀況的改善（包括實驗報告查詢 P95 提升）並不全歸功於資料預聚合最佳化工作，這是各方合力協作（如產品業務形態調整，後端查詢引擎排隊最佳化，快取調優，Doris 叢集調優等）的綜合結果。

# 小技巧

由於業務查詢需求的多樣，在查詢明細表時，會出現一個欄位**既作為維度又作為指標**來使用的情況。

如廣告業務表中的`targetConvNum`(目標轉化個數)欄位，此欄位的取值為 0 和 1，查詢場景如下：

```
--作為維度
select targetConvNum,count(distinct user_id)
from analysis.doris_xxx_event 
where olap_date = 20221105
and event_name='CONVERSION'
and exp_id like '%154556%'
group by targetConvNum;

--作為指標
select sum(targetConvNum)
from analysis.doris_xxx_event 
where olap_date = 20221105
and event_name='CONVERSION'
and exp_id like '%154556%';
```

如果這個欄位被選取進入聚合表，應該如何處理呢？

**我們的處理方式是：**

-   在聚合表中把這類欄位建模成**維度**
-   聚合表中需要一個計數指標 cnt，表示聚合表中一條資料由明細表多少條資料聚合得
-   當這類欄位被作為指標查詢時，可將其與cnt指標配合計算得到正確結果

**明細表查詢：**

```
select sum(targetConvNum)
from analysis.doris_xxx_event 
where olap_date = 20221105
and event_name='CONVERSION'
and exp_id like '%154556%';
對應的聚合表查詢：
select sum(targetConvNum * cnt)
from agg.doris_xxx_event_agg
where olap_date = 20221105
and event_name = 'CONVERSION' 
and exp_id = 154556;
```

# 結束語

經過這一系列基於 Doris 的效能最佳化和測試，A/B 實驗場景查詢效能的提升超過了我們的預期。值得一提的是，**Doris 較高的穩定性和完備的監控、分析工具也為我們的最佳化工作提效不少。** 希望本次分享可以給有需要的朋友提供一些參考。

最後，**感謝 SelectDB 公司和 Apache Doris 社群對我們的鼎力支援**。Apache Doris 是小米集團內部應用最為廣泛的 OLAP 引擎之一，目前集團內部正在推進最新的向量化版本升級工作。未來一段時間我們將會把業務最佳化工作和 Doris 最新的向量化版本進行適配，進一步助力業務的正向發展。

— **End** —

最後，歡迎更多的開源技術愛好者加入 Apache Doris 社群，攜手成長，共建社群生態。**Apache Doris 社群當前已容納了上萬名開發者和使用者，承載了 30+ 交流社群**，如果你也是 Apache Doris 的愛好者，掃碼加入 Apache Doris 社群使用者交流群，在這裡你可以獲得：

-   專業全職團隊技術支援
-   直接和社群專家交流，獲取免費且專業回覆
-   認識不同行業的開發者，收穫知識以及合作機會
-   Apache Doris 最新版本優先體驗權
-   獲取一手乾貨和資訊以及活動優先參與權

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c2f0452c74be4860adacf0ff4e21f631~tplv-k3u1fbpfcp-zoom-1.image)

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e07fef302258494e963bcd7eb02f44a1~tplv-k3u1fbpfcp-zoom-1.image)</https:>

小米 A/B 實驗場景基於 Apache Doris 的查詢提速最佳化實踐

相關文章