cicada-smile

一、业务背景

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

阅读标签

Java基础】【设计模式】【结构与算法】【Linux系统】【数据库

分布式架构】【微服务】【大数据组件】【SpringBoot进阶】【Spring&Boot基础

数据分析】【技术导图】【 职场

分类:

技术点:

相关文章: