精准推荐平台现网引流测试初探

前言

大数据时代，海量流量和数据是变现的源泉。腾讯拥有最多样的用户数据，社交、聊天、游戏、听音乐、看电影、逛电商，等等，有巨大的挖掘空间，个性化精准推荐无疑是一把开矿的钥匙。TEG-数据平台部基于“数据+算法+系统”的设计理念，海量数据实时采集、流式计算、实时建模、实时推荐，构建海量、实时、精准的个性化精准推荐平台。建设这套能承载300亿次/天的推荐请求，300000次/天多维交叉计算的分布式实时计算平台是一项浩大工程，保障这套平台质量也是非常大的挑战。

本文将重点介绍现网引流测试方法在TEG-数据平台部精准推荐平台质量保障中的应用。

精准推荐平台架构精准推荐平台实时接入用户行为数据和广告的点击曝光数据（8亿用户行为，15000亿条记录/天）；实时计算平台和离线计算平台进行计算（主要以实时计算为主，离线计算部分主要是高复杂性的聚合计算，后续也将实时化），结果存入分布式存储平台；推荐引擎根据分布式存储数据进行计算用户对待投放广告或产品的中意程度（中意程度通过用户可能点击的权重值体现）。

质量保障挑战：精准推荐平台，除系统复杂、代码量大外，对测试带来不同的挑战：数据多样性：海量实时业务数据流的复杂多样性，采用传统的数据构造方法无法覆盖。

数据时效性：数据在系统中实时流转，按滑动时间戳记录计算结果且有过期失效，相同的数据在不同时刻计算结果不相同，使用同一批数据在版本中测试的想法无法实现。

数据非随机性：用户行为和广告曝光点击是随机的，但用户的活跃度和广告的热度加入了非随即性，这种非随机性很难找寻，很难通过人为构造。

性能评估：海量流量服务，动辄要上千台的机器规模，任何性能的波动都可能会对整套平台带来严重的容量冲击。系统中的cache缓存对非随机性非常敏感，正是数据非随机性，性能测试不能通过模拟请求的方式进行。

稳定性：做为大数据的核心平台，需要保障现网运行提供7×24小时服务的能力。

现网引流应运而生海量处理系统，复杂多样的数据流极难模拟，而现网多样数据可为我而用。直接把现网实时接入数据和实时推荐请求引一部分出来，不间断地导入测试集群，可以很好的解决数据的多样性、时效性、非随机性。监控测试集群的各项业务运行指标，来发现平台可能存在的问题和风险，同时可以实现准确的性能测试和长期的稳定性测试。

架构图中可以看到，测试集群是有AB两套，A环境上部署了跟现网完全一致的版本，而B环境上部署的是待测版本。通过AB两套环境在同样数据流下的各项指标的表现以及具体计算结果的对比，不但可以发现性能稳定性的变化，还可以做到对结果的功能性验证。

架构中之所以不直接跟现网大集群对比，主要原因是测试集群机器规模远小于现网，将来也不可能跟现网一样，那样成本太高了。所以，测试集群不可能把现网流量全部导入，而只能导入一小部分。这样，变通办法就是AB两套环境的对比。A环境可以认为是现网的精简版。这套现网引流的框架，解决了在实时数据处理平台测试中用传统手段很难解决的困难。

现网引流数据引入：整体推荐平台有三个输入源：a、通过AccessServer接入的广告投入请求。b、通过TDAgent和TDBus接入的用户行为数据和广告数据。c、TDW离线计算的数据，这些数据为实时计算所用，例如用户人群聚类信息、算法模型数据等。

广告投放请求引流：为配合现网引流实施，AccessServer提供旁路功能，把请求复制一份发送出去，不处理旁路的返回（旁路功能只对消息进行转发，不做内容解析，AccessServer是cpu计算型server，旁路功能增加网络IO开销，但对AccessServer的性能影响可以忽略）。旁路出来数据会发给请求中转Server，再由请求中转server发给要引流请求的服务端。请求中转server支持把请求复制转发给多个服务，也可以选取特定广告位和算法相关的请求进行转发，能很方便的特定广告位和算法场景测试。请求中转server转发给服务端的流量可以通过配置进行调节，方便进行压力性能测试。引流流量跟进测试集群规模可控。

