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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

優(yōu)化基于用戶(hù)行為序列的查詢(xún)

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

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

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

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

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

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

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

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

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

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

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

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

查詢(xún)資源預(yù)估

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

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

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

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

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

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

異步查詢(xún)

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

但在以下個(gè)別場(chǎng)景中，可能需要用戶(hù)等待數(shù)分鐘或者更久：

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

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

3)查詢(xún)返回的結(jié)果集特別大，例如查詢(xún)一個(gè)用戶(hù)群的列表，返回的結(jié)果集可能有幾百兆或者更大。

考慮到盡可能不阻塞用戶(hù)的查詢(xún)工作，且避免因誤操作關(guān)閉頁(yè)面導(dǎo)致無(wú)法找回之前的查詢(xún)結(jié)果，我們?cè)诋a(chǎn)品中增加了異步查詢(xún)功能。

針對(duì)上述三個(gè)場(chǎng)景，允許用戶(hù)將此查詢(xún)保留至后臺(tái)持續(xù)計(jì)算。當(dāng)查詢(xún)完成，通過(guò)消息通知及時(shí)告知用戶(hù)查看或下載分析結(jié)果。

整體性能提升對(duì)比

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

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

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

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

songjy