Spark 4.3 落进 Databricks Runtime 19：状态化 Real-Time Mode 三项基准 P99 全部压进 150 毫秒、Project Feather 给小数据迭代免掉 shuffle、Auto CDC 补上 SCD Type 2；ClickHouse 重估应用侧数据副本：Agent 的移动工作集让同步层失去摊销基础，NVMe 中央 Postgres 以约 4 倍于 RDS Multi-AZ 的同步复制吞吐主张简化；老主库还活着就晋升？Managed Postgres 用并行夺锁与双网卡设计把脑裂关在门外

11 月 3 日到 5 日，三条动态都在重新安排「副本」与「状态」的存放位置：Spark 4.3 进入 Databricks Runtime 19，聚合、去重与自定义状态处理进入 Real-Time Mode，三项有状态基准的 P99 端到端延迟全部压进 150 毫秒，毫秒级负载不再需要第二个流式引擎，小数据交互与 SCD-2 历史管道一并补齐；ClickHouse 先用一篇架构文章重估应用侧数据副本——同步层的摊销前提在 Agent 的移动工作集面前失效，NVMe 直连的中央 Postgres 以约 4 倍于 RDS Multi-AZ 的同步复制吞吐主张「先把数据库做快，再谈副本」；再用一篇工程深潜回答故障切换最硬的问题——老主库还活着就晋升怎么办，pg_stop 与 hba 锁不住已建连接，双网卡强制解绑与 Dynamic NIC 删除把写入路径从虚机外面掐断。状态进引擎，副本下沉，这是本期的主线。

Spark 4.3 进 Databricks Runtime 19：状态化 Real-Time Mode 转正，一个引擎吃完流式负载

事件概述

Databricks 工程博客发布《Introducing Apache Spark 4.3 - Now available in Databricks Runtime 19》，Spark 4.3 随 DBR 19 向平台用户开放。距离上游 4.3.0 发布（Vol.108 已报版本机制与流式 shuffle 基建）过去一周，这篇官方文章把落点放在了三块此前未被展开的能力上：Real-Time Mode 从无状态扩展到有状态处理——流式聚合、dropDuplicates 与 Scala/Java 的 transformWithState 进入低延迟执行模式，三项代表性有状态基准的 P99 端到端延迟全部低于 150 毫秒；Project Feather 面向小数据迭代砍掉固定执行开销；开源 Auto CDC 端到端补上 SCD Type 2。对 Spark 用户的直接含义：欺诈检测、持续更新的用户活动、设备监控这类「既要低延迟又要记得住上下文」的负载，不再需要为毫秒级延迟单独引入一个流式引擎。

技术解析

• 状态进 Real-Time Mode：流式聚合、dropDuplicates、transformWithState 三个有状态算子进入低延迟执行模式（SPARK-58635、SPARK-57228），编程模型不变——状态存储与 checkpoint 沿用 Structured Streaming 现有机制，耐久与恢复语义不动。官方基准（SPARK-58884）显示去重、窗口聚合、自定义状态处理三类负载的 P99 端到端延迟均低于 150 毫秒；文章明确指出这是三项实测负载的结果，不是对所有管道的延迟承诺。
• 执行引擎换轴：传统阻塞式 shuffle 要求生产 stage 完成后下游才能启动，撑不住长驻流式任务间的连续数据流。Spark 4.3 引入原生并发 stage 调度与流水线化 shuffle（SPARK-54699、SPARK-58076、SPARK-56664），新增 PipelinedShuffleDependency（SPARK-58185）让消费者在生产者仍在运行时就开始读取；调度器把由这类依赖相连的 stage 视为一个流水线组——整组一起调度、一起失败（SPARK-58263、SPARK-58398），任务槽不足时快速失败而非挂起。shuffle 按依赖类型路由到对应 manager，依赖定契约、manager 定传输。这套并发调度与流水线交换是通用引擎能力，不只为 Real-Time Mode 服务。
• Project Feather：针对「生成转换→小样本跑一遍→看结果→再改」的交互回路（无论人还是 LLM 助手在写代码），Spark 4.3 对符合条件的小型单分区查询片段提供 opt-in 的免 shuffle 单任务执行（SPARK-57851）——单个小文件扫描或不超过 1000 行的内存内关系，物理计划里原本会引入 shuffle 的 Exchange 直接省掉，支持的查询形态覆盖选择扫描、聚合、distinct、窗口、排序与 limit。配套的 Arrow 原生 Dataset 缓存（SPARK-57268，需在启动时设 spark.sql.cache.serializer 为 ArrowCachedBatchSerializer）按列存 Arrow 批、带压缩与列统计，Arrow 输入避免多余转换。进程内本地重分区的更大范围支持留给下个版本（SPARK-57399）。
• SCD Type 2 进开源 Auto CDC：管道可追踪每条记录的历史而非覆盖最新值（SPARK-56249），Python、SQL、Spark Connect 三面可用（SPARK-58321 等）。输出表用 __START_AT、__END_AT 两列标记每段记录的有效期；引擎侧做目标 schema 推导与专用 SCD-2 流处理（SPARK-58319 等），校验保留列、时序类型与历史追踪配置（SPARK-57251 等），并把窄化微批与演化后的目标 schema 对齐（SPARK-58418）。落地方式是每个微批一次 MERGE，目标表必须建在实现了 Data Source V2 行级操作的目录连接器上——Parquet 不满足，Iceberg 是典型选择。
• Spark Connect 与 Python 面：Connect 新增列出与检视会话/操作的 REST 端点与跨端追踪的 operation ID（SPARK-57941、SPARK-58547）；本地开发可用 SPARK_LOCAL_CONNECT_REUSE=1 复用常驻 Connect 服务器省启动开销（SPARK-57787）；JDBC 驱动补齐 ARRAY/MAP/STRUCT 结果与 schema 内省（SPARK-57380 等）。DataFrame.zip 不再退回 RDD API 即可合并同源投影（SPARK-55886）；pickle UDF 输入批可按字节数而非仅行数封顶（SPARK-57593）。
• SQL 面：纳秒时间戳进 opt-in 预览（SPARK-56822），TIMESTAMP_NTZ(p)/TIMESTAMP_LTZ(p) 精度 7 到 9，配套 timestamp_nanos、unix_nanos 函数（SPARK-57526 等）；JSON_TABLE 一次完成数组展开与字段抽取、列路径共享单次解析（SPARK-58366）；VARIANT 支持字段更新与删除（SPARK-57804 等）并把字段抽取下推到聚合/排序/join（SPARK-58089）；ASOF JOIN 进预览（SPARK-58092），按事件时刻对齐特征版本，取代手写范围 join 加排序。

