导读：过去两个月，Databend 的技术迭代沿着三大方向加速推进：从让优化器更精准地理解数据，到推动空间索引从扫描剪枝跨越至 Join 优化，再到持续扩充 Paimon、Iceberg 等开放湖仓生态。与此同时，80 余项 Bug 修复进一步清除了查询正确性、执行稳定性与升级兼容性上的问题。本文梳理 2026 年 6–7 月 Databend 及 Databend Cloud 的重点更新，并基于一条真实的模型 Eval 观测数据管道，实战演示如何将这些新能力有机串联。

两个月，182 项更新

从 v1.2.916-nightly 到 v1.2.930-nightly，加上 7 月发布的两个 patch 版本，Databend 主仓库在 2026 年 6–7 月共发布：

• 15 个 nightly 版本：6 月 11 个，7 月 4 个
• 2 个 patch 版本：均发布于 7 月

按 release note 统计，两个月累计合并约 182 项更新：

• 40 个新功能
• 80 个 bug 修复
• 33 项重构
• 18 项维护工作
• 9 项 CI / 构建改进
• 1 项文档更新
• 1 份 RFC

修复仍然占据最大比重，但这次更新并不只是稳定性迭代。优化器统计、Spatial Index Join 和 Paimon Catalog 都代表了明确的新方向。

优化器统计：从“估一个大概”到更接近真实分布

查询优化器需要根据数据分布决定 Join 顺序、扫描方式和算子组合。如果统计信息不准确，尤其是在数据倾斜或高频值明显的情况下，即使 SQL 不变，也可能得到代价很高的执行计划。

这两个月，Databend 对统计模块进行了集中升级：

• KLL Histogram：RFC 定义了基于 KLL Sketch 生成 ANALYZE 直方图的方案，并完成实现。它在统计精度与内存占用之间取得了更好的平衡。
• Count-Min Sketch：以较低的空间成本估算值的出现频率，帮助优化器识别高频值和数据倾斜。
• Top-N 选择率估算：利用 Top-N 统计改进等值条件的选择率判断，并在数据追加后自动刷新。
• 在 EXPLAIN 中展示剪枝 IO：执行计划现在能够直接显示剪枝阶段的 IO 代价，索引减少了多少扫描不再只能靠推测。

对于使用者，这类更新通常表现为“无须修改 SQL，但计划更合理”。对完成过 ANALYZE 的表，等值过滤和范围过滤的行数估算会更接近真实数据分布。

ANALYZE
 TABLE events;



EXPLAIN


SELECT
 *


FROM events


WHERE user_id
 =
 42;

空间分析：索引开始参与 Join

上一阶段，Databend 已经可以使用空间索引进行扫描剪枝。这次更新继续向前一步： 空间索引开始参与连接计算。

典型的空间关联查询，例如“找出位于每个行政区域内的兴趣点”，如果直接对两张表逐行执行几何判断，数据量增长后代价会迅速上升。基于 R-Tree 的 Spatial Index Join 可以先缩小候选范围，再执行精确的空间关系计算。

本次主要更新包括：

• 单机 Spatial Index Join：利用 R-Tree 加速空间关联，避免对两张表进行完整的两两比较。
• 分布式 Broadcast Spatial Join：在集群中广播较小的空间表，提升大表关联小空间表时的执行效率。
• 更低的 Geometry 处理开销：通过流式提取 bounding box 避免整体反序列化，并使用 geozero 直接从 EWKB Header 读取 SRID。

同时，Join Planning 中原有的 spatial runtime filters 已被移除，并补充了空间连接的正确性回归测试。


SELECT

    r.region_name,

    p.name


FROM regions
 AS r


JOIN pois
 AS p


    ON ST_CONTAINS(r.boundary, p.location);

开放湖仓：新增 Paimon Catalog

湖仓生态中最重要的进展是 Paimon Catalog 接入，而且这项能力来自社区贡献。

