去年春节期间，支付宝推出的“集五福”活动广受欢迎。每张福卡背后都附有刮刮卡，上面提供了来自蚂蚁金服、阿里巴巴及其合作伙伴提供的多种权益。该活动主要集中在春节前几天，因此需要快速匹配权益和目标人群，处理系统冷启动问题，优化转化率并提升用户体验，这些都成为了在线学习系统优化的关键任务。

最初构建这样一个系统需要许多复杂的模块。我们需要收集日志、聚合数据、拼接和采样样本等流处理任务，还需要对接模型训练和验证的机器学习模块，同时需要实时加载模型的服务模块以及其他配套设施。多个模块的连接显著增加了系统的复杂性。

在实施过程中，我们面临了不少挑战。例如，在大型促销期间，为了保证关键链路的稳定性，某些数据处理链路可能会被降级，但下游团队可能并不知情。另一个常见的问题是离线和在线处理逻辑不一致，需要离线特征来训练基准模型，而在线特征则用于实时更新模型。这种差异已经导致了一些业务效果的负面影响。

总结起来，我们遇到的主要问题可以归结为三类：首先是服务水平协议（SLA），整个链路的SLA受每个模块的SLA影响，随着模块数量增加，波动性成为限制业务发展的关键因素；其次是系统效率，大部分模块通过数据落盘来连接，增加了不必要的I/O、计算和网络成本；最后是开发和运维成本，不同的模块风格各异，开发模式、计算框架甚至代码风格都不一致，导致对接时需要耗费大量时间熟悉系统，降低了业务开发的效率。

理想的系统应具备“稳、快、简”的能力。首先，它需要保证数据和计算的一致性，确保整个链路的端到端SLA，数据一致性是业务稳定的基础。其次，我们需要优化系统效率，将多个系统的连接转换为内部连接，减少不必要的I/O和计算成本。此外，统一的系统还可以大大简化开发和运维工作，从前需要对接多个系统，现在只需对接一个系统即可。以前在应急情况下需要追溯多个业务来查找问题，现在一体化的系统调试变得更加容易。

在线机器学习系统需要解决的核心问题之一是打通流计算和模型训练。为此，我们需要一种媒介，将两者有效连接起来。Ray框架因其灵活的调度机制和多语言接口等特点，非常适合这一任务。Ray通过简单的语法变化，如添加“@remote”修饰符，可以将函数和类转换为分布式任务和服务，从而实现单机程序向分布式任务的转变。

Ray在调度方面表现出色，可以根据计算和数据的需求进行异构调度。在Ray系统中，可以通过简单的修改实现从单机程序到分布式任务的转变，从而实现数据共享和两种计算模式的融合。此外，Ray还支持动态生成DAG节点，使得在机器学习过程中可以动态调整DAG结构，以适应新模型的设计或超参数的调试。

在线系统与离线系统相比，最大的区别在于在线系统需要更高的时效性。因此，完备的容错机制至关重要。通过Ray的Actor机制，可以实现模型训练过程中节点的故障恢复，确保数据和计算的连续性。

为了保障链路的波动性，我们从三个方面入手：系统波动性、模型波动性和机制波动性。系统波动性包括数据实时性和强一致性保障；模型波动性则要求设计的模型能够适应实时数据流，同时避免因数据噪声导致的性能下降；机制波动性则涉及赛马机制和快速回滚策略。

我们通过Ray实现了数据共享和计算模式的兼容，构建了一个高效稳定的在线机器学习系统。该系统已经在支付宝的一些场景中成功部署，取得了显著效果。未来，我们将继续推广这一系统，应用于更多业务场景中。