Fivetran：两年后，AI如何改变性能工程

到2025年初我们已经经历了轻松的2倍、艰难的2倍和极其困难的剩余部分。这项工作提醒我们，工程上多出的那一个“九”的可靠性或性能是以不断增长的成本为代价的。幸运的是，我们完成了之前设定的所有OKR。明显的瓶颈消失了；火焰图变得平坦。团队中的主流观点（包括我的）是，这个柠檬已经没有汁水了。剩下的只是每个只有几个百分点的长尾胜利，而诚实的问题是，这些是否值得一个工程师花一个季度的时间。

这个观点是错误的，但原因并非你所想。剩下的想法仍然很小。真正改变的是评估一个想法的成本崩溃了，而一旦评估几乎免费，长尾的5%胜利就变成了一门好生意。

以下是旧经济的形态。在AI出现之前，尝试一个性能想法确实很痛苦。你会花两三天时间拉取生产日志，阅读旧提交以理解某段代码为何写成那样，并搭建本地测试——结果却发现收益只有1%或2%。由于前期成本如此之高，我们经常放弃好的想法。不是因为我们认为它们不好，而是因为我们无法事先判断它们是否好，而发现答案需要三天时间。

这是一个对易于评估想法的过滤器，而不是对高价值想法的过滤器。它多年来默默扭曲了我们的路线图，而我们对此没有名字。

[CTA_MODULE]

真正改变的是什么

将AI引入团队的日常工作流程具体改变了四件事：

上下文收集不再花费数天

得益于AI的信息检索和综合能力，过去需要两三天手工挖掘日志和阅读代码的工作，现在只需几小时。这就是整个游戏的关键。下面的一切都是它的结果。

我们在编写代码之前评估影响

我们可以在不触及代码库的情况下分析生产日志，确定有多少连接会真正从更改中受益。“如果这可行，生产中多大比例会变快？”过去我们是在事后回答这个问题，或者根本不回答。

我们可以主动分析热点路径

我们的核心行处理和列处理循环是O(N×M)——一个小常数因子至关重要。AI对这些循环的静态分析能捕捉到采样分析器完全遗漏的微妙反模式：冗余的对象转换、缺失的缓存、内层循环中的分配。

原型和工具变得便宜到可以一次性使用

本地POC和JMH微基准测试只需数小时而非数天。在极端情况下，我们用编码代理构建了完整的操作工具，而无需专门投入工程师。

真正的改变：收集和筛选我们以前无法获取的材料

最大的改变比“AI写代码更快”更微妙。

在大型分布式系统中进行性能工程，主要是一个解析证据的问题。“为什么这么慢”的答案几乎总是存在于你已有的材料中：数千连接的生产日志、五年的提交历史、跨三个抽象层的四层重试逻辑、一周的舰队遥测。证据存在，但没有人有时间去阅读。

所以当我们开始这次旅程时，我们没有阅读它。我们抽样。我们只看一个连接而不是一千个，阅读当前代码而不是历史，对一个基准进行性能分析而不是分析整个舰队。然后我们根据样本进行推理，有时是对的。

AI移除了抽样步骤。我们现在经常阅读所有这些材料，而差异不是渐进的。这是在我们能提出多少问题方面的一次革命性变化。

具体来说，这使我们的工作重组为五大支柱。

支柱1：代码库考古与深度走查

在一个复杂的流水线中，困难的部分很少是编写修复；而是理解一切如何相互通信，以及为什么某些遗留代码在多年前写成那样。AI浏览提交、PR描述和代码路径，解释全貌。它考虑所有因素，不遗漏任何步骤或事实。以下是一些与我们的性能工作相关的深奥事实，AI能够挖掘出来：

