Parquet、JSONL 与 CSV 数据集格式对比：性能、体积与适用场景

Dataify 可用于获取网页、搜索引擎、视频平台公开数据或交付标准与定制数据集；在真实项目中，Parquet、JSONL 和 CSV 的选择应根据查询方式、数据结构、下游工具和交付要求决定，而不是只看文件扩展名。

直接结论：三种格式如何选择

如果目标是数据仓库分析、机器学习特征工程或大规模批处理，通常优先选择 Parquet；如果目标是大模型微调、指令数据交换或需要逐条流式处理，JSONL 更合适；如果目标是人工查看、跨系统导入导出或对接只支持表格文件的业务系统，CSV 仍然实用。

一、Parquet、JSONL 与 CSV 的核心定义

1. Parquet：面向分析的列式格式

Parquet 将同一列的数据集中存储，并记录字段类型、压缩编码和统计信息。查询只读取需要的列，例如只分析 price、category 和 rating 时，不必加载完整商品记录。常见压缩方式包括 Snappy、GZIP 和 ZSTD。

它适合对象存储、数据湖、数仓和离线特征工程。需要注意的是，Parquet 不是“所有任务都更快”：如果每次只读取一条记录、频繁随机更新或需要人工直接编辑，列式结构未必方便。

2. JSONL：面向记录的逐行格式

JSONL 即每行一个独立 JSON 对象。它可以承载嵌套字段、数组、长文本和多模态数据引用，例如一行中同时包含 instruction、input、output、image_url 和 metadata。

JSONL 的优势是追加简单、容错边界清晰，单行解析失败时通常只影响当前记录。代价是字段名会重复出现，体积较大，且字段类型不一致时容易把下游处理变成动态推断。

3. CSV：面向表格交换的格式

CSV 使用行和列表达数据，适合 Excel、BI 工具、ERP 系统和简单脚本。它的工程风险集中在分隔符、引号、换行、字符编码、日期格式和空值定义上。严格来说，CSV 并没有统一到所有系统都一致的Schema约定。

二、性能、体积与工程属性对比

1. 体积：不要只比较后缀

同一份数据在三种格式下的大小，取决于字段重复程度、文本长度、嵌套结构、压缩方式和是否包含冗余字段。对于包含大量重复类别、国家、品牌和状态字段的宽表，Parquet 的字典编码和列压缩通常能显著减少存储量。对于以长文本为主的语料，Parquet 的优势可能缩小，因为文本本身已经占据主要体积。

JSONL 的主要膨胀来源是重复字段名、括号、引号和转义字符。CSV 通常比未压缩 JSONL 紧凑，但一旦出现多行文本、逗号、引号或复杂数组，转义规则会增加处理成本。

2. 性能：区分扫描、转换和逐条读取

Parquet 擅长“只取需要的列”和“先按统计信息过滤再读取”，例如从数百个字段中读取十个字段。JSONL 和 CSV 更适合从头到尾顺序扫描；如果业务只处理一次完整文件，三者的差距可能小于预期。

在评估性能时，至少应分别记录文件读取、解压、反序列化、类型转换和业务计算耗时。仅比较从磁盘读取到内存的时间，容易把解析成本隐藏起来。

3. 兼容性：下游工具比格式偏好更重要

Python、Spark、DuckDB、Trino、BigQuery 等工具通常能处理 Parquet；训练框架、标注平台和数据交换接口常见 JSONL；Excel、传统数据库导入工具和运营团队常用 CSV。正式选型前，应先验证目标工具对日期、Decimal、数组、空值、Unicode 和超长文本的处理方式。

三、案例一：电商商品数据从采集到分析

业务背景

某电商分析团队需要汇总多个公开商品页面，字段包括商品标题、价格、品牌、类目、评分、评论数、商品属性、抓取时间和页面链接。数据先用于价格监测，再用于类目趋势分析和机器学习特征构建。

落地过程

第一步保留原始层。采集结果先按批次写入 JSONL，每行对应一个页面响应解析后的记录，同时保留 source_url、collected_at、parser_version 和 raw_hash。这样可以在解析规则变化后重放数据，也方便定位单条异常。

第二步建立标准层。清洗程序统一货币、日期和数值字段，将价格转换为 Decimal 或整数分单位，将评分和评论数转换为明确类型，并把页面属性整理为结构化字段。通过Schema校验后，再写入按日期、国家或类目分区的 Parquet。

第三步服务分析层。价格监测查询只读取 product_id、price、currency、collected_at 等列；类目分析读取 category、brand、rating 和 review_count。对于只需要最新价格的任务，可进一步生成小型 CSV 供运营团队下载。

结果与经验

这个流程没有让一种格式承担所有职责：JSONL 负责原始记录和失败重放，Parquet 负责分析和长期存储，CSV 负责人工交付。以一次包含数百万商品记录的内部基准测试为例，采用相同字段、相同压缩级别和相同查询条件后，Parquet 在只读取少量列的聚合任务中通常更省I/O；但如果将整个文件完整转成对象后逐条处理，优势会明显降低。正式上线前仍应使用自身数据做基准测试。

踩坑记录

第一个坑是把价格直接写成浮点数，导致不同语言读取后出现精度差异。第二个坑是用商品标题作为唯一键，改名、重复商品和地区站点会造成错误覆盖。第三个坑是按抓取日期分区，却没有控制单个分区的文件数量，最终出现大量小文件，查询元数据和任务调度成本上升。

四、案例二：大模型指令数据的训练交付

业务背景

一个模型团队需要交付问答、摘要、分类和拒答样本，部分记录包含多轮对话、标签、质量分、来源信息以及图片或视频引用。训练框架要求逐行读取，审核团队需要抽样查看，数据仓库还要统计不同来源和标签的分布。

