互联网广告流式处理系统的设计与实现

郑国英 张扬

摘 要： 随着互联网的迅猛发展，越来越多的互联网广告开始出现。互联网广告以其精准，快速，高效的投放，给广告主带来了丰厚的回报。通过对广告投放系统实时数据处理的分析，针对重定向和实时数据统计等问题，提出了流式处理的方案，运用Storm等技术，设计并实现一种广告投放的流式数据处理系统，详细论述了其设计与实现过程。

关键词： 互联网广告; 实时; 流式计算; Storm

中图分类号： TG4

文献标志码： A

文章编号：1007-757X（2019）06-0085-04

Abstract： With the rapid development of the Internet， more and more online advertising appeared. Because of its precise， fast and efficient delivery， online advertising makes advertisers obtain immense financial rewards. This paper analyzed the real-time data processing system for the online advertising， firstly. Then， in order to solve the problems of retargeting and real-time data statistics， a stream computing scheme was proposed. On the basis of the technology of Storm， we designed and implemented a kind of online advertising continuous computing system. The paper discussed the design and implementation procedure fully.

Key words： Online advertising; Real-time; Stream computing; Storm

0 引言

目前，流式處理[1]方案在国内的互联网企业中使用的越来越多，它被应用在金融领域、互联网领域、物联网领域等，并且它在数据统计、流量计算方面有很大的作用。

流式处理的流程主要包括日志采集，消息队列，日志解析，数据统计，数据展示。互联网广告流式处理系统从客户投放的需求和体验出发，着重在提高广告投放效率，实时展示投放数据，充分利用大数据的优势向广告主提供更加高效的服务，建立实时的投放优化机制，实现数据的实时处理[2]及效果展示，降低投放成本，实现更加精准的投放，提供给客户一个客观真实的页面数据。为运营人员及客户提供辅助和决策服务。互联网广告流式处理系统主要能够实时地展现数据投放的效果，对稳定性，容错性，实时性等方面的要求相对来说比较高。

互联网广告投放时会产生大量的日志数据，这些日志包含请求日志，竞价日志，曝光日志，点击日志等等。对于这些日志，因为其数据量大，处理逻辑相对复杂，同时又需要能及时高效的处理，如何采取处理框架是一个比较重要的选择，这关系到投放的精准性和高效性。互联网广告流式处理系统能够实时地处理这些日志数据，满足运营部门的需求，并能以一种高效的方式展现出来，提高使用人员的使用体验。

1 Storm的技术分析

Storm[3]是一个分布式运行的，能够实时处理的，可容错的流式计算框架。与大数据处理平台的Hadoop相比，Storm也能够处理大数据量的数据，同时Storm还能在高容错的条件下更加实时地处理数据。Storm在在线机器学习计算，实时统计分析，持续性计算，分布式RPC等等场景下都能够使用。Storm能够根据运行状态随时扩展集群数量，提高集群的数据处理能力，并且能将每个消息都进行处理，不丢失一条消息，在容错方面也有一定的保证，而且它的处理相当迅速（在集群中，单个节点能处理数百万的消息数据）。Storm能够非常简单方便地安装部署，同时后期的运维也非常轻松，最重要的一点是它能够利用多种语言来编写程序，对研发人员的要求大大降低。

Storm集群[4]中有一个主节点以及多个工作节点，如图1所示。

主节点上又称nimbus，因为服务器上启动一个nimbus的守护进程，主要作用是分配代码、布置任务及集群检测。工作节点又叫做supervisor，因为它的服务器上运行了一个supervisor的守护进程，主要作用是监听工作，创建或者停止工作进程。Topology任务必须在nimbus节点上进行提交，然后nimbus根据每个supervisor的资源利用情况，合理地将Topology任务分配给supervisor。Nimbus和Supervisor能实现无状态的快速失败，保证了集群整体的健壮性，在这个过程中由ZooKeeper来协调这两者的工作。

当提交Topology任务之后，Nimbus节点先对它进行分片，生成多个task，同时Task和Supervisor的有关信息会提交给zookeeper集群，Supervisor通过查询zookeeper集群上，获取各自的Task，然后将task交给worker进行处理，如图2所示。

