ClickHouse Agents让分析数据库走向代理原生分析平台；多阶段分布式查询执行引入交换操作符实现2.1倍TPC-H加速；Databricks Lakebase CDF让OLTP变更捕获原生接入湖仓

第十一期追踪到DataInfra领域三条重要动态：ClickHouse 5月27日在Open House 2026发布ClickHouse Agents——这是分析数据库首次将AI代理分析作为一等工作负载纳入平台核心，基于Claude的完全托管代理分析服务以无代码Agent构建器（聊天界面/沙箱代码解释器/可共享工件/技能管理/记忆/多Agent工作流）让任何人定义和部署基于ClickHouse数据的分析代理，MCP原生集成让代理从任意兼容系统拉取上下文，AWS Agent Registry原生集成连接云上代理生态，Agentic Data Stack将ClickHouse+LibreChat（2025年11月收购）+Langfuse组合为”存储+交互+可观测”一站式代理分析栈——ClickHouse从”最快的分析数据库”正式走向”代理原生的分析平台”；同日ClickHouse发布多阶段分布式查询执行（私有预览）——引入交换操作符核心抽象将中间数据在执行阶段间自由移动，GatherExchange/ShuffleExchange/BroadcastExchange/ScatterExchange四种模式覆盖从单播到多播到重分区的全部数据移动需求，TPC-H 100GB 8节点总体2.1倍加速/扫描主导查询7.4倍加速/多JOIN查询2-5倍加速/内存需求从16GiB降至每节点2GiB——这是ClickHouse Cloud从单节点分析引擎走向MPP式分布式引擎的架构性跃迁，配合CostBench开放基准（ClickHouse Cloud成本效能为最近竞争对手的23倍）共同强化分析引擎层竞争力；Databricks 5月27日发布Lakebase CDF（公开预览）——OLTP行级变更原生捕获为Unity Catalog托管表，无需数据库连接器/无需监控复制状态/无需独立提取作业，SDP流式管道/DBSQL物化视图/Agent Bricks统一订阅同一隔离馈送，完成Medallion架构Bronze层闭环（此前Vol.10报道的Lakebase已提供Gold层Synced Tables，CDF补上Bronze层数据流入），同日披露Lakebase弹性架构的单元设计——每个区域由多个相同形状的自包含单元组成，5月8日AWS us-east-1事件中仅13%数据库受影响（对比无单元架构约100%），无状态Postgres计算+区域冗余存储+最小化云依赖+故障注入测试的四层弹性设计指向99.99%单数据库月度可用性目标——这三条动态共同指向DataInfra的又一个维度跃迁：分析数据库正在从”被人查询”走向”被代理查询”，从”单节点优化”走向”分布式协作”，从”孤立引擎”走向”数据栈原生集成”。

ClickHouse Agents与Agentic Data Stack：分析数据库走向代理原生

事件概述

5月27日，ClickHouse在Open House 2026 Day 1发布ClickHouse Agents——基于Anthropic Claude的完全托管代理分析服务，进入公开Beta。ClickHouse Agents是一个无代码Agent构建器，让任何人定义、配置和部署基于ClickHouse数据的分析代理，开箱即用包含聊天界面、沙箱代码解释器、可共享工件、技能管理、记忆和多Agent工作流。Agent原生连接ClickHouse数据，并通过MCP协议从任意兼容系统拉取上下文，同时与AWS Agent Registry原生集成。同日，ClickHouse发布Agentic Data Stack——将ClickHouse（存储与查询）+LibreChat（2025年11月收购的开放交互层）+Langfuse（2026年1月收购的LLM可观测性）组合为”存储+交互+可观测”一站式代理分析栈，提供Docker Compose一键部署方案。ClickStack MCP Server也在同日开源——针对可观测性场景优化，相比通用ClickHouse MCP减少25%工具调用、2.5倍一致性提升、评估分数提升近20%。AI Notebooks进入Beta——持久化调查工作区替代临时聊天会话，支持从任何点分支探索。

