datainfra前沿动态 · Vol.53

Amazon 收购 DuckLabs，DuckDB 归入 AWS 但保持 MIT 协议与独立基金会治理；Ray Data 用 Shuffle V2 把 shuffle 中间态从 actor 堆内存搬进 object store，TPC-H SF1000 q21 提速 53 倍；Delta Lake 4.4.0 与 AWS Glue 6.0 同时落地 VARIANT、地理空间与纳秒类型，开放表格式的类型系统开始收敛；Hologres V4.2.0 用 Liquid Table 让 shard 数从建表时的一锤定音变成可在线流动的配置

本期聚焦四条 DataInfra 动态：Amazon 于 8 月 26 日宣布签署最终协议收购 DuckDB 背后的阿姆斯特丹公司 DuckLabs，创始团队留任、项目继续以 MIT 协议在独立基金会下开源，AWS 同时披露 Amazon Quick 已用 DuckDB 处理超 25 亿次查询并将平均延迟降低 30%；Anyscale 在 8 月 25 日连发多篇文章，其中 Ray Data 的两项重构最值得关注——与 NVIDIA cuDF 团队合作的 GPU-Native Operators 让模糊去重流水线在 FineWeb 10BT 上取得 4 倍加速与 3.1 倍 TCO 改善，Shuffle V2 则把 shuffle 中间结果从长期存活 aggregator 的堆内存搬进 Ray object store，换来可溢写、可 lineage 重建、无资源长期预留的容错模型，TPC-H SF1000 上 q21 从 6300 秒压缩到 119 秒；开放表格式的类型系统出现罕见同步——Delta Lake 4.4.0（8 月 20 日）支持 Spark 4.2、SQL DDL 标识列与 Unity Catalog 表的生成列，AWS Glue 6.0（8 月 27 日）则在同一张 Iceberg v3 表里同时落地 GEOMETRY/GEOGRAPHY、TIMESTAMP_NTZ(9)、带自动 shredding 的 VARIANT 与 DEFAULT 列值；阿里云 Hologres V4.2.0 把 QE V2 执行引擎铺开到 Nested Loop Join、Lookup Join、SQE 外表直读等场景，并用 Liquid Table 将 reshard 从重建表的线性耗时操作变成秒级元数据切换。

DataInfra DuckDB DuckLabs AWS 收购 嵌入式分析 Ray Ray Data Anyscale Shuffle V2 cuDF RapidsMPF Rapids GPU 数据处理 Apache Iceberg Iceberg v3 VARIANT 地理空间 纳秒时间戳 AWS Glue Delta Lake Delta Lake 4.4.0 Apache Spark 4.2 标识列 Unity Catalog Hologres 阿里云 Liquid Table QE V2 开放表格式

本期追踪到四条 DataInfra 动态，横跨 8 月 18 日至 8 月 27 日，落点分别在产业格局、执行引擎、表格式与实时数仓四个层面，但它们共享同一条主线：数据基础设施正在同时完成一次「形态下沉」和一次「类型上浮」——引擎形态从”必须是一套远程集群”下沉为”可以是进程内的一个库”，而表格式的能力则从”只管 schema 和文件”上浮到”原生理解半结构化、时空与高精度时间”。Amazon 收购 DuckLabs 是这条主线最直白的注脚：Andy Warfield 在 All Things Distributed 上用一整篇文章论证单机硬件（m8g.48xlarge 相比 19 年前的 m1.xlarge 拥有约 50 倍的内存、核心与网络带宽）已经吞掉了当年催生 MapReduce 与 Spark 的物理约束，而 Agent 的交互模式——先小规模试探、再逐步收敛——恰好与 DuckDB 的”TB 级以下日常查询”设计前提高度重合。同周，Anyscale 把 Ray Data 的 shuffle 从”长期存活 aggregator 的堆内存”重构为”object store 中的普通 Ray object”，用一次架构决策同时换掉内存上限、不可重建状态与资源长期预留三块天花板。而真正值得放在一起看的是第三条：Delta Lake 4.4.0 与 AWS Glue 6.0 上的 Iceberg v3 在相隔一周内分别补齐了标识列/生成列与地理空间/纳秒/VARIANT/DEFAULT，两条独立的开放表格式路线首次在同一组数据类型上汇合。第四条里，Hologres V4.2.0 用 Liquid Table 把”改 shard 数”从随数据量线性增长的重建操作变成秒级元数据切换——这恰恰是对同一个问题的另一种回答：当物理约束松动，剩下的瓶颈就都是那些”建表时就得一锤定音”的静态决策。