Databend 现在可以直接读取 Paimon 表，并支持分布式写入。已经使用 Paimon 构建数据湖的团队，可以在保留现有存储和表格式的情况下，将 Databend 接入分析链路，减少数据复制和中间转换。

Iceberg 兼容性也得到进一步完善：

• 修复谓词下推过程中未保留受支持谓词合取项的问题，让下推更加完整。
• 在 CI 中增加对 Iceberg Variant Metadata 读取的覆盖，降低兼容性回归风险。

这些改动延续了 Databend 对开放表格式的支持方向：让计算引擎可以直接连接已有湖仓，而不是要求团队先迁移数据。

数据加载与导出：补齐数据“出口”

相较于已经较为完整的导入能力，这两个月的更新重点补强了数据导出和文件可追溯性。

更可靠的 Schema 推断与文件追踪

NDJSON Schema 推断得到改进。同时，Stage 增加了一组文件级元数据列：

• metadata$file_path
• metadata$file_basename
• metadata$file_content_key
• metadata$file_last_modified

metadata$filename 对 CSV、Text、NDJSON 和 Avro 也会返回 Stage 相对路径。发生数据异常时，可以直接定位记录来自哪个文件、何时进入系统。


SELECT

    metadata$file_path,

    metadata$file_last_modified,

    $
1


FROM
 @stage
/
in (FILE_FORMAT
 =
>
 'ndjson');

SQL 与数据管道：减少日常操作中的绕路

这次更新还包含一组面向日常开发的改进：

• ILIKE：支持大小写不敏感的模式匹配，不再需要手动组合 LOWER()。
• PostgreSQL 聚合语法兼容：降低 PostgreSQL 查询迁移时的改写成本。
• Stream Backlog：新增 Backlog API 和表函数，并通过快照逻辑变更计数改进估算。
• Materialized CTE：为需要复用中间结果的查询提供更明确的执行语义。
• 虚拟列开放到社区版：让半结构化数据的常用字段可以更高效地参与查询。
• Time Travel 快捷路径：新增 NO_CHECK 快照查找，并利用 UUID v7 进行时间戳导航。


SELECT
 *


FROM logs
 WHERE msg ILIKE
 '%timeout%';


SELECT
 *
 FROM stream_backlog(
'my_stream');

存储与执行：让批量写入和后台维护更平稳

在存储与表管理方面，更新重点集中在并行执行、聚簇维护和资源峰值控制。

Multi Insert 支持分布式写入

INSERT ALL 和 INSERT FIRST 等一条语句写入多张表的场景，过去写入阶段集中在单节点执行。现在，写入任务可以分散到多个 Fragment 并行运行，各节点产生的 Commit Metadata 最终由 Root Fragment 汇总并统一提交。

这让大批量、多目标表写入能够更充分地利用集群资源。

聚簇与存储维护

• 增加聚簇深度百分位指标。
• 有序任务可以跳过不必要的 Partial Sort。
• 移除旧版 Hilbert Clustering 实现。
• 引入新的 Parquet Writer，并针对公共前缀优化字符串统计长度。
• Vacuum2 改为增量删除 Block，降低峰值开销。
• 限制并发 IO 操作数量，避免瞬时请求打满存储层。

安全与治理：收紧网络出口和租户边界

这两个月的安全更新主要围绕外部访问控制与多租户隔离展开：

• Endpoint Egress Policy：支持 Allowlist 模式的 endpoint_url_policy，限制查询能够访问的外部端点。
• Stage 路径遍历防护：增加 Stage Path Traversal Policy，并将相关开关从 Settings 移至 Config 层。
• 连接信息脱敏：进一步隐藏日志和错误信息中的连接凭据。
• 租户隔离修复：处理 Session Tenant Override、HTTP Session State 隔离，以及 Reload Race 期间可能出现空 Role Cache 等边界问题。

这些能力对生产环境尤其重要：系统不仅要能够访问外部数据，还需要明确限定数据可以流向哪里，以及不同租户之间如何保持隔离。

