Apache Flink 2.3.0携15项FLIP全面演进SQL与云原生S3；Ray Data 2.56记忆感知执行终结OOM；AWS Redshift跨仓库DDL与BI仪表板冷启动25.7x加速；BigQuery Conversational Analytics GA开启代理式分析时代

第二十三期追踪到DataInfra领域四条重要动态：6月25日Apache Flink 2.3.0发布——15项FLIP（FLIP-555原生S3文件系统/基于AWS SDK v2完全替代Hadoop依赖/平均吞吐提升2.17倍/检查点1.85x加速/小状态4.58x加速/FLIP-564 FROM_CHANGELOG与TO_CHANGELOG SQL算子支持Changelog语义/FLIP-550/557物化表DDL/FLIP-339自适应分区选择/状态访问性能优化/通用ZK HA/检查点失败恢复/Flink Agents 0.3.0预览版），SQL算子首次支持Changelog语义——流处理SQL从”批式查询”走向”真正的流原语”；6月30日Ray Data 2.56发布——记忆感知执行（Memory-Aware Execution）+PyArrow block格式统一（移除Pandas/Arrow混用）+取消预算控制（Cancel Budgeting），OOM异常从300+降为0、95分位端到端执行时间从1055s降为447s、对象存储峰值降低41%，分布式数据预处理从”手动调内存”走向”运行时自适应”；6月26日Trino 482发布——“Summer of Grammar”填补SQL标准空白（BETWEEN SYMMETRIC/IS [NOT] TRUE|FALSE|UNKNOWN谓词/UNIQUE与MATCH谓词/命名参数/OVERLAY函数/正则函数REGEXP_COUNT_LIKE/LIKE谓词使用列引用），char→varchar转换变更为破坏性变更（静默截断改为类型转换异常）——SQL方言从”方言”走向”标准”；6月29日AWS Redshift发布跨仓库多仓库功能——远程物化视图（MV）操作（CREATE/DROP/REFRESH/ALTER/METADATA）、远程表DDL（ALTER TABLE ALTER DISTSTYLE/APPEND）、并发扩展（Concurrency Scaling）覆盖zero-ETL/auto-copy/COPY，BI仪表板冷查询编译从4.3s降为170ms（25.7倍加速）、价格性能提升8.3倍——数据仓库从”单仓资源池化”走向”多仓协同”。同期Google Cloud BigQuery Conversational Analytics于7月1日GA——自然语言查询走代理式推理+多步骤规划+SQL生成+自动可视化+Open Knowledge Format（OKF）即插即用，分析师直接以自然语言提问，BigQuery自动规划查询计划、生成SQL、生成可视化——数据分析从”人写SQL”走向”代理式分析”。四条动态共同指向数据基础设施的”协议标准化+代理化执行”主线：Flink 2.3.0标准化流处理SQL与S3协议（消除Hadoop/SQL方言碎片化），Ray Data 2.56标准化分布式数据预处理的执行抽象（消除OOM/手动调优），Trino 482标准化SQL方言（消除方言差异），Redshift多仓库标准化数据仓库协同（消除单仓资源上限），BigQuery Conversational Analytics标准化代理式分析（消除SQL人工编写）。

Apache Flink 2.3.0：15项FLIP全面演进SQL与云原生S3，从流处理框架到流处理协议栈

事件概述

6月25日，Apache Flink 2.3.0正式发布——这是继Vol.22的Databricks DAIS 2026、Vol.21的AWS EMR Spark 4.0后，本周最重大的开源数据基础设施版本发布。Flink 2.3.0带来15项FLIP（Apache Flink Improvement Proposals），覆盖云原生存储、SQL引擎、状态管理、HA、Agent能力五大维度。核心新功能包括：（1）FLIP-555原生S3文件系统（flink-s3-fs-native）——基于AWS SDK v2完全替代Hadoop S3A，平均吞吐提升2.17倍、检查点1.85倍加速、小状态（<1GB）4.58倍加速；（2）FLIP-564 FROM_CHANGELOG/TO_CHANGELOG SQL算子——首次在SQL层面支持Changelog语义，让流处理SQL可以表达”上一个版本到当前版本的变更”；（3）FLIP-550/557物化表DDL——通过SQL直接管理物化表（创建、刷新、查询），让Flink的流表二象性在SQL层落地；（4）FLIP-339自适应分区选择——根据运行时统计自动调整分区数，消除手动调优；（5）状态访问性能优化、通用ZK HA、检查点失败恢复、Savepoint/Checkpoint格式优化。同期Flink Agents 0.3.0作为预览版发布——这是Apache Flink 2.3.0中面向AI代理场景的关键能力。

技术解析

• FLIP-555原生S3文件系统：Hadoop依赖的彻底解耦：此前Flink通过Hadoop FileSystem抽象访问S3，具体实现依赖Hadoop S3A连接器——这带来三个问题：（1）Hadoop版本依赖管理复杂（Hadoop 2.x/3.x升级时S3A API变动需要适配）；（2）性能损耗（Hadoop S3A的JVM序列化/反序列化开销）；（3）功能受限（部分AWS S3新功能如S3 Express One Zone、Directory Buckets无法通过Hadoop S3A使用）。FLIP-555将S3访问从Hadoop抽象中解耦，构建原生的flink-s3-fs-native实现——基于AWS SDK v2，直接使用S3 API，无Hadoop依赖。性能基准测试显示：在标准对象存储基准上，平均吞吐提升2.17倍（最高3.5倍），检查点写入时间降低1.85倍（从约100秒降为约54秒），小状态场景（<1GB）提升4.58倍。AWS SDK v2的底层使用C实现（CRT库）也带来CPU效率提升。此外S3 Express One Zone和Directory Buckets的支持让Flink可以在低延迟存储上运行流处理。

