1. 项目概述1.1 这到底是个什么项目先别被标题吓住拆开来看其实就是一个数据湖场景里很典型的组合Iceberg当下最流行的开源数据湖表格式之一负责管理海量数据文件的元数据、快照和事务。Rest CatalogIceberg 的 Catalog 实现方式之一通过 HTTP 接口把元数据操作和存储解耦让引擎Spark、Flink、Trino 等能通过标准 REST 协议访问 Iceberg 表。OSS阿里云对象存储作为 Iceberg 表数据的落地存储层。Nessie一个基于 Git 理念的 Catalog 服务支持分支、标签、提交历史常和 Iceberg 搭配做数据湖的版本管理和多分支开发。我用这套组合做了一个实时数仓的存储底座业务数据落 OSSIceberg 管表结构Nessie 做分支发布和灰度Rest Catalog 统一暴露给上层计算引擎。看着挺美真跑起来才发现坑一个接一个。其中最折磨人的就是两个问题Polaris 使用 Rest Catalog 连接 OSS 时所有上传/提交操作都报x-amz-content-sha256相关错误。Nessie 配置和 Iceberg 集成时各种版本不匹配、参数不生效、提交报错。这篇文章把我这两周踩坑、查源码、看 issue、反复验证的过程全部记录下来包含最终可用的配置、报错原因分析和排查思路。希望看完你能少走一半弯路。1.2 这套方案适合谁参考如果你属于下面任意一类这篇文章值得花十分钟读完正在用 Iceberg Rest Catalog 对接阿里云 OSS遇到 S3 兼容接口签名报错的。想用 Nessie 做 Iceberg 的多分支管理但被版本兼容性搞得头疼的。搞实时数仓、数据湖选型想提前知道这套组合有哪些隐藏成本的。我自己用的是Spark 3.5 Iceberg 1.5.0 PolarisIceberg 官方 Rest Catalog 实现 Nessie 0.89.0 阿里云 OSS下文所有配置和踩坑记录都基于这套环境但结论大多可以推广到相近版本。2. 技术栈选型与整体架构思路2.1 为什么选 Iceberg Rest Catalog OSS Nessie先说清楚这套组合扮演的角色后面讲问题才不至于一头雾水。Iceberg 解决的是“表”的问题。传统 Hive 表把分区目录当表结构数据文件一多更新、删除、小文件合并都是灾难。Iceberg 用元数据文件清单文件数据文件三层结构管理表每次写入生成一个快照查询走元数据过滤不用全目录扫描。在 OSS 这种对象存储上Iceberg 的表现比 Hive 表稳健得多。Rest Catalog 解决的是“元数据访问”的问题。Iceberg 早期用 Hive MetastoreHMS或 JDBC 作为 Catalog前者部署重且接口固化后者不适合多引擎并发。Rest Catalog 把 Catalog 封装成一个 HTTP 服务客户端通过 REST API 完成建表、删表、提交事务、加载元数据等操作。好处是语言无关任何能发 HTTP 请求的引擎都能接入。可以集中管理权限、审计、多租户隔离。Catalog 服务端可以随时替换底层存储比如元数据存在数据库或文件系统里。OSS 解决的是“数据文件存哪”的问题。阿里云 OSS 兼容 S3 APIIceberg 官方就有S3FileIO实现理论上把 endpoint 指过去就行。但它毕竟不是真正的 S3签名算法、路径风格、请求头解析上有很多“近似但不完全一致”的地方这就是x-amz-content-sha256报错的根源后面细说。Nessie 解决的是“表结构版本管理”的问题。想象你把整个数据湖当成一个 Git 仓库每张表就是一个文件每一次 DDL/DML 就是一次 commit然后你可以基于任意历史提交拉分支、改结构、灰度验证验证通过再合并回主分支。Nessie 干的就是这件事。对于多团队协作、生产与开发环境混用的场景特别有用。2.2 架构拓扑与数据流------------------------------------------------------------------- | 计算引擎层 | | Spark / Flink / Trino / StarRocks... | ------------------------------------------------------------------- | REST 协议iceberg.rest.Catalog v ------------------------------------------------------------------- | Catalog 服务层 | | PolarisIceberg Rest Catalog 实现 / NessieGit-like | ------------------------------------------------------------------- | S3FileIOS3 兼容协议 v ------------------------------------------------------------------- | 存储层 | | 阿里云 OSSBucket AccessKey Endpoint | -------------------------------------------------------------------图里可以看出计算引擎不直接碰 OSS 元数据而是先找 Catalog 服务要表结构拿到 manifest 文件位置后再由S3FileIO去 OSS 读数据文件。所以 Catalog 服务能不能正确生成有效的 OSS 路径和签名直接决定能不能读写。2.3 版本选型教训别追新追新容易出事我一开始用的是 Iceberg 1.4.3 Nessie 0.88.0后来为了试 Polaris 的新特性升到了 Iceberg 1.5.0结果一堆兼容性问题冒出来。组件初始版本最终稳定版本说明Iceberg1.4.31.5.01.5.0 对 Rest Catalog 支持更完善但 S3FileIO 配置项有变化Polaris0.0.1-SNAPSHOT0.0.1-SNAPSHOT官方还在演进中配置项调整频繁Nessie0.88.00.89.00.89.0 开始支持 Iceberg 1.5.x 的 Rest 规范Spark3.4.13.5.0适配 Iceberg 1.5.0 需要 Spark 3.5OSS SDK-3.17.2影响不大主要是服务端兼容踩坑后的经验是不要盲目追最新版本优先看官方 Release Note 里的兼容矩阵。Iceberg 和 Nessie 的迭代速度很快版本间 API 变动频繁稍不留神就是连环坑。3. 核心问题一Polaris x-amz-content-sha256 报错深度拆解3.1 报错现象与触发条件先说现象。我用 Spark 通过 Polaris 的 Rest Catalog 建表、写数据第一次建表还能成功因为建表只写元数据不触发数据文件上传一旦执行INSERT INTO开始写数据文件立刻报错Caused by: java.net.SocketException: Connection reset Caused by: com.aliyun.oss.common.comm.CommunicationException: Connection reset by peer Caused by: org.apache.iceberg.exceptions.RuntimeIOException: Failed to write file to OSS ... Caused by: software.amazon.awssdk.services.s3.model.S3Exception: null (Service: S3, Status Code: 400, Request ID: ...)最核心的一条错误信息是The request signature we calculated does not match the signature you provided. Check your key and signing method. (Service: S3, Status Code: 403)或者在某些版本下会直接提示x-amz-content-sha256 must be UNSIGNED-PAYLOAD or a valid SHA256 hash两种报错其实指向同一个问题OSS 服务端对 S3 签名协议中x-amz-content-sha256请求头的解析和 AWS S3 不一致。3.2 为什么会出现这个请求头x-amz-content-sha256是 AWS S3 在 SigV4 签名协议里引入的一个请求头作用是告诉服务端“请求体内容的 SHA256 哈希值”用于防止请求体在传输途中被篡改。在 AWS S3 上这个头有三种取值具体的 SHA256 哈希字符串例如e3b0c44298fc1c149afbf4c8996fb924...。UNSIGNED-PAYLOAD表示请求体内容不参与签名校验。STREAMING-AWS4-HMAC-SHA256-PAYLOAD即STREAMING-UNSIGNED-PAYLOAD-TRAILER等流式上传模式。客户端比如 Iceberg 用的 AWS SDK for Java 2.x在向 S3 发起请求时会自动加上这个头。默认情况下AWS SDK 会把请求体先读进内存算出 SHA256再附带签名发送。对于大文件上传这会带来很大的内存开销。于是 Iceberg 的S3FileIO针对对象存储场景做了一件事在配置里允许你关闭这个请求体哈希计算也就是让 SDK 把x-amz-content-sha256的值置为UNSIGNED-PAYLOAD避免一次性加载整个文件到内存。理论上这个设计没问题但是阿里云 OSS 的 S3 兼容层对UNSIGNED-PAYLOAD的解析并不总是像 AWS S3 那样宽容。某些情况下 OSS 服务端会认为这个头的值不合法直接返回 400 或 403。3.3 根本原因深挖我特意去翻了 Iceberg 和 AWS SDK 的源码把整个链路摸了一遍Iceberg 侧S3FileIO在初始化时会把s3.signer、s3.use-arn-region-enabled、s3.path-style-access等配置传给 AWS SDK。其中最关键的是s3.checksum-validation-enabled和s3.ssec这类参数。在 Iceberg 1.4.x 到 1.5.0 之间S3FileIO增加了对s3.signer的显式支持意图是让你把 SigV4 签名器的实现切换为AWS4UnsignedPayloadSigner。AWS SDK 侧默认的DefaultS3Signer会计算请求体 SHA256。AWS4UnsignedPayloadSigner则会在请求头里写UNSIGNED-PAYLOAD。如果配置没生效SDK 就还是走默认签名器请求头里带着完整 SHA256。OSS 服务端侧当前阿里云 OSS 的 S3 兼容 API 对x-amz-content-sha256的校验逻辑比较严格。它要求请求头要么是一个合法 SHA256要么是UNSIGNED-PAYLOAD。问题在于——当 SDK 用的是UNSIGNED-PAYLOAD但签名计算时用的却是默认 signer或者反过来OSS 就会判定签名不匹配。最终问题定位Iceberg 1.5.0 的S3FileIO有一个 bug在通过 Rest Catalog 自动加载 S3 配置的场景下s3.signer配置没有正确传递给 AWS SDK。导致请求头声明的是UNSIGNED-PAYLOAD但签名算法用的却是默认 signerOSS 一校验就崩。3.4 排查思路一步步缩小范围如果你也遇到类似问题别急着改代码按这个思路排查第一步确认请求头值。在 Spark 提交脚本里加上 JVM 参数开启 AWS SDK 的调试日志--conf spark.driver.extraJavaOptions-Dorg.slf4j.simpleLogger.defaultLogLeveldebug -Daws.request.debugtrue --conf spark.executor.extraJavaOptions-Dorg.slf4j.simpleLogger.defaultLogLeveldebug -Daws.request.debugtrue跑一次 INSERT在日志里搜x-amz-content-sha256看实际发的值是什么。第二步对比 AWS S3 和 OSS 行为差异。如果你有 AWS 环境同样的配置连 AWS S3 大概率一切正常因为 AWS 对签名头宽容得多。这就反过来印证问题出在 OSS 的兼容层。第三步确认配置是否传递到 AWS SDK。在 Spark 代码里或 Catalog 配置里打印S3FileIO的实际配置项。最简单的方式是在代码中调用System.out.println(((S3FileIO) io).getS3FileIOProperties());但 Rest Catalog 下的配置是服务端返回给客户端的这个链路很容易断。3.5 最终解决方案含详细配置3.5.1 方案一显式设置 signer 并关闭校验推荐在 Spark 侧连接 Rest Catalog 时除了必填的catalog-impl、uri等参数外额外加上CREATE CATALOG polaris_oss WITH ( type rest, uri http://localhost:8181/api/catalog, warehouse oss://my-bucket/warehouse, credential polaris:polaris, io-impl org.apache.iceberg.aws.s3.S3FileIO, s3.endpoint https://oss-cn-hangzhou.aliyuncs.com, s3.access-key-id your-access-key, s3.secret-access-key your-secret-key, s3.signer software.amazon.awssdk.s3.signer.AwsS3V4Signer, s3.use-arn-region-enabled false, s3.path-style-access true, http-client.type okhttp );注意几个关键点s3.signer在这套方案里实际上不生效这是 Iceberg 的一个 bug所以我换了个更稳的思路见方案二。s3.path-style-access true很重要OSS 的 S3 兼容层对 virtual-hosted-style 支持不完整强烈建议用 path-style。http-client.type okhttp是因为默认的 Apache HttpClient 在某些版本下会覆盖请求头。3.5.2 方案二在 Spark Session 里强制加 Hadoop 配置终极解法上面的方法我在 1.5.0 版本下没完全生效最终是靠 Hadoop 配置层面的参数解决的在 Spark 作业启动脚本里加上--conf spark.sql.catalog.polaris_oss.s3.signersoftware.amazon.awssdk.s3.signer.AwsS3V4Signer --conf spark.sql.catalog.polaris_oss.s3.checksum-validation-enabledfalse --conf spark.sql.catalog.polaris_oss.s3.ssec.enabledfalse同时在 Spark 的 Hadoop 配置目录core-site.xml里加上configuration property namefs.s3a.signer.override/name valuesoftware.amazon.awssdk.s3.signer.AwsS3V4Signer/value /property property namefs.s3a.aws.credentials.provider/name valueorg.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider/value /property /configuration这组配置加完之后x-amz-content-sha256的报错彻底消失。原理是显式指定了签名器让请求头和签名算法保持一致而且关闭了响应校验避免 OSS 返回的错误被 SDK 二次校验拦截。提示fs.s3a.signer.override是 Hadoop S3A 文件系统层的参数它会影响所有通过 Hadoop 访问 S3 兼容存储的路径。如果同集群有其他 S3 任务注意隔离性。3.5.3 方案三绕过 SDK直接用 OSS SDK 写数据不推荐Iceberg 底层用的是 AWS SDK for Java 2.x理论上没法直接用 OSS SDK 替换除非你自己实现一套FileIO。工作量太大不做详细展开。3.6 这个坑的本质总结用一句话总结Iceberg 的 S3FileIO 和阿里云 OSS 的 S3 兼容层在签名协议上存在细微不一致Iceberg 1.5.0 在 Rest Catalog 场景下又有配置穿透 bug最终导致x-amz-content-sha256请求头和实际签名算法不一致。这不是 OSS 或者 Iceberg 单方面的问题而是两套系统对上暗号时对不上。理解了这一点以后换对象存储比如腾讯云 COS、华为云 OBS大概率还会遇到类似的坑排查思路完全一致。4. 核心问题二Nessie 配置与集成实战4.1 Nessie 到底解决什么问题值得引入吗按照我的理解传统数仓的 DDL 变更基本靠人肉审批发布窗口权限和版本都靠管理流程约束。Nessie 把“表结构”和“数据快照”变成一个有版本的树你可以在任意历史点上拉分支做实验实验不污染主分支验证完毕合并回主线。比如我们团队多个业务线共用一套 Iceberg 表A 组要加一个字段B 组要删一个字段在传统模式下必须排队A 不能影响 B。有了 NessieA 在dev-branch-a上加字段B 在dev-branch-b上删字段各自测试互不影响测完分别merge到main。听起来很美。4.2 Nessie Iceberg 的部署架构Nessie 官方推荐的方式是运行一个 Nessie Server然后 Iceberg 通过 Rest Catalog 协议连上它。Spark/Flink/Trino -- Iceberg Rest Catalog Client -- Nessie Server -- Metadata Store | v PostgreSQL/InMemoryNessie Server 本身不存数据文件它只存 Iceberg 表的元数据指针和 Git 风格的提交历史。底层的 metadata store 可以是内存、PostgreSQL 或者 MongoDB。生产环境建议 PostgreSQL。4.3 Nessie 安装与启动配置我用 Docker 方式启动的 Nessie Serverversion: 3.8 services: nessie: image: ghcr.io/projectnessie/nessie:0.89.0 ports: - 19120:19120 environment: - QUARKUS_HTTP_PORT19120 - QUARKUS_DATASOURCE_DB_KINDpostgresql - QUARKUS_DATASOURCE_JDBC_URLjdbc:postgresql://postgres:5432/nessie - QUARKUS_DATASOURCE_USERNAMEnessie - QUARKUS_DATASOURCE_PASSWORDnessie - QUARKUS_DATASOURCE_JDBC_DRIVERorg.postgresql.Driver - QUARKUS_HIBERNATE_ORM_DATABASE_GENERATIONupdate - QUARKUS_HTTP_CORS_ORIGINS* depends_on: - postgres postgres: image: postgres:15 environment: - POSTGRES_USERnessie - POSTGRES_PASSWORDnessie - POSTGRES_DBnessie volumes: - nessie-db:/var/lib/postgresql/data volumes: nessie-db:关于这个配置有几点说明QUARKUS_HTTP_CORS_ORIGINS*在测试环境方便前端联调生产环境务必收紧。Nessie 0.89.0 默认使用 Quarkus 3.x 框架所以环境变量全部以QUARKUS_开头。如果不用 PostgreSQL直接用默认的内存版本删掉datasource相关的环境变量即可但重启数据全丢。启动后验证curl http://localhost:19120/api/v2/tree能看到一个空的树结构就说明服务起来了。4.4 Spark 连接 Nessie 的完整配置Spark 3.5 Iceberg 1.5.0 Nessie 0.89.0 的正确连接方式如下首先在 Spark 启动脚本中把 Iceberg 和 Nessie 的依赖加进去spark-sql \ --packages org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.5.0,org.projectnessie:nessie-spark-extensions-3.5_2.12:0.89.0 \ --conf spark.sql.extensionsorg.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \ --conf spark.sql.catalog.nessieorg.apache.iceberg.spark.SparkCatalog \ --conf spark.sql.catalog.nessie.catalog-implorg.apache.iceberg.nessie.NessieCatalog \ --conf spark.sql.catalog.nessie.urihttp://localhost:19120/api/v1 \ --conf spark.sql.catalog.nessie.refmain \ --conf spark.sql.catalog.nessie.authentication.typebearer \ --conf spark.sql.catalog.nessie.authentication.tokenyour-token \ --conf spark.sql.catalog.nessie.warehouseoss://my-bucket/nessie-warehouse \ --conf spark.sql.catalog.nessie.io-implorg.apache.iceberg.aws.s3.S3FileIO \ --conf spark.sql.catalog.nessie.s3.endpointhttps://oss-cn-hangzhou.aliyuncs.com \ --conf spark.sql.catalog.nessie.s3.access-key-idyour-access-key \ --conf spark.sql.catalog.nessie.s3.secret-access-keyyour-secret-key \ --conf spark.sql.catalog.nessie.s3.path-style-accesstrue这里有几个大坑4.4.1 坑一uri 版本Nessie 0.89.0 提供/api/v1和/api/v2两套 API。Iceberg 1.5.0 的 NessieCatalog 默认用的是 v1 协议但 Nessie 0.89.0 的 v1 已经标记废弃且某些响应字段有变动。所以我改成显式指定http://localhost:19120/api/v1反而稳定。别用/api/v2那是 Nessie 原生客户端协议Iceberg 目前不支持。刚上手的人最容易在这个地方被绕晕Iceberg 的 Rest Catalog 和 Nessie 的 native API 是两个不同的协议不能互相混用。4.4.2 坑二ref参数--conf spark.sql.catalog.nessie.refmain指定默认分支。如果你没有名为main的分支Nessie 默认只有main但你可以在服务端改名这里就会报错。排查方法# 查看当前所有分支 curl http://localhost:19120/api/v1/trees # 创建一个新分支 curl -X POST http://localhost:19120/api/v1/trees \ -H Content-Type: application/json \ -d {name: dev-branch, hash: ...}4.4.3 坑三认证方式Nessie 默认没有开启认证authentication.typebearer可以随便填一个 token。但如果 Nessie 开启了 auth这里的 token 必须有效否则报 401。生产环境建议启用基于 OIDC 的认证但那是另一个大坑本文不展开。4.5 使用 Nessie 做多分支管理的实践连接成功后建表只是第一步真正有意思的是分支操作。我演示一个实际场景4.5.1 在开发分支上做表结构变更-- 当前在 main 分支 USE nessie; CREATE TABLE main_table (id INT, name STRING) USING iceberg; -- 创建开发分支 dev-branch CALL nessie.system.create_branch(dev-branch, main); -- 切换到 dev-branch SET spark.sql.catalog.nessie.ref dev-branch; -- 在 dev 分支上加字段 ALTER TABLE main_table ADD COLUMN age INT; -- 查 main 分支不受影响 SET spark.sql.catalog.nessie.ref main; DESCRIBE TABLE main_table; -- 只有 id, name 两个字段age 不在 -- 切回 dev 分支 SET spark.sql.catalog.nessie.ref dev-branch; DESCRIBE TABLE main_table; -- 有 id, name, age 三个字段这个体验确实像 GitDDL 变成有版本的操作团队协作时不必互相阻塞。4.5.2 合并分支-- 在 main 分支上执行合并 SET spark.sql.catalog.nessie.ref main; CALL nessie.system.merge_branch(dev-branch, main); -- 验证 DESCRIBE TABLE main_table; -- main 分支现在也有 age 字段了注意merge_branch的语义和 Git 的 merge 类似如果 main 分支在 dev 分支创建之后又有其他改动导致文件冲突合并会失败需要通过 rebase 或手动解决冲突。这个和 Git 是一个逻辑。4.5.3 分支历史的查看与回滚-- 查看提交历史 CALL nessie.system.show_log(main); -- 回滚到指定历史提交 CALL nessie.system.assign_branch(main, main, some-commit-hash);这里我踩过一个坑回滚之后Iceberg 数据文件并没有被删除只是元数据指针回到了历史位置。旧文件还躺在 OSS 里如果频繁回滚OSS 存储成本会一直涨。所以生产环境要定期清理孤儿文件。4.6 Nessie 和 Polaris 如何选择我同时用了 Polaris 和 Nessie两者并不冲突但要看场景对比项PolarisIceberg Rest CatalogNessie核心定位Iceberg Catalog 标准化实现数据湖版本管理 Catalog多版本/分支不支持原生分支概念支持 Git 风格分支、标签、回滚权限控制支持基于 Credential 和 Principal需要额外集成 OIDC适用场景多引擎共享同一套 Catalog统一元数据多团队并行开发、灰度发布、CI/CD部署复杂度较低中等需要数据库稳定性相对较新迭代快相对成熟我的建议是团队规模小、元数据统一是刚需时用 Polaris需要多分支开发、版本回溯、灰度发布时引入 Nessie。两者可以共存Polaris 作为底层 CatalogNessie 作为上层的版本控制层。5. 常见报错与排查技巧速查表整理一份我在整个过程中遇到的报错合集推荐收藏。每一条都是真金白银换来的。5.1 报错速查表报错关键词可能原因解决方案Connection reset by peer请求头被服务端判定异常直接断开连接检查x-amz-content-sha256相关配置x-amz-content-sha256 must be UNSIGNED-PAYLOAD or a valid SHA256 hash签名器和请求头值不匹配显式指定s3.signerAwsS3V4SignerThe request signature we calculated does not match签名算法不一致或 Endpoint 填错检查s3.endpoint和 AccessKeyTable does not exist(Rest Catalog)Catalog 服务元数据和存储不一致或命名空间错误检查warehouse配置和命名空间NoSuchBucketOSS Bucket 不存在或路径错误确认 Bucket 名和 regionNessie: ref not foundref参数指向了不存在的分支查看api/v1/trees确认分支名Unsupported operation: mergeNessie 版本和 Iceberg 版本不兼容升级 Nessie 或降低 Iceberg 版本Failed to find metadata tableIceberg 元数据表未正确加载检查iceberg.mr.catalog配置Invalid signatureAccessKey/SecretKey 不正确确认 OSS 的密钥对是主账号还是 RAM 子账号5.2 终极排查思路三板斧遇到问题先别慌按这三步走能解决 80% 的问题第一板斧抓真实请求。把客户端日志调到 DEBUG看实际发出的 HTTP 请求头和响应体。这一步能定位 90% 的协议问题。别嫌日志多关键时候救命。第二板斧隔离变量。先连 AWS S3 测试相同配置如果不报错说明是 OSS 兼容层问题再换 HMS Catalog 测试如果不报错说明是 Rest Catalog/Nessie 问题。逐步缩小范围。第三板斧查兼容矩阵。Iceberg 官方文档里的 Compatibility Matrix、Nessie 的 Release Notes以及 GitHub issue 列表都是宝贵的排错资源。很多坑官方其实早有记录只是没写进 README。6. 实践心得与经验分享6.1 这套方案踩完坑后我的最终结论Iceberg Rest Catalog OSS Nessie 组合是完全可行的前提是做好版本锁定和配置管理。一周前我还想放弃这套方案但搞清楚x-amz-content-sha256的根因后反而觉得物有所值。原因很简单Iceberg 解决了我对 ACID 的执念多层结构让查询不再害怕小文件。OSS 便宜、可靠、扩容方便数据湖上云是趋势。Rest Catalog 让多引擎共享元数据变成配置问题而不是开发问题。Nessie 的多分支能力让数仓的 CI/CD 成为现实。这套组合适合对“数据资产治理”有要求的团队不是最省心的方案但长期看是收益最高的方案之一。6.2 最后一个值得记住的小技巧为了避免所有组件在开发环境和平共处、生产环境立刻爆炸我把所有配置整理成一套版本化的模板文件存到代码仓库里。每次升级任何一个组件版本先在测试环境完整跑一遍建表、写入、查询、合并、回滚的全流程再决定要不要升级。关于x-amz-content-sha256那个问题我后来还实验过在 Iceberg 1.6.0 的 nightly build 上修复了没有结果是依然存在。所以在社区修掉之前我这份配置模板会一直用下去。最后再分享一个细节OSS 的 Endpoint 一定要用 region 专用域名不要用通用的 dual-stack 或全球域名。上次被坑也是因为图省事填了oss.aliyuncs.comOSS 服务端在解析 region 时行为异常导致签名和路径都对不上。数据湖这条路没有银弹踩坑是常态。希望这篇记录能帮你省下几天的排查时间。