写点什么

与收入息息相关,美团外卖广告系统架构解密

  • 2021-11-05
  • 本文字数:4323 字

    阅读完需:约 14 分钟

与收入息息相关,美团外卖广告系统架构解密

前几天无意刷到了 2021 Q2 互联网公司广告的营收榜单,惊讶于广告业务的增长速度和进化能力,也对这背后的技术起了兴趣,支撑如此庞大业务量和数据背后用了什么技术?如何建立起稳定的广告系统架构支撑?中间走过哪些坑,又解决什么难题等等?带着一系列疑问,我们采访到了 ArchSummit 全球架构师峰会的讲师--美团资深技术专家林乐彬,来解答这些问题。此外,他还会在 ArchSummit 深圳 2021 上带来《美团外卖广告系统平台化架构实战》的演讲分享,感兴趣的同学不要错过。

美团广告系统架构探索与实践

 

InfoQ:您可以先给大家简单介绍一下广告系统平台架构的设计思路和构建过程吗?

 

林乐彬:架构是为业务服务的,设计思路就是如何通过合理的架构设计保证业务的快速发展。即相对业务来说,架构保持适度的前瞻性但不能过渡设计。因此我们架构构建的过程,会根据业务发展的阶段特点所制定。

 

我们的广告系统是在 2016 年开始建设的,前期业务试水阶段,我们通过 MVP 方案帮助业务快速拿到收益;之后,随着业务体量的变大,主要体现在 C 端流量和 B 端的供给大幅增加,主要的工作是提升架构可扩展性,解决可能出现的系统瓶颈。在后来,随着新老业务的不断发展,产品需求越来越多,研发人力是有限的,这个时候,我们开展了以提升研发效率为目标的平台化阶段工作。贯穿始终的是稳定性、性能优化、资源利用率提升的不断建设

 

InfoQ:我们在构建如此庞大的广告架构系统时,主要走过哪些坑,又解决了哪些技术痛点?

 

林乐彬:遇到的问题,解决的技术痛点有很多,主要有以下几点:

 

1. 前期的数据同步系统比较简单,广告的更新数据,增量更新采用 B 端直接发送数据到下游服务,而全量更新则复用增量更新的方式更新数据。后面随着业务体量的变大,在扩展性和稳定性都出现了一些问题,比如更新物料多了,积压现象明显等。此外每次服务发版的时候,切换流程都比较繁琐,很容易出问题。后面我们借鉴 ESB 的总线思路,自研了一套流批一体的数据通路平台。

 

2. 为了提升迭代效率,我们开展了平台化项目,在实现中,我们会通过 DAG 的调度框架替代原先程序自身调度逻辑。新的框架带来了便利性同时,由于引入了线程池的调度,性能会有一定的折损。我们通过无锁化调度以及线程模型调优等方案基本保证了与原生的性能持平。此外在某些服务,由于业务逻辑十分复杂,人工很难给出最好的调度关系,因此无法达到最佳的性能,我们基于数据驱动的思想,实现了逻辑调用的自动化方案,从而极大的提升了业务的性能。

 

3. 在算法架构方向,算法的迭代会经过“训练样本构建,模型训练,评估,特征上线,模型推送以及线上推理” 一系列过程,由于各个环节割裂,人工参与度高,以及中间出现大量重复开发,会导致算法迭代实验周期很长,我们通过一站式的算法平台解决了算法迭代的痛点。此外在线推理中,随着模型复杂度增加以及体量变大,性能遇到较大挑战,导致无法正常迭代,我们通过搭建 Workflow 的预估框架,异构计算等方案提升性能,保证算法持续迭代。

 

InfoQ:目前我们广告架构系统比较大的挑战有哪些?

 

林乐彬:说到目前比较大的挑战,首先,我们支持的业务线比较多,包括 feed 流形式的列表广告,针对泛 ka 的展示广告,搜索广告 以及游戏场景的创新广告 等主要产品线,以及对应的 20+ 个细分的业务场景,所有这些业务的引擎架构都收口在我们团队。

 

