flink实时数仓保障体系

1：查看kafka延迟监控：flink 消费上游的 lag（比如看消费 kafka lag 情况）
2：分层和时延之间做好平衡和取舍，既需要保证复用性，又要避免造成链路过长。
3：乱序数据的处理。
4：提前压测，应对流量高峰期，特别是大促场景下，提前做好资源保障、任务优化等措施。
5：设置好延时基线，通过优化程序代码、资源、解决倾斜与反压等问题，使其控制在base line之内。
6：指标监控，监控任务failover情况、checkpoint指标、GC情况、作业反压等，出现异常告警。
7：Flink链路延迟监控的LatencyMarker观测延迟情况。

## 数据一致性
1：正确性实时计算端到端的一致性，对数据正确性的影响，常用手段就是通过输出幂等方式保障，这种方式要求输出使用存储介质支持重写，对于不支持幂等的存储，比较常用的就是DWD层的kafka， 可能会产生重复的数据，那么在下游使用的时候可以使用row_number() 语法进行去重，保证相同的key不会被多次计算；
2：离线与实时的一致性，需要保证使用数据源一致、加工业务逻辑一致。
## 数据完整性:
目标有效数据从数据源头到数据加工再到前端数据展示，不能因为加工逻辑权限，存储异常，前端展现异常等原因导致数据丢失。例如：
1:数据源层出现背压时，导致数据源头（MQ,KAFKA）消息积压，积压严重时导致资源耗尽，进而导致数据丢失；
2:数据处理层数据加工未按照需求进行加工，导致目标有效数据丢失；
3:数据存储层的存储容量写满时，导致新数据无法继续写入导致数据丢失；
4:数据加工正确性、数据加工及时性、数据快速恢复性构成数据完整性；
## 数据加工正确性：
目标源数据按照业务需求加工成目标有效数据，目标有效数据根据不同维度不同指标计算成需要展示的不同指标数据。例如：
1:数据源层原始数据包含不同联盟的点击数据，那么数据处理层过滤掉不需要的联盟点击数据，并将目标联盟的点击数据根据媒体和创意信息补齐当前点击所属的账号、计划、单元；
2:业务层根据媒体，账号、计划、单元不同维度计算出对应的点击总量；
## 数据加工及时性：
目标源数据从产生到前端展示的时间需要控制合理的时间范围内；
## 数据快速恢复性：
数据在流转路径中因为异常导致流转中断，数据停止在某一个环节中，当异常解决，系统恢复正常时，停止的数据（停止的数据）需要快速恢复流转，并且这种恢复是正确的，不应该存在重复的消费和加工或者遗漏。例如：
1:数据处理层因为消费程序性能问题导致消息积压，性能问题解决后数据挤压问题逐步得到缓解直到恢复正常水平；
2:数据处理层因为消费程序bug导致程序崩溃，重启后数据消费正常；
## 数据可监控性：
数据流转路径中关键节点的关键状态可以有效监控；
## 数据高可用性：
数据不能因为灾难性的问题导致丢失造成不能使用的情况，因此需要考虑实时数据消费应用集群和存储集群的主备和可容灾;

https://blog.csdn.net/weixin_44275820/article/details/119892620

任务压测
提前压测应对流量高峰期，特别是大促场景下，提前做好资源保障、任务优化等措施。
任务分级
制定保障等级，从任务影响面大小、数据使用方来划分，一般情况公司层面优先于部门层面，外部使用优先于内部使用， 高优先级任务需要优先/及时响应、必要情况下做双链路保障机制；
做好指标监控
指标监控，监控任务failover情况、checkpoint指标、GC情况、作业反压等，出现异常告警。
高可用HA
整个实时Pipeline链路都应该选取高可用组件，确保理论上整体高可用；在数据关键链路上支持数据备份和重演机制；在业务关键链路上支持双跑融合机制
SLA保障
在确保集群和实时Pipeline高可用的前提下，支持动态扩容和数据处理流程自动漂移
弹性反脆弱
基于规则和算法的资源弹性伸缩；支持事件触发动作引擎的失效处理。
监控预警
集群设施层面，物理管道层面，数据逻辑层面的多方面监控预警能力
自动运维
能够捕捉并存档缺失数据和处理异常，并具备定期自动重试机制修复问题数据
上游元数据变更抗性
上游业务库要求兼容性元数据变更；实时Pipeline处理显式字段。

人力成本
通过支持数据应用平民化降低人才人力成本
资源成本
通过支持动态资源利用降低静态资源占用造成的资源浪费
运维成本
通过支持自动运维／高可用／弹性反脆弱等机制降低运维成本
试错成本
通过支持敏捷开发／快速迭代降低试错成本

敏捷大数据是一整套理论体系和方法学，在前文已有所描述，从数据使用角度来看，敏捷考量意味着：配置化、SQL化、平民化。