导读：如今大部分人工智能应用是基于监督学习范式开发的，即模型在线下进行训练，然后部署到服务器上进行线上预测，这样的开发方式在实时响应上存在较大的局限。随着计算和 AI 体系逐步成熟，我们希望机器学习应用能更多地在动态环境下运行、实时响应环境中的变化，这推动了机器学习从传统离线学习逐渐向在线学习演进。相比于传统的离线机器学习，在线学习可以带来更快的模型迭代速度，让模型预测效果更贴真实情况，对于线上的波动更加敏锐。
最近两年，国内各一线互联网厂商分别推出自己的在线学习技术体系及相关架构。蚂蚁金服从 2018 年 7 月开始，基于最新的 Ray 分布式引擎自研了金融级的在线学习系统，与传统在线学习框架相比，在端到端延迟、稳定性、研发效率等方面都有不同程度的提高。
Ray 是伯克利大学 AMPLab 在 2017 年 12 月开源的高性能分布式计算引擎，推出至今不足两年，在计算框架领域还是一个十足的“新生儿”，虽然业内关注度颇高，但真正将 Ray 付诸应用的企业并不多，蚂蚁金服或许是国内第一个“吃螃蟹”的公司。为什么 Ray 能够得到蚂蚁金服的青睐？它与红透半边天的开源计算引擎 Spark、Flink 相比有什么独特的优势？在 Ray 的使用过程中可能会遇到哪些问题？蚂蚁金服的踩坑经验有何可借鉴之处？带着这些问题，InfoQ 在近期召开的 QCon 上海 2019 大会 现场采访了蚂蚁金服资深技术专家周家英（徒离），以下为采访问答实录。
InfoQ：能否请您总体介绍一下蚂蚁金服大数据技术架构的演进历程，包括经历了哪几个阶段、以及每个阶段你们所做的重点工作等。
周家英： 蚂蚁金服的大数据技术架构早期也是从离线计算阶段发展起来的，这一阶段大概是在 2011 年到 2013 年，当时还是以业界传统的离线计算为主，也就是 Hadoop。2013 年之后，随着分布式实时计算系统 Storm 推出，我们开始逐步将业务转向实时计算。从 2016 年开始，团队经过了一次比较大的转型，希望打造一套迎接下一代大数据计算的技术体系。一开始我们先尝试将计算引擎剥离出来，让业务与计算平台或中台体系直接对接，而不是对接具体的某个引擎。在这个阶段，我们经历了如特征中台、事件中台或者决策中台这些概念。
从这往后，大数据引擎、整个大数据体系都发展得非常快。我们不想继续像赶潮流一样，围绕一两个引擎或者一两种比较流行的计算模式去建立生态，我们认为应该有一套稳定的大数据计算架构设计思路，能够覆盖所有数据层面的问题。我们希望能逐渐沉淀出自己的一套技术体系，这套体系可以同时兼容和支持业界所有比较活跃的计算引擎，所以我们从 2017 年开始提出所谓“开放架构”的概念，从针对不同计算引擎单独建设，转变成建设一套开放的计算架构。
首先，它是一个致力于解决大数据计算问题的整体架构，在这个架构中会包含不同的计算引擎，但是这些引擎在是以插件化的方式存在的，这意味着，当引擎发生变化的时候，上层的业务是无感知的。基于这个架构，我们在一些关键能力上做了大量自研工作，比如我们现在正在做的融合计算引擎。传统的计算模式和计算引擎是绑定的，从 Flink 到 Spark，一个是流一个是批，虽然这两个之间可以互相转换，但是很多的特性在转换的时候其实没有那么顺畅，而且在转换的时候有一些优点会丢失。另外，像图计算模式其实无法被包括在任何计算引擎之中，因为这些计算引擎在设计的时候已经绑定了一个模式。我们提出融合计算的概念，就是希望能够用 Ray 这个分布式计算框架同时支持多种计算模式，并内聚地把各个计算模式融合起来。这指的是通过不同的融合手段，在研发、容灾、运行几个阶段，把各个计算模式通过一个闭环组合在一起，达到性能最优、效率最佳。另外我们在图计算、AI 以及软硬件结合方面也有比较多的投入。这是蚂蚁金服整个大数据计算的发展历程。
InfoQ：在整个过程中，蚂蚁金服有没有学习一些国外其他企业的经验？
周家英： 当然，我们并不是凭空或盲目地去做所谓的创新，而是会首先看到业界最先进的技术和经验。我们会和业界一些实战派的大型互联网公司对标，比如 Google、Facebook、Amazon 等；同时会对标一些更偏研究性质的公司的产品或理念，比如微软、IBM 等；另外我们也会结合自己的业务特点和之前踩过的坑综合考虑。也就是先看业界最领先的技术从工程方面和研究方面分别有哪些，同时再看之前踩过的坑，以及自己遇到的问题，结合自己的业务场景和规模，从而才确定刚才我们说的工作重点以及未来规划。
InfoQ：前面提到了实时数据阶段和在线数据阶段，二者关键的不同是什么？
周家英：实时数据阶段是从离线数据阶段发展过来的，虽然比以前更快，但是它所面临的问题也很直观。比如数据计算从 T+1 变成 T+ 分钟或 T+ 秒，这就是从离线到实时了，但是到底是秒还是分钟，是可以在一个很大的区间里切换的，这并不会对线上场景有什么大的影响。如果是一个监控任务或同步任务，那么它的时效性可以在实时和离线层面*过渡。但是在线计算需要与线上业务的一致性对齐，比如我们的业务依赖于数据库进行计算，只有当数据库返回结果之后才能继续支撑下一个业务。我们认为在线数计算更多是支持线上决策业务的大数据计算场景，而非从离线到实时的简单转变。
InfoQ：那么在线数据阶段对技术架构的挑战主要体现在哪里？
周家英： 挑战非常多。首先，在线计算意味着一个完全不同的计算模式。比如从计算数据准备的角度来讲，它是一个流计算的模型；但是如果要能把它查出来，把它依赖于线上的服务，其实又有一种比如说分布式服务的概念。如何让查询得到的数据越来越快、同时要准，也依赖于写入数据与计算结果和查询数据最后结果匹配的情况。这是一个不同的计算模式，会更多样性一些。同时还有一个很关键的点，就是我们以前的所谓离线计算或者说实时计算，其实它和在线的应用是分开的，比如在线应用的 SLA、物理机房部署是单独的一套，而大数据的机房部署又是另外一套，两边是相对解耦的，所以我们一般会说，当数据仓库或数据计算产生问题的时候不会对在线业务产生影响。但是在线计算概念出来以后，就意味着我们的数据计算要和数据业务放在一起，所以整个部署架构、容灾体系、SLA 标准，都需要全面改变和提升。
InfoQ：与传统在线学习框架相比，蚂蚁金服的在线学习系统在哪些方面做了优化？
周家英： 传统的机器学习是离线的机器学习，它的特征是迭代周期非常长，数据计算是以天或小时级别来进行的，传统的在线学习主要是指把批计算变成流计算，将流计算的计算引擎和机器学习训练的引擎连接在一起，然后两边做快速迭代来产生数据模型。而蚂蚁的在线学习体系是在业界的基础上，把不同计算模式由不同引擎拼接起来这样一个架构变成一套融合的架构，即用一个引擎支持不同的计算模式。我们认为，流计算是一种计算模式、模型训练是一种模式、分布式服务是一种模式，我们把这三种模式汇集在一套计算引擎上面，这个计算引擎就是 Ray。总结来说，我们用一个计算引擎覆盖了在线学习的所有环节，而传统的在线学习框架可能是用不同的引擎分别解决不同的问题，做的是拼接的工作，这是最大的区别。
InfoQ：为什么蚂蚁金服选择基于 Ray 来自研在线学习系统？你们前期做了哪些技术调研工作？与其他分布式引擎相比，Ray 的优势和不足分别是什么？
周家英：我们之所以选择 Ray 是因为除了它以外，其他的计算引擎大多已经和某一种计算模式绑定了，比如 Spark 推出的时候目标就是代替 Hadoop 做批计算，虽然它也可以跑流计算，但是 Spark 是拿批来模拟流；Flink 推出的时候是为了代替 Storm 做更好的流计算，虽然它也可以跑批计算，但是是拿流来模拟批，而在模拟的过程中都会有一定的缺陷或先天不足。因为这些计算引擎本身就是为了一种特定的计算模式设计的，它们天然做不到融合。所以我们在 16-17 年左右找到了伯克利的 AMPLab，他们提出的概念很符合我们之前对计算的想法，就是在下层有一层抽象和通用的分布式调度能力，我们可以基于这个原始层，在上面抽象出不同的计算模式，同时把通用能力沉淀到下层，最终变成两个层级：第一层是计算模式，流、批、图计算、机器学习都是不同的计算模式；而下面一层是分布式服务，我们认为这是一个核心层，它必须能解决调度问题、容灾问题、资源恢复问题等。通过这样的前期调研加上后期不断尝试并跟伯克利 AMPLab 及社区沟通，我们最终达成了一致，我们认为 Ray 是融合计算中的最佳实践方案。
Ray 的优势恰恰是一开始设计的时候，没有把自己绑定成某一种场景或计算模式的解决方案，它是一个真正的原生的分布式框架，可扩展性非常强。它不具备任何强封装的特性，所以可以非常灵活地做一些改动。劣势的话，Ray 本身是一个很新的框架。我们认为一个计算引擎在推出的前三年其实都是非常原始的状态，它在未来可能会有比较大的变化，或者会进行比较大的改动。
但其实 Ray 的优势和劣势也可以看作两个互补的特性，它既是一个刚刚推出、很多形态还没有确定的东西，但它也更原生、更简单、更容易改造、更容易达成融合的效果，是这样一个相辅相成的关系。目前来看，我们相信 Ray 是最适合做云原生的一套计算架构。
InfoQ：现在还有其他企业也在使用 Ray 这个引擎吗？
周家英： 从官方社区组织的活动或合作伙伴来看，目前阿里巴巴、Facebook、Amazon 这些大公司都有在关注及展开合作，但还处于比较早期的阶段，相对来讲比例非常少。很多企业可能还只是用 Ray 最原生的 API 或者原生的一些功能来解决很小一部分增强学习问题，或者做一些实验性的使用，像蚂蚁金服这样深度参与配合和大规模上线的可能是世界上唯一一家。
InfoQ：蚂蚁金服在使用 Ray 的过程中踩过哪些坑？基于 Ray 打造在线学习系统有哪些需要注意的地方？能否分享一下你们的经验。
周家英：坑有很多。Ray 本身是一个非常新的引擎，刚从实验室出来和能真正到线上生产之间是有非常大的鸿沟的。比如实验室可能经常使用一个比较小规模的测试集来测试它的性能稳定性等，但是在企业的生产环境里，它可能需要更大规模的测试集并进行更严格的可靠性的保障，可能中间有许多它之前没有的功能是我们需要再独立开发并重新贡献回给社区的，如可用性、性能优化，还有配套的生态，如调优、DevOps 工具，以及部署、调度等这样跟上下游结合的东西。
除了上面这些工程上的坑，还有一些别的问题。比如 Ray 需要兼容 TensorFlow，要实现多语言的调度、多语言的容灾等，有很多额外的工作需要做，比如在线训练过程当中的一些机器学习的特性语言，比如如何进行不同模型的训练并且不会对其他模型造成影响，比如在线学习如何把噪声降到最低，如何做版本回滚、如何做在线打通等。
这些都是我们认为比较大的一些特性，也是传统机器学习体系难以保证的一些点，蚂蚁金服围绕这些点投入了大量精力并做了大量工作，目前我们有几十个人扑在这个项目上。我们也希望后续能把这些工作回馈给社区。我们 计划在明年 3 月的时候将在线学习的这套框架和对 Ray 所作的改动全部开源，就是不希望其他公司或使用者再去踩一遍和我们相同的坑。
InfoQ：您认为 Ray 引擎现在是否足够成熟？什么样的企业或场景适合选用 Ray？为什么？
周家英：以官方开源的 Ray 版本来讲，它还是一个相对原始、没有太多功能的原生态的计算引擎，从这个角度来看，如果其他企业想用 Ray 做 Reinforcement Learning 或者深度学习的计算可能是比较实用的。那如果对应到我们现在内部的 Mobius 版本，它包含一套在线学习的整体研发平台，同时有流模式、在线学习模式、机器学习模式以及分布式服务等特性的支持。对于这个版本，我认为所有希望快速进行在线学习作业研发的企业都可以使用，因为它已经是一个完整的平台，我们把业务的计算领域封装得更好，它更适用于生产环境。
InfoQ：你们是什么时候开始筹划把 Ray 的内部版本开源出来的？
周家英： 开源的想法在我们开始做这个项目的时候就有了。我们不希望关起门来做一个东西，而是希望在它发展成熟到一定阶段之后，把它变成一个大众都可以去共享的项目和产品。我们既希望它可以服务于不同客户部门、不同使用者，也希望使用者可以能贡献更好的 Feature 进来。
我们希望通过 Ray 构建在线学习系统，让整个业界的在线学习能力更进一步，比如端到端延迟更低、可用性更高，或者整体的计算体系更内聚，将 Ray 开源肯定会有技术方面的积极影响。如果从这个项目的影响来讲，我们也希望通过开源，让更多的 Contributer 和 Committer 加入进来，把这个项目的特性或能力做得越来越强，同时也可以让 Ray 这个计算引擎被越来越多的人知道。
InfoQ：蚂蚁金服接下来还有什么技术上的规划？会关注哪些新技术？
周家英： 大数据计算未来的技术规划包括几点，一个是开放式的计算架构；一个是融合的计算引擎，也就是 Ray；还有一体式的全图计算，所谓大的包含图计算的场景；然后还有硬件与计算的结合，我们有硬件团队专门做硬件方面的优化使之与计算更加适配，这是我们整体的计划。
其他新技术还有比如数据湖以及图计算相关的，包括超大规模图计算、快速动态图计算、统一的图语言等，这些领域我们也都一直在关注。
采访嘉宾介绍
周家英（徒离），蚂蚁金服资深技术专家，现负责数据技术部在线计算团队。2011 年加入支付宝后，一直参与支付宝数据相关工作。经历了蚂蚁金服从离线数据，实时数据，到目前在线数据的不同的阶段，参与过蚂蚁实时数据平台，Serverless Streaming，在线作业调度，计算元数据，以及新一代计算引擎的建设。熟悉蚂蚁数据技术架构演进历史，对分布式环境下的在线计算场景及高可用方案有切身体会。