题干与适用场景
湖仓任务从对象存储读取 Parquet。少量文件在跨区域复制后出现页数据损坏，现有流程只能在整文件失败时重跑。请设计页级 CRC 校验方案，说明校验覆盖范围、压缩顺序、reader 兼容、隔离损坏页和验收指标。题目适合数据工程、存储格式和湖仓基础设施岗位，核心考察列式文件完整性与故障边界，归为 data。
面试官考察点
- 能否区分页级 CRC 与文件级校验，并准确说明 CRC 是可选字段。
- 能否解释校验对象和压缩边界，避免把校验头部或解压结果混为一谈。
- 能否设计旧 reader 忽略 CRC 时的兼容与灰度策略。
- 能否在发现坏页后阻止静默脏读，并把文件隔离、重复制和重写分开。
- 能否用结果一致性、坏页定位时间和额外 CPU/I/O 衡量收益。
回答前需要澄清的问题
- 使用的 Parquet writer、reader 和版本是否实现页 CRC 校验？
- 损坏发生在对象存储、复制链路还是本地缓存？是否有端到端校验？
- 文件是否启用压缩、加密或页索引？消费端能否定位 row group 与 column chunk？
- 业务允许跳过损坏文件、重建分区，还是必须恢复全部行？
- 读取失败能否安全重试，重试是否会把坏对象继续缓存？
30 秒回答框架
“我先依据 Parquet format 规范确认页 CRC 的写入和读取支持，记录文件、row group、column chunk、page 类型及对象版本。校验失败时立即将对象标为不可用，保留坏页定位信息，不跳过返回结果；通过副本或上游重写恢复。旧 reader 忽略 CRC 仍可读取，但不应把它当作完整性证明。灰度阶段用注入损坏的 data page、dictionary page 和复制截断样本，比较错误捕获率、定位时间、重试成本和结果一致性。”
分步骤深入解答
第一步：明确规范边界
Parquet 页头包含可选的 32 位 CRC 字段，适用于 data page、dictionary page 等页类型。先确认 writer 是否真的填充该字段、reader 是否在读取时验证；仅修改 writer 配置不能保证消费端检测损坏。
write page bytes -> compute CRC32 -> persist page header + payload
read page -> read header -> verify payload CRC -> decode校验记录应带文件版本、row group、column chunk、page ordinal 和对象版本，便于重试后确认读取的是同一对象。
第二步：处理压缩与校验顺序
规范对 CRC 计算的字节范围必须以实际格式定义和实现为准。工程上要固定“写入计算什么、读取验证什么”的版本矩阵，不能凭经验把解压后的逻辑值重新算 CRC。压缩解码失败与 CRC 不匹配是两类错误，日志和指标要分开。
第三步：设计故障隔离
校验失败时让当前文件读取失败并进入隔离队列，记录对象 URI、版本、页定位和异常类型。不要静默跳过损坏页，因为结果会缺行。若有另一副本，按对象版本读取并再次验证；若副本均坏，触发分区重写或从上游重放，而不是无限重试同一对象。
第四步：兼容旧 reader
旧 reader 可能忽略 CRC 字段并正常返回数据，因此“能读”不等于“验证过”。灰度发布时建立 reader 版本矩阵：新 reader 开启严格验证，旧 reader 继续读取但标注完整性能力缺失。对关键任务可在新 reader 旁路抽样验证，逐步淘汰无法报告校验状态的版本。
第五步：结合加密和页索引
页加密、压缩和 CRC 的顺序必须遵循目标实现；不能把加密认证标签当作 CRC，也不能假设页索引能发现 payload 损坏。读取路径应先完成格式要求的完整性验证，再解码和页裁剪，并确保错误定位仍能映射到 column chunk。
第六步：构造损坏注入测试
复制测试对象后只翻转一个 data page 字节，再分别破坏 dictionary page、页头、对象尾部和复制版本。验证新 reader 能定位错误，旧 reader 的差异被记录；同时测试压缩编码、null、空页和大页，避免只覆盖普通样本。
第七步：定义可重复验收
在固定对象版本、相同并发和冷缓存条件下比较开启与关闭 CRC 的 CPU、读取字节、p95、失败捕获率和定位时间。结果数据必须与未损坏对照完全一致；损坏样本必须失败并进入隔离队列。将校验失败率、重复重试次数和恢复成功率接入告警。
高质量示范回答
“我会先对照 Parquet format 规范和目标 reader 的实现，确认页 CRC 是可选字段、哪些页类型写入校验，以及校验覆盖的确切字节。写入时记录文件版本和页定位，读取时先验证 CRC，再解压和解码；压缩失败与 CRC 失败分别统计。发现坏页立即让文件失败并隔离，按对象版本尝试另一副本，不能跳过坏页返回部分结果，也不能无限重试同一坏对象。
旧 reader 可能忽略 CRC，所以灰度中建立版本矩阵和能力标签。用字节翻转、页头损坏、dictionary page 损坏和复制截断构造样本，比较捕获率、定位时间、CPU、读取字节、恢复成功率和结果哈希。只有新 reader 能稳定捕获且恢复流程可控，才扩大写入范围。”
常见错误
- 把 CRC 当加密认证 → CRC 主要检测随机损坏，不能证明来源和防篡改 → 需要时叠加加密认证。
- 只改 writer 不测 reader → 下游可能忽略字段 → 建立读写版本矩阵。
- 跳过坏页继续返回 → 产生静默缺行 → 失败并隔离，走副本或重写。
- 把压缩失败和 CRC 失败混为一类 → 无法判断链路或解码问题 → 分开指标和恢复动作。
- 无限重试同一对象 → 放大成本并持续读取坏数据 → 固定对象版本并设置重试上限。
- 只测整文件损坏 → 漏掉页头、字典页和边界页 → 做分层损坏注入。
追问及应对
追问一：CRC 能防止恶意篡改吗？
不能。CRC 适合检测传输或存储中的随机错误；需要防篡改时使用加密认证、签名或受信存储校验，并保留 CRC 作为快速局部检测。
追问二：旧 reader 忽略 CRC 会不会破坏兼容？
通常不会改变格式可读性，但它无法提供完整性保证。发布前应标注能力，关键任务优先使用严格验证 reader，并观察旁路结果。
追问三：发现一个坏页能否只重读该页？
可以尝试同一对象的范围读取或另一副本，但最终结果必须验证完整；若副本仍坏，应重写文件或重放上游，不能把未验证数据交给下游。
追问四：为什么要记录对象版本？
对象可能在重试期间被覆盖。版本让日志、CRC 结果和恢复动作对应同一字节内容，避免把不同版本的错误混在一起。
追问五：如何控制 CRC 的性能开销？
以真实页大小和读取并发测 CPU、吞吐和 p95；可先对高风险分区灰度，并用抽样任务评估收益，不能只依据理论开销。