点击关注上方“知了小巷”，
设为“置顶或星标”，第一时间送达干货。
前文回顾：
《数据模型⽆法复⽤，归根结底还是设计问题》从模型设计层⾯，逐步将分散、杂乱、烟囱式的⼩数仓整合成了可复⽤、可共享的数据中台，数据研发效能得到明显提升。那是不是交付数据⾜够快，使⽤数据的⼈就满意了呢？
供应链部⻔运营陈英俊（化名）每天上班第⼀件事情，就是打开供应链辅助决策系统（数据产品），根据系统上给出的商品库存数据、区域下单数据，制订商品的采购计划，然后发送给供货商。可是今天当他准备⼯作时，突然发现系统中部分商品库存数据显⽰为0，他第⼀时间将问题反馈给了数据部⻔。与此同时，与他⼀样⽆法⼯作的还有供应链部⻔的其他50多名运营。
接到投诉后，负责库存域的数据开发郝建（化名）⽴即开始定位，⾸先就“商品库存”指标的产出表ads_wms_sku_stock_1d进⾏排查，确认它产出任务没有问题，是这个任务的上游输⼊表数据有问题，引发下游表数据异常。
从数据⾎缘图中可以看到，ads_wms_sku_stock_1d上游有20多张表，郝建逐层校验是哪个表的数据出现问题，结果锁定在了dwd_wms_inbound_stock_df。这张表的产出任务在前⼀天有⼀次线上变更，任务代码存在漏洞，对部分商品⼊库数据格式解析异常，但是没有将异常抛出，导致产出数据表dwd_wms_inbound_stock_df 数据异常，进⽽影响了所有下游表。
排查问题⽤了近3个⼩时。
既然问题定位清楚，就要开始修复的流程。修改好代码后，郝建重新跑了dwd_wms_inbound_stock_df的产出任务，确认数据没有问题，然后需要重跑该任务下游链路上的5个任务（图中红⾊表的产出任务）。
运⾏完任务⽤了5个⼩时。
经过数据验证，确认没有问题，此时已经过去了将近9个⼩时。对于像陈英俊这样的运营来说，⼀天都⽆法⼯作。想必运营对数据是不会满意的？所以，光快还不够，还要保证质量。
当然，这个例⼦暴露出这样⼏个问题：
1. 数据部⻔晚于业务⽅发现数据异常，被投诉后才发现问题。
2. 出现问题后，数据部⻔⽆法快速定位到数据异常的根源，排查⽤了较⻓的时间。
3. 故障出现在数据加⼯链路的上游顶端，出现问题没有第⼀时间报警处理，导致问题修复时，所有下游链路上的任务都要运⾏，修复时间成本⾮常⾼。
这些问题最终导致了数据⻓时间不可⽤。那如何解决这些问题，确保数据⾼质量的交付呢？⾸先，我们要了解产⽣这些问题的根源，毕竟认识问题才能解决问题。
</> 数据质量问题的根源
在电商业务数据中台构建之初，对数据团队⼀年内，记录在案的321次数据质量事件做了逐⼀分析，对这些事件的原因进⾏了归纳，主要有下⾯⼏类。如果想要改进数据质量，不妨也对过去踩 过的坑做⼀次复盘，归⼀下类，看看问题都出在哪⾥，然后制定针对性的改进计划。
业务源系统变更
数据中台的数据来源于业务系统，⽽源系统变更⼀般会引发3类异常情况：
⾸先是源系统数据库表结构变更。例如业务系统新版本发布上线，对数据库进⾏了表结构变更，增加了⼀个字段，同时对部分字段的类型、枚举值进⾏了调整。这种表结构变更没有通知到数据团队，导致数据同步任务或者数据清洗任务异常，进⽽影响了下游数据产出。
第⼆个是源系统环境变更。经常在⼤促期间⻅到这种情况，其中的典型是前端⽤⼾⾏为埋点⽇志量暴增，系统管理员紧急对服务器进⾏扩容，上线了5台新的服务器，但是没有配置这5台服务器的⽇志同步任务，结果导致数据侧少了这5台服务器的数据，最终影响了数据计算结果的准确性。
最后⼀个是源系统⽇志数据格式异常。这种情况通常出现在前后端埋点⽇志中。业务系统发布上线引⼊埋点BUG，导致IP格式出现了不符合约定的格式（⽐如，我们⼀般约定的IP格式是166.111.4.129，结果出现了166.111.4.null），最终也会导致计算结果错误。
数据开发任务变更
这种情况在数据质量事件中占到了60%以上，⽽它⼤多数是由于数据开发的纰漏引发的，来看⼏个⽐较熟悉的例⼦：
1. 任务发布上线，代码中引⽤的测试库没有修改为线上库，结果污染了线上数据；
2. 任务发布上线，代码中使⽤了固定分区，没有切换为“${azkaban.flow.1.days.ago}”，导致数据异常；
3. 前⾯例⼦中，数据格式处理错误，代码忽略了异常，导致数据错误；
4. 任务配置异常，它通常表现在任务没有配置依赖，前⼀个任务没有运⾏完，后⼀个任务就开始运⾏，输⼊数据不完整，导致下游数据产出错误。
物理资源不⾜
在多租⼾下，Hadoop⽣态的⼤数据任务（MR，Hive，Spark）⼀般运⾏在yarn管理的多个队列上（调度器为CapacityScheduluer），每个队列都是分配了⼀定⼤⼩的计算资源（CPU、内存）。
这里展⽰了两种常⻅的物理资源不⾜，导致任务延迟产出的情况。
基础设施不稳定
从数量上来看，这类异常不算多，但影响却是全局性的。我们曾经在⼤促期间，碰到了⼀个Hadoop 2.7 NameNode的BUG，造成HDFS整个服务都停⽌读写，最终通过临时补丁的⽅式才修复。
总的来说，出现问题并不可怕，可怕的是，我们没有及时发现问题，尽快恢复服务，举⼀反三地通过流程和技术⼿段，降低问题出现的概率。所以接下来我们就来看⼀看，如何提⾼数据质量？
</> 如何提⾼数据质量？
要想提升数据质量，最重要的就是“早发现，早恢复”：
早发现早隔离早治疗
那具体如何做到这两个早呢？这里总结了⼀套数据质量建设的⽅法：
1. 添加稽核校验任务
在数据加⼯任务中，对产出表按照业务规则，设计⼀些校验逻辑，确保数据的完整性、⼀致性和准确性，这是提升数据质量最⾏之有效的⽅法。
通常建议在数据产出任务运⾏结束后，启动稽核校验任务对数据结果进⾏扫描计算，判断是否符合规则预期。如果不符合，就根据提前设定的强弱规则，触发不同的处理流程。
如果是强规则，就⽴即终⽌任务加⼯链路，后续的任务不会执⾏，并且⽴即发出电话报警，甚⾄可以要求，关键任务还要开启循环电话报警，直到故障被认领；如果是弱规则，任务会继续执⾏。但是存在⻛险，这些⻛险会通过邮件或者短信的⽅式，通知到数据开发，由⼈来进⼀步判断⻛险严重程度。
那具体要加哪些稽核规则呢？
完整性规则。主要⽬的是确保数据记录是完整的，不丢失。常⻅的稽核规则有表数据量的绝对值监控和波动率的监控（⽐如表波动超过20%，就认为是异常）。还有主键唯⼀性的监控，它是判断数据是否有重复记录的监控规则，⽐较基础。除了表级别的监控，还有字段级别的监控（⽐如字段为0、为NULL的记录）。
⼀致性规则。主要解决相关数据在不同模型中⼀致性的问题。商品购买率是通过商品购买⽤⼾数除以商品访问uv计算⽽来的，如果在不同的模型中，商品购买⽤⼾数是1W、商品访问uv10W，商品购买率20%，那这三个指标就存在不⼀致。
准确性规则。主要解决数据记录正确性的问题。常⻅的稽核规则有，⼀个商品只能归属在⼀个类⽬，数据格式是不是正确的IP格式，订单的下单⽇期是还没有发⽣的⽇期等等。
它们是强规则还是弱规则，取决于业务对上述异常的容忍度（⽐如涉及到交易、⽀付跟钱相关的，⼀般都会设置为强规则，对于⼀些偏⾏为分析的，⼀般都是弱规则）。
2. 建⽴全链路监控
在《数据模型无法复用，归根结底还是设计问题》一文中，强调数据中台的模型设计是分层的，确保中间结果可以被多个模型复⽤。
不过这会导致数据加⼯的链路变⻓，加⼯链路的依赖关系会⾮常复杂，最终当下游表上的某个指标出现问 题，排查定位问题的时间都会⽐较⻓。所以，我们有必要基于数据⾎缘关系，建⽴全链路数据质量监控。
从这个图中可以看到，业务系统的源数据库表是起点，经过数据中台的数据加⼯链路，产出指标“⿊卡会员购买⽤⼾数”，数据应⽤是链路的终点。
对链路中每个表增加稽核校验规则之后，当其中任何⼀个节点产出的数据出现异常时，我们能够第⼀时间发现，并⽴即修复，做到早发现、早修复。另外，即使是使⽤⽅反馈经营分析上的⿊卡会员购买⽤⼾数，相较于昨天数据⼤幅下降超过30%，我们也可以快速判定整个指标加⼯链路上节点是否运⾏正常，产出任务是否有更新，提⾼了问题排查速度。
3. 通过智能预警，确保任务按时产出
在数据质量问题中，会存在物理资源不⾜，导致任务产出延迟的情况。通常，所有数据中台产出的指标要求6点前产出。为了实现这个⽬标，我们需要对指标加⼯链路中的每个任务的产出时间进⾏监控，基于任务的运⾏时间和数据⾎缘，对下游指标产出时间进⾏实时预测，⼀旦发现指标⽆法按时产出，则⽴即报警，数据开发可以终⽌⼀些低优先级的任务，确保核⼼任务按时产出。
4. 通过应⽤的重要性区分数据等级，加快恢复速度
稽核校验会消耗⼤量的资源，所以只有核⼼任务才需要。核⼼任务的定义是核⼼应⽤（使⽤范围⼴、使⽤者管理级别⾼）数据链路上的所有任务。
5. 规范化管理制度
数据质量取决于稽核规则的完善性，如果数据开发没有添加，或者添加的规则不全，是不是就达不到早发现、早恢复？
这个问题戳中了要害，就是规则的完备性如何来保障。这不仅仅是⼀个技术问题，也涉及管理。 这需要制定⼀些通⽤的指导规则（⽐如，所有数据中台维护的表都需要添加主键唯⼀性的监控规则），但这些通⽤规则往往与业务关系不⼤。如果涉及业务层⾯，就要由数据架构师牵头，按照主题域、业务过程，对每个表的规则进⾏评审，决定这些规则够不够。
如果要做稽核校验，建议可以通过组建数据架构师团队，由这个团队负责核⼼表的规则审核，确保规则的完备性。
那么如果按照以上这⼏个⽅法建⽴了数据质量体系之后，要如何验证体系是否有效呢?
</> 如何衡量数据质量？
做数据治理，需要奉⾏“效果可量化”的原则，否则这个治理做到什么程度，很难衡量。那么如何评价数据质量是否有改进呢？除了故障次数，还可以有这样⼏个指标。
1. 4点半前数据中台核⼼任务产出完成率。这个指标是⼀个综合性指标，如果任务异常，任务延迟，强稽核规则失败，都会导致任务⽆法在规定时间前产出。
2. 基于稽核规则，计算表级别的质量分数。根据表上稽核规则的通过情况，为每个表建⽴质量分数，对于分数低的表，表负责⼈要承担改进责任。
3. 需要⽴即介⼊的报警次数，通常以开启循环报警的电话报警次数为准。对于核⼼任务，任务异常会触发循环电话报警，接到报警的数据开发需要⽴即介⼊。
4. 数据产品SLA。每个数据产品上所有指标有没有在9点产出，如果没有，开始计算不可⽤时间，整体可以按照不同数据产品的重要性进⾏折算，99.8%是数据产品⼀个相对⽐较好的SLA。
不过，技术和规范最终需要依靠产品来帮助落地，在公司内部，有⼀个数据质量中⼼的产品，通过介绍这个产品，希望能给出⼀个参考，如何去设计⼀个数据质量中⼼，或者在选型的时候，数据质量中⼼必须具备的功能。
</> 数据质量中⼼
数据质量中⼼（以下简称DQC）的核⼼功能是稽核校验和基于数据⾎缘的全链路数据质量监控。
DQC的⾸⻚是质量⼤屏，提供了稽核规则的数量、表的覆盖量以及这些规则的执⾏通过情况。通过这些数据，就能跟公司⽼板讲清楚，⽬前数据质量⽔平建设如何？⽬标是多少？距离⽬标还有多少差距。
在DQC 中创建稽核规则⾮常简单，DQC内置了⼤量的基础规则，例如IP字段格式校验，主键唯⼀性校验，表⾏数波动率校验，同时还提供了⾃定义SQL的⽅式，允许业务层⾯的规则创建，例如前⾯提到的⼀致性规则中，两个指标想除等于第三个指标，就可以通过⾃定义SQL解决。
DQC还提供了全链路监控的功能，覆盖了从数据导⼊、数据加⼯、模型产出、指标、到数据应⽤的完整链路。绿⾊节点代表数据正常，蓝⾊节点代表数据正在产出中，红⾊节点代表数据异常，灰⾊节点代表产出任务还未被调度到。通过这个监控，⼤幅提⾼了问题发现和定位的速度。
可以发现，⼀个好⽤的DQC，必须要具备的功能就是质量度量、稽核规则管理以及全链路监控。
</> 总结
重点：
1. 数据质量治理必须要做到全链路，从业务系统的数据源到指标所在的应⽤，这样可以提前发现问题，将故障消灭在摇篮中；
2. 根据应⽤的优先级和全链路⾎缘关系，圈定核⼼任务，要确保核⼼任务的稽核规则全覆盖，优先保障核⼼任务的按时产出，在资源紧缺时，有必要停⽌⾮核⼼任务。
3. 稽核规则的完备性，可以通过数据架构师团队对每个域下的核⼼表进⾏评审的⽅式保障，同时问题回溯和复盘，也可以不断地完善。
往期推荐：
