修补、迁到托管服务还是重建：广告事件管道在高峰丢事件时，每条路各要付出多少代价

如果你的广告事件管道在流量高峰时丢失展示和点击，出路有三条。你可以修补漏事件的那些环节；可以把传输和存储事件的服务器（往往是 Kafka 和 ClickHouse）迁到托管服务；也可以请一家外部公司重建管道。选哪条路，也决定了你要请什么人。修补需要在你的团队内部工作的工程师，而重建需要一家能交付整条管道并把它交接给你的公司。做选择之前，先算出你的归因报表与出价方日志之间差距的年度成本。然后从三个方面比较每条路：成本、你保有的控制权，以及你用于计费的数字多快能重新变准。

我们的归因报表与出价方日志之间的差距，让我们付出多少成本？

大部分成本体现在发票上，所以从发票入手。取一个月，把三个数字并排放在一起：你向广告主计费的展示数、每个广告交易平台向你计费的展示数，以及你的出价方记录的胜出次数。

你要付哪些钱，由广告交易平台决定。OpenRTB 2.6 是 IAB Tech Lab 的标准，广告交易平台和出价方用它来实时交易广告。它写明，广告交易平台会在“胜出的出价根据交易平台各自的业务政策变为可计费时”发送计费通知。每个广告交易平台都按自己的政策、依据自己的记录向你计费，而你向广告主计费依据的是你的报表。你的管道丢失的每一次展示，都是付过钱却从未计费的。被算了两次的展示会被计费两次；当广告主自己的计数对不上时，你要以抵扣额度的形式把钱退回去。

下面用整数举例，不是任何人的真实数据。某平台每月买入 5 亿次展示，以每千次 2 美元的价格转卖给广告主。如果它丢失 3% 的展示事件，就有 1500 万次展示没有计费，合计每月 30,000 美元，即每年 360,000 美元，这还没算重复计数和抵扣额度。

还有两项成本更难定价。一项是你的员工每月花在向广告主和广告交易平台解释差异上的工时。另一项是依据不完整数据给出的出价。把这两项都记在总数旁边。

这个年度总额，大致就是一条路最多该花的钱。一条路如果比它所消除的差距还贵，就需要别的理由，比如现有管道承载不了的流量增长。

给各条路定价之前，先把差距拆开。那篇讲报表对不上出价方日志的文章介绍了核对计数：按竞价 ID，也就是每个广告交易平台给一场竞价打上的编号，把出价方日志里的每一次胜出与报表里的一次展示对应起来。核对计数能显示，差距中有多少是丢失的事件，又有多少来自两边按不同的规则计数。规则不同，解决办法是约定一套统一的规则，并在你运行的任何管道里执行它。托管服务或新管道都不会改变计数规则。

每条路要花多少钱？

修补和重建主要按项目付费。托管服务则只要你还在用，每个月都会多一份账单。

就地修补花的是工程时间，可以来自你自己的工程师，也可以来自在你团队内部工作的外部工程师。没有新增的订阅费用。要把第二轮修补列入计划，因为修补之后的第一个繁忙期，往往会暴露出下一个跟不上的环节。

托管服务按月计费，账单中有一部分按事件的 GB 数计价，所以账单会随你的流量变化。服务商服务器之外的一切，仍然由你的工程师来运行。Amazon MSK Serverless 是 AWS 的 Kafka 托管服务中的一个选项；Kafka 是在采集环节和数据库之间暂存事件的队列。根据它的价格页面（2026 年 10 月 14 日查阅），每个集群（即这项服务的每一个独立安装）和每个分区（即队列的一个切片）都有按小时计的费率。此外，每写入队列 1 GB、每从队列读出 1 GB，都要另收一笔费用，存储也另有费率。所以，每多一个读取同一批事件的程序，比如每天对照出价方日志做的核对计数，账单都会增加。

按你预计明年最忙那个月的流量给托管这条路定价，并把这个流量与服务商的上限对照一下。以 MSK Serverless 为例，根据它的配额页面（2026 年 10 月 14 日查阅），一个集群的写入一旦超过每秒 200 MB，就会被放慢。

重建的钱大部分花在项目本身。再加上新旧两条管道并行运行的那几个月，以及你自己的人评审和验收这项工作的工时。交接之后，得有人来运行新管道，合同里应当写明是谁。请每家公司以书面形式为同样的范围报价，并把并行运行包括在内，这样你就能把各家报价逐项并排比较。

每条路给我们留下多少控制权？

托管服务会拿走一部分控制权，首先是你的日程安排。按照 MSK 的版本支持政策，如果一个集群过了所用 Kafka 版本的支持终止日期还停留在这个版本上，它“会被自动升级到推荐的 Kafka 版本”。该政策还写道：“升级之前，您不会收到任何通知。”你要么在这些日期之前安排好自己的升级，要么接受服务商定的时间。日后要离开，本身又是一次迁移。数据要复制到你在别处运行的系统里，每一个写入或读取这些数据的程序都要切换过去。

就地修补让管道的全部控制权留在你手里。修补是谁做的，谁就清楚它们怎样起作用，所以如果其中有些人是外聘人员，要在他们离开之前，请他们为每一处修补写一份书面说明。

选择重建，你的控制权就是合同给你的那些。合同应当写明：代码归你的公司所有，并且从工作一开始就存放在你公司的账户里。设计文档应当随代码一起交付，同时附上处置手册，也就是处理每一种告警的书面说明。在外部公司还在项目上的时候，你的工程师就应当开始响应新管道的告警。

