ORC 的错误处理和异常恢复机制有哪些？例如 CRC 校验失败时的行为。

发布时间：2026年4月10日

问题引入：从金融交易流水归档的 P0 级数据损坏事故说起

在一次例行的金融交易对账任务中，我们遭遇了灾难性的数据不一致。下游的 Spark 作业在读取前一天归档的 ORC 文件（/data/finance/transactions.orc）时，突然抛出java.io.IOException: Invalid checksum异常，并且作业直接失败。这笔“消失”的交易金额高达数百万，触发了最高级别的风控警报。

经过紧急排查，我们定位到根本原因：在 Flink 实时入湖作业将数据写入 S3 的过程中，某个网络抖动导致一个 Stripe 的尾部字节在传输中被篡改。由于 ORC 文件默认启用了CRC (Cyclic Redundancy Check)校验，Reader 在读取该 Stripe 时检测到了数据损坏，并立即中止了读取。

这次事故暴露了我们对 ORC 错误处理机制的认知盲区。ORC 作为一个企业级存储格式，其设计哲学是在数据完整性和查询可用性之间做出明确的权衡。它并非一个“尽力而为”的格式，而是一个“要么全对，要么报错”的严谨系统。本文将深入剖析 Apache ORC 2.3.0 中的错误处理与异常恢复机制，特别是围绕 CRC 校验这一核心防线，为你揭示 ORC 如何守护数据的“最后一公里”安全，并