01序言
Elasticsearch聚合功能非常豐富，性能也相當不錯，特別適合實時聚合分析場景，但在二次聚合上也有明顯短板，不支持。
項目是一個基於日期維度做預處理的技術方案，以下是結合Elasticsearch優缺點揚長避短的一次嘗試性實戰，非常有意思，希望可以帶來一些參考，同時歡迎各種討論。
02背景需求
公司所屬行業是物流速運，面向企業服務（簡稱ToB模式），提供多種物流運輸方案產品，客戶分布遍布全國，客戶數量在百萬級以上，日均產生物流運輸需求在幾十萬票以上，對於客戶訂單的聚合統計分析查詢需求強烈，且需要一定的實時性。
用戶需求
用戶要求在地圖上展示客戶的聚合分布聚合分布維度按照全國、省、市、區縣、鄉鎮 劃分。
篩選條件
用戶基於多個篩選條件過濾聚合，多條件任意組合，如下：
行政區域按照國家4級行政區域：省、市、區、鎮等數量在5000+以上
企業組織架構企業內部多層級組織架構：大區、小區等數量超過3000+以上
客戶企業類型客戶企業類型劃分：2B、2C等數量在10+以上
客戶行業類型客戶企業行業所屬類型劃分，如家具、服裝、電子、3C等數量在100+以上
企業業務類型企業物流業務類型，如寄件、派件、未寄件派件等
日期範圍日期範圍篩選限制在1個月，即日期的滑動窗口在1~31天（這個限定範圍是與業務部門多次討論得來，否則後面實現的代價會更大，原有是多個月的窗口期）
業務模型
原始數據模型說明：
客戶下單一次，業務系統記錄一條數據客戶下單多次，業務系統記錄多條數據業務需求數據模型說明：
單個客戶即使單天下單多次，單天聚合統計也只能算1個客戶。單個客戶連續多天都有下單，多天聚合統計也只能算1個客戶。業務類型有寄件/派件，按照其中一種處理，邏輯比較計算。
聚合模型
聚合數據模型說明
基於前面的原始業務模型數據聚合，按照區域+其它部分條件聚合，統計組合後條件下的分組客戶數量
03技術探索
業務需求是一個很典型的聚合統計，多數大數據產品或者傳統關係資料庫都支持，相反Elasticsearch聚合支持的不怎麼好，不能滿足需求。
技術抽象
業務需求的技術本質實際上是一個去重然後分組聚合的過程。
去重合併按照客戶維度去重，合併符合過濾條件的客戶數據，相同多條客戶數據合併為單條數據聚合分組按照聚合維度分組，並計算出分組後的客戶數量
技術嘗試
在實現業務需求過程中嘗試過多種技術產品，遇到不少問題。
Mysql當數據達到一定數量級，運行超時嚴重，甚至直接運行不起來Prestodb定位是秒級分析型產品，單任務啟動就需要消耗好幾秒的時間，且受資源限制，並發度與響應度不能滿足要求。優點可與Hive很好結合MPPGreenplum/Vertica/Infobright，與Prestodb其實本質差不多，都不能滿足性能要求。窮舉法探討過將所有的組合條件全部計算存儲起來，業務系統只要去定位去查詢，比如Kylin產品，查詢複雜度確實低了，但計算量與存儲量實在是太大，根本不現實
Elasticsearch雖然提供了聚合能力，但不支持在一次聚合過程中完成去重與分組統計，也就是二次聚合，這是ES局限，也是ES定位。
04矩陣轉換
嘗試過幾次不同的技術產品之後得出結論，單一的數據產品已有能力是無法滿足要求的，正可謂魚與熊掌不可兼得。所以必須改變思維，設計了一種矩陣變換的算法機制，結合Hive+ES實現，以下介紹這種技術實現方式。
可轉換性分析
分析原有業務需求，發現只有日期這個條件組合特別多，動態變化範圍很大，如果按照單月最長31天計算組合數就有31的階乘；其餘的條件變化小，也沒有動態的組合條件，所以重點解決日期組合這個條件。
數據行轉列
原有業務數據是按照行存儲，聚合日期最小粒度是天， 單個客戶下單信息除了下單日期、業務類型，其餘的是相同的。將單個客戶單月31天的下單數據31條轉換成1條數據31列存儲，31列分表代表從下單日期往後疊加的日期，列存儲的值代表當天是否有下單以及業務類型。
本次行轉列基於Hive實現，數倉ODS數據都存儲在Hive上，方便做下一步數據清洗轉換計算。首先在Hive上 按照【客戶+日期】維度將客戶下單數據去重，並按照業務類型簡單的邏輯計算，合併單日多次下單的業務類型。客戶數據按照日期排序，從歷史日期到當下昨天日期，計算任務默認T+1其次在Hive上 將去重後的客戶數據，按照行轉列模型將1～31天行數據轉換到31列的數據，並填充原始行的業務類型值。列合併邏輯計算
業務需求是按照日期範圍聚合，在一個日期範圍內，客戶訂單業務類型要做一些邏輯計算（業務類型：0/1/2），按照最大，所以需要計算單個客戶單條數據之後31天的業務類型。
列合併邏輯計算示意圖
本次列合併邏輯計算基於Hive實現。合併完整的數據之後按照月的維度分開存儲，當計算任務下次T+1運行時，只要更新最近31天的數據，最多跨度2個月。數據同步到Elasticsearch中，一個月一個索引，也只要更新最近的2個索引。Elasticsearch更新索引也很方便，採用別名切換方式，可在毫秒間完成，ES這個優點有效的避免了業務系統查詢停頓空白問題。業務查詢
選擇Elasticsearch做為查詢引擎是非常正確的，得益於Elasticsearch高效的查詢機制以及高效的聚合能力。
依據 起始日期 定位 到該日期的月度索引，並鎖定對於下單日期所有數據。Elasticsearch支持動態索引搜索，支持高效的過濾filter掃描。依據結束日期與起始日期差值，定位到指定的 數據列最後只要一次聚合即可返回數據，性能很好。Elasticsearch支持高效的聚合特性agg案例：查詢2019-03-01~2019-03-05之間的聚合數據
05結語
技術
本次需求的技術實現比較曲折，在探討大數據分析方面做了一次很重要的探索實踐，沒有一種通用的數據系統即可滿足性能與功能，所以在面對實際業務問題要去探討多種技術的混合實踐。本次項目中的Hive+ES結合就是一次很有趣的混合。學會培養一些算法思維，用微觀的眼光分析問題解決問題。本次項目中採用矩陣轉換，有效避免了諸多技術產品的不足，滿足了性能與功能。項目
項目案例是在2019年3月完成，此時任職 跨越速運大數據中心。項目方案依賴大數據平臺實現大量的預計算，矩陣變換是由服務端工程師想出來的，典型的前後端配合完成內容來源
本次內容源於 2019-04-20深圳Elastics-meetup分享大會《大會分享活動： Elasticsearch 實時高效聚合計算應用實踐》重新整理。PPT回顧下載：ES社區 ，elasticsearch.cn
06關於作者
Elastic-stack產品深度用戶，ES認證工程師。2012/2013年接觸Elasticsearch，對Elastic-Stack開發、架構、運維等方面有深入體驗，實踐過多種Elasticsearch項目，最暴力的大數據分析應用，最複雜的業務系統應用。業餘為企業提供Elastic-stack諮詢培訓以及調優實施。