datainfra前沿动态 · Vol.119

ClickHouse 史上最大平台扩展：可观测性托管公测、agentic SIEM 与 Langfuse AI Gateway 一起落地；Managed Postgres GA 加 Xata 收购，给 Postgres 装上秒级分支与 agent 沙箱；Confluent 用 OpenSearch oi2 专用实例把可观测性热层砍掉 46% 节点；KubeRay 进 CNCF，PARK stack 治理拼图完成

本期聚焦可观测性成为数据基建主战场：ClickHouse 一口气发布平台史上最大扩展，把托管可观测性、agentic SIEM、AI Gateway 与 Managed Postgres 收进同一个云平台；Confluent 的生产案例展示了可观测性负载如何倒逼存储层专用化；KubeRay 捐入 CNCF 补上 PARK stack 最后一块治理拼图。四条合流的指向是：agent 既是数据基建的新负载，也是新用户。

DataInfra ClickHouse Observability SIEM Langfuse PostgreSQL Xata Amazon OpenSearch oi2 KubeRay CNCF Ray 可观测性 Agentic SIEM 数据基建

11 月 9 日 ClickHouse 打出「平台史上最大扩展」的组合拳：ClickHouse Observability 进入公测，托管 OTLP 接入按量计价（日志与 trace \$0.20/GB、指标 \$0.10/百万数据点）；ClickHouse Security 以私有预览亮相，用 9 月收购的 RunReveal 技术搭出 agentic SIEM；1 月收购的 Langfuse 发布开源 AI Gateway，零代码改动捕获 AI 用量与成本；Managed Postgres 同日 GA，Xata 收购把秒级分支、克隆与 scale-to-zero 带进 Postgres，铺路 agent 沙箱与 agent 记忆专用层。AWS 侧，Confluent 把 OpenSearch 热层迁到 oi2 专用实例，168 个节点缩到 90 个、索引延迟减半、写队列清零——可观测性负载正在存储层逼出专用硬件路线。治理侧，Anyscale 与 Google 把 KubeRay 捐入 CNCF，PARK stack（PyTorch、AI 模型、Ray、Kubernetes）全部归入 Linux Foundation 治理。四条放在一起是一句话：数据基建的下一个主战场是可观测性，而 agent 既是最重的负载，也是最挑剔的用户。

ClickHouse 平台最大扩展：托管可观测性、agentic SIEM 与 AI Gateway 同日落地

事件概述

ClickHouse 在 11 月 9 日发布自 ClickHouse Cloud 上线以来最大的一次平台扩展，官方口径覆盖 transactions、observability、security、AI engineering 四条线。公告里给出的客户基座是 5,000+ 付费客户（DoorDash、Ramp、Meta、Tesla、Cisco、Visa），而平台化的逻辑写在开头：AI 正在让查询量、数据量与负载形态变得不可预测，开发者需要的是一组专用但共享同一高性能底座的服务，而不是一个更大的单一数据库。

三件新产品构成「Observe / Secure / AI Engineering」两翼。ClickHouse Observability 以公测亮相：团队把 OpenTelemetry collector 指向一个托管 OTLP endpoint，摄入、schema、存储、扩缩容全部交给平台，ClickStack UI 负责调查界面，内置 MCP server 让 agent 用专用工具与 SQL 直接查日志、追 trace、比对事件模式。ClickHouse Security 以私有预览发布，构建于 9 月收购的 RunReveal 之上，定位是 agentic SIEM：原生 agent 分诊告警、查询底层数据、把推理过程写回案例档案，100+ 云与 SaaS 数据源经一方集成完成归一化，检测以 detections-as-code 管理。Langfuse（1 月收购，35k+ GitHub stars、月下载 9,000万+，财富 50 强中 21 家在用）同日发布开源 AI Gateway：模型请求路由经过网关即可自动 trace 用量、token 消耗与成本，零代码改动，Rust 实现，可自托管。

