追求极致的AI·OS——AI·OS引擎平台

AI·OS技术栈

2018年9月底，搜索事业部举办了一场十年技术峰会。在这场峰会上，我们正式将搜索的在线服务由iSearch5升级到AI·OS大数据深度学习在线服务体系。这次名称的变化，体现的是搜索技术十年量变到质变的积累，体现的是搜索人十年的坚持。

搜索近十年的发展可以分为四个主要的阶段。一是2008至2009年，iSearch 4.0版本，是搜索技术独立起航的第一个版本，它脱胎于iSearch 3.0，强调的是分布式、大规模、高可用，有很好的扩展能力，当时在B2B和淘宝同时上线，使搜索技术赶上了业务的发展。二是2009年至2011年，引擎出现了Kingso和HA3两个分支，Kingso以高性能闻名于世，HA3则是完全重构的版本，具有良好架构。这个阶段主题是系统化和高性能，我们开始将引擎视为一个完整、闭环的系统，而不是一系列进程和脚本的拼接。三是2011年至2013的搜索技术峰会，我们将集团搜索引擎统一，提出了iSearch 5.0引擎平台。这个阶段的关键是平台化，我们认为应当打造一个引擎平台支持全集团的搜索业务，而不是为每个搜索业务定制引擎，只有这样才能走得更快。当年在平台化与效率的问题上，搜索内部有一波不小的争论，事实上，这种争论在集团很多平台上仍在重演。只要有平台与业务之分，就会产生这种争论，平台如何抽象才能支持好业务的迭代、保证业务不被阻塞，业务又如何积累产生平台性的创新、保证平台的统一性，究竟应该统一版本还是分支发展。我个人是平台化坚定的支持者，但平台化不意味着不允许分支，平台化也不意味着不允许业务快速迭代创新，平台化更不意味着只能有一个团队开发平台功能。恰恰相反，平台团队仅仅是代码主线的维护者，是武林盟主而不是皇帝。一切以技术正确、而不是政治正确来衡量，只要坚持这一点，万流归宗，所有的分支自然会回归主线，这是中台应有的自信，充分开放才能成就中台。

2013年到现在的五年，是搜索发展的第四个阶段，搜索技术面对了很多新的挑战，其中最大两个，一是推荐的崛起，二是深度学习的广泛应用。这也是AI·OS产生的原因，我们面对的不再是搜索一个单一引擎，而是多样化的推荐引擎和深度学习引擎，这就需要更高层的服务框架抽象和更高效的执行引擎。

接下来，我来介绍一下引擎平台在最近一年的发展和创新。

Suez Turing在线服务框架

推荐业务与深度学习的发展都对在线服务框架提出了很大的挑战。

从推荐业务来看，与搜索类似，也是query处理、召回、排序、后处理几个阶段，但每个阶段都有自己的特点。比如推荐的召回广泛使用多路召回混排的模式，细节每个场景还会略有不同。如此之多的种类和组合，很难用一个固定的引擎支持，而简单把这些逻辑丢给算法同学，又会回到TPP上一坨复杂低效java代码的老路。我们需要一个高性能、易定制、高抽象的在线服务框架。

从深度学习的应用来看，模型已经无孔不入，不仅仅是排序时才需要运行深度模型。在query处理、召回甚至是取摘要时都可能有模型。从性能优化的角度考虑，我们还有可能在离线Build阶段运行模型。所以，深度模型的计算，不是一个割裂的、另类的需求。是必须内置到执行引擎，与正常的召回、过滤、排序、统计对等的功能。

基于这些考虑，今年我们升级了Suez服务框架，提出了Suez Turing全图化在线服务框架。今年，Suez Turing引擎在架构上实现了HA3、BE、RTP的整合，并在双11成功应用到了主搜、店铺内、猜你喜欢BE、海神、菜鸟等业务线。主搜上实现了HA3和RTP合图并支持了粗排深度模型；猜你喜欢BE上实现了算子并行使得latency降低一半；codegen技术使菜鸟包裹引擎统计性能提升一倍。经历双11，Suez Turing框架的稳定性和性能均得到了验证。

RTP深度学习预测服务

