PB 級數(shù)據(jù)即席查詢基于 Flink 的實踐

首先做一個簡單的個人以及團(tuán)隊介紹。我們來自 360 政企安全集團(tuán)，目前主要從事 360 安全大腦的 “威脅狩獵“ 項目的開發(fā)工作。我們團(tuán)隊接觸 Flink 的時間比較早，在此期間，我們基于 Flink 開發(fā)出了多款產(chǎn)品，并在 2017 年和 2019 年參加了于柏林舉辦的 Flink Forward 大會，分別介紹了我們的 “UEBA” 以及 “AutoML” 兩款產(chǎn)品。

本次分享主要分為兩塊內(nèi)容：

• 第一部分 “Threat Hunting 平臺的架構(gòu)與設(shè)計” 將由蘇軍來為大家分享；

  
  

• 第二部分 “以降低 IO 為目標(biāo)的優(yōu)化與探索” 將由劉佳來為大家分享。

一、Threat Hunting 平臺的架構(gòu)與設(shè)計 

第一部分內(nèi)容大致分為三個部分，分別是：

• 平臺的演進(jìn)

  
  

• 架構(gòu)設(shè)計

  
  

• 深入探索索引結(jié)構(gòu)

1. 平臺的演進(jìn)

我們認(rèn)為所有技術(shù)的演化和革新都需要具體的商業(yè)問題來驅(qū)動，以下是我們團(tuán)隊近幾年基于 Flink 開發(fā)的幾款產(chǎn)品：

• 2017 年我們基于 Flink DataStream 開發(fā)了用戶行為分析系統(tǒng) UEBA，它是通過接入企業(yè) IT 拓?fù)涞母黝愋袨閿?shù)據(jù)，比如身份認(rèn)證數(shù)據(jù)、應(yīng)用系統(tǒng)訪問數(shù)據(jù)、終端安全數(shù)據(jù)、網(wǎng)絡(luò)流量解析數(shù)據(jù)等等，以用戶 / 資產(chǎn)為核心來進(jìn)行威脅行為的實時檢測，最后構(gòu)建出用戶威脅等級和畫像的系統(tǒng)；

  
  

• 2018 年基于 UEBA 的實施經(jīng)驗，我們發(fā)現(xiàn)安全分析人員往往需要一種手段來獲取安全事件對應(yīng)的原始日志，去進(jìn)一步確認(rèn)安全威脅的源頭和解決方式。于是我們基于 Spark 開發(fā)了 HQL 來解決在離線模式下的數(shù)據(jù)檢索問題，其中 HQL 可以認(rèn)為是表達(dá)能力比 SQL 更加豐富的查詢語言，大致可以看作是在 SQL 能力的基礎(chǔ)上增加了算法類算；

  
  

• 2019 年隨著離線 HQL 在客戶那邊的使用，我們發(fā)現(xiàn)其本身就能夠快速定義安全規(guī)則，構(gòu)建威脅模型，如果在離線模式下寫完語句后直接發(fā)布成在線任務(wù)，會大大縮短開發(fā)周期，加上 Flink SQL 能力相對完善，于是我們基于 Flink SQL + CEP 來升級了 HQL 的能力，產(chǎn)生了 HQL RealTime 版本；

  
  

• 2020 年隨著客戶數(shù)據(jù)量的增大，很多已經(jīng)達(dá)到了 PB 級，過往的解決方案導(dǎo)致離線的數(shù)據(jù)檢索性能遠(yuǎn)遠(yuǎn)低于預(yù)期，安全分析人員習(xí)慣使用 like 和全文檢索等模糊匹配操作，造成查詢延時非常大。于是從今年開始，我們著重優(yōu)化 HQL 的離線檢索能力，并推出了全新的 Threat Hunting 平臺。

通過調(diào)查發(fā)現(xiàn)，擁有 PB 級數(shù)據(jù)規(guī)模的客戶往往有以下幾個商業(yè)需求：

• 第一是低成本的云原生架構(gòu)。我們知道目前大部分的大數(shù)據(jù)架構(gòu)都是基于 hadoop 的，其特點(diǎn)是數(shù)據(jù)就在計算節(jié)點(diǎn)上，能夠減少大量網(wǎng)絡(luò)開銷，加速計算性能。但是整個集群為了做到資源均衡，往往需要相同的資源配置，且為了能夠存儲盡量多的數(shù)據(jù)，集群規(guī)模會很大, 所以這類架構(gòu)在前期需要投入大量硬件成本。
  而存算分離和彈性計算則能夠解決這一問題，因為磁盤的價格是遠(yuǎn)低于內(nèi)存和 CPU 的，所以用廉價的磁盤存儲搭配低配 CPU 和內(nèi)存來存儲數(shù)據(jù)，用少量高配機(jī)器來做計算，可以在很大程度上降低成本。

  
  

