广告是许多互联网公司的主要营收手段，百度的搜索广告，阿里的电商广告，微信的信息流广告和公众号内广告，头条的信息流广告等。今天分享的主题就是广告系统架构的基本概括。下面是一个比较简易的广告系统架构图，从这个图中我们可以看到广告系统各个模块之间的流程关系， 我画的这个图比较简单，但是实际上整个庞大的广告系统来说是非常复杂的。
图 1 广告系统简易架构图
广告商业平台是提供给广告主创建广告的前端页面，广告主可以自主上传广告素材和设定定向条件。素材类型可以是视频 文字 图片等，定向条件可以是地区 性别 兴趣爱好等。每个广告主可以创建多个广告组，每个广告组包含多个广告计划，每个广告计划可以有多个广告创意。一个广告组可以是为了某一相同推广目的设定的广告组别，一个广告计划是包含投放定向范围等的一类广告，广告创意定义了具体投放到媒体的展现形式。系统会将这些广告信息和定向信息加载到线上存储器，供接下来投放到媒体客户端。
我们根据用户的特征匹配广告特征，最终能够决定用户看到什么广告的取决于三个特征，即用户特征，内容特征和环境特征。用户特征即是每个用户身上所具有的标签特性，年龄性别和一些商业属性的关键词，我们可以通过用户平常阅读的内容，喜欢点赞评论的活跃度以及好友关系等，推断抽象出该用户的特征，用一些规则关键词标注之。广告也具有自己的特征，广告的特征包含广告定向条件和从广告中提取的内容特征。环境特征是用户当前所处的环境信息，如天气地理位置时间区间等，用户现在所处的地区可能是常驻地区也可能是旅游临时出差的地区，系统需要根据这些作出判断，最终通过这些特征的匹配计算将广告展示给特定用户。
比如环境特征，我们可以通过三个途径获取用户的地理位置，GPS定位，WIFI或移动信号的位置，用户自主选择的地区。可以根据这些条件来判断用户当前所在位置和常驻位置，以及是否曾经出现过在该地区。我们就可以做到给常驻广州的人推荐一个当地音乐培训职业教育的广告，给来广州旅游的人推荐酒店景点门票的广告。虽然当时获得的用户地区相同，但不同用户在该地区的表现特征不同，所以看到的广告也会不同。
广告内容是预先发送到媒体客户端的，在用户打开app之前，广告就已经通过预加载机制发送到客户端了，当用户浏览app里内容时，不断向下滑动将会不间断的看到一条条广告。预先加载被称为send事件，用户看到广告称之show事件，用户点击广告称为click事件，用户在下载了广告推广的其他app或在广告落地页填写了个人信息称为convert事件。从send 到 convert 的系列事件遵循漏斗模型。在竞价广告中，广告的计费采用二价策略，在竞争中胜出的广告，只会比第二位的广告单价多0.01元，这样可防止广告主定价过来带来的风险损失。
广告的每一次事件都会产生一条日志发送到后端系统，每条回传日志都包含用户信息，广告信息，环境信息，流量位信息等，具体的便是用户id，广告id，用户标签，地理位置，广告在app里的位置等。一条日志可能会包含上百个字段，这些日志会打到kafka，通过spark streaming 处理去重过滤筛选等，分别进入到不同的topic 或 生成hdfs文件等，然后将数据导入到hive，在数据仓库阶段做ETL处理，抽象出维度指标信息，根据不同的业务需求加工成不同的数据格式，供各业务线人员查询。可提供客户端的即席查询也可是以接口形式提供的固定查询。广告主可以在后台查看广告的受众信息，可以看到每条广告的转化率，受众分布等信息，以此来判定投放是否合理，可以据此优化投放策略。用户画像部门可以拿到这些信息去训练更新模型，数据分析师根据这些数据分析总结一些结论。
下面这是一个广告系统的结构图，我把它分了六大模块，每个模块都是一个大团队来做的。投放模块是离用户最近的模块，就是这个模块将广告内容发送到用户app, 回传日志，执行投放策略等，可以把它理解成链接用户和广告的通道。检索模块主要是对广告做了个倒排索引，将广告存入到天池系统，根据一定的规则从系统召回广告并做排序，筛选出排名靠前的广告。商业平台除了刚才说的广告录入功能，还包含财务系统，账号流水，充值系统，代理商系统，线索系统，adx系统，DMP系统等等。
图2 广告系统功能模块图
实时计算涉及到点击服务，反作弊和计费系统等，一次点击会产生回传日志扣费等这样的行为。一些非法的情况下会触发反作弊行为，竞对的恶意点击，黑白名单的限制等，扣费时需要将非法的点击去掉，分析数据的时候也取排除作弊点击后的有效点击。
无论什么系统都需要监控，可以分为业务监控和系统监控，系统监控就是云服务平台上机器性能压力等的监控，如CPU使用率，Mysql主从延迟监控，ES查询超时监控等。业务监控是基于业务场景的监控，如某流量位的收入监控，基础统计数据指标的监控，点击转化率监控等，这些监控可以帮助我们实时有效的发现生产环境的问题，比如某个流量位的收入骤降可能是投放策略出了问题，基础统计的指标不对可能是消费日志的延迟等。
我们每天处理的广告日志有30多T，250亿条左右，要对这些数据做ETL，根据不同业务需求设计不同的计算流程。要保证数据产出的质量和时间，进行数据治理，每天凌晨启动成千上万个例行任务批量的计算数据，对集群的压力也比较大，在资源一定的情况下要保证数据产出的时间，不能延迟，不能丢数，保证数据的一致性和准确性。对数据的产出结果，需要设定数量值的监控，对每天的数据总量，数据平均量，数据的环比波动等都有个监控，以便数据不准时能及时发现。对数据的产出时间也要有足够的监控，防止数据延迟带来的损失，可以通过调整运行参数，启用压缩，设置不同的map reduce数量和切换不同集群的缩短数据产出时间。
数据治理也是做数据工作很重要的一方面，我们在使用数据时候要保证同样字段和值在不同业务方的理解保持一致，做到信息同步，如城市编码变更的话，没有很好的同步信息，投放端和数据处理端对同一编码的理解不一致，会导致用户在后台看到的广告投放地区和实际投放地区不一致。又如客户端回传的日志中没有包含用户信息，这将给后端处理数据带来难度，因此数据治理要保证数据的信息完整性，一致性。
数据可视化是将处理后的数据加载到线上存储器，提供接口供用户查看，可以选用ElasticSearch , Druid，Kylin，Mysql，Clickhouse等作为存储器，用thrift框架写接口提供服务。
除了提供可视化实时的数据看版外，我们同样给运营销售提供查询工具，他们可通过页面选择不同的指标维度，查看销售业绩，系统会将这些筛选条件解析成sql语句，扔到hive上执行，执行结果提供下载链接，这样方便了运营销售自主查询，提高效率。
AB测是优化广告系统的一个重要依据，拿出一部分流量，通过设置不同的策略观察用户表现，对比结果分析，找出最优的策略，用数据说话而不是直觉。举个例子，搜索时将搜索的结果调差一些，会增加用户再次搜索的兴趣，广告的展示点击概率就会上升。同时在线上跑的测试可以达到上百个，根据最终结果，我们会选择ROI最高的那个策略做全量推送。
使用DMP是投放优化的重要手段，它能更好的定向受众群体，提供给客户自主定义规则人群包。定向智能根据一些训练出来的特征定向，但无法更进一步的定义规则，而DMP可以根据特征定义规则，筛选出更符合广告受众的目标群体。比如，一则儿童艺术培训的广告，希望投放给30多岁，男性，有车，常驻地区广州，出现过的地区经常有某某小学，这样的目标群体就需要根据不同的特征组合来筛选，这便是DMP在广告投放中的应用。广告投放的DMP数据可以通过多种渠道获得，有广告主自己提供的DMP，有媒体方自己的DMP，也有第三方数据公司提供的DMP。
数据仓库是数据处理的重要一环，数据仓库对数据做了不同粒度的分层，客户端和数据端约定数据的格式，客户端会将数据打到消息队列，我们将数据消费到hdfs或其他在线存储。随着数据量的增长，维度和指标都不断增多，业务线逐渐增多，根据需求，将数据按照不同方式处理，过滤聚合汇总到不同的表里。在数据仓库的处理流程中，一般分为这样几层，ODS层，DWD层，DWA层，DIM层，APP层等。
ODS层是存放的原始数据，未经处理过的，可以原始日志信息，mysql同步数据等。日志数据是最细粒度的数据，包含每一次操作的明细，我们需要对这些数据做预处理，筛选过滤写UDF处理等，处理后的数据进入到下一层DWD，DWD层的数据相对来说比较干净，过滤掉了一些非法值，或做了一些简单基础的聚合，DWA可以做进一步的聚合，根据定义的维度GROUP BY一下，这一层没有非常明细的数据，只有按照指定为度聚合后的数据，当然数据量也会更少一些。DIM层数据是一些基础枚举数据，如广告属性信息，城市编码信息，销售团队信息等，这里的数据一般很少变更。APP层的数据是根据不同的业务需求划分的，每个特定的需求可能会需要一个或多个APP层的数据表，如对线索数据的分析，对广告受众分布的分析等。我们最终会将处理后的数据加载到 ES, Druid Mysql 或Redis，提供RPC 或 HTTP的接口给外界查询。整个数据仓库的分层和数据处理流程如下图。
图3 数据分层结构示意图
下图是技术栈的应用分类，我把它总共分为四类，计算，存储，服务与框架，监控与报警。计算可以用spark flink等，存储我们一般用es druid hive clickhouse 等在线和离线的存储，服务与框架就是主流的thrift或基于thrift开发的微服务框架，监控报警使用开源的openTSDB等，都是业内比较普遍的技术选型。
图4 技术栈
图5介绍了倒排索引，我们根据数据出现的位置坐索引，比如Tom出现在记录的地 2 ，16行，这样就可以做成Tom 到 2，16 这两个文档的映射，同样对于年龄，比如 35，在记录的第 2 ，3，12，41等行出现，也可以做这样的倒排索引，这样当查询age=35的数据时候，就能根据索引很快的找到对应的文档。倒排索引能很大程度上提高查询的效率，广告系统中广告的检索也是用的倒排索引。
图5 倒排索引
在大数据中广泛的使用列式存储，如图6，列存储中每个字段的数据聚集存储，在查询只需要少数几个字段的时候，能大大减少读取的数据量，查询密集型应用的特点之一就是查询一般只关心少数几个字段，而相对应的，行式存储中每次必须读取整条记录；另外，既然是一个字段的数据聚集存储，那就更容易为这种聚集存储设计更好的压缩/解压算法。在数据仓库应用中，数据压缩可以用小得多的代价换取更大好处。其中包括减少对于存储量的要求；增大数据吞吐量，这相当于减少查询响应时间。
图6 列存储
问：广告太多会降低用户体验，媒体方是如何避免这种情况出现的呢？
答：用户看到的广告是根据广告和用户的匹配度计算出来的，当然机器计算呈现出来的广告并都是用户喜欢的广告，对于这种情况，我们留给了用户自主选择的权利，就是用户可以在每条广告上点击喜欢或不喜欢，如果用户点击不喜欢达到一定次数，便不会出现同类型的广告，或在一定周期内都不会出现任何广告。