一、什么是数据质量管理？

数据质量管理是指对数据从产生、获取、存储、共享、维护、应用等各个阶段可能引发的各类数据质量问题，进行识别、度量、监控、预警等一系列管理活动，并通过改善和提高组织的管理水平使数据质量获得进一步提高。

“数据质量管理是对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的数据质量问题，进行识别、度量、监控、预警等一系列管理活动，并通过改善和提高组织的管理水平使得数据质量获得进一步提高。数据质量管理的终极目标是通过可靠的数据提升数据在使用中的价值，并最终为企业赢得经济效益。”——以上内容摘自百度百科。

笔者观点：“数据质量管理不单纯是一个概念，也不单纯是一项技术、也不单纯是一个系统，更不单纯是一套管理流程，数据质量管理是一个集方法论、技术、业务和管理为一体的解决方案。通过有效的数据质量控制手段，进行数据的管理和控制，消除数据质量问题进而提升企业数据变现的能力。在数据治理过程中，一切业务、技术和管理活动都围绕这个目标和开展”。

数据质量管理的目的？

解决企业内部数据使用过程中遇到的数据质量问题，提升数据的完整性、准确性和真实性，为企业的日常经营、精准营销、管理决策、风险管控等提供坚实、可靠的数据基础。

二、数据质量问题有哪些？

数据真实性：数据必须真实准确的反映客观的实体存在或真实的业务，真实可靠的原始统计数据是企业统计工作的灵魂，是一切管理工作的基础，是经营者进行正确经营决策必不可少的第一手资料。

数据准确性：准确性也叫可靠性，字段值 错误、缺失，空值。成绩单中分数出现负数或订单中出现错误的买家信息等。是用于分析和识别哪些是不准确的或无效的数据，不可靠的数据可能会导致严重的问题，会造成有缺陷的方法和糟糕的决策。

数据唯一性：用于识别和度量重复数据、冗余数据。重复数据是导致业务无法协同、流程无法追溯的重要因素，也是数据治理需要解决的最基本的数据问题。

数据完整性：数据完整性问题包括：模型设计不完整，例如：唯一性约束不完整、参照不完整；数据条目不完整，例如：数据记录条数，丢失或不可用；数据属性不完整，例如：数据属性空值。不完整的数据所能借鉴的价值就会大大降低，也是数据质量问题最为基础和常见的一类问题。

数据一致性：多源数据的数据模型不一致，例如：命名不一致、数据结构不一致、约束规则不一致。用户ID必须保持同一种类型，且长度也要保持一致。数据实体不一致，例如：金额不平、（数据量条数）数据编码不一致、命名及含义不一致、分类层次不一致、生命周期不一致。相同的数据有多个副本的情况下的数据不一致、数据内容冲突的问题。

数据关联性：数据关联性问题是指存在数据关联的数据关系缺失或错误，例如：函数关系、相关系数、主外键关系、索引关系等。存在数据关联性问题，会直接影响数据分析的结果，进而影响管理决策。

数据及时性：数据的及时性(In-time)是指能否在需要的时候获到数据，数据的及时性与企业的数据处理速度及效率有直接的关系，是影响业务处理和管理效率的关键指标。

三、数据质量问题根因分析

说到数据质量问题的原因，做过BI或数仓项目的小伙伴肯定都知道，这是一个业务和技术经常扯来扯去、互相推诿的问题。在很多情况下，企业都会把数据质量问题推给技术部门，让技术部门去查找和处理。但是企业的数据质量问题真的都是技术引起的吗，技术部门人一定会说：“这个锅我不背！”

其实，影响数据质量的因素主要就技术、业务、管理三个方面，下面我们就来从这三方面分析下产生数据质量问题都有哪些原因。

1、技术方面

数据模型设计的质量问题，例如：数据库表结构、数据库约束条件、数据校验规则的设计开发不合理，造成数据录入无法校验或校验不当，引起数据重复、不完整、不准确。

