广告、增值服务、佣金是互联网公司最常见的三种盈利方式。在三大经典中，广告的市场份额最大，几乎是大多数互联网平台的主要收入渠道。商业的重要性不言而喻。从技术角度来看，广告业务涉及AI算法、大数据处理、搜索引擎、高性能高可用工程架构等多个方向，也具有良好的技术诉求。从去年开始接触广告业务，到现在快一年了。本文将结合我的个人经验，参考业内优秀案例，对广告系统的架构实践进行讲解，希望能让大家有所收获。内容包括以下3个部分：广告业务介绍面临的技术挑战广告系统架构详解01广告业务介绍广告可以说是无处不在。微信、抖音、哔哩哔哩、百度、淘宝等等，这些占据用户时间最长的APP，随处可见广告的影子。我们每天随处可见的广告背后的商业逻辑是什么？在分享广告系统的架构之前，先给大家快速科普一下业务知识。1、广告业务的核心点是平衡。为什么广告业务的核心点是“平衡”？从广告的标准定义上就可以理解。广告是指广告主通过互联网平台以有偿方式向用户传播产品或服务信息的一种方式。这个定义涉及三个主体：广告主、平台和用户，但这三个主体有着不同的利益和关注点。图1：广告业务的三角平衡广告主：关注ROI，花钱是否能带来预期收益使用？有时三者的利益会发生冲突。比如平台增加广告位，收入肯定会增加，但用户体验可能会变差。因此，广告业务最终需要在三者之间找到平衡点。从平台的角度看广告业务，在保证用户体验的同时，必须考虑到大部分广告主的ROI（保证他们能赚钱），然后再考虑在此基础上实现平台收益最大化，这是一个健康的广告生态。2、从收入分解公式中认清广告的本质。广告业务发展了几十年，结算广告费用的方式有很多种。最常见的有：CPT：按时间计费，独占包时隙包位置CPM：按千次展示计费CPC：按点击计费CPA：按行为计费（如下载、注册等）图2：广告费结算方式的演变之所以会出现不同的结算方式，其实是随着广告市场的发展，逐渐衍生出来的。一开始，流量稀缺，平台主导。如今逐渐成为买方市场，广告主作为需求方的议价能力增强。从上图可以看出，由于CPA代表了广告主最终想要的转化效果，所以按照CPA结算对广告主最有利，但对平台最不利。结算方式演化到今天其实是一种平衡，所以在平衡点附近的CPM和CPC是最常见的结算方式。以CPC为例，收入可以分解为如下公式：其中PV代表系统流量，PVR和ASN代表广告填充率，CTR代表广告点击率，ACP代表广告的平均点击价格。上述每一项指标都可以通过一系列的广告策略得到改善。比如填充率可以通过开发更多的广告主来实现，CTR可以通过AI算法精准投放来提升，ACP可以通过精准的流量溢价或者增加广告主的ROI来实现。掌握上面的收??入分解公式对于理解广告业务至关重要，几乎任何业务行为都可以与这个公式的某个指标相关联。3、广告的核心业务流程广告业务发展到今天，随着广告主对投放效果的要求不断提高，精准投放和实时竞价是目前最为主流的业务形式。对于互联网平台，前期一般采用“自营竞价广告网络”实现商业变现。简单理解：就是利用平台自有流量和自研广告主，实现业务闭环。本文分享的广告架构主要针对这种业务形态，其核心业务流程如下图所示。图3：广告核心业务流程广告主首先通过投放平台发布广告，可以设置投放城市、投放时间段、人群标签、出价等一系列定向条件。完成后，该广告将存入广告库，同时进入索引库，以便广告搜索引擎调取。C端请求后，广告引擎会完成召回、算法策略、竞价排名等一系列逻辑，最终选出TopN条广告，实现千人千面广告。用户点击广告后，会触发广告扣费流程，平台才能真正获得收益。以上就是广告业务的核心流程。随着平台流量和广告主规模的进一步提升，往往会逐渐从“自营竞价网络”发展为“联盟广告、RTB实时竞价”，类似阿里妈妈、腾讯广告。对于点通和今日头条的海量引擎来说，此时的业务复杂度和技术架构都会达到一个新的高度。本文就不展开了，后面会详细分享给大家。02面临的技术挑战在对广告业务有了初步的了解之后，再来看广告系统面临的技术挑战：1.高并发：广告引擎与C端流量打通，请求量大（pingfeng经常有几万的QPS）。实时响应，几十毫秒内返回结果。2、业务逻辑复杂：一个广告请求涉及多渠道召回、算法模型打分、竞价排序等业务流程复杂，策略多，执行环节长。3、稳定性要求高：广告系统直接与营收挂钩，广告引擎、计费平台等核心系统稳定性要求高，易用性至少要三九。4、大数据存储与计算：随着业务的发展，促销和扣单的数量很容易达到数千万甚至数亿。此外，收入报表聚合维度较多，单份报表可能达到数百亿条记录。5、账目准确：广告扣账是一项财务操作，需要防止丢失或重复，否则会损害某一方的利益。此外，如果营收数据不准确，也可能影响经营决策。03广告系统架构详解在了解了广告业务的目标和技术挑战之后，接下来就是详细介绍广告系统的整体架构和技术方案。图4：广告系统整体结构以上是我公司目前广告系统的结构图。这种结构适用于广告业务的起步阶段。以“自营竞价网络和站点流量”为目标，不涉及联盟广告。各子系统说明如下：广告投放系统：面向广告主，核心功能包括会员续费、广告库管理、设置推广条件、设置广告竞价、查看投放效果等广告运营后台：用于产品运营该平台的核心功能包括广告位管理、广告策略管理和各种运营工具。广告检索平台：承接C端高并发请求，负责从海量广告库中筛选出数条或数十条广告，实时性要求高。这个平台通常由多个微服务组成。AB实验平台：广告业务的稳定器，任何广告策略调整都可以通过该平台进行灰度实验，观察收益指标的变化。广告计费平台：面向C端，负责实时扣费，与收入直接挂钩，易用性要求高。账户管理中心：广告业务中的财务系统，管理与金额相关的业务，包括充值、冻结、扣费等。大数据平台：整个广告系统的底盘，需要聚合各种异构数据源，完成离线和实时的数据分析统计，生成业务报表，产生模型特征等。下面介绍一下架构中的技术困难。1、广告数据的存储广告系统需要存储多种不同特性的数据，并采用多模式的数据存储方式。图5：广告数据多模式存储的OLTP场景，包括广告库、创意库、会员库、广告产品库、广告策略库等，均存储在MySQL中。数据规模大的广告库和创意库，根据AdvertiserIDHash做分库分表。OLAP场景涉及到的报表很多，聚合维度也很多。单张表的记录数可能达到数百亿条。底层使用HDFS和HBase进行存储。广告检索场景的索引数据，包括正向索引和倒排索引，使用Redis和ES存储。另一个存储需要解决的问题是：广告的同步问题。广告投放后，首先会存储在MySQL数据库中，然后需要将广告实时传输到检索系统，完成正向索引和倒排索引的更新。图6：广告指数的更新流程指数更新服务有几个重点需要说明：当各业务系统发生促销、余额等信息变化时，发送MQ消息，指数更新服务订阅MQ感知变化，完成增量同步。在变化的消息体中，不传输实际变化的字段，只通知变化的广告ID，索引更新服务实时读取最新数据完成更新，可以有效解决由变化引起的数据不一致问题消息乱序。当更新索引的并发度达到一定水平时，可以通过合并同一广告的变化，或者前后分离的方式来提高整体的更新速度。2.广告检索平台整体流程广告检索平台负责承担C端的流量请求，从海量广告库中筛选出最合适的TopN个广告，并在几十毫秒内返回结果。它是一个多层次筛选和排序的过程。图7：广告检索平台整体流程。Recall层关注算法模型，Search层关注业务。从下到上，计算复杂度逐层递增，候选集逐层递减。（注：搜索广告场景和推荐广告场景在部分子模块上存在差异，但整体流程基本相同，这里不再赘述）性能设计是检索平台的重点，而通常有以下几种方式：可以横向缩放。Redis缓存用于避免高并发请求直接打到数据库，可以根据业务规划分布多组缓存。使用多线程并行化某些子流程，例如多路召回逻辑和多模型评分逻辑。热点数据缓存在本地，如广告位配置信息、策略配置信息等，可以在服务启动时在本地预加载，然后定时同步。非核心进程设置超时熔断遵循降级逻辑，如溢价策略（不溢价只是利润少，不影响广告召回）。与主流程无关的逻辑异步执行，如推演信息缓存、召回结果缓存等。简化RPC返回结果或Redis缓存对象的结构，去除不需要的字段，减小IO包的大小。GC优化，包括JVM堆内存设置、垃圾收集器选择、GC频率优化和GC耗时优化。3、计费平台技术方案计费平台也是一个核心系统，主要完成实时扣费功能。比如CPC结算方式下，广告主设置的预算是50元，每点击一次扣1元。当扣减金额达到预算时，需要及时下线广告。此外，计费平台还需要支持CPM、CPT等结算方式，以及支持反作弊、余额行处理、摊销和扣单对账等。计费平台的特点是：高并发，数据量大，同时可用性要求高，所以需要做很多的推导，不能重复推导。下面以CPC实时点击扣费为例，详细介绍技术方案。图8：CPC实时扣费流程首先，整个扣费过程是异步处理的。当收到实时扣费请求时，系统首先将用于扣费的信息缓存在Redis中，然后发送MQ消息。这两个步骤完成后，推演动作就结束了。这样做的好处是可以保证推演接口的性能，同时利用MQ可靠的传递和重试机制保证整个推演过程的最终一致性。为了提高可用性，针对Redis和MQ不可用的情况，采用了降级方案。当Redis不可用时，切换到TiKV进行持久化；当MQ下发失败时，改用线程池进行异步处理。此外，每次有效点击都需要生成扣单，面临数据存储量大的问题。目前使用的是MySQL分库分表，后期会考虑使用HBase等分布式存储。另外，为了订单和账务系统的数据一致性，通过大数据平台进行日级增量抽取，通过Hive任务完成对账和监控。4、OLAP海量数据报表技术解决方案数据报表也是广告平台的核心业务。它是广告商和平台运营商优化投放和进行商业决策的依据。我们先来看看广告数据仓库的层次结构：图9：广告数据仓库的层次结构源数据层：对应各种源数据，包括实时采集到HDFS的前后端日志，MySQL业务数据表增量或全量同步。数据仓库层：包含维度表和事实表，通常是源数据清洗后的宽数据表，如行为日志表、促销宽表、用户宽表等。数据集市层：数据的轻粒度汇总表，如广告效果表、用户行为全链路表、用户群体分析表等。Spark任务等采用这样的层次结构，类似于软件分层的思想，提高了数据的可维护性和复用性。再看应用层报表面临的挑战：聚合维度多，需要分时、广告位、推广等几十个维度；单表最高可达百亿级别；支持时间范围的实时查询。该部分由公司大数据部门维护，采用开源技术方案。离线部分使用Kylin，数据存储在HBase；实时部分使用Flink和SparkStreaming，数据存储在Druid中。写在最后这篇文章详细介绍了广告系统的初始架构和核心技术方案。随着业务的发展，架构会越来越复杂，但大数据存储、高并发、高可用一直是广告业务的技术难点。关于广告系统的稳定性保障、广告策略的可扩展性设计、RTB实时竞价的系统架构等有价值的内容，稍后再与大家分享。欢迎关注我的公众号。关于本文，如果大家有什么问题或者建议，可以留言讨论。本文转载自微信公众号“IT人的职场进阶”，可通过以下二维码关注。转载本文请联系ITProfessionalWorkplaceAdvancement公众号。
