datainfra前沿动态 · Vol.75

Amazon EMR on EC2 支持 Spark Connect，把 PySpark 开发从集群里拆出来；ClickHouse 用八台同源集群测出本地 NVMe 让 Postgres 吞吐差 9.2 倍；阿里云八月数据库更新给出跨目录联邦的 LakeBase Catalog 与 AnalyticDB 数据分支；Concurrence 把万亿 token 的 AI 访问收进 Unity Gateway

本期聚焦「拆开」：AWS 把 PySpark 的客户端与计算引擎分离，让开发环境和生产环境落在同一个集群上；ClickHouse 用一组只差存储介质的对照实验，量化了本地 NVMe 给 Postgres 带来的吞吐与尾延迟差距，并把持久性从存储层搬回数据库自身的复制与归档；阿里云八月更新把元数据从各个目录里抽出来做联邦查询，把开发用的数据从主干上分出去做分支；Concurrence 则把散在各处的模型调用收进一个网关，顺手退役了自建的日志存储与反向 ETL。

DataInfra Apache Spark Spark Connect Amazon EMR ClickHouse PostgreSQL NVMe CDC HTAP 阿里云 PolarDB AnalyticDB LakeBase Catalog Databricks Unity Gateway Lakehouse

本期四条动态分属托管 Spark、OLTP 存储选型、云数据库产品更新与 AI 访问治理，动作的形状却一致：把原本挤在同一个系统里的两件事拆开，让每一边各自选型。AWS 拆的是写代码的地方与跑代码的地方，中间接一条 gRPC/TLS 通道；ClickHouse 拆的是事务与分析，顺带把持久性从块存储搬回 Postgres 自己的 quorum 复制与 WAL 归档；阿里云拆的是元数据与数据、开发分支与主干，代价是一层联邦 catalog 与一套分支语义；Concurrence 拆的是业务数据管道与模型访问通路，把后者收进网关。四处拆分都没有让复杂度消失，而是把它推到了新划出来的那条边界上——一条要自己拼端口号的连接串、一条要评估下推覆盖率的 CDC 管道、一张需要工单申请的公测清单、一个合规判断优先于成本判断的路由规则。

Amazon EMR on EC2 支持 Spark Connect：客户端留在本地，计算留在集群

事件概述

AWS Big Data Blog 在 9 月 23 日宣布 Amazon EMR on EC2 支持 Spark Connect，四位作者（Al MS、Arun Prabakaran、Karthik Prabhakar、Rekha Veeraraghavan）把这条公告写成了一篇 Advanced（300）级的上手指南。功能是：Spark 跑在专用的 EMR on EC2 集群上，Python 跑在开发者本地，两边通过 gRPC/TLS 通信。开发者可以在 Visual Studio Code、PyCharm、Kiro 或本地 Jupyter 里设断点、检查 DataFrame，而看到的是全量数据，不是抽样。

此前在 EMR on EC2 上开发 Spark 只有两条路：在与集群绑定的 notebook 里写，或者打包成 job 提交后再看结果。两条路都有同一个问题——本地与集群的版本和依赖不一致，导致”部署—检查”循环缓慢且难定位。Spark Connect 的做法是让调试所用的环境就是代码作为批处理作业调度运行时的环境：同一个集群、同一套实例类型、库、bootstrap actions 与 Spark 配置。