Amazon 收购 DuckLabs：DuckDB 归入 AWS，但保持 MIT 协议与独立基金会治理

事件概述

2026 年 8 月 26 日，AWS 数据服务副总裁 Mai-Lan Tomsen Bukovec 在 AWS Big Data Blog 宣布：Amazon 已签署最终协议，收购总部位于阿姆斯特丹的 DuckLabs——开源分析型数据库 DuckDB 背后的公司。交易预计在 customary closing conditions 满足后很快完成。

公告中最关键的三条承诺是：Hannes Mühleisen 与 Mark Raasveldt 两位创始人将继续领导团队并主导开源项目的技术方向；DuckDB 项目继续由 DuckLabs 团队驱动、继续开源；继续由独立的非营利基金会（the Foundation）监督，并维持当前的 MIT 许可证。DuckDB 两位创始人最初在荷兰国家数学与计算机科学研究中心（CWI，也是 Python 的诞生地）开始该项目。

AWS 给出的战略叙事相当清晰：过去 20 年 AWS 的数据布局是从 S3 数据湖、EMR、Redshift 一路铺到 Athena、Glue、S3 Tables、S3 Vectors 与 Graviton 版 Redshift，覆盖的是”数百 TB 到 PB 级”；而 DuckDB 占据的是另一头——全球 90% 以上的数据查询量在 1 TB 以下。AWS 的表述是，要把”DuckDB 在 1TB 及以下日常查询上的超能力”与”S3 与 Redshift、Athena、EMR、Glue-ETL、SageMaker 的 EB 级企业级规模”组合起来。

值得注意的是，AWS 内部早就在用 DuckDB。公告披露：Amazon Quick 在 2025 年 10 月上线时，为了让自研 dashboarding 引擎提速，选择了 DuckDB 查询 S3 Tables 中的数据；截至公告时，Quick 已用这套含 DuckDB 集成与优化的自研查询引擎处理了超过 25 亿次查询，DuckDB 的集成与优化帮助 Quick 把平均查询延迟降低了 30%。外部客户案例方面，Allen Institute 科学计算执行总监 David Feng 表示，该机构自 2025 年起用 DuckDB 分析 TB 级科学数据，在 S3 上对神经生理与行为数据做实时质控与分析，“原本需要数分钟的查询现在不到一秒返回”。

技术解析

  • 为什么是现在——“物理条件变了”：同日 Werner Vogels 的 All Things Distributed 刊出 AWS 杰出工程师 Andy Warfield 的长文《DuckDB and the Changing Physics of Analytics》，给出了这笔收购的技术论证。核心论据是硬件与数据规模的剪刀差：19 年前 AWS 最强的 m1.xlarge 有 15 GB 内存、4 个虚拟核、约 1 Gb/s 网络；今天一台 m8g.48xlarge 拥有约 50 倍的内存、50 倍的核心、50 倍的网络带宽——单机的并行度与聚合 I/O 带宽已经超过很多人当年跑 Hadoop 和 Spark 的整个集群。而数据量的增长服从分布：最大数据集指数级膨胀，但那是尾部；多数数据集随”业务规模、客户数、一个人一天的银行交易笔数”这类人类尺度线性增长。
  • “库”这种形态的真正含义：Warfield 强调，DuckDB 以嵌入式库的形式存在并不意味着它必须待在客户端进程里，而是意味着它不必是一个位于线缆另一端的外部服务——于是同一个高效代码基可以被放置在软件栈的合适位置：应用进程内、Lambda 函数里、服务端引擎代码中，甚至编译成 WebAssembly 完整跑在浏览器标签页里（shell.duckdb.org）。他把 DuckDB 称为“结构化数据的 glibc”：一个精简、不起眼、无处不在、大量软件链接它但几乎没人需要想起它的依赖。
  • 为什么和 Agent 天然契合：AWS 博客给出的观察是，Agent 操作数据的方式很像人——它们会戳一戳、做实验、在小数据集上跑探索性分析，然后才决定真正要做什么。而 DuckDB 的向量化执行不需要重型编译器即可运行 SELECT * FROM table 这类简单语句，其”让日常 SQL 查询极快”的架构前提天然适配这种交互模式。
  • 治理边界：公告明确划出了三条不变——MIT 许可不变、独立基金会监督不变、DuckLabs 团队继续驱动项目。这与 Elastic、MongoDB、Redis 等公司改协议的历史形成对照，也说明 AWS 买的是团队与深度集成能力，而非闭源权利。