这些业务场景相互之间逻辑差异很大,由于发展阶段不同,因此业务的诉求也会有很大的差异。如何通过技术能力帮助各自业务快速发展,以及如何通过技术让不同业务线之间相互赋能都是比较大的挑战。

 

其次,算法的日益复杂,以及产品的需求多样化,导致耗时越来越多。而在上游超时一定的情况下,如何通过合理的架构设计与极致的性能优化,从而更好的为业务提供服务也是重中之重。

 

InfoQ:架构构建的过程中,在一些技术方向上我们做过哪些取舍,原因是什么,您可以从技术的角度简单讲解一下吗?

 

林乐彬:快速支撑业务的思路还是技术平台思路。这是我们整体做过一个比较大的取舍,对于这个问题,我的思考是要根据业务的发展阶段来决定,这也是我们架构构建的过程。在业务的早期,规模还比较小,业务希望快速拿到收益,这个时候我们会把有限的人力投入到快速支撑业务上。而当业务发展到了一定的规模,以及业务线逐渐增多的时候,我们会启动技术平台的思路建设,一方面通过技术能力的深入来解决规模化带来的问题,同时也通过平台化的能力提升多个业务线的功能复用度,帮助更多业务线提升迭代效率。

 

此外在一些技术细节上我们也做过一些取舍,这里举一个外卖特色的例子:在广告检索方面,外卖广告有着典型的 LBS 的配送范围限制,因此针对商家的召回场景,因为数量不会特别多,在架构设计的时候,根据业务的特点,在召回阶段我们没有采用传统的正倒排的召回模式,而是采用了上游服务进行商家 LBS 范围筛选,在召回阶段只做非广告商家过滤的方式。

 

InfoQ:在高可靠性和可扩展性的架构中,我们如何处理系统可靠性和可扩展性等问题?

 

林乐彬:可靠性主要在以下两个层面做了一些工作。

 

1. 运营机制层面,我们针对日常,事前(事故发生前),事中(事故发生时候),事后 (事故发生后)等几个阶段分别建立了一套成体系的稳定性建设方案。在“日常”主要是一些基本能力的建设,包括流程规范、性能优化、日常演练等等;在事前做好各种力度监控,保证有错误可以第一时间发现;在事中,做好各种应急方案,如降级,回滚等;在事后,做好事后总结,做到可以举一反三。

 

2. 在具体的落地动作中,映射到架构层面,也做了很多。我这里简单讲一下我们接下来要做的一个事情,智能降级的方案。将我们之前在智能算力沉淀的能力(可以参考我们之前在美团公众号的文章-美团外卖广告智能算力的探索与实践),用到稳定性上面,即如果出现流量突增的时候,可以做到根据流量的价值,不同的流量选择不同的降级方案,从而使在降级过程中,收入损失最小。

 

可扩展性对于广告系统来说,常见的就是两种场景,一种是广告请求,一种是广告更新。前者是读场景,后者是写场景。针对广告请求场景我们的可扩展性设计主要在两个层级上,一个是针对服务,一个是针对逻辑功能。前者主要是通过服务的拆分的方式,即:针对流量,功能,存储进行了拆分。后者逻辑功能部分主要通过平台化中框架和组件的思想来实现解耦以及提升扩展性。针对广告更新,我们主要是通过消息总线的方式来进行双方的解耦,来达到可扩展的效果。

 

不同业务场景带来的架构调整挑战

 

InfoQ:随着业务的发展,每天广告的请求量很大,流量分布时间段也不平均,同时要求低延时响应,我们如何来处理这种高峰值爆发的情况?

 

林乐彬:外卖的业务,有着典型的潮汐效应,每天的流量高峰主要集中在午高峰和晚高峰期间。其实线上的机器数量也是按照高峰期的峰值进行预估的,正常情况是没有问题。但是如果出现活动流量突增的时候,我们的处理原则是减少损失与影响范围,并尽快进行恢复。


