1. 元数据管理

1.1. 元数据管理

• 元数据管理，记录数据仓库中模型的定义，各层级间的映射关系，监控数据仓库的数据状态及ETL的任务运行状态；
• 一般会通过元数据资料库（Metadata Repository）来统一地存储和管理元数据，其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致；
• 元数据管理应具备的功能：
  • 搜索和发现：
    • 数据表、字段、标签、使用信息；
  • 访问控制：
    • 访问控制组、用户、策略；
  • 数据血缘：
    • 管道执行、查询；
  • 合规性：
    • 数据隐私/合规性注释类型的分类；
  • 数据管理：
    • 数据源配置、摄取配置、保留配置、数据清除策略；
  • AI 可解释性、再现性：
    • 特征定义、模型定义、训练运行执行、问题陈述；
  • 数据操作：
    • 管道执行、处理的数据分区、数据统计；
  • 数据质量：
    • 数据质量规则定义、规则执行结果、数据统计；

1.2. 元数据管理的价值

• 数据资源管理
  • 对数据资产进行有效的组织、管理，可以帮助数据专业人员收集、组织、访问和丰富元数据，以支持数据治理；
• 开发协同
  • 通过元数据管理，可以方便的进行数据调研成果的落地、共享，支撑数仓螺旋开发；
  • 方便数据在企业内横向、纵向传递，这是团队协作的要求，也是项目经验的知识沉淀；
• 动态的数据字典，方便元数据查询、审计
  • 支撑各类数据报表、运营统计，为后续数据处理提供基础元数据查询。
    • 比如：统计接入了多少个系统、每个系统有多少张表，数据清洗需要知道每张表的字段信息。
  • 元数据还可以通过 OpenAPI 实现导出，快速支持保障合规审计等工作。
• 确保数据的规范化、标准化，确保数据准确性、可用性；
• 数据生命周期管理；
• 最重要的意义就是数据资源的可管、可控、可查。

元数据管理回答的问题：

• 都有哪些数据？
• 数据在哪里用？
• 数据的业务定义是什么？
• 这个数据有没有其他名称？
• 这个数据与其他数据有什么关系？
• 谁在用这个数据？
• 为什么要使用这个数据？
• 这个数据什么时候、被谁、做过什么样的修改？
• 数据是否准确、可靠？

2. 元数据管理架构

2.1. 元数据管理平台架构

• 接入层
  • 适配不同元数据生产方，转换成标准定义，输出全种类实体、关系变更消息。
• 存储层（元数据库）
  • 基于元模型的实体、关系的存储与查询，支持统计与分析能力。
• 功能层
  • 提供元模型管理、元数据分析应用、元数据管理、元数据检核等功能。
• 应用层
  • 基于定板元数据提供单点、复杂查询服务，基于分析引擎提供面向不同角色的元数据分析服务。

2.2. 元数据管理架构的类型

• 集中式的架构
  • 指的是采集多种数据源的元数据到元数据自己的存储中来，再集中加工给其他场景提供服务；
• 分散式的架构
  • 没有自己的元数据存储，而是在使用的时候，去即时的查询其他数据源的元数据。
• 集中式的架构 VS 分散式的架构
  • 集中式的架构
    • 优点：可以快速的检索元数据，抽取的时候，也可以自由的转换，自定义补充，提升了元数据的质量；
    • 缺点：需要保证自身存储和其他源数据的一致性，增加了流程复杂度和工作量。
  • 分散式架构
    • 优点：元数据总能够保持最新，查询更加的简单；
    • 缺点：无法自定义或修改元数据项，查询也受源系统可用性的影响。

  一般我们推荐使用集中式架构，定时采集源系统的元数据，通过 hook 方式捕捉各种引擎运行时数据血缘关系，并且定义通用的数据模型提供给第三方接入使用。

3. 元数据管理平台设计要点

3.1. Hook 方式采集数据血缘

当前众多大数据组件都提供了 Hook 钩子的方式，相当于以插件的方式实时的捕捉执行计划。解析之后，推送到 Kafka，再去解析到分布式的图数据库中。

3.2. 通用的数据源模块

一般公司肯定是存在多种不同类型的数据源的，比如 Mysql，Oracle，Hive 等，可以制作一个通用的模块，提供统一的接口，来对接这些不同的数据源。

数据源模块则提供三方接口供采集模块定时采集数据源的元数据信息。

核心的技术点，就是要隔离不同数据源的驱动，这些驱动也需要以插件化来集成到数据源模块中。

3.3. 个性化的 SDK 接入

如果公司的核心业务部门比较多，公司的数据平台产品比较多，那么势必会产生一些其他的元数据。比如监控平台监控的资源使用情况、任务调度的任务运行情况等。

这种 SDK 接入，需要考虑接入时的安全校验，限流（可定时消费一批Kafka数据来实现）等问题。

3.4. 后端存储的统一模型

