追求卓越

打造極致文化與產(chǎn)品研發(fā)結(jié)合的最佳實(shí)踐

神策已啟動(dòng)「卓越產(chǎn)品計(jì)劃」

產(chǎn)品功能、性能、穩(wěn)定性不斷邁向新臺(tái)階

在上一篇文章《卓越產(chǎn)品計(jì)劃丨神策分析之五重性能優(yōu)化》中,我們了解了神策分析性能優(yōu)化的的五重實(shí)踐,主要包括批量導(dǎo)入性能優(yōu)化、智能聚合表優(yōu)化、數(shù)據(jù)重組織查詢優(yōu)化、查詢?nèi)ブ貎?yōu)化、頁(yè)面首次首屏加載時(shí)間優(yōu)化。今天我們將重點(diǎn)講述數(shù)據(jù)重組織查詢優(yōu)化。

在過去 7 年多的發(fā)展過程中,我們基于 Apache Impala 做了大量的二次開發(fā),極大地優(yōu)化了 Apache Impala 的查詢性能。經(jīng)過不斷地探索與實(shí)踐,我們開發(fā)的一些基于數(shù)據(jù)組織的性能優(yōu)化效果顯著,其中 shuffle merge 是其中重要的一項(xiàng)優(yōu)化。

如下圖所示,神策分析中,Event 數(shù)據(jù)按天和 EventBucket 做分區(qū),即同一天的數(shù)據(jù)置于同一一級(jí)分區(qū)內(nèi),同一天的數(shù)據(jù)再按 EventBucket 分區(qū),這樣可以保證同一事件的數(shù)據(jù)在同一分區(qū)內(nèi),同時(shí)將分區(qū)內(nèi)的文件按{User_id, Time}排序。

神策分析的 10+ 分析模型,大多基于按時(shí)間排序的用戶事件序列進(jìn)行分析,對(duì)該功能的性能優(yōu)化,可以有效提升查詢性能。

一、相關(guān)名詞解讀

在進(jìn)行數(shù)據(jù)重組織查詢優(yōu)化的過程中,經(jīng)常會(huì)提及不少名詞,你都了解嗎?為了幫助各位閱讀,我們提取了常見的 5 個(gè)名詞并做了詳細(xì)解釋。

1、數(shù)據(jù)模型

指神策分析中的事件模型。簡(jiǎn)單來說,事件模型包括事件(Event)和用戶(User)兩個(gè)核心實(shí)體,同時(shí)配合物品(Item)實(shí)體可以做各種維度分析。

2、數(shù)據(jù)組織

指按照一定的方式和規(guī)則來存儲(chǔ)模型數(shù)據(jù),比如數(shù)據(jù)如何做分區(qū)、如何建索引等。

3、數(shù)據(jù)重組織

對(duì)應(yīng)數(shù)據(jù)組織,針對(duì)不合理的數(shù)據(jù)存儲(chǔ),重新組織模型數(shù)據(jù),以提升數(shù)據(jù)的使用效率。

4、EventBucket

每個(gè)事件都有唯一的 Event_id, EventBucket 是對(duì) Event_id 的分桶,在數(shù)據(jù)組織上,會(huì)將 Event 均勻地存放在 EventBucket 中,當(dāng)前 EventBucket 默認(rèn)為 10。

5、SamplingGroup

是對(duì) User_id 的虛擬分桶。在數(shù)據(jù)重組織中, 會(huì)盡可能地將同一 User_id 的數(shù)據(jù)存放在同一 SamplingGroup 下,當(dāng)前 SamplingGroup 默認(rèn)為 64。

二、shuffle merge 原理

通常,exchange 算子后會(huì)接一個(gè) sort 算子將數(shù)據(jù)按{User_id, Time}來排序,此時(shí)的排序?yàn)槿判?未利用底層數(shù)據(jù)的有序性,復(fù)雜度比較高,代價(jià)較大。shuffle merge 則可以充分利用底層數(shù)據(jù)的有序性,將全排序轉(zhuǎn)化為歸并排序,跳過耗時(shí)的 sort 算子,降低排序的時(shí)間復(fù)雜度,加速計(jì)算過程。

