醉后不知天在水 https://kunni.top// 满船星梦压星河 Tue, 27 Oct 2026 11:33:31 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2026, 困溺 <![CDATA[（不）锐评云谷食堂]]> https://kunni.top//article/3f40e356-2fd6-8006-aedc-eb7d20864eac https://kunni.top//article/3f40e356-2fd6-8006-aedc-eb7d20864eac Fri, 09 Oct 2026 00:00:00 GMT
一起去码头上吃点薯条。
从夯到拉评价分成 5 个等级，从天花板到地板砖，依次是：夯 → 顶级 → 人上人 → NPC → 拉完了。

天权餐厅

蘸水菜
从夯到拉：人上人
简简单单，清清淡淡，清清脆脆，因为油盐比较少，比较健康。
notion image
神龙炒饭
从夯到拉：夯
跟麻辣香锅一样难排但好吃的店，有锅气。
notion image
 
牛关关
各种口味（番茄、红烧、麻辣）的牛腩、牛骨，凑合。
notion image
 

天枢餐厅

街头美式汉堡
从夯到拉：NPC
一般，只适合周四晚上吃吃。
notion image

天璇餐厅

山东炒鸡
从夯到拉：顶级
好吃👍。
notion image

开阳餐厅

缙云烧饼
从夯到拉：人上人
4号楼没啥好吃的，这个还行。
有薄饼和胖饼两种。
notion image
瘦肉丸里加满辣椒。
notion image
 
 
]]> <![CDATA[DuckDB 与 DuckLake：从嵌入式分析，到湖存储的新选择]]> https://kunni.top//article/4020e356-2fd6-805d-8daf-ee42dd9ad3e4 https://kunni.top//article/4020e356-2fd6-805d-8daf-ee42dd9ad3e4 Fri, 23 Oct 2026 00:00:00 GMT
对于长期使用 Flink、Iceberg、Paimon 的开发者来说，第一次接触 DuckDB 和 DuckLake，很容易产生两个疑问：
  • 已经有这么多数据库和计算引擎，为什么还需要 DuckDB？
  • DuckLake 与 DuckDB 是什么关系，它又与 Iceberg、Paimon 有什么不同？
理解它们的关键，不是先比较功能数量或性能数字，而是先弄清楚：它们分别承担哪一层的职责，又想减少哪一部分复杂度。

一、先分清层次：DuckDB 是数据库，DuckLake 是湖表格式

DuckDB 是一个支持 SQL 的关系型分析数据库。它拥有自己的查询执行能力、事务管理和原生存储，默认可以直接嵌入应用进程运行。因此，按产品类别划分，它更接近 MySQL、PostgreSQL，而不是 Iceberg。
不过，“同属数据库”不意味着定位相同。DuckDB 的设计重心是分析型负载，尤其是扫描、聚合和 JOIN；它又借鉴了 SQLite 简单、嵌入式的使用方式。因此，一个更直观的类比是：面向分析的 SQLite。
DuckLake 则处于另一个层次：它定义湖上的表、快照、文件与元数据组织方式，并通过 SQL 数据库管理 Catalog。它的比较对象更接近 Iceberg、Paimon。
从工程职责上，可以做如下划分：
组件
主要承担的职责
Flink
分布式、有状态的有界／无界数据处理
DuckDB
SQL 分析计算，也能管理自身的原生数据库
Iceberg
开放表格式，定义快照、Schema、数据文件与删除语义
Paimon
面向流批场景的湖存储，包括主键更新、合并与文件组织
DuckLake
使用 SQL 数据库管理元数据的开放湖表与 Catalog 格式
这里的划分只是为了突出设计重心：Flink 的核心是分布式有状态计算；Iceberg 通过规范描述表状态；Paimon 的主键表还包含 LSM、版本合并和 compaction 等存储机制，不能简单理解成一个文件格式。

二、为什么已经有 Flink、Spark，还需要 DuckDB？

1. 并不是每个分析任务都值得启动一套分布式执行流程

数据工程里，有很多需求看起来很小，却经常需要经过完整的平台链路：
  • 检查一批文件有没有重复数据；
  • 对某个月的数据做一次聚合；
  • 将 CSV 清洗后转换为 Parquet；
  • 把日志与维表 JOIN，生成一份报告；
  • 排查一次连接器提交前后的数据差异。
对这些任务而言，实际计算可能并不是主要成本。环境准备、作业提交、数据搬运和结果获取，反而可能占据更多时间。
DuckDB 提供了另一种选择：把分析数据库当作程序库使用，而不是先建设一个数据库服务或计算平台。它默认运行在应用进程内，可以由 Python、Java、C++ 等语言调用。
因此，它首先降低的是“使用分析能力的门槛”，而不只是某个算子的执行时间。

2. 文件可以直接成为查询输入

使用 DuckDB，并不一定要先把数据导入它的原生数据库。
CSV、JSON、Parquet 等文件可以直接出现在查询中。应用可以对文件进行过滤、JOIN 和聚合，也可以把查询结果转换成另一种格式。
这让它很适合处于数据库之外的数据：
文件不再只是等待导入数据库的中间产物，也可以直接成为分析的数据源。

3. 轻量，不等于只能处理小数据

DuckDB 的核心是单节点数据库，但可以利用多核、内存和本地磁盘资源。它的扩展方向主要是单节点资源扩展，而不是自动把一个查询分发到多个计算节点。
同时，单节点不等于所有数据都必须装进内存。DuckDB 支持通过 spill-to-disk 处理超过内存容量的工作集，不过部分复杂聚合和算子组合仍可能遇到内存限制。
所以，选型时更值得问的是：
经过过滤、分区和列裁剪后，这个任务真正需要处理多少数据？其中间结果是否适合单节点？
而不是仅凭数据湖的总容量，决定所有查询都必须走分布式系统。

三、一个具体场景：给商家生成销售分析报表

假设一个电商平台已经通过上游处理，得到了一批整理好的支付记录：
  • 每笔支付只有一条记录；
  • 数据已经去重；
  • 某个月的数据以 Parquet 保存；
  • 查询期间，这批已发布文件保持不变。
运营提出一个需求：
查询某个商家，各商品品类的支付笔数、销售额和平均支付金额。
一种实现方式是将数据导入分析数据库，再执行查询；另一种方式是提交批处理作业。
如果这个任务适合单节点资源，也可以把 DuckDB 嵌入报表后端：
这套方案的价值在于：不必为了一个局部分析需求，额外维护一份导入后的数据副本和一套独立服务。
DuckDB 的向量化执行以批次处理数据；对于远程 Parquet，减少不必要的列和数据读取，也有助于降低 I/O 成本。但具体性能仍取决于文件布局、网络、硬件和查询形态，不能脱离条件承诺“多少 GB 一定几秒完成”。
这不只是临时脚本的用法。Hex 在公开工程文章中介绍过：其分析工作台采用基于 DuckDB 的架构，查询保存在 S3 中的 Arrow 数据，避免每一步都把完整数据物化为 Pandas DataFrame，只在需要时才将数据送入 Python。
这个案例说明，DuckDB 也可以成为产品内部的分析计算内核，而不必始终以“一个供用户直接登录的数据库”的形态出现。

四、既然 DuckDB 能直接读文件，为什么还需要 DuckLake？

因为，“能查询文件”与“能正确管理一张持续变化的表”，是两个不同的问题。
如果数据只是一批不再变化的文件，直接扫描通常容易理解。但当数据持续追加、更新和删除时，就必须回答：
  • 当前这张表包含哪些文件？
  • 哪些记录已经被删除？
  • 一次写入是否完整提交？
  • 读者应该看到哪个版本？
  • 字段重命名后，旧文件应该如何解释？
  • 多个 writer 同时提交时，如何避免覆盖彼此的结果？
Iceberg 用表元数据、快照、Manifest List、Manifest 以及数据／删除文件等结构解决这些问题。表的逻辑内容不能简单等同于目录中的全部文件。
DuckLake 面对的是同一类需求，但它选择了不同的元数据架构：
主要数据继续保存在 Parquet 文件中，表元数据则交给关系数据库管理。

五、DuckLake 的核心设计：让数据库管理湖表元数据

1. 数据与元数据分别放在哪里？

一个典型的 DuckLake 部署可以简化为：
DuckLake 的规范定义了 Catalog 中的 SQL 表结构、查询和更新语义。DuckDB 通过 ducklake 扩展实现这些操作，但规范本身与查询执行器是两个概念。
在参考实现中，Catalog 可以根据部署需求选择不同数据库：本地使用可以选择 DuckDB 或 SQLite，多用户、远程协作场景则可以使用 PostgreSQL。
因此，使用 PostgreSQL 做 DuckLake Catalog，并不意味着要把整座数据湖的明细全部导入 PostgreSQL。

2. 一次写入如何变成可见数据？

先忽略小数据的特殊优化，普通文件写入可以理解为：
  1. 准备新的数据文件；
  1. 在 Catalog 事务中登记文件和相关元数据；
  1. 提交新的快照；
  1. 读者根据目标快照，确定应该读取的文件集合。
这里最重要的区别是：
文件上传成功，不等于数据已经成为表中可见的一部分。
可见性由表的提交协议决定，而不是由对象存储目录是否出现新文件决定。

3. 为什么要把元数据放进数据库？

DuckLake 的设计思路是：既然数据库已经擅长事务、索引、并发控制和结构化查询，就可以让它更完整地管理湖表元数据，而不是把这部分状态全部编码到元数据文件中。
由此可以获得几个值得关注的设计空间：
  • 关系化的元数据查询：文件、字段、快照和统计信息具有明确的 SQL 表示。
  • 同一 Catalog 内的多表事务：相关表的变更可以放进同一个事务边界。
  • 事务化的数据与 DDL 变更：数据修改和建表、改表等操作具有事务支持。
  • 小变更内联：小批数据可以先写入 Catalog 内部的数据表，而不是每次都生成一个小 Parquet 文件。
最后一点也意味着：严格来说，DuckLake 的实际数据并非永远全部位于 Parquet 中。它允许针对小变更使用不同的物理存储路径。

六、DuckLake 与 Iceberg、Paimon：不同的复杂度分配方式

从设计重心来看，可以这样比较：
项目
值得关注的核心思路
Iceberg
用开放规范和文件化元数据描述表状态，实现跨引擎的表访问
Paimon
将流式更新、主键合并和 LSM 等存储机制结合起来
DuckLake
用关系数据库管理湖表元数据，以数据库事务协调表变更
这些区别来自各自的表状态与存储组织方式，不应被简化成“谁支持更新、谁不支持更新”。
更合理的工程判断是：它们在不同位置承担复杂度。
文件化元数据需要考虑文件组织、遍历、缓存和提交协议；数据库化元数据则需要评估：
  • Catalog 数据库的容量和热点；
  • 高频提交下的事务竞争；
  • 高可用、备份和恢复；
  • 元数据恢复点与对象存储数据的一致性；
  • 内联数据增长后的运维成本。
所以，DuckLake 并不是“没有元数据管理成本”，而是把一部分问题交给了成熟的数据库基础设施。
同样，开放规范也不能自动证明所有引擎都已完整支持。选型时仍需要检查目标实现对类型、删除、演进和事务语义的覆盖程度。

七、对 Flink 湖存储连接器开发的启发

1. 将 DuckDB 当作独立消费者，而不是只当作另一个 Sink

连接器能成功写出文件，只能证明写入链路完成了一部分工作。
更有价值的验证是：
从这个角度，DuckDB 可以成为跨引擎互操作验证的参与者。
建议重点覆盖：
  • 更新、删除之后的最终结果；
  • 字段重命名后的身份匹配；
  • 时间戳精度与时区语义；
  • DECIMAL 的精度和舍入；
  • 嵌套类型和空值；
  • 同一快照在不同引擎中的一致性。
这里强调的是逻辑表读取。例如，Iceberg 删除文件需要按适用规则作用于数据文件，不能直接扫描所有 Parquet 来代替表查询。

2. “存储有 ACID”不等于“Flink 自动 exactly-once”

这是连接器设计中最容易被产品能力列表掩盖的问题。
即使外部存储支持事务，仍然需要明确：
这些是需要额外建立的连接器协议。数据库事务可以提供原子提交能力，但不会自动替 Flink 管理 checkpoint 状态、重试幂等和恢复决策。

3. 不要只优化写入吞吐，也要评估下游读取成本

文件大小、排序方式、版本数量和 compaction 策略，会影响后续读取需要做多少工作。Paimon 主键表就是一个直观例子：不同 sorted run 中可以保留同一主键的多个物理版本，读取或 compaction 需要按规则合并它们。
因此，连接器性能评估不应只记录“每秒写入多少条”，还应该记录：
  • 写出了多少文件；
  • 一次查询需要读取多少字节；
  • 需要合并多少版本；
  • 删除处理占多少开销；
  • compaction 后是否显著改变消费成本。
好的写入路径，应当同时考虑数据未来如何被读取。

结语：不是替代所有系统，而是重新选择边界

理解 DuckDB 和 DuckLake，可以抓住两句话：
DuckDB 尝试让分析计算像调用一个库一样方便。
DuckLake 尝试让湖表元数据更多地回归数据库管理。
前者让我们重新审视：哪些分析任务真的需要分布式执行，哪些可以在单节点内更直接地完成。
后者让我们重新审视：湖存储中的哪些状态应该文件化，哪些能力可以交给数据库事务。
对于 Flink、Iceberg、Paimon 开发者而言，它们最有价值的启发，不是“现有系统应该被替换”，而是：
先明确问题的边界，再选择复杂度应该由谁承担。
]]> <![CDATA[大数据项目周报(十月下)]]> https://kunni.top//article/3e10e356-2fd6-8004-9641-e11d662a3e4b https://kunni.top//article/3e10e356-2fd6-8004-9641-e11d662a3e4b Sun, 20 Sep 2026 00:00:00 GMT

2026/10/16～2026/10/22

本周十大热点

1. Apache Kafka 4.3.2 修复分层存储数据丢失风险

Kafka 4.3.2 不能只当作一次普通补丁更新。其中最需要排查的是 KAFKA-20732：
  • 分层存储在 Leader 切换后，远端最高 Offset 的内存状态可能尚未初始化；
  • 按容量执行保留策略时，同一批本地、远端数据可能被重复计入大小；
  • 系统因而误判超过 retention.bytes，删除实际上仍应保留的远端数据；
  • 随着日志起始 Offset 推进，本地副本也会删除对应数据。
本版还修复了 Kafka Streams 状态目录过早清理，以及任务损坏、任务复用和状态更新超时后线程退出等问题。
这不是所有 Kafka 集群都会触发的通用故障。启用了分层存储和容量保留策略的团队，应优先核对受影响版本、配置与修复分支；其他版本线不能仅凭本条消息直接决定跨大版本升级。
原文：
编辑评价：本周数据正确性方向的最高优先级事项。 补丁版本是否重要，应看修复的故障后果，而不是版本号变化大小。

2. DuckDB 2.0.0 LTS 正式发布

DuckDB 发布代号为 Cinnamon Teal 的 2.0.0 LTS，支持期至少持续到 2027 年 10 月。
主要变化包括：
  • 完善 Quack 远程协议，并增加 CONNECT 语句；
  • 引入异步 I/O，提升远程文件读取的并行能力；
  • 将 VARIANT 更完整地接入列式存储、执行与 Parquet 读写；
  • CLI 为 Agent 提供紧凑输出、截断提示和结构化错误；
  • 默认使用可扩展的 PEG SQL Parser；
  • 增加 Trigger 等 SQL 能力，部分 Trigger 组合仍有限制。
升级时尤其需要注意：2.0 之前的版本不能读取由 2.0 新建的数据库文件；2.0 仍可读写既有格式文件。关键业务应先验证文件兼容性、客户端与扩展，而不是只替换可执行文件。
原文：
编辑评价：本周最重要的分析数据库版本之一。 远程连接、异步 I/O、半结构化数据和客户端体验同时演进，但不能把它简单理解为放弃嵌入式定位。

3. DuckLake 1.1 发布：加强元数据、删除向量与文件裁剪

DuckLake 同步发布 1.1 规范与 DuckDB 参考实现。需要区分“升级扩展”和“迁移 Catalog 规范”两件事。
依赖 1.1 规范的新能力包括：
  • 嵌套 Schema；
  • PostgreSQL、SQLite Catalog 中的 VARIANT 小批量数据内联；
  • 与 Iceberg 计数约定一致的 Epoch 分区变换；
  • 一个 Puffin 文件保存同一数据文件多个快照的删除向量；
  • 记录字符串统计边界是否精确，以及文件的 Row Group 数量。
新扩展还改善文件裁剪、Compaction 控制和外部 Parquet 导入，这些改进中的多数无需迁移既有 1.0 Catalog。
迁移是显式选择，不会因为升级扩展就自动发生；操作前应备份 Catalog，并验证工作流兼容性。
原文：
编辑评价：开放湖存储的优化继续下沉到元数据层。 提前知道文件统计、删除历史和并行扫描粒度，可以减少不必要的对象存储读取。

4. pgBackRest 2.60.0 收紧恢复与备份过期的校验行为

pgBackRest 2.60.0 最值得关注的不是功能数量，而是发现页面校验错误后的默认行为变化：
  • restore 遇到无效页面校验和时，默认报错并停止，恢复出的集群可能不完整、无法启动，需要重新恢复；
  • expire 在最旧保留备份包含校验错误时，默认拒绝执行过期清理，并阻止该仓库相应归档过期；
  • backup 对这类错误仍默认告警，而不是与恢复命令一样默认失败；
  • checksum-page-error=n 可以改为告警，但这不等于修复损坏。
其他更新包括对象存储多文件／Range 读取预取，以及 GCS Workload Identity Federation。
原文：
编辑评价：升级前应先检查恢复与清理自动化。 更严格的正确性检查有价值，但原本“继续执行”的流程现在可能明确停止，不能把这种行为差异当作偶发失败。

5. LinkedIn 公布每日数千亿事件的埋点管道重建实践

LinkedIn 介绍了高吞吐 Tracking Infrastructure 的并行重建与迁移，覆盖每日数千亿事件、峰值每秒数百万事件。
可复用的经验包括：
  • 按工作负载成本和故障影响拆分容量与部署单元；
  • 批次内复用公共上下文，减少重复序列化和网络传输；
  • 新旧链路并行比对，分批迁移，利用路由保持快速回滚；
  • 将 Kafka Producer 异步回调中的过载信号接入后续请求准入。
作者报告：迁移到全部流量口径后，入站网络用量约下降 89%。这是上下文复用、Protocol Buffers 与相关序列化改造的共同效果，不是单纯更换传输协议的收益。
一个重要边界是：API 在记录进入 Producer 本地缓冲后就可返回成功，并不等待 Kafka Broker 确认。API 成功、Broker 确认和下游内容正确必须分别验证。
原文：
编辑评价：比“迁移到 gRPC”更值得读的是异步管道的成功边界、隔离与准入设计。 性能数据来自作者的生产观测，不应直接迁移成其他系统的预期收益。

6. Apache Fluss 展示带外部副作用 Worker 的崩溃恢复方法

Fluss 官方博客通过一个可复现实验，讨论 Worker 调用外部服务后崩溃时，如何判断是否应该重试。
核心方法是：
  1. 调用服务前，先将稳定的 action_id、完整请求与摘要写入日志；
  1. 重启后重放已提交历史，识别未确认的动作；
  1. 向下游查询已提交回执，区分“尚未执行”和“已执行但确认未写回”；
  1. 对已完成的动作补记确认，避免再次提交副作用。
实验报告通过 7 个核心场景、344 项断言。不过它只覆盖单 Worker、单 Bucket、集群与下游服务继续运行时的进程崩溃，且恢复读取期间要求停止写入。
这不是 Fluss 自动提供通用外部 Exactly-once 的证明：下游幂等键、回执契约和故障模型仍是必要条件。
原文：
编辑评价：价值在于明确说明“日志知道什么、外部系统知道什么”。 适合借鉴到异步任务和外部 API 调用，但不能跳过实验边界直接套用到分布式生产系统。

7. dbt State 为自托管用户提供持续免费额度

dbt Labs 为已 GA 的 dbt State 增加免费计划，让自托管用户在试用结束后继续使用每月额度。
需要注意的条件包括：
  • 免费额度为每月 1,000 DATT，并在每月 1 日重置；
  • DATT 按一天内被跳过或克隆的目标模型／测试计量，同一对象当天多次复用只计一次；
  • dbt State 是共享运行状态的独立服务，仍需要 dbt 账号；
  • 支持 Snowflake、BigQuery、Databricks 和 Redshift；
  • 多数 dbt Platform 用户的新增额度有效期到 2027 年 3 月，不能与自托管方案的长期免费额度混为一谈。
原文：
编辑评价：对数据工程团队的意义是降低状态复用的试用门槛。 “Free forever”不等于无限用量，也不等于底层数据仓库计算免费。

8. OpenReplay 分享单实例 ClickHouse 承载大规模行为事件的实践

ClickHouse 发布 OpenReplay 客户案例，重点是自托管产品如何控制数据管道与运维复杂度：
  • 行为事件集中写入，再通过物化视图转换到目标表；
  • 使用 TTL 管理保留周期，替代原先大量手工清理工作；
  • PostgreSQL 继续保存元数据，并非完全移除；
  • 以纵向扩容控制部署复杂度，而不是立即引入分片集群。
文中报告，最大客户场景每天接收数十亿事件、约 6 TB 数据，并提供亚秒级查询；部分管道变更的开发调试时间从两天缩短到半天。
这些是厂商发布、客户口述的特定部署经验，不是所有查询的延迟承诺，也不是经过独立复现的通用单机容量上限。
原文：
编辑评价：值得借鉴的是数据生命周期与部署复杂度的取舍。 架构收益不只有峰值吞吐，还包括保留策略、管道修改成本和客户侧维护负担。

9. Databricks AI Runtime 正式 GA

Databricks 宣布 AI Runtime（AIR）正式可用，将托管 GPU 基础设施、开发工具和数据治理放进同一个平台边界。
主要能力包括：
  • 按需 GPU 与多节点训练；
  • GPU、网络健康检查和故障资源管理；
  • 自带代码、容器与 Ray 工作负载；
  • 训练数据流式加载与缓存；
  • Unity Catalog 权限、隔离与审计。
这里的变化不只是“平台可以调用模型”，而是训练执行与数据访问治理进一步整合。公告中的启动延迟、训练规模和客户加速数据均来自厂商披露，不能据此直接判断自身任务的性能或成本。
原文：
编辑评价：Lakehouse 正在承接更多训练基础设施职责。 对已有独立 GPU 平台的团队，评估重点应是数据路径、权限边界、可观测性和故障处理，而不是只比较入口便利性。

10. ClickHouse 公布 NVIDIA Vera CPU 扩展性实测

ClickHouse 使用未针对 Vera 定制的标准二进制，在早期访问服务器上测试 ClickBench，以及过滤、聚合和 Join 三组微基准。
测试机器为双路、176 个物理核心、352 个硬件线程。文中的计算密集型过滤和聚合测试，在 176 个线程时约达到单线程的 163 倍；继续增加 SMT 线程后，收益和并行效率下降。
重要边界是：部分微基准有意增加计算强度，以避免先受内存带宽限制。因此不能把接近线性扩展的曲线推广到所有分析查询，也不能替代实际成本比较。
原文：
编辑评价：更值得关注的是“什么先成为瓶颈”，而不是跑分排名。 CPU 核心数、内存带宽、算子类型与 SMT 收益需要放在一起看。

本周主要趋势

以下为基于本期材料的编辑归纳，不是独立测量结论。

1. 正确性与恢复语义，比“支持某项功能”更重要

Kafka 的保留策略修复、pgBackRest 的恢复校验，以及 Fluss 的副作用恢复实验，都指向同一个问题：一旦故障发生，系统到底能保证什么？
  • 本地与远端同时存在，不代表保留策略一定安全；
  • 备份流程完成，不代表恢复出的页面一定正确；
  • 日志记录了意图，不代表外部服务尚未完成动作；
  • API 返回成功，不代表 Broker 已确认，更不代表下游收到正确内容。
对应阅读：热点 1、4、5、6 的官方原文。

2. 数据系统的效率优化，越来越依赖元数据和状态复用

DuckLake 将更多文件信息放进 Catalog；dbt State 复用历史运行状态；OpenReplay 用生命周期策略减少维护工作；LinkedIn 则消除批次内重复上下文。
这些案例的共同启发是：在增加机器之前，先检查能否避免重复计算、重复读取、重复传输和重复运维。
对应阅读：热点 3、5、7、8 的官方原文。

3. 数据平台与 AI 执行平台继续融合，但治理边界不能被省略

DuckDB 把 Agent 视为需要专门输出协议的客户端；Databricks AIR 把 GPU 训练纳入数据平台治理；观察名单中的 Agent Memory 则将持久记忆落在数据库服务上。
从这些材料看，平台整合的价值正在从“提供模型接口”转向数据访问、状态保存、训练执行与可审计性。是否更适合生产，仍需逐项检查可用阶段和故障边界。
对应阅读：热点 2、9，以及下文 Agent Memory 公告。

未进入前十但值得观察

PostgreSQL 部分操作系统版本仓库迁入归档

PGDG 将 RHEL 10.0／9.6（含对应 Rocky Linux、AlmaLinux）及 SLES 15.6 的仓库移入归档，归档仓库不再获得后续更新；滚动 EL-10、EL-9 仓库 RPM 不受前一项调整影响。
仍依赖这些固定版本源的团队应核对升级计划；不能把“还能从归档安装”当作“仍在持续更新”。
原文：RHEL 公告、SLES 公告。

Unity Catalog 的 Catalog 间迁移接口仍处于 Private Preview

Databricks 介绍基于 Iceberg REST Catalog 的 REGISTER／UNREGISTER，用于不复制底层数据的表注册迁移。相关接口仍是 Private Preview，而原地转为 Managed Table 的后续能力仍在路线图中，不能写成已经全面可用。
原文：Unity Catalog 与开放 Catalog。

Databricks Agent Memory 进入 Beta

Agent Memory 基于 Lakebase，结合自动上下文加载、按需工具和离线记忆整理。它值得作为数据库承接 Agent 持久状态的方向观察，但仍处于 Beta；公告中的成功率和 Token 收益来自内部评测。
原文：Agent Memory 公告。

TiDB Cloud BYOC 进入 Public Preview

数据平面运行在客户 AWS 账号中，由 TiDB Cloud 执行经授权的生命周期管理。其价值在数据驻留和托管运维的结合，但仍是 Public Preview，区域可用性也受实例与可用区条件约束。
原文：TiDB Cloud BYOC 公告。

Lance 14.0.0 RC 与 LanceDB 0.41 Beta

本周候选包含多次 Beta／RC 更新，统一作为一个观察主题，不逐个版本占用热点名额。Lance 14.0.0-rc.1 明确标为 Pre-release，涉及编码、索引与 MemWAL 等变化，不能写成 14.0 已正式发布。
原文：Lance 14.0.0-rc.1、LanceDB Releases。

2026/10/09～2026/10/15

本周十大热点

1. PostgreSQL 生态集中发布安全修复

本周 PostgreSQL 生态连续出现三组安全更新。
PgBouncer 1.26.1
修复三个 CVE：
  • CVE-2026-107350：SCRAM 身份验证绕过。知道一个用户密码的客户端可能冒充其他用户，包括管理员和后端超级用户；
  • CVE-2026-107349：未经身份验证的客户端可以触发无限循环，导致拒绝服务；
  • CVE-2026-107348：特定 max_packet_size 配置下的整数溢出可能触发无限循环和拒绝服务。
原文：
https://www.postgresql.org/about/news/pgbouncer-1261-released-fixes-three-cves-3403/
psqlODBC 18.00.0005
修复 CVE-2026-109448。旧版本使用有符号 16 位字段保存绑定参数数量，当应用绑定超过 32767 个参数时可能发生堆内存越界写入，造成崩溃或内存损坏。
原文：
https://www.postgresql.org/about/news/psqlodbc-18000005-released-with-security-fix-for-cve-2026-109448-3404/
PostgreSQL JDBC 42.7.14
修复两个 CVE：
  • CVE-2026-107314
  • CVE-2026-107315
原文：
https://www.postgresql.org/about/news/2026-10-07-postgresql-jdbc-42714-security-update-for-multiple-cves-3399/
编辑评价：本周运维优先级最高。 使用 PgBouncer、PostgreSQL ODBC/JDBC 驱动的团队应优先核对部署版本和升级窗口。

2. Apache Paimon 2.1.0 正式发布

Apache Paimon 发布 2.1.0，更新横跨核心格式、索引、并发写入、Flink、Spark、 Python 和对象存储。
值得关注的变化包括：
  • DV 表支持向量索引；
  • DV 表支持全文索引；
  • BTree 全局索引支持 TopN 下推；
  • 增加并发 MERGE INTO 与 Compaction 冲突检测；
  • 改进 Parquet 谓词下推；
  • 支持 ORC Time 类型谓词下推；
  • 改进数据演进场景中的索引和统计信息；
  • 扩展 Python/Rust 原生扫描规划；
  • 增强 Flink、Spark、Hive 和对象存储支持；
  • 修复 Chain Table DV 行可能静默丢失数据的问题。
原文：
https://github.com/apache/paimon/releases/tag/release-2.1.0
编辑评价：本周 Lakehouse 方向最重要的开源版本之一。 这不是普通补丁版本， 而是索引、并发写入、Python 和查询下推能力的集中增强。

3. Apache Flink CDC 3.7.0 发布

Flink CDC 3.7.0 从单纯的 CDC 工具继续向流式数据转换平台发展。
主要变化包括：
  • 增加可插拔模型 API；
  • 增加 OpenAI 兼容模型客户端；
  • 内置文本生成、分类、翻译、摘要、情感分析、信息提取、脱敏、Embedding 和图像理解函数；
  • Pipeline YAML 支持内联 Python UDF；
  • 增加有序异步执行，在保留数据和 Schema 事件顺序的同时改善 I/O 密集转换吞吐；
  • 新增 SQL Server Pipeline Source；
  • 新增 Apache Fluss Pipeline Source；
  • Fluss Source 支持主键表、日志表、快照读取和日志读取；
  • 改进 Paimon、Fluss Sink 的现有表 Schema 检查和自动扩展；
  • 扩展 YAML Transform 表达式、日期、字符串、集合和空值处理能力。
原文：
https://flink.apache.org/2026/10/10/apache-flink-cdc-3.7.0-release-announcement/
编辑评价：Flink CDC 正进一步打通 Fluss、Paimon、Hudi、Iceberg 和 Kafka 等实时湖仓组件，同时将模型调用引入流式转换。

4. Amazon Redshift 自动解决部分 Iceberg 并发写冲突

Amazon Redshift 开始自动解决实际不重叠的 Apache Iceberg 并发写入，而不是让所有 竞争提交失败并整体重试。
新的检查过程会逐步判断：
  1. 两个操作的类型是否可能冲突；
  1. 是否修改相同分区；
  1. 是否修改相同数据文件。
AWS 给出的追加写测试中：
  • 基础乐观并发模式在 16 个并发写入者时，吞吐下降到单写入者的约 0.17 倍；
  • 开启自动冲突解决后，同一测试约达到单写入者吞吐的 2 倍；
  • 同一时间窗口完成的提交数量提高约 12 倍；
  • 测试中的追加写没有再被冲突拒绝。
需要注意，这组测试主要针对互不重叠的追加写。修改相同分区或相同文件时，仍需要更细 粒度的冲突检查。
原文：
https://aws.amazon.com/blogs/big-data/resolving-concurrent-write-conflicts-for-apache-iceberg-tables-in-amazon-redshift/
编辑评价：这标志着 Iceberg 的关注重点从“支持事务写入”进一步转向多写入者生产环境 中的吞吐、冲突解决和可观测性。

5. LinkedIn 公布 Apache Celeborn 大规模生产实践

