数据采集与存储：数据源类型、格式与策略

做数据回放，第一步就是搞清楚数据从哪来、长什么样、怎么存。这三个问题搞不定，后面定位问题就是空中楼阁。我这些年踩过的坑，十有八九都跟数据采集和存储有关。

数据源说白了就是数据的源头。我个人习惯把数据源分成三大类：传感器日志、数据库binlog、网络pcap。每种都有它的脾气。

这是嵌入式系统里最常见的数据源。温度、湿度、加速度、GPS坐标……传感器每隔几秒吐一条记录。我在项目中遇到过一个问题：传感器采样频率是100Hz，但日志系统扛不住，丢包了。后来发现是日志写入线程优先级太低，被其他任务抢了CPU。

  关键点：传感器日志通常带有时间戳，但时间戳的精度和同步性是个大坑。我曾经见过两个传感器的时间戳差了整整2秒，回放时数据完全对不上。

binlog是MySQL等数据库的二进制日志，记录了所有数据变更。做数据回放时，binlog能帮你精确还原某个时间点的数据库状态。嗯，这里要注意：binlog的格式有STATEMENT、ROW、MIXED三种。我建议用ROW格式，因为它记录了每一行数据的变化，回放时最精确。

小技巧：解析binlog可以用开源工具，比如mysqlbinlog或者canal。我自己写过一个解析器，专门用来回放线上数据库的变更，定位了一个困扰团队两周的bug。

pcap是网络数据包的抓包文件。做网络协议分析、定位丢包或延迟问题时，pcap是首选。你想想看，一个TCP连接为什么卡住了？抓个pcap一看，哦，原来是重传风暴。

我曾经用pcap回放定位过一个诡异的问题：某设备每隔5分钟断连一次。抓包后发现，是路由器的ARP缓存过期了，设备没有及时刷新。这种问题，不看pcap根本想不到。

数据采回来了，用什么格式存？这取决于你要怎么用。我列个表，一目了然。

我个人习惯：调试阶段用CSV或JSON，方便肉眼检查。正式回放系统用Parquet，性能好太多。有一次我处理100GB的传感器数据，CSV格式跑了半小时没跑完，换成Parquet后，5分钟搞定。

避坑指南：我曾经把JSON日志直接存到文件里，结果一条日志里有个特殊字符，导致整个文件解析失败。后来我养成了习惯：所有数据入库前，先做格式校验。

数据存哪？这得看你的回放系统是实时还是离线，数据量有多大。

最简单直接。适合单机调试、小规模数据。我刚开始做数据回放时，就是把pcap文件丢在本地，写个脚本循环读取。但本地文件有个问题：磁盘满了怎么办？我遇到过磁盘写满，导致回放程序崩溃的情况。

# 一个简单的本地文件读取示例
import pandas as pd
df = pd.read_csv('sensor_data.csv')
for index, row in df.iterrows():
    replay(row)  # 回放每一条数据

数据量大、需要多机共享时，云存储是首选。S3、OSS、MinIO都行。我建议用对象存储，因为它支持版本管理，万一回放出问题，还能回滚到旧版本。

小技巧：云存储的读写延迟比本地磁盘高，所以我会在本地加一层缓存。先把数据拉到本地，再回放，速度能快一个数量级。

实时回放场景，消息队列是标配。Kafka、Pulsar、RabbitMQ都行。数据从采集端直接写入队列，回放系统从队列里消费。这样做的好处是：解耦、可扩展、支持回溯。

我记得有一次做实时回放，数据源是1000个传感器，每个每秒发10条数据。如果用本地文件，根本来不及写。换成Kafka后，轻松搞定。

  核心逻辑：消息队列的消费者要设计好offset管理。我曾经因为offset提交错误，导致重复消费了100万条数据，回放结果全错了。

下面这张图，把数据采集与存储的核心逻辑串起来了。你看一眼，就能明白整个流程。

说白了，数据采集与存储没有银弹。你得根据实际场景选。数据量大、实时性高，就上消息队列+Parquet。数据量小、调试用，本地文件+CSV就够了。

我的建议：先跑通一个最小闭环，再优化。别一上来就上Kafka+云存储，那玩意儿配置起来够你喝一壶的。我刚开始做数据回放时，就用一个CSV文件+Python脚本，跑通了再慢慢升级。

好了，数据采集与存储这块就聊到这。记住：数据源要准、格式要稳、存储要快。这三样做好了，后面的回放和定位问题就轻松多了。