2023年第4期
总第18期
目录
contents
03
02
01
04
数据质量
监控
五个原则
下的数据
质量建设
之道
数据质量
那点事
阿里数据
质量管理
方法总结
数据质量那点事
1、数据质量基本概念
数据质量管理（Data Quality Management），是指对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的各类数据质量问题，进行识别、度量、监控、预警等一系列管理活动，并通过改善和提高组织的管理水平使得数据质量获得进一步提高
数据质量管理不是一时的数据治理手段，而是循环的管理过程。其终极目标是通过可靠的数据，提升数据在使用中的价值，并最终为企业赢得经济效益
2、影响因素
数据问题的来源可能产生于从数据源头到数据存储介质的各个环节。在数据采集阶段，数据的真实性、准确性、完整性、时效性都会影响数据质量。除此之外，数据的加工、存储过程都有可能涉及对原始数据的修改，从而引发数据的质量问题。所以，技术、流程、管理等多方面的因素都有可能会影响到数据质量。
在企业中，随着企业业务的增长，数据也是一个增量积累的过程。随着数据类型、数据来源的不断丰富以及数据数量的快速增长，企业在数据管理工作和数据流程中面临越来越多的数据质量问题。而且数据质量的管理并没有被企业重视起来，其根本原因还是ROI并没有那么明显。
数据质量管理相对来说成本比较高。因为它涉及到企业数据标准的制定、规范的落地、生命周期的管理等多个环节。从收益上来说，数据质量的效益和结果并不是十分明显，大部分企业不会把数据质量作为KPI。在企业的不同系统中，业务领域的关键指标不一致，数据无法共享导致出现数据孤岛，大量数据无法关联，并且有明显的数据冗余等问题，还有数据的维护需要投入大量的人员、时间、软硬件成本。所以数据的质量管理往往被会边缘化甚至趋向于无。
在此附上数据的生命周期图，包括各环节的数据流转和数据处理。
- 完整性
数据完整性问题包含数据条目不完整，数据属性不完整等
- 一致性
多源数据的数据模型不一致，如命名不一致，数据编码不一致，含义不一致，生命周期不一致等
- 准确性
准确性也叫可靠性，不可靠的数据可能会导致严重的问题，会造成有缺陷的方法和糟糕的决策
- 唯一性
用于识别和度量重复数据，冗余数据，重复数据是导致业务无法协同， 流程无法追溯的重要因素，也是数据治理需要解 决的最基本的数据问题
- 关联性
数据关联性问题是指存在数据关联的数据关系缺失或错误，例如：函数关系、相关系数、主外键关系、索引关系等。存在数据关联性问题，会直接影响数据分析的结果，进而影响管理决策。
- 真实性
数据必须真实准确的反映客观的实体存在或真实的业务，真 实可靠的 原始统 计数据是企业统计工作的灵魂，是一切管理工作的基础，是经 营 者进行正确 经营决策必不可少的第一手 资料。
- 及时性
数据的及时性(In-time)是指能否在需要的时候获到数据，数据的及时性与企业的数据处理速度及效率有直接的关系，是影响业务处理和管理效率的关键指标。
「驱动力」
文章转自：大数据私房菜
原文链接：https://mp.weixin.qq.com/s/Hq7XlJmigoQFMs4PCcFpgw
3、评估维度
- 逻辑检查
不同表字段之间可能会有逻辑关联，需要稽核
- 离群值检查
部分数据可能会偏离其他数据，比如同一个商品金额大家都是100元，而有一条数据是1W
- 自定义规则
由需求方自定义相关规则
- 波动稽核
与上周环比稽核波动情况
- 强弱规则
每个规则的权重应该是不一样的，需要配置优先级，这对后续的告警方 式是有帮助的
我们最终的目的是希望做到页面可配置
4、实施流程
事前定义质量规则
- 梳理表，字段等信息
- 确定资产等级
- 制定检验规则
事中监控数据质量
- 在数据抽取过程中，可以对数据进行数据量稽核及唯一性，非空性稽核
- etl过程对脏数据进行清洗，保证数据质量
- 指标计算过程中，可以对指标进行波动值稽核，保证指标变化在合理范围内
以上如果有异常都需要邮件短信报警，对应负责人根据优先级判断是不是需要及时处理
事后分析和问题跟踪
每周定时跑一次程序，对全局数据进行质量稽核控制，如唯一性，非空性等
对于程序跑出来的数据：
数据质量概览在数据质量管理系统查询
数据质量明细数据在数据质量管理系统查询
根据异常数据统计出来的各种数据质量报表也可以在数据质量管理系统查询，包括表覆盖率，历史趋势，综合分析，排名分析等(质量报告支持导出为word，pdf，excel)
对异常进行评估、严重程度、影响范围、问题分类等
重大问题告警
- 警告：邮件短信通知
- 数据整改：问题跟踪处理，故障review，一周内处理完成
5、总结
数据质量管理贯穿数据生命周期的全过程，覆盖质量评估、数据监控、数据探查、数据清洗、数据诊断等方面。数据源在不断增多，数据量在不断加大，新需求推动的新技术也不断诞生，这些都对大数据下的数据质量管理带来了困难和挑战。因此，数据质量管理要形成完善的体系，建立持续改进的流程和良性机制，持续监控各系统数据质量波动情况及数据质量规则分析，适时升级数据质量监控的手段和方法，确保持续掌握系统数据质量状况，最终达到数据质量的平稳状态，为业务系统提供良好的数据保障。
「驱动力」
五个原则下的
数据质量建设之道
文章转自： EAWorld
原文链接：https://mp.weixin.qq.com/s/JCPiiEkt7PBv5pftvE5RHQ
1.业务操作部门在数据录入过程可能输入错误的数据。这决定了数据源的质量。
2.在数据抽取、加载工程中导致数据记录丢失、数据重复等问题。
3.在数据加工、转换过程中，由于数据加工、转换的代码鲁棒性和稳定性不够，导致的数据加工结果出现的错误。
4.数据计算汇总过程中，导致的数据的错误。
5.分析展现工具将加工好的数据展现给数据分析人员、管理决策人员出现的错误。
在某种意义上讲，分析者所做出的决策的正确性来源于企业信息源的质量、数据仓库本身的质量、数据集市的质量以及数据仓库各过程的质量。在数据应用过程中5步中有4步是技术或管理造成的，只有1步会是录入环节导致。而恰好是这一步是数据中台无法管理和解决的业务系统的数据。因此从根本上解决数据质量问题，从源头解决是最有效的途径，在辅助数据中台从技术和管理上加强测试、规范和监控，那么数据质量问题的解决就水到渠成了。
【3、数据质量建设的五个原则】
总结古人治理黄河水患，主要有两种策略，一种是“疏通”，上策迁移民众和中策分流黄河水患，都是具体体现；另一种是“围堵”，加高增厚堤防，抑制河水烂漫。
治理数据质量的问题可以应用下古人的智慧和考量。采用规划顶层设计，制定统一数据架构、数据标准，设计数据质量的管理机制，建立相应的组织架构和管理制度，采用分类处理的方式持续提升数据质量，这是数据质量管理“疏”的方式。而单纯依赖技术手段，通过增加ETL数据清洗处理逻辑的复杂度，使用数据质量工具来发现ETL数据处理中的问题属于“堵”的方式，只能解决表面的问题，不是根本的解决方法。事实上这种方式也在好多企业中使用，其根本目的在于提高ETL处理的准确度，做法无可厚非，毕竟找别人的问题之前，先要保证自身是没有问题的。
按照多个行业实施数据质量管理项目的经验，数据质量管理应该是采用“疏”和“堵”相结合的方式，通过这种方式解决数据质量问题有5个原则。
1、全程监控原则：
全程监控是针对数据生命周期全过程中各环节进行数据质量监控，从数据的定义、录入、获取、计算、使用的全过程进行质量监控。数据定义阶段，对数据模型、字典枚举值进行监控，判断是否遵循了统一的标准。数据录入阶段对输入的合法性进行校验等，数据获取阶段对数据记录数、数据一致性进行检核等。明确各部门在数据全生命周期中的责任，全方位保证数据质量。
2、闭环管理原则：
从问题定义、问题发现、问题整改、问题跟踪、效果评估5个方面建立问题处理的闭环机制。从业务、技术两个维度出发做问题定义，由工具自动发现问题，明确问题责任人，通过邮件、短信等方式进行通知，将问题及时通知到责任人，跟踪问题整改进度，建立相应的质量问题评估KPI，保证数据质量问题管理闭环。
「驱动力」
在数字化转型的背景下，数据是一把双刃剑，它能给企业带来业务价值的同时也是组织最大的风险来源。糟糕的数据质量常常意味着糟糕的业务决策，将直接导致数据统计分析不准确、监管业务难、高层领导难以决策等问题。
「目录」
【1、数据质量问题产生来源】01 数据质量问题产生来源02 数据质量问题域及分类03 数据质量建设的五个原则04 数据质量关键技术及流程05 数据质量管理实践
数据集成融合就和古人筑堤坝一样，古人筑堤坝是为约束河水，让自然资源为我所用，发挥自然资源的价值；今人做数据集成融合，建数据中台，是为了挖掘数据价值，发挥数据资源的价值，让数据资源为企业的业务创新发挥价值。
大数据时代数据集成融合的需求不仅要融合企业内部数据，也要融合外部（互联网等）数据。如果没有对数据质量问题建立相应的管理策略和技术工具，那么数据质量问题的危害会更加严重。据IBM统计，数据分析员每天有30%的时间浪费在了辨别数据是否是“坏数据”上。
【2、数据质量问题域及分类】
数据质量问题从大的方面可以划分为技术、业务和管理问题域。技术问题域包括数据校验不够、默认值使用不当等问题，通常是由于系统建设和数据处理导致的。业务问题域细分为信息问题域和流程问题域，业务上存在多渠道数据创建、不合理的数据变更流程的问题。管理问题域包括数据责任人不明确、没有奖惩制度，缺少培训等。
企业数据分为创建、加载、汇总、分析到展现5个步骤，很显然，步任何一步出错都会导致整个结论分析失真：
3、全员参与原则：
数据质量提升涉及到组织多个部门，包括不仅限于数据提供方、数据消费方、数据质量管理员等。尤其在数据质量问题定义和整改阶段需要多方人员的参与才能达到效果。在数据质量问题定义阶段，需要数据责任人、业务专家、数据使用人员对数据问题校验规则达成一致，共同制定数据检核范围、数据问题条件等。问题整改阶段，要由数据责任方、数据质量管理员和技术人员，共同定位问题原因并进行整改。
4、借助工具，自动检核：
数据质量工具保证问题发现的效率。在数据使用过程中深入分析已发现的数据质量问题的成因，及时由IT部门将其转化为技术规则落地到系统中，通过技术手段自动检核数据质量问题，提升数据质量检核效率。数据质量工具在采集到的数据模型元数据的基础上，通过配置自动生成检核规则的脚本，并通过设置数据质量检核任务的运行周期，定时检核数据质量问题，并将数据质量问题数据保存到系统中，便于用户进行查看和定位问题。
5、提升意识、主动管理：
数据质量管理工作需要提升全员数据质量意识，形成组织数据治理的文化氛围。数据使用方发现数据质量问题后，及时主动的进行问题的上报，避免数据问题对业务造成影响。数据责任人接到问题通知后，应主动配合数据管理部门进行问题整改。数据管理部门应该从事前预防数据问题出发，制定企业数据标准并加强宣贯，减少因为缺少统一的标准、规范导致数据质量问题。
【4、数据质量关键技术及流程】
在“五个原则”的指导下开展数据质量建设工作，从平台层面需要制定数据质量管理的功能架构。
基于全栈式信创能力，普元数据质量平台包括了规则定义、任务管理、调度执行、生成检核结果、形成质量分析报告、问题处理、沉淀知识库、质量监控，涵盖了数据质量问题的发现、整改、反馈的整个流程。
「驱动力」
通过对不同业务规则的收集、分类和抽象，我们定义了这几个质量维度：完整性、有效性、正确性、唯一性、及时性、合理性。
基于以上几个质量维度，总结了业务场景中常用的检核规则，提供模版式的检核规则配置方式，便于使用者快速配置。这些检核规则包括：空值检查、值域检查、有效性检查、规范检查、及时性检查、重复数据检查、完整性检查，当然，我们也保留了原先的自定义SQL的配置方式。
新的数据质量平台中，提供了业务化的检核规则配置方式，提供了常用的检核类型，满足实际场景使用需要。
业务化的检核规则配置步骤有：基本信息、规则配置、结果配置、告警配置。其中，规则配置根据检核规则类型不同，具体的配置会有所不同。
那么，如何从技术实现和管理流程方面，保障企业数据质量的稳步提升？
检核脚本生成和调度执行
检核规则采用业务化配置和模版导入方式输入检核规则，通过系统内置SQL引擎，实现检核脚本的自动生成，从而降低业务规则转化为技术实现的成本，提高业务规则的实现效率。
数据质量平台的调度模块则按照检核任务的执行频度设置，周期性或定时执行检核任务。
规范管理流程
在数据使用过程中，深入分析已发现的数据质量问题的成因，及时由IT部门将其转化为技术规则落地到平台中，通过技术手段自动检核数据质量问题，提升数据质量检核效率。
数据质量平台在采集到的数据模型元数据的基础上，通过配置自动生成检核规则的脚本，并通过设置数据质量检核任务的运行周期，定时检核数据质量问题，并将数据质量问题数据保存到平台中，便于用户进行查看和定位问题。
同时，根据数据的检核结果，平台自动形成检核指标、检核规则的分析结果，生成质量趋势的分析报告。
由此，形成从问题定义、发现、分析，到问题的处理和跟踪，再到数据质量评估和统计分析的管理流程。
「驱动力」
【5 数据质量管理实践】
为实现数据质量的切实落地，推进数据质量问题的有效解决，某一线城市大数据中心的数据质量工作开展，按照发现问题、分析问题、提出方案、解决问题等几步来进行。
- 第一步：设置数据质量规则。即针对不同的数据对象，配置相应的数据质量指标，不限于：数据唯一性、数据准确性、数据完整性、数据一致性、数据关联性、数据及时性等。
- 第二步：分析数据质量问题产生的原因。可能是技术层面数据模型设计的质量问题，也可能是业务层面系统相互独立导致数据无法对接或者是业务端进行数据录入时未按照规范进行录入。
- 第三步：选择解决办法。技术上可以通过ETL工具按照数据标准规范进行数据清洗和标准；业务上可以对业务系统进行升级改造和数据补录。
- 第四步：质量检测，监督检查。设置数据检查任务对存量数据进行检查，形成数据质量问题清单并出具数据质量问题报告。通过定期对系统开展全面的数据质量状况评估，从问题率、解决率、解决时效等方面建立评价指标进行整改评估，根据整改优化结果。
形成有效的闭环管理
在形成规范流程的基础上，从业务、技术两个维度出发做问题定义，由工具自动发现问题，明确问题责任人，通过邮件等方式进行通知，将问题及时通知到责任人，跟踪问题整改进度，建立相应的质量问题评估KPI，保证数据质量问题管理闭环。
通过建立数据质量闭环管理机制、明确各部门关于数据质量提升工作的分工职责并强化执行；同时基于数据管理工具，持续改进管理流程，支撑企业级数据质量管理，确保企业级数据质量稳步提升。
数据质量监控
随着大数据时代的带来，数据的应用也日趋繁茂，越来越多的应用和服务都基于数据而建立，数据的重要性不言而喻。而且，数据质量是数据分析和数据挖掘结论有效性和准确性的基础，也是这一切的数据驱动决策的前提！如何保障数据质量，确保数据可用性是每一位数据人都不可忽略的重要环节。
数据质量，主要从四个方面进行评估，即完整性、准确性、一致性和及时性，本文将会结合业务流程和数据处理流程，对这个四个方面进行详细的分析和讲解。
数据，最终是要服务于业务价值的，因此，本文不会单纯讲解理论，而是会从数据质量监控这一数据的应用为出发点，为大家分享居士对数据质量的思考。通过本文，你将获得如下几方面的知识点：
- 数据质量核心关注的要点
- 从数据计算链条理解，每一个环节会出现哪些数据质量问题
- 从业务逻辑理解，数据质量监控能带来的帮助
- 实现数据质量监控系统时要关注的点
- 数据质量监控面临的一些难点和解决思路
四大关注点
本节，先简单地聊一下数据质量需要关注的四个点：即完整性、准确性、一致性和及时性。这四个关注点，会在我们的数据处理流程的各个环节有所体现。
一、完整性
完整性是指数据的记录和信息是否完整，是否存在缺失的情况。数据的缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确，所以说完整性是数据质量最基础的保障。
简单来讲，如果要做监控，需要考虑两个方面：一是，数据条数是否少了，二是，某些字段的取值是否缺失。完整性的监控，多出现在日志级别的监控上，一般会在数据接入的时候来做数据完整性校验。
二、准确性
准确性是指数据中记录的信息和数据是否准确，是否存在异常或者错误的信息。
直观来讲就是看数据是否上准确的。一般准确性的监控多集中在对业务结果数据的监控，比如每日的活跃、收入等数据是否正常。
三、一致性
一致性是指同一指标在不同地方的结果是否一致。
数据不一致的情况，多出现在数据系统达到一定的复杂度后，同一指标会在多处进行计算，由于计算口径或者开发人员的不同，容易造成同一指标出现的不同的结果。
四、及时性
在确保数据的完整性、准确性和一致性后，接下来就要保障数据能够及时产出，这样才能体现数据的价值。
及时性很容易理解，主要就是数据计算出来的速度是否够快，这点在数据质量监控中可以体现在监控结果数据数据是否在指定时间点前计算完成。
0x02 数据处理各环节的数据质量
数据质量监控之所以难做，是因为在数据的各个环节都会出现数据质量的问题。因此，本节将以一个典型的数据处理链条为例，为大家分享在每个阶段容易出现哪些数据质量问题。
如下图，为了举例说明，我画了一个简单的数据处理流程（在实际中的情况会比该情况复杂很多），我将数据处理分为 3 个阶段：数据接入、中间数据清洗、结果数据计算。
「驱动力」
文章转自：CSDN，作者木东居士
原文链接：https://blog.csdn.net/wowotuo/article/details/89424624
数据接入
如上图所示，数据接入环节最容易出现的是数据完整性的问题，这里要特别注意的是数据量是否陡增和陡降。
陡增意味着可能会出现大量数据重复上报或者异常数据侵入等情况，陡降意味着可能出现数据丢失的情况。
另一方面，也要检查不同字段的的取值是否有丢失，比如地址和设备字段是否出现大量空值等异常。
数据清洗
在这里，我将数据清洗的范围局限在数据仓库的中间表清洗上，这一部分一般也是我们的数据仓库要建设的核心部分，业务到了一定程度，数据中间层的建设必不可少！
在这一环节，最容易出现的是数据一致性和数据准确性的问题。数据中间层保障来数据是从统一出口而出，让数据一起对或者一起错。但是很难保证数据准确性的问题，因此在数据清洗阶段需要尽量保障数据的准确性。
数据结果
结果数据，主要是强调对外提供数据的过程，一般是从中间表中计算或直接取得的可展示数据。这里是业务方和老板最容易感知的到的地方，因此在这环节，主要关注的是数据准确性和数据及时性。
整体来讲，数据的完整性、准确性、一致性和及时性在数据处理的各个阶段都需要关注，但是可以先抓住的核心的问题来解决。
业务流程各环节的数据质量
聊完数据处理，我们继续聊一下业务流程。数据最终的价值是要服务于业务的，因此数据质量最好也是能从解决业务问题出发，因此，本节从典型的业务场景来讲解数据质量该怎么做。
首先，居士认为，既然做监控肯定是要考虑使用方的，而我们的数据质量监控平台一个很重要的作用是希望让老板、产品和运营这些使用方对我们的数据放心，那么他们的关注点是什么？居士认为，是业务指标！
那么，这个业务指标可以从两个角度来考虑：
- 单个指标的数值异常，比如说数据是否达到来某个临界值？是否有陡增和陡降？
- 整个业务链条的数据是否有异常，比如从曝光到注册的转化是否有异常？
如下图，是一个 App 的用户行为漏斗分析，其实也就是从获取用户到转化的简单链路。
那么针对该链路，我们数据质量监控要做的事，除了告诉使用方某一个节点的值有问题，也需要告诉他们整个链条哪里出了问题，哪里的转化低了。
「驱动力」
如何实现数据质量监控
前面分享了数据质量关注的点，以及从技术和业务角度会如何关注数据质量，本节将简单地分享一下如何实现数据质量监控。这里将分两个角度：宏观的设计思路和技术实现思路。
一、设计思路
数据质量监控的设计要分为四个模块：数据、规则、告警和反馈。
- 数据：主要是需要被数据质量监控到的数据，数据可能存放在不同的存储引擎中，比如Hive、PG、ES等。
- 规则：是指如何设计发现异常的规则，一般而言主要是数值的异常和环比等异常监控方式。也会有一些通过算法来发掘异常数据的方法。
- 告警：告警是指出发告警的动作，这里可以通过微信消息、电话、短信或者是微信小程序的方式来触发告警内容。
- 反馈：这里需要特别注意，反馈是指对告警内容的反馈，比如说收到的告警的内容，那么负责人要来回应这个告警消息是否是真的异常，是否需要忽略该异常，是否已经处理了该异常。有了反馈的机制，整个数据质量监控才容易形成闭环。更能体现业务价值。
二、技术方案
关于技术方案，这里不多描述细节，因为不同的公司和团队情况对实现方案的考虑是不同的，简单做的话，可以写一些定时脚本即可，复杂的话可以做成一个分布式的系统。这里也可以参考居士17年写的一部分内容No.22 漫谈数据质量监控。
本篇只简单说明几个技术实现中需要关注的点：
- 最开始可以先关注核心要监控的内容，比如说准确性，那么就对核心的一些指标做监控即可，不用开始就做很大的系统。
- 监控平台尽量不要做太复杂的规则逻辑，尽量只对结果数据进行监控。比如要监控日志量是否波动过大，那么把该计算流程前置，先计算好结果表，最后监控平台只监控结果表是否异常即可。
- 多数据源，多数据源的监控有两种方式可以处理：针对每个数据源定制实现一部分计算逻辑，也可以通过额外的任务将多数据源中的数据结果通过任务写入一个数据源中，再该数据源进行监控，这样可以减少数据监控平台的开发逻辑。具体的优缺点可以自行衡量。
- 实时数据的监控，实时和离线数据监控的主要区别在于扫描周期的不同，因此在设计的时候可以先以离线数据为主，但是尽量预留好实时监控的设计。
- 在设计之初，尽量预留好算法监控的设计，这是一个很大的加分项，具体的结合方式也可以和第二点建议接近，比如算法异常数据放到一张结果表中，再在上面配置简单的告警规则即可。
一些困难
在做数据质量监控的时候难免会遇到一些困难点，亦或是被老板挑战的地方，下面列举几个问题和解决的思路，供大家参考：
问题一：假设你的结果表要经过多层的中间表计算，你怎么保证每个环节都是正确的，且最终结果是正确的？
思路：从两个点考虑：
- 每一层代码有 Code Review，保证代码逻辑正常。
- 单独一条计算流，对关键指标从原始数据直接计算结果，和日常的结果表做对比，发现不同则告警。这种方式也可以理解为是结果数据和源数据的对账。
问题二：告警信息太多了，太容易被忽略怎么办？
思路：主要是思路是提高告警的准确率，避免无用的告警，有三个思路：
- 多使用机器学习算法的方式来发现异常点，比如：异常森林。
- 加入反馈机制，如果业务负责人认为该告警是正常的，就打上正常的tag，后续告警规则根据反馈进行优化。
- 加入屏蔽功能，屏蔽不感兴趣的告警。
「驱动力」
…… …… …… …… …… …… ……
阿里数据质量管理方法总结
一、数据质量保障原则
如何评估数据质量的好坏，业界有不同的标准，阿里主要从4个方面进行评估：完整性、准确性、一致性、及时性；
1.完整性
数据完整性是数据最基础的保障；
- 完整性：指数据的记录和信息是否完整，是否存在缺失的情况；
- 数据缺失：主要包括记录的缺失和记录中某个字段信息的缺失；
记录的丢失：如，交易中每天只发订单数都在 100 万笔左右，如果某天支付订单突然下降到 1 万笔，很可能是记录丢失了；
记录中字段的丢失：如，订单的商品 ID、卖家 ID 都是必然存在的，这些字段的空值个数肯定是 0，一旦大于 0 就违背了完整性约束；
2. 准确性
- 准确性：指数据汇总记录的信息和数据是否准确，是否存在异常或者错误的信息；
准确：数据表中记录的信息与业务过程中真实发生的事实要一致；如何判断是否准确：卡点监控 —— 制定相应规则，根据根校验数据，符合规则的数据则认为是准确的；
如，一笔订单如果出现确认收货金额为负值，或者下单时间在公司成立之前，或者订单没有买家信息等，这些必然是有问题的；
3. 一致性
- 一致性：一般体现在跨度很大的数据仓库体系中，如阿里的数据仓库，内部有很多业务数据仓库分支，对于同一份数据，必须保证一致性；
一致：也就是指多个业务数据仓库间的公共数据，必须在各个数据仓库中保持一致；
如，用户 ID，从在线业务库加工到数据仓库，再到各个消费节点，必须都是同一种类型，长度也需要保持一致；
- 所以，在阿里建设数据仓库时，才有了公共层的加工，以确保数据的一致性；
4. 及时性
- 及时性：指数据要能及时产出；
主要体现在数据应用上，要及时产出给到需求方；
- 一般决策支持分析师希望当天就能看到前一天的数据，而不是等三五天才能看到某一个数据分析结果；否则就已失去了数据及时性的价值；
如，阿里 “双 11” 的交易大屏数据，就要做到秒级；
二、数据质量方法概述
阿里的数据质量建设体系：
「驱动力」
文章转自：大数据梦想家，作者梦想家Alex
原文链接：https://mp.weixin.qq.com/s/yQFDMYZJXeUBUjmbM4S3tQ
…… …… …… …… …… …… ……
1. 消费场景知晓
- 功能：分析解决消费场景知晓的问题；
- 方法：通过数据资产等级和基于元数据的应用链路，来分析解决消费场景知晓的问题；确定数据资产等级：根据应用的影响程度，确定数据资产的等级；
- 过程：根据数据链路血缘，将资产等级上推至各数据生产加工的各个环节，确定链路上所有涉及数据的资产等级，以及在各个加工环节上根据资产等级的不同所采取不同的处理方式；
2. 数据生产加工各个环节卡点校验
主要对两部分的数据卡点校验：在线系统和离线系统数据生产加工各个环节的卡点校验；
- 在线系统：OLTP（On - Line Transaction Processing，联机事务处理）系统；
在线系统生产加工各环节卡点校验：
1）根据资产等级的不同，当对应的业务系统变更时，决定是否将变更通知下游；
2）对于高资产等级的业务，当出现新业务数据时，是否纳入统计中，需要卡掉审批；
- 离线系统：OLAP（On - Line Analytical Processing，联机分析处理）系统；
离线系统生产加工各环节卡点校验：
主要包括：代码开发、测试、发布、历史或错误数据回刷等环节的卡点校验；代码开发阶段、发布前的测试阶段
针对数据资产等级的不同，对校验的要求有所不同；
3. 风险点监控
风险点监控：主要针对在数据运行过程中可能出现的数据质量和时效等问题进行监控；
主要对两个方面进行风险点监控：
- 在线数据的风险点监控：
主要针对在线系统日常运行产出的数据进行业务规则的校验；
主要使用 “实时业务检测平台 BCP（Biz Check Platform）”；
- 离线数据的风险点监控：
主要是针对离线系统日常运行产出的数据，进行数据质量监控和时效性监控；
DQC：监控数据质量；
摩萨德：监控数据时效性；
4. 质量衡量
- 对质量的衡量：
事前的衡量：如 DQC 覆盖率；事后的衡量：跟进质量问题，确定质量问题原因、责任人、解决情况等，并用于数据质量的复盘，避免类似事件再次发生；根据质量问题对不同等级资产的影响程度，确定其是属于低影响的事件还是具有较大影响的故障；
- 质量分：综合事前和事后的衡量数据进行打分；
5. 质量配套工具
- 针对数据质量的各个方面，都有相关的工具进行保证，以提高效能；
01 消费场景知晓
- 消费场景知晓的问题：
数据研发工程师难以确认几百 PB 的数据是否都是重要的？是否都要进行保障？是否有一些数据已经过期了？是否所有需要都要精确的进行质量保障？
- 解决方案：数据资产等级方案；
- 产出：
根据数据产品和应用的影响程度，给数据产品和应用划分资产等级，并打标处理；
根据数据链路血缘，将资产等级上推至各数据生产加工的各个环节，确定链路上所有涉及数据的资产等级，打标处理；（等级标签与对应的数据产品 / 应用一致）
1. 数据资产等级定义
背景：针对阿里庞大的数据仓库，数据的规模已经达到 EB 级，对于这么大的数据量，如果一概而论势必会造成精力无法集中、保障无法精确；
五个数据等级，不同性质的重要性一次降低：
「驱动力」
…… …… …… …… …… …… ……
- 毁灭性质
即，数据一旦出错，将会引起重大资产损失，面临重大受益损失，造成重大公共风险；
- 全局性质
即，数据直接或间接用于集团业务和效果的评估、重要平台的运维、对外数据产品的透露、影响用户在阿里系网站的行为等；
- 局部性质
即，数据直接或间接用于内部一般数据产品或者运营 / 产品报告，如果出现问题会给事业部或业务线造成影响，或者造成工作效率损失；
- 一般性质
即，数据主要用于小二的日常数据分析，出现问题几乎不会带来影响或者影响很小；
- 未知性质
即，数据主要用于小二的日常数据分析，出现问题几乎不会带来影响或者影响很小；
- 未知性质
不能明确说出数据的应用场景，则标注为未知；
对于不同的数据资产等级，使用英文 Asset 进行标记：
毁灭性质：A1 等级；
全局性质：A2 等级；
局部性质：A3 等级；
一般性质：A4 等级；
未知性质：A5 等级；
重要程度：A1 > A2 > A3 > A4 > A5；
如果一份数据出现在多个应用场景中，遵循就高原则；
数据资产等级落地方法
需要解决的问题：对于如此庞大的数据量，如何给每一份数据都打上一个等级标签？
数据资产等级落地的方法 / 步骤：
数据流转过程
- 数据从业务系统中产生，经过同步工具进入数据仓库系统中，在数据仓库中进行一般意义上的清洗、加工、整合、算法、模型等一系列运算；
- 通过同步工具输出到数据产品中进行消费；
数据从业务系统到数据仓库再到数据产品，都是以表的形式体现的，流转过程如下图：
「驱动力」
同步到数据仓库（对应到阿里就是 MaxCompute 平台）中的都是业务数据库的原始表，主要用于承载业务需求，往往不能直接用于数据产品；（一般是 ODS 层的全量数据）
在数据产品中使用的都是经过数据仓库加工后的产出表；（根据需求 / 报表进行加工）
划分数据资产等级
根据数据流转过程，建立元数据，记录数据表与数据产品或者应用的对应关系；
根据影响程度，给数据产品和应用划分数据资产等级；
打标：依托元数据的上下游血缘，将整个消费链路打上某一类数据资产标签（也就是对消费链路数据打标）；
链路：指数据从业务系统到数据产品的流转过程；
总结：
通过上述步骤，就完成了数据资产等级的确认，给不同的数据定义了不同的重要程度，需要用到元数据的支撑；
02 数据加工过程卡点校验
目的：保障数据准确性、保障与离线数据的一致性；
1）在线业务系统卡点校验（数据产出环节）
- 在线系统数据加工过程卡点校验，主要指在在线系统的数据生产过程中进行的卡点校验；
- 目的：保障与离线数据的一致性；
- 背景 / 问题：在线业务复杂多变，总是在不断变更，每一次变更都会带来数据的变化，因此需要做到两点：
- 数据仓库需要适应着多变的业务发展，及时做到数据的准确性；
…… …… …… …… …… …… ……
- 需要高效的将在线业务的变更通知到离线数据仓库；阿里解决上述两个问题的方法：工具和人工双管齐下：既要在工具上自动捕捉每一次业务的变化，同时也要求开发人员在意识上自动进行业务变更通知；
2）工具
发布平台：发送重大变更的通知；
通知内容：变更原因、变更逻辑、变更测试报告、变更时间等；
数据库平台：发送库表变更通知；
通知内容：变更原因、变更逻辑、变更测试报告、变更时间等；
3）发布内容
功能：在业务进行重大变更时，订阅发布过程，然后给到离线开发人员，使其知晓此次变更的内容；
注：业务系统繁忙，日常发布变更数不胜数，并不是每一次业务变更都只会是离线业务，那样会造成不必要的浪费，而且影响在线业务迭代的效率；
订阅内容：针对全集团重要的高等级数据资产，整理出哪些变化会影响数据的加工，则订阅这些内容；
如，财报，这个自然是 A1 等级的资产，如果业务系统的改造会影响财报的计算，如约定好的计算口径被业务系统发布变更修改了，那么务必要告知离线业务，作为离线开发人员也必须主动关注这类发布变更信息；
卡点：发布平台集成了通知功能，针对重要的场景发布会进行卡点，确认通知后才能完成发布；
4）数据库表的变化感知
无论是随着业务发展而做的数据库扩容还是表的 DDL 变化，都需要通知到离线开发人员；
DDL（(Data Definition Language）：数据库模式定义语言；用于描述数据库中要存储的现实世界实体的语言。
DDL 数据库模式定义语言是 SQL 语言（结构化查询语言）的组成部分；
例：CREATE DATABASE（创建数据库）、CREATE TABLE（创建表）；
DML（Data Manipulation Language）：数据操纵语言命令；使用户能够查询数据库以及操作已有数据库中的数据。
例：insert、delete、update、select 等都是 DML ；
「驱动力」
背景 / 问题：数据仓库在进行数据抽取时，采用的是 DataX 工具，可能限制了某个数据库表，如果发生数据库扩容或者迁移，DataX 工具是感知不到的，结果可能会导致数据抽取错漏，影响一系列的下游应用；
解决方法：通过数据库平台发送库表变更通知；
5）开发人员
数据资产等级的上下游打通，同样也要将这个过程给到在线开发人员，使其知晓哪些是重要的核心数据资产，哪些暂时还只是作为内部分析数据使用；
要提高在线开发人员的意识，通过培训，将离线数据的诉求、离线数据的加工过程、数据产品的应用方式，告诉在线业务开发人员，使其意识到数据的重要性，了解数据的价值，同时也告知出错后果，使在线开发人员在完成业务目标时，也要注重数据的目标，做到业务端和数据端一致；
6）离线系统卡点校验（数据离线加工环节）
背景 / 问题：数据从在线业务系统到数据仓库再到数据产品的过程中，需要在数据仓库这一层完成数据的清洗、加工；正是有了数据的加工，才有了数据仓库模型和数据仓库代码的建设；如何保障数据加工过程中的质量，是离线数据仓库保障数据质量的一个重要环节；
目的：保障数据加工过程中的质量（主要指数据的准确性）；
另外，需要在两个环节进行卡点校验：
7）代码提交时的卡点校验
背景 / 原因：数据研发人员素质不同，代码能力也有差异，代码质量难以得到高效保障；
解决方法：开发代码扫描工具 SQLSCAN，针对每一次提交上线的代码进行扫描，将风险点提取出来；
卡点方式：使用代码扫描工具 SQLSCAN，扫描代码提取风险点；
8）任务发布上线时的卡点校验
为了保障线上数据的准确性，每一次变更都需要线下完成测试后在发布到线上环境中，线上测试通过后才算发布成功；
卡点方式：分别对任务（指变更的业务）发布上线前和上线后进行测试；
9）发布上线前的测试：主要包括 Code Review 和回归测试；
- Code Review：是一种通过复查代码提高代码质量的过程；
- 回归测试：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误；
…… …… …… …… …… …… ……
回归测试的目的：
保障新逻辑的正确；保证不影响非此次变更的逻辑；
注：对于资产等级较高的任务变更发布，采用强阻塞的形式，必须通过在彼岸完成回归测试之后才允许发布；
10）发布上线后的测试：在线上做 Dry Run 测试或者真实环境运行测试；
- Dry Run 测试：
不执行代码，仅运行执行计划，避免线上和线下环境不一致导致语法错误；
- 真实环境的运行测试：
使用真实数据进行测试；
- 节点变更或数据重刷新前的变更通知
通知内容：变更原因、变更逻辑、变更测试报告、变更时间等；
过程：
使用通知中心，将变更原因、变更逻辑、变更测试报告、变更时间等自动通知下游，下游对此次变更没有异议后，再按照约定时间执行发布变更，将变更对下游的影响降低至最低；
03 风险点监控
风险点监控：主要指针对数据在日常运行过程中容易出现的风险进行监控，并设置报警机制；
主要包括在线数据和离线数据运行风险点监控；
目的：保障数据的准确性；
1）在线数据风险点监控
- 目的：减少了在线业务系统产生的脏数据，为数据准确性把第一道关；
另外，减少用户错误信息的投诉，也减少了离线数据错误的回滚；
- BCP：阿里的实时业务检测平台；
- 思路 / 监控过程：在每一个业务系统中，当完成业务过程进行数据落库时，BCP 订阅一份相同的数据，根据提前设定好的业务规则，在 BCP 系统中进行逻辑校验，当校验不通过时，以报警的形式披露出来，给到规则订阅人，以完成数据的校对；
- BCP 的校验过程：
「驱动力」
获取数据源：用户在 BCP 平台订阅数据源，获取需要校验的数据源；
编写规则：针对所订阅的数据源进行规则的编写，即校验的逻辑；
- 规则 / 逻辑：是至关重要的，是校验的核心，只有通过了这些规则，才认定该条记录是对的；
如，针对 “订单拍下时间” 进行校验；逻辑：订单的拍下时间肯定不会大于当天的时间，也不会小于淘宝创立的时间；
配置告警：针对不同的规则配置不同的告警形式；
注：由于 BCP 的配置和运行成本较高，主要根据数据资产等级进行监控；
- 离线数据风险点监控
离线数据风险点监控主要包括对数据准确性和数据产出的及时性进行监控；
- 数据准确性监控
数据准确性是数据质量的关键，因此数据准确成为数据质量的重中之重，是所有离线系统加工时的第一保障要素；
方法：通过 DQC 进行数据准确性监控；
DQC（Data Quality Center，数据质量中心）：主要关注数据质量，通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控；
注：监控数据质量并报警，其本身不对数据产出进行处理，需要报警接收人判断并决定如何处理；
监控方式：通过配置数据质量检验规则，自动在数据处理任务过程中进行监控；
监控规则：
强规则：会阻断任务的执行；
将任务置为失败状态，其下游任务将不会被执行；
弱规则：只告警而不会阻断任务的执行；
常见的 DQC 监控规则：主键监控、表数据量及波动监控、重要字段的非空监控、重要枚举字段的离散值监控、指标值波动监控、业务规则监控等；
规则配置：依赖数据资产等级确定监控规则；
DQC 检查其实也是运行 SQL 任务，只是这个任务是嵌套在主任务中的，一旦检查点太多自然就会影响整体的性能；因此还是依赖数据资产等级来确定规则的配置情况；
注：不同的业务会有业务规则的约束，这些规则来源于数据产品或者说消费的业务需求，有消费节点进行配置，然后上推到离线系统的起点进行监控，做到规则影响最小化；
…… …… …… …… …… …… ……
数据及时性
在确保数据准确性的基础上，需要进一步让数据能够及时的提供服务；否则数据的价值将大幅度降低，甚至没有价值；
阿里的大部分离线任务：
一般以天为时间间隔，称为 “天任务”，对于天任务，数据产品或者数据决策报表一般都要求在每天 9:00 甚至更早的时间产出；
为了确保前一天的数据完整，天任务是从零点开始运行的，由于计算加工的任务都是在夜里运行的，而要确保每天的数据能够按时产出，需要进行一系列的报警和优先级设置，使得重要的任务优先且正确的产出；
重要的任务：资产等级较高的业务；
任务优先级
对于 Map 任务和 Reduce 任务，调度是一个树形结构（RelNode 树），当配置了叶子节点（RelNode 节点）的优先级后，这个优先级会传递到所有上游节点，所以优先级的设置都是给到叶子节点，而叶子节点往往就是服务业务的消费节点；
设置优先级：首先确定业务的资产等级，等级高的业务所对应的消费节点自然配置高优先级，一般业务则对应低优先级，确保高等级业务准时产出；
任务报警
任务报警和优先级类似，也是通过叶子节点传递；
任务在运行过程中难免会出错，因此要确保任务能够高效、平稳地执行，需要有一个监控报警系统，对于高优先级的任务，一旦发现任务出错或者可能出现产出延迟，就要报警给到任务和业务 Owner；
摩萨德：阿里自主开发的监控报警系统；
摩萨德
摩萨德：离线任务的监控报警系统；是数据运维不可或缺的保障工具；
根据离线任务的运行情况实时决策是否告警、何时告警、告警方式、告警给谁等；
两个主要功能：强保障监控、自定义告警；
强保障监控
强保障监控是摩萨德的核心功能，是仅仅围绕运维目标即业务保障而设计的，只要在业务的预警时间受到威胁，摩萨德就一定会告警出来给到相关人员；
「驱动力」
强保障监控主要包括：
监控范围：设置强保障业务的任务及其上游所有的任务都会被监控；
监控的异常：任务出错、任务变慢、预警业务延迟；
告警对象：默认是任务 Owner，也可以设置值班表到某一个人；
何时告警：根据业务设置的预警时间判断何时告警；
业务延迟预警和出错报警，都是根据 “产出预警时间“ 来判断的；
产出预警时间：摩萨德根据当前业务上所有任务最近 7 天运行的平均时间来推算当前业务所用的大概时间，来作为产出预警时间；
告警方式：根据业务的重要紧急程度，支持电话、短信、旺旺、邮件告警；
例：生意参谋业务（预警业务延迟）
资产等级及需求：定义的资产等级是 A2，要求早上 9:00 产出数据给到上架；
设置：给生意参谋业务定义一个强保障监控，业务产出时间是 9:00，业务预警时间是 7:00；
这里的预警时间是指，一旦摩萨德监控到当前业务的产出时间超出预警时间时，就会打电话给值班人员进行预警；
如，摩萨德推测生意参谋的产出时间要到 7:30，那么电话告警就出来了，由值班人员来判断如何加速产出；产出时间推算（预警判断，也就是产出延迟判断）：摩萨德是根据当前业务上所有任务最近 7 天运行的平均时间来推算的；虽然有误判的可能性，但是总体还是非常准确的，可以接受；
- 自定义监控
自定义监控是摩萨德比较轻量级的监控功能，用户可以根据自己的需求进行配置，主要包括：
- 出错告警：可根据应用、业务、任务三个监控对象进行出错告警配置，监控对象出错即告警给到人 / Owner / 值班表；
- 完成告警：可根据应用、业务、任务三个监控对象进行完成情况告警配置，监控对象完成即告警给到人 / Owner / 值班表；
- 未完成告警：可根据应用、业务、任务三个监控对象进行未完成情况告警配置，监控对象未完成即告警给到人 / Owner / 值班表；
- 周期性告警：针对某个周期的小时任务，如果在某个时间未完成，即告警给到人 / Owner / 值班表；
- 超时告警：根据任务运行时长进行超时告警配置，任务运行超过指定时间即告警给到人 / Owner / 值班表；
…… …… …… …… …… …… ……
- 摩萨德甘特图的服务
针对业务的运行情况，摩萨德会提供一天关键路径，即完成业务的最慢任务链路图；因为每个业务上游可能有成千上万个任务，所以这条关键路径对于业务链路优化来说非常重要；
04 质量衡量
保障数据仓库的数据质量，有很多方案，评价这些方案的优劣，需要一套度量指标：
- 数据质量起夜率
一般数据仓库的作业任务都是在夜晚进行，一旦出现问题就需要值班人员起夜进行处理；
起夜率：用每个月的起夜次数，作为衡量数据质量建设完善度的一个指标；
- 数据质量事件
数据质量事件：记录每一次数据质量的问题；
针对每一个数据质量问题，都记录一个数据质量事件：
功能：既用来衡量数据本身的质量，也用来衡量数据链路上下游的质量，是数据质量的一个重要度量指标；
- 用来跟进数据质量问题的处理过程；
- 用来归纳分析数据质量原因；
- 根据数据质量原因来查缺补漏，既要找到数据出现问题的原因，也要针对类似问题给出后续预防方案；
- 数据质量故障体系
对于严重的数据质量事件，将升级为故障；
故障：指问题造成的影响比较严重，已经给公司带来资产损失或者公关风险；
背景：数据从采集到最后的消费，整个链路要经过几十个系统，任何一个环节出现问题，都会影响数据的产出，因此需要一种机制，能够将各团队绑在一起，目标一致，形成合力，故障体系在这个背景下应运而生；
故障体系中，一旦出现故障，就会通过故障体系，要求相关团队在第一时间跟进解决问题，消除影响；
「驱动力」
1）故障定义
首先识别出重要的业务数据，并注册到系统中，填写相关的业务情况，如技术负责人、业务负责人、数据应用场景、延迟或错误带来的影响、是否会发生资产损失等，完成后，会将这部分数据的任务挂到平台基线上，一旦延迟或错误，即自动生成故障单，形成故障；
2）故障等级
故障发生后，会根据一定的标准判断故障等级，如故障时长、客户投诉量、资金损失等，将故障按 P1~ P4 定级，各团队会有故障分的概念，到年底会根据故障分情况来判断本年度的运维效果；
3）故障处理
故障发生后，需要快速地识别故障原因，并迅速解决，消除影响；
在处理故障的过程中，会尽量将故障的处理进度通知到相关方，尽可能减少对业务的影响；
4）故障 Review
故障 Review：即分析故障的原因、处理过程的复盘、形成后续解决的 Action，并且都会以文字的形式详细记录，对故障的责任进行归属，一般会责任到人；
注：对故障责任的判定，不是为了惩罚个人，而是通过对故障的复盘形成解决方案，避免问题再次发生；
电话：1580-136-5057
邮箱：kai.zhao@yeepay.com
地址：朝外大街甲6号万通中心D座25层
增值电信业务经营许可证：陕B2-20210327 | 
陕公网安备 61102302611033号