一、前言二、数据经常被质疑不准怎么办？三、数据质量问题的根源
1、业务系统变更2、系统资源不足3、基础设施不稳定4、系统代码bug 四、如何提高数据质量
1、如何提前发现数据问题
基础设施资源告警添加数据稽查规则稽查任务可视化稽查任务是不是越多越好 2、如何快速定位问题出现原因
数据血缘数据血缘的实现 3.如何加快数据恢复速度？ 五、管理制度的规范化 一、前言
大家好，我是王老狮。细心地小伙伴应该发现我改名字了，具体改名原因呢？毕竟过了一年了，我也成长了，DarkKing感觉有点太中二了，因此换个成熟稳重一点的名字。（难道我会告诉你我有起名困难症吗？）
随着互联网后期以及物联网的崛起，甚至互联网公司们已经不满足现实世界，诞生了元宇宙概念开始往虚拟世界方向走。包括上海也将元宇宙当做重点建设方向去布局。身为韭菜的你是不是瑟瑟发抖。现实中收割完之后，虚拟世界里继续收割。真是走廊上铺地铺，不留余地啊。
到底元宇宙是好是坏，我们不做评论。但同时随着大家通过云端互联交互越多，产生的数据也会越来越多。大数据存储也从数仓进化到数据湖的概念。因此，掌握一些大数据的知识对于未来发展以及了解趋势是非常有必要的。接下来将会开设新专栏，详细讲解下数据架构从0到1建设的过程。同时对于遇到的一些问题该如何解决提供一些见解。有兴趣的朋友可以一起讨论。今天我们就来聊一聊。数据质量这一块。
每天各产业负责人来到公司第一件事一般都是打开电脑看下昨天的经营数据，看整体效益怎么样，对数据进行分析来制定后面的运营策略。有一天产线同事早上打开数据，准备进行数据分析制定运营策略时，发现昨天数据都是0，之后一通电话异常上报给数据部门。
接到数据异常的投诉后，数据部门开始介入定位问题原因。从下游ADS应用层表开始查看。但是数据指标的产出可能是有几张甚至几十张表数据产生，一张一张的检查check，很显然是非常耗时的。通过一层一层向上排查。最终发现是采集层数据没有采集到ODS。采集模块存在一些问题，因为物理资源不足导致采集功能不可用。之后开始扩容，重新采集，跑数据。进行数据恢复。
排查问题时间将近花了一上午，问题处理数据重新计算基本上又花了半天，数据将近一天不可用。其他部门的业务进展也受到了影响。
因此作为业务部门会对数据部门满意吗？因此如何保证数据质量，是数据团队必须要攻克的问题。那么为了保证数据质量，我们要做到哪几个目标呢？
数据异常如何早于业务方发现？不要等到业务方投诉过来了还没有发现问题如何快速的定位问题？而不是一张一张表的check。数据问题如何快速的修复？数据的故障在数据采集层就出现了问题，那么后期的数据的同步，加工处理，计算输出都要重新运行，修复时间极高。 三、数据质量问题的根源通过几年的数据开发经验，数据的开发问题主要有以下几点
1、业务系统变更因为数据主要还是依赖业务方的，所以当业务方发布版本迭代时，对应产出数据的表，日志发生异动时，没有通知到数据方，那么就有可能会导致数据发生异常。一般常见的有以下4种情况。
业务系统数据切换新表，老表不在写入，导致数据团队数据更新异常。业务系统表结构变更，导致数据同步存在异常。业务系统环境异动，导致数据采集存在异常业务系统日志格式有异常，导致采集异常 2、系统资源不足
大数据体系下，数据的计算基本都是在公共集群上进行处理的。资源通过yarn进行管理。
资源是个非常稀缺的东西。计算资源分配不合理，或者ＳＱＬ优化的不是很好，都可能导致资源的不足。导致计算失败。主要也有一下几个原因。
数据计算内存资源不足，导致数据任务异常数据存储磁盘不足导致任务异常。任务计算时间拥挤，系统资源抢占。临时增加计算任务，没有及时扩充系统资源系统中存在慢SQL查询，导致计算时间延迟，计算任务积压。 3、基础设施不稳定
这种一般出现的异常不多，但一旦出现，影响都是全局性的并且是致命的。
机房停电物理机挂掉网络不稳等开源系统组件自身的bug 4、系统代码bug
这种问题一般出现的是最多的，特别是大数据本身业务代码的一些异常或者任务配置有问题，导致数据计算错误或者任务执行失败
展示层代码存在bug数据开发代码存在bug数据任务发布上线异常数据任务配置异常 四、如何提高数据质量
如何提高我们的数据质量，提高业务部门对数据团队的满意度。那么就要针对我们的目标，和发现问题的根源提供针对性的解决方案。
提前发现数据问题快速定位问题出现原因提高数据恢复速度 1、如何提前发现数据问题 基础设施资源告警 通过对基础设施添加资源告警，保证计算资源的充足
如计算资源到达90%进行警告提醒，98以上可能要进行电话提醒。
通过对任务处理完成的数据，针对业务设计一套校验规则，如前后表行数是否一致，关键字段的枚举，字段的最大和最小值是否在预期内等，这是提升数据质量最有效的方法，也是最能保证数据准确的方法。同时添加字段级别的校验规则还可以对业务方的数据质量做一些回溯，发现业务方数据库的一些不合理的值，从而进行治理。
因为稽查规则和业务息息相关，所以业界没有开源组件，基本都是公司自研。不过实现也比较简单。一般做法如下：
常用的数据稽查规则要满足以下需求：数据的完整性
数据的完整性顾名思义就是我们要确保记录是完整的没有丢失，如表级别的表行数是否一致，主键是否唯一等，采集过程中数据的波动率。
还有字段级别的监控，如关键字段是否非null，非0值，以及是否不再枚举范围之内。数据的一致性
数据的一致性主要是指我们的数据在不同的模型中数据应该是一样的。比如昨天累计用户为2w，昨天活跃用户为2000，活跃用户占比为20%。那么这三个指标就存在不一致了，因为活跃用户应该为活跃用户/累计用户为10%。而这个活跃用户占比可能使用了其他模型中的注册数进行计算导致数据不一致性。因此数据的一致性强调数据的来源应该只有一份，其他依赖该数据的数据指标理应都从这张表产生。这个在数据建模的时候是非常重要的一个标准，数据的准确性
数据的准确性主要就是保证数据的条目是准确地。就比如用户的下单日期不可能早入商品的发布日期。当天用户活跃不可能高于注册用户等。
稽查任务执行如下：
计算任务和稽查任务挂钩，保证数据运行时业务数据的准确性。
网易的模板稽查规则配置模型，有兴趣的可以参考:
通过对稽查任务大盘的可视化，可以帮助研发更加清晰地发现任务执行情况，快速分析问题原因。
稽查任务本身是一个比较耗资源的任务，因此我们要区分业务指标的重要等级，重要级别的必须增加稽查任务。一般重要的按需增加。以合理的利用资源和减少成本。
2、如何快速定位问题出现原因 数据血缘 数据仓库的设计中我们一般都是进行分层的。好的模型数据数据复用率会很高，可能一个中间结果被多个数据模型服用，那么这会导致我们数据加工链路变差。排查定位问题的时间也会比较长。因此建立数据的全链路监控，数据的血缘关系是非常有必要的。
从下图可以看到，血缘的建立一般都是我们通过业务方数据源起点，记录大数据加工过程，到指标的绑定以及指标的应用，建立起数据的全加工路径。这样那个数据指标出现了问题，通过数据链路就可以很快的定位到那个节点发生故障。从而快速响应去解决。
基于hadoop生态的数据血缘业界有apache的Atlas，Altas是apache开源的一套元数据治理的系统，它为Hadoop集群提供了包括数据分类、集中策略引擎、数据血缘、安全和生命周期管理在内的元数据治理核心能力。通过在hadooop生态组件里面配置hook的方式，自动将任务执行信息以及数据元信息倒入到Atlas中。Atlas的安装我之前有写过博客，大家感兴趣可以了解一下:Atlas的安装和使用
Altas 表元数据信息
Altas 数据血缘
如果脱离了hadoop集群组件的，那可能就要自己实现对应的hook函数了。
因为大数据以及业务存储组件当前很多，因此要完全实现各个存储组件以及同步任务的血缘系统难度大。因此更多的还是根据业务来自研自己的血缘组件。
血缘组件关联一般有手动和自动两种。
手动血缘关联
手动关联要求对整个数据开发过程要求可视化，在配置采集，计算任务，指标关联时，通过配置的方式把血缘关系写进血缘系统中。最后做一个数据呈现即可。此方法对数据开发可视化要求比较高。如果研发手动执行脚本，那么可能就记录不了血缘。导致血缘确实。维护难度大。
自动血缘关联
自动血缘关联即在数据任务执行过程中，通过SQL解析或者日志的方式，记录数据的流转。自动写入血缘系统中。
一般常用的方法有：
1、数据引擎的埋点
2、SQL PROXY LOG等
根据使用的存储引擎不同选择不同的方式。像使用SQL语言的则可以通过sql解析的方式，记录数据从哪来到哪去。如果是ES则可以通过数据引擎埋点的方式记录。
数据血缘的展示
小米公司的数据血缘展示形式
网易的数据血缘展示形式
有了前两道关，及时发现了并且定位到数据问题，那么接下来就是要进行数据恢复了。数据异常恢复一般我们要通过经常出现的一些问题进行分析。增强程序的健壮性以及容错性。比如日志任务漏采要有离线补齐的能力，数据同步中断要有中断补偿机制或者增量更新的能力。当然更重要的是我们要根据的数据重要性区分等级，按照优先级进行恢复。
五、管理制度的规范化在强大的技术也抵不过混乱的管理，即使已经有了前面描述的那么多能力，如果并没有开发添加规则或者规则不全面，报警发出无人处理，还是无法达早发现早处理的要求。因此建立完整的数据开发流程制度是保证数据质量的一个重要保证。好了，今天先聊到这里，后面在和大家继续聊一下数据治理相关的内容。