技术解析

• ClickHouse Agents核心架构：底层基于LibreChat开源平台（2025年11月随收购加入ClickHouse），Claude作为推理引擎。沙箱代码解释器让Agent安全执行Python/SQL代码处理查询结果，可共享工件让分析发现成为团队可复用资产。技能管理系统让Agent获得领域专用能力（如”查询优化""Schema分析”），记忆功能让跨会话上下文持续。多Agent工作流支持Agent间协作编排——一个Agent负责数据探索，另一个负责可视化，第三个负责异常告警。
• MCP原生集成：Agent通过MCP协议从任意兼容系统拉取上下文——不仅查询ClickHouse数据库，还连接Jira看需求、连Slack看讨论、连GitHub看代码变更，形成”数据+上下文”的完整决策依据。AWS Agent Registry原生集成让Agent直接访问AWS云上代理生态。
• Agentic Data Stack一站式栈：ClickHouse处理高并发低延迟查询，LibreChat提供Agent交互界面和多轮对话管理，Langfuse提供LLM调用追踪/质量评估/成本监控。三者组合形成”存储+交互+可观测”闭环——DWAINE（Data Warehouse AI Natural Expert）已在ClickHouse内部为200+用户处理70%数据仓库查询、日消耗3300万LLM tokens。Canva用Langfuse构建多Agent客服体验，Khan Academy用Langfuse运营Khanmigo AI导师服务1.5亿注册学习者。
• ClickStack MCP Server：不是通用SQL接口的封装，而是提供高级语义工具——挖掘日志重复模式、将属性与异常值关联、检查慢速追踪、通过可重复工作流推进调查。直接SQL访问保留为”逃生舱”——当需要深入探索或测试异常假设时使用。编排功能支持创建仪表板、持久化搜索、管理告警、跨团队共享发现。
• AI Notebooks：持久化调查工作区替代临时聊天会话——每次调查形成结构化的提示、查询、图表、推理步骤和发现的序列。非线性工作流支持从任何点分支探索替代理论，无需丢失之前工作。笔记本可在团队间共享，将调查转变为持久的协作工件。
• ClickStack Cloud（私有预览）：完全托管的无服务器可观测性平台，用户发送OTLP数据到托管端点即可通过ClickStack UI探索日志/指标/追踪，无需管理收集器、基础设施规模或Schema调优。自动调优引擎从查询模式学习——物化高频查询字段、调整主键适配常见过滤器、为仪表板和调查工作流添加物化视图和索引。

行业影响

ClickHouse Agents的深层意义不是”又一个AI聊天界面”，而是分析数据库首次将AI代理分析作为平台核心工作负载纳入一等公民地位。此前的AI+数据库方案是”在数据库外面套一个AI壳”——AI代理通过MCP或SQL接口查询数据库，但数据库本身对”被代理查询”和”被人查询”不做区分。ClickHouse Agents将”被代理查询”作为平台级能力：沙箱代码解释器解决代理安全执行代码的需求，技能管理解决代理获得领域知识的需求，记忆解决代理跨会话持续的需求，多Agent工作流解决代理协作的需求——这些能力是”被代理查询”场景独有的，“被人查询”场景不需要。

这与Vol.10报道的Hologres CLI & Skills形成有趣的对照——两者都在构建”代理友好的数据基础设施”，但切入点不同：Hologres从”数据库操作层”入手（CLI安全边界+Agent Skills知识包），ClickHouse从”分析交互层”入手（Agents代理构建器+Agentic Data Stack全栈）。前者解决”代理如何安全地操作数据库”，后者解决”代理如何高效地分析数据”——两者共同指向一个趋势：分析数据库正在从”被动查询”走向”代理原生”。