今年双11，各种业务场景上深度学习应用仍然处于井喷状态。搜索与推荐各种业务场景纷纷上线大模型，特别是AOP一站式算法平台推出后，大幅降低了算法同学实验和上线模型的难度。RTP上的模型复杂度大幅增加。

在CPU计算上，我们主要的两个优化手段是online2offline和fg codegen技术，将CPU端性能提升一倍以上。在异构计算加速上，今年我们大规模应用了GPU和FPGA异构计算技术，使用FPGA的数量超过了GPU。特别是我们与AIS合作FPGA加速方案，是FPGA在阿里集团内首个深度学习大规模生产应用的场景。在去年双11灰度验证的基础上，今年FPGA成为支撑搜索双11的主力，在中小batch场景下，FPGA带来的提升明显。FPGA全链路软硬件都可掌控、可优化，未来潜力巨大。

另一方面，RTP平台上业务大幅增长，而且业务都是用户自助创建的。如何自动为用户选择最合适的集群，如何保证这么多的业务安全稳定的升级和更新。我们在集群治理方面也做了不少工作，大大减轻了RTP平台的维护代价。

搜索混部

今年双11，搜索混部仍然保持持续工作，在包括11日凌晨最高峰的时段都保持不降级。混部上10日晚间至11日凌晨计算的算法模型，在11日当天上线，为提升用户体验发挥了巨大的作用。在双11的30小时内，搜索事业部国内所有机房的平均负载做到了40%，峰值做到50%。最大的一个混部机房做到平均负载57%，峰值70%。

今年我们与计算平台事业部合作，推出了AliYarn，将搜索在线多年积累的在线调度和隔离能力输出到Yarn中。通过这个版本，我们在去年混部深度学习训练任务的基础上，做到了与Flink实时计算任务的混部。双11后，AliYarn将会在搜索在线上线，成为Sigma上同时支持离线任务、流式任务、在线服务的调度器。

在线服务计算存储分离

不论是搜索还是推荐，还是深度学习，都离不开数据，计算和存储是在线服务要解决的两个永恒的问题。搜索调度系统统一后，可以发现上层业务非常多样，有极端重计算轻索引的应用，也有极少流量索引巨大的应用。不论是那种在线服务，对latency的要求都是一样的。对大数据量的应用，普遍存在着搬移慢，故障恢复慢的问题。而为了支持这些大数据量的应用，即使他们只运行在少数机器上，为了成本，我们的机型也要做普遍的适配，实际上是加大了整体成本。再加上索引切换之类的额外预留，实际有效存储使用不到一半。

今年阿里集团普遍推广使用计算存储分离技术，搜索也不例外，但搜索的场景非常特殊。一是，搜索分离的数据量并不大，因为我们是在线服务，最大也不过是PB级，这与大数据离线计算相比，数据量不值一提。二是，搜索的服务质量要求极高，我们要求4个9稳定的读latency，而且是在一个并不小的写背景下，这与追求吞吐的离线计算和作为普通log存储的场景完全不同。三是，搜索对服务的可用性要求极高，要做到在线服务级别的可用性。

今年双11我们在两个业务场景实验了在线服务计算存储分离。一是一个推荐场景，存储分离节省了45T内存，结合Suez Turing全图化框架，大幅缩列提升性能，以73%的服务器支撑了262%的流量。另一个是摘要服务场景，这在搜索与推荐链路都是至关重要的服务，存储分离集群稳定承担了20%的流量。集群延迟和性能表现稳定。双11后，我们将在搜索全面推广计算存储分离技术。

展望

接下来，AI·OS引擎平台会继续推进在线服务框架的迭代演进，推进Suez Turing上层引擎的统一，做更大范围的合图。最终我们希望能让用户很方便地定制后台引擎，同时保持高性能和高可用。

集群调度和管理方面，我们会推广计算存储分离技术，将大量大索引有状态的服务无状态化，加速调度决策执行速度和故障恢复的速度。同时，我们还会进一步统一搜索的在离线调度，做更大范围的统一调度。

在异构计算加速方面，我们要积极尝试新的密度更高的异构硬件型号，在FPGA软硬件协同和GPU的新型号引入方面也要投入更大的精力。