这是彭文华的第110篇原创
以前分享过DMP（数据管理平台）的来龙去脉。DMP是互联网最挣钱的广告系统中的用户基础数据提供方。百度的凤巢、淘宝的直通车（阿里妈妈）还有腾讯的广点通，是老牌三大网络广告投放平台，现在多了一个头条的巨量引擎。
阿里妈妈曾经创造了阿里巴巴80%的现金收入。现在头条系的流量也起来了，巨量引擎给今日头条每年带来超千亿的广告收入！
简单来说，我们在互联网上看到的任何一个广告，再说一遍，是任何一个广告，背后都有一个DSP系统在支持着。
今天就给大家分享一下广告系统核心DSP（Demand Side Platform，广告需求方平台）的架构设计。
DSP是个啥？
DSP就是广告主需求平台，是广告系统中最重要的系统，相当于电商系统中的交易平台一样。只不过呢，DSP是广告主在买展现的机会（广告位），卖家是广告展现位置的拥有者（媒体），商品就是用户的点击了（商机）。简单来说，DSP就是互联网公司用流量变现的超级利器！
互联网广告系统整体是这个样子的：
如图所示，整个广告系统作为平台，一边是广告主，一边是媒体提供的广告位。拥有广告位资源的媒体，通过接入SSP，将广告资源放在供应商平台上；想投放广告的广告主，则在DSP上制定投放计划，寻找投放资源，ADN广告网络和ADX广告交易市场则完成双方需求的匹配和投放。
所以广告系统的需求基本上就能列出来了：
- 要给广告主提供媒体端提供的广告位资源列表
- 要给广告主提供按需购买和展现广告的服务
- 要给广告主提供广告展示和点击的效果
- 要在广告费用用完的时候及时停止展示，同时给双方提供费用清单
DSP数据流应该如何架构？
既然整个广告系统已经摸的差不多了，咱就把DSP放大看看。按照信息系统建设的逻辑，先把DSP的业务流程梳理一下，然后再划分其各项功能，然后就能把数据逻辑和架构整理出来了。
我们先画出业务流程图，以百度推广为例，它的投放流程如下：
广告主在百度凤巢上的流程是这样的：先建立投放计划，计划中会建立投放单元，然后管理创意，选择关键词，对关键词进行竞价（出价），确认后完成投放计划。凤巢就会根据广告主设置的规则，进行广告投放。每当有人搜索一个关键词，就按照规则给他展示；有人点击，就给他计费；最后在广告主的页面上把统计结果展示出来。
既然业务流程弄清楚了，那就可以开始画系统的架构图了。DSP其实囊括了：
- 广告渠道接入能力，对接ADX；
- 用户标签数据接入能力，对接DMP；
- 投放策略管理能力，面向广告主的投放素材的投放策略管理，从需求侧（广告侧）增加点击概率；
- 算法能力，资源的智能匹配，让合适的人在合适的地方和时间看到合适的广告，从供应侧（用户侧）增加点击概率；
- 实时能力，实时监控，动态调整，不浪费一个展现机会，也不多展示一次；
- 统计展现能力，实时计算和统计，能长时间追溯和分析。
上图基本上就是DSP所需要的各项关键能力。底层需要有广告渠道和用户数据对接能力，核心是策略和算法能力，上层得有实时监控和数据统计展示能力。
系统架构有了，咱再画一下数据架构图。先整理一下思路：用户数据有DMP，广告资源有ADX，我们都不用管；算法和策略各自有一帮人负责，一方面那些都属于事务性，另一方面属于算法和策略方面，咱数据组也不用管，只需要考虑实时监测和数据统计展现就行了。
前面肯定得有实时数据采集，另外还得从DMP里拿到用户标签数据。中间得是两个应用，一个是广告资源列表，一个是广告购买（RTB），现在都是竞价购买的形式（这些不属于DSP，只是辅助理解业务）。后面则是数据统计和展示服务。整个系统大概就是这样的：
中间的广告业务应用就扔给业务开发团队，我们往下梳理数据架构图。前面的实时数据采集一般就是Nginx转发，后面可以用flume，但必须得用kafka进行分发，一边走实时，一边走离线。这里因为涉及到钱，可能要回溯很久的数据，所以建议Lambda架构，因为kappa回溯老数据的时候非常费劲。实时这边建议直接走flink+kafka，缓存用redis，持久用Hbase，算完之后数据建议直接扔实时数仓里。离线那边就随便了，用Hive + Spark就行；实时数仓可以用CK、Doris、Druid等；展示用Data V、Davinci等。所以数据架构图就出来了：
当然，这个架构图还很简单，很多细节还没细化，比如第三方的数据没及时到，该咋办？各个指标应该如何管理和计算？如何保证各个环节的exactly only、深分页等等。这些都是流失计费系统需要解决的问题。
- 数据不及时：FLink自身的Watermark机制，增加环节Retry，多等一会；
- exactly only：两阶段递交、三阶段递交、paxos保证端到端exactly only；
- 深分页：分桶+谓词下推+并行查询。
各大厂DSP实时OLAP选型
百度凤巢用的是自研的Drios（原百度palo），17年开源，后来当时的创始人叶谦大佬带研发团队出来创业。现在已经是炙手可热的MPP类实时OLAP产品了。他们的公众号是DorisDB，大家可以关注一波，里面有美团、小米、京东等大厂的分享经验，我就不复制粘贴了。之前分享过一个进大厂的小秘籍，就是找一些只有大厂才会用的产品，会用了，练熟了，就好进大厂了。这个秘籍一般人我不告诉他！
阿里优酷用的是定制化的kylin，这个很有意思，Kylin本来是需要预计算的，按理来说不太适合实时场景，但是他们通过微批+预计算Rollup物化视图等手段保证数据构建效率，通过Blink分钟级微批计算，Kylin分钟级增量保证实时性。居然结果还非常不错~~~
头条的巨量引擎用的是Druid，这是一个基于时序的数据库。因为广告数据全部都是日志数据，天然有序，对于Druid来说非常匹配。基本能做到来一条算一条，这效率嗷嗷的。不过Druid不支持join，对场景和设计水平有比较高的要求。
