检索技术核心20讲
陈东
奇虎360商业产品事业部资深总监
立即订阅
2355 人已学习
课程目录
已完结 29 讲
0/4登录后,你可以任选4讲全文学习。
课前必学 (2讲)
开篇词 | 学会检索,快人一步!
免费
导读 | 三步走策略,轻松搞定检索!
基础技术篇 (8讲)
01 | 线性结构检索:从数组和链表的原理初窥检索本质
02 | 非线性结构检索:数据频繁变化的情况下,如何高效检索?
03 | 哈希检索:如何根据用户ID快速查询用户信息?
04 | 状态检索:如何快速判断一个用户是否存在?
05 | 倒排索引:如何从海量数据中查询同时带有“极”和“客”的唐诗?
测一测 | 检索算法基础,你掌握了多少?
特别加餐 | 倒排检索加速(一):工业界如何利用跳表、哈希表、位图进行加速?
特别加餐 | 倒排检索加速(二):如何对联合查询进行加速?
进阶实战篇 (13讲)
06 | 数据库检索:如何使用B+树对海量磁盘数据建立索引?
07 | NoSQL检索:为什么日志系统主要用LSM树而非B+树?
08 | 索引构建:搜索引擎如何为万亿级别网站生成索引?
09 | 索引更新:刚发布的文章就能被搜到,这是怎么做到的?
10 | 索引拆分:大规模检索系统如何使用分布式技术加速检索?
11|精准Top K检索:搜索结果是怎么进行打分排序的?
12 | 非精准Top K检索:如何给检索结果的排序过程装上“加速器”?
13 | 空间检索(上):如何用Geohash实现“查找附近的人”功能?
14 | 空间检索(下):“查找最近的加油站”和“查找附近的人”有何不同?
15 | 最近邻检索(上):如何用局部敏感哈希快速过滤相似文章?
16 | 最近邻检索(下):如何用乘积量化实现“拍照识花”功能?
特别加餐 | 高性能检索系统中的设计漫谈
测一测 | 高性能检索系统的实战知识,你掌握了多少?
系统案例篇 (4讲)
17 | 存储系统:从检索技术角度剖析LevelDB的架构设计思想
18 | 搜索引擎:输入搜索词以后,搜索引擎是怎么工作的?
19 | 广告系统:广告引擎如何做到在0.1s内返回广告信息?
20 | 推荐引擎:没有搜索词,“头条”怎么找到你感兴趣的文章?
结束语 (2讲)
结束语 | 成长和进化,技术如此,我们亦如此
免费
结课测试 | 这些检索知识,你都掌握了吗?
检索技术核心20讲
15
15
1.0x
00:00/00:00
登录|注册

19 | 广告系统:广告引擎如何做到在0.1s内返回广告信息?

陈东 2020-05-13
你好,我是陈东。今天我们来讲广告系统。
说到广告系统,很多人可能没有那么熟悉。但是在互联网行业中,广告系统其实是非常重要,并且非常有代表性的一种系统。
一方面是因为,广告是许多互联网公司的重要营收来源。比如,我们熟悉的 Google 和 Facebook,它们的广告收入就占公司总收入的 80% 以上。因此,尽管许多互联网公司的主营业务并不一样,有的是搜索引擎,有的是电商平台,有的是视频平台等等。但是,它们背后都有着相似的广告业务线。
另一方面,互联网广告对于工程和算法有着强烈的依赖。强大的工程和算法让现在的互联网广告能做到千人千面。最常见的,我们在打开网站的一瞬间,广告系统就会通过实时的分析计算,从百万甚至千万的广告候选集中,为我们这一次的广告请求选出专属的广告。而且,整个响应广告请求的处理过程,只需要 0.1 秒就能完成。
那在大型广告系统中,广告的请求量其实非常大,每秒钟可能有几十万甚至上百万次。因此,广告系统是一个典型的高并发低延迟系统。事实上,这背后离不开一个高性能的广告检索引擎的支持。那今天,我们就来聊一聊,广告系统中负责检索功能的广告引擎架构。

