datainfra前沿动态 · Vol.46

Gartner 预测 AI 优化 IaaS 支出 2026 年增长 96% 推理首超训练；AWS 发布 Kinesis AI 成本优化 Agent 实现流基础设施自运维；Flink 300M+ RPM 生产调优 13 条实战指南；语义层重现锁隐危机与 Lakehouse 融合进化

本期聚焦四条 DataInfra 动态：Gartner 发布预测报告称 AI 优化 IaaS 支出 2026 年将增长 96% 达 420 亿美元，推理支出首次超越训练成为云基础设施消费主力；AWS 开源 Kinesis Mode Optimizer Agent，基于 Bedrock AgentCore 自动分析全账户流成本并推荐最优容量模式；数据工程师分享 Flink 有状态 Exactly-Once 作业扩展至 3 亿 RPM 的 13 条生产调优指南；DEW #282 追踪语义层重现开放表格式的锁隐危机与 Lakehouse 从列存向全文检索+向量索引的融合进化趋势。

DataInfra Gartner AI IaaS 推理 云基础设施 AWS Kinesis Agent 成本优化 Bedrock AgentCore Apache Flink 流处理 生产调优 Exactly-Once RocksDB Checkpoint 语义层 Lock-in Lakehouse 全文检索 StarTree Iceberg Oracle 融合数据库 Netflix 分布式图

本期追踪到四条 DataInfra 动态，从行业宏观数据到具体工程实践再到架构哲学，共同描摹了一个核心信号：AI 推理正在成为数据基础设施的首要消费者，而基础设施本身也必须学会自优化。2026 年 8 月 10 日，Gartner 发布重磅预测——全球 AI 优化 IaaS 支出将在 2026 年增长 96% 达 420 亿美元，且推理支出（$233 亿）将首次超越训练支出（$190 亿），标志着数据基础设施的消费模式从”批量构建模型”转向”持续实时推理”。同日，AWS 开源了 Kinesis Mode Optimizer Agent——一个基于 Amazon Bedrock AgentCore 的 AI 代理，能自主分析全账户所有 Kinesis 流的 7 天 CloudWatch 指标，生成三种容量模式的三方成本对比并推荐最优方案，标志着流基础设施运维正式进入”AI 代理替代人工巡检”阶段。Data Engineering Weekly #282 追踪到两条深刻影响 DataInfra 架构走向的线索：Mohamed El Zein 发布了将 Flink 有状态 Exactly-Once 作业扩展至 3 亿+ RPM 的 13 条生产级调优指南——涵盖 Kafka 事务池化、RocksDB 压缩策略、Ingest-DB 恢复等硬核主题；与此同时，Yannick Misteli 发出”语义层正重现开放表格式的锁隐危机”警告，而 StarTree 在 Iceberg 上实现全文检索的事件则指向 Lakehouse 从纯列存向融合数据库（Converged Database）的进化。四条动态从行业消费趋势、基础设施自运维、流处理规模化实践到架构锁隐哲学，构成了一幅 AI-first DataInfra 的完整拼图。

Gartner 预测 AI 优化 IaaS 支出 2026 年增长 96% 达 420 亿美元，推理支出首次超越训练

事件概述

2026 年 8 月 10 日，Gartner 发布全球 AI 优化 IaaS 支出预测报告。核心数据为：2026 年全球 AI 优化 IaaS 支出预计增长 96%，达到 420 亿美元；2027 年将继续增长 56.5% 至 661 亿美元。Gartner 高级首席研究分析师 Hardeep Singh 指出，这一增长由 LLM 训练的持续需求和 Agentic AI 在企业应用中的快速落地共同驱动。

更具转折意义的是消费结构的变化：2026 年推理支出（233 亿美元）将首次超越训练支出（190 亿美元），占 AI IaaS 总支出的 55%，且这一比例预计在 2027 年升至 59%。Gartner 明确将这一转变归因于”企业从模型开发转向生产级部署，微调和领域特定模型（DSM）越来越多地集成到面向客户和运营的系统中，需要持续、实时的执行而非周期性训练。”

