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

背景技術(shù)

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

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

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

1、解決的問題

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

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

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

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

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

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

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

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

(5)為大促提供保障

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

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

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

3、技術(shù)方案

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

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

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

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

舉例：

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

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

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

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

非時(shí)序化的需要精確查詢以及多表關(guān)聯(lián)的數(shù)據(jù)我們存儲(chǔ)在PostGreSql中，在PostGreSql中我們設(shè)置了分片表、本地表，對不同場景設(shè)置了不同的索引如：B-tree, Hash, GiST, GIN等，利用其Sharding, point-in-time recovery(PITR)等非常棒的特性實(shí)現(xiàn)了高可用、負(fù)載均衡與復(fù)制功能，從而保障了數(shù)據(jù)可以快速存儲(chǔ)到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ù)分析需求的實(shí)現(xiàn)”是在新的條件下應(yīng)對以上挑戰(zhàn)的一種探索，解決了海量數(shù)據(jù)的匯總、查詢問題，幫助業(yè)務(wù)部門快速進(jìn)行數(shù)據(jù)的分析和挖掘，為各個(gè)業(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ù)中心大數(shù)據(jù)技術(shù)中心基礎(chǔ)分析研發(fā)部經(jīng)理，15年從業(yè)背景，蘇寧架構(gòu)師職稱。對于基于大數(shù)據(jù)的數(shù)據(jù)分析系統(tǒng)的建設(shè)有豐富的經(jīng)驗(yàn)，對于電商訂單、購物車、價(jià)格等高并發(fā)系統(tǒng)的設(shè)計(jì)、開發(fā)和運(yùn)維也有獨(dú)到的見解，目前致力于蘇寧基于大數(shù)據(jù)的各類分析平臺(tái)的建設(shè)。

標(biāo)簽： 大數(shù)據(jù) 大數(shù)據(jù)技術(shù) 大數(shù)據(jù)中心 電商 電子商務(wù) 互聯(lián)網(wǎng) 互聯(lián)網(wǎng)電子商務(wù) 基于大數(shù)據(jù) 全文搜索引擎 數(shù)據(jù)分析 數(shù)據(jù)庫 搜索 搜索引擎

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。