数据技术篇之数据同步
第3章 数据同步
1.数据同步基础
- 直连同步
（1）什么是直连同步？
直连同步是指通过定义好的规范接口 API 和基于动态链接库的方式直接连接业务库，如 ODBC/JDBC 等规定了统
一规范的标准接口，不同的数据库基于这套标准接口提供规范的驱动，支持完全相同的函数用和 SQL 实现。
（2）优点
配置简单、实现容易
（3）缺点及优化
业务库直连的方式对源系统的性能影响较大，当执行大批量数据同步时会降低甚至拖垮业务系统的性能。如果业务库采取主备策略，则
可以从备库抽取数据，避免对业务系统产生性能影响。但是当数据量较大时，采取此种抽取方式性能较差，不太适合从业务系统到数据
仓库系统的同步。
（4）适用场景
比较适合操作型业务系统的数据同步。
- 数据文件同步
（1）什么是数据文件同步
数据文件同步通过约定好的文件编码、大小、格式等，直接从源系统生成数据的文本文件，由专门的文件服务器，如 FTP 服务器传输到
目标系统后，加载到目标数据库系统中。
（2）优点
在从源系统生成数据文件的过程中，可以增加压缩和加密功能，传输到目标系统以后，再对数据进行解压缩和解密 这样可以大大
提高文件的传输效率和安全性。
（3）缺点及优化
由于通过文件服务器上传、下载可能会造成丢包或错误，为了确保数据文件同步的完整性，通常除了上传数据文件本身以外，还会上传一
个校验文件，该校验文件记录了数据文件的数据量以及文件大小等校验信息，以供下游目标系统验证数据同步的准确性。
（4）适用场景
当数据源包含多个异构的数据库系统（如 MyS QL Oracle QL Server DB2 等）。另外，互联网的日志类数据，通常是以文本文件形式存
在的，也适合使用数据文件同步方式。
- 数据库日志解析同步
（1）什么是数据库日志解析同步
通过解析日志文件获取发生变更的数据，从而满足增量数据同步的需求。
（2）优点
数据库日志解析同步方式实现了实时与准实时同步的能力，延迟以控制在毫秒级别，并且对业务系统的性能影响也比较小。
（3）缺点
① 数据延迟。例如，业务系统做批量补录可能会使数据更新量超出系统处理峰值，导致数据延迟。
② 投人较大。采用数据库日 抽取的方式投入较大，需要在源数据库与目标数据库之间部署一个系统实时抽取数据。
③ 数据漂移和遗漏。数据漂移，一般是对增量表而言的，通常是指该表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据
或者丢失当天的变更数据。
（4）适用场景
目前广泛应用于从业务系统到数据仓库系统的增量数据同步应用之中。
2.阿里数据仓库的同步方式
阿里数据仓库的数据同步特点是数据来源的多样性和数据量巨大。因此需要针对不同的数据源类型和数据应用的时效性要求采取不同的策略。
- 批量数据同步
针对将不同的数据源批量同步到数据仓库，以及将经过数据仓库处理的结果数据定时同步到业务系统，阿里巴巴提出了DataX。DataX可接入的数据源如下图所示。
（1）DataX是什么？
DataX是一个个能满足多方向高自由度的异构数据交换服务产品。
（2）工作原理及构成
对于不同的数据源， DataX 通过插件的形式提供支持，将数据从数据源读出并转换为中间状态，同时维护好数据的传输、缓存
等工作。数据在 DataX 中以中间状态存在， 并在目标数据系统中将中间状态的数据转换为对应的数据格式后写入。
DataX 采用 Framework+Plugin 的开放式框架实现， Framework 处理缓冲、流程控制、并发、上下文加载等高速数据交换的大部分技术问
题，并提供简单的接口与插件接人。插件仅需实现对数据处理系统的访问，编写方便，开发者可以在极短的时间内开发 个插件以快速支持新
的数据库或文件系统。数据传输在单进程（单机模式）／多进程（分布式模式）下完成，传输过程全内存操作，不读写磁盘，也没有进间通
信，实现了在异构数据库或文件系统之间的高速数据交换。
Job ：数据同步作业
Splitter ：作业切分模块，将一个大任务分解成多个可以并发行的小任务
Sub-Job ：数据同步作业切分后的小任务，或称之为 Task
Read er ：数据读人模块，负 运行切分后的小任务，将数据从源系统 载到 DataX
Channel: Reader Writer 通过 Channel 交换数据。
Writer ：数据写出模块，负责将数据从 DataX 导人目标数据系统。
- 实时数据同步
实时数据同步就是建立 个日志数据交换中心，通过专门的模块从每台服务器源源不断地读取日志数据，或者解析业务数据库系统的 binlog 或归档日志，将增量数据以数据流的方式不断同步到日志交换中心，然后通知所有订阅了这些数据的数据仓库系统来获取。阿里巴巴的TimeTunnel (TT ）系统就是这样的实时数据传输平台，具有高性能、实时性、顺序性、高可靠性、高可用性、可扩展性等特点
（1）TT是什么？
TT 是一种基于生产者、消费者和 Topic 消息标识的消息中间件，将消息数据持久化到 HBase 的高可用、分布式数据交互系统。
生产者 ：消息数据的产生端，向 TimeTunnel 集群发送消息数据，就是图中的生产 Client。
消费者：消息数据的接收端，从 TimeTunnel 集群中获取数据进行业务处理。
Topic ：消息类型的标识，如淘宝 acookie 日志下的 Topic为taobao_acookie 生产 Client 和消费 Client 需要知道对应的Topic名字。
Broker模块： 负责处理客户端收发消息数据的请求，然后往HBase 取发数据
3.数据同步遇到的问题与解决方案
- 分库分表的处理
（1）问题
随着数据量的增加，需要系统具备灵活的扩展能力和高并发大数据了的处理能力，目前一些主流数据库都提供了分布式分库分表的方案来解决这个问题。但是分库分表却增加了数据同步处理的复杂度。
（2）解决方案
阿里巴巴的 TDDL ( Taobao Distributed Data ayer ）就是这样一个分布式数据库的访问引擎，通过建立中间状态的逻辑表来整合统一分库分表的访问。
TDDL是在持久层框架之下、JDBC驱动之上的中间件，它与JDBC规范保持一致，有效解决了分库分表的规则引擎问题，实现了 SQL解析、规则计算、表名替换、选择执行单元并合并结果集的功能，同时解决了数据库表的读写分离、高性能主备切换的问题，实现了数据库配置信息的统一管理。
- 高效同步和批量同步
（1）问题
随着业务的发展和变化，会新增大批量的数据同步，使用传统方式每天去完成成百上千的数据同步工作，一方面，工作量会特别方面，相似并且重复的操作会降低开发人员的工作热情。
数据仓库的数据源种类特别丰富，遇到不同类型的数据源同步就要求开发人员去了解其特殊配置。
部分真正 的数据需求方，如 Java 开发和业务运营，由于存在相关数据同步的专业技能门槛，往往需要将需求提交给数据开发方来完成，额外增加了沟通和流程成本。
（2）解决方案
阿里巴巴数据仓库研发了 OneClick 产品：
对不同数据源的数据同步配置透明化，可以通过库名和表名唯定位，通过 IDB 接口获取元数据信息自动生成配置信息。
简化了数据同步的操作步骤，实现了与数据同步相关的建表、配置任务、发布、测试操作一键化处理，并且封装成 Web 接口进一步达到批量化的效果。
降低了数据同步的技能门槛，让数据需求方更加方便地获取和使用数据。
注：IDB 是阿里巴巴集团用于统一管理 MySQL 、OceanBase、PostgreSQLacle、SQL Server 等关系型数据库的平台，它是一种集数据管理、结构管理、诊断优化、实时监控和系统管理于一体的数据管理服务；在对集团数据库表的统一管理服务过程中， IDB 产出了数据库、表、字段各个级别元数据信息，并且提供了元数据接口服务。
- 增量与全量同步的合并
（1）问题
在传统的数据整合方案中，合并技术大多采用 merge 方式( update+insert ）；但是当前流行的大数据平台基本都不支持update 操作
（2）解决方案
现在比较推荐的方式是全外连接（ full outer join) ＋数据全量覆盖重新加载（ insert overwrite ），即如日调度，则将当天的增量数据和前一天的全量数据做全外连接，重新加载最新的全量数据。
- 同步性能的处理
（1）问题
针对数据同步任务 一般首先需要设定首轮同步的线程数，然后运行同步任务。这样的数据同步模式存在以下几个问题:
有些数据同步任务的总线程数达不到用户设置的首轮同步的线程数时，如果同步控制器将这些同步线程分发到 CPU 比较繁忙的机器上，将导致这些同步任务的平均同步速度非常低，数据同步速度非常慢。
用户不清楚该如何设置首轮同步的线程数，基本都会设置成一个固定的值，导致同步任务因得不到合理的CPU 资源而影响同步效率。
不同的数据同步任务的重要程度是不一样的，但是同步控制器平等对待接收到的同步线程，导致重要的同步线程因得不到CPU资源而无法同步。
上述数据同步模式存在的几个问题导致的最终结果是数据同步任务运行不稳定。
（2）解决方案
针对数据同步任务中存在的问题，阿里巴巴数据团队实践出了一套基于负载均衡思想的新型数据同步方案。该方案的核心思想是通过目标数据库的元数据估算同步任务的总线程数，以及通过系统预先定义的期望同步速度估算首轮同步的线程数，同时通过数据同步任务的业务优先级决定同步线程的优先级，最终提升同步任务的执行效率和稳定性。
具体实现步骤如下：
① 用户创建数据同步任务，并提交该同步任务。
② 根据系统提前获知及设定的数据，估算该同步任务需要同步的数据量、平均同步速度、首轮运行期望的线程数、需要同步的总线程数。
③ 根据需要同步的总线程数将待同步的数据拆分成相 等数量的数据块，一个线程处理 个数据块，并将该任务对应的所有线程提交至同步控制器。
④ 同步控制器判断需要同步的总线程数是否大于首轮运行期望的线程数，若大于，则跳转至⑤若不大于，则跳转至⑥。
⑤ 同步控制器采用多机多线程的数据同步模式，准备该任务第一轮线程的调度，优先发送等待时间最长、优先级最高且同 任务的线程。
⑥ 同步控制器准备一定数据量（期望首轮线程数－总线程数）的虚拟线程，采用单机多线程的数据同步模式 ，准备该任务相应实体线程和虚拟线程的调度，优先发送等待时间最长、优先级最高且单机 PU 剩余资源可以支持首轮所有线程数且同 任务的线程，如果没有满足条件的机器，则选择 CPU 剩余资源最多的机器进行首轮发送。
⑦ 数据任务开始同步，并等待完成。
⑧ 数据任务同步结束。
- 数据漂移的处理
（1）什么是数据漂移
数据漂移是ODS数据的一个顽疾，通常是指ODS（通常我们把ong源系统同步进入数据仓库的第一层数据成为ODS或staging层数据，阿里统称为IDS）表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或则丢失当天的变更数据。
（2）产生数据漂移的原因
由于 ODS 需要承接面向历史的细节数据查询需求，这就需要物理落地到数据仓库的 ODS 表按时间段来切分进行分区存储 ，通常的做法是按某些时间戳字段来切分，而实际上往往由于时间戳字段的准确性问题导致发生数据漂移
通常，时间戳字段分为四类：
数据库表中用来标识数据记录更新时间的时间戳字段（假设这类字段叫 modified time ）
数据库日志中用来标识数据记录更新时间的时间戳字段·（假设这类宇段叫 log_time)
数据库表中用来记录具体业务过程发生时间的时间戳字段 （假设这类字段叫 proc_time)
标识数据记录被抽取到时间的时间戳字段（假设这类字段extract time)
理论上，这几个时间应该是一致的，但是在实际生产中，这几个时间往往会出现差异，可能的原因有以下几点
由于数据抽取是需要时间的， extract_time 往往会晚于前三个时间。
前台业务系统手工订正数据时未更新 modified_time
由于网络或者系统压力问题， log_time 或者 modified_time 会晚于proc_time
通常的做法是根据其中的某 个字段来切分 ODS 表，这就导致产生数据漂移。
（3）解决方案
①多获取后一天的数据
②通过多个时间戳字段限制时间来获取相对准确的数据