━━━━━ 正文从此处全选复制 ━━━━━

FutureX · Database

本期要点

· Snowflake Semantic Studio 转 GA，semantic view 的编写移进 Workspaces，与 SQL、notebook、dbt 项目放在一处

· pg_lake 3.5 不再绑定 Polaris 的 URL 布局，Postgres 可经 Lakekeeper、Nessie 等 REST catalog 读 Iceberg 表

· ClickHouse 推出官方纯 C 客户端 clickhouse-c，header-only，直连原生二进制协议

· Amazon EMR 8.1.0 支持 multi-catalog：Iceberg / Hudi / Delta / Hive 共用一个 catalog，跨账号 join 无需拷贝数据

· 论文实测语义查询引擎：temperature 0 下同一查询重跑 5 次，最多 10.2% 的行输出发生变化

▎ 版本与产品发布

ClickHouse 发布纯 C 语言客户端 clickhouse-c · olap

ClickHouse 官方在其 GitHub 组织下推出了 clickhouse-c。它是一个只有头文件的 header-only C 库，使用原生二进制协议（基于 TCP，数据分块传输，也支持压缩）与服务器通信，因此既不需要走 HTTP 接口，也不必引入体量较大的 C++ 客户端 clickhouse-cpp。官方文档说明，核心头文件 clickhouse.h 负责 Native 格式数据块的编码和解码，clickhouse-client.h 负责 TCP 上收发数据包的循环，压缩相关的头文件则要链接 LZ4/ZSTD。socket、TLS、内存分配、重试以及连接池，库本身都不提供，需要调用方自行处理。该项目仍在积极开发中，v1 版本已能解码 ClickHouse 的核心类型。

在这之前，ClickHouse 官方提供的客户端涵盖 C++、Go、Java、Python 等语言，唯独没有纯 C 的版本。C 库依赖少、移植容易，嵌入式环境和对性能要求高的服务可以直接采用，Rust、Ruby 等语言也能在它的基础上做 binding。对 ClickHouse 而言，这一变化降低了各类运行时接入的门槛，查询引擎本身并没有改动。[1]

其他版本动态：
· ClickHouse 陆续发布了 v26.9.17.8-stable、v26.8.25.14-lts、v26.7.28.6-stable、v26.3.49.3-lts 等多个补丁版本。Weaviate 推出 v1.40.1，并把修复回补到旧版本线 v1.39.12 / v1.38.21，解决了 schema 删除后重建 class 的问题，还加快了启动时对向量维度重建索引的速度。Apache Paimon 发布 2.1.0，PyPaimon 2.1.0 同步发布，目前公开的变更说明主要是兼容性和谓词裁剪方面的修复。LanceDB v0.41.0-beta.6 开放了 search effort 参数，官方把这项改动标注为破坏性变更。RisingWave v3.0.5 可以按表查询 Iceberg 元数据。TiDB 的每日构建在 CBO 中加入 late materialization，做法是先按过滤条件筛出行，再去读取其余的列。YugabyteDB 2.31 预览构建调整了 xCluster DDL 的提交时机，改为等向量索引建完之后再提交。Apache Doris 4.1.5-rc03 和 Apache Hudi 1.1.2-rc1 则进入了候选发布阶段。[2]

▎ 数据库 × AI

Snowflake Semantic Studio 转 GA：semantic view 拥有了专用的开发界面 · ai-native

Snowflake 宣布 Semantic Studio 正式可用。该产品 8 月 26 日进入公开预览，如今把 semantic view 的编写搬进了 Workspaces，与团队原有的 SQL、notebook、dbt 项目处在同一个地方。它还增加了 git 版本管理，并和 Snowflake 的编码 agent CoCo 做了深度集成。semantic view 是供 agent 和 BI 工具读取的指标及业务语义定义。

Snowflake 在博文中说明了改动的缘由。semantic view 起初只是单个 Cortex Analyst 部署所用的上下文，通常由一两位熟悉数据的人负责维护。data agent 普及以后，每个 agent、每个 BI 工具都要读取它，只改一行定义，就会同时影响所有调用方。过去要排查一次 agent 的错误回答，得在监控、agent trace、worksheet 和 semantic view 编辑器这 4 个界面之间来回切换。现在只要把监控中的 request ID 交给 CoCo，它就能找到出问题的定义并完成修改。Snowflake 表示，内部遥测数据显示，超过半数的 agent 构建者需要在 semantic view 界面和 agent 管理界面之间反复切换。

行业里的做法正趋向于把语义层当作 agent 的上下文来管理。Snowflake 这次则把语义层的工程化工作，包括版本管理、评测和调试，都放进了自家的开发界面。[3]

Elastic 称仅靠向量检索难以命中产品编号，RAG 应采用混合检索 · vector ⚠️ 厂商口径

在 AI Engineer 大会的一场工作坊上，Elastic 的 Jeff Vestal 和 James Williams 指出，像「XK-47-B」这样本身没有语义的产品编号，语义检索无法处理；而 BM25 词法检索又应付不了口语化的提问。因此两种方式需要一起使用，只有在对相关性指标有要求时，才再加上 re-ranker。两路结果的分数尺度不一样，合并时可以采用 RRF（倒数排名融合，只看名次、不用分数），也可以先对分数做归一化再加权。他们还提到，不少只用纯向量库的团队，会另外接入一套检索系统来拼出混合检索；Elastic 的卖点则是一次 API 调用就能走完从切块到查询的整个流程。以上属于厂商立场的论述。[4]

