大数据之路_数据同步

数据同步基础：数据同步技术更通用的含义是不同系统间的数据流转，有多种不同的应用场景。主数据库与备份数据库之间的数据备份，以及主系统与子系统之间的数据更新，属于同类型不同集群数据库之间的数据同步。另外，还有不同地域、不同数据库类型之间的数据传输交换，比如分布式业务系统与数据仓库系统之间的数据同步。对于大数据系统来说，包含数据从业务系统同步进入数据仓库和数据从数据仓库同步进入数据服务或数据应用两个方面。总的来说，同步方式可以分为三种 直连同步 、数据文件同步和数据库日志解析同步。

 

直连同步：这种方式配置简单，实现容易，比较适合操作型业务系统的数据同步。但是业务库直连的方式对源系统的性能影响较大，当执行大批量数据同步时会降低甚至拖垮业务系统的性能。如果业务库采取主备策略，则可以从备库抽取数据，避免对业务系统产生性能影响。但是当数据量较大时，采取此种抽取方式性能较差，不太适合从业务系统到数据仓库系统的同步。

 

数据文件同步：数据文件同步通过约定好的文件编码、大小、格式等，直接从源系统生成数据的文本文件，由专门的文件服务器，如 FTP 服务器传输到目标系统后，加载到目标数据库系统中。当数据源包含多个异构的数据

库系统（如 MyS QL Oracle QL Server DB2 等）时，用这种方式比较简单、实用。另外，互联网的日志类数据，通常是以文本文件形式存在的，也适合使用数据文件同步方式。

由于通过文件服务器上传、下载可能会造成丢包或错误，为了确保数据文件同步的完整性，通常除了上传数据文件本身以外，还会上传一个校验文件，该校验文件记录了数据文件的数据量以及文件大小等校验信息，以供下游目标系统验证数据同步的准确性。

另外，在从源系统生成数据文件的过程中，可以增加压缩和加密功能，传输到目标系统以后，再对数据进行解压缩和解密 这样可以大大提高文件的传输效率和安全性。

 

数据库日志解析同步：

目前，大多数主流数据库都已经实现了使用日志文件进行系统恢复，因为日志 文件信息足够丰富，而且数据格式也很稳定，完全可以通过解析日志文件获取发生变更的数据，从而满足增量数据同步的需求。

Oracle 为例，可以通过源系统的进程，读取归档日志文件用以收集变化的数据信息，并判断日志中的变更是否属于被收集对象，将其解析到目标数据文件中。这种读操作是在操作系统层面完成的，不需要通过数据库，因此不会给源系统带来性能影响。

然后可通过网络协议，实现源系统和目标系统之间的数据文件传输。相关进程可以确保数据文件的正确接收和网络数据包的正确顺序，并提供网络传输冗余，以确保数据文件的完整性。

数据文件被传输到目标系统后，可通过数据加载模块完成数据的导人，从而实现数据从源系统到目标系统的同步。

数据库日志解析同步方式实现了实时与准实时同步的能力，延迟可以控制在毫秒级别，并且对业务系统的性能影响也比较小，目前广泛应用于从业务系统到数据仓库系统的增量数据同步应用之中。

通过数据库日志解析进行同步的方式性能好、效率高，对业务系统的影响较小。但是它也存在如下一些问题：

（1)数据延迟。例如，业务系统做批量补录可能会使数据更新量超出系统处理峰值，导致数据延迟。

(2)投人较大。采用数据库日志 抽取的方式投入较大，需要在源数据库与目标数据库之间部署 一个系统实时抽取数据。

（3)数据漂移和遗漏。数据漂移， 一般是对增量表而言的，通常是指该表的同一个业务日期数据中包含前一天或后一天凌晨 附近的数据或者丢失当天的变更数据。

 

批量数据同步：

要实现各类数据库系统与数据仓库系统之间的批量双向数据同步，就需要先将数据转换为中间状态，统一数据格式。

阿里巴巴的 DataX 就是这样 个能满足多方向高自由度的异构数据交换服务产品。对于不同的数据源， DataX 通过插件的形式提供支持，将数据从数据源读出并转换为中间状态，同时维护好数据的传输、缓存等工作。

•Job ：数据同步作业

• Splitter ：作业切分模块，将 个大任务分解成多个可以并发行的小任务

• Sub-Job ：数据同步作业切分后的小任务，或称之为 Task

• Read er ：数据读人模块，负 运行切分后的小任务，将数据从源系统 载到 DataX

• Channel: eader Writer 通过 hannel 交换数据。

• Writer ：数据 出模块，负责将数据从 DataX 导人目标数据系统。

 

 

分库分表处理：

高效同步和批量同步：

增量与全量同步的合并：现在我们比较推荐的方式是全外连接（ full outer join) ＋数据全量覆盖重新加载（ insert overwrite ），即如日调度，则将当天的增量数据和前一天的全量数据做全外连接，重新加载最新的全量数据。此外，如果担心数据更新错误问题，可以采用分区方式，每天保持 个最新的全量版本，保留较短的时间周期（如3-7 天）

另外，当业务系统的表有物理删除数据的操作，而数据仓库需要保留所有历史数据时，也可以选择这种方式，在数据仓库中永久保留最新全量数据快照。

数据漂移的处理：通常是指 ODS 表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。

由于 ODS 需要承接面向历史的细节数据查询需求，这就需要物理落地到数据仓库的 ODS 表按时间段来切分进行分区存储 ，通常的做法是按某些时间戳字段来切分，而实际上往往由于时间戳字段的准确性问题导致发生数据漂移。

处理方法主要有以下两种：

( l ）多获取后一 天的数据

(2 ）通过多个时间戳字段限制时间来获取相对准确的数据

最后将两份数据根据订单做全外连接，将漂移数据回补到当天数据中。