Datadog 2026 年 6 月 23 日复盘 Stream Router 迁移：Claude 与 Cursor 改写存储层，45 分钟操作降到 1 秒。 这条复盘落在「前置部署」Forward Deployed Engineer（FDE）的交付工程这一段：客户现场的遗留系统与损坏的 schema 不会因为模型变强而自动消失，「前置部署」Forward Deployed Engineer（FDE）稀缺的能力，是把一个正在承载生产流量的系统在不停机的前提下换掉底层存储模型。Datadog 工程师 Arnold Wakim 把 FDE 最常被追问的两件事用量化结果写清楚了：AI 到底能替人写多少代码，以及切换生产之前必须具备哪些硬前提。对做企业级数据系统落地的「前置部署」Forward Deployed Engineer（FDE）来说，这是一份可以直接照抄顺序的迁移作业书，而不是一篇感想；FDE 在客户现场最容易犯的错，也恰好是这篇文章用数据否掉的那个动作。「前置部署」Forward Deployed Engineer（FDE）把交付风险压下去的办法，通常不是换更强的模型，而是把验收判据先建起来。 Stream Router 是 Datadog 内部的 control plane 服务，为 metrics pipeline 决定每一个数据点该写进哪个 Kafka 集群、topic 与分区，该平台每天处理超过 100 万亿个事件。2016 年时这套路由只是三行配置文件，靠人工编辑、手动发布；随着规模增长文件涨到数千行，Stream Router 用集中式 gRPC 服务与自动化编排取代了改文件再手工推的流程，路由改用 API 管理、发布变得渐进且自动。为了高可用，写路径与读路径被解耦：写路径用 FoundationDB 的「键值模型」key-value，读路径用 RocksDB 把写路径的静态快照恢复进内存，供高吞吐查询。问题的根源在于实体关系：一条 route 引用 sharding strategy，一条 rule 引用 route，这些对象天生是关系型；在「键值模型」下，代码只能把数万条记录拉进 pod 进程，在应用内自己扮演一个关系数据库。「前置部署」Forward Deployed Engineer（FDE）在客户环境里遇到的多数存储难题，本质上都是这一条：实体是关系型的，而存储被建成了键值型的。FDE 在技术尽调时第一个该问的问题就是这句：这张表到底是关系型的还是键值型的。而「前置部署」Forward Deployed Engineer（FDE）判断一次存储改造能否成立的依据，也应该落在实体关系上，而不是落在某个数据库的跑分上。 代价以很具体的方式出现：最吃力的操作开始撞上 FoundationDB 的「事务大小」上限，原本用来替换手工配置的系统，自己变成了瓶颈。团队先走了一条捷径——把 FoundationDB 换成 PostgreSQL，但保留原来的键值访问模式，这条路同样走不通：最吃力的操作预估仍需 45 分钟，因为依然要发出几千次串行往返。作者给出的结论很明确：瓶颈在「数据模型」以及围绕它写出来的应用逻辑，不在数据库本身。这条判断对「前置部署」Forward Deployed Engineer（FDE）尤其值钱，因为客户现场最常见的错误动作，就是把「换引擎」当成「换模型」。FDE 判断一个迁移值不值得立项，第一步应该是评审 schema，而不是评审数据库产品清单。对「前置部署」Forward Deployed Engineer（FDE）来说，后面那 45 分钟这个数字还有一个附带用途：把它和它的来源一起写进提案，就能挡住一类注定要靠人天硬填的迁移项目。 新方案是先手工把关系 schema 设计出来，再考虑让 AI 参与。写路径直接选自管的 PostgreSQL，Datadog 已经在自建 PostgreSQL 平台，关系语义与事务模型都是现成的。读路径需要重新选型：读侧服务从静态快照启动、全内存服务查询，所以必须是一个嵌入式数据库。候选第一是 SQLite，但新 schema 依赖数组列（array columns），SQLite 原生不支持；最后选 DuckDB，因为它同时解决两个问题——原生支持数组，SQL 方言与 PostgreSQL 高度兼容，可以共享查询逻辑，不必维护两套实现。工具选型之外还有一个关键取舍：新库不再依赖应用层重建关系，外键约束把原先写在代码里的关系校验交回数据库。对「前置部署」Forward Deployed Engineer（FDE）来说，这段是可以直接复用的选型判据：读路径从快照启动就选嵌入式引擎，schema 用到数组列就排除 SQLite。FDE 写选型报告时，应当把被排除的 SQLite 和排除理由一并写下来，这是最省事的评审材料；「前置部署」Forward Deployed Engineer（FDE）真正要交付的也不是引擎名字，而是引擎与 schema 的匹配关系。 迁移能跑通，靠的是三件在动手之前就已经存在的东西，不是靠模型本身。第一是模块化接口：Stream Router 的存储层躲在一个叫 Controller 的内部接口之后，新方案只是同一个接口的第二个实现，系统其余部分完全不用改。第二是完整的「端到端测试」end-to-end test：每个 Controller 方法都有端到端测试，并且对每次操作之后存储状态该长什么样有明确断言，这套测试成为每一次 AI 生成变更的二元成功判据，任何在旧后端上通过的测试都必须在新后端上同样通过。第三是并行基础设施：资深工程师 Rémi Calixte 搭了「蓝绿部署」blue/green deployment 架构，两套完全独立的 Stream Router 实例并行处理同一批请求，客户端按「特征开关」指向其中之一；每个集群里还跑着一个专门的 validator 服务，周期性比对两边的路由响应，一旦出现分歧立刻告警。「前置部署」Forward Deployed Engineer（FDE）可以直接把这三条当成前置检查表：接口没抽出、断言没有、并行环境没有，就先不要启动这种规模的改写。FDE 在客户现场要把这三条逐条打钩确认，再去谈排期和报价；「前置部署」Forward Deployed Engineer（FDE）如果跳过其中任何一条，等价于把验收权交给了模型自己的说法。 AI 工作流分三个阶段，顺序本身就构成了这个方法的一部分。Phase 1 是建图：把旧的键值 controller 交给 Claude，要求产出 markdown 文档，描述每个关键函数的意图——它为什么存在、保护了什么行为，而不是逐行解释它做了什么。作者认为这是整个项目最有价值的一步：在后两个阶段里，这些文档与新 schema、失败测试输出一起被喂给模型，每一轮的往返次数明显下降，而新会话也能靠它直接接上进度。同一条规律也适用于代码注释，解释「为什么」的注释持续提升了生成实现的质量。Phase 2 是 stub、测试、迭代的五步循环：先挑一个旧 controller 的方法；在新的 PostgreSQL controller 里建一个返回错误的 stub；跑端到端测试；把失败输出连同旧实现、新 schema 与 Phase 1 文档交给 Claude 或 Cursor；迭代到测试通过。反过来说，更高层、范围更大的提示效果一贯更差：上下文过载、编造接口、代码能编译但行为与预期不符。Phase 3 是生产验证：PostgreSQL 版作为 blue 与 FoundationDB 版 green 并行运行，validator 每 30 秒比对一次双方响应，在真正切换之前用真实生产数据跑了数周，而不只是跑测试夹具。这条顺序对「前置部署」Forward Deployed Engineer（FDE）的意义在于，它把「让 AI 改生产系统」拆成了三件可分别验收的事，FDE 可以在每一件上单独设关卡。 作者也写清了 AI 不够用的地方，这是这篇复盘最值得信的段落。在 SQL 性能上，模型生成的查询正确但不优：批处理（batching）、UNNEST 技巧与公共表表达式（common table expression，CTE）这类优化必须人工介入，AI 生成的查询结果没问题，但发出的往返次数远超必要；作者一行行手写了优化版本，模型看过一次模式后能在后续方法里复制，但它不会自己发现这些模式，尽管这些模式在文献里到处都是。可操作的做法是跑 EXPLAIN ANALYZE，把 planner 输出喂给模型让它去找缺失的优化点。Token 消耗同样显著，早期尤其费：当时喂的是完整测试输出而不是裁剪后的摘录，而自有测试套件本身输出冗长，当时并没有为 AI 辅助工作流优化过。还有两处作者没有覆盖：文章给出的是「估计值」45 分钟而不是实测基线，也没有披露分位延迟与 AI 生成代码在最终代码中的占比，读者无法据此推算自己环境的收益上限。「前置部署」Forward Deployed Engineer（FDE）读到这段应当调整预期：AI 承担的是方法级的翻译工作，性能调优这一步仍要人来兜底。FDE 在报价时应当把性能调优的人工工时单列出来，因为这部分不会被模型吃掉；「前置部署」Forward Deployed Engineer（FDE）在客户面前也不要承诺「AI 写完就能上线」，文章的原文结论是必须保持对生成代码的怀疑。 项目从初始设计到进入生产大约 3 个月，即 2025 年 12 月至 2026 年 2 月，核心概念验证（proof of concept，PoC）在 4 周内达成。原先估计要跑 45 分钟的操作现在约 1 秒完成，接近 3000 倍，此前会超时的 API 调用现在约 1 秒返回。路由数据集在 PostgreSQL 里缩小 40 倍，DuckDB 静态快照更小。整体延迟下降一个或多个数量级，从数百毫秒降到几毫秒，原因是 PostgreSQL 生成高效查询计划，把谓词下推到服务端，而不是把关系重建到应用层之后再过滤。退役自管的 FoundationDB 集群之后，数据库成本降低 90%；读写两条路径上的 pod 的 CPU 与内存消耗都下降；生产部署没有发生事故。这组数字对「前置部署」Forward Deployed Engineer（FDE）的可迁移之处不是倍数本身，而是倍数来自数据模型重构，而不是来自换一个更快的数据库。FDE 向客户汇报这类成果时，建议把「倍数来自数据模型重构」这句话放在数字之前，否则客户很容易把它理解成换了个数据库；「前置部署」Forward Deployed Engineer（FDE）也可以顺手复述另一组事实：数据集缩小 40 倍与成本降 90% 是同一件事的两个侧面。 - 「前置部署」Forward Deployed Engineer（FDE）：先做两项可行性判断，再决定是否把改写交给模型：存储层是否躲在接口之后（Datadog 是 Controller 接口），以及是否存在断言操作后存储状态的端到端测试。两项缺一，AI 生成的代码就没有可行的验收判据，此时正确的动作是先把这两件事补上，而不是先买模型额度。 - 「前置部署」Forward Deployed Engineer（FDE）可照抄的操作顺序是：先手工设计关系 schema，再产出 Phase 1 意图文档，最后才进入 stub 与失败测试的迭代循环；跳过前两步直接让模型改写，作者明确说结果一贯更差。 - 「前置部署」Forward Deployed Engineer（FDE）：提示规则是一次只喂一个方法或一条失败测试；上下文窗口塞满就开新会话，靠 Phase 1 的意图文档续接，而不是靠堆更长的对话历史。FDE 在客户现场做同类重构时，把这条写进交付规范，能省掉反复重开的会话。 - 「前置部署」Forward Deployed Engineer（FDE）：性能兜底动作是让 AI 生成的 SQL 先跑 EXPLAIN ANALYZE，并把 planner 输出回喂给模型；发现往返次数异常就人工改写 batching、UNNEST 与 CTE，再把优化后的查询当范例喂回去，让模型在后续方法里复制这个模式。 - 切换生产的退出方式：用「蓝绿部署」并行新旧两套实例，配一个 validator 周期性比对双方响应（Datadog 的比对间隔是 30 秒），分歧立即告警；用真实生产流量跑满数周再切，回滚就是把「特征开关」切回旧实例。 - 预算项要单独留出来：AI 辅助期的 token 消耗会明显上升，早期喂完整测试输出尤其费，先把测试输出裁成摘录再喂给模型。 - 「前置部署」Forward Deployed Engineer（FDE）：不适用条件很清楚——如果迁移目标只是换数据库版本、而不换「数据模型」，这套方法拿不到收益。Datadog 的结论是瓶颈在数据模型与围绕它的应用逻辑，因此这类项目的第一步应该是评审 schema，而不是评审数据库产品清单。FDE 在客户现场做存储层提案时，先证明数据模型有问题，再去谈引擎选型。 原始来源： - https://www.datadoghq.com/blog/engineering/ai-assisted-storage-migration/ - https://www.datadoghq.com/blog/engineering/timeseries-indexing-at-scale/#metrics-platform-overview - https://duckdb.org/docs/lts/sql/dialect/postgresql_compatibility