数据同步技术分析与介绍

导言
基于数据采集日常所遇到的数据同步技术进行技术了解，持续补充文档内容。目标是通过阅读此文档能够有效了解到相关数据同步技术知识，提升阅读人员对数据同步方式的了解程度。如果对文档中描述的内容感兴趣，可自行查找相关资料学习，增加个人数据同步技术的深度。
一、数据实时同步技术
1.1.CDC数据同步
1.1.1.技术介绍
变化数据捕获 (Change Data Capture，缩写CDC) 是指识别和捕获对数据库中的数据所做的更改（包括数据或数据表的插入、更新、删除等），然后将这些更改按发生的顺序完整记录下来，并实时传送到下游流程或系统的过程。通过这种方式，CDC能够向数据仓库提供高效、低延迟的数据传输，以便信息被及时转换并交付给专供分析的应用程序。CDC的核心思想是进行数据更改的捕获和识别，并将其发送下游系统。
1.1.2.应用场景
1)数据分发：将一个数据源的数据分发给多个下游业务系统，常用于业务解耦、微服务系统。
2)数据采集：面向数据仓库、数据湖的ETL数据集成，消除数据孤岛，便于后续的分析。
3)数据同步：常用于数据备份、数据归集等。
1.1.3.常见的变化数据捕获方法
LogMiner 是 Oracle 数据库提供的一个分析工具，该工具可以解析 Oracle Redo 日志文件，从而将数据库的数据变更日志解析成变更事件输出。通过 LogMiner 方式时，Oracle 服务器对解析日志文件的进程做了严格的资源限制，所以对规模特别大的表，数据解析会比较慢，优点是 LogMiner 是可以免费使用的。

下列4种CDC的实现方式中，基于日志方式的CDC是最优的实现方式，其实时性高、无侵入性，并且能将所有的更改捕获。如果无法获取并解析数据库日志文件，则可以选择其他三种方式进行CDC。
基于快照的方式虽然可以捕获所有的变更记录，但是其有个明显的缺点就是需要大量的存储空间来保存快照数据，且实时性低。
基于触发器的方式因为要增加触发器，则对变更数据进行多次写入操作，有一定的侵入性。
基于查询的方式则需要在数据表上进行时间列、自增列的添加，侵入性强，且无法获取删除操作，因此很少使用。
1)基于查询的CDC：这种方法中，需要不断的查询源数据库表中的数据，以获取更改的数据记录；查询过程中需要通过某些列来判断哪些数据是变更的；常见的有时间戳列、自增序列列，可以通过保存创建时间列、修改时间列来表示插入、变更的记录，自增列也很容易识别出新插入的记录。
2)基于触发器的CDC：在这个方法中，当业务系统执行插入、更新、删除这些SQL时，以激活数据库的触发器，使其对数据记录进行变更捕获，并将数据保存在一个临时表中，最后将变更数据从临时表中抽取到数据仓库中。
3)基于快照的CDC：如果上述的触发器以及增加列查询的方式都不被允许的情况下，就可以使用快照表等方式进行变更数据的捕获；其实现思路就是通过比较源表和快照表的方式，获取数据的变更信息，通过快照的方式可以检测到插入、更新以及删除的数据记录。
4)基于日志的CDC：当数据库表完成一个的新的DML(insert，update，delete)操作后，数据库都会将它实时记录到日志文件中；通过解析数据库操作日志的方式，可以将插入、更新、删除的数据更改操作都可以捕获，发送下游系统。
1.1.4.变更日志流
CDC程序将包括插入、更新、删除的数据操作通过进行解析处理转换，形成统一规范的变更消息传递给下游的系统，这些消息流包括INSERT(+I)，UPDATE_BEFORE(-U)，UPDATE_AFTER(+U)，DELETE(-D)四种消息状态语义：
1)INSERT(+I)：新插入的数据记录行。
2)UPDATE_BEFORE(-U)：数据记录行被更新前的数据。
3)UPDATE_AFTER(+U)：数据记录行被更新后的数据。
4)DELETE(-D)：删除的数据记录行。

1.1.5.技术优点
1)通过增量加载或将数据更改实时流式传输，而无需周期性调度执行批量加载更新操作。
2)CDC实时同步传输数据，它利于不停机的数据库迁移，并支持实时分析，可以帮助用户根据最新的数据做出更快、更准确的决策。
3)CDC最大限度地减少了数据的传输网络流量，适合跨广域网传输数据。通过指定表的方式同步，减少数据传输量，降低网络带宽和存储需求。
4)CDC可以确保多个系统中的数据保持同步。
5)技术可以免费使用。
6)能够支持不同类型的数据源和目标系统，并适应复杂的数据同步需求。
7)通过对变更操作进行校验和持久化，保证数据同步的可靠性和一致性
1.1.6.技术缺点
1)需要源库进行授权，开通日志等权限。
2)不同类型数据库版本受限，部分早期版本不支持CDC。
3)数据库类型受限，不是所有类型的数据库都可以采用CDC同步。
4)只支持增量数据同步，历史数据无法同步。
5)部分类型的数据库只支持DML操作，不支持同步DDL操作。
1.1.7.开库要求
1)数据库cdc同步表单账号与权限申请。
a.数据库：数据库服务器地址信息，如：阿里x.阿里x.阿里x 端口号。
b.同步cdc账号和密码提供。
c.需开启cdc日志同步权限，开启授权账号。
2)数据库环境及权限要求。
a.oracle日志要求
开启归档日志，启用pk/ui附加日志，查看是否启用归档日志和pk/ui级别日志语句：
select log_mode, SUPPLEMENTAL_LOG_DATA_MIN MIN, SUPPLEMENTAL_LOG_DATA_PK PK, SUPPLEMENTAL_LOG_DATA_UI UI, SUPPLEMENTAL_LOG_DATA_ALL ALL_LOG from v$database;; – 值：yes -表示已启用。
若以上语句，值不是yes，则需执行以下语句授权：启用归档日志和pk/ui附加日志。启用pk/ui附加日志语句：
alter database add supplemental log data(primary key, unique) columns;
1.1.8.CDC技术拓展介绍

1)ETLCloud CDC能够自动根据不同的数据库类型捕获数据变化日志可实现数据表的实时毫秒级同步，实时数据可同时并行分发到多个目标库或应用中。支持实时数据传输到Hive、MongoDB 、Doris、MSQ中，同时也支持从MongoDB 、MSQ、文件实时传输到SQL数据库中，支持一对多传输，支持多流合并传输，传输过程中支持数据质量检查，能实时把脏数据分发到指定表中并发送告警通知。
2)Sqoop CDC通过监视源数据库的事务日志来实现数据的增量抽取。它能够检测到源数据库中发生的更改操作，并将这些更改操作应用于目标数据库，以保持两者的数据同步。使用CDC，用户可以在不间断的情况下将更新的数据批量和实时地移动到目标数据库中，而无需整体导出整个数据集。
3)DataX CDC基于DataX框架，为用户提供了一种灵活、高效的数据同步解决方案。它通过监视源数据库的事务日志或数据库增量日志来捕获源数据库中的变更操作，并将这些操作应用于目标数据库，以保持两者之间的数据同步。这种增量方式可以大大减少数据传输的时间和成本，并提供更及时的数据更新。
4)Flink CDC利用Flink框架的流式计算能力来处理和转换变更数据。它使用源数据库的增量日志或者事务日志作为输入源，通过Flink的流处理引擎对日志进行实时解析和处理，并将解析后的数据应用于目标数据库，以实现数据的增量传输和同步。
1.1.9.CDC技术介绍
1)Oracle 数据同步
a.数据同步支持范围：支持数据库DML、DDL操作。
b.数据同步方式：1、DataX同步历史数据，2、CDC同步新增数据。

