公司楼下的咖啡店老板都知道，我们数据团队每周一早上都在干同一件事：人肉对数。MySQL 里的订单、Oracle 里的库存、本地机房里的一份 CSV，三套数据三个世界，每个人电脑里都躺着一个"同步脚本.v3.final"。我接手这个烂摊子之后，把这些全部迁到了 DataWorks 数据集成上。这篇是实操记录，包含选型对照、配置流程和四个我实际踩过的坑。
一、数据集成到底是个啥
一句话：它是一个稳定高效、弹性伸缩的数据同步平台，负责在复杂网络环境下的异构数据源之间搬数据。有两个边界要先说清楚，不然容易用错：
- 它只管"搬"——把可以抽象成逻辑二维表的数据从源端搬到目标端，本身不做 ETL 转换，清洗加工是后续数据开发的事；
- 它覆盖全链路网络场景——公网、VPC、高速通道、云企业网（CEN）都支持，跨阿里云账号、跨 Region、本地 IDC 接入都在射程内。
选同步方案就看三个维度组合，我把它整理成了表：
| 维度 | 选项 | 说明 |
|---|---|---|
| 同步时效 | 离线 | 周期性调度，小时/天级批量迁移 |
| 实时 | 捕获源端 CDC 变更日志，秒级延迟 | |
| 同步范围 | 单表 | 精细化字段映射，适合小表 |
| 整库 | 多张表一次迁完，自动建表 | |
| 分库分表 | 多张同结构表合并写入目标端单表 | |
| 数据策略 | 全量 | 迁所有历史数据，用于初始化数仓 |
| 增量 | 只迁新增和变更，离线靠增量字段，实时靠 CDC | |
| 全增量 | 首次全量后自动衔接增量，入仓最省事 |
我那三套数据的组合是：订单表走"实时 + 单表 + 全增量"，库存表走"离线 + 整库 + 全量"，历史归档 CSV 走"离线 + 单表 + 全量"。方案定了，配置反而简单。
二、实操流程：六步，卡点在第二步
官方流程是：配数据源 → 准备资源组并打通网络 → 建任务 → 调试 → 发布 → 运维。我翻译成实操语言：
- 配数据源。MySQL、Oracle、MaxCompute、OSS 这些都是预置模板，填连接串和账号就行；
- 资源组 + 网络连通。这一步是成败关键——数据源和资源组之间网络不通，任务必然失败，没有"重试一下就好了"的侥幸。本地 IDC 走专线或公网，云上走 VPC；
- 建任务。新手用向导模式，点选完成大部分配置；要参数化、动态列映射就上脚本模式（JSON）；
- 数据预览 + 试运行。先小数据量试跑，别一上来全量；
- 提交发布，进入 DAG 工作流，编排调度依赖；
- 运维：监控同步状态、设告警、按量调资源。
整库迁移有个细节很贴心：支持自动建表，单任务同步多张表，任务数量和资源消耗都下来了。
三、四个坑，都是我交过学费的
坑一：它会重复，你必须自己去重。 数据集成只保证至少一次传输（at least once），不保证精确一次（exactly-once）。也就是说，传输后数据可能重复，去重要靠目标端主键和能力兜底。我第一批同步完没做去重，报表金额虚高 3%，查了半天才发现是增量数据重复写入。
坑二：字段映射是暗雷区。 源端和目标端字段类型不兼容（比如源端 String、目标端 Integer）会直接中断或产脏数据；目标端类型最大值小于源端，还会静默截断精度。配置时逐字段核对，别信"看起来差不多"。
坑三：脏数据失败不回滚。 可以设脏数据阈值，超了任务失败退出。但注意：失败时已成功写入的数据不会回滚——批量写入机制，且不提供事务支持，回滚能力取决于目标端。所以我的习惯是目标表按分区重建，失败了整个分区重来，干净。
坑四：计费有三块，别只算一块。 资源组费用（任务执行依赖资源组，Serverless 资源组支持按需弹性伸缩、按量付费）+ 调度费用（离线/整库任务涉及调度运行）+ 公网流量费用（走公网传输才产生）。第一笔账单出来别懵。
四、安全与隔离：企业用的前提
标准模式工作空间默认开发/生产环境隔离，两套 MaxCompute 项目数据完全隔离、权限独立；配合数据分类分级、敏感数据识别、动态/静态脱敏，以及 RAM 细粒度权限和 STS 临时凭证，基本能满足合规要求。我迁的三套库里有一份用户手机号表，脱敏规则配好后，开发环境查询出来全是掩码，这点让我对"平台级方案"彻底改观。
五、什么情况别用它
单表单次拷贝，用 DTS 或 ossimport 更直接；只需要文件互传，OSSCLI 一条命令的事，不必兴师动众。数据集成的价值在"持续、多源、异构"——一次性的小活儿别往平台上搬。
如果你手上也有三套以上各自为政的数据源，可以去DataWorks 产品页看看，建议先拿一张最疼的表走一遍"离线整库"全流程，跑通了再上实时。一句话总结：数据集成解决的是"搬"的问题，而且搬得比人肉脚本稳——但重复、类型、脏数据这三个坑，它给你机制，不给你包办。
