一、实时数据采集概述

大家好，我是老张。做数据这行十几年了，今天咱们聊聊实时数据采集。

说实话，我刚入行那会儿，实时采集还是个新鲜词。那时候大家做数据，基本都是T+1，今天处理昨天的数据，慢悠悠的。但现在不一样了，你想想看，股票价格晚一秒可能就是几百万的损失，工厂设备停转一分钟就是几十万的产能浪费。嗯，这就是实时数据采集要解决的问题。

1.1 实时数据采集的定义

实时数据采集，说白了就是数据从产生到被系统拿到，中间延迟控制在毫秒或秒级。我个人习惯把它分成三个层次：

• 硬实时：延迟在毫秒级，比如工业控制、自动驾驶。错过截止时间就是事故。
• 软实时：延迟在秒级，比如监控告警、交易系统。偶尔延迟几秒还能接受。
• 准实时：延迟在分钟级，比如报表统计、用户行为分析。很多传统ETL改造后就是这个水平。

1.2 应用场景

我挑三个最典型的场景说说，都是我自己踩过坑的。

金融场景

金融是实时采集最苛刻的领域。股票行情、风控检测、量化交易，每一笔数据都跟钱直接挂钩。

• 行情数据：每秒几万笔订单，延迟要求毫秒级
• 交易风控：买入卖出前必须实时校验账户余额、持仓限制
• 反欺诈：信用卡盗刷检测，30秒内必须识别异常

我记得有一次帮券商做行情网关，数据从交易所到用户终端，整个链路延迟必须控制在5毫秒以内。那段时间天天调网络参数、优化序列化协议，头发都掉了一把。

IoT场景

物联网设备数量大、数据频率高，但单个设备的数据价值密度低。

• 工业设备监控：温度、振动、压力，每秒采集一次
• 车联网：GPS位置、车速、电池状态，每100毫秒上报
• 智能家居：传感器数据聚合，秒级响应

我曾经给一个工厂做过设备数据采集，3000多台机器，每台每秒上报10个指标。你算算，每秒3万条数据。刚开始用的Kafka，结果分区配置不对，消费者跟不上，数据积压了半小时。嗯，后来重新设计了分区策略和消费者并发度才搞定。

运维场景

运维监控是实时采集的「老本行」。服务器CPU、内存、磁盘、网络，这些指标必须实时可见。

• 基础设施监控：服务器、容器、数据库的指标采集
• 应用性能监控：接口响应时间、错误率、调用链追踪
• 日志采集：业务日志、系统日志的实时汇聚分析

运维场景有个特点：数据量大但容忍度相对高。一般10秒内的延迟都能接受，但告警必须准，不能漏报也不能误报。

1.3 核心挑战

做实时采集这么多年，我觉得核心挑战就三个：延迟、吞吐、一致性。这三者就像不可能三角，你很难同时做到极致。

挑战	说明	我踩过的坑
延迟	数据从产生到消费的时间	序列化方式选错，延迟从2ms飙到50ms
吞吐	单位时间内能处理的数据量	单机采集器扛不住百万级QPS，必须做分布式
一致性	数据不丢、不重、不乱序	网络抖动导致数据重复，对账对了一周

延迟挑战

延迟的来源很多：网络传输、磁盘IO、序列化/反序列化、GC暂停。我曾经遇到一个案例，数据采集端延迟正常，但到了消费端就慢了。查了半天，发现是消费端的反序列化用了JSON，换成Protobuf后延迟直接降了80%。

吞吐挑战

吞吐量上不去，常见原因有：

• 单点瓶颈：所有数据都往一个节点写
• 资源争抢：CPU、内存、网络带宽不够
• 锁竞争：多线程写同一个队列或文件

我一般建议用分区+分片的思路。比如Kafka按key分区，每个分区独立消费。数据量再大就上多级聚合，先在本机做预聚合，再上报到中心。

一致性挑战

一致性是最容易被忽视的。很多人觉得「数据能到就行」，但到了之后呢？

• 不丢：网络闪断、进程崩溃，数据会不会丢？
• 不重：重试机制导致数据重复，下游能不能去重？
• 不乱序：多线程发送、多分区消费，顺序乱了怎么办？

知识体系总览

下面这张图是我自己总结的实时数据采集知识体系，你可以对照着看看自己当前在哪个环节。

这张图把实时数据采集分成了五层。从数据源到最终存储消费，每一层都有各自的挑战。我个人觉得，最容易被忽视的是采集层和传输层之间的衔接——数据格式不统一、协议不匹配，这些问题在前期设计时就要想清楚。

---

公众号:蓝海资料掘金营，微信deep3321