实习期间的一点总结,做的是MongoDB数据源的同步,遇到了不少坑,遇到不少问题
内容:将指定数据源(如MySQL等数据库)内容增量/全量同步到Dataworks上
1、DDL,建表
需要在开发环境的生产环境建立存放数据的表,分为全量表(无尾缀)和增量表(_delta)
做好字段和表名的备注工作,设计分区字段和生命周期(增量表的生命周期短期,全量表视具体情况)
相关DDL写在一个文件价中,由于只需要执行一次并不需要提交
2、构建增量同步脚本
需要设置过滤条件,以拿到前一天的增量数据,视具体情况设计,比如将表中的创建时间、更新时间或是结束时间等与传参($bizdate等)比较以限定时间
需要注意数据来源和数据去向的设计,传参的设计,依赖关系(一般设置为空间根节点),并发数等
考虑到服务器核数可以设置相关同步串行执行。之后提交、发布到线上
3、构建全量同步脚本
全量的没有过滤条件,且只用跑一次,依赖空间根节点,发布到线上后设置补数据为某天即可将全量的数据导入然后冻结或是下线,之后可通过HQL根据表中具体字段insert overwrite .. partition (date)重新分区等
全量数据一般还是导入到增量表中,后续手动导一遍全量
4、构建HQL,将增量数据合并到全量表中以及数据源的二次处理
合并数据就是join然后insert overwrite,视业务情况LEFT JOIN和FULL JOIN都是常用的
举例:有的数据需要对比历史数据进行增量更新,那么FULL JOIN是常用的
有的log日志在过滤后直接插入到当天分区
二次处理:在处理一些如mongoDB等数据源时往往需要explode,这是在同步到增量表后通过HQL合并到我们的主表当中,也包括对业务情况进行一些过滤处理。
5、查验数据,查看任务依赖关系
查验数据,查的是生产环境的数据
SET odps.sql.allow.fullscan = true;
SELECT `date`,COUNT(1)
FROM tableName
GROUP BY `date`;
修改表的生命周期:
ALTER TABLE tableName SET TBLPROPERTIES ('lifecycle' = '36500')
查询表DDL:
show create table tableName;
依赖关系在运维中心中对相关节点进行下游分析,展开看看就行了
6、补数据
全量数据手动跑一遍,按照首日全量导入的业务时间,插入到主表中。
如果全量脚本是几天前跑的,那么需要对相关的合并HQL进行补数据,将缺的几天数据补上。
标签:总结,同步,数据源,Dataworks,HQL,全量,增量,数据 From: https://www.cnblogs.com/SenX/p/17824650.html