datainfra前沿动态 · Vol.45

Google BigQuery 发布自主性能三件套与搜索摄入全面升级：历史学习优化器 GA + DTS 零代码多源摄入 + Apache Fluss 毕业为 ASF Top-Level Project；AWS MWAA 全面拥抱 Airflow 3.0 事件驱动编排

本期聚焦四条 DataInfra 动态：Google Cloud BigQuery 一周内连发三项重大升级——自主查询优化器历史学习正式上线、Advanced Runtime 增强向量化与短查询 SMP 加速、以及 Fluid Scaling 流体计费；同时 BigQuery DTS 新增 9 种零代码数据源连接器、Apache Iceberg 托管表摄入和 MCP Server for Agents；BigQuery Search 则实现自主嵌入生成 GA、混合搜索 Preview 和单查询 133× 槽位效率提升。AWS MWAA 正式支持 Airflow 3.0 Asset-Based Scheduling，通过 SQS Asset Watcher 实现跨账户近实时事件驱动编排。Apache Fluss 从 ASF 孵化器毕业成为 Top-Level Project，与 Apache Paimon 共同构成阿里云 OpenLake 的 Lakestream 实时流存储层。四条动态从查询引擎自主化、数据摄入零代码化、编排事件驱动化到流存储标准化，呈现 DataInfra 在 Agentic AI 时代的全面进化。

DataInfra Google Cloud BigQuery 自主优化 History-Based Optimization Advanced Runtime Vectorized Execution Fluid Scaling Data Transfer Service Apache Iceberg MCP Hybrid Search Autonomous Embedding BM25 AWS MWAA Apache Airflow Asset-Based Scheduling Event-Driven SQS Apache Fluss TLP Streaming Storage Lakestream Apache Paimon OpenLake 阿里云 Agentic AI

本期追踪到四条 DataInfra 动态，从查询引擎自主化、数据摄入零代码化、搜索能力统一化、编排事件驱动化到流存储标准化，呈现数据基础设施在 Agentic AI 时代”不用人手调优、不用写胶水代码、不用等轮询周期”的全面进化。2026 年 8 月 7 日至 8 日，Google Cloud BigQuery 团队在一周内密集发布了三项重大升级：自主性能三件套（History-Based Optimizations + Advanced Runtime + Fluid Scaling）实现了查询优化从”人手调参”到”自学习闭环”的范式转变——包含自纠正安全护栏、增强向量化至多 10× 加速 40% 槽位缩减、以及 SMP-over-MPP 短查询路径至多 10× 槽位降低；BigQuery DTS 零代码多源摄入全面扩张新增 9 种连接器（SQL Server、Shopify、Klaviyo、HubSpot、Mailchimp 等），首次支持直接摄入 Apache Iceberg 托管表，并提供全托管 MCP Server 供 AI Agent 发现和执行数据传输；BigQuery Search 搜索能力统一化实现自主嵌入生成 GA（含图像/ObjectRef 支持）、AI.SEARCH() GA 单查询 133× 槽位效率提升、以及混合搜索 Public Preview（BM25 关键词 + 向量语义双路融合）。8 月 6 日，AWS 发布 MWAA 对 Apache Airflow 3.0 事件驱动编排的全面支持——利用 Asset Watcher 在 Triggerer 中监听 SQS 队列，将跨账户工作流触发从分钟级轮询升级为秒级近实时，彻底消除传统 Sensor 的轮询开销和 Worker 占用。8 月 7 日，Apache 软件基金会官方宣布 Apache Fluss 从孵化器毕业成为 Top-Level Project——这个由阿里云 Flink 团队贡献的 Flink Unified Streaming Storage 项目，为 Lakehouse 提供了原生列式流存储层，与 Apache Paimon 共同构成阿里云 OpenLake 的 Lakestream 实时数仓架构，在阿里巴巴 618 峰值已处理千亿级事件流量。四条动态共同指向一个正在清晰化的趋势：DataInfra 正在从”被动响应式”基础设施进化为”主动自治式”基础设施——查询自己调优、数据自己摄入、管道自己编排、流存储自己标准化。

Google BigQuery 发布自主性能三件套：历史学习优化器 + Advanced Runtime + Fluid Scaling，查询优化从”人手调参”到”闭环自学习”