1.2.OGG数据同步

1.2.1.技术介绍
OGG（Oracle GoldenGate）就是一款能够轻松实现数据库同步需求的解决方案，它是由Oracle阿里推出的一种实时数据复制技术，可以在异构数据库之间进行双向数据传输和同步。它可以捕获生产环境的变更并将其传输到目标端，从而实现两边数据库的同步。
它通过解析源数据库在线日志或归档日志获得数据的增删改变化（数据量只有日志的四分之一左右）OGG能够实现大量交易数据的实时捕捉，变换和投递，实现源数据库与目标数据库的数据同步，保持最少10ms的数据延迟1。

Oracle GoldenGate 实现原理是通过抽取源端的redo log 或者 archive log ，然后通过TCP/IP投递到目标端，最后解析还原应用到目标端。
详细OGG如何数据同步，基本原理和架构：
1)源端（SRC）：获取Oracle数据表数据，从日志文件获取
管理者：MGR（Manger）
第一、进程：Extract提取进程，获取日志数据文件
第二、本地缓存：Local TrailFile，将日志文件数据存储到本地TrailFile文件中，缓存
第三、进程：（可选）Pump进程，将本地Local TrailFile发送给目标端
2)目标端（DST）：发送数据到目标，如Topic
管理者：MGR（Manger）
第一、进程：Collect进程，接收源端pump进程发送的数据，新版添加进程
第二、远程缓存：RemoteTrailFile，目标端接收到数据文件以后，进行缓存
第三、进程：Replicat进程，复制进程，解析RemoteTrailFile文件，转换JSON格式，发送到Kafka
1.2.2.进程介绍
1)Manager进程： Manager进程是GoldenGate 的控制进程。如果把所有的 Oracle 进程比喻为军队，那么 Manager 就相当于司令。Manager 进程运行在源端和目标端上，它主要有以下几个方面的 作用：启动、监控、重启GoldenGate 的其他进程，报告错误及事件，分配数据存储空间，发布阈值报告等。每个源端或者目标端有且只能存在一个 Manager 进程。其运行状态有两种即 RUNNING（正在运行）和STOPPED（已经停止）。在Windows 系统上，Manager进程是作为一个服务来启动的，而在类UNIX系统中， Manager则是一个操作系统进程。
2)Extract进程：Extract运行在数据库源端，负责从源端数据表或者日志中捕获数据。在早期的 GoldenGate 版本中，它通常被称为Collect 进程。按照其所处的阶段不同，Extract的作用可以按照时间来划分。初始数据装载阶段：在初始数据装载阶段，Extract进程直接从源端的数据表中抽取数据。 同步变化捕获阶段：初始数据同步完成以后，Extract进程负责捕获源端数据的变化（DML和DDL）。Extract 进程利用其内在的checkpoint机制，周期性地检查并记录其读写的位置，通常是写入到一个本地的trail文件。这种机制是为了保证如果Extract 进程终止或者操作系统宕机，重新启动 Extract 进程后，GoldenGate能够恢复到以前的状态，从上一个断点处继续往下运行，而不会有任何数据损失。Extract进程的状态包括STOPPED（正常停止）、STARTING （正在启动）、RUNNING （正在运行）、ABENDED（Abnomal End 的缩写，表示异常结束）。
3)Pump进程：Pump进程运行在数据库源端，其作用非常简单。如果源端使用了本地的trail文件， 那么Pump 进程就会把trail以数据块的形式通过TCP/IP协议发送到目标端，这通常也是推荐的方式。Pump 进程本质是Extract进程的一种特殊形式，如果不使用trail 文件，那么就 是Extract 进程在抽取完数据以后，直接投递到目标端。与Pump进程相对应的叫做Server Collector进程，这个进程不需要引起人们的关注， 因为在实际操作过程中无需对其进行任何配置，所以对人们来说它是透明的。它运行在目 标端，其任务就是把 Extract/Pump 投递过来的数据块重新组装成trail 文件。
4)Trail文件：为了更有效、更安全地把数据库事务信息从源端投递到目标端，GoldenGate引进trail 文件的概念。前面提到Extract抽取数据以后GoldenGate会将抽取的事务信息转化为一 种GoldenGate 专有格式的文件，然后Pump负责把源端的trail文件投递到目标端，所以源、目标两端都会存在这种文件，源端存放的trail文件叫本地trail文件，目标端存放的trail文件叫远程trail文件。trail文件存在的目的旨在防止单点故障，将事务信息持久化，并且使用checkpoint 机制来记录其读写位置，如果故障发生，则数据可以根据checkpoint 记录 的位置来重传。
5)Replicat进程：Replicat进程，通常也把它叫做应用进程。运行在目标端，是数据传递的最后一站， 负责读取目标端trail文件中的内容，并将其解析为 DML或DDL语句，然后应用到目标数据库中。和Extract 进程一样，Replicat也有其内部的checkpoint机制，保证进程重新启动后可以从上次记录的位置开始恢复，而无数据损失的风险。它的运行状态和Extract进程一致，包括STOPPED、STARTING、RUNNING、ABENDED。
总结：共4个进程，分别为Manager、Extract、Pump、Replicat，其中Manager运行在源端及目标端，Extract、Pump分别为抽取及投递进程，运行在数据源端，Replicat运行在目标端负责读取投递的内容并应用到数据库中，其中源端与目标端以trail文件来传递、解析。
1.2.3.应用场景
1)数据库备份与恢复：OGG可以将生产环境的数据备份到另一个数据库中，以保证数据安全性和可用性。同时，在需要恢复数据时，OGG可以快速地将备份数据恢复到原始环境中，减少业务中断时间。
2)多地点数据同步：对于跨地理位置的业务应用，OGG可以将多个数据中心的数据同步到一个集中的数据仓库中，以支持全局数据的查询和统计分析。
3)实时数据分析：OGG可以将生产环境的实时数据传输到数据分析平台中，以支持实时的业务洞察和决策。
4)数据库升级和迁移：OGG可以将旧的数据库版本升级到新版本，或将数据迁移到新的硬件平台上，从而保证业务的顺畅进行。
1.2.4.OGG的部署方式
OGG的部署分为源端和目标端两个部分。在源端，需要安装OGG的采集组件（Capture）和传输组件（Pump），用于捕获和传输源端数据库的变更数据。在目标端，需要安装OGG的应用组件（Apply），用于接收和执行传输过来的数据。
下面是OGG的部署步骤：
1)在源端安装Capture和Pump组件；
2)在目标端安装Apply组件；
3)配置OGG的参数文件，指定源端和目标端的数据库连接信息、传输方式、校验方式等；
4)启动Capture、Pump和Apply组件，开始数据传输和同步。
1.2.5.OGG的主要特点
1)准实时数据同步：OGG可以准实时捕获源数据库上的数据变更，并即时传输到目标数据库中，使目标数据库与源数据库保持同步。
2)支持异构数据库：OGG可以在不同的数据库之间进行数据传输和同步，包括Oracle、MySQL、SQL Server、Sybase等数据库。
3)支持广泛的数据格式：OGG可以解析多种数据格式，包括行格式、列格式、XML格式等。
4)支持高效的数据压缩：OGG可以对数据进行压缩，从而减少数据传输的网络带宽和存储空间的占用。
5)支持高可靠性：OGG可以通过内置的数据校验和和容错机制来确保传输过程中的数据一致性和可靠性。
1.2.6.OGG支持的组建

1.2.7.OGG的特性
1)对生产系统影响小，实时读取交易日志，以低资源占用实现大交易量数据实时复制。
2)以交易为单位复制，保证交易一致性，只同步已提交的数据
3)高性能，智能的交易重组和操作合并，使用数据库本地接口访问，并行处理体系，灵活的拓扑结构，支持一对一、一对多、多对一、多对多和双向复制等。
1.3.DG数据同步
1.3.1.技术介绍
dg全名成为Data Gurad。是oracle数据库的一种灾备工具。在Data Gurad 环境中，至少有两个数据库，一个处于Open 状态对外提供服务，这个数据库叫作Primary Database。 第二个处于恢复状态，叫作Standby Database。 运行时primary Database 对外提供服务，用户在Primary Database 上进行操作，操作被记录在联机日志和归档日志中，这些日志通过网络传递给Standby Database。 这个日志会在Standby Database 上重演，从而实现Primary Database 和Standby Database 的数据同步。

原理是日志文件从主库传输到备库，然后在备库上应用这些日志，从而使备库与主库保持同步
DG由一个primary数据库及一个或多个standby数据库组成，备库最多9个
主库：即被大部分应用访问的生产数据库，该库即可以使单实例数据库，也可以使RAC
备库：备库也支持单机或RAC，备库正常为只读状态
1.3.2.应用场景
1)保证简单的数据保护和可用性：一个DG集可以包含一个主库和多个备库，主库控制着所有资源的访问，并记录所有的数据变更，而备库则存储着主库的备份，并保证能够快速响应主库的请求，以实现数据库的高可用和数据冗余。
2)应对故障和数据备份：DG可以在简单的两个数据库节点之间实现自动切换，并可以在主库发生故障的情况下，快速地将系统转移到备库，并且备库的数据在主库正常时都是与主库同步的。
3)数据复制和数据同步：DG技术可以帮助企业快速建立一个数据同步节点，以保证数据的一致性和完整性，减少系统中的数据冲突和数据重复的问题。
4) 数据保护：对于对数据保护要求较高的业务，DG可以提供可靠的数据冗余和故障恢复能力，在需要灾难恢复时可以快速地将业务切换到备库。
5)降低主库压力：采用DG方案，可以在备库上执行只读查询等操作，分担主库的性能压力。
6)数据库升级：DG可以用于数据库升级过程中的平滑迁移，减少停机时间。
1.3.3.DG的组成部分
1)主库（Primary Database）：主库是整个DG系统的核心组建，它为所有的存储器分配器提供服务。这里的存储器分配器是DG的一个主要特点，通过存储器分配器，管理员可以对DG的数据进行管理和分配。
2)备库（Standby Database）：备库是DG系统中的备份数据库实例，它保存一份与主库完全一样的数据拷贝，在主库出现故障的情况下，可以快速切换至备库，以保证系统的稳定运行状态。
3)DG存储器分配器（DG Broker）：DG存储器分配器是一个计算机软件程序，它是DG系统的前台控制组件，可以直接与Oracle数据库实例进行通信，负责将所有的备份变更事件传递给所有的备库，并同步所有的数据冲突。
1.3.4.DG工作模式
DG的核心机制是通过复制数据来达到数据库保护、可用性和恢复的目的。DG是通过一个异步或同步数据复制进程来实现的。
1.3.5.DG工作进程模式
1)ARCH进程-传归档日志

主库：产生日志后通过LGWR进程写入在线重做日志，当满足相关条件后在线重做日志会进行切换，ARC0进程归档该日志至主库本地的归档目录（log_archive_dest_1配置），归档完成后，ARC1进程就会将归档日志传输到备库(log_archive_dest_2配置)，备库RFS进程负责接收日志。
如果备库有standby重做日志，则把日志复制到standby重做日志，接着把standby重做日志归档至备库本地归档目录，最后应用归档日志。
如果没有配置standby重做日志，rfs进程接收日志后，直接把它放到备库的归档目录下，再应用该日志。
Arch方式是Oracle默认的传输方式，这种方式只有在主库日志归档的时候才会发送日志到备库。如果发生主库宕机的情况，则online redo log中的数据就会丢失，要想避免数据丢失，就需要使用LGWR。
2)LGWR进程-传重做日志
LGWR分为SYNC(同步)和ASYNC（异步）两种模式，oracle12c 增加fast sync模式
异步模式：在异步模式下，源数据库实例不需要在目标数据库实例的确认之前就提交事务。异步模式的数据传输方式，消息是从源到纪录文件直到传输到该组内的成员，不需要等待确认，只能保障数据在源上进行了备份操作。异步传输会对目标数据库实例的数据稍有滞后，但可以利用更多的网络吞吐量进行备份和复制。
同步模式：在同步模式下，源数据库实例必须在目标数据库实例的确认之后才能提交事务。数据的传输是基于事务的传输方式，等待确认，传输的过程中，如果主库出现问题，备库进行切换，无需进行数据同步。同步模式为每个成员提供一致性的数据，但会对应用系统的性能稍有影响。
ASYNC异步模式
主库： 只要有新的重做日志产生，LGWR进程将触发LNSn（Log Network Server）进程把新生成的重做日志传输到备库（如果配置了3个备库，则有3个LNS进程）。 ASYNC是redo buffer保存到 online redo log后，LNSn才开始传输。
备库： RFS进程负责接收日志。接收到日志后将其写入standby重做日志，如果备库开启了实时应用，就立即做日志应用，如果没有开启，则等standby重做日志归档后再应用。

SYNC同步模式（不建议，会影响生产）
主库：redo log buferr中只要有新的变更产生，LGWR进程将触发LNSn进程把新生成的重做日志传输到备库。SYNC是在redo buffer时，LNSn进程就开始传输，也就是说是从内存中就开始传输，并不写入redo log。
备库：rfs进程负责接收日志。接收到日志后将其写入standby重做日志，如果备库开启了实时应用，就立即做日志应用，如果没有开启，则等standby重做日志归档后再应用。这种方式备库需要给主库一个回复，证明传输成功，如果有问题一直不回复就会导致主库的lgwr进程一直挂起，影响主库。

1.3.6.技术优点
1)数据冗余：DG可以提供数据冗余，确保在主库故障时可以快速切换到备库，避免数据丢失。它通过实时传输和应用归档日志来保持主备库之间的数据一致性。
2)主备切换：DG可以在主库发生故障时快速将备库提升为新的主库，实现快速的灾难恢复。
1.3.7.技术缺点
1)数据延迟：由于数据传输的延迟，主库和备库之间可能存在一定的数据不一致性。
2)高网络带宽需求：DG需要高速、可靠的网络连接，以确保数据能够及时传输。
3)逻辑备库不能支持某些特定的数据对象和数据类型。
4)不支持双向复制，所以，无法应用于信息集成的场合。
5)只能复制整个数据库，不能选择某个SCHEMA或表空间或表进行单独复制。
6)不支持异构的系统环境，需要相同的操作系统版本和数据库版本（Oracle 11g支持部分异构平台）。
7)在Oracle 11g之前的物理备库虽然可以以只读方式打开，然后执行查询、报表等操作，但需要停止应用日志，这将使目标库与源数据不能保持同步，如果在此期间源数据库发生故障，那么将延长切换的时间。从Oracle 11g开始，ADG可以在数据库打开的情况下应用日志，这极大地提高了DG的应用范围。
1.4.ADG数据同步
1.4.1.技术介绍

