《计算广告学之内容匹配广告&展示广告原理、技术和实践》学习笔记

第1章 内容匹配广告投放技术：网盟概述&工程架构

1.1网盟概述

角色	关注
网站主（Publishers）	用户体验，赚钱
广告主（Advertisers）	投资回报率ROI
网民	有用的信息，良好的体验
网盟（Ad network/Matcher）	赚钱，找到网名和广告的最佳匹配，实现流量价值，平衡各方利益、构建可持续发展的生态圈

1.2网盟广告系统的工程架构

页面特征子系统：爬虫，收集到大量网页，基础服务处理页面，得到页面的特征。页面的主题，分类等

用户特征子系统：

CTR预估子系统：根据过去用户对广告的互动行为的训练，预测以后用户对广告的点击概率。

检索子系统：核心系统

广告特征子系统：

网盟广告检索系统— 数据角度

大计算量：每天100亿+广告检索量和行为采集量，相当于每秒11.5万QPS.且高速增长。

大数据量：分布式离线挖掘。每天P级规模数据入库，T级别特征产出，积累时间大于一年。在线实时特征规模在T级别，Key值数量100亿规模。

高增长率：数据、流量、机器增长规模每年超过50%。

系统机器数量：10000+高性能服务器。

网盟广告检索系统— 指标角度

高实时性：实时更新用户、网页、广告数据。系统100ms内完成实时检索。每秒10W+实时数据入库，生效时间<1s

高容错性：如果每台机器异常概率为0.1%，1W台机器的话，每天都会有10台机器故障。

     实时检索服务：故障实时识别、流量自动切换到正常机器。

     特征存储服务：数据多备份、持久化，重启快速恢复。

     数据推送服务：数据推送状态快速迁移，备机提供服务。

高实验性：数据驱动系统演化，每天并发上百个实验。

高一致性：涉及到钱的问题，张冠李戴会非常麻烦。

高扩展性：数据增长迅速，系统需要支持热机扩容。

高可用性：7*24小时服务稳定，每天100亿次检索，出错影响用户体验。

1.3工程架构解决的技术问题

网盟广告检索系统--技术
产品技术	关键词定向，回头客定向，兴趣定向
应用技术	分层实验框架，用户识别，高性能检索
基础技术	分布式计算（MapReduce），流式计算(Stream)，高性能计算(Hadoop)，KV存储引擎(Redis)，资源定位(ZooKeeper)，消息队列(MQ)

1.3.1用户识别

用户识别技术新动向—— Cookie Matching(Cookie Mapping)

1.3.2分层实验框架：为了支持更多的实验

实验样本要具有可比性

缺点：

     实验容量有限。可用流量只有100%，没有分配到流量的机器需要等待。

     实验和机器强耦合。不同机器部署的实验不同，实验流量变化时需要同时调整机器部署。

     维护代价大。机器部署易购数量和实验数量对应，增加维护难度。

优点：

     实验只消耗部署机器的资源。

     结构简单，实验独占流量，排查问题简单，不存在相互影响。

如何提高实验的并发度？通过分层流量复用。

分层模型：每一层只能选择一个实验命中。层和层之间解耦，相互不影响。

E1和E2共享100%流量用于实验；

E3独享100%流量用于实验。

一份流量可以同时命中E1、E3、E4、E5。

通过给流量打标签，来判断流量命中了哪些实验。

缺点：

     机器物理部署的应用包含所有实验代码，浪费资源，主要是内存。

     存储性资源变成限制实验数量的主因。

优点：

     实验和机器解耦。所有机器都可能命中实验，流量变化时不用调整部署。

     实验数量不受限于流量大小，取决于实验设计。

     实验机器同构，维护、发布简单。

1.3.3高性能检索

1.3.3.1高性能检索的计算模型

核心：Query构造，倒排索引，归并算法，大根堆。

简单的筛选在前面，快速的筛选广告。复杂的计算放在最后，只需要对少量的广告进行计算。=>系统更高效

1.3.3.1高性能检索的网络模型

检索程序是同步模型，计算量大。网络程序异步模型。

慢Query的问题，有同步模型引入。同步模型中慢Query可能把系统拖挂。

慢Query的产生原因：攻击行为，实验引入（流量小，但是实验性能低），服务Bug，网络抖动（机房网络不稳定），机器异常。

慢Query的监控和处理策略：

     慢Query的比例波