事件概述

2026 年 8 月 7 日，Google Cloud 的 Joe Yong 和 Manan Goel 联合发布了 BigQuery 自主查询性能的三大核心升级——History-Based Optimizations（历史学习优化器）、Advanced Runtime（增强运行时）和 Fluid Scaling（流体计费）。这三项能力并非独立的新功能发布，而是 BigQuery 自 2025 年以来持续积累的自主性能优化体系的系统性阐述。Google Cloud 披露，仅在 2025 年，BigQuery 已实现查询性能提升至多 35%、查询处理成本（槽位用量）降低至多 40%。

这次发布的核心叙事是：当 AI Agent 每秒发出数千条查询、而非人类每天跑几十条查询时，手动查询调优在物理上不可能完成——数据平台必须能够自学习、自优化、自纠正。 BigQuery 将这一愿景称为”come in to work and BigQuery is faster than it was the day before”。

技术解析

  • History-Based Optimizations（HBO）：从静态统计到运行时记忆的自学习范式：传统查询优化器依赖静态统计信息和基数估算，在面对复杂多表 JOIN 和快速增长的数据时，这些估算可能严重失真。HBO 改变了这个范式——它追踪过去查询的运行时统计信息，记住哪些优化策略对特定查询有益并自动持续应用，同时记住哪些优化曾导致性能退化并自动避免。这是一个自带安全护栏的闭环自纠正系统：每次应用优化后，系统测量实际效果——如果观察到预期性能提升则接受该优化，如果未显著改善甚至出现退化或失败，则立即撤销该优化并对该查询永不再尝试。这意味着 BigQuery 的优化器不仅”学习成功经验”，还”记住失败教训”——传统数据库中需要 DBA 手动管理的 Plan Guide 被完全自动化。Google 披露了一个企业客户的实测数据：P90 执行时间下降至多 50%，槽位使用量下降至多 15%，零性能退化。

  • Advanced Runtime：增强向量化 + 短查询 SMP-over-MPP 双路径加速：BigQuery 的增强运行时包含两大子能力。(1) 增强向量化：利用新一代处理器的 SIMD 指令集，自主识别消除重复计算的机会，原生处理字典编码和游程编码数据，结合最先进的并行算法在符合条件的查询阶段扩大加速机会。效果为符合条件的查询至多 10× 加速，整体槽位时间降低至多 40%。(2) 短查询优化：针对高并发低延迟的 BI 看板和 Agentic 应用（每秒数千条查询、要求亚秒级延迟），BigQuery 自主识别”短”查询并减少数据重分布阶段——本质是在 MPP（大规模并行处理）分布式数据库内透明地实现了一条 SMP（对称多处理）查询路径。效果为短查询槽位使用降低至多 10×、P99 亚秒级延迟、部分客户吞吐量至多 3× 提升。这两项优化均零用户干预——不需要修改 SQL、不需要改写 Schema、不需要添加 Query Hint。

  • Fluid Scaling：真正按秒计费的自主扩缩容：BigQuery 的 Fluid Scaling 在原有 Autoscaler 基础上实现了真正的按秒计费——不像传统方案按节点或集群粒度计费，而是直接按槽位-秒消耗量计费，自主性能提升直接转化为成本节省。Google 引用了 AdTech 公司 RISE（日处理 1PB+ 数据、月管理 3 万亿+ 竞价）CEO Chen Shalit 的证言：Fluid Scaling 使其基础设施成本降低 25%，每小时数据处理吞吐量提升，客户获得了”最新鲜”的数据。Google 自报 Fluid Scaling 平均为自动扩缩容工作负载降低成本至多 34%。

  • 开放格式同等受益：Google 特别强调，BigQuery 的自主性能优化对 Apache Iceberg 等开放表格式同等生效——无论是 BigQuery 原生 Capacitor 存储格式还是 Iceberg 表的 Parquet 数据，都享受相同的自动过滤器下推、CMETA 索引裁剪、I/O 层页面跳过和异步读取、以及增强向量化。Google 内测数据显示，在 TPC-DS 10TB 基准测试中，BigQuery on Iceberg 相比一个流行的开源分布式 SQL 查询引擎取得了显著的性能与成本优势。