Storm处理流程涉及Stream、Spout、Bolt、Stream Grouping。Stream是storm的关键抽象化，是一个无边界的tuple序列，storm可以分布式并行对tuple序列进行处理。Spout是数据源，用于生产数据，一般是从外部数据源中进行获取并发送给tuple。Bolt用于处理数据，主要对数据进行过滤，聚合，读写数据库等操作。Stream Grouping用于规定各个bolt接受什么样的流数据，然后以什么的分组方式进行发送。Topology都通过Stream Grouping相连的Spout和Bolt节点而组成的网络。Storm处理逻辑的结构图，如图3所示。

2 系统需求分析与总体设计

根据系统设计方法，结合真实系统的开发实践，该系统的架构设计图如图4所示。

在图4中，有三部分组成：第一部分是数据的收集汇总，表示将服务器中实时生成的数据采用一定的方式收集起来，并汇总在一起，第二部分是数据的消息队列，主要的作用是将会记得数据采用消息队列的方式进行管理分发;第三部分是数据的业务处理，其作用是从消息队列中读取的数据进行统计汇总，并更新后台数据库。

数据源是实时生成的，所以数据收集汇总时，flume-ng[5]采用的是内存模式，实时tail日志文件，并将其存到内存中并发送出去，为防止数据丢失，将数据汇总后统一发送给kafka[6]消息队列中间件，storm从消息队列中实时读取数据，并根据业务需求，生成不同的数据，将其更新到数据库中。

互联网广告流式处理系统能实现数据的实时展现，有利于运营人员和广告主准确了解当前的投放效果，合理调整投放策略。互联网广告流式处理系统有日志预处理模块，数据统计模块，计费模块，重定向模块。这四个模块能够处理完成业务需求对实时性要求高的任务。流式系统处理模块示意图如图5所示。

1） 日志预处理模块：

流式处理系统的数据源有两类数据，一类是竞价系统产生的日志数据，另一类是广告主回传的用户数据。日志解析模块主要是实时获取数据，并且将数据进行解析，以方便后续的处理。当程序从Kafka中读取到日志数据时，能够解析出该日志时什么部分的日志，是竞价系统还是广告主回传的数据，然后能分别对不同的日志进行处理，不仅如此，还要具体区分出是哪种类型的日志，日志的类型主要有竞价日志类型，曝光日志类型，点击日志类型，营销点日志类型等等，同时，对于不同版本的日志也需要进行解析并给出相关的数据。

2） 数据统计模块：

竞价系统每次对ad exchange所发送过来的请求进行应答，决定对请求的广告位进行购买，将所报的价格和广告的url返回给ad exchange，这就是一次竞价，每次竞价成功之后，客户端会展现竞价成功的广告，这就是一次曝光，当展示的广告被用户看见，并且用户点击该广告，那么这就是一次点击，点击完之后，用户能到达该广告的所属广告主的网站页，这就是一次到达。该功能能将这些数据进行实时统计，并展现在后台页面上。除了竞价，曝光，点击等数据，运营人员和广告主还能查看到点击率，曝光率，达到率。该功能不仅能统计这些数据，还能根据其他的需求进行统计。

3） 计费处理模块：

广告竞价系统在竞价过程中，需要统计竞价成功后所需要花费的每次曝光的计费处理功能能记录每次曝光点击所需要花费的展示价钱，能查看每天投放的钱款是如何花费的，合理优化广告投放。该功能还能统计千次曝光的平均展示价格，和平均点击价格以及完成一个转化的价格。广告主和运营人员需要这些计费结果，合理控制预算。避免超出预算。

4） 重定向模块：

在各种广告投放中，重定向投放是相对来说比较高效的投放方式。在广告主页面进行埋点，用户访问广告主的页面，服务器会记录下用户的Cookie以及用户的行为数据，然后获取到用户浏览数据和cookie，通过这些数据进行分析，在广告投放时，通过cookie mapping找到这些用户的相关数据，然后对这些用户进行广告投放，这样精准的方式能更达到高效的投放效果。

3 系统的实现

互联网广告流式处理系统主要由四个模块组成，日志解析模块用来实现数据获取和日志解析;

数据统计模块能够统计投放的实时状况，对于运营人员有重要的价值;计费处理模块能够实时展示投放的金额，合理有效控制投放的预算;重定向模块主要为了更加快速准确的找到高价值的人群。

3.1 日志预处理模块

日志解析模块主要有两方面的功能，其一是数据获取，其二是日志解析。

