快手、孩子王、华为等专家分享大模型在电商运营、母婴消费、翻译等行业场景的实际应用 了解详情
写点什么

如何打造高质量的 SSP 广告引擎(上)

  • 2019-11-28
  • 本文字数:2921 字

    阅读完需:约 10 分钟

如何打造高质量的SSP广告引擎(上)

当今互联网有几种主流的商业模式:广告、游戏、增值服务等。毫无疑问“广告推送”带给互联网公司的收入绝对是相当可观。今天为大家分享一篇来自 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 结构的定义大致类似如下的结构:


<business name="卫士广告">    <stage name="用户画像">        <attrlist>{年龄:20;收入:3k;爱好:旅游}</attrlist>    </stage>    <stage name ="点睛DSP">        <adlist>{ad1:com.mobilesafe.apk ;ad2:com.zhushou.apk; ad3:com.browser.apk}</adlist>    </stage>。。。。。。</business>
复制代码


支持 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 的性能影响会非常的大。


2019-11-28 14:223197

评论

发布
暂无评论
发现更多内容
如何打造高质量的SSP广告引擎(上)_服务革新_李振博_InfoQ精选文章