行业影响

这笔交易把”嵌入式分析引擎”从工具层的热门选择，直接抬升为云厂商数据栈的一等公民。对从业者有三点直接影响：其一，DuckDB 进入 AWS 服务的路径会显著变短——公告已明确表示将”继续投资 DuckDB 与 S3、Redshift、Athena、EMR、Glue-ETL、SageMaker 的深度集成”，Quick 之外，Athena 与 Glue 是最合理的下一站。其二，“该不该为这个查询起一个集群”会成为一条被重新审视的默认假设——当单机的网络与内存带宽已经超过当年集群，很多定时跑的中小规模 Spark 作业在成本上会开始说不通。其三，对 Snowflake、Databricks 与 ClickHouse 等以”服务端集群”形态为主的玩家，这是一个关于查询入口位置的竞争信号：如果分析的第一入口越来越是 Agent 和本地/边缘进程，那么延迟预算的构成就会改变。

需要保持观察的是治理的实际走向。MIT 协议 + 独立基金会的组合在短期内是强约束，但基金会与 AWS 之间的资源依赖是否会在 2-3 年后改变路线图优先级，是这笔交易真正的长期风险点。

相关链接

Ray Data 双引擎重构：Shuffle V2 把中间态搬进 object store，GPU-Native Operators 拿下 3.1 倍 TCO

事件概述

2026 年 8 月 25 日，Anyscale 集中发布了一批 Ray 生态文章（与 Ray Summit 同期），其中两篇构成 Ray Data 的一次实质性双引擎重构，均随 Ray 2.58 交付。

Shuffle V2（You-Cheng Lin、Yuanzhuo Yang）针对的是一个老痛点：shuffle 是 Ray Data 中无法流式处理的操作——groupby、join、按 key repartition 都必须把相同 key 的行聚到一起，因此它是流水线 OOM 和失败的主要来源。V1 的做法是维护一组长期存活的 aggregator actor，map task 把 shard 提交给对应 partition 的 aggregator，由其在堆内存中持有 shards 直到 shuffle 结束。原文对这一设计的评价很直接：“a job that ran fine at 100 GB falls over at 1 TB”。V2 的核心决策只有一句话——shuffle 中间结果不再累积在 aggregator 的堆内存里，而是作为普通 Ray object 物化进 object store。

GPU-Native Operators（Richard Liaw、Felix Cheung、Lee Yang）则是 Ray Data 与 NVIDIA cuDF 团队合作的产物，补齐了两块此前只能靠用户 UDF 自行调用的 GPU 能力：cuDF 作为 map_batches 的一等 batch format，以及基于 RapidsMPF 的 GPU 原生 shuffle。

技术解析

Shuffle V2：一次架构决策换掉四块天花板

  • 可溢写（Spilling replaces the memory ceiling）：shards 变成 object store 里的对象，内存压力大时会 spill 到磁盘，shuffle 中间结果不再被 RAM 封顶。
  • 可重建（Leveraging Ray Core’s lineage reconstruction）：V1 中一个 partition 只存在于累积它的 actor 内部，丢失一个 aggregator 就丢失它拥有的所有 partition 且不可恢复；V2 中丢失的 shard 可以通过重新执行产出它的 map task 来重建，原文结论是”losing any individual shard will not cause the entire job to fail”。
  • 不再预先固定资源（Reducer memory comes from measurement）：V1 的 aggregator 池大小来自对最初几个 input bundle 的采样，且 shuffle 开始后无法 resize；V2 中 map 和 reduce 都是普通 Ray task，按集群剩余资源调度，reducer 内存直接测量 partition shards 的实际大小。同时消除了”整个 shuffle 期间一直占用 num_aggregators × num_cpus 预留”的问题。
  • V2 解锁的三项优化：输入合并（block 缓冲到 shuffle_input_batch_bytes 默认 1 GiB 后合并成单个 map task，按 node 做 key 避免额外传输）、中间 shard 压缩（Arrow IPC buffer，默认 zstd，可选 lz4/none）、跨 shuffle 边界融合（reduce 下游紧邻的 map 被折叠进 reduce task，一次物化消失）、以及向量化聚合（把整个 block 交给 Arrow 原生 group-by，而非在 Python 中按 group 循环；已向量化 Count/Sum/Min/Max/Mean/MissingValuePercentage/ZeroPercentage/Unique/CountDistinct 共 9 种）。

