datainfra前沿动态 · Vol.94

Trino 484 重写 JSON 类型体系并加上十余条破坏性变更；Databricks 把空间 SQL 搬上 Lakehouse//RT，50 并发下最高 38 倍；Apache Doris 4.1.5 的正确性修复集中在 Iceberg schema 演进与缓存失效的交叉地带；AWS 同日给 DynamoDB Streams 补上时间戳起点、给 MWAA 装上四个 Agent 技能包

本期聚焦四条把「藏在实现细节或人的经验里」的东西提升为可命名、可配置、可回放接口的动作：Trino 把 JSON 的构造、序列化与数值保真写成显式规则并接受十余条破坏性变更，Databricks 用第三方基准把实时空间查询的性能摆到桌面上，Apache Doris 把湖仓格式演进带来的正确性缺口逐条补上，AWS 则分别把流的起点与 Airflow 的运维知识参数化。

DataInfra Trino JSON SQL 引擎 Databricks Lakehouse//RT 空间计算 Apache Sedona Apache Doris Iceberg 倒排索引 AWS DynamoDB Streams MWAA Airflow Agent Skills

本期四条动态集中在 10 月 15 日，来自三个开源/厂商项目与一家云厂商，形状高度一致：把一件原本要靠读源码、问同事或翻部署文档才能确定的事，改成一个有名字、有参数、有边界的入口。Trino 484 用十余条破坏性变更换来了 JSON 类型的完整语义与 interval 的显式精度；Databricks 把空间 SQL 放进实时仓，并首次给出用 Apache Sedona 的 SpatialBench 跑出来的并发对比；Apache Doris 4.1.5 的更新清单里，正确性修复的密度高过新特性，且几乎全部落在外部湖仓格式与 schema 演进的交叉处；AWS 一边给 DynamoDB Streams 补上 AT_TIMESTAMP 起点，一边把 Airflow 的编写、调试、测试、升级封成四个可版本化的 Agent 技能包。四处动作都不是新增能力那么简单，而是为原本模糊的地方划了一条线。

Trino 484：JSON 类型被重写成一套有边界的语义，代价是十余条破坏性变更

事件概述

Trino 于 10 月 15 日发布 484 版本（GitHub 标签 484 于 10 月 16 日 00:08 UTC 打出，官方文档标注为 15 Oct 2026）。这是一个把注意力集中在「类型语义」上的版本：一个编号为 #30341 的改动集重写了 JSON 类型的构造、序列化与转换规则，另一个编号为 #6754 的改动集重定义了 interval 的精度与取值范围，此外还有一项涉及部署形态的缓存重构 #29184。三者都附带了明确的破坏性变更说明。

对使用者来说，这一版的升级成本明显高于常规月度版本：官方在「General」一节里列出的破坏性变更有十余条，其中八条直接挂在 JSON 上，四条挂在 interval 上，另有一条改掉了用户名的大小写处理。

