背景
因为不同业务的数据存储和利用需要不同，企业通常会将不同业务产生的数据别离存储在独立的数据库中。随着业务架构的一直调整，以及受开发过程的影响，原先离开存储的数据库逐步暴露出一些问题：1、数据扩散在不同的数据库实例上，造成独立的数据孤岛，难以实现数据的聚合剖析。传统的通过 MySQL 主从关系同步数据的形式，在 MySQL5.7 版本之前无奈建设多对一的增量同步关系。MySQL5.7 版本尽管推出了多源复制性能，但性能繁多，无奈进行不同库表间的映射，且配置过程简单，当源数量较多时容易出错。2、数据库分库分表之后存在多个数据库实例，难以再合并到对立的库表中。传统的数据库迁徙工具无奈解决合并过程中产生的数据抵触问题。3、数据量越来越大，在不影响业务的前提下很难调整数据库架构。在线批改字段类型或者字段名，要么受限于数据库性能，要么可能给业务带来较大影响而难以调整。
为此，UDTS 在数据传输的根底上，减少了数据集成服务，可实现多个数据源合并，买通数据孤岛以取得数据的对立视图，不便业务进行数据分析决策; 助力企业灵便调整业务架构，优化现有的数据库服务; 疾速实现分库分表合并、自定义抵触解决策略、不便业务构建数据看板。
一站式数据集成解决方案
多源数据聚合
针对数据库扩散，难以聚合的问题。UDTS 推出数据集成服务，可轻松帮忙用户实现多源聚合。单个工作可反对多达 10 个数据源聚合，同时可反对不同类型网络环境下的数据源，包含外网、内网以及专线。
举例: 假如当初有两个数据源，别离是 10.10.10.100:3306 和 10.10.10.120:3306，聚合模式如下图所示：
思考到大多数据源都承载着在线业务，为了防止多源聚合对线上业务的影响，UDTS 数据集成服务还反对针对每个数据源独立限速。
数据库合库合表
数据库合库合表通常存在以下难点:
- 数据库实例扩散；
- 数据可能存在抵触；
- 对不同的数据库须要不同的数据抵触解决办法。
针对以上这些问题，UDTS 数据集成服务在多源聚合的根底上，提供以下形式解决：
1、自定义根底数据
- 对于每个数据源，都可指定“是否保留指标库的原数据”，如果抉择“是”，在导入数据表时，会保留原有数据库表定义及数据。
- 而如果抉择了不保留数据，则在导入数据时，会依据映射规定先清理对应的表及其数据。
2. 主动解决数据抵触
在创立工作时可对每个数据源独立定义数据抵触解决策略，在数据集成时，可依据本人的数据抵触解决策略来解决抵触数据。以后提供“保留”与“替换”两种策略。
- 保留: 当数据发生冲突时，保留指标库中的原数据，而抛弃以后数据。
当应用保留规定时，导入数据应用 INSERT IGNORE INTO , 比方 INSERT IGNORE INTO table VALUES(1, “name”, 18)，当有反复数据时，保留原有的数据，新插入的数据会被疏忽。
- 替换: 当产生数据抵触时，应用新的数据替换指标库中原来的数据。
当应用替换规定时，导入数据应用 REPLACE INTO，比方 REPLACE INTO table VALUES(1, “name”, 18)，老的数据将会被新数据笼罩，集成工作中有多个子工作 (多个源往同一个指标数据库同步) 时，须要留神程序。
数据库架构调整
在开发的过程中，难免会遇到数据库改名、表变更等问题，但等到数据库架构要调整的时候，才发现累积了一堆“陈年旧债”。通过 UDTS 数据集成服务的全量 + 增量，不仅能够将全量数据按映射规定迁徙到指标库中，还可动静实现增量数据的库表名称的映射。
防止用户对数据源锁库锁表的担心，UDTS 数据集成服务还提供了 No Lock 模式，在此模式下数据集成服务运行的过程中不会对源库表进行任何的锁操作。
数据集成服务案例
1、数据脱敏
某教育企业，应用 UDTS 数据集成服务，将数据脱敏解决后，再交由外部其它部⻔进行数据分析，提取数据的无效价值。既防止了敏感数据透露危险，又帮忙企业更快、更精准的决策。
2、数据合并
某金融企业应用 UDTS 数据集成服务，将后期拆分后的数据库合并，不便进行后续的业务开发和剖析。
3、架构调整 某交友软件为了适应新的架构，通过 UDTS 数据集成服务对数据库 db 和 table 进行了从新调整，适应了新的环境。
架构的调整不仅仅是对现有数据库的改名，还依赖于存量数据的变更、增量数据的同步、业务的回滚等。
总结
总的来说，UDTS 数据集成服务带给企业的价值次要体现在以下三个方面：
- 多源数据聚合，数据合并，构建 BI 数据看板，提取数据价值；
- 同构数据整合，主动解决数据抵触。
- 数据库架构在线调整，晋升业务整体性能。
UDTS 数据集成服务目前正在收费公测期，欢送返回控制台开启体验～