第三章 数据同步之问题与解决办法

分表分库的处理

1）传统数据库的分表分库处理：

2）在大数据系统中的做法是构建分布式数据库访问引擎（中间层），将分布在不同数据库中的表集成为一张表，业务系统像单表一样使用

3）分布式数据库访问引擎位于数据持久层与JDBC驱动之间，实现了以下功能：

---

高效同步与批量同步

1）数据同步流程：创建表--同步工具中配置数据库连接/表/字段--测试

2）存在问题：

① 数据量增大时，每天会有大量重复的配置工作，降低开发人员热情

② 不同数据库有个性配置

3）解决方式：

① 实现配置流程一键化操作，并封装web接口进一步达到批量化的效果

② 开发数据库管理平台，统一管理数据、数据结构；实现对不同数据源配置透明化，通过库名表名唯一的定位数据

---

增量与全量数据同步：

1）数据量超出一定阈值，每个周期同步全量数据会消耗大量资源。在这种情况下可以只同步增量数据并与前一天的全量数据进行合并。

2）当前流行的大数据平台基本不支持update操作，所以我们用全外连接+全量覆盖的方式更新数据。即将当天增量数据与前一天全量数据做全外连接，然后重新加载最新的全量数据。

---

数据漂移的处理

1）数据漂移发生在数据仓库的最底层ODS层，当日业务数据中包含前一天或者后一天凌晨的数据，或者当天的变更数据丢失

2）原因：数据在ODS层按时间分区存储，时间戳的准确性导致了数据漂移。

时间戳分四类：

① 数据库表中的数据更新时间（modified_time）

② 数据库日志中的数据更新时间 (log_time)

③ 数据库表中业务发生时间 (proc_time)

理论上这3个时间时相同的，事件中往往存在偏差，理由如下：

① 前台业务手工修正数据未更新modified_time

② 由于网络压力，modified_time和log_time晚于proc_time

3）数据漂移场景

① 依据modified_time划分，会发生因为未更新modified_time而导致数据遗漏，或者由于网络压力凌晨的数据漂移到后一天

② 依据log_time划分，由于网络压力，业务发生时未能实时更新数据，导致凌晨的数据漂移到后一天

③ 依据proc_time划分，仅仅包含一个业务记录，遗漏过程的变化记录