百度垂类离线计算系统发展历程 _垂类离线计算

作者 | 弘远君
导读
introduction
本文以百度垂类离线计算系统的演进方向为主线，详细描述搜索垂类离线计算系统发展过程中遇到的问题，以及对应的解决方案。架构演进过程中一直奉行“没有最好的架构，只有最合适的架构”的宗旨，面对不同阶段遇到的问题，给出了适合的解决方案。尤其是近10年来的超大规模系统架构的升级，一方面需要考虑系统本身的通用性和适配性，以满足多个业务方的需求；另一方面需要结合系统当前运行的特点，在易用性、稳定性、智能化等不同方面进行提升。希望读者能在了解系统演进的过程中获得一些启发。
全文9127字，预计阅读时间23分钟。
GEEK TALK
01
相关背景介绍
在过去，用户通过“百度一下”得到的搜索结果是从互联网上抓取来的结果，也被称为“自然结果” 。随着网络信息日益丰富，自然结果不能有效满足用户需求。为了解决自然结果无法满足搜索需求的问题，提出了针对各个垂类深耕的搜索结果的解决方案，一方面为用户带来的更优质的内容，让用户体验即搜即得的便捷，另一方面也可以帮助优质内容生产者提升访问量。
随着业务发展，除了标准通用的业务处理需求变更之外，越来越多的业务有自定义代码的更新需求。通过自定义数据处理，一方面，产品负责同学可以将原始传入的数据按照业务需求进行定制化处理，将原始数据转化为最终搜索的结果数据。另一方面，通用默认的一些功能机制限制了少量垂类的发展，业务希望引入更多的策略模型逻辑信号等处理以及打分机制，提升排序召回的效果。
在这样的背景下，业务对于数据加工计算的框架引擎的需求越来越强烈，并且功能也逐渐成为整个垂搜离线处理过程中不可或缺的一部分。
GEEK TALK
02
【百度垂类离线计算系统发展历程】计算系统演进过程
百度搜索系统离线数据处理从时间线的发展阶段来说一共经历如下几个阶段：

文章插图
a.原始离线处理系统: 本阶段主要是实现业务加工入口从0到1的构建。整体上还没有形成完备的框架体系并且开发成本较高，并且所有业务逻辑混在一个公共服务中，不同数据通过不同配置调用不同的策略逻辑。
b.业务离线处理架构: 本阶段初步形成一整套的业务服务处理框架，有统一的服务框架和开发阶段，实现了云原生和服务隔离的模式。
c.Serverless架构: 本阶段业务的接入效率上进一步提高，业务从管理服务面向转向管理业务加工函数，业务只需注册函数就可以快速测试上线，同时支持容器实例的自动伸缩，使得在业务的使用效率得到的极大提升的同时相应资源成本急剧压缩。
d.数据智能架构: 在原有服务部署的基础上同时实现了数据的管理，从函数管理进一步升级成为需求管理，实现多语言服务框架支持的基础上，成本进一步压缩&效率提升。
GEEK TALK
03
计算系统核心设计核心思路
&核心实现
下面详细阐述各个阶段的详细特点以及核心实现。
3.1 原始离线处理系统
这套架构应用于2018以前，当时垂类的发展整体属于起步阶段。该阶段业务主要的需求就是可以将原始的业务数据直接上线。架构的主要精力聚焦于通用业务能力的建设。随着业务的逐步深耕，发现有少量的业务慢慢演化出来自定义加工的需求。
根据当时的业务需求，最终从原有的数据加工模块中衍生出业务数据加工系统。当前阶段的数据加工处理方式是使用统一Handler处理方式，当然这个处理并非是必选项，多数业务仍然不需要自定义加工处理。各业务之间也完全没有数据隔离，这种架构最核心的意义就是从无到有提供业务的自定义加工能力。如下图所示，此时计算系统只包含计算引擎部分，其他系统完全没有建设。下面会对该系统的部分细节进行详细说明。