大型广告系统架构 — 检索模块

Posted TigerMee

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了大型广告系统架构 — 检索模块相关的知识,希望对你有一定的参考价值。

广告系统主要解决一个问题:在给定展示场景、用户的情况下,返回收益最大化的广告。下图是一个广告系统最简单的架构图。其中,Router,检索模块,排序模块一般称为广告系统的核心。同时,与之辅助的至少包含三大系统:特征计算系统,计费系统,投放系统。



先介绍一下三个辅助系统的主要功能:

  • 特征计算系统:实时计算广告展示环境 (网页,APP) 的特征,用户的特征。并提供实时查询功能。

  • 计费系统:实时处理广告的展现 (CPM)、点击 (CPC)、转化 (CPA)数据,并计算广告的剩余预算。需要包括反作弊功能。

  • 投放系统:供广告主使用,设置广告的基本信息和定向条件。


核心部分包含了三个模块:

  • Router:对外提供HTTP服务。接收请求后,依次与特征计算系统、检索模块、排序模块交互,最后返回广告。

  • 检索模块:检索模块主要解决相关性问题。首先,根据广告主设定的定向条件筛选出本次请求能否返回的广告;然后,按多种定向策略筛选出与本次请求最相关的若干个广告。

  • 排序模块:排序模块主要解决收益最大化的问题。通用的排序标准是eCPM。以CPC广告系统为例,eCPM=eCTR*CPC,CPC是广告主设定的,排序模块的核心就是使预估的eCTR尽可能地接近实际CTR。




本文讨论检索模块的架构设计。在检索模块中使用的数据一般可以分为三类:

  1. 广告本身的信息。例如ID,标题,描述,出价,投放时间,预算余额等。

  2. 广告的定向数据。例如国家,设备,人群等。

  3. 各个定向策略使用的内部数据。例如,预先计算出的各个广告的特征,人群的兴趣点扩充数据等。


同样,讨论架构先说业务特点。

  1. 大型广告系统中,单机的瓶颈首先出现在内存上,通常内存的使用率在80%以上,只剩余20%的内存空间实际上是非常危险的,后文中会阐述原因。在使用的内存中,可以假定70%是广告数据,30%是各策略使用的内部数据。

  2. 数据的更新量占数据总量的比例很小,一般更新量会比总量少两个数量级。

  3. 数据存在热点。例如,一些热门搜索词会被大量广告主购买,一些热门的人群也会被广告主大量购买。

带着这些前提,接下来讨论检索模块的几个主要问题。


  • 冷启动

检索模块在提供服务前,需要将最新的广告数据和策略数据加载到内存中。假定检索模块使用的是内存为64G的机器,按内存使用率80%计算,系统启动的时候需要把50G的数据加载到内存,可以想象这是一个耗时很长的操作。另外,广告系统一般都包含正排索引和倒排索引两种数据,倒排索引是根据正排索引建立的,所以系统启动的时候不仅仅是加载数据,还存在计算的过程,当然,在不存在指针的情况下,倒排索引也可以预先计算好,可以减少启动时间。


全量与增量。因为广告数据是实时在变化的,所以一般的方案是定期对数据库做快照,并记录下时间点。系统启动时,加载最新的一个快照的数据,并且加载完所有该快照生成时间之后的所有更新,才可以对外提供服务。快照一般称为全量,更新一般称为增量。另外,这里说的时间,不一定是真实的时间,也可以是逻辑时间。例如,创建一个高可用服务,对外提供始终自增的id,每一条数据更新都关联一个唯一的id,做快照的时候,快照的id就是最新一条记录的id。


预生成索引文件。数据库的快照一般是以文本文件的形式存储的。但是,系统在启动的时候处理文本文件,是非常耗时的。所以一般会使用一台单独的机器预先加载快照文件,将数据转换为与检索模块相同的二进制的格式,再dump到二进制文件中,这样检索模块启动的时候直接加载二进制文件,可以达到很好的性能。注意,为了提高加载数据的效率,二进制数据往往没有经过任何序列化,因此建立索引的服务必须使用和检索模块同样的操作系统和配置。


  • 内存数据结构设计

