随着互联网的快速发展，大数据与软件质量的关系越来越密切，从源码撰写、持续集成、测试调试、发布运营，整个流程中大数据无所不在。每个数据关联起来对软件质量中的发现、度量、定位都有着重要的价值。如何从 0 到 1 建立基于大数据的质量平台，利用大数据来改善软件质量？
来自阿里巴巴优酷事业部技术专家万传奇老师将在 4 月 20 - 22 日召开的 QCon 全球软件开发大会上分享优酷大数据质量平台建设及线上质量闭环解决方案实践。在大会开始前，我们有幸采访了万传奇老师，提前了解一下优酷大数据质量平台建设背后的技术故事。
受访嘉宾介绍
万传奇（花名“万众”），阿里巴巴优酷事业部技术专家。2014 年进入阿里，负责阿里集团持续集成平台 CISE 、AONE 实验室等开发工作，支撑集团所有事业部的测试任务。并通过整合集团测试工具插件化，中间件 Docker 化等核心工作，积累了丰富的测试经验。
2017 年开始，全面负责优酷质量部平台建设工作，建立起以大数据为基础的视频质量保障体系，高效结合了实时度量、监控、灰度、告警、定位、分析等多项功能，形成一套完整质量保障解决方案，成为优酷业务线以及阿里相关多媒体质量唯一标准。
平台搭建背景
随着优酷技术栈和阿里不断整合，各客户端埋点数据参照集团的方式全部上报，但对于数据的使用，大家多是写个离线 SQL ，或者部分数据对接集团各个横向服务平台来使用。从优酷业务线角度看，没有一个垂直的大数据平台来支撑各业务线，严重影响开发的效率以及数据对业务本应有的强力支持。基于这个背景，团队临危受命，开始了大数据平台的开发工作。
平台搭建过程中“坑”
从技术角度来说，优酷大数据质量平台搭建分为三大部分：实时、离线、检索。
实时框架我们选择了 Blink（ Flink ）和 Spark Streaming ，两个框架都能很好处理实时需求，我们在 ETL 层面选用了 Blink ，数据计算部分选用了 Spark；
离线部分依托 ODPS 平台，这个平台相对功能强大，适合新人上手，简单的 SQL 就能满足业务需求；
检索部分我们主要依赖 ELK 技术，并将数据存储在 OTS （ HBase ）和 ElasticSearch 中用来进行实时离线度量数据查询，也包括了上面说的聚合查询、全文检索等。
在平台搭建过程中遇到不少“坑”，我们也总结了一些经验，主要分为以下两点：
1、成本
在开发之前，需要考虑两个成本问题：费用成本和人力成本。
大数据是特别耗费资源的，如果这方面不加以控制，产品的性价比就大打折扣，结合优酷大数据平台的经验，这块一定要强关联业务，比如说在数据预计算处理的时候，需要考虑可选维度或必选维度，亦或是哪些维护可以合并处理，这样在存储上能够极大节省空间。在离线计算过程中，如何抽象出中间表，降低计算复杂程度，节省计算资源。
再说人力成本，这个在中后期表现特别明显，随着平台发展，业务方的需求源源不断涌入，从链路上要对接数据、数据计算、存储、后端接口封装、前端展现等一系列开发工作，这就需要我们明确数据格式规范、对各环节的计算逻辑抽象，支持灵活的配置化工作等，有了通用化作为前提，大数据平台同学就可以专注链路架构上的优化，业务同学深度参与进来，这样非常有利于平台的迭代。
2、 盲目调参
常规的参数调优，这是大数据工程师必须经历的。对于初次进行大数据平台开发的同学，建议大家不要盲目调参，要看是哪个环节出现了瓶颈，是网络问题，计算资源问题，还是数据倾斜问题等，针对性的进行参数调整，效率会更快。
平台线上质量保证
测试领域有过几个明显阶段，手工测试、自动化测试、再到持续集成，其实不外乎在追求更高的质量，更快的研发效率。但随着移动互联网高速发展，对于质量的要求要远远高于 PC 时代，测试人员的能力也需要随之提升，不仅要对接常规的开发测试需求，还要关注产品效果、线上运维情况等，也就是说测试领域未来需要复合型人才。
我们都知道现在的移动互联网产品迭代速度很快，各类设备的测试都要涵盖到，单从通用的测试角度来说，就要考虑 APP 启动时间、页面响应时间、页面滑动流畅度、崩溃、卡顿、功耗 等等，测试成本非常高，甚至大多数时候又回到了手工测试去验证。那么大数据能为测试带来哪些帮助？
首先，我们将业务关注的数据进行埋点，可以是功能、性能、用户体验、用户行为等等，这样就保证了我们测试的结果和用户感受基本一致，释放了大部分的常规测试手段，如 UI 、性能、接口等。
其次，我们将数据流程分成：线下、灰度、线上三个阶段进行保障，逐级利用真实设备的数据来保证质量，间接释放了多机型测试不充分的问题。拿优酷播放卡顿指标问题来说，用户观看视频出现一个等待圆圈开始到结束，就是一次卡顿，此时数据埋点纪录这个卡顿时长并上报到大数据平台。
这样大数据平台就可以对这一指标做出各类质量方面的工作，比如：
一次播放中出现了多少次卡顿、卡顿平均时长是多少
卡顿超过多少的时候会导致用户退出 App
卡顿分布在哪个网络是否有故障
新上线的版本卡顿是否有增加
对应大数据质量平台的功能，就大致分为实时度量、监控告警、数据分析、定位排查、灰度验证等几大部分。
监控告警
传统的监控手段，对于服务器性能指标、调用链路等已经相对成熟，一般发现异常就能够确定原因。在移动互联网时代，质量这个词涵盖的不单单是线上的故障，更多的是体验。如果让用户感知的问题发现不及时或者没有发现，所有的努力都会付之东流。
所以我们的重头放在了客户端埋点数据上，把播放体验相关的埋点数据（卡顿、播放成功率）、性能指标数据（启动时间、 Crash ）、关键服务返回数据（ CDN 节点数据）、用户行为数据（点击行为、停留行为）等进行分类计算抽象形成 CUBE ，把能够反应在现象上的问题做成监控，来衡量我们的质量到底好还是坏。
在大数据质量平台，涉及到多维度计算，比如一次播放成功率下跌，具体是发生在安卓还是 iOS ？是全国范围还是具体某一个省？是所有移动用户还是联通用户出的问题？这就涉及到了我们如何对维度切片、钻取，维度大了发现了问题也不好定位出原因，粒度小了对于存储计算都是极大浪费。
这就需要结合业务来看，定义必选监控维度，然后将错误数据流通过 ETL 单独切分，落盘到有聚合功能 ElasticSearch 、Druid 中，做到维度进一步细化，把告警从“大面”缩减到“小面”。比如说北京市联通出现了播放成功率下跌，通过聚合发现，出错 CDN IP 高度集中，告警层面就可以直接交给网络服务定位系统去处理了。此外，监控从实时性、准确性、告警条件模型都有一些探索，我们将在 QCon 的分享中和大家做进一步交流。
智能分析
现在各大公司都在做 Trace 相关工作，阿里优酷大数据平台也不例外。在原有的服务端日志收集的基础上，融合了客户端埋点日志、客户端远程 Debug 日志、服务变更操作、以及规范了第三方服务日志（ CDN 等）。这样操作有利于统一收集已发现问题的数据；当数据在手，被明确告知是有问题的，我们该如何分析？
首先，如果是错误码，我们一层一层看下去也能解决，但是有一些问题，不是错误导致的。举个例子，某天，我们这收到一个客诉反馈说看视频特别卡，突然出现的，我们查了日志没有任何报错，最后是一位细心的同学发现，用户网络 IP 在北京，CDN IP 被打到了广州。对于这类问题，就是两个 IP 字符串提取并作地域解析匹配即可。
其次，我们结合数据，要建立起一个定位知识库，把历史故障、线上 Bug 、badcase 抽象成我们的定位诊断库。
第三，也是我们现在正在做的一些事情，知识库是人建立起来的，其实这就好比监督学习，但我们想能不能用无监督学习的方式把问题定位出来呢？再举个例子，我们会做一些大型活动，但是有时发现从第一个页面跳转到第二个页面的用户转化率发出警报（只有 10% ），我们会把这一类的用户进行全链路数据检索（不只是服务端日志），然后将各类特征做聚类分析，就会惊奇的发现，绝大部份用户会有共同的特征被聚类出来，问题可能是可能关联一个服务来自于同一台服务器超时引起，也有可能是来自于同样的客户端设备因为页面加载适配问题等。所以说，未来的方向重点在于数据和算法结合起来，挖掘更大的价值。
InfoQ：感谢万传奇老师接受我们的采访，更多精彩内容请锁定 4 月 20~ 22 日的 QCon 北京站。目前 8 折报名倒计时 5 天，立减 1360 元，点击「阅读原文」查看大会日程安排，与国内外一线技术大咖碰撞思维火花。
（本文转自微信公众号：InfoQ）
