導(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è)诒WC聚合表請(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ā)展印蔬。