LinkedIn 已经在大多数 Spark 和 Flink 工作负载中部署 Apache Celeborn 远程 Shuffle 服务。
架构和运营改造包括：
  • 五节点 Raft Master，跨故障域部署；
  • 基于网络拓扑和故障域的副本放置；
  • 对维护状态感知的 Slot 分配；
  • 使用 NVMe SSD 替代旋转磁盘；
  • 针对高并发场景优化 Slot 选择、文件 Flush、GC 和堆外内存；
  • 增加 RPC/HTTP 身份验证、授权、TLS 和静态加密；
  • 增加生产 CLI、Dashboard、SLO 和原生 IPv6；
  • 通过 Kubernetes StatefulSet 和持久卷运行 Worker。
公开结果包括：
  • Shuffle Fleet 所需规模减少约 35%；
  • Slot 选择性能提升约 6 倍；
  • Flink 大规模历史回填达到每小时数亿事件；
  • 原本持续多天的回填在数小时内完成；
  • 支撑数千个 Pipeline 实例；
  • 逐步取消 Spark 历史处理和 Flink 近实时处理两套重复实现。
原文：
https://www.linkedin.com/blog/engineering/infrastructure/scaling-spark-and-flink-shuffle-at-linkedin-with-apache-celeborn
编辑评价：这是本周信息密度最高的生产工程文章之一，覆盖架构、可靠性、资源效率、 安全、运维和开源回馈，不是普通客户案例。

6. AWS 将数据质量检查原生集成到 EMR Spark

Amazon EMR Data Quality 现在直接集成在 emr-spark-8.1.0 及后续版本中。
主要能力包括：
  • 支持 EMR on EC2、EMR on EKS 和 EMR Serverless；
  • 在 Spark Job 内直接执行 DQDL 数据质量规则；
  • 规则可以直接写在 Job 中，也可以存储在 Glue Data Catalog；
  • 支持完整性、唯一性、值域、引用完整性和统计分布检查；
  • 支持基于历史运行结果的异常检测；
  • 评估结果可以停止 Pipeline、隔离错误记录、发送告警或控制后续写入；
  • 可以与 Apache Iceberg Write-Audit-Publish 结合；
  • 适用于 Iceberg、Hudi 和 Delta Lake。
原文：
https://aws.amazon.com/blogs/big-data/bring-data-quality-to-your-amazon-emr-workloads-with-amazon-emr-data-quality-built-on-aws-glue-data-quality/
编辑评价：数据质量正在从独立外围任务进入数据处理运行时，适合生产级 Lakehouse 管道和集中治理场景。

7. Databricks 发布 Lakebase Search 实际容量测试

Databricks 使用真实内部应用和最多 400 万条 MIRACL Passage 测试 Lakebase Postgres 中的 BM25 与向量混合检索。
关键结果包括：
  • Lakebase Search 将向量检索和 BM25 作为 Postgres 扩展运行；
  • 当 Local File Cache 大小接近向量索引时，缓存命中率约为 95%～98%；
  • 候选数量从 1000 降到 200，仍保留 90.5% 的 Top-10 结果；
  • 200 个候选读取的页面约为 1000 个候选的三分之一；
  • 400 万条数据的向量索引约为 23 GB；
  • 400 万行通过 Binary COPY 在 8 CU 下用约 19 分钟载入；
  • 文中给出了连接池、冷启动、CU、并发和缓存比例的容量规划数据。
原文：
https://www.databricks.com/blog/sizing-lakebase-search-lessons-real-app-and-4-million-passages
编辑评价：该文章比普通产品发布更有价值，因为它给出了容量规划方法、缓存比例和可复用 的性能数据。

8. dbt 增加 Amazon Redshift Data Sharing 支持

dbt-redshift 现在支持 Redshift Data Sharing 的读写场景。
新的能力包括：
  • 跨 Redshift 数据仓库和数据库物化模型；
  • 使用共享数据而不复制或移动数据；
  • 支持跨项目引用；
  • 支持将 CI 环境放在独立集群，同时读取生产共享数据；
  • 支持将 ETL 与 BI 查询隔离到不同集群；
  • 将元数据查询从传统 PostgreSQL Catalog 迁移到 Redshift 原生 SVV_* System View 和 SHOW API；
  • 改善大型项目和高并发环境下的元数据解析性能。
已知限制：
  • 消费者侧的普通 View 不能直接引用 Datashare 对象；
  • 第一层通常需要物化为 Table 或 Incremental Model；
  • 相关能力仍处于 dbt Platform Latest Release Track 的 Beta 阶段。
原文：
https://www.getdbt.com/blog/dbt-now-supports-amazon-redshift-data-sharing
编辑评价：对使用 Redshift、dbt Mesh、隔离 CI 和多团队数据架构的组织具有直接价值。

9. ClickHouse 定位并修复额外 32ms 尾延迟

ClickHouse 客户发现，客户端与服务器之间约有 32ms RTT 时，空闲连接上的下一条简单 查询会从约 32ms 增加到约 64ms。
根因是：
  • Native Protocol 在数据包和 EndOfStream 之间发送多种 Metadata Packet；
  • 连接空闲后，TCP 拥塞窗口重新缩小；
  • 多个未批量发送的小包超出初始拥塞窗口；
  • 服务器必须等待客户端 ACK，增加一个完整 RTT。
修复方案是在应用层批量发送查询结束阶段的 Metadata Packet：
  • TCP PUSH 包从约 50 个下降到约 25 个；
  • 额外约 32ms 尾延迟下降到约 1ms；
  • 不需要通过关闭 ProfileEvents 或修改系统 TCP 参数规避问题。
原文：
https://clickhouse.com/blog/chasing-32ms-tail-latency-clickhouse
编辑评价：这是典型的高质量数据库工程复盘，结论可以迁移到其他自定义 TCP 协议和 低延迟服务。

10. DuckDB CLI 增加 Agent Mode

DuckDB CLI 的 Agent Mode 针对 Coding Agent 优化输出格式，减少终端输出对模型造成的 误导和 Token 消耗。
DuckDB 官方实验使用 Claude Code 回答 22 个 TPC-H SF100 问题：
  • 每个问题分别使用 Agent Mode 和普通模式运行三次；
  • 总计 132 次运行；
  • 所有结果均正确；
  • 模型读取的 DuckDB 输出从 123.6k Token 降到 50.8k；
  • 输出 Token 减少约 59%。
原文：
https://duckdb.org/2026/10/09/agent-mode
编辑评价：它不是数据库执行引擎的核心突破，但说明数据库 CLI 正开始将 Agent 视为一等客户端。

本周主要趋势

1. Lakehouse 进入“可写、可索引、可治理”阶段

本周的多个重要事件围绕同一方向：
  • Paimon 增强索引、并发写入和查询下推；
  • Redshift 自动解决部分 Iceberg 并发写冲突；
  • EMR 将数据质量检查放进 Spark 运行时；
  • ClickHouse 通过 Iceberg Connector 统一查询历史与实时数据；
  • dbt 和 Redshift Data Sharing 减少跨数据仓库的数据复制。
关注点正在从“能否读取开放表格式”转向：
  • 多写入者并发；
  • 索引和谓词下推；
  • 数据质量；
  • 数据共享；
  • 实时和历史数据统一查询。

2. 实时计算与数据湖进一步融合

Flink CDC 3.7 新增 Fluss Source，并加强 Paimon、Fluss Sink；Databricks 继续推动 实时分析直接运行在统一的 Lakehouse 数据和治理体系上。
实时系统与 Lakehouse 的边界继续缩小，新的竞争点逐渐变成：
  • 数据进入查询状态的速度；
  • 是否需要复制到独立 Serving Layer；
  • 实时与批处理是否共享 Schema、权限和治理；
  • 写入、Compaction 和查询之间如何协同。

3. 数据基础设施开始面向 Agent 工作负载优化

本周多个项目都出现 Agent 或 AI 数据工作负载相关变化：
  • DuckDB 为 Agent 优化 CLI 输出；
  • Lakebase 测试 BM25 和向量混合检索容量；
  • Flink CDC 将模型调用和 Embedding 引入流式转换；
  • Paimon DV 表增加向量和全文索引；
  • 数据平台开始同时服务人类分析、应用和 Agent。

未进入前十但值得观察

ClickHouse 与 Redshift Serverless 的 CostBench 对比

ClickHouse 发布厂商 Benchmark，声称在持续写入 1132 亿条股票报价的测试中， ClickHouse Cloud 相对 Redshift Serverless 获得约 1996 倍的端到端性能成本优势。
原文：
https://clickhouse.com/blog/clickhouse-vs-redshift-serverless-real-time-performance-per-dollar
该结果具有讨论价值，但测试由 ClickHouse 自己设计和发布，需要等待独立复现。

Lance 和 LanceDB beta 版本密集发布

时间窗口内，Lance 14.0 和 LanceDB 0.41 发布了多个 beta：
  • Lance 增强编码、索引、Mem-WAL、DataFusion 和对象存储支持；
  • LanceDB 增加 JSON 字段全文索引、SQL 参数绑定及多项远程 API 改进。
由于均为高频 beta，本期未将单个版本列入正式热点。

Apache Fluss

本时间窗口内，Apache Fluss 没有发布新的独立官方文章，但通过 Flink CDC 3.7.0 新增的 Fluss Pipeline Source 和 Sink 改进进入了本周重要事件。

信息源

1. 数据库与 OLAP/列式存储
信息源
主要方向
RSS/Atom
PostgreSQL News
PostgreSQL 版本、安全公告及生态扩展
https://www.postgresql.org/news.rss
DuckDB Blog
嵌入式 OLAP、向量化执行、Parquet
https://duckdb.org/feed.xml
PingCAP Blog
TiDB、分布式数据库、HTAP
https://www.pingcap.com/feed/
ClickHouse Blog
列式数据库、实时分析、OLAP
https://clickhouse.com/rss.xml
StarRocks Blog
MPP、实时数仓、Lakehouse 查询
https://www.starrocks.io/blog/rss.xml
Apache Doris Blog
MPP、实时数仓、湖仓分析
https://doris.apache.org/blog/rss.xml
Databend Blog
云原生数仓、列式存储、对象存储
https://www.databend.com/blog/rss.xml
2. 查询引擎与计算框架
信息源
主要方向
RSS/Atom
Trino Blog
联邦查询、分布式 SQL、数据湖查询
https://trino.io/feed.xml
Apache Flink
流计算、CDC、流批一体
https://flink.apache.org/posts/index.xml
Apache Arrow
内存列式格式、Parquet、跨语言计算
https://arrow.apache.org/feed.xml
Velox Blog
向量化执行引擎、查询算子、Nimble
https://velox-lib.io/blog/rss.xml
3. 数据湖与 Lakehouse
信息源
主要方向
RSS/Atom
Delta Lake Blog
Lakehouse、事务表格式、Delta Kernel
https://delta.io/rss.xml
Apache Hudi Blog
数据湖、增量处理、索引、流式写入
https://hudi.apache.org/blog/rss.xml
Databricks Blog
Spark、Delta Lake、Lakehouse、数据平台
https://www.databricks.com/feed
AWS Big Data Blog
Redshift、EMR、Iceberg、Glue、Kinesis
https://aws.amazon.com/blogs/big-data/feed/
4. 流数据与数据工程
信息源
主要方向
RSS/Atom
Confluent Blog
Kafka、流数据平台、实时架构
https://www.confluent.io/rss.xml
dbt Labs Blog
数据转换、Analytics Engineering、数仓开发
https://www.getdbt.com/blog/feed.xml
Decodable Blog
Flink、CDC、流处理和数据管道
https://www.decodable.co/blog/rss.xml
5.媒体与行业聚合源
信息源
特点
RSS
The New Stack · Data
数据基础设施、数据库和工程实践
https://thenewstack.io/data/feed/
InfoQ · Architecture & Design
架构、分布式系统、数据库和工程案例
https://feed.infoq.com/architecture-design
Data Engineering Weekly
数据工程文章和社区动态周报
https://www.dataengineeringweekly.com/feed
]]> <![CDATA[Paimon学习笔记： Data Evolution表]]> https://kunni.top//article/3e30e356-2fd6-8042-bf76-c1017d4907a6 https://kunni.top//article/3e30e356-2fd6-8042-bf76-c1017d4907a6 Sat, 17 Oct 2026 00:00:00 GMT

1. 一句话理解 Data Evolution

Paimon Data Evolution 是一种面向 无主键 Append Table 的列级更新机制：
  • 每一行由 Paimon 分配稳定的 _ROW_ID；
  • 更新时只写发生变化的列，不重写未变化的列或大对象；
  • 同一逻辑行的不同列可以来自不同物理文件；
  • 读取时按 _ROW_ID 对齐，并按文件版本为每一列选择最新值；
  • 多次更新产生的列文件最终通过 compaction 合并。
它特别适合如下流水线：
  1. 先写入原始数据；
  1. 后续异步补充标签、描述、特征、Embedding 等列；
  1. 原始图片、音视频等大对象保持不动；
  1. 持续构建或刷新向量、全文、标量索引。

2. Data Evolution 不等于 Schema Evolution

这两个概念很容易混淆。
概念
解决的问题
示例
Schema Evolution
表中有哪些列、列叫什么、列类型是什么
ALTER TABLE ADD COLUMN caption STRING
Data Evolution
已有行的新列值或旧列值如何补充、替换
为历史图片计算 caption 并写回
执行：
只会修改 Schema，不会自动为历史行计算 caption。还需要通过 UPDATE、MERGE INTO、PyPaimon shard update 等方式执行数据回填。

3. 与普通 Append Table、主键表的区别

特性
普通 Append Table
Data Evolution Table
Primary Key Table
Primary Key
无
无
有
相同业务键再次 INSERT
新增一行
新增一行
按合并引擎更新
行身份
通常不暴露稳定行身份
_ROW_ID
Primary Key
更新方式
通常需要重写数据
按 _ROW_ID 做列级更新
按 Primary Key 合并
未更新列
随文件一起重写
保留旧列文件
由 merge engine 决定
BLOB/Vector 专用存储
不适用
核心场景
部分场景支持
典型用途
日志、事件
多模态和异步特征生产
CDC、业务实体状态
最重要的区别是：
Data Evolution 表中的业务字段 id 不是 Primary Key。
例如：
这会产生两条不同的逻辑行，并获得两个不同的 _ROW_ID。

4. 建表前提与硬约束

4.1 必须同时开启的选项

这两个选项都是不可变选项，应在建表时确定。

4.2 表模型约束

Data Evolution 表必须满足：
  1. 是 Append Table；
  1. 没有 Primary Key；
  1. bucket = -1，即 bucket-unaware；
  1. 必须启用 Row Tracking；
  1. 不能启用 clustering.incremental。

4.3 Spark 建表示例

deletion-vectors.enabled 不是普通列更新的必要条件，但执行行级 DELETE 或 MERGE INTO ... DELETE 时需要开启。

4.4 Flink 建表示例

5. 核心概念一：Row ID

5.1 _ROW_ID 是什么

Row Tracking 为每一条 Append Table 记录分配一个 BIGINT 类型的内部行 ID。
可以通过 $row_tracking 系统表查看：

5.2 Row ID 如何分配

普通追加文件在写出时可以还没有 firstRowId。提交快照时，提交层根据上一个快照的 nextRowId 为新文件分配连续区间。
假设两个新文件分别有 3 行和 2 行：
文件的 Row ID 范围定义为：
文件中第 i 个位置对应：

5.3 Row ID 不是永久业务 ID

以下操作会保留 Row ID：
  • 普通列更新；
  • 列回填；
  • 逻辑删除；
  • 普通 Data Evolution compaction；
  • compaction 中拆分大文件。
以下操作可能改变或移除 Row ID：
  • materialize_deletion_vectors；
  • reassign_row_id；
  • overwrite；
  • 分区删除或分区替换。
因此：
_ROW_ID 是存储层行定位符，不应直接当成永久业务主键。
如果其他表持久化保存了 _ROW_ID，必须与 Row ID 重分配、Deletion Vector 物化等维护任务协调。

6. 核心概念二：文件组和范围契约

Data Evolution 的正确性依赖严格的 Row ID Range 文件布局。

6.1 Normal File

