我们构建了SmithDB，用于代理可观测性的数据层

# 我们构建了 SmithDB：智能体可观测性的数据层 来源：https://www.langchain.com/blog/introducing-smithdb 我们正式推出 SmithDB——专为智能体可观测性而构建的分布式数据库，现已成为 LangSmith 核心工作负载的底层支撑。 SmithDB 为 LangSmith 在关键可观测性工作负载上提供了行业领先的性能，具备可移植性，能部署在客户数据所需的任意位置，并支持传统可观测性存储无法处理的、智能体原生的查询模式。 ## 智能体带来了全新的数据难题 在智能体可观测性领域，追踪数据扮演着智能体核心行为记录的角色。 当 LangSmith 在 2023 年首次发布时，AI 应用相对简单：团队主要构建 RAG 流水线、提示链以及非常早期的智能体。 自那以后，智能体变得越来越普遍且运行时间更长，LLM 上下文窗口大小急剧增加，工作负载中也越来越多地包含多模态内容，如图像和音频。 结果，与现代智能体相关的追踪数据在数量（追踪条数）和规模（单个负载大小）上都出现了爆炸式增长。一个现代智能体的追踪可能包含数百个深度嵌套的跨度。  除了规模庞大且结构嵌套，智能体追踪数据还会分片到达：一个智能体跨度的开始事件可能比结束事件早几分钟甚至几小时到达。 分析这些数据所需的查询模式也变得越来越复杂。智能体可观测性需要支持： - **随机访问：** 即时加载单次运行或单个追踪 - **交互式过滤：** 按元数据、反馈、延迟、错误、标签和时间对大型追踪数据集进行切片 - **全文搜索：** 在智能体运行的输入和输出中查找短语和模式 - **JSON 过滤：** 查询任意用户定义的元数据和结构化工具输出 - **树感知查询：** 基于根运行、子运行或追踪中的任意节点进行过滤 - **线程重建：** 跨多个智能体追踪即时重建长时间运行的对话 - **聚合：** 为不同过滤条件计算成本、延迟、Token 用量、评估器分数 要支持所有这些特性，同时满足低延迟、处理大型智能体追踪、以及支持自托管和多云部署的需求，就需要一种全新的架构。 这正是 SmithDB 诞生的动力。 ## 介绍 SmithDB SmithDB 是 LangSmith 专为智能体可观测性和评估工作负载构建的数据层。 它使用 Rust 构建，并采用了 Apache DataFusion 查询引擎和 Vortex 文件工具包，同时针对 LangSmith 独特的工作负载进行了大量定制化改造。 从高层来看，SmithDB 由三个组件构成： 1. **对象存储**：用于持久化追踪数据 2. **一个小的 Postgres 元数据存储**：用于存储分段元数据 3. **无状态的摄取、查询和压缩服务**  ### 性能 对于可观测性来说，性能不仅仅是锦上添花。无论是对于人类开发者还是智能体本身，缓慢的可观测性工具都会成为智能体开发循环中的瓶颈。SmithDB 在智能体可观测性的关键工作负载上提供了领先的性能，使 LangSmith 的核心体验提升了高达 12 倍。 | 工作负载 | SmithDB 延迟 | | --- | --- | | 追踪树加载 | P50 92ms / P99 595ms | | 单次运行加载 | P50 71ms / P99 358ms | | 运行过滤 | P50 82ms / P99 434ms | | 追踪数据摄取 | P50 630ms / P99 1.47s | | 全文搜索 | P50 400ms / P99 870ms | | 线程过滤 | P50 131ms / P95 268ms | ### 可移植性 由于 SmithDB 由对象存储提供支持，因此无需管理本地磁盘。查询和摄取服务都是无状态的。系统通过增加计算资源来扩展，而持久化数据则存储在对象存储中。 这使得 SmithDB 在自托管和多云环境中的部署，比需要本地磁盘和复杂分片的传统数据库集群要容易得多。 ## SmithDB 现已服务于生产流量 今天： - **100% 的美洲云数据摄取**已由 SmithDB 处理 - **100% 的追踪 UI 查询流量**已由 SmithDB 处理，包括线程查询 - **所有主要过滤器**均由 SmithDB 支持，包括元数据、反馈、文本搜索、树过滤器和追踪过滤器 - 产品集成功能，如运行规则、批量导出和实验，已接近完成 很快： - 所有相关的产品功能都将迁移到 SmithDB，并且 SmithDB 将可用于 LangSmith 的自托管部署 ## 早期反馈 过去几个月，我们一直在将客户工作负载迁移到 SmithDB。以下是来自 Clay 和 Vanta 团队的反馈： > *我们每天向 LangSmith 记录数亿个智能体可观测性事件。SmithDB 使我们的团队能够以改进生产环境智能体所需的速度来搜索、调试和分析这些数据。性能提升是立竿见影且令人印象深刻的，尤其是在那些追踪探索曾成为瓶颈的大型项目上。* — Jeff Barg，Clay 公司 AI 负责人 > *迁移到 SmithDB 后，性能提升立即就能感受到。我们的用户体验明显更流畅，深入分析数据变得比以往更快、更直观。这是一次极好的体验。* — Andy Almonte，Vanta 公司 AI 高级工程经理 > *我们有很多包含大型工具调用的追踪，迁移到 SmithDB 后，跨项目查询和阅读追踪变得容易得多。这帮助我们更快地定位边缘情况、构建评估数据集，并比以往更迅速地迭代我们的追踪。* — Kunal Rai，Unify 公司 AI 软件工程师 > *在 Cogent，我们的后台智能体可能会同时产生海量追踪。我们需要对这些系统进行实时可观测性，而 SmithDB 实现了这一点：几秒钟内就能看到追踪，而不是几分钟——这是我们测试其他供应商时的体验。* — Larsen Weigle，Cogent Security 公司技术专家 ## 关键工程挑战 为了让 SmithDB 成为智能体可观测性工作负载的极致性能数据库，我们付出了巨大的工程努力。 从高层来看，SmithDB 是构建在对象存储之上的日志结构合并树（LSM）。LSM 树将写入缓冲在内存中，作为不可变的排序批次刷新到持久存储，并定期将这些段合并压缩在一起。在查询时，多个段会被读取并合并成一个有序流。 SmithDB 有五个主要组件： - **摄取服务：** 接收追踪写入，按分区和时间桶进行批处理，并写入不可变文件 - **元数据存储：** 记录段元数据，包括位置、时间范围、行数以及更新/删除向量 - **查询服务：** 公开查询接口，具有理解 LangSmith 运行语义和对象存储的自定义执行计划。大量使用 SSD 和内存缓存。 - **压缩服务：** 将写入优化的段重写为查询优化的段，同时应用删除、升级、TTL 过期和索引合并 - **集群管理器：** 将实时服务节点分配给键范围。这一点很重要，因为 SmithDB 不仅要分发负载，还要努力让重复查询落在可能缓存了正确数据的节点上。 集群管理器受 Google 的 Slicer 和 Databricks 的 Dicer 项目启发，通过将键空间划分为切片并将每个切片分配给一组稳定的服务节点来避免这个问题。路由器使用这些分配将相关请求发送到同一个节点或小型副本集。 这赋予了 SmithDB 两个重要特性： - **粘性路由：** 相关请求更有可能落在已经缓存了正确元数据或段字节的节点上。 - **自适应负载均衡：** 当节点加入、离开或过载时，集群管理器可以移动切片，而无需更改持久化的段元数据。 以下是未来博客文章中将详细展开的一些关键工程挑战的细节： ### 基于对象存储的渐进式查询 许多 LangSmith 查询要求获取特定租户和追踪项目的最新运行。一个朴素的对象存储方案会找出所有候选文件，打开其中许多，进行排序合并和去重，然后才应用限制。 SmithDB 会向后遍历时间，并在最新的候选段上构建一个有限的时间窗口。这将“先对所有内容排序，再限制”的策略，转变为“读取最新的有界切片，流式传输，合并和去重行，并在正确性允许的情况下尽早停止”，这显著减少了满足“Top K”风格查询所需扫描的数据量。  ### 从摄取节点读取最新数据 对象存储是持久化的真实来源，但最新的数据往往仍然存在于写入它的摄取节点上。 每个文件段都会记录生成它的服务器标识符。如果该写入节点仍在线，查询规划器会使用自定义计划，直接从该摄取节点的本地 SSD 和内存缓存中扫描这些文件，而不是立即从对象存储中读回它们。这避免了从对象存储中读取几十个小文件来满足对最新数据的查询。  ### 每次运行有多个事件 智能体可观测性建立在长时间运行的跨度之上。 在传统的请求/响应应用中，一个跨度可能在几毫秒内开始和结束。但智能体跨度可能保持打开更长时间。单次运行可能涉及模型补全、工具调用、重试、后台工作或委派给其他智能体。等到跨度结束再写入任何内容是不理想的。 在 SmithDB 中，运行是一个事件序列，而不是单个不可变行。这听起来简单，但它影响了整个查询引擎。需要做额外的工作来将过滤器展开，以定位到特定事件，并在查询时高效地合并事件。处理每次运行的多个事件也影响了我们的压缩策略。 ### 时间分层的压缩 摄取优化了写入延迟，这会产生许多小的不可变段。如果一直以这种状态进行查询，会造成过多的文件打开开销和去重工作。 压缩将这些写入优化的段转换为查询优化的段。SmithDB 使用一种时间分层的策略。时间分层决定了 SmithDB 执行此压缩工作的积极程度。较新的数据更有可能收到结束事件，因此过早将其压缩成大文件会造成不必要的写入放大。较旧的数据则更稳定，更有可能被反复扫描，因此值得合并成更大的文件。 这保持了快速的摄取速度，同时逐渐使较旧数据的查询成本更低。 ### 删除、TTL 和保留策略变更 在可观测性系统中，删除和升级等突变操作通常很困难，因为数据文件是不可变的。默认情况下，SmithDB 不会为每次删除同步重写数据文件。相反，元数据存储会将删除和升级向量附加到段条目中。查询和压缩路径会使用这些向量来正确解释不可变文件。文件重写会在压缩期间发生。 这种策略使得 SmithDB 中的突变操作具有很高的可扩展性。这对智能体可观测性尤其重要，因为保留策略很少是统一的。大多数追踪对最近的调试、监控和评估有用，但只有一小部分需要根据特定追踪的内容长期保留。 ### 大字段的延迟物化 智能体追踪通常包含大型、无界的负载。SmithDB 通过将核心运行字段与大字段分离，来保持常见列表和过滤查询的速度。核心行携带指向大字段文件的指针，查询引擎仅在这些大负载被查询实际投影时才去获取它们。 这意味着加载运行列表或应用过滤器不需要读取兆字节的 JSON，除非用户实际打开该运行或请求这些字段。 ### 全文搜索和 JSON 过滤 在超过 1MB 的负载上支持亚秒级的全文搜索和 JSON 键路径过滤是一个具有挑战性的工程问题。 SmithDB 通过一个针对对象存储优化的自定义倒排索引布局来高效处理这些查询。在本地磁盘上，索引可以依赖廉价的寻道和许多小读取。在对象存储上，这种模式行不通：每一个不必要的请求都会增加延迟，过早地获取大型发布列表或位置列表会主导整个查询。 SmithDB 的索引布局旨在避免这种情况。术语被排序到行组中，每个行组记录最小/最大术语区域。因此，精确和前缀术语查询可以在获取发布字节之前修剪索引行组。发布和位置与术语字典分开分块，所以常见术语不会导致巨大的内存分配或一次巨大的对象存储范围读取。行组和块阈值限制了构建器内存和查询时的 I/O。 ### 集群管理和粘性路由 SmithDB 包含一个轻量级的集群管理器，用于控制哪些服务节点处理哪些流量。这一点很重要，因为 SmithDB 不仅试图分发负载，还试图让重复查询落在可能缓存了正确数据的节点上。 集群管理器受 Google 的 Slicer 和 Databricks 的 Dicer 项目启发，通过将键空间划分为切片并将每个切片分配给一组稳定的服务节点来避免这个问题。路由器使用这些分配将相关请求发送到同一个节点或小型副本集。 这赋予了 SmithDB 两个重要特性： - **粘性路由：** 相关请求更有可能落在已经缓存了正确元数据或段字节的节点上。 - **自适应负载均衡：** 当节点加入、离开或过载时，集群管理器可以移动切片，而无需更改持久化的段元数据。 ## 未来计划 除了让 LangSmith UI 的更多部分由 SmithDB 支持之外，我们对于这个数据层将解锁的全新产品体验感到非常兴奋。 LangSmith 的下一阶段不仅仅是更快的追踪加载。它旨在让追踪数据更有用：更容易搜索、更容易分析、更容易反馈到智能体开发循环中。SmithDB 将作为实现这一切的基础层。 我们也在寻找有才华的系统工程师和数据库工程师加入我们。 试用 SmithDB