银行数据迁移项目,比起一般遇到的项目,其实难度还是挺大的。
从0到1的项目好做,普通迭代开发的也不难,但是,对于(系统升级)数据迁移的项目,有点要老命。
0,数迁项目背景
一般由于业务部门新的业务需求的增加或者合并,为满足新需求,将某个系统(比如说最常见的信用卡系统)进行改造升级,其数据要进行迁移,很多旧口径逻辑变更,重新映射,再次进行数据建模,实现各种业务指标开发。
举个例子:
比如A银行本身做贷款项目,数据都使用银行贷款系统,一直稳定运行使用很多年,但是几年后,银行和各机构线上营销的趋势猛增,A银行也不例外,A银行和美团,消费金融等app进行合作,发现原本的系统结构不符合现在的合作业务需求,存在功能异构,逻辑重大变更,需要对之前的系统重新建模,数据重新迁移到新系统。
一般数迁项目难以开发,是弊端很多:
0,建模分析工作做得不够完全,细致到位。
1,新需求文档写的很烂,字段数据类型对应不上。跑脚本很吃力,报错多。
2,新需求文档存在逻辑变更,功能异构,其字段的逻辑,映射规则,字段的增减,改动很频繁,还要你及时更新脚本通,并且跑通脚本。
3,一些映射口径有遗漏,在映射表里找不到替代方案;有些映射规则都还没有确定下来,就叫你瞎开发。
4,一些映射口径可以从旧到新映射,但却不能还原回来,到时候数据自测肯定对不上数据。
5,当你开发测试发现有问题的时候,他们告诉你报错的那张表突然说下线。
6,测试环境切换频繁;测试环境没有数据;没有业务培训直接上手。
当然,你已经很努力的在那边开发了 ,然而行员领导可能觉得大家还很傻冒,对你一通乱骂。有时候他们也不知道疑难杂症究竟有多少!!!
1,需求案例(字段新增)
原表字段:
日期(yyyy-mm-dd) | 产品类型 | 产品代码 | 折算系数 |
upl_date | prd_type | prd_code | cnvr_coef |
现需求指标字段:
日期(yyyy-mm-dd) | 产品类型 | 产品代码 | 产品名称 | 折算系数 |
upl_date | prd_type | prd_code | prd_name | cnvr_coef |
现在需要新增一个字段,在产品代码字段后面。
这个时候,你该如何应对呢???
2,初始化脚本开发
2.1,什么是初始化脚本。
就是在这个需求上线的时候,要提前在正常日常跑批脚本之前,先执行。以满足后续的跑批要求。
其特点:
1,一次性的,上线之后就只跑一次。
2,执行前置,时间上要先跑。之后再跑日常跑批脚本。
目的性:
为了把历史的数据按照最新的需求,给迁移到新系统上。
2.2,脚本开发
特别是对于这种表结构有新增的需求,其实是最难的。比字段的删减,字段名变更,某字段逻辑变更都要难。
1,先rename原目标表
alter table key_prd rename to key_prd_2024068 ;
2,key_prd_new
2,再创建新目标表结构
drop table if exists key_prd_new ;
create table key_prd_new (
upl_date date comment '日期',
prd_type string comment '产品类型',
prd_code string comment '产品代码',
prd_name string comment '产品名称',
cnvr_coef secimal(26,10) comment '折算系数'
)
comment '重要产品表'
partition by (dt string comment '时间分区'
sys_src string comment '系统名' )
;
注意:数据迁移的项目,表的分区一般都是双分区,一级分区是dt 时间分区,二级分区是sys_src 系统分区。
3,数据回插(原系统数据回插到新系统的表里)
--对新表进行【动态插入】的方式就行数据回插
insert overwrite key_prd_new patition (dt, sys_sc)
select upl_date
,prd_type
,prd_code
,'' as prd_name --产品代码【新增字段】
,cnvr_coef
,dt
,sys_src
from key_prd_2024068 --旧系统表的备份数据
;
注意:如果新增字段的数据类型为 string ,数据回插的时候,默认 ''
如果新增字段的数据类型为 decimal ,数据回插的时候,默认 0
4,分批次回插
如果说之前的旧系统的数据量太大了,字段50+,数据量有接近100亿,那么如果按照上面步骤3的方法,还可以做到嘛???
当然不行了,生产上的资源本来就很紧张,每天都有很多的脚本在跑批。
内存不会太多,所以针对如此巨量的数据,肯定不够加载到内存里,如果硬是要这么操作,那肯定会导致其他的作业无法正常跑批,导致整个调度系统瘫痪。
所以有什么解决的办法呢??
答案就是把该表的数据量做一个统计,如果说有近百亿的数据,那么一般按照银行的要求,每次加载的数据量,不超过1亿,意味着把表的数据差不多要分成100份,分批次导入。
那么如何比较均等的,分为100份数据呢??
我们可以对该表进行分区的数据统计。
select dt
,count(*)
from key_prd
group by dt ;
看看每个日期分区的数据是多少,是不是均匀或者说稳步缓增的。
一般来说,数据量都是差不多,比较均匀,也有数据量稳步缓慢增加的。
看看要多少个分区的数据量加起来差不多到1亿。
--对新表进行【动态插入】的方式就行数据回插
insert into key_prd_new patition (dt, sys_sc) --注意,变为 insert into
select upl_date
,prd_type
,prd_code
,'' as prd_name --产品代码【新增字段】
,cnvr_coef
,dt
,sys_src
from key_prd_2024068 --旧系统表的备份数据
where dt >20240101 and dt < 20240205 --时间分区内的数据量和<=1亿
;
按照上面的方式,依次进行分批次数据插入。就完美解决了,perfect!
今天这期属于数迁项目实战,希望你可以学到更多,不光是业务背景,sql技能,更重要的是认知,是对项目开发的框架的理解。
就好比如写语文作文一样,别人年纪比普通人小很多,但是写出来的作文深度比之高深很多。我想这不是努力不努力的问题,同样需要悟性,认知在里头。希望可以给大家增加一些知识面,仔细琢磨,提升自己的悟性。
欢迎一键三连!!!
标签:实战,初始化,数据量,prd,--,init,key,dt,数据 From: https://blog.csdn.net/wowulita123/article/details/139538989