在核心业务系统与外围系统之间批量交互数据是银行应用系统中最常见的任务之一，由于通常要受到多方面因素的制约，这是一个十分复杂而且耗费精力的工作。本文对其中的技术困难和应对策略进行了总结。
尽管目前银行正在进行综合业务系统大集中的改造，但并非所有银行的应用都会集中到惟一一个核心业务系统上，因为银行业务系统的大集中主要是会计账务意义上的大集中——“全行一本账”，即全行共享集中的客户信息，或者称之为核心账务系统（以下简称“核心系统”）。而银行内还存在许多面向管理类的应用系统，比如客户积分管理、人事管理、成本利润管理、资产负债管理、风险管理、反洗钱管理、银行绩效管理、业务数据统计等，这些业务往往仍由独立的应用系统来支持，这些围绕在核心业务系统的应用系统，我们姑且称之为“外围系统”。
核心系统与外围系统的数据交换可以分为批量数据交换和实时数据交换两类。实时数据交换是双向的，一般由专门的中间件完成。批量数据交换也可能是双向的，但总体上是从核心系统流向外围系统的批量数据交换方式为主。从这一点来看核心系统是数据生产者，外围系统是数据消费者。外围系统之间也可以有批量数据交换和实时数据交换，因而互相扮演数据生产者和数据消费者的角色。本文将主要讨论批量数据交换。
数据提取的困难及应对办法
数据交换前一般都有现成的核心系统或者外挂系统作为数据源，因而一般只能选择特定的源系统来提供数据，这就给数据提取增加了很多困难,即强加了许多约束，以下是最常遇到的一些约束和应对办法。
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. 可用性约束: 数据源系统与目标系统的稳定性有时差别很大，部分系统很稳定，几乎不可能宕机，有的系统隔三差五出故障，这就会导致数据采集及时性上波动很大，目标系统面临风险。应对策略是: 如果数据源不稳定，那就要看有多少目标系统依赖这个数据源，因为业务的关键性决定了系统的稳定性和关键性，如果目标系统支撑的业务很关键，就必须改进数据源的不稳定性，这是彻底的办法; 如果由于种种原因，数据源的稳定性不能提高，就需要取消该数据源系统提供数据的资格，而目标系统则按照这一部分数据缺失来处理，目标系统的补救措施可以是采用人工补录方法得到数据，也可以是新建系统等办法。这两种办法都有“口渴凿井”的阻力，因为如果数据量大，人工补录和新建系统都耗时很长，这意味着目标系统在相当长的时间内得不到数据。如果是数据目标系统不稳定，那就最好使用平面文件作为数据采集中介，可以起到数据缓存的效果，这样在目标系统可用时进行连续处理。
数据的加载
在完成数据的抽取后，就可以把采集到的数据加载到目标系统的临时表中（每次加载之前都清空的是永久性临时表，对应的刷新后的表为主表），而目标系统要经过刷新动作，才能得到新的业务数据。这里有如下一些加载办法:
● 全量时的刷新: 临时表数据为全量时，直接用临时表的内容覆盖主表，或者将主表重命名，将临时表更名为主表，再加上相应的索引。
● 增量时的刷新: 临时表数据为增量时，因为通常临时表与主表的结构一致，所以可首先将主表按主键与临时表进行关联，删除主表中的对应纪录，然后将临时表中的记录插入到主表中。这样临时表中采集到的新增、更新的纪录都会刷新到主表中，对于逻辑删除的纪录，往往表现为更新动作，所以一般都会更新到主表中，但有时个别的表在数据源系统中会进行物理删除数据动作，这时临时表中会采集不到这种纪录，刷新后主表的相应记录仍然存在，这就是误差，一般经过一段时间，将这种表与数据源系统同步一次将是很有必要的，可以保证误差不会持续扩大。
● 混合型时的刷新: 目标系统往往采集的数据源表很多，有的数据源能够采集到增量，有的只能是采集到全量，对目标系统的刷新将是一个混合模式。此时，增量数据应用增量模式来刷，而全量数据要用全量模式来刷。
● 并行与串行问题: 串行刷新是一张主表刷新完后继续下一张主表; 并行刷新是确定一个并发度，同时有多个主表同时刷新，高效的刷新往往都是并行刷新的。