• FLIP-564 FROM_CHANGELOG/TO_CHANGELOG SQL算子：流处理SQL的Changelog原语：传统SQL是批式查询——查询看到的是表在某个时间点的快照。但流处理中数据持续变化（INSERT/UPDATE/DELETE），流处理SQL需要表达”基于变更”的查询（如”最新值”查询）。此前Flink SQL通过Temporal Join、Top-N、MATCH_RECOGNIZE等方式间接实现，但缺乏统一的Changelog原语。FLIP-564引入两个新SQL算子：FROM_CHANGELOG（从Changelog数据流构建物化视图）和TO_CHANGELOG（将物化视图转为Changelog流）。这让流处理SQL可以表达”读取一个表的变更日志”、“查询两个版本的差异”、“将查询结果发布为变更流”等高级模式——SQL从”批式查询”走向”真正的流原语”。

• FLIP-550/557物化表DDL：流批统一的SQL入口：Flink的”流表二象性”是指同一份数据既是流（持续变更）也是表（快照查询）。此前Flink通过Dynamic Table概念在内部实现流表转换，但缺少SQL层的物化表管理。FLIP-550/557引入物化表DDL（Data Definition Language）——通过CREATE MATERIALIZED TABLE语句创建物化表，REFRESH MATERIALIZED TABLE触发刷新，SELECT查询物化表。物化表可以是流模式（基于CDC持续刷新）或批模式（定时全量刷新）。这与Vol.22报道的Delta Lake 4.3的UniForm流式CDF和Vol.13报道的Delta Catalog-Managed Tables思路相似——都是通过统一入口管理流批数据，但Flink在SQL层实现，Delta在表格式层实现。

• FLIP-339自适应分区选择：自动消除手动调优：此前Flink用户需要根据数据量手动设置分区数（env.setParallelism()），分区数过多导致任务调度开销大，分区数过少导致单个任务处理数据过多OOM。FLIP-339引入自适应分区选择——根据运行时统计（输入数据量、可用slot、状态大小）动态调整分区数，目标是最小化端到端执行时间。这与Spark的Adaptive Query Execution（AQE）功能类似但更早——AQE在Spark 3.x引入，Flink 2.3.0引入自适应分区选择。

• Flink Agents 0.3.0：面向AI代理的流处理扩展：Flink Agents 0.3.0作为Flink 2.3.0的预览版发布——Flink Agents是Flink的AI代理扩展，让用户可以在Flink流处理管道中调用LLM、使用外部工具、维护Agent状态。Flink Agents的核心是”Event-driven Agent”——每个事件（消息、数据、信号）触发Agent推理，Agent根据当前状态和事件决定下一步行动。Flink Agents利用Flink的状态管理提供Agent的记忆能力，利用Flink的事件时间提供Agent的时间感知能力，利用Flink的检查点提供Agent的容错能力。这与Vol.17报道的阿里云LoongSuite GenAI SemConv（Agent调用链观测）、Vol.15报道的Databricks Genie Agents（企业数据上下文代理）、Vol.19报道的华为云Agentic Infra（Token工厂）形成AI代理基础设施的四象限：Flink Agents提供流式Agent运行时，LoongSuite提供Agent可观测性，Genie Agents提供企业数据上下文代理，华为云提供Token工厂算力。

行业影响

Apache Flink 2.3.0的深层意义不是”又一个Flink版本更新”，而是Flink从”流处理框架”走向”流处理协议栈”——通过标准化SQL方言、S3协议、状态协议、HA协议，让Flink的不同能力可以独立演进、跨实现兼容。

FLIP-555的Hadoop解耦是这一范式转变的具象化：Hadoop是2006年设计的批处理抽象，S3是2006年发布的云对象存储——两者是不同代际的技术。Flink之前必须通过Hadoop FileSystem抽象访问S3，意味着Flink无法直接使用S3的现代特性（S3 Express One Zone、Directory Buckets、智能分层），也无法摆脱Hadoop的版本依赖包袱。FLIP-555将S3作为一等公民纳入Flink，意味着Flink开始”云原生”——不再被Hadoop的历史包袱约束。Ray Data 2.56（本期）做的是同样的事：将数据预处理的执行抽象从Python Pandas/Arrow混用统一为PyArrow blocks。

FLIP-564的Changelog SQL算子是另一个范式转变：流处理的核心是Changelog（变更流），但传统SQL只支持快照查询。此前Flink用户必须用DataStream API才能访问Changelog，SQL层面只能间接表达。FLIP-564在SQL层引入Changelog原语，意味着SQL用户可以像写批式SQL一样写流式SQL——这是SQL从”查询语言”走向”流处理协议”的标志。BigQuery Conversational Analytics（本期）做的是反方向的事：让AI代理生成SQL——但底层依然是Changelog vs Snapshot的协议层转换。