• 第二是低延時的查詢響應(yīng)。安全分析人員在做威脅檢測時，大部分時間是即席查詢，即通過過濾、join 來做數(shù)據(jù)的檢索和關(guān)聯(lián)。為了能夠盡快的獲取查詢結(jié)果，對應(yīng)的技術(shù)方案是：列存/索引/緩存。




• 列存不用多說了，是大數(shù)據(jù)領(lǐng)域常見的存儲方案；
• 在列存的基礎(chǔ)上，高效的索引方案能夠大量降低 io，提高查詢性能；
• 而存算分析帶來的網(wǎng)絡(luò)延時可以由分布式緩存來彌補(bǔ)。

  
  

• 第三是需要豐富的查詢能力，其中包括單行的 fields/filter/udf 等，多行的聚合 /join，甚至算法類的分析能力，這部分我們主要依賴于自己開發(fā)的分析語言 HQL 來提供。

2. 架構(gòu)設(shè)計

首先，數(shù)據(jù)是來自于已經(jīng)存儲在 ES 中的歷史數(shù)據(jù)和 kafka 里的實時數(shù)據(jù)，其中 ES 里的歷史數(shù)據(jù)我們通過自己開發(fā)的同步工具來同步，kafka 里的實時數(shù)據(jù)我們則通過 Streaming File Sink 寫 orc 文件到存儲集群。在數(shù)據(jù)同步的同時，我們會將這批數(shù)據(jù)的索引信息更新到數(shù)據(jù)庫中。

安全分析人員會從前端頁面通過寫交互式分析語言 HQL 發(fā)起數(shù)據(jù)檢索的請求，此時請求會進(jìn)入調(diào)度系統(tǒng)，一旦開始執(zhí)行作業(yè)，首先會將分析語句解析成算子列表，算子緩存算法會判斷該次查詢是否可以命中緩存系統(tǒng)中已有的緩存數(shù)據(jù)。

• 如果分析語句的輸入是已經(jīng)算好并且 cache 好了的中間結(jié)果，那么直接讀取緩存來繼續(xù)計算；

  
  

• 如果不能命中，證明我們必須從 orc 文件開始重新計算。

我們會先提取出查詢語言的過濾條件或者是 Join 條件來做謂詞下推，進(jìn)入索引數(shù)據(jù)庫中獲得目前符合該查詢的文件列表，隨后將文件列表交給計算引擎來進(jìn)行計算。計算引擎我們采用雙引擎模式，其中復(fù)雜度高的語句我們通過 Flink 引擎來完成，其它較為簡單的任務(wù)我們交給平臺內(nèi)部的 “蜂鳥引擎”?！胺澍B引擎” 基于 Apache arrow 做向量化執(zhí)行，加上 LLVM 編譯，查詢延遲會非常小。

由于整個系統(tǒng)的存算分離，為了加速數(shù)據(jù)讀取，我們在計算集群節(jié)點(diǎn)上增加了 alluxio 來提供數(shù)據(jù)緩存服務(wù)，其中不僅緩存 remote cluster 上的數(shù)據(jù)，同時會緩存部分歷史作業(yè)結(jié)果，通過算子緩存的算法來加速下次計算任務(wù)。

這里還需要強(qiáng)調(diào)兩點(diǎn)：

• 第一點(diǎn)是索引數(shù)據(jù)庫會返回一批符合該條件的文件列表，如果文件列表非常大的話，當(dāng)前的 Flink 版本在構(gòu)建 job graph 時，在獲取 Filelist Statistics 邏輯這里在遍歷大量文件的時候，會造成長時間無法構(gòu)建出 job graph 的問題。目前我們對其進(jìn)行了修復(fù)，后期會貢獻(xiàn)給社區(qū)。

  
  