技术解析

  • 可观测性的定价模型：日志与 trace 按未压缩摄入量计 \$0.20/GB，指标按数据点计 \$0.10/百万——指标不按时间序列基数收费，官方理由是 ClickHouse 本身不怕基数，用户也不该被基数计价绑架。公测期半价，含 30 天保留。摄入与查询的计算分离，调查容量的自动伸缩建立在 On-Demand Compute 之上。
  • Observability Apps（私有预览）：用自然语言描述需求，agent 生成自定义可观测性应用——查询、可视化、可串联的调查界面，生成代码跑在沙箱里、查询只读且继承查看者权限。配套文章《The observability UI as we know it is dead》把这定位成「可观测性界面的生成式重构」：固定界面的路线图等不起每个团队各自的调查路径。
  • 架构背书：底层数字来自已有生产部署——Mercado Libre 用 ClickHouse 每分钟处理约 4 亿 span，查询快 75 倍、压缩率约 89%；Buildkite 每天摄入数十亿次测试执行，摄入延迟 10 秒。
  • 产品层级理顺：开源 ClickStack 继续开源并持续投入；原 Managed ClickStack 变为 Observability 的 self-managed 选项，资源计价不变——想要最低单位成本的团队保留自管路径，托管版本成为默认起点。

行业影响

可观测性是 ClickHouse 生态渗透最深却一直没有「官方产品化」的场景——Netflix、Anthropic、OpenAI 的案例都是自建。这次发布实质是把一组已被验证的自建模式收编成按量计价的服务，与 Datadog 们的战争从「你们底层不就是 ClickHouse 吗」打到「我们就是 ClickHouse 本尊」。真正的新变量是 agent：Trunk.io 的证言直言小团队靠「现成 agent + 可观测性数据库访问权」维持 AI 辅助分诊，SIEM 里的 agent 分诊、Apps 里的生成式界面，都在把「agent 作为可观测性的一等用户」写进产品定义。当调查负载来自 agent，容量规划与计价模型都要重写——这是按 GB 计价的深层动机。

相关链接

Managed Postgres GA 加 Xata 收购：给 agent 准备的 Postgres 什么样

事件概述

同日，ClickHouse Managed Postgres 宣布 GA（AWS 全面可用，GCP 私有预览），并公布收购 Xata——一家把自己定位为「agent-native Postgres」的公司。过去 10 个月的公开测试里，这个本地 NVMe 存储的 Postgres 服务宣称 OLTP 负载 2–10 倍性能提升，已支撑数百个生产客户，迁移来源包括 Aurora、RDS 与 Neon。与 ClickHouse 的连接走两条原生通路：WalShadow 消费物理 WAL 做亚秒级复制，pg_clickhouse 扩展让应用通过标准 Postgres 接口反向查询 ClickHouse。

Xata 带来的是另一层能力：基于 Xatastor copy-on-write 存储（ZFS on NVMe）的即时分支与克隆、自动闲置与 scale-to-zero。收购后的 roadmap 分两步——先把分支能力接进 NVMe 生产 Postgres，形成「生产库 + 弹性分支环境」的单一平台；再开一个面向 agent 的专用层，支持 agent 沙箱、agent 记忆与「百万级间歇活跃 Postgres 环境」的经济性运行。

技术解析

  • 双库一平台的连接件：WalShadow 走物理 WAL 复制（亚秒级延迟），ClickPipes 提供免额外费用的备选通道；pg_clickhouse 让事务应用在 Postgres 方言里查询分析数据，减少迁移工作量。GA 后 beta 折扣结束，备份存储与公网出流量开始计费。
  • 企业面：跨可用区最多双 standby、自动故障切换、PITR；内置 PgBouncer 连接池与只读副本；Query Insights 与 Prometheus endpoint 自带可观测性；SAML/SSO、RBAC、Terraform/OpenAPI/CLI 全套 IaC。
  • Xatastor 的经济学：copy-on-write 让「克隆一份生产数据」变成元数据操作，配合自动闲置，测试环境的边际成本趋近于零——这是「给每个 agent 发一个沙箱数据库」在成本上成立的前提。David AI 的证言给出了当前的工作形态：开发者与 AI 编码 agent 在 Xata 分支上并行构建测试，生产跑在 ClickHouse Managed Postgres。

