【51CTO.com原創(chuàng)稿件】技術(shù)領(lǐng)域

互聯(lián)網(wǎng)電子商務(wù)領(lǐng)域，尤其涉及到快速實現(xiàn)業(yè)務(wù)部門數(shù)據(jù)分析需求的處理方法以及系統(tǒng)。

背景技術(shù)

隨著計算機通訊技術(shù)的發(fā)展，蘇寧易購各業(yè)務(wù)系統(tǒng)產(chǎn)生的業(yè)務(wù)數(shù)據(jù)的規(guī)模也越來越大，對如此龐大的數(shù)據(jù)進行快速分析傳統(tǒng)的框架和技術(shù)已顯得力不從心，并且隨著數(shù)據(jù)挖掘技術(shù)的發(fā)展，對其海量數(shù)據(jù)的分析往往都是隨機維度的自由組合，對此類需求傳統(tǒng)的做法都是一個固化離線統(tǒng)計分析，消耗大量的人力、物力，并且都不能實時分析。針對以上問題，我們設(shè)計出了一套可以快速響應(yīng)蘇寧各業(yè)務(wù)部門數(shù)據(jù)需求分析的工具，不僅支持多維度的自由組合、個性化的設(shè)置，而且還能快速統(tǒng)計出用戶隨機指定的相關(guān)維度、指標(biāo)數(shù)據(jù)。高效實現(xiàn)了用戶的個性化需求，達到創(chuàng)新!

創(chuàng)新的內(nèi)容(技術(shù)創(chuàng)新和業(yè)務(wù)價值)

主要創(chuàng)新在于：首先我們將數(shù)據(jù)進行分類，如蘇寧的業(yè)務(wù)數(shù)據(jù)可以歸類為時序化和非時序化，匯總類和明細類數(shù)據(jù)等，然后采用不同的架構(gòu)技術(shù)方案進行處理。如針對時序化的數(shù)據(jù)，我們基于Druid做了相關(guān)的設(shè)計和封裝，可以將能預(yù)匯總的數(shù)據(jù)存儲于此。時序化的明細數(shù)據(jù)我們基于ElasticSerach技術(shù)作了封裝，可以將歷史數(shù)據(jù)通過Spark直接初始化到ElasticSerach，增量數(shù)據(jù)可以開啟ElasticSerach服務(wù)獲取Kafka實時增量數(shù)據(jù)信息。針對一些特殊場景如精確去重計算，涉及多表關(guān)聯(lián)，我們采用了基于PostGreSql進行了相關(guān)的組件封裝，整套的技術(shù)架構(gòu)方案，能覆蓋用戶在海量數(shù)據(jù)中快速自定義維度、指標(biāo)進行數(shù)據(jù)分析的大部分場景。對于業(yè)務(wù)系統(tǒng)產(chǎn)生的海量數(shù)據(jù)，無論是實時還是離線的，都可以自由的進行維度、指標(biāo)組合，個性化的設(shè)置，對用戶數(shù)據(jù)分析需求進行快速統(tǒng)計。其特點為：對存儲海量的業(yè)務(wù)數(shù)據(jù)無論是匯總和明細查詢都能夠高效的查詢，個性化的維度、指標(biāo)的自由組合，能夠很好支持業(yè)務(wù)部門的大部分數(shù)據(jù)分析需求。

1、解決的問題

(1)業(yè)務(wù)部門數(shù)據(jù)分析需求問題

蘇寧易購各業(yè)務(wù)系統(tǒng)(如訂單，價格，購物車，促銷等電商業(yè)務(wù)系統(tǒng))每天產(chǎn)生海量的數(shù)據(jù)，各業(yè)務(wù)部門在業(yè)務(wù)數(shù)據(jù)產(chǎn)生后，都會對業(yè)務(wù)數(shù)據(jù)進行數(shù)據(jù)分析和相關(guān)的明細查詢操作。然而這種數(shù)據(jù)分析往往帶有隨機和不確定性，每個部門不同的崗位想看的、想分析的往往會截然不同，這樣就會產(chǎn)生了大量的報表需求，給開發(fā)部門帶來了巨大的工作量。針對此需求背景，我們進行了架構(gòu)的調(diào)整和設(shè)計，實現(xiàn)能夠讓客戶自由選擇不同維度和指標(biāo)進行個性化需求分析，快速的統(tǒng)計出用戶想要的數(shù)據(jù)。在明細數(shù)據(jù)查詢的時候，根據(jù)用戶選擇的日期、維度和指標(biāo)也能快速的響應(yīng)。用這種支持用戶個性化的定義分析工具，可以解決大部分的日常的數(shù)據(jù)分析需求，為公司節(jié)約了成本。