数据源存在数据质量问题，例如：有些数据是从生产系统采集过来的，在生产系统中这些数据就存在重复、不完整、不准确等问题，而采集过程有没有对这些问题做清洗处理，这种情况也比较常见。

数据采集过程质量问题， 例如：采集点、采集频率、采集内容、映射关系等采集参数和流程设置的不正确，数据采集接口效率低，导致的数据采集失败、数据丢失、数据映射和转换失败。

数据传输过程的问题，例如：数据接口本身存在问题、数据接口参数配置错误、网络不可靠等都会造成数据传输过程中的发生数据质量问题。

数据装载过程的问题，例如：数据清洗规则、数据转换规则、数据装载规则配置有问题。

数据存储的质量问题，例如：数据存储设计不合理，数据的存储能力有限，人为后台调整数据，引起的数据丢失、数据无效、数据失真、记录重复。

业务系统各自为政，烟囱式建设，系统之间的数据不一致问题严重。

2、业务方面

业务需求不清晰，例如：数据的业务描述、业务规则不清晰，导致技术无法构建出合理、正确的数据模型。

业务需求的变更，这个问题其实是对数据质量影响非常大的，需求一变，数据模型设计、数据录入、数据采集、数据传输、数据装载、数据存储等环节都会受到影响，稍有不慎就会导致数据质量问题的发生。

业务端数据输入不规范，常见的数据录入问题，如：大小写、全半角、特殊字符等一不小心就会录错。人工录入的数据质量与录数据的业务人员密切相关，录数据的人工作严谨、认真，数据质量就相对较好，反之就较差。

数据作假，对，你没看错，就是数据作假！操作人员为了提高或降低考核指标，对一些数据进行处理，使得数据真实性无法保证。

3、管理方面

认知问题。企业管理缺乏数据思维，没有认识到数据质量的重要性，重系统而轻数据，认为系统是万能的，数据质量差些也没关系。

没有明确数据归口管理部门或岗位，缺乏数据认责机制，出现数据质量问题找不到负责人。

缺乏数据规划，没有明确的数据质量目标，没有制定数据质量相关的政策和制度。

数据输入规范不统一，不同的业务部门、不同的时间、甚至在处理相同业务的时候，由于数据输入规范不同，造成数据冲突或矛盾。

缺乏有效的数据质量问题处理机制，数据质量问题从发现、指派、处理、优化没有一个统一的流程和制度支撑，数据质量问题无法闭环。

缺乏有效的数据管控机制，对历史数据质量检查、新增数据质量校验没有明确和有效的控制措施，出现数据质量问题无法考核。

小结：影响数据质量的因素，可以总结为两类，客观因素和主观因素。客观因素：在数据各环节流转中，由于系统异常和流程设置不当等因素，从而引起的数据质量问题。主观因素：在数据各环节处理中，由于人员素质低和管理缺陷等因素，从而操作不当而引起的数据质量问题。

四、数据质量管理的方法论(制定解决方案)

数据是数字化时代企业的重要资产，数据可以以产品或服务的形态为企业创造价值。既然数据可以是产品、可以是服务，那问题就简单了。虽然数据质量管理没有成熟方法论支撑，但是产品和服务的质量管理体系却已非常的成熟了，何不尝试用产品和服务的质量管理体系来管理数据质量？！那国际上最权威的质量管理体系IOS9001是否也适用于企业的数据质量管理呢？

下图是ISO9001基于PDCA的质量管理核心思想，其重点强调以客户为关注焦点、领导作用、全员参与、过程方法、持续改进、循证决策和关系管理。

依据ISO9001以及企业在数据治理方面的相关经验，笔者认为企业数据质量管理应从以下几个方面着手：

1、组织环境

我们在数据治理框架、主数据管理、数据标准管理等章节，都提到了组织机构的设置，这里再次强调一个强有力的数据管理组织的建设是数据治理项目成功的最根本的保证。其作业是两个层面：一是在制度层面，制定企业数据治理的相关制度和流程，并在企业内推广，融入企业文化。二是在执行层面，为各项业务应用提供高可靠的数据。

