引言最近在处理数据质量问题时我越来越认识到数据库、数据平台和分析模型并不能自动产生高质量数据。数据挖掘的价值建立在数据能够真实、完整和稳定地描述业务对象与业务过程的基础上。如果平台中的数据来源不清、含义不明、口径不一即使算法更加复杂、模型精度更高所得结果也可能只是对错误数据进行更加精细的计算。问题在于数据平台中的数据往往来自多个外围系统。数据被抽取、传输和加工之后原本依附于业务系统的字段含义、代码规则、流程状态和责任关系可能已经被削弱甚至丢失。数据虽然进入了平台却未必真正具备分析和使用条件。更困难的是数据治理人员不可能理解所有业务业务人员也不可能逐条检查海量数据。那么如何在数据源头提高质量又如何让业务知识持续进入数据治理过程核心观点数据质量不是后期清洗出来的而是在数据形成和流动过程中逐步建立起来的。一、数据质量为什么不能依赖末端清洗数据质量治理常常从数据清洗开始。平台发现字段缺失、格式错误、重复记录和异常值后通过转换、补齐、去重和修正等方式处理数据。这些工作十分必要但它们主要解决的是数据的形式问题。清洗可以把日期格式统一可以删除重复记录也可以将错误编码转换为标准编码却无法恢复已经丢失的业务事实。例如一条设备状态记录虽然格式完整但如果源系统在设备报废后仍然持续生成运行数据那么后期清洗很难判断哪条记录真实、哪条记录失效。又如同一个代码在不同系统中具有不同含义仅仅统一字段格式并不能消除业务语义上的冲突。数据从业务现场产生后需要经过采集、系统记录、接口传输、平台接入、加工处理和场景应用。任何一个环节发生偏差都可能影响最终结果。因此质量控制不能只布置在数据链路末端而应进入数据的整个生命周期。图1 数据质量不是“洗出来”的如图1所示正确的数据质量路径并不是“原始数据进入平台后集中清洗”而是在数据生成、传输、加工和使用过程中同步配置标准、规则、校验、追溯和反馈机制。这意味着数据质量治理的基本重心必须发生转变从事后修复数据结果转向控制数据产生和流动的过程。二、数据抽取以后为什么只剩下字段和记录外围系统中的数据并不是孤立存在的。在原有业务系统中一条记录通常与具体业务对象、业务流程和管理规则相互连接。字段代表什么含义、代码来自哪套标准、记录由谁创建、何时生效、允许如何变更都由原系统中的业务环境共同决定。但在传统的数据抽取过程中被迁移到数据平台的往往只有数据表、字段和记录。与数据相关的语义、规则、责任、流程和时间条件并不会自动进入平台。图2 数据抽取导致业务上下文丢失如图2所示数据一旦脱离原系统至少可能失去字段的真实业务含义及统计口径、代码表的版本和映射关系、记录的创建审核与状态流转过程、数据所有者及维护责任、数据之间的主从层级与依赖关系以及数据生效、失效和更新时间要求。因此数据在平台中“可见”并不等于它已经“可理解”数据在技术上能够被查询也不等于它能够直接被用于分析和决策。这也是为什么外围系统数据不能在完成抽取后立即被视为高质量数据。平台必须重新建立数据与业务上下文之间的连接包括补充业务定义、标准映射、代码关系、责任主体、时间语境和质量规则。数据治理在这一阶段解决的核心问题不只是数据是否正确而是平台能否重新理解这些数据代表什么以及在什么条件下可以使用。三、数据质量不存在脱离场景的统一答案即使数据语义已经明确也不能用一套完全相同的标准评价所有数据。数据质量并不是一种脱离用途而独立存在的属性。判断一份数据是否合格需要结合它所服务的业务目标、使用方式和风险程度。以设备位置数据为例用于月度资产统计时只要能够反映设备的总体区域分布少量时间延迟和位置误差可能不会影响结果。但如果同一份数据被用于实时风险预警则需要更高的定位精度、更短的更新周期和更完整的数据覆盖。如果数据直接驱动自动控制或模型决策对唯一性、一致性、可追溯性和可解释性的要求还会进一步提高。图3 同一份数据在不同场景中具有不同质量要求如图3所示数据质量治理不能首先提出一套抽象指标再机械地套用到所有数据上。更合理的顺序是先明确业务场景和使用目标再识别支撑场景的关键数据随后确定每项数据需要达到的质量边界最后配置对应的检查规则和验证证据。由此可以建立一条更加完整的关系业务场景 → 业务目标 → 关键数据 → 质量要求 → 判断规则 → 验证证据。完整性、准确性、一致性、唯一性和及时性等质量维度依然重要但它们必须服从场景需求。评价质量的关键不是数据在所有维度上是否达到最高水平而是它是否足以支撑当前场景并将业务风险控制在可接受范围内。四、不需要每个人都懂业务但必须让规则懂业务数据质量治理中最现实的困难是技术人员不能完全理解业务而业务人员也无法长期参与每一条数据的检查。很多质量判断最初以经验形式存在于业务人员的头脑、制度文件和日常操作中。例如设备报废后不应继续产生正常运行数据客户注销后不能继续创建有效订单一个身份证号码在同一系统中只能对应一个有效主体档案。如果这些知识始终停留在个人经验或口头约定中数据治理就会持续依赖少数业务专家。人员变化以后判断标准也可能随之丢失。解决这一问题的关键不是让所有治理人员都成为业务专家而是将分散的业务知识转化为组织能够重复执行的治理规则。图4 业务经验如何转化为可执行的数据质量规则如图4所示业务人员首先解释对象、状态、关系和操作条件治理人员将这些知识沉淀为业务术语、数据标准、主数据规则、代码体系、指标口径、数据质量规则和接口契约技术平台再依据这些规则自动执行校验、识别异常、记录证据并触发整改。在这一过程中各类人员承担不同职责。业务人员负责说明业务事实和判断边界数据治理人员负责将业务知识转化为标准和规则技术人员负责实现规则执行、监控和留痕数据责任人负责确认问题、推动整改并验证结果。这样数据质量治理就不再依赖某一个人是否了解全部业务而是依赖业务知识是否已经被组织化、结构化和规则化。真正需要实现的不是“人人都懂所有业务”而是让业务知识能够被系统识别、被平台执行、被组织复用。五、源头治理不是简单把问题退回源系统强调源头治理并不意味着数据平台发现问题以后只需要通知源系统修改数据。很多质量问题并不是由某一条错误记录造成的而是由录入方式、接口逻辑、业务流程或标准体系中的缺陷持续产生。例如源系统没有必填校验导致关键字段长期缺失不同系统使用不同代码表导致平台不断进行人工映射接口缺少更新时间和状态字段导致平台无法判断数据是否仍然有效。如果治理只修改平台中的结果数据相同问题仍会在下一次抽取时重新出现。因此源头治理需要区分两个层面。第一个层面是数据修复即修正已经产生的错误数据第二个层面是机制修复即调整产生错误数据的录入规则、接口逻辑、业务流程和责任机制。只有机制得到修复数据质量问题才不会持续重复产生。这也意味着平台必须保留完整的数据血缘、加工日志、规则执行结果和问题处理记录。没有这些证据治理人员只能看到错误结果却无法判断问题到底产生在业务录入、源系统、接口传输还是平台加工环节。六、数据质量如何真正形成闭环数据质量问题被发现并不意味着治理已经完成。真正的闭环需要回答五个问题问题发生在哪里为什么会发生由谁负责修复修复了数据还是修复了机制以及如何证明问题已经解决且不会重复发生。图5 数据质量问题的追溯、整改与复评闭环如图5所示数据质量闭环首先沿着数据血缘定位问题发生的具体环节。应用结果出现异常后需要依次检查加工规则、平台接入、接口传输、源系统记录和业务操作。在定位断点后应判断问题属于数据录入错误、标准冲突、接口缺陷、加工逻辑错误还是业务流程本身存在不合理之处。随后由对应责任主体执行整改并重新抽取、加工和校验数据。复评不是简单确认某条记录已经修改而是需要形成证据证明问题断点已经明确相关数据和治理机制已经修复受影响的数据范围已经识别修复后的数据能够满足目标场景监控和预警规则已经更新并且同类问题没有继续产生。因此质量治理的完整过程可以表示为发现问题 → 沿血缘追溯 → 定位质量断点 → 分析根本原因 → 修复数据与机制 → 重新验证 → 持续监控。闭环的目标不是把某次检查中发现的数据全部改对而是减少质量问题再次发生的可能性。七、数据质量评价不应只剩下一个分数很多数据质量平台最终会输出一个综合得分例如完整性95分、准确性90分或者数据集综合质量达到92分。这些分数可以帮助管理者快速了解整体情况但不能代替具体的治理判断。同样是90分的数据集可能一个数据集只存在非关键字段缺失另一个数据集却在核心风险预警字段上存在错误。两者的综合分数相近但对业务的影响完全不同。因此数据质量评价不应只呈现一个总分而应同时说明数据在不同质量维度上的实际状态、问题发生在哪一条数据链路、现有证据是否足以支持评价结论、问题会影响哪些业务场景、整改责任和进度如何以及复评结果是否证明问题已经真正解决。评价的目的不是为数据贴上“优秀、合格或不合格”的标签而是帮助组织识别数据质量形成过程中的具体断点并推动问题进入整改闭环。结语真正能够保证的是质量形成机制严格来说没有任何组织能够通过一次治理永久保证所有数据始终正确。数据源会变化业务规则会调整系统会升级场景要求也会不断提高。数据质量治理因此不可能是一项一次性工程而应成为数据生产和使用体系中的持续运行机制。真正能够被保证的不是某一时刻所有数据都没有问题而是数据用途和质量要求能够被明确业务知识能够转化为标准和规则数据来源及加工过程能够被追溯问题能够被及时发现和准确定位责任能够落实到具体主体整改结果能够通过证据重新验证相同问题能够通过规则和机制改进减少复发。当这些机制建立以后数据平台才不再只是存储和汇聚数据的技术设施而会逐步成为形成可信数据、支撑业务分析和模型应用的治理基础设施。数据挖掘的命中率和精确度也只有建立在这样的数据质量基础上才具有真正可以解释、验证和复用的价值。最终结论数据质量不能被一次性“验收完成”。真正可持续的保证是场景有标准、过程有规则、问题有血缘、整改有责任、复评有证据。