實(shí)戰(zhàn)：如何實(shí)時(shí)采集上億級(jí)別數(shù)據(jù)？
背景介紹
- 公司業(yè)務(wù)系統(tǒng)做優(yōu)化改造，同時(shí)為了能夠?qū)崿F(xiàn)全鏈路監(jiān)控，需收集所有業(yè)務(wù)系統(tǒng)之間的調(diào)用日志。
- 數(shù)據(jù)情況:每天20億+
- 機(jī)器成本:3臺(tái)kafka集群，2臺(tái)logstash采集機(jī)器
- 技術(shù):Java,MQ,MLSQL,Logstash
下圖為最終結(jié)果圖
采集流程
流程分解
流程一：MLSQL 消費(fèi)MQ
原始日志產(chǎn)生側(cè)通過protobuf進(jìn)行序列化推送至mq,然后通過MLSQL進(jìn)行反序列化并進(jìn)行簡單的etl處理后，再推送至MQ
流程二：通過Logstash進(jìn)行消費(fèi)MQ
通過logstash消費(fèi)經(jīng)過MLSQL處理后的數(shù)據(jù)，并在這里通過ruby進(jìn)行再次的加工處理，最后寫入es和hdfs
注意：這里一部分流程推送到es是業(yè)務(wù)側(cè)使用，而另一部分寫入hdfs是提供給數(shù)倉使用
流程三: 數(shù)倉建模
這里通過數(shù)倉建模，將最后的指標(biāo)結(jié)果推送至es提供給業(yè)務(wù)側(cè)使用
注意：本篇主要是借鑒這個(gè)需求講解Logstash在實(shí)際場景中的使用以及優(yōu)化，其他兩個(gè)部分流程不做詳細(xì)講解
為什么這樣設(shè)計(jì)?
原因一：
首先這個(gè)需求屬于日志采集的范疇，但Logstash本身不支持反序列化功能，需要自定義開發(fā)ruby插件來支持，但這樣一來開發(fā)成本較高，且不好維護(hù)，所以使用了MLSQL結(jié)合UDF的方式進(jìn)行流式處理
原因二：
大家在對最后的輸出流程可能會(huì)有疑惑，為什么不直接通過MLSQL來寫入到hdfs和es呢，這里有兩點(diǎn)：
- MLSQL寫入hdfs會(huì)產(chǎn)生大量的小文件，需要單獨(dú)開發(fā)合并文件的功能
- 最后寫入es的數(shù)據(jù)是需要數(shù)倉結(jié)合其他業(yè)務(wù)數(shù)據(jù)進(jìn)行建模的，而MLSQL在這點(diǎn)做的不太好，所以這里走的是離線處理的方式
說到這里，具體的場景需要結(jié)合公司的實(shí)際情況來進(jìn)行決策的，有些同學(xué)或許會(huì)想為什么不用flume進(jìn)行日志采集呢?那這里就不做過多的解釋了，白菜蘿卜各有所愛，適合自己的才是最好的!廢話不多說，接下來進(jìn)入正題，結(jié)合該需求場景，如何使用較少的成本完成大數(shù)據(jù)量的采集呢?以及如何優(yōu)化呢?
Logstash開發(fā)流程
1.確定日志格式
首先呢，一個(gè)日志文件里肯定是不止一種日志格式，也有可能是標(biāo)準(zhǔn)化的格式，這里需要跟日志產(chǎn)生側(cè)進(jìn)行確認(rèn)格式
2.調(diào)試grok
確定好日志格式后，編寫grok語法，然后進(jìn)行調(diào)試，本人是通過kibana6自帶的grok debug進(jìn)行調(diào)試。結(jié)合該需求背景，最后經(jīng)過logstash采集的時(shí)候，其實(shí)已經(jīng)通過MLSQL進(jìn)行了處理，最后Logstash消費(fèi)的是格式就是一個(gè)json字符串，所以不需要grok語法，但是這里還是簡單舉個(gè)例子來說明一下
3.調(diào)試ruby
結(jié)合該需求，使用ruby進(jìn)行一些清洗邏輯
4.優(yōu)化
這里優(yōu)化的工作在整個(gè)需求開發(fā)周期的比例較大，因?yàn)閿?shù)據(jù)量較大，且資源比較少，具體優(yōu)化思路如下：
1.MLSQL優(yōu)化
這部分的優(yōu)化工作主要是在反序化這塊，剔除了一部分無用字段，以及提前過濾了一部分?jǐn)?shù)據(jù)量，這里給出一部分注冊UDF的代碼
2.Kafka端優(yōu)化
因kafka集群是集團(tuán)共用,所以kafka端的優(yōu)化其實(shí)只涉及到消費(fèi)端的優(yōu)化。這里只調(diào)節(jié)了兩個(gè)參數(shù)
- ：數(shù)據(jù)壓縮
- ：消費(fèi)者線程數(shù)
3.hdfs優(yōu)化
logstash寫入hdfs的部分不用使用自帶的webhdfs插件，而是自定義的插件。
因自定義插件中涉及到文件鎖的問題，會(huì)通過比對前后兩次文件是否一致來進(jìn)行文件最后的刷寫，所以這里只能通過減少文件的更新頻率來減少上下文的切換以及刷寫操作
4.ES優(yōu)化
es部分的優(yōu)化也只是涉及到寫優(yōu)化，比如批量寫入、調(diào)大線程數(shù)、增加refresh間隔、禁止swapping交換內(nèi)存、禁止refresh和replica操作，調(diào)大index buffer等操作。
