腾讯大数据平台质量保障之道

本文转载自腾讯大数据官方微信，文章为大家介绍了腾讯在大数据测试和平台建设方面的一些做法和经验。原文如下。

---

引言

大数据时代，业界各巨头都在投入重兵打造自己的大数据平台，分析挖掘蕴藏在数据金矿中的价值。在腾讯，数平承建了公司级大数据平台，我们的测试团队也有幸一起搭上了大数据的航母。这是一种机遇，更是一种挑战。因为大数据平台的技术复杂度、机器规模、容量、发展速度等都远非传统的后台系统可比，以前积累的测试方法和建设的工具平台很多并不适用于大数据测试，业界也没有很成熟的方法可以借鉴。这就需要我们在测试思路和方法上主动探索、大胆创新，过程中难免有弯路和挫折，但我们的成长和收获更多。

本文旨在介绍测试团队在大数据测试和平台建设方面的一些做法和经验，抛砖引玉，共同探讨。

TDW现网压测

TDW（Tencent distributed Data Warehouse）：腾讯分布式数据仓库。TDW是整个数据处理最底层和核心的关键平台，基于Hadoop和Hive进行的大量优化、改造和重构，支持百PB级数据的离线存储和计算，为业务提供海量、高效、稳定的大数据平台支撑。目前TDW集群设备数已超过8000台，总存储量超过100PB，日均计算量超过6.5PB。目前已覆盖公司90%以上的业务产品（计费、即通、微信、广点通、罗盘APP、Qzone、多媒体、电商、游戏和无线等）。对于支撑如此海量大数据处理的核心分布式计算平台，质量保障面临非常大的挑战：

•   开源Hadoop框架在8000+集群规模下，是否能稳定运行，业界没有先例。
•   8000+规模的超大集群，能支持多大的计算能力，容量如何？
•   依赖非常少量的测试机器，如何评估这些关键指标？
  

从测试角度综合分析这些挑战，我们大胆提出了直接在现网集群而不是测试机器进行压测的方案，解决了测试机器资源的问题。在测试数据、场景和任务方面，我们分析后决定直接采用现网真实的海量数据和任务，而不是自己构造。因为大数据处理平台的一个特点就是数据和任务的多样性，各BG、各产品的数据和任务都是各不相同的，而且是在快速的变化中，用传统的测试手段不可能仿真构造，把现网资源为我所用是更有效的方法。

当然，只是胆大还不行，还要充分考虑这里面可能带来的风险，不能蛮干。如果因为测试目的，而损坏用户数据，影响用户报表，造成事故那就得不偿失了。所以，我们也采取了相应的规避保障措施：

•   权限隔离：为测试业务流单独创建权限，可严格保证测试操作对现网用户数据不造成破坏；同时测试权限分配相应的测试资源，对现网同等优先级业务不造成资源竞争影响。通常情况下我们还会将测试的优先级设置为低于现网应用优先级，让现网应用优先获得资源跑完。而且这并不影响测试的效果。
•   结果数据隔离：现网结果数据分布在整个大集群各个目录或者各个库表下；为了对测试结果集中管理，测试结果数据都放在单独的目录与库下存放，保证了现网用户数据安全性、完整性。同时对测试帐号授权更加简单，结果对比实现更加方便，环境清理更加简单。
•   时段选取：大集群的现网运行，有它自己的规律，现网测试的时间，我们一般选取现网压力不大的中午到下午时间段进行。这段时间重要业务已经跑完，而且压力不大，可以跑更多的测试业务，在加上前面的两条措施以及监控和及时处理，可以将风险控制在我们允许的范围内。

通过权限和数据的隔离，以及时段的选取，我们从技术上做到了敢于在现网大集群上开展测试。

在TDW集群从几百台到2000台到4000台到8000+的不断规模扩大、架构优化中，现网压测起到了非常重要的作用，这套方法，我们也在不断完善和优化，像海量数据的一致性对比等都已取得了不错的效果。【编辑注：TDW是腾讯分布式数据库，目前已经开源，更多文章，可查看TDW的系列文章】

TRC现网引流

TRC（Tencent Real-time Computing）：腾讯实时计算平台。做为海量数据处理的另一利器，专门为对时延敏感的业务提供海量数据实时处理服务，包括实时采集、实时计算、实时推荐。TRC是基于开源的Storm深度定制的流式处理引擎，用Java重写了Storm的核心代码。目前，TRC日计算次数超过2万亿次，很多产品已经在实际使用TRC平台提供的实时数据处理服务。跟TDW的离线存储和计算不同，TRC做为一个实时平台，对测试团队的挑战也是不一样的：

