梁方瑋,薛 濤

（西安工程大學(xué) 計算機(jī)科學(xué)學(xué)院,西安 710600）

隨著我國經(jīng)濟(jì)的進(jìn)步與發(fā)展,電商平臺成為人們購銷的首選,物流公共服務(wù)平臺則作為信息化與效率的保障支撐著電商平臺的正常運轉(zhuǎn).為了更好地收集用戶需求、降低網(wǎng)站的開發(fā)維護(hù)成本、提供高質(zhì)量的物流服務(wù).日志信息毫無疑問是其提取寶藏的礦石.因為日志全方面地記錄了平臺服務(wù)性能、接口調(diào)用記錄以及用戶行為的信息,具有較強(qiáng)的追溯作用以及實際價值[1].因此,對物流服務(wù)平臺的日志數(shù)據(jù)進(jìn)行實時采集并挖掘內(nèi)在信息具有較高的現(xiàn)實意義與理論價值.目前,機(jī)器學(xué)習(xí)[2]、文本挖掘[3]等技術(shù)已經(jīng)被應(yīng)用于日志處理領(lǐng)域中,并形成了較為堅實的研究基礎(chǔ).例如,實現(xiàn)多源異構(gòu)日志的日志采集技術(shù)、針對大規(guī)模及高并發(fā)日志數(shù)據(jù)存儲和并行計算技術(shù)等[4-6].但這些研究均持續(xù)時間較長,不能夠很好地滿足實時日志分析以及異常識別等需求.針對此需求,相關(guān)學(xué)者提出利用低時延的流處理框架來保障大規(guī)模日志數(shù)據(jù)實時處理,其中Storm、Flink以及Spark Streaming處理效果最為突出[7,8].且Flink相較于Storm以及Spark Streaming具有更精確的數(shù)據(jù)計算性能和完善的窗口支持特性,更適于進(jìn)行海量日志實時處理.此外,為了保障對海量物流服務(wù)平臺日志數(shù)據(jù)進(jìn)行安全存儲以及高效的實時讀寫,本文將引入HBase數(shù)據(jù)庫進(jìn)行數(shù)據(jù)存儲,相較于Redis、MangoDB以及ElasticSearch等具有高并發(fā)、實時處理數(shù)據(jù)以及適于存儲大規(guī)模數(shù)據(jù)的特性.因此,本文將圍繞海量日志實時處理并借助Flink、HBase等技術(shù)進(jìn)行平臺的設(shè)計與實現(xiàn).

1 海量日志實時處理

大數(shù)據(jù)時代發(fā)展至今,數(shù)據(jù)量呈指數(shù)級增長,大數(shù)據(jù)中的日志處理也就逐漸得到重視.目前,針對海量日志數(shù)據(jù)的處理方式可以分為離線處理與實時處理兩種類型,其基本流程均為日志數(shù)據(jù)采集、日志數(shù)據(jù)歸一化、日志數(shù)據(jù)存儲、日志數(shù)據(jù)預(yù)處理、離線計算/實時查詢和結(jié)果展示[9].但是,隨著需求方對于數(shù)據(jù)實時性要求的不斷提升,如用戶的實時行為、程序?qū)崟r監(jiān)控告警、任務(wù)實時調(diào)度、業(yè)務(wù)綜合推薦等,實時處理成為日志數(shù)據(jù)處理領(lǐng)域當(dāng)前亟待優(yōu)化的關(guān)鍵性課題[10,11],本節(jié)將從實時處理概念與流程、實時流處理框架以及實時存儲數(shù)據(jù)庫角度進(jìn)行具體的日志數(shù)據(jù)實時處理分析.

1.1 大數(shù)據(jù)實時計算與處理

