2020年初,疫情讓許多創(chuàng)業(yè)公司緊急剎車,這無疑是一次極限壓力測試。它讓所有企業(yè)都知道,“黑天鵝”隨時都會來,反脆弱能力很重要。

神策數(shù)據(jù)的反脆弱能力源于夯實的基本功。在過去的5年里,神策數(shù)據(jù)服務(wù)了1000余家企業(yè)。依托底層數(shù)據(jù)采集、建模、分析、應(yīng)用的標(biāo)準(zhǔn)化的用戶分析體系,神策數(shù)據(jù)使得超過EB級別的海量數(shù)據(jù)能夠高效處理,并以秒級的響應(yīng)速度,服務(wù)并驅(qū)動千余家企業(yè)的發(fā)展。

期間,神策數(shù)據(jù)定義了公認(rèn)的行業(yè)最高標(biāo)準(zhǔn):30分鐘完成私有化部署、單日入庫千億條數(shù)據(jù)、億級日活實時在線分析……至今,同行業(yè)內(nèi)無一企業(yè)能夠企及。

在當(dāng)下的窗口期,神策數(shù)據(jù)視之為修煉內(nèi)功的最好時期。復(fù)工兩個月后,神策數(shù)據(jù)又一次震動行業(yè):重構(gòu)分析引擎,進(jìn)入2.0時代!

為什么要優(yōu)化分析引擎?

神策分析引擎是神策數(shù)據(jù)產(chǎn)品矩陣的核心組件之一,它負(fù)責(zé)神策分析中的所有分析模型的計算執(zhí)行,此外,它還支撐了神策用戶畫像平臺的標(biāo)簽人群的計算、神策智能運(yùn)營系統(tǒng)中的受眾選擇等功能。

一般來說,它也是神策系統(tǒng)中最大的硬件資源(CPU、內(nèi)存)占用方。因此,對它的性能進(jìn)行持續(xù)優(yōu)化一直是我們的工作重點。

神策數(shù)據(jù)作為一家以私有化部署為主的大數(shù)據(jù)軟件服務(wù)提供商,隨著客戶群體在不斷增加,客戶的數(shù)據(jù)量級也在快速上升,目前,神策數(shù)據(jù)平臺所處理的日新增數(shù)據(jù)量已經(jīng)高達(dá)1500億條,而神策數(shù)據(jù)的分析引擎每天處理的數(shù)據(jù)條數(shù)則在數(shù)萬億級別。

性能的持續(xù)優(yōu)化一方面可以顯著的提升產(chǎn)品使用體驗的提升,而從另外角度看,也意味著我們的客戶可以以更低的硬件成本來承載系統(tǒng)的運(yùn)行。

神策分析引擎2.0圍繞存儲、查詢執(zhí)行、查詢調(diào)度進(jìn)行了全面升級與優(yōu)化,下面詳細(xì)介紹。

一、存儲的優(yōu)化

雖然我們的最終目標(biāo)是為了優(yōu)化查詢的性能,但是數(shù)據(jù)的存儲是查詢的基礎(chǔ),因此首先我們在存儲方面做了一系列的優(yōu)化,其中最主要的是我們重構(gòu)了事件(Event)數(shù)據(jù)的存儲方案,此外我們也在數(shù)據(jù)的合并策略等其它方面做了優(yōu)化。

重構(gòu)事件數(shù)據(jù)的存儲方案

神策數(shù)據(jù)平臺中對于事件數(shù)據(jù)的存儲方案在我們之前的文章中有比較詳細(xì)的介紹,簡單的說,我們的方案里使用了HDFS+Parquet來存儲歷史數(shù)據(jù)、Kudu存儲實時數(shù)據(jù)的方式,同時按照日期、事件來進(jìn)行分區(qū),如下圖所示:

這種存儲方案對于導(dǎo)入和大部分的查詢場景都是比較友好的。但是隨著越來越復(fù)雜的應(yīng)用場景,我們也發(fā)現(xiàn)了一些需求在目前的方案下無法得到滿足:

1.在很多復(fù)雜的分析場景下,分析引擎需要先對數(shù)據(jù)進(jìn)行按照用戶、時間進(jìn)行排序的處理,而由于底層的事件數(shù)據(jù)的有序性很有限,這樣會導(dǎo)致在執(zhí)行查詢的時候需要對數(shù)據(jù)進(jìn)行臨時的排序操作,消耗比較多的資源。