将本期与Vol.20的Apache Polaris（Iceberg REST Catalog开放规范）相比，Flink 2.3.0的”协议化”路径与Iceberg REST Catalog的”协议化”路径异曲同工：Iceberg REST Catalog让任何目录实现可以服务Iceberg表，Flink 2.3.0让任何存储后端可以服务流处理数据。两者都通过”标准化协议”打破厂商锁定——Iceberg打破目录锁定（Unity Catalog vs Polaris vs Gravitino），Flink 2.3.0打破Hadoop锁定（让S3成为一等公民）。当数据基础设施的核心组件都开始协议化时，开放生态的护城河不再是”我有什么独家技术”，而是”我的协议有多标准”。

相关链接

• Apache Flink 2.3.0 Release Announcement
• FLIP-555: Native S3 FileSystem
• FLIP-564: FROM_CHANGELOG / TO_CHANGELOG SQL Operators
• FLIP-339: Adaptive Partition Selection
• Flink Agents 0.3.0 Documentation

---

Ray Data 2.56：记忆感知执行终结OOM，分布式数据预处理从手动调优走向运行时自适应

事件概述

6月30日，Anyscale发布Ray Data 2.56——这是继Vol.9报道Ray Data 2.50（Reactive Execution）后，Ray Data最重要的版本之一。Ray Data 2.56带来三个核心改进：（1）记忆感知执行（Memory-Aware Execution）——根据集群可用内存和对象存储容量动态调整执行参数；（2）PyArrow block格式统一——彻底移除Pandas block与Arrow block混用，所有block统一为PyArrow格式；（3）取消预算控制（Cancel Budgeting）——优雅取消长时间运行的任务，释放资源避免浪费。性能数据亮眼：在Anyscale内部基准测试中，OOM异常从300+降为0，95分位端到端执行时间从1055秒降为447秒（57%加速），对象存储峰值降低41%。这意味着Ray Data在不变更用户代码的情况下，自动消除了最常见的分布式数据预处理问题——内存溢出。

技术解析

• 记忆感知执行：从”预设内存”到”自适应内存”：此前Ray Data要求用户预设内存参数（DataContext.target_max_block_size、max_concurrent_tasks_per_reader等），参数设置不当会导致两类问题：（1）参数过小导致并发度不足，浪费集群资源；（2）参数过大导致OOM（Out-of-Memory），任务失败重试浪费算力。Ray Data 2.56引入记忆感知执行——运行时持续监控集群可用内存、对象存储容量、任务执行进度，动态调整并发度和block大小。当可用内存下降时自动减少并发任务数（避免OOM），当可用内存充足时自动增加并发任务数（提升吞吐）。这是”声明式资源管理”的典型模式——用户声明目标（“我要处理1TB数据”），运行时决定如何达成（动态调整block大小和并发度）。

• PyArrow block格式统一：消除双格式开销：此前Ray Data内部使用两种block格式：Pandas DataFrame（行存储，适合小批量）和Apache Arrow（列存储，适合大批量）。双格式带来三个问题：（1）Pandas与Arrow之间的转换开销（每次操作都需转换格式）；（2）内存不连续（Pandas需要Python对象包装）；（3）跨block操作需要统一格式。Ray Data 2.56彻底移除Pandas block，所有block统一为PyArrow Table格式——零拷贝、高列式、跨语言兼容（Python/C++/Rust）。这与Vol.12报道的Delta Lake v3的VARIANT类型和Vol.4报道的Daft v0.7.14的arrow-rs重写Parquet读取器方向一致——都是统一数据格式减少序列化开销。

• 取消预算控制：优雅取消与资源回收：分布式数据预处理常因各种原因需要取消（用户手动取消、上游数据变更、超时取消）。此前的”硬取消”（hard kill）立即终止任务，导致已分配的对象存储资源未释放、已读取的数据未清理，下次任务可能因资源残留而失败。Ray Data 2.56引入取消预算控制（Cancel Budgeting）——取消时给任务一个时间窗口（默认30秒）完成”清理工作”（释放对象存储、删除临时文件、上报检查点），超时后才硬终止。这与Vol.20报道的Apache Iceberg C++的Resumable Append类似——都通过”优雅终止”避免资源泄露。

• 性能数据：300+ OOM到0、1055s到447s：Anyscale在内部基准测试（生产工作负载的混合数据集）上的对比：未启用记忆感知时，300+次执行中有OOM异常（执行失败需重试）；启用记忆感知后，OOM降为0。95分位端到端执行时间从1055秒降为447秒（57%加速）——这不是小优化，而是分布式数据预处理的关键瓶颈突破。对象存储峰值降低41%——意味同样规模的集群可以处理更大数据量，或同样数据量使用更小集群。

行业影响

Ray Data 2.56的深层意义不是”又一个Ray Data版本更新”，而是分布式数据预处理从”手动调优”走向”运行时自适应”的范式转变。

此前分布式数据预处理是”专家工作”——资深数据工程师根据集群规格、数据特征、并发度需求手动设置Ray Data参数。错误的参数设置导致三类问题：OOM（内存溢出）、Slow Execution（执行缓慢）、Resource Waste（资源浪费）。这些问题的解决需要专业知识，新手用户难以入手。Ray Data 2.56的记忆感知执行将”调优”从用户侧移到运行时——用户只需声明”我要处理什么数据”，运行时自动决定”如何最优处理”。这是声明式数据处理的典型范式。

