一、使用C/S的ETL软件进行短期的整库迁移
一般的数据库ETL过程用成熟工具较多，如kettle、oracle owb、quest公司（开发toad工具的公司）一个忘记名字的软件。如2期系统的历史数据导入到3期项目中，由于年代久远，两套系统的表、字段均有非常大的修改。整个数据迁移过程需要一个可视化、可批量执行、可保存任务、错误提示友好、效率较高的工具。经过测试，我们选用了开源的kettle。
kettle可以创建“作业”和“转换”。前者用于配置一个简单的迁移过程，包括数据源对象、目标对象和他们之间的映射关系。在转换过程中可以使用js脚本对源数据进行编辑（增、删、改等操作）然后再导入到目标对象中。迁移过程中的错误提示均为标准的java exception提示。“转换”可以将多个作业作为子环节逐一或同步并行执行。借助kettle工具，我们将总局2期所有数据平稳迁移到3期库中，并将迁移后的数据在3期新的业务应用系统上经过了用户测试。
二、开发B/S的类ETL可视化工具应对长期、可变的迁移需求
在目前的项目中，另有新需求是将录入库的信息定时按照一定的规则转移到新的审查库中，两个库表的数据结构有少部分不同指出。要求有页面可灵活配置导出导入、可以使用定时任务、便于修改，其实可以给予kettle做2次开发，但考虑到目前项目整体基于Flex+Java架构，页面组件使用Flex开发更方便。我们决定自己开发一套满足需求的B/S工具，所以有了“数据交换和共享系统”。该系统可以免除C/S软件的安装等缺点（虽然kettle是绿色的），可以在任意一个浏览器中对源数据对象、目标数据对象进行映射。大体思路是：
- 数据源导出在“模块管理”页面进行配置，可以配置源库的某一张表并筛选某些字段进行导出（同时支持HQL查询条件进行筛选），配置好之后持久化到库中，我们的quartz定时会来调用此任务，将数据导出成XML并打成zip包到一个之前配置好的目录、同时在此目录生成一个描述数据信息的tableStructure.xml。BLOB导出到临时文件夹，CLOB使用CDATA标签解决。
- 数据导入在“数据同步”页面进行配置，选择源数据存放路径（上面导出的zip包所在路径）读取tableStructure.xml在左下方用一个grid列出各个字段的信息。再配置要导入的数据源信息，然后查到目标表，选择目标表（一个或多个），右下方列出要被导入的表的各个字段信息。然后如同kettle，拖放源、目标字段，使得左右两侧字段映射好，将映射关系持久化到库中。导入支持外键导入、多表导入、简单HQL语句。
- 最后是调度管理，配置导出任务、导入任务quartz定时任务的cron表达式，进行“立刻执行”、“挂起”、“暂停”等操作。
除以上之外还有标签/标签集管理、日志记录、管理等功能。
三、使用oracle命令进行导出导入
我们自己开发的B/S软件满足了3期系统需求，但是对性能不满意。经过分析，性能瓶颈主要集中在XML操作上，读写XML（特别是写的时候）我们使用了dom4j，当数据量很大的时候我们采用了分为多个XML的策略。如配置成每个XML只导出1W条数据，一个zip包中打入多个xml。但是dom4j在写出每一个XML文件之前，这个xml的近万条数据的document是在内存中加载着并无法释放，当同一时间执行多个调度任务时就有大量的XML被操作，可能出现性能问题导致效率不高。可以通过quartz配置的时间错开、弃用dom4j，改用I/O流直接写文件等操作来优化。
除以上需求外oracle自带的SPOOL、SQLLOADER功能也非常强大，spool号称可以将亿级别的数据高效导出到文件中。可以将spool配合sql写到bat或shell脚本中，将数据导成文件，再写一个对应的导入脚本。定时任务中用应用程序来调用这些批处理，理论性能比基于xml交换的B/S系统高。缺点是没有可视化的导入导出配置，大量的数据交换需要写大量的脚本，维护性非常差【后来我考虑可以用页面简单配置，使用velocity模板生成导入导出脚本】。此外命令导出大数据量时，由于数据文件集中在一个文件中，好几G的数据文件需要写程序进行合理拆分才能加载，否则会内存溢出。
以上是在本项目中对ETL的一些看法，第一次在cnblog发文章，欢迎交流。