小研非现场审计系统业务的ETL论文
1．引言。
在商业银行中，用户对数据实时性的要求很高。在商业银行的一些系统中，如非现场审计系统，用户需要在很短的时间内对交易数据进行分析、统计，并把可疑数据上报，以尽量减少损失。这就要求系统所需数据必须在短时间内到达，但是这些系统的数据源十分繁多。
审计系统中，审计人员需要的信息很全面，既包括个贷业务、信贷业务、私金业务，还要包括国际业务、资金业务和中间业务等，这些业务都有各自的系统，其中有一部分数据还取自于核心系统。而且数据存储在异构的环境中，比如它们使用不同的数据库，不同的操作系统环境等等，如何在众多系统中快速的提取数据和快速的形成一个系统所需的数据集市，这对我们是一个挑战。
针对上述问题，本文提出了一个ETL模型。与其他商业银行常用的模型相比，本模型基于业务设计和实现，具有高效的错误恢复机制，能够利用基础任务和业务任务的划分，根据任务号单独执行出错的任务，而不用将整个ETL过程重新执行一遍，大大缩短了恢复错误的时间，从而可以更好地满足客户对于时间上的要求；与传统成熟的商业ETL工具相比，基于业务的模型设计与实现，可以根据每天的审计目标去创建ETL任务，减少了工作量。同时，此模型部分实现直接采用代码，针对性更强，灵活性更好，可以处理商业银行复杂系统中清洗和转换任务，最重要的是可以减少商业工具一些不必要的执行步骤，缩短了时间。中国硕士提供大量免费mba硕士论文，如有业务需求请咨询网站客服人员！
目标ETL 过程的最终目标是在合理的时间内实现了高质量的审计系统数据集市，以供客户审计业务数据。围绕此目标，本文必须合理、灵活、高效的设计ETL 过程，才能满足用户的需求。在此过程中，存在以下几个问题：
1.灵活的ETL 控制过程。
因为本审计系统涉及的数据源比较多，包括信贷系统、票据系统、核心系统等，根据客户要求，有的业务数据可能需要每天更新，而有的业务数据可能需要每两天更新一次。对于这种数据更新频率不统一的要求，本论文需要设计灵活的ETL过程，可以实现针对单数据源的操作。
2.统一安全的抽取平台。
由于数据源的繁多，而且数据存储在异构的环境中，比如它们使用不同的数据库，不同的操作系统环境等。这就要求本文要实现一个统一的抽取平台，以应对不同的数据承载平台、数据源和数据格式，同时要求在抽取构成中不能破坏源数据。
3.快速的处理过程。
由于用户要求数据的准实时性，要求在尽量短的时间内（比如两个小时）便可以审计业务，所以本文还要解决如何快速在众多数据源中提取数据和快速的形成一个系统所需的数据集市，这对本文是一个巨大的挑战。
4.自动化的处理流程，可定制的服务。
由于商业银行的特殊性，要求数据抽取必须在午夜进行，所以本系统必须实现自动化的处理流程，尽量减少人工干预，降低服务成本。此外，还要实现客户定制任务，包括时间和频率等。
同样由于商业银行业务的特殊性，审计系统的数据一定要高质量，只有高质量的数据作为保证，整个数据集市项目所提供的数据才能体现出高价值，这就要求本系统在ETL 过程中一定要建立合理的质量保证和错误恢复机制。
3．ETL 模型结构设计。
主要分为四个部分：控制台、ODS、ETL过程和审计系统数据集市。
首先开发人员必须利用控制台初始化任务，建立源数据和目标数据集市中的映射关系。
根据数据源的不同，建立不同的任务类型，以供用户选择。然后用户就可以利用控制台管理任务了，包括初始化任务、任务调度、异常处理和记录日志等。
客户启动任务后，ETL过程会根据本次任务需要的数据信息从相应的数据源中抽取数据到ODS中。为什么要先将数据抽取到ODS中，而不直接进行清洗，装载到目标数据集市中呢？ODS是目标数据集市与外部源数据的接口，并且ODS在ETL中有着缓冲和保护的作用，在业务系统和数据集市之间形成一个隔离层，避免外部源数据直接向目标数据集市写数据。
将数据抽取到ODS中，开发人员就可以对ODS中的数据进行多次清洗和转换，即是在清洗和转化过程中发生错误，开发人员也不需要直接从数据源再次抽取，而只要使用ODS中的数据即可，为审计系统提供一定的容错能力。清洗和转换完毕后，将数据装载到审计系统数据集市中。
4. ETL 的功能设计。
4.1 控制台。
控制台中又包括了任务管理、元数据管理、异常处理和系统日志。任务管理实现了任务的初始化、任务调度、任务执行等功能。元数据管理则为开发人员提供了源数据（ODS 中）和数据集市映射关系的管理。
4.1.1 元数据管理目前，元数据存在多种不同的描述，Luo Agostas 说元数据是一种比喻，因为它抽象了看起来完全不同的事物。在数据仓库领域元数据被定义为：描述数据及其环境的数据。在本文里，笔者采用常用的一种描述，将本系统的元数据分为技术元数据和业务元数据。
所谓技术元数据主要是用来描述数据实体和数据处理过程中的技术细节和处理规则。比如数据源接口（数据库名、端口、数据库类型、用户名、密码等）、ETL 任务表（任务编号、任务名称、任务粒度、任务号、后序任务、状态等）、业务元数据则主要是对IT 系统的数据实体和数据处理的业务化描述，包括业务规则、业务术语、统计口径、信息分类等。如某商业商业银行审计系统中的企业基本信息（企业名称、客户类型、企业隶属、企业类型、行业类型、主营业务、经济类型等）、财务报表数据（报表月份、客户名称、报表种类、币种等）、小额担保贷款贴息统计（借据号、合同号、小额担保贷款类型、客户姓名、贷款金额、期限年、期限月、贷款发放日等）等。
考虑到保证系统的执行效率。元数据管理主要为数据集市的形成提供基础数据映射分析，并且在以后的维护中提供支持。
在本文中，任务的划分按照客户审计目标而定，一个任务即是一个审计业务数据的ETL过程，这是本文的重点。在一个数据集市的形成过程中，会涉及到很多的业务系统，因此审计系统的数据集市由很多任务组成。本系统中任务分为两种类型：基础任务和业务任务。基础任务是指实现形成该审计系统数据集市所必须的所有数据，比如审计系统中客户的基本信息，账户信息，企业信息等，这些都是基础数据，无论哪个业务都必须采用的数据，所以基础任务也是每次ETL 过程所必须完成的任务。而业务任务则是可以选择的，依据本次审计人员的要求而决定是否导入审计系统数据集市，比如信贷业务，如果本次审计要求中不包括此业务，那么本次ETL 任务便可不处理该业务数据。基础任务是形成数据集市的必选任务，每天只需执行一次。而业务任务则是根据每天的审计目标而选择的可选任务。
在此基础上又引入了优先级、执行时间和任务号的概念。优先级是在任务创建的同时就会确定的，优先级有三等：重要，一般，不重要。执行时间就是执行任务的时间先后。任务号是若干任务执行先后顺序的依据。
在描述功能前，我们有必要先描述任务的生命周期。在本审计系统中，任务有五种状态：
新建，就绪，执行，成功，失败。状态之间的转换。
新建状态：创建一个任务即添加一个新的 ETL 任务，任务的信息包括目标子任务信息和任务的创建信息（包括创建者和创建时间等等）。
执行状态：任务占用系统资源，同一时刻，处于“执行”状态的只有一个任务，另外的任务处于“就绪”状态。
成功状态：任务执行完毕，并且执行过程中没有发生异常，或者发生异常后又重新执行完毕。
任务状态之间的转换主要包括以下几种：
创建新任务：创建一个新的任务，即确定一个检测计划，初始化任务的数据源和元数据等信息。
调度：准备执行任务，将其置为“就绪状态”，随时可以分派执行，由于同步机制的限制，系统在同一时刻只能执行一个任务。
出现异常：任务在执行过程中，发生可恢复或者不可恢复的异常，中止执行，将其置为“失败”状态。
任务管理模块包括的功能主要有任务初始化、任务调度和任务执行。
任务初始化主要是创建任务，用户根据本次审计目标的要求来建立一个 ETL 任务，包含任务信息和任务的创建信息。任务信息是指选择符合本次审计目标的业务任务，基础任务不用选择，因为是必选的，在执行ETL 的时候，会首先执行基础任务。
任务调度模块是贯穿整个数据集市形成过程的，在此过程中监听事件，并能够根据事件启用相应的任务。在此模块启动后，根据任务号顺序执行，关于任务的任务号确定问题，本系统中采用一个较为简单的原则来解决：在任务创建的同时已经确定了任务的优先级，结合任务的执行时间，先按照执行时间先后确定任务号，如果执行时间相同，再按照任务的重要性确定任务号，如果重要性也相同，则对二者（或者更多）随机确定任务号。如果任务B的任务号是排在任务A 的任务号的下一位，则成任务B 是任务A 的后续任务。顺序执行任务的同时要监听触发事件，此模块监听的事件可分为主要有两种：
①任务结束。在一个任务执行时，任务调度模块会实时监控这个任务的状态，当一个任务执行完毕后，将此任务的状态置为完成，并将其后序任务状态置为准备。而当错误发生后，首先将其状态置为异常，然后调用异常处理模块，处理好现场，并将该子任务的状态置为“失败”。并将错误记录到日志中，顺序执行下一个任务。
②时间到达。对于一些任务，用户希望它们定时执行，所以任务调度模块必须实时比较它们的启动时间和系统时间，一旦二者一致，就执行此任务。任务调度模块一直执行到任务完成后关闭系统时才随系统一起停止运行。
任务执行即是开始 ETL 处理过程。任务的执行方式分为两种：手动和定时，手动方式随时可以执行，定时方式则是在设定的时间自动启动。具有管理员权限的用户随时可以执行任务。定时任务则要在系统内设置定时执行任务的时间，可以根据任务需求设置几种频率：
每月，每周，每天等。每天到零点时刻，系统就会添加所有在这一天内要执行的定时任务到队列中，然后计算出到达下一个设定的执行时间的时间差，让线程休眠相同时间，醒来后再执行。同一个任务可以多次重复执行。如果在执行任务过程中新添加了一个任务，系统会根据此任务的任务号插入到队列中。每完成一个任务，系统就从执行队列中选取一个优先级最高的执行。
4.1.3 异常处理。
任何系统都会出现异常情况，所以异常处理模块必不可少。在本模型中，异常处理模块主要应对任务执行异常情况，比如数据出现乱码，从而致使数据转化任务出错；正在执行抽取或导入任务时，网络断开，等等。
在出现错误后，本模块会将该任务的状态置为“异常”，然后调用相应的处理程序。对于一些任务执行过程中发生的错误，只需要重新执行该任务便可，比如网络或电源断开；而对于一些错误的处理则比较麻烦，比如抽取数据的时候一个表发生错误，并且ETL 过程已经执行完毕后发现的，这种情况下，重新执行一遍ETL 过程势必要花费大量的时间，无论是用户还是数据源系统都是不允许的，因此我们可以利用前面所述基础任务和业务任务的划分，根据任务号单独执行出错的任务，这种做法就大大节省了时间，从而提高了错误恢复的效率。
4.1.4 系统日志。
系统日志模块也是 ETL 过程中必不可少的一个模块。它的作用在于记录每一个任务完成情况，以及系统启动时间和完成时间等详细信息，以便技术人员在查看以往的记录的时候有据可依，并且也可以从中查看一些异常情况，分析问题，解决系统无法自动解决的问题。
日志模块对于管理员的一些操作也要做详细的记录，比如某天某个管理员没有按照要求擅自启动了ETL 系统，导致了错误的发生，或者在发生异常后，管理员做出了一些解决措施。或者有管理员利用职权窃取数据，这些都将被记录下来，为以后的责任的追究和工作表现提供证据。
4.2 ETL 过程。
此模块是 ETL 的主要实现过程,包含三个阶段：数据抽取、清洗和转换、转载。
在数据抽取阶段，我们根据用户提供的数据源方式分为以下几种处理方式：①抽数。针对此种数据源，我们在数据源接口表中定义好了数据源的地址、端口号、用户名和密码，以及抽取时间后，即可定时调用任务抽取数据。②送数。由于数据源保密性要求、时间上的不合适或者网络隔绝等条件的限制，ETL 系统只能等待数据源送数过来，或者以备份文件，或者以文本文件的形式送达。这时，我们可以监听送数事件，当查看到特定目录中出现数据的时候，便启动往ODS 导数任务。在抽取任务中，我们也必须描述清楚数据的增长方式：
增量或者全量。增量抽取往往适用于交易信息，这类数据的特点是每天的操作不会对以前的信息造成影响；全量则适用于客户信息、票据信息等可能被更改的数据，这些信息在各个抽取任务中都会有所体现。
在清洗和转化操作阶段，我们根据处理的源数据的规模大小和相关性将几个处理过程作为一个子任务，这样做的好处是方便实时查看进度和减少任务失败时重新执行的时间损失，同时也最大化地利用了数据库的缓存池。这样的一个任务提交时，比每个处理过程执行完毕后就提交节省很多时间，而每个任务完成后再提交则有可能导致数据库缓存池溢出错误，从而导致任务提交失败。即使没有出现错误，实践证明提交一个任务比子任务需要更多的时间。
在装载阶段，我们采用成熟的商业工具即可，因为这类工具具有稳定性和安全性，并且在此阶段，没有太多可以优化的地方。只是在装载前我们会停去掉表的索引，在导完数据后再统一建立，这么做的好处是提高导入速度。
装载完毕后，对存在于 ODS 中的历史数据，我们也需要定时的清理，以减少整个ETL系统负担。针对不同的数据，清理的要求也不同，有的数据需要保留一天，以便同以后的数据对比，有的数据则可以即时清理掉。在本模型中，我们可以设置表数据的清理范围和时间，用户只需根据具体要求设置好执行时间，则系统会在指定时间清理指定数据。
5．模型的应用。
我们将此模型应用到某商业银行的非现场审计系统中，针对审计系统的特点对各个模块就行了本地化。系统实际运行情况表明，该系统具有很好的效率，可靠性比较强，同时具有一定的容错性，能很好的满足用户的需求。
6．总结。
本文针对商业银行系统复杂的数据存储环境设计了基于业务的 ETL 模型，该模型将商业工具和编程实现结合起来，可以灵活地实现用户要求，同时保持了很高的效率。本模型在任务管理模块将业务划分为任务，既可以按照传统ETL 流程处理数据，也可以在发生错误后按照任务的任务号单独完成目标数据库中出错部分，这种灵活的处理方式大大节省了时间。异常处理模块和系统日志模块为系统的安全性、健壮性提供了保障，历史数据的定时清理机制也保证了此ETL 系统可以高效的完成任务。