性能数字（Ray Data release test suite，TPC-H SF1000，1 × m5.2xlarge head + 32 × m5.4xlarge worker，Ray 2.58）：

  • TPC-H q21：V1 6300 秒 → V2 仅架构改动（关闭向量化）2400 秒 → V2 完整（开启向量化）119 秒，端到端 53 倍；向量化聚合在 aggregate_groups 测试中单项带来超过 30 倍提升。
  • Joins：V1 因 aggregator 池在整个 shuffle 期间持有 CPU 预留、map 阶段只能竞争剩余资源而直接超时；V2 下四种 join 类型全部在约 320 秒内完成。
  • 压缩基准：对比无压缩，zstd（默认）减少溢写字节 91%、运行时间 26%；lz4 减少溢写字节 68%、运行时间 21%。选型建议是 IO-bound 用 zstd、CPU-bound 用 lz4、数据已压缩用 none。
  • 一个诚实的反面数据：在只启用架构、关闭向量化时，q1、q13、q15 反而比 V1 更慢（如 361s vs 240s、372s vs 272s），原因是上游 filter/projection 让实际参与 shuffle 的数据很小，V2 的 encode + object-store 往返开销超过了架构节省。开启向量化后，V2 在所有查询上都击败 V1。

启用方式（Ray 2.58+）：

from ray.data.context import DataContext, ShuffleStrategy
DataContext.get_current().shuffle_strategy = ShuffleStrategy.HASH_SHUFFLE_V2

即将到来的 Ray 2.59 会将其重命名为 SHUFFLE_V2（因不再局限于 hash 分区），HASH_SHUFFLE_V2 保留为别名。路线图还包括：sort() 与 random_shuffle() 迁移到 V2；依赖 Arrow 26.0.0 的增量 join（从一侧建 hash table、另一侧分批流式通过，把内存占用限制为 build side + 一个 batch）；以及磁盘 shuffle（Ray 2.59 目标）——map 输出直接写本地磁盘、每个 mapper 一个文件按 offset 索引，把 driver 需跟踪的对象数从 map_tasks × partitions 坍缩为每个 mapper 一个 handle，并通过每节点的 Arrow Flight server 按 byte range 批量读取。

GPU-Native Operators：cuDF batch format + RapidsMPF shuffle

  • map_batches 新增 batch_format="cudf"，UDF 直接拿到 cudf.DataFrame 而非 pandas DataFrame 或 Arrow table，省去用户手工做数据格式转换。此前 Ray Data 只有 Pandas、Numpy、PyArrow 三种原生 batch format。
  • GPU shuffle 基于 RapidsMPF，ranks 之间经 UCXX 直接通信，shuffled 数据走 RDMA 或 NVLink 等高性能传输，跳过 CPU 与 Ray object store。
  • 基准（FineWeb 10BT 数据集上的模糊去重流水线，2–8 节点；CPU 用 m8id.4xlarge @ $1.04416/小时，GPU 用 g6.4xlarge @ $1.3232/小时）：
    • MinHash 签名生成阶段（计算密集）：15.2×–15.7× 加速（2 节点 1899s → 125s；8 节点 519s → 33s）。
    • 分组阶段（shuffle 密集）：3.0×（2 节点）/ 2.4×（4 节点）/ 1.5×（8 节点）——原文坦率指出，由于 shuffle 开销随 GPU 数量增长，该数据集下 2 个 GPU 是最优点，8 GPU 时数据集太小无法吃满。
    • 端到端：2 节点 3718s → 939s（4.0×），成本 2.16→2.16 → 0.69，TCO 改善 3.1×；4 节点 TCO 改善 2.9×；8 节点 2.2×。

GPU shuffle 目前为实验特性。后续方向是 cuDF 与 RapidsMPF 之间的算子融合（避免阶段间无谓的 host-to-device 往返，让数据留在 GPU 内存中），以及让基于 preprocessor API 的特征工程流水线也能走 GPU 路径。

行业影响

这两项工作共同标记了 Ray Data 的一个定位转向：它不再只是”能调度 GPU 的数据加载器”，而是开始在系统层面原生理解 GPU 的内存层次与通信拓扑。Shuffle V2 的价值尤其超出 Ray 生态本身——它示范了一个通用模式：把中间状态从”活在计算进程里”搬到”活在可被调度器感知、可溢写、可重建的存储层里”，是把分布式数据处理的容错模型从”整体重试”降级为”局部重建”的关键一步。这与 Spark 的 shuffle service 外置化、Flink 的算子状态托管化是同一条思路的延续。

