Parquet vs CSV
Scrapeless Google Search API 返回结构化 JSON，下游数据管道可以将其转换为分析表。
摘要
- Parquet 是一种面向列的二进制文件格式。 分析型读取器可以利用其结构只读取选定列和元数据。
- CSV 是一种文本交换格式。 当表结构约定明确时，它便于检查和大范围导入。
- 压缩和查询节省取决于数据和读取器。 在没有具代表性的测量结果前，避免给出固定的速度或大小结论。
- 文件格式不是数据库。 数据集更新、事务规则和目录管理需要额外的设计。
当同一批记录要服务不同任务时，比较 Parquet 和 CSV 就变得有用。打开小型导出的分析师，需求与按计划执行、在长历史上扫描选定字段的查询不同。格式选择应服从工作负载、接收方工具以及保持数值正确性的规则。
CSV 让文本易于检查。Parquet 将带类型的列组织起来以供分析访问。你可以将 Parquet 保留为内部数据集，并为特定审阅发布 CSV，而无需让任何一种格式成为所有使用方的通用来源。
列式存储会改变分析读取的工作方式
Parquet 以列式表示对数据进行分组，而不是将每条记录存储为一行分隔文本。 Parquet 格式概览 介绍了该格式在为分析型工作负载实现高效存储与检索方面的侧重。一个只需要少数字段的读取器可以避免实现与之无关的列。
CSV 将字段组合在文本记录中。解析器通常需要解释记录边界和分隔符，即使最终分析只保留部分列。这并不意味着 CSV 不适合小任务；它解释了为什么一个很宽的历史表可能更适合采用另一种表示方式。
想象一个搜索数据集包含查询上下文、URL、标题和描述性文本。一个域名频率报告需要域名和采集上下文，而不是每一个标题和摘要。列式读取器可以利用这一更窄的需求。实际节省仍然取决于数据集的写入和查询方式。
| 维度 | Parquet | CSV |
|---|---|---|
| 表示方式 | 带类型的二进制列 | 分隔的文本记录 |
| 选定列 | 读取器可以读取所需列的数据 | 解析器解释文本记录 |
| 人工检查 | 需要兼容的查看器 | 可用文本和表格工具读取 |
| 嵌套值 | 格式支持嵌套结构 | 需要转换约定 |
| 共享更新 | 需要数据集协调 | 需要数据集协调 |
CSV 需要方言，Parquet 需要兼容的数据类型
CSV 的互操作性依赖于已声明的文本约定。 CSV 引号与记录规则 涵盖了诸如字段中包含逗号和换行符等常见情况。编码、分隔符选择以及对空值的解释仍然需要与消费者达成一致。
Parquet 存储模式信息，但模式的存在并不保证每个引擎都以同样方式解释每一种逻辑类型。时间戳单位、时区处理、小数精度以及扩展类型都可能带来兼容性问题。在编写生产数据集之前，先决定下游工具支持哪些逻辑类型。
无论哪种格式，都应把标识符当作标识符对待。带前导零的值不应仅仅因为全部由数字组成就被当作数字。当前可能出现多种语境时，应在列名之外定义货币和计量单位。在接受导出结果之前，用一条特意构造的包含非 ASCII 文本、缺失值和大型标识符的记录进行测试。
行组和统计信息支持选择性工作
Parquet 文件包含行组、列块和页面来组织存储的值。 Parquet 文件布局 解释了这些结构。读取器可以利用可用的元数据和统计信息，在筛选条件排除文件部分内容时避免不必要的工作。
此功能具有条件性。只有当引擎能够应用过滤器且存储的元数据提供有用信息时，过滤器才有帮助。如果每个行组都跨越被过滤值的整个范围，则过滤器可能几乎无法排除任何内容。当需要使用所选列中的数据时，仍然需要对其进行解码。
围绕真实查询进行设计。如果报表通常会选择时间范围和市场，请对数据集进行安排，使这些约束能够缩小扫描范围。验证读取器的执行行为，而不是假设某个文件扩展名就会激活所有优化。先读取整个数据集再进行过滤的查询，无法获得预期的收益。
压缩是一种工作负载权衡
压缩通过增加编码和解码的工作来减少存储的字节数。Parquet 可以将列编码与压缩结合使用，这在相邻值具有编码可以利用的模式时非常有用。CSV 也可以进行压缩，因此公平的比较应包括双方实际的传输表示形式。
使用具有代表性的数值来衡量写入时间、读取时间、峰值内存以及传输的字节数。由重复类别构成的列与由已压缩或高度可变文本构成的列，其行为是不同的。所选用的编解码器和读取器的实现，以及文件格式本身，同样会产生影响。
避免将某一项测量结果视为通用比率。整表导出、选定列的聚合以及单条记录的检查会触发不同的成本。明确定义验收查询以及预期的硬件或服务配置。当有助于简化故障排查时，即使面向机器的分析表示是二进制的，也要保留一份供人工审查使用的导出结果。
分区和小文件需要单独规划
分区数据集是一组文件，其布局使读取方能够选择相关的子集。 Arrow Parquet 数据集处理 既记录单个文件，也记录分区的集合。分区布局是一个额外的选择，而不是写入一个 Parquet 文件后自动具备的属性。
根据常见的筛选条件和预期记录数量来选择分区键。基数非常高的键会产生大量小文件，而过于宽泛的键则可能几乎起不到剪枝作用。当数据集中包含过多微小对象时，文件列举和元数据处理工作会主导整个查询开销。
保持更新语义的显式性。追加新文件时，可能会重复已经在其他位置存在的业务记录。要安全地替换文件，可能需要使用带有协同元数据更改的目录或表格格式。仅靠 CSV 和 Parquet 并不能为共享的可变数据集提供事务协议。读取方需要知道哪一组文件构成一个完整已发布的快照。
将搜索获取与存储决策分离
获取 API 和分析型存储格式解决的是工作流中的不同阶段。 无爬取版 Google 搜索 API 返回结构化的搜索 JSON。你的管道选择一个表级粒度，验证字段，并为下游使用者写出 Parquet 或 CSV。
在构建表格时，保留查询上下文、市场、语言、捕获身份和结果类别。需要嵌套细节而分析性投影省略时，单独保留原始响应。 web-data 存储讨论 为在更广泛的数据管道中放置导出提供上下文。
使用当前预算获取方式 无爬取方案定价然后在保存数据集的系统中测量存储和查询成本。更小的分析文件并不会改变发出了什么请求，而一次成功的请求也不能证明生成的表具有预期的模式或记录覆盖范围。
为重复分析选择 Parquet，为交接选择 CSV
当兼容的分析工具需要反复读取选定字段、应用过滤条件并受益于类型化存储时，选择 Parquet。当前端接收方需要一个可移植的表格、简单的导入方式或直接进行文本检查时，选择 CSV。当不同的使用方有各自的需求但共享同一条已验证的转换流程时，同时保留这两种输出格式。
在比较性能之前先检查值的保真度。确认在预期粒度上的行数、标识符值、空值计数、小数行为以及时间戳的解释。使用下游工具读取输出，而不是只依赖写入器自行打开其文件。
将架构、分区方案和发布边界与数据集一同记录下来。当某个字段的含义发生变化时，创建一个显式迁移，而不是让新旧文件在无声无息中产生分歧。对不一致数据进行的快速查询依然是不可靠的结果。在所有权和校验清晰之后，格式选择才能发挥最佳效果。
结论
Parquet 与 CSV 的选择是一个基于工作负载的决策，而不是一场会产生永久赢家的比赛。对于频繁的分析型读取，使用兼容的、带类型的列式存储；对于表格数据交换，则使用规范良好的 CSV。使用接收端引擎验证数据值，测量实际查询表现，并将分区与数据集更新视为需要明确设计和负责的部分。
准备好构建分析型搜索数据集了吗？
使用 Google 搜索 API 收集结构化搜索记录，并以下游工具所需的格式发布已验证的表格。
今天注册即可获得 5 美元的免费额度 — 无需信用卡.
领取您的 $5 额度 →常见问题解答
Parquet 总是比 CSV 更小吗？
Parquet 并不能保证总是比所有 CSV 表示都更小。数据分布、编码方式、压缩以及文件大小都会影响结果。请使用在你的工作流程中实际使用的压缩和写入器设置，对等量记录进行比较。
你可以在文本编辑器中打开 Parquet 吗？
由于 Parquet 是一种二进制格式，文本编辑器无法将其呈现为普通的可读表格。使用兼容的库或查看器来检查其模式、元数据和值。当接收方需要基于文本的交接时，生成 CSV 视图。
Parquet 会取代数据仓库吗？
Parquet 本身并不能取代数据仓库。它只是一个文件格式。查询执行、访问控制、目录、事务以及可靠的数据集发布需要其他组件。数据仓库或数据湖架构可以将 Parquet 作为其存储设计的一部分来使用。
一次性的小型导出是否应该使用 Parquet？
一次性的小型导出应使用其接收方能够准确处理的格式。CSV 通常适合用于在电子表格中查看，而如果类型兼容性或后续分析用途很重要，则 Parquet 很有用。应对数值进行校验，而不是仅根据文件大小来选择格式。