导读：
今天分享的主题是元数据治理实践，这是一项长期持续的工作，涉及多部门协作、多角色参与，链路长且复杂，要有完善的流程、成熟的平台、业务和技术部门共同参与，才能推进治理工作的有效展开。
1
背景说明
1.1 痛点问题
随着《“十四五”数字经济发展规划》的印发、数据治理相关法律法规的公布、数据治理高峰论坛的举办等等，都体现了数据治理的重要性。从国家宏观发展层面看，响应国家政府监管要求，数据治理是时代发展趋势。
另一方面，从企业发展和长远的战略规划来看，数据治理的痛点问题日渐突出，必须加快数据治理进程。企业面临的数据治理痛点可以总结如下：
质量问题：很多公司的数据部门启动数据治理的大背景就是数据质量存在问题。质量问题包括数据内容质量、元数据质量2方面。
（1）数据内容质量差：可能会影响业务分析和决策，数据内容质量差易导致数据问题后知后觉、数据可信度低、业务反馈意见大、数据部门压力大等；
（2）元数据质量差：会导致用户“找不到”、“看不懂”自己想要的数据。例如数据地图90%以上的用户都是IT技术人员，业务人员几乎很难使用。当表数量很大时，要找到一个自己想要的数据如大海捞针，即数据“找不到” ；数据地图78%的核心表都存在元数据信息缺失，尤其是业务元数据和管理元数据，用户找到数据但也难懂数据背后的含义，即数据“看不懂”问题。
安全问题：数据安全是一个企业的高压线，一旦数据泄露，对业务的影响非常之大，将造成重要影响。元数据缺失安全等级，就会导致数据在使用时，没有约束的依据和规则。
标准问题：没有标准则没有评判依据，杂乱无章的数据将是治理最大的困难。当公司业务部门比较多的时候，各业务部门、开发团队的数据标准不一致，数据代码、名称、口径重复，关键字段缺失等，导致数据打通和整合过程困难，无法进行数据流动和共享。
价值问题：数据资产只有被业务使用，才能体现出价值，否则将视为无效资产。而无效资产需要及时被发现、被治理，否则冗余的资产也会带来存储和管理成本。同时无效资产和有效资产混杂在一起，业务将很难识别哪些是有价值的资产，为业务使用带来的困难。
1.2 解决方案架构图
元数据治理是一项长期持续的工作，涉及多部门协作、多角色参与，链路长且复杂，需要有完善的流程、成熟的平台、业务和技术部门共同参与，才能推进治理工作的有效展开。元数据治理的解决方案架构图如下：
数据治理的最终愿景可以概括为三点：
- 流程方面：落地一套标准的数据治理规范流程
- 平台方面：沉淀一套全链路的数据治理工具体系
- 业务方面：定标准/保质量/抓安全/降成本/提价值
为了实现该愿景，我们将整个治理体系划分四层：
管理层：管理层主要是从集团层面来制定数据治理的组织架构、职责分配、制定流程，这是整个治理工作的基础前提，否则后续治理工作将无法展开。
标准层：标准层主要是定义整个数据治理过程中涉及到的各项标准，以及标准的落地评估。标准制定的内容主要包括模型设计规范、指标设计规范、模型开发规范、命名规则规范等等。
执行层：执行层则主要是各个产品模块的具体执行情况展示和分析，也是数据治理工作的重要内容来源。执行层包括元数据的资产全景、模型设计检测规范结果、质量分析报告、安全审计及访问控制、模型开发存储及计算资源情况等，通过执行层的数据结果可以反应当前存在哪些需要治理的数据和数据现状。
评价层：评价层则主要是针对执行层的结果，结合资产健康评估体系的规则，对目前待治理数据进行评分评价，指导数据治理工作人员进一步开展治理工作，并且通过治理工作台来查看整体治理进展。
1.3 元数据治理涉及的各产品间交互
元数据治理流程主要包括元数据采集、元数据注册、元数据治理、元数据发布、元数据使用。整条链路贯穿了各个子产品，包括数据源管理、数据质量、数据安全、数据标准、模型设计、数据资产目录及资产详情等，具体各产品间的交互关系及核心要素如下图所示：
1.4 名词解释
2
元数据治理流程介绍
2.1 存量元数据的治理流程
随着企业业务发展积累了大量的存量数据，数据可能分布在各个业务源系统中，涵盖多个数据源。这些数据若不加以有效利用，对于企业来说就是资源浪费且占据存储和管理成本，且如何从这些海量混杂的数据中，提取有价值、可业务复用的数据，也是数据治理要解决的问题。故存量数据的治理，是数据治理中的一大重点工作。整个元数据治理流程会涉及到IT运维团队、数据治理部门、各业务部门等协同推进完成。
存量元数据治理的业务流程图如下所示：
2.2 增量元数据的治理流程
增量元数据的治理流程和存量元数据的治理流程大部分相似，差别主要是新增数据的表物理模型还未创建，需要先经数据产品或数据开发进行元数据注册，此时主要是注册元数据的逻辑定义信息，经过注册审核后数据开发人员再去进行物理建模，这样建模得到的表更加标准和规范。数据开发人员物理建模后，治理人员再根据元数据信息完善度决定是否需要治理流程来补充元数据的其他信息。
增量元数据治理的业务流程图如下所示：
3
元数据治理产品案例实践
3.1 实践内容
3.1.1 案例场景描述
目标：通过一个简化的案例，介绍元数据基本的治理流程，该案例将介绍业务库存量表的元数据治理流程。
场景：某业务系统的MySQL库中存储了一张「客户信息表」，该表在实际业务中使用比较频繁，但是由于元数据缺失导致经常面临各种数据答疑、数据使用不规范等问题。故计划将该表采集到平台上进行治理，治理内容主要是完善表的业务信息、技术信息、管理信息等，以便将治理后的数据表呈现给用户，方便用户快速理解和使用表。
3.1.2 操作流程说明
为了实现上述案例的场景，我们需要完成以下事项：
（1）登记MySQL数据源，方便后续元数据使用；
（2）采集MySQL数据源中的「客户信息表」的元数据；
（3）「客户信息表」的元数据治理，包括元数据的安全、质量、标准、部门归属等信息；
（4）已治理的元数据表进行发布，发布后业务人员可以在资产目录中查看完整的元数据信息，以便业务使用。
3.2 操作步骤
第一步：登记数据源
在平台的数据源管理模块中，登记业务系统的MySQL数据源信息。登记内容主要包括数据源名称、负责人、数据源连接、用户名和密码等信息。
第二步：创建元数据采集任务
在元数据采集模块创建采集任务，采集上一步中登记的MySQL数据源中的「客户信息表」，根据实际业务场景需要设置采集的间隔周期。
第三步：申请元数据治理
元数据治理是整个操作实践过程中最重要，也是最复杂的一步。元数据治理一般会涉及到多部门间的协作治理，例如业务信息的补充完善需要业务部门专员参与治理，技术信息完善需要IT部门开发参与治理，最终治理的元数据在发布申请时需要治理部门进行最终审核确认。
上一步中采集的元数据表会在平台自动注册为一条元数据记录，此时元数据只有基本的物理信息例如表名、字段名、字段类型等，信息非常不完善。此时元数据是草稿状态，需要通过申请治理来派发治理工单给相关人员处理，如下图所示：
工单接收人接收到治理工单后，可以对元数据信息进行补充，包括表级和字段级的业务元数据、技术元数据等信息。表级元数据治理页面如下所示：
表级元数据信息分为基础信息、业务信息、技术信息，如果上述元数据内容还不够，还需要更多的元数据属性，系统也支持自定义属性及值域，以便业务灵活扩展元数据。
Tips：元数据治理页中，表的技术信息可以点击右侧的“扫描技术信息”按钮，触发一次元数据扫描功能。扫描后系统会自动将源库中的一些物理信息展示在页面上，方便用户确认最新表信息并覆盖填充。
接下来是字段的元数据治理页面，如下所示：
这里可以针对表的每个字段进行治理，治理内容包括基础信息、业务信息、技术信息。图中红色圈选出来的几个信息是和平台其他子产品相关联的内容，这里简单说明一下：
- 安全级别：可以在配置管理模块中设置安全级别的自动推荐方式，可以通过安全中心识别任务扫描获取安全级别，也可以通过第三方NLP接口智能推荐安全级别；
- 数据元：和平台的数据标准模块打通，数据标准中会定义数据元规范、格式、值域等；
- 数据质量管理信息：和平台数据质量中心打通，关联系统规则模板；
- 关联指标：和指标系统打通，能够了解字段和指标的关联关系；
- 关联标签：和标签系统打通，能够了解字段和标签的关联关系。
其他字段的治理项操作页面基本一致，这里就不一一展示了。
第四步：申请元数据发布
经过第三步的元数据治理后（实际治理过程可能需要多轮治理才能达到申请发布的条件）可以申请发布，以便将治理后的表资产共享给业务人员。
第五步：数据资产查看
已治理并发布后的元数据，可在资产目录中的对应业务目录下找到表，或者直接根据关键字搜索表。找到表后在表详情页可查看元数据信息，其中表和字段的基础信息、业务信息、技术信息都比较完善，在此基础上平台也提供了元数据其他丰富的功能例如数据预览、产出信息、数据血缘等等。
以上通过一个简单案例完成了元数据表从业务系统登记、采集、治理、发布、查看使用的主流程。实际业务场景中企业往往存在着大量历史数据亟待治理、同时新增数据的规范治理等，数据治理工作也会更加艰巨、复杂，治理项涵盖内容也会更多更深，由此也是对产品提出了更多的要求和挑战。
作者简介
梦琴，网易数帆有数资深产品经理，6年工作经验。目前主要负责数据地图、元数据中心和数据治理相关内容。
本文为从大数据到人工智能博主「今天还想吃蛋糕」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://cloud.tencent.com/developer/article/2143662
