datainfra前沿动态 · Vol.24

AWS OpenSearch专用日志分析引擎GA以Parquet+DataFusion实现4x性价比；Databricks Lakehouse//RT Beta上线Reyden引擎支撑12K QPS亚百毫秒；BigQuery AI.AGG让单行SQL聚合百万行非结构化数据；AWS Redshift AI性能推荐方案用Bedrock信号关联释放DBA生产力

第二十四期聚焦DataInfra四条动态：7月1日AWS OpenSearch Service推出专用日志分析引擎GA——以Apache Parquet列存+Apache Calcite解析+Apache DataFusion向量化+Lucene倒排四件套实现“按查询路由最佳执行引擎”模式，4x价格性能/2x摄入吞吐/2x查询加速/70%存储成本压缩、1.78M docs/sec峰值摄入、24.4B文档测试集5x压缩、log volume by host查询70x加速——可观测性领域从“通用搜索引擎”走向“专用分析引擎”；6月30日Databricks Lakehouse//RT Beta正式上线——基于全新Reyden异步执行引擎，12000 QPS亚百毫秒、小数据集10ms、大数据集100ms内、16x优于传统实时服务栈、Cisco/Magnite/SES三家客户验证、声明“最佳实时分析引擎就是湖仓”——湖仓从“分钟级分析”走向“毫秒级服务”；6月30日Google Cloud BigQuery AI.AGG函数Preview——单行SQL+自然语言指令对百万行非结构化/多模态数据进行综合分析，多级聚合机制（batching→批次内聚合→跨批次最终聚合）解决LLM上下文窗口与海量数据的矛盾、配合AI.CLASSIFY实现端到端发现-分类-总结工作流——SQL从“查询语言”走向“AI编排语言”；7月1日AWS发布Amazon Redshift AI性能推荐方案——Collector+Analyzer双Lambda+EventBridge每日调度，13条诊断SQL预计算布尔型信号（行倾斜/幽灵行/统计过期/磁盘溢出/小批量INSERT突发）+Bedrock Claude Sonnet 4.6生成优先排序的Top 10建议（critical/high/medium/low），信号-指标关联设计让建议引用具体表名/查询ID/指标值——DBA工作从“经验调优”走向“AI协同调优”。四条动态共同指向数据基础设施的“专用化引擎+AI代理化执行”主线：OpenSearch日志分析引擎专用化可观测性场景（消除通用引擎的over-provisioning），Lakehouse//RT专用化实时分析场景（消除专用服务层的同步复制），BigQuery AI.AGG专用化非结构化聚合场景（消除LLM上下文窗口的硬编码分块），Redshift AI Advisor专用化性能调优场景（消除DBA人工经验扫描）。

DataInfra AWS OpenSearch Service Optimized Log Analytics Engine Apache Parquet Apache DataFusion Apache Calcite Lucene Inverted Index Columnar Storage 4x Price Performance 70% Storage Savings 1.78M docs/sec Observability Databricks Lakehouse Real-Time Lakehouse//RT Reyden Engine Asynchronous Execution 12000 QPS Sub-100ms Latency Delta Lake Apache Iceberg Unity Catalog Cisco Magnite SES BigQuery AI.AGG Multi-level Aggregation AI.CLASSIFY Multimodal SQL AI SQL Primitive Google Cloud AWS Redshift Bedrock Claude Sonnet 4.6 AI Performance Advisor Lambda Collector Lambda Analyzer EventBridge Signal-based Telemetry Row Skew Disk Spill Stale Statistics DBA Automation 数据基础设施 DataInfra前沿动态 Vol.24

第二十四期追踪到DataInfra领域四条重要动态：7月1日AWS OpenSearch Service推出专用日志分析引擎GA（General Availability）——基于Apache Parquet列存+Apache Calcite解析+Apache DataFusion向量化执行+Lucene倒排索引的”四件套”实现”按查询路由最佳执行引擎”模式，实现4x价格性能/2x摄入吞吐/2x查询加速/70%存储成本压缩，在24.4B文档的基准测试中达到1.78M docs/sec峰值摄入、5x压缩、log volume by host查询70x加速——可观测性领域从”通用搜索引擎”走向”专用分析引擎”；6月30日Databricks Lakehouse//RT（Lakehouse Real-Time）Beta正式上线——基于全新Reyden异步执行引擎，12000 QPS亚百毫秒、小数据集10ms、大数据集100ms内、16x优于传统实时服务栈，Cisco（安全威胁查询5x改善）、Magnite（仪表板<200ms）、SES（运营仪表板20x加速）三家客户验证，CEO Ali Ghodsi宣告”最佳实时分析引擎就是湖仓”——湖仓从”分钟级分析”走向”毫秒级服务”；6月30日Google Cloud发布BigQuery AI.AGG函数Preview——单行SQL+自然语言指令对百万行非结构化/多模态数据进行综合分析，多级聚合机制（batching→批次内聚合→跨批次最终聚合）解决LLM上下文窗口与海量数据的矛盾，配合AI.CLASSIFY实现端到端”发现-分类-总结”工作流——SQL从”查询语言”走向”AI编排语言”；7月1日AWS发布Amazon Redshift AI性能推荐方案（Reference Architecture）——Collector+Analyzer双Lambda+EventBridge每日调度，13条诊断SQL预计算布尔型信号（行倾斜/幽灵行/统计过期/磁盘溢出/小批量INSERT突发等）+Bedrock Claude Sonnet 4.6生成优先排序的Top 10建议（critical/high/medium/low），信号-指标关联设计让每条建议引用具体表名/查询ID/指标值——DBA工作从”经验调优”走向”AI协同调优”。四条动态共同指向数据基础设施的”专用化引擎+AI代理化执行”主线：OpenSearch日志分析引擎专用化可观测性场景（消除通用引擎的over-provisioning），Lakehouse//RT专用化实时分析场景（消除专用服务层的同步复制与CDC），BigQuery AI.AGG专用化非结构化聚合场景（消除LLM上下文窗口的硬编码分块），Redshift AI Advisor专用化性能调优场景（消除DBA人工扫描多视图的经验门槛）。