▎ 湖仓 · 开放表格式 · HTAP

pg_lake 3.5：Postgres 可连接任意 Iceberg REST catalog · lakehouse

pg_lake 是 Snowflake 开源的 Postgres 扩展，使 Postgres 可以直接读写对象存储中的 Iceberg 表。它一开始就自带 Iceberg REST catalog 客户端，但请求路径固定为 Apache Polaris 的 /api/catalog 布局。原因在于 REST 规范只规定了 API 的路径，并没有规定它挂在服务器的什么位置。9 月发布的 3.5 版取消了这一限制，现在可以连接 Lakekeeper、Nessie 等 catalog，也能使用 catalog 下发的存储凭证。

不过目前只有 Polaris 支持写入，其他 catalog 暂时只能读取。下一版本计划加入路径前缀的自动发现，让 catalog 配置出错时的提示更清楚，提供无需认证、供开发测试使用的 catalog，并支持 Unity Catalog。沿着这个方向，权限由 catalog 层统一决定，Postgres 和数仓不必各自维护一套。业务库可以直接查询分析引擎产出的表，也可以把事务写入湖仓格式，省去把数据回传的管道。[5]

Amazon EMR 8.1.0 支持 multi-catalog，可跨表格式、跨账号查询 · lakehouse

AWS 介绍了 EMR 8.1.0 中的 RedirectingSessionCatalog（RSC），用来解决 Spark 长期存在的两个问题。第一，默认 catalog 同一时间只能挂载一种格式扩展（Iceberg、Delta、Hudi 中选一个），查询其他格式的表就会失败。第二，V1 metastore 只能绑定单个账号的 Glue Data Catalog，要跨账号访问 Delta、Hudi、Hive 表，只能依靠 Lake Formation 授权、RAM 共享和 resource link 一层层绕过去。

RSC 提供三项能力，均需手动开启，并且向后兼容。其一，它根据 Glue 元数据自动识别每张表的格式并分派，使 Iceberg / Hudi / Delta Lake / Hive 共用同一个 catalog。其二，通过具名 RSC 做跨账号 join，无需复制数据。其三，在查询时动态发现并注册远程 catalog。各业务域分账号持有数据、分析却集中进行的 data mesh 架构，对这些能力的需求最为迫切。这也表明，在云厂商一侧，多种格式并存依然是常态，主要由 catalog 层来统一，而不是收敛到某一种格式。[6]

▎ 技术 · 架构 · 性能基准

性能 · 基准

· Delta Lake 上 Liquid Clustering 在 4 类负载中赢 3 类 ⚠️ 单方口径：这是一位作者自行运行的基准，使用 5000 万行合成的零售交易数据，在 Delta Lake 上比较 Liquid Clustering、ZOrder 和分区三种做法。Liquid Clustering 在点查（1.003 s）、时间范围聚合和大聚合三类负载中延迟最低；ZOrder 仅在固定多列的选择性过滤上领先，耗时 615 ms、扫描 59 MB，而 Liquid Clustering 扫描了 640 MB。有一点与常见建议相反：当日期列在 ZOrder 键中排第三位时，时间范围查询耗时 1.845 s，比单纯按日期分区的 1.038 s 慢了 78%。此外，Liquid Clustering 点查读取的字节数超过 ZOrder 的两倍，速度却更快，可见扫描字节数并不能直接反映性能。这次基准未测量写放大和维护开销。[7]

学界 · 研究前沿

· Same Query, Different Answer（arXiv 2610.13823）：作者重新运行了 SemBench、LRO-Bench、UDA-Bench 三套基准，累计记录 120 万次模型调用。即便 temperature 设为 0，重复运行 5 次，仍有 0.07% 到 10.2% 的行输出出现变化，单个任务中最高达 24.0%。在 UDA-Bench 上，发生变化的抽取值只有几个百分点，最终答案却有约三分之二随之改变。当前对语义查询引擎的横向评测，普遍只比较寥寥几次运行，这一结果会直接影响此类结论是否可信。[8]

· Semantic Views（arXiv 2610.12768）：语义查询引擎每用 LLM 判断一行数据，就要付出一次调用的费用。SemViews 把此前查询留下的 LLM 标签保存为「semantic view」，再借助本地 embedding 和辅助小模型对候选行排序，并通过新的分层抽样做验证，从而保证结果以不低于 1−δ 的概率满足用户设定的精确率和召回率。如果缓存的标签已经过期或本身有误，后果是要多花一些调用次数，准确率不会因此下降。[9]

· Stretto（arXiv 2602.04430）：这是一个语义查询执行引擎，它把查询计划建模为约束优化问题，并用基于梯度的优化器，一边选择各算子的实现方式，一边在整个计划范围内分配误差预算。它提供的是整体计划层面的准确率保证，而不是针对单个算子的保证。[10]

· LLM ORDER BY 的访问路径（arXiv 2509.00303）：这项工作把「LLM ORDER BY」当作一个逻辑算子，系统地比较了它的多种物理实现，并提出了语义感知的外部归并排序。结果发现，没有哪一种实现能在所有数据集上都表现最优，于是作者据此设计了能按预算选择访问路径的优化器。[11]

文中 [N] 为来源编号，全部来源链接请点文末「阅读原文」查看。

FutureX · 记录未来如何发生

素材来源多方媒体/网络新闻