技术解析

  • JSON 的新能力：新增 JSON value 构造函数与 JSON_SERIALIZE 函数，新增 json_scalar()；JSON_EXISTS、JSON_VALUE、JSON_QUERY、JSON_TABLE 现在接受 json 类型输入；JSON 类型支持 datetime 值，并支持从 json 到 date、time 的转换；JSON_VALUE 支持带 RETURNING 的数值、JSON path 算术与数组下标；JSON_OBJECT 允许传入 FORMAT JSON 参数并配合 WITH UNIQUE KEYS 强制嵌套对象的键唯一。
  • JSON 的破坏性变更：JSON_ARRAY、JSON_OBJECT 与 PASSING 子句中的数值参数不再被转成 JSON 字符串，而是保留为 JSON 数字；array、map、row 转 json 时保留数值类型与 decimal 的小数位；decimal 形式的 JSON 数字转 varchar 时保留十进制记法；json_parse() 与 JSON 字面量保留对象成员顺序与重复键；禁止构造嵌套超过 1024 层的数组与对象；拒绝含溢出指数记法或未配对 Unicode 代理转义的输入；JSON_SERIALIZE 成为保留关键字，同名标识符必须加引号；写成 json(x) 的调用必须加限定才能指向函数而非 JSON 构造函数。
  • interval 的重定义：支持显式的 leading-field precision 与最多 12 位小数秒；datetime 相减时可指定结果的字段范围与精度。对应的破坏性变更包括：日时间隔的上限收窄到约 292,000 年，相距更远的时间戳相减会报溢出；不允许抽取 interval 限定符中不存在的字段；抽取时返回完整的 leading field，hour(INTERVAL '36' HOUR) 返回 36；乘除结果按 interval 的字段范围截断。
  • 缓存从「每 catalog 一份」改成节点级共享：新增由节点上所有 catalog 共享的单一文件系统缓存，缓存管理器通过 cache-manager.config-files 配置，SPI 层新增 blob cache manager 供插件提供文件缓存能力。破坏性变更是 fs.cache.directories、fs.cache.max-sizes、fs.cache.max-disk-usage-percentages、fs.cache.ttl、fs.cache.page-size 这几项必须写在缓存管理器配置里，catalog 属性文件里只保留 fs.cache.enabled。
  • 通用层的其他条目：窗口帧规范支持 EXCLUDE 子句（#30226）；CREATE VIEW 支持 IF NOT EXISTS（#28076）；物化视图支持 COMMENT（#31279）；新增 query.max-output-data-size 配置项限制单条查询能产生的数据量（#30615）；CALL 调用的 procedure 支持返回 metrics（#30749）。破坏性方面，GRANT、REVOKE、SET AUTHORIZATION、CREATE SCHEMA 中不再把用户名转成小写，授权给 Alice 只对认证用户 Alice 生效（#30567）；retry-policy 为 TASK 时，spooled exchange 数据丢失后单次任务重试即失败，不再重试到上限（#31336）。
  • 连接器侧的共性动作：Delta Lake 连接器支持 Databricks 18 LTS、支持对带 deletion vector 的表执行 vacuum、新增 delta.object-store-layout.enabled 与同名表属性把数据文件写到哈希前缀目录下（#24199）；Iceberg 连接器支持用 ALTER MATERIALIZED VIEW EXECUTE 在物化视图上跑 optimize、expire_snapshots 等表过程（#21797）、支持 ALTER VIEW REFRESH 刷新视图定义（#30954）、新增 gc_enabled 表属性阻止快照过期与孤立文件清理删掉表文件（#31218）、支持用 sorted_by 自定义 optimize 的排序（#31274）；三个湖仓连接器都新增了 s3.checksum-algorithm 以选择 CRC32、CRC32C、SHA1 或 SHA256 校验和，并允许关掉 expect-continue 握手与 chunked encoding 来适配 S3 兼容存储（#31523、#30534、#31524）。Hive 连接器的默认存储格式改为 PARQUET，$file_modified_time 隐藏列改为返回 UTC。
  • 性能条目：boolean 值的读写（尤其是 ORC 与 Parquet）提速；字典编码数据的过滤与投影提速；date_trunc() 以 week 或 quarter 为单位的谓词提速；未关联的 EXISTS 子查询提速；多个条件用 AND 组合的过滤减少读取量；decimal 列上 sum() 配合移动窗口帧的窗口函数提速。

行业影响

这一版最值得注意的不是新增了多少函数，而是它愿意为语义的确定性付出破坏性变更的代价。JSON 在此前的实现里更像一个「尽力而为的容器」——数值可能被转成字符串、成员顺序可能被重排、嵌套深度没有上限；484 之后，这些行为的每一条都有明确的规则与明确的拒绝条件。代价是升级路径上必须做回归：任何依赖「数字被写成 JSON 字符串」这一旧行为的下游，或任何依赖旧 interval 抽取语义的报表，都会在升级后改变结果。

缓存架构的调整指向的是另一类现实问题。多 catalog 混合部署时，每个 catalog 各自持有一份文件缓存，会造成同一节点上缓存空间的重复占用与难以预测的内存/磁盘压力；改成节点级共享后，缓存变成一个可以被整体规划的资源。配置位置的迁移是这次调整的摩擦成本，但它换来的是「缓存到底占了多少」这个问题第一次有了单一答案。