元数据类型纷繁杂乱，需要统一整理抽象，再分类存储，并且设计之初，就要尽可能的详尽所有情况，设计出统一的表模型，预留扩展字段。

有一套模型是专门解决元数据模型通用性问题的，叫做 CWM （Common Warehouse Metamodel）标准，翻译过来是公共仓库元模型，这里提供了三层元模型来存储一切不同类型的元数据，当然设计起来比较复杂，一般超大型企业会采用这种模型。

如果可以详尽公司未来的元数据种类，可以分门别类建不同类型的元数据模型表来解决。

4. 元数据管理服务

4.1. 元数据查询

4.2. 元模型管理

• 元模型，一些是关系型的，一些是非关系型的，在概念层面它们都代表相同的实体，如：如数据集、数据表、数据字段、数据系统、应用程序、分类、业务术语表、数据血缘等。
• 对于业务元数据，以系统的方式存储所有元数据而不是维护电子表格也非常有必要。

4.3. 元数据维护

4.4. 元数据版本管理

4.5. 元数据对比分析

4.6. 元数据适配器

4.7. 元数据同步管理

4.8. 元数据生命周期管理

5. 元数据分析服务

5.1. 血缘分析

• 血缘分析是一种技术手段，用于对数据处理过程的全面追踪，从而找到某个数据对象为起点的所有相关元数据对象以及这些元数据对象之间的关系。
  • 元数据对象之间的关系特指表示这些元数据对象的数据流输入输出关系。
• 通过血缘分析，可以告诉开发者数据来自哪里，都经过了哪些加工。
• 血缘分析的价值，在于当发现数据问题时、可以通过数据的血缘关系、追根溯源，快速地定位到问题数据的来源和加工过程，减少数据问题排查分析的时间和难度。
  • 这个功能常用于数据分析发现数据问题时，快速定位和找到数据问题的原因。

• 在元数据管理系统成型后，我们便可以通过血缘分析来对数据仓库中的数据健康、数据分布、集中度、数据热度等进行分析。

• 数据血缘分析还有其它的积极意义，比如：
  • 问题定位分析
    • 类似于影响分析，当程序运行出错时，可以方便找到问题的节点，并判断出问题的原因以及后续的影响
  • 指标波动分析
    • 当某个指标出现较大的波动时，可进行溯源分析，判断是由哪条数据发生变化所导致的
  • 数据体检
    • 判定系统和数据的健康情况，是否存在大量的冗余数据、无效数据、无来源数据、重复计算、系统资源浪费等问题
  • 数据评估
    • 通过血缘分析和元数据，可以从数据的集中度、分布、冗余度、数据热度、重要性等多角度进行评估分析，从而初步判断数据的价值

5.2. 影响分析

• 影响分析，告诉开发者数据都去了哪里，经过了哪些加工。
• 影响分析的价值，在于当发现数据问题时，可以通过数据的关联关系、向下追踪，快速找到都哪些应用或数据库使用了这个数据，从而避免或降低数据问题带来的更大的影响。
  • 这个功能常用于数据源的元数据变更对下游ETL、ODS、DW等应用应用的影响分析。
• 在开发中，我们经常会遇到这个问题：如果我要改动某个表、ETL，会造成怎样的影响。
  • 如果没有元数据，那我们可能需要遍历所有的脚本、数据，才能得到想要的答案；
  • 而如果有成熟的元数据管理，那我们就可以直接得到答案，节省大量时间。

5.3. 冷热度分析

• 冷热度分析，是告诉开发者哪些数据是企业常用数据，哪些数据属于“僵尸数据”。、
• 冷热分析的价值，在于让数据活跃程度可视化，让企业中的业务人员、管理人员都能够清晰的看到数据的活跃程度，以便更好的驾驭数据，激活或处置“僵死数据”，从而为实现数据的自助式分析提供支撑。

5.4. 关联度分析

• 关联度分析，是告诉你数据和其他数据的关系、以及它们的关系是怎样建立的。
• 关联度分析，是从某一实体关联的其它实体、和其参与的处理过程，两个角度来查看具体数据的使用情况，形成一张实体和所参与处理过程的网络，从而进一步了解该实体的重要程度。
  • 如：表与ETL 程序、表与分析应用、表与其他表的关联情况等。

    本功能可以用来支撑需求变更的影响评估。

5.5. 数据资产地图

• 数据资产地图，是告诉你有哪些数据，在哪里可以找到这些数据，能用这些数据干什么。
• 通过元数据，可以对企业数据进行完整的梳理、采集和整合，从而形成企业完整的数据资产地图。
• 数据资产地图，支持以拓扑图的形式进行、可视化展示各类元数据和数据处理过程，通过不同层次的图形展现粒度控制，满足业务上不同应用场景的数据查询和辅助分析需要。
• 数据地图包括了数据资源的基本信息，存储位置信息、数据结构信息、各数据之间关系信息，数据和人之间的关系信息，数据使用情况信息等，使数据资源信息详细、统一、透明，降低“找数据”的沟通成本，为数据的使用和大数据挖掘提供支撑。
• 通过元数据以企业全局视角对企业各业务域的数据资产进行盘点，实现企业数据资源的统一梳理和盘查，有助于发现分布在不同系统、位置或个人电脑的数据，让隐匿的数据显性化。