技术解析

  • 版本门槛：集群需要 release label emr-spark-8.0.0 或更高（对应 AWS runtime for Apache Spark emr-spark-8.0，内含 Apache Spark 4.0.2），且 SessionEnabled 设为 true（CLI 为 --session-enabled），并安装 Spark 应用。本地需要 Python 3.9 以上，装 pyspark[connect]==4.0.2——PySpark 客户端版本必须与集群 Spark 版本一致。

  • 连接串要自己改 scheme 和端口：get-session-endpoint 返回的是不带端口的 https:// URL，必须改写成 sc://{host}:443/;use_ssl=true;x-aws-proxy-auth={auth_token};authorization={session_id}。不写端口时 PySpark 客户端默认用 15002，该端口不可达。

  • session 的生命周期由 EMR 托管：启动 session 时 EMR 在集群上以 YARN application 形式拉起 Spark Connect Server，返回 endpoint 与短期 token，开发者不需要自己部署或运维这个 server。单集群最多支持 1,000 个并发 session 与 1,000 个并发 execution role，官方明确标注这是 service maximum 而非容量规划目标。

  • 超时与释放语义：认证 token 1 小时后过期；session 在空闲超时后结束，默认 60 分钟、最长可配到 24 小时。本地调用 spark.stop() 只断开本地连接，session 仍在跑，必须调 terminate-session 或等空闲超时才真正释放集群资源。

  • 本版明确不支持：RDD-based API；多主节点高可用集群；Trusted Identity Propagation；通过 AWS Lake Formation 的细粒度访问控制。区域上排除 AWS GovCloud (US) 与 China Regions。私有子网集群还需要给 EMR service role 挂 AmazonEMRServicePolicyForSessions，以允许在账户内创建 NLB 与 VPC endpoint service。

行业影响

Spark Connect 本身不是新东西，这次的意义在于托管 Spark 把它做成了默认可达的形态，并且把”一个集群服务整个团队”变成了可量化的选项。每个 session 带自己的 execution role、tags 与 lifecycle，团队共享集群时可按 session 限定数据访问范围，按人分摊成本，单独停掉某个 session 也不影响他人。对平台团队来说，修补和监控的对象从几十个开发者各自的集群收敛成一个。

更值得注意的是它改变的是开发期的一致性来源。过去靠镜像、靠 requirements、靠”本地跑得通但集群上不一样”的经验来兜的差异，现在由”客户端连的就是生产集群”这件事本身消掉。代价被推到了边界上：客户端版本必须严格对齐、RDD 代码要改写成 DataFrame、Lake Formation 的细粒度管控暂时缺位。想在混合云或多区域落地的人要留意区域排除清单。

相关链接

ClickHouse 用八台同源集群测出：本地 NVMe 让 Postgres 吞吐差 9.2 倍，但换不了行的布局

事件概述

ClickHouse 的 Kaushik Iska 在 9 月 21 日发了一篇带完整基准方法的长文，回答一个被反复问到的问题：Postgres 跑在本地 NVMe 上，什么变了、什么没变。文章的前半段是一组只差存储介质的对照实验，后半段是一句诚实的结论——更快的盘抬高了上限，不改变行的物理布局。

实验设计值得单独说：八台完全相同的 m6id.4xlarge（16 vCPU、64 GiB RAM），跑源码编译的 Postgres 18.3，shared_buffers=16 GB，开 checksum，四台用实例存储 NVMe、四台用 3,000 IOPS 基线 gp3 EBS。数据集是 pgbench scale factor 33,000，堆大小 482 GiB、33 亿行、约为内存的 30 倍。负载是 16 线程 64 客户端跑五分钟，每台事务随机更新 33 亿行中的一行，八台并行，并用 Parca（eBPF）与 1 Hz 采样的 pg_stat_activity 全程 profiling。

