实时日志/数据库采集处理，实时用户行为属性个人总结

好久没写博客了，做了一段时间的日志采集和流处理，总结一下自己的工作吧。本人只涉及了一些总结，很多技术细节我也不会多说吧。

很有幸的是，在大数据前我负责了内部 debezium 相关的维护开发，所以也会带上数据库的变更。

概述

下图是目前我经手的整个实时流的内容（图里经过简化，抹去了一些内部的信息，不包括监控系统）

本人目前参与了日志采集到提供实时数据整条链路，曾经参与过debezium实时获取mysql变更的工作。

下面根据每个模块介绍一下吧

日志采集端

日志采集这件事花了我半年时间，非常累。原有的公司日志采集使用的是Flume(可能只是名字叫Flume，代码已经基本被魔改了一遍)，原本由监控团队提供，后来开始大规模迁移到filebeat。迁移的规模在5000台以上。

几个问题

Filebeat的引入目前我觉得是不合理的，Filebeat并没有非常的优雅，说几个FileBeat的缺点：

1. 它占用的客户端CPU比较高。使用gzip的压缩算法，4c的机器，CPU能用到20%。
2. 由于内部的机房特殊性，机房间的专线有带宽限制，如果Filebeat使用snappy压缩算法，虽然cpu到了12%-13%，但是他的压缩比太低，导致专线带宽跑满。
3. FileBeat这玩意真的是没有限速，太坑了。日志越多，cpu吃的越多。
4. 因为特殊的机房架构，kafka发生不稳定时，filebeat的客户端内存占用越来越高，非常的离谱，感觉日志都堆积在内存里，又没有java可以通过xmx设置堆大小，过大直接挂掉。
5. 应该没了。。

解决问题

为了解决上面的问题，在日志采集模块，开发了一套完整的自动化运维系统:

• 定时更新 filebeat 采集规则。
• 定时监控 filebeat 客户端内存使用，过大时杀掉进程。
• 定时监控filebeat采集状况，自动恢复。
• 自动部署新机器。
• 没了吧。。

具体我就不扩展整个自动运维系统以及修改的代码了。：）

为了解决CPU过高的问题，改了一些代码(我实在是不喜欢 go 语言，改的我真难受)，不使用kafka的gzip压缩，而是在代码里，自己使用gzip批量日志，发到kafka，cpu从原有的20%以上到了16%左右。

其它

还有还有，1.1.0的kafka也有问题，当网络丢包非常高的时候，并且fb配置了ack，kafka会返回给客户端ack失败，导致连接未关闭，kafka OOM。

不建议通过filebeat在客户端做日志的拆分，占用cpu会比较多，影响服务的稳定性。

内部的k8s集群也用的是filebeat，一个filebeat daemonset pod采集了几十个服务的日志。。。别。。诶，cpu占用可真高，都是泪。

(ps:说实话让我再迁移一边日志采集器，我绝对拒绝，太恶心了)

日志处理

日志拆分

因为监控系统和大数据属于不同的业务组，所以我们提前拆分了日志，通过flink任务，将日志拆分为埋点日志和其它类型日志，监控系统会消费所有的日志数据，大数据会消费埋点日志（埋点日志是大数据的命脉啊）。

埋点日志处理

实时埋点处理任务会消费埋点数据，根据埋点系统注册的信息，将埋点日志拆分到各个埋点topic。下游的实时计算平台，会消费埋点日志，经过一系列的实时处理，写入es，业务组通过soa调用内部后台或者直查es，获取实时用户行为数据。

其它

这一块其实还有别的东西，比如数据量监控，数据延迟等。宏观的说非常监控，就是日志处理，但是周边的系统还是很大的。需要有一套完整的埋点注册服务，兼容实时和离线埋点数据。

数据库变更流采集

数据库的变更使用的是debezium，这个我就不多讲了，debezium现在越来越火了，当时才几百颗star，现在都好几千了。
debezium的坑和经验我以前都有写过。

用户的实时属性，通过dbz和实时计算平台写入es，提供给业务方。

实时计算平台

这部分我不会多说，因为非常庞大，就只是简单的概述。
内部有一套基于flink的实时计算平台，能够消费数据库变更流和日志流，用户可以提供udf，也可以在计算平台通过鼠标配置算子，达到自己想要的流处理结果，计算平台支持写入多种存储系统。（还未SQL化）

实时用户行为/属性

每个用户的行为，需要注册成埋点，通过上述的多个模块，业务方可以通过es实时的获取用户的行为，用来做一些搜索推荐/优化等。

这部分目前没有做的很好，没有和离线那边关联好，感觉需要一个元数据系统，管理好离线和实时的数据schema。

实时用户属性，通过实时的数据库变更流获取，同样也是写入es，提供给业务方。

其它

这一块内容非常的多，很多东西也说不清楚，只能大概的说一下了，记录一下自己之前一段时间的工作吧。最近非常忙，真的很忙。整条实时链路还有一些黑盒存在，需要填坑。

大数据系统有些还不是很熟悉，也需要加油。：）