数据采集层：埋点技术、日志采集、消息队列（Kafka）入门
数据采集是整个实时风控链路的第一道关卡。说白了，你后面模型再牛、规则再准，数据没采上来或者采错了，一切都是白搭。我在风控系统里踩过最大的坑，十有八九都出在这一层。
这一章我们聚焦三件事：埋点怎么设计、日志怎么稳定地收上来、以及Kafka这个“水管”到底该怎么接。嗯，咱们一个一个说。
埋点技术：数据源头怎么“种”下去
埋点，就是在你的应用里安插“传感器”。用户点了什么、页面加载了多久、输入框里填了什么——这些原始行为，都得靠埋点变成一条条可处理的数据。
我个人习惯把埋点分成三类，你根据场景选就行：
| 类型 | 实现方式 | 典型场景 | 我踩过的坑 |
|---|---|---|---|
| 代码埋点 | 在业务代码里手动调用SDK | 关键业务事件（下单、支付） | 漏埋、版本迭代后忘记迁移 |
| 全埋点（无埋点） | 自动采集所有用户交互 | 页面浏览、点击热力图 | 数据量爆炸，存储成本飙升 |
| 可视化埋点 | 通过后台配置圈选元素 | 运营活动、A/B测试 | 圈选规则随页面改版失效 |
对于实时风控，我强烈建议你以代码埋点为主。为什么？因为风控需要精确的语义——你得知道这条数据是“支付成功”还是“支付失败”，全埋点给不了这个粒度。
核心原则：埋点数据必须包含“谁、什么时间、在哪儿、干了什么、结果如何”这五个要素。少一个，后面做特征计算时就得多写一堆脏逻辑。
举个例子，一个标准的支付事件埋点，大概长这样：
{
"event_id": "evt_20250321142301_abc123",
"event_type": "payment_submit",
"timestamp": 1742545381000,
"user_id": "u_887654",
"device_id": "d_iphone15pro_xxxx",
"properties": {
"order_id": "ord_20250321_998877",
"amount": 1299.00,
"currency": "CNY",
"payment_method": "wechat_pay",
"result": "success"
},
"context": {
"ip": "114.114.114.114",
"user_agent": "Mozilla/5.0 ...",
"page_url": "https://shop.example.com/checkout"
}
}注意那个 event_id，必须全局唯一。我曾经因为没加这个字段，导致下游做去重时全靠时间戳+用户ID拼凑，结果同一笔支付被重复计算了三次——风控直接误杀了两个正常用户。教训惨痛。
日志采集：从业务服务器到Kafka的“最后一公里”
埋点数据落到了日志文件里，接下来怎么把它搬到Kafka？这里有两个主流方案。
方案一：Filebeat + Kafka（轻量级，推荐）
Filebeat是Elastic家的轻量采集器。它不占多少资源，适合部署在业务服务器上。我习惯的配置思路是：
- 每个业务实例部署一个Filebeat进程
- Filebeat监听日志文件的新增行，逐行读取
- 读到后直接推给Kafka的指定Topic
- Filebeat内部自带背压机制，Kafka写慢了它会自动降速
一个小技巧：Filebeat的harvester_buffer_size默认是16KB。如果你的单条日志特别大（比如带了完整的HTTP请求体），记得调大这个值，否则日志会被截断。我一般设到64KB。
方案二：Logstash（重型，适合需要复杂清洗的场景）
Logstash功能更强，但吃内存也更多。如果你需要在采集阶段做字段解析、格式转换、甚至调用外部API做IP地理信息解析，那Logstash更合适。
不过我得提醒你：不要在采集层做太重的逻辑。采集层的核心任务是“稳定、快速地搬数据”，清洗和转换应该交给下游的流处理引擎。你想想看，如果采集层挂了，整个风控链路就断了——这个风险不值得冒。
消息队列（Kafka）入门：风控数据的水管
Kafka在风控链路里扮演的角色，就是一根巨大的、高吞吐的、可回溯的水管。业务数据从各个服务流进来，风控引擎从另一端接走。中间哪怕某个消费者挂了，数据也不会丢——这是Kafka最值钱的地方。
几个你必须搞懂的核心概念
| 概念 | 一句话解释 | 风控场景里的角色 |
|---|---|---|
| Topic | 数据流的名字，类似数据库里的表 | 一个Topic对应一类事件，比如“支付事件Topic” |
| Partition | Topic的分片，数据真正存储的地方 | 分区数决定了Kafka的并行处理能力 |
| Offset | 消息在分区里的序号 | 风控系统重启后，从上次的Offset继续消费，保证不丢 |
| Consumer Group | 一组消费者的逻辑分组 | 风控引擎的多个实例组成一个Group，分摊处理压力 |
注意：Kafka不保证全局有序，只保证单个Partition内有序。如果你的风控规则要求“同一个用户的请求必须按顺序处理”，那就要按用户ID做分区策略——把同一个用户的所有事件路由到同一个Partition。我见过有人没注意这个，结果用户先触发了“支付成功”事件，后触发了“支付发起”事件，风控规则直接算错了。
Topic和Partition怎么规划？
我个人习惯按事件类型分Topic。比如：
topic_user_action：用户行为事件（点击、浏览）topic_trade_event：交易事件（下单、支付、退款）topic_risk_feedback：风控结果反馈（命中规则、人工审核结果）
每个Topic的分区数，我一般按预估峰值吞吐量 ÷ 单个分区吞吐量来算。单个分区每秒能处理多少条？实测下来，在普通配置的Kafka集群上，单分区写吞吐大约在5~10MB/s，读吞吐更高。你按这个估算，再留30%的余量就行。
一张图看懂数据采集层
下面这张图，把埋点、采集、Kafka这三块串起来了。你盯着看一分钟，整个链路就清楚了。
避坑指南：我在这层摔过的跟头
做数据采集层，有几个坑你最好提前知道。都是我用线上事故换来的经验。
坑一：埋点数据格式不一致。 同一个事件，iOS端发的字段名叫user_id，Android端叫uid，后端日志里叫userId。下游做特征计算时，得写三套解析逻辑。我的建议是：提前定好数据协议，用JSON Schema做校验，格式不对的直接发到死信队列，别让它污染主链路。
坑二：Kafka分区数设少了。 业务量涨起来之后，单分区成了瓶颈，消费端积压越来越严重。Kafka的分区数只能增加，不能减少。所以一开始就按峰值预估的2倍来设，别省。
坑三：采集层没有监控。 我曾经有一次Filebeat因为磁盘空间写满而停摆，整整两个小时没有采集到任何数据。风控引擎那边静悄悄地跑着，但处理的全是旧数据。后来我养成了一个习惯：给采集层加三个核心指标——采集延迟（当前时间 - 日志时间）、采集速率（每秒多少条）、采集错误数。这三个指标一上，心里就有底了。
小结
数据采集层，说白了就是三个动作：埋下去、收上来、传出去。埋点要精确，采集要稳定，Kafka要扛得住。这一层做好了，后面的实时计算才有意义。否则，再好的风控模型也是空中楼阁。