具体来说,减少损失指减少单次流量的损失,我们主要的思想是针对这次流量进行降级,我们会从服务,功能,数据,流程 多个维度进行降级。减少影响范围指减少不同流量的相互影响,主要的思想是限流和隔离,其中针对限流,主要依赖公司的限流组件能力,可以实现机器,集群,自定义功能等多维度的限流能力;隔离,主要是通过业务线间的部署隔离进行解决,防止不同业务线间的流量相互影响。此外也会利用公司容器动态扩容的能力,快速扩容,进行快速恢复。

 

InfoQ:如何做到尽量不影响用户体验的情况下,提高广告点击率和收入,减少用户流失?我们通过什么样的技术来处理商家、用户和平台之间的利益平衡,维持广告业务的健康可持续发展?

 

林乐彬:用户、商家、平台三方优化的问题,是广告中的核心问题,我们通常有两个阶段,一是从三个方面分别去做优化,做大蛋糕,例如去优化用户体验、去优化商家的 ROI ,二是通过多目标优化的设计,去合理的平衡三方的收益,例如通过多目标 Rank Socre 优化的方式进行三方收益的合理优化。

 

InfoQ:提到深度学习,目前深度学习技术在美团外卖广告系统架构中还有哪些应用场景,具体实践情况如何?

 

林乐彬:深度学习在美团外卖广告的应用主要可以分成两个方面,一是偏推荐的部分,从召回、粗排、搜索广告里的相关性优化,精排中的 CTR、CVR、客单价预估模型的迭代;二是偏广告机制的部分,例如智能出价、智能创意、深度拍卖模型等等。

国内外广告系统架构的发展

 

InfoQ:前些年 DSP 在国内兴起时很火爆,很多人对 DSP 期待也很高,现在来看并没有达到人们的预期高度,您觉得其中主要的问题是什么?

 

林乐彬:我觉得主要有以下几点原因:

 

1. 出于隐私以及利益等原因,数据不够开放,导致媒体、客户、平台之间的数据割裂,限制各方策略优化空间;

 

2. 媒体更希望将优质的流量优先给自有客户,因此对于 DSP 来说,和媒体的自有广告主竞争的时候,不是绝对的公平;

 

3. DSP 的出现,降低了商家投放门槛,由于 App 的使用偏集中化,因此流量主要集中在头部的一些媒体,因此会导致优质流量竞争十分激烈,从而抬升流量成本。

 

InfoQ:最后聊点别的,我们知道微软、Google 等国外公司在广告领域做了很多创新,有哪些是值得我们国内厂商去学习的吗,我们现在的优势或不足又有哪些?

 

林乐彬:在广告领域,国外几家头部公司做出了很多具有影响力的工作。例如微软在召回粗排中的 DSSM(Deep Structured Semantic Model)和 YouTube DNN 经典双塔 + ANN 范式,Google 精排 Wide & Deep 模型推动了深度学习在推荐广告中的大规模落地,同时 GSP VCG 也已成为了广告竞价机制的标准方式。抛开具体技术细节,国外几家公司从业务实践出发,敢于结合先进技术进行 0 到 1 的开创探险精神是最值得我们去关注的。

 

相比较而言,国内互联网起步较晚,很长一段时间都是一个追随者的角色,但近些年国内互联网业务迅猛发展,产品技术不断创新,在很多技术上已经大有赶超之势。总结来看,国内产品模式的创新,海量的互联网用户,科技人才的涌现已成为国内互联网产品技术进一步发展的最大优势。

采访嘉宾介绍

 

林乐彬,资深美团技术专家,2016 年加入美团,目前是美团外卖广告引擎架构负责人,曾前后任职腾讯、百度,有 10 年以上互联网广告相关经验。

 

在 11 月 12-13 日举办的 ArchSummit 深圳 2021 全球架构师峰会中,林乐彬老师将在【高可用高性能业务架构】中分享“美团外卖广告引擎平台化实践”。除了对广告架构的介绍外,还会通过现状分析、业务场景、落地案例深度解读广告架构实践。更多精彩内容请扫码查看。



