3. 数据格式解析：CSV、JSON、Avro、Parquet、Protobuf 的优缺点及适用场景

做金融数据接入这些年，我打交道最多的就是这五种格式。说实话，没有哪个格式是万能的。选错了格式，后面整个管道都得跟着遭殃。今天咱们就掰开揉碎了聊聊，每种格式到底适合什么场景。

3.1 CSV：最朴素的文本格式

CSV 太常见了。说白了就是逗号分隔的文本。我最早做数据清洗时，天天跟 CSV 打交道。

优点：
  • 人类可读，用记事本就能打开
  • 几乎所有工具都支持
  • 文件体积小，传输快
缺点：
  • 没有数据类型定义，数字和字符串混在一起
  • 不支持嵌套结构
  • 转义规则混乱，遇到逗号或换行符就头疼

我在项目中遇到过一件事：某券商给的数据里，有个字段叫"备注"，里面居然包含了换行符。结果下游解析时直接崩了。排查了整整半天才发现问题。

适用场景：小规模数据交换、临时分析、与老系统对接。千万别用在生产环境的实时管道里。

3.2 JSON：灵活但啰嗦

JSON 现在几乎是 API 通信的标配。你想想看，RESTful 接口返回的基本都是 JSON。它的优势很明显：结构灵活，支持嵌套，JavaScript 原生支持。

{
  "trade_id": "T20240315001",
  "symbol": "AAPL",
  "price": 172.35,
  "quantity": 100,
  "timestamp": "2024-03-15T10:30:00Z",
  "tags": ["large", "buy"]
}

但 JSON 有个致命问题：太啰嗦了。同样的数据量，JSON 比二进制格式大 3-5 倍。我做过测试，一个 10 万条的交易记录，JSON 文件 50MB，换成 Avro 只有 12MB。

避坑指南：我曾经在实时行情推送中用 JSON，结果带宽直接被打满。后来改成 Protobuf，带宽占用降了 70%。JSON 适合低频、小数据量的场景，高频场景慎用。

3.3 Avro：大数据生态的宠儿

Avro 是 Hadoop 生态里的明星。它的核心设计是Schema 与数据分离。写入时带上 Schema，读取时自动解析。这一点在金融数据接入中特别实用。

为什么？因为金融数据的字段经常变。今天加个"风险等级"，明天加个"交易渠道"。用 Avro，你只需要更新 Schema，下游自动兼容。

优点：
  • 支持 Schema 演化，向后兼容
  • 二进制格式，压缩率高
  • 与 Kafka、Spark 深度集成
缺点：
  • 人类不可读，调试麻烦
  • Schema 管理需要额外成本
  • 小数据量场景优势不明显

我个人习惯在 Kafka 消息管道里用 Avro。配合 Schema Registry，字段变更时下游消费者完全无感。嗯，这一点在金融系统里太重要了。

3.4 Parquet：列式存储的王者

Parquet 是列式存储格式。什么意思？就是同一列的数据物理上挨在一起。这对分析型查询特别有利。

举个例子：你要统计某只股票过去一年的平均收盘价。用 Parquet 只需要读取"收盘价"这一列的数据，其他列直接跳过。如果是行式存储，你得把整行数据都读进来。

特性 Parquet 行式存储
列查询速度 极快 慢
压缩率 高（同一列数据相似度高） 低
写入速度 慢 快
适用场景 OLAP、数据仓库 OLTP、实时写入
适用场景：历史数据存储、批量分析、数据湖。我建议把日终清算数据存成 Parquet，查询效率能提升 10 倍以上。

3.5 Protobuf：高性能的二进制协议

Protobuf 是 Google 搞出来的。它的设计目标就一个：快。序列化和反序列化的速度，比 JSON 快 5-10 倍。

怎么做到的？它用二进制编码，字段用数字编号代替字符串名称。你想想看，JSON 里每个字段名都要重复写一遍，Protobuf 直接省掉了。

// Protobuf 定义
message Trade {
  string trade_id = 1;
  string symbol = 2;
  double price = 3;
  int32 quantity = 4;
  int64 timestamp = 5;
}
优点：
  • 序列化速度快，体积小
  • 跨语言支持好
  • Schema 严格，类型安全
缺点：
  • 需要预定义 Schema，灵活性差
  • 调试困难，需要工具辅助
  • Schema 变更需要重新编译

我曾经在实时风控系统里用 Protobuf。每秒处理 10 万笔交易，延迟控制在 5 毫秒以内。换成 JSON 的话，延迟直接飙到 30 毫秒。这就是差距。

3.6 如何选择？一张图看懂

下面这张图是我自己总结的。每次做技术选型时，我都会拿出来对照一下。

数据格式选型决策图 实时通信 / 高频交易 消息管道 / 流处理 批量分析 / 数据仓库 Protobuf 延迟低，体积小 Avro Schema 演化，兼容性好 Parquet 列式存储，查询快 API 接口 / 配置文件 临时分析 / 数据导出 跨系统 / 异构数据交换 JSON CSV JSON / Avro

3.7 我的选型建议

说了这么多，到底怎么选？我总结几条实战经验：

  1. 高频交易、实时风控：无脑选 Protobuf。延迟就是金钱，少 1 毫秒可能就多赚几百万。
  2. Kafka 消息管道：Avro 是首选。配合 Schema Registry，字段变更不用停机。
  3. 历史数据存储、数据湖：Parquet 最合适。查询快，压缩率高，存储成本低。
  4. API 接口、配置文件：JSON 够用了。别为了炫技用 Protobuf，调试起来太痛苦。
  5. 临时分析、数据导出：CSV 最方便。Excel 直接打开，业务人员也能用。
重要提醒：我曾经见过一个团队，所有场景都用 JSON。结果实时管道带宽打满，历史查询慢如蜗牛。选型一定要因场景而异，别偷懒。

好了，数据格式这块就聊到这儿。记住一句话：没有最好的格式，只有最合适的格式。下一章咱们聊聊数据接入管道的架构设计，到时候会用到今天讲的这些知识。

专注资料整理
← 上一章 📖 返回目录 下一章 →