连接器侧集中补齐 S3 兼容性与对象布局开关，说明 Trino 面对的部署环境里，非 AWS 原生对象存储与自建 S3 网关的占比已经高到必须显式支持。哈希前缀目录这一项尤其如此——它是对象存储在高并发前缀列举上的经典规避手段，此前多见于对象存储厂商的建议文档，现在被做成了表属性。

相关链接

Databricks 把空间 SQL 搬上 Lakehouse//RT：50 并发下最高 38 倍，基准用的是 Apache Sedona 的 SpatialBench

事件概述

Databricks 于 10 月 15 日宣布，Spatial SQL 与空间 join 现在可以在 Lakehouse//RT 上运行，目前为 Beta。官方给出的性能对比是：在 50 个并发用户下，Lakehouse//RT 比传统云数据仓库最高快 38 倍；单并发场景下，测试集里的每一条空间查询都更快，平均 3 倍、最高 20 倍；即使剔除提速幅度最大的那一条，平均仍有 3.5 倍以上。基准工具用的是 Apache Sedona 子项目 SpatialBench，数据可自行生成复现。

这篇博客把 Databricks 的空间能力整理成四根支柱：Lakehouse 负责长跑的空间 OLAP，Lakebase 负责空间 OLTP、应用与 Agent，Databricks Apps 负责专用界面，Lakehouse//RT 负责实时分析。空间 SQL 本身在今年早些时候已经正式可用，包含 GEOMETRY 数据类型、100 多个空间函数、高性能空间 join、AI/BI 地图以及 Delta Sharing 支持；GEOMETRY 与 GEOGRAPHY 类型也存在于 Apache Spark 中，并复用 Delta 与 Iceberg v3 底层的同一批 Parquet 文件。

技术解析

  • 三个数字来自两种并发：单用户场景下，SpatialBench 全套查询的平均提速约 3 倍、最高 20 倍；50 并发场景下，在「传统数据仓库还能跟得上」的那些查询上最高 38 倍。官方另给出一句口径更保守的表述——剔除最大的那一项提速后，平均提速仍超过 3.5 倍。
  • 基准可复现：SpatialBench 是 Apache Sedona 下的独立项目，官方给出了生成合成数据的快速上手文档，任何人可以按同样的数据与查询复跑。
  • 不需要改代码：在 Databricks SQL Serverless 上跑的空间查询可以不加改动地指向 Lakehouse//RT，也不需要新的 license；H3 网格体系的表达式同样在 Lakehouse//RT 上受支持。
  • 一个明确的使用建议：官方建议不要用 ST_GeomFromWKB 在查询时把 well-known binary 转成几何对象，而是把数据存成原生 GEOMETRY 列。只有用原生类型，查询优化与 file skipping 才能生效。博客里给出的示例是先 ALTER TABLE ... ADD COLUMN ... GEOMETRY(4326) 再回填，随后 ST_DWithin 这类距离判定直接作用在几何列上。
  • 能力边界：空间 SQL on Lakehouse//RT 当前是 Beta；对照物只描述为「传统云数据仓库」，没有点名具体产品与配置。博客 FAQ 里引用的 Lakehouse//RT 本身指标（延迟最低 10 ms、并发最高 12,000 QPS）来自preview 客户观测，是 6 月发布时的口径，不是本次基准的产物。

行业影响

这条发布削弱的是「为空间查询单开一套栈」的理由。过去一家在空间侧跑 OLAP、又要支撑实时位置应用的组织，常见的做法是额外维护一套以 PostGIS 为中心的系统来满足延迟要求。这套做法的成本不在软件本身，而在它带来的数据副本、同步链路与治理开销——同一份数据两个地方存、两套权限、两份口径。Lakehouse//RT 的卖点正是让实时查询直接落在受管的 Delta 与 Iceberg 表上，不需要复制。

值得注意的是基准的选择。厂商自造基准在数据库行业里长期缺乏可比性，这次用的是 Apache Sedona 的开源基准，且给出了合成数据生成方法，可比性与可证伪性都强过自测。仍然要打折扣的地方是对照物没有点名，也没有给出仓库的规格与规模，38 倍这个数字只能读作「在某些查询上、在某些配置下」，不能读作普遍结论。

