目前，字节跳动数据质量平台对于批处理数据的质量管理能力已经十分丰富，提供了包括表行数、空值、异常值、重复值、异常指标等多种模板的数据质量监控能力，也提供了基于spark的自定义监控能力。另外，该平台还提供了数据对比和数据探查功能，为用户在数据开发阶段 及时发现 数据质量问题提供了便利的手段。 本文 分上下两 次连载 ，作者 系 字节跳动数据平台开发套件团队高级研发工程师于啸雨 。
长期以来，数据质量平台的各项能力都只支持batch数据源（主要是Hive），没有流式数据源（如kafka）的质量监控能力。 但其实流式数据与batch数据一样，也有着数据量、空值、异常值、异常指标等类型的数据质量监控需求，另外因流式数据的特殊性，还存在着数据延迟、短时间内的指标波动等特有的监控需求。
此前部分数据质量平台用户为了监控流式数据质量，选择将流式数据dump到hive，再对hive数据进行监控。但这种方式的实时性较差，若有数据质量问题，只能在T+1后报出。且对于很多流式任务的“中间”数据，原本不需要落地，为了监控而落到hive，存在着大量的资源浪费。
为更好地满足流式数据用户的数据质量监控需求，同时填补数据质量平台在流式数据源方面的空白，字节跳动数据质量平台团队于2020年下半年，以Kafka数据写入延迟监控为切入点，陆续调研、开发、上线了一系列基于Flink StreamSQL的流式数据质量监控。
本文为系列文章的上篇，重点介绍 字节跳动数据质量平台 技术调研及选型的思考。
DataLeap
产品调研
在2020年下半年，我们决定支持流式数据的质量监控，随即开展了业内的技术调研。主要基于公开的分享或文档资料，调研了Apache Griffin，以及其他四家厂商对应的产品。
调研分析了相关友商的计算引擎、主要技术实现、产品形态、数据落地形式等，调研的汇总结果如下表所示：
| Apache Griffin | ||||
| M厂 | ||||
| W厂 | ||||
| D厂 | ||||
| 计算引擎 | ||||
| Spark | ||||
| Flink | ||||
| Spark | ||||
| Spark + deequ + delta lake | ||||
| 主要技术实现 | ||||
| 将流转为batch，基于batch数据做计算。 | ||||
| Flink中两个窗口聚合。 | ||||
| Spark收集审计数据，发到审计中心。 | ||||
| 在spark streaming程序中，由deequ分析器对datafram做计算。 | ||||
| 产品形态 | ||||
| 配置化、平台化 | ||||
| 平台化 | ||||
| 提供SDK，需用户写代码，编写分析器。 |
调研主要结论
1、各产品的计算引擎均使用Spark或Flink，二者都能解决需求，在稳定性和性能上也没有显著的差异。实际上各产品在计算引擎选取方面，主要考虑的是已方的技术栈、技术积累、计算引擎与已方技术架构的融合度等。如D厂的主要业务是做Spark的商业化产品，引擎自然地使用Spark；M厂的相应产品产生的背景也是基于Flink在该厂的应用和推广。
2、除Apache Griffin由于采用了先流转批、再复用批处理能力的策略，指标产出延迟为分钟级外，其它指标产出延迟均为秒级。需注意的是指标产出延迟并非报警的延迟。实际报警的延迟时间还受所采用的报警引擎的触发方式、轮询执行周期等影响。
3、各产品均未由计算引擎直接触发报警，而是由计算引擎计算出对应的数据质量指标数据，存到下游sink后，再基于sink中的数据，检测及触发报警。同时还可基于sink中的数据提供灵活的报表、可视化服务。这其实是业内较为普遍的作法，即计算引擎只负责计算，后续监控和报警功能由专门的监控报警引擎负责。
DataLeap
技术选型结果
选型Flink SQL
基于上述友商调研，考虑到当前字节跳动在流计算方面主要的计算引擎为Flink，在kafka/各类MQ - Flink的数据流实时计算方面已经有了很多的技术积累，使用Flink的接入成本相对更低，且能获得更充足的技术支持，我们决定选择Flink作为流式数据质量监控的计算引擎。
确定使用Flink为计算引擎后，在实际实现时，仍有两个选择：可以使用Flink SQL API，也可以使用更为底层的Flink DataStream API。
我们最终决定选择使用Flink SQL API，原因如下：
从性能上看 ，使用SQL API不会比使用DataStream API性能差。Flink SQL最终也会编译成Java代码执行，二者并无本质差别。
从功能上看 ，当前Flink SQL的语法已经很丰富，支持kafka、RocketMQ等常用流式数据源和MySQL、TSDB等sink。另外字节跳动Flink团队也会根据公司内用户的需求，开发一些定制化的功能，如支持kafka header数据字段等。Flink SQL能够满足大部分的流式数据质量监控的功能需求。
从使用友好程度上看 ，在进行规则配置转化时，SQL API相对DataStream API更友好，更易于实现，更便于调试。在增加新的流式监控类型和新feature时，开发人员主要需考虑如何拼SQL计算对应的监控指标，且可直接使用Dataleap数据开发平台的Flink SQL作业进行调试。另外，直接使用SQL API，更容易支持用户自定义SQL指标的监控规则。
本系列文章将会涉及到的技术方案和能力已通过 火山引擎大数据研发治理套件DataLeap 面向企业开放。在下篇中，将重点分享我们基于Flink SQL的流式数据质量监控的实践细节。
点击
阅读原文
了解产品详情
产品介绍
火山引擎大数据研发治理套件DataLeap
一站式数据中台套件，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，帮助数据团队有效的降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。 后台回复数字“2”了解产品
附-本文参考资料
http://griffin.apache.org/docs/profiling.html
How to Monitor Data Stream Quality Using Spark Streaming and Delta Lake
https://github.com/awslabs/deequ
- End -
