监控GreenPlum表存在的问题
只监控时间戳有什么问题:相同时间戳的记录太多,按时间戳升序排序加 limit 会丢失时间戳等于最后一个时间戳的部分记录。
只监控id有什么问题:若只使用唯一id监控数据,数据发生变更id是监控不到的,这是万万不可以的。
在查询时发现一个问题,一般增量代码通过监控时间戳和设置批大小实现数据的分批写入,但GreenPlum的某个表相同时间戳的数据太多(触发器导致),设置批大小往往会将与最后一个时间戳相等的数据截断,导致丢失一部分数据。这在数据做增量更新的时候是不可接受的,既然只监控时间戳会存在问题,那是否需要加个全表唯一的id字段辅助截断。
解决思路:
1、先根据时间戳升序排序和 limit batchSize 截取一部分数据query1;
2、将最大的时间戳保留到变量right_lmt中,将已经查询到的id记录到列表id_has_run中;
3、根据时间戳等于right_lmt并且id not in tuple(id_has_run)来找出剩余部分的记录rest_query;
4、将rest_query 扩充到query1中,因此,实际的批大小比变量batchSize大。
5、增加GreenPlum表id索引。
疑问:既然第一步已经按照时间戳升序排序,为啥第2步不直接用 时间戳等于 right_lmt 并且 id 大于最后一个id来筛选记录呢?
答:这是因为GreenPlum采用的是分布式存储,根据时间戳升序排序并不能保证id是升序排序的,实际上id是乱序的,特别是当已有数据做了更改。