小米 A/B 實(shí)驗(yàn)場(chǎng)景基于 Apache Doris 的查詢提速優(yōu)化實(shí)踐

導(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ā)展印蔬。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末勋桶,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子侥猬,更是在濱河造成了極大的恐慌例驹,老刑警劉巖,帶你破解...
    沈念sama閱讀 211,042評(píng)論 6 490
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件退唠,死亡現(xiàn)場(chǎng)離奇詭異鹃锈,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī)瞧预,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 89,996評(píng)論 2 384
  • 文/潘曉璐 我一進(jìn)店門屎债,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人垢油,你說我怎么就攤上這事盆驹。” “怎么了滩愁?”我有些...
    開封第一講書人閱讀 156,674評(píng)論 0 345
  • 文/不壞的土叔 我叫張陵躯喇,是天一觀的道長。 經(jīng)常有香客問我硝枉,道長廉丽,這世上最難降的妖魔是什么秸讹? 我笑而不...
    開封第一講書人閱讀 56,340評(píng)論 1 283
  • 正文 為了忘掉前任,我火速辦了婚禮雅倒,結(jié)果婚禮上璃诀,老公的妹妹穿的比我還像新娘。我一直安慰自己蔑匣,他們只是感情好劣欢,可當(dāng)我...
    茶點(diǎn)故事閱讀 65,404評(píng)論 5 384
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著裁良,像睡著了一般凿将。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上价脾,一...
    開封第一講書人閱讀 49,749評(píng)論 1 289
  • 那天牧抵,我揣著相機(jī)與錄音,去河邊找鬼侨把。 笑死犀变,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的秋柄。 我是一名探鬼主播获枝,決...
    沈念sama閱讀 38,902評(píng)論 3 405
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場(chǎng)噩夢(mèng)啊……” “哼骇笔!你這毒婦竟也來了省店?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 37,662評(píng)論 0 266
  • 序言:老撾萬榮一對(duì)情侶失蹤笨触,失蹤者是張志新(化名)和其女友劉穎懦傍,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體芦劣,經(jīng)...
    沈念sama閱讀 44,110評(píng)論 1 303
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡粗俱,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 36,451評(píng)論 2 325
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了持寄。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片源梭。...
    茶點(diǎn)故事閱讀 38,577評(píng)論 1 340
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡娱俺,死狀恐怖稍味,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情荠卷,我是刑警寧澤模庐,帶...
    沈念sama閱讀 34,258評(píng)論 4 328
  • 正文 年R本政府宣布,位于F島的核電站油宜,受9級(jí)特大地震影響掂碱,放射性物質(zhì)發(fā)生泄漏怜姿。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,848評(píng)論 3 312
  • 文/蒙蒙 一疼燥、第九天 我趴在偏房一處隱蔽的房頂上張望沧卢。 院中可真熱鬧,春花似錦醉者、人聲如沸但狭。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,726評(píng)論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽立磁。三九已至,卻和暖如春剥槐,著一層夾襖步出監(jiān)牢的瞬間唱歧,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,952評(píng)論 1 264
  • 我被黑心中介騙來泰國打工粒竖, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留颅崩,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 46,271評(píng)論 2 360
  • 正文 我出身青樓蕊苗,卻偏偏與公主長得像挨摸,于是被迫代替她去往敵國和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子岁歉,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 43,452評(píng)論 2 348

推薦閱讀更多精彩內(nèi)容