Databend Meta：用 Lua 编排事务

Databend Meta 新增 Lua Transaction 支持，可以通过 Lua 脚本编排 Meta 上的事务操作。配合 metactl.now_ms() 单调时钟，以及按顺序执行 Lua 源文件的能力，运维和元数据自动化拥有了更灵活的编程接口。

底层工程也在持续更新：

• 新增 Protobuf Storage Variants，并消除 Proto 编码失败路径。
• 继续拆分 Key Error Builder。
• 解耦 Index 与 Database 的 Create Option。
• 按 ID 拆分 Dictionary 更新。
• 为 metabench 增加 Bulk Load 与 Random Read 基准。

稳定性：80 个修复主要解决了什么

如果把 80 个 bug 修复按影响归类，可以看到几个清晰的重点。

避免查询崩溃或卡死

• 修复深层嵌套表达式引发的 Stack Overflow（SIGSEGV）。
• 修复 Runtime 析构阶段可能出现的自死锁。
• 修复 Recluster 因 Block 大小估算不一致陷入死循环的问题。

收敛结果正确性的边界

• 修复 UNNEST 处理 Nullable Array / Variant 时的问题。
• 修复 Date / Timestamp 算术溢出时的定义域计算。
• 修复 GROUPING SETS 中 SELECT Alias 遮蔽列的问题。
• 子查询返回空结果时，变量会被正确设置为 NULL。

避免 Join 与谓词优化走错路径

• 修复等值 Hash Join 错误退化为 Nested Loop Join。
• 改进单行不等式 Join 的安全处理。
• 修复 Null-Safe Join Key 被 Null Filter 规则丢弃的问题。
• 修复 Filter 下推过程中 Union Coercion 丢失的问题。

提升升级兼容性

• 恢复对 Legacy Bincode v4 Segment 的读取支持。
• 恢复 Cluster Stats Pages 的回滚兼容性。
• 保证 Commit Metadata 中 HLL 行数统计的确定性。

这些修复单独看并不显眼，但它们决定了长时间运行的查询、管道和升级流程是否可信。

实战：构建一条模型 Eval 观测数据管道

下面用一个实际场景串联 Stage 元数据、Variant、Stream、Task 和 Stream Backlog：把模型评测产生的观测数据构建成一条自动清洗管道。

数据流如下：

Eval JSON → S3 Stage → Raw Table → Stream → Clean Task → Clean Table

模型 Eval 的观测数据首先以 NDJSON 文件写入 S3。Task 定时将新文件加载到 Raw Table，Stream 捕获新增记录，另一个 Task 消费增量并将嵌套 JSON 展开为结构化数据。

1. 加载原始数据并记录来源

Raw Table 使用 VARIANT 保存完整 Payload，同时记录来源文件和加载时间。这让后续分析可以追溯到具体的 Eval 文件。


CREATE TABLE eval_raw (

    payload   VARIANT,

    file_path STRING,

    loaded_at
 TIMESTAMP

);




COPY
 INTO eval_raw


FROM (


    SELECT

        $
1,

        metadata$file_path,

        NOW()


    FROM
 @eval_stage (FILE_FORMAT
 =
>
 'ndjson')

);

2. 用 Stream 捕获新增数据

CREATE STREAM eval_stream ON TABLE eval_raw;

Stream 让清洗任务只处理新增变化，避免重复扫描整张 Raw Table。

3. 展开 JSON 并写入 Clean Table

Databend 可以通过路径表达式访问 VARIANT 字段，使用 :: 完成类型转换，并用 FLATTEN 展开数组。


INSERT INTO eval_clean


SELECT

    payload:model_name::STRING
   AS model_name,

    payload:eval_id::STRING
      AS eval_id,

    payload:
timestamp::
TIMESTAMP
 AS eval_time,

    sample:input::STRING
         AS input,

    sample:score::
