同步速度

数据同步问题与解决⽅案：增量全量、数据漂移，数据更新、

⼀、增量与全量同步的合并

问题：传统数据同步⽅式为周期全量数据同步，但随着业务发展数据量的急剧增加，周期全量同步的效率太低了。

解决⽅案：每个周期只同步增量数据，然后与上⼀个同步周期获取的全量数据进⾏合并，获取最新版本的全量数据。

传统数据整合⽅案：merge⽅式（update+inrt）；

当前⼤数据平台不⽀持update操作，⽽采⽤：全外连接（fullouterjoin）+数据全覆盖重新加载（inrtoverwrite）；（即如⽇调

度，则将当天的增量数据和前⼀天的全量数据做全外连接，重新加载最新的全量数据）

如果担⼼数据更新错误：每条保持⼀个最新的全量版本，保留较短的事件周期。（另外，当业务系统的表有物理删除数据的操作，⽽数据仓

库需要保留所有历史数据时，也可以选择这种⽅式，在数据仓库中永久保留最新的全量数据快照。）

例：淘宝订单表

1：数据更新

⽅案⼀：数据更新可以增量抽取合并merge，得到最新数据

⽅案⼆：采⽤kudu数据库，kudu⽀持主键更新操作

2、数据删除

⼀般业务系统删除数据，业务库逻辑删除，即打删除或者⽆效标签字段，

但DBA物理删除这么办？下游⽆感的，这样ODS以及数仓永远存在这条数据了。

⼆、实时同步，既解决数据性能，⼜解决数据更新删除问题

DSG/canal:⽤来监控数据库数据的变化，从⽽获得新增、修改、删除等的数据。

⽅案⼀：DSG同步到另⼀个ORACLE数据库，再sqoop从数据库抽取，这样包含增删修改的数据，可解决数据删除问题

⽅案⼆：DSG/canal+Kafka+Spark解析数据+Hive、Kudu

⼆、同步性能的处理

数据同步任务是针对不同数据看系统之间的数据同步问题⽽创建的⼀些列周期调度的任务。在代⾏的数据调度⼯作台上，每条会运⾏

⼤量的数据同步任务。针对数据同步任务，⼀般⾸先需要设定⾸轮同步的线程数，然后运⾏同步任务。这样的数据同步模式存在以下⼏个问

题：

1.有些数据同步任务的总线程数达不到⽤户设置的⾸轮同步的线程数时，如果同步控制器将这些同步县城分发到CPU⽐较繁忙的机器

上，将导致这些同步任务的平均同步速度⾮常低，数据同步速度⾮常慢；

2.⽤户不清楚该如何设置⾸轮同步的线程数，基本都会设置成⼀个固定的值，导致同步任务因得不到合理的CPU资源⽽影响同步效

率；

3.不同的数据同步任务的重要程度是不⼀样的，但是同步控制器平等对待接收到的同步线程，导致重要的同步线程因得不到CPU资源

⽽⽆法同步；

上述三种情况可能会导致同步任务不稳定。

阿⾥集团的解决思路：通过⽬标数据库的元数据估算同步任务的总线程数，以及通过系统预先定义的期望同步速度估算⾸轮同步的线程数，

同时通过数据同步任务的业务优先级决定同步线程的优先级，最终提升同步任务的执⾏效率和稳定性。

具体实现步骤：

1.⽤户创建数据同步任务，并提交该同步任务；

2.根据系统提前获知及设定的数据，估算该同步任务需要同步的数据量、平均同步速度、⾸轮运⾏期望的线程数、需要同步的总线程

数；

3.根据需要同步的总线程数将待同步的数据拆分成等数据量的数据块，⼀个线程处理⼀个数据块，并将该任务对应的所有线程提交⾄同

步控制器；

4.同步控制器判断需要同步的总线程数是否⼤于⾸轮运⾏期望的线程数，若⼤于，则跳转⾄（5）；若不⼤于，则跳转⾄（6）；

5.同步控制器采⽤多机多线程的数据同步模式，准备该任务的第⼀轮线程的调度，优先发送等待时间最长、优先级最⾼且同⼀任务的线

程；

6.同步控制器准备⼀定数量（期望⾸轮线程数-总线程数）的虚拟线程，采⽤单机多线程的数据同步模式，准备该任务响应实体线程和

虚拟线程的调度，优先发送等待时间最长、优先级最⾼且单机CPU剩余资源可以⽀持⾸轮所有线程数且同⼀任务的线程，如果没有

满⾜条件的机器，则选择CPU剩余资源最多的机器进⾏⾸轮发送。

7.数据任务同步开始，并等待完成；

8.数据任务同步结束。

三：数据漂移

通常把从源系统同步进⼊数据仓库的第⼀层数据成为ODS层数据。

数据漂移：指ODS表的同⼀个业务⽇期数据中包含前⼀天或后⼀天凌晨附近的数据，或者丢失当天的变更数据。

