关于XX业务系统数据同步方案简介

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

关于XX业务系统数据同步方案简介

修订记录

目录

1.概述 (4)

2.数据分析现状 (5)

3.数据同步方案 (6)

3.1.理论分析 (7)

3.1.1.理论值分析 (7)

3.1.2.必要条件 (9)

3.1.3.差集计算 (9)

3.2.数据处理方案 (11)

3.2.1.历史数据处理 (11)

3.2.2.过渡性数据处理 (12)

3.2.3.常规数据处理 (12)

3.3.数据时效性 (12)

4.未知性说明 (14)

1.概述

XX业务系统技术支持人员大部分时间均在进行数据统计分析,且基本是在正式环境中进行数据分析处理,而此举在实际操作中除会给生产系统带来诸多压力之外,还可能因为操作人员新建大量临时表时操作失误而出现删表或者删数据的情况。

针对上述情况并结合可视化分析系统的现有使用情况,做本建设性思考方案,旨在针对实际问题提出理论上的建设性方案。

2. 数据分析现状

XX 业务系统数据分析一直因为数据时效性而无法很好的使用Spark 集群,且目前已建设的可视化分析环境因为历史数据存在被修改的可能性而导致用之甚少。且当前XX 业务系统集群可视化分析环境采用按月(月中)更新、人工拷贝而后转由集群导入的方式,如下图1所示。

备份库

集群库

正式库人工拷贝系统同步

图1 – XX 业务系统数据同步示意图

该方式在实际操作中非常消耗人力、物力,且集群数据利用率极低(XX 业务系统版集群可视化环境几乎没人使用)。

3.数据同步方案

近期,在处理HBase数据同步至HDFS方案时,构思如下数据更新方案,如图2所示:

近期数据

差集

全量数据

Override

Append

图2 – HBase数据迁移理论方案示意图

同理,将HBase替换成XX业务系统生产数据库,则会得到下图3所示方案示意图:

近期数据

差集

全量数据

Override

Append

Oracle

图3– XX业务系统数据迁移理论方案示意图

该方案是采用蚂蚁搬家的思路,若在此方案思路使用至XX业务系统数据同步中将会使数据从一个月的更新周期调整为一天,从而使集群数据更接近实时数据,从而为XX业务系统日常统计使用Spark集群提供了可能性。

3.1.理论分析

前期在XX业务系统数据同步过程中,一直困扰的问题是XX业务系统数据存在被修改的可能性,且修改的数据可能是近期也可能是N年前的历史数据。鉴于此实际情况,前期思路一直停留在如何才能以更快速的方式加载生产数据库中的全量数据。且之前提出的伪增量方案由于局限性也不能很好的解决XX业务系统数据面临的实际问题。

现在我们换个思路,如果不能一次性获取那么大批量的数据信息,为何不能采用大量数据按时间段切分成很多小块数据的思路来处理?

借用Spark Streaming将数据按时间切片的思路,将XX业务系统数据进行切片,将数据切分成一个个较小的数据块。如下图4所示,可以通过切片将月度数据集切分成多个日度数据集。

图4 – XX业务系统数据切片示意图

3.1.1.理论值分析

假设XX业务系统数据月度更新(包含新增、修改)量平均值为S,且每月天数按照30日计算,则在对数据切片之后,每天需要处理的数据量将为S1 = S

。若S数量级的数据同步(Oracle至HDFS,不考虑人工数据迁移)耗30

时为T ,则S 1数量级的数据同步耗时则为T 1 = (T 30, T

3

)(注:此区间范围是通

过既往集群数据处理总结所得)。

目前海南医保智能审核数据均来自XX 业务系统系统,所以使用海南智能审核数据处理耗时来对XX 业务系统数据处理耗时进行理论分析存在一定的参考价值。

图5 – 智能审核月度数据处理耗时

如上图5所示,为智能审核系统2018年12月度住院医嘱明细1721W 数据从数据库通过JDBC 方式抽取到HDFS 的耗时日志信息。

在此我们假定S =1721W ,T =1891秒,则理论上将上述数据按日切分后,每日需要处理的数据量S 1=57.36W ,处理耗时T 1将在(63秒,630秒)的区间范围内

注:此处处理耗时区间跨度较大是因为Spark 采用JDBC 方式从数据源抽取数据的耗时,受被抽取数据表的数据量、网络传输速度以及数据源物理磁盘空间等因素所影响,在不同参数环境下,同等数据量的处理耗时不尽相同。

对于住院医嘱明细这类数据量大的数据表,其日度数据处理耗时在63~630秒的区间内,且智能审核采取省级数据单表存储而非按地区分表存储模式,所以其理论数据处理耗时会大于分表存储模式。

3.1.2.必要条件

在该数据同步方案中(图3所示),必须确保数据源能够满足提取近期数据这一必要条件。而这里的近期数据则是近期新增或者修改的数据合集。

如何确定哪些数据是最近新增或者修改的呢?据前期了解,XX业务系统数据中大部分业务数据表存在该条数据记录的更新时间字段。且大部分数据的删除为逻辑删除,而非物理删除。如此一来,在确保没有人工手动修改数据的前提下,就可以通过各表中的更新时间字段来获取到最近更新的数据信息。

注意,这里所取的近期数据均取自数据库相关业务表,若业务表数据量较大则通过更新时间字段进行数据筛选提取时,可能会对数据表的性能指标造成一定的影响。

3.1.3.差集计算

如前所述,在该数据同步方案中,需要对Oracle提取的最新数据集DS new 和HDFS中的全量数据集DS all进行差集运算,这里的差集如何定义?

相关文档
最新文档