• GitHub缺失的表守卫。追踪跨GithubIssuePullRequestUpdater和GithubUpdater的执行流显示api.pullRequest()和updateUsers()无条件触发——即使客户已取消选择那些表，也会获取完整详情。‍
• GitHub部署状态历史。综合旧提交历史显示，部署状态检查是在2021年写的，那时我们还没有增量游标。这解释了为什么每次同步有57,000多次API调用在没有任何状态跟踪的情况下触发。代码在编写时并没有错；平台在其下增长了一项能力，而没有人回头更新。‍
• 可恢复的GCS上传重试。走查四层重试栈——GcsStorageClient → RetriableInputStream → CloudSpecificPutApi → GCS SDK——精确指出了UploadPacketInputStream.restart()清除会话状态并从字节零重新开始250 MB以上上传的那一行。‍
• HybridHash解耦。对照实际条件审查正确性门禁显示，HybridHash被isParallelProcessing()不必要地阻塞，即使标准写入器可以安全地直接写入处理它。

注意四个案例中的模式：这些都不是深奥的算法洞见。它们都是“这段代码做了某人无意之事，原因曾经合理。”这类错误普遍常见，修复价值巨大，但以人类速度阅读代码几乎不可能发现。

支柱2：主动热点路径与反模式分析

2025年12月，我们在核心的行和列处理循环上运行了AI静态分析，专门寻找标准分析器不会暴露的微低效。我们直接从该审计中实施了3到4项核心性能修复。我们尚未将剩余部分转化为正式待办事项，审计可能需要重新进行一次以确保其未过时——但这证明了该技术：AI静态分析能发现不明显的热路径瓶颈。

支柱3：日志挖掘，并首先评估机会大小

在进行任何优化工作之前，回答这个问题：如果这个想法有效，实际生产流量中会有多少真正变快？这是改变我们优先级排序最多的支柱。日志挖掘也不必消耗大量token。我们已经开发出技术，让AI编写代码将我们的日志预处理成更易于管理、token更少的捆绑包，供另一个模型处理。这些都是平台和连接器特定的改进，是AI现在实现的长尾改进识别的一部分：

• GitHub部署状态配额浪费。解析生产日志证明，部署状态调用消耗了每小时API配额的90%以上——每次同步约57,000到59,000次调用——而获取的新更改却为零。这给了我们完全的信心来构建水印修复。
• 布隆过滤器机群规模。分析一整周的生产机群数据证明，外部排序成本的98%发生在增量同步期间，并且内存不是约束。该结果使我们免于内存自动调优项目，并指向CPU缓存优化。这是最有价值的发现类型：它阻止你做几个月的错误工作。
• 管道空闲时间。在数千个连接中挖掘日志显示，下游处理和加载工作线程空闲等待完整表提取或全局刷新。
• Okta请求规模。日志分析显示，178个Okta连接中有39个（约22%）拥有超过1,000个用户，这确定了并行化用户查询在该机群中值得约15%的同步持续时间减少。
• 事件调查。复杂性能健康指标中的回归需要几天的手动日志挖掘来定位。现在只需几小时。

支柱4：快速原型制作和微基准测试

性能想法很便宜；验证它们才是成本所在。在数小时内启动本地测试工具和微基准意味着我们在投入工程时间之前先进行验证。快速原型帮助加速的改进：

• 缓存块分割布隆过滤器。JMH微基准证明，将布隆过滤器位对齐到CPU缓存行，在低级添加和探测操作上产生2.5倍到4.8倍的加速——在接触核心代码之前。
• 数据包压缩V3。运行1TB Postgres到BigQuery的测试工具显示，从Snappy/AES-CBC切换到Zstd/AES-GCM带来+8.2%的行吞吐量提升和-7.6%的运行时减少。
• 可恢复的GCS上传。重试测试脚本证明，在网络中断期间，从最后提交的块恢复可在256 MB数据包上节省最多250 MB的重新上传。

支柱5：自定义AI诊断技能和AI构建的自动化

我们没有仅将AI用于临时聊天，而是将我们的诊断程序打包为可重复使用的技能，并将编码代理指向整个项目。

