You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
|
|
|
|
|
原则上，要求所有汇集系统必须提供增量数据变更办法，采用伪删除+时间戳策略，原则上不允许对表格进行delete操作！
|
|
|
|
|
|
|
|
|
|
|
|
但就是怕坚持不下来，导致出现有的业务系统存在delete操作的问题。
|
|
|
|
|
|
|
|
|
|
|
|
# ds_id 为guid类型，为唯一主键，原来的业务主键不使用
|
|
|
|
|
|
# 每张字段都有一列 is_del,描述此条数据是否已被删除掉，需业务系统进行维护，不得真的执行 delete 操作。
|
|
|
|
|
|
如果实在说服不了业务系统，就需要对于存在delete操作的业务系统表，由我司研发人员，手动写delete trigger,向原表中插入一个带有删除标识的数据记录,来完成对原有逻辑的维护。
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------
|
|
|
|
|
|
可以考虑如下的备用方案：
|
|
|
|
|
|
|
|
|
|
|
|
增量数据通过Kafka的单Topic向业务系统发布，可以避免Kafka的时序不正确问题，性能下降不是最主要的矛盾问题。
|
|
|
|
|
|
|
|
|
|
|
|
# debezium同步postgresql数据至kafka
|
|
|
|
|
|
https://www.cnblogs.com/virtualzzf/p/17574740.html
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# 业务系统数据库，如果共享数据增量获取异常，该如何重置？
|
|
|
|
|
|
答：kafka中json数据格式：ts_ms记录了写入时间戳，可以用Java转化为 Date类型，同理，一旦用户的增量数量获取异常，可以采用如下方法重置：
|
|
|
|
|
|
|
|
|
|
|
|
1、向数据仓库管理员申请最新的完全备份，比如2023-10-31 00：00：00
|
|
|
|
|
|
2、采用Postgresql 16还原此数据库，再通过自行编码等办法，完成自己业务数据库中对共享数据的重建。
|
|
|
|
|
|
3、向 Kafka中获取时间戳大于2023-10-31 00：00：00的数据即可。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对于未来可能出现的多租户多级模式，可以考虑debezium->kafka,然后用Java写代码，将kafka的Topic中数据读取出来，再根据划分的粒度，比如到区县、到校的办法，创建新的Topic,再进行写入即可。
|
|
|
|
|
|
|
|
|
|
|
|
# kafka topic和topic权限操作
|
|
|
|
|
|
https://blog.csdn.net/qq_17328759/article/details/129804571
|
|
|
|
|
|
|
|
|
|
|
|
|