AWS OpenSearch Service专用日志分析引擎GA：Parquet+DataFusion+Lucene四件套，可观测性从通用搜索走向专用分析

事件概述

7月1日，AWS宣布Amazon OpenSearch Service推出专用日志分析引擎（Optimized Log Analytics Engine）正式GA——这是继Vol.21报道OpenSearch Service Serverless安全机制、Vol.18报道OpenSearch Agent Skills后，OpenSearch Service最重要的产品演进。日志分析引擎的核心创新是”按查询路由最佳执行引擎”模式：底层以Apache Parquet存储所有数据，对可搜索字段同时维护Lucene倒排索引；查询由Apache Calcite解析优化后，根据操作类型路由到最佳执行引擎——Apache DataFusion（列存分析操作）或Lucene（搜索谓词），两者可在单个查询中接力执行。性能数据亮眼：相比通用引擎，4x价格性能/2x摄入吞吐/2x查询加速/70%存储成本压缩。在24.4B文档的基准测试中（OTEL logs/traces+Web logs共9.5TB原始JSON），优化引擎以1.78M docs/sec峰值摄入（vs Lucene 647K，2.7x）、80%压缩率（5x vs 原始JSON）、log volume by host查询70x加速、point lookup（单traceId查询）165ms响应——这是云可观测性基础设施的重大技术里程碑。

技术解析

  • Parquet列存+Lucene倒排双索引：让分析与搜索不再互斥：此前OpenSearch Service只有一种通用引擎——所有数据写入倒排索引（适合搜索但空间开销大），所有查询走Lucene（适合搜索但分析性能差）。对于日志分析场景，80%的查询是聚合分析（统计、计数、Top-N），只有20%是关键字搜索——但通用引擎让所有数据都付倒排索引的存储代价，让所有查询都付Lucene的扫描代价。优化引擎引入双索引架构——数据同时以Parquet列存和Lucene倒排存储，Parquet提供5x压缩和列剪枝（column pruning），Lucene提供精确搜索能力。两套索引互相独立，按需选择——聚合查询只读Parquet（消除倒排索引的存储与计算开销），搜索查询只读Lucene（消除列存的扫描开销）。

  • Apache Calcite+DataFusion+Lucene三件套：按查询路由最佳引擎：优化引擎的查询路径是Calcite解析优化→路由决策→引擎执行。Apache Calcite是SQL/PPL解析器与优化器，理解SQL语义并生成最优执行计划；优化引擎的查询计划器根据操作类型决定由哪个引擎执行——聚合、扫描、列裁剪走DataFusion（Rust编写的向量化执行引擎，利用SIMD指令做CPU级并行），精确匹配、词项查询走Lucene。两者可在单个查询中接力——例如SELECT count(*), host FROM logs WHERE content LIKE '%error%' AND time > now() - 15m GROUP BY host的执行流程：Lucene执行content LIKE '%error%'谓词（剪枝到相关shard），DataFusion执行count(*)和GROUP BY host聚合（向量化批处理），最终合并结果。这是”让最合适的引擎做最合适的事”的设计哲学——类似于Vol.22报道的Google Cloud Lightning Engine（Gluten+Velox向量化原生执行），但OpenSearch是查询级别路由，Lightning Engine是任务级别路由。

  • 性能基准：24.4B文档1.78M docs/sec、5x压缩、查询70x加速：基准测试覆盖OTEL traces、OTEL logs、Web logs三类典型可观测性数据，共24.4B文档、9.5TB原始JSON。结果：（1）摄入吞吐1.78M docs/sec vs 647K Lucene（2.7x加速，CPU 62% vs 72%更优，写拒绝0 vs 0）；（2）存储压缩80% vs 52%（5x vs 原始JSON，89% on Web logs），意味着同样存储可保留3x数据；（3）聚合查询加速显著——Error count by service 3.9x、Log volume by host 70x（因为无需倒排索引、只扫描所需列）、5xx errors by service and method 5.2x、Point lookup 2x（虽然走Lucene但剪枝后只需读取目标分片）。其中log volume by host查询70x加速最值得关注——这是典型的”按host分桶统计日志条数”的可观测性仪表板查询，在通用引擎上需要17.6秒，在优化引擎上只需252毫秒。

  • PPL+SQL双查询语言、零迁移成本：优化引擎支持Piped Processing Language（PPL）和SQL两种查询语言，两者都在向量化引擎中原生执行。Domain Specific Language（DSL，OpenSearch传统API）暂不支持。用户通过相同的Bulk API和客户端库摄入数据，无需修改agent、pipeline、应用代码——OpenSearch Service在同一域（domain）下提供”通用引擎”和”优化引擎”两种模式，新域创建时可选，新域迁移到优化引擎是分钟级操作。

  • Lucene保留搜索能力、Calcite跨引擎协调：优化引擎不放弃搜索能力——Lucene倒排索引与Parquet列存共存，查询计划器识别”选择性查找”（如traceId = "abc123"）并路由到倒排索引。在7.4B spans中，单traceId查询165ms返回——这是真正的”调查场景”工作流：先用聚合查询定位问题host/时间窗口（DataFusion），再用traceId查询拉取问题trace细节（Lucene），两个引擎在同一域内接力执行，无需切换系统。

