1.項目背景

中國移動公司旗下?lián)碛泻芏嗟淖訖C(jī)構(gòu),基本可以按照省份劃分. 而各省份旗下的充值機(jī)構(gòu)也非常的多.

目前要想獲取整個平臺的充值情況,需要先以省為單元,進(jìn)行省份旗下的機(jī)構(gòu)統(tǒng)計,然后由下往上一層一層的統(tǒng)計匯總,過程太過繁瑣,且統(tǒng)計周期太長. 且充值過程中會涉及到中國移動信息系統(tǒng)內(nèi)部各個子系統(tǒng)之間的接口調(diào)用, 接口故障監(jiān)控也成為了重點監(jiān)控的內(nèi)容之一.

為此建設(shè)一個能夠?qū)崟r監(jiān)控全國的充值情況的平臺, 掌控全網(wǎng)的實時充值, 各接口調(diào)用情況意義重大.

2.技術(shù)選型：

Apache Spark

Spark Streaming 是核心 Spark API 的一個擴(kuò)展，它并不會像 Storm 那樣一次一個地處理數(shù)據(jù)流，而是在處理前按時間間隔預(yù)先將其切分為一段一段的批處理作業(yè)。Spark 針對持續(xù)性數(shù)據(jù)流的抽象稱為 DStream(DiscretizedStream)，一個 DStream 是一個微批處理(micro-batching)的 RDD(彈性分布式數(shù)據(jù)集);而 RDD 則是一種分布式數(shù)據(jù)集，能夠以兩種方式并行運作， 分別是任意函數(shù)和滑動窗口數(shù)據(jù)的轉(zhuǎn)換。

3.項目架構(gòu)

 

 

4.項目數(shù)據(jù)量

? 數(shù)據(jù)量每天大概 2000 到 3000 萬筆的下單量, 每條數(shù)據(jù)大概在 0.5KB 左右,下單量數(shù)據(jù)大概在 15GB 左右.

? 最后充值成功的大概 500 到 1000 萬,平時充值成功的大概五六百萬筆.

? 月初和月末量比較大

5.目需求實現(xiàn)

1.業(yè)務(wù)概況(顯示總訂單量、訂單成功量、總金額、花費時間)

2.業(yè)務(wù)詳細(xì)概述(每小時的充值訂單量、每小時的充值成功訂單量)

3.業(yè)務(wù)質(zhì)量(每個省份的充值成功訂單量)

4.實時統(tǒng)計每分鐘的充值金額和訂單量

整體步驟：

提取數(shù)據(jù)庫中存儲的偏移量–>廣播省份映射關(guān)系–>獲取kafka的數(shù)據(jù)–>數(shù)據(jù)處理(JSON對象解析，省份、時間、結(jié)果、費用)

–>計算業(yè)務(wù)概況(顯示總訂單量、訂單成功量、總金額、花費時間)–>業(yè)務(wù)概述(每小時的充值總訂單量，每小時的成功訂單量)

—>業(yè)務(wù)質(zhì)量(每個省份的成功訂單量)—>實時統(tǒng)計每分鐘的充值金額和訂單量

 

 

項目需求實現(xiàn)：

1)用flume收集數(shù)據(jù)，放入到kafka，下面是詳細(xì)配置。

 

 

2)用SparkStreaming去消費kafka里面的數(shù)據(jù)前，做一些Kafka參數(shù)的配置以及放入Redis數(shù)據(jù)庫所需要的配置。

(1)在IDEA中配置kafka和Redis相關(guān)參數(shù)，方便獲取kafka里面的數(shù)據(jù)并且存儲到redis里面

 

 

(2)方便計算訂單完成所需要的時間，封裝了一個類

 

 

(3)做一個Redis池去操作Redis中的數(shù)據(jù)

 

 

(4)每次放入Redis前需要判斷偏移量，防止數(shù)據(jù)重復(fù)以及消耗資源

 

 

(5)設(shè)置自己的kafka、mysql(存儲偏移量)、redis的配置

 

 

3)做好一系列配置之后就開始SparkStreaming數(shù)據(jù)處理的核心

先說明一下日志文件中字段的含義

 

 

 

 

(1)下面是SparkStreaming核心代碼

 

 

(2)將封裝好的方法調(diào)用

 

 

pom文件

 

4.0.0

 

標(biāo)簽： Mysql 代碼 數(shù)據(jù)庫

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