【FCon上海】与行业领袖共话AI大模型、数字化风控等前沿技术。 了解详情
写点什么

前亚马逊工程师:广告系统架构解密

  • 2020-11-30
  • 本文字数:3152 字

    阅读完需:约 10 分钟

前亚马逊工程师:广告系统架构解密

AI 大模型超全落地场景&金融应用实践,8 月 16 - 19 日 FCon x AICon 大会联诀来袭、干货翻倍!

一、无处不在的广告


广告的形式分为线上和线下模式。


线上广告以互联网的高速发展作为媒介,在 pc 端和移动端有着多种多样的发展模式:



线下广告以传统方式,以公交站牌、门头、交通等媒介的发展模式。


在当今社会的发展趋势下,线上广告占的比重越来越大。


二、什么是广告



广告的基本组成单位:广告主、媒介、受众。


广告的基础概念:流量。对于互联网来讲,如何更好地引流、吸引更多的群体,和如何精准地向特定人群推送广告主的广告,是互联网广告的关键。


三、互联网广告的发展趋势



  • 互联网广告的行业规模越来越大;

  • 移动端的快速发展,给人们带来了更多的方便,广告产业比重越来越多;

  • 广告模式越来越多;

  • 互联网广告依托互联网媒介的发展,在各类平台广告的比重,有着正相关的影响。


好的互联网产品更够带来更多的广告推广和盈利模式。


四、互联网广告的本质



以 CPC(按照点击计费)为例,收入可分解成下面这个公式:



其中,PV 表示系统的访问量,PVR 和 ASN 表示广告的填充率,CTR 表示广告的点击率,ACP 表示广告的平均点击价格。


上述各个指标都可以通过一系列的广告策略来提升。比如填充率可通过开发更多的广告主来实现,CTR 可通过 AI 算法做到精准投放来提升,ACP 可通过精准流量溢价或者提升广告主 ROI 来完成。


掌握上面这个收入分解公式,对于理解广告业务至关重要,任何业务上的动作几乎都能关联到这个公式的某个指标上。


五、互联网的结算方式



广告业务发展了几十年,广告费用的结算方式也诞生了很多种,我们最常见的有以下几种:


  • CPT: 按时间计费,独占性包时段包位置

  • CPM: 按照每千次曝光计费

  • CPC: 按照点击计费

  • CPA: 按照行为计费(比如下载、注册等)


不同的广告平台适合自己的结算方式:


如以信息流为主的 cpm,搜索软件为主的 cpc 等,根据广告推广的直接效果,而进行的结算模式变革。


六、互联网广告的初始形态



自己引流,开发广告主,具有一定的局限性,只依靠自己的流量,不具有受众的广泛性和多样性,开发广告主的过程中具有一定的限制。


七、后期广告的发展



广告的核心就是流量,联盟广告的出现,确保在受众的多样性和广告平台的多样性,具有更高的曝光率和广告模式的收益。为此此项广告模式,也就要求平台具有多样的资源整合能力,对平台技术的稳定性要求也越来越高。


八、电商广告




对互联网平台来说,初期一般都是采用「 自营的竞价广告网络 」来实现商业变现,简单理解:就是利用平台自有的流量以及自主开发的广告主来实现业务闭环。本文所分享的广告架构主要针对这种业务形态,它的核心业务流程如上图所示。


  • 广告主先通过投放平台发布广告,可设置一系列的定向条件,比如投放城市、投放时间段、人群标签、出价等。

  • 投放动作完成后,广告会被存放到广告库、同时进入索引库,以便能被广告检索引擎召回。

  • C 端请求过来后,广告引擎会完成召回、算法策略、竞价排序等一系列的逻辑,最终筛选出 Top N 个广告,实现广告的千人千面。

  • 用户点击广告后,会触发广告扣费流程,这时候平台才算真正获得收益。


上面是广告业务的核心流程,随着平台流量以及广告主规模进一步增大,往往会从「自营型竞价网络」逐渐向「联盟广告以及 RTB 实时竞价」方向发展,类似于阿里妈妈、腾讯广点通、头条巨量引擎,此时业务复杂度和技术架构会再上一个台阶,本文不作展开,后续再跟大家详细分享。


随着电商模式的发展,B2C、C2C 等模式的开展,卖家和买家都在疯狂的增长,电商平台也为此带来的更多的便利性。对于电商,由于买家和买家的准确性,电商广告具有一定的精准性,广告收益比相对较高,效果更好。好的广告排名往往带来更多的效益,对于电商平台而言,也带来的更多的挑战,平台的维护成本和大数据的处理优化。


九、电商广告面临的技术挑战



由于广告主->平台->受众,平台在为广告主和受众提供更好的服务和用户体验性,同时在追求更好的广告效果,需要各个系统之间的系统运转,保证整个平台的流畅性。


广告平台技术挑战


