好久沒寫博客了，做了一段時間的日志采集和流處理，總結(jié)一下自己的工作吧。本人只涉及了一些總結(jié)，很多技術(shù)細(xì)節(jié)我也不會多說吧。

很有幸的是，在大數(shù)據(jù)前我負(fù)責(zé)了內(nèi)部 debezium 相關(guān)的維護(hù)開發(fā)，所以也會帶上數(shù)據(jù)庫的變更。

目錄

• 概述
• 日志采集端
• • • 幾個問題
    • 解決問題
    • 其它
• 日志處理
• • • 日志拆分
    • 埋點日志處理
    • 其它
• 數(shù)據(jù)庫變更流采集
• 實時計算平臺
• 實時用戶行為/屬性
• 其它

概述

下圖是目前我經(jīng)手的整個實時流的內(nèi)容（圖里經(jīng)過簡化，抹去了一些內(nèi)部的信息，不包括監(jiān)控系統(tǒng)）

本人目前參與了日志采集到提供實時數(shù)據(jù)整條鏈路，曾經(jīng)參與過debezium實時獲取mysql變更的工作。

下面根據(jù)每個模塊介紹一下吧

日志采集端

日志采集這件事花了我半年時間，非常累。原有的公司日志采集使用的是Flume(可能只是名字叫Flume，代碼已經(jīng)基本被魔改了一遍)，原本由監(jiān)控團(tuán)隊提供，后來開始大規(guī)模遷移到filebeat。遷移的規(guī)模在5000臺以上。

幾個問題

Filebeat的引入目前我覺得是不合理的，Filebeat并沒有非常的優(yōu)雅，說幾個FileBeat的缺點：

它占用的客戶端CPU比較高。使用gzip的壓縮算法，4c的機(jī)器，CPU能用到20%。

由于內(nèi)部的機(jī)房特殊性，機(jī)房間的專線有帶寬限制，如果Filebeat使用snappy壓縮算法，雖然cpu到了12%-13%，但是他的壓縮比太低，導(dǎo)致專線帶寬跑滿。

FileBeat這玩意真的是沒有限速，太坑了。日志越多，cpu吃的越多。

因為特殊的機(jī)房架構(gòu)，kafka發(fā)生不穩(wěn)定時，filebeat的客戶端內(nèi)存占用越來越高，非常的離譜，感覺日志都堆積在內(nèi)存里，又沒有java可以通過xmx設(shè)置堆大小，過大直接掛掉。

應(yīng)該沒了。。

解決問題

為了解決上面的問題，在日志采集模塊，開發(fā)了一套完整的自動化運(yùn)維系統(tǒng):

• 定時更新 filebeat 采集規(guī)則。
• 定時監(jiān)控 filebeat 客戶端內(nèi)存使用，過大時殺掉進(jìn)程。
• 定時監(jiān)控filebeat采集狀況，自動恢復(fù)。
• 自動部署新機(jī)器。
• 沒了吧。。

具體我就不擴(kuò)展整個自動運(yùn)維系統(tǒng)以及修改的代碼了。：）

為了解決CPU過高的問題，改了一些代碼(我實在是不喜歡 go 語言，改的我真難受)，不使用kafka的gzip壓縮，而是在代碼里，自己使用gzip批量日志，發(fā)到kafka，cpu從原有的20%以上到了16%左右。

其它

還有還有，1.1.0的kafka也有問題，當(dāng)網(wǎng)絡(luò)丟包非常高的時候，并且fb配置了ack，kafka會返回給客戶端ack失敗，導(dǎo)致連接未關(guān)閉，kafka OOM。

不建議通過filebeat在客戶端做日志的拆分，占用cpu會比較多，影響服務(wù)的穩(wěn)定性。

內(nèi)部的k8s集群也用的是filebeat，一個filebeat daemonset pod采集了幾十個服務(wù)的日志。。。別。。誒，cpu占用可真高，都是淚。

(ps:說實話讓我再遷移一邊日志采集器，我絕對拒絕，太惡心了)

日志處理

日志拆分

因為監(jiān)控系統(tǒng)和大數(shù)據(jù)屬于不同的業(yè)務(wù)組，所以我們提前拆分了日志，通過flink任務(wù)，將日志拆分為埋點日志和其它類型日志，監(jiān)控系統(tǒng)會消費所有的日志數(shù)據(jù)，大數(shù)據(jù)會消費埋點日志（埋點日志是大數(shù)據(jù)的命脈啊）。

埋點日志處理

實時埋點處理任務(wù)會消費埋點數(shù)據(jù)，根據(jù)埋點系統(tǒng)注冊的信息，將埋點日志拆分到各個埋點topic。下游的實時計算平臺，會消費埋點日志，經(jīng)過一系列的實時處理，寫入es，業(yè)務(wù)組通過soa調(diào)用內(nèi)部后臺或者直查es，獲取實時用戶行為數(shù)據(jù)。

其它

這一塊其實還有別的東西，比如數(shù)據(jù)量監(jiān)控，數(shù)據(jù)延遲等。宏觀的說非常監(jiān)控，就是日志處理，但是周邊的系統(tǒng)還是很大的。需要有一套完整的埋點注冊服務(wù)，兼容實時和離線埋點數(shù)據(jù)。

數(shù)據(jù)庫變更流采集

數(shù)據(jù)庫的變更使用的是debezium，這個我就不多講了，debezium現(xiàn)在越來越火了，當(dāng)時才幾百顆star，現(xiàn)在都好幾千了。
debezium的坑和經(jīng)驗我以前都有寫過。

用戶的實時屬性，通過dbz和實時計算平臺寫入es，提供給業(yè)務(wù)方。

實時計算平臺

這部分我不會多說，因為非常龐大，就只是簡單的概述。
內(nèi)部有一套基于flink的實時計算平臺，能夠消費數(shù)據(jù)庫變更流和日志流，用戶可以提供udf，也可以在計算平臺通過鼠標(biāo)配置算子，達(dá)到自己想要的流處理結(jié)果，計算平臺支持寫入多種存儲系統(tǒng)。（還未SQL化）

實時用戶行為/屬性

每個用戶的行為，需要注冊成埋點，通過上述的多個模塊，業(yè)務(wù)方可以通過es實時的獲取用戶的行為，用來做一些搜索推薦/優(yōu)化等。

這部分目前沒有做的很好，沒有和離線那邊關(guān)聯(lián)好，感覺需要一個元數(shù)據(jù)系統(tǒng)，管理好離線和實時的數(shù)據(jù)schema。

實時用戶屬性，通過實時的數(shù)據(jù)庫變更流獲取，同樣也是寫入es，提供給業(yè)務(wù)方。

其它

這一塊內(nèi)容非常的多，很多東西也說不清楚，只能大概的說一下了，記錄一下自己之前一段時間的工作吧。最近非常忙，真的很忙。整條實時鏈路還有一些黑盒存在，需要填坑。

大數(shù)據(jù)系統(tǒng)有些還不是很熟悉，也需要加油。：）

總結(jié)

以上是生活随笔為你收集整理的实时日志/数据库采集处理，实时用户行为属性个人总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。