行业影响

「不再需要第二个流式引擎」是这篇发布里分量最重的一句话。流式处理市场过去十年的默认答案是把 Flink 或专有引擎放在 Spark 旁边，代价是两套语义、两条运维路径；Spark 4.3 用统一 API 加通用流水线调度去换那一段距离，代价是 Real-Time Mode 的能力边界仍按版本逐版扩张。Project Feather 的指向更值得玩味：小数据交互过去是 DuckDB 这类内嵌引擎的主场，Spark 用免 shuffle 单任务执行与 Arrow 缓存把「跑个样本」的体验拉回自己的 API 面，摆明了是给 LLM 辅助开发的高频回路铺路。纳秒时间戳与 ASOF JOIN 则是在为事件密集型负载（特征工程、模型评估的时间点对齐）准备原料。一个引擎多吃一种负载，选型清单上少一行，绑定就深一分——这是 Spark 生态一直打的算盘，本版把筹码推得更靠前。

相关链接

• Introducing Apache Spark 4.3 - Now available in Databricks Runtime 19（Databricks Blog, 2026-11-05）
• SPARK-58884：有状态基准与延迟测量
• Apache Spark 4.3.0 文档

---

ClickHouse 重估应用侧数据副本：Agent 的移动工作集让同步层失去摊销基础

事件概述

ClickHouse 工程博客发布《Does your application need local data or faster Postgres?》，把一个老问题重新问了一遍：当中央 Postgres 变慢，是该在应用旁边放一份同步副本，还是先把数据库本身做快。文章给出的分析路径是——同步层的收益建立在一个前提上：工作集可预测、可预先声明，且多个消费者摊销同一份同步成本。AI Agent 把这个前提打穿了：Agent 的查询路径由运行时的提示词与上下文决定，读商品、找买家、再找相似商品一气呵成，开发者无法预先圈定子集边界；子集被迫放宽、按需加载又免不了远端请求，fan-out 的摊销基础随之瓦解。结论落在架构选型顺序上：先把数据库的存储做快（NVMe 直连计算），再谈应用侧副本。

技术解析