(2)海量數(shù)據(jù)高效匯總問題

無論是面對海量的離線數(shù)據(jù)還是實時的數(shù)據(jù)，對如此龐大的數(shù)據(jù)進行數(shù)據(jù)分析都是困難的，之前我們針對實時數(shù)據(jù)的匯總一般采用STORM進行匯總再存入到DB或者其他的緩存中供查詢，但是這種定時調(diào)度存在延遲，不能進行實時的查詢。在海量的離線數(shù)據(jù)做匯總的時候，之前往往我們借助于HADOOP的離線計算，根據(jù)先定義好的維度統(tǒng)計相關(guān)的指標(biāo)再入庫或緩存操作，這樣預(yù)先需要定義大量的不同維度組合，離線計算時效性也很差?；谝陨系膶崟r和離線的匯總統(tǒng)計出現(xiàn)的瓶頸，我們后續(xù)進行了架構(gòu)的調(diào)整，先在DRUID定義一張大寬表，將相關(guān)的維度和指標(biāo)都定義在這個寬表中，數(shù)據(jù)在存儲的時候會按照維度進行預(yù)匯總，在查詢的時候可以快速相應(yīng)，徹底解決了海量數(shù)據(jù)匯總效率低的問題。

(3)海量明細數(shù)據(jù)高效查詢問題

對于業(yè)務(wù)中需要查詢大量的明細數(shù)據(jù)問題，之前傳統(tǒng)的做法都是分庫分表存儲在DB里，這樣在查詢數(shù)據(jù)集較大的情況下存在很大的延遲問題，在存儲上和歸檔上也是極其不便，我們進行了相關(guān)的架構(gòu)調(diào)整，存儲海量的業(yè)務(wù)明細數(shù)據(jù)采用了ElasticSearch存儲介質(zhì)，ElasticSearch是基于Lucene搜索引擎的其查詢效率很高，徹底解決了海量業(yè)務(wù)明細數(shù)據(jù)查詢高延遲問題。

(4)精確去重(count distinct)和多表關(guān)聯(lián)問題

蘇寧的業(yè)務(wù)分析中涉及統(tǒng)計到很多需要去重的維度、指標(biāo)，利用Druid以及ElasticSearch去重都會有丟失精度問題，利用傳統(tǒng)的關(guān)系數(shù)據(jù)庫則統(tǒng)計的效率較低。鑒于此類場景，我們就PostgreSql進行了封裝，利用其自身Sharding 和分片技術(shù)實現(xiàn)了高效的查詢，滿足了精確去重、多表關(guān)聯(lián)并且高效查詢。

(5)為大促提供保障

蘇寧每年的大促都會進行大力的促銷活動，其交易量會是平時的幾十倍，對海量數(shù)據(jù)的存儲和分析對于傳統(tǒng)的架構(gòu)來說顯然很吃力，本方案運用到諸葛大師的塔羅以及實時GMV項目中，很好的解決了該問題。自定義銷售塔羅我們設(shè)計一張大寬表，將可以匯總的數(shù)據(jù)入Druid進行預(yù)匯總，只保留匯總后的數(shù)據(jù)，業(yè)務(wù)部門可以根據(jù)隨機選取的維度和指標(biāo)進行組合查詢。將明細不需要匯總的數(shù)據(jù)我們放入到ElasticSerach中去，利用其高效的Lucene搜索引擎可以快速查詢出業(yè)務(wù)需要的明細數(shù)據(jù)。對于需要精確去重以及多表關(guān)聯(lián)的特殊場景數(shù)據(jù)，我們存儲到PostGreSql中，用戶可以根據(jù)選擇需要去重的維度和指標(biāo)進行查詢，也能快速的相應(yīng)。利用此發(fā)明我們已經(jīng)多次立項，其中主要內(nèi)容包含實時GMV、歷史GMV、銷售塔羅、會員塔羅、庫存塔羅以及自定義塔羅等，在大促期間給領(lǐng)導(dǎo)、用戶、業(yè)務(wù)人員能夠快速的進行數(shù)據(jù)分析提供保障。

