超大 ORC 文件在云存储上的 Footer 读取优化：从 P0 故障到毫秒级启动
0. 问题引入：一次金融交易归档系统的 P0 级故障
用户原始问题：“在 AWS S3 或 Azure Blob 上读取超大 ORC 文件（>5TB）时，如何避免 Footer 读取成为瓶颈？”
在我们负责的全球金融交易归档系统中，每日会产生超过 10TB 的交易流水，并以单个 ORC 文件的形式归档到 AWS S3。某天，下游的合规审计作业突然开始大规模失败，错误日志显示TimeoutException: Failed to read footer from s3a://.../transactions_20260409.orc。
深入排查发现，这个 5.2TB 的 ORC 文件，其 Footer（包含所有 Stripe 的元数据）大小达到了惊人的1.8GB！每次 Spark 作业启动时，都需要从 S3 的末尾读取这 1.8GB 的数据来构建执行计划。由于 S3 是对象存储，不支持高效的随机读，这次 Footer 读取操作耗时长达12 分钟，远超作业的默认超时阈值（5分钟），最终导致作业失败。
这次 P0 事故让我们意识到，在云原生数据湖架构下，ORC 文件的物理布局设计必须与底层存储的 I/O 特性深度协同。本文将基于Apache ORC 2.
