一、业务背景

1、应用场景

在多变的数据服务场景中，应用中常见如下的业务需求，通过对多种数据结构的灵活组合，快速实现业务模型构建，整体示意图如下：

像常用的画图工具，左边提供基础图形库，中间是画布，右边是组件的控制细节，对比到这里的逻辑如下：

• 字段面板：提供业务数据结构的字段映射，和常规字段类型配置，用来支撑组合面板的表单配置。

  • 数据结构：对现有业务结构做映射，可能是文件、数据表、JSON等，生成相对标准的字段选项；
  • 拓补字段：维护一批基础的字段类型，用来做拓补操作，完善整个业务结构；

• 组合面板：承载字段的组合管理，生成新的数据结构，根据业务场景，完成底层数据的抽取存储或者API服务生成。

  • 业务主体：通过业务需求的判断，明确面板支撑的业务属性，通过基础结构组合新的业务主体；
  • 组合结构：面板上呈现的字段，是多个业务结构的抽取，即不同业务结构中的部分字段组合；

• 规则面板：对组合面板上字段进行规制设定，常见涉及：描述，类型，默认值等，对面板字段进行相对统一的标准化管理。

  • 描述信息：对于组合面板上的字段描述，也可以是原有映射的结果，作为新业务主体的属性说明；
  • 类型维护：复杂的环节，不同数据类型在不同的存储中处理方式不同，需要统一维护类型存储映射；
  • 业务规则：对于新的业务主体，设置属性的规则，可以是：唯一性，默认值，等等；

2、构建服务

基于上述功能的实现，可以快速实现以下服务能力，通常应用在业务多变的场景中：

• 数据主体构建：通过组合面板的结构生成，快速完成相关数据的抽取和存储，作为新的业务场景中的主体数据。

• 服务API生成：在数据服务中，直接通过配置，生成API服务能力，并控制参数的响应结构，这种情况通常会以实时查询的方式处理。

• 数据智能分析：在数据分析场景中，侧重统计的结果，基于字段和图表结构，生成相应的统计分析任务，灵活管理分析报表。

这里是简述相对单一的应用服务，如果把这里的流程分段放大，在整个数据服务体系下，就是围绕元数据管理的复杂的基础系统：围绕数据结构映射，进行元数据标准化管理，在此基础上二次组织数据，快速响应业务需求。在这样的流程下，可以快速建立业务链路，提供高效的服务能力，降低试错的成本。

二、元数据概念

1、基础描述

从定义上说，元数据(Metadata)即描述数据的数据，但是在实际使用的时候，还是存在很多细分的概念，看下面的案例：用户性别；

从细分角度看，可以对上面数据进行两块划分，即业务层与技术层：

• 业务层：名称.释义.说明.值类型;
• 技术层：路由库.路由表.存储类型.值类型;

这里的分层只是描述的侧重点，业务层偏向应用端，技术层偏向底层系统的交互和实现，在对性别的描述上都是核心维度。

所以从本质上看元数据，介于系统和业务中间，提供双方都能明白的语义和逻辑，可以更加高效的支撑数据的业务价值。

2、血缘关系

上面是从单个指标看元数据的结构，如果从整个链路上看，就会形成层级线路，通常称为血缘关系：

从上层业务侧追溯到底层结构，形成血缘关系的概念，概念本身并不重要的，背后的核心是链路的管理，链路上的节点（中间实体）是通过多种计算手段生成；

如果某个节点数据一旦出现质量问题，则需要根据这里的链路关系进行逐级向底层排查，完成问题修复后，还需要根据关系向上逐级修复清洗；如此通过血缘关系进行数据质量的分析和把控。

3、业务价值

元数据管理是一个持续又漫长的过程的，任何系统的搭建都需要业务来衡量其存在的价值，其核心逻辑在于：统一标准化管理元数据信息，规范业务层的定义，并通过技术层面快速定位数据，自动化抽取数据，灵活支撑业务应用。

• 围绕核心业务：通常在项目初期的时候，只围绕一些核心业务主体，使其在使用的时候灵活高效，后续在持续扩展其他能力。

• 数据成本分析：基于元数据中链路，分析各个节点数据的生产维护管理等成本，为数据服务中商业定价提供参考，可能直接影响服务是否可提供的决策。

