这一年多来，阿里Blink测试体系如何从0走向成熟？

这一年多来，阿里 Blink 测试体系如何从 0 走向成熟？

阿里妹导读： Blink是面向数据流处理和批处理的分布式开源计算框架，它支撑了阿里集团上千个业务的大数据实时处理，为了保障 Blink 的可靠性，2017年，搜索事业部的质量团队成立了 Blink 测试小组，从无到有，逐步建立起完善的Blink测试体系，全方位保障了Blink质量。

引言

Apache Flink是面向数据流处理和批处理的分布式开源计算框架，2016年阿里巴巴引入Flink框架，改造为Blink。2017年，阿里整合了所有流计算产品，决定以Blink引擎为基础，打造一款全球领先的实时计算引擎。当年双11，Blink支持了二十多个事业部／群，同时运行了上千个实时计算job，每秒处理的日志数峰值达到惊人的4.7亿。因此Blink的可靠性和稳定性保障变得极其重要，搜索事业部的质量团队为此专门成立了 Blink 测试小组，通过一年多的努力，建立了从代码质量到持续集成再到预发测试的全面的测试体系，帮助 Blink 的质量取得大幅提高。

Blink测试平台介绍

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

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

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

代码质量校验阶段

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

功能测试

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

1、case的统一调度与精细化管理：现在Blink在defender上有12个场景4000多个case，可以每天定时进行dailyrun，如果某一类别的case出现问题可单独执行，并可在页面上显示详情。

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

3、case灵活配置：不仅可以支持系统配置，对每个case集所需资源（slot，memory等）或集群其他配置的不同进行单独配置。

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

5、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运行时间，模块性能测试主要包含网络层性能测试，调度层性能测试， failover 性能测试等，更关注在特定场景下job的处理时间。

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

稳定性测试

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

我们把异常场景分为两类：一类是"黑猴子"，该类场景与运行环境相关，包括机器重启、网络异常、磁盘异常、cpu异常等，这部分异常主要用shell命令来模拟；另一类异常是"白猴子"，此类场景与Blink job相关，包括rpc消息超时，task异常，heart beat消息超时等，主要通过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执行引擎的版本提供依据。目前，兼容性测试主要分为静态检查和动态运行两个阶段，其中，静态检查是整个兼容性测试的基础。

静态检查

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

1. 新的执行引擎生成执行计划的正确性及生成执行计划的时间长短。

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

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

动态运行测试

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

展望

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