将本期与Vol.19报道的阿里云Flink VVR 11.7（AI Agent + Paimon向量搜索）、Vol.20报道的Apache Iceberg C++ 0.3.0（原生C++计算引擎）、Vol.4报道的Daft v0.7.14（arrow-rs重写Parquet读取器）相比，Ray Data 2.56做的是”分布式数据预处理的声明式抽象”——Daft做的是”统一数据格式与跨语言执行”，Iceberg C++做的是”原生C++计算引擎”（消除JVM开销），Flink VVR 11.7做的是”流处理+AI Agent集成”。四者都从不同角度消除分布式数据处理的”专家门槛”——Daft让任何语言可以使用相同数据格式，Iceberg C++让任何引擎可以原生执行，Flink VVR让AI Agent可以接入流处理，Ray Data 2.56让任何用户可以自动获得最优资源分配。当分布式数据处理的”专家门槛”持续降低时，更多业务人员可以独立完成数据预处理——这扩大了DataInfra的用户基数。

将本期与Flink 2.3.0对比，Flink 2.3.0的FLIP-339（自适应分区选择）与Ray Data 2.56的记忆感知执行异曲同工：Flink自适应分区解决”流处理分区数手动调优”，Ray Data记忆感知解决”数据预处理并发度手动调优”。两者都通过”运行时自适应”消除手动调优——这是分布式数据处理引擎的共同演进方向。当Apache Flink、Ray Data、Spark AQE、Presto自适应执行都开始”运行时自适应”时，手动调优将逐步成为历史——数据工程师的工作从”调参数”转向”设计数据流”。

相关链接

• Ray Data 2.56 Release Notes
• Memory-Aware Execution Design Doc
• Anyscale Blog: Ray Data 2.56
• PyArrow Block Format Migration Guide

---

Trino 482 “Summer of Grammar”：SQL标准空白填补与方言收敛，从分布式SQL引擎到标准SQL实现

事件概述

6月26日，Trino发布482版本——这是继Vol.9报道Trino 475（JDBC连接池改进）后，Trino最重要的版本之一。本次发布的代号是”Summer of Grammar”——意指本次重点是SQL语法与标准的对齐。具体变更包括：（1）BETWEEN SYMMETRIC（对称区间查询，支持反向区间）、IS [NOT] TRUE|FALSE|UNKNOWN（三值逻辑谓词，SQL标准的关键特性）、UNIQUE与MATCH谓词（SQL标准谓词）、命名参数（Named Arguments，调用函数时使用参数名而非位置）；（2）OVERLAY函数（字符串覆盖函数，SQL:2003标准）、正则函数REGEXP_COUNT_LIKE、LIKE谓词使用列引用（之前只支持常量）；（3）破坏性变更——char→varchar转换从”静默截断”改为”类型转换异常”（严格遵循SQL标准）。Trino作为分布式SQL引擎，长期以来是”方言代表”（支持Hive、PostgreSQL、MySQL、Oracle等多种方言），本次”Summer of Grammar”标志着Trino从”方言”走向”标准”。

技术解析

• BETWEEN SYMMETRIC：对称区间查询：传统BETWEEN x AND y要求x ≤ y（升序），否则返回空集。但SQL标准定义的BETWEEN SYMMETRIC允许x > y——自动识别并反转区间。例如BETWEEN 10 SYMMETRIC 5 AND 100 SYMMETRIC 200等同于BETWEEN 5 AND 200 AND x >= 10 AND x <= 200。这个特性在用户输入边界值时特别有用——无需先判断x和y的大小关系。这与SQL标准的”对称性”原则一致——查询表达式不应依赖于值的顺序。

• IS [NOT] TRUE|FALSE|UNKNOWN：三值逻辑的SQL标准表达：SQL的逻辑运算有三值逻辑（TRUE/FALSE/UNKNOWN），UNKNOWN是NULL参与比较的结果。传统SQL查询中表达”x IS NULL”实际上是x IS UNKNOWN的特例。SQL标准定义的IS [NOT] TRUE|FALSE|UNKNOWN谓词让用户可以直接表达三值逻辑判断——例如WHERE (a > b) IS NOT FALSE表达”a > b结果不是FALSE（即TRUE或UNKNOWN）“。这在复杂业务逻辑查询中非常有用——例如”找出订单金额为正但优惠金额未知的记录”（WHERE amount > 0 IS NOT FALSE AND discount IS UNKNOWN）。

• UNIQUE与MATCH谓词：SQL标准的子查询谓词：UNIQUE谓词判断子查询是否返回唯一值（无重复行），MATCH谓词判断子查询是否有匹配行。这两个谓词是SQL:1999标准引入的子查询表达方式。WHERE UNIQUE (SELECT * FROM ...)表达”子查询结果唯一”，WHERE MATCH (SELECT * FROM ...)表达”子查询有匹配”。这与EXISTS、IN等子查询谓词功能类似但更符合SQL标准。