• 配置可视化：在数据服务平台中，最忌讳的一点就是靠手动去维护各种作业，不管在什么场景下，都要考虑可配置化管理，保证动作可追溯。

• 流程自动化：不管是元数据结构映射，还是配置后数据的抽取，要保证指令生成后可以自动完成该一系列动作，并完成流程监控分析。

• 资产化分析：通常会把元数据视为数据资产体系，因此围绕元数据去统计数据的使用情况，产生的价值，以及热点数据识别和分布，业务主体关联度等，并输出相应分析结果。

如果单从业务角度去看，元数据系统的存在，就是为了可以快速理解元数据，并且灵活的组织管理，以此降低服务能力的实现成本。

三、架构设计

1、系统分层

• 采集层：元数据系统中的基础节点，架构体系的底层，维护元数据获取通道和映射管理以及落地存储，并实现结构管理和数据处理过程；在数据源中可能存在多种情况：数仓环境、文件结构等，在特定情况中，还需要一定程度的手动维护进行结构拓补；

• 管理层：对于元数据核心能力打造，和相应的标准化管理，或者二次加工，数据源层面直接采集的数据通常不具备标准的业务语义，更多偏向技术侧的说明和逻辑，在经过标准化维护之后，在放开给应用层之前，还需要经过质量检测：例如工作城市，如果缺乏相应的枚举字典，显然是不合格的，必须经过必要的处理才能放开；即管理层放开的数据需要标准化和整体维度完善；

• 应用层：基于元数据能力的应用层开发，对于实际业务场景提供解决方案和功能入口，以及相应的系统中用户权限隔离等基本功能；

从系统分层的角度理解流程并不复杂，但是实际的实现过程简直不堪回首，技术栈使用非常复杂，多个版本逻辑重构再重构，并且不断的改进优化，最终才能实现相对稳定的服务能力。

2、元数据采集

在采集数据的时候，面对的最大问题就是多种类数据源解析适配，以及数据调度任务的抽象，必须开发对应的工具来实现各种场景的元数据解析能力：

• 解析能力：适配解析各种数据源特点，文件格式，SQL脚本，抽象任务等，完成标准元数据的转换沉淀；

• 类型识别：十分复杂的一个节点，类型在描述数据的时候至关重要，结构化存储可以直接读取，文件类结构通常需要类型转换标识，任务流程会直接统一管理，依次保证数据在不同环境中的合理存储；

• 更新消息：业务的发展中，各种数据结构是频繁变动的，这就需要与元数据系统进行同步，通常要向消息服务（总线）发送通知，然后触发元数据更新动作；

核心能力：结构与类型识别解析、获取初始化数据，并且通过消息通知线路，完成动态更新流程的触发。

3、元数据管理

核心能力的打造，通常在系统初期都是围绕基本能力和业务需求的方向，以求快速落地实现，提供业务支撑能力；

• 基础能力：标准化元数据结构，进行结构存储和可搜索能力实现，这个节点进行统一维护，数据类型识别和转换是至关重要的；补充说一句，在数据平台中，都会存在类型服务系统，以提供相应的识别能力和规范不同场景下的转换；

• 实体与关系：数据业务中两个核心概念，实体必然由属性构成这是常说的，实体之间维护的关系：关联、、绑定、输出、输入等，是构建血缘关系和数据链路的核心标识；

• 数据抽取：基于对元数据的组织和实体的定义，生成数据抽取规则，进而完成数据的快速获取，后续就是对接具体的业务，例如数据存储方式，搬运方式，最终落地业务线使用；

• 可视化分析：包括数据质量分析，链路与周期分析，血缘分析等，这类功能一般在核心业务能力完成之后，会按需求等级，逐步迭代实现；

通过核心能力的建设，以求实现对数据的快速定位，高效管理，灵活应用的目标，提高数据服务能力的效率，适应业务发展的多变性。

同系列：消息中间件改造 ┃ 数据服务系统设计 ┃ 业务数据清洗方案 ┃ 数字营销概念 ┃ 标签业务应用 ┃

四、源代码地址

GitEE·地址
https://gitee.com/cicadasmile
Wiki·地址
https://gitee.com/cicadasmile/butte-java-note/wikis

来源：https://www.cnblogs.com/cicada-smile/p/15422869.html