Agentic Data Stack的一站式栈设计也值得关注——ClickHouse+LibreChat+Langfuse的三件套恰好对应代理分析工作负载的三个层次：存储与查询（ClickHouse）、交互与编排（LibreChat）、可观测与评估（Langfuse）。DWAINE内部实践验证了这一架构的生产可行性——70%数据仓库查询由代理处理，日消耗3300万tokens。当代理分析从”实验”走向”生产”时，可观测性和评估不再是可选组件而是必需基础设施——这与Vol.9报道的AgentLoop MemoryStore（Agent记忆云化）和LoongCollector+ACS Agent Sandbox（Agent运行时可观测化）的逻辑一致。

相关链接

• ClickHouse tops $250M ARR and 4,000 customers, launches Claude-powered agents at Open House 2026
• Open House 2026 Day 1: real-time data without lock-in and what teams can build next
• Open House observability announcements: MCP server, AI Notebooks, and ClickStack Cloud
• The Agentic Data Stack
• Agentic Data Stack GitHub Repository

---

ClickHouse多阶段分布式查询执行：交换操作符让分析引擎走向MPP

事件概述

5月27日，ClickHouse在Open House 2026发布多阶段分布式查询执行（Multi-stage Distributed Query Execution），进入私有预览。该功能引入交换操作符（Exchange Operators）核心抽象，允许中间数据在执行阶段间自由移动，使单个查询可扩展到多个节点执行。四种交换模式——GatherExchange（N对1收集）、ShuffleExchange（M对N重分区）、BroadcastExchange（1对N广播）、ScatterExchange（随机分散）——覆盖从单播到多播到重分区的全部数据移动需求。TPC-H 100GB基准测试中，8节点总体2.1倍加速，扫描主导查询Q01达7.4倍加速，多JOIN查询2-5倍加速。大表JOIN的内存需求从单节点16GiB降至每节点2GiB——每个节点仅构建哈希表的1/8。同日ClickHouse发布CostBench开放基准——将ClickHouse Cloud、Snowflake、Databricks、BigQuery、Redshift的专有计费单位统一转换为性能/成本平面，ClickHouse Cloud成本效能为最近竞争对手的23倍。

技术解析

• 交换操作符——分布式查询的核心抽象：此前ClickHouse分布式执行存在三个瓶颈：①容量与分片布局绑定（加计算资源不自动加速单查询）、②大表JOIN右侧被复制到每个节点（大量网络流量和内存浪费）、③最终聚合仍为单节点操作（高基数GROUP BY受限于单节点CPU和内存）。交换操作符解决这三个问题——它不是ClickHouse的原创概念，已在Teradata、Greenplum和SQL Server等MPP数据库中验证，但首次在ClickHouse Cloud中实现。
• 四种交换模式：GatherExchange将工作节点输出发送到协调器生成最终结果；ShuffleExchange按键重新分区行数据（JOIN键或GROUP BY键分区）；BroadcastExchange将小输入复制到每个工作节点（小表JOIN优化）；ScatterExchange随机分散行到工作节点（负载均衡）。以TPC-H查询为例：先BroadcastExchange广播nation小表→ShuffleExchange按供应商键重分区lineitem和supplier→本地JOIN→ShuffleExchange按n_name重分区GROUP BY→GatherExchange收集最终结果。
• 流式与持久化交换：流式交换（默认）通过TCP自定义二进制协议直接发送数据块，数据生成即刻传输，优化交互式查询。持久化交换将中间块写入共享对象存储，用于故障恢复和超出集群内存时的溢出处理——这是ClickHouse Cloud共享存储架构的自然延伸。
• TPC-H 100GB性能：单节点117.6秒→8节点54.7秒，总体2.1倍。扫描主导查询Q01达7.4倍（工作几乎完全是读取和聚合，均匀分割）；多JOIN查询Q19为4.5倍、Q04为4.2倍、Q09/Q22/Q13为3.3-3.4倍；已优化查询Q15为1倍（已经很快无需加速）；Q02为0.6倍（运行时过滤尚未完全支持）。
• 工作节点可互换性：基于ClickHouse Cloud的共享存储架构，任何工作节点都可以扫描表数据、接收重分区行、构建哈希表或聚合。长期方向是完全无状态工作节点——节点按需出现、为查询执行工作、从共享存储读取数据、完成后消失，无需固定所有权或手动数据放置。
• CostBench开放基准：43个生产环境衍生的分析查询，真实匿名数据集，应用每个供应商实际计费模型。ClickHouse Cloud是唯一在数据规模增长时保持”快速且低成本”的系统。读侧已完成，写侧正在推进。源代码在GitHub开放，定价假设和原始JSON结果公开。