技术解析

  • 从训练到推理的消费结构转折：这个数据对于 DataInfra 领域而言是一个分水岭信号——过去五年，数据基础设施的投资逻辑主要围绕”批量训练”构建（大规模 GPU 集群、模型检查点存储、训练数据管道）。当推理超过训练时，基础架构的瓶颈点将转移到完全不同的方向：低延迟流式数据摄入、实时特征存储、向量数据库的高并发查询、模型服务网关的弹性扩缩容。这不是一个量的变化，而是一个质的变化——它意味着数据平台的实时性、可用性和运营效率正在取代原始吞吐量，成为第一优先级。

  • Agentic AI 的乘数效应：Gartner 特别强调了 Agentic AI 对推理消费的放大作用——一个 AI Agent 的每次自主执行都涉及多次模型调用（思考、工具选择、结果验证、循环迭代），单次 Agent 任务可能产生 5-50 次推理请求。这使得推理消费不再是”一个用户一个问题一次调用”的线性模型，而是一个带有自反馈循环的复合消费模型。对于数据基础设施而言，这意味着：推理侧的吞吐量预测变得极其困难（Agent 的调用模式不可预测）；流式数据管道的弹性需求大幅增加（Agent 实时查询知识库、检索上下文、更新状态）；数据库和搜索引擎需要在高并发随机访问和高吞吐批量处理之间无缝切换。

  • 79% 的总 IaaS 增速差：Gartner 同时预测总 IaaS 支出在 2026 年增长 29.3% 至 2873 亿美元，AI 优化 IaaS 的 96% 增速是总 IaaS 增速的 3.3 倍，且 AI 优化 IaaS 在总 IaaS 中的占比从 2025 年的 9.7% 跃升至 2026 年的 14.7%。这组数字清楚地表明：AI 基础设施正在从”云计算中的一个专业细分市场”变成”云计算增长的主要引擎”。大型云厂商（AWS/Azure/GCP）未来的资本支出方向、新产品路线图和定价策略，都将越来越紧密地与 AI 工作负载绑定。

行业影响

Gartner 这份预测报告为 DataInfra 行业提供了一个明确的方向性参考框架。推理超越训练的关键拐点意味着：2026-2027 年将是”实时数据基础设施”的黄金窗口期。具体而言，流处理引擎（Flink/Kafka/Kinesis）、实时特征平台（Tecton/Feast）、向量数据库（Pinecone/Milvus/Weaviate）、数据目录和治理工具（Unity Catalog/Polaris/Glue）都将直接受益于推理消费的增长。

从已经追踪到的动态来看，这一趋势正在得到多方面的印证：AWS 连续发布 Spark Troubleshooting Agent、MSK Agent Skills、Kinesis Optimizer Agent 等 AI 驱动的运维工具——这正是”Agentic AI 大量消费实时数据流”的运维侧需求；BigQuery 发布自主性能三件套（Vol.45）——推理工作负载的高并发短查询需要查询引擎的自主优化能力；Databricks Unity AI Gateway GA（Vol.44）——Agent 大量调用模型时需要一个统一的治理控制面来管理 Token 成本。Gartner 的数字不是预测了未来，而是量化和确认了一个已经在发生但被低估了量级的变化。

相关链接

AWS 开源 Kinesis Mode Optimizer Agent：流基础设施成本管理进入 AI 代理时代

事件概述

2026 年 8 月 10 日，AWS 的 Masudur Rahaman Sayem 和 Roy Wang 在 Big Data Blog 上发布了 Kinesis Mode Optimizer Agent——一个开源的、基于 Amazon Bedrock AgentCore 的 AI 代理，专为 Amazon Kinesis Data Streams 的成本优化而设计。该代理自动拉取账户内所有 Kinesis 流的 7 天 CloudWatch 指标，计算三种容量模式（On-demand Standard、On-demand Advantage、Provisioned）的成本对比，并生成每条流的推荐方案和账户级 On-demand Advantage 适用性评估。之前 AWS 的一篇博文已经证明，选择正确的容量模式可以节省 60% 以上的流处理成本，而这个 Agent 将此前需要手动逐条分析的操作完全自动化。

AWS 将整个方案打包为单命令部署的 CDK 栈（cdk deploy），支持按日/周/Cron 定时执行，且可在多 Region 独立部署。Agent 的推理引擎由 Claude Sonnet 4.5 驱动，通过 Bedrock AgentCore Gateway 解释自然语言请求并路由到 MCP 工具。结果同时以可视化 HTML 报告和机器可读 JSON 格式存储在 S3 中。

