数据传输:同构异IP数据源批量抽取实践

本文介绍了同构异IP数据源的概念及其在数据传输中的挑战,包括数据源扩展性和任务创建繁琐等问题。通过数据传输产品的逻辑数据源功能,实现了高效的任务创建和扩展,支持自动匹配库表,简化了分库分表数据抽取到数据仓库的过程。

小科普:

什么是同构异IP数据源? 指的是库表结构一致、IP不同的多个 数据源;

同构异IP数据源的数据特征:数据源类型相同、IP不同、库表名称符合特定规律、表结构一致。

由于使用场景、业务形态、技术选型、开发架构的差异,在企业中往往存在多套不同的软硬件平台上的信息系统。这些不同来源的数据之间彼此独立、相互封闭,使得数据难以在业务系统间进行互联互通和信息共享,从而形成了信息孤岛。然而,随着信息化应用的不断深入,企业内部、企业与外部信息互通的需求日益强烈,亟需联通信息孤岛,实现数据的互通和共享。由此,数据传输产品应运而生,用于实现多种异构数据源之间的数据交换,帮助数据从业务系统同步进入数据仓库。

数据传输产品致力于提供丰富异构数据源之间数据交换的能力,采用分布式的架构,可实现各部门业务数据在应用层面的互联互通和信息共享,可以从容应对大数据量的数据传输需求。本文主要围绕同构异IP数据源批量抽取的业务场景,针对目前存在的业务痛点,结合实践案例介绍数据传输产品的产品解决方案。

1

业务场景

(1)随着业务的飞速发展,业务系统的数据量也在高速增长,需要系统具备灵活的扩展能力和高并发大数据量的处理能力。针对这个业务应用场景,业内部分的数据库系统如MySQL等提供了分布式分库分表的方案,通过减小单表的数据量来解决这个问题。分库分表的数据特征为:表结构一致,复杂场景下会分布存储在跨IP的多个库的多张表中。数据开发需要把分库分表的数据定期抽取到数仓Hive表。

(2)很多大型企业通常会在不同的地域设立分公司。各分公司的业务数据会按照公司的统一格式存储在各自的业务系统,各分公司的业务数据库的数据特征为:数据源类型相同、IP不同、库表名称符合特定规律、表结构一致。数据开发需要把分散在各个业务系统的数据定期抽取到总公司指定的数据库表用于后续经营分析。

2

业务痛点及产品解决方案

痛点1:创建任务操作繁琐

如果每个任务仅支持抽取单表,需要创建大量任务,任务维护极其困难。进一步来讲,即便已支持在同一任务中手工添加多个分库分表,但每次创建任务时,仍需要数据开发手工一个一个反复添加数据源,效率低,而且容易出错。

解决方案:支持登记逻辑数据源,一个逻辑数据源可以关联多个物理数据源,可以选择基于逻辑数据源创建传输任务,每次创建任务,只需要选择一个逻辑数据源即可。

痛点2:扩展性问题

如果分库分表下的数据源或库表增加时,每一个任务都需要去调整并重新提交上线,效率低,极易产生事故。

解决方案:每次扩展数据源,只需要在逻辑数据源下新增物理数据源即可,不需要修改任务。任务上支持通过库/表的正则表达式的方式,自动匹配对应的库表。

3

实践案例

3.1 需求场景

业务数据按分库分表分布在400张表中,具体来说:4个同构异ip数据源中,每个数据源下分别有10个库,每个库下分别有10张表,每张表中有100条记录。

库名和表名的命名特征如下:设m∈{1,2,3,4},n∈{0,1,2,3,4,5,6,7,8,9},l∈{0,1,2,3,4,5,6,7,8,9}

数据源名称为:physical_mysqlm

库名为:ndi_m_n

表名为:t_sharding_m_n_l

需要每天读取4个MySQL数据源下所有分库分表的全量数据,并覆盖写入Hive表。数据源名称、数据库名称库、表名称示例如下:

表结构如下:

3.2 实践操作步骤

3.2.1 登记逻辑数据源

登记MySQL逻辑数据源,逻辑数据源名称:logic_distmysql。

在该逻辑数据源下,添加已登记的4个物理数据源:physical_mysql_1、physical_mysql_2、physical_mysql_3、physical_mysql_4。

保存成功后,可在数据源列表页查看逻辑数据源详情,确认无误后请前往数据传输。

3.2.2 创建数据传输任务

3.2.2.1 选择数据来源与去向

数据来源与去向配置如下:

step1:选择数据来源

(1)点击切换按钮切换为逻辑数据源模式,选择数据源类型:MySQL,并选择已登记的逻辑数据源:logic_distmysql。

(2)填写库名的正则表达式:ndi_\d+_\d,填写表名的正则表达式:t_sharding_\d+_\d+_\d。

正则匹配的结果预览如下:

step2:选择数据去向

  • 选择数据源类型:Hive,数据源名称:poc-建德十 Hive数据源

  • 选择库名:demo,表名:logicdist

  • 选择写入规则:insert overwrite

3.2.2.2 配置字段映射

字段映射默认为同名映射,配置如下:

3.2.2.3 保存任务

成功保存任务后,即可在任务列表查看任务。目前传输任务默认按照最近修改时间降序排序,如果创建任务后未找到创建的任务,可以输入任务名称搜索。

3.2.3 试运行任务,试运行成功后创建离线开发任务

3.2.3.1 试运行任务

3.2.3.2 运行成功后前往自助分析验证写入结果

前往自助分析验证结果,Hive表中的remark字段内容为来源表表名。输入SQL语句:

select count(id),remark from demo.logicdist
group by remark

3.2.3.3 自助分析结果验证无误后,创建离线开发任务

3.2.4 离线开发任务提交调度

离线开发任务提交上线并配置调度后,每次任务执行时,将对当前逻辑数据源下所有数据源的所有库表进行正则匹配,读取库名和表名均符合正则表达式的所有表。

3.2.5 扩展处理:分库分表扩展时,需要怎么处理?

(1)如果物理数据源下新增库或新增表,无需额外处理

每次任务运行时,会按照库表名称的正则表达式,对逻辑数据源下所有物理数据源的库表(含新增库表)进行正则匹配。

(2)如果新增物理数据源,需在已登记的逻辑数据源下新增物理数据源

如果登记的逻辑数据源下新增物理数据源,需在已登记的逻辑数据源下新增物理数据源,无需修改数据传输任务。任务运行时会对逻辑数据源下所有物理数据源(含新增物理数据源)的库表进行正则匹配。

好啦,以上就是本次的产品实践案例,希望对你在工作中能有所帮助。如有疑问,欢迎评论区留言~

