数据库行业日报
本期要点
· 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 有了自己的 IDE · 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]