技术解析

  • 吞吐与延迟：NVMe 上中位数 16,030 TPS，EBS 上 1,734 TPS，相差 9.2 倍。单次 UPDATE 延迟 4.0 ms 对 36.9 ms。

  • 进程状态分布：EBS 上每台 64 个 backend 里有 29 个（45%）停在 IO:DataFileRead，on-CPU 且无等待的为 0；NVMe 上 9 个（14%）在 IO:DataFileRead，13 个在 on-CPU 干真活，其余两边都主要在 LWLock:WALWrite。

  • CPU 账：NVMe 主机整轮跑掉约 2,253 CPU-seconds（约 9.4 核忙），EBS 只有 251（约 1 核）。EBS 的 per-function CPU 占比看着更高，那是比例不是吞吐——Postgres 两边干的活一样，EBS 上 89% 的 wall time 花在 off-CPU 等 I/O。作者的原话是 “EBS isn’t busy. It’s blocked.”

  • 周边子系统：清理 10 GB bloat 的 VACUUM，NVMe 366 s 对 EBS 964 s（2.6 倍），I/O wait 从 387 s 降到 3 s。约 10 GB slot 的逻辑解码，89 MB/s 对 52 MB/s，只有 1.7 倍，因为解码器单线程且串行读 WAL。

  • 本地 NVMe 的代价与解法：实例存储的生命周期绑在实例上，没有块存储快照模型，容量由机型决定。作者给出的两块积木是跨 AZ 的 quorum 同步复制（synchronous_standby_names = 'ANY 1 (standby1, standby2)'，等最快而非最慢的备库确认，可丢一个节点或一个 AZ）与 WAL-G 连续归档到 S3（RPO 秒级、十一个九的持久性）。持久性由此从存储层上移到 Postgres 与归档。

  • 为什么快盘救不了分析：Postgres 按 8 KB 页存整行，sum(amount) GROUP BY country 仍要把整行读进来。ClickHouse 每列一个文件、向量化执行、按列 codec 压缩（10 倍是常态）。文章点出现在撞墙时间变短了：数据从 10 GB 长到 100 GB 过去要 12–18 个月，现在 1–3 个月。

  • 两套引擎怎么接：应用照旧写 Postgres，CDC 把变更流到 ClickHouse，pg_clickhouse 扩展让应用沿用原有 Postgres 连接查询 ClickHouse 副本。PeerDB 在生产环境每月复制约 200 TB。新出的 WalShadow 直读物理 WAL 并转成 ClickHouse 原生 block，做到亚秒级复制且不用逻辑复制槽，目前是 Private Preview。

行业影响

这篇的价值在于它把”HTAP 要不要合一”这个抽象争论拆成了两个可分别决策的问题。快 OLTP 是存储问题：微秒级 cache miss、便宜的 fsync、可预测的 VACUUM，加 quorum 复制与 WAL 归档后可以拿到网络存储的韧性而不付网络存储的延迟。快 OLAP 是架构问题：没有哪种存储设备能让行存擅长扫十亿行，列存布局才能。

文章也给了评估这套组合时要盯的具体点：pg_clickhouse 的查询下推覆盖率（JOIN 语法差异让改写并不平凡），以及逻辑解码的单线程瓶颈不会因为换盘而消失。这套栈全部开源——Postgres、WAL-G、repmgr、PeerDB、pg_clickhouse、ClickHouse，可以在笔记本上跑通，这降低了验证门槛。

相关链接

阿里云八月数据库更新：LakeBase Catalog 把四个目录的元数据收成一层，AnalyticDB 给数据开分支

事件概述

阿里云 ApsaraDB 团队在 9 月 23 日发布了八月数据库新特性盘点，一共 10 项已验证发布，其中四项被列为重点。对数据基础设施从业者来说，最值得读的是两件以前要在应用层自己搭的事：跨异构目录的元数据统一，以及给数据做分支。

LakeBase Catalog 落在 PolarDB for PostgreSQL 上，把 PostgreSQL、Apache Paimon、DuckDB 与 Lance 四类 catalog 的元数据集中管理，用联邦 SQL 跨目录查询，每个 catalog 仍留在各自的系统里。AnalyticDB for PostgreSQL 的数据分支管理则面向按量付费的 AnalyticDB Supabase 项目，把 Git 的分支语义搬进了数据库：嵌套分支、分支保护、schema 查看、分支重置、快照与时间点恢复。