• 命名参数：函数调用的可读性提升：此前调用函数必须按位置传递参数（func(1, 2, 3)），参数顺序错误会导致逻辑错误但不会报错（参数类型相同时）。命名参数允许使用参数名传递（func(a => 1, b => 2, c => 3)），可读性更高、参数顺序无关。SQL标准的命名参数（SQL/PSM）从SQL:2003开始支持。

• OVERLAY函数：字符串覆盖的SQL标准函数：OVERLAY(string PLACING replacement FROM start [FOR length])——将replacement插入到string的start位置，可选覆盖length个字符。例如OVERLAY('abcdef' PLACING 'XYZ' FROM 3 FOR 2)返回’abXYZef’。这个函数是SQL:2003标准的字符串函数，此前部分数据库（如PostgreSQL、Oracle）支持但Trino不支持，本次填补空白。

• char→varchar破坏性变更：从静默截断到严格异常：此前Trino允许char类型转换为varchar类型——如果char值超过varchar长度则静默截断。SQL标准规定此类转换应该抛异常（防止数据丢失），Trino 482开始遵循此规定。这一变更是破坏性的——使用char→varchar转换的SQL可能在新版本上失败。用户需使用CAST AS VARCHAR(LENGTH)显式指定长度来保留截断行为。

行业影响

Trino 482 “Summer of Grammar”的深层意义不是”又一个Trino版本更新”，而是Trino从”分布式SQL引擎”走向”标准SQL实现”的范式转变。

此前Trino的核心价值是”分布式执行”——将一个SQL查询分布到多个节点并行执行。但SQL语法层面，Trino长期以”PostgreSQL方言为主，融合多种方言”为定位——这导致用户在不同数据库间迁移时需要修改SQL。本次”Summer of Grammar”明确将”SQL标准对齐”作为产品方向——填补BETWEEN SYMMETRIC、IS [NOT] TRUE|FALSE|UNKNOWN、UNIQUE、MATCH、命名参数、OVERLAY等SQL标准空白。这意味着用户在Trino上编写的SQL更接近”标准SQL”——从PostgreSQL、Oracle、SQL Server、DB2迁移到Trino的SQL修改量更小。

将本期与Vol.11报道的Snowflake Adaptive LLM Optimization（不同LLM策略性编排）、Vol.13报道的dbt语义层（统一业务语义）相比，Trino 482的”标准SQL”路径与Snowflake的”统一LLM接口”路径、dbt的”统一业务语义”路径异曲同工：Snowflake统一LLM调用接口（让用户用统一SQL调用不同LLM），dbt统一业务语义（让BI工具用统一语义层查询不同数据仓库），Trino统一SQL语法（让用户用统一SQL查询不同数据源）。三者都从”方言/模型/仓库各自为政”走向”统一接口”——这是数据基础设施的”接口标准化”主线。

将本期与Flink 2.3.0对比，Flink 2.3.0的FLIP-564（Changelog SQL算子）扩展SQL的表达力（让SQL可以表达Changelog），Trino 482的”Summer of Grammar”补齐SQL的语法完整性（让SQL符合SQL标准）。两者方向相反但殊途同归——都在让SQL成为”分布式数据处理的统一语言”。Flink 2.3.0让SQL覆盖流处理，Trino 482让SQL覆盖标准。当SQL可以表达流处理、SQL符合标准、SQL可以跨数据源执行时，SQL作为”数据处理统一接口”的角色得到进一步强化——AI代理（如BigQuery Conversational Analytics，本期）生成的SQL可以在Trino、Flink、Spark、PostgreSQL等多端执行，SQL成为AI代理与数据基础设施之间的”通用协议”。

相关链接

• Trino 482 Release Notes
• Trino SQL Standard Compliance
• BETWEEN SYMMETRIC and IS [NOT] TRUE|FALSE|UNKNOWN

---

AWS Redshift多仓库功能：远程MV操作与BI仪表板25.7x冷启动加速，从单仓资源池化到多仓协同

事件概述

6月29日，AWS Redshift发布两项重大更新：（1）跨仓库多仓库功能——远程物化视图（MV）操作（CREATE/DROP/REFRESH/ALTER/METADATA）、远程表DDL（ALTER TABLE ALTER DISTSTYLE/APPEND）、并发扩展（Concurrency Scaling）覆盖zero-ETL/auto-copy/COPY；（2）BI仪表板性能优化——通过组合技术（Composition Technique）将冷查询编译时间从4.3秒降为170毫秒（25.7倍加速），价格性能提升8.3倍。两项更新共同指向”多仓库协同”——Redshift从”单仓资源池化”（Concurrency Scaling扩展单仓资源）走向”多仓协同”（不同仓库承担不同工作负载并通过MV/表DDL共享数据）。这是继Vol.18报道的Snowflake Cortex AISQL（AI操作符）后，云数仓的又一次重大演进。

技术解析

• 远程物化视图（MV）操作：跨仓库的数据共享：此前Redshift用户需要为不同工作负载创建不同仓库（BI仓库、ETL仓库、Ad-hoc仓库），但跨仓库数据共享需要通过Spectrum查询S3或UNLOAD/COPY数据，效率低且延迟大。远程MV功能允许在一个仓库创建MV，引用另一个仓库的表——查询时自动跨仓库拉取数据并缓存。例如：BI仓库可以创建MV引用ETL仓库的表，BI查询自动从MV读取（MV在ETL仓库自动刷新）。这与Snowflake的Secure Data Sharing（Vol.6报道）功能类似——但Redshift的远程MV在SQL层定义，Snowflake在账户层定义。