对做基础模型数据管线的团队，GPU-Native Operators 给出的信号更直接：数据策管（curation）阶段的去重、聚合正在从 CPU 集群迁移到 GPU 集群，而且 TCO 的改善幅度（3.1×）大于速度的改善幅度（4.0× 中扣掉硬件单价差），说明 GPU 在这类 shuffle + hash 密集负载上的性价比窗口已经打开。不过原文给出的边际收益递减（8 节点时只剩 1.5×）也提醒我们：GPU shuffle 不是”越多越好”，存在随通信开销上升的最优规模点，这是工程落地时需要实测的。

相关链接

开放表格式的类型系统开始收敛：Delta Lake 4.4.0 与 AWS Glue 6.0 上的 Iceberg v3

事件概述

8 月下旬出现了一次罕见的跨路线同步：Delta Lake 4.4.0（8 月 20 日发布）与 AWS Glue 6.0 对 Apache Iceberg v3 的支持（8 月 27 日博客）在相隔一周内，分别把开放表格式的类型系统向前推进了一大步，且推进的方向高度重合。

Delta Lake 4.4.0 的核心是把 Delta 全面对齐到 Spark 4.2 时代并向 Unity Catalog 进一步靠拢：Delta Spark、Delta Connect 与 Delta Sharing 支持 Apache Spark 4.2.0（同时继续支持 4.1.0 与 4.0.1，仅发 Scala 2.13 构件）；CREATE TABLE 支持 SQL DDL 中的标识列（GENERATED ALWAYS AS IDENTITY 与 GENERATED BY DEFAULT AS IDENTITY，可自定义起始值与步长）；通过 Unity Catalog 创建的表支持生成列（建表时保留生成列表达式，写入时用声明的表达式计算或校验生成值）；Delta Kernel 与实验性 Flink connector 可使用 UC Delta API 管理 catalog-managed 表；Delta Flink 实验性 connector 支持 Flink 2.0.2、2.1.3、2.2.1、2.3.0。此外还有更安全的并发写入（避免重复活动文件或丢失的 deletion-vector 更新）、减少对象存储 HEAD 请求、UniForm 支持原子化表初始化与改进的 Iceberg 转换正确性等。

AWS Glue 6.0（由 Apache Spark 4.1 驱动）则在一张 Iceberg v3 表里同时落地了四类新能力：原生地理空间类型 GEOMETRY(4326) / GEOGRAPHY(4326)、纳秒精度时间戳 TIMESTAMP_NTZ(9)、带自动 shredding 的 VARIANT 类型、以及 DEFAULT 列值。AWS 用”连接车辆车队监控”的示例管线把四者串在了一起。

技术解析

AWS Glue 6.0 上的 Iceberg v3 四类能力

  • 地理空间：GEOMETRY(4326) 使用平面模型，GEOGRAPHY(4326) 使用球面/大地模型，SRID 4326 对应 WGS 84。GPS 坐标可以存为原生空间对象而非拆成 latitude/longitude 两个 DOUBLE 列，并直接用 ST_Intersects 等空间谓词查询，无需外部空间库、无需关联单独的几何表。插入侧使用 ST_SetSrid(ST_GeomFromWKB(X'...'), 4326)。注意：该类型是唯一需要额外 Spark 配置的一项——spark.sql.geospatial.enabled=true；纳秒时间戳、VARIANT、DEFAULT 值均开箱即用。另外，Glue 6.0 可读写 GEOGRAPHY，但基于 GEOGRAPHY 的大地空间谓词目前取决于具体引擎。
  • 纳秒精度：TIMESTAMP_NTZ(9) 中 (9) 表示保留 9 位小数。示例给了两条相差仅 1 纳秒的事件（.123456789 与 .123456790）——在标准微秒精度下两者都会变成 .123456，相对顺序未定义；纳秒精度下可被正确区分与排序。这对车队规模下”大量事件落在同一微秒窗口”的去重与定序是刚需，也适用于交易、传感器融合、自动驾驶等亚微秒精度场景。
  • VARIANT + 自动 shredding：不同车辆类型上报完全不同的 JSON 模式（Van 报 fuel_pct/engine.rpm/route.eta_minutes，Robot 报 battery_pct/obstacle_distance_m/cameras.front，Bike 报踏频心率），全部落在同一列中，不需要 schema union、不需要拆表、不需要展平。查询侧用 variant_get(列名, '$.路径', '返回类型') 做任意深度的类型化提取，缺失路径返回 NULL。示例里一条 SQL 同时完成了按 vehicle_type 用 CASE 取能量指标、跨两层嵌套取 $.engine.temp_c、以及进入完全不同的结构取 $.deliveries.completed。
  • DEFAULT 列值：写入端省略字段时自动填充声明的默认值（vehicle_type STRING DEFAULT 'UNKNOWN'、speed_kmh DOUBLE DEFAULT 0.0、region STRING DEFAULT 'EMEA'）。这对多个生产者写入同一张表、但并非所有生产者都填充每一列的场景价值最大，避免了默认值逻辑在各写入端重复实现。
  • 配套的表属性：所有能力都要求 'format-version' = '3'；示例还用了 'write.delete.mode' = 'merge-on-read'，借助基于 Roaring Bitmaps 的 deletion vectors 实现快速行级更正，而不是不断累积 positional delete files。
  • 参考架构是冷热双路径：热路径由 Spark Real-Time Mode（RTM） 作业从 Amazon MSK 读取遥测、用空间谓词评估地理围栏违规，在毫秒级把告警路由到下游 Kafka topic；冷路径由微批作业读同一 topic，以秒级延迟写入 Iceberg v3 表并完成 GEOMETRY / TIMESTAMP_NTZ(9) / VARIANT 转换与 DEFAULT 应用；批处理层直接用 Glue 作业读该表做分析。