技术解析

  • LakeBase Catalog 的边界：它是一个元数据入口，不是一个存储层。跨目录的联合视图不再需要每次先跑一遍 ETL 把数据拼到一起。当前处于公测，需要提交工单申请。

  • 数据分支的语义细节：分支重置会用父分支的数据覆盖当前分支，不是合并，且会短暂中断连接；重置保留分支的连接信息，应用不需要重新配置。MAIN 分支不可删除、不可重置。功能是邀请制预览，预览期免费且不提供 SLA。

  • ApsaraDB for ClickHouse 26.3 LTS：社区兼容版 26.3.2.1-1.3.0，集成 ClickHouse 社区版 26.3 LTS（v26.3.17.4-lts）。扩大了对 Paimon、Iceberg、Delta Lake、Hudi 的访问，新增倒排索引、智能 JOIN 重排、物化 CTE、Bucketed Map、TTL 垂直合并、ALP 浮点压缩与多 SQL 方言兼容。限制写明：Paimon 目前只支持读。

  • PolarDB for MySQL 的 Limitless 多主架构：面向 MongoDB 兼容场景，数据库或集合可分片到最多 63 个读写节点，应用继续走 MongoDB Wire Protocol。官方说明澄清了”多主”的含义——同一时刻每个 database 或 collection 只有一个写属主节点，多主指的是属主权分布在集群上，不是多节点并发写同一集合。该能力处于 canary 发布，需工单申请。

  • SelectDB 的内核透明升级：升级前自动做参数兼容性校验与 SQL 回放验证，平台编排节点升级与服务切换。限制是大版本升级约 10 分钟中断、并行升级约 1–5 分钟，升级开始后不支持回滚，升级期间其他实例生命周期操作不可用。

  • 同期其余条目：SelectDB 的 DataLens AI 兼容 Langfuse 的端到端追踪（邀请制预览）；SelectDB AI 助手做慢 SQL 归因（免费公测，单次分析覆盖不超过 24 小时，需开启 SQL 审计与 enable_profile = true，不建议用于生产关键链路）；PolarDB PostgreSQL 兼容 Oracle 版的结构与权限校验工具（只比对不修复，需 Java 1.8+）；AliPG 20260830 给 PostgreSQL 18 加 tds_fdw、rds_duckdb 新增 all/record/none 三种自动建表模式；Tair 新增法国（巴黎）区域，仅支持云原生实例。

行业影响

把这两条放在一起看，方向是把两类过去由数据团队自己写脚本承担的负担上移到数据库层。跨目录联邦解决的是”找数据”的成本——分析或 AI workloads 想联合看 Paimon 湖表、Lance 向量数据与 Postgres 业务表时，不必先建一条搬运管道。数据分支解决的是”造环境”的成本——过去为了不污染主干，团队要么拷一份数据、要么在 SQL 里加一堆环境判断，现在分支重置一次即可，且连接信息不变意味着 CI 配置不用跟着改。

限制条款同样是信息：LakeBase Catalog 与数据分支都要工单或邀请，ClickHouse 侧的 Paimon 只读，SelectDB 升级不可回滚。这些决定了它们现在能进的是预发与非关键链路，而不是核心生产路径。

相关链接

Concurrence 把万亿 token 的 AI 访问收进 Unity Gateway，顺手退役了自建日志存储

事件概述

Databricks 在 9 月 23 日发了一篇医疗 AI 公司 Concurrence 的案例（作者为 Concurrence 的 Ali Khokhar、John Xing、Tony Shi 与 Databricks 的 Kelly Albano）。这家公司做临床 AI agent，覆盖患者端与医生端的工作流。规模数字是：每 30 天约 1,008 亿 input tokens、1,120 万次 LLM 调用，年化约 1.2 万亿 input tokens；月度 token 量相较 2025 年底的基线增长了约 5 倍（统计到 2026 年 7 月）。

对数据基础设施更相关的不是这些 AI 数字，而是它做的一次架构收敛：把患者状态、agent 与会话状态、trace、评估结果、治理与 AI 访问放在同一个受管基座上，并退役了自建的 prompt-log store 与 reverse-ETL 作业。

