### 基于服务的多源异构数据整合平台解决方案

基于服务的多源异构数据整合平台解决方案

起源

由于早前没有规划, 也不可能规划, 导致供应商数据分布在不同的系统, 各个业务系统都各自管理, 维护这些数据, 很难统一

目标

需要建立统一的数据管理和访问平台，便于统一维护和管理，提供一站式的数据访问服务。

业务场景

业务系统和数据具有以下特点：(大概)

数据非同构：字段类型,长度,意思等不一致；
数据离散性：数据分布在不同的系统或平台；
数据量不大：(目前以商城数据来看)
数据质量不齐：数据一致性的问题，主数据不统一的问题；

采用基于服务的数据整合平台可以在源系统较小改动的情况，有效整合数据，逐步实现各数据源的逻辑整合。

源数据可以是结构化数据，也可以是非结构化数据。

目前大概都是用Mysql, 针对结构化数据的处理过程大概为：

  1. 数据处理
方法1. 作为数据源的结构化数据库需要开放数据库接口(一般为数据库连接啦)，供元数据管理系统(就是新拉出来的系统)从源数据库中抽取数据结构信息，并保存在元系统中。
方法2. 人工做法...
  1. 服务生成
平台级 服务模块可以提供查询存放于元数据系统中的供应商服务元数据，通过简单的操作(例如勾选、组合字段)自动生成提取数据的代码块，并将该部分代码块包装成服务，存放于业务级服务运行模块，并业务级服务注册到平台服务总线( 服务注册可以是手工注册，也可以通过API支持自动注册就更好），对外部进行数据服务。

正向还是反向还是双向 再拟定吧

平台级服务 - 供应商(元数据)

原理很简单

新建一个项目 , 作为

平台级供应商服务

前置 平台级服务总线
提供服务注册、服务发布、服务编排、服务监控等功能；

模块A 为各业务供应商提供唯一标识 [其一就好]
  1. 提供的服务为 高效GUID产生算法(sequence), 可以是基于Snowflake实现64位自增ID算法。
https://gitee.com/yu120/sequence.git
  1. 高效UUID生成
  2. 类似oracle的seq生成服务
模块B 元数据管理

从各 数据源(业务) 抽取元数据，开放接口或底层数据模型，提供给服务生成模块使用。另外元数据管理系统需要将服务作为一类元数据(供应商)管理起来，以便运维人员查看基于服务的数据流向；

业务级对平台级pull

request pull_supplier ( bussiness_code /* 业务代码 */ , curr_supplier_id, [统一合同号, 工商营业执照编号...]):
response {
    new_supplier_seq : string 64 这个可以是UUID
    ...
    相近 : [
        {
            seq char 64
            bussiness_type char 64
            supplier_id
            supplier_name
            ...
            {
                合同相关 [逐步实现, 按需求实现排序实现]
            }

            {
                资质相关
            }

            {
                许可业务
            }
        }
    ]
}

平台级对业务级push

模块C 服务生成模块

模块C 提供服务生成管理界面，展示元数据系统获取的数据源表结构和字段信息，管理员可通过选择相同或不同数据源的字段信息，生成数据提取代码块，并注册到平台级服务总线，从而提供数据访问服务。支持数据库内连接(为数据库表间)和内存连接(程序级整合)两种代码生成模式，提供日常的服务生成、修改、删除、查询等维护功能，支持服务信息由该模块到元数据管理系统的回传，便于元数据系统对服务的管理并提供数据流向信息；

生成代码推到业务服务中,作为执行

业务级供应商服务

模块A 服务运行模块

数据提取服务的执行模块，通过数据库接口连接到各数据源。服务生成模块生成的代码在该模块中打包后发布到业务级服务服务器，形成执行模块。业务级系统的数据访问请求发送到平台级服务总线后，平台级服务总线路由到该业务级服务执行模块进行数据提取；

table 统一supplier 在数据处理 步骤拟定

大概表结构

{
    seq char 64
    bussiness_type char 64
    supplier_id
    supplier_name

    ...

    {
        合同相关
    }

    {
        资质相关
    }

    {
        许可业务系统
    }

}

平台级供应商服务 - 模块B 的迭代

第一次迭代可能只有seq+supplier_name+supplier_id+bussiness_type
这些数据只是为了以后合并的一个预注册

这个时期

pull_supplier  ( bussiness_code /* 业务代码 */ , supplier_id , supplier_name): {
    seq,
    bussiness_code,
    supplier_id , 
    supplier_name
}

可以理解为saveOrUpdate

第二次 资质相关 字段

pull_supplier  ( bussiness_code /* 业务代码 */ , supplier_id , supplier_name , [工商营业执照编号 , ...]): {
    seq,
    bussiness_code,
    supplier_id , 
    supplier_name
    { 资质相关 }
    相似:[
        {
            seq,
            bussiness_code,
            supplier_id , 
            supplier_name
            { 资质相关 }
        }
    ]
}

第三次 合同相关 字段

...
如此类推 , 让供应商以达到最终想要的形态

第N次

派生出 #### 平台级供应商服务 - 模块C 服务生成模块 迭代

因为在 平台级供应商服务 处理数据 , 所以 元数据 与 源数据 之间的映射 是清楚的,

此模块 服务生成模块 生成的代码 可以是可以运行的代码, 也可以是数据转换的代码, 也可以只是个映射关系

平台级服务 ---> pull push 业务级服务[1,2,...N]
业务级服务[1,2,...N] ---> pull push 平台级服务

// TODO 画图

未标明原创文章均为采集，版权归作者所有，转载无需和我联系，请注明原出处，南摩阿彌陀佛，知识，不只知道，要得到

请先后发表评论
  • 最新评论
  • 总共0条评论