• 远程表DDL：跨仓库的表管理：ALTER TABLE ALTER DISTSTYLE允许修改远程表的分布键（解决数据倾斜），ALTER TABLE APPEND允许将本地表数据追加到远程表（高效数据归档）。这些DDL以前只能操作本地仓库的表，本次扩展到远程表——意味着用户可以在BI仓库中定义Ad-hoc查询的表结构，DDL自动应用到数据所在的ETL仓库。

• 并发扩展（Concurrency Scaling）覆盖更多场景：此前Concurrency Scaling仅支持SELECT查询，本次扩展到zero-ETL（实时从RDS/Aurora同步数据到Redshift）、auto-copy（自动从S3摄取数据）、COPY（批量加载数据）。这意味着即使是数据加载操作也可以通过Concurrency Scaling获得弹性——数据加载不再是单仓库资源的瓶颈。

• BI仪表板冷查询编译加速：组合技术消除编译开销：BI仪表板（Tableau、Power BI、Looker）首次加载时需要冷查询——Redshift需要编译查询计划、获取表统计、生成执行计划。冷查询编译开销大（典型查询4-6秒），用户感知”仪表板加载慢”。本次通过”组合技术”（Composition Technique）优化——将常用查询模板预编译为可复用的”组合块”，新查询如果匹配模板则直接复用编译结果，无需重新编译。冷查询编译时间从4.3秒降为170毫秒（25.7倍加速），价格性能提升8.3倍（同样查询消耗更少资源）。

行业影响

AWS Redshift多仓库功能的深层意义不是”又一个Redshift功能更新”，而是Redshift从”单仓资源池化”走向”多仓协同”的范式转变。

此前Redshift的扩展模型是”Concurrency Scaling”——在单仓库内部动态扩展计算节点，处理并发查询。这意味着所有工作负载（BI、ETL、Ad-hoc）共享同一仓库资源——BI查询和ETL作业可能相互影响（ETL作业占用资源导致BI查询排队）。多仓库功能允许用户为不同工作负载创建不同仓库（BI仓库/ETL仓库/Ad-hoc仓库），仓库间通过远程MV/远程表DDL共享数据。这与Vol.18报道的Snowflake Secure Data Sharing、Vol.14报道的Databricks SQL Warehouse（按工作负载分类）形成云数仓的”多仓协同”模式：每个工作负载有专属仓库，仓库间通过共享机制（MV/Sharing/Unity Catalog）协同。

将本期与Flink 2.3.0对比，Flink 2.3.0的FLIP-555（Native S3）将S3作为流处理的一等存储，Redshift多仓库功能将S3作为多仓库协同的共享层——两者都通过”S3作为协议层”实现不同计算单元的协同。Flink让不同Flink部署可以共享S3上的流数据，Redshift让不同Redshift仓库可以共享S3上的表数据。当S3成为”流处理和数仓的统一存储协议”时，云数据栈的部署灵活性大幅提升——用户可以为不同工作负载部署不同的计算引擎（Flink/Redshift/Trino/Spark）而共享同一份S3数据。

BI仪表板冷查询编译加速（25.7倍）的工程意义在于：冷查询的”感知慢”是BI工具被业务用户抱怨的主要原因——用户打开仪表板需要等4秒+，但这是用户感知最敏感的时间窗口（<1秒感知流畅、1-3秒感知可接受、3秒+感知慢）。将4.3秒降为170毫秒（<200毫秒）将BI仪表板从”感知慢”推向”感知即时”——这对业务用户的BI工具采纳率有直接影响。这与Vol.16报道的Google Cloud Serverless Spark Runtime 3.0（75%启动加速）和Vol.22报道的Google Cloud Lightning Engine（4.9倍Spark加速）形成云数仓性能优化的三条路径：Serverless Spark优化”启动速度”，Lightning Engine优化”执行速度”，Redshift优化”BI冷查询速度”。当BI仪表板加载从”4秒”降到”170毫秒”时，业务用户对BI工具的满意度提升——这直接影响DataInfra产品的商业价值。

相关链接

• Redshift Multi-Warehouse Documentation
• Redshift BI Dashboard Performance Optimization
• Redshift Concurrency Scaling for zero-ETL

---

Google Cloud BigQuery Conversational Analytics GA：自然语言查询走代理式推理，数据分析从人写SQL走向代理式分析

事件概述

7月1日，Google Cloud宣布BigQuery Conversational Analytics正式GA（General Availability）——这是BigQuery的自然语言查询与分析代理产品。BigQuery Conversational Analytics允许用户用自然语言提问（“上周哪个产品线销量最高”），BigQuery自动完成”理解问题→规划查询→生成SQL→执行SQL→生成可视化→回答问题”的端到端流程。核心技术包括：（1）代理式推理（Agentic Reasoning）——多步骤规划（先查询总销量，再按产品线分组，最后排序）；（2）Open Knowledge Format（OKF）即插即用——企业可以将自己的业务术语、指标定义、查询模板打包为OKF，BigQuery自动理解这些领域知识；（3）深度调查模式（Deep-Dive Mode）——对复杂问题进行多轮探索性查询；（4）自动可视化——查询结果自动选择最合适的图表类型。BigQuery Conversational Analytics是Google Cloud将”代理式分析”作为BigQuery产品方向的重要里程碑。