<think>我们正在讨论跨数据库实时同步的实现方案。根据引用内容,我们可以总结几种常见方法: 1. 数据库复制(如SQL Server的事务发布) 2. Always On可用性组(SQL Server的高可用方案) 3. ETL工具(用于数据抽取、转换和加载) 4. 专用同步工具(如HKROnline SyncNavigator) 5. 基于日志的同步(如canal) 用户要求的是跨数据库实时同步,因此我们需要关注能够实现实时或近实时同步的方法。 ### 实现跨数据库实时数据同步的常见方法 #### 1. 数据库原生复制技术(如SQL Server事务发布) 引用[1]和[2]提到了SQL Server的事务发布。这种方法通过发布-订阅模型实现数据同步: - 在源数据库(发布服务器)上设置发布(Publication),选择要同步的表和操作(插入、更新、删除)。 - 在目标数据库(订阅服务器)上创建订阅(Subscription),可以是推送订阅或请求订阅。 - 事务日志读取器代理会读取源数据库的事务日志,并将更改传播到目标数据库。 **优点**: - 实时性较好(通常延迟在秒级)。 - 支持构目标(如SQL Server到Oracle,但需要额外的配置或组件)。 - 内置于数据库系统中,稳定性高。 **缺点**: - 配置复杂,需要较高的数据库管理技能。 - 对源数据库性能有一定影响(因为需要读取事务日志)。 - 跨不同数据库厂商(如MySQL到SQL Server)可能需要额外的中间件。 #### 2. 基于日志的同步工具(如Canal) 引用[4]提到了canal,它是阿里巴巴开源的MySQL数据库增量日志解析和同步工具。其原理是: - 模拟MySQL slave的交互协议,伪装成MySQL的从库。 - 向MySQL主库发送dump协议,获取binlog日志。 - 解析binlog日志,将变更事件转发给下游(如消息队列、其他数据库等)。 **优点**: - 实时性强(几乎实时)。 - 对业务系统侵入小(只需读取binlog,不影响主库写入)。 - 支持多种目标存储(如MySQL、Oracle、Elasticsearch等)。 **缺点**: - 主要支持MySQL(其他数据库需要类似工具,如Debezium for PostgreSQL, Oracle等)。 - 需要维护中间件(canal server/adapter)和消息队列(如Kafka)以确保可靠传输。 #### 3. 专用同步软件(如HKROnline SyncNavigator) 引用[2]提到了一款商业软件,它提供图形化界面和简单的配置: - 设置源数据库和目标数据库的连接信息。 - 选择需要同步的表和字段。 - 支持增量同步和断点续传。 **优点**: - 操作简单,无需编写代码。 - 支持数据库(如SQL Server到MySQL)。 - 提供监控和管理界面。 **缺点**: - 商业软件需要购买。 - 定制能力可能受限。 #### 4. ETL工具(如Talend, Informatica, Kettle) 引用[1]提到ETL工具可以实现复杂的数据同步流程: - 通过定时任务或事件触发数据抽取。 - 在内存或中间存储中进行数据转换。 - 加载到目标数据库。 **实时性改进**: - 结合CDC(Change Data Capture)技术,可以实现近实时同步(例如每分钟同步一次)。 **优点**: - 功能强大,支持复杂转换。 - 支持多种数据源和目标。 **缺点**: - 实时性不如前几种方法(除非使用CDC增强)。 - 配置复杂,资源消耗较大。 #### 5. 消息队列中间件(如Kafka Connect) 利用消息队列的分布式特性: - 使用Kafka Connect连接源数据库(通过source connector)捕获变更。 - 将变更事件写入Kafka主题。 - 通过sink connector将变更事件应用到目标数据库。 **优点**: - 高吞吐量,适合大数据量场景。 - 支持多种数据源和目标(有丰富的connector生态系统)。 - 提供持久化和重试机制,保证可靠性。 **缺点**: - 系统架构复杂,需要维护Kafka集群。 - 可能需要开发自定义connector。 ### 选择建议 1. **同构数据库(如SQL Server到SQL Server)**:优先考虑数据库原生复制(事务发布)或Always On可用性组。 2. **数据库(如MySQL到SQL Server)**:考虑使用基于日志的工具(canal/Debezium)或专用同步软件。 3. **需要高可靠性和扩展性**:采用消息队列方案(Kafka Connect)。 4. **简单易用**:选择专用同步软件(如SyncNavigator)。 5. **需要数据转换**:使用ETL工具结合CDC。 ### 实施步骤(以canal为例) 1. **源数据库配置**: - 开启MySQL的binlog(设置`log-bin`和`binlog_format=ROW`)。 - 创建canal用户并授权。 2. **部署canal server**: - 下载canal.deployer,修改配置文件(`conf/example/instance.properties`)指向源数据库。 3. **部署canal adapter**: - 配置数据源映射(源表到目标表),支持不同数据库类型。 4. **启动服务**: - 启动canal server和adapter,监控同步状态。 ### 注意事项 - **数据一致性**:确保同步过程是幂等的,避免重复执行导致数据错误。 - **性能影响**:监控源数据库的性能,尤其是开启binlog和大量数据变更时。 - **网络延迟**:跨机房同步需考虑网络延迟和带宽。 ### 相关问题 1. 如何监控跨数据库同步的延迟和数据一致性? 2. 在同步过程中出现数据冲突如何处理? 3. 如何实现双向同步(双主)? 4. 如何优化大规模数据实时同步的性能?</think>### 跨数据库实时数据同步的实现方案 实现跨数据库实时数据同步的核心是捕获源数据库的变更事件(如增删改),并实时应用到目标数据库。以下是主流解决方案及实施步骤: --- #### 一、主流技术方案 1. **基于数据库日志的同步(推荐)** **原理**:解析数据库事务日志(如 MySQL binlog、SQL Server CDC),捕获增量变更。 **工具**: - **Canal**[^4]:专为 MySQL 设计,伪装成从库读取 binlog,支持同步到数据库(如 SQL Server、Oracle)。 - **Debezium**:支持多种数据库(MySQL、PostgreSQL 等),通过 Kafka 中转数据,实现解耦。 **优点**:实时性强(毫秒级延迟)、对源库性能影响小。 **缺点**:需开启数据库日志功能,配置较复杂。 2. **数据库原生复制技术** - **SQL Server 事务发布**[^2]: ```sql -- 1. 在源库创建发布 EXEC sp_addpublication @publication = 'SyncPub'; EXEC sp_addarticle @publication = 'SyncPub', @article = 'dbo.Table1'; -- 2. 在目标库创建订阅 EXEC sp_addsubscription @publication = 'SyncPub', @subscriber = '目标服务器'; ``` **特点**:内置于 SQL Server,支持跨服务器同步,但仅限 SQL Server 同构环境。 - **Always On 可用性组**[^1]:适用于 SQL Server 高可用集群,实时同步副本,但配置复杂且成本高。 3. **ETL 工具 + CDC(变更数据捕获)** - **工具**:Apache NiFi、Talend、StreamSets。 - **流程**: ```mermaid graph LR A[源数据库] -->|CDC 捕获变更| B(Kafka/消息队列) B --> C{ETL 工具} C -->|转换数据| D[目标数据库] ``` **适用场景**:需数据清洗或转换的构库同步(如 MySQL → SQL Server)。 4. **专用同步软件** - **SyncNavigator**[^2]:支持数据库(MySQL/Oracle/SQL Server 互同步),图形化配置,增量同步。 - **阿里云 DTS**:云服务商提供的全托管方案,适合云端数据库。 --- #### 二、实施步骤(以 Canal 同步 MySQL → SQL Server 为例) 1. **源库(MySQL)配置**: - 开启 binlog: ```ini [mysqld] log-bin=mysql-bin binlog_format=ROW ``` - 创建 Canal 用户: ```sql CREATE USER 'canal'@'%' IDENTIFIED BY 'canal'; GRANT SELECT, REPLICATION SLAVE ON *.* TO 'canal'@'%'; ``` 2. **部署 Canal Server**: - 下载 Canal,修改配置 `conf/example/instance.properties`: ```properties canal.instance.master.address=源库IP:3306 canal.instance.dbUsername=canal canal.instance.dbPassword=canal ``` 3. **部署 Canal Adapter**: - 配置目标库(SQL Server)连接: ```yaml dataSources: target_db: url: jdbc:sqlserver://目标IP:1433;databaseName=test username: sa password: 123456 ``` - 定义同步规则(`conf/rdb/mytest.yml`): ```yaml destination: example outterAdapterKey: target_db mapping: - sourceTable: test.user # MySQL 表 destinationTable: dbo.users # SQL Server 表 ``` 4. **启动与验证**: - 依次启动 Canal Server 和 Adapter。 - 在 MySQL 更新数据,观察 SQL Server 是否实时同步。 --- #### 三、关键注意事项 1. **数据一致性**: - 使用事务保证原子性(如 Canal 支持批量提交)。 - 定期校验 MD5 或行数(如 pt-table-checksum for MySQL)。 2. **性能优化**: - 批量写入:调整 Adapter 的 `commitBatch` 参数减少 IO。 - 网络压缩:跨机房同步启用 TLS 和数据压缩。 3. **高可用**: - Canal 部署多节点 + ZooKeeper 选主。 - 消息队列缓冲(如 Kafka),避免数据丢失。 --- #### 四、方案对比 | **方案** | 实时性 | 构支持 | 复杂度 | 适用场景 | |-------------------|----------|----------|--------|------------------------------| | **Canal/Debezium**| 毫秒级 | 是 | 高 | MySQL/Oracle 等日志完整场景 | | **事务发布** | 秒级 | 否 | 中 | SQL Server 同构环境 | | **ETL + CDC** | 分钟级 | 是 | 高 | 需数据清洗的复杂同步 | | **SyncNavigator** | 秒级 | 是 | 低 | 中小规模,快速实现 | > 💡 **建议**: > - 同构数据库用**事务发布**(SQL Server)或**binlog同步**(MySQL)。 > - 数据库选 **Canal+Adapter** 或 **Debezium+Kafka**。 > - 云环境优先用 **DTS/RDS 数据同步**服务。 --- ### 相关问题 1. 如何监控数据同步的延迟和状态? 2. 同步过程中出现主键冲突或数据不一致如何解决? 3. 超大规模数据(TB级)实时同步有哪些优化策略? 4. 开源工具 Canal 与商业版 Otter 有何区别? [^1]: 数据库备份和还原、数据库复制、Always On 可用性组等方法的优缺点比较。 [^2]: SQL Server 事务发布和 SyncNavigator 工具的实现原理。 [^3]: 百万级商品数据实时同步的业务需求和技术挑战。 [^4]: Canal 实现库多表同步的配置架构。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值