标签：解决方案 数据库 上云 czid 全量 增量 OGG 数据
上篇说到全量数据上云，这里继续讲增量
为什么要用到增量？因为小数据库还好，数据量大的，每一次都要全量既对存储压力巨大，也对上云效率产生弊端，每次都要上全量代价太大了，所以这时候为什么不考虑全量+增量=全量的模式呢，即如果某库数据是一天一调度，那就是昨天的全量+今天的增量=今天的全量，如此一来只需要第一次上一份全量，后续每次的调度只抽取增量即可
难点：
- 如何获取到云下数据库的增量数据
- 如何保证全量+增量的合并数据能和源数据保持一致性
- 如何保存增量数据，如何上云这些增量数据
- 如何调度全量合并，如何设置合理分区
如何获取增量，即增量采集，我之前写过一篇增量采集的博客，传送门
- 对于大型数据库，数据变更频率快，表数量多，对数据传输要求有备份，安全，零差数据的采用基于数据库日志的方法
- 对于小型数据库，且未开归档，但数据变更频率快的采用基于全量对比的方法
- 对于含有标准时间戳字段，且应用环境适合，表数量较少的采用基于时间字段的方法
- 至于触发器，由于需要源端运维成本较大，且对源端存储有压力(既然都是对存储有压力为何不用OGG)，故很少有客户选择这一种
一般来讲应用场景最多的就是第一种和第三种，这里我们采用基于数据库日志的方法，也就是OGG+DataX(数据采集工具), OGG是基于oracle日志，负责采集变化数据的一个数据库插件，大部分公司用它都是用它的灾备功能，而大数据应用里它还有一个更牛逼的作用：采集增量数据并生成数据文件，这个过程由OGG里的两个组件GordenGate 和 Adapter来完成
基于OGG的数据集成方案是把从Oracle采集数据的工作交给OGG来做。主要考虑到既要获得源系统精确的数据变化又要尽量不对源系统造成影响，实现的过程依赖OGG捕获数据库日志，而不是通过查询数据去获得数据变化的增、删、改，确实可以实现这个需求。所以，这个方案非常适合现在这种业务系统无法直接提供增量的场景。基于OGG的方案，首次采用DataX进行全库数据初始化。以后日常的所有的作业都是根据OGG解析出来的增量的csv文件，采用DataX任务装载到云平台中。
云平台里一个表的全量数据和增量数据怎么区分呢，靠分区：比如初始化分区分区值可以设为00000000，后续每天的增量数据保存到具体日分区，如20190719等。
等增量数据上云之后就可以进行全量合并，全量合并的思想就是把全量数据与增量数据通过主键进行比对，每一份数据都有带的操作标识(IDU)，操作时间等，可根据此，主键不同(I标识)的直接添加，主键相同的根据操作时间选择最新的一条，是U的就直接添加，D的删除，如此一来全量合并即完成了，全量合并的sql脚本如下
INSERT OVERWRITE TABLE xxx.xxxx PARTITION(rfq='20190719')
SELECT uuid
,uuid2
,czid
FROM (
SELECT uuid
,uuid2
,czid
,ROW_NUMBER() OVER (PARTITION BY CONCAT(uuid) ORDER BY CAST(czid AS decimal) DESC) AS rn
FROM (
SELECT uuid
,uuid2
,czid
FROM xxx.xxxx
WHERE rfq = '20190718'
AND czid != 'D'
UNION ALL
SELECT uuid
,uuid2
,czid
FROM xxx.xxxx
WHERE RFQ = '20190719'
) T
) t
WHERE t.rn = 1
AND t.czid != 'D'
;
标签：解决方案,数据库,上云,czid,全量,增量,OGG,数据 来源： https://blog.csdn.net/mochou111/article/details/96483753
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。