行业影响

多阶段分布式查询执行的深层意义不是”ClickHouse变快了”，而是ClickHouse Cloud从单节点分析引擎走向MPP式分布式引擎的架构性跃迁。此前的ClickHouse分布式查询依赖数据分片——添加计算资源不会自动加速单个查询，大表必须先重新分布到更多分片。交换操作符将”数据在哪里”与”查询在哪里执行”解耦——任何节点可以读任何数据、处理任何分区，查询计划器自由选择最优执行路径。

这与Vol.10报道的ClickHouse统一数据栈（Postgres+ClickHouse+ClickStack+Langfuse）形成互补——统一数据栈解决”AI代理需要什么数据服务”的问题，多阶段执行解决”这些数据服务如何高效执行”的问题。当代理分析工作负载产生高并发、多JOIN、高基数聚合查询时，单节点优化已触及天花板——MPP式分布式执行是唯一的扩展路径。

CostBench则代表了一种新的竞争叙事——不再比拼”谁最快”，而是比拼”谁最值”。在AI代理工作负载中，成本效能比原始速度更重要——单用户问题可触发多个SQL查询（Schema探索/验证/重试/细化），每个额外查询都增加成本。当ClickHouse Cloud成本效能为竞争对手的23倍时，代理分析的经济学基础发生了质变——从”代理分析很贵”到”代理分析很便宜”，这会改变企业对代理分析的投资决策。

相关链接

• Introducing multi-stage distributed query execution in ClickHouse Cloud
• Introducing CostBench: an open benchmark for data warehouse cost-performance
• CostBench GitHub Repository
• ClickHouse Benchmarks

---

Databricks Lakebase CDF与弹性架构：OLTP数据库安全可靠接入湖仓

事件概述

5月27日，Databricks发布Lakebase Change Data Feed（CDF），进入公开预览。CDF将Lakebase OLTP数据库的行级变更原生捕获为Unity Catalog托管表，无需数据库连接器、无需监控复制状态、无需独立提取作业。下游SDP流式管道、DBSQL物化视图和Agent Bricks统一订阅同一隔离馈送，完全隔离于主要运营工作负载。CDF完成Medallion架构中Bronze层的闭环——此前Lakebase已通过Synced Tables提供Gold层数据服务（Vol.10报道Postgres Managed by ClickHouse的pg_clickhouse统一查询层解决了OLTP+OLAP统一接口问题），CDF补上从运营数据库到湖仓的数据流入路径。同日Databricks披露Lakebase弹性架构设计——基于单元（Cell）的架构将区域划分为多个相同形状的自包含单元，故障爆炸半径被限制在单元边界内。5月8日AWS us-east-1可用区故障中，8个单元仅1个故障转移异常，总体仅13%数据库受影响（对比无单元架构约100%受影响）。无状态Postgres计算+区域冗余存储+最小化云依赖+持续故障注入测试的四层弹性设计指向99.99%单数据库月度可用性目标。

技术解析

