银行应用系统间的数据交换
核心系统与外围系统的数据交换可以分为批量数据交换和实时数据交换两类。实时数据交换是双向的，一般由专门的中间件完成。批量数据交换也可能是双向的，但总体上是从核心系统流向外围系统的批量数据交换方式为主。从这一点来看核心系统是数据生产者，外围系统是数据消费者。外围系统之间也可以有批量数据交换和实时数据交换，因而互相扮演数据生产者和数据消费者的角色。本文将主要讨论批量数据交换。
数据提取的困难及应对办法
数据交换前一般都有现成的核心系统或者外挂系统作为数据源，因而一般只能选择特定的源系统来提供数据，这就给数据提取增加了很多困难,即强加了许多约束，以下是最常遇到的一些约束和应对办法。
1. 数据源约束: 可能是某种关系数据库，也可能是平面文件、电子表格、PDF文件,或者可能是复杂的ERP系统,比如SAP R/3、SAP BW、Peoplesoft等。应对数据源的多样性，可以有两种办法: 一种是设定一种类型（比如关系数据库）作为统一的源类型，其他类型首先转换到关系数据库表中，然后再实施抽取; 另一种方法是直接选用能够支持各种类型接口的数据抽取中间件产品，比如Informatica、Datastage等。
2. 数据目标约束: 目标系统数据平台也可能有多种，比如 Informix on HP_UNIX、DB2 on OS/390、SQL Server on win2000。处理方法与上面的类似:
方法一: 如果抽取工具支持特定目标接口，可以直接将抽取的数据发送到目标系统，这样不用经过“数据落地”的中间环节，采集效率比较高，但仍然需要在目标系统上进行备份，以防回溯或重做。
方法二: 如果抽取工具无法支持特定目标接口，可以首先将抽取的数据转换为平面文件，因为平面文件的适用性非常广泛，通常的数据库都有批量加载工具完成本地或远程加载，而平面文件本身也是很好的备份载体，缺点是有“落地”动作，文件在采集服务器上有产生、传送、备份、删除的环节，对采集服务器要求比较高，效率上要略逊于方法一。
3. 窗口约束: 一次数据抽取往往有严格的时间窗口，比如数据源只能在凌晨时间点A以后才提供服务，同时数据目标又必须在凌晨时刻B之前完成数据刷新，那么数据采集的时间窗口只能落在[A,B]区间之内，否则从业务角度看就是失败的。
如果时间窗口无法满足要求，可以从多个方面下手: 时间点A能否再提前些？个别耗时太长的大表抽取能否改造为更精简的增量采集？是否可以只采集目标需要的字段而不是全字段采集？是否有串行的采集和加载能改为并行的采集和加载？数据源中的大表中是否有合适的索引？目标表加载前清空动作是delete还是truncate？数据库目标系统是否带索引加载？批量加载时应该避免索引和产生数据库日志。采集服务器的CPU数量、内存数量的配置是否能扩容？一般情况下上述的调整都可以满足采集时间窗口的要求。
4. 时间空间约束: 数据源系统可能位于地理位置上分散的多个地方，同时不同的数据采集点提供的数据在业务上可能是不同时间点的数据，比如数据源1生成T-1日数据的时候，从数据源2仅能得到T-2日的数据，这往往是由于两个数据源之间有数据依赖关系。针对空间上的分散，可以考虑将某一个数据源作为各源系统汇聚点（比如选择核心系统），其他源系统或者直接提供数据库直连方式作为源，或者产生平面文件上传并被预先加载到核心数据源，也可以加载到与核心数据源平行的另一台专属机器上，一旦数据源集中后，就可以方便地进行各目标系统数据的采集。
针对业务数据时间点不同的问题，往往需要具体问题具体分析，比如，如果数据源2的数据影响面较小，而目标系统对数据源2的要求又不严格，那么就可以忽略这个问题，如果不能忽略，可以考虑从两个数据源的依赖关系上来突破，目标系统对于数据源2的应采数据是数据源1的一部分A再加上数据源2的另一部分B计算后得出来的，那么目标系统可以扩大采集范围，将A、B都采进来，然后在目标系统中自己计算。这个方法对目标系统的要求会提高，实践中要视数据源2的数据量和算法复杂度而定。
5. 性能约束: 现实中往往有多个数据源、多个目标系统，抽取时是多对多的关系。不同的数据源系统和目标系统的运行性能差异可能是十分巨大的。如何在整体采集性能上时间最优是个挑战。应对策略是: 如果目标系统性能差异比较难识别出来而且波动剧烈，可以考虑将平面文件作为采集加载中间环节以屏蔽目标的性能差异; 如果目标系统性能差异容易识别出来，可以考虑将目标系统按快慢等级分组，按组采取不同的抽取模式和策略。
6. 可用性约束: 数据源系统与目标系统的稳定性有时差别很大，部分系统很稳定，几乎不可能宕机，有的系统隔三差五出故障，这就会导致数据采集及时性上波动很大，目标系统面临风险。应对策略是: 如果数据源不稳定，那就要看有多少目标系统依赖这个数据源，因为业务的关键性决定了系统的稳定性和关键性，如果目标系统支撑的业务很关键，就必须改进数据源的不稳定性，这是彻底的办法; 如果由于种种原因，数据源的稳定性不能提高，就需要取消该数据源系统提供数据的资格，而目标系统则按照这一部分数据缺失来处理，目标系统的补救措施可以是采用人工补录方法得到数据，也可以是新建系统等办法。这两种办法都有“口渴凿井”的阻力，因为如果数据量大，人工补录和新建系统都耗时很长，这意味着目标系统在相当长的时间内得不到数据。如果是数据目标系统不稳定，那就最好使用平面文件作为数据采集中介，可以起到数据缓存的效果，这样在目标系统可用时进行连续处理。
数据的加载
在完成数据的抽取后，就可以把采集到的数据加载到目标系统的临时表中（每次加载之前都清空的是永久性临时表，对应的刷新后的表为主表），而目标系统要经过刷新动作，才能得到新的业务数据。这里有如下一些加载办法:
● 全量时的刷新: 临时表数据为全量时，直接用临时表的内容覆盖主表，或者将主表重命名，将临时表更名为主表，再加上相应的索引。
● 增量时的刷新: 临时表数据为增量时，因为通常临时表与主表的结构一致，所以可首先将主表按主键与临时表进行关联，删除主表中的对应纪录，然后将临时表中的记录插入到主表中。这样临时表中采集到的新增、更新的纪录都会刷新到主表中，对于逻辑删除的纪录，往往表现为更新动作，所以一般都会更新到主表中，但有时个别的表在数据源系统中会进行物理删除数据动作，这时临时表中会采集不到这种纪录，刷新后主表的相应记录仍然存在，这就是误差，一般经过一段时间，将这种表与数据源系统同步一次将是很有必要的，可以保证误差不会持续扩大。
● 混合型时的刷新: 目标系统往往采集的数据源表很多，有的数据源能够采集到增量，有的只能是采集到全量，对目标系统的刷新将是一个混合模式。此时，增量数据应用增量模式来刷，而全量数据要用全量模式来刷。
● 并行与串行问题: 串行刷新是一张主表刷新完后继续下一张主表; 并行刷新是确定一个并发度，同时有多个主表同时刷新，高效的刷新往往都是并行刷新的。
一次性数据抽取
商业银行要接受人民银行和银监会的监管，常常会被要求不定期地提供一次性的交易统计报表，这就需要信息部门配合业务部门提供原始的交易数据用于完成报表，一次性数据提供可以有几个途径完成:
1. 利用企业存储系统提供的镜像数据库
核心交易系统往往有独立的大型存储基础设施，这些存储系统除了拥有海量存储能力、高速的I/O外，还具有瞬时快照功能，能将交易系统的某个时间点的数据库镜像与交易数据库分离，从而为开发或者采集提供绝好接入点。此时一次性的数据提取可以利用镜像数据库，直接使用数据库提供的卸载数据功能得到要采集的数据，比如informix的load/unload。
2. 利用核心的历史数据备份
如果管理部门要求的一次性提供的数据在镜像数据库中已经删除，常见的做法就是重新恢复交易系统的某个时间点的历史数据备份，然后从中得到一次性数据。
3. 利用ODS子系统
有的银行具有ODS系统，在其中会缓存一段时间的原始交易数据，比如传票、分户账明细、一些初步加工过的统计数据等。用ODS提供一次性数据是很好的选择。因为初步加工过的统计数据往往能减少业务部门生成统计报表的时间。
4. 利用数据仓库环境
数据仓库环境是一次性报表最好的数据源，因为前端的BI工具可以很方便地定制各种复杂的、灵活的报表，而且利用BI工具可以方便地从数据仓库中进行钻取、切片、数据挖掘等各种高级应用。业务人员不需信息部门的配合就可以直接生成报表。遗憾的是，数据仓库环境对于大多数国内银行来说并不存在，而应用成功的企业级数据仓库更是凤毛麟角。
数据抽取中的性能优化
对于大批量数据采集，性能的调整可以有以下几个方面可以考虑:
1. 适当的并行度
目标系统从源系统抽取的库表往往不止一个，如果能够对多个目标表进行同时装载，在采集性能上将有很大的提高。但并发度不仅要受制于数据采集软件本身，更多的是受制于采集服务器的硬件配置，比如CPU的数量、内存、硬盘等。
同样，对于源系统的同一张表，可能有多个目标系统需要从中采集数据，那么可以考虑在一个采集作业中读取数据源一次后，同时写多个目标。利用Datastage等采集工具，可以在一个采集作业中实现作业内的并行。
2. 监控历史运行记录，重点优化大表
大表的定义并没有统一的标准，但一般来说，记录总数超过1000万的表，就可以认为是大表。优化的办法是对于数据源的筛选字段建立索引，这样筛选的效率就会高很多。另一个办法从SQL的语句上进行优化。对于大表，可改进增量采集的逻辑，如果缺乏增量采集的筛选字段，可以考虑在数据源数据库中安装触发器。宽表也是个很常见的（字段数目很多的表属于宽表），因为每一条记录的尺寸都很大，所以这也容易导致采集时间变长，优化的办法是分析目标系统，目标系统不需要的内容就不要送到目标系统，这样不仅节约时间，还节约目标系统的硬盘。
3. 避免使用低效的数据库接口技术
采用通用的数据库接口技术往往会导致低效，比如ODBC，所以对于不同的数据库，如Informix、Sybase、SQL Server、Oracle、DB2等，应该采用专用的数据库接口，这可能会比ODBC等接口快上几倍。
4. 压缩和解压缩
如果数据从源系统中抽取出来后，要生成文件传送给目标系统，那么在低速的网络上，文件尺寸过大可能造成性能很低，导致多次中断重传。比如2G以上的大文件，传送起来就比较麻烦，可以考虑压缩和解压缩，这样在传送上会节省时间，但是压缩和解压缩又会占据时间，这要在真实的网络环境中实测后权衡，在高速的网络中，比如千兆网中，大文件不是问题，就不需要压缩/解压缩。
5. 控制数据采集事务的大小
目标系统数据库一般有事务，事务太小或太大都不好，可以找到一个合适的事务大小，比如每插入目标系统1000条记录提交一次。应保证不会在装载大表时耗尽目标系统的锁资源。 6. 分析可能的性能瓶颈
对于数据采集任务，要建立运行日志，定期分析性能瓶颈，持续改进。
7. 采集任务分等级
采集性能问题可能是因为任务安排得不够科学。将紧要的采集作业安排在优先调度的时间点上，比如每天都要开门营业的系统就必须保证优先采集。
8. 采集任务错时调度
采集服务器上的采集任务可以按照时间窗口的大小先后顺序进行错时调度: 比如一次性采集任务或者备份任务就可以考虑在采集服务器空闲的时间来处理。
数据采集系统示例
如附图所示，数据源１为核心交易系统的镜像数据库Informix on HP_UNIX，数据源２为分行系统上传的数据文本数据库MS SQL Server，采集服务器的采集软件平台是安装Windows和SQL Server系统之上的IBMDataStage XE，目标系统是各个核心系统之外的应用系统，图中显示一部分，还可以继续往上累加。
全部的例行采集任务全部使用Datastage Job形式实现，在开发环境下开发测试完成后部署到采集服务器上，采集作业的日志记录在MS SQL Server数据库运行日志表中，由采集监控程序实时扫描日志表探查状态。
每天的例行采集运行过程是这样的: 当核心系统日终业务处理完毕，同时数据源２的文本上传完成，由机房值班人员启动采集总调度，总调度首先将数据源２的文本装入数据库，然后开始向各个目标系统并发传送数据，采集监控每天晚上显示采集作业的运行过程，当任何一个目标系统采集任务运行完毕，会在目标系统数据中的特定表插入一条完成纪录，这样目标系统就可以继续自己的批处理。如果采集监控显示运行错误就报警，由机房人员通知技术人员远程拨入处理故障。
