搜索广告系统结构

搜索广告的系统结构与网页搜索非常类似，包括索引和检索系统，Query的处理流程和文档的排序等，相比网页搜索，搜索广告有以下不同：

• 目标不同，网页搜索主要满足用户的信息需求，搜索广告是在不损害用户体验的前提下最大限度的实现Revenue的最大化。从目标的不同可以看出，满足用户的信息需求更趋于多样化，更难于量化，而搜索广告的目标则单纯的多。

• 文档规模不同，网页搜索的数据非常庞大，索引量的大小会直接影响搜索结果的质量，搜索广告的文档数量要相对少一个量级，所以长尾Query的广告召回是需要重点解决的问题。

• 内容更新方式不同，网页搜索的数据需要搜索引擎主动更新，搜索广告是被动式的，一般是广告主去更新广告的Creative，并且更新量相对较小。

• 排序方式不同，广告的排序不只是考虑相关性，还要加入价格因素和CTR等。

由于以上的不同，搜索广告系统结构在细节上会与网页搜索存在一些区别，例如，索引结构，Query处理等。从整体上来看，我们把系统分为两层，Frontend和Backend，有的商业系统会比这复杂的多，例如会在Frontend前面加上Load Balance和Router，实现负载均衡和流量的分发。

 

接下来我们一步步介绍系统中的每个部分：

Sponsored Search Frontend

搜索广告的前端Server，控制整个Query的处理流程，接收用户输入的Query，调用后台Servers，把处理后的结果返回给终端用户，商业系统通常会用Web Server来处理用户的请求，再通过Web Server调用本地的Frontend Server，目前主流的Web Servers有Apache和Nginx，大部分搜索广告系统都是基于一套完整的系统框架，在框架下实现每个功能模块。接下来介绍每个功能模块：

1.QueryParse Module

Query的原始串是经过UrlEncoding很长的字符串，里面会包含很多参数，广告系统需要首先解析传过来的查询串，转换成系统能够识别的参数值，参数值对应系统这次请求所做的处理流程，做为成熟的商业系统，各个模块都会有不同的配置，QueryParse的目标就是确定所有模块的参数值，一个简单的Query String如下：

q="car rental"&encoding=utf8&lnum=3&rnum=5&mkt=cn&bolding=1

通过QueryParse解析后的各参数值如下：

query的原始串是car rental，用户输入的查询串

encoding的值是utf8指query的编码和当前网页的编码是utf8

lnum代表SERP(搜索引擎结果页)的左面广告数，当前值为3

rnum代表右面的广告数，当前值为5

mkt表示当前查询的市场，比如为cn，这样只有广告主竞价的广告投放在中国市场的才会展示

bolding表示对广告结果是否需要进行bolding处理，更详细的参数可以是加粗/字体/颜色等

以上只是展示了一个简单的例子，成熟的商业系统运行时参数可能会几十成百个。QueryParse是广告系统的第一个Module，也是理解用户查询意图的第一步。

2.QueryPlan Module

经过了第一个QueryParse的处理以后，广告系统已经知道了查询的所有参数，接下来就需要构造广告处理的整个流程，通常在QueryPlan Module还会加入Query的规格化处理，Query的Spelling check等。

Config Reader：

读取相关的配置文件，配置文件包含了后续Module相关的配置信息，QueryParse的结果需要和默认的配置信息进行Merge产生最终的配置结果，这些配置信息决定了当前请求的处理流程，主流的广告系统配置文件都相对很复杂，并进行相应的分层处理，例如：makert配置文件、partner配置文件、site配置文件还有测试用的bucket testing配置等。

Transaction Constructor：

得到处理流程的所有配置信息后，广告系统会初始化需要用到的所有对象，每一个请求都会当做一个完整的Transaction进行处理，系统会维护一个Transaction Pool，避免对象的动态生成，提高处理效率。每个Module会根据当前请求的配置进行初始化，主要包含同步和异步两种类型的Module。

Query Normalizer：

用户输入的Query在进入系统处理之前，需要进行Normalize处理，并进行编码转换，主流系统内部的处理一般是utf8编码，不同语言的Normalizer也会有不同的逻辑，不同的请求需要调用适用于本市场的Normalizer，这也是QueryPlan需要做的工作。主要的Normalize处理包含大小写转换，词形变换，去停用词，词干提取，按字母序排序，中文处理还会包含全角转半角，繁简转换等。

Query Spelling Checker:

原始的Query会包含很多错误的输入，需要先进行Spelling Check处理，把错误的拼写或错误的短语搭配进行纠错，英文的纠错相对容易，线下建立Language Model，计算Term的Uni-gram/Bi-gram/Tri-Gram到N-Gram，加上线下处理好的Query词典/Phrash词典/Term词典，产生候选后计算最小的编辑距离，就能解决大部分问题，中文的纠错还会加入拼音切分，音字转换(解码)，多音字、形近字等处理逻辑。Spelling Check也是搜索引擎和搜索广告系统的标配，工程上的技术都已经很成熟。