技术解析

• 代理式推理：自然语言到SQL的多步骤规划：传统自然语言到SQL（NL2SQL）系统是”单步”——用户问题转换为SQL查询后直接执行。BigQuery Conversational Analytics是”多步”——用户问题先转换为”查询计划”（多个子查询的组合），再逐步执行并整合结果。例如用户问”上周哪个产品线销量最高且增长率最快”——系统规划为：（1）查询上周各产品线销量；（2）查询上周各产品线同比增长率；（3）综合排序选出TOP产品线；（4）生成可视化对比销量与增长率。这种”代理式推理”让BigQuery可以回答更复杂的多维度问题。

• Open Knowledge Format（OKF）：领域知识的即插即用：企业有自己的业务术语（“活跃用户”在A产品定义30天登录，在B产品定义7天登录）、指标定义（“GMV”是否包含运费）、查询模板（“双11大屏”的固定查询模式）。传统方式需要将领域知识硬编码到提示工程中，效率低且难以维护。OKF是Google Cloud 2026年6月提出的开放标准（v0.1）——以Markdown+YAML格式封装业务知识（术语定义、指标公式、查询模板、示例问答），BigQuery Conversational Analytics可以即插即用地理解企业领域知识。OKF是vendor-neutral的（不绑定BigQuery），任何NL2SQL系统都可以采用。

• 深度调查模式：多轮探索性查询：对复杂问题（“为什么Q2毛利率下降”），Conversational Analytics会进行多轮探索性查询——先查询整体毛利率变化，再查询各产品线毛利率，再查询成本构成，再查询成本异常的项目。这种”调查”模式模拟数据分析师的思维方式——先看整体再看局部，先看变化再看原因。深度调查模式可以产生几十个查询的”调查链”，最终回答用户的复杂问题。

• 自动可视化：从SQL结果到最佳图表：Conversational Analytics不只返回表格数据，还自动选择最合适的图表类型——时序数据用折线图、占比数据用饼图、对比数据用柱状图、相关性数据用散点图。这降低了用户对数据可视化技能的要求——用户只需提问，BigQuery自动选择最佳呈现方式。

行业影响

BigQuery Conversational Analytics GA的深层意义不是”又一个自然语言查询产品”，而是数据分析从”人写SQL”走向”代理式分析”的范式转变。

此前数据分析的工作流是”业务人员提问 → 数据分析师写SQL → 执行查询 → 解读结果”——数据分析师是业务人员与数据之间的”翻译”。这个工作流有两个瓶颈：（1）数据分析师资源有限（一个公司通常只有几个数据分析师但几十个业务人员），业务人员等待时间长；（2）数据分析师的SQL能力参差（不同分析师写的SQL效率不同）。Conversational Analytics让业务人员直接以自然语言提问，BigQuery自动完成”SQL生成 + 查询执行 + 结果解读”——数据分析师的”翻译”角色被AI代理取代。

将本期与Vol.18报道的Snowflake Cortex AISQL（AI操作符AI_FILTER/AI_JOIN/AI_AGG作为SQL一等原语）、Vol.22报道的Databricks Genie Ontology（权威图谱）、Vol.15报道的Snowflake Horizon Context（AI生成文档）相比，BigQuery Conversational Analytics、Cortex AISQL、Genie Ontology、Horizon Context都从不同角度让AI代理”理解企业数据”：Cortex AISQL将AI作为SQL操作符（让SQL可以直接调用AI），Genie Ontology构建权威图谱（让AI理解企业业务上下文），Horizon Context提供元数据丰富（让AI理解数据资产的含义），Conversational Analytics让AI直接执行端到端分析。四者形成”AI代理理解企业数据”的完整路径：数据资产 → 元数据丰富（Horizon）→ 业务上下文（Genie）→ SQL调用AI（Cortex）→ 端到端分析（Conversational Analytics）。

将本期与Flink 2.3.0（Changelog SQL算子）对比，Flink 2.3.0让SQL可以表达流处理，Conversational Analytics让自然语言可以生成SQL——两者方向相反但殊途同归。Flink 2.3.0的SQL是”机器可理解的语言”，Conversational Analytics的自然语言是”人类可理解的语言”。当AI代理可以理解自然语言并生成SQL时，SQL成为”人机协议”——人类用自然语言表达意图，AI代理用SQL表达执行。这是AI代理时代的关键基础设施：当所有数据基础设施都提供SQL接口（Flink SQL、Trino SQL、Redshift SQL、BigQuery SQL、Spark SQL）时，AI代理可以”一次生成SQL、多端执行”——这降低了AI代理与数据基础设施的集成成本。

相关链接

• BigQuery Conversational Analytics GA Announcement
• Open Knowledge Format (OKF) v0.1 Specification
• BigQuery Conversational Analytics Documentation

---

编者评

第二十三期的四条动态，从不同层面共同指向数据基础设施的”协议标准化+代理化执行”主线——通过标准化协议消除厂商锁定，通过AI代理化执行降低使用门槛。

