追求卓越

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

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

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

給客戶帶來價(jià)值,價(jià)值源于對(duì)產(chǎn)品的不斷打磨。對(duì)神策分析的性能進(jìn)行持續(xù)優(yōu)化一直是我們的工作重點(diǎn),一方面可以顯著提升產(chǎn)品使用體驗(yàn),另一方面能夠?yàn)榭蛻艚档陀布杀疽猿休d系統(tǒng)運(yùn)行。

本文將結(jié)合具體業(yè)務(wù)場(chǎng)景,詳細(xì)解讀神策分析的五重性能優(yōu)化。

第一,批量導(dǎo)入性能優(yōu)化

神策將數(shù)據(jù)分區(qū)分為三層,第一層是 Project_id,代表用戶項(xiàng)目;第二層是 Day_id,代表日期,第三層是 EventBucket(默認(rèn)為 10 個(gè),可自主配置),代表數(shù)據(jù)對(duì)應(yīng)事件的分桶。

通常情況下,批量導(dǎo)入會(huì)涉及多個(gè)項(xiàng)目、多個(gè)日期的多個(gè)事件,同一個(gè)項(xiàng)目、同一天的同一個(gè)事件桶數(shù)據(jù)應(yīng)該輸出到同一個(gè)文件,在保證文件質(zhì)量的基礎(chǔ)上,導(dǎo)入性能優(yōu)化核心要解決兩個(gè)問題:第一,避免數(shù)據(jù)傾斜;第二,盡可能提高并行度。針對(duì)此,神策從以下四個(gè)維度進(jìn)行了導(dǎo)入性能優(yōu)化:

● 跟三層分區(qū)保持一致,使用三元組(Project_id, Day_id, EventBucket)進(jìn)行數(shù)據(jù) shuffle,以保證一個(gè)分區(qū)下的數(shù)據(jù)文件數(shù)最少

● 在優(yōu)化方案中引入遞增的 slice,解決三元組可能引起的數(shù)據(jù)傾斜問題

● 提出數(shù)據(jù)分布預(yù)估的導(dǎo)入策略,包括后置預(yù)估和前置預(yù)估

● 設(shè)計(jì)流水線提交方案,避免前置預(yù)估計(jì)算帶來的額外開銷

在后續(xù)的文章中我們將詳細(xì)介紹批量導(dǎo)入性能優(yōu)化,此處不做贅述。

第二,智能聚合表優(yōu)化

有別于傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)建設(shè),神策分析在數(shù)據(jù)流處理過程中,基本省去了復(fù)雜的 ETL 流程和傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)的分層建設(shè)思路,用戶可以直接基于事件表 + 用戶表 + Item 表模型進(jìn)行數(shù)據(jù)分析,采用通用分析模型的方式,快速計(jì)算出自己想要的指標(biāo)和結(jié)果。這種設(shè)計(jì)大大降低了用戶的理解和使用成本,但對(duì)于相同或者相似維度的指標(biāo),往往需要基于原始表模型進(jìn)行重復(fù)計(jì)算。

智能聚合表優(yōu)化的基本思路是基于用戶實(shí)際查詢,針對(duì)高頻指標(biāo)和維度,智能構(gòu)建出中間服務(wù)層數(shù)據(jù)模型,在后續(xù)查詢時(shí)基于中間表的方式進(jìn)行計(jì)算,從而避免所有指標(biāo)都要基于原始表所帶來的高計(jì)算成本。當(dāng)然,在實(shí)際執(zhí)行智能聚合表優(yōu)化的過程中,我們也碰到了一系列的技術(shù)挑戰(zhàn)。比如,高頻維度和指標(biāo)的選取需要綜合考慮指標(biāo)的計(jì)算成本、聚合表的壓縮率、聚合表本身的計(jì)算成本等因素。

另外,由于高基數(shù)維度的存在,聚合表往往達(dá)不到很好的壓縮效果,對(duì)此我們結(jié)合實(shí)際業(yè)務(wù)特點(diǎn),有針對(duì)性地采取熱門維度值截取、時(shí)間或者數(shù)據(jù)類型分桶、BitMap 存儲(chǔ)壓縮等方式,將高基數(shù)維度降低為低基數(shù)維度,大大提高了聚合表的壓縮效果。

第三,數(shù)據(jù)重組織查詢優(yōu)化

查詢執(zhí)行,是檢驗(yàn)系統(tǒng)是否健壯的試金石,面對(duì)后端存儲(chǔ)的海量數(shù)據(jù),只有查詢引擎足夠強(qiáng)大,才能保證前端的實(shí)時(shí)查詢平穩(wěn)運(yùn)行。在我們針對(duì)神策分析開發(fā)的一系列基于數(shù)據(jù)組織的性能優(yōu)化中,shuffle merge 是重要的一項(xiàng)。shuffle merge 充分利用了底層數(shù)據(jù)的有序性,變?nèi)判驗(yàn)闅w并排序,跳過耗時(shí)的 sort 算子,極大地降低了排序的時(shí)間復(fù)雜度,加速了計(jì)算進(jìn)程。

在進(jìn)行數(shù)據(jù)重組織查詢優(yōu)化過程中,針對(duì)以下兩個(gè)問題我們可以提出針對(duì)性優(yōu)化方案:

● 對(duì)于數(shù)據(jù)量較大的客戶,其分區(qū)內(nèi)文件數(shù)量較多,再加上客戶數(shù)據(jù)或延遲上報(bào),會(huì)進(jìn)一步增加單分區(qū)內(nèi)的文件數(shù)量。針對(duì)此,我們?cè)O(shè)計(jì)了虛擬分桶采樣組,在數(shù)據(jù)重組織時(shí),盡量將同一采樣組的數(shù)據(jù)組織到同一文件中

● 對(duì)于慢文件拖慢整體進(jìn)度、shuffle merge 的歸并在數(shù)據(jù)規(guī)整后沒有有效利用采樣組以提升并行度這兩個(gè)難題,我們提出了 merge all 的方案,將歸并從 union 算子下移到 scan 階段,直接桶對(duì)桶(采樣組對(duì)采樣組)做歸并

關(guān)于數(shù)據(jù)重組織查詢優(yōu)化的更多細(xì)節(jié)實(shí)踐,將在下一篇文章中詳細(xì)展開。

第四,查詢?nèi)ブ貎?yōu)化

查詢?nèi)ブ厥轻槍?duì)高并發(fā)場(chǎng)景下的查詢優(yōu)化。在實(shí)際業(yè)務(wù)場(chǎng)景中,我們發(fā)現(xiàn)用戶在高峰期發(fā)起的大量查詢中,會(huì)包含部分相同的指標(biāo)內(nèi)容,如果將這種并行查詢?nèi)肯掳l(fā)到查詢引擎中容易導(dǎo)致查詢資源整體緊張。因此,我們引入了針對(duì)查詢的全局去重機(jī)制,對(duì)并發(fā)場(chǎng)景下的重復(fù)查詢進(jìn)行排隊(duì)管理。針對(duì)每一個(gè)查詢類型,生成一個(gè)查詢條件簽名作為全局鎖,相同的查詢條件要先獲得全局鎖,然后才能真正執(zhí)行查詢。當(dāng)相同的全局鎖已經(jīng)被同一個(gè)查詢條件占用時(shí),后續(xù)的查詢會(huì)等待鎖的釋放,當(dāng)?shù)谝粋€(gè)查詢執(zhí)行成功之后會(huì)將查詢結(jié)果寫入到緩存系統(tǒng),后續(xù)即使獲得了全局鎖的查詢也可以直接從緩存系統(tǒng)中獲取到查詢結(jié)果,從而避免了大量重復(fù)查詢?cè)谕粫r(shí)間段的擁擠。

查詢?nèi)ブ貎?yōu)化能夠有效緩解和優(yōu)化高峰場(chǎng)景下的并發(fā)查詢,也在一定程度上提高了系統(tǒng)整體的健壯性。

第五,頁(yè)面首次首屏加載時(shí)間優(yōu)化

優(yōu)化頁(yè)面加載速度、持續(xù)提升用戶體驗(yàn)是我們對(duì)產(chǎn)品性能的另一種優(yōu)化。

首先,通過線上數(shù)據(jù)分析和線下性能診斷,定位性能瓶頸并制定可行的解決方案,沉淀出通用的性能分析平臺(tái),便于我們通過數(shù)據(jù)對(duì)頁(yè)面性能進(jìn)行多維度診斷。通過線上線下對(duì)頁(yè)面性能的分析,我們針對(duì)性能分析階段發(fā)現(xiàn)的問題,如資源體積大導(dǎo)致加載過慢、資源請(qǐng)求過多導(dǎo)致加載阻塞、資源和請(qǐng)求的時(shí)序問題導(dǎo)致首屏渲染的較慢等,采取了多種優(yōu)化手段,包括:

● 同步渲染機(jī)制,在 HTML 初始化的時(shí)候,同步返回首屏所需的異步數(shù)據(jù),避免發(fā)送多次異步請(qǐng)求

● 非首屏的模塊異步加載

● 調(diào)整靜態(tài)資源和異步請(qǐng)求的請(qǐng)求時(shí)序,減少阻塞

● 減少非必要的異步請(qǐng)求

● 建議有條件的客戶開啟 GZIP 壓縮和 HTTP2 協(xié)議等

通過多輪性能優(yōu)化,客戶頁(yè)面首屏?xí)r間平均下降 30%,用戶體驗(yàn)得到了很大提升。

以上性能優(yōu)化實(shí)踐已經(jīng)在部分客戶環(huán)境中得到了效果驗(yàn)證。下圖是某客戶環(huán)境上線相關(guān)優(yōu)化后的概覽平均查詢時(shí)間,已經(jīng)從高峰期的 24s 逐步降低至目前的 12s 左右。

圖 模擬數(shù)據(jù)

雖然性能優(yōu)化已經(jīng)取得了階段性的成果,但是「卓越產(chǎn)品計(jì)劃」仍在繼續(xù),我們也將會(huì)在以下幾個(gè)重點(diǎn)方向持續(xù)投入:在“應(yīng)用化”重構(gòu)和容器化方向,繼續(xù)完善分離集群部署的架構(gòu),完善 SaaS 化多租戶能力、完善多種部署模式下的架構(gòu)統(tǒng)一;在智能聚合表方向,提供更加標(biāo)準(zhǔn)化的聚合表產(chǎn)品能力,更加智能聚合表構(gòu)建方式、基于物化視圖的數(shù)據(jù)一致性中間表和中間表動(dòng)態(tài)管理能力等。此外,我們還會(huì)在產(chǎn)品能力上加強(qiáng)對(duì)于業(yè)務(wù)資源治理能力的支持,提供統(tǒng)一的資源管理中臺(tái)和集中式的業(yè)務(wù)集市中間表管理能力。

關(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)鏈接。 ）