行业影响

Postgres 与分析引擎配对正在成为行业母题，分歧在连接层怎么修。本刊 Vol.116 报过 EDB 收购 Altinity：Postgres 与 ClickHouse 共用一个 Iceberg catalog，走开放格式中间层；ClickHouse 的选择是物理复制加同栈托管，用「同一个云平台、同一套权限与 IaC」换集成深度。值得注意 Xata 的叙事重心——「agent 需要完全隔离、可秒级供给、可即时克隆的数据库环境」，这基本是把 Neon 的 serverless Postgres 故事对着 agent 重讲一遍，而收购方恰好吸纳了从 Neon 迁来的客户。当数据库采购决策的一部分开始由 agent 的行为模式驱动，分支、沙箱与 scale-to-zero 会从事锦上添花变成采购清单的硬项。

相关链接

Confluent 的热层现代化：oi2 专用实例砍掉 46% 节点、索引延迟减半

事件概述

AWS 大数据博客 11 月 10 日发布 Confluent 案例：这家「Kafka 原创团队创建、现属 IBM」的公司，其支撑 Kafka、Connect 与 Flink 舰队运营的内部日志系统跑在 Amazon OpenSearch Service 上，每天摄入数百 TB 日志。工程团队把热层从上一代 Graviton2 通用实例 r6gd 迁到 OpenSearch 专用实例 oi2，结果是舰队从 168 个节点缩到 90 个（-46%），索引延迟从约 0.18–0.19ms 降到约 0.08–0.10ms，四个域的写队列从两位数清到接近零——而这一切发生在单节点单价更高的情况下，成本反而下降。

方法论是「measure-first」两阶段：第一阶段在节点数不变的前提下原地换型（blue/green 重供给），在固定摄入量下实测新实例的真实效率——同量摄入下 oi2 的 CPU 只有 r6gd 的约三分之一，单节点余量约 2.7 倍；第二阶段逐步删节点，每步驻留确认集群健康，直到第一个 guardrail 触顶——最终触顶的不是 CPU 而是 JVM heap：节点变少让相同分片集中到更少节点上，查询模式驱动的堆压力成了缩容地板。

技术解析

  • oi2 的存储路径是杠杆：本地 NVMe 是主存储层（无独立 EBS 卷），数据同步复制到 S3 换取 11 个 9 的持久性；存储与网络路径专为索引与 merge I/O 优化。AWS 内部基准称 oi2 索引吞吐比 OR2 高 9%、比 I8g 高 33%，单实例最高 22.5TB 存储。
  • 物理段复制：OpenSearch 优化实例族用物理（段）复制替代逻辑（文档）复制——数据只在主分片索引一次，副本直接从主分片拷段。副本省下的重复索引算力直接变成集群吞吐。注意监控口径：配置副本时索引速率显示值约为真实值的一半。
  • 成本账：热层 on-demand 成本约降 18%，全部来自节点数缩减对单价的反超；最终足迹若签 1 年 RI，估算比原 r6gd on-demand 基线低 47–51%。文章给的教训一句话：优化「单位工作量效率」，不是「实例单价」。
  • 诚实的离群值：D 域削得最狠，CPU 从 43% 升到 56%，是唯一写队列没有归零的域——作者明说要在峰值流量里再观察，才算数。

行业影响

可观测性负载与通用存储的错配已经不是新闻，新闻是解法的分层：ClickHouse 在数据库层做托管产品（本期第一条），AWS 在实例层做专用硬件，Confluent 的案例说明后者在「数百 TB/天摄入、索引写为主」的负载上同样有 40%+ 的舰队级空间。对自建可观测性的团队，这篇文章的实操价值超过产品发布——两阶段换型法、heap 而非 CPU 是缩容地板、10MB bulk 与 10s 刷新间隔的调参基线，都是能直接抄走的作业。指标按数据点而非序列基数计价的定价思路（ClickHouse）与按量摄入的实例经济性（oi2）在呼应同一件事：可观测性数据的计价单位正在从「容量」迁移到「摄入量」。

相关链接