3.Query Rewrite

广告系统相对于网页搜索，广告的文档规模有限，长尾Query很难匹配到合适的广告，Query Rewrite是广告匹配中最重要的一环，Query Rewrite的过程隐含了对Query查询意图的分析，目前大部分网页搜索的Query Rewrite技术都可以适用于广告系统，但比网页搜索的准确率要求要高，因为广告主竞价的Bidword，不能和用户输入的Query完全无关，并且也会损害用户的搜索体验。广告系统中的Query Rewrite可以适当的语义宽泛，适当的发散，详细的方法我们准备在单独的文章中讨论。

4.GeoQP

广告主竞价Bidword时，都会指定广告的展示地域，举个简单的例子，美国广告主的不会把广告展示给亚洲的用户，每次竞价和制定的广告都有目标的Geo设定，GeoQP要完成把广告展示给正确的User的处理逻辑，一个用户的当前请求，会包含三个部分的Geo信息：

用户注册的地域信息，广义的注册信息包含Cookie的位置信息，因为搜索引擎并不能拿到用户完整的Profile，但却可以精确定位一个Cookie。

用户IP的位置信息，每个请求都会有IP地址，IP可以转换成详细的地理位置。

用户Query中的位置信息，查询串中也会包含位置信息，比如:"New York Hotel"。

根据上面三种位置信息，GeoQP可以实时计算概率最大的一个做为当前请求的Geo信息，目前，Geo的精度最少需要到城市级别，有的也可精确到经纬度。

5.AdsMatch

Match Driver是整个广告系统中最重要的环节之一，信息检索系统中最重要的两个指标就是召回率和准确率，AdsMatch直接影响广告的召回，召回的过程是通过Bidword或Query Term检索倒排的过程，Query Rewrite的结果间接影响着广告的召回，广告系统中把Match的方式分为两种：Bidword Match和Advanced Match

Bidword Match是广告召回最基本的Match Type，通过广告主竞价的Bidword进行召回，按匹配方式又分为两种：

• Exact Match，只有当用户输入的Query和广告主竞价的Bidword完全匹配时，才会召回创意，生成最终的广告条目。

• Phrase Match，用户输入的Query可以提取主要的Phrase或者是中心词，利用处理后的Phrase或者中心词去匹配广告主竞价的Bidword。

Top Query的匹配可以通过Bidword Match进行召回，得到满足数目的广告，但搜索中存在大量的长尾Query，这就需要另一种Match Type：Advanced Match，这种匹配方式不限于Bidword的方式，主要是利用Query中的Term和广告主的层次关系进行召回。

• Query Term Match，利用网页搜索的方法来实现长尾广告的召回，英文需要进行Chunk处理，中文需要把Query分词，得到Term以后，去检索对应的倒排表，主要可以有三种类型的倒排，广告的Title、Description和Landing Page，有的也会做url的倒排，处理当Query包含Domain Name时候的召回。

• Customer Match，利用广告主竞价广告的层次关系进行召回，当用户输入的Query召回的结果非常少时，可以通过Customer级别的倒排索引召回广告，例如，Query只召回一个创意，可以根据AdGroup或者Campaign召回同一个广告主的类似广告。

6.Ads Ranking

通过Query召回广告以后，需要经过Ranking Module，最终生成广告的Ranking结果，确定广告的展示位置，Ranking的过程经过以下的流程:

Text Relevance，Ranking的基础Feature，文本相关性主要通过计算Query/Bidword/Ads的TF/IDF，BM25F等方法得到最基本的分数，还会加入Term距离，最小滑动窗口等Feature，这些方法都很成熟，各广告系统实现也都差不多。

Sementic Relevance，语义级别的相关性，用的较多的是pLsa和LDA，在Term级别更高一级的Topic上做相关性匹配。

Category Relevance，Query Classification和Ads Classficaion是基础的数据处理，也是匹配过程中非常重要的Feature，类目体系的构建也会影响类目相关性，类目的深层次挖掘可以到达Entity的级别，相关性也会更加精准。

Click Prediction，CTR Prediction是广告相关性中最重要的Feature，广告展示的目的无非是增加用户的点击，常用的方法有Logistic Regression和Maximum Entropy，CTR Prediction中的Cold Start也是比较重要的方法，毕竟新增广告是没有历史点击的。

Click Feedback，历史点击固然重要，但线上的点击反馈也是Click Model需要考虑的问题，实时的Feedback能够及时的调整Click Model。

