分表分库的处理
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划分，仅仅包含一个业务记录，遗漏过程的变化记录
