好久没写博客了，不是自己偷懒，的确是没有时间哦。
最近项目组里想做一个ETL数据抽取工具，这是一个研发项目，但是感觉公司并不是特别重视,不重视不是代表它不重要，而是可能不会对这个项目要求太高，能满足我们公司的小需求就行，想从这个项目里衍生出更多的东西估计难。昨天领导让我写写自己的见解，今天写了点，不过说见解还真不敢，所以取了个名字叫建议了，今天把这个文档贴到自己博客里和大伙分享分享。
贴文档之前，我想很多朋友估计并不熟悉ETL，如果接粗过数据挖掘一定对ETL很熟悉了，ETL是数据挖掘里非常重要的一环，具体什么是ETL，大家看下面这段文字：
ETL(Extract-Transform-Load的缩写，即数据抽取、转换、装载的过程)作为BI/DW（Business Intelligence）的核心和灵魂，能够按照统一的规则集成并提高数据的价值，是负责完成数据从数据源向目标数据仓库转化的过程，是实施数据仓库的重要步骤。如果说数据仓库的模型设计是一座大厦的设计蓝图，数据是砖瓦的话，那么ETL就是建设大厦的过程。在整个项目中最难部分是用户需求分析和模型设计，而ETL规则设计和实施则是工作量最大的，约占整个项目的60%～80%，这是国内外从众多实践中得到的普遍共识。
ETL是数据抽取（EXTRACT）、转换（TRANSFORM）、清洗（CLEANSING）、装载（LOAD）的过程。是构建 数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗,最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。
我们所要做的ETL工具不是针对数据仓库，说白了就是要个安全稳定的数据库数据导出导入工具。下面就是我写的文档，希望童鞋们看了后请多多指教。
1.1. 概述
如图1-1：
ETL工具共分为三大模块：ETL核心模块、日志模块和WEB模块。
1.1.1. ETL核心模块
ETL核心模块是整个ETL工具的核心，它主要的功能是根据事先定义好的规则将源数据库的数据抽取到目标数据库。其主要工作流程是：
数据抽取-->数据转换-->数据清洗-->数据加载
ETL工具里的配置数据库必须包含两个方面的数据：
- 元数据：元数据主要是指源数据、目标数据库以及可以用于抽取的表、字段等等信息，还有一些相关函数的定义等等。
- ETL任务信息：ETL任务在我们ETL工具里称作job，job是指一个将数据从源数据库导出，并且按照一定规则导入到目标数据库的过程，ETL任务信息就是指一个job的相关配置信息。
1.1.2. 日志模块
良好的系统最重要的特征之一就是它的差错、容错以及能正确提供系统运行信息的特性。所以日志模块是每个系统必不可少的部分，它设计的优劣直接关系到系统后期维护的成本。
ETL工具里的日志模块，我个人认为应该包含如下的部分：
- 程序运行信息。这个主要是用log4j在代码里记录。
- ETL任务（即job）运行失败的日志信息。一切因为程序所抛出的异常所引起的失败都要记录在log4j的运行日志里，如果能精确提炼出的常见异常，最好能记录在数据库的日志表，便于快速查找错误信息（这个在有WEB系统时候可以做）。
- 审计日志。审计日志是带有一定业务需求的日志，这个是否要记录看实际的需求。
- 错误告警。一般而言ETL抽取数据的操作都是一件漫长的事情，ETL开发人员不可能长时间坚守在系统旁边，所以当系统运行出错能在第一时间通知到相关负责人是很有必要。Log4j里有邮件通知的功能，用起来也不太难，可以考虑在日志模块加入告警的功能。
1.1.3. WEB模块
当我们开发好了ETL工具后我们需要一个入口，告诉我们设计的ETL工具你具体做什么样的任务。WEB模块的作用就是给用户操作的入口，我个人认为WEB模块包含以下功能：
- 元数据管理：主要是向配置数据库定义源数据库和目标数据库的相关信息,例如：数据库的url，用户名，密码，相关的表以及表里字段信息等等。这些信息很重要，如果没有这些信息，整个ETL作业就是无源之水，根本无法进行。
- ETL任务的配置信息：即job的配置信息，这个就是定义我们ETL的抽取过程，例如ETL需要抽取的源数据库是那个，抽取那张表那些字段，按照什么规则转化数据，清洗数据，最终导入到那个目标数据库等等。
- 查看日志信息：这个功能可选，查看日志信息主要是提高系统的友好程度，便利系统运行信息的查看。
- 用户管理：这个功能暂时可选，因为我们所开发的ETL工具主要是内部使用，没有太大必要做复杂的权限管理，但是简单的用户信息管理做做应该还是必要的。
整个WEB模块也是可选的，如果人力和时间不够是没必要做一个web系统，ETL入口我们可以手动的配置任务信息。（假如真的做了WEB模块，对ETL后台的设计和开发要求也会更高）。
1.2. 关于技术开发的一点建议
我之前看过大家写的ETL需求文档，大家考虑的非常全面，这里我暂时有两个技术建议， 建议如下：
1.2.1. Xml技术
Xml技术在企业级系统开发和互联网开发中使用十分广泛，xml使用的场景也是非常的多，其中一个特点非常适合我们在ETL工具开发中使用到，那就是它可以存储复杂的富有变化的数据结构。而我们定义ETL任务信息（job配置信息）就是一个复杂的富有变化的数据。大家看下面的例子：
<?xml version="1.0" encoding="UTF-8"?>
<Job>
<Id>流水号</Id>
<Extract>
<JDBCSource>
<Url>…</Url>
<Username>…</UserName>
<Password>…</Password>
</JDBCSource>
<JDNISource>…</JNDISource>
<Table>…</Table>
<Columns>
<Column>…</Column>
<Column>…</Column>
…
</Columns>
<Where>…</Where>
<Commit>…</Commit>
<OrderBy>…</OrderBy>
<FilePath></FilePath>
</Extract>
<Transform>
<Columns>
<Column>
<SrcColumn> <!-- 抽取的原字段-->
</SrcColumn>
<Methods>
<Method id="1"> <!-- 第一次转换-->
<Function>...</Function>
</Method>
<Method id="2"> <!-- 第二次转换-->
<Function>...</Function>
</Method>
</Methods>
<DesColumn> <!-- 加载的目标字段-->
</DesColumn>
</Column>
<Column>...</Column>
</Columns>
<SouceFilePath>...</SourceFilePath>
<TargetFilePath>...</TargetFilePath>
<Commit>...</Commit> <!--每一批次的处理条数 -->
</Transform>
<Load>
<JDBCSource>
<Url>…</Url>
<Username>…</UserName>
<Password>…</Password>
</JDBCSource>
<JDNISource>…</JNDISource>
<Table>…</Table>
<Columns>
<Column>…</Column>
<Column>…</Column>
…
</Columns>
<Commit>…</Commit>
<LoadFilePath></LoadFilePath>
</Load>
</Job>
这是一个job配置信息demo，如果我们把这些数据用数据库来存储解析起来一定是非常复杂，数据库的表结构不适合表现出程序里复杂的数据结构。
在这里我们不应该把XML当做配置文件看待，而是当做一种数据存储的介质，其作用主要是便于我们读写数据。
既然对xml有读写操作，因此使用digester解析xml的技术远远不够，这里我建议使用xmlbeans，xmlbeans对于读写xml更加的简便，关于xmlbeans的学习参考如下：
Xmlbeans的使用：
http://blog.163.com/pqg_iloveyou/blog/static/33351875200761811255619/
xsd的学习资料：
http://www.w3school.com.cn/schema/schema_example.asp
xmlbeans官网：
http://xmlbeans.apache.org/
xsd在eclipse开发起来十分的简便。
使用xmlbeans维护xml的成本也会比较低。
1.2.2. Spring Batch技术
对于spring batch技术我现在还不是特别熟悉，到底能不能被我们使用还需要考察和研究，但现在我知道的它的几个特点很符合我们ETL工具开发的场景：
- spring batch批量处理框架，我们的抽取数据的过程就是一个批量的过程，因此spring batch是适合我们现在应用的场景。
- 我们抽取的数据先是存储在临时文件，现在规定的临时文件的格式是csv，而spring batch正好有批量操作csv文件的功能，这个也很符合我们应用的场景。
1.3. 总结
因为本人以前做过和ETL工具类似的项目，因此这里大胆的提出一点自己的建议，仅供参考。
不过我在概述里画的系统结构图希望大家可以好好看看，也许还有很多不合理的地方，这需要大家集体智慧进行改进，我个人觉得系统的整体架构设计十分重要，我在看需求分析时候虽然感觉大家写的很全面，但是很难对系统整体结构有一个清晰认识，究其原因是需求里缺乏对系统的整体架构设计的部分，我个人觉得系统整体设计很重要很有必要，整体架构设计会给我们带来很多好处：
- 整体架构设计会给我们需要做哪些功能有一个清晰的认识，这个认识会避免开发的时候遗漏了功能。
- 整体架构能清晰表现出各个功能模块的关系，做过开发的人应该都会有这样的体会，模块之间的交互的地方很容易产生问题，而且交互产生的问题也是很难查找定位的，整体架构设计会让我们清晰认识到模块交互关系，利于我们做模块之间交互的开发。
- 整体架构能清晰体现出模块之间的边界在哪里，这个很重要，不清晰模块之间的边界，很容易在把A模块的功能写到了B模块中，最终导致系统的不稳定。
- 整体架构的设计能给项目开发的分工做参考，更合理的安排工作，提高生产效率。
