一次有趣的Elasticsearch+矩陣變換聚合實踐

作者介紹

李猛，Elastic Stack 深度用戶，通過 Elastic 工程師認證，2012年接觸 Elasticsearch，對 Elastic Stack 技術棧開發、架構、運維等方面有深入體驗，實踐過多種大中型項目；為企業提供 Elastic Stack 諮詢培訓以及調優實施；多年實戰經驗，愛搗騰各種技術產品，擅長大數據，機器學習，系統架構。

背景需求

公司所屬行業是物流速運，面向企業服務（簡稱ToB模式），提供多種物流運輸方案產品，客戶分佈遍佈全國，客戶數量在百萬級以上，日均產生物流運輸需求在幾十萬票（單）以上，對於客戶訂單的聚合統計分析查詢需求強烈，且需要一定的實時性。

同時需要滿足以下用戶需求：
1、用戶需要在地圖上展示客戶的聚合分佈；
2、聚合分佈維度按照全國、省、市、區縣、鄉鎮劃分。

地圖展示樣例：非內部效果圖

篩選條件

用戶端基於多個篩選條件過濾聚合，選擇任意條件組合，如下：
• 行政區域：
按照國家4級行政區域：省、市、區、鎮等數量在5000+以上
• 企業組織架構：
企業內部多層級組織架構：大區、小區等數量超過3000+以上
• 客戶企業類型：
客戶企業類型劃分：2B、2C等數量在10+以上
• 客戶行業類型：
客戶企業行業所屬類型劃分，如傢俱、服裝、電子、3C等數量在100+以上
• 企業業務類型：
企業物流業務類型，如寄件、派件、未寄件派件等
• 日期範圍：
日期範圍篩選限制在1個月，即日期的滑動窗口在1~31天（這個限定範圍是與業務部門多次討論得來，否則後面實現的代價會更大，原有是多個月的窗口期）

篩選條件說明

業務模型

業務數據模型說明：
• 單個客戶即使單天下單多次，單天聚合統計也只能算1個客戶；
• 單個客戶連續多天都有下單，多天聚合統計也只能算1個客戶；
• 業務類型有寄件/派件，按照其中一種處理，邏輯比較計算。

樣例數據模型說明

聚合數據模型

聚合數據模型說明：基於前面的業務模型數據聚合，按照區域+其它條件聚合，獲取聚合後分組客戶數量。

聚合後的業務數據模型

技術抽象

業務需求是一個很典型的聚合統計，多數大數據產品或者傳統關係數據庫都支持，相反 Elasticsearch 聚合支持的不怎麼好，不能滿足需求。
業務需求的技術本質實際上是一個去重然後分組聚合的過程：

1、去重合並：按照客戶維度去重，合併符合過濾條件的客戶數據，相同多條客戶數據合併為單條數據；
2、聚合分組：按照聚合維度分組，並計算出分組後的客戶數量。

技術抽象過程

技術嘗試

在實現業務需求過程中嘗試過多種技術產品，遇到不少問題：

1、Mysql：當數據達到一定數量級，運行超時，甚至直接運行不起來；
2、Prestodb：定位是秒級分析型產品，單任務啟動就需要消耗好幾秒的時間，且受資源限制，併發度與響應度不能滿足要求，優點可與 Hive 很好結合。
3、MPP：Greenplum/Vertica/Infobright，與 Prestodb 其實本質差不多，都不能滿足性能要求。
4、窮舉法：探討過將所有的組合條件全部計算存儲起來，業務系統只要去定位去查詢，比如 Kylin 產品，查詢複雜度確實低了，但計算量與存儲量實在是太大，根本不現實；
5、Elasticsearch：雖然提供了聚合能力，但不支持在一次聚合過程中完成去重與分組統計，也就是不支持複雜的二次聚合，這是 ES 侷限，也是 ES 定位。

舉法計算量=愚公

矩陣轉換