行业影响

BigQuery 这次”三件套”发布的深层意义不在于个别技术指标的提升，而在于它系统性地定义了 “Agentic-Ready 数据平台”应该具备的自主能力矩阵：查询执行层的自学习优化（HBO）→ 物理执行层的自适应加速（Advanced Runtime）→ 资源调度层的按秒计费（Fluid Scaling）。三层闭环共同回答了一个核心问题：当查询由 Agent 而非人类大规模产生时，谁来管理查询性能？

这对于 DataInfra 行业有至少两重信号意义。第一，传统数据库的”手动调优”假设正在被系统性推翻——Plan Guide、Query Hint、人工统计信息刷新这些 DBA 的核心技能，在 Agentic 工作负载面前不再是可扩展的方案。BigQuery 选择将 HBO 的护栏设计为”自纠正”而非”尽力而为”——优化出错不是降低信心分数而是直接撤销并永不再试——这是一种工程上的强硬立场，表明 Google 对自主优化可靠性的信心。第二，开放格式的性能差距正在缩小——当 Iceberg 表能享受与原生格式同等的自主优化时，“专有格式性能更好”的传统论点被削弱，这直接利好整个开放 Lakehouse 生态。

相关链接

BigQuery 搜索与摄入全面升级：自主嵌入生成 GA + 混合搜索 Preview + DTS 零代码多源摄入 + Iceberg 托管表 + MCP Server for Agents

事件概述

2026 年 8 月 8 日，Google Cloud 同一天发布了两篇重磅博文，全面升级 BigQuery 的数据摄入与搜索能力。第一篇由 Vignesh Rajamani 和 Pallavi Palleti 撰写，宣布 BigQuery Data Transfer Service (DTS) 大规模扩展：新增 9 种连接器（SQL Server、Shopify、Klaviyo、HubSpot、Mailchimp 等），首次支持直接摄入 Apache Iceberg 托管表（Preview），并提供全托管 MCP Server（Preview） 供 AI Agent 程序化发现数据源并执行传输。第二篇由 Joe Malone 和 Francis Lan 撰写，宣布 BigQuery Search 三大里程碑：自主嵌入生成（Autonomous Embedding Generation）GA——新增图像/ObjectRef 嵌入支持；AI.SEARCH() GA——单查询槽位效率提升至多 133×；混合搜索（Hybrid Search）Public Preview——BM25 关键词匹配与向量语义搜索双路融合。两篇文章共同构成了 BigQuery 作为”统一数据+AI 平台”的完整能力矩阵补全。

