数据同步基础
1.直连同步
是指通过ODBC、JDBC的规范API进行同步。该同步的特点是直接，针对不同的数据源库API通用。缺点是很容易影响源数据库的正常业务，有时候甚至会拖垮源数据库。如果源数据库存在主从策略，则可以从从库读取数据，减少对源数据库的影响。但是当数据量较大时，此方法抽取数据较慢，不适合用于从数据库同步到数仓。
2.数据文件同步
源数据库以约定的格式，编码，大小等信息生成对应的文件，再通过FTP文件服务器将文件传输到目标系统，加载到目标系统的数据库中。当数据源包含多种异构的数据源时，此种方式较为简单使用。互联网日志类数据大都是字符串的形式存储，也是适合用文件同步的方式。
在文件传输过程中可能会丢包或者数据错误，在传输文件中除了数据本身外还可以添加文件大小，数据行数等信息。在下游拿到包后可以解析信息进行校验，如果数据有误，丢包的情况发生，则让上游重试发送文件。
文件传输前可以对文件压缩和加密，压缩以达到高效传输，加密以达到安全传输。
3.数据日志文件解析同步
通过解析日志文件的方式同步数据，最大的优点是不会对源数据库产生影响，因为解析日志操作是在系统层进行的。
也存在如下缺点：
1.当出现大批量的业务数据补录时，这些日志超出了同步系统的处理能力，就会造成数据延迟
2.投入较大，需要在源数据库和目标数据库之间部署一个日志抽取系统，增加人力成本。
3.数据漂移，指同一个业务日期的日中中包含前一天的日子或者后一天凌晨附近的数据，或者是本属于当日的数据丢失了。
阿里数据仓库的同步方式
1.批量数据同步
将各种异构数据源的数据都转化为字符串的中间格式，再同步到数据仓库。
阿里以dataX实现多异构数据源之间的数据同步。dataX可以通过插件的形式新增自定义的同步方式，开发简单，只需定义对数据系统的访问。传输过程全内存操作，中间数据不落盘，没有进程间通信，保证了高效率传输。
dataX的大致工作模式同一般的大数据处理框架的模式一样，都是先将一个大的任务拆分成众多小的任务，由reader去读取这些小任务进行发送channel，channel下游对接writer，writer负责将小任务对应的数据写入目标数据源。都是分而治之的思想。
2.实时数据同步
阿里采用binlog日志解析，再同步到TimeTunnel消息队列中，供下游实时系统消费。TimeTunnel类似于kafka，也是基于Producer、consumer、topic、broker组件的分布式消息中间件。
***数据同步遇到的问题与解决方案
1.分库分表处理
对于分库分表，阿里的处理策略是加了一层逻辑中间表，该中间表能整合位于不同库的表，让上层读分表就像读单表一样。该逻辑表位于持久层之下，JDBC之上，保持了和JDBC一样的规范，让上层就像读JDBC一样。
2.高效同步与批量同步
在同步数据的过程中，由于业务复杂性，源数据库的多样化、表的多样化、数据字段的多样化，面对这样海量的信息，不可能要求数据同步人员去了解数据库中每一个表字段的信息，并配置到dataX中进行数据同步。阿里开发了oneClick，该组件基于源数据库里的表的元数据信息去自动推断相关表和字段的信息，并自动化配置。减少了开发人员的介入，减少工作量并减少人工出错的概率。同步库名和表名唯一确定一个表。并根据源数据库的配置信息自动去目标数据库生成相关的表和字段。
3.增量与全量同步的合并
采用每日同步新增的数据，再和数仓里的全量数据做合并。其实更好的处理方式是采用实时同步变更的数据，采用拉链表的方式更新数据
4.同步性能的处理
根据源数据库的数据量信息、期待同步时长估算出需要同步的线程数。比如总量100W，期待同步1分钟，而一个线程一分钟最多同步10万的数据量，所以总的需要10个线程，将这100w数据拆分成10个task，分发给2个节点，每个节点启动5个线程同时进行同步。但是单个节点启动5个线程同步数据，这5个线程同步的50w数据都必须再单个节点的IO上限之下。
5.数据漂移的处理
数据库中有4类时间戳字段：按时间顺序分别如下：
1.业务发送时间：process_time,如用户下单的提交时间
2.业务系统数据库处理该下单的时间:modified_time
3.bin-log日志标识数据记录变更的时间:log-time
4.标识业务数据被抽取到的时间：extract_time
由于数据抽取需要时间，所以extract_time是最晚的。
前台业务系统手工订正数据是没有更新modified_time。
由于系统压力，modified_time和log_time会晚于process_time。
ODS通常选用上面几个时间中的一个作为分区时间。这就是导致凌晨11：59发送的业务数据，最终由于系统压力第二天凌晨00:01才到达业务数据库，如果以modified_time作为分区时间，那么这条前一天发送的业务数据就被归纳到后一天了。造成了数据不准确。
如果更具extract_time来分区，数据漂移是最明显的，因为extract_time是最晚的。
如果以modified_time来分区，可能由于手工修改数据，未更新modified_time而导致数据遗漏。或者凌晨产生的数据漂移到后一天。
如果以log_time来作为分区时间，也会由于系统压力，log_time会晚于process_time，也会产生前一天的业务数据漂移到后一天。
如果取process_time,就只能采集到一个业务过程的数据。也就是该业务过程由用户发起并记录到数据库。有些操作并不是用户发起的，并没有process_time,如果不属于用户发起的业务，就没有process_time。不能获取这部分数据就违背了ODS于业数据要保持一致性的原则。
对于如上的情况，可以采取如下的2种策略解决数据漂移问题
1.向后根据log_time多取后一天凌晨10分钟前的数据，下游再根据不同的业务需求分别取不同的数据。但该方法会导致数据一定程度上的不准去，如一个订单11:59下单，凌晨00:01申请退款并关闭了该订单。如果根据该方法则申请退款也会被算在当天的数据里，所以该订单状态会被更新为关闭状态。当实际上当天该订单并没有关闭，而是第二天才关闭。
2.通过多个时间戳字段限制时间来获取相对准确的数据。