行业影响

AWS OpenSearch Service专用日志分析引擎GA的深层意义不是”又一个搜索引擎性能优化”，而是可观测性领域从”通用搜索引擎”走向”专用分析引擎”的范式转变。

此前云可观测性的标准做法是”通用搜索引擎+倒排索引”——Splunk、Elasticsearch、OpenSearch都用Lucene作为核心，所有数据入倒排索引，所有查询走Lucene扫描。这个设计源自”搜索是核心需求”的假设，但对日志分析场景而言是over-provisioning——日志场景80%是聚合查询，只有20%是关键字搜索。优化引擎的”Parquet列存+Lucene倒排双索引+按查询路由”设计，正是对这一over-provisioning的纠正：让数据存储按场景需求（Parquet压缩+Lucene搜索能力），让查询执行按操作类型（DataFusion聚合+Lucene谓词）。

将本期与Vol.22报道的Google Cloud Lightning Engine对比，两者都代表了”按查询/任务类型选择最佳执行引擎”的设计哲学。Lightning Engine用Gluten+Velox做任务级别路由（批处理任务用C++向量化执行，小任务用JVM执行）；OpenSearch优化引擎用Calcite做查询级别路由（聚合用DataFusion，谓词用Lucene）。这是”专用化执行”在两个不同维度的落地——任务级别和查询级别。当Snowflake、BigQuery、DuckDB、Flink都开始”按操作类型选择执行引擎”（向量化/标量、JIT/AOT、列存/行存）时，“专用化执行”成为数据基础设施的共识范式。

将本期与Vol.18报道的OpenSearch Agent Skills对比，OpenSearch Agent Skills让AI代理通过MCP协议搜索可观测性数据，优化引擎让AI代理的搜索更快、更便宜——AI代理的可观测性场景特别吃查询性能（AI代理可能每秒发起数十次日志查询），4x价格性能意味着AI代理的可观测性成本降低4倍。当AI代理成为可观测性的主要使用者时，“专用分析引擎”是AI代理时代可观测性的必要条件——通用引擎的高延迟和高成本无法支撑AI代理的实时推理需求。

将本期与Vol.20报道的Apache Iceberg C++ 0.3.0（原生C++计算引擎）对比，OpenSearch优化引擎用Rust+DataFusion向量化执行，Iceberg C++用C++原生引擎——两者都通过”原生编译型语言+向量化执行”消除JVM/解释型的开销。DataFusion（Rust）和Velox（C++）正在成为数据基础设施的”向量化执行标准”——Apache Arrow生态让两个项目可以共享数据格式与执行原语，OpenSearch的”Calcite+DataFusion”架构和Databricks的”Gluten+Velox”架构本质上是同一设计哲学的不同实现。

相关链接

Databricks Lakehouse//RT Beta上线：Reyden异步执行引擎12000 QPS亚百毫秒，湖仓从分钟级分析走向毫秒级服务

事件概述

6月30日，Databricks正式开放Lakehouse//RT（Lakehouse Real-Time）Beta——这是继Vol.22报道Lakehouse//RT在DAIS 2026发布后的重要里程碑。Lakehouse//RT基于Databricks全新研发的Reyden异步执行引擎，直接对Delta Lake和Apache Iceberg表进行亚秒级SQL查询，无需数据复制/移动/CDC管道，无需独立的服务层（Redis/Cassandra/Druid），无需独立治理层（与Unity Catalog原生集成）。性能数据惊艳：在标准分析基准上，12000 QPS亚百毫秒（sub-100ms）、小数据集10ms、大数据集100ms内、最多16000并发用户和AI代理同时访问、16x优于传统专用实时服务栈。早期客户验证：Cisco（安全威胁查询5x响应时间改善）、Magnite（核心仪表板查询<200ms）、SES（数十亿行遥测运营仪表板20x加速，淘汰独立服务系统）。Lakehouse//RT Beta意味着Databricks湖仓从”ETL+CDC+专用服务系统”的复杂架构，走向”湖仓就是实时服务”的极简架构。