用户行为数据和广告数据引流：用户行为数据和广告数据通过TDAgent和TDBus接入，都会缓存到TDTube（消息中间件，支持1个生成数据多份消费）。TDAgent是部署在业务机器上，上千个部署点，如果在每个机器上进行旁路不现实。TDBus的资源瓶颈是网络流量，直接全量旁路一份对现网影响非常大。从TDTube上可选取特定topic数据引流，且可以控速引流，对于现网影响非常小。从TDTube上引流数据是通过数据转发server消费TDTube的数据完成的。数据转发server可选取特定topic数据进行转发，支持把数据复制转发给多个服务，消费TDTube的速度可配置。引流流量跟进测试集群规模可控。

TDW离线数据：一些TDW离线计算的任务还没有实时化，需要借助TDW批量计算能力进行计算，把计算的结果定期导入实时计算系统中。实时计算系统只读取离线数据，不修改离线数据，所以测试环境可通过直接使用现网离线数据的方式引流（TDW离线计算的质量保障使用其他方法保障）。用户聚类、模型数据等数据量不大，可全量加载测试环境。

通过三个数据源的引流，测试环境就可以获得源源不断的现网数据了。

现网引流计算结果校验：数据引流到测试环境了，接下来就是系统计算结果正确性的验证了。正是由于数据的随机性和海量计算，计算结果无法直接预期，所以测试环境下才构建了两套环境，一套稳定版本环境，一套测试版本环境，通过对比两套环境的计算结果，验证系统计算功能正确性。

为更好地通过对比发现系统风险，建设了现网引流工具平台，对比数据直接通过前台展现，方便查询两套环境的运行差异。

业务指标的对比

业务指标主要包含处理数据条数、成功数、失败数、超时数（平台会自动计算成功率、失败率、超时率），句柄数、进程数、进程重启次数（分布式系统的进程down掉会被自动拉起，进程重启次数方便识别系统的运行稳定性）等。两套环境的数据对比通过把数据上报到秒级监控（借助秒级监控实现交叉分析；通过不同的sysID区分环境，秒级处理；秒级监控对上报数据进行交叉分析，例如上报成功、失败、错误码、ip，秒级监控就会保障计算出某IP机器上某个错误码失败的情况；），前台通过提取秒级监控处理结果进行对比。如果希望对比其他指标（例如某个某块的耗时、日志中是否有exception异常等），都可以自定义的上报，平台自动提取对比。

计算结果对比

通过业务指标的对比差异可发现系统运行的风险，通过真实的计算结果对比可更精细低发现系统的bug。在精准推荐平台现网引流中的计算结果对比主要包括两个方面，1、计算返回的广告投放请求结果，2、TDEngine中的计算结果。广告投放请求计算结果对比直接对比返回的可投广告列表，在请求转发工具中完成，未展现在前台。两套环境的计算结果在TDEngine中存在不同的表中，直接对比计算结果表，前台上有了展现。如图是不同的计算维度结果的对比情况（有两个版本同时测试，增一套测试集群，即存在测试集群1和测试集群2）。 注：系统如果存在bug，导致计算结果对比不上，这个错误会延续到数据过期（当前是7天），需要通过清空数据来恢复，正常对比。

资源指标对比

除系统运行业务指标的对比、计算结果对比外，平台运行的资源消耗对比也非常重要。当前现网引流工具平台对集群运行的CPU、内存、磁盘IO、网络IO进行对比。这些指标的监控在性能测试时使用非常方便。 当前已支持ganglia的指标收集的对比，例如系统GC情况，运行线程数等。

现网引流测试应用简单实例

以ComputerServer版本为例。版本转测后，替换ComputerServer的测试版本，两套环境在相同的请求下运行，通过对比计算结果和系统运行情况，快速发现系统的功能、稳定性风险。

从下面两个图可以看出来，系统在小压力下是运行稳定性，说明系统的基础功能正常。但随着压力的不断增加，开始出现错误尖针。错误在17：05时刻，测试版本出现失败数较大的尖峰波动。直接查询日志发现，是后端dataproxy重启使得消息没有返回，导致计算超时，问题快速找到了。 后续还可以把出现异常的时候，把error日志也抓取到前台展现，可以加快问题定位速度。