其優(yōu)化前后的查詢計(jì)劃分別如下:

最終,基于此優(yōu)化,我們可以實(shí)現(xiàn)如下邏輯的查詢:

三、神策的數(shù)據(jù)重組織查詢優(yōu)化實(shí)踐

在 shuffle merge 的實(shí)際應(yīng)用中,對(duì)于數(shù)據(jù)量較大的客戶,其分區(qū)內(nèi)文件數(shù)量較多,再加上客戶數(shù)據(jù)或存在延遲上報(bào)的情況,會(huì)形成比較多的小文件,進(jìn)一步增加單分區(qū)內(nèi)的文件數(shù)量,造成了以下問題:

● 同一分區(qū)內(nèi)同一 User_id 的數(shù)據(jù)分散在不同的文件里,在 shuffle 時(shí)需要一次打開多個(gè)文件,每個(gè)文件僅讀一部分,帶來大量的隨機(jī) IO。因?yàn)橥?User_id 的數(shù)據(jù)分散在不同的文件里,在多讀取不同的 User_id 序列時(shí),會(huì)存在同一文件多次讀取的情況,IO 會(huì)成倍放大

● 同一 User_id 的數(shù)據(jù)分散在不同的文件里,導(dǎo)致歸并排序時(shí)歸并路數(shù)過多,維護(hù)敗者樹的代價(jià)過高。單個(gè)文件讀取較慢則會(huì)阻塞整個(gè)查詢進(jìn)程

為了減少上述問題帶來的影響,我們需要盡可能地將同一分區(qū)下同一 User_id 的數(shù)據(jù)存放于同一文件中,這樣可以明顯減少歸并路數(shù),進(jìn)而降低隨機(jī) IO,提升數(shù)據(jù)掃描性能。針對(duì)此,我們?cè)O(shè)計(jì)了虛擬分桶 SamplingGroup,它是 User_id 的 hash 值。在數(shù)據(jù)重組織具體應(yīng)用過程中,將同一 SamplingGroup 的數(shù)據(jù)組織到同一文件中。重組織后的 Event 數(shù)據(jù)組織形式如下:

當(dāng)數(shù)據(jù)量較大,且歸并路數(shù)較多時(shí),遇到慢文件的概率大大提升,很容易拖慢整體的 shuffle merge 速度;另外,在數(shù)據(jù)規(guī)整后,shuffle merge 的歸并是按 SamplingGroup 串行執(zhí)行的,未能充分利用 SamplingGroup 以提升并行度。針對(duì)此,我們提出了 merge all 的方案——將歸并從 union 算子下移到 scan 階段,直接桶對(duì)桶(SamplingGroup to SamplingGroup)做歸并,如下圖所示:

該方案能夠直接在計(jì)算節(jié)點(diǎn)上,通過 hdfs api 對(duì)時(shí)間線上的同一 SamplingGroup 數(shù)據(jù)做歸并,大大節(jié)省了網(wǎng)絡(luò)間 shuffle 的數(shù)據(jù)量;更容易將謂詞及列裁剪下推到 scan 階段,以進(jìn)一步減少數(shù)據(jù)掃描量;充分利用 hdfs api 的讀優(yōu)化功能,以提升 scan 效率;在計(jì)算節(jié)點(diǎn)較少或者內(nèi)存不充足的情況下,可主動(dòng)控制歸并數(shù)量,按 SamplingGroup 分批歸并,以降低計(jì)算所需內(nèi)存。

另外,在和 profile 表做聯(lián)合 join 時(shí),可以采用 sort merge bucket join,進(jìn)一步提升 join 效率,在 profile 表較大和內(nèi)存資源有限的情況下發(fā)揮較大作用。

數(shù)據(jù)重組織查詢優(yōu)化后,神策數(shù)據(jù)幫助某客戶實(shí)現(xiàn)了 shuffle merge 場(chǎng)景下 1 倍左右的性能提升,開啟 merge all 后,其漏斗分析場(chǎng)景中的性能提升高達(dá) 40%～150%。

關(guān)注神策數(shù)據(jù)公眾號(hào),了解更多產(chǎn)品技術(shù)解讀。

（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）