技术解析

  • Reyden异步执行引擎：从”同步执行”到”异步执行”：传统分析引擎是同步执行模型——查询进入后驱动线程占用，等待I/O完成后再执行计算，多个查询需要多线程并发（线程数受CPU核心数限制），高并发时延迟急剧上升（线程上下文切换+CPU争用）。Reyden是全异步执行模型——查询任务以协程（coroutine）形式调度，I/O等待期间让出CPU，CPU密集计算期间不阻塞其他查询。异步模型让Reyden的并发度从”CPU核心数×线程”扩展到”百万级协程”——这是从”线程级并发”到”协程级并发”的范式跳跃，让Reyden可以在同样硬件下支撑10x+并发查询。基准测试结果：在12,000 QPS下保持亚百毫秒延迟，吞吐上升时延迟不退化。

  • 直接查询Delta/Iceberg表：消除同步复制与CDC：此前企业搭建实时分析系统的标准做法是”Kafka CDC→专用服务系统（Redis/Cassandra/Druid/Pinot）→反范式化数据模型”——这个架构有三个核心问题：（1）数据滞后——CDC管道延迟通常30秒到5分钟，AI代理无法在”现在”查询数据；（2）数据复制成本——同一份数据存两份（湖仓+服务系统），存储成本翻倍；（3）治理脱节——服务系统的访问控制需独立维护，治理裂缝导致”湖仓合规但服务系统不合规”。Lakehouse//RT直接对Delta/Iceberg表执行查询——无需Kafka、无需CDC、无需反范式化、无需服务系统。Reyden的优化器理解Delta/Iceberg文件格式（min/max统计、Z-order、Liquid clustering、删除向量），直接定位最相关的文件并向量化读取，延迟从”分钟级”降到”毫秒级”但数据保持”现在时”。

  • 原生Unity Catalog治理：消除治理脱节：Lakehouse//RT所有查询都在Unity Catalog治理框架内执行——访问控制（ABAC）、行级安全（Row-Level Security）、列级掩码（Column Masking）、审计日志（Audit Log）原生支持。这与Vol.16报道的Databricks Cross-Engine ABAC（Unity Catalog通过Scan API在Spark/DuckDB/Starburst强制执行治理）形成呼应——Unity Catalog成为跨引擎的统一治理层，Lakehouse//RT加入这一治理层后，“湖仓的毫秒级服务”和”专用服务系统的毫秒级服务”在治理层面达到同等合规水平。

  • 预聚合物化视图：支持复杂分析而不只是简单查询：Lakehouse//RT不只是简单key-value查询引擎——它支持完整的SQL（ANSI-compliant），包括JOIN、聚合、子查询。对于复杂分析查询，建议预先物化（materialized views）——Databricks的AI-driven predictive optimization自动管理物化视图。这与Vol.14报道的Databricks Liquid Clustering（AI驱动表优化）异曲同工——AI驱动的物化视图管理让Lakehouse//RT在复杂查询场景下也保持亚秒级延迟。

  • 实际生产案例：Cisco/Magnite/SES三例验证：三家客户验证了Lakehouse//RT的生产可用性。Cisco（安全威胁查询）——“威胁查询需要持续低延迟，即使跨用户和代理扩展”——Lakehouse//RT实现5x响应时间改善，让Cisco可以把安全查询工作负载从独立服务系统迁移到湖仓。Magnite（广告平台）——平台每秒处理数百次实时性能数据查询——Lakehouse//RT实现核心仪表板查询<200ms，“延迟和一致性直接影响产品体验”。SES（卫星通信）——数十亿行遥测数据——Lakehouse//RT实现20x加速，淘汰独立服务系统，减少运维成本。

行业影响

Databricks Lakehouse//RT Beta的深层意义不是”又一个实时分析产品发布”，而是湖仓从”分钟级分析”走向”毫秒级服务”的范式跃迁。

此前湖仓的定位是”分析”——分钟级延迟、批处理为主、面向BI和数据科学。实时服务（毫秒级）由专用系统（Redis、Cassandra、Druid、Pinot、Materialize）承担，湖仓和实时服务是两个独立系统。Lakehouse//RT打破这一边界——湖仓直接成为实时服务。这与Vol.22报道的Delta Lake 4.3（Delta Kernel成为Spark/DuckDB/Flink共享表统一内核）和Vol.21报道的AWS EMR Spark 4.0（Spark直查Iceberg）异曲同工——都是”统一执行层”的方向——Spark既能分析也能服务、Flink既能流处理也能批处理、Delta/Iceberg既是分析表也是服务表。Lakehouse//RT完成了湖仓→实时服务的最后一块拼图。

将本期与Vol.14报道的Databricks Liquid Clustering对比，Liquid Clustering让湖仓的列存数据布局更适配查询模式（行级并发替代文件级），Lakehouse//RT让湖仓的执行引擎适配实时场景（异步执行+亚秒级）。两者结合——Liquid Clustering优化数据布局，Lakehouse//RT优化执行路径——让湖仓的查询性能从”分钟级”推到”毫秒级”。当湖仓可以同时支撑BI仪表板（分钟级）、数据科学（Jupyter notebook分钟级）、实时服务（毫秒级）时，企业不再需要为不同延迟需求搭建不同系统——这是DataInfra的”系统整合”主线。

将本期与Vol.18报道的Snowflake Cortex AISQL对比，Cortex AISQL将AI操作符作为SQL一等原语（让SQL可以调用AI），Lakehouse//RT将湖仓表作为实时服务对象（让湖仓可以替代服务系统）。两者方向相反但殊途同归——Cortex AISQL让SQL向上扩展到AI能力，Lakehouse//RT让湖仓向下扩展到服务能力。当SQL可以调用AI、湖仓可以承担服务时，数据基础设施的能力边界被打破——单一系统可以承担更多工作负载，企业数据栈的复杂度持续降低。

相关链接

Google Cloud BigQuery AI.AGG函数Preview：多级聚合机制让SQL成为AI编排语言

事件概述