大數(shù)據(jù)的實時計算與處理可以針對性解決數(shù)據(jù)實時性的需求,結(jié)合流處理框架以及實時存儲與高并發(fā)數(shù)據(jù)庫可以更好地解決面向大數(shù)據(jù)的高吞吐率和并發(fā)性需求.相較于傳統(tǒng)的離線批數(shù)據(jù)處理,大數(shù)據(jù)實時計算與處理的思路可以更好地解決基于海量日志的數(shù)據(jù)處理課題.實時計算與處理的流程主要包括數(shù)據(jù)的實時采集、數(shù)據(jù)的實時計算以及數(shù)據(jù)的實時下發(fā).數(shù)據(jù)的實時采集包括用戶行為記錄的數(shù)據(jù)采集、網(wǎng)站請求的數(shù)據(jù)采集、機(jī)器CPU/MEM/IO記錄的數(shù)據(jù)采集等.數(shù)據(jù)的實時計算是針對采集的數(shù)據(jù)進(jìn)行實時計算,計算的結(jié)果包括用戶信息統(tǒng)計、請求數(shù)量及請求IP、單位內(nèi)機(jī)器CPU/MEM/IO的均值、Error級日志數(shù)據(jù)過濾等.數(shù)據(jù)的實時下發(fā)則是將數(shù)據(jù)交由下游進(jìn)行處理,下游包括數(shù)據(jù)信息監(jiān)測告警、數(shù)據(jù)信息實時存儲與檢索等[12].實時處理流程如圖1所示.

圖1 大數(shù)據(jù)實時處理流程及應(yīng)用場景

1.2 Flink流處理框架

針對大數(shù)據(jù)的實時處理,采用的是Flink流處理框架進(jìn)行實時計算,相較于離線批數(shù)據(jù)處理框架可以很好地解決實時監(jiān)控告警、窗口聚合、故障溯源等情況.實時計算是不斷地從MQ（Message Queue,消息隊列）中讀入采集的數(shù)據(jù),并在計算后存入數(shù)據(jù)庫中.面向的是數(shù)據(jù)量未知、計算操作簡單且需要實時響應(yīng)的情況.而離線計算則是從數(shù)據(jù)存儲中讀取固定量的數(shù)據(jù)進(jìn)行復(fù)雜的計算并生成詳細(xì)報表.所以,基于實時計算的流處理框架Flink可以保障數(shù)據(jù)的實時處理、不斷進(jìn)行數(shù)據(jù)迭代與更新.

Flink是針對流數(shù)據(jù)與批數(shù)據(jù)的分布式處理框架,可以兼顧有界批數(shù)據(jù)和無界實時數(shù)據(jù)的處理.Flink的核心為分布式運行,主體部分包括Program code（Flink程序代碼）、Job client（執(zhí)行起點,負(fù)責(zé)接收用戶代碼并創(chuàng)建流數(shù)據(jù)）、Job manager（作業(yè)管理器,負(fù)責(zé)進(jìn)行調(diào)度）、Task manager（接受上一級傳遞的Task,是JVM中的一個或多個線程中執(zhí)行任務(wù)的工作節(jié)點）[13].Flink的工作流程如圖2所示.

圖2 Flink流處理框架工作流程

1.3 HBase實時處理數(shù)據(jù)庫

除了對于流處理框架的選擇外,平臺要求數(shù)據(jù)庫可以進(jìn)行數(shù)據(jù)實時存儲、高并發(fā)以及查詢操作.HBase數(shù)據(jù)庫相較于傳統(tǒng)的RDBMS（關(guān)系型數(shù)據(jù)庫）等類型的數(shù)據(jù)庫,可以很好地解決實時讀寫、大規(guī)模數(shù)據(jù)存儲以及隨機(jī)訪問等場景.HBase是通過從下到上線性地增加節(jié)點來進(jìn)行數(shù)據(jù)庫拓展,將大規(guī)模且稀疏的數(shù)據(jù)表構(gòu)建在服務(wù)器集群上.但是HBase的實時計算的特性是由其自身的架構(gòu)與數(shù)據(jù)結(jié)構(gòu)所決定的,其底層架構(gòu)為LSM-Tree+HTable（region分區(qū)）+Cache,客戶端可以直接定位到待查詢數(shù)據(jù)所處的服務(wù)器位置,并在服務(wù)器上進(jìn)行數(shù)據(jù)匹配,整個過程由Cache緩存完成,這也是HBase雖然部署于批處理系統(tǒng)的集群上卻可以進(jìn)行實時計算的緣由.除此上述的關(guān)鍵特性外,HBase的系統(tǒng)架構(gòu)中較為關(guān)鍵的組件包括:Client（客戶端,包含訪問數(shù)據(jù)庫的接口）、Zookeeper（數(shù)據(jù)庫依賴,對Region相關(guān)信息進(jìn)行存儲）、HMaster（進(jìn)程管理,用于管理Region server的負(fù)載調(diào)度）等[14].其具體的工作流程圖如圖3所示.

