ITPub博客

 导读：两个 Agent 跑过同一批测试，最后生成的 patch 甚至逐字节相同。只看 PASS 率，它们几乎没有区别。展开 Trace，也就是一次任务中模型请求、工具调用和验证过程的完整记录，一个可能很快找到问题，另一个可能经历多次重复扫描和无效重试。本文介绍一套逐 span 评估 Agent Trace 的方法。Databend 保存并分析海量 Trace，普通代码处理可以直接确定的

 导读：Jev 最近很火，它擅长的语义判断如果直接放进数据库，能否让分类、筛选这类任务留在 SQL 里完成？本文以 Databend 的 Python UDF 集成为例，走通接入和查询过程，也看看远程模型调用的性能、成本与数据边界。最近Jev 突然火起来了，稍微试了下做分类任务效果非常不错，成本也低廉。所以给 Databend 的 Python UDF 写了一个 Jev 集成，顺手把过程

 导读：Databend 原生 Data Lineage 自 v1.2.935 起可用，在数据库内部采集数据流动关系，支持表级和列级追踪，并提供 Databend Cloud 血缘图和 SQL 查询两种分析方式。采集到的对象和字段依赖关系可用于变更影响分析、数据问题定位、数据资产治理和敏感数据传播追踪。数据血缘解决什么问题？表结构变更可能影响下游视图、数据任务和报表；指标异常需要沿加工链

 摘要：我让 gpt-6-astra 和 claude-fable-5.1 分别在 Evot、Pi、DeepSeek Harness 上修复 serde_json 的同一个 JSON 解析 Bug。六次运行都通过了完整测试，核心补丁逐字节相同。只看 PASS 率，六次没有区别。Trace 记录了另一组数据。GPT-6-Astra 平均请求模型 9 次，耗时 52.0 秒。Claude-F

 AI 系统越做越多、开发速度越来越快，为什么数据链路反而越来越长，数据工程也越来越复杂？导读：本文根据吴炳锡在厦门“智能体落地方法论：从技术构建到企业落地”行业技术沙龙的演讲实录整理而成。演讲结合头部模型公司、工业制造、公共数据平台、金融机构和 AI 应用企业的真实实践，讨论了 Agent Trace 与 Evals 数据的采集、加工、存储和分析难题，以及如何借助云原生湖仓简化跨云、多

 导读：物化视图并不只是缓存查询结果。本文将深入解析 Databend 如何通过 Change Tracking、Checkpoint 和 Read Fix，在降低刷新成本的同时保证查询正确性，并帮助数据工程师判断增量物化视图适合哪些应用场景。刷新可以延迟，结果不能过期物化视图（Materialized View，MV）通过预先计算并持久化高频查询结果，以额外的存储空间换取更低的查询延迟

 Cluster Key 专题介绍Cluster Key 系列希望帮助数据工程师从“会写 CLUSTER BY”走向“能够解释、设计并验证数据布局”。1. 原理篇：从传统分区到微分区，Snowflake 与 Databend 如何减少数据扫描？2. 最佳实践篇（本文）：从真实 Workload 出发，判断表是否值得聚类，并选择列、顺序和粒度。第一篇回答“Cluster Key 为什么能减

 Cluster Key 专题介绍Cluster Key 决定了大表中的数据如何在物理层面聚集，也直接影响查询需要扫描多少数据。但从“知道语法”到“真正用对”，中间至少隔着三个问题：它为什么有效、应该怎么选，以及 Databend 的实现有什么特点。本系列共 2 篇：1. 原理篇（本文）：从传统 Partition、Micro-partition 和 Block 出发，解释 Min/Ma

 导读：本文是《从万亿级大模型到全线应用：Databend Cloud 助力头部 AI 企业构建全链路 Trace 数据管道》的技术延伸，面向正在建设 Agent Trace、日志分析、Kafka 入仓或高吞吐半结构化数据管道的数据工程师，重点拆解 Agent Trace 从 Kafka 进入 Databend Cloud 的接入链路，以及开源项目 bend-ingest-kafka 在

 某中国头部 AI 大模型企业，以突破性的长文本处理能力与高阶推理技术著称，同时也是推动万亿级大模型开源的行业领跑者。随着其开源万亿级强化推理大模型投入应用，模型需要处理百万级超长上下文与 Agent 级复杂任务。一次长任务可能包含数千次工具调用，累计处理数百万 context tokens。随任务一起快速增长的，还有记录模型决策、工具调用与执行过程的 Agent Trace。这款模型上

 导读：过去两个月，Databend 的技术迭代沿着三大方向加速推进：从让优化器更精准地理解数据，到推动空间索引从扫描剪枝跨越至 Join 优化，再到持续扩充 Paimon、Iceberg 等开放湖仓生态。与此同时，80 余项 Bug 修复进一步清除了查询正确性、执行稳定性与升级兼容性上的问题。本文梳理 2026 年 6–7 月 Databend 及 Databend Cloud 的重点

 导读： 查询优化器既要了解数据的整体分布，也要识别少量高频值，否则就可能在 JOIN 顺序、扫描策略和算子选择上做出错误判断。本文结合 Databend 的实现与 Benchmark，介绍 KLL、Top-N 和 Count-Min Sketch（CMS）如何分工协作：KLL 以较低内存开销构建近似等深直方图，Top-N 精确记录最常见值，CMS 则补足未被 Top-N 保留的热点。适

 导读：QUALIFY 的价值不只是“少写一层子查询”，更重要的是把窗口函数的计算与过滤放回同一个语义层里表达。本文通过事件去重、Top N 排名、CTE 拆分和子句分工等常见场景，说明如何用 QUALIFY 写出更清晰、更稳定、更容易维护的 SQL，适合数据工程师、Analytics Engineer 和经常编写复杂分析查询的开发者阅读。为什么 QUALIFY 不只是少一层子查询提到

 导读：AST Visitor API 迁移看起来像一类适合 AI 批量生成的工程任务：节点多、模式重复、样板代码占比高。但真正的风险不在“代码能不能写出来”，而在“写完之后如何证明没有漏掉节点、重复访问字段或改变遍历顺序”。本文以一次 Visitor API 迁移为线索，介绍一套从源码扫描、运行时 trace、独立比较、失败定位，到真实 SQL 语料和覆盖率反馈逐渐形成的可执行验证体系

 导读：数据入仓看似只是“把文件导进表里”，真正上线后却会遇到调度、重试、去重、凭证管理和失败恢复等一连串工程问题。本文用一个最小可跑通的示例，演示如何用 Airflow 编排本地 CSV / NDJSON 文件，经 S3 暂存后导入 Databend Cloud，并进一步说明这条链路如何扩展成一套可重跑、低运维、面向云原生数仓的数据入仓实践。阅读时间约为 6 分钟。为什么需要一条可重跑

 导读：本文介绍 Databend 针对 Bitmap 聚合场景的一次性能优化：通过引入 HybridBitmap，在小集合阶段使用轻量的 SmallBitmap，只在集合真正膨胀后切换到 RoaringTreemap，避免大量小 bitmap 被过早反序列化和构造成完整大集合结构。Benchmark 显示，在大量小 bitmap 聚合场景下，bitmap_intersect、bitma

一个轻量级 histogram 如何在低开销与高精度之间取得平衡？

湖仓的竞争正从「SQL 多快、存储多便宜」，转向「Agent 多可靠、业务任务多安全」

Databend 云原生湖仓同时支持私有化和公有云两种部署形态，因此在写入方式上也共提供了4方式种选择。本文一方面通过性能测试认识不同形态的性能差异，另一方面也尝试理解这些设计背后的原因，进而体会如何结合业务场景选择最适合的写入方式。

Databend 正式从单一数仓进化为 Analytics + Search + AI 一体化数据库，v1.3 版本即将发布