数据采集与存储：数据源类型、采集策略与存储格式
做数据回放，第一步就是搞定数据怎么来、怎么存。这活儿我干了好几年，踩过的坑真不少。今天咱们就聊聊数据采集与存储这块，我把自己的经验掰开揉碎了讲给你听。
数据源类型：你面对的是什么样的数据？
数据源这东西，说白了就是数据的“老家”。我见过太多人一上来就闷头写采集脚本，结果发现数据格式不对、字段对不上，白忙活半天。所以，先搞清楚数据源类型，这是基本功。
常见的几类数据源，我列个表给你看：
| 数据源类型 | 典型代表 | 特点 |
|---|---|---|
| 关系型数据库 | MySQL、PostgreSQL、Oracle | 结构化强，支持事务，适合OLTP场景 |
| 非关系型数据库 | MongoDB、Redis、Cassandra | 灵活schema，高扩展性，适合海量数据 |
| 日志文件 | Nginx日志、应用日志 | 半结构化，时间序列特征明显 |
| 消息队列 | Kafka、RabbitMQ、Pulsar | 流式数据，实时性高，适合事件驱动 |
| API接口 | RESTful API、gRPC | 按需拉取，数据量可控，但延迟不稳定 |
我个人习惯，拿到一个新项目，先花半天时间梳理数据源清单。你想想看，如果连数据从哪来都不清楚，后面的采集策略就是瞎搞。
数据采集策略：全量还是增量？这是个问题
数据采集策略，核心就两个词：全量采集和增量采集。但实际落地时，门道可多了。
全量采集
就是把数据源里的所有数据一次性拉过来。适合数据量小、变化不频繁的场景。比如配置表、字典表这些，我一般每周跑一次全量。
增量采集
只拉取新增或变化的数据。适合大数据量、高频更新的场景。比如用户行为日志，每秒都在产生新数据，全量采集根本不现实。
这里有个坑，我曾经踩过——增量采集的断点续传问题。有一次采集任务跑了12小时，结果中间网络断了，重新跑时不知道从哪续上，只能全量重来，气得我够呛。
常见的采集策略，我总结成下面这张图：
嗯，这里要注意，实际项目中往往是全量+增量混合使用。比如每天凌晨跑一次全量，白天每5分钟跑一次增量。这样既有全量数据的完整性，又有增量数据的实时性。
数据存储格式：CSV、Parquet、Avro怎么选？
存储格式这块，我见过太多人无脑选CSV，觉得简单通用。但说实话，在数据回放场景下，CSV很多时候是坑。咱们一个一个说。
CSV：简单但低效
CSV的优点就是人类可读，Excel能直接打开。但缺点也很明显：
- 没有schema信息，字段类型全靠猜
- 压缩率低，同样数据比Parquet大3-5倍
- 不支持嵌套结构，复杂数据得拆成多张表
我建议，CSV只适合做数据交换的中间格式，或者数据量小于100MB的小项目。别拿它当主力存储。
Parquet：列式存储的王者
Parquet是我个人最推荐的格式，尤其适合数据回放。为什么？
- 列式存储：查询时只读需要的列，IO开销小
- 高压缩率：支持snappy、gzip等压缩算法，存储成本低
- 自带schema：字段名、类型、精度都写在文件里
- 支持谓词下推：过滤条件直接在文件层面生效
Avro：行式存储的利器
Avro是行式存储，适合写密集的场景。比如Kafka消息的序列化，Avro就是标配。
- 行式存储：写入速度快，适合流式数据
- schema可演化：字段可以增删，兼容性好
- 自带序列化：数据紧凑，网络传输效率高
但Avro的查询性能不如Parquet，因为它是行式存储，读数据时得把整行都读出来。
三种格式的对比，我整理成表格：
| 特性 | CSV | Parquet | Avro |
|---|---|---|---|
| 存储方式 | 行式 | 列式 | 行式 |
| 压缩率 | 低 | 高 | 中 |
| 查询性能 | 差 | 优 | 中 |
| 写入性能 | 中 | 中 | 优 |
| schema支持 | 无 | 有 | 有 |
| 适用场景 | 小数据、临时交换 | 分析查询、数据回放 | 流式写入、消息队列 |
选型时，我一般遵循这个原则：读多写少用Parquet，写多读少用Avro，临时用用CSV。数据回放场景下，绝大多数是读操作，所以Parquet是我的首选。
最后说一句，数据采集与存储是数据回放的基石。地基没打好，后面复现场景就是空中楼阁。我见过太多人在这上面翻车，所以多花点心思在这块，绝对值得。
可可精品资料库