Delta Lake 4.4.0 的另一个方向：把”表该长什么样”的声明权交给 SQL 与 Catalog

如果说 Glue 6.0 / Iceberg v3 这一侧的重点是类型表达能力，Delta 4.4.0 的重点则是把企业级表语义下沉到 SQL DDL 与 Catalog 层：标识列让” surrogate key 由谁生成”从 ETL 代码回到建表语句；生成列在 UC 托管表上被保留与校验，意味着派生值的不变量由 Catalog 与引擎共同保证，而不是靠写入端自觉遵守；而 UC Delta API 从 Spark 侧（4.3.0 引入、默认启用）进一步扩展到 Kernel 与 Flink connector，说明 Delta 正在把”catalog-managed 表”确立为跨引擎的默认形态。

行业影响

这两条路线在一周内的并行推进，指向开放表格式竞争的下一阶段：决胜点正在从”谁的文件布局与提交协议更优”转向”谁能原生表达业务数据的形状”。过去十年，表格式行业的三个共识（schema evolution、隐藏分区、时间旅行）已经解决的都是”数据与元数据的组织问题”；而 VARIANT、地理空间、纳秒时间戳、DEFAULT 值、标识列、生成列解决的是另一个层次的问题——让表格式直接承载业务语义，从而消灭表外的一层预处理代码。

一个值得注意的收敛信号是 VARIANT 已同时出现在三条路线上：Iceberg v3 的 VARIANT 类型（Iceberg 官方博客 8 月 12 日专门发文解释，Parquet 已定义其二进制编码，Iceberg 在其之上增加了 schema、文件、快照与统计层面的约定，shredding 目前仅在 Parquet 可用）、Delta Kernel 在 4.2.0 中让 Variant 类型 GA 并在 4.4.0 中继续增强、以及 DuckDB v2.0 把 VARIANT 作为一等公民。当 Spark、Flink、DuckDB、Trino 都能用同一套 variant_get 语义读同一份 Parquet，“半结构化数据进湖仓”就不再需要为每个来源建一套展平管线。

需要提醒的落地约束有两条：一是 Iceberg v3 的类型是引擎能力而非纯格式能力——GEOGRAPHY 的空间谓词目前仍取决于具体引擎，跨引擎可移植性需要实测；二是 Delta UniForm 的兼容性存在版本错位：delta-iceberg_2.13 仅支持 Spark 4.1，不与 Spark 4.2 兼容，而 Delta Spark 主体已经支持 4.2——在规划升级时序时需要把 UniForm 单独考虑。

相关链接

阿里云 Hologres V4.2.0：QE V2 全面铺开，Liquid Table 让 shard 数从静态决策变成在线配置

事件概述

阿里云实时数仓 Hologres V4.2.0 发布（官方文档更新时间 2026-08-18），是本期唯一的中国厂商动态，也是四条里”最贴近单机引擎工程细节”的一条。这个版本在查询优化、数据摄入、AI 与多模态检索、存储引擎四个方向同时推进，其中最值得 DataInfra 从业者关注的有两处：查询引擎 V2（QE V2）的场景覆盖大幅扩展，以及 Liquid Table 让表的 shard 数可以在线变更。