• GitHub连接剖析技能。我们构建了一个自定义的Claude技能，给定连接后，它获取同步日志，总结每次API调用，识别延迟和错误模式，并指出主要低效。在多个连接上运行它给了我们机群范围内的使用模式，并使我们能够优先考虑最大影响。这里的重要转变是诊断程序不再是一个工程师头脑中的部落知识，而是成为任何人都可以运行的工件。让AI将代码与指标匹配并不遗漏任何数据点，极大地提升了我们进行剖析的能力。
• 由AI端到端构建的OTD回归检测机器人。我们有一个操作差距：服务级别和VIP账户的微妙准时交付（OTD）回归未被检测到。该系统每天运行，扫描服务和VIP账户中超过4%的OTD下降，自动将Jira工单分配给负责团队，发送包含受影响最大五个连接的Slack摘要，并在性能恢复时自动解决工单。

最后一点值得特别强调给工程领导者。该机器人不在路线图上，因为它会花费一个工程师一个季度的时间，而路线图槽位更值得花在引擎上。“零人员执行”是项目选择中一种真正新颖的选项，它恰好适用于每个团队都有的那类有用但从未优先考虑的层级的工作。

总体结果

AI时代产生的项目并不小。

BATCH_COMPLETE信令

我们通过在每个表的提取完成后异步触发表处理和加载任务，而不是等待整个同步或全局刷新，消除了资源空闲时间。这意味着管道并行化而非全局停滞，在基准测试中导入吞吐量提高了最多70%，在特定生产连接中提高了47%。我们迄今已实施了六个服务，所有服务都适用于任何表数高的连接器服务。

SAP HANA连接器

我们构建了一系列连接器端和核心优化——DateTime、UTF-8和BigDecimal反序列化，异步BATCH_COMPLETE信令，SplitFileWriter和导入并行化，ResultSet调优——并大致使初始同步基准导入吞吐量翻倍，生产初始和增量同步观察到的吞吐量提高35-40%。

GitHub连接器

对生产连接日志和API使用模式的分析使我们能够消除冗余调用并防止速率限制瓶颈：表选择保护、列表页面大小从30提高到100，以及即使REST API没有原生支持，也能提取增量更改的自定义机制——包括对部署状态的经验性的updated_at水印过滤器。在高容量连接上，这消除了超过90%的API调用，并在影响最大的更改中将同步持续时间平均降低了高达35%。

较小范围的工作，现在值得做，因为评估成本低廉，包括并行化的Okta用户查询（对于22%拥有超过1000用户的连接，全量同步持续时间减少15%）和并行化的Kustomer逐表权限检查（在几乎所有Kustomer连接器中，获取标准配置的速度提高31%）。获取标准配置在几乎所有Kustomer连接器中，获取标准配置的速度提高31%。

进行中的行为更改包括在非并行拆分写入器上启用HybridHash的自适应去重；缓存对齐的拆分块布隆过滤器（在1000万到5000万元素下，布隆操作性能提升3.8倍到4.8倍）；Zstd/AES-GCM数据包压缩（总体初始同步运行时间估计减少4-5%，且无峰值CPU增加）；所有目标的SplitFileWriter并行化，包括之前因OOM问题受阻的Parquet写入器目标，我们的分析表明这些是安全的；以及可恢复的GCS数据包上传。

工具改进 包括：

• 将生产连接的按需分析移至一个有护栏的CLI命令，该命令在Temporal中针对特定连接、服务类型或同步类型触发Java分析，并使用分数采样。
• 一个OTD回归机器人，以及自动化的基准失败和回归检测。

我们学到的东西：一个由AI驱动的参考，用于您自己的性能工作

我们在第1部分中的列表仍然有效。这第二个列表包含我们两年前就希望拥有的能力：