2.一個典型的應(yīng)用場景里會存在多種不同類型的事件,這些事件有的需要永久保留、高頻查詢,而有的可能只需要保留比較短的時間周期,或者在一段時間之后就不再高頻使用。

3.雖然大部分的事件都是對歷史的記錄,在入庫之后就不會需要進(jìn)行更新。但是依然有部分類型的事件需要支持比較頻繁且實時的更新操作,比較典型的如電商的訂單事件,訂單的狀態(tài)往往是需要可變的,如果能實現(xiàn)直接對狀態(tài)的更新會讓很多分析場景更簡單。

為了解決上面幾個問題,我們對事件數(shù)據(jù)的存儲方案進(jìn)行了一次重構(gòu),完成了以下兩個主要改進(jìn)點:

1.進(jìn)一步強(qiáng)化了對每個分區(qū)內(nèi)數(shù)據(jù)的預(yù)排序。盡可能的保證數(shù)據(jù)的有序性,這樣可以極大的減少我們在實時分析時需要的重排序時間。

2.支持對于不同事件分桶的數(shù)據(jù)使用完全不同的存儲策略(Storage Policy)這些不同的存儲策略可以使用不同的存儲系統(tǒng)、存儲周期、壓縮算法等。

例如對于常規(guī)的事件,我們默認(rèn)使用基于本地HDFS+Parquet的存儲方案;而對于低頻使用的事件,我們可以設(shè)置定期的歸檔策略,把歷史數(shù)據(jù)放入AWS S3等更廉價的存儲;對于需要支持更新的事件,則采用直接基于Kudu的存儲。

可以看到,新的存儲方案不僅直接支撐了后續(xù)復(fù)雜查詢效率的優(yōu)化,還使得客戶在海量數(shù)據(jù)下的存儲成本更加可控,同時,這個全新的設(shè)計也為未來更復(fù)雜的應(yīng)用場景預(yù)留了足夠的靈活性。

存儲相關(guān)的其它優(yōu)化

支持?jǐn)?shù)據(jù)的實時導(dǎo)入是神策數(shù)據(jù)平臺的重要特性,但是在實時導(dǎo)入的場景下,存儲系統(tǒng)里會不可避免的產(chǎn)生大量的碎片文件,而這些碎片文件則會對查詢的性能有很大負(fù)面影響。

在我們之前的設(shè)計里,這些碎片文件的合并是由一個定時調(diào)度的任務(wù)來執(zhí)行,這個任務(wù)會持續(xù)的使用固定的資源來進(jìn)行碎片數(shù)據(jù)的合并,這一方式會導(dǎo)致在系統(tǒng)的使用高峰期占用過多的資源,而在低峰期則可能產(chǎn)生資源空閑。

因此,我們對它的調(diào)度策略進(jìn)行了優(yōu)化,使用動態(tài)的調(diào)整與執(zhí)行并行度的方式,以保證在盡可能用滿系統(tǒng)資源的同時,不影響正常的查詢負(fù)載。

此外,我們還優(yōu)化了主要數(shù)據(jù)的壓縮算法。在經(jīng)過大量的真實數(shù)據(jù)測試之后,我們發(fā)現(xiàn)使用LZ4/ZSTD的組合方案來替換之前SNAPPY/GZIP的方案,可以在壓縮比不變甚至略有提升的同時,降低數(shù)倍的CPU資源使用。