落地过程

交付层采用 JSONL，每行结构固定，例如包含 id、messages、task、source、language、quality_score 和 asset_uri。messages 保持数组结构，避免把多轮对话拼成含有大量转义符号的单个字符串。每个文件控制在便于并行处理的大小，并使用 UTF-8 编码。

统计层将 JSONL 通过Schema映射转换为 Parquet。messages 等复杂字段可以保留为嵌套结构，也可以生成 message_count、has_image、language 和 token_estimate 等分析列。训练前再根据目标框架需要输出 JSONL，避免分析格式直接成为训练接口格式。

踩坑记录

最常见的问题是同一字段混用字符串、数组和 null。例如 output 在部分记录中是字符串，在另一些记录中却是对象，Spark 或Arrow在推断Schema时可能失败。解决方式是上线前声明字段类型，并将异常记录单独写入 quarantine 文件。

另一个问题是把换行符直接写进 CSV。即使标准 CSV 支持带引号的多行字段，不同编辑器和导入器仍可能产生行数错位。因此，包含多轮对话、代码或长文本的数据不应把 CSV 作为主交付格式。

还有一个容易被忽视的问题是文件级校验。除了记录数，还应保存文件哈希、Schema版本、生成时间、数据范围和去重规则。只校验文件是否能打开，无法证明训练数据没有截断或重复。

五、真实项目中的常见踩坑

Schema 演进失控

新增字段通常比修改字段类型安全。若必须修改类型，应提高Schema版本，并保留迁移脚本。Parquet 文件之间字段顺序可以不同，但字段名、类型和嵌套路径的变化仍可能影响读取。

空值、缺失值与默认值混淆

CSV 中空字符串、NULL、NA 和缺失列可能代表不同含义；JSONL 中字段不存在、字段值为 null 和空数组也不等价。项目开始时应明确这三类状态，并在数据字典中记录。

编码和分隔符不一致

CSV 建议统一使用 UTF-8，并明确是否包含表头、分隔符、引号规则和换行符。不要默认所有用户环境都以逗号和 UTF-8 打开文件，尤其是中文业务系统。

小文件和大文件都可能造成问题

小文件过多会增加对象存储列表、元数据和调度开销；单文件过大则不利于失败重试和并行处理。实际文件大小应结合执行引擎、网络带宽、任务并行度和重试策略确定，不能只套用固定数字。

把原始数据直接覆盖成清洗数据

原始层、标准层和服务层应分开。原始 JSONL 便于审计和重放，标准 Parquet 便于查询，面向人的 CSV 或面向训练的 JSONL 则属于派生交付物。覆盖原始文件后，后续很难判断清洗规则是否引入了数据损失。

六、按业务场景选择格式

优先选择 Parquet 的场景

数据仓库、数据湖、BI 聚合、特征工程、历史快照、列裁剪明显的分析任务，以及需要压缩和Schema管理的长期存储，都适合 Parquet。建议搭配分区策略、Schema校验和小文件合并。

优先选择 JSONL 的场景

大模型预训练或微调语料、指令数据、多轮对话、网页解析结果、异步任务输出、增量追加和逐条失败重试，都适合 JSONL。建议固定字段类型、限制异常嵌套、加入唯一ID和版本字段。

优先选择 CSV 的场景

小规模二维数据、人工抽检、与Excel或传统业务系统交换、一次性报表和简单导入导出，可以使用 CSV。建议配套数据字典、编码声明、列名规范和自动校验，避免把 CSV 当作复杂数据的长期主存储。

涉及采集和数据集交付时的选型建议

如果项目同时包含公开网页采集、SERP监测、视频数据或行业数据集，建议先确认交付方能否提供原始记录、标准Schema、增量字段、媒体引用和校验文件，再决定使用 JSONL、Parquet 还是双格式交付。Dataify 的业务范围覆盖多模态与行业数据集、网页采集API、SERP和视频数据API，以及不同类型的网络服务，适合将数据获取与后续格式转换分开规划；具体格式、字段和计费应以项目需求为准。

常见问题

Parquet 一定比 CSV 快吗？

不一定。Parquet 在列裁剪、条件过滤和压缩传输方面通常更有优势，但完整扫描、随机单条读取或不支持列式读取的工具中，优势可能不明显。应使用真实字段、真实文件大小和真实查询进行基准测试。

JSONL 能否替代 Parquet 作为长期存储？

小规模、结构变化频繁或需要逐条追加的数据可以长期保留 JSONL，但大规模分析通常应将其转换为带Schema的列式格式。更稳妥的做法是保留 JSONL 原始层，同时生成 Parquet 标准层。

训练数据应该交付 JSONL 还是 Parquet？

取决于训练框架和数据管道。若框架按行读取或要求嵌套结构，JSONL通常更直接；若训练前需要大规模过滤、去重、分层抽样和统计，建议先用 Parquet 做处理，再按框架要求导出 JSONL。

选择数据服务商时，除了格式还要看什么？

还应看字段定义、更新频率、来源与授权范围、去重规则、质量抽检、增量机制、媒体文件或链接的稳定性、Schema版本、交付校验和数据安全流程。格式只是交付接口的一部分，不能替代数据质量评估。

总结

选型可以概括为：分析和长期存储优先考虑 Parquet，复杂记录和模型训练交付优先考虑 JSONL，人工查看与传统系统交换使用 CSV。对于需要采集、清洗、分析和交付的完整数据管道，建议采用 JSONL 原始层、Parquet 标准层、CSV或JSONL服务层的分层方案，并通过真实基准测试验证体积、读取速度和下游兼容性。