把空间能力拆成四根支柱的讲法本身也反映了当下的产品结构：同一个语义对象（GEOMETRY 列）现在要一并服务长查询、点查、应用与 Agent 四种访问模式。引擎侧的收敛（同一批 Parquet 文件、同一套函数）与访问侧的发散（四种执行环境）是并行发生的。

相关链接

Apache Doris 4.1.5：正确性修复集中在 Iceberg schema 演进与缓存失效的交叉地带

事件概述

Apache Doris 于 10 月 15 日发布 4.1.5 版本（GitHub 标签 4.1.5-release，发布时间 2026-10-15T04:44 UTC），完整的变更清单维护在 issue #68889。这是一个补丁版本，但它的内容分布很能说明问题：新特性只有六项，改进与修复占了绝大部分，而修复中最密集的一块不在执行引擎，也不在存储层，落在「外部湖仓格式 × schema 演进 × 元数据缓存」这三者的交界处。

新特性里也有两条指向明确的场景：自定义倒排索引分析器开始支持 ik_smart 与 ik_max_word 两种分词器，Routine Load 作业与异步物化视图可以显式绑定到计算组。

技术解析

  • 湖仓写入与元数据：Hive 表支持静态分区覆盖（#68181）；批量访问 Hive Metastore 分区以减少元数据请求（#68197）；Iceberg 与 HDFS 文件改为延迟打开，并向下游传递 delete file 的大小（#67842）。
  • AI 与检索：自定义倒排索引分析器支持 ik_smart 与 ik_max_word 分词器（#68550）；新增 norms 索引属性与对应的 BE 配置项，可在 VARIANT 路径上跳过 norms（#68140）；AI RESOURCE 支持专用的 embedding 属性（#68384）。
  • 云与作业管理：Routine Load 作业与异步物化视图可通过 compute_group 属性显式绑定计算组（#67010）；FE 到 MetaService、BE 到 MetaService 的 RPC 限流支持 dry-run 模式（#67421、#67240）。
  • 外部湖仓读的正确性：修复 Iceberg 在 schema 演进之后的历史扫描、跨嵌套 schema 演进的 V2 读取，以及历史扫描的 schema 绑定（#67479、#67690、#68568）；Iceberg time travel 现在正确处理小数时间戳（#67704）；修复 VARIANT 子路径的规划失败并保留 schema 元数据中的可空性（#68121、#67856）；缺失的 snapshot 文件与非法 name mapping 改为报错，不再静默返回错误数据（#68143、#68003）；修复 schema 类型提升之后 equality-delete 的键匹配（#68383），并保留表演进为无分区布局时的文件分区规格（#68481）；Iceberg 的 execute 动作改为在对应的 catalog 认证上下文中执行（#67695）。
  • 缓存作用域与资源释放：Hive 文件缓存条目改为按表隔离，外部元数据变更后正确失效名称缓存与行数缓存（#68575、#67417、#68196）；缓存淘汰时释放 Iceberg FileIO 与 Hudi fsView 资源（#66913）。
  • Paimon 与 Hudi：保留 Paimon CAST 谓词语义、从快照元数据估算行数、元数据刷新时失效 SDK 缓存（#67933、#68155、#68238）。
  • 查询与函数层面的修复：修复 WinMagic 子查询改写引发的 join 放大（#67288）；窗口函数简化时保留滑动窗口行直到可安全淘汰（#67329、#67743）；TRY_CAST 在算术溢出时返回 NULL（#67985）；JSON 文本不再在字符串内的 U+0000 处被截断（#68735）；修复 IPv6 的奇数字节截断与 IPv4 CIDR 的零地址处理（#68414、#68420）；修复 conv 在基数转换时的 BIGINT 溢出（#68424）；topn、topn_array、topn_weighted 在 space_expand_rate 为 0 时的候选丢失（#68545）。

行业影响