检索模块使用的数据结构必须具备两个特性:高效存储,高效更新。


高效存储是指如何使用尽可能小的内存空间存储给定的数据。因此工程师需要对内存进行精确的控制(内存中的数据排列,分配和释放),这也是为什么大多数对内存要求严格的系统都使用C/C++开发的原因(无意引起语言之争)。位操作在检索模块中很常见,同时在设计结构体时,要充分考虑数据对齐(可参考的资料很多,这里不展开)。下面重点介绍两种常见的技术。


MemoryPool

MemoryPool是C++中常用的内存分配技术。大的对象或数组往往是分配在堆上,系统中时刻都有不同的对象被创建和销毁,如果每次都使用 malloc/free 去创建/销毁对象,则容易造成内存碎片。MemoryPool的作用是,为常见的对象批量申请内存并预留,在系统需要创建对象的时候,从预留的内存中选择一块空间,作为新的对象,供系统初始化和使用。在销毁对象时,并没有实际销毁这段内存空间,而是将该空间记录在MemoryPool内部的列表中 (freelist),在下次分配空间的时候优先从该列表分配。


常见的MemoryPool提供Create和Destroy两个方法。

  • Create即创建一个对象,如果MemoryPool中有预留的空间,则在预留的空间上分配,否则批量向系统申请空间。为了提供效率,Create方法常常返回指针而不是ID,因此MemoryPool不能移动其内部已经分配的空间。在Create方法返回后,常见的是使用Placement Constructor初始化对象。

  • Destroy方法接受指针作为参数,该指针指向的内存地址必须是MemoryPool分配的。Destroy方法可以调用对象的析构函数,然后将该指针加入到freelist。


以上讨论的是固定长度的MemoryPool,一般一个结构体对应一个MemoryPool。还有另一种可以存储多种长度的对象的MemoryPool,在实际使用中比较少见,想了解这方面的设计可以参考TCMalloc。


B+树

B树及其变种是数据库常用的数据结构。在内存-磁盘式数据库中,类B树的数据结构允许系统只将一部分节点加载到内存;在全内存数据库中,类B树的数据结构允许系统只将一部分节点的数据放入CPU的缓存中。类B树的数据主要有以下几个优点:

  1. 数据的插入和删除性能相对稳定。

  2. 在内存不足时,允许只将用户查询的索引数据全部或部分放入内存,提高查询效率

  3. 在执行新增和删除操作是,只需要修改很少的节点(修改次数与Fanout有关)

  4. locality性比较好,尤其在系统存在热点数据的情况下更为明显。


实际使用中,B+树是比B树更好的选择。B+树相比B树,主要有两个优点:

  1. 索引和数据相分离,内部节点只保存索引数据。内存中相同大小的内部节点,B+树可以存储更多的索引。

  2. 叶子节点存储了全部的数据,并且叶子节点通过指针关联,可以方便地按顺序遍历全部或者部分数据。


B+树在使用过程中最常见的问题是,往往由于使用方式的不当,导致节点没有被填满,导致巨大的内存浪费。


在实际实现中,B+树的节点往往会根据Fanout预留全部的内存空间。以插入数据为例,在节点发生分裂时,分裂后的两个节点都会有一定的空间未被使用,如果没有合理地选择插入数据的顺序,会造成大量的节点未被充分使用。


例如,我们要将1到10十个数字插入到一颗空的B+树种,如果顺序插入,会得到如下的结果:



如果我们熟悉B+树的分裂策略,再稍微仔细的计算一下插入顺序,会得到不同的结果:



可以看到,顺序插入使用了导致B+树生成了八个节点,打乱一下次序只需要七个节点即可。不要小看这一个节点,当Fanout很大时,会节省非常可观的内存。笔者曾经通过优化B+树的内部组织,为单机节省了7G的内存。