DOUBLE
         AS score,

    sample:passed::
BOOLEAN
       AS passed


FROM eval_stream,


LATERAL FLATTEN(input
 =
> payload:samples)
 AS sample


WHERE payload:model_name
 IS
 NOT NULL;

4. 监控清洗任务是否跟得上


SELECT
 *


FROM stream_backlog(
'eval_stream');

如果 Backlog 持续增长，说明清洗 Task 的执行频率或计算资源需要调整。Stage 元数据负责来源追踪，Stream 负责增量捕获，Stream Backlog 则提供管道积压的直接观测。

支撑这条管道的 Private Task 在 6–7 月也完成了一系列可靠性修复，包括：

• 让 Task History 与 Databend Cloud 保持一致。
• 解开失败 Task Run 的卡死状态。
• 在 ALTER SET 时保留 Task 选项。
• 删除 Task 时取消正在运行的 Task Run。
• 触发所有已经就绪的后继 Task。
• 改进 Task Run 的追踪能力。

对于需要长期自动运行的数据管道，这些行为边界往往比单个新语法更重要。

Databend Cloud Agent 进入内测

Cloud Agent 是嵌入 Databend Cloud 控制台的 AI 助手，目前正在内测，后续将逐步开放试用。

用户可以使用自然语言提出任务，Agent 通过 21 个能力域、约 110 个工具，在控制台内执行数据查询、集群管理、账单排查、数据同步和图表可视化等操作。它的目标不只是回答“应该怎么做”，而是进一步完成实际操作。

客户端与驱动更新

主仓库之外，客户端和驱动也完成了配套迭代。

bendsql

• v0.34.1（7 月 8 日）：新增 Python 3.14 支持与密钥对认证；修复 CLI 将 BEGIN ... END 脚本块按内部分号错误切分的问题。
• v0.34.2（7 月 16 日）：修复 Node.js Windows 构建。

databend-jdbc

v0.4.7 和 v0.4.8 于 7 月 14 日发布，重点包括：

• 接入 Arrow HTTP Result 与分页预取。
• Arrow 格式支持 Decimal。
• 支持 Auto Presign。
• 从 databend-client 解耦。
• 改进 Session / Presign 错误处理与指数退避重试。

这些更新未必会出现在功能演示的第一屏，却直接影响应用接入 Databend 时的稳定性和开发体验。

结语

回看 6–7 月，Databend 一边继续收敛生产环境中的正确性与稳定性问题，一边扩展优化器、空间分析和开放湖仓能力。优化器开始用 KLL Histogram、Count-Min Sketch 和 Top-N 更准确地理解数据；空间索引从扫描剪枝进入 Join；Paimon 通过社区贡献接入 Databend；Stage、Stream 和 Task 则逐渐组合成更完整的数据管道能力。

这些改进也让 Databend 更适合 Agent Trace 场景。Agent 运行会持续产生结构多变的 Prompt、Tool Call、Span、延迟、Token 消耗和 Eval 结果。Databend 可以用 VARIANT 保留原始 Trace，通过 Stream 与 Task 增量处理，并利用列式分析、数据剪枝和 Time Travel 完成聚合、排障与回放。

Databend 的优势不只是存储 Trace，而是把接入、处理、Eval、查询和长期留存放在同一套系统中。它面向 Data Agent 提供统一的数据基础设施，在一个 S3 原生、弹性的数据仓库中承载 SQL 分析、JSON 与全文搜索、向量检索，以及 Agent Trace 和 Eval 工作负载。相关能力已在中国头部 AI 公司的大规模生产场景中得到验证。

Databend 是一款面向现代数据与 AI 工作负载的开源云原生数据仓库，欢迎参与社区讨论、贡献和产品试用：

• 官网： databend.cn
• 文档： docs.databend.cn
• GitHub： databendlabs/databend

ITPub博客

Databend 产品更新：从 Spatial Index Join 到 Eval 数据管道