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

简介: 前亚马逊工程师:广告系统架构解密(3)
  • 广告主先通过投放平台发布广告,可设置一系列的定向条件,比如投放城市、投放时间段、人群标签、出价等。


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


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


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


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


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


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


image.png


由于广告主->平台->受众,平台在为广告主和受众提供更好的服务和用户体验性,同时在追求更好的广告效果,需要各个系统之间的系统运转,保证整个平台的流畅性。
广告平台技术挑战对广告业务有了初步了解后,再来看下广告系统面临的技术挑战:

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

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

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

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

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

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



image.png


计费平台的方案计费平台也是一个核心系统,主要完成实时扣费功能。比如CPC结算方式下,广告主设置的预算是50元,每次点击扣1元,当扣费金额达到预算时,需要将广告及时下线。除此之外,计费平台还需要支持CPM、CPT等多种结算方式,以及支持反作弊、余额撞线处理、扣费订单的摊销和对账等功能。计费平台的特点是:并发高、数据量大、同时可用性要求高,需要做到不少扣,不重复扣。下面以CPC实时点击扣费为例,详细说下技术方案。


image.png


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

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

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

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


image.png


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

  • 源数据层:对应各种源数据,包括HDFS中实时采集的前后端日志,增量或者全量同步的MySQL业务数据表。
  • 数据仓库层:包含维度表和事实表,通常是对源数据进行清洗后的数据宽表,比如行为日志表、推广宽表、用户宽表等。
  • 数据集市层:对数据进行轻粒度的汇总表,比如广告效果表、用户行为的全链路表、用户群分析表等。
  • 数据应用层:上层应用场景直接使用的数据表,包括多维分析生成的各种收入报表、Spark任务产出的算法模型特征和画像数据等。

采用这样的分层结构,和软件分层思想类似,提高了数据的维护性和复用性再来看应用层报表部分面临的挑战:聚合维度多,需要分时、分广告位、分推广等几十个维度;单表最大达到百亿级别;支持时间范围的实时查询。这部分由公司的大数据部门维护,采用了开源的技术方案,离线部分使用Kylin,数据存储在HBase中;实时部分使用Flink和Spark Streaming,数据存储在Druid中。


image.png


  • 对于平台而讲,在确定需求后,首先需要明确自己的发展模式,更具模式,确定系统,从而明确各个系统的功能、协同性、以及各个系统的压力点。进行倒推,确定平台系统的架构和技术方案。
  • 好的系统架构,需要以系统的可用性为基础,进行系统升级和拓展。
  • 对于互联网广告业务来讲:好的产品往往带来革命性的变革,这个社会缺乏沉淀和创意。优秀的产品思路决定着广告行业的风向。
  • 小问题:百度为何衰落的呢?是电商的冲击还是微信的崛起呢?
相关实践学习
简单用户画像分析
本场景主要介绍基于海量日志数据进行简单用户画像分析为背景,如何通过使用DataWorks完成数据采集 、加工数据、配置数据质量监控和数据可视化展现等任务。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
1月前
|
监控 API 持续交付
构建高效可扩展的微服务架构:后端工程师的挑战与机遇
【4月更文挑战第10天】随着数字化转型的加速,微服务架构已成为企业开发云原生应用的首选模式。本文将深入探讨微服务的核心概念、优势以及在设计和实施过程中遇到的挑战。我们将提供实用的策略和最佳实践,帮助后端工程师构建出既高效又可扩展的微服务系统,同时确保系统的健壮性和可维护性。文章将重点讨论如何通过容器化、服务网格、API 网关等技术手段,优化微服务的性能和可靠性,并分享实际案例分析。
17 0
|
12月前
|
存储 Cloud Native 搜索推荐
「微服务架构」亚马逊引领其自有微服务架构的原因
「微服务架构」亚马逊引领其自有微服务架构的原因
|
存储 弹性计算 监控
小需求背后的大智慧,揭秘亚马逊云科技事件驱动型架构
近二三十年来,软件开发领域毫无疑问是发展最为迅速的行业之一。 在上个世纪九十年代,世界上市值最高的公司大多是资源类或者重工业类的公司,例如埃克森美孚或者通用汽车,而现在市值最高的公司中,纯粹的软件公司谷歌微软位列前五,而排名第一的苹果公司也有相当部分是软件业务。 现在每个企业机构无一例外地都在利用软件优化自己的业务,因此也造就了软件行业非常多的工作机会,从而也吸引了越来越多的小伙伴进入到软件以及相关的行业中。
|
存储 机器学习/深度学习 人工智能
为何阿里云、亚马逊都要“卷”云计算基础架构?
为何阿里云、亚马逊都要“卷”云计算基础架构?
114 0
|
Java 中间件 Devops
工程师们不断推动下的云服务架构
工程师们不断推动下的云服务架构
工程师们不断推动下的云服务架构
|
SQL 存储 消息中间件
工程师误删了公司生产数据库,如何看待数据安全架构的脆弱性?
工程师误删了公司生产数据库,如何看待数据安全架构的脆弱性?
工程师误删了公司生产数据库,如何看待数据安全架构的脆弱性?
前亚马逊工程师:广告系统架构解密(2)
前亚马逊工程师:广告系统架构解密(2)
215 0
前亚马逊工程师:广告系统架构解密(2)
|
人工智能 搜索推荐 算法
前亚马逊工程师:广告系统架构解密(1)
前亚马逊工程师:广告系统架构解密(1)
213 0
前亚马逊工程师:广告系统架构解密(1)
|
SQL 存储 消息中间件
工程师误删了公司生产数据库,如何看待数据安全架构的脆弱性?
这个事情发生在两年前,是某丰的工程师,根据网上披露的信息,大体情况是这样:首先工程师接到了需求变更的任务工单,需要进行数据库SQL执行操作,并事先准备好了SQL的脚本。接下来通过登陆跳板机就进入到了生产数据库的管理端,然后运行Navicat-MySQL的客户端管理工具。这时候问题出现了,他发现自己选择错了数据库,但是SQL脚本已经粘贴上准备执行了,所以他的目的是按delete键删除选定的执行SQL语句,可是万万没想到鼠标光标跳到了数据库实例上面,这时候的delete键就是删除数据库实例了,结果这位工程师还不看弹出框的提醒,直接按了回车键。最后的结果那就是运营监控管控平台挂了!故障持续了10小时
工程师误删了公司生产数据库,如何看待数据安全架构的脆弱性?
|
人工智能 监控 安全
疫情期,APP 崩了怎么办?阿里工程师公开高可用架构笔记 | 开发者必读(158期)
最近“某某 app 崩了”带着广大网友都能领悟的痛频上热搜。网友纷纷呼唤程序员小哥哥快上班,其实疫情期间线上流量激增,很多线上应用都面临着巨大挑战。阿里巴巴在多年 双11 高并发,高可用和高客户体验要求背景下积累了相应的技术体系,并赋能罗辑思维等客户,帮助他们落地全链路压测。本文整理自高用户、突发高流量场景下的真实案例,公布阿里在高可用架构建设过程中的实践笔记,期待帮助更多企业从容应对接下来的高流量场景。