细心的读者可以发现,在已知全部数据的情况下,是可以计算出插入B+树的最优方案的。前文提过,广告系统的数据更新量相比全量会少两个数量级,因此系统启动结束之后,内存的布局基本也就固定了,另外系统会随着上线被频繁重启,因此,解决了系统启动时候B+树的内存布局,也就解决了大部分问题。B+树的最优插入方案留给读者去思考。


  • 数据更新

广告的数据和策略使用的数据都需要更新,但特点不同。广告数据对实时性要求非常高,广告主期望在秒级更新,但一天的更新量可能只占全量的1%不到。策略使用的数据往往需要通过大量的离线计算才能生成,往往几个小时甚至一天才需要更新一次,但更新的量很大,可能大部分数据都需要被更新。


增量更新 (INC)

广告数据对实时性要求高,因此一般采用增量更新的方案。回想本文开始的检索端架构图,投放系统和计费系统将广告数据更新到DB,同时发送给Message Queue,MQ中的每条数据都带着一个表示逻辑时间的ID。在各个检索模块的服务器上部署一个单独的服务从MQ订阅数据,该服务在接收到数据后,将数据以文件的形式持久化到磁盘。检索模块中有一个线程,定期从文件中读取更新的增量数据,并更新到内存中。


难点在于,检索模块在数据更新的同时,还需要继续提供服务,不能出现因为更新数据而锁住数据的情况。回想前文所说的,为了提高效率,系统中的数据都使用MemoryPool存储,MemoryPool对外暴露的都是指针,在一次请求过程中基本都在通过指针读取数据,很少有Copy数据的情况。因此,不能修改当前正在检索的数据。


这里一般使用Copy-On-Write的更新策略。即,同一个Key关联的数据有多个版本,在更新数据时,不更新原始的数据,而是Copy一份原有数据,并在此基础上最修改,新的数据比原有数据的版本号更大。在更新的过程中,老版本的数据依然可用;在下次查询中,返回的是最新版本的数据,同时在合适的时机删除老版本的数据。事实上,这个策略在目前的NoSQL系统中普遍存在。


Copy-On-Write的难点在于,如果保证Copy的数据尽量的小,最好只Copy更新的那个数据(实际上很难实现)。结合上文,读者可以考虑如何实现一个支持多版本数据的B+树,并且在Copy的时候尽可能少地Copy节点。


全量更新 (Reload)

策略数据对实时性要求不高,但更新的数量可能会很大,一般会使用Reload的方式进行更新。Reload更新最典型的方案是双Buffer切换。即,将新的数据全部导入到一个新的数据对象(Hash表)中,导入完毕后,使用新的对象替代老的对象。


Reload方法更新的数据,最大的好处是可以假定内存中的数据结构是只读的,不会出现增量更新方式中对数据结构进行插入和删除的操作。因此,可以使用一些更加简单高效的数据结构。


如果使用双Buffer切换的方式进行Reload数据,需要注意在更新的过程中,该数据的内存使用量会翻倍;如果多份数据同时进行Reload,会导致内存使用突然激增,甚至会超出系统极限,导致程序崩溃。这样的案例在生产环境中真实的出现过,虽然系统会自动重启,但如果大量机器同时触发这个情况,会出现非常危险的雪崩效应。这也是前文提到的,系统的内存使用量在80%以上,其实是有很大的风险的原因。因此,在多份数据都使用Reload的方案更新时,要注意好控制内存的使用,通过一些机制避免多个任务并行。


作为大型广告系统的核心,检索模块面临的问题非常复杂,实际的架构设计要紧密结合业务进行展开。没有统一的方案,只有不同的权衡妥协。本文重点讨论了检索模块一些常见的问题和解决方案,其中有很多细节留给读者思考。




关注我的公众号架构丛谈 最朴素地谈架构


以上是关于大型广告系统架构 — 检索模块的主要内容,如果未能解决你的问题,请参考以下文章

大型广告系统架构概述

大型广告系统架构概述

大型广告系统架构概述

大型广告系统架构概述

query-搜索推荐----架构

[Spring cloud 一步步实现广告系统] 业务架构分析