Normal File 使用普通表文件格式，例如 Parquet 或 ORC，存储：
  • 全部普通列；或者
  • 一次更新选择的部分普通列。
任意两个存活的 Normal File，其 Row ID Range 必须：
  • 完全相同；或者
  • 完全不相交。
不允许部分重叠，也不允许一个严格包含另一个。
Row ID Range 完全相同的一组 Normal File 构成一个逻辑文件组。

6.2 Dedicated File

Dedicated File 是专用格式文件，例如：
  • BLOB 文件；
  • Vector Store 文件。
Dedicated File 的范围可以小于 Normal File，但必须完全包含在某一个 Normal Range 内：
例如 Normal Range 为 [0, 5] 和 [6, 9]：
Dedicated Range
是否合法
原因
[0, 5]
是
与一个 Normal Range 完全相同
[2, 4]
是
完全包含在 [0, 5]
[4, 7]
否
跨越两个 Normal Range
[0, 9]
否
不能依赖两个 Normal Range 的并集

6.3 为什么普通列更新必须重写完整范围

假设原始文件：
执行：
不能只写一行 [rowId=1, b=22]，而是要生成：
逻辑结果由两个文件合并：
结果：
这说明 Data Evolution 节省的是 未更新列的重写成本，而不是把一次普通列更新缩小到单行文件。
更新一行，也可能需要处理其所在文件范围内的所有行。

7. 文件元数据

理解以下 DataFileMeta 字段非常重要：
字段
含义
firstRowId
文件第一个逻辑位置的 Row ID
rowCount
物理位置数，包含被 Deletion Vector 隐藏的位置
schemaId
写出文件时使用的 Schema
writeCols
文件实际写入的列或嵌套字段路径
minSequenceNumber
文件中最小数据版本
maxSequenceNumber
文件中最大数据版本
writeColsSequences
compaction 后每个物理字段保留的最大版本
extraFiles
Sidecar 等与主文件对齐的附属文件

7.1 writeCols

例如：
必须结合文件自己的 schemaId 解析 writeCols，不能只按最新表 Schema 的字段名解析。
这是为了正确处理：
  • 字段重命名；
  • 新增字段；
  • 不同 Schema 版本下的字段 ID；
  • 嵌套字段演进。

7.2 writeCols = null 的优化编码

开启：
当 Normal File 包含全部非 Dedicated 列时，可以省略 writeCols。
该选项默认关闭，主要原因是老版本 Reader 可能把 null 错误理解为“文件包含表中全部列”。启用前应升级所有 Reader、Writer、Compactor 和维护任务。

8. 读取流程

8.1 总体流程

8.2 主要处理层次

8.3 Scan 阶段

Data Evolution Scan 不能像普通 Append Scan 一样独立判断每个文件。
原因是：
  • 老文件的某个列可能已被新文件覆盖；
  • 老文件统计信息不能用来判断新版本列值；
  • 查询投影可能只需要一个文件组中的部分列文件；
  • 即使查询列在所有文件中都不存在，也要保留一个文件来提供正确行数并补 NULL；
  • 开启 Deletion Vector 时必须保留 Anchor File。
因此 Scan 会：
  1. 按重叠 Row ID Range 对文件分组；
  1. 合并最新列 Provider 的统计信息；
  1. 基于逻辑最新值做文件组级过滤；
  1. 根据 Projection 和 Predicate 需要，删除不贡献列的物理文件；
  1. 必要时保留 Anchor 或行数代表文件。

8.4 Split 生成

Split 规划会先把重叠 Row ID Range 合并成不可拆的逻辑组，再根据目标 Split 大小做打包。
这样可以保证需要一起进行列合并的文件不会被分配到不同 Split。

8.5 Provider 选择

同一文件组中的 Normal File 按新版本优先排序。对每个请求字段，Reader 选择第一个能够提供该字段的文件。
例如：
读取 id,b,c 时：
这不是按业务键进行 Join，而是按 Row ID 位置做列拼装。

8.6 缺列、NULL 和 BLOB Placeholder

三种情况语义完全不同：
表示
读取语义
文件没有写该列
文件不提供新值，继续找旧 Provider
文件写了该列且值为 NULL
最新值就是 NULL，不能回退
BLOB Placeholder
保留旧 BLOB，继续向旧版本查找
不要使用 NULL 表示“保持旧 BLOB 不变”。BLOB Placeholder 是内部写入语义，由 Paimon Writer 管理。

8.7 Filter Pushdown 为什么更谨慎

多文件位置合并要求所有列 Reader 保持严格对齐。
如果只对其中一个 Reader 下推行过滤，可能出现：
此时列会错位。
因此：
  • 单文件读取可以正常执行文件索引和格式级下推；
  • 可证明安全的合并组可共享一个 Bitmap Selection；
  • 其他合并读取通常只能用索引跳过整个文件组；
  • 系统字段的物理值可能因 Row ID 重分配而过期，不直接下推到物理文件。

8.8 Row Sidecar

可选配置：
Writer 会为 Normal File 生成行存 Sidecar，用于加速稀疏 Row ID 读取。
默认使用 Sidecar 的两个门槛：
只有同时满足以下条件时才使用 Sidecar：
  1. 选中行数不超过 4096；
  1. 选中行比例不超过 5%；
  1. 不是全文件读取；
  1. 文件存在唯一的 Row Sidecar；
  1. 不是 BLOB 或 Vector Store 文件。
Row Sidecar 适合全局索引返回少量 Row ID 后的点查，不适合大范围扫描。

9. 普通列更新流程

9.1 端到端流程

9.2 为什么关闭 File Rolling

部分列文件必须与原 Normal Range 完全对齐。因此 Spark 和 Flink 的 Data Evolution Writer 都会禁用普通文件滚动：
Flink 还会关闭 Append Write Buffer，以避免中途 Flush 导致文件提前关闭。

9.3 未命中行也要写

一个范围内只更新少量行时，Writer 会：
  • 匹配行写新值；
  • 未匹配行复制旧值；
  • 被 Deletion Vector 隐藏的位置仍然保留占位；
  • 最终写出的行数必须等于原范围 rowCount。
这保证其他列文件仍可按位置对齐。

9.4 更新分区列

Matched partial update 不支持修改分区列。
分区决定文件所在目录和文件组归属，直接修改分区列不是简单的列 Provider 替换，而是删除旧行并向另一个分区插入新行。

10. Spark UPDATE 与 MERGE INTO

10.1 UPDATE

Spark 的 Data Evolution UPDATE 内部会构造成基于 _ROW_ID 的 self-merge。
当条件可以安全放入 MergeRows 时，可优化为：
避免普通 self join、shuffle 和 sort。

10.2 MERGE INTO

语义：
  • Matched Update：保留现有 _ROW_ID，写部分列文件；
  • Not Matched Insert：追加新行，提交时分配新 _ROW_ID；
  • Matched Delete：需要 Deletion Vector；
  • Not Matched By Source Delete：需要 Deletion Vector。
Spark Data Evolution MERGE 支持的 Action 形态：
Clause
支持的 Action
WHEN MATCHED
UPDATE、DELETE
WHEN NOT MATCHED
INSERT
WHEN NOT MATCHED BY SOURCE
DELETE
WHEN NOT MATCHED BY SOURCE 需要 Spark 3.4 或更高版本。

10.3 _ROW_ID 快捷路径

如果匹配条件为：
Paimon 可以跳过普通业务条件 Join，直接定位目标范围。
Self-merge _ROW_ID 快捷路径只支持 WHEN MATCHED，不能同时包含：
  • WHEN NOT MATCHED；
  • WHEN NOT MATCHED BY SOURCE。

10.4 File Pruning

默认开启。Paimon 会先收集实际被更新的目标文件 ID，从后续部分列写入中裁剪未触碰文件。
如果预期目标分区的大多数文件都会被更新，收集文件 ID 的成本可能高于收益，可以关闭。

10.5 Spark UPDATE 冲突重试

Spark V1 UPDATE 默认配置：
只有确定性条件和确定性更新表达式才适合自动重试。

11. Flink Data Evolution 更新

Flink 提供专门的 procedure：
该 procedure 是精简版 Merge：
  • 支持匹配后更新；
  • 不追加 source 中未匹配的行；
  • 不执行删除；
  • 目标表不能是空表；
  • 更新前固定一个 base snapshot；
  • 输入按 firstRowId Shuffle，并按 _ROW_ID 排序；
  • 每个范围补齐未更新行后写部分列文件。
删除应使用：
  • Flink 1.17+ Batch SQL DELETE FROM；或者
  • delete Action。

12. PyPaimon 更新方式

PyPaimon 提供多种 API。

12.1 按 Predicate 更新

12.2 按 Row ID 更新

输入只需要 _ROW_ID 和待更新列：

12.3 Shard Update

适合批量计算派生列：
必须遵守：
  1. 输出批次与输入批次行数相同；
  1. 顺序相同；
  1. 不能过滤、排序、复制行；
  1. 不同 Worker 使用不同 shard index，但 shard count 必须一致。

13. Nested Field Evolution

默认情况下，更新单位是顶层列。
例如：
更新 payload.caption 时，默认会把整个 payload 当作更新列。
启用：
后，writeCols 可以记录：
Reader 会按叶子字段选择最新 Provider，并重新组合 Struct。

13.1 当前限制

  • 支持把一层 Struct 的直接子字段分散到不同文件；
  • 不支持把更深层的同一个子 Struct 再分散到多个文件；
  • 顶层 Struct 整体写入与任意子字段写入会产生冲突；
  • 是否支持具体赋值语法还取决于 Spark/Flink Engine。

13.2 升降级风险

该选项具有明显的混合版本风险：
  1. 必须先升级所有 Reader、Writer、Compactor 和维护任务；
  1. 只能通过持久化表选项开启；
  1. 开启后不能关闭或删除；
  1. 一旦提交了嵌套路径文件，旧版本 Reader 无法正确重建；
  1. 二进制降级不安全。

14. BLOB 和 Vector 文件

14.1 BLOB

对于托管 BLOB：
  • Normal File 提供普通列；
  • BLOB 数据写入专用 BLOB 文件；
  • BLOB 文件可按独立大小滚动；
  • 每个 BLOB 文件必须包含在一个 Normal Range 中；
  • 新 BLOB 版本可以只覆盖部分范围；
  • Placeholder 表示沿用旧值；
  • 显式 NULL 表示把值更新为 NULL。

14.2 Vector

专用 Vector File 可以独立于 Normal File 滚动，但读取一个完整向量列时，选中的 Vector 文件应按 Row ID 顺序完整覆盖对应 Normal Range。
当前维护限制：
  • Dedicated Vector File Compaction 尚未支持；
  • 包含 Dedicated Vector File 的组不能执行 Deletion Vector Materialization。

14.3 Flink BLOB 更新注意

Flink procedure 支持多种 BLOB 更新形态，但托管 BLOB 值会进入 Merge Sort Buffer。
单行托管 BLOB 如果大于 write-buffer-size（默认 256 MB），任务会失败。

15. 删除与 Deletion Vector

15.1 为什么不能直接移除位置

假设范围为 [0, 5]，删除 Row ID 2。
如果直接把物理位置移除，后面的 Row ID 会错位：
其他列文件仍然有 6 个位置，无法继续按位置合并。
因此普通删除只写 Deletion Vector：

15.2 Anchor File

同一 Row Range Group 中最老的 Normal File 是 Anchor File。
排序规则：
Deletion Vector 关联到 Anchor，读取时应用到整个逻辑文件组，从而同时隐藏：
  • 普通列；
  • BLOB；
  • Vector。

15.3 Spark 删除

或者：
必须配置：

15.4 Flink 删除

Flink 1.17+ 可以在 Batch 模式执行：
也可以提交 delete Action。Action 会固定一个 $row_tracking Snapshot，找到匹配 Row ID 并写入 Deletion Vector。

16. 并发与冲突检测

Data Evolution 的并发冲突分为两类。

16.1 Layout Conflict

操作基于旧 Snapshot 计划时，认为 Normal Range 是：
在提交前，另一个 compaction 把它们合并为：
Row ID 没变，但文件边界变了。旧 Writer 生成的 [0, 5] 部分列文件不再符合当前布局。
这属于 Row ID Range/Layout Conflict。

16.2 Logical Update Conflict

冲突判断不仅看 Range，还看写入字段 ID：
两个写入范围相同，但列不重叠，可以不构成列更新冲突。
即使两个 Predicate 命中了不同业务行，也会冲突，因为两个文件都覆盖完整 [0,5] 范围，并且都替换 b。
冲突条件可简化为：
Nested Field 开启时，冲突会细化到叶子字段；但整列 Struct 更新会与其任意子字段更新冲突。

16.3 Compaction 后 Rebase

Spark MERGE 可以在并发 compaction 改变边界后，把已写出的普通部分列文件重新映射到最新范围，而不重新执行 source 和 join。
PyPaimon 也支持类似恢复，大小由：
限制。设置为 0 B 可关闭。
以下情况不执行这种恢复：
  • 启用了 Deletion Vector；
  • 同一提交包含已有行的 BLOB 文件；
  • 同一提交包含已有行的 Vector 文件；
  • 存在真正的同列并发更新冲突；
  • 当前文件总大小超过 PyPaimon 配置上限。

17. Compaction

17.1 普通 Data Evolution Compaction

目的：
  • 合并多次部分列更新；
  • 降低读取文件数；
  • 合并相邻 Normal Range；
  • 保留 Row ID；
  • 保留逻辑删除；
  • 保留字段版本信息。
例如：
逻辑值不变，Row ID 不变。
普通 compaction 不会物理删除被 Deletion Vector 隐藏的位置，因为这会破坏未重写列文件的对齐。

17.2 合并相邻范围

普通 compaction 可以：
Row ID 不变，但边界改变，这也是并发部分列写入可能遇到 Layout Conflict 的原因。

17.3 拆分大 Normal File

配置：
只有文件严格大于：
才会因为“大文件”被选择。
拆分时：
  • 只重写 Normal File；
  • Row ID 保持不变；
  • BLOB/Vector 文件不重写；
  • 切分点不能落在 Dedicated File Range 内；
  • 实际输出大小可能大于目标值；
  • Dedicated Range 如果阻止所有安全切分，则不会仅因大小触发任务。

17.4 BLOB Compaction

默认关闭，应根据 BLOB 文件碎片情况单独决定是否开启。
Vector Dedicated Compaction 当前未支持。

18. Deletion Vector Materialization

当需要真正移除删除位置时，运行：
该过程会：
  1. 读取受影响文件组；
  1. 应用 Deletion Vector；
  1. 只写存活行；
  1. 为存活行分配新 Row ID；
  1. 删除已物化的 Deletion Vector；
  1. 删除受影响的 Global Index；
  1. 对受影响 Row Range 做并发冲突检查。
因此它与普通 compaction 的关键区别是：
操作
删除位置
Row ID
普通 Compaction
保留逻辑删除位置
保留
Materialize DV
物理移除删除位置
重新分配
当前不支持物化包含 Dedicated Vector File 的文件组。
历史 Snapshot 或 Tag 仍可能引用旧文件。只有引用过期并执行 Snapshot Expiration 后，存储空间才会被真正回收。

19. Global Index 与 Data Evolution

19.1 为什么索引会过期

Global Index 通常保存：
Data Evolution 更新列时 Row ID 不变，但列值可能改变：
旧索引仍把 a200 指向 Row ID 100，因此索引已过期。

19.2 更新索引列的策略

值
行为
THROW_ERROR
默认值，拒绝更新已建立 Global Index 的列
DROP_PARTITION_INDEX
提交更新时删除受影响分区索引
IGNORE
保留旧索引，之后必须刷新或重建
使用 IGNORE 时：
  • Spark、Flink 增量构建可根据索引源元数据定位发生变化的 Row Range；
  • 老索引没有 Data Evolution Source Metadata 时不能自动增量刷新；
  • PyPaimon 当前的增量构建主要补未覆盖范围，已覆盖行发生值更新后应显式删除并重建相关索引。

19.3 Search Mode 与覆盖范围

索引覆盖和索引新鲜度是两个不同概念：
  • Coverage：这个 Row ID Range 是否有索引文件；
  • Freshness：索引中的值是否仍然是最新列值。
detail 等搜索模式可以补扫未覆盖范围，但不能自动识别“覆盖范围内的旧值”。

20. 与 Lance、LanceDB 和 Apache Iceberg 的对比

Data Evolution 并不是 Paimon 独有的需求。随着湖仓系统开始承载图片、音视频、Embedding、模型分数和大量派生特征，多个项目都在解决同一个问题：
如何只写发生变化的列，同时保持行身份、快照隔离、索引正确性和可维护性？
Lance 已经具备成熟的整列追加和整列替换能力，并正在设计更细粒度的 Data Overlay；LanceDB 在其上提供面向特征工程和检索的高级接口。Iceberg 现有 Copy-on-Write 和 Merge-on-Read 仍主要工作在行粒度，但 V4 规范和社区开发计划已经明确加入 Column File。
本章以 2026-10-17 时各项目的官方文档、格式规范、主分支行为和公开 Roadmap 为依据。由于 LanceDB 与 Lance Core 的发布节奏并不完全同步，对只存在于最新格式设计中的能力会单独标记为实验性，不假设上层产品已经公开支持。
这里需要区分三个 Lance 相关概念：
名称
含义
Lance File Format
支持独立列文件、Fragment、随机访问和索引的底层格式与 Dataset 实现
LanceDB
基于 Lance 的检索数据库和 SDK，提供 Update、Merge Insert、Feature Engineering、Vector/FTS 等高级能力
Paimon file.format=lance
Paimon 使用 Lance 编码读写物理数据文件，表元数据、快照、Row ID、冲突和 Compaction 仍由 Paimon 管理
因此：
在 Paimon 中选择 Lance 作为文件格式，不等于把 Paimon 表转换成 Lance Dataset，也不会自动使用 Lance 的 Fragment、Transaction 或 Stable Row ID 语义。

20.1 三者共同要解决的问题

三种设计都面对同样的写放大问题。
假设一行包括：
如果只更新 model_score，传统 Row Rewrite 可能重写整行，甚至重新处理大型图片。列级更新希望把写入缩小为：
三者的共同思想是：
  1. 逻辑行不再要求全部列位于一个物理文件；
  1. 数据文件需要某种稳定的位置或行身份；
  1. Reader 负责把多个物理来源拼成逻辑行；
  1. 更新文件积累后需要 Compaction；
  1. 更新过的索引不能继续无条件使用；
  1. Snapshot 必须原子切换，不能暴露半完成状态。

20.2 Lance 的 Fragment 模型

Lance 的核心组织单位是 Fragment：
Lance 把 Fragment 定义为“表示同一批行的多个列文件集合”。
一个 Fragment 的多个 Data File：
  • 表示同一批物理行；
  • 每个文件通过 fields 声明自己保存的 Field ID；
  • 缺失列在没有其他 Provider 时读作 NULL；
  • 文件按物理位置对齐；
  • Fragment 通过 physical_rows 记录原始物理位置数；
  • Deletion File 记录被逻辑删除的本地 Row Offset。
这与 Paimon 的 Normal Row ID Range Group 很相似：
但两者的身份边界不同：
Paimon
Lance
文件通过 firstRowId + rowCount 建立对齐
文件直接归属于同一个 Fragment
相同范围的 Normal File 构成文件组
Fragment 元数据显式包含多个列文件
Dedicated File 可覆盖 Normal Range 的子区间
Fragment Base Data File 通常描述同一组物理行
Compaction 可以合并相邻 Row ID Range
Compaction 可以合并或重写 Fragment

20.3 Lance 增加和回填新列

Lance 的新增列能力支持三种重要模式。
20.3.1 只增加 Schema
该模式只更新元数据。旧 Fragment 不包含新列文件，Reader 为历史行补 NULL。它与 Paimon 单纯增加一个可空列的初始效果相同：只增加列定义，不自动计算历史值。
20.3.2 增加列并立即回填
Lance 可以通过 SQL 表达式计算新列，也可以通过批处理函数计算 Embedding、模型输出等复杂结果。耗时函数还可以使用 Checkpoint，失败后从已完成批次继续。
实现会逐个 Fragment 读取必要输入列，并为新列写出额外 Data File，而不重写旧列文件。
其逻辑结构为：
与 Paimon Shard Update 的共同点是：
  • 按已有物理顺序读取；
  • 输出行数和顺序必须保持一致；
  • 只写新列；
  • 不复制大型未更新列。
Lance 的 API 对 Batch UDF 和 Checkpoint 支持更直接；Paimon 的优势是同一存储语义已经接入 Spark SQL、Flink Procedure 和 PyPaimon。

20.4 Lance 整列替换

Lance 的整列替换事务用于替换现有 Fragment 的列文件。它把“目标 Fragment”和“新的列文件”作为一个原子替换单元提交。
要求：
  1. 目标字段必须已经存在于 Dataset Schema；
  1. 当前 API 按顶层列整体替换，不能只暂存一个嵌套叶子字段；
  1. 输入必须产生与 Fragment physical_rows 完全相同的行数；
  1. 输入包含被删除的物理位置，不能先应用 Deletion File 后缩短；
  1. 新文件与 Fragment 按物理位置对齐；
  1. 调用方需要基于正确 Read Version 提交，才能检测同字段并发替换。
这与 Paimon Normal Partial File 的契约高度相似：

20.5 Lance 列重写与 Paimon 部分列 MERGE

Lance Merge Insert 提供两种写入形态：
列重写模式的语义是：
  • Source 只携带 Join Key 和待更新列；
  • 不读写 Source 省略的列；
  • 在命中的 Fragment 上附加新的列文件；
  • 新列文件仍覆盖整个 Fragment；
  • 未命中行需要保留原值；
  • 不移动逻辑行，也不新增 Fragment；
  • Commit 会声明这是保持行位置不变的列重写；
  • 提交元数据记录被修改字段，用于处理索引覆盖失效；
  • 提交元数据记录实际命中位置，用于更新 Stable Row ID 的行级版本信息。
这几乎就是 Paimon Data Evolution MERGE 的 Lance 对应物：
Lance 文档还给出了一个重要成本模型：
可以用近似条件选择：
例如：
只要一个 Fragment 中更新超过约 0.1% 的行，整列替换就可能比移动完整行更便宜。
Paimon Data Evolution 当前主要采用整列范围写法，没有在普通 UPDATE 中自动切换为 Row Rewrite。其优势是模型统一、未更新 BLOB 不动；代价是极稀疏普通列更新仍会处理完整 Normal Range。

20.6 Lance 普通 UPDATE 与 Paimon UPDATE 不完全相同

Lance 普通行更新默认采用 Row Rewrite。
其执行方式是：
  1. 找出匹配行；
  1. 将旧物理行加入 Deletion File；
  1. 写出包含更新后完整行的新 Fragment；
  1. Stable Row ID 开启时把原 Row ID 复制给新物理行；
  1. 新地址替换旧地址。
因此不能笼统地说：
Lance 的所有 UPDATE 都是列级更新。
更准确的说法是：
Lance 操作
物理更新粒度
新增列并回填
给每个 Fragment 增加新列文件
整列替换
替换 Fragment 的完整列文件
Merge Insert 列重写
更新选中列，但文件覆盖完整命中 Fragment
普通行更新
默认删除旧物理行并写完整新行
Data Overlay
只写变化 Cell，目前实验性
Paimon Data Evolution 表的 Spark UPDATE 和匹配型 MERGE 默认走部分列文件语义，这是两者 API 默认行为的重要差异。

20.7 Stable Row ID 对比

Paimon
Paimon Row ID 以文件范围元数据为基础：
普通更新和普通 Compaction 保留 Row ID。Deletion Vector Materialization 会移除位置，并为重写范围中的存活行重新分配 Row ID。
Lance
Lance 同时区分：
未开启 Stable Row ID 时，_rowid 实际等同于物理 Row Address，会在 Compaction 或 Row Rewrite 后变化。
开启 Stable Row ID 后：
  • 新行从 Manifest 的 next_row_id 单调分配；
  • Fragment 保存 Row ID Sequence；
  • Update 把同一 Stable Row ID 搬到新物理地址；
  • 旧物理位置通过 Deletion File 隐藏；
  • Compaction 可以删除物理墓碑，但保留存活行的 Stable Row ID；
  • Row ID Sequence 可以内联在 Manifest，也可以溢写到隐藏列；
  • _row_created_at_version 和 _row_last_updated_at_version 支持增量处理和 Change Feed。
对比：
行身份特性
Paimon
Lance
默认是否开启
Data Evolution 必须开启 Row Tracking
默认可不开启 Stable Row ID
物理地址
不作为主要公开模型
fragmentId + localOffset
逻辑 ID 存储
主要通过 firstRowId + position 推导
Fragment Row ID Sequence
Update 后
保留原 ID
开启 Stable ID 时保留
普通 Compaction
保留 ID
开启 Stable ID 时保留
物理删除墓碑
Materialize DV 会重分配 ID
可重写物理文件并保留存活行 ID
行版本元数据
主要依赖 Snapshot 和 Sequence
有显式 created/last-updated version sequence
这里 Lance 的 Stable Row ID 更接近“永久逻辑行身份”；Paimon _ROW_ID 更接近“在不执行重分配维护时稳定的存储层位置标识”。

20.8 删除与 Compaction 对比

两者都采用逻辑删除文件：
共同点：
  • 删除不立即重写大型数据文件；
  • 删除记录的是物理位置；
  • Reader 在输出前过滤这些位置；
  • 历史版本仍可以引用旧数据；
  • 真正回收空间需要重写与清理历史版本。
主要区别：
项目
Paimon
Lance
删除定位
Row Range Group 的 Anchor File
Fragment 本地 Row Offset
普通 Compaction
保留逻辑删除位置，以维持未重写列对齐
可以重写整个 Fragment 并移除删除位置
删除物化后的 Row ID
当前 Paimon 会重分配受影响范围的 Row ID
Stable Row ID 开启时可保留存活行 ID
专用列文件约束
BLOB/Vector 可能阻止切分或 DV Materialization
重写 Fragment 时统一处理 Fragment 文件与 Row ID Sequence
这种差异来自文件组织：
  • Paimon 普通 Compaction 可以只重写 Normal File，同时保留 Dedicated File；
  • Lance Fragment Rewrite 可以把所有当前逻辑列重新组织到新 Fragment，并通过 Row ID Sequence 保留逻辑身份。

20.9 Lance Data Overlay：比整列更新更细的未来方向

Lance 的最新格式设计中已经包含 Data Overlay 的元数据、读取、事务、冲突和维护规则，但官方格式文档明确标记：
所以它代表正在开发的方向，不能当成当前稳定生产 API。
Data Overlay 的目标是只写变化的 Cell：
例如，当一次更新只改变 Fragment 中第 1、3 个位置的 age 时，Overlay 可以只保存：
而不保存同一 Fragment 中未命中的 age。
读取规则：
这与 Paimon 的区别非常关键：
从粒度看：
Overlay 会降低极稀疏更新的写放大，但会增加：
  • Coverage Bitmap；
  • Overlay 文件打开；
  • 读取时版本查找；
  • Base 与 Overlay 合并；
  • 索引排除和重新计算；
  • Overlay Compaction。
Lance 规划两种 Overlay Compaction：
Paimon 如果未来要支持稀疏普通列更新，也会面临类似设计选择：
  • 是否增加 Cell Coverage；
  • 如何表达显式 NULL 与未覆盖；
  • 如何与 Deletion Vector 叠加；
  • 如何维护字段级索引新鲜度；
  • 如何限制 Overlay 层数；
  • 如何在 Compaction 中折叠版本。

20.10 索引一致性对比

Paimon
Paimon Global Index 使用 Row ID Range，更新索引列时由：
决定：
  • THROW_ERROR；
  • DROP_PARTITION_INDEX；
  • IGNORE 后刷新。
增量 Index Planner 根据字段版本和 Row Range 判断需要重建的索引范围。
Lance
Lance 索引通常与 Fragment 和 Row Address/Stable Row ID 关联。
对于列文件替换：
  • 被修改字段列表用于识别失效的索引覆盖；
  • 覆盖这些字段的索引移除受影响 Fragment Coverage；
  • 查询退回 Flat Scan；
  • 后续 Optimize 或 Reindex 重新纳入。
对于 Row Rewrite：
  • 旧地址通过 Deletion File 隐藏；
  • 新物理行可能暂时未进入已有索引；
  • Flat Tail 保证仍可搜索；
  • Optimize 把新行折入索引。
实验性 Overlay 设计则使用：
计算字段级 Exclusion Set：
  1. 从索引结果排除 Overlay 更新过的位置；
  1. 用当前值重新扫描和判断这些位置；
  1. 将仍然匹配的行补回结果。
相比之下：
设计
优点
代价
Paimon Throw/Drop/Rebuild
语义简单，易保证正确
更新索引列可能阻塞或导致较大重建
Lance Fragment Coverage Pruning
允许保留其他 Fragment 的索引
受影响 Fragment 暂时退化为 Flat Scan
Lance Overlay Exclusion
可继续利用旧索引大部分结果
查询链路更复杂，需要排除和重新计算

20.11 Paimon 与 Lance 的能力矩阵

维度
Paimon Data Evolution
Lance/LanceDB
核心定位
湖仓 Append Table 的列级演进
ML/检索优化的列式 Dataset 和数据库
物理分组
Row ID Range Group
Fragment
新增空列
Schema Evolution
Metadata-only Schema Change
新列回填
Spark/Flink/Python 部分列写
SQL、Batch UDF、Stream/Reader
已有列整列替换
部分列文件
Fragment Column Replacement
匹配型列更新
默认 Data Evolution 路径
Merge Insert Column Rewrite，需显式选择或由特定路径使用
极稀疏更新
仍写完整 Range 的更新列
默认 Row Rewrite 或整列 Fragment Rewrite
Cell Overlay
不支持
Main 中实验性，尚非稳定 Library 能力
Nested Leaf 更新
可选，一层组合
普通 Update 不支持嵌套路径；Overlay Reader 设计可按叶子合并
BLOB
Paimon 托管 BLOB、Placeholder、Dedicated File
Lance 原生 Blob；列重写路径当前对 Blob 存在限制
Vector
Dedicated Vector File + Global Index
原生 Vector 类型与 ANN Index
Stable Row ID
Data Evolution 必须有，但维护可重分配
可选；开启后以 Row ID Sequence 跨 Rewrite 保持
删除
Deletion Vector
Deletion File/Bitmap
删除物化
重分配受影响 Row ID
可保留 Stable Row ID
SQL/引擎生态
Spark、Flink、PyPaimon
SDK、LanceDB SQL/Enterprise、DataFusion
索引更新
Throw/Drop/Ignore+Refresh
Fragment Coverage、Flat Tail、Optimize；未来 Overlay Exclusion
Compaction
合并列版本和 Range
合并/重写 Fragment、折叠删除、维护索引

20.12 Iceberg 当前的 UPDATE 模型

Iceberg V2/V3 的 Row-Level Update 主要有两类：
Copy-on-Write
优点：
  • 读取简单；
  • 最新 Snapshot 没有额外 Merge-on-Read 成本；
  • 普通 Data File 可直接使用标准 Parquet/ORC/Avro Reader。
缺点：
  • 更新一个窄列也会重写其他列；
  • 宽表、Embedding 和大型载荷写放大明显。
Merge-on-Read
典型更新可表达为：
V2 使用 Position Delete File，V3 可以使用 Deletion Vector。
它减少了立即重写原文件的成本，但新行通常仍是完整 Row，不是只含更新列的 Column File。
因此在 Iceberg V4 Column File 完整落地前：
Iceberg 有 Row-Level Update 和 Delete，但没有与 Paimon Data Evolution 等价的稳定、通用 Column Provider 读取模型。

20.13 Iceberg V3 Row Lineage

Iceberg V3 引入：
新行可以通过：
继承 Row ID。
当已有行移动到新 Data File 时，Writer 应：
  1. 复制原 _row_id；
  1. 修改行时把 _last_updated_sequence_number 写为 NULL，在提交后继承新 Sequence；
  1. 未修改行保留原 Last Updated Sequence。
