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