2、核心創(chuàng)新點

我們針對海量的數(shù)據(jù)下自定義維度和指標(biāo)進行快速響應(yīng)做了一套方案，對各種業(yè)務(wù)場景的覆蓋，對現(xiàn)有的開源技術(shù)Druid、ElasticSearch和PostGreSql進行封裝，制作成適合支持蘇寧此類業(yè)務(wù)場景個性化的組件，用此整套架構(gòu)方案我們可以快速實現(xiàn)業(yè)務(wù)部門數(shù)據(jù)分析，實現(xiàn)用戶可以隨機定義維度和指標(biāo)進行快速分析，無須再進行大量的個性化報表開發(fā)，不僅用戶體驗得到提高，同時也釋放了大量的開發(fā)資源。

3、技術(shù)方案

***步：數(shù)據(jù)的接入 ;

將時序化類型的匯總增量的實時流式數(shù)據(jù)和全量需要初始化的離線數(shù)據(jù)接入到Druid中，個性化的匯總數(shù)據(jù)分析都是基于DRUID實現(xiàn)的。海量的時序化的明細數(shù)據(jù)信息接入到ElasticSearch，離線數(shù)據(jù)我們通過Spark組件初始化到ElasticSerach,增量的流式數(shù)據(jù)我們通過ElasticSearch監(jiān)控服務(wù)去從kafka拉取，所有的個性化的明細數(shù)據(jù)查詢都是基于ElasticSearch實現(xiàn)的。非時序化需要進行精確去重以及多表關(guān)聯(lián)的數(shù)據(jù)我們初始化到PostGreSql中，在PG 中我們支持匯總和明細各種場景的海量數(shù)據(jù)快速查詢。

第二步：個性化的數(shù)據(jù)分析匯總查詢;

個性化的數(shù)據(jù)分析匯總主要是基于Druid操作的，首先設(shè)計一張大寬表，這個大寬表包含了業(yè)務(wù)域的所有的維度和指標(biāo)，再將實時和離線數(shù)據(jù)接入到這個基于Druid的大寬表中，數(shù)據(jù)會根據(jù)這個大寬表的定義的維度進行預(yù)匯總，存儲的并非明細數(shù)據(jù)，界面提供用戶選擇的維度和指標(biāo)，可以任意的組合，支持個性化的配置，將選擇好的維度和指標(biāo)固化后進入到查詢界面，再從Druid中開始查詢已經(jīng)配置好的維度和指標(biāo)進行數(shù)據(jù)分析。

舉例：

銷售塔羅：蘇寧的銷售數(shù)據(jù)有實時數(shù)據(jù)和歷史數(shù)據(jù)，在統(tǒng)計銷售數(shù)據(jù)的時候會有很多維度進行統(tǒng)計、如統(tǒng)計各大區(qū)的付款金額和訂單數(shù)量、各品牌、品類的付款金額和訂單數(shù)量、各業(yè)務(wù)渠道的同期和本期的銷售額等，這樣就會有大量的報表需要開發(fā)人員去開發(fā)，而且銷售的維度和指標(biāo)有很多，涉及到數(shù)據(jù)挖掘那組合就更多了。之前的做法是實時數(shù)據(jù)我們基于STORM匯總后落入DB提供展示，但是這種設(shè)計不能滿足用戶個性化的操作，不能隨意的選擇維度和指標(biāo)，往往都是先提需求再進行相關(guān)的開發(fā)，仍然有大量的開發(fā)工作量。后續(xù)我們基于Druid存儲后，將所有的銷售維度和指標(biāo)都放在一張大寬表中，數(shù)據(jù)基于維度預(yù)匯總進行存儲，頁面支持個性化的配置，這樣就能夠快速的實現(xiàn)業(yè)務(wù)部門的數(shù)據(jù)分析需求。