ADG(Advanced Database Guardian)技术是针对数据库领域的一种新型技术，它能够有效地提升数据库的性能，加强数据的安全性。它通过在数据库中加入一些专门的安全功能和算法，提升数据库的安全性和防御能力。ADG技术的主要特点有：
1)数据保护：ADG技术能够对数据库中的重要数据进行加密，以保护数据的安全性，防止数据被黑客窃取或篡改。
2)安全监测：ADG技术能够对数据库中的安全事件进行监测，及时发现和处理安全事件。
3)权限控制：ADG技术能够对数据库进行访问控制，只允许授权的用户对数据库进行访问和操作。
1.4.2.应急机制
1)ADG数据同步延迟的应急机制。
在ADG数据同步延迟情况下，备库数据无法及时更新，为保证业务能够查询到最新数据，需要将备库交易切换至主库，这可以通过调整连接备库应用服务器的WebLogic多数据源顺序，将主库作为主数据源实现。调整完毕后，由于所有交易均访问主库，主库资源开销增大，需要对应用服务器进行流控以减少访问主库的交易量，避免出现主库资源耗尽的情况。

2)主数据库不可用的应急机制。
　　当主数据库不可用的时候，由于配置了多数据源，连接主库的应用服务器自动将数据源故障转移至备库。此时原主库上查询交易依然可用，因为备库不能写入，所以维护交易失效。在主库长时间无法恢复的情况下，需将备库配置为ADG主库后维护交易才可成功。另外，需要通过流控限制访问备库的交易量，避免出现备库资源耗尽的情况。

3)备数据库不可用的应急机制。
当备数据库不可用的时候，由于配置了多数据源，连接备库的应用服务器自动将数据源故障转移至主库。此时原备库上查询交易依然可用，需要通过流控限制访问主库的交易量，避免出现备库资源耗尽的情况。
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/acdc864977c043f5abbb933c4026b30c.png

1.4.3.部署要求
1)主数据库和备用数据库的版本和操作系统平台必须完全一致。
2)主数据库和备用数据库必须通过网络连接。
3)必须启用归档模式，将主数据库的归档日志传输到备用数据库。
4)必须使用相同的数据库名和SID（System Identifier）。
1.4.4.应用注意事项说明
1)ADG会产生一定的性能开销，尤其是在网络传输和应用归档日志时会占用大量资源。因此，在使用ADG之前需要做好性能测试和容量规划。
2)ADG并不是万无一失的，仍然需要考虑数据恢复的情况。因此，需要在每个备用数据库上定期测试和验证数据的一致性和可用性。
3)ADG并不能解决所有的灾难恢复问题，比如说物理破坏或者数据中心故障等问题。因此，需要根据业务需求配合使用其他灾难恢复方案。
1.5.Mysql 主从复制
1.5.1.技术介绍
主从复制技术是MySQL数据同步中最常用的技术之一。该技术将一个MySQL数据库作为主数据库，将另一个MySQL数据库作为从数据库。主数据库中的数据发生变化后，从数据库会自动同步这些变化。
主从复制技术的优点在于可以实现实时同步，主从复制技术还可以实现数据备份和容灾恢复。

在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql 线程和IO 线程)在 Slave 端，另外一个线程(IO 线程)在 Master 端。
1)Slave 上面的IO 线程连接上 Master，并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容。
2)Master 接收到来自 Slave 的 IO 线程的请求后，通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 BinaryLog 中的位置。
3)Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的RelayLog （中继日志文件）文件(MySQL-relay-bin.阿里阿里阿里)的最末端，并将读取到的Master 端的bin-log 的文件名和位置记录到master-info 文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”。
4)Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句，并在自身执行这些 Query。这样，实际上就是在 Master 端和 Slave 端执行了同样的 Query，所以两端的数据是完全一样的。
1.5.2.主从复制原理
mysql 主从复制的原理是基于二进制日志（binlog）的，主数据库在执行数据更新的操作时，会把操作记录到 binlog 文件中，并通过 binlog dump 线程发送给从数据库。从数据库有两个线程负责接收和执行主数据库的操作，分别是 I/O 线程和 SQL 线程。I/O 线程负责连接主数据库，请求并接收 binlog 事件，并保存到本地的中继日志（relay log）中。SQL 线程负责读取中继日志中的事件，并在从数据库中重放，从而实现数据的同步。
mysql 主从复制有不同的同步策略，主要有以下几种：
1)同步策略：主数据库会等待所有的从数据库都回应后才会提交事务，这样可以保证强一致性，但是会严重影响性能和可用性。
2)半同步策略：主数据库至少会等待一个从数据库回应后才会提交事务，这样可以保证至少一个从数据库和主数据库是一致的，但是仍然有可能出现数据丢失或不一致的情况。
3)异步策略：主数据库不用等待从数据库的回应就可以提交事务，这样可以提高性能和可用性，但是会牺牲一致性，可能出现数据延迟或丢失的情况。
4)延迟策略：从数据库可以设置一个延迟时间，让自己落后于主数据库一定的时间，这样可以避免一些误操作或攻击对数据造成的影响，也可以用于备份或审计的目的。
1.5.3.主从复制模式
MySQL 主从复制默认是异步的模式。MySQL增删改操作会全部记录在binary log中，当slave节点连接master时，会主动从master处获取最新的bin log文件。并把bin log中的sql relay。
1)异步模式（mysql async-mode）：异步模式如下图所示，这种模式下，主节点不会主动push bin log到从节点，这样有可能导致failover的情况下，也许从节点没有即时地将最新的bin log同步到本地。

2)半同步模式(mysql semi-sync)：这种模式下主节点只需要接收到其中一台从节点的返回信息，就会commit；否则需要等待直到超时时间然后切换成异步模式再提交；这样做的目的可以使主从数据库的数据延迟缩小，可以提高数据安全性，确保了事务提交后，binlog至少传输到了一个从节点上，不能保证从节点将此事务更新到db中。性能上会有一定的降低，响应时间会变长。如下图所示：

