aPAAS schema 设计

接口：

N

是否索引字段：Y N

电话：

复选框

字段：收件人

库表映射

是否退货

是否为空：Y N

是否有账号

表名------------------------描述

收货

开始

注册

...

地址

时间

节点1接口

状态

主键ID

文本框

字段名称

释义

说明

......

单选框

菜单

值类型

路由库

路由表

文本域

数字

descr

名称：

Y

文件

电话

退货

是否唯一：Y N

加入购物车/直接购买

基础字段

接口声明列表

视图设计

默认值：null

发货

css code + js脚本

收件人

code：recever

规则

登录

样式面板

1、应用场景在多变的数据服务场景中，应用中常见如下的业务需求，通过对多种数据结构的灵活组合，快速实现业务模型构建，整体示意图如上：像常用的画图工具，左边提供基础图形库，中间是画布，右边是组件的控制细节，对比到这里的逻辑如下：● 字段面板：提供业务数据结构的字段映射，和常规字段类型配置，用来支撑组合面板的表单配置。  ○ 数据结构：对现有业务结构做映射，可能是文件、数据表、JSON等，生成相对标准的字段选项；  ○ 拓补字段：维护一批基础的字段类型，用来做拓补操作，完善整个业务结构；● 组合面板：承载字段的组合管理，生成新的数据结构，根据业务场景，完成底层数据的抽取存储或者API服务生成。  ○ 业务主体：通过业务需求的判断，明确面板支撑的业务属性，通过基础结构组合新的业务主体；  ○ 组合结构：面板上呈现的字段，是多个业务结构的抽取，即不同业务结构中的部分字段组合；● 规则面板：对组合面板上字段进行规制设定，常见涉及：描述，类型，默认值等，对面板字段进行相对统一的标准化管理。  ○ 描述信息：对于组合面板上的字段描述，也可以是原有映射的结果，作为新业务主体的属性说明；  ○ 类型维护：复杂的环节，不同数据类型在不同的存储中处理方式不同，需要统一维护类型存储映射；  ○ 业务规则：对于新的业务主体，设置属性的规则，可以是：唯一性，默认值，等等；2、构建服务基于上述功能的实现，可以快速实现以下服务能力，通常应用在业务多变的场景中：● 数据主体构建：通过组合面板的结构生成，快速完成相关数据的抽取和存储，作为新的业务场景中的主体数据。● 服务API生成：在数据服务中，直接通过配置，生成API服务能力，并控制参数的响应结构，这种情况通常会以实时查询的方式处理。● 数据智能分析：在数据分析场景中，侧重统计的结果，基于字段和图表结构，生成相应的统计分析任务，灵活管理分析报表。这里是简述相对单一的应用服务，如果把这里的流程分段放大，在整个数据服务体系下，就是围绕元数据管理的复杂的基础系统：围绕数据结构映射，进行元数据标准化管理，在此基础上二次组织数据，快速响应业务需求。在这样的流程下，可以快速建立业务链路，提供高效的服务能力，降低试错的成本。二、元数据概念1、基础描述从定义上说，元数据(Metadata)即描述数据的数据，但是在实际使用的时候，还是存在很多细分的概念，看下面的案例：用户性别；从细分角度看，可以对上面数据进行两块划分，即业务层与技术层：● 业务层：名称.释义.说明.值类型;● 技术层：路由库.路由表.存储类型.值类型;这里的分层只是描述的侧重点，业务层偏向应用端，技术层偏向底层系统的交互和实现，在对性别的描述上都是核心维度。所以从本质上看元数据，介于系统和业务中间，提供双方都能明白的语义和逻辑，可以更加高效的支撑数据的业务价值。2、血缘关系上面是从单个指标看元数据的结构，如果从整个链路上看，就会形成层级线路，通常称为血缘关系：从上层业务侧追溯到底层结构，形成血缘关系的概念，概念本身并不重要的，背后的核心是链路的管理，链路上的节点（中间实体）是通过多种计算手段生成；如果某个节点数据一旦出现质量问题，则需要根据这里的链路关系进行逐级向底层排查，完成问题修复后，还需要根据关系向上逐级修复清洗；如此通过血缘关系进行数据质量的分析和把控。3、业务价值元数据管理是一个持续又漫长的过程的，任何系统的搭建都需要业务来衡量其存在的价值，其核心逻辑在于：统一标准化管理元数据信息，规范业务层的定义，并通过技术层面快速定位数据，自动化抽取数据，灵活支撑业务应用。● 围绕核心业务：通常在项目初期的时候，只围绕一些核心业务主体，使其在使用的时候灵活高效，后续在持续扩展其他能力。● 数据成本分析：基于元数据中链路，分析各个节点数据的生产维护管理等成本，为数据服务中商业定价提供参考，可能直接影响服务是否可提供的决策。● 配置可视化：在数据服务平台中，最忌讳的一点就是靠手动去维护各种作业，不管在什么场景下，都要考虑可配置化管理，保证动作可追溯。● 流程自动化：不管是元数据结构映射，还是配置后数据的抽取，要保证指令生成后可以自动完成该一系列动作，并完成流程监控分析。● 资产化分析：通常会把元数据视为数据资产体系，因此围绕元数据去统计数据的使用情况，产生的价值，以及热点数据识别和分布，业务主体关联度等，并输出相应分析结果。如果单从业务角度去看，元数据系统的存在，就是为了可以快速理解元数据，并且灵活的组织管理，以此降低服务能力的实现成本。三、架构设计1、系统分层● 采集层：元数据系统中的基础节点，架构体系的底层，维护元数据获取通道和映射管理以及落地存储，并实现结构管理和数据处理过程；在数据源中可能存在多种情况：数仓环境、文件结构等，在特定情况中，还需要一定程度的手动维护进行结构拓补；● 管理层：对于元数据核心能力打造，和相应的标准化管理，或者二次加工，数据源层面直接采集的数据通常不具备标准的业务语义，更多偏向技术侧的说明和逻辑，在经过标准化维护之后，在放开给应用层之前，还需要经过质量检测：例如工作城市，如果缺乏相应的枚举字典，显然是不合格的，必须经过必要的处理才能放开；即管理层放开的数据需要标准化和整体维度完善；● 应用层：基于元数据能力的应用层开发，对于实际业务场景提供解决方案和功能入口，以及相应的系统中用户权限隔离等基本功能；从系统分层的角度理解流程并不复杂，但是实际的实现过程简直不堪回首，技术栈使用非常复杂，多个版本逻辑重构再重构，并且不断的改进优化，最终才能实现相对稳定的服务能力。2、元数据采集在采集数据的时候，面对的最大问题就是多种类数据源解析适配，以及数据调度任务的抽象，必须开发对应的工具来实现各种场景的元数据解析能力：● 解析能力：适配解析各种数据源特点，文件格式，SQL脚本，抽象任务等，完成标准元数据的转换沉淀；● 类型识别：十分复杂的一个节点，类型在描述数据的时候至关重要，结构化存储可以直接读取，文件类结构通常需要类型转换标识，任务流程会直接统一管理，依次保证数据在不同环境中的合理存储；● 更新消息：业务的发展中，各种数据结构是频繁变动的，这就需要与元数据系统进行同步，通常要向消息服务（总线）发送通知，然后触发元数据更新动作；核心能力：结构与类型识别解析、获取初始化数据，并且通过消息通知线路，完成动态更新流程的触发。3、元数据管理核心能力的打造，通常在系统初期都是围绕基本能力和业务需求的方向，以求快速落地实现，提供业务支撑能力；● 基础能力：标准化元数据结构，进行结构存储和可搜索能力实现，这个节点进行统一维护，数据类型识别和转换是至关重要的；补充说一句，在数据平台中，都会存在类型服务系统，以提供相应的识别能力和规范不同场景下的转换；● 实体与关系：数据业务中两个核心概念，实体必然由属性构成这是常说的，实体之间维护的关系：关联、、绑定、输出、输入等，是构建血缘关系和数据链路的核心标识；● 数据抽取：基于对元数据的组织和实体的定义，生成数据抽取规则，进而完成数据的快速获取，后续就是对接具体的业务，例如数据存储方式，搬运方式，最终落地业务线使用；● 可视化分析：包括数据质量分析，链路与周期分析，血缘分析等，这类功能一般在核心业务能力完成之后，会按需求等级，逐步迭代实现；通过核心能力的建设，以求实现对数据的快速定位，高效管理，灵活应用的目标，提高数据服务能力的效率，适应业务发展的多变性。

长度：

是否成功

字段面板

时间戳：

收件人：

点击每个节点展示对应的表单试图设计如当前点击了收货节点

表单input_type：text|select|...

地址：

流程设计

状态：

订单号：

付款