一个成熟 OLAP 引擎的补丁版本里，正确性修复压过新特性并不罕见；罕见的是这批修复的高度集中——它们几乎全部发生在「读外部表」与「元数据缓存」重叠的位置。这正是湖仓架构把复杂度推到的地方：表不再是自己写的，schema 会被上游改，缓存必须知道什么时候该失效，而认证上下文要跟着 catalog 走。任何一个环节漏掉，症状都不是报错而是「返回一个看起来正常但错了的数」。Doris 这次把「缺失 snapshot 文件」从静默返回改成明确报错，就是把这类症状往可见方向挪了一步。

ik_smart 与 ik_max_word 进倒排索引分析器是一条值得单独看的条目。这两个分词器来自中文分词生态，被做成自定义分析器的一等选项，意味着中文检索场景在开源 OLAP 里是被当作正式需求对待的，而不是靠用户自己打补丁。与之配套的 norms 属性与 VARIANT 路径跳过 norms，则是在为半结构化列上的索引开销留一个开关——这同样是近期多家引擎在处理 VARIANT 时的共同动作。

Routine Load 与异步物化视图可以绑定计算组，反映的是存算分离之后资源隔离粒度的下沉。过去隔离通常做到「集群」或「资源组」这一层，现在往「单个作业」走。这一步的收益是可预测的作业性能，代价是调度器要管的约束变多，也因此要配套加上 RPC 限流的 dry-run 模式来降低误配风险。

相关链接

AWS 同日两项：DynamoDB Streams 补上时间戳起点，MWAA 装上四个 Agent 技能包

事件概述

10 月 15 日，AWS 在数据基础设施侧给出两条彼此独立但方向一致的更新。第一条是 Amazon DynamoDB Streams 支持基于时间戳的流处理：使用者可以指定一个时间点，从该时间点或其之后写入的第一条记录开始消费，对应的 shard iterator 类型是 AT_TIMESTAMP。在此之前只有两种起点——从最早保留的记录开始（最多 24 小时）或从开始消费之后新写入的记录开始。该能力可通过 DynamoDB Streams Kinesis adapter 与 KCL 配合使用，覆盖所有商业区域、AWS GovCloud（美国）区域与中国区域，除标准 GetRecords 请求费用外不额外收费。

第二条是 Amazon Managed Workflows for Apache Airflow（MWAA）接入 Agent Toolkit for AWS，提供四个内置的 AI agent 技能：authoring-mwaa-workflow、debugging-mwaa-workflow、testing-mwaa-workflow、upgrading-mwaa-environments。它们让支持 agent skills 的 AI 编码助手能用自然语言与 MWAA 交互，官方举的例子是用一段话描述 ETL 管线，由编写技能生成带任务依赖与错误处理的 DAG。四个技能对 MWAA Provisioned 与 MWAA Serverless 环境都适用，覆盖 MWAA 可用的全部区域。

技术解析

  • AT_TIMESTAMP 的语义：给定时点 T，从「T 时刻或其之后写入的第一条记录」开始。它不保证从 T 之前未消费的记录开始，也不保证跳过 T 之后的任何记录，作用是把起点从两个极端之一移到一个可指定的位置。
  • 官方列出的四类用例：中断之后恢复消费；为调试与审计按过去的某个时间点重放数据；跳过积压，从接近最新记录的一个近期时间戳续读；在做完时间点恢复（PITR）导出之后，从导出时间戳开始同步。
  • 与 PITR 的组合最值得注意：过去在 PITR 恢复之后要决定从哪儿继续消费流，只能在「重放最多 24 小时」和「接受丢失」之间选一个。现在导出时间戳可以直接作为流的起点，恢复与续流之间的接缝第一次有了明确的对齐方式。
  • MWAA 的四个技能覆盖的是一条管线的完整生命周期：编写、调试、测试、环境升级。它们以插件形式分发在 aws-data-analytics 插件里，装好之后由使用者的 AI 编码助手调用，不绑定特定厂商的助手。
  • 两者都不是新增算力：AT_TIMESTAMP 不增加吞吐，四个技能不改变 Airflow 的执行语义。它们改的是「人怎么告诉系统从哪儿开始」与「人怎么把运维经验传给工具」。

行业影响

两条更新做的是同一件事：把一项过去由人凭经验判断的操作，换成可声明的入口。流的起点从二选一变成时间戳参数；Airflow 的编写、调试、测试、升级从「老工程师脑子里的知识」变成四个可以放进仓库、可以版本化、可以评审的技能包。

时间戳回放补齐的是流处理里长期缺的一环。Kinesis Data Streams 早已有 AT_TIMESTAMP 类能力，DynamoDB Streams 直到现在才补上，意味着此前 DynamoDB 到下游的同步在恢复场景下只能在全量重放与接受丢失之间取舍。补齐之后，「重放最近两小时」这类操作不再需要自己维护位点台账。

Agent skills 这一形态从通用编码向托管数据服务扩散是近期更值得跟踪的动向。Anyscale 在 2026 年 4 月就为 Ray 发布了类似的技能包，MWAA 这次是同一思路在托管 Airflow 上的落地。它把「怎样正确使用某个托管服务」从文档检索变成了可执行资产，收益是新手与 Agent 都能少踩配置坑；代价是这份资产的正确性由服务方与使用者共同承担——技能包写错，错的不是一个建议，而是一份会被反复执行的 DAG。

相关链接

编者评

把四条放在一起看，10 月 15 日这天发生的事有一个共同的形状：原本要靠读源码、问同事或翻部署文档才能确定的东西，被改成了一个有名字、有参数、有边界的入口。Trino 把 JSON 的构造、序列化、数值保真、嵌套深度写成显式规则，把 interval 的精度与范围写成可声明的限定符，把文件缓存从「每个 catalog 各自一份」收成节点级的一份；Databricks 把实时空间查询的性能从厂商主张变成一份能用开源基准复跑的数字；Doris 把湖仓格式演进带来的静默错误逐条改成明确报错或明确修复；AWS 则分别把流的起点和 Airflow 的运维知识参数化。

四处的共同代价也一致：划线之后，原来模糊但省事的做法不再可用。Trino 484 的十余条破坏性变更意味着升级必须做回归，这是为语义确定性付的账；Lakehouse//RT 的 38 倍需要自己按 SpatialBench 的数据与查询复跑才能确认落在自己的查询上；Doris 把缺失 snapshot 从「返回错数据」改成「报错」，会让一部分原本能跑完的作业开始失败；Agent 技能包把运维知识固化之后，错的技能包会被反复执行。把隐性约束显式化的收益是能讨论、能测试、能追责，代价是必须先接受一批新的失败。

本期还需要交代几处没有单独立篇但值得记录的观察。Google Cloud 在 10 月 15 日的发布说明里有一条与迁移相关的小项：BigQuery 的 GoogleSQL 列别名已正式可用，但需要先显式启用，官方给出的理由之一是让 Snowflake 与 Teradata 的查询语法可以直接迁移；同日的另外三条分别是跨区域复制表正式可用、对话式分析代理的回答可导出为 PDF 或 CSV、Dataflow 的 Auto VM Selection 开始优先选择第四代 Compute Engine 机器系列并在不可用时回退到第二代。Databricks 同日还有两篇未成篇的博客，一篇讲其 AI Research 团队如何使用 AI Runtime，另一篇讲 Atlassian 如何在 Databricks 上搭建基于 OCSF 的安全数据湖仓。

关于中文来源的覆盖情况需要如实说明：阿里云、火山引擎等国内厂商的官方博客与产品更新页，本期仍然抓取不到可解析的条目列表，这已是连续第十三期。本期在国内生态侧改以开源项目的发布记录作为间接观察点——Apache Doris 于 10 月 15 日发布 4.1.5，是当日唯一有实质内容的国产开源数据系统更新；Apache Paimon（2.1.0，10 月 12 日）、StarRocks（3.5.21，8 月 31 日）、SeaTunnel（3.0.0，9 月 29 日）、Amoro、Kyuubi、Linkis、InLong 等项目的发布记录当日均无新版本。需要说明的是，这个观察点只能反映开源项目的节奏，国内闭源数据产品的更新动向仍然无法核实。

另有一处补记：DuckDB 在 10 月 13 日发布了一篇《What Is Inside an Iceberg Table?》，逐层拆解 Iceberg 表的文件结构。它不在本期的覆盖窗口内，此前也未被本专栏报道，列在这里供回溯。