ZSTD官方的測試結(jié)果(https://github.com/facebook/zstd)

最后,我們還對稀疏寬表的數(shù)據(jù)的寫入效率進(jìn)行了優(yōu)化,這個優(yōu)化對于那些上千個屬性的寬表的數(shù)據(jù)寫入效率有數(shù)倍的提升。

二、查詢執(zhí)行的優(yōu)化

查詢執(zhí)行,一直是檢驗系統(tǒng)是否健壯的試金石。后端存儲的海量數(shù)據(jù),只有查詢引擎足夠強(qiáng)大,才能保證前端風(fēng)平浪靜地實時查詢,整體平穩(wěn)運(yùn)行。正如我們之前的文章所介紹的,神策分析引擎是以Impala的執(zhí)行引擎為核心的系統(tǒng)(詳情內(nèi)容請參考鏈接:付力力:基于Impala構(gòu)建實時用戶行為分析引擎),因此這部分主要也是對Impala的執(zhí)行計劃以及計算層做的修改。

優(yōu)化基于用戶行為序列的查詢

基于用戶行為序列的查詢是應(yīng)用場景非常普遍的一類分析需求,神策分析中的漏斗分析、歸因分析、Session分析等功能都屬于這一類。它們的共同點是需要得到每個用戶的完整、有序的行為序列,然后進(jìn)行一系列復(fù)雜的規(guī)則計算。

在我們之前的分析引擎的實現(xiàn)里,受限于底層的數(shù)據(jù)存儲結(jié)構(gòu),這類查詢每次都需要對幾億至上千億條的數(shù)據(jù)進(jìn)行重排序操作,雖然我們對這個排序操作本身已經(jīng)做了比較深度的優(yōu)化,但是依然是非常耗時的操作。尤其在內(nèi)存資源不足的情況下,還會啟用基于磁盤外部排序,這樣整體的耗時會更長。

在一般的數(shù)據(jù)分析系統(tǒng)里,通常解決這類復(fù)雜分析問題的思路是進(jìn)行預(yù)計算,即在預(yù)先定義好維度、指標(biāo)的前提之下,把結(jié)果提前計算出來并緩存好。不過預(yù)計算的局限性是非常明顯的,即很難應(yīng)對靈活多變的需求。

因此,為了更好的支撐這類靈活的分析需求,我們依然確定了從查詢執(zhí)行本身來優(yōu)化的整體思路,基于上文所提到的存儲結(jié)構(gòu)優(yōu)化,在Impala執(zhí)行層更加充分的利用了底層數(shù)據(jù)的有序性,把全局的內(nèi)存排序優(yōu)化為了局部的歸并排序,最終使用更少的內(nèi)存資源和更短的執(zhí)行時間完成了查詢的執(zhí)行。

優(yōu)化前后的執(zhí)行計劃對比

在這個優(yōu)化點完成之后,部分復(fù)雜查詢場景的效率提升了10倍,而內(nèi)存使用則降低到原本的1/5。

查詢引擎的其它優(yōu)化

除了專門針對用戶行為序列查詢的優(yōu)化之外,我們還對Impala的代碼生成(Codegen)技術(shù)做了進(jìn)一步的擴(kuò)展,讓它在更多的場景下可以使用。

另外還實現(xiàn)了Join表達(dá)式下推的優(yōu)化、針對復(fù)雜條件表達(dá)式的表達(dá)式預(yù)求值優(yōu)化等,這些優(yōu)化都在不同的使用場景下提升了數(shù)倍的查詢效率。

值得一提的是,由于這些優(yōu)化點中很多并非神策獨有的場景,我們也會把這類通用的優(yōu)化點都提交給Impala社區(qū),其中部分已經(jīng)合并到最新的官方Release版本中。

三、查詢調(diào)度的優(yōu)化

查詢性能上的指標(biāo)提升固然重要,但是對于神策系統(tǒng)的直接使用者來說,在查詢性能提升同時,也更期望有穩(wěn)定優(yōu)異的綜合使用體驗。尤其在數(shù)據(jù)量巨大、硬件資源有限的客觀場景之下,不同查詢的響應(yīng)時間也會存在比較大的差異,但是我們依然期望可以通過在查詢調(diào)度、產(chǎn)品體驗上的一系列優(yōu)化,讓每位用戶都能在一個可預(yù)期的時間內(nèi),及時得到正確的數(shù)據(jù)分析結(jié)果。

查詢資源預(yù)估

Impala并不是一個為高并發(fā)或者大量用戶共同使用而設(shè)計的系統(tǒng),尤其是在遇到大量高內(nèi)存消耗查詢的場景下,很容易出現(xiàn)集體失敗的情況。而這種情況之所以出現(xiàn),最主要的問題就在于查詢引擎往往很難準(zhǔn)確預(yù)估出一個查詢所需要的資源,尤其是內(nèi)存資源的大小。

只有有了準(zhǔn)確的資源預(yù)估,查詢的分級調(diào)度、排隊、并發(fā)控制等策略才有了執(zhí)行的前提。不過很遺憾的是,雖然Impala最近發(fā)布的幾個新版本也在查詢的資源預(yù)估、資源的控制方面做了不少的改進(jìn),但是依然不能滿足神策分析這種復(fù)雜應(yīng)用場景的需要。

不過,我們也發(fā)現(xiàn)并非一定需要依賴Impala才能獲取到查詢預(yù)估的信息。神策分析雖然是一個非常靈活的數(shù)據(jù)分析系統(tǒng),但是在實際的應(yīng)用場景下,用戶的查詢模式上依然還是會形成某種規(guī)律。

因此,我們完全通過對已經(jīng)完成的歷史查詢記錄的分析,結(jié)合Impala的已有功能,構(gòu)建出了一個查詢資源預(yù)估的模型。這樣,我們可以在任何一個查詢執(zhí)行之前,對它的資源消耗做出相對準(zhǔn)確的預(yù)估。

有了準(zhǔn)確的查詢資源預(yù)估,神策數(shù)據(jù)分析系統(tǒng)不但可以告知用戶每個查詢的大致執(zhí)行時長,還可以在查詢資源不足的情況下實現(xiàn)對查詢資源的有效調(diào)度,從而避免資源擠兌導(dǎo)致查詢連環(huán)失敗的現(xiàn)象。

在此基礎(chǔ)上,我們還支持對用戶、角色、項目等不同維度的查詢資源進(jìn)行精細(xì)化控制,以滿足集團(tuán)型客戶在資源控制方面的復(fù)雜需求。

異步查詢

大部分場景下,神策分析都可以將分析結(jié)果實時返回給用戶,例如在數(shù)秒或者不超過30秒的時間內(nèi)返回并展現(xiàn)出結(jié)果。

但在以下個別場景中,可能需要用戶等待數(shù)分鐘或者更久:

1)查詢的數(shù)據(jù)量特別大,同時查詢復(fù)雜度很高,且無法命中緩存;