5.6. ETL 自动化管理

• 在数仓中，很大一部分 ETL 都是枯燥重复的步骤。
  • 例如：
    • 源系统-ODS 层的：表输入——表输出。
    • 又比如 ODS-DW：SQL 输入——数据清洗——数据处理——表输出。
    • 以上的规则其实就属于一部分元数据。
• 那理论上完全可以实现，写好固定脚本，然后通过前端选择——或 api 接口。
• 进而对重复的 ETL 实现自动化管理，降低 ETL 开发的时间成本。

5.7. 数据安全管理

• 在数据中台，一切数据接口指标，都会从数据仓库中出口。
• 因此理论上，只需在此处的元数据中对管理元数据的权限进行配置，即可实现全公司的数据安全管理。

6. 元数据采集服务

• 采集服务，需要能够适应异构环境：
  • 支持从传统关系型数据库、大数据平台中采集；
  • 支持从数据产生系统到数据加工处理、从系统到数据应用报表系统的全量元数据，包括过程中的数据实体（系统、库、表、字段的描述）以及数据实体加工处理过程中的逻辑。
• 需要多种采集适配器：
  • 支持多种存储格式的元数据自动获取，如：数据库、报表工具、ETL工具、文件系统等；
  • 对于无法完成自动获取的元数据，需要可自定义的元数据采集模版，以完成元数据的批量导入。

7. 元数据访问服务

• 元数据访问服务是元数据管理软件提供的元数据访问的接口服务，一般支持REST或Webservice等接口协议。
• 通过元数据访问服务支持企业元数据的共享，是企业数据治理的基础。

8. 元数据项目的实施步骤

8.1. 划定元数据范围

首先确定元数据来源范围，在实际的工作中，不是所有数据都是要做元数据管理，通常我们会选择业务数据做元数据管理，非业务数据（例如：备份数据、系统日志等）是不会纳入管理范围内，主要还是因为元数据管理是提供业务和开发人员快速掌握业务数据。

确定规则后，就要结合公司的实际情况去梳理出哪些业务系统、哪些数据库、哪些数据库用户、哪些表需要做元数据管理。当然也可以支持非结构化数据的元数据抽取，例如：word、pdf等。

8.2. 元数据标准

在梳理的过程中可能会出现有些数据库或者有些数据定义不规范的情况，导致元数据管理无法进行下去。那接下来需要建立元数据的管理规范，去反推前端的源数据进行整改，主要是保证元数据的完整性和一致性。

针对不同的类型的公司要求，元数据会开放给不同的人群，所以要对元数据进行权限管理，规范里面就需定义权限的管理流程：元数据的权限分层、元数据权限申请流程、元数据的发布流程、元数据的审核流程。

我的公司将元数据分为业务和技术两个管理属性，技术人员可以查看全域元数据，业务人员只能查看自己所对应业务流程的元数据，如要查看其他业务流程的元数据，需进行申请，申请流程要过元数据对应的业务和技术属主。

8.3. 元数据接入

元数据从哪接入，一般都是从源系统接入，假如公司已经存在数仓或者实时性要求不高，为了节约开发工作量，对于已有的元数据会从数仓接入，还未接入的会从源系统进行接入。

但这种方案也是存在风险，假如数仓的数据和源系统出现不一致，就会导致元数据出错。现在大部分的元数据抽取都是采用配置自动化的方式进行。

8.4. 元数据维护

元数据维护主要是对已经发布的元数据进行维护管理，已经发布上线的元数据，如需调整、优化则必须重新走元数据发布流程，不准许对元数据进行直接修改。为了安全，元数据所有操作行为都要记录到元数据操作日志里面。

可以对元数据创建目录将不同的元数据挂在对应的目录下，按照业务流程、业务主题域、开发流程设计对应的目录，主要还是根据公司要求设计。

8.5. 元数据查找、分析、报告

有单独的页面支持元数据的模糊或精准快速查找，通过输入关键信息查找对应的元数据。我所在的公司将元数据作为数据资产的一类，因此我们需要产出元数据资产报告，从报告中能够快速的了解元数据访问热度、数据价值、数据成本、数据分布等相关信息。

分析这块上一篇文章就有提到，主要是血缘分析，做血缘分析的两种方法。血缘分析对做关联影响分析很重要，尤其是刚进来的开发或者业务不了解数据，通过血缘分析能够快速的定位、分析数据。

• Previous
  数据治理：元数据的概念详解
• Next
  数据治理：数据治理的概念详解