对广告业务有了初步了解后,再来看下广告系统面临的技术挑战:


1、高并发 :广告引擎和 C 端流量对接,请求量大(平峰往往有上万 QPS),要求实时响应,必须在几十毫秒内返回结果。


2、业务逻辑复杂 :一次广告请求,涉及到多路召回、算法模型打分、竞价排序等复杂的业务流程,策略多,执行链路长。


3、稳定性要求高 :广告系统直接跟收入挂钩,广告引擎以及计费平台等核心系统的稳定性要求很高,可用性至少要做到 3 个 9。


4、大数据存储和计算 :随业务发展,推广数量以及扣费订单数量很容易达到千万甚至上亿规模,另外收入报表的聚合维度多,单报表可能达到百亿级别的记录数。


5、账务的准确性 :广告扣费属于金融性质的操作,需要做到不丢失、不重复,否则会损害某一方的利益。另外,如果收入数据不准确,还可能影响到业务决策。


下面着重介绍平台设计的几个关键点:


广告检索平台的性能设计



计费平台的方案


计费平台也是一个核心系统,主要完成实时扣费功能。比如 CPC 结算方式下,广告主设置的预算是 50 元,每次点击扣 1 元,当扣费金额达到预算时,需要将广告及时下线。


除此之外,计费平台还需要支持 CPM、CPT 等多种结算方式,以及支持反作弊、余额撞线处理、扣费订单的摊销和对账等功能。


计费平台的特点是: 并发高、数据量大、同时可用性要求高,需要做到不少扣,不重复扣。 下面以 CPC 实时点击扣费为例,详细说下技术方案。



CPC 实时扣费流程


首先,整个扣费流程做了异步化处理,当收到实时扣费请求后,系统先将扣费时用到的信息缓存到 Redis,然后发送 MQ 消息,这两步完成后扣费动作就算结束了。


这样做的好处是:能确保扣费接口的性能,同时利用 MQ 的可靠性投递和重试机制确保整个扣费流程的最终一致性。


为了提高可用性,针对 Redis 和 MQ 不可用的情况均采用了降级方案。Redis 不可用时,切换到 TiKV 进行持久化;MQ 投递失败时,改成线程池异步处理。


另外,每次有效点击都需要生成 1 条扣费订单,面临大数据量的存储问题。目前我们采用的是 MySQL 分库分表,后期会考虑使用 HBase 等分布式存储。另外,订单和账务系统之间的数据一致性,采用大数据平台做天级别的增量抽取,通过 Hive 任务完成对账和监控。



OLAP 海量数据报表方案


数据报表是也是广告平台的核心业务,它是广告主、平台运营人员进行投放优化、业务决策的依据。先来看下广告数据仓库的分层结构:


  • 源数据层 :对应各种源数据,包括 HDFS 中实时采集的前后端日志,增量或者全量同步的 MySQL 业务数据表。

  • 数据仓库层 :包含维度表和事实表,通常是对源数据进行清洗后的数据宽表,比如行为日志表、推广宽表、用户宽表等。

  • 数据集市层 :对数据进行轻粒度的汇总表,比如广告效果表、用户行为的全链路表、用户群分析表等。

  • 数据应用层 :上层应用场景直接使用的数据表,包括多维分析生成的各种收入报表、Spark 任务产出的算法模型特征和画像数据等。


采用这样的分层结构,和软件分层思想类似,提高了数据的维护性和复用性。


再来看应用层报表部分面临的挑战:聚合维度多,需要分时、分广告位、分推广等几十个维度;单表最大达到百亿级别;支持时间范围的实时查询。


这部分由公司的大数据部门维护,采用了开源的技术方案,离线部分使用 Kylin,数据存储在 HBase 中;实时部分使用 Flink 和 Spark Streaming,数据存储在 Druid 中。




  • 对于平台而讲,在确定需求后,首先需要明确自己的发展模式,更具模式,确定系统,从而明确各个系统的功能、协同性、以及各个系统的压力点。进行倒推,确定平台系统的架构和技术方案。

  • 好的系统架构,需要以系统的可用性为基础,进行系统升级和拓展。

  • 对于互联网广告业务来讲:好的产品往往带来革命性的变革,这个社会缺乏沉淀和创意。优秀的产品思路决定着广告行业的风向。

  • 小问题:百度为何衰落的呢?是电商的冲击还是微信的崛起呢?


作者介绍


骆俊武,前亚马逊工程师,现 58 转转技术总监


本文转载自公众号技术琐话(ID:TheoryPractice)。


原文链接


前亚马逊工程师:广告系统架构解密


2020-11-30 14:056924

评论 1 条评论

发布
用户头像
清晰明了,挺不错的
2020-11-30 20:49
回复
没有更多了
发现更多内容
前亚马逊工程师:广告系统架构解密_移动_骆俊武_InfoQ精选文章