2019年年初，我接到了一个神秘电话，电话那头竟然准确的说出了我的昵称：上海小胖。
我想这事情不简单，就回了句：您好，我是小胖，请问您是？
“我就是刚刚加了你微信的 xxx 啊”
哦……他只是把我的微信昵称报出来了……
随着深入沟通，了解到对方是某央企保密单位的大数据部门技术负责人，因为目前整个集团在进行数字化转型。在决策过程中，遇到了几个阻力。
首先，大部分部门和科室的数据基础还很薄弱，存在数据标准混乱、 数据质量层次不齐、各条块之间数据孤岛化严重等现象，阻碍了数据的共享应用。
其次，受限于数据规模和数据源种类的丰富程度，多数企业的数据应用刚刚起步，主要集中在精准营销，舆情感知和风险控制等有限场景，应用深度不够，应用空间亟待开拓。
再次，由于数据的价值很难评估，企业难以对数据的成本以及其对业务的贡献进行评估，从而难以像运营有形资产一样管理数据资产。
而这位技术负责人本着认真、负责、专研的精神，死磕大数据领域，试图在市面上找到一款能够满足他需求的产品，帮助他解决数据痛点。
经过沟通，了解到目前的企业数据现状是：
数据散落在各部门科室，8大部门共50+科室
数据量非常大，高峰期每小时可产生100GB数据，每天存量数据 1TB
数据类型丰富，包括：
关系型数据库：Oracle，MySQL，PostgreSQL，GBase，GauseDB等
非关系型数据库：MongoDB
结构化文件：XML，Excel，CSV，TXT
非结构化文件：音频，视频，pdf
每个月都会有 5 个新项目，而每次对接新项目都需要花费 1-3个月时间在数据对接上
项目周期长，而大多数时间都在数据冗余、清洗、过滤上
多副本数据带来的数据维护成本也在不断增加，影响了研发进度
考虑迁移在坚定不移的执行数字化转型战略，打赢传统数据组织转向大数据生态的攻坚战中，技术负责人悟出了一个道理，要打赢这场硬仗，必须得做数据整合！
要做数据整合，那不就是传统数据仓库和数据湖吗？在技术负责人经过一番市场调研后发现，数据仓库和数据湖都无法满足他心中的未来大数据架构。
那是什么样的数据架构无法满足呢？面向应用开发的共享数据
简而言之就是，数据仓库和数据湖无法做即时交付，目前的应用场景还是如上文提到的：应用深度不够，应用空间亟待开拓。
经过几番调研后，技术负责人找到一款产品Tapdata，用他的原话说就是：“这款产品的理念很先进，可以说和我的想法不谋而合。”
扩展开来说就是：
通过数据同步完成数据汇聚、采集工作
通过数据发布对外提供数据服务
通过数据治理对数据资产进行有效管理
而最重要的是数据是可被重复使用，可实时交付的。
解决方案 架构Tapdata 的数据同步工具，只需要简单的拖拉拽，就可以完成多源数据库的同步。同时依赖于灵活的 js 脚本能力，对复杂的 ETL 场景也可以非常轻松搞定。
那这里就上一个当时给技术负责人就他们企业现状做的架构图，因为本篇文章是在讨论数据迁移，所以我就给出数据同步的架构图。
整个架构采取 mongodb 分片集群作为底层存储，使用数据同步工具将多源数据实时抽到 mongodb 中，在抽取过程中完成数据清洗、过滤。
技术实现在使用数据同步工具做数据迁移的时候，需要和用户沟通具体场景，比如：
本次目标是一次性数据导入，还是需要之后保持增量同步
数据迁移中有没有复杂的ETL场景
对同步延时要求
同步的数据量预估，高峰预估
在明确目标和需求后，我们采取了多节点分布式采集的方式来满足应用高峰时产生的数据量，根据当时预估高峰每小时 100GB，一天存量 500GB 计算。
通过数据工具将不同的数据源，通过任务编排的方式进行组合，完成数据清理工作。
用户本次数据同步要求更多是在数据同步性能及数据量上，对数据的ETL没有过多的要求，都是一些简单的字段重命名，字段类型转换
所以通过数据同步工具只需要 1 分钟即可完成从源端数据库到目标端 mongodb 的同步工作。
创建数据源