• 第二點(diǎn)是數(shù)據(jù)緩存那一塊，我們的 HQL 之前是通過 Spark 來實現(xiàn)的。用過 Spark 的人可能知道，Spark 會把一個 table 來做 cache 或 persist。我們在遷移到 Flink 的時候，也沿用了這個算子。Flink 這邊我們自己實現(xiàn)了一套，就是用戶在 cache table 時,我們會把它注冊成一個全新的 table source，后面在重新讀取的時候只會用這個新的 table source 來打通整個流程。

3. 深入探索索引結(jié)構(gòu)

數(shù)據(jù)庫為了加速數(shù)據(jù)檢索，我們往往會事先為數(shù)據(jù)創(chuàng)建索引，再在掃描數(shù)據(jù)之前通過索引定位到數(shù)據(jù)的起始位置，從而加速數(shù)據(jù)檢索。而傳統(tǒng)數(shù)據(jù)庫常見的是行索引，通過一個或若干字段創(chuàng)建索引，索引結(jié)果以樹形結(jié)構(gòu)存儲，此類索引能夠精確到行級別，索引效率最高。

某些大數(shù)據(jù)項目也支持了行索引，而它所帶來的弊端就是大量的索引數(shù)據(jù)會造成寫入和檢索的延時。而我們平臺處理的是機(jī)器數(shù)據(jù)，例如終端/網(wǎng)絡(luò)這類數(shù)據(jù)，它的特點(diǎn)是重復(fù)度非常高，而安全分析的結(jié)果往往非常少，極少數(shù)的威脅行為會隱藏在海量數(shù)據(jù)里，占比往往會是 1/1000 甚至更少。

所以我們選擇性價比更高的塊索引方案，已經(jīng)能夠支撐目前的應(yīng)用場景。目前通過客戶數(shù)據(jù)來看, 索引能夠為 85% 的語句提供 90% 以上的裁剪率，基本滿足延時要求。

某些大數(shù)據(jù)平臺是將索引數(shù)據(jù)以文件的形式存儲在磁盤上，外加一些 cache 機(jī)制來加速數(shù)據(jù)訪問，而我們是將索引數(shù)據(jù)直接存在了數(shù)據(jù)庫中。主要有以下兩個方面的考慮：

• 第一是 transaction。我們知道列存文件往往是無法 update 的，而我們在定期優(yōu)化文件分布時會做 Merge File 操作，為了保證查詢一致性，需要數(shù)據(jù)庫提供 transaction 能力。

  
  

• 第二是性能。數(shù)據(jù)庫擁有較強(qiáng)的讀寫和檢索能力，甚至可以將謂詞下推到數(shù)據(jù)庫來完成，數(shù)據(jù)庫的高壓縮比也能進(jìn)一步節(jié)省存儲。

上圖為塊索引的設(shè)計。在我們的索引數(shù)據(jù)庫中，我們把這些數(shù)據(jù)分為不同類別數(shù)據(jù)源，比如終端數(shù)據(jù)為一類數(shù)據(jù)源，網(wǎng)絡(luò)數(shù)據(jù)為一類數(shù)據(jù)源，我們分類數(shù)據(jù)源的邏輯是他們是否擁有統(tǒng)一的 Schema。就單個數(shù)據(jù)源來說，它以日期作為 Partition，Partition 內(nèi)部是大量的 ORC 小文件，具體到索引結(jié)構(gòu)，我們會為每一個字段建 min/max 索引，基數(shù)小于 0.001 的字段我們建 Bloom 索引。

上文提到過，安全人員比較喜歡用 like 和全文檢索。對于 like 這一塊，我們也做了一些優(yōu)化。全文檢索方面，我們會為數(shù)據(jù)來做分詞，來構(gòu)建倒排索引，同時也會對于單個分詞過后的單個 item 來做文件分布層面的位圖索引。

上圖是一個索引大小的大致的比例假設(shè)，JSON 格式的原始日志大有 50PB，轉(zhuǎn)化成 ORC 大概是 1PB 左右。我們的 Index 數(shù)據(jù)是 508GB， 其中 8GB 為 Min/Max 索引，500GB 為 Bloom。加上上文提到的位圖以及倒排，這個索引數(shù)據(jù)的占比會進(jìn)一步加大?；诖?，我們采用的是分布式的索引方案。

我們知道日志是在不斷的進(jìn)行變化的，對于有的數(shù)據(jù)員來說，他有時會增加字段或者減少字段，甚至有時字段類型也會發(fā)生變化。

