追求卓越
打造極致文化與產(chǎn)品研發(fā)結(jié)合的最佳實踐
神策已啟動「卓越產(chǎn)品計劃」
產(chǎn)品功能、性能、穩(wěn)定性不斷邁向新臺階
給客戶帶來價值,價值源于對產(chǎn)品的不斷打磨。對神策分析的性能進(jìn)行持續(xù)優(yōu)化一直是我們的工作重點,一方面可以顯著提升產(chǎn)品使用體驗,另一方面能夠為客戶降低硬件成本以承載系統(tǒng)運行。
本文將結(jié)合具體業(yè)務(wù)場景,詳細(xì)解讀神策分析的五重性能優(yōu)化。
第一,批量導(dǎo)入性能優(yōu)化
神策將數(shù)據(jù)分區(qū)分為三層,第一層是 Project_id,代表用戶項目;第二層是 Day_id,代表日期,第三層是 EventBucket(默認(rèn)為 10 個,可自主配置),代表數(shù)據(jù)對應(yīng)事件的分桶。
通常情況下,批量導(dǎo)入會涉及多個項目、多個日期的多個事件,同一個項目、同一天的同一個事件桶數(shù)據(jù)應(yīng)該輸出到同一個文件,在保證文件質(zhì)量的基礎(chǔ)上,導(dǎo)入性能優(yōu)化核心要解決兩個問題:第一,避免數(shù)據(jù)傾斜;第二,盡可能提高并行度。針對此,神策從以下四個維度進(jìn)行了導(dǎo)入性能優(yōu)化:
● 跟三層分區(qū)保持一致,使用三元組(Project_id, Day_id, EventBucket)進(jìn)行數(shù)據(jù) shuffle,以保證一個分區(qū)下的數(shù)據(jù)文件數(shù)最少
● 在優(yōu)化方案中引入遞增的 slice,解決三元組可能引起的數(shù)據(jù)傾斜問題
● 提出數(shù)據(jù)分布預(yù)估的導(dǎo)入策略,包括后置預(yù)估和前置預(yù)估
● 設(shè)計流水線提交方案,避免前置預(yù)估計算帶來的額外開銷
在后續(xù)的文章中我們將詳細(xì)介紹批量導(dǎo)入性能優(yōu)化,此處不做贅述。
第二,智能聚合表優(yōu)化
有別于傳統(tǒng)的數(shù)據(jù)倉庫建設(shè),神策分析在數(shù)據(jù)流處理過程中,基本省去了復(fù)雜的 ETL 流程和傳統(tǒng)數(shù)據(jù)倉庫的分層建設(shè)思路,用戶可以直接基于事件表 + 用戶表 + Item 表模型進(jìn)行數(shù)據(jù)分析,采用通用分析模型的方式,快速計算出自己想要的指標(biāo)和結(jié)果。這種設(shè)計大大降低了用戶的理解和使用成本,但對于相同或者相似維度的指標(biāo),往往需要基于原始表模型進(jìn)行重復(fù)計算。
智能聚合表優(yōu)化的基本思路是基于用戶實際查詢,針對高頻指標(biāo)和維度,智能構(gòu)建出中間服務(wù)層數(shù)據(jù)模型,在后續(xù)查詢時基于中間表的方式進(jìn)行計算,從而避免所有指標(biāo)都要基于原始表所帶來的高計算成本。當(dāng)然,在實際執(zhí)行智能聚合表優(yōu)化的過程中,我們也碰到了一系列的技術(shù)挑戰(zhàn)。比如,高頻維度和指標(biāo)的選取需要綜合考慮指標(biāo)的計算成本、聚合表的壓縮率、聚合表本身的計算成本等因素。
另外,由于高基數(shù)維度的存在,聚合表往往達(dá)不到很好的壓縮效果,對此我們結(jié)合實際業(yè)務(wù)特點,有針對性地采取熱門維度值截取、時間或者數(shù)據(jù)類型分桶、BitMap 存儲壓縮等方式,將高基數(shù)維度降低為低基數(shù)維度,大大提高了聚合表的壓縮效果。
第三,數(shù)據(jù)重組織查詢優(yōu)化
查詢執(zhí)行,是檢驗系統(tǒng)是否健壯的試金石,面對后端存儲的海量數(shù)據(jù),只有查詢引擎足夠強(qiáng)大,才能保證前端的實時查詢平穩(wěn)運行。在我們針對神策分析開發(fā)的一系列基于數(shù)據(jù)組織的性能優(yōu)化中,shuffle merge 是重要的一項。shuffle merge 充分利用了底層數(shù)據(jù)的有序性,變?nèi)判驗闅w并排序,跳過耗時的 sort 算子,極大地降低了排序的時間復(fù)雜度,加速了計算進(jìn)程。
在進(jìn)行數(shù)據(jù)重組織查詢優(yōu)化過程中,針對以下兩個問題我們可以提出針對性優(yōu)化方案:
● 對于數(shù)據(jù)量較大的客戶,其分區(qū)內(nèi)文件數(shù)量較多,再加上客戶數(shù)據(jù)或延遲上報,會進(jìn)一步增加單分區(qū)內(nèi)的文件數(shù)量。針對此,我們設(shè)計了虛擬分桶采樣組,在數(shù)據(jù)重組織時,盡量將同一采樣組的數(shù)據(jù)組織到同一文件中
● 對于慢文件拖慢整體進(jìn)度、shuffle merge 的歸并在數(shù)據(jù)規(guī)整后沒有有效利用采樣組以提升并行度這兩個難題,我們提出了 merge all 的方案,將歸并從 union 算子下移到 scan 階段,直接桶對桶(采樣組對采樣組)做歸并
關(guān)于數(shù)據(jù)重組織查詢優(yōu)化的更多細(xì)節(jié)實踐,將在下一篇文章中詳細(xì)展開。
第四,查詢?nèi)ブ貎?yōu)化
查詢?nèi)ブ厥轻槍Ω卟l(fā)場景下的查詢優(yōu)化。在實際業(yè)務(wù)場景中,我們發(fā)現(xiàn)用戶在高峰期發(fā)起的大量查詢中,會包含部分相同的指標(biāo)內(nèi)容,如果將這種并行查詢?nèi)肯掳l(fā)到查詢引擎中容易導(dǎo)致查詢資源整體緊張。因此,我們引入了針對查詢的全局去重機(jī)制,對并發(fā)場景下的重復(fù)查詢進(jìn)行排隊管理。針對每一個查詢類型,生成一個查詢條件簽名作為全局鎖,相同的查詢條件要先獲得全局鎖,然后才能真正執(zhí)行查詢。當(dāng)相同的全局鎖已經(jīng)被同一個查詢條件占用時,后續(xù)的查詢會等待鎖的釋放,當(dāng)?shù)谝粋€查詢執(zhí)行成功之后會將查詢結(jié)果寫入到緩存系統(tǒng),后續(xù)即使獲得了全局鎖的查詢也可以直接從緩存系統(tǒng)中獲取到查詢結(jié)果,從而避免了大量重復(fù)查詢在同一時間段的擁擠。
查詢?nèi)ブ貎?yōu)化能夠有效緩解和優(yōu)化高峰場景下的并發(fā)查詢,也在一定程度上提高了系統(tǒng)整體的健壯性。
第五,頁面首次首屏加載時間優(yōu)化
優(yōu)化頁面加載速度、持續(xù)提升用戶體驗是我們對產(chǎn)品性能的另一種優(yōu)化。
首先,通過線上數(shù)據(jù)分析和線下性能診斷,定位性能瓶頸并制定可行的解決方案,沉淀出通用的性能分析平臺,便于我們通過數(shù)據(jù)對頁面性能進(jìn)行多維度診斷。通過線上線下對頁面性能的分析,我們針對性能分析階段發(fā)現(xiàn)的問題,如資源體積大導(dǎo)致加載過慢、資源請求過多導(dǎo)致加載阻塞、資源和請求的時序問題導(dǎo)致首屏渲染的較慢等,采取了多種優(yōu)化手段,包括:
● 同步渲染機(jī)制,在 HTML 初始化的時候,同步返回首屏所需的異步數(shù)據(jù),避免發(fā)送多次異步請求
● 非首屏的模塊異步加載
● 調(diào)整靜態(tài)資源和異步請求的請求時序,減少阻塞
● 減少非必要的異步請求
● 建議有條件的客戶開啟 GZIP 壓縮和 HTTP2 協(xié)議等
通過多輪性能優(yōu)化,客戶頁面首屏?xí)r間平均下降 30%,用戶體驗得到了很大提升。
以上性能優(yōu)化實踐已經(jīng)在部分客戶環(huán)境中得到了效果驗證。下圖是某客戶環(huán)境上線相關(guān)優(yōu)化后的概覽平均查詢時間,已經(jīng)從高峰期的 24s 逐步降低至目前的 12s 左右。
圖 模擬數(shù)據(jù)
雖然性能優(yōu)化已經(jīng)取得了階段性的成果,但是「卓越產(chǎn)品計劃」仍在繼續(xù),我們也將會在以下幾個重點方向持續(xù)投入:在“應(yīng)用化”重構(gòu)和容器化方向,繼續(xù)完善分離集群部署的架構(gòu),完善 SaaS 化多租戶能力、完善多種部署模式下的架構(gòu)統(tǒng)一;在智能聚合表方向,提供更加標(biāo)準(zhǔn)化的聚合表產(chǎn)品能力,更加智能聚合表構(gòu)建方式、基于物化視圖的數(shù)據(jù)一致性中間表和中間表動態(tài)管理能力等。此外,我們還會在產(chǎn)品能力上加強(qiáng)對于業(yè)務(wù)資源治理能力的支持,提供統(tǒng)一的資源管理中臺和集中式的業(yè)務(wù)集市中間表管理能力。
關(guān)注神策數(shù)據(jù)公眾號,了解更多產(chǎn)品技術(shù)解讀。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
