由于最近公司的实时数据处理引擎再向Flink迁移，所以专门设计、总结了一篇“基于Flink的实时数据消费应用/功能质量保障方法”。欢迎大家一起分享探讨在大数据方面的测试方法和经验。
什么是Flink？
Apache Flink是由Apache软件基金会开发的开源流处理框架，其核心是用Java和Scala编写的分布式流数据流引擎。Flink以数据并行和流水线方式执行任意流数据程序，Flink的流水线运行时系统可以执行批处理和流处理程序。此外，Flink的运行时本身也支持迭代算法的执行。
为什么在实时数据处理，分析场景下要选择Flink？
Flink 是目前唯一能同时集高吞吐、低延迟、高性能三者于一身的分布式流式数据处理框架。Apache Spark 只有高吞吐、高性能。因为Spark Stream 做不到低延迟，本质还是微批处理。Apache Storm 只有低延迟、高性能，但达不到高吞吐。
Flink的优点
同时支持高吞吐、低延迟、高性能；
支持事件事件(Event Time)概念
支持有状态计算
支持高度灵活的窗口(Window)操作
基于轻量级分布式快照实现的容错
基于JVM实现独立的内存管理
Save Points的实现
关于Flink的基础介绍可以查看链接：https://flink.apache.org/
实时数据消费应用中数据的一般流转路径
要保障实时数据消费应用的质量，首先需要清楚基于实时数据加工的业务链路是怎样的，数据流转路径是怎么样的。
原始数据层
可以理解为上游原始数据，这对我们整个消费应用来说除了数据本身外其他都是黑盒，不可见的。目前我们消费应用接入的数据源提供方式常见的有KAFKA，MQ。
数据处理层
整个数据流转路径的核心，负责根据业务需求将原始数据进行处理并转发。处理实时数据的应用框架可以是Flink，Storm,Spark streaming等。
数据存储层
加工后的数据存放的地方，业务功能可以在这里取到需要使用的数据。一般可以为基于内存的key-value数据库redis，列式数据库ClickHouse，也可以将数据转发至另一个数据通道中。
业务层
负责具体使用数据，在这里可以对数据进行业务层面的处理。
可视化层
负责展示数据，也就是数据可视化。
质量目标
根据实时数据的应用场景和实时数据相关业务链路，实时数据消费应用的质量目标包括以下几点：
数据完整性:目标有效数据从数据源头到数据加工再到前端数据展示，不能因为加工逻辑权限，存储异常，前端展现异常等原因导致数据丢失。例如：
数据源层出现背压时，导致数据源头(MQ,KAFKA)消息积压，积压严重时导致资源耗尽，进而导致数据丢失；
数据处理层数据加工未按照需求进行加工，导致目标有效数据丢失；
数据存储层的存储容量写满时，导致新数据无法继续写入导致数据丢失；
数据加工正确性、数据加工及时性、数据快速恢复性构成数据完整性；
数据加工正确性：目标源数据按照业务需求加工成目标有效数据，目标有效数据根据不同维度不同指标计算成需要展示的不同指标数据。例如：
数据源层原始数据包含不同联盟的点击数据，那么数据处理层过滤掉不需要的联盟点击数据，并将目标联盟的点击数据根据媒体和创意信息补齐当前点击所属的账号、计划、单元；
业务层根据媒体，账号、计划、单元不同维度计算出对应的点击总量；
数据加工及时性：目标源数据从产生到前端展示的时间需要控制合理的时间范围内；
数据快速恢复性：数据在流转路径中因为异常导致流转中断，数据停止在某一个环节中，当异常解决，系统恢复正常时，停止的数据(停止的数据)需要快速恢复流转，并且这种恢复是正确的，不应该存在重复的消费和加工或者遗漏。例如：
数据处理层因为消费程序性能问题导致消息积压，性能问题解决后数据挤压问题逐步得到缓解直到恢复正常水平；
数据处理层因为消费程序bug导致程序崩溃，重启后数据消费正常；
数据可监控性：数据流转路径中关键节点的关键状态可以有效监控；
数据高可用性：数据不能因为灾难性的问题导致丢失造成不能使用的情况，因此需要考虑实时数据消费应用集群和存储集群的主备和可容灾;
数据可监控性中有哪些有效的监控点
数据源层有效监控有：
消息挤压监控；
重试监控(消费失败，网络超时);(“重试”官方解释主要用于对业务系统临时处理不了的消息进行存放，然后再按照一定的策略投递给客户端处理。可以提供错误原因、错误处理次数等查询。)
数据处理层有效监控有:
重启监控:Flink消费应用出现异常导致重启；
checkpoint失败监控：保存应用当前最新状态失败；
背压监控：上游因为下游原因出现背压；
节点资源监控(CPU利用率，内容使用率，网络情况，磁盘使用率等)；
数据存储层有效监控有：
已使用内存量监控；
主从一致性监控：主从同步延迟，写数据同时读取数据，可能会读取到不一致的脏数据；
热key监控；
大key监控；
业务层有效监控有:
系统存活监控；
接口可用率监控；
特定方法自定义监控；
质量目标分布
在整个实时数据加工流程中，并不是所有的环节都需要达成相同的质量目标。将质量目标分布在不同的加工环节上；
从质量目标的分布上看质量目标主要集中在数据处理层，这也客观的反映了在整个实时数据消费应用的数据流转路径中“数据处理层”是核心的特点。
如何守住质量目标(划重点！)
1.原始数据层
由于“原始数据层”在整个数据流转路径中担任的是原始数据提供方的角色且具体的数据产生逻辑和方式对于下游来说完全是个黑盒。所以在这里我们需要做好对数据源的监控，至少需要具备消息积压监控，且积压阈值需要准确的设置，设置过高会导致下游数据延迟时间已经超时合理范围但上游积压告警还未出现。
2.数据处理层
如何守住数据正确加工？
基于Flink的实时数据消费应用是不存在功能接口供测试人员从功能角度进行验证的，且复杂场景下，对一条消息的处理会存在多个计算逻辑(多个算子)，因此如何保障加工逻辑的覆盖度变得非常重要。
要保证加工逻辑的覆盖度就需要清理出数据加工路径，按照等价类划分的方法构造出不同路径下的样例数据，进行覆盖。确保线上运行时正常，异常数据应用都可以正常处理。至于覆盖测试如何进行可以使用Flink-spector，一种应用于Flink程序的单元测试框架。为了进一步保证程序的健壮在数据加工路径覆盖测试完成后可以对代码进行静态扫描。以上是从白盒角度对加工路径进行覆盖进行加工准确性的保证。另一种是从黑盒功能性的角度进行加工准确性的验证；
Flink实时消息消费应用通过不同算子对数据的加工，这些算子可以转换成SQL，测试人员可以根据PRD中数据指标的具体口径进行提数和实时加工应用的数据进行对比。(注意此方法不仅在上线前可以当做数据正确加工验证的测试方法，也可以在上线后当做数据正确加工的监控手段。)
如何守住数据快速恢复？
Flink框架自带保证程序的容错恢复和程序启动时其状态恢复，checkpoint和savepoint，测试人员需要根据具体的实时消费场景判断程序是否正确配置了相关内容。
(注意检查完checkpoint配置后在测试环境中运行后，一定要在Flink UI中查看Checkpoint耗时，如果Checkpoint配置有问题，或者状态很大的情况发生，会极大的影响消费性能。导致积压)
如何守住数据及时加工？
数据及时加工反应的其实是实时数据消费的性能，对实时消息消费应用的性能测试可以从以下几个方面入口：
单算子性能测试：Flink应用程序是由不同算子组成，如果一个算子对一条消息处理的性能本身就存在问题，那么整个链路的性能也不会好到哪里去。
多算子性能测试：多个算子的协作完成了对一条消息的处理，因此需要衡量多个算子处理完一条数据的性能
(注意单算子或多算子的性能在上线前需要测试外，上线后还需要做到持续的监控)如下图：
仿真性能测试：使用真实数据对实时消息消费应用集群进行测试，观察消费的性能表现。目前一般的做法可以是调整上游消息的位点；高保真流量回放
数据采样性能测试：从线上真实数据中取出目标数据，并积累到一定数量后对实时消息消费应用进行测试。在仿真测试中线上流量对应的数据可能有大部分是我们加工逻辑中直接被过滤掉的，这种情况下剩下的部分数据并没有起到性能测试的作用；实现方法如下图：
另外在性能测试中，并不能单单只看消息的积压层度，还需要观察集群的内存使用率，cpu利用率，网络流入、流出速率，磁盘使用率等指标的展现；
如何守住高可用？
对于支持高并发、多节点，集群物理环境复杂的分布式系统来说，类似磁盘打满、网络延迟等物理节点的异常很难避免。高可用反映的其实是消费应用的稳定性，通常做法就是现在使用到的故障模拟演练。包括机器重启、网络异常、磁盘异常、cpu异常。在故障发生时应用依然可能正常运行。
3.数据存储层
数据存储层主要作用是数据存储并没有数据处理的逻辑，因此数据存储层主要质量目标还是存在于监控和高可用上。
4.业务层和可视化层
业务层会设计数据的二次加工，这部分数据加工的正确性可以使用功能测试完成，也可以进一步的使用单元测试提高覆盖度。
还需要进行幂等性测试，因为Flink保证数据一致性，正确性的手段均是针对Flink本身。即使Flink有checkpoint和savepoint的保障机制，也需要保证下游数据的幂等性。
总结
根据前几点我们汇总出基于flink的实时数据消费应用的质量保障思维导图：
扫一扫
606
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