圖3 HBase數(shù)據(jù)庫工作原理

2 日志實時處理平臺

當(dāng)前,訪問量10萬級的物流服務(wù)平臺的日志數(shù)據(jù)量就超過1 GB,單機(jī)服務(wù)器已經(jīng)不能滿足海量日志存儲的需求,所以需要進(jìn)一步引入大規(guī)模數(shù)據(jù)存儲HBase,并且為了更好地降低日志數(shù)據(jù)信息時延的問題、提高日志的時效性,需要進(jìn)一步引入流處理框架Flink解決這一問題,故本節(jié)將結(jié)合Flink與HBase以及其他相關(guān)技術(shù)對海量物流服務(wù)平臺的日志數(shù)據(jù)實時處理平臺的架構(gòu)以及功能進(jìn)行介紹,并進(jìn)一步分析架構(gòu)中各部分集群的連通方式與各技術(shù)的工作原理.

2.1 日志實時處理平臺架構(gòu)設(shè)計

本文在傳統(tǒng)的大數(shù)據(jù)實時處理流程中嵌入針對日志數(shù)據(jù)的相關(guān)技術(shù),并對傳統(tǒng)流程的結(jié)構(gòu)進(jìn)行了優(yōu)化使得架構(gòu)更適用于海量日志數(shù)據(jù)的實時處理進(jìn)程.平臺架構(gòu)主要包含5層,日志采集層利用Flume進(jìn)行數(shù)據(jù)采集,Flume是以一個典型分布式的日志采集系統(tǒng)[15].日志削峰層是利用Kafka對日志數(shù)據(jù)進(jìn)行削峰處理.日志處理層利用Flink對采集的數(shù)據(jù)進(jìn)行實時處理與計算,包括數(shù)據(jù)清洗、實時ETL（Extract-Transform-Load）以及實時預(yù)警.日志存儲層利用HBase進(jìn)行數(shù)據(jù)存儲.日志展示層利用Kibana進(jìn)行數(shù)據(jù)與計算結(jié)果的展示,平臺架構(gòu)如圖4所示.

圖4 海量日志實時處理平臺架構(gòu)圖

2.1.1 日志采集層

日志采集層將Flume與Kafka集群整合[15],其中,Flume是數(shù)據(jù)的傳輸者,可以源源不斷地將日志數(shù)據(jù)采集到端口上,但不會持久性地對數(shù)據(jù)進(jìn)行保存,僅以一個臨時性的緩存進(jìn)行保存,并利用sink將數(shù)據(jù)落地傳輸?shù)終afka消息隊列當(dāng)中.而Kafka作為消息隊列,除了接收來自Flume的日志數(shù)據(jù)外,還需對數(shù)據(jù)進(jìn)行削峰平谷.

該部分的整合思路是利用Flume對日志數(shù)據(jù)進(jìn)行采集并將其發(fā)送到Kafka消息隊列當(dāng)中.平臺采用Flume集群的方式進(jìn)行配置,核心是在Kafka創(chuàng)建一個實時處理平臺的Topic并將Flume采集到的日志數(shù)據(jù)發(fā)送到該Topic上即可.