2、数据质量管理方针

为了改进和提高数据质量，必须从产生数据的源头开始抓起，从管理入手，对数据运行的全过程进行监控，强化全面数据质量管理的思想观念，把这一观念渗透到数据生命周期的全过程。数据质量问题是影响系统运行、业务效率、决策能力的重要因素，在数字化时代，数据质量问题影响的不仅仅是信息化建设的成败，更是影响企业降本增效、业务创新的核心要素，对于数据质量问题的管理，深度执行的总体策略“垃圾进，垃圾出（garbage in，garbage out）”，采用事前预防控制、事中过程控制、事后监督控制的方式进行数据质量问题的管理和控制，持续提升企业数据质量水平。

3、数据质量问题分析

关于质量问题的分析，笔者推荐采用经典的六西格玛（缩写：6σ 或 6Sigma），六西格玛是一种改善企业质量流程管理的技术，以“零缺陷”的完美商业追求，以客户为导向，以业界最佳为目标，以数据为基础，以事实为依据，以流程绩效和财务评价为结果，持续改进企业经营管理的思想方法、实践活动和文化理念。六西格玛重点强调质量的持续改进，对于数据质量问题的分析和管理，该方法依然适用。

根据六西格玛的DMAIC模型，我们可以将数据质量分析定义为六个阶段：

（1）定义阶段（D阶段）。界定数据质量治理的范围，并将数据质量改进的方向和内容界定在合理的范围内。通过使用主数据识别法、专家小组法、问卷调查法、漏斗法等方法，定义出数据治理的对象和范围。企业数据质量治理对象一般主要包括两类数据：一类是操作型数据，例如：主数据、参照数据和交易数据。另一类是分析型数据，例如：主题数据、指标数据等。注：根据笔者经验以及80/20法则，企业的数据质问题80%是由于管理不当或业务操作不规范引起的，参考：《主数据的3大特点、4个超越和三个80/20原则》。

（2）测量阶段（M阶段）。在定义出数据治理对象和内容后，需要选取以下若干个指标来作为数据质量评价指标，建立数据质量评估模型，对企业的数据进行评估和测量。常用的数据质量评价指标就是我们上述提到的：数据唯一性、数据完整性、数据准确性、数据一致性、数据关联性、数据及时性等。

（3）分析阶段（A阶段）。基于数据质量评估模型，执行数据质量分析任务，通过数据分析，找到发生数据质量问题的重灾区，确定出影响数据质量的关键因素。数据治理和大数据分析是密不可分的，数据治理的目标是提升数据质量从而提高数据分析的准确性，而大数据分析技术也可反向作用于数据治理，通过大数据分析算法和大数据可视化技术，能够更准确、更直观的定位到发生数据质量问题的症结所在。该阶段可以用的大数据技术包括：回归分析、因子分析、鱼骨图分析、帕累托分析、矩阵数据分析等。

（4）改进阶段（I 阶段）。通过制定改进管理和业务流程、优化数据质量的方案，消除数据质量问题或将数据质量问题带来的影响降低到最小程度。我们一直在强调数据质量的优化和提升，绝不单单是技术问题，应从管理和业务入手，找出数据质量问题发生的根因，再对症下药。同时，数据质量管理是一个持续优化的过程，需要企业全员参与，并逐步培养起全员的数据质量意识和数据思维。该过程主要用到方法：流程再造、绩效激励等。