6月30日，Google Cloud发布BigQuery AI.AGG函数Preview——这是继Vol.23报道BigQuery Conversational Analytics GA、Vol.11报道Snowflake Cortex AISQL、Vol.15报道Snowflake CoCo平台化、Vol.22报道Databricks Genie Ontology后，AI代理与数据基础设施融合的又一重要里程碑。AI.AGG是BigQuery的新型AI函数，允许用户通过单行SQL+自然语言指令对百万行非结构化/多模态数据进行总结与综合分析。核心技术是多级聚合机制（multi-level aggregation）——LLM上下文窗口有限，AI.AGG自动将输入行分批（batching）→批次内聚合→跨批次最终聚合，让用户可以像写GROUP BY一样对海量文本/图像数据进行AI驱动的总结。配合AI.CLASSIFY等AI函数，AI.AGG实现端到端”发现-分类-总结”工作流——例如”先发现产品类别（AI.AGG返回JSON）→按类别打标签（AI.CLASSIFY）→按类别总结特征（AI.AGG）“。BigQuery AI.AGG Preview意味着SQL从”查询语言”走向”AI编排语言”。

技术解析

  • 多级聚合机制：解决LLM上下文窗口与海量数据的矛盾：传统LLM API的输入受限于上下文窗口（即使Gemini 1.5 Pro有2M token，仍不足以处理百万行日志），用户必须手动分块（将数据切成N份，每份调用LLM，然后聚合结果）——这要求用户编写复杂的应用代码。AI.AGG的多级聚合机制是自动化的：第一级，BigQuery将输入行按LLM上下文窗口分批（例如每批1000行）；第二级，每批内调用LLM生成中间摘要（如每1000行生成200 token摘要）；第三级，所有中间摘要再次输入LLM生成最终摘要（如200×200=40,000 token可以装入上下文窗口）。整个分块-聚合过程对用户透明——用户只需写SELECT AI.AGG(content, '总结这些日志') FROM logs GROUP BY component即可。自动化的多级聚合让”用LLM分析海量数据”成为SQL的一等公民能力。

  • 多模态支持：文本+图像作为输入：AI.AGG支持文本（字符串/文件引用）、图像（通过外部对象表Object Table）作为输入——这让SQL可以分析Cloud Storage中的图像（无需先OCR或预处理）。例如对产品图片做”主要类别发现”——SELECT AI.AGG(STRUCT(OBJ.GET_ACCESS_URL(ref, 'r')), 'What are the major categories?') FROM product_images——BigQuery自动为每张图片生成对象表引用（access URL），AI.AGG处理图像并返回类别列表。多模态SQL让”用LLM分析图像/视频/音频”成为标准SQL能力，无需调用Cloud Vision API等独立服务。

  • NULL智能处理与陷阱：AI.AGG自动跳过NULL输入行——但有一个关键陷阱：当传入STRUCT时，STRUCT中任何一个字段为NULL，整行被跳过（类似CONCAT()）。最佳实践是用IFNULL()为关键字段提供fallback值（IFNULL(description, 'No description')）。这与Vol.11报道的Snowflake Cortex AISQL的NULL处理类似——AI函数需要明确的输入质量保障。

  • Token使用与最佳实践：由于多级聚合结构，总输入token数可能高于原始数据（取决于聚合轮次）——例如3级聚合可能让token数膨胀3-5倍。最佳实践是用LIMIT限制行数、在上游预过滤。这是AI函数相对于传统SQL函数的”成本特性”——用户需要理解”调用AI的成本”。

  • 端到端工作流：发现-分类-总结的SQL组合：AI.AGG的真正威力在于与其他AI函数组合形成端到端工作流：（1）发现阶段——AI.AGG(content, 'What are the major categories?')返回类别列表的JSON字符串；（2）结构化阶段——JSON_VALUE_ARRAY()将JSON解析为ARRAY<STRING>，存入变量；（3）分类阶段——AI.CLASSIFY(content, generated_labels)为每行打标签；（4）总结阶段——按标签GROUP BY后再次AI.AGG()生成类别总结。整个工作流是纯SQL，无需应用代码——这与Vol.22报道的Databricks Genie Ontology（让AI代理理解企业数据上下文）和Vol.18报道的Snowflake Cortex AISQL（AI操作符作为SQL一等原语）异曲同工，都是让”AI能力”成为SQL的内建操作。

  • 指定模型端点：生产环境建议显式指定：AI.AGG允许用户指定模型端点（endpoint => 'gemini-2.5-flash'或完全限定的Vertex AI Model Garden URL）。生产环境强烈建议显式指定——否则AI.AGG使用”近期版本”模型，可能随时间变化导致行为不一致。

行业影响

BigQuery AI.AGG Preview的深层意义不是”又一个AI SQL函数”，而是SQL从”查询语言”走向”AI编排语言”的范式转变。

此前用LLM分析海量数据的工作流是”应用代码 + LLM API + 自建分块逻辑”——需要开发者写Python/JavaScript代码、调用LLM API、手动实现分块、解析结果、存储。这与Vol.18报道的Snowflake Cortex AISQL”SQL调用AI”是同一方向，但AI.AGG更进一步——SQL不仅调用AI，还编排多步AI调用（多级聚合、发现-分类组合）。当SQL可以表达”先聚合再总结”、“先发现再分类”等多步AI工作流时，SQL成为”AI工作流的声明式语言”。

将本期与Vol.18报道的Snowflake Cortex AISQL对比，Cortex AISQL提供AI_FILTER/AI_JOIN/AI_AGG/AI_CLASSIFY/AI_GENERATE等AI操作符，BigQuery AI.AGG是其中AI.AGG的Preview——两者在”AI作为SQL操作符”方向上一致，但BigQuery AI.AGG的多级聚合机制更成熟（自动分块、对用户透明），Snowflake Cortex AISQL当时报道时未提及多级聚合。这与Vol.22报道的Databricks Genie Ontology（权威图谱+PageRank判定）形成”AI SQL操作符”的三个支柱：Snowflake的AI操作符（基础）→BigQuery的AI.AGG（多级聚合）→Databricks的Genie Ontology（业务上下文）。三者共同推动SQL的”AI化”演进。

