加入收藏 | 设为首页 | 会员中心 | 我要投稿 滁州站长网 (https://www.0550zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 大数据 > 正文

数据治理之路-第二篇-数据质量之路

发布时间:2022-12-05 15:31:13 所属栏目:大数据 来源:转载
导读: 数据质量定义
数据准确性这个词有点太过于抽象,下面我们就一起把数据准心具象化。
对准心进行分解 有衍生出2个抽象名称进行定义。一个是数据稳定性和数据准确性。下面进行场景说明进行更好

数据质量定义

数据准确性这个词有点太过于抽象,下面我们就一起把数据准心具象化。

对准心进行分解 有衍生出2个抽象名称进行定义。一个是数据稳定性和数据准确性。下面进行场景说明进行更好理解。

大数据架构图_大数据技术架构_cio面临大数据架构的选择困境

场景说明我们先开始谈谈数据稳定性

那如何进行稳定性保障内。我认为应该从2个方面 技术+策略展开。

架构图

工欲善其事必先利其器。我们下面开始对于技术这个层次进行剖析。下面先看看本人设计的关于数据稳定性的架构图。

大数据技术架构_cio面临大数据架构的选择困境_大数据架构图

流批一体

基于spark引擎 自研一套通过抽象 input-filter-output 三层进行配置化开发。解决异源同构以及开发者与底层架构解耦 让业务开发人员关注业务价值。后面文章会对该架构进行开源剖析,有兴趣的可以留言。

调度集群

基于海豚调度3.0 进行二次开发。担任的是哨兵的角色。监控作业的运行状态,根据策略进行状态判断是否需要告警(事后的处理方式)。那我们下面讲讲关于策略。

策略

我们分为3种 一种是基于时间基线来保证任务能按照指定时间完成,任务状态是保证作业异常情况下的恢复机制 而最后一种是基于统计是为了后续优化点和风险点进行待办优化点。

时间基线 根据我们的业务对数据进行4层伐分。每层都规定时间段。比如dwd的运行时间是1小时,当该层运行时间超过一小时则进行预警。避免造成数据不出来。任务状态 是根据流批一体架构对于异常的处理进行上抛。上抛的异常信息归结有2种 一种是基于业务异常另一种是基于系统异常。基于业务异常1.基于数据异常

是根据业务数据特点,对流批一体增加一个数据质量拦截。对于业务数据异常 进行上抛 避免当数据异常影响下游情况。比如 当业务系统业务导致拉取数据为空,对于空的数据经过数仓每层的装换,必然导致数据结果的错误。虽然数据质量可用对最终数据进行异常检测 但是那属于事后 恢复周期较长。

2.基于系统异常

当运行spark 任务的时候 会来着底层组件的异常 或者 hadoop 本身集群的异常或者网络抖动导致task 经常性失败。对该类异常进行统一捕获进行上抛。基于统计

该方式主要通过分析作业的运行效率已经运行周期和历史状态进行分析。研判出风险作业进行集中回顾和解决。把问题杀死在摇篮中的一种机制。

上面讲了 我通过一些策略进行发现问题。但是总不能发现问题就打电话吧 有些并不是那么重要。所以 发现问题后 我们就对这些问题进行分类以及划分优先等级。从而进行不同方式的预警。下面另一个话题是告警等级划分。怎么划分呢?

告警等级体系

自上而下 业务重要度以及报表重要度2个原则进行划分。举个例子 财务的优先级>运营指标 一个报表每天的访问量前十 并且一出问题 群里都还是‘天翻地覆’造成积极响应的。

待完善

技术

上面讲了那么多的策略和告警体系。作为开发或者作为测试我们应该怎么做呢。下面开始拿干货了。

基于时间线

大数据技术架构_cio面临大数据架构的选择困境_大数据架构图

公司测试环境 由于有些敏感 只给出一部分

我们通过横向分层纵线分主题域的形式,每个主题域都封装在一个流程内。每个流程包含多个的主题。我们是根据对一个主题域进行时间基线的管控。基于调度自带的超时告警机制进行设置。

大数据架构图_大数据技术架构_cio面临大数据架构的选择困境

设置主题域的超时时间界面当主题域运行时间超过所设置的基线时间 则进行对流批一体架构的所有任务进行关闭处理 并进行上报异常。

基于任务状态

基于业务特征进行判断

大数据技术架构_大数据架构图_cio面临大数据架构的选择困境

往流批一体作业开发模块中增加该行代码即可当判断条件符合的时候 即进行拦截 并上报调度 告知任务失败。

基于系统异常

流批一体架构当中, 实现了异常捕获并上报异常 。并对异常进行分类,为告警等级提供依据。基于统计 实现思路 通过调度平台集成 SQL组件功能。对调度元数据进行分析。统计运行周期,运行失败数等维度进行每天一统计 并发送到prometheus。在通过granfana 可视化进行展示并设置告警规则。

以上 主要是讲了 数据怎么在指定时间内出来的事中和事后措施或者机制。如果要全面的解决。个人建议 更多从事前和事后的方式去解决。事前的模型设计和预判和事后的回顾复盘。数据问题95%都处在事前设计上。因为由于不能全面的分析所有的故障点 所以需要事中和事后来进行兜底或者说保障。

有兴趣的可以看看 我写的 数仓建模专栏的文章

数据质量问题分类

大数据技术架构_大数据架构图_cio面临大数据架构的选择困境

造成数据质量的四大原因

数据质量原因开发问题

一般数据开发分为六个环节

大数据技术架构_cio面临大数据架构的选择困境_大数据架构图

数据开发流程需求分析

保障开发问题导致的分为事前保障,事中监控以及事后反馈三个点。

事前大数据架构图,通过圈定数据质量范围,制定研发各个环节的质量规范,把95%可能的数据质量问题把控在事前。

事前对应的开发环节个人觉得有 需求分析-模型设计-以及模型/需求评审以及开发4个环节。

(编辑:滁州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!