具體的整合過程為:① 首先設(shè)定兩個Flume agent并部署于服務(wù)器上進(jìn)行數(shù)據(jù)采集.其次,將日志數(shù)據(jù)以下沉的方式發(fā)送到另一個新的Flume agent服務(wù)器上.② 配置完成后即可啟動Flume agent對日志數(shù)據(jù)進(jìn)行監(jiān)聽與傳輸; ③ 在Kafka中創(chuàng)建一個Topic來接收采集到的日志數(shù)據(jù).整合的原理如圖5所示.

圖5 Flume與Kafka整合工作流程圖

2.1.2 日志處理層

日志處理層是將Kafka與Flink結(jié)合,其原理是Flink對外提供了Kafka connectors用于讀取Kafka topic中的日志數(shù)據(jù),并且Kafka consumer與Flink的checkpoint機(jī)制相互結(jié)合后可以保障exactly-once的數(shù)據(jù)處理.為了能夠進(jìn)一步保證數(shù)據(jù)處理的唯一性,Flink自身也并非完全依賴于Kafka consumer的跟蹤模式,而是在Flink內(nèi)進(jìn)行跟蹤與檢查從而保證日志數(shù)據(jù)處理的唯一性.

具體的整合過程為:① Kafka consumer提供了一個（或多個）針對Kafka topic的訪問接口,其構(gòu)造函數(shù)對外接收相關(guān)的配置參數(shù)（包括:Kafka topic信息、Kafka brokers列表、Zookeeper服務(wù)器列表等,以保障連通性穩(wěn)定）.② Kafka consumer建立一個到Client端的連接來查詢Topic內(nèi)的日志數(shù)據(jù),完成后啟用Flink的checkpoint機(jī)制.③ Kafka consumer會從Kafka topic中的未消費的日志數(shù)據(jù)為起始,單向周期性地掃描Kafka的消息偏移量以及其他操作的狀態(tài).④ Flink將上述的內(nèi)容以流數(shù)據(jù)的形式存儲到checkpoint當(dāng)中,并繼續(xù)讀取Kafka隊列中新的數(shù)據(jù).整合過程如圖6所示.

圖6 Kafka與Flink整合工作流程圖

除了上述的基本集群整合外,為了保障平臺的優(yōu)勢性能,還需對Flink進(jìn)行額外的配置:① 由于海量日志數(shù)據(jù)的采集源各不相同,為了便于后續(xù)存儲需要在Flink job中對日志數(shù)據(jù)進(jìn)行統(tǒng)一化.具體步驟是利用grok（基于正則表達(dá)式）解析原日志數(shù)據(jù)的message字段并建立新的結(jié)構(gòu)來存儲統(tǒng)一的日志數(shù)據(jù).統(tǒng)一化后需要對數(shù)據(jù)進(jìn)行去重、臟數(shù)據(jù)等數(shù)據(jù)清洗,并將其轉(zhuǎn)換為LogEvent格式便于后續(xù)的存儲.③ 為了能夠?qū)θ罩緮?shù)據(jù)中的異常情況進(jìn)行實時告警,還需在Flink框架中設(shè)定Filter算子進(jìn)Error級日志過濾,過濾后的Error級日志數(shù)據(jù)將封裝為新的Event（即告警信息）,再由sink調(diào)用下游服務(wù)進(jìn)行告警.④ 為了進(jìn)一步優(yōu)化Flink針對海量日志處理的性能,在Flink中嵌入負(fù)載預(yù)測模型以及負(fù)載預(yù)測網(wǎng)絡(luò)便于對數(shù)據(jù)流量進(jìn)行預(yù)測以及資源的優(yōu)先調(diào)度.⑤ 為了能夠有效保障告警機(jī)制的正確運行,平臺在Flink源碼中設(shè)定樂觀容錯機(jī)制保障日志數(shù)據(jù)處理的適當(dāng)容錯性.