将本期与Vol.23报道的BigQuery Conversational Analytics GA对比，Conversational Analytics让AI代理生成SQL、用户用自然语言提问，AI.AGG让SQL直接调用AI、用户在SQL中表达AI调用。Conversational Analytics是”自然语言→SQL”的接口，AI.AGG是”SQL→AI调用”的能力。两者结合——用户用自然语言提问，BigQuery生成包含AI.AGG的SQL，自动调用AI分析海量非结构化数据——形成”自然语言→AI增强SQL→数据洞察”的端到端工作流。当自然语言成为AI代理时代的SQL前端时，AI.AGG等AI函数让SQL的”AI增强”成为可能。

将本期与Flink 2.3.0的FLIP-564（FROM_CHANGELOG/TO_CHANGELOG SQL算子）对比，Flink让SQL表达”Changelog”（变更流），AI.AGG让SQL表达”AI聚合”（LLM分块总结）。两者方向相反——Flink SQL向下扩展到流处理原语，AI.AGG SQL向上扩展到AI原语。当SQL可以表达流处理、可以表达AI调用、可以符合SQL标准（Trino 482 Vol.23）时，SQL成为”分布式+流式+AI”的统一语言。这与Vol.23”协议标准化+代理化执行”的主线一致——SQL作为人机协议，覆盖流处理、标准SQL、AI调用、跨数据源执行。

相关链接

AWS Redshift AI性能推荐方案：Bedrock Claude Sonnet 4.6信号关联让DBA从经验调优走向AI协同调优

事件概述

7月1日，AWS发布Amazon Redshift AI性能推荐方案（Reference Architecture）——这是继Vol.23报道AWS Redshift多仓库功能、Vol.14报道Redshift RG实例、Vol.18报道Cortex AISQL后，Redshift在AI协同运维方向的最新实践。方案由两个AWS Lambda函数（Collector+Analyzer）+Amazon EventBridge定时器组成，每日自动运行：（1）Collector Lambda运行13条诊断SQL（面向SYS_QUERY_HISTORY/SVV_TABLE_INFO/SVV_ALTER_TABLE_RECOMMENDATIONS等系统视图）+采集CloudWatch多维度指标（容量/查询/WLM/连接数/存储），预计算布尔型性能信号（行数据倾斜/幽灵行/统计信息过期/磁盘溢出/小批量INSERT突发等），将JSON遥测写入S3；（2）Analyzer Lambda从S3读取遥测，构建结构化Prompt（含”已触发信号”+CloudWatch指标>> CORRELATION关联行+过滤后的支撑数据+显式返回格式指令），调用Amazon Bedrock上的Anthropic Claude Sonnet 4.6生成优先排序的Top 10建议（critical/high/medium/low），通过SNS发送邮件摘要。信号-指标关联是核心创新——LLM不直接读原始视图，而是读”已计算的信号+相关联的指标”，让建议引用具体表名/查询ID/指标值。这与Vol.18报道的Snowflake Cortex AISQL（AI操作符）和Vol.22报道的Databricks Genie Ontology（业务上下文）是同一方向——让AI代理理解数据基础设施的”语义”。