技术解析

  • DTS 零代码多源摄入 + Iceberg 托管表：BigQuery DTS 的扩展方向清晰——消除数据摄入的工程负担。Google 引用了企业客户每周花费 100+ 小时构建和修复脆弱自建 ETL 管道的现状，将 DTS 定位为”零代码、全托管”的替代方案。新增连接器覆盖三大类别：(1) 企业数据库——SQL Server (Preview)、PostgreSQL (GA)、MySQL (GA)，支持完整和增量传输；(2) 电商与营销平台——Shopify、Klaviyo、HubSpot、Mailchimp（均为 Preview），自动抽取订单、库存、客户画像、邮件/SMS 互动日志等关键业务数据；(3) 迁移连接器——Snowflake 迁移 (GA)，支持增量传输、自动 Schema 检测、私有连接和跨三朵云（GCP/AWS/Azure）的数据迁移。最值得关注的新能力是 直接摄入 Apache Iceberg 托管表——数据不仅进入 BigQuery 原生存储，还可直接写入 Iceberg 表，保持跨多云查询引擎的存储兼容性，同时享受 BigQuery 的性能调优。

  • MCP Server for DTS：Agent 驱动的数据传输：DTS 的 MCP Server 能力代表了 DataInfra 中最前沿的趋势——让 AI Agent 直接操作数据基础设施。通过这个完全托管的 MCP Server，开发者可以让 AI 应用和 Agent 程序化发现可用的数据源、配置传输任务并在用户授权下执行。这意味着数据传输不再需要一个工程师去控制台点击配置——Agent 可以直接说”我需要在 BigQuery 中分析 Shopify 的订单数据，帮我设置一个每日增量同步”。这是对 Vol.42-44 追踪的”Agent-First DataInfra”趋势在数据摄入层的直接落地。

  • 自主嵌入生成 GA：嵌入从”管道工程”到”Schema 定义”：BigQuery 的自主嵌入生成将嵌入向量的维护从异步管道工程简化为一个 DDL 操作——用户只需在表 Schema 中定义一个 GENERATED ALWAYS AS (AI.EMBED(...)) STORED 列并设置 asynchronous = TRUE，BigQuery 即在新数据摄入时自动、持续、异步生成嵌入向量，无需管理重试、错误日志和管道编排。GA 版本新增 图像/ObjectRef 嵌入支持，将这一能力从文本扩展到真正的多模态搜索与分析。用户可选择外部模型（如 Vertex AI text-embeddings）或直接使用 Gemma 嵌入模型。

  • AI.SEARCH() GA：单查询 133× 槽位效率提升：AI.SEARCH() 提供了一个无需手动生成嵌入向量的自然语言搜索接口——直接传入自然语言查询和嵌入列名，BigQuery 内部使用相同的嵌入模型完成向量化与相似度搜索。GA 版本的核心改进在效率层：Google 披露经过一年的优化，AI.SEARCH() 在单查询场景（Agentic 搜索中最常见的模式）中实现了至多 133× 的槽位效率提升，使得直接在 BigQuery 上支撑高并发的用户面搜索成为可能。

  • 混合搜索 Public Preview：BM25 + 向量双路融合：混合搜索解决了纯语义搜索的一个经典盲区——特定技术术语（如免疫疗法药物代号 “MK-3475”）缺乏广泛的语义上下文，纯向量搜索可能无法正确排序。混合搜索通过 Reciprocal Rank Fusion 和 BM25 算法，将关键词精确匹配与语义相似度双路融合，显著提升搜索精度并降低 LLM 幻觉成本。用户只需在 AI.SEARCH() 中设置 mode => 'HYBRID' 并可选扩展向量索引以覆盖关键词列。

行业影响

BigQuery 这次搜索与摄入的双线升级，本质上是在回答一个战略问题：数据仓库的边界在哪里？ 当 BigQuery 可以零代码摄入 SQL Server/Shopify/HubSpot 的数据、可以自主生成嵌入向量、可以做混合搜索（BM25+向量）、可以通过 MCP Server 让 Agent 自主管理数据传输时——它正在从一个”存放结构化数据的 SQL 引擎”演变为一个”覆盖摄入-存储-搜索-嵌入-分析的端到端数据平台”。

对于 DataInfra 从业者，至少有三个信号值得关注。(1) 零代码数据摄入正在成为云数据仓库的标配能力——BigQuery DTS 的零摄入费用策略（Google 自有源和 AWS S3/Azure Blob/Redshift/Teradata 全部免费）直接挑战了传统 ELT 工具（如 Fivetran）的价值主张——如果不靠连接器收费，ETL 工具还能靠什么差异化？(2) 向量搜索正在从专用向量数据库迁回数据仓库——BigQuery 混合搜索 + 133× 效率提升 + 自主嵌入的 GA，意味着越来越多的 RAG 和搜索应用不需要独立部署 Pinecone/Weaviate 等专用向量数据库，可以直接在 BigQuery 中完成端到端的多模态搜索。(3) MCP 协议正在成为 DataInfra 产品的标准 Agent 接口——继 AWS Spark Agent MCP（Vol.42）、Unity AI Gateway MCP（Vol.44）之后，BigQuery DTS 也加入了 MCP Server 的行列，Agent-First DataInfra 的”MCP Everywhere”趋势进一步确认。

相关链接

AWS MWAA 全面拥抱 Airflow 3.0 事件驱动编排：Asset Watchers + SQS 实现跨账户秒级触发，从轮询到事件的范式跨越

事件概述

2026 年 8 月 6 日，AWS 三位作者——Satya Chikkala、Corrine Tan 和 Haofei Feng——在 AWS Big Data Blog 上发布了一篇技术深度文章，详细阐述了如何利用 Apache Airflow 3.0 的 Asset-Based Scheduling 与 Amazon SQS 在 Amazon MWAA 上构建跨账户事件驱动管道编排。这不是一个单纯的”how-to”指南——它是 MWAA 正式拥抱 Airflow 3.0 新编排范式的标志性发布，核心创新在于：用 SQS 触发的 Asset Watchers（运行在 Triggerer 中）替代传统的轮询式 Sensor，实现跨 AWS 账户 MWAA 环境之间从”分钟级轮询等待”到”秒级近实时触发”的范式跨越。