2.1.3 日志存儲層

日志存儲層利用HBase進(jìn)行數(shù)據(jù)存儲.除了對于日志數(shù)據(jù)的采集以及實時計算與處理外,還需將日志數(shù)據(jù)進(jìn)行存儲便于后續(xù)使用,所以該層將Flink與HBase進(jìn)行交互.Flink對此提供Flink HBase connector用于Flink從HBase數(shù)據(jù)庫中讀取或?qū)懭霐?shù)據(jù),其中Flink利用TableInputFormat讀取HBase中的批量數(shù)據(jù),以及利用TableOutputFormat向HBase中寫入數(shù)據(jù).

2.2 物流服務(wù)平臺海量日志實時處理平臺功能介紹

海量日志實時處理平臺除了日志的采集、傳輸、實時計算、存儲以及展示外,并基于Flink設(shè)計了日志數(shù)據(jù)去重、異常檢測及告警、容錯機(jī)制以及負(fù)載預(yù)測等功能.

2.2.1 日志數(shù)據(jù)實時去重

實時去重模塊通過選取Flink狀態(tài)后端的Rocks-DBStateBackend進(jìn)行數(shù)據(jù)集合的維護(hù),其狀態(tài)數(shù)據(jù)均存儲在Task manager本地機(jī)器的內(nèi)存和磁盤之上,便于對數(shù)據(jù)進(jìn)行實時的操作.為了保障大規(guī)模數(shù)據(jù)的全局去重,針對Flink的狀態(tài)需設(shè)置為KeyedState,設(shè)置完成后Flink將會對處理的數(shù)據(jù)通過RocksDB進(jìn)行掃描并利用KeyedState進(jìn)行日志數(shù)據(jù)主鍵的比對,從而保障日志數(shù)據(jù)處理的實時性以及唯一性.

2.2.2 異常日志檢測及實時告警

異常日志檢測及告警是利用Flink作業(yè)去實時處理Kafka隊列中的數(shù)據(jù)來進(jìn)行異常檢測的計算,具體是利用filter算子進(jìn)行異常日志的過濾,核心代碼為:

.filter（logEvent-> "error".equals（logEvent.getLevel（）））

過濾完成后將異常日志數(shù)據(jù)構(gòu)建成一個新的事件信息封裝成告警內(nèi)容,在下游進(jìn)行告警消息的發(fā)送,發(fā)出的應(yīng)用異常日志告警消息中會攜帶一個鏈接,通過該鏈接可以跳轉(zhuǎn)到對應(yīng)的異常日志信息.

2.2.3 日志數(shù)據(jù)處理容錯效率策略

日志數(shù)據(jù)處理容錯效率策略是基于補(bǔ)償函數(shù)的樂觀容錯機(jī)制.相較于Flink系統(tǒng)分布式快照的悲觀容錯機(jī)制,樂觀容錯機(jī)制無須耗費額外的時間開銷去進(jìn)行階段性檢查,從而具有更高的使用效率.同時,本文選用PageRank全量迭代算法的數(shù)據(jù)收集及數(shù)據(jù)處理接口,可以直接在Flink系統(tǒng)中調(diào)用,該算法機(jī)制的整體流程如圖7所示.

圖7 基于補(bǔ)償函數(shù)的樂觀容錯機(jī)制工作流程圖

2.2.4 實時負(fù)載預(yù)測及資源調(diào)度

為了能夠有效應(yīng)對實時計算負(fù)載的波動,本文通過量化集群資源來得出本階段內(nèi)的日志數(shù)據(jù)量,再利用負(fù)載預(yù)測模型來預(yù)測下一階段的日志數(shù)據(jù)量變動,最后針對下一階段的日志數(shù)據(jù)量進(jìn)行系統(tǒng)資源分配.為了在Flink的基礎(chǔ)上實現(xiàn)負(fù)載預(yù)測以及資源調(diào)度,需要在原Flink架構(gòu)上進(jìn)行優(yōu)化,具體的優(yōu)化方案為:

1）添加負(fù)載監(jiān)控節(jié)點:用于實時計算日志負(fù)載量,存入本地用于后續(xù)負(fù)載預(yù)測;

2）添加負(fù)載預(yù)測節(jié)點:執(zhí)行負(fù)載預(yù)測算法接口,結(jié)合得到的負(fù)載序列計算下一階段的負(fù)載波動情況;

3）添加資源調(diào)度節(jié)點:由Zookeeper集群承擔(dān),用于存儲負(fù)載預(yù)測的結(jié)果及資源調(diào)度方案,并實時執(zhí)行調(diào)度方案;

4）添加負(fù)載遷移節(jié)點:根據(jù)資源調(diào)度方案對節(jié)點狀態(tài)進(jìn)行修訂,從而完成資源在線調(diào)度.

3 實驗與結(jié)果分析

3.1 實驗環(huán)境

結(jié)合對于海量日志實時處理平臺的整體架構(gòu),平臺的具體部署環(huán)境如表1所示.

表1 平臺部署環(huán)境表

平臺部署完成后,對平臺的基本功能進(jìn)行測試,經(jīng)過測試可以得出平臺在日志數(shù)據(jù)采集、日志數(shù)據(jù)在消息隊列中的傳輸、日志基本實時處理以及日志存儲這幾個方面響應(yīng)正常且執(zhí)行次尋準(zhǔn)確.除以上的基本功能外,本文接下來將就其余創(chuàng)新功能進(jìn)行更為詳細(xì)的測試介紹.

3.2 海量日志去重效果測試

前文的功能設(shè)計中可以看出日志數(shù)據(jù)的去重是由日志數(shù)據(jù)“鍵”的沖突來進(jìn)行重復(fù)檢驗的,并利用RocksDB進(jìn)行日志數(shù)據(jù)的本地存儲,RocksDB具體的測試參數(shù)設(shè)置如表2所示.

表2 測試參數(shù)表

完成基礎(chǔ)的測試參數(shù)設(shè)定后,利用腳本隨機(jī)生成1萬條、10萬條、100萬條簡易日志數(shù)據(jù),分別對基于Flink狀態(tài)后端RocksDB的去重框架、基于MapReduce與HDFS的去重框架、基于Spark Streaming與Map-Reduce的去重框架以及基于單一HBase的全局去重框架進(jìn)行測試,測試的結(jié)果由（重復(fù)數(shù)據(jù)量,響應(yīng)時間）表示,測試結(jié)果如表3和表4所示.

從表3和表4中我們可以看出基于Flink狀態(tài)后端RocksDB的去重框架相較于基于MapReduce與HDFS的去重框架、基于Spark Streaming與MapReduce的去重框架具有更高的去重準(zhǔn)確率,且相較于直接存儲于數(shù)據(jù)庫進(jìn)行主鍵對比的HBase具有更快的響應(yīng)速度,故通過測試結(jié)果可以看出本文基于Flink狀態(tài)后端RocksDB的去重框架具有較為優(yōu)良的效率.

表3 不同框架下的數(shù)據(jù)重復(fù)量（條）

表4 不同框架下去重的響應(yīng)時間（ms）

3.3 異常日志檢測及告警效果測試

本文對Error級別的日志數(shù)據(jù)處理采用了在Flink中內(nèi)嵌filter算子進(jìn)行告警的方式,告警的信息是通過Flink下游的封裝后通過郵件的方式進(jìn)行告警.實驗選取Crontab指定腳本定時執(zhí)行Error級日志編寫與發(fā)送,實時監(jiān)測郵件端的報警情況,以其中一次的郵件報警結(jié)果為例,如圖8所示.

圖8 日志處理平臺實時告警測試結(jié)果圖

