隨著大數(shù)據(jù)應(yīng)用的發(fā)展，人們對實時數(shù)據(jù)的要求越來越高，大數(shù)據(jù)也逐漸從最初的離線數(shù)據(jù)倉庫架構(gòu)發(fā)展到Labmda架構(gòu)，實現(xiàn)了離線實時更新的目標(biāo)。到后來的Kappa體系結(jié)構(gòu)中，Labmda體系結(jié)構(gòu)的實時部分被提取出來單獨運行。實時大數(shù)據(jù)時代已經(jīng)到來，本文在此背景下介紹了一種基于Kappa體系結(jié)構(gòu)的多源異構(gòu)數(shù)據(jù)實時處理與分析體系結(jié)構(gòu)。

一、架構(gòu)介紹

下圖為基于Kappa架構(gòu)的多源異構(gòu)數(shù)據(jù)實時處理分析體系結(jié)構(gòu)，如圖所示，它主要包括數(shù)據(jù)采集、流數(shù)據(jù)處理、流數(shù)據(jù)存儲、數(shù)據(jù)服務(wù)四個環(huán)節(jié)，其中數(shù)據(jù)服務(wù)沒有固定的結(jié)構(gòu)，在不同的業(yè)務(wù)場景變化很大。以下主要介紹了三個環(huán)節(jié)：數(shù)據(jù)采集、流數(shù)據(jù)處理和流數(shù)據(jù)存儲。

1、數(shù)據(jù)采集

采用ELK構(gòu)件結(jié)構(gòu)實現(xiàn)數(shù)據(jù)采集，其中Logstash接收多源異構(gòu)數(shù)據(jù)并同時發(fā)送到消息隊列進行流數(shù)據(jù)處理，ElasticSearch用于源數(shù)據(jù)存儲。Logstash支持多種傳輸模式，包括TCP、UDP、JDBC和Kafka等，它還支持多源數(shù)據(jù)的類型驗證，并在初期過濾不符合規(guī)范的異構(gòu)數(shù)據(jù)。Kibana是ElasticSearch的可視化查詢工具，能夠使用組合嵌套查詢語句全局查詢ElasticSearch中的數(shù)據(jù)。

2、流數(shù)據(jù)處理

Flink實時流計算引擎用于實現(xiàn)流數(shù)據(jù)處理，訂閱發(fā)送到第一個鏈路Logstash的消息隊列，從消息隊列中獲取多源異構(gòu)數(shù)據(jù)，并根據(jù)業(yè)務(wù)需求進行數(shù)據(jù)過濾、重復(fù)數(shù)據(jù)刪除、補全、格式轉(zhuǎn)換、索引提取等ETL操作。格式化數(shù)據(jù)和指標(biāo)數(shù)據(jù)經(jīng)過ETL后可以繼續(xù)用于統(tǒng)計分析、匹配算法，實現(xiàn)業(yè)務(wù)需求的畫像、預(yù)測等結(jié)果數(shù)據(jù)。

3、流數(shù)據(jù)存儲

流數(shù)據(jù)存儲也采用ELK組件結(jié)構(gòu)，它不僅存在于整個建筑的尾部，也存在于建筑的中間環(huán)節(jié)。在第一個環(huán)節(jié)中，Lostash將數(shù)據(jù)傳輸?shù)较㈥犃谢驅(qū)⑵浯鎯Φ紼lasticSearch，兩者都是流數(shù)據(jù)存儲。在第二個環(huán)節(jié)中，中間階段的數(shù)據(jù)需要推送到消息隊列中，同時存儲到ElasticSearch中，推送到消息隊列用于中間存儲，便于后續(xù)處理流程訂閱數(shù)據(jù)進行業(yè)務(wù)處理，存儲到ElasticSearch中則是傳統(tǒng)數(shù)倉架構(gòu)中中間表留存的思維，用于中間數(shù)據(jù)的存儲和查詢。第二環(huán)節(jié)處理后的結(jié)果數(shù)據(jù)根據(jù)需要可不推送到消息隊列，只進行ElasticSearch存儲。

二、關(guān)鍵技術(shù)點

多源異構(gòu)數(shù)據(jù)的實時處理分析架構(gòu)中最為復(fù)雜和難以設(shè)計的是第二環(huán)節(jié)流數(shù)據(jù)處理。采用Flink實現(xiàn)流數(shù)據(jù)處理的方法是豐富多樣的，可能存在的問題也是多種多樣的。為了減少問題出現(xiàn)的概率，本文介紹以下兩種維持Flink穩(wěn)定高效運行的優(yōu)化解決方案。

1、檢查點重啟策略

由于各種原因，F(xiàn)link流數(shù)據(jù)處理任務(wù)可能會中斷。為了實現(xiàn)因故障中斷的任務(wù)的自動重啟，保證系統(tǒng)的魯棒性，需要配置檢查點重啟策略。其原理是定期對Flink任務(wù)進行快照，當(dāng)任務(wù)由于故障而中斷時，如果配置了重啟策略，程序?qū)淖钚碌目煺瘴恢没謴?fù)。

當(dāng)然，檢查點重新啟動策略只是一種故障安全策略，重新啟動只能解決部分問題，還有許多問題是重新啟動無法解決的。在這種情況下，任務(wù)會反復(fù)重啟，直到重啟次數(shù)超過設(shè)置的限制而出現(xiàn)中斷，這時就需要工程師來手動解決。

2、內(nèi)存模型優(yōu)化

下圖顯示了Flink任務(wù)運行時容器的內(nèi)存模型。當(dāng)Flink任務(wù)啟動時，將啟用一個嚴(yán)格按照下圖內(nèi)存模型分配內(nèi)存的容器。一般情況下，默認(rèn)的內(nèi)存分配無法支持生產(chǎn)環(huán)境下的任務(wù)運行，因此每位大數(shù)據(jù)工程師都應(yīng)該掌握內(nèi)存分配技能，以支持業(yè)務(wù)任務(wù)的運行。

但是僅僅支持運行是遠遠不夠的，內(nèi)存分配的合理程度對系統(tǒng)的穩(wěn)定性和魯棒性有著巨大的影響。例如，若集群之間的網(wǎng)絡(luò)交換速度是系統(tǒng)的瓶頸，短時間內(nèi)的大量數(shù)據(jù)吞吐可能會導(dǎo)致交換內(nèi)存占滿，無法進行數(shù)據(jù)交換導(dǎo)致任務(wù)中斷。在這種情況下，可以通過增加網(wǎng)絡(luò)交換內(nèi)存來提高瓶頸的吞吐量，避免系統(tǒng)故障。

三、總結(jié)

本文介紹了多源異構(gòu)數(shù)據(jù)實時處理與分析體系結(jié)構(gòu)的流程結(jié)構(gòu)并闡述了兩種保持系統(tǒng)穩(wěn)定性和魯棒性的關(guān)鍵技術(shù)。該架構(gòu)可以應(yīng)用于各種生產(chǎn)業(yè)務(wù)場景，目前鵬信科技已將該架構(gòu)應(yīng)用于態(tài)勢、反詐、研判等安全項目，支撐項目穩(wěn)定高效運行，效果顯著。

來源：【鵬信科技】微信公眾號