4月17日QCon业务架构专场会议上，腾讯QQ空间营收功能后台技术负责人冯启航以“QQ空间平台百亿级流量的社交广告系统海量实践”为主题，用自身在QQ空间增值营收服务上的多年探索经验，为大家分享了他对于大数据为增值营收带来新的增长引擎的独特思考。以下是冯启航的分享实录：
冯启航：大家下午好，我是来自腾讯的冯启航，2010年毕业一直就职于QQ空间，现在是QQ空间的营收以及人工智能后台的负责人。今天要讲的是我们一直建设了差不多四年左右的广告系统。互联网的商业模式就是流量变现，这对产品很重要的过程，做营收的，怎么把流量合理应用起来，是我们一直要解决的问题，今天分享的就是怎么流量变现的服务实践，以往讲广告系统挺多是讲广告的算法，今天是更多的讲工程实践。
***部分讲业务背景，第二部分讲我们在架构过程中的一些设计思路，列举一些具体的案例看看实践的问题，第三部分讲一下做ROI提升做的事情，***再小结一下。
业务背景：空间里的广告除开广点通的效果类的展示广告外大部分流量都是自己平台管理的，比如有品牌类展示广告，还有平台自身的推直播、UGC功能，黄钻收入的需求，我们这些视作内部的大广告主，他们的问题是我们聚焦要解决的。
今天分享的系统叫QBOSS，取这个名字是最开始建设定位于Qzone业务支撑系统，随着发展，QQ空间等产品接入广告渠道有数百个,系统每天的有三百亿左右的日常流量，流量访问是很大的，日常峰值40万每秒，性能要求高，我们的要求是整个广告请求耗时在50ms内。
架构设计的***步是理清一些业务概念。
中间核心是广告，根据广告的业务特点分了四个维度四个方向上设计了概念。首先在广告的左侧是建立渠道的概念，有利于规范的管理。右侧是体现平台和产品运营导向的一些内容，例如作为对平台健康来说，防止广告对用户进行骚扰也很重要，比如用户重复看过的广告还出现这是不允许的，还有就是按时间排期，优先级等体现平台产品的运营导向的。上面的方向是真正用户能够感受到广告体验的，我们称为资源，它分为两部分，一个是素材数据，这个图片是什么样子，视频是什么样子，这是素材问题，另外还有一个很值得说的，对开发者我们给他一个控制展示逻辑json模板的DIY定义机制，他是能够支持开发者结合渠道制定自己展示逻辑，这也是一个很关键的设计，它做到了让渠道业务的逻辑和广告系统解耦，而且对开发组非常友好。广告概念下面的方向是讲用户细分，广告给更合适的用户，避免全量用户去展示，骚扰用户也浪费了流量。在这个方向也有很多算法和大数据的发展空间。
腾讯通用技术积累
看经典的三层架构里，接入层有TGW WNS MSF TSW等，。中间层里SPP是腾讯内部最多使用的后台服务开发框架，把网络通信相关的功能都已经收归了。还有一个同步中心，这是我们Qzone自研的，因为Qzone这样量级的产品肯定是存在异地服务的，现在是深圳、上海、天津三地同步服务的，就涉及到数据的同步问题，我们都抽象成一个公共服务建设出来做了同步中心。另外我们用的比较多的是SSVR，它类似于一种队列型的服务，但是不一像大家经常看到的云队列的服务，我们是一个流水来实现本地队列的服务，这个简单可控，实践证明这么多年用下来没出什么问题。存储层的选型比较多，首先CKV是腾讯最广泛使用的产品，CDB是在MySQL上建立起来的，Redis用的也是比较多，TDW是针对海量数据做的一个数据库。
左边是一些系统或者组件，比如织云是我们的运维门户包含了很多运维标准工具和流程;L5是做负载均衡的，罗盘、DC上报、CRA等是报表系统依赖的系统 ，神盾是推荐引擎，另外当然有成熟CDN支持我们的广告素材数据发布和访问。那我们搭一个海量系统还需要做什么事情?用它来凑一凑，这个就比较靠谱了?其实整个广告系统麻雀虽小五脏俱全，很多非核心服务我在这里就不赘述了。今天重点讲的在线服务有策略中心、用户中心，数据中心，还有离线处理部分，主要把用户的数据处理上去。我们的客户系统终端覆盖PCQzone，独立版APP，QQ，接入渠道是个人中心，应用开屏，Feeds广告。先看策略中心是很综合的一个服务，相当于广告系统的中控，把SSP \DSP\DMP都结合起来了。这里都是重控制逻辑的部分，分享里也不赘述。
用户中心服务，先从DMP建设开始
像上图左边这样，我们去搜集很多平台相关的活跃特性，你是不是黄钻，是不是登录活跃用户，把这些数据建立成一个标签，广告主就可以任何组合选出一个用户群定义出来。还有一种是号码包方式，腾讯内部还有很多做数据挖掘的团队，另外腾讯的业务实在太大了，很多的数据产生方，不能都集合到我这里来，你必须用号码包的方式组织起来，这个用的比较广泛。最开始最简单的架构就是对外服务，提供一个协议就是询问用户是不是这个用户群的，服务就回答YES or NO，就是做了一个匹配逻辑，把用户的数据和用户群定义的数据做一次比对，这是最简单最开始的架构，但是遇到了一些问题，一个是你DMP要做强大，你的tag数据一定要做的多，tag来源很多，很多的数据团队并不一定他的数据会放在你这个地方。就算是给你离线缓存有这个权限，对你的系统来说也是很大的负担，还有个成本就是开发效率，投放体验优化等，做这个系统的时候人力紧张，有的广告系统的团队专门做这个，而我们这里只有一到两个人开发做这个DMP，必须关注研发的效率。再就是内存存储成本，性能要求决定了你的存储的选型只能用内存，但是内存设备价格太高了，如果DMP都存下所有数据那你想想这几百个指标要多少数据容量和设备呢?
我们带着问题继续往下走。***个问题，我们怎么提高用户画像tag的建设效率，之前怎样做的呢?其实很多兄弟团队还是这样做的，比如我要做年龄和性别进来，一定是在TLV协议上取一个新的名字，这样每增加一个tag效率是很低的 ，每个标签的增加需要开发介入，更改协议，更改匹配逻辑的代码。后来我们决定，放弃这个设计，采用bit协议来管理(如下图)，增加一个tag就是增加一个ID是很简单的事情，bit的资源就是上线一套存在就有64位上去，再增加一套就是128了，对资源有分配序号的，每一个tag要新增我就给你分配对应的bit，我新增一堆tag没有工作量了只需要分配。
第二个问题是增加一个适配层来处理数据来源。其实腾讯还有很多是有数据的技术团队，但是没有渠道触达用户，我们把这个数据接入能力做成适配协议后，走出一个插件式高效率的方式开放出去。数据团队按这个协议写好服务，接入就可以提供给广告主使用了。另外适配也可以兼容一些必须实时访问的tag数据服务方。
第三个问题是号码包定投，一开始我们想的也比较简单，用nosql存储存用户uin为key，value是包含某个号码包id的数组，存一下用户在哪个号码包里面，每次访问的时候拿这个数据判断就行了，看起来很简单很容易理解，但是实践的时候会发现有缺点.首先是投放体验，投放一个五千万或者一亿的号码，系统需要把这个号码的所有用户的数据都拿出来一边读一边写。那这样一个投放操作需要影响在线的服务，因为他要改在线的数据，在线的容量也会受到影响，而且广告主什么时候投放号码包也不确定，投放几个也不知道，对外网服务的稳定性造成的风险挺大的。并且我们有三个地方的服务，深圳上海天津，如果你在深圳投放，你还要同步这个数据到上海和天津，耗时更长。存储回收也比较麻烦，很多号码跟着广告走的，广告一旦下线，这个数据的意义就不大了，但是你很难回收。你只能把这个号码拿出来再更新一下。我们以前做过被动的更新，当你用到这个用户的时候再拿出来比对是否过期，不过这是非常被动的。解决这个问题，我们用了Qzone自研的存储利器好友参与系统，非常适合改造出适合号码包的topic类型存储，我们认为topic是个主题，是否参与一个游戏、是否在一个号码包里，都可以看作topic主题。以前最火的QQ农场，你可以看到有多少个好友在玩农场，上千个好友都要看他是否在玩农场，这是非常大的计算量，于是我们就做了这个存储系统。我们可以根据这个存储系统的数据结构需求，把顺序的号码包数据处理成一个Btree树结构，还有他用tmpfs处理这个号码包，使得每个btree文件就是服务器上可以管理的文件，可视化的，我们的深圳上海天津三地同步也很简单，只需要跨地域同步文件就可以，现在都是可视化操作了。管理方便，回收数据也很方便，直接删除文件即可。性能也非常好。
数据中心服务。它的难点主要是管理用户的广告反馈数，广告系统里面，数据中心和其他的和UGC很大的功能不同是，他是读多写多的访问模型，为什么这么说呢?比如最普通的场景里：一次广告曝光，曝光之前我需要看一下这个用户有没有看过这个广告，就需要再读一次，如果觉得这个用户能够被曝光，他就要写一下广告记录，所以每一次曝光都需要读写这个数据，读和写的频次都是很高的。不同于普通的功能类型产品，我发表一个说说相册一般来说都是读的情况很多，写的情况相对很少。另外我还是存在需要异地服务接入，数据同步问题也是，因为量大了，就容易堵塞通道。
数据中心服务架构剖析：每一个地区是左边这样一个架构，首先我的主要是逻辑服务，存储是CKV，在逻辑上读写命令处理是分开部署的，代码虽然是一起的。另外我做了快慢分离，同步转异步，比如我要统计这个广告的曝光点击量，点击率，第三方监控(我在你这里投广告你曝光了多少第三方需要统计一下)这些需求的性能实现是相对慢的，还有自己的一些统计功能，包括还有到同步中心的同步数据操作到另外两地都是很慢的，这个绝对不能放在在线的写操作里。 SSVR起到了一个队列作用，它一部分是很快地接收数据写入到队列文件里去，另外再起一组进程读文件，按后端服务的容量，往后队列的形式，跟后端通道通信，对后端慢的服务也是按需调度服务的，只要跑得过这个流水产生的时间就行了。
架构里我们在统计数据功能实现上做了两个独立的通道，左边DC上报这是腾讯公司级的组件层面做的一个，是基于用户维度处理，用户实际曝光和点击哪些广告，在罗盘系统上做出一个统计报表。另外右边在队列服务后面我们自己做了一个统计的数据，我们是根据广告ID的维度做的，我们不想再处理很大量的问题，我们不关注用户ID信息了，只关注广告ID的维度，所以就可以上一些取巧的数据合并操作，数据量、计算量减少显著，很简单地数据统计就可以把这个报表生成。两个通道两个独立逻辑，两个通道得出的数据是一致这个报表的数据就是很准的。
***讲一下右边数据中心的异地同步方案。先对比一下通常的功能产品的模型，一般都是三地读一地写，比如你要看照片三地都可以看，你要发表一个照片一定要先接入到深圳收归写操作，然后再同步到上海和天津，这样设计比较简化，要考虑成功率去重试、时序性等，同步服务哪个数据失败了要重试，一定程度会堵塞通道，还比较难避开这个问题。而在这个广告系统里一定是要多读多写的，如果按这个常规方案会出现一个问题：用户在上海点了一个广告，本来当用户第二次请求已经过来了，不该出现广告了，但是还出现了，因为数据还在深圳往上海赶的路上。所以需要在本地直接写好数据，所以我们只有选择三地写三地读的方案，而这就要在同步中心建六个通道，比一般的产品投入量会大很多。所以我们要考虑如何简化设计。广告系统强调的是实时性、对数据的三地一致性和时序性要求并不强烈。所以根据这个我们大胆做了一个不做堵塞通道的一个同步逻辑，而且我们同步的数据只同步一些增量动作信息，比如我在深圳点击一个广告，我并不告诉你深圳存的是什么，往上海天津同步的就是告诉有这个动作发生，由每个城市的被你的服务自己决定如何改写数据。因为很多渠道的接入比例和异地方案不一样，所以在这个设计上，***深圳上海天津的数据总容量和用户key下面的value其实都不一样。容灾方面假如通道有一些故障都断的情况下，短时间断了会形成三个“孤岛”，三个“孤岛”的***的问题是假如用户在上海点了个广告，下一次他又去深圳了，这个广告就会被看到了。我们敢这么设计是大胆地尝试，基于接入方式不会这么频繁的变动的假设，我们有去实际模拟验证一下，这样的用户按我们的统计，一天影响量才万分之五.而要发生这样一整天的故障，本来在腾讯也不常见，有这样的故障，我们的平台肯定已经做了其他的接入服务的调度容灾方案，例如当初的天津大爆炸，我们很快就把服务流量切走了，不会让用户进入“孤岛”。
平台海量服务运营能力，首先是监控能力，接口级别监控，实实在在统计他的成功率和延时;用户端是监控，真正看你广告拉出来的延时，还有广告数据监控：广告有没有按时出现，有没有点击率符合预期。其次是服务容量，不考虑研发bug的情况下，我们的服务都定型后，所谓质量就是个容量问题，容量够了质量就好，容量不够质量就不好。容量对变化无常，这是广告系统会遇到的问题，广告计算的负载波动比较大，特别是平台类型的广告系统，不像效果性广告可以保持平稳的广告输出量，特征是比较平的，我们这儿不一样，比如手Q的banner有广告没广告对你的系统有一个明显的影响的，还有每个广告的计算需求都会不一样，例如是否定投计算是否验证曝光数据等，希望云计算的弹性能力来做这个事情，但是现在的技术发展情况下要快速应对这种非常突然的负载变化时候，服务质量不抖动是很有难度的。那我们能做的就是，对未来要承担的负债有一个预警，你就要去算，因为广告主都会有提前量，比如下午的广告上午就投了，不会马上生效，总有一个时间去检测我的负债是否足够。总比在周末节假日突然发现负载不行了，措施不及要强。另外还有是做高性能，性能足够我就可以在设备需求不大的情况下，留够5到8倍的buffer，如果性能不行，同样的buffer需要的设备数量就巨大了，运维兄弟的压力就会很大。 性能方面很多常规的优化的手段都有做，例如尽可能的缓存，和对应的淘汰逻辑，微线程的方式提供服务，坚持业务和广告逻辑解耦，避免json协议编解码，还有各种分离部署，避免一些服务抖动毛刺，例如数据中心的读和写以及回收多个命令字就分开服务，为了避免有些广告可能突然间会量上来，有一些代价大的操作会给代价小的服务带来不稳定表现。容灾方面，尽量设计无状态的服务，那么结合L5负载均衡避开单机故障印象了，我们支持城市级别容灾。值得强调的是抓细节吧，所谓容灾，其实一些很关键的服务，我们总是可以覆盖住的，但是实际检验起来让你容灾难以为继的可能都是一些细节，所以重在细节，找短板。
下面部分再讲一下广告系统ROI优化之路，这是我们走过的弯路。首先在ROI优化前先要找准自己的瓶颈，我们的广告数量级并不大，因为都是大业务的需求，可能广告里就五个六个，不大于十个的广告，但是效果广告系统的广告数据量是很大的，成千上万的，甚至会经过初选、试选，算法复杂程度都不一样，很多事情可以做，他可以做到千人千面。而我们需求量也不稳定，所幸的广告质量是可控的，因为广告主离我们比较近，我们了解他们的需求。基于这个前提，我们去设计适合咱们的ROI策略算法。
ROI提升实践三种尝试
***种是最开始走的弯路，有用户进来通过各种方式查体的数据查在线的优化，会发现就算你知道用户喜欢哪一类广告，但是你现在的库存里面是没有这类广告，你没办法的。同样一个项目他的广告通过更多渠道去做他，可能这个广告的用户群并没有在这个渠道上投，他去了另外一个渠道也可以做，广告主来说他投放的代价是很大的，因为每个投放会带来开发成本和投放成本，因为每渠道都是不一样的。第三是非常有用的方式，我还是把渠道流量给一个项目，但是你不能再用一个广告了，必须要设计多个广告进来自己跟自己竞争，不同点在于广告A投的是这个用户群，广告B投的是另外的用户群，或者设计多个广告图。让用户点击数据说话，技术上等待二三十分钟就可以选出来优劣，让点击率高的广告生存下来，这个策略最直接的作用就是起到广告主和用户间的沟通桥梁，你做的工作好坏用户会给你反馈，这个是刺激到广告主你要去用新做一个广告，其实很多广告投放也很有门道的。有了这个反馈广告主会更善于利用流量，ROI提升落到实处了。
ROI另外一些很重要的功能点就是负反馈。我们分析过，有的人看广告七次都不会点进来，你给他投放再多次或者其他类型的广告他也不会点，他选择性地忽视了，这部分人群不要给他出广告，对他来说他体验也好了，对我们来说我们收益上也没什么损失，还减少了骚扰。还有是频率限制，流量出来后并不是马上给它消耗完，平稳地在一天或者更多天消耗完。甚至发现一个偶然的好处，第三方投放的时候，因为他们往往不太知道Qzone流量的威力，经常网站顶不住，等到网站顶住了的时候，流量却消耗完了。虽然广告主不知道我们Qzone的流量有多厉害，但是他肯定知道他的网站可以顶多少访问量，按需做频率限制就做好了广告的转化体验。
还有一个是Qboss人群分析统计，你投完之后我们可以测试这个tag组选的好还是不好，你选一组tag后，我们统计出曝光和点击人群里，符合这个tag的占比多少，如果两个持平了，可能说这个tag在广告受众里不是很明显的东西，如果点击比例高于曝光的，这就是很正向的tag，反之就是负向的。通过这个工具，广告主就学习到了经验，以后投这类广告的时候你就是知道优先要投哪部分人群。
ROI提升的事情我们是去年12月之前结束的，看各渠道的点击率提升，有的是百分之十几，有的是百分之三四百，这个是符合预期的，我们提供的只是一种工具，一个反馈渠道让广告主得到信息和经验。你自己广告主的优化必须是你自己想办法做的事情，做的好就是百分之四百，做的不好你还是百分之十几。
系统架构设计心得
我们技术价值一定要体现在业务上面，我们开始做的广告系统，比如今天讲的听起来很朴素的，但是他能解决业务问题就是一个好的东西。还有是职责识别，我们把一个广告系统分成3个大的方向，每个大的方向有它的职责范畴，抽象一下也就能满足大系统小做的要求了，一个复杂问题简单化，比如用户中心这块儿你只需要给我判断这个用户是不是用户集的，别的问题都不用管。再是抽象一个层，可以解决很多需求问题。善于在存储上做性能提升例如redis的成功，逻辑很简单，性能也非常好，包括我们刚才介绍的好友参与系统都能很快解决问题。低成本的优化思路上尽量优先考虑业务场景特点的利用，如果成本高，首先可能考虑到存储的介质优化，看看有没有一些数据协议压缩等等手段，可是收效不一定好，我建议大家还是从业务家度上考虑问题，可能他给你带来的是上十倍百倍的成本节约，广告系统就大量利用广告短期时效性的特点去做了很多成本节约。尽量做无状态的服务，能够保证你的负载均衡一致性，容灾也方便。还有各种部署的分离，在一些小的系统里这个有点多余，但是在海量系统里这个还是很有必要的。***我们所有的架构设计都是依赖自己的数据方面经验的，但是在你上线前或者后一定要通过数据验证它。例如我们设计的异地同步方案，容灾的考虑就有数据调研，上线后也去验证了，这样我们才能让这个架构继续工作，也有利于后续的经验积累。
