如果你不想Delay又不想通宵盯着屏幕输出的话  请参考我的步骤 而且我也希望听到你的反馈和建议。


标准的DM在没有明确特殊需求以外 基本目的之一就是将一端的数据整合到另一端数据库中。不过根据过去的经验来看 这个过程中还是会出现一些其他的需求。比如

1. 过滤一部分数据。  有时候是过滤老数据 有时候是基于业务和安全考虑 只平移一部分经授权的数据

2. 内容转换 有时候Target端的业务系统的Schema可能和你的不太一样 比如枚举类型 有的喜欢0和1 有的喜欢T和F 有的枚举的更多 这个时候 最方便的就是用Kettle或其他ETL工具在转换的过程中做Mapiing


流程1 Schema对比

如果你有权利在DM阶段前期进行数据库设计的话 我指的是Target段的数据库Schema设计 这个时候两段数据库类型如果不一样的话 你可以用第三方工具进行Schema的平移 也可以手动来做设计 如果有tmp层的话 你可以在这个层面上的table设计上加大放宽Data Type的定义。


如果不是 Target端的技术人员或DBA已经把数据库Schema设计完毕 并且告诉你里面有数据而且也不同意授权给你修改Schema的时候。这个时候你需要做的就是把流程2提前进行。


流程2 数据抽样 Data Sample

这个步骤非常重要 你不认真做的话 中期就等着加班吧.

比如 在你ETL设计完毕以后 你可以找一张表随机抽取10到100条不等的数据 而实际情况是上你每张表都需要这么做.

然后将你抽取出来的随机数据 在目标段的tmp层进行插入和读取测试

测试的目的就是Data type是否一致, 是否有乱码导致失败。 我遇到过的一次就是 remark信息中含有法文字符 结果在转换的过程中直接报错。 读取测试是为了测试数据平移完毕以后 是否按正常格式来显示.


流程3 作业设计Job

这里牵扯到一个量化的标准 就是你的ETL-Server到底有多强! 我之前的案例是16G的Dell服务器 用Kettle-3.2.5 （后来4.0.4我也试了 一个操行 看来不是版本问题 或者说新版本没解决这个问题） 读取DB2/4000w左右的数据的时候频繁发生lost connection的事情，读取MySQL的时候更尿了，100w得左右就GameOver (后来测试过 应该是跨中美网络的问题 专跳HKG人民的网络以后就正常了！)


这个时候 需要调整的地方有两个

1. Source端的设置  比如TimeOut和max packages等等这些和数据批量读取有关的参数 如果是MySQL 建议从Slave去读 DB2的话就麻烦了  我不是专业的DB2的DBA 能调整的参数基本上是从Google上找到的。 随大流 其实说实话帮助不大

2. Job的调度 这个设置的效果最明显 比如分批. 之前那个4000w左右的表  我是按照数据维护时间字段来做的区分，按照季度来分，平均每季度(除当前季数据两较大以外)其余季度的数据都相对较少 ，total下来大致都保持在60w左右     速度和质量都还ok 后面就根据这个设计思路将其余129张表(千万级以上的只有20张左右)全部做完。


从设计到测试到运行耗时5天.