关联阅读:

 

Twitter 广告平台实时计费系统的架构增强之道

 

大规模图算法在京东广告的实践

 

如何搭建批流一体大数据分析架构?

 

面向下一代的粗排排序系统 COLD

2021-11-05 15:025515

评论

发布
暂无评论
发现更多内容

TiDB SQL调优实战——索引问题

TiDB 社区干货传送门

性能调优 实践案例

从TiDB中学习代码提交规范的重要性

TiDB 社区干货传送门

TiDB 底层架构

我们为什么放弃 MongoDB 和 MySQL,选择 TiDB

TiDB 社区干货传送门

数据库架构选型

干货分享丨携程国际业务动态实时标签处理平台实践

TiDB 社区干货传送门

实践案例

TiDB 集群跨平台在线迁移方案(离线环境下从 x86 节点迁移到 arm64 节点)

TiDB 社区干货传送门

管理与运维

生产环境 TiDB V5.0.3 集群部署

TiDB 社区干货传送门

实践案例

TiDB for PostgreSQL 学习指南

TiDB 社区干货传送门

实践案例 管理与运维

TiDB K8S 删除备份阻塞问题排查

TiDB 社区干货传送门

TiDB 底层架构 管理与运维

【精选实践】58 集团的数据库技术选型思路

TiDB 社区干货传送门

数据库架构选型

TiDB 入门运维基础教程(二)--生产环境安装

TiDB 社区干货传送门

安装 & 部署

【联合方案】神州信息 - 新一代分布式网贷系统

TiDB 社区干货传送门

实践案例

【TiDB 最佳实践系列】海量 Region 集群调优

TiDB 社区干货传送门

实践案例

使用 TiCDC 实时同步 TiDB 数据到备用逃生环境的实践

TiDB 社区干货传送门

实践案例 安装 & 部署

SQLserver迁移TiDB场景的实践

TiDB 社区干货传送门

迁移 管理与运维

TiDB K8S 定时备份状态异常问题排查

TiDB 社区干货传送门

管理与运维

58同城大规模TiDB运维漫谈

TiDB 社区干货传送门

安装 & 部署

Tidb duration 耗时异常上升案例

TiDB 社区干货传送门

故障排查/诊断

TiDB 对大事务的简单拆分

TiDB 社区干货传送门

性能调优

【SOP 系列 19】region 分布不均问题排查及解决不完全指南

TiDB 社区干货传送门

管理与运维

TiDB5.0.3-ARM平台性能测试

TiDB 社区干货传送门

安装 & 部署

事务前沿研究丨事务测试体系解析

TiDB 社区干货传送门

TiDB 底层架构

TiDB SQL 自动重试调研

TiDB 社区干货传送门

TiDB 底层架构

TiDB集群的GC不回收案例(案情二)

TiDB 社区干货传送门

故障排查/诊断

TIDB:分布式事务算法Percolator学习笔记

TiDB 社区干货传送门

TiDB 底层架构

TiDB 在 2021 易车 818 汽车狂欢节的应用

TiDB 社区干货传送门

实践案例

TiDB和MySQL的锁一些分析比对

TiDB 社区干货传送门

实践案例 TiDB 底层架构

TiDB在X86和ARM混合平台下的离线部署和升级

TiDB 社区干货传送门

安装 & 部署

通过 ProxySQL 在 TiDB 上实现 SQL 的规则化路由

TiDB 社区干货传送门

管理与运维

扩容TIKV节点遇到的坑

TiDB 社区干货传送门

管理与运维

【TiDB CPU使用率过高之一】Scheduler worker CPU

TiDB 社区干货传送门

实践案例

TiDB 配置参数修改与系统变量修改步骤

TiDB 社区干货传送门

实践案例

与收入息息相关,美团外卖广告系统架构解密_架构_辛晓亮_InfoQ精选文章