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

很有幸的是，在大數據前我負責了內部 debezium 相關的維護開發(fā)，所以也會帶上數據庫的變更。

目錄

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

概述

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

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

下面根據每個模塊介紹一下吧

日志采集端

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

幾個問題

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

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

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

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

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

應該沒了。。

解決問題

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

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

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

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

其它

還有還有，1.1.0的kafka也有問題，當網絡丟包非常高的時候，并且fb配置了ack，kafka會返回給客戶端ack失敗，導致連接未關閉，kafka OOM。

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

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

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

日志處理

日志拆分

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

埋點日志處理

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

其它

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

數據庫變更流采集

數據庫的變更使用的是debezium，這個我就不多講了，debezium現在越來越火了，當時才幾百顆star，現在都好幾千了。
debezium的坑和經驗我以前都有寫過。

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

實時計算平臺

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

實時用戶行為/屬性

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

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

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

其它

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。