（5）控制阶段(C阶段）。固化数据标准，优化数据管理流程，并通过数据管理和监控手段，确保流程改进成果，提升数据质量。 主要方法有：标准化、程序化、制度化等。

五、数据质量监控(事前预防控制、事中过程控制和事后监督控制)：

5、数据全周期管理

数据的生命周期从数据规划开始，中间是一个包括设计、创建、处理、部署、应用、监控、存档、销毁这几个阶段并不断循环的过程。企业的数据质量管理应贯穿数据生命周期的全过程，覆盖数据标准的规划设计、数据的建模、数据质量的监控、数据问题诊断、数据清洗、优化完善等方面。

（1）数据规划。从企业战略的角度不断完善企业数据模型的规划，把数据质量管理融入到企业战略中，建立数据治理体系，并融入企业文化中。

（2）数据设计。推动数据标准化制定和贯彻执行，根据数据标准化要求统一建模管理，统一数据分类、数据编码、数据存储结构，为数据的集成、交换、共享、应用奠定基础。

（3）数据创建。利用数据模型保证数据结构完整、一致，执行数据标准、规范数据维护过程，加入数据质量检查，从源头系统保证数据的正确性、完整性、唯一性。

（4）数据使用。利用元数据监控数据使用；利用数据标准保证数据正确；利用数据质量检查加工正确。元数据提供各系统统一的数据模型进行使用，监控数据的来源去向，提供全息的数据地图支持；企业从技术、管理、业务三个方面进行规范，严格执行数据标准，保证数据输入端的正确性；数据质量提供了事前预防、事中预警、事后补救的三个方面措施，形成完整的数据治理体系。

上图展示了在数据开发的流程中，数据质量平台可以提供哪些功能：

数据探查：可以根据各种维度来查看数据明细和分布情况。

数据对比：开发同学可能经常会发现线上表和测试表不一致，所以我们在任务上线的环节提供了数据对比的功能。

任务监控：监控线上数据，提供报警和熔断功能。

数据质量平台最有代表性的功能是：对数据开发平台产出的 Hive 表数据进行主键重复检测，如果存在重复则进行报警。

数据质量监控最有用的场景是防止数据问题蔓延到下游。举个例子：数据任务产出一张 Hive 表，该表可能会同步一些信息到 Hive metastore（HMS）。HMS 的主从架构可能存在一定的延迟，假设 HMS 出现问题，下游任务可能会读到脏数据，这时如果我们使用数据质量监控，就能及时发现问题，阻止下游任务运行。

1、事前预防控制：建立数据标准化模型、规则

统一指标定义

统一指标口径

统一外部数据输出归口

一、源端管控

源端变动，必须提前通知数仓侧。

有条件的话，使用工具监控源端重点内容的变动。

建立数据标准化模型，对每个数据元素的业务描述、数据结构、业务规则、质量规则、管理规则、采集规则进行清晰的定义，以上的数据质量的校验规则、采集规则本身也是一种数据，在元数据中定义。面对庞大的数据种类和结构，如果没有元数据来描述这些数据，使用者无法准确地获取所需信息。正是通过元数据，使得数据才可以被理解、使用，才会产生价值。构建数据分类和编码体系，形成企业数据资源目录，让用户能够轻松地查找和定位到相关的数据。实践告诉我们做好元数据管理，是预防数据质量问题的基础。

数据质量问题的预防控制最有效的方法就是找出发生数据质量问题的根本原因并采取相关的策略进行解决。

1）确定根本原因：确定引起数据质量问题的相关因素，并区分它们的优先次序，以及为解决这些问题形成具体的建议。

2）制定和实施改进方案：最终确定关于行动的具体建议和措施，基于这些建议制定并且执行提高方案，预防未来数据质量问题的发生。

2、事中过程控制: ETL管理和监控

事中数据质量的控制，即在数据的维护和使用过程中去监控和处理数据质量。通过建立数据质量的流程化控制体系，对数据的新建、变更、采集、加工、装载、应用等各个环节进行流程化控制。数据质量的过程控制，要做好两个强化：

（1）强化数据的标准化生产，从数据的源头控制好数据质量，该过程可以采用系统自动化校验和人工干预审核相结合的方式进行管理，数据的新增和变更一方面通过系统进行数据校验，对于不符合质量规则的数据不允许保持，另一方面采集流程驱动的数据管理模式，数据的新增和变更操作都需要人工进行审核，只有审核通过才能生效。

（2）强化数据质量预警机制，对于数据质量边界模糊的数据采用数据质量预警机制。数据预警机制是对数据相似性和数据关联性指标的重要控制方法。针对待管理的数据元素，配置数据相似性算法或数据关联性算法，在数据新增、变更、处理、应用等环节调用预置的数据质量算法，进行相识度或关联性分析，并给出数据分析的结果。数据预警机制常用在业务活动的交易风险控制等场景。

2.1、ETL管理和监控

ETL基本上就是几个维度

1、ETL任务运行的情况

如果是自研框架的话，可以在每个步骤加个AOP做一些日志的打印，如果是纯hive的话，可以看yarn页面

甚至自己调用api看：https://www.cnblogs.com/yurunmiao/p/4224137.html（Hive SQL运行状态监控（HiveSQLMonitor））

2、ETL任务开始，结束和消耗时间（轻量，适中，重量）

3、ETL的重要级别（是否涉及资产相关，是否是上游任务）

4、ETL成功失败的分析（这个一般调度框架都会知道，只是要考虑如何把消息整合到一起，写入同一个地方）

5、单独对某些类型的ETL做实时记录（比如spark任务，可以在跑完某一个步骤，往kafka推送一条跑数据的消息，这样就可以相对实时的监控到一些代码写成的ETL的日志情况，当长时间没有收到该任务的消息的时候，就可以做一些报警）

3、事后监督控制: 监控指标

3.1、数据质量监控--监控指标

一、源端管控

源端变动，必须提前通知数仓侧。

有条件的话，使用工具监控源端重点内容的变动。

二、数仓监控管理

对已有规范没有贯彻的给予警告：建模规范、开发规范、上线规范

使用工具加强数据质量监控，发现问题及时通知、告警。

建立数据质量解决机制，责任到人。

定期复盘

重要常见问题入告警规则

源端数据质量问题，协调源端解决

存储模型、ETL开发、上线流程等引起的问题，需要制定合适的解决方案

二、数据监控

我们对于的监控指标是这样的，数据还在数仓层面的时候，其实能够监控的维度不多

1、基于表

统计Count或者表实际占用的磁盘空间，PV（加group条件），UV（加group条件去重）可以提供几种默认报警规则根据平均值，上一次的值，或者7天前的值，与本次的值做比较，来设定是否报警，然后再提供自定义sql报警功能

基本上就是count总条数，PV，UV，环比，数据匹配率（join的场景下，会不会丢数据），或者聚合后的头部数据的对比

2、基于字段

默认提供重复值校验，字段缺失率（为null或者空字符串的比例）打分，也可以自定义，如果是数值类型可以计算平均值，最大/最小，中位数，四分位数等指标

3、偏向产品

不同产品对数据分析就会有不同的要求，而且都不太一样，比如留存，获客啊，用户行为喜欢啊，这个就非常的繁多了，还是根据产品或者分析的经验来做自定义吧

定期开展数据质量的检查和清洗工作应作为企业数据质量治理的常态工作来抓。

1）设置数据质量规则。基于数据的元模型配置数据质量规则，即针对不同的数据对象，配置相应的数据质量指标，不限于：数据唯一性、数据准确性、数据完整性、数据一致性、数据关联性、数据及时性等。

2）设置数据检查任务。设置成手动执行或定期自动执行的系统任务，通过执行检查任务对存量数据进行检查，形成数据质量问题清单。

3）出具数据质量问题报告。根据数据质量问题清单汇总形成数据质量报告，数据质量报告支持查询、下载等操作。

4）制定和实施数据质量改进方案，进行数据质量问题的处理。

5）评估与考核。通过定期对系统开展全面的数据质量状况评估，从问题率、解决率、解决时效等方面建立评价指标进行整改评估，根据整改优化结果，进行适当的绩效考核。

笔者观点：数据治理的“常态化”才是数据质量问题的最好解决方式，而要实现常态化治理就需要改变原来的企业组织形式、管理流程、转变观念，以适应这种变化。数据治理的“常态化”要经得起折腾，所以千万不能老做些重新发明轮子的亊情！

六、纠正数据问题

企业还需要不时进行主动的数据清理和处理补救，以纠正现有的数据问题。

纠正数据问题涉及数据的生产方、消费方，这一步骤需要企业数据环境中的前中后台共同开展数据纠错。数据质量管理方案要与企业的特定的业务目标紧密匹配，使各方对数据质量管理目标和纠正方案达成共识，这对数据质量目标的最终达成至关重要。

建立数据质量解决机制，责任到人。

七、质量考核体系KPI

对已有规范没有贯彻的给予警告：建模规范、开发规范、上线规范

使用工具加强数据质量监控，发现问题及时通知、告警。

数据质量考核建立数据质量KPI，通过专项考核计分的方式对各企业各业务域、各部门的数据质量管理情况进行评估。

以数据质量的评估结果为依据，并将问题数据归结到相应的分类，并按所在分类的权值进行量化。总结发生数据质量问题的规律，利用数据质量管理工具定期对数据质量进行监控和测量，及时发现存在的数据质量问题，并督促落实改正。

考核实行奖惩结合制，每次根据各业务域、各部门数据质量KPI的检核情况，分别给予相应的奖罚分值，作为各业务域、各部门年终考核的内容，并将数据质量专项考核结果纳入对于人员、部门的整体绩效考核体系中。

通过评价相关数据质量KPI水平，督促各方在日常工作中重视数据质量，在发现问题时能够追根溯源地主动解决，对于高水平的数据质量工作成果进行激励、表彰，提升企业的数据质量管理意识。

总结

数据质量管理是企业数据治理一个重要的组成部分，企业数据治理的所有工作都是围绕提升数据质量目标而开展的。要做好数据质量的管理，应抓住影响数据质量的关键因素，设置质量管理点或质量控制点，从数据的源头抓起，从根本上解决数据质量问题。对于数据质量问题采用量化管理机制，分等级和优先级进行管理，严重的数据质量问题或数据质量事件可以升级为故障，并对故障进行定义、等级划分、预置处理方案和Review。量化的数据质量使得我们可以通过统计过程控制对数据质量进行监测。一旦发现异常值或者数据质量的突然恶化，便根据数据产生的逻辑顺藤摸瓜找到产生数据的业务环节，然后采用六西格玛流程改善中的经典分析方法对业务进行完善，真正的做到有的放矢。

火山引擎流批数据质量解决方案和最佳实践

数据质量挑战

目前我们的数据质量挑战有哪些？可以通过几个用户 case 了解一下。

User Story 1

某流量级产品商业化系统，M 级日志条数/秒；希望秒级监控日志延迟、关键字段空值，T+1 检测日志波动率。

User Story 2

某内部业务系统，日志存储 ES；希望每 5 分钟检测上一周期日志波动情况。

User Story 3

某内部指标平台，业务数据由 Hive 定期同步到 ClickHouse；希望每次同步任务后检查 Hive 与 ClickHouse 中的指标是否一致。

通过上面的介绍，大家应该也大致清楚了当前数据质量需要解决的问题。可能有些同学会说，数据质量平台我也做过，问题归总起来也不复杂，总而言之就是对数据进行各种计算，对比计算来的阈值即可，一般直接依赖于 Spark 引擎或者 Hive 引擎计算即可。确实，其实这也是我们数据质量最开始的样子。那为什么会演化到目前这样，我们面临了一些什么问题？

首先是场景需求非常复杂：

离线监控不再多说了，大家都熟悉，主要是不同存储的数据质量监控，比如 Hive 或者 ClickHouse 。

字节跳动内部的广告系统对时效性和准确性要求很高，用广告同学的话说，如果用微批系统 10 min 才做一次检测，可能线上损失就上百万了甚至千万了。所以广告系统同学对实时性要求相对较高。

另外一个是复杂拓扑情况下的流式延迟监控。

最后是微批，指一段时间内的定时调度，有些 Kafka 导入 ES 的流式场景，需要每隔几分钟对比下前一周期。

此外，字节跳动各种产品会产出海量的日志数据，我们需要用有限的资源来满足大家对质量监控的需求。

面临这些挑战，我们的解决方案是什么？

流批数据质量解决方案

产品功能架构

火山引擎流批数据质量解决方案有 4 个大的功能：

离线数据质量监控：解决批和微批监控场景，支持 Hive、ClickHouse、ES 等多种数据源，并有字段、唯一性等多种监控维度，允许通过 SQL 自定义维度聚合进行监控。

流式数据质量监控：解决流式监控场景，支持 Kafka/BMQ 等数据源。

数据探查：解决数据开发之前对数据内容存疑问题，支持 Hive 数据源。

数据对比：解决新旧表数据一致性问题，支持 Hive/Hive SQL 数据源。

上图是数据质量平台的系统架构图，主要分为 5 个部分：

Scheduler：外部调度器，触发离线监控。主要分两种类型：

对外提供 API 调用任务；

定时调度，通过 calljob 调用数据。

Backend：后端服务，偏服务层，处理业务逻辑。主要负责：

质量平台和外部的交互，所有 API 响应都是通过这一层进行；

任务提交：用户在质量平台配置的规则会放到业务存储，Scheduler 被调用后，Backend 会将任务相关的参数配置进行任务提交；

获取质量监控的结果并进行判断，然后和外部系统进行交互，在需要时发送警报通知用户。

Executor：平台核心的任务执行模块，集成了一些引擎，例如数据探查使用 OLAP 引擎。质量监控部分使用 Griffin 的 Measure 进行数据统计。

Monitor：是一个相对独立的模块，主要进行状态服务的流转，提供重复报警等功能。

Alert Center：质量平台强依赖于该平台。它是外部报警服务，接收各种报警事件。

离线数据检测流程

下面看一下离线数据的检测流程

离线数据的监控、探查、对比的执行流程一致，主要分为 4 步：

监控触发：调度系统调用质量模块 Backend API；

作业提交：Backend 以 Cluster 模式提交 Spark 作业至 Yarn；

结果回传：作业结束 (成功、失败)，Driver 将结果 sync 至 Backend；

消息触发：Backend 根据结果触发相应动作 (例如：报警、消息提示)。

我们总结了一下数据质量平台的优势：

调度系统低耦合：数据质量平台没有和调度系统强绑定，一般可以用业务系统的 API 实现互相调用。

事件触发高效，Backend 水平扩展能力强：Backend 是无状态的实例服务，如果质量监控的业务系统较多，Backend 可以采用水平扩展的方式部署，接收请求并提交作业。

没有 Quota 限制：平台本身没有维护数据质量监控单独需要的资源队列，而是把这个权限开放给用户，用他们自身的资源做资源监控。这样就把 Quota 问题转换成了用户资源问题。

当然任何一个工具都不可能是完美的，数据质量平台暂时还有一些待提升的地方：

非 CPU 密集型查询较重：整个平台的设计是以任务提交的方式完成离线场景的需求。但是后来我们发现其实不需要启动 Spark 的作业仍然会启动一个 Spark 作业，如 ES SQL 查询，这个查询是很重的。

依赖 Yarn 做调度稳定性不高：平台上的任务在资源不充足或被挤占的情况下，会出现任务运行或调用很慢。

流式监控执行

对于流式数据的监控，我们选择了 Flink 引擎，因为流式数据不同于离线数据，不能用快照的方式低成本拿到过程。所以我们要依赖一些外部的时序数据库再加规则引擎来展示对数据的监控。

平台上流式数据监控的流程为：

根据规则定义，创建 Flink 作业；

根据报警条件，注册 Bosun 报警事件；

Flink 作业消费 Kafka 数据，计算监控指标写 Metrics；

Bosun 基于 Metrics 的时序数据，定时检测，触发报警；

Backend 接收报警回调，处理报警发送逻辑。

流式监控支持抽样 & 单 Topic 多 Rule 优化

Kafka 数据抽样

一般流式数据的问题都是通用性问题，可以通过数据采样发现问题。因此我们开发了数据采样的功能，减少数据资源的占比消耗。Flink Kafka Connector 支持抽样，可直接操作 kafka topic 的 offset 来达到抽样的目的。比如，我们按照 1% 的比例进行抽样，原来上 W 个 partition 的 Topic，我们只需要 ** 个机器就可以支撑。

单 Topic 多 Rule 优化

最早的时候我们是对一个 Topic 定义一个 Rule，然后开启一个 Flink 任务进行消费，执行 Rule。后来我们发现一些关键的数据需要对多个维度进行监控，也就是要定义多个维度的 Rule，对每一条 Rule 都开任务去消费是非常耗资源的，所以我们利用监控不是 CPU 密集型作业的特性，复用读取部分，单 slot 中执行多个 Rule，对 Topic 级别进行单一消费，在一个任务中把相关 Rule 都执行完。

未来演进方向

本文介绍了数据质量平台的实现和最佳实践，最后谈谈平台未来的演进方向。

底层引擎统一，流批一体：目前平台的离线任务大部分是基于 Spark 完成的，流式数据采用了 Flink 处理，OLAP 引擎又引进了 presto，导致这套系统架构的运维成本比较高。我们看到 Flink 目前的 presto 能力和 Flinkbatch 的能力也在不断发展，因此我们后续会尝试切一些任务，做到真正意义上的统一引擎。

智能：引入算法进行数据驱动。考虑引入 ML 方法辅助阈值选取或者智能报警，根据数据等级自动推荐质量规则。举几个例子，比如我们可以基于时序算法智能的波动率监控来解决节假日流量高峰和平常的硬规则阈值的提升。

便捷：OLAP 对性能提升比较显著，但是目前我们只用在了数据探查功能上。后续可以将 OLAP 引擎应用于质量检测、数据据探查、数据对比应用与数据开发流程。

优化：比如通过单一 Job，同时运行多个监控，将监控和数据探查结合。我们现在在尝试将数据质量的规则生成和数据探查做结合，做到所见即所得的数据和规则的对应关系。

Q&A

Q：数据质量问题的排查很多时候时间成本非常高，你们在数据质量问题的归因分析上有做什么工作吗？

A：这个问题是非常核心的痛点。这里可以介绍下目前我们的思路：联合字节跳动算法的同学做数据下钻，也就是对数据链路的每一张表都进行数据探查。如果发现质量问题，通过一些类似于血缘和字段的关系找到数据上游的字段。目前我们在做的还是这样偏探查+流程的方式去尽快了解上游数据，归因分析这部分暂时还没有什么进展。

Q：数据质量闭环是如何做的：比如数据质量问题由谁来解决？数据质量如何衡量？

A：数据质量问题谁来解决？谁在关注数据质量，谁去 push 推进，谁开发了数据，谁去解决数据质量问题。这是一个协作上的问题。

如何衡量数据质量？我们内部有一些可治理的指标，比如报警量、核心任何的报警率等。

Q：如何保证端到端数据一致性？

A：端到端数据一致性不是一个单一的工具能解决的，可能需要一些方案，比如：从端上上报的数据，结合埋点系统做数据校验，在发版的时候确定数据是准确的。但是我认为端到端数据一致性目前整个行业都还做的比较欠缺，业务端如果出现了问题，是很难排查的。如果对数据链路的每一层都做监控，可能问题排查起来会相对简单一些，但这种做法代价又比较大。