•   实时处理的特点，决定了我们不能像离线平台那样直接在现网集群开展测试。
•   海量实时业务数据流的复杂多样性，决定了我们同样不能采用传统的数据构造方法。
•   做为大数据的核心平台之一，性能稳定性的评估非常重要，需要7×24小时提供服务的能力。

不用的平台，不同的特点，不同的挑战，我们也采取了不同的测试方法。既然不能在现网集群开展测试，也无法模拟复杂多样的数据流，那我们就直接把现网的数据流引一部分出来，导入我们的测试集群。监控在测试集群的性能稳定性表现，以及各项业务指标的变化，来发现平台可能存在的问题和风险。

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

经过持续优化的TRC现网引流平台，目前已可以做到针对每个业务、每个指标的AB Test，TRC全流程中每个模块的每次改动，只要影响到了某个业务流的某个指标，我们都可以通过平台快速及时发现。

之所以不直接跟现网大集群对比，主要原因是测试集群机器规模远小于现网，将来也不可能跟现网一样，那样成本太高了。所以，测试集群不可能把现网流量全部导入，而只能导入一小部分。这样，我们的变通办法就是AB两套环境的对比，A环境可以认为是现网的精简缩小版。

这套现网引流的框架，解决了我们在实时数据处理平台测试中用传统手段很难解决的困难，在几个重大版本测试中发挥了关键作用。经过工具平台化之后，已是我们大数据测试的利器之一。

Libra实验平台

在大数据时代的变现法则中，广告推荐无疑是已被证明最有效最直接的方式。基于海量数据实时处理，及时收集用户兴趣，及时反馈到推荐算法上，给用户推荐最感兴趣的广告。数平构建了一整套海量实时的广告推荐解决方案，帮助业务提升广告的投放效果。

除了平台的海量处理能力之外，推荐平台的核心就是推荐算法，推荐算法的好坏，直接决定了投放广告的点击率，而这是评价一个推荐系统好坏的最重要指标。做为测试团队来说，如何测试一个算法的好坏，其实是非常有挑战性的一项工作。因为，几亿的互联网用户，各种地域、各种年龄段、各种职业、各种兴趣爱好，可以说是五花八门纷繁芜杂。一个测试人员，仅凭自己的喜好，只能代表非常非常小的一批用户群，而且已了解推荐算法情况下的点击已经失去了客观性。最终互联网用户整体的广告点击率，测试人员是没有办法判断和评估的，而这又是整个推荐团队最关心的事情。这就产生了直接的矛盾：业务团队最关注的指标，测试团队给不出来！针对这个问题，测试团队内部也有多次激烈的讨论。测试团队要不要支撑算法测试？做算法测试吧，你又拿不出最关键的结果；不做吧，这又是业务团队最关心的，同时也是测试团队的缺失。

经过跟业务团队的多次沟通，算法测试方面，我们也逐渐有了自己的方案和思路。那就是直接用真实的互联网用户来帮我们，他们在完全不知情的情况下，最自然的点击也是最真实有效的。而这个，正是我们最想知道的。

具体来说，就是测试团队跟业务中心合作，在推荐系统前端增加一个路由染色模块，这个路由染色模块可以通过我们的测试管理台来控制，实现了按广告位、号段的后台打点分流，让按我们的需要挑选出的一批真实的互联网用户走到我们新的待验证的推荐算法上，同时，利用TRC实时计算平台统计实验效果数据，实时呈现待测新推荐算法的实际点击情况。

Libra实验平台同时支持整个实验生命 周期的管理，以及算法得到验证之后在现网的灰度放量。支持同时开展多个试验，实时展现实验效果。

通过Libra实验平台。弥补了测试团队在算法测试方面的空白，同时为业务团队提供了最有价值的数据指标。

结束语

大数据时代，带来新的挑战，也给了我们学习和成长的机会。做为大数据测试团队，一方面深入理解新技术、新平台、新业务，另一方面，在测试技术上要摆脱固有的思维，灵活变通，大胆突破，勇于创新，才能真正成为大数据保驾护航的精英团队。我们还在路上！

原文地址：腾讯大数据