• CDF——原生CDC治理：此前运营数据库的变更捕获需要独立的CDC管道——配置数据库连接器、监控复制状态、维护提取作业，管道复杂度为O(n)（每个源到每个目标一条管道）。CDF将CDC原生集成到Unity Catalog——一次性启用后自动应用于项目内所有表，变更存储在Unity Catalog托管表中，任何引擎通过标准SQL直接读取。下游消费者完全隔离互不影响，不影响主要运营工作负载。
• Medallion架构闭环：运营数据库（Bronze层）通过CDF捕获原始变更→SDP流式管道/DBSQL物化视图（Silver层）清洗转换→Lakebase Synced Tables（Gold层）为应用提供服务。此前Synced Tables已解决Gold层（数据从湖仓到应用），CDF解决Bronze层（数据从运营数据库到湖仓），两者组合形成运营数据库与湖仓的双向闭环。
• 多引擎统一订阅：SDP流式管道（实时处理）、DBSQL物化视图（数仓分析）、Agent Bricks（AI计算）统一订阅同一隔离馈送——不同工作负载从同一数据源读取但互不影响。这消除了”每个下游消费者一条独立管道”的复杂性。
• 单元架构——爆炸半径控制：每个区域由多个相同形状的自包含单元组成，每个单元包含Kubernetes、控制平面、计算和存储。区域增长时添加新单元，故障被限制在单元边界内。5月8日AWS us-east-1事件实测：8个单元中1个故障转移异常，其他7个正常——仅13%数据库受影响，对比无单元架构约100%受影响，爆炸半径降低约10倍。
• 无状态Postgres计算：所有持久数据存储在远程存储服务，计算进程本地磁盘不保存任何持久状态。计算实例故障时可以即时替换，无需数据复制到热备用或运行传统Postgres崩溃恢复（后者可能需10+分钟）。区域冗余存储默认跨可用区冗余，无额外成本。
• 控制平面即数据平面：在代理工作负载时代，数据库启动/暂停操作需要99.99%+可用性（Neon实测90%自动暂停数据库的会话生命周期<10分钟）。将控制平面关键部分分离为数据平面控制器服务——仅处理热路径操作（启动/暂停），最小化外部依赖。
• 故障注入测试：每个版本部署到真实集群运行混合工作负载，注入杀死进程/关闭节点/网络故障/擦除磁盘/循环重启等故障，以编程方式断开可用区网络验证故障转移——目标任何工作负载中断≤30秒。使用SqlLancer和SqlSmith验证内部数据一致性和无已提交事务丢失。
• Always-On定价：基线容量25%折扣（无长期承诺），额外50%促销折扣至2027年1月31日。将无服务器的灵活性与预配置的经济性结合。

行业影响

Lakebase CDF的深层意义不是”又一个CDC工具”，而是OLTP数据库的变更捕获从”外部管道”变为”平台原生能力”。此前的CDC方案（Debezium/Fivetran/PeerDB）是独立于数据库的基础设施——需要部署连接器、监控复制延迟、处理Schema变更、维护管道健康。CDF将这些基础设施工作内化为数据库平台的一部分——启用即用，无需运维，变更自动治理。这与Vol.8报道的Databricks Catalog Commits GA的思路一致——Catalog Commits将事务协调从文件系统上移到目录层（“外部”变”原生”），CDF将变更捕获从外部管道内化到平台层（“外部”变”原生”），两者共同指向Unity Catalog作为”数据基础设施操作系统”的定位——事务协调、变更捕获、访问治理都在目录层原生完成。

CDF与Vol.10报道的ClickHouse Postgres Managed的CDC形成直接对照——两者都解决”OLTP到OLAP的数据流动”问题，但路径不同：ClickHouse通过ClickPipes/PeerDB提供CDC（外部管道方案，已收购PeerDB），Databricks通过CDF原生集成（平台内化方案）。前者更灵活（支持任何Postgres源），后者更简洁（无需额外基础设施）。两种路径各有取舍——外部管道方案在多源异构场景下更优，平台内化方案在单平台场景下更高效。

Lakebase弹性架构的单元设计则提供了云原生数据库容灾的新范式——传统高可用方案（跨AZ热备用）解决的是单点故障，单元架构解决的是”整个可用区故障时如何控制爆炸半径”。5月8日AWS事件是真实的验证——13%受影响vs 100%受影响，10倍改善。这与Vol.10报道的ClickHouse Cross-Region Replication（跨区域同步复制，分钟级恢复）从不同层面解决容灾问题——ClickHouse在区域级别保护数据安全，Databricks在可用区级别控制故障范围。

