前言
RTP平台是阿里内部一个通用的在线预测平台，不仅支持淘系搜索、推荐、聚划算、淘金币等业务，也支持国际化相关icbu、lazada等搜索推荐业务，同时还支持着淘客，优酷、飞猪等大文娱的搜索推荐场景。作为一个通用的在线预测平台，RTP不仅提供基本的模型inference能力，同时对于排序打分类场景有更深度的优化。
近些年，机器学习的发展速度越来越快，机器学习的技术应用也越来越广，从2016年开始，RTP平台开始逐渐支持一些简单的深度模型场景例如wdl、dnn等，但是有限的模型种类不仅限制了算法同学的发挥，在从系统维护优化角度来说，也是逐个击破的策略，总体业务支撑的效率偏低。
因此从2017年初开始，在原有rtp系统的基础上，我们基于深度学习的场景，重新思考了我们的架构和业务场景，对RTP整个平台做了一次较大的升级，从设计上考虑整体的迭代效率、运行效率、可扩展性，大幅提升了RTP整体的能力，从架构重构到现在，RTP整体的业务量和业务形式都有了大幅度的增长，同时算法同学应用RTP平台也拿到了相当可观的算法效果。
本文主要围绕着RTP重构的思路及问题展开。
迭代效率-平台与架构
近几年来，机器学习领域正在飞速发展，模型的快速迭代速度和架构的灵活性在这个时刻显得尤为重要。加快算法迭代速度，简化算法验证成本，能带来革命性的进步。在caffe、tensorflow等机器学习系统开源之后，对于训练本身的迭代瓶颈得到了一定的缓解，inference在小模型、小的问题集上也还能够适用，但是大规模模型的inference仍然是一个复杂的系统工程问题。
RTP系统的设计宗旨是让算法同学能够享受端到端的用户体验，尽可能简化算法同学需要对工程细节的了解。
我们思考一下，对于一个算法工程师而言，开发一个新的算法，或者上线一些新的feature需要做的工作。
- 原始数据准备
一般而言数据源头都有对应的负责团队或者负责人负责数据的质量和使用方式的，大部分工作是数据准备，数据清洗等工作，odps/blink在这部分工作中起着巨大的作用，很多团队都沉淀了自己的一套流程，全量、批量数据、实时数据的产出都依托于odps及blink的能力，最终以表的形式推送到RTP系统。 - feature生成
feature一般可以用通用的feature生成规则（一般就是原始值、id特征、各种交叉特征等规则），rtp从最初的版本开始就提供对应的feature生成规则，保证用户训练生成feature的逻辑与在线inference中产生的feature一致。 模型设计、训练
模型方面应该将自由度交给算法同学，让他们能自由设计；训练平台方面，集团内也已经有较为成熟的训练平台，常用的例如Pai、Porsche，或者基于PS等自己开发的算法，亦或者Caffe等开源平台训练。- 模型、数据、feature生成规则部署到在线
这一步是比较复杂的，也是RTP系统希望能解决的。以往的做法有点类似算法同学作为PM的角色来上线整个模型，思考如何将模型推到在线的各种系统上去。具体需要考虑的部分包括原始数据、模型数据、模型inference具体逻辑。
虽然大部分都已经有自动流程，但是完全新增的模型，整体上线的时间也会很长，更重要的是，从模型与数据的整体设计产出，到真正可服务的链路过长，导致整体的认知成本极高，依赖算法同学来串联整体系统最终完成模型服务的模式是非常低效而又容易出现问题的。
整体模型的样本特征等的管理平台我们把它叫做AOP平台，AOP平台会负责整个模型及样本的所有元信息的管理及在离线的一致性。下图中可以看到AOP的运作方式，AOP主要管理着整体的元信息，并负责协调样本和日志数据的一致性，离线数据库表与在线字段数据的一致性、离线与在线的特征处理方式的一致性、离线模型的训练、验证及自动发布到RTP系统。
运行效率-存储与计算
RTP平台主要的运行效率取决于对应特征及模型的计算过程，整个RTP设计优化的思路也围绕这几点而来。
架构优化-online2offline
在很长时间以来，在线服务的体系里都将业务的离线处理逻辑和在线计算逻辑分离开，用户需要协调离线数据处理过程和在线计算逻辑，为了完成对在线逻辑的一些性能优化，往往需要离线数据做一定的预处理或者索引构建等过程，而后才能让在线的服务使用。
环视其他有在线服务特性的系统，对于搜索引擎而言，类似“组合索引”、“过滤转倒排”等优化方式，包括正常的倒排索引，都是“因为可以加速在线检索过程”而生成的；对于数据库而言，类似“物化视图”的思路，也是因为可以加速在线的查询过程而在离线提前计算好；对于分析引擎而言也是一样的，为了能快速拿到统计数据，在索引构建的同时就会将统计结果预先计算好。这些方案的核心思路都是数据的构建是为了在线计算。
RTP系统是基于suez平台实现的，在RTP之前，suez平台并没有为数据的构建是为了在线计算建立一套行之有效的优化通路，先变更离线数据的计算方式，然后在线才开启这个优化/功能，这实际上和数据的构建是为了在线计算的思路是矛盾的。现有的一些优化方案中都需要多处配置，先配置好离线，等离线生效了才能配置在线，造成了很多优化功能实际上难以大范围的用起来，这也反向的制约了我们做联动优化的意愿。
这一现象在RTP的场景中更为明显，RTP的一个设计原则在于让迭代变得更简单，因此在RTP中，我们大大的削减了用户所需要关心的优化选项和配置，极尽可能的减少用户所需要关心的“工程优化”的问题，这就迫使我们必须体系化的解决优化的问题。 
因此在过去的一年中，我们重构我们上线流程中涉及的大部分系统，将“用户应该做的优化”沉淀成一系列的optimize pass，从在线计算逻辑中推导出我们应该做的优化，并自动的生效的系统中。一些典型的应用，类似自动的离线predict、数据的format等都可以自动根据具体在线的运行逻辑而自动生成，大大降低了整体系统的优化的人力成本。
特征计算优化-codegen
特征的计算在整个RTP的系统中是非常重要的一环，无论是传统的LR、GBDT模型还是深度学习模型，都离不开基本的特征运算。对于特征运算而言，不仅需要考虑特征的表达能力和运算速度，还需要考虑扩展能力、组合能力等。
特征计算的过程实际上是一个非常结构化的数据的计算，在这一方向上，很长一段时间依赖RTP的特征计算都是解释执行的，而特征计算本身是较为固化的，解释执行在泛用性上是可以满足需求，但是性能上是不够优的，在过去的一年我们尝试了codegen技术，并取得了相当不错的结果，这部分细节我们在另一篇文章中已经总结了，具体可以看：
大规模深度学习预测场景下 codegen 的思考与应用
网络计算优化-异构计算
对于深度学习场景而言，异构计算是其中非常关键的一环，目前RTP平台不仅支持GPU，也大量使用FPGA来加速预测过程。
GPU在重计算的场景下有着巨大的优势，特别是一些CNN模型的场景下，GPU整体的吞吐和latency都明显优于FPGA，同时有良好的生态，整个机器学习领域甚至并行计算领域中，GPU的案例非常之多，前人都留下了无数的工作成果可以很方便的应用起来，例如量化、甚至于排序等都有现成可用的方案。
FPGA而言，对于非图像视频类场景而言，模型的计算复杂度不是特别高，很难发挥GPU完全的能力，从我们实践下来的结果看，FPGA非常适用于中小复杂度的计算，一方面是从成本角度看，FPGA相对于GPU而言是便宜得多的，另一方面FPGA对硬件的定制化能力更强，可以精细化调度和控制计算单元，使得整体硬件的能力能更加充分的被发挥出来，在刚刚过去的双十一，RTP用到的异构计算资源中，FPGA的数量已经超过GPU的数量，成为整个机器学习异构计算中相当重要的一员。
在我们看来，FPGA和GPU各有所长，对平台而言，这两种异构计算实际上是互补的，一个考虑泛用性，一个考虑成本；一个考虑高密度计算，一个考虑中小密度计算。这两种异构计算给了平台业务更多的选择和手段，同时给用户提供高灵活性和低成本。