Hologres 中 Table Group（TG）决定一张表的 shard 数，shard 数直接决定查询与写入的并行度——过少形成瓶颈，过多带来额外调度与资源开销。但实践中存在根本性难题：业务在建表时往往无法准确预估未来数据量。过去扩 shard 需要走 rebuild 路径——新建目标分布再把原表数据重新导入，对大表而言耗时随数据量线性增长。

技术解析

Liquid Table：把”改分布”与”搬历史数据”解耦

核心思路是元数据先切换，数据文件不动：reshard 时系统不同步重写历史文件，而是先完成 TG 与 shard 布局的元数据切换，让新写入立即进入新分布；随后后台按用户配置逐步将旧布局文件重排为新布局文件，不阻塞业务。因此用户感知到的生效时间取决于元数据切换（秒级）而非表的大小。

-- 创建目标 Table Group，决定新的 shard 数
CALL hg_create_table_group('tg_128', 128);
-- 一行 ALTER 完成在线扩容
ALTER TABLE public.orders SET (table_group = 'tg_128');
-- 可选：配置后台数据重组织窗口
ALTER TABLE public.orders SET (
  liquid_table_enable_data_reorganization = true,
  liquid_table_reorganization_partition_window = '3 day'
);

官方说明的边界是：ALTER 秒级返回，新写入与新查询立即使用新分布，修改期间写入请求延迟可能升高但不会失败，读延迟不受影响；降级到 V4.1 前需删除所有 Liquid Table。

QE V2 的场景扩展与执行层微优化

V4.2 把自 3.1 版本上线的 QE V2 执行引擎铺到了更多场景：Nested Loop Join、两阶段 Broadcast、Lookup Join、SQE（外表直读）、自适应 Bulkload DOP。同时新增了一批 CTE 计划改写规则与执行层复用机制，给出了相当具体的数字：

  • Scan Filter 复用：Scan 算子执行过滤时就地复用 Filter 减少内存分配与计算开销，5%–20% 过滤率下性能提升超过 100%，50% 过滤率下提升超过 200%（GUC hg_experimental_qe_v2_enable_reuse_filter，默认开启）。
  • Fragment Instance 复用：消费完一个 split 后重置状态继续消费下一个，而非销毁重建；多文件场景下内存成本为 0，CPU 成本仅为新建的 41.8%（GUC hg_experimental_qe_v2_enable_reuse_fragment_instance，默认开启）。
  • 文件内并行扫描：单个 ORC 文件按 split_size_mb 切成多个 sub-split 由多个 NiagaraScan 并发读取，解决大文件下标量扫描退化为单文件单并发的问题（GUC hg_experimental_enable_parallel_file_scan，默认关闭）。
  • 向量 TopK Scan 改写：解决”向量查询偏好大文件”与”标量 OLAP 查询偏好小文件”这组矛盾诉求，通过计划改写让两者在大文件场景下各取所需。
  • 其他改写：Cross Join 支持 Runtime Filter（把标量子查询的聚合结果下推给 probe 端大表，在扫描阶段直接过滤行与 RowGroup）、重复 Project 下推、重复模式自动抽取为 CTE、聚合下推进 CTE producer、shuffle 下推与合并（多层 hash shuffle 共享前缀时只在最底层做一次）、join order 的 scale_factor 调整新策略。此外超过 300 个 PQE 函数（含常用 JSON/JSONB 函数）迁移到新执行框架并可下推到 HQE。

数据湖侧与 AI 侧

  • Paimon FileSystem Catalog 支持：简化数据湖表管理，并支持本地数据中心与云之间的数据同步等混合云场景。
  • Paimon blob 类型读写：配合 DLF，Paimon 的 blob 类型映射到 PostgreSQL 生态的 bytea，使 AI 函数可以直接处理存为 Paimon blob 的多模态数据；ai_embed 函数相应支持 BYTEA 与 Paimon blob 输入，可直接对二进制数据做 embedding，用于多模态检索与以图搜图。
  • 数据湖查询引擎路径合并：HiveQE 与 FSE 两条路径合并，查询效率提升超过 30%。
  • AI 函数接入 Model Studio：支持 LLM、LLM-VL、embedding、qwen-vl-ocr、qwen-mt 系列，覆盖 LLM 推理、文本 embedding、视觉理解、OCR、翻译；新增语音转文字函数 AI_TRANSCRIBE；全文检索新增模糊匹配与检索期分词器参数，索引格式改为多 segment（低命中率场景检索性能在特定情况下快 3 倍以上，拼音分词器吞吐提升 25%–150%）。
  • 其他：DECIMAL 精度从 38 位扩展到 76 位（支持 DECIMAL(76, 38)，满足财务高精度计算，但不可作为 distribution key / cluster key / partition key）；Dynamic Table 增量模式支持 TopN 处理；新增 cron job 定时调度能力；逻辑分区表 GA；Serverless 场景下逻辑分区表改用分区级锁降低锁竞争；HBO 准入阈值从 20 秒降到 1 秒以覆盖更多查询。