第三步：個性化的數(shù)據(jù)分析明細查詢;

個性化的數(shù)據(jù)分析明細查詢主要是基于ElasticSearch操作的，在ElasticSearch中我們定義了索引和類型，將涉及到的維度和指標(biāo)信息都定義在其中，接著我們將明細數(shù)據(jù)灌入其中，因ElasticSearch是基于Lucene框架的全文搜索引擎，其支持海量明細數(shù)據(jù)高效的查詢。如像訂單明細數(shù)據(jù)，每天約數(shù)十萬數(shù)據(jù)量，兩年數(shù)據(jù)存儲在ElasticSearch中，在對兩年訂單明細數(shù)據(jù)進行隨意過濾查詢，其相應(yīng)速度都是秒級，用戶體驗較好。

第四步：非時序需要精確查詢和多表關(guān)聯(lián)的查詢

非時序化的需要精確查詢以及多表關(guān)聯(lián)的數(shù)據(jù)我們存儲在PostGreSql中，在PostGreSql中我們設(shè)置了分片表、本地表，對不同場景設(shè)置了不同的索引如：B-tree, Hash, GiST, GIN等，利用其Sharding, point-in-time recovery(PITR)等非常棒的特性實現(xiàn)了高可用、負載均衡與復(fù)制功能，從而保障了數(shù)據(jù)可以快速存儲到PostGreSql中并且能高效的查詢出來。對于需要精確去重的業(yè)務(wù)場景，我們可以直接采用和關(guān)系型數(shù)據(jù)庫一樣的操作count(distinct)即可，對于多表關(guān)聯(lián)，PostGreSql能很好支持大部分 SQL標(biāo)準(zhǔn)并且提供了許多其它特性。

總結(jié)

隨著數(shù)據(jù)量的不斷增長和業(yè)務(wù)對快速分析的要求，傳統(tǒng)的框架和技術(shù)已無法應(yīng)對新的挑戰(zhàn)。新的挑戰(zhàn)逼迫技術(shù)人員要找到能滿足海量數(shù)據(jù)和快速分析需求的解決方案。本文所述的“海量數(shù)據(jù)條件下企業(yè)自定義數(shù)據(jù)分析需求的實現(xiàn)”是在新的條件下應(yīng)對以上挑戰(zhàn)的一種探索，解決了海量數(shù)據(jù)的匯總、查詢問題，幫助業(yè)務(wù)部門快速進行數(shù)據(jù)的分析和挖掘，為各個業(yè)務(wù)部門的決策和行為提供數(shù)據(jù)支撐，特別是在大促期間能對精準(zhǔn)營銷等業(yè)務(wù)提供數(shù)據(jù)方面的保障，為公司的“數(shù)據(jù)經(jīng)營”添磚加瓦。

附圖

圖1 業(yè)務(wù)系統(tǒng)技術(shù)架構(gòu)圖

圖2 業(yè)務(wù)系統(tǒng)應(yīng)用架構(gòu)圖

圖3 業(yè)務(wù)系統(tǒng)應(yīng)用集成圖

圖4 銷售塔羅數(shù)據(jù)流向圖

圖5 用戶可自由選擇關(guān)心的指標(biāo)及維度

作者：丁安國，蘇寧易購IT總部大數(shù)據(jù)中心基礎(chǔ)分析研發(fā)部經(jīng)理，15年從業(yè)背景，蘇寧架構(gòu)師職稱。對于基于大數(shù)據(jù)的數(shù)據(jù)分析系統(tǒng)的建設(shè)有豐富的經(jīng)驗，對于電商訂單、購物車、價格等高并發(fā)系統(tǒng)的設(shè)計、開發(fā)和運維也有獨到的見解，目前致力于蘇寧基于大數(shù)據(jù)的各類分析平臺的建設(shè)。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】