1. 在写一行代码之前先评估机会。问：“如果这有效，生产环境的哪个部分会更快？”并使用日志和代码回答，而不是凭直觉。一个帮助3%连接的更改和一个帮助60%连接的更改在白板上看起来一样。
2. 挖掘整个舰队，而不仅仅是样本。采样从来不是方法上的选择；它是预算限制。当读取所有数据只需花费几小时而不是几周时，读取所有数据。一个星期的全舰队遥测回答了一个年度的抽查未能回答的问题。
3. 将负面的评估结果视为胜利。证明内存不是不我们的去重约束，在内存自动调优项目开始之前就终止了它，并将我们引向CPU缓存工作。阻止你做几个月错误工作的发现，比大多数启动某事的发现更有价值。
4. 做考古，而不仅仅是读代码。将AI指向提交历史和PR描述，并问为什么代码看起来这样。我们最有价值的发现都是同一形状：代码在编写时是合理的，当平台在其下面增加了功能时，悄悄地不再合理。
5. 端到端追踪多层堆栈。重试逻辑、缓冲和错误处理分布在四个抽象层中，正是bug躲避分析器和审查者的地方，因为没有任何单个文件看起来是错误的。询问完整路径和具体行。
6. 质询守卫，而不仅仅是算法。我们一些最容易的胜利是比需要的更严格的正確性门。问“这个检查实际需要什么条件？”分开于“这个检查正确吗？”
7. 定期有意地对热循环运行静态分析。分析器显示时间花在哪里；它们不显示冗余的对象转换或内循环中本不应该存在的分配。在O(N×M)路径中，常数因子是整个游戏。
8. 在集成之前进行微基准测试。隔离验证机制——我们在触及核心代码之前验证了布隆过滤器操作2.5倍-4.8倍的提升。如果机制在隔离时不赢，它在系统中也不会赢。
9. 为无法微基准测试的任何东西构建一次性工具。无论是失败路径行为、网络断连还是重试语义，编写一次性脚本演示浪费。现在足够便宜，值得为单个问题做。
10. 将重复的诊断打包为技能，而不是提示词。当你第二次运行相同的调查时，使其成为工件。存在于一个工程师头脑中的诊断只扩展到一个工程师；技能扩展到团队，并且可以在整个舰队上运行。
11. 使用代理处理永远不会配备人员的工作。你一直决定不优先考虑的工具——监视器、摘要和回归检测器——现在可以在不占用路线图位置的情况下构建。保留那类工作的清单；它突然成为积压工作而不是愿望清单。
12. 重新运行审计；发现会过时。审计是不断变化的代码库的快照。我们的需要一个全新的遍历，我们在运行时知道这一点。使用AI审计代码的成本大幅下降，所以值得做。
13. 根据第1部分的测量基础设施验证一切。AI输出是假设，而不是结果。上面每个主张只有在基准确认它并且基准改进记录解释它时才成为现实。没有测量基础设施（并且团队信任它），AI分析不会提供太多好处。
14. 保持优先级排序的人工化。AI降低了评估想法的成本。它没有决定哪个5%的胜利值得一个季度，哪个客户的问题最重要，或者何时停止。经验丰富的工程师的判断是值得的。

教训

教训不是“AI让我们编写代码更快。”我们从未受限于编写代码。

我们受限于知道要编写哪些代码第一部分中的每一个实践——指标、监控工具、基准测试和改进记录——都是为了回答这个问题，而每一个实践都是让证据变得足够廉价以便采取行动的方式。AI 是同样的工具，应用于我们早已拥有但从未能负担得起的阅读成本的证据。

这意味着这个故事的两部分并非真的分离。AI 对我们如此高效的原因在于，我们花了两年时间构建测量基础设施，使 AI 的答案可以被验证。我们花了两年时间构建性能工程实践，使我们的团队能有效加速 Fivetran。只有在存在合适且值得信赖的指标时，挖掘生产日志的代理才有用。只有存在基准测试套件进行验证并记录结果，微基准测试才能指导行动。只有存在拥有队列和路线图的常设团队，热点路径审计才能转化为实际吞吐量提升。

如果你从零开始，不要从 AI 开始。从指标开始。

进一步了解 Fivetran 的工程运营，请参阅：

• 基准测试：数据管道吞吐量分析
• 基准测试：数据管道延迟分析。

Fivetran 还发布了公开可用的基准测试。

[CTA_MODULE]