技術嘗試過多次不同的技術產品之後得出結論，單一的數據產品已有能力是無法滿足要求的，正可謂魚與熊掌不可兼得。所以必須改變思維，設計了一種矩陣變換的算法機制，結合 Hive+ES 實現，下面介紹這種技術實現方式。

可轉換性分析：分析原有業務需求，發現只有日期這個條件組合特別多，動態變化範圍很大，如果按照單月最長31天計算組合數就有31的階乘；其餘的條件變化小，也沒有動態的組合條件，所以重點解決日期組合這個條件。

下單日期可變數大

數據行轉列：原有業務數據是按照行存儲，聚合日期最小粒度是天，單個客戶下單信息除了下單日期、業務類型，其餘的是相同的；將單個客戶單月 31 天的下單數據 31 條轉換成 1 條數據 31 列存儲，31 列分表代表從下單日期往後疊加的日期，列存儲的值代表當天是否有下單以及業務類型。

1、本次行轉列基於 Hive 實現，數倉 ODS 數據都存儲在 Hive 裡，方便做下一步數據清洗轉換計算；
2、首先在 Hive 上按照【客戶+日期】維度將客戶下單數據去重，並按照業務類型簡單的邏輯計算，合併單日多次下單的業務類型；
3、客戶數據按照日期排序，從歷史日期到當下昨天日期，計算任務默認 T+1；
4、其次在 Hive 中將去重後的客戶數據，按照行轉列模型將 1～31 天行數據轉換到 31 列的數據，並填充原始行的業務類型值。

客戶端行轉列示意圖

列合併邏輯計算：業務需求是按照日期範圍聚合，在一個日期範圍內，客戶訂單業務類型要做一些邏輯計算（業務類型：0/1/2），按照最大，所以需要計算單個客戶單條數據之後 31 天的業務類型。

1、本次列合併邏輯計算基於 Hive 實現；
2、合併完整的數據之後按照月的維度分開存儲，當計算任務下次 T+1 運行時，只要更新最近 31 天的數據，最多跨度 2 個月。
3、數據同步到 Elasticsearch 中，一個月一個索引，也只要更新最近的 2 個索引。Elasticsearch 更新索引也很方便，採用別名切換方式，可在毫秒間完成，ES 這個優點有效的避免了業務系統查詢停頓空白問題。

客戶日期列邏輯合併

業務查詢

選擇 Elasticsearch 做為查詢引擎是非常正確的，得益於 Elasticsearch 高效的查詢機制以及高效的聚合能力。

1、依據起始日期定位到該日期的月度索引，並鎖定對於下單日期所有數據，Elasticsearch 支持動態索引搜索，支持高效的過濾 filter 掃描；
2、依據結束日期與起始日期差值，定位到指定的數據列；
3、最後只要一次聚合即可返回數據，Elasticsearch 支持高效的聚合特性 agg。

說明案例：查詢2019-03-01~2019-03-05 客戶聚合數據

結語

本次需求的技術實現比較曲折，在探討大數據分析方面做了一次很重要的探索實踐，沒有一種通用的數據產品即可滿足性能與功能，所以在面對實際業務問題要去探討多種技術的混合實踐。本次項目中的 Hive+ES 結合就是一次很有趣的混合。

學會培養一些算法思維，用微觀算法的思維分析問題解決問題。本次項目中採用矩陣轉換，有效避免了諸多技術產品的不足，滿足了性能與功能。

項目案例是在 2019 年 3 月完成，時任職於跨越速運大數據中心。項目方案依賴大數據平臺實現大量的預計算，矩陣變換是由服務端工程師想出來的，項目完成需要前後端通力配合才能完成。

聲明：本文由原文作者“李猛”授權轉載，對未經許可擅自使用者，保留追究其法律責任的權利。

【阿里雲Elastic Stack】100%兼容開源ES，獨有9大能力，提供免費X-pack服務（單節點價值$6000）