第一个层面是云原生协议的标准化：Apache Flink 2.3.0的FLIP-555（Native S3）将S3作为流处理的一等存储。 此前Flink必须通过Hadoop FileSystem抽象访问S3，这意味着Flink被Hadoop的历史包袱约束，无法直接使用S3的现代特性（S3 Express One Zone、Directory Buckets、智能分层）。FLIP-555将S3作为一等公民纳入Flink，基于AWS SDK v2完全替代Hadoop依赖——平均吞吐提升2.17倍、检查点1.85x加速、小状态4.58x加速。这是Flink从”流处理框架”走向”流处理协议栈”的标志——通过标准化存储协议（S3），让Flink的不同能力可以独立演进、跨实现兼容。将本期与Redshift多仓库对比，两者都通过”S3作为协议层”实现不同计算单元的协同：Flink让不同Flink部署可以共享S3上的流数据，Redshift让不同Redshift仓库可以共享S3上的表数据。当S3成为”流处理和数仓的统一存储协议”时，云数据栈的部署灵活性大幅提升——用户可以为不同工作负载部署不同的计算引擎（Flink/Redshift/Trino/Spark）而共享同一份S3数据。

第二个层面是分布式执行的运行时自适应：Ray Data 2.56的记忆感知执行终结OOM。 此前分布式数据预处理是”专家工作”——资深数据工程师根据集群规格、数据特征、并发度需求手动设置Ray Data参数。Ray Data 2.56引入记忆感知执行——运行时持续监控集群可用内存、对象存储容量、任务执行进度，动态调整并发度和block大小。OOM异常从300+降为0，95分位端到端执行时间从1055s降为447s（57%加速）。这是分布式数据预处理从”手动调优”走向”运行时自适应”的范式转变——用户只需声明”我要处理什么数据”，运行时自动决定”如何最优处理”。Flink 2.3.0的FLIP-339（自适应分区选择）做的是同样的事：Flink自适应分区解决”流处理分区数手动调优”，Ray Data记忆感知解决”数据预处理并发度手动调优”。当Apache Flink、Ray Data、Spark AQE、Trino自适应执行都开始”运行时自适应”时，手动调优将逐步成为历史——数据工程师的工作从”调参数”转向”设计数据流”。

第三个层面是SQL方言的标准化：Trino 482的”Summer of Grammar”填补SQL标准空白。 此前Trino以”PostgreSQL方言为主，融合多种方言”为定位，用户在不同数据库间迁移时需要修改SQL。本次填补BETWEEN SYMMETRIC、IS [NOT] TRUE|FALSE|UNKNOWN、UNIQUE、MATCH、命名参数、OVERLAY等SQL标准空白——char→varchar转换从”静默截断”改为”类型转换异常”（严格遵循SQL标准）。这是Trino从”分布式SQL引擎”走向”标准SQL实现”的范式转变。将本期与Flink 2.3.0对比，Flink 2.3.0的FLIP-564（Changelog SQL算子）扩展SQL的表达力（让SQL可以表达Changelog），Trino 482的”Summer of Grammar”补齐SQL的语法完整性（让SQL符合SQL标准）。两者方向相反但殊途同归——都在让SQL成为”分布式数据处理的统一语言”。当SQL可以表达流处理、SQL符合标准、SQL可以跨数据源执行时，SQL作为”数据处理统一接口”的角色得到进一步强化。

第四个层面是数据分析的代理化执行：BigQuery Conversational Analytics GA开启代理式分析时代。 此前数据分析的工作流是”业务人员提问 → 数据分析师写SQL → 执行查询 → 解读结果”。Conversational Analytics让业务人员直接以自然语言提问，BigQuery自动完成”SQL生成 + 查询执行 + 结果解读”——数据分析师的”翻译”角色被AI代理取代。这是数据分析从”人写SQL”走向”代理式分析”的范式转变。将本期四条动态串联，Flink 2.3.0让SQL覆盖流处理（FLIP-564 Changelog），Trino 482让SQL符合标准（Summer of Grammar），BigQuery Conversational Analytics让自然语言生成SQL。三者形成”自然语言 → SQL → 多端执行”的AI代理数据栈——人类用自然语言表达意图，AI代理用SQL表达执行，SQL在Flink/Trino/Redshift等多端执行。

将二十三期主线串联，数据基础设施正在从”工具集合”走向”协议栈+代理执行”的两层架构。 工具集合阶段（2010-2020）——Hadoop生态、Spark、Flink、Kafka、Airflow等工具各自演进，工具间的集成需要胶水代码。协议栈阶段（2020-2026）——Iceberg REST Catalog、Delta REST API、Open Knowledge Format、Flink Native S3等协议标准让不同工具可以互操作。代理执行阶段（2026-）——BigQuery Conversational Analytics、Databricks Genie Agents、Flink Agents等AI代理让自然语言成为数据访问的统一接口。当数据基础设施完成”工具→协议→代理”的演进时，数据访问的门槛将从”专业技能”（写SQL、调集群、配置管道）降低到”自然语言”（直接提问）——这将释放巨大的数据价值，让更多业务人员可以独立完成数据分析。这对DataInfra从业者的启示是：未来5年的核心竞争力是”让数据更易访问”——通过协议标准化降低集成成本，通过AI代理降低使用门槛。