关于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进行差集运算，这里的差集如何定义？
图6 – 数据集示例
如上图6所示，上面部分为全集数据DS all下面部分为最新数据DS new，我们可以很清晰的知道code为001、002的两个数据对应的name信息被修改。

那么此时如果要将更新后的数据替换掉DS all中的原有的数据，则需先将DS all中code为001和002的记录去掉得到DS mid，并将DS mid写入HDFS 而后再将DS new追加写入，这样就可以得到最新的全集数据了。

在这个过程中DS mid则被称之为差集。

将DS mid与DS new共同写入HDFS，则被称之为数据合并。

注：为更好的确保差集计算的准确性，此处必须确保被计算的数据集存在主键字段，否则差集计算可能存在问题。

附：Spark差集计算函数
3.2.数据处理方案
由于XX业务系统生产数据库存放在电信机房，而Spark集群部署在公司内网，两者在网络环境上存在一定隔阂且XX业务系统生产数据库太大不可能通过网络传输方式将数据一次性传输至集群服务器，所以本方案将数据处理分为三个步骤，即历史数据处理、过渡性数据处理及常规数据处理。

3.2.1.历史数据处理
即XX业务系统过往历史数据，此类数据特征为体量大、集群服务器上不存在该部分数据(此处假设集群服务器不存放任何XX业务系统相关数据)。

在对历史数据做处理时，需要将该部分数据通过现有人工拷贝处理方式备份至公司内网Oracle服务器，而后再由Spark通过JDBC方式进行全量数据抽取处理。

3.2.2.过渡性数据处理
由于XX业务系统生产数据体量大，所以在历史数据处理时，将会出现耗时相对较久的情况。

而此段时间内，XX业务系统生产库将会源源不断的产生新的数据信息，此时在历史数据同步至HDFS，需对此段过渡期的数据进行批量处理，即使用该同步方案思路将近N天的数据同步至HDFS，以此来确保HDFS与XX业务系统生产数据库的数据一致性问题。

3.2.3.常规数据处理
在过渡性数据处理完成后，后续处理即为常规处理，即按日从XX业务系统正式库抽取最新数据，而后同步至HDFS，从而得到最新的数据信息。

3.3.数据时效性
如前所述该方案采用按日同步的方式，理论而言HDFS上的数据与XX 业务系统正式数据库时差为1天。

然而此处的1天在不同语境及处理方式下不尽相同。

由于Spark集群对数据分析采用的是基于数据模型的分析方式，即用户在进行数据分析前需对原始数据进行加工处理。

如此一来，数据处理的耗时将为数据导入和模型生成的耗时总和。

根据最近一次（2019年1月3日）XX业务系统数据模型生成情况来看，当前数据量下XX业务系统所有模型生成耗时为2.4小时，而且后续会随着业务量的增加而耗时更久，所以此处假设模型生成耗时为3小时。

为确保工作人员能够在上午8点开始正常使用Spark集群进行数据相关统计分析，则在除去模型生成的3小时耗时外，若从0点计时则会有5小时的时长用以进行数据的同步处理。

然而，据前期对接XX业务系统所了解的情况，在0点之后XX业务系统系统将有大量批量任务需要执行，数据库压力很大，若在此时段进行数据抽取处理，则会对XX业务系统正式数据库的正常运行造成不必要的影响。

综上所述，该方案建议XX业务系统近期数据的抽取工作安排在下午至午夜某时段，尽可能的在对正式库不造成太大影响情况下完成有关处理。

如此一来，相关人员在使用Spark集群对XX业务系统进行数据分析时其时差并非理论上的一天。

4.未知性说明
该方案中数据差集计算及合并写入部分未就千万级别数据进行有效测试，其耗时存在未知性。

此外，该方案为基于历史经验的理论性假设方案，就实际操作而言需进行相关数据测试、验证之后方知是否可行。