大數據

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

作者介紹

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

背景需求

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

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

image.png

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

篩選條件

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

image.png

篩選條件說明

業務模型

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

image.png

樣例數據模型說明

聚合數據模型

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

image.png

聚合後的業務數據模型

技術抽象

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

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

image.png

技術抽象過程

技術嘗試

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

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

image.png

舉法計算量=愚公

矩陣轉換

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

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

image.png

下單日期可變數大

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

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

image.png

客戶端行轉列示意圖

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

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

image.png

客戶日期列邏輯合併

業務查詢

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

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

image.png

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

結語

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

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

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

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


image.png

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

相關活動


更多折扣活動,請訪問阿里雲 Elasticsearch 官網

阿里雲 Elasticsearch 商業通用版,1核2G ,SSD 20G首月免費
阿里雲 Logstash 2核4G首月免費


image.png

image.png

Leave a Reply

Your email address will not be published. Required fields are marked *