技术解析

  • Agentic 运维的完整范式演示：Kinesis Optimizer Agent 不是简单的监控告警脚本，而是对”AI Agent 替代人工运维”的一次完整范式演示。其架构包含四个关键层次：(1) 调度层（EventBridge Scheduler + Scheduler Lambda）负责定时触发；(2) 推理层（Bedrock AgentCore Gateway + Claude Sonnet）负责解释意图（“Generate an optimization report”→“我需要分析所有流、计算成本、生成推荐”）；(3) 工具层（Tool Lambda 暴露的 MCP 工具集）负责执行具体操作——ListStreams → DescribeStream → GetMetricData → 三方成本计算 → S3 写入；(4) 呈现层（HTML + JSON 报告）负责将分析结果转化为可行动的推荐。这个四层架构是 Agentic DataInfra 运维的通用模式，可以直接复用到 MSK 集群规模优化、Redshift 工作负载管理、EMR 集群配置推荐等场景。

  • MCP 工具的领域建模：Agent 的工具层实现了三个 MCP 工具——list_kinesis_streams、get_stream_metrics 和 generate_report。这种”将领域能力封装为 MCP 工具供 Agent 调用”的模式，与 AWS 近期发布的 MSK Agent Skills（Vol.42）和 Spark Troubleshooting Agent（Vol.42）一脉相承。这三个工具之间的数据依赖关系（列表→指标→报告）实际上定义了一个”Agent 可执行的运维工作流”——Agent 不需要理解 Kinesis 的定价模型或 CloudWatch 的指标命名规则，它只需要知道”先列流、再取指标、最后生成报告”这个组合逻辑，具体实现封在工具中。

  • “强烈偏好 On-demand”的设计哲学：Agent 的代码中内置了一个明确的偏好——“strongly prefer on-demand modes for their operational simplicity (automatic scaling, no capacity planning, and no throttling risk)“。这反映了一个有趣的趋势：基础设施 Agent 不仅在执行层面替代人工，还在决策层面体现了工程哲学——传统人工运维中，“省钱”和”省心”是两个需要权衡的目标，而这个 Agent 在设计层面将”省心”（自动扩缩、无容量规划、无节流风险）作为默认偏好。这意味着 Agentic 运维不仅仅是自动化，更是一种”编码化的工程判断”。

行业影响

Kinesis Optimizer Agent 的意义远超 Kinesis 本身——它是 DataInfra 运维范式转换的一个清晰信号。回顾过去三个月 AWS 发布的 Agent 工具：Spark Troubleshooting Agent（8 月 3 日）→ MSK Agent Skills（8 月 3 日）→ Kinesis Optimizer Agent（8 月 10 日），AWS 正在以每周一个的速度将核心数据服务接入 Agentic 运维框架。这不是一个单点产品功能，而是一个系统性的平台战略——让每一个数据基础设施组件都配备一个内建的 AI Agent，负责监控、诊断、优化和建议。

从行业演进的角度看，这与本刊多次追踪的”Agent-First DataInfra”叙事（Vol.37-45）高度一致。当 AI Agent 每秒产生数千条流式查询时，人类运维团队不可能手动管理流的容量模式——唯一的出路是让基础设施本身具备自优化能力。Kinesis Optimizer Agent 证明了这个方向的技术可行性：单命令部署、零人工干预、7×24 定时执行、自然语言驱动推理——流基础设施的运维正在从”人盯盘”变成”Agent 盯盘，人看报告”。

相关链接

事件概述

Data Engineering Weekly #282 的编辑精选引用了 Mohamed El Zein 发表的一篇深度技术文章，系统阐述了如何在生产环境中将 Apache Flink 有状态 Exactly-Once 作业扩展到每秒 3 亿条记录（300M+ RPM）。这不是一篇理论综述，而是一份”战地外科手册”——作者直言 Flink 的大规模调优是”解决一个问题触发另一个问题”的痛苦循环，并提炼出 13 条经过生产验证的配置、优化和避坑指南。

文章覆盖了从 Kafka 事务管理、RocksDB 状态后端调优、Checkpoint/Savepoint 策略选择、K8s 自动伸缩陷阱到 S3 存储优化等多个维度，是 Flink 大规模生产运维领域少见的系统性参考资料。