技术解析

  • 事件溯源式的患者状态：新信息记录为不可变事件而非覆盖已有记录，当前患者状态从事件历史算出，同时保留每条信息的来源与出处，团队称之为 world model。事件经 Zerobus Ingest 落入受管 Delta 表，每月 270 万条 world-model 事件，峰值每天 9 万条。

  • 测试流量大于生产流量：每个 agent 上线前先对模拟患者测试，目前仿真与评估流量约为生产流量的 7 倍。能做到这一点靠的是状态由不可变事件算出——可以重放状态、测试不同分支，不改动真实患者记录。

  • 编码 agent 走统一网关：2026 年 7 月，14 名用户经 Unity Gateway 产生 358.5 亿 input tokens，其中 95.37% 是 cache read。官方 coding CLI ug 自 7 月 10 日上线以来，编码 agent 累计约 36 万次请求、610 亿 input tokens。每次请求都关联到发起人的身份，MCP 访问按工程师组授权，访问 Databricks、Datadog、Linear 等工具时各自单独认证。

  • 合规门在成本门之前：批处理 AI 跑在 BAA 覆盖的 Databricks 托管 Claude 上，endpoint resolver 只允许 BAA 覆盖命名空间内的模型，避免 PHI 被路由到未覆盖的模型。文章把这条写成了原则——“routing is compliance-gated before it is cost-gated”。自杀倾向、自伤与医疗急症的安全分类跑在同一条受覆盖路径上。

  • 未搬完的部分也写明了：实时患者与临床推理目前仍在 Concurrence 原有的 provider 基础设施上；Unity Gateway 的实时推理集成已建好并加了 feature flag，用合成 canary 持续端到端测试，等合规覆盖到位再切生产流量。生产推理用 14 个模型，受管目录里共 46 个模型。

  • 被删掉的组件：迁移到这套架构后，Concurrence 退役了自建的 prompt-log store 和 reverse-ETL 作业，改用受管 Delta 表与 Lakebase Synced Tables。

行业影响

这篇最值得抄的不是规模，而是两处顺序安排。一处是”合规先于成本”的路由次序——多数多模型路由的讨论默认先谈质量与价格，这里把合规做成了一个前置的命名空间约束，用 endpoint resolver 之类的机制把约束落在执行路径上，而不是写在规范文档里。另一处是 retired 组件清单：自建日志存储与反向 ETL 是最容易被默认为”当然要有一套”的东西，当 trace 与业务数据落在同一个受管基座上时，这两层就没有存在理由了。

需要留意的是这是一篇厂商案例，没有给出性能基准或成本对比，规模数字也是客户自报。它的参考价值在于架构取舍的可复制性（事件溯源 + 统一网关 + 合规前置），不在于那串 token 数字。

相关链接

编者评

本期四条看起来分散在托管 Spark、OLTP 存储、云数据库与 AI 网关，合起来是一次边界重划：AWS 把”写代码的地方”与”跑代码的地方”拆开，ClickHouse 把”事务”与”分析”拆开，阿里云把”元数据”与”数据”、“开发分支”与”主干”拆开，Concurrence 把”业务数据管道”与”模型访问通路”拆开。拆完之后每一边可以各自选型——客户端留在笔记本上、分析留在列存里、catalog 留在各自系统上、模型调用留在网关后面。复杂度没有减少，只是从系统内部转移到了那条新划出来的边界，而且这条边界上的东西都还没长结实：连接串要手工补 :443，pg_clickhouse 的下推覆盖率要自己评估，LakeBase Catalog 与数据分支要工单或邀请，Unity Gateway 的实时推理还挂在 feature flag 后面等合规覆盖。

有意思的是四家各自给出的限制条款比功能清单更值得读。AWS 明写这一版不支持 Lake Formation 细粒度管控与多主节点 HA；ClickHouse 明写逻辑解码的单线程瓶颈不因换盘而改善；阿里云明写 Paimon 只读、升级不可回滚；Concurrence 明写实时推理还没切过去。这些条款共同说明一件事：拆开带来的自由度是一次性的，边界处的协议与能力补齐才是长期的活。

本期中文源落在阿里云八月的月度盘点上，是当月唯一够分量的中文发布；火山引擎的公开文档与开发者社区在本窗口内没有匹配的数据基建类更新。另有几条线索留到下期：Apache Iceberg 1.12.0 截至发稿仍停在 1.12.0-rc1（9 月 22 日打版，官方 releases 页最新仍为 1.11.0），Iceberg Rust 0.11 的发布投票此前已失败两次；Apache Doris 4.1.4.1-rc01、Apache Gravitino v1.3.1-rc2、Apache Beam v2.77.0-RC2 均为候选版，无可核实的正式发布说明；LanceDB 在 9 月 23 日连发 v0.40.0-beta.7 至 beta.9 三个预发布版本。Google Cloud 在 9 月 21 日发了一篇 Managed Spark 用 flexible VMs 应对机型缺货的最佳实践，其配套的 Yahoo 客户案例已在 Vol.62 报道，本篇的新增内容是分档机型表与配额、CUD、Hyperdisk 的取舍，暂不单列。