当今互联网有几种主流的商业模式:广告、游戏、增值服务等。毫无疑问“广告推送”带给互联网公司的收入绝对是相当可观。今天为大家分享一篇来自 360 手机卫士团队分享的 SSP 广告引擎。
一、概述
当今互联网有几种主流的商业模式:广告、游戏、增值服务等。今天我想谈一谈广告系统中的 SSP 引擎。SSP(全称:Sell-Side Platform)是一个媒体服务平台,该平台通过人群定向技术,智能的管理媒体广告位库存、优化广告的投放,助网络媒体实现其广告资源优化,提高其广告资源价值,达到帮助媒体提高收益的目的(以上摘自 360 百科)。大白话就是: 各种端(app 端)找 SSP 要广告, SSP 选出一批广告, 并告诉这些端,按照某些样式展示。SSP 负责如何去选广告, 以及相应的样式是什么样子。SSP 不断优化选择广告和确定样式的策略,让各个产品能赚到更多的钱。
一个好的 SSP 系统应该具备那些能力? 我总结了五点,列在下面:
灵活扩展能力
快速接入各种广告源
快速接入各个产品
快速验证广告的不同样式
快速调整广告页面布局
快速调整广告策略
高性能、高并发能力
高效发布和在线灰度能力
快速调试定位错误能力
强大的数据处理和分析能力
精准的用户画像刻画
准确的广告推荐
分钟级数据监控
支持海量数据细粒度的多维数据查询
二、SSP 系统架构
SSP 作为一个大型的业务系统, 系统结构还是比较复杂的,架构上可以分为以下六层:产品层、接口层、业务中间层、微服务层、数据处理层、数据存储层。分层系统架构图见图 2-1, 详细架构图见图 2-2
三、Flexible and Scaling (灵活扩展性)
在上一章 SSP 系统架构图中所展示的,系统灵活扩展能力主要体现在业务中间层,从大到小我们分了四个层次来为系统提供足够的灵活扩展性, 分别是架构层、业务层、广告控制层、广告展示层。 我们抽象出四个概念用来对应,Micro Service 对应架构层, Topology Organizer 对应的是业务层, Rule Manage System 对应的是广告控制层, Template Manage System 对应的广告展示层。
3.1 Micro Service
micro service 翻译过来是微服务, 与微服务对应的是单体式架构(传统方式),单体式架构特点是所有功能打包在一起,基本没有外部依赖,优点是开发管理简单;而微服务架构整个系统由多个子服务组成,各个服务功能独立,服务之间通过消息传递来耦合,最大优点是系统耦合性低,有非常好的扩展性,架构示意图见 图 3.1-1 和 图 3.1-2。
从第二章的 SSP 系统架构图上可以看到, SSP 是一个非常复杂的系统, 并且 SSP 有个特点就是各个子服务(各个 DSP, 用户画像,红
包等)之间几乎没有什么关系, 如果想要快速的接入一个广告源,快速的上线一个产品,具有非常灵活的 DSP 上下线规则, 那么微服务
架构是我们唯一的选择。
3.2 Topology Organizer (based DAG Algorithm)
系统架构层我们采用了微服务解决了独立子服务接入的灵活性,那么业务逻辑的多变组合如何来高效解决呢? 在 Topoplogy Organizer 框架中我们给出了比较好的一个解决方案。该框架包含 DAG, topology, stage, context 四个概念,我们把业务拆解成一个功能单元的组合体, 每个功能单元叫做 stage, DAG 代表了 stage 的执行逻辑图,topology 用来控制 stage 的执行先后顺序,context 用来做 stage 之间的数据交换,这个结构只有数据耦合,具备并行操作的基础(这在 migo 架构中会详细说)。不同业务可以共用 stage 模块代码,大大减少了代码的重复开发量,提高了开发效率。示意图如下:
图中左右两个业务的 DAG 表示图,可见初始化规则库、请求解析、用户画像服务、过滤服务、返回广告等 stage 是可以共用的,
业务可以由这些 stage 灵活组合而成。
3.2.1 DAG
DAG(有向无环图), 如图 3.2-1 所示, 业务可以组织成 DAG,这种图结构保证了功能模块的执行顺序, 定义好一个 DAG 也就
定义好了一个业务的流程。
3.2.2 topology
topology 算法用来实现 DAG 的功能块执行顺序,保证功能块的次序不会被颠倒,如图 3.2-1 的左图, 通过 topology 会被分解成初始化规则库-> 请求解析->用户画像->点睛 DSP(或自运营 DSP、MAX DSP, 以上可以通过异步技术手段并行化处理)->过滤服务 ->重排服务 ->返回广告
3.2.3 stage
我们把每个功能模块称为 stage, 负责完成某一特定功能。stage 模块可以逐步沉淀出很多公共模块,为代码共享,加快开发提供了很好的基础。比如各类 DSP stage 可以抽象出公共 DSP stage, 公共 DSP stage 负责完成和下游 DSP 的 RPC 交互操作,派生的 DSP stage 只用改写自己的各种参数即可。
3.2.4 context
context 是一种表示上下文信息的数据结构,在 Topology Organizer 框架中起到 stage 之间传递数据的作用,正式由于这个结构的提出,才使得 stage 之间逻辑解耦,交互完全变成数据依赖,相当于贯穿一个业务的数据总线。
context 结构的定义大致类似如下的结构:
支持 add, delete, get,set 操作。add, delete 用来添加删除 context 的任意路径的节点, get,set 操作用来对 context 某一路径节
点取值或者赋值。
3.3 Rule Manage System
我们用 micro service 和 Topology Organizer 解决了架构和业务的灵活扩展性,但光做到这两点还不足以提供足够的灵活性。不同业务在同一 stage 下的数据处理逻辑可能会有一些不同,比如频次控制服务,卫士广告可能每个广告控制 10 次, 卫士 CPM 可能是每个广告控制 100 次。如果我们把这些限制条件写入到代码中,那么随后带来的将是无休止的策略调整和代码上线。下面我们介绍一下 Rule Manage System,如何优雅的在数据项这么细的粒度提供灵活性。
3.3.1 rule engine
什么是 rule ,我们可以认为 rule 是条件到输出的一个函数映射,形式描述如下:
Output = R(condition,condition,…) ; Output 为输出, R 为 rule 映射关系,condtion_list 是条件, 为输入参数。
我们发现,上节描述的频次控制功能可以描述成一个规则 Output = R(product,ad_control,model),展开成如下两个具体
规则 :
通过添加上面两个规则,我们不用修改代码即可实现对频次控制策略的运营,如果卫士广告频次想改成 15 次, 运营改这个规则就可以了,而不用去改引擎代码,避免了引擎测试、上线、重启后续一系列麻烦的事情。
rule table : 许多的 rule 构成一张规则表, 如果我们想查找符合某种条件的输出是什么, 查这个规则表即可, 如果我们想灵活的控制某一数据项, 向这个规则表插入一条 rule 即可。图 3.3-1 展示了一个规则表实例。
rule engine:对 rule table 进行管理,组织成特定数据结构(可以是上图所示的表的结构, 也可以是其他更加复杂的数据结构),提供插入,删除,查找等操作。
3.3.2 quick match rule
上节我们谈到 rule engine 可以不同的组织方式,不同的数据结构带来的查询性能会有很大的区别,SSP 引擎由于请求量非常大,而且每个请求都会对 rule engine 进行规则查询,那么如何快速的进行 rule match 对 SSP 的性能影响会非常的大。
评论