3)全同步模式：全同步模式是指主节点和从节点全部执行了commit并确认才会向客户端返回成功。
1.5.4.主从复制类型
1)基于二进制日志点的复制
基于二进制日志点的复制，按三种日志格式进行划分：基于SQL语句的复制(statement-based replication, SBR)、基于行的复制(row-based replication, RBR)、混合模式复制(mixed-based replication, MBR)：是上面两种方式的折中。
基于SQL语句的复制
在MySQL5．0及之前的版本中只支持基于浯旬的复制（也称为罗辑复制），这在数据库领域是很少见的。基于浯旬的复制模式下，主库会记录那些造成数据更改的查询，当备库读取并重放这些事件时，实际上只是把主库上执行过的SQL冉执行一谝。这种方式既有好处，也有缺点。
最明显的好处是实现相当简单。理论上讲，简单地记录和执行这浯旬能够让主备保持同步。另一个好处是二进制日志里的事件更加紧凑，所以相对而言，基于语句的模式不会使用太多带宽。一条更新好几兆数据的语句在二进制日志里可能只占几十个字节。另外mysql bin log工具是使用基于语句的日志的最佳工具。
但事实上基于语句的方式可能并不如其看起来那么便利。因为主库上的数据更新除了执行的浯旬外，可能还赖于其他因素。例如，同一条SQL在主库和备库上执行的时间可能稍微或很不相同，因此在传输的二进制日志中，除了查询语句，还包括了一些元数据信息，如当前的时间戳。即便如此，还存在着一些无法被正确复制的SQL。例如，使用CURRENT_USER()函数的浯旬。存储过程和触发器在使用基于语句的复制模式时也可能存在问题。
另外一个问题是更新必须是串行的。这需要更多的锁，有时候要特别关注这一点。另外不是所有的存储引擎都支持这种复制模式。尽管这些存储引擎是包括在MySQL5．5及之前版本中发行的。
优点：
历史悠久，技术成熟。
产生的bin log文件较小，比较节省空间。
Bin log中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况。
bin log可以用于实时的还原，而不仅仅用于复制。
主从版本可以不一样，从服务器版本可以比主服务器版本高。
缺点：
不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。
调用具有不确定因素的 UDF（用户自定义函数）时复制也可能出问题。
INSERT … SELECT会产生更多的行级锁
使用以下函数的语句也无法被复制：LOAD_FILE()、UUID()、USER()、FOUND_ROWS()、SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)
基于行的复制
MySQL5.1开始支持基于行的复制，这种方式会将实际数据记录在二进制日志中，跟其他数据库的实现比较相像。它有其自身的一些优点和缺点，最大的好处是可以正确地复制每一行，一些浯旬可以被更加有效地复制。
基于行的复制没有向后兼容性，和MySQL5.1一起发布的mysql bin log工具可以读取基于行的复制的事件格式（它对人是不可读的，但MySQL可以解释），但是早期版本的mysysyqlbinlog无法识别这类事件，在遇到错误时会退出。由于无须重放更新主库数据的查询，使用基于行的复制模式能够更高效地复制数据。重放一些查询的代价可能会很高。例如，下面有一个查询将数据从一个大表中汇总到小表。

想象一下，如果表enormous_table的列coll和col2有三种组合，这个查询可能在源表上扫描多次，但最终只在目标表上产生三行数据。但使用基于行的复制方式，在备库上开销会小很多。这种情况下，基于行的复制模式更加高效。
但在另一方面，下面这条浯旬使用基于语句的复制方式代价会小很多：

由于这条浯旬做了全表更新，使用基于行的复制开销会很大，因为每一行的数据都会被记录到二进制日志中，这使得二进制日志事件非常庞大。并且会给主库上记录日志和复制增加额外的负载，更慢的日志记录则会降低并发度。
由于没有哪种模式对所有况都是完美的，MySQL能够在这两种复制模式间动态切换。默认情况下使用的是基于语句的复制方式，但如果发现语句无法被正确地复制，就切换到基于行的复制模式。还可以根据需要来设置会话级别的变量binlog_format,控制二进制日志格式。
对于基于行的复制模式，很难进行时间点恢复，但这并非不可能。稍后讲到的日志服务器对此会有帮助。
混合模式复制
是上面两种方式的折中。
2)基于GTID的复制（MySQL>5.7推荐使用）
在传统的复制里面，当发生故障，需要主从切换，需要找到binlog和pos点，然后将主节指向新的主节点，相对来说比较麻烦，也容易出错。在MySQL5．6里面，不用再找binlog和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行，因为复制是自动的，MySQL会通过内部机制GTID自动查找点同步。
多线程复制〔基于库〕，在MySQL5．6以前的版本，slave的复制是单线程的。一个事件一个事件的读取应用。而master是并发写入的，所以延时是避免不了的。唯一有效的方法是把多个库放在多台slave，这样又有点浪费服务器。MySQL5．6里面，我们可以把多个表放在多个库，这样就可以使用多线程复制。
基于GTID复制实现的工作原理：
主节点更新数据时，会在事务前产生GTID，一起记录到bin log日志中。
从节卓的I/O线程将变更的bin log，写入到本地的relay log中。
SQL线程从relay log中获取GTID，然后对比本地bin log是否有记录（所以MySQL从节点必须要开启binary log。
如果有记录，说明该GTID的事务已经执行，从节点会忽略。
如果没有记录，从节中就会从relay log中执行该GTID的事务，并记录到bin log。
在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部曰描。
1.5.5.主从复制形式
1)一主一从

2)一主多从，提高系统的读性能：一主一从和一主多从是最常见的主从架构，实施起来简单并且有效，不仅可以实现HA，而且还能读写分离，进而提升集群的并发能力。

3)多主一从 （从5.7开始支持）:多主一从可以将多个mysql数据库备份到一台存储性能比较好的服务器上。

4)双主复制：双主复制，也就是互做主从复制，每个master既是master，又是另外一台服务器的slave。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。

5)级联复制：级联复制模式下，部分slave的数据同步不连接主节点，而是连接从节点。因为如果主节点有太多的从节点，就会损耗一部分性能用于replication，那么我们可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。

1.5.6.主从切换机制
1)一主一从：两台机器 A 和 B，A 为主库，负责读写。B 为从库，负责读数据。如果 A 库发生故障，B 库成为主库负责读写，修复故障后，A 成为从库，主库 B 同步数据到从库 A。

优点： 从库支持读，分担了主库的压力，提升了并发度，且一个机器故障了可以自动切换，操作比较简单，阿里从库还可以充当数据备份的角色。
缺点： 一台从库，并发支持还是不够，并且一共两台机器，还是存在同时故障的机率，不够高可用。
对于一主一从的模式，一般小阿里会这么用，不过该模式下，主从分离的意义其实并不大，因为小阿里的流量不高，更多是为了数据库的可用性，以及数据备份。
2)一主多从：一台主库多台从库，A为主库，负责读写。B、C、D为从库，负责读数据。如果 A 库发生故障，B库成为主库负责读写，C、D 负责读，修复故障后，A也成为从库，主库B同步数据到从库 A。