这与 Paimon、Lance 的共同方向一致：
但 Iceberg Spec 特别指出：
  • Equality Delete 型更新无法保留原 Row ID；
  • 因为 Writer 不读取旧行，无法知道新行对应哪个旧 Row ID；
  • 这种更新被视为删除旧行并新增一个新身份的行。
所以 Iceberg 的 Row ID 是否稳定，还取决于 Engine 采用何种更新路径。

20.14 Iceberg V4 Column File

Iceberg V4 规范已经增加 column_files：
约束包括：
  • Column File 只能关联到 Data File 或 V4 Leaf Manifest；
  • 同一个 Field ID 在一个 Tracked File 的 Column File 列表中最多出现一次；
  • Column File 更新后，当前版本使用 MODIFIED Entry；
  • 旧元数据通过 REPLACED Entry 记录，支持 Change Detection；
  • 添加 Column File 时可以更新 Data Sequence Number；
  • Reader 需要把 Base File 和 Column File 按行位置 Stitch。
社区提案的目标非常明确：
这与 Paimon Data Evolution 和 Lance Fragment 整列替换的核心思想相同。

20.15 Iceberg V4 当前实现状态

截至本章分析的 2026-10-17：
  1. Iceberg 主规范已经描述 V4 column_files；
  1. V4 Adaptive Metadata Tree Spec PR 已合并；
  1. 主实现已支持 Format Version 4 的部分基础元数据和 Manifest 读写；
  1. 当前主分支中还没有完整、稳定的 Column File 公共模型和 Reader Stitching；
  1. 当前主分支中的兼容性元数据读写层还没有把 column_files 完整暴露为成熟的数据文件模型；
  1. Column File 相关实现仍在多个开放 PR 中推进。
社区当前已经完成或正在推进的里程碑包括：
  1. V4 Adaptive Metadata Tree 规范；
  1. Column File 的基础元数据模型；
  1. Manifest 中 Column File 的读取；
  1. Row-based Reader 的列拼接；
  1. Vectorized Reader 的列向量拼接；
  1. Generic Reader、Spark、Flink 和 Encryption 的统一接入。
因此应把 Iceberg Column File 定位为：
已进入 V4 规范、正在快速实现，但尚不能按成熟生产能力与 Paimon Data Evolution 或 Lance 整列更新直接等同。

20.16 Iceberg Proposal 与 Paimon 的关键差异

Iceberg Issue #15146 明确说明：
这意味着当前 Iceberg Column Update Proposal 更接近：
而 Paimon 已经支持：
两者都在物理上写完整对齐列文件，但操作入口不同：
场景
Paimon
Iceberg V4 Proposal
全表新列回填
支持
目标场景
全 Data File 某列刷新
支持
目标场景
Predicate 命中部分行
支持，补齐 Range 内旧值
当前 Proposal 明确列为 Non-goal
行级删除
Deletion Vector
V3/V4 Deletion Vector
稀疏 Cell Update
不支持
当前 Proposal 不支持

20.17 三者总对比

维度
Paimon Data Evolution
Lance/LanceDB
Iceberg V2/V3
Iceberg V4 Column File
当前成熟度
已实现
整列更新已实现；Overlay 实验中
行级更新成熟
规范已进入，Reader/Writer 开发中
主要更新单位
列 × Normal Range
列 × Fragment，或完整匹配行
完整行/Data File
列 × Tracked Data File
部分行部分列
支持，但写完整 Range
Column Rewrite 支持；普通 Update 默认 Row Rewrite
通过行级 MOR/COW，不是列文件
当前 Proposal 非目标
稀疏 Cell 文件
无
Data Overlay 设计
无
无
行身份
_ROW_ID
Stable _rowid 可选
V3 _row_id
继承 V3 Row Lineage
删除
DV
Deletion File
Position/Equality Delete、DV
Colocated DV
Reader 拼接
按 Row ID 位置合并 Provider
Fragment 内按位置合并 Data File
合并 Delete 与完整行
Base + Column File Stitch
大对象支持
托管 BLOB、Vector Dedicated File
Blob、Vector 原生
依赖 Data File 类型
Column File 可存标准格式列
索引
Global Index + Row Range
原生 ANN/Scalar/FTS
外部/引擎级能力为主
Secondary Index Spec 也在推进
更新后索引
Throw/Drop/Refresh
Coverage Pruning/Flat Tail/Optimize
通常重写或重新维护
实现仍在设计和开发
Compaction
合并列版本；DV 物化独立
Fragment Rewrite，可保留 Stable ID
Rewrite Data Files/Delete Files
需要整合 Column File
生态重点
Spark/Flink/Python 湖仓
ML、检索、嵌入式/服务
跨引擎湖仓标准
未来 V4 跨引擎列级更新

20.18 对 Paimon 设计的启示

启示一：Paimon 和 Lance 的成熟整列设计高度趋同
两者都选择：
这说明 Paimon 的 Row ID Range Group 并不是孤立设计，而是与 ML 数据格式的发展方向一致。
启示二：Paimon 的优势在湖仓引擎集成
Lance 在格式、随机访问、向量索引、UDF 回填和 Stable Row ID 方面更原生；Paimon 则已把列级更新统一接入：
  • Spark SQL UPDATE/MERGE；
  • Flink Procedure 和 Delete；
  • PyPaimon；
  • Catalog、Snapshot、Branch、System Table；
  • BLOB/Vector/Global Index。
对于已有 Flink/Spark 湖仓管道，Paimon 的使用门槛更低。
启示三：Lance Stable Row ID 更适合跨重写外部引用
Paimon 的 Row ID 在 DV Materialization 和显式 Reassign 时会变化。如果跨表引用 _ROW_ID 是关键需求，可以借鉴 Lance：
  • 为逻辑 ID 建立独立 Sequence；
  • 物理位置改变时保留逻辑 ID；
  • Row ID 与 Row Address 明确分离；
  • 为创建版本和最后更新版本建立行级元数据。
代价是 Row ID Sequence、映射索引和 Compaction 复杂度上升。
启示四：稀疏 Overlay 是值得关注但代价很高的方向
Paimon 当前对普通列的极稀疏更新仍有较大读取和写入放大。Lance Overlay 展示了可行方向，但也同时引入：
  • Cell Coverage；
  • 多层版本；
  • 索引 Exclusion；
  • Overlay 合并；
  • Base Fold；
  • Row Rewrite 冲突；
  • Feature Flag 和混合版本兼容。
在没有明确稀疏更新比例和收益数据前，完整 Range 列文件仍是更简单可靠的设计。
启示五：Iceberg V4 会缩小格式能力差距
Iceberg 一旦完成 Column File：
  • 宽表新列回填不再需要重写 Base File；
  • 标准 Parquet/ORC/Avro 可以作为 Column File；
  • 跨引擎兼容会成为强项；
  • Paimon 不能只依赖“支持列级更新”作为差异点。
Paimon 更需要突出：
  • 部分行匹配更新已经可用；
  • Spark/Flink/Python 统一语义；
  • BLOB Placeholder 和 Dedicated Storage；
  • Global Index 刷新；
  • Compaction Conflict Rebase；
  • 多模态端到端能力。

20.19 选型建议

需求
更适合的方向
Flink/Spark 湖仓中持续补充特征列
Paimon Data Evolution
图片/BLOB、Embedding、全文和向量检索一体化，同时仍需湖仓批处理
Paimon 或 LanceDB，取决于计算生态
Python/Rust 为主的 ML Dataset、随机访问和训练数据加载
Lance
Retrieval、Vector/FTS、低延迟 SDK 查询
LanceDB
最大化跨引擎开放格式兼容
Iceberg
当前就要生产可用的列级部分更新
Paimon 或 Lance 的整列重写路径
等待标准化 Column File 后让多引擎共同读写
关注 Iceberg V4
大量极稀疏 Cell Update
当前应基准测试 Row Rewrite 与整列 Rewrite；持续关注 Lance Overlay

20.20 延伸材料与 Roadmap

为了降低对内部代码结构的依赖，建议优先按文档主题阅读，而不是按具体文件或类名查找：
Paimon
  • Data Evolution 总览；
  • File Layout and Reads；
  • Data Evolution Maintenance；
  • PyPaimon Data Evolution；
  • Global Index 的更新与维护；
  • Lance 文件格式集成说明。
Lance 与 LanceDB
  • Lance Data Evolution；
  • Fragment 与多列文件布局；
  • Row ID and Lineage；
  • Transaction Conflict Rules；
  • Data Overlay Files；
  • LanceDB Feature Engineering、Computed Column 和 Column Refresh；
  • Update、Merge Insert、Compaction 与 Index Maintenance。
Iceberg
  • Table Format Specification 中的 Row Lineage、Deletion Vector 和 V4 Column File；
  • V4 Adaptive Metadata Tree；
  • Efficient Column Updates Proposal；
  • Column File Metadata、Manifest Reader 和 Reader Stitching 的实现进展。
Iceberg 社区 Roadmap 应以 Issue #15146 及其关联的 V4 Column File PR 为入口。具体 PR 编号和拆分方式会随开发过程变化，学习时应关注以下里程碑，而不是绑定某个内部实现名称：
  1. Column File 元数据进入公共数据模型；
  1. V4 Manifest 能够稳定读写 Column File；
  1. Row-based Reader 能按位置拼接 Base 和 Column File；
  1. Vectorized Reader 能零拷贝或低拷贝拼接列向量；
  1. Spark、Flink 和 Generic Reader 形成一致语义；
  1. Encryption、Projection、Deletion Vector 和 Change Detection 完整接入；
  1. Writer 和 Column Update API 达到可生产使用状态。

21. 关键配置表

配置
默认值
说明
row-tracking.enabled
false
为 Append Table 开启 Row ID，不可变
row-tracking.partition-group-on-commit
true
提交时按分区组织新文件，使分区内 Row ID 更连续
data-evolution.enabled
false
开启 Data Evolution，不可变
deletion-vectors.enabled
false
开启行级逻辑删除
data-evolution.write-cols-optimization.enabled
false
完整非 Dedicated 列文件省略 writeCols
data-evolution.nested-field.enabled
false
开启 Struct 子字段级更新
data-evolution.row-id-conflict-rewrite.max-size
256 MB
PyPaimon 边界冲突自动重写上限
data-evolution.row-sidecar.enabled
false
生成稀疏 Row ID 读取 Sidecar
data-evolution.row-sidecar.max-selected-rows
4096
Sidecar 最大选中行数
data-evolution.row-sidecar.max-selection-ratio
0.05
Sidecar 最大选中比例
data-evolution.merge-into.file-pruning
true
Spark MERGE 部分列写前裁剪未触碰文件
data-evolution.merge-into.source-persist
false
Data Evolution Merge 是否缓存 Source
data-evolution.compaction.split-large-files
false
Compaction 是否拆分大 Normal File
data-evolution.compaction.large-file-ratio
2.0
大文件判定倍率
blob-compaction.enabled
false
是否执行 BLOB Compaction
global-index.column-update-action
THROW_ERROR
更新索引列时的行为
Spark Connector 专用配置：
配置
默认值
spark.paimon.write.data-evolution.update-conflict-retry.max-attempts
20
spark.paimon.write.data-evolution.update-conflict-retry.wait-ms
10

22. 引擎能力对比

能力
Spark
Flink
PyPaimon
INSERT 新行
支持
支持
支持
UPDATE 普通列
支持
通过专用 procedure
支持
MERGE Matched Update
支持
支持
支持
MERGE Not Matched Insert
支持
专用 procedure 不支持
支持
MERGE Matched Delete
支持，需 DV
专用 procedure 不支持
支持，需 DV
Not Matched By Source Delete
Spark 3.4+，需 DV
专用 procedure 不支持
视 API 规则
DELETE FROM
支持，需 DV
Flink 1.17+ Batch，需 DV
delete_by_predicate
按 _ROW_ID 更新
内部和 SQL 快捷路径
内部支持
直接 API
Shard 派生列回填
可通过 Spark SQL/DF
可通过任务实现
原生支持
普通 Compaction
支持
支持
依赖相应维护能力
Materialize DV
支持
支持
依赖相应维护能力

23. 观测与排障

23.1 查看逻辑行和 Row ID

23.2 查看当前文件布局

检查要点：
  1. Normal File Range 是否相同或不相交；
  1. 相同 first_row_id 的 Normal File 是否有相同 record_count；
  1. Dedicated File 是否完整包含于一个 Normal Range；
  1. write_cols 是否符合预期；
  1. 同一列是否存在过多版本；
  1. 文件数是否因频繁更新持续增长。

23.3 不要用 $files.record_count 求逻辑行数

多个列文件可能代表相同 Row ID Range：
逻辑行数仍可能只有 100，而不是 300。
此外，Deletion Vector 还会减少可见行数。应查询表本身获取逻辑行数。

23.4 常见问题

更新一行为什么写了很多行？
因为普通列更新单位是“选中列 × 完整 Normal Range”，不是单个匹配行。
UPDATE 后读取文件越来越多？
每次部分列更新会增加列版本，需要定期 compaction。
同一文件范围内更新不同业务行为什么冲突？
两个 Writer 如果都更新相同列，就都在替换该列的完整 Range。
新增列后为什么历史行是 NULL？
Schema Evolution 只新增列定义，不自动执行数据回填。
删除后文件大小为什么没有下降？
普通删除只写 Deletion Vector。需要 materialize_deletion_vectors 才会移除位置，但 Row ID 会改变。
Compaction 后更新提交为什么失败？
可能是 Normal Range 边界变化导致 Layout Conflict。重新规划，或使用支持 Rebase 的 Spark/PyPaimon 路径。
更新索引列为什么报错？
默认 global-index.column-update-action=THROW_ERROR，需要选择删除分区索引、忽略后重建，或先手动删除索引。

24. 文件大小设计

target-file-size 不只是影响扫描性能，也影响未来的更新成本。

大文件

优点：
  • 全表扫描文件数少；
  • Manifest 和文件打开开销低。
缺点：
  • 更新一行也要处理更大的 Normal Range；
  • 单次部分列更新成本高；
  • 并发更新更容易落入同一个 Range。

小文件

优点：
  • 更新粒度更小；
  • 冲突域更小；
  • 稀疏更新成本低。
缺点：
  • 文件数多；
  • 扫描和元数据开销高；
  • compaction 压力更大。
可同时考虑：
target-file-row-num 只约束支持该选项的新写入，不会在普通部分更新时拆开已有 Normal Range。Data Evolution compaction 也可能产生更大的合并范围。

25. 已知限制和使用边界

  1. 不能定义 Primary Key；
  1. 只支持 bucket = -1；
  1. 不能开启 clustering.incremental；
  1. Matched partial update 不能修改分区列；
  1. 普通列的稀疏更新仍要处理完整文件范围；
  1. Dedicated Vector File Compaction 尚未支持；
  1. 包含 Dedicated Vector File 的组不能 Materialize DV；
  1. data-evolution.compaction.rewrite-row-ids=true 已废弃并会被拒绝；
  1. Branch Merge 不支持 Data Evolution 表；
  1. import_files 不支持 Row Tracking 或 Data Evolution 表；
  1. Nested Field 开启后存在严格的混合版本和降级风险；
  1. _ROW_ID 不能作为永久业务标识；
  1. 更新已建立 Global Index 的列必须处理索引新鲜度；
  1. 并发 Delete、Append、Compact、Overwrite 可能发生提交冲突，应做好任务编排和重试；
  1. 历史 Snapshot/Tag 会延迟旧文件的空间回收。

26. 推荐实践

26.1 表设计

  • 保留稳定的业务 ID，但不要把它误认为 Paimon Primary Key；
  • 根据更新粒度设计 target-file-size；
  • 大 BLOB、Vector 使用 Dedicated Storage；
  • 需要行级删除时，从建表阶段就规划 Deletion Vector；
  • 对长期保存的 _ROW_ID 引用建立维护协议。

26.2 更新任务

  • 只声明真正需要更新的列；
  • 避免 UPDATE SET 中无意义地重写全部列；
  • 尽量按分区限制更新范围；
  • 对大范围更新评估是否关闭 MERGE File Pruning；
  • 对确定性 Spark UPDATE 配置合理冲突重试；
  • 对频繁更新的列设置定期 compaction。