广告引擎的整体架构和工作过程

首先,我们来了解两个基本概念。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《检索技术核心20讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • paulhaoyi
    老师,后面会出一篇专门介绍现在索引技术的现状(大厂们放下主流使用的索引技术,例如结合深度学习的一些索引技术,记得看过一篇阿里妈妈的tdm深度学习树索引框架类似的)与展望(比较能代表老师认可的索引发展趋势的前沿索引技术研究)的文章么?作为大家在课外持续学习的引导。

    作者回复: 是否会出相关的文章,需要看大部分读者的诉求和接受程度。
    不过你既然在这里问了,我就先回答你。
    我认为,随着AI的发展,以及数据量的持续增加,检索引擎会往智能化,个性化的方向去发展。基于向量的检索引擎是近期的一个热点。在这方面,其实已经有了许多的开源材料可以让我们去学习。我列出几个供你参考。
    1.Facebook在2017年开源的faiss框架。这是一个高性能的高维向量相似检索和聚类框架。支持多种向量检索算法。我们专栏中介绍的乘积量化的方案也支持。
    2.微软在2019年开源的sptag搜索算法。这是微软的搜索引擎bing使用的向量检索算法。
    3.阿里在2018年开源的tdm算法。这是阿里的推荐系统中使用的向量检索算法。
    这是很有代表性的几个算法和框架。希望对你有帮助。

    2020-05-17
    5
  • 范闲
    有两种思路
    1.直接对用户做标签,如果是标签1只对pc做请求,若果是标签2,只对app做请求。如果是3,就同时做请求,然后合并。这个3的时候会导致请求处理速度下降
    2.增加分叉-即是pc又是app,这样避免了用户标签的速度下降的问题,但是引入了空间上的消耗

    作者回复: 1.有一个思路需要转变一下,搜索引擎中,是文章要满足搜索流量的需要;但是广告引擎中,是流量要满足广告设置的需要。两者正好是相反的。
    因此,当一个广告请求流量进来时,我们只知道这个流量是PC流量或是APP流量,只有两种可能性,没有你说的123三种情况。
    2.增加一个分叉和索引分片是OK的。不过在检索的时候就需要特殊处理。就是如果是PC流量的话,需要同时查询PC索引分片和这个新的综合分片;如果是APP流量的话,也需要同时查询APP索引分片和这个新的综合分片。

    2020-05-14
    1
  • 一步
    对于思考题:
    对于 既在 PC 网站投放,又在 APP 上投放 的广告,在 PC 索引posting list和 APP 索引posting list上都存在不就可以了吗? 这样的话在一个分片上就可以解决了,虽然说会浪费一些空间,但是题目中说了(现实中)这样的广告主是很少量的, 是可以接受的

    作者回复: 是的。可以将相同的数据存在两个分片上。
    毕竟我们从来没有要求索引分片必须完全不重复。索引分片的意义是在于能让我们快速减少检索空间。因此,根据合适的业务,进行合理的索引拆分,这样才是合理的设计。

    2020-05-14
    1
  • 一步
    为什么还要把 区分度低的标签加入过滤列表,再对最后的结果进行遍历呢?
    这里直接使用区分度度高的标签建立倒排索引不就可以了吗? 然后在归并不就可以了吗?

    作者回复: 之所以对于区分度不高的标签要建立过滤机制,是因为我们要满足广告主的投放设置要求。
    比如说,90%的广告设置希望将广告投放给“地域:国内”这个标签,我们觉得这个标签用处不大,没有加入倒排索引的key中,那么如果一个海外流量进来,它并没有“地域:国内”这个标签,如果我们不在最后进行一次标签检查过滤的话,我们就会将广告投在这个海外流量上了。这就违背了广告主的期望。

    2020-05-14
    1
  • 那时刻
    补充回答下老师对于讨论问题的回复,我开始的想法也是在“PC 网站”和“APP”作为两个分叉,各自保存一份数据,这样的会带来数据冗余,对于这样少量的广告主需求问题不大,如果这种需求多了的话,冗余数据量会很大吧?

    另外请教老师一个问题,最近两年广告bidding越来越流行了,不知bidding功能的引入是否对于广告检索有很大结构的上影响呢?

    作者回复: 关于讨论题,的确复制两份是会有冗余,但是如果这部分数据比例不大的话,其实复制数据是更好的设计。而如果同时投两边的比例很大的话,那么实际上,PC网站和APP就没有区分度了,就不应该将这个维度作为树形节点了。

    然后关于bidding的问题,你说的是RTB,real time bidding吧,的确是这样的。rtb就是要求在100ms内返回结果。因此,对于检索效率和精准打分判断要求都很高。这一讲的内容其实是适用的。
    此外,我们还有另一个设计,就是非精准打分+流量分层处理。就是在入口处预判流量的价值,价值不高的直接抛弃。

    2020-05-14
    1
  • w h l
    老师,你好,请教一下Java广告引擎框架和推荐算法框架是用啥?

    作者回复: 首先,并没有非常成熟的一体化的广告引擎框架,或者推荐引擎框架。不过我们在专栏中也说了,无论是广告引擎还是推荐引擎,其实都有着类似的架构,核心都是召回+排序。
    对于候选集的召回问题,我们可以使用elastic search框架来完成;而对于排序问题,其实elastic search自带有简单的排序功能,比如说bm25。如果你想用机器学习来打分排序的话,那么就可以使用TensorFlow框架来完成模型的创建。

    2020-06-23
  • 黄海峰
    这几篇不是很理解召回这个术语是什么意思,是否只搜索引擎从存储里取出网页返回给用户,或是这里的从广告库里取出广告展示给用户,就是取出的意思吗?

    作者回复: 其实召回的意思我觉得挺形象的,就是在一堆的数据中,捞出一批你觉得不错的结果集合。这就是召回了。
    你理解成取出没问题,不过要注意得是从一堆数据中,取出小范围的结果。

    2020-05-13
  • 那时刻
    对于讨论题,我的想法是另外建一个树形索引使用 ”媒体类型“ 作为树形检索节点,“PC 网站”和“APP”作为两个分叉,但是这两个分叉都指向同一个倒排索引,假定这个是粗粒度索引。之前文中提到树形索引是细粒度索引,查找的时候,在细粒度索引里找到结果集之后,然后再和粗粒度索引的结果进行归并。整体想法类似于文中提到的过滤列表方式。

    因为需要与细粒度索引里找到结果集进行合并,所以需要分别加载到不同服务器上效果比较好,因为不同服务器处理的细粒度索引查询请求不同。

    作者回复: 我理解一下,你是不是这样的意思: 再增加一个粗粒度索引(也许叫新的索引分片比较好),这个索引中的广告设置就是“即投放PC网站又投放APP”的。
    然后你指的“两个分叉都指向这个索引”,其实可以理解为再增加一条分叉,这个分叉就代表了“即投放PC网站,又投放APP的”。而它指向的索引分片,就是前面我们构建的索引。
    这样,当PC的广告请求到来时,我们会走两个分叉,一个是“PC网站”的分叉,另一个是“新增加的“即投PC又投APP”的分叉,然后将结果合并。

    这样是OK的,不过你会发现流程改动较大。我们还可以有另一种改法,就是“将即投PC网站,又投APP”的广告设置同时加入到“投PC网站”和“投APP”的两个对应的索引分片中。这样,当PC的广告请求到来时,我们就可以只查询一个索引分片就可以得到正确结果了。
    你会发现,使用复制一份数据的方式,就可以让流程变简单。

    2020-05-13
收起评论
8
返回
顶部