优点：多个从库支持读，分担了主库的压力，明显提升了读的并发度。
缺点：只有一台主机写，因此写的并发度不高。
基本上大阿里，比如百度、滴滴，都是这种一主多从的模式，因为查询流量太高，一定需要进行读写分离，同时也需要支持服务的高可用、数据容灾。
再结合上一篇文章讲的分库分表，基本就是大阿里的标配了。
1.5.7.应用场景
1)数据备份：主从复制可以实现数据的热备份，即从节点可以实时地同步主节点的数据变化，提高数据的可靠性和安全性。但是，主从复制不能防止人为的误操作，如删除或修改数据，因此还需要定期的全量备份或者使用延迟复制等策略。
2)读写分离：主从复制可以实现读写分离，即主节点负责写操作，从节点负责读操作，分担服务器的负载压力。读写分离可以提高数据库的并发能力和响应速度，尤其是在读多写少的场景下。读写分离可以通过程序或者代理软件来实现。
3)业务拆分：主从复制可以实现业务拆分，即根据不同的业务需求，将不同的从节点分配给不同的用户或者服务。例如，有些从节点可以提供外部用户的查询服务，有些从节点可以用于内部数据分析或者开发测试，有些从节点可以用于数据备份或者故障恢复等。这样的拆分可以使数据库对不同用户或者服务互不影响，提高数据库的可用性和灵活性。
1.5.8.主从复制的优点
1)读写分离：主从复制可以实现读写分离，从而提高系统性能。主服务器处理写操作和更新操作，而从服务器处理读操作，减轻了主服务器的负载。
2)备份和恢复：从服务器可以用于备份数据，如果在主服务器发生故障时，可以快速切换到从服务器，保证业务的连续性。同时，从服务器还可以用于测试和开发环境，减少对生产环境的影响。
3)负载均衡：通过在多个从服务器上分配读操作，可以平衡系统负载，提高整体性能。
4)扩展性：主从复制可以方便地增加系统容量，只需添加更多的从服务器即可。
5)故障转移：如果主服务器发生故障，可以快速地将一个从服务器提升为新的主服务器，实现故障转移，保证系统的可用性。
6)数据实时性：主从复制可以保证数据的实时性，主服务器的数据变更会实时同步到从服务器。
7)数据安全性：通过在从服务器上备份数据，可以防止数据丢失，提高数据安全性。
1.5.9.主从复制的缺点
1)写入无法扩展：主库的写入操作无法扩展到其他从库。
2)写入无法缓存：从库的写入操作无法缓存到主库，只能在主库上执行。
3)复制延时：主从复制过程中，数据从主库复制到从库需要一定的时间，导致数据同步延时。
4)锁表率上升：主从复制时，多个从库同时读取数据，导致锁表率上升。
5)表变大：缓存率下降。随着数据量的增加，表的大小也会增加，缓存率会下降。
1.5.10.主从复制存在的问题
1)主从延迟：由于主从复制是异步的，从节点可能会落后于主节点，导致数据不一致的情况。主从延迟的原因可能有网络延迟、从节点负载过高、主节点写入过快等。主从延迟的解决办法可能有优化网络配置、增加从节点数量、使用并行复制或半同步复制等。
2)主键冲突：如果主从复制中存在双主或者多主的情况，可能会出现主键冲突的问题，即两个或多个主节点同时插入相同的主键值，导致数据不一致或者复制失败。主键冲突的解决办法可能有使用自增列或者UUID作为主键、使用分区表或者分片等。
3)数据不一致：除了上述两种情况外，还有一些其他的原因可能导致数据不一致的问题，例如非确定性函数的使用、隐式类型转换、字符集编码不匹配、binlog格式不兼容等。数据不一致的解决办法可能有使用行级binlog格式、避免使用非确定性函数、保持字符集编码一致、定期检查数据完整性等。
1.6.Sql server发布订阅
1.6.1.技术介绍
SQL Server发布订阅功能是一种用于数据库同步和复制的功能。发布者将一份数据发布，并将其存储在发布数据库中，订阅者可以订阅这个数据，并将其同步到订阅者自己的数据库中。
SQL Server发布订阅功能可以帮助企业将数据从中心数据库同步到各地分支机构或其他数据中心，实现数据的复制与同步，这种方式可以大大提高数据的可用性，避免单点故障的风险。同时，发布订阅功能也可以用于开发测试环境中，方便开发团队共享测试数据。
数据库复制功能解释：
1)发布服务器：数据的来源服务器，维护源数据，决定哪些数据将被分发，检测哪些数据发生了修改，并将这些信息提交给分发服务器。
2)分发服务器：分发服务器负责把从发布服务器拿来的数据传送至订阅服务器。
3)订阅服务器：订阅服务器就是发布服务器数据的副本，接收维护数据。
4)订阅类型：①准订阅是指由发布服务器将所有发生修改过的数据复制给订阅者，这种在数据同步性价比较高的场合，推荐使用推订阅。②拉订阅是指订阅服务器在经过一段时间就会向发布服务器要求复制出版数据库发生的变化的数据。
发布、分发、订阅可以部署在独立的服务器上面也可以部署在一台sql server上面，然而分开部署肯定能提高性能。
1.6.2.复制类型
SQLSERVER供了三大类复制类型：快照复制、事务复制、合并复制。可以在实际应用中使用相应的复制类型，每一种复制类型都在不同程序上实现数据的一致性。
1)快照复制：如其名字所言，快照复制指在某一时刻给出版数据库中的出版数据照相，然后将数据复制到订阅者服务器。快照复制实现较为简单，其所复制的只是某一时刻数据库的瞬间数据，快照复制是将整个出版物传送给订阅者，就是在某一时刻将出版数据进行一次“照相’，生成一个描述出版数据库中数据的当前状态的一个文件，然后在相应的时间将其复制到订阅者的数据库上，快照复制并不是不停的监视出版数据库中发生的变化情况，它是对出版数据库进行一次扫描，把所有出版数据中的数据从源数据库送至目标数据库，而不仅仅是变化的数据。如果数据量很大，那么要复制的数据就很多。因此对网络资源要求很高，不仅要有较快的传输速度，而且要保证传输的可靠性。快照复制是最为简单的一种复制类型，能够在出版者和订阅者之间保证数据的一致性。快照复制通常使用在一定时间内出现大量的更改的操作，但数据总量不大，变化周期较长。

2)事务复制：事务复制是将整个数据集发送给订阅服务器，由于体积大而造成复制周期较长，会形成复制滞后问题。那么事务复制使用事务日志来生成将复制到订阅服务器的事务，因为它只复制事务也就是变化，所以滞后也比快照复制低得多，因为将不断的在订阅服务器处得到及时应用。事务复制有三个组件：①快照代理，它生成架构数据以及跟踪复制过程所需的数据。②分发代理：它分发快照和随后的命令。③日志读取器代理：它读取发布数据的事务日志。

