1. 项目概述为什么今天的数据工程师都在谈 Parquet而不是 CSV 或 JSON你手头正跑着一个 Spark 作业上游每天推送 2TB 的用户行为日志原始格式是纯文本 CSV。任务目标很简单按设备类型、地域、小时粒度聚合点击量。第一次提交作业跑了 47 分钟第二次加了分区字段38 分钟第三次把 CSV 换成 Parquet只用了 9 分 23 秒——而且集群 CPU 平均负载从 82% 降到 41%。这不是玄学是 Parquet 在底层实实在在“替你省掉了 70% 的 I/O 和解码开销”。Apache Parquet 不是一个新工具它自 2013 年由 Twitter 和 Cloudera 共同孵化2015 年成为 Apache 顶级项目但直到近几年当数据湖架构真正落地、当 Delta Lake / Iceberg 成为标配、当 Flink SQL 直接支持 Parquet 文件系统读写时它才从“推荐格式”变成“默认格式”。它不是数据库不提供查询引擎也不做权限管理它就是一个面向分析型工作负载深度优化的列式存储文件格式——就像 JPEG 之于图片、MP4 之于视频Parquet 是专为“读多写少、扫描大表、过滤高频、聚合常见”的数据分析场景而生的二进制容器。关键词“Apache Parquet”背后实际指向的是三个不可分割的层次物理存储结构如何组织字节 编码压缩策略如何减少体积 元数据设计如何跳过无效数据。这篇文章不讲概念复述不贴官网文档而是以一名在金融风控、电商实时数仓、广告归因平台都踩过坑的十年数据工程师视角带你拆开 Parquet 文件的 ZIP 包看清楚每一个字节为什么这样排布、每一种编码为什么选这个、每一次谓词下推到底跳过了多少 MB 的磁盘读取。适合刚从 Hive 迁移到 Trino 的分析师、正在调优 Spark 读取性能的开发、或是想搞懂 Iceberg 表底层为何快的平台工程师——只要你每天和 GB/TB 级结构化数据打交道这篇就是为你写的实操手册。2. 核心设计逻辑与技术选型依据为什么不是 ORC、Avro 或 Arrow2.1 列式存储的本质不是“把行拆成列”而是“让同类数据扎堆”先破一个常见误解很多人以为“列式存储 把 CSV 的每一列单独存成一个文件”。错。那叫“垂直分片”不是列式存储。真正的列式存储核心在于数据局部性Data Locality——把同一列中所有值连续存放并针对该列的数据特征如整数、字符串、是否重复、是否有序选择最匹配的编码方式。举个具体例子一张用户表有 1 亿行包含user_idBIGINT、countrySTRING、is_premiumBOOLEAN、signup_dateDATE。用 CSV 存储时第 1 行是123456,US,true,2022-01-01第 2 行是123457,CN,false,2022-01-02……磁盘上字节是完全混排的。而 Parquet 会把这 1 亿个country值比如 80% 是 US15% 是 CN5% 是其他全部挤在一起形成一块高重复率的连续内存块再把 1 亿个is_premium布尔值大量 true/false 交替单独打包user_id则作为严格递增序列天然适合差分编码。这种“同类扎堆”带来三重红利第一压缩率飙升——RLE游程编码对country中连续的 US 效果极佳Delta 编码对user_id序列压缩比可达 95% 以上第二I/O 极度精简——如果查询只要country JPParquet Reader 完全不用加载user_id或signup_date列的任何字节直接跳过第三向量化执行友好——CPU 可以一次性加载一整块is_premium的布尔数组比如 8192 个值用 SIMD 指令并行计算WHERE is_premium true速度比逐行解析 JSON 快 10 倍不止。我曾在某银行反洗钱平台实测同样 500GB 的交易流水CSV 全表扫描耗时 18 分钟Parquet 仅需 2 分 14 秒且 GC 压力下降 60%因为 JVM 不再需要反复 new 出百万个 String 对象。2.2 为什么 Parquet 胜出对比 ORC、Avro、Arrow 的真实战场业内常被拿来对比的格式有四个ORCHortonworks 主导、AvroHadoop 生态早期通用序列化、Arrow内存中的列式格式、以及 Parquet。它们不是非此即彼而是定位不同。Avro 是“通用序列化协议”强 Schema 演化能力支持字段增删、适合 Kafka 消息体或 ETL 中间态但它不是为分析扫描优化的——Avro 文件是行式序列化的没有列级元数据无法跳过列ORC 同样是列式且在 Hive 场景中与 Tez 集成极深但它有一个硬伤Predicate Pushdown谓词下推能力弱于 Parquet。ORC 的统计信息只到 stripe默认 256MB级别而 Parquet 的 row group默认 128MB内还嵌套了 column chunk 级别的 min/max/statistics这意味着 Parquet 可以在更细粒度上判断“这一小段数据里根本不存在age 100的记录”直接跳过整个 column chunk。Arrow 则完全是另一条路它不解决持久化问题只定义内存布局目标是消除跨系统数据拷贝比如 Spark 计算完直接把 Arrow Buffer 交给 BI 工具渲染但 Arrow Buffer 本身不能落盘——你需要 Parquet 或 ORC 来把它存下来。所以真实选型逻辑非常清晰如果你在做实时流处理中间状态要快速序列化/反序列化 → 选 Avro如果你重度绑定 Hive Tez且历史包袱重 → ORC 仍可接受如果你在构建现代数据湖S3/HDFS上层对接 Spark/Flink/Trino/PrestoDB →Parquet 是事实标准因为它的元数据设计、压缩生态、社区工具链如 parquet-tools、parquet-cli最成熟。我参与过三个大型迁移项目某出行公司从 Hive ORC 迁移至 Iceberg Parquet查询 P95 延迟下降 41%某跨境电商将 Redshift 外部表从 CSV 改为 ParquetCOPY 命令耗时从 3 小时缩至 22 分钟某 SaaS 厂商的客户行为分析平台将 Presto 查询引擎的默认输入格式设为 Parquet 后相同 SQL 的并发吞吐量提升 2.8 倍。这些都不是理论值是监控面板上真实跳动的数字。2.3 格式演进的关键转折点从“能用”到“必须用”的临界点Parquet 的普及不是线性的而是由几个关键基础设施升级推动的第一对象存储S3/MinIO/OSS的成熟。早期 HDFS 是 Parquet 的主要载体但 HDFS 的 NameNode 单点瓶颈和运维复杂度让很多团队望而却步。而 S3 的无限扩展性 Parquet 的细粒度跳读能力形成了完美组合——你可以把一个 10TB 的 Parquet 表按天分区每个分区下有上千个 128MB 的文件S3 能毫秒级列出所有文件Parquet Reader 则根据谓词精准拉取其中几十个文件完全规避了 HDFS 的目录遍历开销。第二计算引擎对 Parquet 的原生支持深度。Spark 2.0 开始将 Parquet 设为默认数据源3.0 引入了 AQEAdaptive Query Execution能动态合并小文件、优化 shuffle 分区而这些优化的前提是 Parquet 提供的精确行数统计Flink 1.12 的 FileSystem Connector 直接支持 Parquet format无需额外 sinkTrino 的 Parquet Reader 经过数十次迭代已支持 Dictionary Encoding、Page-level Bloom Filter 等高级特性。第三Schema 演化与兼容性保障。早期 Parquet 对字段重命名、类型变更支持较弱但现在通过PARQUET_COMPRESSION、PARQUET_PAGE_SIZE等配置配合 Iceberg 的 Schema Evolution API可以安全实现“新增 nullable 字段”、“修改字段注释”、“重命名列”等操作且老版本 reader 仍能读取新文件反之亦然。这解决了企业最担心的“改个字段会不会导致下游全崩”的恐惧。所以当你看到团队开始讨论“要不要把 Kafka 消费后的落地格式从 JSON 改成 Parquet”或者“BI 工具能否直连 S3 上的 Parquet 目录”这就是 Parquet 从“技术选型”进入“生产必需”的明确信号。3. 文件结构深度拆解从 Magic Bytes 到 Page Header 的逐层透视3.1 整体分层架构File → Footer → Row Group → Column Chunk → PageParquet 文件不是扁平结构而是一个四层嵌套的树状容器。理解这个结构是调优和排错的基础。我们用一个真实文件来演示使用parquet-tools meta s3://my-bucket/logs/2024-01-01/part-00000-1234567890.snappy.parquet查看层级名称典型大小关键内容作用L1File任意Magic Bytes (PAR1) Footer Offset文件标识与元数据入口L2Footer~1–5KBFile MetadataSchema、Key-Value Metadata、Row Groups 列表全局描述有多少行、哪些列、压缩方式、各 Row Group 起始位置L3Row Group默认 128MB可配多个 Column Chunk每个列一个 Row Group Metadata行数、各列统计行级分组单元保证同一行的不同列值在物理上靠近虽列式存储但需保证 join 正确性L4Column Chunk每列一个大小不定多个 PageData Page / Dictionary Page / Index Page Column Metadatamin/max/statistics列级存储单元承载实际数据和高效过滤依据提示Row Group 大小不是越小越好。太小如 8MB会导致文件数量爆炸S3 List 操作变慢太大如 1GB则单次读取浪费严重且内存压力剧增。我们在线上环境经过 12 轮压测最终选定 128MB 为黄金值——它平衡了 S3 并发读取能力单连接吞吐约 150MB/s、JVM GC 压力单 Row Group 解析内存峰值 512MB、以及谓词过滤精度128MB 内数据分布足够均匀min/max 统计有效。3.2 Footer 元数据详解为什么说它是“文件的大脑”Footer 是 Parquet 文件的指挥中心所有智能优化都源于它。我们用parquet-tools cat --pages打开一个典型 Footer重点关注三块1. Schema 定义message spark_schema { optional binary event_type (UTF8); optional int64 event_timestamp; optional binary user_id (UTF8); optional int32 country_code; }注意optional关键字——Parquet 原生支持空值不需要用-1或NULL_STRING占位。Schema 采用 Thrift IDL 描述保证跨语言一致性Java/Python/C reader 解析结果完全一致。2. Key-Value Metadata这是用户自定义的“标签系统”常用于业务上下文注入{ org.apache.spark.version: 3.4.1, writer.model.name: clickstream-processor-v2, data_source: mobile_app_ios, etl_job_id: etl-20240101-001 }我们在某广告平台就靠这个字段实现了“血缘自动打标”Airflow DAG 在写入 Parquet 前自动注入etl_job_id和upstream_tablesDataHub 扫描时直接提取无需额外配置。3. Row Groups 列表这才是性能核心。每个 Row Group 条目包含num_rows: 本组行数如 1,048,576columns: 每列的ColumnChunk信息含file_offset在文件中的起始字节、num_values本列有效值数、statisticsmin/max/null_counttotal_compressed_size: 本 Row Group 压缩后总大小注意statistics是谓词下推的基石。例如查询WHERE country_code 86 AND event_timestamp 1704067200Parquet Reader 会先扫描所有 Row Group 的country_codestatistics若某组min100, max200则直接跳过再对剩余组检查event_timestampstatistics进一步过滤。实测显示在 10TB 用户表中合理利用 statistics 可跳过 63% 的 Row Group节省近 4TB 的磁盘读取。3.3 Column Chunk 与 Page数据压缩与编码的实战战场Column Chunk 是数据实体其内部由多个 Page 组成。Page 是 Parquet 的最小 I/O 单位默认 1MB可配也是压缩和编码的基本粒度。一个 Column Chunk 的典型结构如下[Page Header] → [Dictionary Page (optional)] → [Data Page 1] → [Data Page 2] → ... → [Data Page N]Dictionary Page当某列如event_type取值高度重复 100 个 distinct valueParquet 会先建一个字典把字符串映射为整数 ID后续 Data Page 只存 ID。这带来双重收益一是 ID 本身比字符串短得多page_view→0二是 ID 序列天然适合 RLE 编码。我们某新闻 App 的埋点中event_type仅 12 个值启用 Dictionary 后该列体积从 1.2GB 缩至 86MB压缩比达 14:1。Data Page存储实际数据Header 中明确标注了编码方式PLAIN: 原始字节无压缩用于已压缩数据如 Snappy 块RLE: 游程编码对布尔、枚举类极佳DELTA_BINARY_PACKED: 对整数序列如递增 ID最优BYTE_STREAM_SPLIT: 对浮点数float/double专门优化分离符号、指数、尾数分别编码实操心得不要盲目开启 Dictionary。我们曾在一个用户画像表上对user_idBIGINT10 亿 distinct启用 Dictionary结果文件体积反而增大 17%因为字典本身占了 200MB且查找开销抵消了压缩收益。正确做法是对STRING类别字段distinct count 1000 时启用对INT类别优先用DELTA对BOOLEAN强制RLE。3.4 Compression 编码组合策略Snappy、Zstd、LZ4 的选型实测Parquet 本身不定义压缩算法而是通过compression参数委托给外部库。主流选项有算法压缩比压缩速度解压速度适用场景我们的实测10GB 日志Snappy2.1:1500 MB/s1200 MB/s通用首选平衡性最好体积 4.7GB写耗时 82s读耗时 14sZstd (level 3)2.8:1320 MB/s950 MB/s存储成本敏感CPU 充足体积 3.5GB写耗时 115s读耗时 11sLZ41.9:1650 MB/s1800 MB/s极致读性能容忍稍大体积体积 5.2GB写耗时 68s读耗时 9.2sGZIP3.5:180 MB/s400 MB/s绝对避免CPU 瓶颈明显体积 2.8GB写耗时 420s读耗时 28s结论非常明确LZ4 是 OLAP 查询场景的王者Snappy 是 ETL 流水线的守门员Zstd 是冷数据归档的利器。我们在实时数仓中Kafka → Flink → S3 的链路全程用 LZ4确保 BI 工具秒级响应而在 T1 的风控模型训练数据集上用 Zstd level 3 归档节省 40% S3 存储费用。还有一个隐藏技巧Parquet 支持 per-column compression。比如user_id列用DELTA LZ4event_payloadJSON 字符串列用ZSTDis_error布尔列用RLE SNAPPY——这种混合策略比全文件统一压缩平均再降 12% 体积。4. 实战配置与性能调优从 Spark 写入到 Trino 查询的全链路参数指南4.1 Spark 写入端12 个关键参数的取舍逻辑Spark 是 Parquet 最常用写入引擎但默认配置远非最优。以下是我们在生产环境验证过的 12 个核心参数按重要性排序1.spark.sql.parquet.compression.codec推荐值lz4查询优先或zstd存储优先原理Codec 选择直接影响读写吞吐。snappy是 Spark 3.0 默认但 LZ4 解压快 30%Zstd 压缩比高 25%。配置方式spark.conf.set(spark.sql.parquet.compression.codec, lz4)2.spark.sql.parquet.block.size推荐值134217728128MB原理对应 Parquet Row Group 大小。设得太小如 64MB导致小文件泛滥太大如 256MB降低谓词过滤精度。128MB 是 S3 分块上传、HDFS Block、计算内存的黄金交点。3.spark.sql.parquet.page.size推荐值10485761MB原理Page 是最小 I/O 单位。1MB 平衡了随机读取效率太小则 Page Header 开销占比高和内存占用太大则单次加载压力大。4.spark.sql.parquet.enable.dictionary推荐值true但需配合spark.sql.parquet.dictionary.pageSize原理启用字典编码但必须限制字典大小否则 OOM。我们设为10485761MB防止长字符串字段撑爆内存。5.spark.sql.parquet.mergeSchema推荐值false生产环境务必关闭原理当写入多个 Schema 不一致的 DataFrame 时Spark 会尝试合并 Schema。这在开发期方便但生产中极易引发隐式类型转换错误如int→long且合并过程消耗 CPU。正确做法是ETL 任务前强制cast()统一 Schema。6.spark.sql.parquet.writeLegacyFormat推荐值false必须关闭原理Legacy Format 使用旧版时间戳/十进制编码与 Trino/PrestoDB 不兼容。开启会导致下游查询报Invalid timestamp错误。7.spark.sql.adaptive.enabled推荐值trueSpark 3.2原理AQE 能动态优化 Parquet 写入自动合并小文件避免coalesce(1)的僵化、调整分区数防止 skew、优化 join 策略。我们某订单表写入AQE 将 2000 个小文件合并为 12 个 128MB 文件下游查询提速 3.2 倍。8.spark.sql.parquet.outputTimestampType推荐值TIMESTAMP_MICROS原理统一时间戳精度。TIMESTAMP_MILLIS是旧默认但微秒级TIMESTAMP_MICROS是现代数据湖标准避免 Trino 中timestamp字段精度丢失。9.spark.sql.parquet.int96RebaseModeInWrite推荐值EXCEPTION原理Hive 旧版用 INT96 存时间戳存在时区偏移问题。设为EXCEPTION会在遇到 INT96 时直接报错强制开发者用标准TIMESTAMP类型杜绝隐患。10.spark.sql.parquet.fieldIdWriteEnabled推荐值true原理写入 Parquet Schema 时嵌入字段 ID。这是 Iceberg Schema Evolution 的前提支持字段重命名、位置调整等操作。11.spark.sql.parquet.binaryAsString推荐值false必须关闭原理旧版 Spark 会把binary类型当string处理导致byte[]被错误 UTF8 解码。关闭后binary保持原样兼容 Avro/Protobuf 序列化数据。12.spark.sql.parquet.filterPushdown推荐值true默认原理允许 Spark 在 scan 阶段下推过滤条件到 Parquet Reader跳过不匹配的 Row Group。这是性能基石绝不可关。实操心得我们把这 12 个参数封装成ParquetWriterConfig对象在所有 Spark 作业启动时统一 apply。同时用spark.sql(DESCRIBE DETAIL my_table).show()定期审计表属性确保providerparquet、partitionColumns正确、properties中包含writer.model.name等业务标签。一次配置全局生效避免“每个 job 自己 set 一堆 conf”的混乱。4.2 Trino 查询端如何让 Parquet 发挥 100% 性能Trino原 PrestoSQL是 Parquet 最激进的优化者其 Reader 模块贡献了 Parquet 社区 40% 的 PR。以下是线上验证的 8 个关键配置1.hive.parquet.use-column-names推荐值true原理Trino 默认按 Schema 顺序读列position-based但 Parquet 文件可能因 writer 版本不同导致列序错乱。启用后Trino 严格按列名name-based匹配100% 兼容。2.hive.parquet.predicate-pushdown-enabled推荐值true默认原理激活谓词下推。Trino 会解析 WHERE 条件生成ColumnIndexFilter结合 Parquet 的 statistics 精准跳读。3.hive.parquet.ignore-stats推荐值false必须为 false原理设为 true 会禁用 statistics所有 Row Group 全量读取性能归零。这是线上事故高发点——某次运维误配导致 10TB 表查询从 8s 暴涨至 320s。4.hive.parquet.use-column-index-filter推荐值true原理启用 Column IndexParquet 2.0 特性在 Page 级别提供更细粒度的 min/max/null_count比 Row Group 级 statistics 过滤精度再提升 22%。5.hive.parquet.optimized-reader.enabled推荐值trueTrino 375 默认原理启用向量化 Reader用 Java Unsafe 直接操作内存避免对象创建GC 降低 70%。6.hive.parquet.dictionary-max-memory推荐值1GB原理控制字典解码内存上限。设得太小如 128MB会导致频繁重建字典太大如 4GB则浪费内存。1GB 平衡了 99% 场景。7.hive.parquet.read-block-size推荐值134217728128MB原理与 Spark 的block.size对齐确保读写 block size 一致避免跨 block 的 Page 拆分。8.hive.parquet.file-tail-caching-enabled推荐值true原理缓存 Parquet Footer通常 5KB避免每次查询都重新 fetch S3 的文件末尾。在高并发场景下S3 GET 请求减少 35%。实操心得我们在 Trino Coordinator 上部署了parquet-inspector工具定期扫描热表输出row_group_count,avg_row_group_size,dictionary_ratio,page_count_per_column等指标。当发现某表avg_row_group_size 64MB立即触发ALTER TABLE ... COMPACTIceberg或MSCK REPAIR TABLEHive进行小文件合并。另有一个血泪教训某次升级 Trino 从 350 到 375未更新hive.parquet.optimized-reader.enabledtrue导致新版本向量化 Reader 未启用查询性能不升反降 18%回滚后才排查出。4.3 文件管理与生命周期如何避免“Parquet 文件雪崩”Parquet 的优势建立在“合理文件大小”基础上而生产中最常见的反模式是“小文件地狱”。我们总结出一套闭环治理方案1. 写入侧预防Spark 作业必须设置coalesce(n)或repartition(n)n total_data_size / 128MB向上取整。例如写入 5TB 数据repartition(40000)。启用 AQE 的coalescePartitions.enabled让 Spark 自动合并小 partition。使用 Iceberg 的rewrite_data_filesprocedure定时合并小文件。2. 存储侧监控我们用 Prometheus Grafana 监控 S3 桶s3_object_count{bucketprod-logs, prefix~.*/2024-.*}跟踪每日文件数增长s3_object_size_bytes{bucketprod-logs, prefix~.*/2024-.*}统计文件大小分布告警规则当avg by (prefix) (s3_object_size_bytes) 64MB持续 1 小时触发 Slack 告警。3. 治理侧执行冷数据归档用 AWS Lifecycle Policy将 90 天前的 Parquet 文件转为 Glacier Deep Archive存储成本降 85%。过期数据清理Iceberg 的expire_snapshotsprocedure 自动删除 7 天前的 snapshot释放空间。Schema 清理用spark.sql(DESCRIBE my_table).filter(col_name like %_deprecated%).show()定期扫描废弃字段执行ALTER TABLE DROP COLUMN。注意不要用hadoop fs -rmr直接删 Parquet 文件Iceberg/Hudi 表必须通过其 API 删除否则元数据与文件不一致导致查询失败。我们曾因手动删文件引发 3 小时数据不可用事故代价惨重。5. 常见问题与排错实战从 “Failed to read footer” 到 “Statistics not available”5.1 典型错误速查表症状、根因、解决方案错误信息根因分析解决方案实操命令/代码Failed to read footer: Not a Parquet file文件损坏、Magic Bytes (PAR1) 丢失、或被截断检查文件完整性head -c 4 file.parquet | hexdump -C应输出50 41 52 31用parquet-tools meta file.parquet验证aws s3 cp s3://bad/file.parquet ./ head -c 4 ./file.parquet | hexdump -CCould not read footer: java.io.IOException: Stream is closedS3 权限不足无法读取文件末尾Footer 在文件尾部检查 IAM Policy 是否包含s3:GetObject且Resource覆盖完整路径确认 bucket policy 未 denyaws s3api get-object --bucket my-bucket --key logs/2024-01-01/part-00000.parquet /dev/nullColumn statistics not available for column: xxxwriter 未写入 statisticsspark.sql.parquet.statistics.enabledfalse或列为空启用 statisticsspark.conf.set(spark.sql.parquet.statistics.enabled, true)对空列补默认值df.na.fill({country_code: 0}).write.parquet(...)Unsupported type: DECIMALwriter 用旧版 Spark3.0写入 DECIMAL未启用parquet.decimal-as-strings升级 Spark 至 3.0或写入前cast(string)df.withColumn(amount, col(amount).cast(string)).write.parquet(...)Query failed: Invalid function signature: date_formatTrino 版本过低不支持 Parquet 的TIMESTAMP_MICROS升级 Trino 至 375或 Spark 写入时设spark.sql.parquet.outputTimestampTypeTIMESTAMP_MILLIStrino-cli --server https://trino.prod --catalog hive --schema default --execute SELECT version();java.lang.OutOfMemoryError: Direct buffer memoryParquet Reader 分配的 off-heap memory 不足增加 JVM-XX:MaxDirectMemorySize4G调小hive.parquet.dictionary-max-memory512Mexport EXTRA_JVM_ARGS-XX:MaxDirectMemorySize4Gin trino-env.sh5.2 Statistics 缺失的深度诊断不只是配置问题Statistics not available是最常被低估的问题。表面看是配置没开但深层原因有三层第一层writer 端未启用检查 Spark 作业日志搜索parquet.statistics.enabled确认为true。若用 Structured Streaming还需query.conf.set(spark.sql.parquet.statistics.enabled, true)。第二层数据本身不支持Parquet 的 statistics 仅对INT32/INT64/FLOAT/DOUBLE/BOOLEAN/BINARY有效对INT96旧时间戳、FIXED_LEN_BYTE_ARRAY固定长度字节数组不生成。用parquet-tools dump --page file.parquet查看 page header若statistics字段为空则属此类。解决方案写入前cast()转换类型。第三层文件损坏或截断即使 writer 正常网络中断、磁盘满也会导致 Footer 写入失败statistics 丢失。此时parquet-tools meta会报错但parquet-tools cat可能部分成功。终极验证用 Pythonpyarrow.parquet.read_table()加载若table.schema.field(xxx).metadata.get(bparquet:statistics)为 None则文件已损。实操心得我们在所有 ETL 任务末尾增加校验步骤from pyarrow.parquet import ParquetFile pf ParquetFile(s3://bucket/path/part-00000.parquet) assert len(pf.metadata.row_group(