大数据之路：数据同步

目录

1.数据同步基础

2.阿里数据仓库的同步方式

3.数据同步遇到的问题和解决方案

---

1.数据同步基础

大数据的数据同步主要包括从分布式业务系统同步进入数据仓库和数据从数据仓库同步进入数据应用和数据服务两个方面。本文主要讲述的是前者。

从业务系统同步数据到数据仓库的数据同步总的说来分为三种，直连同步(侵入式)，数据文件同步，数据库日志解析。

直连同步：通过JDBC方式直接连接源系统抽取数据，当数据量大时容易对数据库造成压力甚至拖垮数据库的性能。

数据文件同步：约定好数据文件的格式，编码，大小，通过专门的FTP文件服务器传输到目标系统，同时配上一个校验文件，用于核验数据文件的数据量以及文件大小等校验信息以防丢包并验证数据同步的准确性。传输前加密压缩，传输后解密和解压缩。

数据库日志解析同步：这个方式其实已经 可以达到“实时”和“准实时”的要求了。数据库日志文件格式稳定内容丰富，解析日志文件获取发生变更的数据完成增量同步的需求。数据库日志抽取通常是获取所有的数据记录的变更(增，删，改)，根据主键分组并按照操作时间倒序排序 来查看数据状态的变化。通过数据库日志解析增量同步该方式性能好，效率高，对业务系统影响较小，但有如下问题：a.数据延迟。例如，业务系统做批量补录可能会使数据更新量超出系统处理峰值，导致数据延迟。b.投人较大。采用数据库日 抽取的方式投入较大，需要在源数据库与目标数据库之间部署 个系统实时抽取数据。c.数据漂移和遗漏。数据漂移，一般是对增量表而言的，通常是指该表的同一个业务日期数据中包含前一天或后一天凌晨 附近的数据或者丢失当天的变更数据。（QST:数据延迟和数据漂移，这俩我不能理解啥意思啥情况）

“删除数据”这个变更情况，其落地方式视情况而定 ，主要有三种。

第一种：不过滤删除流水。不管是否是删除操作，都获取同一主键最后变更的那条流水。

第二种：过滤最后一条删除流水。如果同一主键最后变更的那条流水是删除操作，就获取倒数第二条流水。

第三种：过滤删除流水和之前的流水。如果同一主键变更的过程中有删除操作，则根据操作时间讲该删除操作和之前的操作流水都过滤掉。

一般可使用第一种，“不过滤删除流水”，留下删除标识来判断数据是否有效。

如果明确业务数据不存在业务上的删除，但是存在批量手工删除或备份数据删除，例如淘宝商品，会员 等，则可以采用只过滤最后一条删除流水的方式，通过状态字段来标识删除记录是否有效。(QST:折啥意思，为什么这样的话第二种方式有效？？)

2.阿里数据仓库的同步方式

阿里数据同步的数据源类型是多样的，需要同步的数据是海量的，阿里大数据处理系统MaxCompute的数据存储达到EB级别，每天同步的数据量达到PB级别。

批量数据同步：Datax,多方向多自由度的数据同步，有分布式有单机的。读取数据，处理处于中间状态的数据格式化统一化再传到目标数据仓库。一般所有字段全部统一用String类型。一个大Job通过Splitter切分为多个并行执行的Sub-Job，运行Sub-Job中的读入数据数据部分对中间状态做处理，通过Channel传给Writer，Writer负责数据写出模块。

实时数据同步：双十一的数据大屏是通过解析Mysql库binlog日志(相当于Oracle的归档日志)来实时获得增量的数据更新，加上订阅消息，实现实时增量同步数据。比如阿里实时数据传输平台TimeTunnel(TT)，通过一个模块不停去读取并解析各机子的日志文件，增量数据通过数据流传输到日志交换中心，然后通知所有订阅了这些数据的数据仓库系统来获取。

3.数据同步遇到的问题和解决方案