这篇文章与 Vol.42 中 AWS Spark Troubleshooting Agent 和 MSK Agent Skills 构成了 AWS DataInfra 2026 年 8 月的”三部曲”——计算引擎 Agent + 流平台 Agent + 编排引擎事件驱动化。

技术解析

  • 架构四组件：Producer DAG → SQS → Asset Watcher → Consumer DAG：整个事件驱动编排架构包含四个关键组件。(1) Producer DAG 在生产者 MWAA 环境（Account A）中运行，当任务完成时将资产事件发布到跨账户 SQS 队列，消息包含 dag_id、run_id、logical_date 和数据集特定上下文。(2) Amazon SQS 作为消息代理跨账户解耦生产者和消费者，提供持久消息传递——即使消费者环境暂时不可用，消息也不会丢失。(3) Asset Watcher 作为后台进程在消费者 MWAA 环境（Account B）的 Triggerer 组件中运行，持续监听 SQS 队列，消息到达时立即更新 Airflow 资产状态。(4) Consumer DAG 通过资产调度自动触发，通过 triggering_asset_events 访问消息内容完成下游处理。

  • 关键架构决策：Asset Watcher 在 Triggerer 而非 Scheduler 中运行：这篇博文披露了一个核心架构细节——Airflow 3.0 的 Asset Watchers 运行在 Triggerer 中，而非传统的 Scheduler。这是一个有意为之的设计：Triggerer 本来就设计为高并发、事件驱动的长连接管理器，天然适合持续监听外部事件源（如 SQS 队列）。Scheduler 则专注于 DAG 解析和调度决策，不应被 I/O 密集的队列监听占用资源。这个架构选择对 MWAA 用户的实际影响是：Asset Watcher 不占用 Scheduler 资源、不占用 Worker 槽位——这与传统 Sensor 需要 Worker 持续轮询的模式形成鲜明对比。

  • 三种编排模式对比暴露了轮询模式的结构性劣势：文章给出了三种跨环境 DAG 触发模式的量化对比。Sensor（轮询）模式响应时间为轮询间隔级、占用 Worker 资源、中等耦合——本质上是”不断敲门直到有人开门”的笨重方式。MwaaTriggerDagRunOperator 模式响应时间为秒级但耦合紧密且占用 Worker（若设置 wait_for_completion）。Asset Watchers + SQS 模式（本文推荐）响应时间为秒级、松耦合、不占用 Worker——因为监听逻辑跑在 Triggerer 中。这三种模式的技术演进路径清晰展示了编排范式的结构性变迁：从”主动询问”（Poll）到”被通知”（Event）是编排系统成熟度的分水岭。

  • 配套 Agent Skill 降低了实施门槛：AWS 还为这套事件驱动编排方案提供了 Agent Skill——用户可以用自然语言描述跨账户工作流需求，Skill 自动生成 Producer DAG、Consumer DAG、SQS 配置和 IAM 策略。这与 Vol.42 中 MSK Agent Skills 的设计理念一致：将复杂的多组件配置编码为可复用的结构化知识。

行业影响

Airflow 3.0 的 Asset-Based Scheduling 代表了工作流编排领域自 DAG 模型诞生以来最重要的范式升级之一。传统 Airflow 的定时触发（cron-based）和 Sensor 轮询模型，在数据管道变得跨团队、跨账户、跨区域时暴露出两个结构性缺陷：轮询浪费（每小时数千次空轮询消耗 Worker 资源和 API 配额）和响应延迟（下游 DAG 必须等待下一个轮询周期才能感知上游完成）。

MWAA 这次发布直接解决了这两个问题。通过将 Asset Watcher 部署到 Triggerer 中、利用 SQS 作为跨账户消息总线，Airflow 3.0 的编排模型从”定时轮询”升级为”事件驱动”——这是流处理领域早已完成的范式升级在工作流编排领域的迟到实现。对于 DataInfra 团队，这意味着两件事：(1) 多团队数据管道的 SLA 可以从”T+5分钟”压缩到”T+几秒”；(2) 编排基础设施的成本结构变得更可预测——不再有大量空闲 Worker 在轮询空队列。

