关于ETL引擎设计的一点感想

    做ETL已经不是第一次了，无论是EAI，EII，还是分布式计算，ETL好像都是其中不可或缺的一环。而ETL不但要处理不同数据库之间的差异，同时还要处理数据语义上的差异，一些时候还可能要牵扯一些业务逻辑。因此，每次做ETL几乎都需要重新来过。且ETL开发相对复杂。商业上也没有相对成熟的产品和中间件。往往成为项目的重点和难点。

   由于ETL并不是我的工作范围，只是近期才开始接收ETL的维护工作。对项目中老的ETL复杂的逻辑搞的头晕脑胀，总觉的什么地方不对，却一直无法指出老的架构到底错在那里。昨天晚上睡觉前，突然有所领悟。

   首先，ETL的工作宏观上来说，就2个步骤，数据抽取，数据写入。当然，其中可能还要牵扯到数据的清洗，转换等功能。但首先，最基本的功能是抽取，写入。以此为核心，使用微核模式。创建一个最小可用的ETL Server。

   其次，数据的清洗和转换工作，作为可选的步骤，以IOC模式进行配制化管理，如何处理，交由用户决定。

  接着，ETL Server，本质上讲ETL Server只是一个任务执行任务的平台，因此。尽量保持ETL Server的简化至关重要。只保留相应的启动，停止，增加任务，删除任务，查询状态等功能。

   第四，需要保留单独的调度模块。把任务调度和ETL Server进行解耦，分别保持独立。如何调度任务，交由定时模块来确定。ETL Server只是被动执行。（可使用Bridge模式，不过，不推荐，一个定义良好的接口足以）

   第五，线程的问题，由于在ETL中，处于性能的考虑，多线程几乎必不可免，应该由谁来进行线程的调度这是一个问题。当前，普遍的做法是由ETL Server来处理和分配线程。
            而我认为，ETL Server很难智能的判断那些需要使用线程，那些不使用线程更好。因此，是否使用线程交由用户决定，系统只提供相应的线程服务。把线程作为底层服务提供给用户，既可以保证线程调度的准确，同时兼顾了灵活性。
     当然，为了方便用户的使用，应当提供一些典型的模版类。

   第六，注意表示逻辑与ETL逻辑的分离，如果需要展现ETL工作状态，并提供状态查询功能。必须注意保证表现逻辑与ETL 的业务逻辑分离。这里可以使用Adapter模式来处理两者之间的差异。

     总的来说，开发一个好的ETL应该做到，表现逻辑与ETL逻辑分离，调度逻辑与ETL逻辑分离，单个任务处理逻辑与ETL逻辑分离，最终保持微核模式。

  好处:（1）逻辑清晰
           （2）每部分功能简单，易于维护
            （3）模块之间实现松耦合
            （4）易于做单元测试