行业影响

Hologres V4.2 最值得注意的不是单点性能，而是它体现的两个工程取向。

其一，“把静态决策变成在线配置”正在成为实时数仓的标配能力。Liquid Table 与同日发布的 AWS MSK 原位 ZooKeeper→KRaft 升级（8 月 26 日，无需新建集群、无需数据迁移，走熟悉的版本升级流程）在精神上完全一致：它们都在消除”某件事必须在系统建立之初就一次性决定、之后想改就得推倒重来”这类运维债。对数据平台团队来说，这类能力的价值往往超过同等幅度的性能提升——因为它买断的是未来的试错权。

其二，数据湖与 AI 的耦合方式正在从”把数据搬到 AI 能读的地方”转向”让 AI 函数直接读湖里的二进制”。Hologres V4.2 的 Paimon blob 读写 + ai_embed 支持 BYTEA 输入，与本期 Ray Data 的 GPU-Native Operators、Iceberg/Delta 的 VARIANT 化，是三个不同层次上对同一件事的回应：多模态与半结构化数据正在成为数据基础设施的一等负载，而不是需要先被 ETL 成结构化表格的”原材料”。当 blob 与 VARIANT 都能被原生存储、原生索引、原生做向量检索，“数据湖 → 特征工程 → 模型训练”这条链路中间那层转换代码会持续变薄。

相关链接

编者评

把这四条放在一起，最清晰的线索是“位置”与”形状”这两件事正在同时被重新定义。

位置问题上，Amazon 收购 DuckLabs 与 Ray Data 的 GPU 化看似方向相反——一个把计算往进程内收，一个把计算往 GPU 和网络拓扑里推——但它们的判断依据是同一个：硬件的物理约束已经改变，因此软件必须重新回答”计算应该发生在哪里”。Warfield 给出的剪刀差（单机 50 倍增长 vs 数据集的幂律分布）解释了前者；Ray Data 用 15 倍加速的 MinHash 与 3.1 倍 TCO 证明的则是后者——对 hash 密集、shuffle 密集负载，GPU 的通信栈（NVLink/RDMA）本身就成了新的性能来源。二者并不冲突：未来的数据栈大概率是”TB 级以下就地算、TB 级以上按数据形状选 CPU 或 GPU 集群”，而不是一条路径通吃。

形状问题上，Iceberg v3 与 Delta 4.4.0 的同步推进说明表格式竞争已经越过”元数据正确性”阶段，进入”类型表达能力”阶段。VARIANT 同时出现在 Iceberg、Delta 与 DuckDB v2.0 三条路线上尤其值得关注——这意味着半结构化数据进湖仓的展平管线可能在两三年内大幅萎缩。而 Hologres 的 Paimon blob 支持则从另一侧逼近同一目标：不是把多模态数据结构化后再入库，而是让库直接理解二进制并在其上做 embedding。

最后一个容易被忽略但可能最有长期价值的信号，是本期反复出现的**“解除一锤定音”主题：Shuffle V2 解除了”shuffle 前必须猜对 aggregator 池大小”，Liquid Table 解除了”建表时必须猜对 shard 数”，MSK 原位 KRaft 升级解除了”建集群时必须选对元数据模式”，Delta 4.4.0 的生成列则解除了”派生值的不变量只能靠写入端自觉遵守”。在硬件红利足以掩盖大量低效的年代，这些静态决策的代价并不显眼；而当竞争焦点转向”业务变化的速度能否快过平台调整的速度”**时，能否把一次性决策改造成可在线调整的配置，就成了区分平台代际的关键。DataInfra 的下一个分水岭，可能不在于谁算得更快，而在于谁更少地强迫用户在第一天就把话说死。