KubeRay 进 CNCF：PARK stack 的治理拼图完成

事件概述

Anyscale 与 Google 的维护者团队 11 月 9 日宣布 KubeRay 加入 CNCF（以 sandbox 项目起步）。公告给出的框架是 PARK stack——PyTorch、AI 模型、Ray、Kubernetes——正在成为生产 AI 的事实开源标准，而这个栈里的几乎每一块早已在 Linux Foundation 体系内：PyTorch 与 Ray 归 PyTorch Foundation，Kubernetes 归 CNCF，KubeRay 是最后一块留在厂商手里的拼图。捐赠之后，PARK stack 全栈处于厂商中立治理之下。

KubeRay 是在 Kubernetes 上运行 Ray 工作负载的 operator 与工具集，提供三个 CRD：RayCluster 管理集群全生命周期（head/worker pod 供给、健康检查、GCS 容错、与 Ray Autoscaler 协同的动态伸缩），RayJob 为批处理、分布式训练与 RL 工作负载自动供给临时集群、提交作业、完成后拆除，RayService 面向 Ray Serve 长驻在线推理，管理零停机滚动升级、自动故障切换与流量路由。

技术解析

  • 生态集成靠标准件而非重造：可观测性走 OpenTelemetry + Prometheus 指标 + Fluent Bit 日志；批调度与配额对接 Kueue、Volcano 与 KAI，带来 gang scheduling（全有或全无的 pod 放置）、多租户配额、优先级抢占与拓扑感知调度；安全面提供自动 mTLS 与 Kubernetes 网络策略。
  • 治理意义大于代码意义：KubeRay 本身不换仓库、不换维护者，变的是采购与合规视角——企业平台团队把 Ray 工作负载放上生产时，「项目归 CNCF」意味着商标、治理与 roadmap 中立性都不再依赖单一厂商的存续。Anyscale 自身 7 月已宣布并入 Nscale，中立治理对这类母公司变动下的项目尤其重要。
  • 社区节奏：KubeCon NA 2026 有 KubeRay BoF 与 Hark 的生产案例演讲（多模态 AI 工作负载与 agentic workflow 扩展），双周社区会议照常。

行业影响

AI 基础设施的「云原生化」走完了从事实到名分的一步：分布式 AI 负载作为一等云原生工作负载，其 operator 与 Kubernetes 本体同处一个治理体系。对照看这两年的节奏——Kueue 毕业路径上的 gang scheduling 普及、Volcano 在训练集群的渗透、Ray Summit 上物理 AI 与 RL 的规模故事——KubeRay 进 CNCF 更像是给已经发生的迁移补发产权证。对国内团队的直接相关性在于：Ray 是许多预训练与后训练平台的调度底座，KubeRay 是它在 K8s 上的标准运行方式，治理中立化之后，「自建平台绑死某家商业公司」的顾虑又少了一条。

相关链接

编者评

本期四条动态的两条暗线在 11 月 9 日这一天交汇。一条是可观测性成为数据基建的主战场：ClickHouse 把 observability、SIEM 与 AI gateway 收进同一个平台，是「数据库厂商向上打产品」；Confluent 与 AWS 的 oi2 案例是「云厂商向下打硬件」；两边都在回应同一个负载现实——全保真、高基数、agent 驱动的调查流量。另一条是 agent 重新定义数据库的形态与归属：Xata 的 agent 沙箱层、Observability Apps 的生成式界面、agentic SIEM 的自动分诊，说的是「agent 作为用户」；KubeRay 进 CNCF 说的是「agent 的基础设施需要中立治理」。合起来是一个正在成形的判断：未来两年数据基建采购清单上的很多条目，将由 agent 的行为模式——而不是人的查询习惯——决定规格。余下的小字也值得一看：dbt 发布从 trusted data 到 trusted agents 的成熟度路径，TNS 报道 CNCF 调查称 75% 云原生开发者已用 AI 写码，DuckDB 用一篇列式存储教程（《Ducks in a Column》）把「只读需要的列」这条最朴素的规则重讲了一遍——负载和界面都在变，列式这条地基没动。