1. 概念：

在数据系统诞生之日起，对数据的接入，落地，计算，存储，价值传递每个过程中，需要对每个环节做出一定的效率和合理性的思考

2. 环节把控

2.1 数据接入时

1. 数据源数量的检查
   可以针对不同的数据源头对数据量提前做一个预估，比如每秒多少条，每秒多少M等？不符合告警
2. 数据源头数据格式规范检查
   与数据源约定好数据格式，并读取做出检查，不符合规范告警

2.2 数据源落地

1. 数据落地时间的检查
   不管数据落地到hdfs，还是消息队列，如果对数据落地时间和业务时间由于链路传输或者接入程序的问题，导致相差太远不可容忍的话（实时要求高），需要检查
2. 落地数据量的检查
   如果数据源中存在重复数据或者数据的分割符不清晰，导致接入的时候和落地时数据量不一致，可以考虑检查

2.3 数据计算

1. 计算任务有没有正常启动
   比如任务可能有长驻任务，也可能有定时任务，需要对常驻任务周期检查是否运行，定时任务检查是否定时启动等
2. 监控每个任务的运行时间
   根据不同的任务，预估任务的运行时间，不符合告警

2.4 结果存储

1. 根据业务场景，设置业务数据优先级别，检查重要的报表数据是否在规定的时间生成
2. 根据不同的业务需求，对每次计算结果数据量检查，比如波动运行在 1% ~ 3%为合理
3. 检查结果的数据质量，一般需要结果业务经验，设置合理的同比或者环比来设置合理的阈值，合理监控告警

3. flink数据质量保障（实时数仓）

针对项目：

事前

1. 做好压测，flink官方提供了压测模拟数据源，保障资源在高峰没有瓶颈
2. 测试时，对实时和离线都有的指标进行结果对比，保证数据一致性

事中

做好监控，告警
kafak 使用 kafak eagle，关注是否出现kafka的数据积压
prometheus + grafana 监控flink 作业的运行情况

事后

1. 能重跑就重跑（比如flink消费kafka，可以指定时间点消费）
2. 如何集群资源充沛，可以考虑使用备用链路，即上限任务失败，立即启动备用链路
3. 允许离线任务和实时任务有 1% ~3%的任务偏差

4. 离线数仓

自己写SQL维护，并结合后端工程师的springboot项目，提供置空率，指标波动等告警
离线数仓中做的：空值数据量的控制，重复数据指控，事实表的度量值或者指标结果值的阈值控制，数据量的同比和环比检测