2020 年初，疫情讓許多創業公司緊急剎車，這無疑是一次極限壓力測試。它讓所有企業都知道，“黑天鵝”隨時都會來，反脆弱能力很重要。
神策數據的反脆弱能力源於夯實的基本功。在過去的 5 年裡，神策數據服務了 1000 餘家企業。依託底層數據採集、建模、分析、應用的標準化的用戶分析體系，神策數據使得超過 EB 級別的海量數據能夠高效處理，並以秒級的響應速度，服務並驅動千餘家企業的發展。
期間，神策數據定義了公認的行業最高標準：30 分鐘完成私有化部署、單日入庫千億條數據、億級日活實時在線分析……至今，同行業內無一企業能夠企及。在當下的窗口期，神策數據視之為修煉內功的最好時期。復工兩個月後，神策數據又一次震動行業：重構分析引擎，進入 2.0 時代！
- 為什麼要優化分析引擎？
神策分析引擎是神策數據產品矩陣的核心組件之一，它負責神策分析中的所有分析模型的計算執行，此外，它還支撐了神策用戶畫像平臺的標籤人群的計算、神策智能運營系統中的受眾選擇等功能。
一般來說，它也是神策系統中最大的硬件資源（CPU、內存）佔用方。因此，對它的性能進行持續優化一直是我們的工作重點。
神策數據作為一家以私有化部署為主的大數據軟件服務提供商，隨著客戶群體在不斷增加，客戶的數據量級也在快速上升，目前，神策數據平臺所處理的日新增數據量已經高達 1500 億條，而神策數據的分析引擎每天處理的數據條數則在數萬億級別。
性能的持續優化一方面可以顯著的提升產品使用體驗的提升，而從另外角度看，也意味著我們的客戶可以以更低的硬件成本來承載系統的運行。神策分析引擎 2.0 圍繞存儲、查詢執行、查詢調度進行了全面升級與優化，下面詳細介紹。
一、存儲的優化
雖然我們的最終目標是為了優化查詢的性能，但是數據的存儲是查詢的基礎，因此首先我們在存儲方面做了一系列的優化，其中最主要的是我們重構了事件（Event）數據的存儲方案，此外我們也在數據的合併策略等其它方面做了優化。
- 重構事件數據的存儲方案
神策數據平臺中對於事件數據的存儲方案在我們之前的文章中有比較詳細的介紹，簡單的說，我們的方案裡使用了 HDFS + Parquet 來存儲歷史數據、Kudu 存儲實時數據的方式，同時按照日期、事件來進行分區，如下圖所示：
這種存儲方案對於導入和大部分的查詢場景都是比較友好的。但是隨著越來越複雜的應用場景，我們也發現了一些需求在目前的方案下無法得到滿足：
1. 在很多複雜的分析場景下，分析引擎需要先對數據進行按照用戶、時間進行排序的處理，而由於底層的事件數據的有序性很有限，這樣會導致在執行查詢的時候需要對數據進行臨時的排序操作，消耗比較多的資源。
2. 一個典型的應用場景裡會存在多種不同類型的事件，這些事件有的需要永久保留、高頻查詢，而有的可能只需要保留比較短的時間週期，或者在一段時間之後就不再高頻使用。
3. 雖然大部分的事件都是對歷史的記錄，在入庫之後就不會需要進行更新。但是依然有部分類型的事件需要支持比較頻繁且實時的更新操作，比較典型的如電商的訂單事件，訂單的狀態往往是需要可變的，如果能實現直接對狀態的更新會讓很多分析場景更簡單。
為了解決上面幾個問題，我們對事件數據的存儲方案進行了一次重構，完成了以下兩個主要改進點：
1. 進一步強化了對每個分區內數據的預排序。儘可能的保證數據的有序性，這樣可以極大的減少我們在實時分析時需要的重排序時間。
2. 支持對於不同事件分桶的數據使用完全不同的存儲策略（Storage Policy）這些不同的存儲策略可以使用不同的存儲系統、存儲週期、壓縮算法等。
例如對於常規的事件，我們默認使用基於本地 HDFS + Parquet 的存儲方案；而對於低頻使用的事件，我們可以設置定期的歸檔策略，把歷史數據放入 AWS S3 等更廉價的存儲；對於需要支持更新的事件，則採用直接基於 Kudu 的存儲。
可以看到，新的存儲方案不僅直接支撐了後續複雜查詢效率的優化，還使得客戶在海量數據下的存儲成本更加可控，同時，這個全新的設計也為未來更復雜的應用場景預留了足夠的靈活性。
- 存儲相關的其它優化
支持數據的實時導入是神策數據平臺的重要特性，但是在實時導入的場景下，存儲系統裡會不可避免的產生大量的碎片文件，而這些碎片文件則會對查詢的性能有很大負面影響。
在我們之前的設計裡，這些碎片文件的合併是由一個定時調度的任務來執行，這個任務會持續的使用固定的資源來進行碎片數據的合併，這一方式會導致在系統的使用高峰期佔用過多的資源，而在低峰期則可能產生資源空閒。
因此，我們對它的調度策略進行了優化，使用動態的調整與執行並行度的方式，以保證在儘可能用滿系統資源的同時，不影響正常的查詢負載。
此外，我們還優化了主要數據的壓縮算法。在經過大量的真實數據測試之後，我們發現使用 LZ4/ZSTD 的組合方案來替換之前 SNAPPY/GZIP 的方案，可以在壓縮比不變甚至略有提升的同時，降低數倍的 CPU 資源使用。
圖 ZSTD 官方的測試結果（https://github.com/facebook/zstd）
最後，我們還對稀疏寬表的數據的寫入效率進行了優化，這個優化對於那些上千個屬性的寬表的數據寫入效率有數倍的提升。
二、查詢執行的優化
查詢執行，一直是檢驗系統是否健壯的試金石。後端存儲的海量數據，只有查詢引擎足夠強大，才能保證前端風平浪靜地實時查詢，整體平穩運行。正如我們之前的文章所介紹的，神策分析引擎是以 Impala 的執行引擎為核心的系統，因此這部分主要也是對 Impala 的執行計劃以及計算層做的修改。
- 優化基於用戶行為序列的查詢
基於用戶行為序列的查詢是應用場景非常普遍的一類分析需求，神策分析中的漏斗分析、歸因分析、Session 分析等功能都屬於這一類。它們的共同點是需要得到每個用戶的完整、有序的行為序列，然後進行一系列複雜的規則計算。
在我們之前的分析引擎的實現裡，受限於底層的數據存儲結構，這類查詢每次都需要對幾億至上千億條的數據進行重排序操作，雖然我們對這個排序操作本身已經做了比較深度的優化，但是依然是非常耗時的操作。尤其在內存資源不足的情況下，還會啟用基於磁盤外部排序，這樣整體的耗時會更長。
在一般的數據分析系統裡，通常解決這類複雜分析問題的思路是進行預計算，即在預先定義好維度、指標的前提之下，把結果提前計算出來並緩存好。不過預計算的侷限性是非常明顯的，即很難應對靈活多變的需求。
因此，為了更好的支撐這類靈活的分析需求，我們依然確定了從查詢執行本身來優化的整體思路，基於上文所提到的存儲結構優化，在 Impala 執行層更加充分的利用了底層數據的有序性，把全局的內存排序優化為了局部的歸併排序，最終使用更少的內存資源和更短的執行時間完成了查詢的執行。
優化前的執行計劃
優化後的執行計劃
優化前後的執行計劃對比在這個優化點完成之後，部分複雜查詢場景的效率提升了 10 倍，而內存使用則降低到原本的 1/5。
- 查詢引擎的其它優化
除了專門針對用戶行為序列查詢的優化之外，我們還對 Impala 的代碼生成（Codegen）技術做了進一步的擴展，讓它在更多的場景下可以使用。
另外還實現了 Join 表達式下推的優化、針對複雜條件表達式的表達式預求值優化等，這些優化都在不同的使用場景下提升了數倍的查詢效率。
值得一提的是，由於這些優化點中很多並非神策獨有的場景，我們也會把這類通用的優化點都提交給 Impala 社區，其中部分已經合併到最新的官方 Release 版本中。
三、查詢調度的優化
查詢性能上的指標提升固然重要，但是對於神策系統的直接使用者來說，在查詢性能提升同時，也更期望有穩定優異的綜合使用體驗。尤其在數據量巨大、硬件資源有限的客觀場景之下，不同查詢的響應時間也會存在比較大的差異，但是我們依然期望可以通過在查詢調度、產品體驗上的一系列優化，讓每位用戶都能在一個可預期的時間內，及時得到正確的數據分析結果。
- 查詢資源預估
Impala 並不是一個為高併發或者大量用戶共同使用而設計的系統，尤其是在遇到大量高內存消耗查詢的場景下，很容易出現集體失敗的情況。而這種情況之所以出現，最主要的問題就在於查詢引擎往往很難準確預估出一個查詢所需要的資源，尤其是內存資源的大小。
只有有了準確的資源預估，查詢的分級調度、排隊、併發控制等策略才有了執行的前提。不過很遺憾的是，雖然 Impala 最近發佈的幾個新版本也在查詢的資源預估、資源的控制方面做了不少的改進，但是依然不能滿足神策分析這種複雜應用場景的需要。
不過，我們也發現並非一定需要依賴 Impala 才能獲取到查詢預估的信息。神策分析雖然是一個非常靈活的數據分析系統，但是在實際的應用場景下，用戶的查詢模式上依然還是會形成某種規律。
因此，我們完全通過對已經完成的歷史查詢記錄的分析，結合 Impala 的已有功能，構建出了一個查詢資源預估的模型。這樣，我們可以在任何一個查詢執行之前，對它的資源消耗做出相對準確的預估。
有了準確的查詢資源預估，神策數據分析系統不但可以告知用戶每個查詢的大致執行時長，還可以在查詢資源不足的情況下實現對查詢資源的有效調度，從而避免資源擠兌導致查詢連環失敗的現象。
在此基礎上，我們還支持對用戶、角色、項目等不同維度的查詢資源進行精細化控制，以滿足集團型客戶在資源控制方面的複雜需求。
- 異步查詢
大部分場景下，神策分析都可以將分析結果實時返回給用戶，例如在數秒或者不超過 30 秒的時間內返回並展現出結果。但在以下個別場景中，可能需要用戶等待數分鐘或者更久：
1) 查詢的數據量特別大，同時查詢複雜度很高，且無法命中緩存；
2) 查詢的併發人數較多，且無法命中緩存；
3) 查詢返回的結果集特別大，例如查詢一個用戶群的列表，返回的結果集可能有幾百兆或者更大。
考慮到儘可能不阻塞用戶的查詢工作，且避免因誤操作關閉頁面導致無法找回之前的查詢結果，我們在產品中增加了異步查詢功能。
針對上述三個場景，允許用戶將此查詢保留至後臺持續計算。當查詢完成，通過消息通知及時告知用戶查看或下載分析結果。
- 整體性能提升對比
附上做完上面的所有優化之後，我們自己模擬的標準數據集下在一些典型場景下的性能提升對比：
神策分析引擎 2.0 是神策數據各產品線和分析模型演進與迭代的基礎，本文提到的部分功能及優化點已經隨著神策分析新版本的上線覆蓋了數百家客戶，部分底層架構改動較大的優化點則正在小範圍試運行階段，會在未來的兩個月內逐步覆蓋到神策數據的所有客戶。
給客戶帶來價值，而價值源於打磨。在神策數據內部，我們視技術實力為根據地，產品的性能指標一定做到市場最佳，絕不容忍被趕上，哪怕有一丁點苗頭，我們都會全力以赴，希望通過構建更強大產品性能和功能，讓用戶從數據中獲得更深入的數據洞察力。
