[发明专利]分布式数据自动结构化入库方法及系统在审
申请号: | 201910971142.5 | 申请日: | 2019-10-14 |
公开(公告)号: | CN110737710A | 公开(公告)日: | 2020-01-31 |
发明(设计)人: | 施红;陆晓 | 申请(专利权)人: | 神州数码融信软件有限公司 |
主分类号: | G06F16/25 | 分类号: | G06F16/25;G06F16/23;G06F16/27;G06F16/28;G06F9/54 |
代理公司: | 11303 北京方韬法业专利代理事务所(普通合伙) | 代理人: | 党小林 |
地址: | 100000 北京市海淀区西北旺*** | 国省代码: | 北京;11 |
权利要求书: | 查看更多 | 说明书: | 查看更多 |
摘要: | |||
搜索关键词: | 集群 入库 分布式数据 自动结构 写入 格式化 第三方系统 对象执行 消息队列 原始消息 写数据 源系统 解耦 独立性 存储 保证 | ||
本发明提供了一种分布式数据自动结构化入库方法及系统。该方法包括:将需要入库的原始消息同步或者异步的写入kafka集群;利用kafka集群的消息队列对写入消息进行存储;根据所述kafka集群的消息,对所述kafka集群中的格式化对象执行入库操作。本发明提供的分布式数据自动结构化入库方法及系统完成了本系统与第三方系统的解耦,保证源系统的独立性和写数据的稳定性。
技术领域
本发明涉及数据处理技术领域,特别是涉及一种分布式数据自动结构化入库方法及系统。
背景技术
随着大数据技术的逐渐成熟与完善,越来越多的大数据技术被应用于银行系统,各个银行都在逐步构建数据集市、大数据平台等系统,但这些系统的数据来源、数据清洗、数据结构化、数据落地成为难点与痛点。
目前行业内处理数据报文清洗、结构化、落地的方式比较典型的就是集中式逐个开发模式。由于数据格式与数据内容各种各样,落地数据库各式各样,以现有的典型技术,每一种数据格式或者每种数据内容和数据库类型,都要开发对应的数据清洗、接口化以及入库引擎。增加开发成本和开发难度,且当性能无法满足要求时,只能通过增加服务器资源解决,无法实现横向扩展。
比如:当前系统已拥有解析A系统提供xml格式数据并落地到oralce数据库的能力,但当需要把B系统提供的分隔符格式的数据落地到db2数据库时,需要开发一下内容:
1、开发解析分隔符格式数据的代码;
2、由于数据节点复杂,需要开发结构化此数据的代码;
3、开发此数据格式、内容的入库模板;
4、开发模板数据写入DB2的引擎;
5、如果因为处理内容增加导致服务器资源不够,好需要增加服务器资源。
现有的数据入库方式具有以下明显的缺陷:
在开发成本方面,由于每种数据格式,每种数据内容以及每种数据库类型都需要个性化开发,增加了开发成本。
在开发难度方面,由于解析每种格式数据的技术不同,数据库操作驱动不同,在日常开发、升级的过程中,增加了开发难度,对开发本系统的人员要求较高。
在运维难度方面,由于每种报文内容都要用代码进行逐个节点、字段解析,当源数据增加或修改数据节点的时候都需要修改对应的代码,增加维护的难度与风险。
在性能瓶颈方面,由于是集中式部署,当服务器资源达不到要求时,从硬件层面只能通过增加机器资源解决,但一台服务器所能增加的资源是有限的,加到一定程度后,就无法再通过增加资源解决性能问题。
在数据完整性方面,当数据库宕机或系统出问题导致数据无法落地时,则此阶段的数据则会丢失。
在事务一致性方面,落地的源数据为多节点的时候,可能需要提交到多个表中(特别对于关系型数据库),在提交到多个表的过程中,由于不是同一个事务,当部分表提交失败时,无法进行事务回退的操作,造成数据错乱。
在独立性方面,数据落地时,由于是同步提交,操作数据库会消耗大量时间,在这个过程中会对上游系统进行干扰。如果入库应用异常或者数据库宕机更会对上游系统造成灾难性后果。
在单一性方面,所有源数据只能一次消费,即源数据一般只能存到一个地方,不能同时落地到多个存储空间。
发明内容
本发明要解决的技术问题是提供一种分布式数据自动结构化入库方法及系统,完成了本系统与第三方系统的解耦,保证源系统的独立性和写数据的稳定性。
该专利技术资料仅供研究查看技术是否侵权等信息,商用须获得专利权人授权。该专利全部权利属于神州数码融信软件有限公司,未经神州数码融信软件有限公司许可,擅自商用是侵权行为。如果您想购买此专利、获得商业授权和技术合作,请联系【客服】
本文链接:http://www.vipzhuanli.com/pat/books/201910971142.5/2.html,转载请声明来源钻瓜专利网。