数据获取采用flume-ng，采用tail方式将系统生成的数据进行收集，汇总，利用memory模式，批量将日志文件的数据读取并写入内存中，然后将内存中的数据发送到消息队列Kafka中。在Kafka中进行了分区，提高kafka中数据读取的性能。

日志解析部分主要是storm中的spout并行读取kafka中分区数据，因为有两种日志数据，所以有两套不同的解析逻辑。竞价系统日志记录了投放的具体的信息，比如媒体，广告位，时间，广告交易平台，交易价格等，通过解析，将各个数据提取出来，并且还需要区分是哪一种类型的数据，比如竞价，曝光，点击等。还有广告主回传的数据包含了用户浏览数据，例如：cookie，ip，url，访问页面类型（购物车，订单，单品）等。通过解析，需要将数据进行解析，这一部分的解析相对来说比较复杂，需要采用多种解密手段，数据分离，提取的手段。

3.2 数据统计模块

数据统计模块主要实现各项投放指标的统计，主要包括数据整合，数据统计，数据库更新等。

数据整合：将解析的数据进行分解组合，因为解析完的日志有两部分，其中一部分是竞价系统的数据，还有一部分是广告主的数据，两种数据在这里需要整合在一起，每个页面的PV能够和竞价系统的投放相关联，这里我们采用了cookie的方式，当用户通过广告点击进入广告主页面时，系统会获取一个cookie，主要是该次点击的竞价id，通过这个id，我们能找到投放的具体信息，比如媒体，广告位等，通过这样的方式我们将广告主数据和竞价系统的数据打通，方面后续的统计计算。

数据统计：将整合好的数据，按照运营提出需求，分时进行统计，统计的维度主要包括投放策略，广告位，媒体，时段，创意等等，这里统计的数据包含竞价数，曝光数，点击数，到达数，轉化数。

更新数据库：将统计好的数据批次更新mysql中的数据。这里因为mysql数据库的读写性能的关系，我们将每次操作mysql的时间设置为5分钟一次，避免mysql因为读写太频繁而导致数据后台崩溃。

3.3 计费处理模块

计费处理模块主要实现投放金额的统计，括金额统计，数据库更新等。

金额统计：通过整合好的数据将每次消耗的金额数据提取出来，也需要统计出其他维度的信息，然后和数据统计模块的投放数据整合到一起，同时，还需要计算总的消耗，以及千次曝光价格（cpm），点击价格（cpc），转化价格（cpa）。

更新数据库：将金额统计的结果写入到mysql中，这里需要写入两部分数据，一部分是关于投放的消耗，例如曝光价格，点击价格，转化价格等等，这个需要和数据统计的结果合并输出，另一部分财务统计部分，这里需要统计广告主的财务情况，合理调整我们投放的利润。

3.4 重定向模块

重定向模块主要将访问过的用户的cookie收集起来，并根据收集的用户的cookie进行投放，主要有三部分组成：cookie獲取，cookie分析，更新数据库。

cookie获取：广告主回传的数据经过日志解析，提取过相关信息，在这里提取出用户的cookie以及历史浏览行为。

cookie分析：将过去的cookie和它对应的浏览行为整理，并分析，多次访问单品页的用户，有很大的购物趋势，更具访问的深度和次数，通过设置阈值的方式分析出cookie的投放价值，并根据这些投放价值设置投放时的价格权重。

更新数据库：将分析得到的cookie针对每个交易平台做一次cookie mapping，从而得到每个交易平台对应的uid，然后将uid和它的投放权重批量写入到redis中，当竞价系统投放时，对比redis中的uid和由交易平台传过来的请求解析的uid是否匹配，如果匹配，根据价格权重进行出价，如果不匹配，则不然。重定向流程图如图6所示。

4 系统的测试

流式处理系统的测试主要分为两个方面，其一是功能性测试，其二是性能测试。功能性测试主要是针对系统各功能模块的测试。具体的功能模块包括日志预处理模块，数据统计模块，击飞处理模块，重定向模块这四个主要的功能模块。针对这四个功能，测试各功能模块的准确性，保证各方面数据都能够正确处理。性能测试主要测试流式处理系统的实时性以及极限压力情况。保证数据能有规定的时间内能处理完成，并且面对数据量比较大的情况下，也能达到相应的响应速度，以及准确度。