2)查詢的并發(fā)人數(shù)較多,且無法命中緩存;

3)查詢返回的結(jié)果集特別大,例如查詢一個用戶群的列表,返回的結(jié)果集可能有幾百兆或者更大。

考慮到盡可能不阻塞用戶的查詢工作,且避免因誤操作關(guān)閉頁面導(dǎo)致無法找回之前的查詢結(jié)果,我們在產(chǎn)品中增加了異步查詢功能。

針對上述三個場景,允許用戶將此查詢保留至后臺持續(xù)計算。當(dāng)查詢完成,通過消息通知及時告知用戶查看或下載分析結(jié)果。

整體性能提升對比

附上做完上面的所有優(yōu)化之后,我們自己模擬的標(biāo)準(zhǔn)數(shù)據(jù)集下在一些典型場景下的性能提升對比:

神策分析引擎2.0是神策數(shù)據(jù)各產(chǎn)品線和分析模型演進(jìn)與迭代的基礎(chǔ),本文提到的部分功能及優(yōu)化點已經(jīng)隨著神策分析新版本的上線覆蓋了數(shù)百家客戶,部分底層架構(gòu)改動較大的優(yōu)化點則正在小范圍試運(yùn)行階段,會在未來的兩個月內(nèi)逐步覆蓋到神策數(shù)據(jù)的所有客戶。

給客戶帶來價值,而價值源于打磨。在神策數(shù)據(jù)內(nèi)部,神策數(shù)據(jù)視技術(shù)實力為根據(jù)地,產(chǎn)品的性能指標(biāo)一定做到市場最佳,絕不容忍被趕上,哪怕有一丁點苗頭,神策數(shù)據(jù)都會全力以赴,希望通過構(gòu)建更強(qiáng)大產(chǎn)品性能和功能,讓用戶從數(shù)據(jù)中獲得更深入的數(shù)據(jù)洞察力。

了解更多分析引擎的詳細(xì)內(nèi)容,可關(guān)注神策數(shù)據(jù)公眾號,或在神策數(shù)據(jù)官網(wǎng)進(jìn)行demo體驗。

分享到

songjy

相關(guān)推薦