在事务复制中，当出版数据库发生变化时，这种变化就会立即传涕给订阅者。并在较短时间内完成（几秒）而不是像快照复制那样要经过很长一段时间间隔。因此，事务复制是一种接近实时地从源到目标分发数据的方法。由于某种原因事务复制的频率较高，所以必须保证在订阅者与出版者之间要有可靠的网络连接。
3)合并复制：合并复制是为移动用户设计的，可以在发布服务器或是订阅服务器处执行修改，在合并代理运行时，这些修改将同步，多用于发布服务器与订阅服务都修改数据的情况下。工作原理如下：在要复制的每个表上实现触发器，并使用包含GUID列唯一标识要复制的表中的每一行。对其中的任何一个表进行修改时，都会将更改将记录一个数据表中，在合并代理运行时，它收集数据表中的GUID，这些GUID指出了在发布服务器和订阅服务器处修改过的行。对于只在发布服务器或是订阅端修改的数据则直接进行相应操作，如INSERT，UPDATE，DELETE，如果双方都有GUID则按照用户指定的方式解决冲突，默认发布服务器伏先。
配置复制：
无论是快照复制，事务性复制还是合并复制，创建复制都要经过以下几个步骤：
a.创建发布服务器。选择要发布的服务器。如果有条件的，也可以分发服务器，在这里我们就将发布服务器和分发服务器设置在同一台计算机上。
b.不论是发布服务器还是订阅服务器必须开启代理服务。
c.创建一个发布。即将需要的数据库及对象发布出来。
d.选择一个适合自己的发布类型。
e.设置复制代理及安全，即指定可以运行代理的用户帐号。
创建可以使用此发布的订阅服务器。
1.6.3.应用场景
1)数据库读写分离：通过对一个主库的进行“事务复制”，我们可以将每次主库的更新都同步到只读库上，从而达到读写分离的效果，进而提高系统性能。
2)数据库高可用方案：能将主库的更改实时同步到其他库中。
3)与其他系统进行数据对接：在与第三方阿里做对接时，可以直接将数据库中的指定表/指定列，甚至指定行的数据同步更新到对方的数据库里面，这样就减少了开发量。
4)总库和分库之间交换数据：如实现不同业务库字典表的一致性。
1.6.4.技术缺点
1)数据同步是异步的，变更的数据几秒钟后才能同步到订阅服务器；
2)不是整库的同步，需要对同步的对象（表、视图、存储过程、函数等）进行配置；
3)参与复制的表要有主键，而且不能有TRUNCATE TABLE操作；
4)对对象进行DROP操作时，要先从发布订阅中移除；
5)部署比较麻烦，易出错。
1.7.同步方式对比说明
1.7.1.CDC和OGG的区别
1)OGG是商业软件，需要收费；CDC是开源软件，可以免费使用。
2)CDC基于提交的事务为单位传输，而OGG是基于子交易单元（一个子交易可能含有好几个事务）传输；
3)异构数据库间字符集转换：IBM CDC支持，而OGG不支持；
1.7.2.DG和ADG的区别
1)功能不同：DG是Data Guard数据卫士，拥有备份的功能，能够确保数据的高可用性和数据保护，ADG是“Active Data Guard”，可以查询或导出数据，适用于只读性的应用。
2)读写不同：DG读写不能并行，ADG的读写可以并行。
3)数据同步方式不同：ADG支持实时数据同步，而DG则是异步数据同步。在切换过程中，ADG可以快速切换到备库并接管业务，而DG需要手动干预，并且需要进行数据一致性检查以确保数据的完整性。因此，ADG比DG更适合需要从故障中快速恢复的业务场景。另外，ADG还支持跨数据中心的数据同步，并且可以配合使用RAC实现高可靠、高可用的Oracle数据库环境。
4)DG（Data Guard）是 Oracle 数据库的一种灾难恢复和数据保护解决方案。它通过在主数据库和一个或多个备用数据库之间实时复制数据，提供了数据的冗余备份和故障切换功能。DG 主要用于灾难恢复，可以在主数据库发生故障时快速切换到备用数据库，保证业务的连续性和数据的安全性。
5)ADG（Active Data Guard）是在 DG 基础上增加了一些额外的功能，可以在备用数据库上提供只读访问。与传统的备用数据库不同，ADG 可以在备用数据库上打开数据库实例，并允许用户对备用数据库进行只读查询和报表生成，而不会影响主数据库的性能。ADG 可以充分利用备用数据库的资源，提供更高的可扩展性和负载均衡能力。同时，ADG 也可以作为备用数据库，当主数据库发生故障时可以切换到 ADG。
总结：
DG 是一种基本的灾难恢复和数据保护解决方案，可以在主备数据库之间复制数据，用于快速切换和恢复。
DG时代的数据同步方式如采用Redo Log的物理方式，则数据库同步数据快、耗用资源低，但存在一个大问题。Oracle 11G以前的Data Guard物理备份数据库，可以以只读的方式打开数据，但这时日志的数据同步过程就停止了。而如果日志的数据同步处于执行过程中，则数据库就不能打开。也就是日志读、写两个状态是互相排斥的。而Active Data Guard则是主要解决这个问题。
ADG 在 DG 的基础上增加了只读访问功能，可以在备用数据库上执行只读查询和报表生成，提高整体系统的性能和可用性。ADG主要解决了DG时代读写不能并行的问题。
二、数据定时同步技术
2.1.DataX定时同步
2.1.1.技术介绍
DataX数据融合工具，是由阿里自由研发的数据同步软件，名字由阿里自主命名。支持大数据量高并发同步，提供高效便捷的数据清洗及安全加密性数据传输保障。为客户灵活的数据消费提供强有力的技术驱动。产品支持多种RDBMS数据源及多种NOSQL目标库集群，支持大规模的数据集成。支持单字段DES、SHA-1等数据加密，数据传输过程保证在单进程或者多线程内完成，传输过程全内存操作，不读写磁盘，也没有IPC，支持分布式任务性调度，可灵活自定义cron表达式，具有对业务系统库实现全量，增量数据同步等特点，也可以自定义限流，限速，降低业务系统的影响。完善的纠错机制与系统运行态监测，能对同步过程迅速预警。高质量体系保障数据传输的安全性，支持混合云，私有化的部署。

DataX是一款离线数据同步工具，实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、Sysbase、DB2、达梦、mongo 等各种异构数据源之间高效的数据同步功能。 DataX将不同数据源的同步抽象为从源头数据源读取数据的Reader插件，以及向目标端写入数据的Writer插件，理论上DataX框架可以支持任意数据源类型的数据同步工作。同时DataX体系作为一套生态系统, 每接入一套新数据源该新加入的数据源即可实现和现有的数据源互通。

1)Reader：Reader为数据采集模块，负责采集数据源的数据，将数据发送给Framework。
2)Writer： Writer为数据写入模块，负责不断向Framework取数据，并将数据写入到目的端。
3)Framework：Framework用于连接reader和writer，作为两者的数据传输通道，并处理缓冲，流控，并发，数据转换等核心技术问题。
2.1.2.支持的数据库范围
类型 数据源 Reader(读) Writer(写) 文档
RDBMS 关系型数据库 MySQL √ √ 读 、写
Oracle √ √ 读 、写
OceanBase √ √ 读 、写
SQLServer √ √ 读 、写
PostgreSQL √ √ 读 、写
DRDS √ √ 读 、写
Kingbase √ √ 读 、写
通用RDBMS(支持所有关系型数据库) √ √ 读 、写
阿里云数仓数据存储 ODPS √ √ 读 、写
ADB √ 写
ADS √ 写
OSS √ √ 读 、写
OCS √ 写
Hologres √ 写
AnalyticDB For PostgreSQL √ 写
阿里云中间件 datahub √ √ 读 、写
SLS √ √ 读 、写
图数据库 阿里云 GDB √ √ 读 、写
Neo4j √ 写
NoSQL数据存储 OTS √ √ 读 、写
Hbase0.94 √ √ 读 、写
Hbase1.1 √ √ 读 、写
Phoenix4.x √ √ 读 、写
Phoenix5.x √ √ 读 、写
MongoDB √ √ 读 、写
Cassandra √ √ 读 、写
数仓数据存储 StarRocks √ √ 读 、写
ApacheDoris √ 写
ClickHouse √ √ 读 、写
Databend √ 写
Hive √ √ 读 、写
kudu √ 写
selectdb √ 写
无结构化数据存储 TxtFile √ √ 读 、写
FTP √ √ 读 、写
HDFS √ √ 读 、写
Elasticsearch √ 写
时间序列数据库 OpenTSDB √ 读
TSDB √ √ 读 、写
TDengine √ √ 读 、写
2.1.3.核心模块介绍
1)DataX完成单个数据同步的作业，我们称之为Job，DataX接受到一个Job之后，将启动一个进程来完成整个作业同步过程。DataX Job模块是单个作业的中枢管理节点，承担了数据清理、子任务切分(将单一作业计算转化为多个子Task)、TaskGroup管理等功能。
2)DataXJob启动后，会根据不同的源端切分策略，将Job切分成多个小的Task(子任务)，以便于并发执行。Task便是DataX作业的最小单元，每一个Task都会负责一部分数据的同步工作。
3)切分多个Task之后，DataX Job会调用Scheduler模块，根据配置的并发数据量，将拆分成的Task重新组合，组装成TaskGroup(任务组)。每一个TaskGroup负责以一定的并发运行完毕分配好的所有Task，默认单个任务组的并发数量为5。
4)每一个Task都由TaskGroup负责启动，Task启动后，会固定启动Reader—>Channel—>Writer的线程来完成任务同步工作。
5)DataX作业运行起来之后，Job监控并等待多个TaskGroup模块任务完成，等待所有TaskGroup任务完成后Job成功退出。否则，异常退出，进程退出值非0。
2.1.4.技术优点
1)稳定性 。DataX采用了分布式架构，可以将数据同步任务分配到多个节点上执行，从而提高了数据同步的效率和稳定性。
2)高效性 。DataX每一种读插件都有一种或多种切分策略，都能将作业合理切分成多个Task并行执行，可以让DataX速度随并发成线性增长。
3)可扩展性 。DataX提供了丰富的插件机制，可以方便地扩展支持新的数据源和数据目的地。
4)易用性 。DataX的配置非常简单，只需要按照指定格式编写配置文件即可完成数据同步任务的配置。
2.1.5.技术缺点
1)需要人工配置同步任务 ，不具备自动化能力。
2)基于查询获取数据的方式，慢查询会使数据库服务器变得更慢，并且导致其他查询的执行速度变慢，查询响应时间的增加会使整个系统的性能减慢。
3)基于查询获取数据的方式，无法直接感知到源表删数据的操作。
4)基于查询获取数据的方式，超出查询范围的数据变更无法感知到。
2.2.ETL定时同步
2.2.1.技术介绍
ETL是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，因而也称为数据仓库技术。其目的是将分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。