那么我們采取這種 Merge Schema 模式方案，在文件增量寫入的過程中，也就是在更新這批數(shù)據(jù)的索引信息的同時來做 Schema Merge 的操作。如圖所示，在 block123 中，文件 3 是最后一個寫入的。隨著文件的不斷寫入，會組成一個全新的 Merge Schema。可以看到 B 字段和 C 字段其實是歷史字段，而 A_V 字段是 A 字段的歷史版本字段，我們用這種方式來盡量多的讓客戶看到比較全的數(shù)據(jù)。最后基于自己開發(fā)的 Input format 加 Merge Schema 來構(gòu)建一個新的 table source ，從而打通整個流程。

二、以降低 IO 為目標(biāo)的優(yōu)化與探索 

上文介紹了為什么要選擇塊索引，那么接下來將具體介紹如何使用塊索引。塊索引的核心可以落在兩個字上：“裁剪”。裁剪就是在查詢語句被真正執(zhí)行前就將無關(guān)的文件給過濾掉，盡可能減少進(jìn)入計算引擎的數(shù)據(jù)量，從數(shù)據(jù)源端進(jìn)行節(jié)流。

這張圖展示了整個系統(tǒng)使用 IndexDB 來做裁剪流程：

• 第一步是解析查詢語句。獲取到相關(guān)的 filter，可以看到最左邊的 SQL 語句中有兩個過濾條件, 分別是 src_address = 某個 ip，occur_time > 某個時間戳。

  
  

• 第二步將查詢條件帶入 Index DB 對應(yīng)數(shù)據(jù)源的 meta 表中去進(jìn)行文件篩選。src_address 是字符串類型字段，它會聯(lián)合使用 min/max 和 bloom 索引進(jìn)行裁剪。occur_time 是數(shù)值類型字段并且是時間字段，我們會優(yōu)先查找 min/max 索引來進(jìn)行文件裁剪。需要強(qiáng)調(diào)的是, 這里我們是將用戶寫的 filter 封裝成了 index db 的查詢條件，直接將 filter pushdown 到數(shù)據(jù)庫中完成。

  
  

• 第三步在獲取到文件列表后，這些文件加上前面提到的 merged schema 會共同構(gòu)造成一個 TableSource 來交給 Flink 進(jìn)行后續(xù)計算。

同時，構(gòu)建 source 的時候，我們在細(xì)節(jié)上做了一些優(yōu)化。比如在將 filter 傳給 ORC reader 的時候，清除掉已經(jīng) pushdown 了的 filter， 避免在引擎?zhèn)冗M(jìn)行二次過濾。當(dāng)然, 這里并不是將所有 filter 都清除掉了，我們保留了 like 表達(dá)式，關(guān)于 like 的 filter pushdown 會在后文介紹。

接下來著重介紹一下四大優(yōu)化點(diǎn)：

• 第一點(diǎn)，數(shù)據(jù)在未排序的情況下，裁剪率是有理論上限的，我們通過在數(shù)據(jù)寫入的時候使用 hilbert 曲線排序原始數(shù)據(jù)來提升裁剪率；

  
  

• 第二點(diǎn)，因為安全領(lǐng)域的特殊性，做威脅檢測嚴(yán)重依賴 like 語法，所以我們對 orc api 進(jìn)行了增強(qiáng)，使其支持了 like 語法的下推；
  
  
• 第三點(diǎn)，同樣是因為使用場景嚴(yán)重依賴 join，所以我們對 join 操作也做了相應(yīng)的優(yōu)化；

  
  

• 第四點(diǎn)，我們的系統(tǒng)底層支持多種文件系統(tǒng)，所以我們選取 Alluxio 這一成熟的云原生數(shù)據(jù)編排系統(tǒng)來做數(shù)據(jù)緩存，提高數(shù)據(jù)的訪問局部性。

1. 裁剪率的理論上限及 Hilbert 空間填充曲線

裁剪可以抽象成 N 個球扔進(jìn) M 個桶的概率問題，在這里我們直接說結(jié)論。假設(shè)行在塊中隨機(jī)均勻分布，所有塊的總行數(shù)固定，查詢條件命中的總行數(shù)也固定，則塊命中率直接與 “命中的總行數(shù) / 總塊數(shù)” 正相關(guān)。

結(jié)論有兩個：