Price Score，竞拍机制也会影响最终的Revenue，Price也是广告排序的重要指标，有时低CTR高Price也能提高Revenue，应用最多的是GSP竞拍。

Filter Process，广告的展示时间，展示地域需要进行过滤，有的广告主不希望展示广告，当用户搜索某些Query时。

Placement，广告的展示位置和CTR有直接关系，放置的位置和当前的Query和当前的用户都有直接关系，排序后的广告需要放在合适的位置才能在保证用户体验的前提下提高CTR。

7.Result Format

通过系统的处理后，产生出最相关的广告条目，需要在展示给用户前做些最后的处理，主要的包括Bolding和显示格式的处理，Bolding通过加粗或字体颜色等，让用户很明显知道是哪些Term触发了此条广告，Bolding的广告主要分为Token和Substring两种，Token是通过先把广告的文本进行Chunk或分词处理，然后进行匹配，Substring则直接进行字符串的匹配进行Bolding处理。最后的输出格式也是需要考虑的问题，SERP左面和右面的广告格式是不一样的，不同Partner展示的格式也是不一样，有的可能需要Xml格式，有的可能需要Json格式。

8.Other Modules

除了以上这些Modules以外，一个完整的系统还需要很多其他的Modules，包括防恶意点击的AntiSpam，过滤垃圾流量的Traffic Protection，日志跟踪用的Log Module，监控系统的Monitor，此外Billing系统也需要点击信息，需要相应的Module记录点击的Event等。

Sponsored Search Backend

搜索广告的后台Server是广告数据的存储中心，前端Server控制广告的处理流程，后台Server响应前台Server发过来的数据查询请求，返回满足条件的广告条目，由于数据量很大，传统的索引结构都会分行列访问，现在主流的广告系统后台都搭建在云平台，应用云存储解决大数据量的问题。Sponsored Search Backend主要分为Index Server、Inverted Index和Forward Index三部分。

1.Index Server

Index Server是Sponsored Search Backend提供给Frontend Server访问数据的接口，Index Server接收Frontend Server传过来的Query查询，然后调用Query Evaluation Module进行评估，解析需要进行的各种操作，最后调用Inverted Index和Forward Index接口取得满足条件的广告，返回给Frontend Server。

Query Evaluation主要用来评估查询串中所要做的处理，包括过滤条件，比如，投放时间/投放地域/匹配类型等，特征查询，比如，历史CTR大于一定值等。.

Opeartion主要用来调用索引接口，执行解析后的查询条件，如果是分列存储还需要进行Merge操作，返回满足条件的广告。

2.Inverted Index

广告系统中的倒排和传统网页搜索的倒排基本一致，存储结构也是Key对应倒排链表，Inverted Index是索引服务中最重要的结构，按照倒排表Key的类型不同，可以把倒排索引大致分为三种类型：

Bidword相关的倒排：

关键字是Bidword，倒排链表存储的是Created Id，相同Ad Group的Created Id一般都存储在相邻的位置，利于顺序读取，进行广告Item筛选，倒排表中需要存储Bidword和Created Id对应的Features，用于线上Ranking的计算。

Term相关的倒排：

关键字是Chunk处理或分词后的Term，倒排链存储的是Creative Id和对应的Title和Description信息，一般还会存储Term在对应Created中的TF和位置信息及其他文本相关的Features。更广义的倒排还会包含Landing Page的信息，存储Term对应Landing Page分析后的Feature。

Feature相关的倒排：

为了实现高效的过滤，广告系统中一般还会存储特定Feature相关的倒排，例如，投放时间为Key，倒链表数据为相关的Created Id。

3.Forward Index

正排索引中存储的是和Bidword及Term无关的数据，当Index Server根据Inverted Index的数据处理完后，需要返回符合条件的广告时，才会访问正排索引获取相应的数据。正排索引数据主要包括以下几种。

Creative数据，包含Creative的详细信息，包含Title，Description，View Url，Landing Url等。

AdGroup数据，AdGroup级别的信息，比如，价格消耗，广告类目等。

Customer数据，和广告主相关的信息和Feature。

不管是Inverted Index和Forward Index都会涉及数据的更新操作，传统的做法都会保留索引的全量主库，外加实时更新的增量小库，在一定时间内定时进行Merge，然后每天进行一次全量Build，现在大部分广告系统都搭建在云存储之上，可以实现实时的更新，避免了库的合并和切换。

以上内容，是从搜索广告的整体结构做一个简单介绍，现实的商业广告系统要比这复杂的多，接下来我们会继续介绍搜索广告中最重要的几个部分。

 

大家可以加我个人微信号：scccdgf

 

 

或者关注soledede的微信公众号：soledede

微信公众号：