由于ODS需要承接⾯向历史的细节数据查询需求，这就需要物理落地到数据仓库的ODS表按时间段来切分进⾏分区存储；（通常的

做法是按某些时间戳字段来切分，⽽实际上往往由于时间戳字段的准确性问题导致发⽣数据漂移）

问题：通常，时间戳分为四类（根据其中的某⼀个字段来切分ODS表，导致产⽣数据漂移）：

1.数据库表中⽤来表⽰数据记录更新时间的时间戳字段（假设这类字段叫modified_time）；

2.数据库⽇志中⽤来表⽰数据记录更新时间的时间戳字段（假设这类字段叫log_time）；

3.数据库表中⽤来记录具体业务过程发⽣时间的时间戳字段（假设这类字段叫proc_time）；

4.标识数据记录被抽取到时间的时间戳字段（假设这类字段叫extract_time）；

理论上以上⼏个时间应该是⼀致的，但实际⽣产中，这⼏个时间往往会出现差异，可能的原因有⼀下⼏点：

1.由于数据抽取是需要时间的，extract_time往往会晚于前三个时间；

2.前台业务系统⼿⼯订正数据时未更新modified_time；

3.由于⽹络或者系统压⼒问题，log_time或者modified_time会晚于proc_time；

数据漂移场景：

1.根据extract_time来获取数据（ODS数据）。（数据漂移问题最明显）

2.根据modified_time限制。（最常见，但是往往会发⽣不更新modified_time⽽导致的数据遗漏，或者凌晨事件产⽣的数据记录漂

移到前⼀天。）

3.根据log_time限制。（由于⽹络或者系统压⼒问题，log_time会晚于proc_time，从⽽导致凌晨时间产⽣的数据记录漂移到后⼀

天。）（例：天猫“双11”⼤促期间，凌晨时间产⽣的数据⾮常⼤，⽤户⽀付需要调⽤多个接⼝，导致log_time晚于实际的⽀付时

间）

4.根据proc_time限制。（得到的ODS表只是包含⼀个业务过程所产⽣的记录，会遗漏很多其他过程的变化记录，违背了ODS和业

务系统保持⼀致的设计原则）

两种解决⽅法：

（1）多获取后⼀天的数据

每个时间分区中，向前、向后多冗余⼀些数据，保障数据智慧多不会少，⽽具体的数据切分让下游根据⾃⾝不同的业务场景⽤不

同的业务时间proc_time来限制。

2.缺点：产⽣数据误差。（例：⼀个订单是当天⽀付的，但是第⼆条凌晨申请退款关闭了该订单，那么这条记录的订单状态会被更新，

下游在统计⽀付订单状态时会出现错误）

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

1.⾸先，根据log_time分别冗余前⼀天最后15分钟的数据和后⼀天凌晨开始15分钟的数据，并⽤modified_time过滤⾮当天数

据，确保数据不会因为系统问题⽽遗漏；

2.然后，根据log_time获取后⼀天15分钟的数据；针对此数据，按照主键根据log_time做升级排列去重。（因为最终需要获取的是

最接近当天记录变化的数据（数据库⽇志将保留所有变化的数据，但是落地到ODS表的是根据主键去重获取最后状态变化的数

据））

3.最后，将前两步的结果数据做全外连接，通过限制业务时间proc_time来获取所需要的数据。

例：淘宝交易订单的数据漂移；

“双11”的交易订单中，有⼀⼤批在11⽉11⽇23:59:59左右⽀付的交易订单漂移到了12⽇。主要原因是⽤户下单⽀付后系统

需要调⽤⽀付宝的接⼝⽽有所延迟，从⽽导致这些订单最终⽣成的时间咵天了。即modified_time和log_time都晚于proc_time。

难点：

1.如果订单只有⼀个⽀付业务过程，则可以⽤⽀付时间类限制就能获取到正确的数据。但是往往实际订单有多个业务过程：下单、⽀

付、成功，每个业务过程都有响应的时间戳字段，并不只有⽀付数据会漂移。

2.若果直接通过多获取后⼀天的数据，然后限制这些时间，则可以获取到相关数据，倒数后⼀天的数据可能已经更新多次，直接获取到

的那条记录已经是更新多次后的状态，数据的准确性存在问题。

解决⽅法：

1.根据实际情况获取后⼀天15分钟的数据，并限制多个业务过程的时间戳字段（下单、⽀付、成功）都是“双11”当天的，然后对

这些数据按照订单的modified_time做升序排列，获取每个订单⾸次数据变更的那条记录；

2.根据log_time分别冗余前⼀天最后15分钟的数据和后⼀天凌晨开始15分钟的数据，并⽤modified_time过滤⾮当天数据，针对

每个订单按照log_time进⾏降序排列，去每个订单当天最后⼀次数据变更的那条记录。

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