写点什么

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

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

    阅读完需:约 10 分钟

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

一、无处不在的广告


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


线上广告以互联网的高速发展作为媒介,在 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:057324

评论 1 条评论

发布
用户头像
清晰明了,挺不错的
2020-11-30 20:49
回复
没有更多了
发现更多内容

架构实战营作业--学生管理系统

Simon

架构实战营

DataSphere Studio 0.9.1 版本发布

WeDataSphere

大数据 微众银行 WeDataSphere DataSphere Studio 数据应用开发平台

Wireshark 数据包分析学习笔记 Day27

穿过生命散发芬芳

Wireshark 数据包分析 4月日更

你可以伤害我,但是不能侮辱我

小天同学

人生 自我思考 个人感悟 4月日更 处世态度

架构训练营——作业1

架构实战营

【译】如何编写Go代码(使用GOPATH)

xcbeyond

Go 语言 4月日更 GOPATH

作业1

大肚皮狒狒

模块一笔记:4R、3原则与设计环

去北方

模块一作业

Focused

VSCode 插件之 - GitLens

HoneyMoose

二叉树学习总结

Nick

数据结构 算法 二叉树 红黑树

阿里内部资料:并发编程知识点总结

Java架构师迁哥

Pod 阶段

耳东@Erdong

容器 4月日更

架構實戰營 - 模塊 1 作業

Frank Yang

架构实战营模块1 课后作业

Neil43

架构实战营

架构实战营0期作业1

sjj

架构实战营模块一作业

hunk

架构实战营

【命题作业】模块 1:微信业务架构图+“学生管理系统”架构设计

小李

架构实战营

架构师实战营 1 期 作业1-微信的业务架构及学生管理系统

灵霄

架构实战营

Visual Studio Code 插件之 - Git History

HoneyMoose

架构实战营作业--业务架构图

Simon

架构实战营

学生管理系统

focus

自然语言处理:网购商品评论情感判定

不脱发的程序猿

人工智能 自然语言处理 4月日更 网购商品评论情感判定 文本分析

架构训练营--微信业务架构

月伴沧海

ES6面向对象 动态添加标签页

Chalk

JavaScript 大前端 ES6 4月日更

架构训练营作业第一期

预测师

「编程模型」C++组合逻辑

顿晓

C++11 4月日更 std::function

模块一:作业

去北方

架构实战营

【架构实战营】模块 1 作业

dragonboa

杭州又多了一个失意的人

箭上有毒

前亚马逊工程师:广告系统架构解密_移动_骆俊武_InfoQ精选文章