導(dǎo)讀：?Apache Doris 是小米集團(tuán)內(nèi)部應(yīng)用最為廣泛的 OLAP 引擎之一阔拳，本文主要從數(shù)據(jù)的角度分析 A/B 實(shí)驗(yàn)場(chǎng)景查詢的性能現(xiàn)狀，探討基于 Apache Doris 的性能優(yōu)化的解決方案涤伐。經(jīng)過一系列基于 Doris 的性能優(yōu)化和測(cè)試恬惯，A/B 實(shí)驗(yàn)場(chǎng)景查詢性能的提升超過了我們的預(yù)期狭郑。希望本次分享可以給有需要的朋友提供一些參考。
作者｜小米集團(tuán)大數(shù)據(jù)工程師 樂濤
一铸题、業(yè)務(wù)背景
A/B實(shí)驗(yàn)是互聯(lián)網(wǎng)場(chǎng)景中對(duì)比策略優(yōu)劣的重要手段铡恕。為了驗(yàn)證一個(gè)新策略的效果，需要準(zhǔn)備原策略A和新策略B兩種方案丢间。 隨后在總體用戶中取出一小部分探熔，將這部分用戶完全隨機(jī)地分在兩個(gè)組中，使兩組用戶在統(tǒng)計(jì)角度無差別烘挫。將原策略A和新策略B分別展示給不同的用戶組诀艰，一段時(shí)間后，結(jié)合統(tǒng)計(jì)方法分析數(shù)據(jù)饮六，得到兩種策略生效后指標(biāo)的變化結(jié)果其垄，并以此判斷新策略B是否符合預(yù)期。
小米A/B實(shí)驗(yàn)平臺(tái)是一款通過A/B實(shí)驗(yàn)的方式卤橄，借助實(shí)驗(yàn)分組绿满、流量拆分與科學(xué)評(píng)估來輔助完成科學(xué)的業(yè)務(wù)決策，最終實(shí)現(xiàn)業(yè)務(wù)增長的一款運(yùn)營工具產(chǎn)品窟扑。其廣泛的應(yīng)用于產(chǎn)品研發(fā)生命周期中各個(gè)環(huán)節(jié)：
本文主要從數(shù)據(jù)的角度分析A/B實(shí)驗(yàn)場(chǎng)景查詢的性能現(xiàn)狀棒口，探討一下性能優(yōu)化的解決方案。
二辜膝、數(shù)據(jù)平臺(tái)架構(gòu)
A/B實(shí)驗(yàn)平臺(tái)的架構(gòu)如下圖所示：
平臺(tái)使用的數(shù)據(jù)主要包含平臺(tái)自用的實(shí)驗(yàn)配置數(shù)據(jù)无牵、元數(shù)據(jù)，以及業(yè)務(wù)方上報(bào)的日志數(shù)據(jù)厂抖。
由于業(yè)務(wù)方引入 SDK茎毁，并與分流服務(wù)進(jìn)行交互，日志數(shù)據(jù)中包含其參與的實(shí)驗(yàn)組 ID 信息。
用戶在實(shí)驗(yàn)平臺(tái)上配置七蜘、分析谭溉、查詢，以獲得報(bào)告結(jié)論滿足業(yè)務(wù)訴求橡卤。
鑒于AB實(shí)驗(yàn)報(bào)告各個(gè)業(yè)務(wù)方上報(bào)數(shù)據(jù)的鏈路都大體類似扮念，我們就拿頭部業(yè)務(wù)方廣告業(yè)務(wù)舉例
數(shù)據(jù)流程如下圖所示：
整個(gè)數(shù)據(jù)鏈路并不復(fù)雜，日志數(shù)據(jù)傳入后碧库，經(jīng)過必要的數(shù)據(jù)處理和清洗工作進(jìn)入 Talos（小米自研消息隊(duì)列）柜与，通過 Flink 任務(wù)以明細(xì)數(shù)據(jù)的形式實(shí)時(shí)寫入到 Doris 表中，同時(shí) Talos 數(shù)據(jù)也會(huì)同步到 Hive 表進(jìn)行備份嵌灰，以便問題排查和數(shù)據(jù)修復(fù)弄匕。
出于對(duì)高效寫入以及字段增減需求的考慮，Doris 明細(xì)表以 Duplicate 模型來建模：
CREATE TABLE `dwd_xxxxxx` (
? `olap_date` int(11) NULL COMMENT "分區(qū)日期",
? `user_id` varchar(256) NULL COMMENT "用戶id",
? `exp_id` varchar(512) NULL COMMENT "實(shí)驗(yàn)組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
;
三沽瞭、數(shù)據(jù)現(xiàn)狀分析
在提速之前迁匠，小米A/B實(shí)驗(yàn)平臺(tái)完成實(shí)驗(yàn)報(bào)告查詢的 P95 時(shí)間為小時(shí)級(jí)，實(shí)驗(yàn)報(bào)告使用數(shù)據(jù)的方式存在諸多的性能問題驹溃，直接影響業(yè)務(wù)部門做運(yùn)營和決策的效率城丧。
3.1 報(bào)告查詢基于明細(xì)
當(dāng)前報(bào)告查詢的數(shù)據(jù)來源為明細(xì)表，而明細(xì)表的數(shù)據(jù)量巨大：
而且豌鹤，實(shí)驗(yàn)報(bào)告的查詢條件中時(shí)間范圍常常橫跨多天芙贫。基于歷史查詢報(bào)告統(tǒng)計(jì)傍药，查詢條件中時(shí)間范圍大于一天的報(bào)告占比69.1%磺平，具體的時(shí)間跨度占比分布如下：
明細(xì)數(shù)據(jù)的巨大掃描量給集群帶來了不小的壓力，且由于報(bào)告查詢存在并發(fā)以及 SQL 的拆分拐辽，如果一個(gè) SQL 請(qǐng)求不能快速的返回結(jié)果釋放資源拣挪，也會(huì)影響到請(qǐng)求的排隊(duì)狀況。因此在工作時(shí)間段內(nèi) Doris 集群BE節(jié)點(diǎn) CPU 負(fù)載狀況基本是持續(xù)滿載俱诸，磁盤 IO 也持續(xù)處于高負(fù)荷狀態(tài)菠劝，如下圖所示：
BE節(jié)點(diǎn)CPU使用率
BE節(jié)點(diǎn)磁盤IO
個(gè)人思考
當(dāng)前報(bào)告所有查詢基于明細(xì)數(shù)據(jù)，且平均查詢時(shí)間跨度為 4 天睁搭，查詢掃描數(shù)據(jù)量上百億赶诊。
由于掃描數(shù)據(jù)量級(jí)大，計(jì)算成本高园骆，給集群造成較大壓力舔痪，導(dǎo)致數(shù)據(jù)查詢效率不高。
如果通過對(duì)數(shù)據(jù)進(jìn)行預(yù)聚合處理锌唾，控制 Scan Rows 和 Scan Bytes锄码，減小集群的壓力夺英，查詢性能會(huì)大幅提升。
3.2 字段查詢熱度分層分布
由于之前流程管控機(jī)制相對(duì)寬松滋捶，用戶添加的埋點(diǎn)字段都會(huì)進(jìn)入到明細(xì)表中痛悯，導(dǎo)致字段冗余較多。
統(tǒng)計(jì)歷史查詢報(bào)告發(fā)現(xiàn)重窟，明細(xì)表中常用的維度和指標(biāo)只集中在部分字段载萌，且查詢熱度分層分布：
參與計(jì)算的指標(biāo)也集中在部分字段，且大部分都是聚合計(jì)算(sum)或可以轉(zhuǎn)化為聚合計(jì)算(avg)：
個(gè)人思考
明細(xì)表中參與使用的維度只占54.3%巡扇，高頻使用的維度只占15.2%扭仁，維度查詢頻次分層分布。
數(shù)據(jù)聚合需要對(duì)明細(xì)表中維度字段做取舍霎迫，選擇部分維度進(jìn)行上卷從而達(dá)到合并的目的，但舍棄部分字段必然會(huì)影響聚合數(shù)據(jù)對(duì)查詢請(qǐng)求的覆蓋情況帘靡。而維度查詢頻次分層分布的場(chǎng)景非常適合根據(jù)維度字段的熱度做不同層次的數(shù)據(jù)聚合知给，同時(shí)兼顧聚合表的聚合程度和覆蓋率。
3.3 實(shí)驗(yàn)組ID匹配效率低
當(dāng)前明細(xì)數(shù)據(jù)的格式為：
明細(xì)數(shù)據(jù)中的實(shí)驗(yàn)組ID以逗號(hào)分隔的字符串形式聚攏在一個(gè)字段中描姚，而實(shí)驗(yàn)報(bào)告的每條查詢語句都會(huì)使用到exp_id過濾涩赢，查詢數(shù)據(jù)時(shí)使用LIKE方式匹配，查詢效率低下轩勘。
個(gè)人思考
將實(shí)驗(yàn)組ID建模成一個(gè)單獨(dú)的維度筒扒，可使用完全匹配代替LIKE查詢，且可利用到Doris索引绊寻，提高數(shù)據(jù)查詢效率花墩。
將逗號(hào)分隔的實(shí)驗(yàn)組ID直接打平會(huì)引起數(shù)據(jù)量的急劇膨脹，因此需要設(shè)計(jì)合理的方案澄步，同時(shí)兼顧到數(shù)據(jù)量和查詢效率冰蘑。
3.4 進(jìn)組人數(shù)計(jì)算有待改進(jìn)
進(jìn)組人數(shù)查詢是實(shí)驗(yàn)報(bào)告的必查指標(biāo)，因此其查詢速度很大程度上影響實(shí)驗(yàn)報(bào)告的整體查詢效率村缸，當(dāng)前主要問題如下：
當(dāng)進(jìn)組人數(shù)作為獨(dú)立指標(biāo)計(jì)算時(shí)祠肥，使用近似計(jì)算函數(shù)APPROX_COUNT_DISTINCT處理，是通過犧牲準(zhǔn)確性的方式提升查詢效率梯皿。
當(dāng)進(jìn)組人數(shù)作為復(fù)合指標(biāo)的分母進(jìn)行計(jì)算時(shí)仇箱，使用COUNT DISTINCT處理，此方式在大數(shù)據(jù)量計(jì)算場(chǎng)景效率較低东羹。
個(gè)人思考
AB實(shí)驗(yàn)報(bào)告的數(shù)據(jù)結(jié)論會(huì)影響到用戶決策剂桥，犧牲準(zhǔn)確性的方式提升查詢效率是不可取的，特別是廣告這類涉及金錢和業(yè)績的業(yè)務(wù)場(chǎng)合属提，用戶不可能接受近似結(jié)果渊额。
進(jìn)組人數(shù)使用的COUNT DISTINCT計(jì)算需要依賴明細(xì)信息，這也是之前查詢基于明細(xì)數(shù)據(jù)的重要因素。必須為此類場(chǎng)景設(shè)計(jì)新的方案旬迹，使進(jìn)組人數(shù)的計(jì)算在保證數(shù)據(jù)準(zhǔn)確的前提下提高效率火惊。
四、數(shù)據(jù)優(yōu)化方案
基于以上的數(shù)據(jù)現(xiàn)狀奔垦，我們優(yōu)化的核心點(diǎn)是將明細(xì)數(shù)據(jù)預(yù)聚合處理屹耐，通過壓縮數(shù)據(jù)來控制Doris查詢的Scan Rows和Scan Bytes。與此同時(shí)椿猎，使聚合數(shù)據(jù)盡可能多的覆蓋報(bào)告查詢惶岭。從而達(dá)到，減小集群的壓力犯眠，提高查詢效率的目的按灶。
新的數(shù)據(jù)流程如下圖所示：
整個(gè)流程在明細(xì)鏈路的基礎(chǔ)上增加聚合鏈路，Talos數(shù)據(jù)一方面寫入Doris明細(xì)表筐咧，另一方面增量落盤到Iceberg表中鸯旁，Iceberg表同時(shí)用作回溯明細(xì)數(shù)據(jù)以及生成聚合數(shù)據(jù)，我們通過工場(chǎng)Alpha（小米自研數(shù)據(jù)開發(fā)平臺(tái)）的實(shí)時(shí)集成和離線集成保證任務(wù)的穩(wěn)定運(yùn)行和數(shù)據(jù)的一致性量蕊。
4.1 選取高頻使用維度聚合
在生成數(shù)據(jù)聚合的過程中铺罢，聚合程度與請(qǐng)求覆蓋率是負(fù)相關(guān)的。使用的維度越少残炮，能覆蓋的請(qǐng)求就越少韭赘，但數(shù)據(jù)聚合程度越高；使用的維度越多势就，覆蓋的請(qǐng)求也越多泉瞻，但數(shù)據(jù)粒度就越細(xì)，聚合程度也越低苞冯。因此需要在聚合表建模的過程中取得一個(gè)平衡瓦灶。
我們的具體做法是：拉取歷史（近半年）查詢?nèi)罩具M(jìn)行分析，根據(jù)維度字段的使用頻次排序確認(rèn)進(jìn)入聚合表的優(yōu)先級(jí)抱完。在此基礎(chǔ)上得出聚合表的覆蓋率和數(shù)據(jù)量隨著建模字段增加而變化的曲線贼陶，如下圖所示：
其中覆蓋率根據(jù)歷史請(qǐng)求日志代入聚合表計(jì)算得出。
我們的原則是：針對(duì)OLAP查詢巧娱，聚合表的數(shù)據(jù)量應(yīng)盡可能的控制在單日1億條以內(nèi)碉怔，請(qǐng)求覆蓋率盡可能達(dá)到80%以上。
因此不難得出結(jié)論：選擇14個(gè)維度字段對(duì)聚合表建模比較理想禁添，數(shù)據(jù)量能控制到單日8千萬條左右撮胧，且請(qǐng)求覆蓋率約為83%。
4.2 使用物化視圖
在分析報(bào)告歷史查詢?nèi)罩緯r(shí)老翘，我們發(fā)現(xiàn)不同的維度字段查詢頻次有明顯的分層：
Top7維度字段幾乎出現(xiàn)在所有報(bào)告的查詢條件之中芹啥，對(duì)于如此高頻的查詢锻离，值得做進(jìn)一步的投入，使查詢效率盡可能的提升到最佳墓怀。
Doris的物化視圖能夠很好的服務(wù)于此類場(chǎng)景汽纠。
什么是物化視圖？
物化視圖是一種特殊的物理表傀履，其中保存基于基表(base table)部分字段進(jìn)一步上卷聚合的結(jié)果虱朵。
雖然在物理上獨(dú)立存儲(chǔ)，但它是對(duì)用戶透明的钓账。為一張基表配置好物化視圖之后碴犬，不需要為其寫入和查詢做任何額外的工作：
當(dāng)向基表寫入和更新數(shù)據(jù)時(shí)，集群會(huì)自動(dòng)同步到物化視圖梆暮，并通過事務(wù)方式保證數(shù)據(jù)一致性服协。
當(dāng)對(duì)基表進(jìn)行查詢時(shí)，集群會(huì)自動(dòng)判斷是否路由到物化視圖獲取結(jié)果啦粹。當(dāng)查詢字段能被物化視圖完全覆蓋時(shí)偿荷，會(huì)優(yōu)先使用物化視圖。
因此我們的查詢路由如下圖所示：
用戶的查詢請(qǐng)求會(huì)盡可能的路由到聚合表物化視圖卖陵，然后是聚合表基表遭顶，最后才是明細(xì)表张峰。
如此使用多梯度的聚合模型的配合來應(yīng)對(duì)熱度分層的查詢請(qǐng)求泪蔫，使聚合數(shù)據(jù)的效能盡可能的發(fā)揮到最大。
4.3 精確匹配取代LIKE查詢
既然物化視圖這么好用喘批，為什么我們不是基于Doris明細(xì)表配置物化視圖撩荣，而是單獨(dú)開發(fā)聚合表呢？
是因?yàn)槊骷?xì)數(shù)據(jù)中的實(shí)驗(yàn)組ID字段存儲(chǔ)和查詢方式并不合理饶深，聚合數(shù)據(jù)并不適合通過明細(xì)數(shù)據(jù)直接上卷來得到餐曹。
3.3節(jié)已經(jīng)提到，exp_id（實(shí)驗(yàn)組ID）在明細(xì)表中以逗號(hào)分隔的字符串進(jìn)行存儲(chǔ)敌厘，查詢數(shù)據(jù)時(shí)使用LIKE方式匹配台猴。作為AB實(shí)驗(yàn)報(bào)告查詢的必查條件，這種查詢方式無疑是低效的俱两。
我們希望的聚合方式如下圖所示：
我們需要將exp_id字段拆開饱狂，把數(shù)據(jù)打平，使用精確匹配來取代LIKE查詢宪彩，提高查詢的效率休讳。
控制聚合表數(shù)據(jù)量
如果只做拆分打平的處理必然會(huì)導(dǎo)致數(shù)據(jù)量的激增，未必能達(dá)到正向優(yōu)化的效果尿孔，因此我們還需要想辦法來壓縮exp_id打平后的數(shù)據(jù)量：
聚合表選取維度字段建模的時(shí)候俊柔，除了4.1節(jié)提到的筹麸，以字段的使用頻次熱度作為依據(jù)之外，也要關(guān)注字段的取值基數(shù)雏婶，進(jìn)行綜合取舍物赶。如果取值基數(shù)過高的維度字段進(jìn)入聚合表，必然會(huì)對(duì)控制聚合表的數(shù)據(jù)量造成阻礙尚骄。因此块差，我們?cè)诒ＷC聚合表請(qǐng)求覆蓋量的前提下，酌情舍棄部分高基數(shù)（取值有十萬種以上）的維度倔丈。
從業(yè)務(wù)的角度盡可能過濾無效數(shù)據(jù)（比如一個(gè)實(shí)驗(yàn)組的流量為0%或者100%憨闰，業(yè)務(wù)上就沒有對(duì)照的意義，用戶也不會(huì)去查需五，這樣的數(shù)據(jù)就不需要進(jìn)入聚合表）鹉动。
經(jīng)過這一系列步驟，最終聚合表的數(shù)據(jù)量被控制在單日約8000萬條宏邮，并沒有因?yàn)閑xp_id打平而膨脹泽示。
值得一提的是，exp_id字段拆分后蜜氨，除了查詢從LIKE匹配變?yōu)榫_匹配械筛，還額外帶來了兩項(xiàng)收益：
字段從String類型變?yōu)镮nt類型，作為查詢條件時(shí)的比對(duì)效率變高飒炎。
能利用Doris的前綴索引和布隆過濾器等能力埋哟，進(jìn)一步提高查詢效率。
4.4 使用BITMAP去重代替COUNT DISTINCT
要提速實(shí)驗(yàn)報(bào)告查詢郎汪，針對(duì)進(jìn)組人數(shù)（去重用戶數(shù)）的優(yōu)化是非常重要的一個(gè)部分赤赊。作為一個(gè)對(duì)明細(xì)數(shù)據(jù)強(qiáng)依賴的指標(biāo)，我們?nèi)绾卧诓粊G失明細(xì)信息的前提下煞赢，實(shí)現(xiàn)像Sum,Min,Max等指標(biāo)一樣高效的預(yù)聚合計(jì)算呢抛计？
BITMAP去重計(jì)算可以很好的滿足我們的需求捡遍。
什么是BITMAP去重摇庙？
BITMAP去重簡單來說就是建立一種數(shù)據(jù)結(jié)構(gòu)爷肝，表現(xiàn)形式為內(nèi)存中連續(xù)的二進(jìn)制位(bit)撵彻，參與去重計(jì)算的每個(gè)元素（必須為整型）都可以映射成這個(gè)數(shù)據(jù)結(jié)構(gòu)的一個(gè)bit位的下標(biāo)紧卒，如下圖所示：
計(jì)算去重用戶數(shù)時(shí)昆烁，數(shù)據(jù)以bit_or的方式進(jìn)行合并废士，以bit_count的方式得到結(jié)果蚯姆。更重要的是媒抠，如此能實(shí)現(xiàn)去重用戶數(shù)的預(yù)聚合弟断。BITMAP性能優(yōu)勢(shì)主要體現(xiàn)在兩個(gè)方面：
空間緊湊：通過一個(gè)bit位是否置位表示一個(gè)數(shù)字是否存在，能節(jié)省大量空間趴生。以Int32為例阀趴，傳統(tǒng)的存儲(chǔ)空間為4個(gè)字節(jié)昏翰，而在BITMAP計(jì)算時(shí)只需為其分配1/8字節(jié)（1個(gè)bit位）的空間。
計(jì)算高效：BITMAP去重計(jì)算包括對(duì)給定下標(biāo)的bit置位刘急，統(tǒng)計(jì)BITMAP的置位個(gè)數(shù)棚菊，分別為O(1)和O(n)的操作，并且后者可使用CLZ叔汁，CTZ等指令高效計(jì)算统求。此外，BITMAP去重在Doris等MPP執(zhí)行引擎中還可以并行加速處理据块，每個(gè)節(jié)點(diǎn)各自計(jì)算本地子BITMAP码邻，而后進(jìn)行合并。
當(dāng)然另假，以上只是一個(gè)簡化的介紹像屋，這項(xiàng)技術(shù)發(fā)展至今已經(jīng)做了很多優(yōu)化實(shí)現(xiàn)，比如RoaringBitmap边篮，感興趣的同學(xué)可以看看：GitHub - RoaringBitmap/RoaringBitmap
全局字典
要實(shí)現(xiàn)BITMAP去重計(jì)算己莺，必須保證參與計(jì)算的元素為UInt32 / UInt64，而我們的user_id為String類型戈轿，因此我們還需設(shè)計(jì)維護(hù)一個(gè)全局字典凌受，將user_id映射為數(shù)字，從而實(shí)現(xiàn)BITMAP去重計(jì)算思杯。
由于聚合數(shù)據(jù)目前只服務(wù)于離線查詢胜蛉，我們選擇基于Hive表實(shí)現(xiàn)全局字典，其流程如下：
指標(biāo)聚合
生成Doris聚合表時(shí)智蝠，將user_id作為查詢指標(biāo)以BITMAP類型來存儲(chǔ)腾么，其他常規(guī)查詢指標(biāo)則通過COUNT / SUM / MAX / MIN等方式聚合：
如此明細(xì)表和聚合表的指標(biāo)計(jì)算對(duì)應(yīng)關(guān)系如下：
五奈梳、優(yōu)化效果
SQL視角
查詢請(qǐng)求轉(zhuǎn)換成SQL之后杈湾，在明細(xì)表和聚合表的表現(xiàn)對(duì)比如下：
常規(guī)聚合指標(biāo)查詢的性能提升自不必說（速度提升50~60倍）
進(jìn)組人數(shù)查詢性能的提升也非常可觀（速度提升10倍左右）
集群視角
SQL查詢的快進(jìn)快出攘须，使查詢占用的資源能快速釋放漆撞，對(duì)集群壓力的緩解也有正向的作用。
Doris集群BE節(jié)點(diǎn)CPU使用情況和磁盤IO狀況的改變效果顯著：
需要說明的是于宙，集群狀況的改善（包括實(shí)驗(yàn)報(bào)告查詢P95提升）并不全歸功于數(shù)據(jù)預(yù)聚合優(yōu)化工作浮驳，這是各方合力協(xié)作（如產(chǎn)品業(yè)務(wù)形態(tài)調(diào)整，后端查詢引擎排隊(duì)優(yōu)化捞魁，緩存調(diào)優(yōu)至会，Doris集群調(diào)優(yōu)等）的綜合結(jié)果。
六谱俭、小技巧
由于業(yè)務(wù)查詢需求的多樣奉件，在查詢明細(xì)表時(shí)宵蛀，會(huì)出現(xiàn)一個(gè)字段既作為維度又作為指標(biāo)來使用的情況。
如廣告業(yè)務(wù)表中的targetConvNum(目標(biāo)轉(zhuǎn)化個(gè)數(shù))字段县貌，此字段的取值為0和1术陶，查詢場(chǎng)景如下：
--作為維度
selecttargetConvNum,count(distinct user_id)
from analysis.doris_xxx_event?
where olap_date = 20221105
and event_name='CONVERSION'
and exp_id like '%154556%'group bytargetConvNum;
--作為指標(biāo)
select sum(targetConvNum)
from analysis.doris_xxx_event?
where olap_date = 20221105
and event_name='CONVERSION'and exp_id like '%154556%';
如果這個(gè)字段被選取進(jìn)入聚合表，應(yīng)該如何處理呢煤痕？
我們的處理方式是：
在聚合表中把這類字段建模成維度
聚合表中需要一個(gè)計(jì)數(shù)指標(biāo)cnt梧宫，表示聚合表中一條數(shù)據(jù)由明細(xì)表多少條數(shù)據(jù)聚合得到
當(dāng)這類字段被作為指標(biāo)查詢時(shí)，可將其與cnt指標(biāo)配合計(jì)算得到正確結(jié)果
明細(xì)表查詢：
select sum(targetConvNum)
from analysis.doris_xxx_event
where olap_date = 20221105
and event_name='CONVERSION'
and exp_id like '%154556%';
對(duì)應(yīng)的聚合表查詢：
select sum(targetConvNum * cnt)
from agg.doris_xxx_event_agg
where olap_date = 20221105
and event_name = 'CONVERSION'
and exp_id = 154556;
七摆碉、結(jié)束語
經(jīng)過這一系列基于Doris的性能優(yōu)化和測(cè)試塘匣，A/B實(shí)驗(yàn)場(chǎng)景查詢性能的提升超過了我們的預(yù)期。值得一提的是巷帝，Doris較高的穩(wěn)定性和完備的監(jiān)控馆铁、分析工具也為我們的優(yōu)化工作提效不少。希望本次分享可以給有需要的朋友提供一些參考锅睛。
最后埠巨，感謝SelectDB公司和Apache Doris社區(qū)對(duì)我們的鼎力支持。Apache Doris是小米集團(tuán)內(nèi)部應(yīng)用最為廣泛的OLAP引擎之一现拒，目前集團(tuán)內(nèi)部正在推進(jìn)最新的向量化版本升級(jí)工作辣垒。未來一段時(shí)間我們將會(huì)把業(yè)務(wù)優(yōu)化工作和Doris最新的向量化版本進(jìn)行適配，進(jìn)一步助力業(yè)務(wù)的正向發(fā)展印蔬。