技术解析

  • Kafka 事务池化（Transaction Pooling）：4 小时重启死循环的解药：这是 13 条建议中技术含量最高的一条。在极高吞吐 + 低 Checkpoint 间隔（几十秒级别）的组合下，Flink 会在 Kafka 中产生数十万个事务 ID。当作业重启时，Flink 需要遍历所有历史事务 ID 直到找到属于新 epoch 的事务——这个过程在事务 ID 空间无限增长的情况下，最终导致超时死循环（作者实测 4 小时仍未完成）。TransactionNamingStrategy.POOLING 通过复用事务 ID 池而非单调递增，从根本上消除了这个问题。这条经验在官方文档中很少被强调，但一旦在生产环境中触发，代价极为惨重。

  • V2 异步状态 API 的隐式陷阱：作者明确指出，Flink 的 V2 异步状态 API 在 RocksDB 后端上存在两个致命问题——TTL（Time-To-Live）静默失效（AsyncKeyedStateBackendAdaptor 丢弃了 TTL 设置），以及规范化 Savepoint 完全不支持异步 API。这意味着使用 RocksDB 的团队如果无意中切换到 V2 API（可能是为了利用异步 I/O 提升性能），将面临状态无限膨胀（TTL 失效）和作业升级时 Savepoint 解析失败的严重风险。作者的建议直截了当：“使用 RocksDB 时，坚持使用 V1 状态 API。“这是一个典型的”新功能在文档中看起来很棒，但在生产中有隐藏代价”的案例——RocksDB 至今仍是 Flink 最广泛使用的状态后端。

  • Ingest-DB + 异步压缩的恢复加速组合拳：大状态作业（数百 GB 到 TB 级）的故障恢复是一场与时间的赛跑。作者推荐了一套四配置组合：local-recovery: true（本地恢复）→ use-ingest-db-restore-mode（Ingest-DB 恢复模式，快 2-5 倍）→ async-compact-after-rescale（恢复后异步压缩，解决 Ingest-DB 导致的 SST 文件未合并问题）→ use-delete-files-in-range（清理因扩缩容产生的冗余文件）。这套组合拳在利用 Ingest-DB 恢复加速的同时，通过异步压缩解决了其副作用（首个 Checkpoint 体积爆炸），形成了完整的恢复策略闭环。

行业影响

这篇实践指南的深层价值不仅在于技术细节的本身，更在于它揭示了 Flink 生产化运维的真实复杂度。3 亿 RPM 这个数字本身很惊人，但更值得注意的是达到这个规模所需的认知成本——13 条指南涉及 Kafka 事务、状态后端、Checkpoint、自动伸缩、压缩策略、文件系统等多个领域的深刻理解。这意味着在大规模流处理领域，“经验壁垒”非但没有因工具的成熟而降低，反而在 AI 时代变得更加显著——因为 Agentic 应用对实时数据流的延迟、吞吐和可靠性要求远高于传统 BI 场景。

从 DataInfra 行业的角度看，这篇文章也验证了前文 Gartner 预测中指出的趋势——推理工作负载的增长将直接推高对高性能流处理基础设施的需求。Flink 的 300M+ RPM 不是实验室数字，而是在实际生产环境中服务于实时特征计算、在线推理、流式 ETL 等 Agentic AI 的核心场景。当 AI Agent 每秒发起成千上万次推理调用，每个调用都可能触发实时数据查询时，Flink 这样的流处理引擎已经不再是”一个做实时分析的辅助工具”，而是成为了 AI 数据基础设施的关键路径。

相关链接

语义层锁隐警报与 Lakehouse 融合进化：数据基础设施的两个架构信号

事件概述

Data Engineering Weekly #282 的编辑精选中包含了多条值得关注的行业分析线索，其中两条对 DataInfra 的架构演进具有风向标意义。第一条来自 Yannick Misteli 的观点文章《The Semantic Layer Is Not a Layer Anymore》，作者提出了一个尖锐的警告：语义层正在重复开放表格式曾经经历过的”锁隐”（lock-in）陷阱——标准化的指标定义被每个供应商封装在自己的控制面和访问层中，使得语义层从”可以自由切换的标准协议”变成了”每个平台的自有领地”。第二条来自 Oracle 的融合数据库（Converged Database）概念文章和 StarTree 在 Apache Iceberg 上实现全文检索的技术突破，共同指向 Lakehouse 正在从单纯的列式存储向融合多种数据模型（文本检索、向量索引、图查询）的”全能数据库”方向进化。