放在更大的历史叙事中看，Airflow 的这次升级与 AWS 8 月初密集发布的 Agent 驱动 DataInfra 工具（Spark Agent、MSK Agent Skills）共同构成了一个完整画面：编排层不再只是”定时跑任务”，而是成为事件驱动的数据基础设施神经中枢。当 Spark Agent 自动诊断作业故障、MSK Agent Skills 自动规划 Kafka 迁移、Airflow Asset Watchers 自动感知跨账户数据就绪——运维人员终于可以从”盯监控→手动触发→人工排查”的循环中解放出来。

相关链接

Apache Fluss 毕业为 ASF Top-Level Project：157 位贡献者、千亿级事件验证的流存储层，与 Paimon 共同构成阿里云 OpenLake Lakestream

事件概述

2026 年 8 月 7 日，Apache 软件基金会官方宣布 Apache Fluss 从孵化器毕业成为 Top-Level Project（TLP）。毕业提案以 Incubator PMC 全票通过并经 ASF 董事会批准——这是对项目技术成熟度、社区健康度和治理卓越性的正式认可。Apache Fluss PMC Chair、阿里云 Flink 团队 Staff Engineer Jark Wu（伍翀）在阿里云官方博客上发表署名文章，详述了 Fluss 从阿里内部项目到全球 Apache TLP 的完整历程。

Apache Fluss——全称 Flink Unified Streaming Storage（德语中意为”河流”）——诞生于阿里 Flink 团队在实时数据基础设施中面临的核心痛点：缺乏统一的流批存储层、高昂的计算成本和过于复杂的数据管道。在超过一年的密集开发和阿里内部大规模生产验证后，Fluss 于 2024 年 Flink Forward Asia 上开源，2025 年 6 月进入 ASF 孵化器，仅用一年即完成孵化毕业——速度在 Apache 项目中属于第一梯队。

技术解析

  • Fluss 的核心架构定位：Lakehouse-Native 流存储：Fluss 不是另一个消息队列（如 Kafka）或另一个表格式（如 Iceberg），而是一个位于计算引擎和 Lakehouse 存储之间的流式存储中间层。其核心能力包括四项：(1) 高效列式流存储——基于 Apache Arrow 列式格式，支持服务端列裁剪和下推，减少数据读取和传输量，专为流式分析优化而非通用消息传递；(2) 实时更新与低延迟查询——主键表原生支持流式更新、部分更新、Changelog、KV 查找和 Delta Join，使同一份实时数据既能服务计算又能服务点查；(3) 流与湖统一——持续将实时数据分层沉降到 Apache Paimon、Apache Iceberg、Lance 等开放 Lakehouse 格式，在统一表抽象下兼顾数据新鲜度和成本高效的长周期存储；(4) 开放生态与多语言访问——与 Apache Flink、Apache Spark、StarRocks 等计算引擎协同工作，提供 Java、Rust、Python、C++ 客户端。

  • Lakestream：Fluss + Paimon 的统一实时数仓架构：阿里云的 OpenLake 解决方案将 Fluss 和 Apache Paimon 定位为统一的 Lakestream——Paimon 保存长周期历史数据，Fluss 服务最新数据（亚秒级新鲜度）。通过 Lakestream Union Read 能力（由 Serverless Flink、Serverless Spark 和 EMR StarRocks 驱动），用户和 Agent 可以从单一表视图查询从历史到当下的完整数据——对于需要”从过去到现在的完整上下文”的实时决策和 Agent 操作，这是一个关键的架构能力。阿里云将这一能力定位为 Agentic Lake 愿景的核心支柱——Agent 原生数据引擎与统一语义层的演进方向。

  • 社区健康度与生产验证：截至毕业，Apache Fluss 的社区数据显示了强劲的增长势头——157 位贡献者来自多个国家和组织、2,000+ GitHub Stars、1,700+ 合并 Pull Requests。在生产端，Fluss 已在阿里巴巴、小红书、京东、蚂蚁集团、Fresha、爱奇艺等公司部署，覆盖日志分析、实时数仓、搜索推荐、索引管道和实时特征服务等场景。最关键的数据是：在阿里巴巴 618 购物节峰值期间，Apache Fluss 成功处理了千亿级事件流量——这是对其生产就绪性的最终确认。