• 第一點(diǎn)，如果命中總行數(shù) = 總塊數(shù)，即 X 軸值為 1 的時候，命中率為 2/3， 也就是 2/3 的塊，都包含命中的行，對應(yīng)的塊修剪率的上限是 1/ 3。1/3 是一個很低數(shù)值，但是由于它的前提是數(shù)據(jù)隨機(jī)均勻分布，所以為了讓數(shù)據(jù)分布更好，我們需要在數(shù)據(jù)寫入時對原始數(shù)據(jù)進(jìn)行排序。

  
  

• 第二點(diǎn)，假設(shè)命中總行數(shù)固定，那么大幅度減少每塊中的行數(shù)來增加總塊數(shù)，也能提升塊修剪率。所以我們縮小了塊大小。根據(jù)測試結(jié)果，我們設(shè)定每個文件的大小為：16M?？s小文件大小是很簡單的。針對排序，我們引入了 hilbert 空間填充曲線。
  
  

為什么使用 hilbert 曲線？主要是基于兩點(diǎn)：

• 首先是，以什么路徑遍歷 2 維空間，使路徑的地址序列對其中任一維度都基本有序？為什么要對每一列或者說子集都有序？因為系統(tǒng)在使用的過程中，查詢條件是不固定的。數(shù)據(jù)寫入時排序用到了 5 個字段，查詢的時候可能只用到了其中的一個或兩個字段。Hilbert 排序能讓多個字段做到既整體有序，又局部有序。

  
  

• 另外，空間填充曲線有很多，還有 Z 形曲線、蛇形曲線等等，大家可以看看右邊這兩張對比圖。直觀的看，曲線路徑的長跨度跳躍越少越好，點(diǎn)的位置在迭代過程中越穩(wěn)定越好。而 hilbert 曲線在空間填充曲線里面綜合表現(xiàn)最好。

hilbert 用法，就是實現(xiàn)一個 UDF，輸入列值，輸出坐標(biāo)值，然后根據(jù)坐標(biāo)值排序。

我們抽樣了客戶環(huán)境所使用的 1500 條 SQL 語句，過濾掉了其中裁剪率為分之 100% 的相關(guān)語句，也就是沒有命中文件的無效語句。然后還剩下 1148 條，我們使用這些語句做了裁剪率排序后，對裁剪率進(jìn)行了對比，裁剪率 95 百分位從之前的 68% 提升到了 87%，提升了 19%。可能大家會覺得 19% 這個數(shù)值不是特別高，但如果我們帶上一個基數(shù)，比如說 10 萬個文件，這樣看的話就會很可觀了。

2. 字典索引上 Like 的優(yōu)化

之前也有講到安全行業(yè)的特殊性，我們做威脅檢測的時候會嚴(yán)重依賴 like 查詢。鑒于此，我們也對它做了優(yōu)化。

• 首先我們?yōu)?ORC api 添加了 like 條件表達(dá)式，保證 SQL 中的 like 能下推到 orc record reader 中。

  
  

• 其次，重構(gòu)了 orc record reader 的 row group filter 邏輯，如果發(fā)現(xiàn)是 like 表達(dá)式，首先讀取該字段的 dict steam，判斷 dict stream 是否包含 like 目標(biāo)字符串，如果字典中不存在該值，直接跳過該 row group，不用讀取 data stream 和 length steam，能大幅提高文件讀取速度。后期我們也考慮構(gòu)建字典索引到索引數(shù)據(jù)庫中，直接將字典過濾 pushdown 到數(shù)據(jù)庫中完成。

例如圖上所示，最左邊的 SQL 中有三個表達(dá)式。前兩個在上文中已經(jīng)提到了，是將 filter 直接 pushdown 到 index db 中完成，我們交給 orc reader 的 filter 只有最后一個 attachment_name like '%投標(biāo)%'，真正需要讀取的記錄只是 dict 包含 “投標(biāo)” 的 row group，也就是做到了 row group 級別的過濾，進(jìn)一步減少了需要進(jìn)入計算引擎的數(shù)據(jù)量。

3. 基于索引對 join 的優(yōu)化

威脅情報的匹配中大量使用 join 操作，如果要加速 join 的性能，僅僅是 where 條件的 filter pushdown 是遠(yuǎn)遠(yuǎn)不夠的。

Flink 中已經(jīng)內(nèi)置了許多 join 算法，比如 broadcast join, hash join 和 sort merge join。其中，sort merge join 對預(yù)先排好序的表 join 非常友好，而上文有提到我們使用 Hilbert 曲線來對多字段進(jìn)行聯(lián)合排序，所以 sort merge join 暫時不在我們的優(yōu)化范圍之內(nèi)。