技术解析

  • 信号-指标关联设计：不让LLM做”侦探”：传统AI-DBA方案让LLM直接读SYS_QUERY_HISTORY等系统视图——但系统视图有数千行、LLM的token预算有限、LLM容易”幻觉”出错误的关联。信号-指标关联是相反的设计——应用层先预计算布尔型/阈值型发现（如”表X有行倾斜=true”、“查询Y有磁盘溢出=true”），让LLM只读”已计算的事实+对应的CloudWatch指标”——LLM的工作从”在海量数据中找规律”降级为”在已标记的事实中找因果”，大幅提升建议的精确度。这是”declarative signals + correlation”的典型模式——应用层做计算密集型工作，LLM做语义理解型工作。

  • 三层Prompt结构：触发信号+CloudWatch指标+支撑数据+指令：build_prompt()函数生成的四段式Prompt：（1）第一段列出已触发的信号（如”表X: row_skew=true, stale_stats=true”）；（2）第二段附加CloudWatch指标，使用>> CORRELATION标注行将每个信号与支撑指标配对（如”行倾斜=table X, 关联指标=QueryRuntimeBreakdown增长20%”）；（3）第三段包含过滤后的支撑数据，仅限于触发信号的表与查询行；（4）第四段是显式指令——“返回以竖线分隔的文本，每条建议引用具体表名、查询ID、指标值”。四段式设计让LLM的输出”自带证据”——用户看到”建议X”时能立即看到”由信号Y触发+关联指标Z”，可追溯、可审计。

  • 预计算信号集：覆盖表级、运行时、高级场景三大类：compute_signals()函数预计算的信号集包括：（1）表级信号——行数据倾斜（row skew）、幽灵行（ghost rows）、统计信息过期（stale statistics）、未排序数据（unsorted data）、排序键/分布键次优、VARCHAR列过大；（2）运行时与工作负载信号——磁盘溢出（disk spill）、小批量INSERT突发（small-insert bursts）、高频DDL执行、COPY文件大小未优化；（3）高级场景信号——Redshift Spectrum查询未能剪裁分区、数据共享物化视图执行全量刷新、WLM配置缺少QMR（Query Monitoring Rules）。信号集是”Redshift运维审查Playbook”的形式化——资深DBA的调优经验被编码为可重复执行的信号检查，新手DBA可以立即获得”专家级”的调优建议。

  • Bedrock配置：Claude Sonnet 4.6 + 16384 max_tokens：方案使用us.anthropic.claude-sonnet-4-6（支持多区域推理）作为LLM。客户端配置read_timeout=600（10分钟超时）、max_tokens=16384（确保完整建议输出）。推理耗时对完整遥测负载通常2-4分钟——意味着每日分析在合理时间内完成。多区域推理支持让方案在AWS各区域可用，符合企业数据驻留要求。

  • 推荐输出结构：可执行的SQL/配置动作：每条建议包含字段：（1）优先级（critical/high/medium/low）；（2）类别（query_optimization/table_design/capacity/wlm/maintenance/ingestion）；（3）signal_source（触发该建议的信号和CloudWatch指标名称）；（4）plain-language explanation（通俗解释）；（5）specific SQL/configuration action（具体SQL或配置动作）；（6）expected impact estimate（预期影响估计）。“specific SQL/configuration action”是核心价值——LLM不只说”表X有行倾斜”，而是给出”ALTER TABLE X ALTER DISTKEY new_dist_key; ANALYZE X;“这样的可立即执行的SQL。

  • 完整部署参考：IAM角色+Secrets Manager+SNS邮件+EventBridge每日调度：方案提供完整参考实现——IAM角色redshift-performance-recommendations-role授予Redshift Data API/S3/SNS/Bedrock/Lambda/CloudWatch Logs/CloudWatch Metrics最小权限，Secrets Manager存储数据库管理员凭证（避免硬编码），SNS主题redshift-performance-recommendations发送Email摘要，EventBridge规则redshift-performance-daily每日触发Collector。完整参考实现降低了企业采纳门槛——开发者可以”复制-粘贴”部署，立即获得价值。

行业影响

AWS Redshift AI性能推荐方案的深层意义不是”又一个AI-DBA产品”，而是DBA工作从”经验调优”走向”AI协同调优”的范式转变。

此前DBA调优Redshift工作流是”手动查视图+凭经验关联+凭直觉给建议”——DBA在SYS_QUERY_HISTORY中找慢查询，关联SVV_TABLE_INFO看表设计，再关联CloudWatch看WLM状态，整个过程可能耗费数小时。资深DBA的调优经验是关键，但经验难以传承、难以规模化——新DBA需要数年才能积累类似经验。AI性能推荐方案将”资深DBA的调优经验”编码为”预计算信号集+LLM语义关联”——新DBA可以立即获得”专家级”的调优建议，资深DBA的时间被释放到更高价值的架构工作。

将本期与Vol.22报道的Databricks Genie Ontology对比，Genie Ontology构建企业数据上下文的”权威图谱”（用PageRank式算法判定权威性），Redshift AI性能推荐方案构建Redshift运维上下文的”信号-指标关联”（预计算布尔信号+LLM语义理解）。两者都是”让AI代理理解数据基础设施的语义”——Genie让AI代理理解”业务指标是什么”，Redshift Advisor让AI代理理解”性能问题是什么”。两者共同推动”AI代理+数据基础设施”的深度融合——AI代理不仅能回答业务问题（Genie），还能诊断基础设施问题（Redshift Advisor）。

将本期与Vol.18报道的Snowflake Cortex AISQL（AI操作符）对比，Cortex AISQL让SQL调用AI，Redshift Advisor让AI调用基础设施诊断——方向相反但都是”AI与数据基础设施的双向融合”。Cortex AISQL是”SQL→AI”（用户写SQL，调用AI能力），Redshift Advisor是”AI→基础设施”（LLM读遥测，输出运维建议）。当AI可以调用基础设施诊断、SQL可以调用AI能力时，AI代理成为”数据基础设施的统一用户”——无论是分析数据还是运维数据，AI代理都是入口。

将本期与Vol.15报道的Snowflake CoCo平台化（Desktop+Cloud Agents+Automations+Skill Catalog）对比，CoCo让AI代理成为”开发全表面平台”，Redshift Advisor让AI代理成为”DBA助手”。CoCo覆盖开发场景，Redshift Advisor覆盖运维场景——两者都是”AI代理的领域专业化”——AI代理不只是通用聊天机器人，而是特定领域的”专家”（开发专家、运维专家）。当AI代理在不同领域专业化时，“AI代理+人类专家”的协作模式成为企业新常态——AI代理处理重复性工作（生成建议、关联指标），人类专家处理创造性工作（架构设计、决策审批）。

相关链接

编者评

第二十四期的四条动态，从不同层面共同指向数据基础设施的”专用化引擎+AI代理化执行”主线——通过专用化引擎消除over-provisioning，通过AI代理化执行降低使用门槛。

