blink测试技术介绍

摘要：blink测试团队成立一年多的时间，从无到有，逐步创建起完整的blink测试体系，从代码质量到集成测试再到预发测试，全方位保障blink质量，取得了显著的成果。

引言：

flink是面向数据流处理和批处理的分布式开源计算框架。2016年阿里巴巴引入flink框架，改造为blink，将其运用到搜索及推荐的离线实时计算中，成功解决了搜索、推荐实时大数据量计算的痛点。2017年5月，集团整合了全部流计算产品，决定以blink引擎为基础，打造一款全球领先的实时计算引擎。2017年的双11，blink支持了20多个事业部／群，同时运行了1100+实时计算job，每秒处理的日志数峰值达到惊人的4.7亿。集团内部Blink用户群已经超过1400+的开发同窗。所以blink质量保障变得极其重要，blink测试团队成立一年多的时间，从无到有，逐步创建起完整的blink测试体系，全方位保障blink质量。

Blink测试平台介绍

blink测试团队为blink质量量身打造blink测试平台，内容以下图所示：

blink测试平台包含了三个测试阶段： 代码质量校验阶段，主要进行静态代码扫描、单元测试和基于minCluster的测试；集成测试阶段主要是进行功能测试、性能测试和带有破坏性的稳定性测试；而预发测试阶段，主要是利用用户的job进行仿真测试，并在版本发布以前作最后的版本兼容性测试。

平台选取部分测试集合归入到precommit的验证中，可尽早发现代码中问题，而大规模的功能、性能、稳定性测试，一般做为dailybuild的集合。另外，blink测试平台创建了较为完善的质量度量体系，除去对代码覆盖率的统计及变化的分析，还可一键生成测试报告，并对不一样版本的质量进行横向对比。

代码质量校验阶段：

代码质量校验阶段是整个blink质量保障的基础。主要包含单元测试，利用aone提供的"集团代码规约扫描"工具对代码进行规范扫描，单机运行的基于minicluster的集成测试，只有这三个阶段都测试经过后才容许blink代码提交到项目git。

功能测试：

blink功能测试框架使用defender，该框架是由pytest[1]改造而来，很好的支持了blinkSql测试的特性，并支持第三方插件的引入。在测试集群中能够端到端的对某一场景进行精准测试。具体流程以下图所示，支持IDE和Jenkins两种触发模式，yarn_job、yarn_session和local三种case运行调度模式。执行结束后经过web页面或邮件的形式对结果进行展现，并对运行结果进行持久化。具备以下优点：

一、case的统一调度与精细化管理：如今blink在defender上有12个场景4000多个case，能够天天定时进行dailyrun，若是某一类别的case出现问题可单独执行，并可在页面上显示详情信息。

二、case的三种运行模式知足了不一样场景的测试需求：其中yarn_session模式对一个模块中存在sqlCase的场景较为适用，可大大减小与Yarn交互的时间。

三、case灵活配置：不只能够支持系统配置，对每一个case集所需资源（slot，memory等）或集群其余配置的不一样进行单独配置。

四、一个case可同时支持批和流两种运行类型。

五、client类型灵活扩展：可对现有数据存储和服务进行集成和扩展。现已支持多类型data store读写服务，yarn_session的启动，blink job交互等。

性能测试：

Blink做为实时大数据处理引擎，其对单位时间内的数据处理能力和数据处理的实时性提出了很是严苛的要求。所以，性能测试是整个Blink测试中很是重要的一环，是衡量Blink新版本可否发布的核心标准之一。

Blink的性能测试主要包含Operator性能测试、SQL性能测试和runtime性能测试：

Operator指构成SQL语义的一个原子操做，例如Sum，Aggregate等，是一个不能再分割的算子。Operator的性能测试主要用于监控单个算子在整个开发过程当中的性能变化，以保证局部处理的优化和提升。目前，Operator的测试分红两个部分：单个算子的性能测试和算子组合的性能测试。Operator测试以Daily Run的方式反馈性能的变化。

SQL性能测试主要用于监控版本开发过程当中单个SQL的性能变化。TPCH和TPCDS是业界SQL标准性能测试集，分别有22和103个测试用例。测试平台将其引入到blink性能测试中，以更全面地衡量blink的性能变化。

Runtime性能测试主要为了保障runtime层面性能不回退，主要包含端到端性能测试和模块性能测试。端到端性能测试首先根据梳理出测试场景，关注各场景job在指定数据量下的job运行时间，模块性能测试主要包含网络层性能测试，调度层性能测试，faliover性能测试等，更关注在特定场景下job的处理时间。

性能测试将来规划是将E2E性能测试，模块级别性能测试和参数调整总体联动起来，使其可以更好协助开发定位性能问题root cause和查看参数调优效果。

稳定性测试：

对于支持高并发、多节点，集群物理环境复杂的分布式系统来讲，相似磁盘打满、网络延迟等物理节点的异常很难避免。Blink做为一个高可用的分布式系统，必然要作到在异常状况下也能保证系统的稳定运行及数据的正常产出。“避免失败的最好方法就是不断地失败”，所以，在Blink任务运行期间将可能发生的异常模拟出来，就可以验证blink的稳定性。

咱们把异常场景分为两类：一类是"黑猴子"，该类场景与运行环境相关，包括机器重启、网络异常、磁盘异常、cpu异常等，这部分异常主要用shell命令来模拟；另外一类异常是"白猴子"，此类场景与blink job相关，包括rpc消息超时，task异常，heartbeat消息超时等，主要经过byteman[2]软件注入的方式来实现。在稳定性测试中，monkey做为调度会随机选取上述异常场景进行组合，以模拟线上可能出现的全部异常场景。