另外，我們知道 join 的性能和左右表的大小正相關(guān)，而威脅情報 join 的稀疏度非常高，所以事先對左右表做裁剪，能夠大幅減少進(jìn)入 join 階段的數(shù)據(jù)。

上文提到過我們已經(jīng)為常見字段建立了 bloom 索引。那么利用這些已經(jīng)創(chuàng)建好的 bloom，來進(jìn)行文件預(yù)過濾，就變得順理成章，并且省掉了構(gòu)建 bloom 的時間開銷。

對于 broadcast join，我們直接掃描小表，將小表記錄依次進(jìn)入大表所屬文件的 bloom，判斷該數(shù)據(jù)塊是否需要, 對數(shù)據(jù)量大的表做預(yù)裁剪。

對于 hash join，正如我們看到的，我們可以預(yù)先對 join key 的文件級 bloom 做 “預(yù) join” 操作，具體就是將左表所屬的某個文件的 bloom 依次與右表所屬文件的 bloom 做 “與” 操作，只保留左右表能 “與后結(jié)果條數(shù)不為 0” 的文件，再讓各表剩余的文件進(jìn)入引擎做后續(xù)計算。

比如說圖上的這三張表，分別是 table1、 table2 和 table3 。我們可以從 index DB 中獲取到表的統(tǒng)計信息，也就是文件個數(shù)或者說是文件表的大小。圖上就直接列的是文件個數(shù)：table 1 是 1000 個， 然后 table 2 是 5 萬個文件， table 3 是 3 萬個文件。

我們就是參照上一張圖片里面的邏輯進(jìn)行預(yù) join，然后預(yù)估 join 的成本。我們會讓成本低的預(yù) join 先進(jìn)行，這樣的話就能夠大幅度減少中間結(jié)果，提升 join 的效率。

4. Alluxio 作為對象存儲的緩存

因為底層文件存儲系統(tǒng)的多種多樣，所以我們選取了 Alluxio 數(shù)據(jù)編排系統(tǒng)，Alluxio 的優(yōu)點(diǎn)是讓數(shù)據(jù)更靠近計算框架，利用內(nèi)存或者 SSD 多級緩存機(jī)制加速文件訪問，如果在完全命中 cache 的情況下，能夠達(dá)到內(nèi)存級 IO 的文件訪問速度，減少直接從底層文件系統(tǒng)讀文件的頻次，很大程度上緩解了底層文件系統(tǒng)的壓力。

對我們系統(tǒng)來說就是它帶來了更高的并發(fā)，而且對低裁剪率的查詢更友好，因為低裁剪率的話就意味著需要讀取大量的文件。

如果這些文件在之前的查詢中已經(jīng)被 load 到 cache 里面，就能夠大幅度的提升查詢速度。

在做完這些優(yōu)化以后，我們做了性能對比測試。我們選取了一個規(guī)模為 249TB 的 es 集群。它使用了 20 臺服務(wù)器，F(xiàn)link 使用了兩臺服務(wù)器，為了在圖標(biāo)上看到更直觀的對比效果，我們選取了 16 條測試結(jié)果。

圖表上紅橙色的是 es，藍(lán)色的是 HQL 優(yōu)化前，綠色的是 HQL 優(yōu)化后。上面的數(shù)字標(biāo)簽是與 es 相比，HQL 的性能差值。比如第一個標(biāo)簽就意味著 HQL 的性能五倍于 es，其中 6 號和 7 號比 es 慢，主要是因為 HQL 是塊索引，es 是行索引，全在內(nèi)存里面，所以可以做到超快的檢索速度。13 號是因為 HQL 在使用 not equal 的情況下，裁剪率相對較差。

總體說，優(yōu)化效果是很明顯的，大部分語句在與 es 查詢速度相比是持平甚至略優(yōu)的。完全滿足客戶對長周期數(shù)據(jù)存儲和查詢的期望。

三、未來規(guī)劃

上圖是未來規(guī)劃。因為客戶現(xiàn)場經(jīng)常會涉及到很多的 BI Dashboard 運(yùn)算和長周期運(yùn)算報告的需求，所以我們下一步會考慮做 BI 預(yù)算，以及蘇軍提到的容器化和 JVM 預(yù)熱，當(dāng)然還有對標(biāo) es，以及提升多用戶并發(fā)查詢的能力。