行业影响

Apache Fluss 的 TLP 毕业对于 DataInfra 行业有多重意义。首先，它是 Apache 生态中第一个专注”流存储”的 TLP 项目——Kafka 是消息队列、Pulsar 是消息与流平台、Flink 是流计算引擎、Paimon 是流式 Lakehouse 格式——Fluss 填补了”计算（Flink）与存储（Paimon/Iceberg）之间的流存储空白”。这个定位的独特之处在于：Fluss 是”湖原生”的——它的列式存储格式（Arrow）和 Lakehouse 分层沉降机制，意味着它从一开始就为分析查询而非消息传递设计。这与 Kafka 的”日志即存储”哲学形成了对比——Kafka 将消息日志作为持久化层，而 Fluss 将列式流存储作为实时分析加速层。

其次，阿里云通过 Fluss + Paimon 构建了从流计算到流存储到湖存储的完整开源栈——Flink（计算）+ Fluss（流存储）+ Paimon（湖格式）+ Iceberg（开放表格式）。这意味着阿里云的 OpenLake 方案在开源生态布局上已经覆盖了实时 Lakehouse 的所有关键层次。尤其值得注意的是，阿里巴巴选择将 Fluss 和 Paimon 都捐献给 Apache 软件基金会——这确保了流存储和湖格式这两个关键基础设施层的厂商中立性，与 Databricks 通过 Unity Catalog 构建的”以我为主”生态策略形成了差异化路线。

最后，Lakestream 概念代表了实时数仓架构的下一个演进方向。“流批一体”已经从口号进入了工程落地阶段——Fluss 的 Union Read 能力使查询引擎能透明地访问”最新数据（Fluss 列式流存储）+ 历史数据（Paimon/Iceberg）“，用户无需关心数据在哪一层、以什么格式存储。在 Agentic AI 时代，这种透明的实时-历史数据访问能力尤为关键——Agent 需要同时查询”刚刚发生什么”和”历史上类似情况怎么处理”来做决策，而 Lakestream 架构正是为这种”从当下回望历史”的查询模式设计的。

相关链接

编者评

本期四条动态看似覆盖了四个不同的技术层——查询引擎自主化（BigQuery HBO）、数据摄入零代码化（BigQuery DTS + MCP）、编排事件驱动化（MWAA + Airflow 3.0）、流存储标准化（Apache Fluss TLP）——但它们共享一个底层叙事：Agentic AI 时代的数据基础设施，正在从”人驱动的工具”演变为”自驱动的平台”。BigQuery 不再需要 DBA 手动调参——它自己学习、自己优化、自己纠正错误。MWAA 不再需要数据工程师写 Sensor 轮询——它自己监听事件、自己触发下游。BigQuery DTS 甚至不需要人配置数据传输——Agent 可以通过 MCP 自己发现数据源并启动同步。Apache Fluss 不再是一个公司内部的流存储方案——它通过 Apache 治理成为整个行业共享的基础设施标准。

这一叙事与 Vol.42-44 中追踪的”Agent-First DataInfra”趋势形成纵深呼应。Vol.42（08-04）关注的是 Agent 作为运维工具（Spark Agent、MSK Agent Skills），Vol.43（08-05）关注的是基础设施韧性（Redshift DR、YugabyteDB AMP），Vol.44（08-06）关注的是 AI 治理控制面与工程范式（Unity AI Gateway、dbt context engineer）。本期 Vol.45 则进一步将叙事推进到”平台自身的自主化”——不是 Agent 来运维平台，而是平台本身变得 Agentic。

如果用一个词概括 2026 年 8 月第一周 DataInfra 的技术趋势，那就是 Autonomy（自主性）——查询自主优化、数据自主摄入、管道自主编排、存储自主标准化。这四条动态从 Google Cloud、AWS、阿里云三个不同的云厂商发出，但指向了同一个方向：未来的数据基础设施不需要操作员，它自己就是操作员。