26.3 索引

  • 更新索引列前明确选择 global-index.column-update-action；
  • IGNORE 后必须安排索引刷新或重建；
  • 用 Row Sidecar 优化全局索引后的稀疏 Row ID 回表；
  • DV Materialization 后重新构建受影响索引。

26.4 运维

  • 定期查询 $files 检查列版本数量；
  • 监控小文件数量、单 Range 文件数量和读取放大；
  • 普通 compaction 与 DV materialization 分开调度；
  • Materialize DV 前确认下游没有长期依赖旧 _ROW_ID；
  • 结合 Snapshot/Tag 保留策略安排空间回收。

27. 实现原理核对路线

不建议从具体类名开始阅读，因为内部结构会随重构变化。更稳定的方法是按问题和模块逐层核对。

第一阶段：表模型与配置

重点理解：
  • 为什么必须无主键、bucket=-1；
  • Data Evolution 如何改变普通 Append Table 的扫描和读取语义；
  • 哪些选项不可变。

第二阶段：Row ID 分配

重点理解：
  • nextRowId；
  • firstRowId；
  • Append、Partial Update、Compact 文件的不同处理。

第三阶段：文件扫描与读取

重点理解：
  • Row Range Group；
  • Provider 选择；
  • Projection Pruning；
  • Deletion Vector；
  • Nested Field；
  • BLOB Fallback；
  • Row Sidecar。

第四阶段：Spark 写入

重点理解：
  • UPDATE 如何转换成 Self Merge；
  • _ROW_ID 快捷路径；
  • 完整 Range 补齐；
  • File Pruning；
  • Compaction Conflict Rebase。

第五阶段：Flink 写入

重点理解：
  • 固定 Snapshot；
  • 按 firstRowId Shuffle；
  • _ROW_ID 排序；
  • 原值补齐；
  • BLOB Placeholder；
  • Deletion Vector 写入。

第六阶段：冲突和维护

  • 找到提交冲突检测模块，核对 Range 与 Field ID 的冲突条件；
  • 找到普通 Compaction 规划和执行模块，核对 Row ID 保留规则；
  • 找到 Deletion Vector Materialization，核对物理删除和 Row ID 重分配；
  • 找到边界变化后的重试或 Rebase 路径，核对其适用条件。

第七阶段：索引

  • 核对索引文件如何记录 Row Range 和源 Snapshot；
  • 核对更新索引列后的 Throw、Drop 或 Ignore 行为；
  • 核对未覆盖范围与已覆盖但可能过期范围的区别；
  • 核对增量刷新如何识别字段版本变化。

28. 推荐验证场景

比记住测试类名更重要的是理解每组测试验证的契约。

Core 语义

  • 同一 Row ID Range 的多列文件能正确合并；
  • 缺失列、显式 NULL 和 BLOB Placeholder 的语义不同；
  • Projection Pruning 不会丢失行数或 Deletion Vector Anchor；
  • 普通文件索引和 Bitmap Selection 不破坏列位置对齐；
  • Nested Field Provider 能按支持的层级正确组合；
  • 非法 Normal/Dedicated Range 会在提交或读取时被拒绝。

并发与提交

  • 同一 Range 更新不同字段可以提交；
  • 同一 Range 更新相同字段发生冲突；
  • Compaction 改变边界后能够 Rebase，或给出明确冲突；
  • Overwrite、分区删除和 Row ID 重分配不会被旧计划静默覆盖；
  • Deletion Vector 与部分列更新的并发行为符合预期。

Spark 与 Flink

  • UPDATE 和 MERGE 只写声明更新的字段；
  • 未命中行在输出列文件中得到正确旧值；
  • _ROW_ID 快捷路径和普通业务条件路径结果一致；
  • DELETE 正确生成并应用 Deletion Vector；
  • 分区裁剪、文件裁剪和 Self Merge 优化不改变结果。

Python

  • Predicate、Row ID 和 Shard Update 结果一致；
  • Shard Update 对行数和顺序进行严格校验；
  • Stream Commit Identifier 生命周期正确；
  • Native Commit、REST Commit 和普通 Catalog 行为一致；
  • Row Sidecar 只在稀疏读取阈值内启用。

29. 建议动手实验

实验一：观察一次部分列更新

  1. 建 Data Evolution 表；
  1. 插入 5 行；
  1. 查询 $row_tracking；
  1. 查询 $files；
  1. 只更新其中一行的一个列；
  1. 再次查询 $files；
  1. 验证新文件与原 Normal File 的 Row Range 完全相同。

实验二：验证不同列并发更新模型

  1. 两个任务固定同一个 Snapshot；
  1. 一个更新 b，一个更新 c；
  1. 对比更新相同列 b 的行为；
  1. 对照“Range 相交且字段集合相交”的冲突模型解释结果。

实验三：删除与物化

  1. 开启 Deletion Vector；
  1. 删除一行；
  1. 验证 Row ID Range 和 record_count 不变；
  1. 执行普通 compaction，确认 Row ID 不变；
  1. 执行 materialize_deletion_vectors；
  1. 观察新 Row ID 和索引变化。

实验四：Compaction 边界变化

  1. 创建两个相邻 Normal Range；
  1. 固定旧 Snapshot 规划更新；
  1. 运行 compaction 合并范围；
  1. 提交旧更新；
  1. 观察 Layout Conflict 或 Rebase。

实验五：Row Sidecar

  1. 开启 data-evolution.row-sidecar.enabled；
  1. 构建标量 Global Index；
  1. 查询少量 Row ID；
  1. 对比 Sidecar 开关下读取的物理文件和性能。

30. 最终心智模型

可以把 Data Evolution 看成一个以 Row ID Range 为单位的、支持多版本列文件的存储模型：
读取时：
更新时：
维护时：
只要始终抓住三个关键词，就能理解大部分实现：
  1. Row ID 对齐；
  1. 列 Provider 最新版本胜出；
  1. Normal Range 必须完全相同或完全不相交。

31. 延伸阅读

建议优先阅读以下稳定主题：
  1. Data Evolution：建表、更新、删除和并发行为；
  1. File Layout and Reads：Row ID Range、Provider 选择和文件契约；
  1. Data Evolution Maintenance：普通 Compaction、文件拆分和 DV Materialization；
  1. PyPaimon Data Evolution：Predicate、Row ID、Shard 和 Stream Update；
  1. Global Index Management：索引覆盖、新鲜度和更新策略；
  1. Flink Action 与 Procedure：Merge、Delete 和维护任务；
  1. Spark Maintenance 与 Index Procedure：Compaction、DV 和 Global Index；
  1. Lance Data Evolution 与 Row Lineage：Fragment、Column Replacement 和 Stable Row ID；
  1. Lance Data Overlay：稀疏 Cell 更新的实验性设计；
  1. Iceberg Table Format Specification：V3 Row Lineage、Deletion Vector 和 V4 Column File；
  1. Iceberg Efficient Column Updates Proposal：Column File 的目标、非目标和实施进展。
阅读在线文档时应注意版本选择。master 或 main 页面反映正在开发的行为，未必代表某个已发布版本已经具备相同能力。
]]> <![CDATA[Apache Paimon 2.1.0 正式发布：强化多模态 AI、原生 Python 与湖仓互操作]]> https://kunni.top//article/3fa0e356-2fd6-80f9-8b4f-db92b3ec8507 https://kunni.top//article/3fa0e356-2fd6-80f9-8b4f-db92b3ec8507 Thu, 15 Oct 2026 00:00:00 GMT
发布日期：2026 年 10 月 12 日
Apache Paimon 社区正式发布 Apache Paimon 2.1.0 和 PyPaimon 2.1.0。
相比 2.0.0，本版本经过约两个月迭代，两个正式 Tag 之间涉及约 1,000 个提交，重点完善了多模态数据管理、Data Evolution、PyPaimon 原生执行、全局索引、REST Catalog、Iceberg 兼容以及 Flink、Spark 集成。
正式源码包已经发布，Java 构件和 PyPaimon 也分别可以从 Maven Central 与 PyPI 获取。

版本亮点

  1. Data Evolution 能力进一步完善，支持更加灵活的列级、嵌套字段级更新与数据回填。
  1. 多模态数据能力增强，持续完善 BLOB、VECTOR、VARIANT、视频和 LeRobot 数据集支持。
  1. PyPaimon 原生执行路径扩展，加强 Rust Native、Ray 和 PyTorch 等 AI 数据处理生态。
  1. 全局索引与搜索能力升级，增强 BTree、Bitmap、Multivalue、FM、向量和全文索引。
  1. REST Catalog 与数据治理能力增强，新增权限、策略、查询授权和语义视图等管理能力。
  1. Iceberg、Flink、Spark 和 CDC 集成持续增强，并修复大量并发、Compaction 和格式兼容问题。

多模态与 Data Evolution

Paimon 2.1.0 继续完善面向 AI 数据管道的 Data Evolution 模型。对于启用 Row Tracking 的 Append Table，可以只更新指定列，而无需重写未发生变化的大字段文件；逻辑行可以由普通列文件、BLOB 文件和向量文件按照 Row ID 组合而成。
本版本主要增强包括：
  • 支持嵌套字段级 Data Evolution。
  • 完善 Spark UPDATE、MERGE INTO 和 Flink SQL DELETE。
  • 增强 PyPaimon 按 Row ID、业务键和条件进行更新、删除与合并。
  • 优化并发更新和 Compaction 之间的冲突检测与重试。
  • 支持 Data Evolution 表上的 Deletion Vector、索引下推和统计信息裁剪。
  • 增强 BLOB 数组、MAP BLOB、向量文件和局部列回填能力。
Data Evolution 能够避免在更新标签、描述、向量等派生数据时重复改写图片、视频等大型原始数据，尤其适合数据标注、Embedding 生成和模型训练数据迭代场景。

PyPaimon 与 AI 数据处理

PyPaimon 2.1.0 是本次发布的重点方向之一。Native 读取、写入、扫描规划和提交能力得到扩展，更多主键表、动态 Bucket、Data Evolution、BLOB、VARIANT 和分支写入场景可以进入 Rust 原生执行路径。
在分布式 AI 数据处理方面，本版本增强了：
  • 基于 Ray 的分布式向量搜索、全文搜索和混合搜索。
  • Ray Row ID 更新和大规模 MERGE。
  • PyTorch 流式、批式和分布式 Dataset。
  • LeRobot 数据集导入、直接采集写入和训练窗口读取。
  • Packed Video 存储、关键帧索引和并行视频解码。
  • HDFS Native Client，以及 BLOB、VARIANT 和向量数据的原生读取。
PyPaimon 进一步从“Python 访问接口”演进为面向 AI 和多模态工作负载的数据处理 SDK。

全局索引与搜索能力

Paimon 2.1.0 对全局索引进行了较大范围的增强：
  • BTree 支持复合键、前缀、范围、IN 和空值查询。
  • BTree 可选 Bloom Filter，并优化 Posting List 编码。
  • 新增面向数组成员查询的 Multivalue Index。
  • 完善 FM Index，支持精确子串查询和主键表。
  • 支持索引增量刷新和并行构建。
  • 向量索引和全文索引支持 Deletion Vector 表。
  • 支持向量、全文和混合搜索的预过滤及分布式执行。
  • 改进索引覆盖范围、残余谓词和统计信息处理的正确性。
2.1.0 的全局索引体系覆盖标量过滤、数组成员检索、子串搜索、向量相似度搜索和全文搜索，为统一分析与 AI 检索提供了更加完整的能力。

REST Catalog 与数据治理

REST Catalog 在 2.1.0 中进一步从远程元数据访问接口扩展为统一的 Catalog 与治理入口，新增或增强了：
  • REST Schema Management。
  • 权限和策略管理。
  • 行级过滤与列掩码。
  • Query Authorization。
  • Semantic View 和实体标签管理。
  • 分区统计信息注册。
  • PyPaimon REST Commit 与权限管理。
  • REST Management OpenAPI。
此外，Paimon 视图现在可以在 REST、JDBC 和 Hive Catalog 中保存，并可维护不同 SQL 引擎方言的查询定义。

Iceberg 兼容性

本版本继续增强 Paimon 表的 Iceberg 元数据发布能力：
  • 支持 Iceberg Format V3 Row Lineage 元数据。
  • 支持将 VARIANT 列发布为 Iceberg V3。
  • 增强 Iceberg REST Catalog 属性透传与异常恢复。
  • 改进 Tag 到 Iceberg Snapshot Reference 的映射。
  • 完善时间精度、NaN Bounds 和不兼容类型校验。
  • 修复回滚、元数据过期和 REST 短暂故障场景。
其他引擎可通过 Iceberg Connector 读取 Paimon 发布的元数据，而数据写入、Compaction 和生命周期管理仍由 Paimon 负责。

Flink、Spark、CDC 与可靠性

围绕计算引擎集成，2.1.0 增强了：
  • Flink Data Evolution SQL DELETE、Savepoint Auto Tag 和异步 Lookup 刷新。
  • Spark Data Evolution Self-Merge、MERGE INTO、Row ID 重分配及 Format Table 操作。
  • Format Table 的 TRUNCATE TABLE、ANALYZE TABLE、分区统计和 Overwrite。
  • MySQL CDC 表级配置、PostgreSQL jsonb、Debezium 主键解析和多表 CDC 状态恢复。
  • 并发 MERGE 与 Compaction 冲突检测。
  • Manifest、Block Cache、文件索引、向量搜索和 BLOB 读取性能优化。
2.1.0 继续提供 Flink 1.16—2.2、Spark 3.2—4.1，以及多个 Hive 版本的构件。
]]> <![CDATA[Variant 二进制编码]]> https://kunni.top//article/3f40e356-2fd6-8021-9f78-ce6049792c96 https://kunni.top//article/3f40e356-2fd6-8021-9f78-ce6049792c96 Fri, 09 Oct 2026 00:00:00 GMT
原文：VariantEncoding.md
 
一个 Variant 表示以下三种类型之一：
  • 原始类型（Primitive）：一种类型及其对应的值，例如 INT、STRING
  • 数组（Array）：由 Variant 值组成的有序列表
  • 对象（Object）：由字符串和 Variant 组成的无序键值对集合。一个对象不能包含重复的键
一个 Variant 使用两个二进制值进行编码：值和元数据。
允许使用的原始类型数量是固定的，具体见下表。这些类型是 Parquet 格式所支持的逻辑类型中被普遍支持的一个子集。
Variant 二进制编码可以将半结构化数据（例如 JSON）表示为一种能够按路径进行高效查询的形式。即使数据结构非常宽或嵌套非常深，该设计也能够高效访问嵌套数据。
采用这种表示方式的另一个原因是：除元数据外，每个嵌套的 Variant 值都是连续存储且自包含的。
例如，当一个 Variant 包含由多个 Variant 值组成的数组时，只要将其中某个内部 Variant 值与完整 Variant 的元数据配对，该内部值本身就是一个合法的 Variant。
本文档描述 Variant 二进制编码方案。
Variant 字段还可以进行“拆分”（shredding）。拆分是指把 Variant 中的某些元素提取到单独的列中，以实现更高效的数据提取和过滤下推。[Variant 拆分规范](VariantShredding.md)描述了如何将 Variant 值拆分成带类型的 Parquet 列。

Parquet 中的 Variant

在 Parquet 中，一个 Variant 值由一个包含两个字段的 Group 表示，这两个字段分别名为 value 和 metadata。
  • Variant Group 必须使用 VARIANT 逻辑类型进行标注。
  • value 和 metadata 字段都必须是 binary 类型，即 Parquet Thrift 定义中的 BYTE_ARRAY。
  • metadata 字段必须标记为 required，并且必须是符合下文定义的有效 Variant 元数据。
  • 对于未拆分的 Variant 值，value 字段必须标记为 required；如果值的一部分已经被[拆分](VariantShredding.md)为带类型的 Parquet 列，则应标记为 optional。
  • 如果 value 字段存在，它必须是符合下文定义的有效 Variant 值。