分库分表的处理：TDDL(Taobao Distributed Data Layer) 分布式数据库访问引擎，通过建立中间状态的逻辑表来整合统一分库分表的访问。再JDBC层之上，再持久层之下，包括了SQL解释器，SQL优化器，SQL执行器，结果集合并。（QST:真牛逼啊，有源码可看吗

高效同步和批量同步：OneClick产品，实现了数据的一键化和批量化同步，还包括了与数据同步相关的建表，配置任务，发布，测试操作。    数据仓库的数据源种类丰富，不同数据源的同步需要开发人员去了解其特殊配置，为解决这个问题，OneClick通过 库名和表名唯一 定位 ，通过IDB接口获取元数据信息自动生成配置信息。

增量和全量同步的合并：在数据库不支持update或者数据量特别大的情况下，采用 全外连接(Full outer Join)+数据全量覆盖重新加载(Insert Overwrite)。用今天新增数据 full outer join 昨日全量数据，得到今日全量数据 insert overwrite。如果怕数据错误，以时间为分区字段，保留近5-7日的全量数据版本。

同步性能的处理：基于负载均衡的思想设计的一套数据同步方案，实现了根据目标数据库元数据信息来自动估算同步任务所需的总线程数，数据同步任务按照业务优先级定位。

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

数据漂移的案例：双十一的时候，发现有批在11月11日23:59:59左右支付的交易订单漂移到了12日。主要原因是用户下单支付后系统需要调用支付宝接口而有所延迟，从而导致这些订单最终生成的时间跨天了。即modified_time和log_time都晚于proc_time。

数据漂移的原因：时间戳字段通常分为4类，具体业务过程发生时间 proc_time，数据库表中数据记录更新时间的时间戳字段 modified_time，数据库日志中标识数据记录更新时间的时间戳字段log_time，数据记录被抽取到数据仓库的时间戳字段 extract_time。按理来讲，这四个应一样，但这四个往往出现差异从而导致当根据其中某个时间戳字段区分ODS表时就会发生数据漂移。

数据漂移的一般处理：1.多获取后一天凌晨15min的数据来保证数据只多不少，而具体的数据切分
让下游根据自身不同的业务场景用不同的业务时间 proc time 来限制。但是这种方式会有一些数据误差，例如 某个订单是当天支付的，但是第二天凌晨申请退款关闭了该订单，那么这条记录的订单状态会被更新，下游在统计支付订单状态时会出现错误。(QST：这个案例我不理解，会出现啥错误)        2.通过多个时间戳字段限制时间来获取相对准确的数据。首先根据log_time冗余前一天最后15min和后一天最开始15min的数据，然后根据modified_time去筛选出当天数据，确保不会出现因系统问题导致的遗漏。然后将后一天log_time前15min的数据按照logtime升序排序去重获得最接近当天记录变化的数据。最后将第一步的全部数据和第二步中最接近昨天的记录做全外连接，然后通过限制proc_time来最终获取我们所需要的数据。（牛啊牛啊，真牛啊）

操作包含多个业务过程时发生数据漂移的处理：比如订单有多个业务流程，包括 下单，支付，成功，每个业务过程都有对应的时间戳，每个业务过程都可能会发生数据漂移。因此，我们可以根实据际情况获取后 15 分钟的数据，并限制多个业务过程的时间戳字段（下单、支付、成功）都是“双 ”当天的，然后对这些数据按照订单的 modified time 升序排列，获取每个订单首次数据变更的那条记录。此外，我们可以根据 log_time 分别冗余前一天最后 15 分钟的数据和后一天凌晨开始 15 分钟的数据，并用 modified time 过滤非当天数据，针对每个订单按照 log time 进行降序排列 ，取每个订单当天最后一次数据变更的那条记录。最后将两份数据根据订单做全外连接，将漂移数据回补到当天数据中。（QST：我不理解。。）