技术解析

  • 语义层：从”开放标准”到”围墙花园”的代际重复：Misteli 的核心论点可以概括为：“我们之前用开放表格式解决了存储层的锁隐问题，现在语义层正在以完全相同的方式制造新的锁隐。” 作者将这一过程描述为：“开放表格式给了我们一个标准的轮子。然后每个供应商都加上了自己的目录、治理模型、访问层和控制面——让轮子在移动到别处时变得非常困难。“语义层目前正处于类似的周期中：指标定义（Metrics）本身可能遵循共同的标准（如 dbt 的语义模型），但各平台围绕这些定义构建的计算引擎、权限模型、缓存策略、查询优化却是完全私有的。结果是：企业可以在 Snowflake 上用 SQL 查询同一个 Iceberg 表（数据层开放），但如果想将语义层从 dbt Cloud 迁移到 Looker 或 ThoughtSpot，需要完全重写指标逻辑和依赖关系（语义层锁定）。

  • Lakehouse 从”文件格式+列存”到”融合数据库”的进化路径：StarTree 在 Iceberg 上实现全文检索的技术突破，加上 Oracle 提出的”融合数据库”（Converged Database）概念——区别于传统”多模型数据库”（Multi-Model Database），后者是多个数据库引擎共享同一套基础设施，而融合数据库是在同一个查询引擎内原生支持多种数据模型——描摹出 Lakehouse 进化的下一个方向。回顾过去一年 Lakehouse 的技术积累：Apache Iceberg 1.11.0 引入了 VARIANT 类型（半结构化数据）和删除向量（CDC 支持）；Delta Lake 4.3 通过 Delta Kernel 实现了跨引擎的状态同步（Vol.43 前已报道）；Iceberg Rust 0.10 和 Go 0.6 拓展了多语言生态；现在 StarTree 在 Iceberg 上叠加全文检索，Apache Fluss（Vol.45）补全了流式存储能力。这意味着一个统一的趋势：未来的 Lakehouse 不只是”用 SQL 查询 Parquet 文件”，而是模糊 OLAP、全文检索、向量搜索、流处理和图查询的边界。用 Oracle 的术语来说，这就是从”数据湖上跑多个引擎”转变为”数据湖本身就是一个全能引擎”。

行业影响

这两条信号分别从”不要重复犯的错误”和”正在发生的正确方向”两个角度，为 DataInfra 的架构选型提供了重要的决策参考。

语义层的锁隐警告尤其及时。随着 dbt + Fivetran 合并后加速推进”开放数据基础设施”（Open Data Infrastructure）的愿景，以及 Apache Ossie（原 OSI）进入 ASF 孵化器，语义层的标准化竞赛正在升温。Misteli 的警告提醒我们：标准化不是目的，可移植性才是目的。如果一个语义层的”标准”实际上被单一供应商的执行层绑定，那么这个标准就与 2015 年 Hive Metastore 的”开放标准”没有本质区别。

Lakehouse 的”融合数据库”进化则为 AI-first 数据基础设施提供了一个令人兴奋的技术愿景：当数据不仅以列存格式被高效扫描，还能被全文索引快速检索、被向量引擎语义查询、被流处理引擎实时处理——且这一切都发生在同一套存储系统（Iceberg/Delta）上时，“数据平台”的定义将从根本上被改写。传统的数据架构是”存储 → 引擎 → 应用”的三层模式，而融合数据库的方向是”存储 = 引擎”，所有能力都是表格式的原生扩展。

相关链接

编者评

本期四条动态虽然在主题上跨度极大——从 Gartner 的宏观市场预测到 Flink 的 13 条调优参数、从 AWS 的 Agent 开源代码到语义层的哲学警告——但它们都指向同一个正在成形的行业现实：数据基础设施正在变成 AI 的”操作系统”。Gartner 的数字告诉我们推理正在超过训练——这意味着数据基础设施的主要消费者正在从”训练模型的 ML 工程师”转变为”依赖实时数据的 AI Agent”；AWS 的 Kinesis Agent 告诉我们基础设施本身也必须配备 AI Agent 来自我管理——因为人类运维跟不上 Agentic 工作负载的节奏；Flink 300M+ RPM 指南告诉我们实时流处理已经从”有也可以”变成了生产硬需求；语义层和 Lakehouse 的进化信号告诉我们基础设施的架构需要从”存储+查询”向”语义理解+多模式融合”升级。这不是四个独立的事件——这是一条线索的四根丝线，正在共同编织一个 AI-first DataInfra 的未来。