• 同步层的完整成本：sync 引擎订阅逻辑复制流，按声明的子集（哪些表、哪些行、哪些列）在应用本地物化一份副本。读路径确实本地化了，但写路径要单独维护——应用走自己的 API 写中央库，提交后再从复制流里等自己那条变更回来，客户端上一次写产生两个事件，应用要用乐观暂存态去调和「已提交的」与「已到达的」，提交被拒时还得回滚本地视图。
• Agent 打穿前提：传统应用的工作集有界——商品页读商品、账单页读一个账户；Agent 的导航路径运行时才确定，声明式子集要么宽到等于全量、要么靠渐进加载兜底。同步层的 fan-out 在「多消费者复用同一子集」时最划算，Agent 各要各的、还在变，摊销机会持续流失。文章把这一层追问得很直白：如果数据集是移动靶，这套架构还成立吗。
• NVMe 中央库的替代方案：ClickHouse Managed Postgres 把数据放在物理直连计算的 NVMe 上，与网络附加存储（RDS 的 EBS 卷、Neon 的存算分离）相比，读、写、WAL 与 VACUUM 后台工作共享的 IOPS 预算大幅放宽；I/O 受限的负载加计算无用，瓶颈在库底下的存储，这才是该先查的地方。
• 副本下沉而非外溢：应用侧副本解决不了耐久性，NVMe 贴着计算也意味着它跟着计算一起没了。该有的那份副本在数据库层——最多 2 个跨可用区 standby，双 standby 走同步仲裁（主库等至少一个确认才算提交），单 standby 走异步换低写延迟；WAL 持续归档到对象存储，基准备份支持 PITR。PostgresBench HA 轮实测：双同步 standby 配置下吞吐约为同配置 RDS Multi-AZ 集群的 4 倍——耐久没有把性能还回去。
• 边界诚实：NVMe 治不了低效查询，连接池、查询优化、并发控制仍是前提；该复制的复制一份在库底下由服务管，比每个应用旁边各养一份要省心。

行业影响

这篇是 ClickHouse Managed Postgres 的产品论证，但问题域是真的：本地优先（local-first）与 sync 引擎栈（ElectricSQL、PowerSync 这一类）过去两年的叙事建立在「中央库就是快不起来」上，文章用 Agent 工作集的不可预测性从这个叙事的根部拆了一刀。对架构师，实用的是一个判断顺序——先确认慢在存储还是慢在查询，再确认工作集是否稳定可声明；两问都答不上来之前，加一层本地副本是在给未来的自己造调和债。PostgresBench 的 4 倍数字由 ClickHouse 自己测，口径与配置照单全收前先复核自己的负载画像；但「NVMe 直连 + 数据库层复制」对抗「EBS + 应用侧副本」这两条架构路线的成本天平，确实被云厂商的网络附加存储定价长期掩盖着。Databricks 的 Lakebase（Vol.109、Vol.111 已报）与 ClickHouse 这套 Managed Postgres 走的是同一条路：OLAP 厂商把 OLTP 副本管理做成平台内建能力，数据库层的复制份内工作，正在被重新定价为卖点。

相关链接

• Does your application need local data or faster Postgres?（ClickHouse Blog, 2026-11-03）

---

老主库还活着就晋升？ClickHouse Managed Postgres 的 fencing 工程深潜

事件概述

11 月 4 日，ClickHouse 发布《Fencing a Postgres primary that might still be alive》，作者 Furkan Sahin（Ubicloud 首席工程师，PGConf.EU 2026 演讲《The Primary Is Down. Are You Sure?》的成文版）。文章回答托管 Postgres 服务最硬的一个问题：网络分区下控制面摸不到主库、客户端却还连得上，此时晋升 standby，老主库仍在收写——脑裂。解法叫 fencing：晋升之前先掐断老主库的一切写入路径。文章逐层展示了 Ubicloud（ClickHouse Managed Postgres 的开源控制面，两边团队自 Citus Data 与微软时代就在一起造托管 Postgres）在裸金属、AWS、GCP 三种环境下的并行夺锁设计，以及一个刻意选择的 fail-open 取舍。

技术解析