以下是 Parquet 中未拆分 Variant 的预期表示形式：
以下是 Parquet 中已拆分 Variant 的一个示例：
VARIANT 注解本身不会对 Variant Group 的重复性施加额外限制，但包含它的类型（例如 MAP 和 LIST）可能对此作出限制。
Variant Group 的名称就是 Variant 列的名称。

元数据编码

编码后的元数据始终以一个头字节开始：
version 是一个 4 位值，当前必须始终为 1。
sorted_strings 是一个 1 位值，表示字典中的字符串是否经过排序且互不重复。
offset_size_minus_one 是一个 2 位值，用于表示每个字典大小字段和偏移量字段所占的字节数。实际字节数 offset_size 的计算方式为：
第 5 位（标记为 R）是保留位，读取器必须忽略它。
完整元数据的编码结构如下：
元数据首先编码 header 字节，然后编码 dictionary_size。
dictionary_size 是一个长度为 offset_size 字节的无符号小端序整数，表示字典中的字符串数量。
接下来是 offset 列表，其中包含 dictionary_size + 1 个值。每个 offset 都是一个长度为 offset_size 字节的无符号小端序整数，表示第 i 个字符串在 bytes 中的起始字节偏移量。
第一个 offset 始终为 0，最后一个 offset 始终等于 bytes 的总长度。
元数据的最后一部分是 bytes，用于保存字典中的所有字符串。所有字符串都必须使用 UTF-8 编码。

元数据编码语法

编码后元数据的语法如下：
对应说明如下：
  • metadata：由 <header>、<dictionary_size> 和 <dictionary> 组成。
  • header：1 个字节，编码方式为：
    • version：4 位版本 ID，当前必须始终为 1。
    • sorted_strings：1 位值，表示字典中的字符串是否已排序且互不重复。
    • offset_size_minus_one：2 位值，表示字典大小字段和偏移量字段各自使用多少字节。
    • dictionary_size：长度为 offset_size 字节的无符号小端序整数，表示字典中的字符串数量。
    • dictionary：由若干 <offset> 和 <bytes> 组成。
    • offset：长度为 offset_size 字节的无符号小端序整数，表示第 i 个字符串在 bytes 中的起始位置。列表中应包含 dictionary_size + 1 个值，最后一个值是 bytes 的总长度。
    • bytes：采用 UTF-8 编码的字典字符串值。
    注意事项：
    • 所有偏移量都相对于 bytes 数组的起始位置。
    • 第 i 个字符串的长度可以按以下方式计算：
      • 第一个字符串的偏移量始终为 0，因此从信息角度看它是冗余的。规范仍然保留该值，以简化内存中的处理。
      • offset_size_minus_one 表示每个 dictionary_size 和 offset 条目使用的字节数：
        • 值为 0：1 字节
        • 值为 1：2 字节
        • 值为 2：3 字节
        • 值为 3：4 字节
      • 如果 sorted_strings 为 1，字典中的字符串必须互不重复，并按字典序排序。
      • 如果 sorted_strings 为 0，读取器不能对字符串的顺序或唯一性作任何假设。

      值编码

      完整的 Variant 值编码首先包含 value_metadata 字节，然后包含零个或多个用于表示 val 的字节：

      基本类型

      basic_type 是一个 2 位值，表示 Variant 值属于哪一种基本类型。每个值的含义见基本类型表。

      值头部

      value_header 是一个 6 位值，用于保存更多类型信息。其格式取决于 basic_type。
      原始类型的值头部（basic_type=0）
      当 basic_type 为 0 时，value_header 是一个 6 位的 primitive_header。
      每个值的含义见原始类型表。
      短字符串的值头部（basic_type=1）
      当 basic_type 为 1 时，value_header 是一个 6 位的 short_string_header：
      short_string_header 的值就是字符串的长度。
      对象的值头部（basic_type=2）
      当 basic_type 为 2 时，value_header 由以下字段组成：
      • field_offset_size_minus_one
      • field_id_size_minus_one
      • is_large
      field_offset_size_minus_one 和 field_id_size_minus_one 都是 2 位值，分别表示字段偏移量和字段 ID 使用多少字节进行编码。
      实际字节数的计算方式如下：
      is_large 是一个 1 位值，表示使用多少字节来编码元素数量：
      • is_large=0：使用 1 个字节
      • is_large=1：使用 4 个字节
      第 5 位（标记为 R）是保留位，读取器必须忽略它。
      数组的值头部（basic_type=3）
      当 basic_type 为 3 时，value_header 由以下字段组成：
      • field_offset_size_minus_one
      • is_large
      field_offset_size_minus_one 是一个 2 位值，表示用于编码字段偏移量的字节数。
      实际字节数为：
      is_large 是一个 1 位值，表示元素数量字段使用多少字节：
      • is_large=0：使用 1 个字节
      • is_large=1：使用 4 个字节
      第 5～3 位（标记为 RRR）是保留位，读取器必须忽略它们。

      值数据

      value_data 的编码格式取决于 value_metadata 指定的类型。对于某些类型，value_data 的长度为零字节。
      原始类型的值数据（basic_type=0）
      当 basic_type 为 0 时，value_data 的格式取决于 primitive_header。
      每种原始类型的具体编码格式见原始类型表。
      短字符串的值数据（basic_type=1）
      当 basic_type 为 1 时，value_data 是表示该字符串的一系列 UTF-8 编码字节。
      对象的值数据（basic_type=2）
      当 basic_type 为 2 时，value_data 用于编码对象。其编码格式如下：
      对象的 value_data 首先是 num_elements。它是一个长度为 1 字节或 4 字节的无符号小端序整数，表示对象中的元素数量。
      num_elements 的字节数由 value_header 中的 is_large 指定。
      接下来是 field_id 列表。该列表包含 num_elements 个条目，每个 field_id 都是一个长度为 field_id_size 字节的无符号小端序整数。
      field_id 是元数据字典的索引。
      field_id 列表之后是 field_offset 列表。该列表包含 num_elements + 1 个条目，每个 field_offset 都是一个长度为 field_offset_size 字节的无符号小端序整数。
      field_offset 表示第 i 个 value 开始位置的字节偏移量。该偏移量相对于第一个 value 的第一个字节。
      最后一个 field_offset 指向最后一个 value 结束位置之后的第一个字节。
      field_offset 列表之后是 value 列表。它包含 num_elements 个 value 条目，每个条目都是一个编码后的 Variant 值。
      对于对象中的第 i 个键值对：
      • 键是由第 i 个 field_id 索引的元数据字典条目；
      • 值是从第 i 个 field_offset 所指向的字节位置开始的 Variant value。
      字段 ID 和字段偏移量必须按照元数据字典中对应字段名称的字典序排列。
      不过，实际的 value 条目不必按照任何特定顺序存放。这意味着 field_offset 的值不一定单调递增。
      例如，对于以下对象：
      field_id 列表必须按照字段名称的字典序排列：
      field_offset 列表必须是：
      但 value 列表本身可以采用任意顺序。
      数组的值数据（basic_type=3）
      当 basic_type 为 3 时，value_data 用于编码数组。其格式如下：
      数组的 value_data 首先是 num_elements。它是一个长度为 1 字节或 4 字节的无符号小端序整数，表示数组中的元素数量。
      num_elements 的字节数由 value_header 中的 is_large 指定。
      接下来是 field_offset 列表。该列表包含 num_elements + 1 个条目，每个 field_offset 都是一个长度为 field_offset_size 字节的无符号小端序整数。
      field_offset 表示第 i 个 value 的起始字节偏移量。该偏移量相对于第一个 value 的第一个字节。
      最后一个 field_offset 指向最后一个 value 的最后一个字节之后的位置。
      field_offset 列表之后是 value 列表。它包含 num_elements 个 value 条目，每个条目都是一个编码后的 Variant 值。
      对于数组中的第 i 个条目，其值是从第 i 个 field_offset 所指向位置开始的 Variant value。

      值编码语法

      编码后值的语法如下：
      对应说明如下：
      • value：由 <value_metadata> 和一个可选的 <value_data> 组成。
      • value_metadata：1 个字节，编码方式为：
        • basic_type：基本类型表中的 ID。<value_header> 必须采用与该基本类型对应的形式。
        • value_header：以下类型之一：
          • primitive_header：原始类型表中的 ID。<val> 必须是对应的 <primitive_val> 形式。
          • short_string_header：以字节为单位的无符号字符串长度，范围为 0～63。
          • object_header：
            • array_header：
              • value_data：原始值、短字符串值、对象值或数组值之一。
              • primitive_val：二进制表示形式见类型表。
              • short_string_val：UTF-8 编码的字节。
              • object_val：
                • array_val：
                  • num_elements：长度为 1 字节或 4 字节的无符号小端序整数，具体取决于 <object_header> 或 <array_header> 中的 is_large。
                  • field_id：长度为 1、2、3 或 4 字节的无符号小端序整数。其长度由 <object_header> 中的 field_id_size_minus_one 决定，用于索引字典。
                  • field_offset：长度为 1、2、3 或 4 字节的无符号小端序整数。其长度由 <object_header> 或 <array_header> 中的 field_offset_size_minus_one 决定，表示在 fields 内的字节偏移量。
                  • fields：零个或多个 <value>。
                  每个 value_data 都必须与 value_metadata 定义的类型相对应。
                  布尔类型和空值类型没有相应的 value_data，因为它们的类型本身已经定义了对应的值。
                  每个 array_val 和 object_val 必须为 field_offset 包含恰好 num_elements + 1 个值。
                  最后一个条目表示最后一个字段之后一个字节的位置，也就是所有字段的总字节数。所有偏移量都相对于对象或数组中第一个字段的第一个字节。
                  field_id_size_minus_one 和 field_offset_size_minus_one 表示每个字段 ID 或偏移量使用的字节数：
                  • 值为 0：1 字节
                  • 值为 1：2 字节
                  • 值为 2：3 字节
                  • 值为 3：4 字节
                  数组和对象的 is_large 标志用于表示元素数量使用 1 字节还是 4 字节编码。
                  当元素数量超过 255 时，is_large 必须设置为 true。
                  实现也可以为这些字段使用大于实际所需的编码宽度。例如，一个少于 256 个元素的对象也可以将 is_large 设置为 true。
                  “短字符串”基本类型是一种优化方式。对于长度小于 64 字节的字符串，可以直接把字符串长度编码进类型字节中。它在语义上与原始类型中的“字符串”完全相同。
                  Decimal 类型包含 Scale，但不包含 Precision。十进制值的隐含精度为：
                  当 val 为 0 时，精度为 1。
                  注意：Variant 二进制编码中的 Decimal 值使用小端序保存未缩放值。这与 Parquet 的 DECIMAL 逻辑类型不同：后者对于 BYTE_ARRAY 和 FIXED_LEN_BYTE_ARRAY 物理类型使用大端序补码编码。

                  编码类型

                  Variant 基本类型

                  基本类型
                  ID
                  说明
                  原始类型（Primitive）
                  0
                  原始类型之一
                  短字符串（Short string）
                  1
                  长度小于 64 字节的字符串
                  对象（Object）
                  2
                  由“字符串键、Variant 值”键值对组成的集合
                  数组（Array）
                  3
                  Variant 值组成的有序序列

                  Variant 原始类型

                  等价类别
                  Variant 物理类型
                  类型 ID
                  等价的 Parquet 类型
                  二进制格式
                  NullType
                  null
                  0
                  UNKNOWN
                  无
                  Boolean
                  boolean (True)
                  1
                  BOOLEAN
                  无
                  Boolean
                  boolean (False)
                  2
                  BOOLEAN
                  无
                  Exact Numeric
                  int8
                  3
                  INT(8, true)
                  1 字节
                  Exact Numeric
                  int16
                  4
                  INT(16, true)
                  2 字节，小端序
                  Exact Numeric
                  int32
                  5
                  INT(32, true)
                  4 字节，小端序
                  Exact Numeric
                  int64
                  6
                  INT(64, true)
                  8 字节，小端序
                  Double
                  double
                  7
                  DOUBLE
                  IEEE 小端序
                  Exact Numeric
                  decimal4
                  8
                  DECIMAL(precision, scale)
                  1 字节 Scale，范围为 [0, 38]；随后是小端序的未缩放值，参见 Decimal 表
                  Exact Numeric
                  decimal8
                  9
                  DECIMAL(precision, scale)
                  1 字节 Scale，范围为 [0, 38]；随后是小端序的未缩放值，参见 Decimal 表
                  Exact Numeric
                  decimal16
                  10
                  DECIMAL(precision, scale)
                  1 字节 Scale，范围为 [0, 38]；随后是小端序的未缩放值，参见 Decimal 表
                  Date
                  date
                  11
                  DATE
                  4 字节，小端序
                  Timestamp
                  timestamp
                  12
                  TIMESTAMP(isAdjustedToUTC=true, MICROS)
                  8 字节，小端序
                  TimestampNTZ
                  timestamp without time zone
                  13
                  TIMESTAMP(isAdjustedToUTC=false, MICROS)
                  8 字节，小端序
                  Float
                  float
                  14
                  FLOAT
                  IEEE 小端序
                  Binary
                  binary
                  15
                  BYTE_ARRAY
                  4 字节小端序长度，随后是数据字节
                  String
                  string
                  16
                  STRING
                  4 字节小端序长度，随后是 UTF-8 编码字节
                  TimeNTZ
                  time without time zone
                  17
                  TIME(isAdjustedToUTC=false, MICROS)
                  8 字节，小端序
                  Timestamp
                  timestamp with time zone
                  18
                  TIMESTAMP(isAdjustedToUTC=true, NANOS)
                  8 字节，小端序
                  TimestampNTZ
                  timestamp without time zone
                  19
                  TIMESTAMP(isAdjustedToUTC=false, NANOS)
                  8 字节，小端序
                  UUID
                  uuid
                  20
                  UUID
                  16 字节，大端序
                  “等价类别”列表示采用不同物理编码的类型在逻辑上是等价的。
                  例如，一个用户表达式在处理内容为 "hello" 的字符串时，无论该字符串使用短字符串优化，还是使用长字符串编码，都应该表现出相同的行为。
                  同样，一个用户表达式在处理值为 1 的 int8 时，其行为应该与处理 Scale 为 2、未缩放值为 100 的 decimal16 相同。

                  Decimal 表

                  Decimal 精度
                  Decimal 值类型
                  Variant 物理类型
                  1 <= precision <= 9
                  int32
                  decimal4
                  10 <= precision <= 18
                  int64
                  decimal8
                  19 <= precision <= 38
                  int128
                  decimal16
                  > 38
                  不支持
                  ㅤ

                  字符串值必须使用 UTF-8 编码

                  Variant 二进制格式中的所有字符串都必须使用 UTF-8 编码，包括：
                  • 字典中的键字符串；
                  • “短字符串”值；
                  • “长字符串”值。

                  对象字段 ID 的顺序和唯一性

                  对于对象，字段 ID 和偏移量必须按照对应字段名称的字典序排列。排序时，对 UTF-8 字节使用无符号字节顺序。
                  需要注意的是，字段值本身不必遵循该顺序。因此，偏移量不一定按照升序排列。
                  为了让 Variant 值的构造更加灵活，字段值不必与字段 ID 使用相同的顺序。
                  实现可以依赖字段 ID 的这种顺序来搜索字段名称。例如，可以结合元数据查询，对字段 ID 执行二分查找，从而找到指定名称的字段。
                  字段名称区分大小写。
                  每个对象中的字段名称必须唯一。无论两个同名字段是否使用不同的字典 ID，对象中包含两个相同名称的字段都属于错误。

                  版本与扩展

                  实现不需要解析元数据版本高于其所支持版本的 Variant 值。
                  不过，规范可以在不递增版本 ID 的情况下添加新类型。出现这种情况时，如果实现希望继续读取，它应当能够读取 Variant 值的其余部分。

                  拆分

                  当只需要读取少数字段时，把整个 Variant 对象保存在单列中可能导致较差的读取性能。
                  更好的方法是为各个字段创建独立的列。这种方式称为拆分（shredding）或子列化（subcolumnarization）。
                  [VariantShredding.md](VariantShredding.md) 描述了 Parquet 中的 Variant 拆分规范。
                  ]]>