本篇文章主要介绍了"大型广告系统架构 — 检索模块"，主要涉及到系统架构,广告系统方面的内容，对于软件工程感兴趣的同学可以参考一下：
广告系统主要解决一个问题：在给定展示场景、用户的情况下，返回收益最大化的广告。下图是一个广告系统最简单的架构图。其中，Router，检索模块，排序模块一般称为广...
广告系统主要解决一个问题：在给定展示场景、用户的情况下，返回收益最大化的广告。下图是一个广告系统最简单的架构图。其中，Router，检索模块，排序模块一般称为广告系统的核心。同时，与之辅助的至少包含三大系统：特征计算系统，计费系统，投放系统。
先介绍一下三个辅助系统的主要功能：
特征计算系统：实时计算广告展示环境 (网页，APP) 的特征，用户的特征。并提供实时查询功能。
计费系统：实时处理广告的展现 (CPM)、点击 (CPC)、转化 (CPA)数据，并计算广告的剩余预算。需要包括反作弊功能。
投放系统：供广告主使用，设置广告的基本信息和定向条件。
核心部分包含了三个模块：
Router：对外提供HTTP服务。接收请求后，依次与特征计算系统、检索模块、排序模块交互，最后返回广告。
检索模块：检索模块主要解决相关性问题。首先，根据广告主设定的定向条件筛选出本次请求能否返回的广告；然后，按多种定向策略筛选出与本次请求最相关的若干个广告。
排序模块：排序模块主要解决收益最大化的问题。通用的排序标准是eCPM。以CPC广告系统为例，eCPM=eCTR*CPC，CPC是广告主设定的，排序模块的核心就是使预估的eCTR尽可能地接近实际CTR。
本文讨论检索模块的架构设计。在检索模块中使用的数据一般可以分为三类：
广告本身的信息。例如ID，标题，描述，出价，投放时间，预算余额等。
广告的定向数据。例如国家，设备，人群等。
各个定向策略使用的内部数据。例如，预先计算出的各个广告的特征，人群的兴趣点扩充数据等。
同样，讨论架构先说业务特点。
大型广告系统中，单机的瓶颈首先出现在内存上，通常内存的使用率在80%以上，只剩余20%的内存空间实际上是非常危险的，后文中会阐述原因。在使用的内存中，可以假定70%是广告数据，30%是各策略使用的内部数据。
数据的更新量占数据总量的比例很小，一般更新量会比总量少两个数量级。
数据存在热点。例如，一些热门搜索词会被大量广告主购买，一些热门的人群也会被广告主大量购买。
带着这些前提，接下来讨论检索模块的几个主要问题。
检索模块在提供服务前，需要将最新的广告数据和策略数据加载到内存中。假定检索模块使用的是内存为64G的机器，按内存使用率80%计算，系统启动的时候需要把50G的数据加载到内存，可以想象这是一个耗时很长的操作。另外，广告系统一般都包含正排索引和倒排索引两种数据，倒排索引是根据正排索引建立的，所以系统启动的时候不仅仅是加载数据，还存在计算的过程，当然，在不存在指针的情况下，倒排索引也可以预先计算好，可以减少启动时间。
