数据仓库作为全行数据中心能高效支持全行或全公司的统计 、数据分析工作，除了稳定的ETL架构、高效的数据处理能力，流畅的开发管理流程，还需要有全面的数据管理体系，确保提供的数据准确性和高质量。数据管理主要有数据标准，元数据和数据质量3方面。那数据治理是指对没有规范或者不符合规范的数据进行清理并建立标准和规范，那也是从这3方面着手。那这三方面的数据管理也是全行级的管理，并不仅仅限于数据仓库，只是在数据仓库管理中会更多的使用到。
1、数据标准
数据标准指在全行或全公司范围内统一数据分类分级、定义、记录格式及转换、编码等技术标准。举个简单的例子，在核心系统中的客户性别和贷款系统中的客户性别是否一样？当两个系统的数据都到数据仓库的客户表中，需要怎么整合在一起。
最理想的方式是在公司刚建立的时候就定义了数据标准，每个系统建设时的数据字段都按同一个标准来，这样各个系统之间的数据表字段定义一致，无需转换就可以互相关联、比较。但现实中往往各个系统建设时同一个定义的字段在命名、格式、代码值等都会不同，导致在数据应用时需要互相转换才能统一计算。那数据标准就是制定一套全行的规范，各系统统一按这个规范转换后再一起进行数据加工和分析，那数据标准制定的原则有:
(1)以业务为导向：基于银行已有实际业务和系统情况制定数据标准；
(2)遵循外部标准：充分遵循各类成熟的外部标准，并按照国家标准、金融行业标准和国际标准的顺序进行采纳;
(3)前瞻性及科学性：既满足现阶段业务需求，更要结合国内外经验发展所带来的数据标准需求；
数据标准可以分为基础数据标准和业务标准，基础数据标准就是行内一套统一的字段定义和代码规范以及各系统数据字段往标准代码转换的规则，那这些数据标准和转换规则主要在数据仓库主模型进行落地，第5节中介绍的公共代码转换作业就是指这里往数据标准进行转换，除了转换规则外，数据标准的定义主要内容如下：
那业务标准主要有机构标准、产品标准、渠道标准、客户标准等，其实就是在第9节中提到的主题模型建设时最重要的主题数据分类和ID的确定。以下是一个银行产品标准的例子，对全行的产品进行统一分类，形成标准。
那标准定义完成后，对于后续的标准更新、增加等都需要有一定的管理流程，才能保证标准的统一性。那在数据标准制定时也会建设数据标准管理系统，它的主要功能有数据标准的维护和展现、数据标准的相关流程实现。
那在标准的推广中，从源系统直接改造那是最彻底的，但改造已建系统和产品化的系统工作量太大也无必要，因为数据标准的作用是统一全行的数据定义，便于数据分析和处理，通过数据仓库的数据集中和转换也可以达到同样的目的，那新系统的建设可以基于全行的数据标准进行表设计，减少数据分析转换成本。
2、元数据管理
元数据是“关于数据的数据”，包括技术元数据和业务元数据，其中，技术元数据包括物理模型及数据库对象的信息、数据据处理流程和关系信息、工具元数据信息（前端展示工具、ETL工具），业务元数据包括逻辑模型、应用指标和维度描述、业务功能描述。
那元数据管理也需要有系统来支撑，它的主要功能有：
（1）元数据采集，包括各个系统的数据库对象（表、视图、索引等）信息、系统间接口、ETL作业信息、数据转换进行采集并存储；
（2）数据展示：对采集的元数据信息进行展示、查询和简单统计；
（3）影响分析：影响分析是指以某一个物理表或者字段为出发点，查找其下游所有层次的影响对象。即“它被哪些表和字段加工使用了”，它以采集相关的数据库结构信息和ETL加工过程元数据为基础。结果以图形方式展示。影响分析是在数据结构层级做出的分析结果，分析对象可以是数据库表或字段。
（4）血缘分析：血缘分析是指以某一个物理表或者字段为出发点，查找其上游所有层次的对象，即“它从哪些表和字段来，是按什么规则加工的”，他和影响分析刚好分析路径相反。
影响分析和血缘分析在数据仓库分析源系统变动对数据仓库和下游系统的影响并调整时会经常用到，因此快速准确的影响分析功能可以提高数据仓库的维护效率。目前来看表级的分析可以做到精确和快速，但是字段级的影响分析还不能完全准确，主要是数据转换时的字段映射往往采集不到，因为光从工具来实现来看，开发人员写SQL五花八门，而且分析每个SQL字段映射需要能看到SQL执行引擎的底层信息，难度很大，但如果数据转换作业按照第5节中的配置化来做，可以只采集分析配置文件即可分析到数据转换规则，即提高开发效率，又能方便分析。如果有厂商保证在不需要任何规范的前提下能进行字段级的影响分析，那需要重点POC进行验证。
之前我们提到的指标系统其实也可以是元数据的一部分，但它还有计算跑批的功能，因此会单独建立一个子系统，减少耦合和影响。元数据管理系统更多的是管理和分析，在全行数据管理和数据仓库设计和需求分析中使用。
3、数据质量
数据质量是指数据的完整性、准确性和一致性，数据质量的好坏影响着数据分析的效果和质量，数据质量问题可能贯穿于ODS建设中的每一个环节，对数据质量检查和监控是数据仓库建设中必不可少的重要组成部分，数据质量问题可以分为业务问题好技术问题，技术问题指在数据在抽取、传输、整合、加载、分析等各个环节代码原因导致的数据问题，如数据拉链表出现断链的问题，主键重复等问题；业务问题指发现源业务系统的数据存在规则错误，如企业规模类型字段缺失或分类不准确、总账表科目出现借贷不平等。
数据质量问题可以通过数据质量检查来及时发现，那检查主要是根据数据质量检查规则来进行计算和比对。数据质量的问题越早发现对后续处理越简单，如果错误数据继续往后使用，那会影响后续所有使用的加工作业。那数据质量的检查可以在事前、事中和事后进行检查，事前是指在ETL作业前先对加工的源数据进行检查，发现问题及时停止作业，事中指在数据加工作业中间或者完成时对作业的结果进行检查，发现问题后续作业可以先暂停。事前和事中的检查往往是对关键的作业和表数据进行检查，比如检查重点字段账户余额总分是否一样，事后检查是在批处理结束后再安排检查，针对影响小且修复成本较小的问题。
数据质量检查系统主要的功能有：
（1）数据检查规则配置：配置规则需要能转换到可执行的SQL脚本、错误级别并能传递参数；
（2）数据质量作业：数据质量作业需要和调度系统进行集成，通过一个统一的数据质量检查作业，传入规则编号和参数既可选择检查规则进行数据质量检查。对于检查出错的作业根据规则配置的错误级别来暂停批处理或只是警告，继续执行后续作业。
（3）数据质量结果查询和处理：对于每天发现的数据质量问题结果进行存储并跟进后续处理结果，按周期对全行数据质量和改善情况进行统计和产生报告。
数据质量除了系统的规则和运行，最主要的还需要有从全行数据质量管理办法来确定数据质量问题处理的负责部门，对于业务数据问题需要业务部门进行数据更新、补录。在数据录入和业务过程中对数据录入进行规范操作。从数据产生的源头对数据质量进行控制。特别是会影响报送、数据分析的字段要重点关注。
4、数据补录
数据质量检查过程中会经常发现源系统的字段缺失，导致数据报送不符合规范，影响数据分析结果，那往往需要业务人员进行补录，那补录最好的系统当然是在源系统，但往往许多系统设计时并没有考虑补录数据的需求，因此可以在全行建立一个补录系统，通过配置需要补录的字段、格式、检查规则以及后台系统及数据库自动产生补录界面，该补录界面可以被各系统进行集成，以便在各系统进行数据补录。
那对于一些数据应用系统的结果数据，如反洗钱上报的交易对手缺失，可以在数据应用系统中补录，对于补录的数据如有必要也可以回传给数据仓库进行数据补充，以便其它系统使用。
数据质量管理、元数据管理、数据补录系统都可以被所有系统使用，可以作为全行的公共数据服务。再加上全行级的数据标准管理系统可以整合为数据管理系统，以便统一建设和管理，减少重复功能和配置。
版权声明：本文为acumen_leo博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/acumen_leo/article/details/97555426