现网引流的性能测试在很多的后台系统中，测试性能都是根据系统的特性构造请求压力，不断加压，再通过系统在不同压力下的性能表现，确定系统性能结果。在精准推荐系统中，一个广告推荐请求中包含100个广告的算法计算，1个广告算法计算需要2~7次的数据查询，也就是说1个推荐请求要查询数据200次~700次。如果每次查询都需要查询数据存储系统，这个开销太大。因此，系统设计中增加数据缓存cache机制（计算所使用的数据通过查询数据存储系统获得后就会被缓存，再次使用此数据时，可以直接使用缓存cache的结果；缓存cache数据有过期时间，一般是60秒，过期后重新通过查询数据存储系统获得）。一个广告推荐请求，数据全部缓存cache命中和全部不命中，性能差异会有几十倍。实际的广告推荐请求中，包含的QQ号码用户，广告列表不是完全随即的。不同的QQ号码用户有不同的活跃度，不同的广告有不同的热度，因此QQ号码用户、广告重复出现的频度是非随即的，且这种非随机性很难构造，通过构造请求的方式进行性能测试结果对现网实际运行的性能表现没有参考价值。

现网引流就很好地解决这个数据非随即的问题，通过引流现网请求进行性能测试，最直接的反馈系统上线后的性能表现。

在现网引流性能测试时，要考虑其他几种情况。1、现网流量充足；2、现网流量不足；3、现网预测测试。

现网流量充足：现网流量大于测试环境性能测试的量。此时可以方便的过滤掉一些流量，控制发送给测试环境的流量进行性能压力测试现网流量不足：当进行某算法现网效果实验时，流量比较小，直接引流不能对测试环境构成压力。由于推荐系统中有缓存cache机制，不能使用拷贝请求多次发送的方式增加压力。为解决此问题，通过缓存一段时间现网流量，再读取这些流量存储数据对测试环境构建压力。由于推荐业务的特性，此方法与实际性能会有差异，但缓存使用最近一个小时的请求，测试性能与实际性能差异可忽略。

现网预测测试：现网推荐业务每次计算的广告素材平均有100个，如果增加到200个、300个… ，性能变化情况。由于现网上没有这样的流量，无法直接引流，必须通过构造请求的方式。考虑到数据的非随机性，先从现网引流请求中提取QQ号码和广告ID累计一定的量，再按QQ号码出现的频度、广告ID出现的频度，构造请求（200个、300个。。。素材）施加压力。这里要注意，由于广告会下架的，数据失效，累计时间不能太久，1个小时以内为益。

现网引流总结

现网引流的总体思路就是利用现网丰富的数据进行测试，以上主要介绍了在精准推荐平台上应用的案例。现网引流的方法在其他系统上也可以应用，主要的建设重点考虑以下几个方面。

测试环境建设

首先要考虑对比校验的复杂性，如果能直接和现网对比，或者计算结果可以通过输入简单计算处理，可以考虑一套环境。例如精准推荐平台这样的复杂场景，可考虑两套或多套环境。其次，在机器规模上先根据集群部署等价关系推导使用最少的机器；出现不能用等价关系推导的，可考虑最小集群规模（当然集群规模小了，会损失一些无法覆盖的场景）。

数据引流方式

数据引入，不同的系统有不同的数据来源，另外测试环境小，可能无法把现网流量全部引入，原则上引入的数据可以近似等价地反映现网流量特性。

对比校验方式

对比检验主要分三类：运行状态指标、计算结果指标（包括中间计算结果）、资源消耗指标，可根据系统特性自己选取（系统使用秒级监控的团队可以联系我们）。

测试覆盖完善

现网引流不是“一招制敌”的武功，建设了现网引流，让现网流量在测试环境上运行并不能完全保障系统的质量。建设者一定要明确建设的现网引流，现在能保障哪些、那些还不能保障的点中哪些可以通过优化能覆盖，哪些必须通过其他方法覆盖，规划完善之路。

结语

精准推荐平台现网引流测试是海量实时计算系统测试的一种实践，借助丰富的现网数据解决构建数据无法模拟现网的困境，比较方便地通过对比测试发现系统风险。当然，现在的现网引流还有很多地方需要优化，对比指标可以再优化，例如现网数据虽然很丰富，但并不是覆盖所有的数量场景（异常数据不是时刻都会出现，测试阶段可能不出现），再例如系统除了数据计算功能，还有异常处理、容灾扩缩容等功能，如何与现网引流相结合，都在推动我们不断思考前行，去建设基于现网的大数据测试体系。