网站建设项目付款方式,网站备案查询中心,分销商城app开发,群辉wordpress阿里云ssl导读#xff1a;如今大部分人工智能应用是基于监督学习范式开发的#xff0c;即模型在线下进行训练#xff0c;然后部署到服务器上进行线上预测#xff0c;这样的开发方式在实时响应上存在较大的局限。随着计算和 AI 体系逐步成熟#xff0c;我们希望机器学习应用能更多地… 导读如今大部分人工智能应用是基于监督学习范式开发的即模型在线下进行训练然后部署到服务器上进行线上预测这样的开发方式在实时响应上存在较大的局限。随着计算和 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前面提到了实时数据阶段和在线数据阶段二者关键的不同是什么周家英实时数据阶段是从离线数据阶段发展过来的虽然比以前更快但是它所面临的问题也很直观。比如数据计算从 T1 变成 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还有一体式的全图计算所谓大的包含图计算的场景然后还有硬件与计算的结合我们有硬件团队专门做硬件方面的优化使之与计算更加适配这是我们整体的计划。
其他新技术还有比如数据湖以及图计算相关的包括超大规模图计算、快速动态图计算、统一的图语言等这些领域我们也都一直在关注。
原文链接 本文为云栖社区原创内容未经允许不得转载。