哪条路能最快让我们用于计费的数字恢复准确？

就地修补的效果在下一个高峰就能检验：比较修补前后管道每个环节按小时统计的数量。迁到托管服务要花更长时间，因为要复制数据，要把每一个写入或读取事件的程序切换过去，两套系统还要并行运行，直到它们的计数一致。服务商服务器之外的漏点仍然需要修补，比如采集器，也就是从浏览器和应用接收事件的程序。重建耗时最长。正如那篇讲报表对不上出价方日志的文章所说，在用于计费的报表切换过去之前，两条管道要在同样的事件上并行运行至少一个完整的计费周期。

怎样依据我们自己的数据选择走哪条路？

选择大体取决于四个答案。前三个来自你已经保存的记录，第四个可能需要做一次测试。

• 差距中有多少是丢失的事件，有多少是计数规则造成的？核对计数会给出这个比例
• 高峰时，事件在哪些环节丢失？从采集器到数据库，每个环节按小时统计的数量，会显示数量在哪里下降
• 上个季度，你的工程师花在管道上的工时都去了哪里？把工单和告警分成两类：花在维持服务器运行上的时间，以及花在修复计数或数据问题上的时间
• 十二个月后，管道必须承载多大的流量？把录下来的一天自有流量按那个速率重新发送一遍，看管道能不能扛住

把三条路并排比较，情况如下。

• 就地修补。花的是工程工时，控制权全在你手里，结果在下一个高峰就能检验
• 托管服务。一份随流量变化的月度账单，升级按服务商的日程走，结果要等迁移之后
• 请外部公司重建。一个项目加上几个月的并行运行，控制权靠合同保障，结果要等至少一个完整的计费周期之后

比较各条路时，为每一条加总两项：它在未来十二个月里的成本，以及差距的月度成本乘以这条路补上差距之前的月数。只在能消除你实际查出的损失的路之间比较这些总数。如果事件在到达数据库之前就丢了，托管数据库帮不上忙。如果差距来自两边一天的截止时刻不同，重建也帮不上忙。

这几条路能结合起来吗？

最省钱的方案往往是按固定顺序把三条路结合起来。先约定计数规则，因为无论底层运行的是什么，这些规则都适用。接着修补你能明确指出的漏点。服务器和设计放到最后决定，等几周干净的逐小时计数显示出还剩下什么之后再定。

重建并不一定意味着自己运行服务器。新管道可以架在托管的队列和托管的分析数据库之上，有些服务商还会运行加载器，也就是把事件从队列写入数据库的那一步。ClickHouse Cloud 是 ClickHouse 数据库的托管版本，它为此提供 ClickPipes。它的文档把 ClickPipes 称为“一个托管的集成平台”，并把 Kafka 和 AWS MSK 列在它的数据源之中。这样，外部公司要构建的就是你的平台特有的部分，比如计数规则和每天对照出价方日志做的核对计数，再加上采集器，以及在没有合适托管选项的地方所需的加载器。

外部公司的方案应当展示什么？

无论一家公司提议走哪条路，它的方案都应当能用你自己的数据来核验。要求对方提供与这条路相符的核查内容。

• 这家公司提议的每一项修补前后，你最忙那一小时里每个环节的计数
• 按明年的流量算出的你最忙那个月的账单、仍要由你自己运行的部分，以及你将来如何离开这家服务商
• 付款与每天对照出价方日志所做的核对计数挂钩，差距须保持在约定范围之内；同时写明并行运行的时长，以及你的工程师接手告警的日期

amBrain 构建广告事件管道吗？

amBrain 为广告技术构建事件分析管道：展示和点击事件的采集、处理与报表。在 AdTech 领域，amBrain 还从事 DSP 开发、实时竞价平台和广告交易平台工程方面的工作；RTBBidder 是 amBrain 为一家客户开发的需求方平台。

amBrain 诊断交易和广告技术领域的慢系统：对运行中的平台做端到端测量，报告会指明时间耗在了哪里。

amBrain 自 2019 年起开发软件。它有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。它关于所有权的说法是：“客户拥有产品与代码的全部所有权，我们的可复用组件除外。”

这里的内容都不是在描述某个客户的管道。文中提到 Amazon MSK、Kafka、ClickHouse 和 ClickPipes，只是把它们作为常见的例子；amBrain 并不声称用过它们，也不声称把某条管道迁到过托管服务。本文没有给出 amBrain 的价格或工期，上文的美元数字是一个虚构的例子。

如果你要和 amBrain 谈，就从你那个差距的年度成本，以及你最忙那一天的逐小时计数谈起。

关于修补或重建广告事件管道的常见问题

• 决定重建之前，修补应该试多久？试到修补之后的第一个高峰过去；如果数量下降只是挪到了下一个环节，就再试完第二轮修补。如果数量在已经修过的环节再次下降，或者第二轮修补之后，接下来的高峰又出现了新的下降，说明修补已经跟不上你的流量。到这时，才该把重建提上议程
• 重建管道的公司，之后也能负责运行它吗？可以安排，前提是合同写明由谁响应告警、响应要多快。无论如何，都要让你自己的工程师留在告警值班表上，这样合同一结束，管道也不会落到没有一个人了解它的地步