考虑到blink支持任务failover的特性和稳定性测试的自动运行，咱们把稳定性测试设定为一轮轮的迭代循环，每一轮迭代都包含释放出monkey，提交任务，等待job恢复，校验四个阶段，校验主要包含checkpoint，container及slot资源等是否符合预期，校验失败就报警，校验成功后经过后进入下一轮迭代，以验证任务在长时间运行下的任务稳定性。

稳定性测试架构分为四层：组件层主要包含测试blink job，monkeys和dumper；action层包含job启动，状态校验，输出校验等；执行层包含service，monkey操做等，monkey操做时会根据ssh到具体机器，执行monkey操做；最上层是WebUI。详情以下图所示：

预发测试

Blink预发测试阶段主要经过克隆线上的真实任务和数据来进行复杂业务逻辑和大数据量的测试。 所以，Blink 预发测试是对代码质量校验和集成测试的补充以及整个测试流程的完善，是blink版本发布的最后一道关卡。

Blink预发测试主要分为两个部分：仿真测试和兼容性测试。

仿真测试

仿真测试对Blink的功能、性能和稳定性等基础测试指标进行进一步地衡量，并将开发中的版本与当前的线上版本进行横向比较。所以，仿真测试可以尽早发现各类功能、性能退化和稳定性问题，从而提升上线版本的质量。

仿真测试主要分为环境克隆，环境适配和测试运行三个阶段：

环境克隆

环境克隆是实现整个仿真测试的基础，包括线上任务的挑选、克隆和测试数据的采样。

Blink的线上任务分散在多个不一样的工程中，数量较多。虽然，每个线上任务都有其内在的业务逻辑，可是，不一样的任务能够根据其主要的处理逻辑进行归类，例如，以Agg操做为主的任务集合，以Sum操做为主的任务集合等，所以，Blink仿真测试须要对线上任务进行甄别，挑选出其中最具备表明性的任务。

仿真测试的测试数据集是当前线上任务输入数据的采样，仅在数据规模上有差别，而且，能够根据测试需求的不一样进行动态地调节，从而实现对测试目标的精确衡量。

环境适配

环境适配是仿真测试过程当中的初始化阶段，主要进行测试用例的修改，使其可以正常运行。该过程主要包括两个步骤：更改测试数据输入源和测试结果输出地址和更新任务的资源配置。

测试运行

测试运行是仿真测试流程中的实际执行模块，包括测试用例的运行和结果反馈两个部分。

Blink仿真测试包括功能测试、性能测试和稳定性测试等模块，不一样的测试模块具备不一样的衡量标准和反馈方式。这些测试模块的测试结果与代码质量校验和集成测试的结果一块儿构成Blink测试的结果集。

性能测试和功能测试以仿真任务和采样数据做为输入，对比和分析任务在不一样执行引擎上的执行过程和产出。其中，性能测试重点考察执行过程当中不一样执行引擎对资源的利用率、吞吐量等性能指标。功能测试则将执行的最终结果进行对比。须要特别指出的是，在功能测试中，线上版本的运行结果被假定为真，既当线上版本的执行结果与开发版本的执行结果不一样时，认为开发版本的执行存在错误，须要修复开发中引入的错误。

稳定性测试重点关注仿真测试任务在线上克隆环境、大数据量和长时间运行条件下的稳定性。其以Blink开发版本做为惟一的执行引擎，经过收集执行过程当中的资源利用状况、吞吐量、failover等指标来进行度量。

兼容性测试

Blink兼容性测试主要用于发现Blink新、旧版本之间的兼容性问题，从而为线上任务升级Blink执行引擎的版本提供依据。目前，兼容性测试主要分为静态检查和动态运行两个阶段，其中，静态检查是整个兼容性测试的基础。

静态检查

静态检查主要用于分析线上任务在不一样执行引擎下生成执行计划的不一样，包括两个方面的内容：

一、新的执行引擎生成执行计划的正确性及生成执行计划的时间长短

二、新、旧版本的执行引擎生成的执行计划是否兼容

在静态检查中，若新的执行引擎不能正确的生成执行计划，或者生成执行计划的时间超出预期，均可以认为静态检查失败，Blink新版本中存在异常或者缺陷，须要查找缘由。当新版本可以正确地生成执行计划时，若新、旧版本的执行引擎生成的执行计划不兼容，那么，须要将对比结果反馈给开发人员以判断该执行计划的更改是否符合预期；若执行计划兼容或者执行计划的更改符合预期，则能够直接进行运行时测试。

动态运行测试

Blink动态运行测试利用仿真测试中的功能测试模块来进行任务的运行，是升级Blink新版本以前的最后一轮测试。若任务可以正常启动且测试结果符合预期，则认为该任务能够自动升级，反之，则须要人工介入进行手动升级。

展望

经过一年多的努力，blink总体质量已经有很大幅度的提升，blink的测试方法和工具也愈来愈成熟，blink回馈社区之际，咱们会逐步将测试工具一块儿输出，回馈更多的社区开发测试者，与此同时，随着blink用户群的壮大，blink业务开发者对于业务任务的质量保证须要日渐高涨，blink测试团队将来会提供更多质量保证和开发效率工具，进一步提高blink开发者工程效率。

本文做者：溶月

阅读原文

本文为云栖社区原创内容，未经容许不得转载。