1．引言 在商业银行中，用户对数据实时性的要求(4)

　　日志模块对于管理员的一些操作也要做详细的记录，比如某天某个管理员没有按照要求擅自启动了ETL 系统，导致了错误的发生，或者在发生异常后，管理员做出了一些解决措施。或者有管理员利用职权窃取数据，这些都将被记录下来，为以后的责任的追究和工作表现提供证据。

　　4.2 ETL 过程
　　此模块是 ETL 的主要实现过程,包含三个阶段：数据抽取、清洗和转换、转载。

　　在数据抽取阶段，我们根据用户提供的数据源方式分为以下几种处理方式：①抽数。针对此种数据源，我们在数据源接口表中定义好了数据源的地址、端口号、用户名和密码，以及抽取时间后，即可定时调用任务抽取数据。②送数。由于数据源保密性要求、时间上的不合适或者网络隔绝等条件的限制，ETL 系统只能等待数据源送数过来，或者以备份文件，或者以文本文件的形式送达。这时，我们可以监听送数事件，当查看到特定目录中出现数据的时候，便启动往ODS 导数任务。在抽取任务中，我们也必须描述清楚数据的增长方式：

　　增量或者全量。增量抽取往往适用于交易信息，这类数据的特点是每天的操作不会对以前的信息造成影响；全量则适用于客户信息、票据信息等可能被更改的数据，这些信息在各个抽取任务中都会有所体现。

　　在清洗和转化操作阶段，我们根据处理的源数据的规模大小和相关性将几个处理过程作为一个子任务，这样做的好处是方便实时查看进度和减少任务失败时重新执行的时间损失，同时也最大化地利用了数据库的缓存池。这样的一个任务提交时，比每个处理过程执行完毕后就提交节省很多时间，而每个任务完成后再提交则有可能导致数据库缓存池溢出错误，从而导致任务提交失败。即使没有出现错误，实践证明提交一个任务比子任务需要更多的时间。

　　在装载阶段，我们采用成熟的商业工具即可，因为这类工具具有稳定性和安全性，并且在此阶段，没有太多可以优化的地方。只是在装载前我们会停去掉表的索引，在导完数据后再统一建立，这么做的好处是提高导入速度。

　　装载完毕后，对存在于 ODS 中的历史数据，我们也需要定时的清理，以减少整个ETL系统负担。针对不同的数据，清理的要求也不同，有的数据需要保留一天，以便同以后的数据对比，有的数据则可以即时清理掉。在本模型中，我们可以设置表数据的清理范围和时间，用户只需根据具体要求设置好执行时间，则系统会在指定时间清理指定数据。

　　5．模型的应用 本文来自中国科教评价网
　　我们将此模型应用到某商业银行的非现场审计系统中，针对审计系统的特点对各个模块就行了本地化。系统实际运行情况表明，该系统具有很好的效率，可靠性比较强，同时具有一定的容错性，能很好的满足用户的需求。

　　6．总结
　　本文针对商业银行系统复杂的数据存储环境设计了基于业务的 ETL 模型，该模型将商业工具和编程实现结合起来，可以灵活地实现用户要求，同时保持了很高的效率。本模型在任务管理模块将业务划分为任务，既可以按照传统ETL 流程处理数据，也可以在发生错误后按照任务的任务号单独完成目标数据库中出错部分，这种灵活的处理方式大大节省了时间。异常处理模块和系统日志模块为系统的安全性、健壮性提供了保障，历史数据的定时清理机制也保证了此ETL 系统可以高效的完成任务。本硕士论文来源于中国硕士论文网，参考文献：http://www.lunwenad.com/wzlb-3.html，转载敬请保留链接，谢谢。

　　本系统也还存在一些不足的地方，比如对于语义异构问题没有有效提出有效的方法，希望将来能够改进。