• 为什么晋升挡不住老主库：pg_promote 与 DNS 切换都管不住老主库继续收写。三个具体场景：单 standby 异步复制，主库本就不等它；双 standby 仲裁提交（ANY 1）下，只要另一个 standby 还在 ACK，主库照常提交；最隐蔽的一种——客户端取消查询或主库崩溃重启，已经写进 WAL 的提交会直接可见，这是 Postgres 同步复制的已知行为。所以必须在晋升前让老主库彻底无法被写入，fencing 的耗时就直接等于故障切换停机时间的下限——多机制并行、谁先成功谁算，是这个约束逼出来的设计。
• 虚机内的两件工具都不够：pg_stop 用 pg_ctlcluster 停集群，但 postgresql-common 的 start.conf 默认重启自启，VM 一重启主库复活；hba 锁门写新 pg_hba.conf 再 reload，规则只拦「新的连接尝试」，已建连接（包括 PgBouncer 的长驻服务端连接）不再过 hba 校验。两者还都依赖控制面能 SSH 进 VM——分区场景下这个前提不成立，必须从虚机外面动手。
• 裸金属：控制面连宿主机一起管，每台 VM 有独立网络命名空间，一对 veth 连通内外——客户端、复制、WAL 上传对象存储、控制面的 SSH 全走这一对。fence 就一条命令：ip link set vetho<vm> down。链路状态成对生效，命名空间外一切流量切断，Postgres 还在跑但谁也够不着它。
• AWS：主网卡（device index 0）运行中不可解绑，EC2 API 里翻遍没有满意的 fence 原语。解法是设计出来的——每台 Postgres 服务器双网卡：index 0 管理网卡走控制面 SSH，index 1 用户网卡挂公网地址、DNS 记录、客户端与复制流量。fence 就是强制解绑用户网卡（force: true，AWS 文档写着「last resort」，但这里旧主库不复用、网卡解绑后直到 VM 销毁，语义成立）。文章附了真实故障切换日志：SIGKILL 之后 pg_stop 找不到运行中的集群、hba reload 失败，detach NIC 是唯一成功的机制，13 秒后控制面从管理网卡收走老主库的内核日志。
• GCP：常规 NIC 创建时定死不可后删，2025 年 10 月 30 日 GA 的 Dynamic NIC 补上缺口——VLAN 子接口，增删不重启实例。用户网卡做成 Dynamic NIC，fence 是一次 deleteNetworkInterface 调用。删除后流量何时真正停没有文档承诺，实测：请求后 0.7 到 2.5 秒用户流最后一个包，操作标记完成在 5 到 7 秒。
• fail-open 的取舍：状态机为每个机制并行起子任务，全部失败时依然晋升——这是写进代码并用测试钉住的行为。更严格的设计会叫人值守，数据库在有人处理前没有主库；这里选了可用性。文章留给圈外读者的两条检查也实用：有 postgresql-common 的服务器先看 start.conf 停库后重启会发生什么；依赖删网卡做 fence 的，先确认你的云上哪些网卡能从运行中的 VM 上摘下来。

行业影响

fencing 是托管数据库里最难被营销、又最见真章的部分——SLA 页面上的 99.99% 背后就是这些细节。这篇文章的价值在于把三朵环境各自的 fence 原语盘点了一遍并给出可复用的结论：裸金属有宿主机视角、公有云只能靠 API 面，而 API 面里真正可用的原语（AWS 的次网卡强制解绑、GCP 的 Dynamic NIC 删除）都需要在组网时就预留——意味着 fence 能力是创建实例那一刻的决定，故障发生时没有补救窗口。fail-open 的选择同样值得对照自检：它把「脑裂丢写」换成「短暂双主窗口靠旧库失联兜底」，对多数应用是正确排序，但这个排序该由业务对丢写与停机的相对成本拍板，不是由托管商默认值替你拍。ClickHouse 连发两文（本篇加读路径那篇）把 Managed Postgres 从产品页推向工程叙事，与 Vol.111 里 clickhousectl 对 Postgres 运维面的持续加码是同一条路线的不同侧面——这个产品线在认真地对标传统托管 Postgres 阵营的基本盘。

相关链接

• Fencing a Postgres primary that might still be alive（ClickHouse Blog, 2026-11-04）
• ClickHouse Managed Postgres 产品页

---

编者评

把三条放回一起看，「副本放在哪」是本期真正的题眼：Spark 用流水线化调度把流式状态收进同一个引擎，省掉的是引擎级的重复；ClickHouse 两篇文章一个说应用侧副本在 Agent 时代失去摊销基础、该把复制下沉到数据库层，一个演示数据库层的那份副本如何在故障切换时把脑裂窗口关住——副本不是越多越安全，位置和时机才决定它的价值。三条动态合起来的趋势可以概括成一句话：数据栈的复杂度没有消失，但正在从用户的手里搬回系统的底层，搬的依据是 AI 负载的三个特征——工作集不可预测、迭代回路极短、时序精度要求更高。开源侧版本动态：Lance v15.0.0-beta.10（11-04）把节流错误上的 Retry-After 元数据保留进 namespace 层（标了破坏性变更）并修复聚类 restore 的定义覆盖，配套新增缓存指标；LanceDB 跟进 v0.42.0-beta.3/beta.4（11-04/11-05）；Arrow 26.0.1（11-03）转正式；Materialize v26.49.0（11-05）、Weaviate v1.39.15（11-04）、MatrixOne v4.2.8（11-04）为常规迭代；Daft 的 releases 通道连续第三期不可用，待确认。Databricks 同日另有一篇开放权重模型的企业论证（11-04），属 AI 战略文章，不入本期。中文源继续空转：阿里云博客页面第三期抓不到可解析的文章索引，火山引擎文档站 11-04 仅有一次 PostgreSQL 文档指南的例行更新，无产品发布，观察窗口继续顺延。