4.1 系统模块功能测试

系统模块功能性测试分别对四个主要模块进行测试。分个模块进行准确性以及代码层面的测试，保证能够实现各模块的功能，并且能对处理过程中的错误进行汇总，避免因为错误，导致系统各模块的功能受到影响。

日志预处理模块测试：主要针对日志预处理模块进行测试，首先测试程序能够准确对源日志的数据进行读取，其次测试程序模块能正确解析各种系统以及各种类型的日志，主要能够分别解析出竞价日志，曝光日志，点击日志，营销点日志。需要注意的是：因为日志系统的升级，程序需要解析出不同版本的日志，并采用不同的日志解析逻辑。

数据统计模块测试：主要是针对数据统计的结果进行测试，针对统计的各项指标，包括竞价数，曝光数，点击数，以及转化数等等，采用造数据的方式，对于处理结果和预期结果进行对比，看是否数据是否一致。在这个过程中，重点测试的指标是营销点统计数据，其中包括营销点转化数据，到达数据等等。

计费处理模块测试：该测试主要针对的是设计投放金额的模块的测试，测试投放金额的周期性刷新，能保证相关的曝光数据中统计实时花费金额的多少，同时测试其他与计费相关的指标。

重定向模块测试：主要测试重定向功能是否能够实时实现，访问过广告主页面之后，在去浏览其他页面，是否还会推送曾经访问过的广告主的产品。这里测试的方法比较复杂，因为这重定向数据并未展现出来，所以每次测试都需要直接读取数据库中的数据，或者直接寻找展现在该浏览器中投放媒体的广告。各模块测试情况，如表1所示。

4.2 系统性能测试

系统性能测试主要分成两个部分，包括实时性测试以及压力测试。实时性测试主要保证日志从读取然后后台处理到展现能够在五分钟以内完成，压力测试主要是保证在数据流量突然暴涨的情况下，流式系统也能够正常的运转，并且对日志数据进行准确处理。

在对整个系统进行具体的测试之后，能保证系统数据在五分钟内处理完成，并且达到每秒2M的数据进行正确处理。性能测试情况，如表2所示。

5 总结

本文中所涉及到的研究内容和所取得的阶段性成果如下：

对互联网广告流式处理系统进行需求分析，了解分析系统的设计与实现方法。通过对互联网广告的分析了解到互联网广告投放的投放时流量大和时效短的特点，所以本次系统在设计中要考虑到实时响应，容错处理。

因为流式系统需要和其他投放系统进行数据交互，所以都是以数据库方式进行交换，流式系统将处理结果写入到数据库中，其他系统能读取该数据库信息。

虽然互联网广告流式处理系统的出现已经提高了投放的效果，对于运营人员是相当重要，但是目前仍然存在以下问题。

（1） 数据库写入问题

因为流式系统处理的数据量相当大，他们对应的处理速度要相当快，保证投放数据能最快展现出来，但是因为流式系统与数据库交互采用的累计批量的方式，所以不是完全的实时，仍然会有少许的延迟。

（2） 版本更新问题

如果处理逻辑改变，那么就需要我们将在Storm中运行的Topology kill掉之后，然后才能将新版本代码提交到系统中，这样数据会有一部分丢失。

参考文献

[1] 亓开元，赵卓峰，房俊，等.针对高速数据流的大规模数据实时分析方法[J].计算机学报，2012，35（3）：477-490.

[2] Qian Z P， He Y， Su C Z， et al. TimeStream： Reliable stream computation in the cloud[C]// Proc. of the 8th ACM European Conf. on Computer Systems （EuroSys 2013）. Prague： ACM Press， 2013. 1-14.

[3] Storm wiki[EB/OL]. 2017-08-12. https：//en.wikipedia.org/wiki/Storm_（event_processor）.

[4] Storm tutorial[EB/OL]. 2017-08-23. https：//storm.canonical.com/Tutorial.

[5] Honghao G， Jinyu K， Jiaan Z， et al. Reliability analysis on Web-based service system using probabilistic model checking[J]. Journal of Southeast University， 2017（47）：132-139.

[6] Apache Kafka， A high-throughput distributed messaging system [EB/OL].  2017-08-30. http：//kafka.apache.org/design.html.

（收稿日期： 2019.03.18）