相关链接

• Announcing Lakebase Change Data Feed (CDF)
• How the Lakebase architecture stays resilient to cloud failures
• Introducing Always-On pricing: automatic savings for Databricks Lakebase

---

编者评

第十一期的三条动态，与前十期的主线形成了又一个维度的跃迁。Vol.1-2确立了”AI原生基础设施”和”基础设施AI代理化”两条主线，Vol.3-4追踪到AI代理趋势渗透到治理层和存储/芯片层，Vol.5看到横切面基础设施为AI代理重新定义角色，Vol.6见证了AI推理基础设施的精细化，Vol.7看到湖仓格式插件化和AI代理成为基础设施原生操作者，Vol.8看到AI基础设施的系统性构建和湖仓事务模型的架构性重构，Vol.9看到AI Agent记忆/安全/可观测性的基础设施化，Vol.10看到数据基础设施从”为人设计”走向”为代理设计”。本期则看到了一个更具体的转变：分析数据库正在从”被人查询的数据存储”走向”被代理查询的分析平台”，从”单节点优化”走向”分布式协作”，从”孤立引擎”走向”数据栈原生集成”。

ClickHouse Agents的意义不在于”又一个AI聊天机器人”——市场已有无数——而在于分析数据库首次将代理分析作为平台核心能力而非外部附加。当沙箱代码解释器、技能管理、记忆、多Agent工作流成为数据库平台的一部分时，“被代理查询”不再是”被人查询”的特例，而是一等公民。Agentic Data Stack的一站式栈设计（ClickHouse+LibreChat+Langfuse）进一步将”存储+交互+可观测”三个层次打包——DWAINE内部实践验证了70%查询由代理处理的可行性。当代理分析从实验走向生产时，可观测性和评估不再是可选组件——这与Vol.9的AgentLoop MemoryStore和LoongCollector+ACS Agent Sandbox的逻辑一脉相承。

多阶段分布式查询执行则补上了ClickHouse走向代理原生分析平台的基础设施短板——代理分析工作负载产生高并发、多JOIN、高基数聚合查询，单节点优化已触及天花板。交换操作符将”数据在哪里”与”查询在哪里执行”解耦，这是ClickHouse Cloud从单节点引擎走向MPP引擎的架构性跃迁。配合CostBench的23倍成本效能优势，ClickHouse在分析引擎层的竞争力从”最快”扩展为”最快+最省+最代理友好”。

Lakebase CDF与弹性架构则代表了Databricks对”运营数据库如何安全可靠地接入湖仓”这个核心问题的回答。CDF将CDC从外部管道内化为平台能力，单元架构将爆炸半径从100%降至13%——两者共同指向”OLTP数据库不再是湖仓的外部数据源，而是湖仓的原生组成部分”。这与Vol.10的ClickHouse统一数据栈（Postgres for OLTP + ClickHouse for OLAP）从不同角度解决同一问题——ClickHouse用”两个引擎+统一查询层”，Databricks用”一个平台+原生CDC”。

将十一期主线串联，一个完整的演进图景浮现：DataInfra正在经历从”为人设计”到”为人+代理协同设计”到”为代理设计”到”代理基础设施化”到”代理原生平台化”的五阶段范式迁移。Vol.1-3让基础设施支持AI代理，Vol.4-6为AI代理重新设计基础设施，Vol.7-8让AI代理成为基础设施的原生操作者，Vol.9-10让AI代理自身的基础设施需求成为独立产品品类，Vol.11则让分析数据库本身成为代理原生的平台。当分析数据库有代理专用的交互模式（ClickHouse Agents）、分布式执行引擎（多阶段查询）、原生CDC（Lakebase CDF）和弹性容灾架构（单元设计）时，“代理分析”不再是在人类数据库上”加一层AI”的外部方案，而是数据库平台的原生能力——这个转变的深层含义是：分析数据库的最终形态不是”支持AI代理查询的数据库”，而是”AI代理原生分析平台”。