实时 vs. 批处理：收入数据的新鲜度何时真正重要

“实时”或许是曾经被写进需求文档中、代价最高昂的一个词。没有人会反对它，毕竟谁会想要过时的数据呢？于是它就这样毫无争议地写进了需求规格，六个月后，一条流式处理管道支撑起了一个某位副总裁一天只打开两次的仪表盘。为此付出的代价，不仅仅是基础设施本身，还有值班轮岗、系统的脆弱性，以及一份比当初写下这条需求的人在职时间还要长久的维护负担。

更好的问题是：这个具体的决策，究竟需要多“新鲜”的数据？新鲜度是每一条数据流各自的属性，而不同的收入数据流，其需求可能天差地别。我们见过一些团队，仅仅是把这个问题拆解到每一条数据流的层面去逐一回答，而不是设定一个全局默认值，就真正省下了不少真金白银。这篇文章要讨论的，就是如何有意识地做出这个判断。它与现代收入平台参考架构一文中其他关于契约的决策并列，新鲜度正是各层之间需要明确约定的契约之一。

决定新鲜度的是决策本身，而不是数据本身

先从这个数据所驱动的行动节奏入手：这个数字会引发什么后果，而这个答案又会以多快的速度过时？

线索路由必须在表单提交后的几秒钟内完成。响应速度慢会实实在在地降低转化率，因此这一场景确实需要低延迟。

而季度预测则完全是另一回事。管理层每周才会查看一次，每秒钟刷新一次不仅是浪费，反而会更糟糕，因为日内的噪音会制造出虚假的波动，而总会有人对此做出反应。用于季度业务回顾（QBR）的健康度评分也是同理：它需要在评审那一刻是最新的，而不需要精确到每一分钟都是最新的。

让新鲜度与决策的节奏相匹配。一份比它所服务的决策更“新鲜”的数据，不会带给你任何额外价值，却会让你付出额外的成本。大多数关于实时与批处理的争论，一旦有人把这句话说出口，往往就此终结。

实时处理真正的代价

流式处理并不只是“更快的批处理”，它是一种完全不同的工程承诺，而当你只是在撰写需求文档、而不是亲自运维这套系统时，很容易低估这些代价。

流式系统必须处理乱序事件、延迟到达的数据、恰好一次的处理语义，以及永不停歇的持续处理。当一个批处理任务失败时，你可以重新运行它；而当一条数据流出现故障时，这种失败往往更隐蔽，你可能要等到数字看起来不对劲时才会发现。

调试也更加困难。一条批处理管道有离散的运行记录，可供你检查和重放；而一条数据流则是一个不断移动的目标，要复现一个发生在凌晨 2 点 14 分、且涉及特定事件顺序的 bug，会是一个糟糕的下午。

还有正确性的问题。实时系统常常必须在所有数据都到齐之前就给出一个答案，然后再事后修正。对于一个会被截图放进董事会材料里的收入指标而言，一个事后会被追溯修改的数字，比一个滞后四个小时的数字更快摧毁信任。没有人愿意去解释，为什么周二的管道数字和邮件里发的不一样。

批处理的“无聊”恰恰是它最大的优点：可预测、可重放、容易推理。对于大多数收入分析场景而言，这正是你真正想要的，而“无聊”维持起来也更便宜。这一点很重要，因为分析的质量，终究取决于其背后的RevOps 数据治理水平。

为数据流分级

不要设定一个全局配置，而应该把每一条数据流归入以下三个层级之一。

实时层，以秒为单位。只为那些延迟会真正改变结果的数据流保留这一层级：线索路由、信号触发的告警、入站响应、欺诈或客户流失的干预措施。这类场景的行动窗口只有几秒钟，因此流式处理的成本是值得的。

近实时层，从几分钟到几小时不等。用微批处理来应对那些需要合理新鲜度、但并不需要精确到秒的数据流，比如管道仪表盘、互动评分，以及大多数写回执行系统的回写操作。这一层能让你以远低于实时处理的成本，获得实时处理大部分的感知价值，根据我们的经验，大多数数据流都应该落在这一层级。

批处理层，从几小时到每天一次。这是聚合分析、预测、归因建模和报表的默认选择。每晚跑一次，或每天跑几次就已经足够，而这种稳定性本身就是一个优点，而不是一种妥协。

真正的纪律在于，要克制住把一切都提升到第一层级的冲动，仅仅因为“实时”听起来更安全。但它通常并不更安全，只是运行成本更高、也更难以让人信任。

新鲜度与正确性冲突的两个场景

归因本质上是一个与时间高度相关的问题。归因主干需要在一整段完整的触点序列上分配功劳，而这要求的是完整的客户旅程。零散的、实时的片段化数据，只会产出你不断需要修正的功劳分配结果。归因理应属于批处理的范畴，追求实时归因，往往意味着追求的是错误的归因。

回写是另一个这样的场景。通过回写层把洞察推送到人们实际工作的系统中，其新鲜度需要与目标系统的使用方式相匹配。给销售代表推送的热线索提醒，需要近实时；而每晚同步到 CRM 中的客户账户健康度数据，则可以走批处理。如果回写得过于激进，你会得到噪音、告警疲劳，以及各种竞态条件——同步任务覆盖掉了销售代表十分钟前刚做的编辑。

新鲜度是数据的生产方与消费方之间，针对每一条数据流分别协商出的契约。用这种方式来看待它，关于“全局是否应该更快”的争论也就自然消解了。

关键要点

• 真正的问题是一个决策需要多新鲜的数据，而不是数据本身能有多新鲜，价值的上限由决策的节奏所决定。
• 实时处理背后隐藏着人们容易低估的代价：运营复杂度、令人头疼的调试过程，以及那些在被写进材料之后还会被修改的数字。
• 三个层级几乎能覆盖所有场景：对延迟敏感的行动用秒级，仪表盘和回写用分钟级，分析与预测用小时级或每日一次。大多数数据流都应该落在后两个层级。
• 归因需要完整的客户旅程，因此理应属于批处理；回写则需要与目标系统的使用节奏相匹配，否则就会变成噪音。

有意识地决定新鲜度，是一套精心构建的收入技术栈所具备的、不那么显眼的特征之一，而这正是像 Revnewo 这样的平台所遵循的契约驱动设计理念。如果你团队里的每一份需求文档都默认写着“实时”，那么对数据流进行分级，是一种能迅速帮你省下预算、并提升可靠性的方法。