結(jié)合100輪次的腳本測試結(jié)果,可以得出基于Flink內(nèi)嵌filter算子的告警模式響應(yīng)平均時間在7.8 ms且郵件發(fā)送間隔在3 s內(nèi),測試結(jié)果可以滿足“實時告警”的響應(yīng)需求,相較基于Filebeat+Kafka+Storm的日志實時處理架構(gòu)的告警響應(yīng)速度提升幅度接近一倍.

3.4 日志數(shù)據(jù)處理容錯效率測試

本文對Flink底層源碼進(jìn)行調(diào)整后進(jìn)行了容錯效率的測試,測試所采用的數(shù)據(jù)集為Facebook頁面日志數(shù)據(jù)集gemsec-Facebook、霍林斯大學(xué)教育網(wǎng)頁日志數(shù)據(jù)集Hollins以及維基百科網(wǎng)頁的日志數(shù)據(jù)集Wikitopcats,3個數(shù)據(jù)集均符合補(bǔ)償?shù)惴≒ageRank的計算范疇.本文從正確性測試、恢復(fù)性能測試以及迭代恢復(fù)時長測試這3個角度對樂觀容錯機(jī)制及Flink原有的悲觀容錯機(jī)制進(jìn)行比對,測試的具體結(jié)果如表5所示.從測試結(jié)果可以看出,經(jīng)過優(yōu)化的容錯機(jī)制相較于原Flink內(nèi)嵌的悲觀容錯機(jī)制具有更高的恢復(fù)準(zhǔn)確性、更短的恢復(fù)迭代次數(shù)以及更短的恢復(fù)時間.

表5 日志數(shù)據(jù)處理容錯效率測試結(jié)果表

3.5 實時負(fù)載預(yù)測及資源調(diào)度效果測試

本文對Flink底層源碼進(jìn)行優(yōu)化后進(jìn)行了負(fù)載預(yù)測及資源調(diào)度測試,選用1個Job manager節(jié)點、6個Task manager節(jié)點、3個節(jié)點構(gòu)成的Kafka與Zookeeper集群,具體的測試參數(shù)設(shè)置如表6所示.

表6 實時負(fù)載預(yù)測及資源調(diào)度效果測試

從預(yù)測算法性能以及調(diào)度響應(yīng)時間這兩個測評標(biāo)準(zhǔn)對優(yōu)化的Flink調(diào)度策略、原Flink調(diào)度策略以及Elastic Nephel調(diào)度策略進(jìn)行測試,測試的環(huán)境是利用腳本編寫了負(fù)載波動的日志傳輸情況,具體的測試結(jié)果如圖9所示.

從圖9的測試結(jié)果可以看出,優(yōu)化后的Flink調(diào)度策略相較于原Flink的調(diào)度策略從算法的偏差值方面具有低的偏差值,且在調(diào)度響應(yīng)時間角度Flink優(yōu)化調(diào)度策略具有更低的響應(yīng)時間.

圖9 日志容錯效率測試結(jié)果圖

4 結(jié)論與展望

本文實現(xiàn)了基于Flink+HBase的物流服務(wù)平臺海量日志數(shù)據(jù)實時處理平臺.平臺除了實現(xiàn)基本的數(shù)據(jù)采集、消息隊列傳輸、日志實時處理（ETL）以及日志實時存儲外,還在日志處理環(huán)節(jié)對Kafka及Flink的具體連接方式以及底層源碼進(jìn)行了優(yōu)化,并設(shè)計了大規(guī)模日志數(shù)據(jù)去重、實時告警、樂觀容錯機(jī)制以及彈性調(diào)度的功能,使得平臺更加完善.相較于原Flink的基礎(chǔ)框架以及功能,平臺具有更優(yōu)良的性能及更快速的響應(yīng)時間,并添加了新的功能模塊設(shè)計.在下一步的研究工作中,將會利用實際日志數(shù)據(jù)替代腳本數(shù)據(jù)進(jìn)行測試,并根據(jù)實際測試結(jié)果進(jìn)行深入的優(yōu)化.