1)提取（Extract）：提取是从数据库中读取/提取信息的过程。在此阶段，从多个或不同类型的来源收集数据。具体的步骤分为以下三步：
a.确定数据源，需要确定从哪些源系统进行数据抽取。
b.定义数据接口，对每个源文件及系统的每个字段进行详细说明。
c.确定数据抽取的方法：是主动抽取还是由源系统推送？是增量抽取还是全量抽取？是按照每日抽取还是按照每月抽取？
2)转换（Transform）：转换是将提取的数据从之前的形式转换为所需形式的过程。数据可以放入另一个数据库。可以通过使用规则或查找表或将数据与其他数据组合来进行转换。数据转换一般包括两类：第一类：数据名称及格式的统一，即数据粒度转换、商务规则计算以及统一的命名、数据格式、计量单位等；第二类：数据仓库中存在源数据库中可能不存在的数据，因此需要进行字段的组合、分割或计算。主要涉及以下几个方面：
a.空值处理：可捕获字段空值，进行加载或替换为其他含义数据，或数据分流问题库。
b.数据标准：统一元数据、统一标准字段、统一字段类型定义。
c.数据拆分：依据业务需求做数据拆分，如身份证号，拆分区划、出生日期、性别等。
d.数据验证：时间规则、业务规则、自定义规则。
e.数据替换：对于因业务因素，可实现无效数据、缺失数据的替换。
f.数据关联：关联其他数据或数学，保障数据完整性。

3)加载（Load）：加载是将数据写入目标数据库的过程。将经过清洗后的干净的数据集按照物理数据模型定义的表结构装入目标数据仓库的数据表中，如果是全量方式则采用LOAD方式，如果是增量则根据业务规则MERGE进数据库，并允许人工干预，以及提供强大的错误报告、系统日志、数据备份与恢复功能。整个操作过程往往要跨网络、跨操作平台。ETL是数据集成的第一步，也是构建数据仓库最重要的步骤，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为并为数据存储、数据分析和机器学习做好准备，进而为企业的决策提供分析依据。
2.2.2.同步分类
1)全量同步：将全部数据抽取到目标系统中，一般用于数据初始化装载。
2)增量同步：检测数据变动，只抽取发生变动的数据，一般用于数据更新。
2.2.3.应用场景
1)多源数据整合：企业通常有多个数据源，包括数据库、文件、应用程序等，ETL能够将这些分散的数据整合在一起，为企业提供全面且一致的数据视图。
2)数据清洗与质量控制：ETL可以清洗和验证数据，排除重复、不完整或不准确的数据，提高数据的质量和可靠性。
3)支持企业决策：通过将多个数据源中的数据整合起来，ETL可以为企业提供准确的决策支持信息，且现在的ETL愈发更加注重实时数据处理能力，能够对流式数据进行实时抽取、转换和加载，使得企业和个人能够及时获得最新的数据洞察，并做出实时决策。
4)优化业务流程：ETL将数据从不同系统中抽取出来，并进行转换和加载，可以实现数据在不同系统之间的流动，优化业务流程，提高企业的效率和竞争力。
5)数据安全与隐私保护：ETL工具和平台将加强数据加密、访问控制和匿名化等技术手段，确保数据在抽取、转换和加载的过程中得到充分的保护，同时遵守相关的法规和隐私规范。
6)赋能企业员工数据处理和分析能力：掌握ETL技术可以使个人具备处理和分析大规模数据的能力。在当今数据驱动的时代，数据处理和分析已成为许多职业领域的核心需求，如数据科学家、业务分析师、市场营销人员等。ETL的知识和技能使个人能够有效地抽取、转换和加载数据，为数据分析和洞察提供基础。
7)数据备份和迁移：ETL可以将数据从一个系统迁移到另一个系统中。
2.2.4.常见配套的应用工具

结构化数据ETL工具：
1)Sqoop：大数据领域很常见的一种ETL工具，主要职责是把结构化数据库提供JDBC连接上去之后进行数据抽取，使用并发处理的形式批量导入到大数据的数据仓库中。缺点是对国外的主流关系型数据库支持性更好，而且2.X版本改造后性能下降。
2)Kettle：一个传统的可视化ETL工具，开源免费。缺点是面对特别复杂的业务逻辑，受制于组件的使用情况。
3)Datastage：IBM阿里开发的一款ETL工具，具有良好的跨平台性和数据集成能力，提供了可视化的ETL操作界面。缺点是价格远高于其他的ETL工具，而且需要占用较高的系统资源和硬盘空间。
4)Informatica：一款易于配置和管理，能够快速实现ETL任务的ETL工具。缺点和Flume一样，价格高，占用空间大。
5)Kafka Connect：一个分布式流处理平台，也可以用作ETL工具，具有高吞吐量和低延迟性，但是开发和使用成本较高。而且Kafka的使用场景主要是数据流处理领域，不适合复杂的数据清洗和转换操作。
非结构化/半结构化数据ETL工具：
1)Flume：支持数据监控，在大数据平台上部署简单，亿级以上大数据同步性能较好。缺点是没有可视化界面，只能通过后台命令操作，并且不支持扩展开发，功能少，不支持数据清洗处理。
2)FineDataLink：帆软推出的一款可视化ETL工具，具有ETL和ELT两种数据处理方式，操作简单，功能丰富，支持三十多种格式和结构的异构数据源。
3)Logstash：一个开源的ETL工具，主要用于数据采集和转换。支持插件式架构、多个数据格式和编码。缺点是存在性能问题，不适合处理大量数据。而且配置复杂，不易于维护。
2.2.5.技术优点
1)数据同步效率高 。ETL可以将数据从不同的数据源中提取、转换和加载到目标数据库，实现数据的集中存储和管理，从而提高数据同步效率。
2)数据清洗和整合能力较强 。ETL工具可以通过预设的规则和模板，对不同数据源的数据进行清洗和整合，从而保证数据的准确性和一致性。
3)可扩展性强 。ETL工具可以支持多种不同的数据源和目标数据库，可以方便地扩展数据同步的范围和规模。
4)维护性和使用性较好 。ETL工具提供了友好的用户界面和图形化工具，方便用户进行配置、管理和监控，同时也可以提供灵活的数据转换和映射功能。
2.2.6.技术缺点
1)要求业务表建立触发器，对业务系统有一定的影响，容易对源数据库构成威胁。
2)时间戳维护需要由业务系统完成，对业务系统也有很大的侵入性，特别是对不支持时间戳自动更新的数据库，还要求业务系统进行额外的更新时间戳操作。
3)无法捕获对时间戳以前数据的delete和update操作，在数据准确性上受到了一定的限制。