第一个层面是专用化引擎的演进：AWS OpenSearch日志分析引擎用Parquet+DataFusion+Lucene四件套实现”按查询路由最佳执行引擎”模式。 此前云可观测性的标准做法是”通用搜索引擎+倒排索引”——但对日志分析场景是over-provisioning，80%的聚合查询付了Lucene扫描的代价。优化引擎引入双索引架构——Parquet列存+Lucene倒排共存，Calcite解析查询后按操作类型路由到DataFusion（向量化聚合）或Lucene（精确搜索），两者可在单查询中接力。4x价格性能、2x摄入吞吐、70%存储成本压缩、log volume by host查询70x加速、1.78M docs/sec峰值摄入——这是云可观测性的重大技术里程碑。当可观测性需求从”通用搜索”走向”专用分析”时，“专用化执行”成为可观测性引擎的共识范式。将本期与Vol.22报道的Google Cloud Lightning Engine（任务级别路由：Gluten+Velox向量化）对比，两者都是”按执行类型选择最佳引擎”的范式——任务级别路由（Lightning Engine）和查询级别路由（OpenSearch优化引擎）殊途同归，都让”专用化执行”成为数据基础设施的共识设计哲学。

第二个层面是湖仓实时服务的范式跃迁：Databricks Lakehouse//RT Beta用Reyden异步执行引擎支撑12000 QPS亚百毫秒。 此前湖仓的定位是”分钟级分析”，实时服务由独立系统（Redis/Cassandra/Druid）承担——数据复制+CDC+治理脱节三大问题困扰企业。Lakehouse//RT直接对Delta/Iceberg表执行亚秒级查询，无需数据复制、无需CDC管道、无需独立治理层（与Unity Catalog原生集成）。Reyden的全异步执行模型用协程替代线程，并发度从”CPU核心数”扩展到”百万级协程”——12,000 QPS下延迟不退化。当湖仓可以同时支撑BI（分钟级）、数据科学（分钟级）、实时服务（毫秒级）时，企业不再需要为不同延迟需求搭建不同系统——这是DataInfra的”系统整合”主线。Cisco（5x改善）、Magnite（<200ms）、SES（20x加速、淘汰独立服务系统）三家客户的验证让Lakehouse//RT从Demo走向生产。

第三个层面是SQL的AI编排能力：BigQuery AI.AGG Preview让单行SQL+自然语言指令对百万行非结构化/多模态数据进行综合分析。 AI.AGG的多级聚合机制（自动batching→批次内聚合→跨批次最终聚合）解决LLM上下文窗口与海量数据的矛盾——用户无需写应用代码，BigQuery自动完成分块。多模态支持让SQL可以分析Cloud Storage中的图像（无需Cloud Vision API）。配合AI.CLASSIFY等AI函数，AI.AGG实现端到端”发现-分类-总结”工作流——纯SQL，无需应用代码。当SQL可以表达”先聚合再总结”、“先发现再分类”等多步AI工作流时，SQL成为”AI工作流的声明式语言”。这与Vol.23报道的BigQuery Conversational Analytics GA（自然语言→SQL接口）形成”自然语言→AI增强SQL→数据洞察”的端到端闭环——用户用自然语言提问，BigQuery生成包含AI.AGG的SQL，自动调用AI分析海量非结构化数据。

第四个层面是DBA的AI协同调优：AWS Redshift AI性能推荐方案用Bedrock Claude Sonnet 4.6信号关联让DBA从经验调优走向AI协同调优。 方案的信号-指标关联设计是核心创新——应用层先预计算布尔型/阈值型发现（行倾斜、幽灵行、统计过期、磁盘溢出等），让LLM只读”已计算的事实+对应的CloudWatch指标”——LLM工作从”在海量数据中找规律”降级为”在已标记的事实中找因果”，大幅提升建议的精确度。信号集是”资深DBA调优经验的形式化”——新DBA可以立即获得”专家级”的调优建议，资深DBA的时间被释放到架构工作。当资深DBA的经验被编码为”信号+关联”时，AI代理成为”数据基础设施的运维专家”——AI代理不仅能回答业务问题（Genie），还能诊断基础设施问题（Redshift Advisor）。

将二十三期与本期串联，数据基础设施正在从”工具集合”走向”专用化执行+AI代理化”的双层架构。 工具集合阶段（2010-2020）——Hadoop生态、Spark、Flink、Kafka、Airflow等工具各自演进，工具间的集成需要胶水代码。专用化执行阶段（2020-2026）——Iceberg REST Catalog、Delta REST API、Open Knowledge Format、Flink Native S3等协议标准让不同工具可以互操作，Lightning Engine、OpenSearch优化引擎、Lakehouse//RT等专用化执行让不同场景获得最优性能。AI代理化阶段（2026-）——BigQuery Conversational Analytics、Databricks Genie Agents、BigQuery AI.AGG、Redshift AI Advisor等AI代理让自然语言成为数据访问的统一接口，让”业务人员”和”DBA”都可以通过AI代理完成工作。当数据基础设施完成”工具→专用执行→AI代理”的演进时，数据访问和运维的门槛将从”专业技能”（写SQL、调集群、配置管道、DBA经验）降低到”自然语言+AI协同”（直接提问、AI自动诊断）——这将释放巨大的数据价值，让更多业务人员可以独立完成数据分析，更多资深DBA的时间可以投入到架构工作。这对DataInfra从业者的启示是：未来5年的核心竞争力是”让数据和基础设施更易被AI代理使用”——通过专用化执行提升特定场景的性能，通过AI代理化让AI成为数据和基础设施的统一用户。当AI代理成为”数据访问+基础设施运维”的统一入口时，掌握”如何让AI代理更好使用数据”的工程师将成为最有价值的人才——他们是”AI代理时代的数据基础设施架构师”。