银行信息系统架构：数据整合平台及模型设计

数据产生后经过数据交换系统进入数据整合平台。在数据架构概述章节中，提到了数据整合平台分为贴源模型层（ODS）、数据仓库层（EDW）、共性加工层（GDM）、实时决策处理和历史数据存储等。同时，也针对未来数据仓库随着大数据技术的引入逐步向逻辑数据仓库扩充，此处分两部分介绍数据的整合。

第一部分介绍传统数据整合平台的数据分布。第二部分简单介绍基于分布式数据处理技术的逻辑数据仓库。

1.数据整合平台的数据分布

（1）贴源模型层ODS（OperationalDataStorage）　由于ODS的模型特征主要是贴近源系统，因此又把这层叫作操作数据存储层。

ODS用于支持企业对于即时性的、操作性的、跨系统汇合的全体信息的需求，其数据具有四个基本特点：面向主题（subject-oriented）的、集成的、可变的、数据是当前或接近当前的。

ODS兼具数据仓库和OLTP系统的部分特征，它和数据仓库一样都是面向主题（ODS的主题更加按照业务发生的主题归类，如存款、贷款、中间业务等，这样的主题分类基本等同于源系统的分类方法）和集成的，但是和数据仓库不同的是，ODS可以进行联机修改，包括增、删、改等操作。在企业数据分析环境体系内，ODS是数据仓库体系结构中的一个可选部分。

在实践中，银行在搭建ODS系统时，通常都会打破集成定义，直接将源系统的数据抽取至目标数据库，将它视为源数据的复本，而没有进行真正的数据集成；由于是贴源存储，因此在模型构建时很大程度上会带有系统来源的痕迹，可以认为是以业务条线为分类进行数据组织。同时在数据保存上，对于某些数据规模较小的银行，在没有构建数据仓库之前，也会让ODS承担一部分积累历史数据的职能。

在当前数据架构的讨论中，把ODS内部的数据存储分为四个独立的区域，分别是：

1）当日增量数据区域，满足下游系统获取增量的需求。

2）当日完整镜像区域，满足下游系统获取当日全量的需求。

3）准实时批量数据交换存储区域，满足基于数据总线获取的准实时数据的存储。

4）短期历史拉链区域，满足部分应用对贴源数据的短期历史获取需求。

（2）DW（DataWarehouse）数据仓库层 数据仓库层是整合数据架构的核心，我们从以下几个角度进项详细的讨论。

1）数据仓库的定义。数据仓库是一个用来支持管理人员决策的数据集合。数据仓库中应具备以下4个基本特征：

①面向主题（subject-oriented）。

②集成（integrated）。

③非易失的（nonvolatile）。

④随时间不断变化的（time-variant）。

2）数据仓库和ODS的比较。下面以ODS和数据仓库独立建设为例，主要从建模方式、数据整合、模型扩展性、数据存储周期、数据标准化、时效性、应用侧重点等维度进行实施上的差异比对，见表4-1。

表4-1 数据仓库和ODS对比表

3）数据仓库的模型设计。数据仓库建设的重点是整合层逻辑数据模型的设计。逻辑数据模型（Logical Data Model）是一种图形的展现方式，采用面向主题的方法有效组织来源多样的各种业务数据，同时能全面反映银行复杂的业务规则，支持不同类型的分析应用。它使用统一的逻辑语言描述银行业务，是数据管理的分析工具和沟通交流的有力手段；同时还能够很好地保证数据的一致性，是实现商务智能（BusinessIntelligence）的重要基础。它所遵循的设计原则如下：

①中性。整合模型具有应用中性的特征，从业务逻辑角度以关系模型方法进行建模，涵盖了银行所有的业务范围，并可以满足不断产生的业务发展需求。整合模型层采用的这种语义关系建模的设计方式，保存了各种分析性应用需要的所有业务数据以及这些数据之间重要的业务规则，体现了其作为数据仓库的基础数据层满足不同应用对数据的使用需求的功能。整合层模型原则上不为任何特定的应用进行针对性的设计，模型不会由于现有应用的变动或者对新应用的支持而在结构上重构，这体现了模型对应用支持的中立性。

②一致性。作为基础数据平台设计基础的逻辑数据模型必须在设计过程中保持一个统一的业务定义，比如当事人的分类等应该在整个企业内部保持一致，将来各种分析应用都使用同样的数据，这些数据应按照预先约定的规则进行刷新，保证同步和一致。如外部客户信用等级和银行内部信用等级数据必须依照一套相同的存放规则进行处理，它们和其他数据的关联以及刷新的频率等都应该保持同步。

整合层模型中对金融机构的重要业务元素以及一些业务规则进行了规范化的处理，例如所关注的所有个人和组织都统称为当事人，它是一个中性的概念，可以包含所有的个体以及各种可能的组合，如客户、员工、内部机构、竞争对手、合作伙伴等。统一这样的定义和概念，方便不同系统的开发人员在进行功能设计和展现时的沟通和交流。

③灵活性。整合层模型是一个基本上满足第三范式要求的语义关系模型，这种设计方法能够最大程度上减少数据冗余。

第三范式的设计同时保证了整合层模型的灵活性和扩展性。面对新的需求，整合层模型的这种结构能够进行简单、自然的扩展。这种特性使得整合层模型在设计过程可以“想大做小”——在有一个全局规划的同时，选定某些部分入手，然后再逐步进行完善。比如可以从通过一个客户的基本信息资料、持有产品、账户信息入手进行简单的分析，然后补充客户与银行的往来历史，延伸至全面的客户统一视图。

④满足详细粒度要求。为了满足将来不同的应用分析需要，整合层模型能够提供最小粒度的详细数据以支持各种可能的分析查询。以这些最小粒度的详细数据为基础，可以根据不同的统计分析口径汇总生成所需的各种结果。

物理数据模型是数据仓库基础建设的重要组成部分，它是以数据仓库逻辑数据模型为基础，结合具体的物理平台产品特性进行物理化而形成的，为最后搭建数据仓库实体表提供形式化定义。物理数据模型和逻辑数据模型在结构上的主要区别在于：

①不包含逻辑数据模型中没有数据来源的实体或字段。

②新增一些纯粹用于后台加工的数据表或项。

③根据平台性能要求，合并、拆分逻辑数据模型中的某些实体。

在搭建数据仓库主题模型时，银行如果购买了成熟的金融行业数据模型产品，则可以对产品进行客户化，形成自有的数据模型；如果银行没有购买相关产品，也可以借助模型设计人员的经验，直接设计数据仓库模型。

业内可参考的数据仓库模型包括Teradata公司的金融逻辑数据模型FSLDM，以及IBM公司在IFW中的分类模型FSDM。这两个模型都可以作为指导数据仓库模型设计的范本。但是在当前银行的实践中数据仓库模型以Teradata公司的金融逻辑数据模型FSLDM为主。

在此以Teradata的金融逻辑数据模型主要参考，对数据仓库的逻辑数据模型进行简单的介绍：

在Teradata的金融逻辑数据模型中，将数据分为10个主题，分别是：

①当事人（PARTY）。是指银行作为一个金融机构所服务的对象和其可能感兴趣并进行分析的任意对象，如对公客户、同业客户、个人客户、代理机构、合作伙伴、交易对手、员工、分行、部门等。一个当事人可以同时有多种角色，例如，本行的一名员工同时是本行的个人客户。借助当事人主题的建立可以实现基于客户基本信息的分析，是实现以客户为中心的各种分析应用的重要基础。

当事人主题的数据是银行业务活动过程的关键数据要素，也是构建基于数据仓库的各类分析型应用的不可或缺的数据基础，在以客户为中心的商业经营模式过程中，这些信息显得尤其重要。

②协议（AGREEMENT）。协议是金融机构与当事人之间针对某种特定产品或服务而签立的契约关系，它可以是多样化的，如账户、客户和银行签订的合同等。当金融机构与客户之间针对某种产品或服务的条款和条件达成协议时，一个协议就会被开立，因此协议是客户和银行往来的重要载体。

该主题的模型结构能够存储银行和客户签订的或与当事人实际发生业务往来而产生的各种形式的协议，可以包含账户、合同、借据等。

协议主题所包含的各种信息是进行各种经营分析都会用到的核心数据，在应用领域中，协议信息担当着非常重要的角色。

③产品（PRODUCT）。产品：指为拓展市场占有率，满足客户更广泛需求而制定的可营销的交易品种的集合，产品是金融机构向用户销售的或提供给客户所使用的服务。如果有必要，可以包括竞争对手所提供的产品。

④内部机构（INTERNAL.ORGANIZATION）。内部组织机构是指金融机构的内部组织和业务单元，如分行、支行、储蓄所、部门、销售团队等。

内部机构是一种特殊的当事人。记录内部机构和雇员的静态信息，以及变化历史；记录内部机构之间、内部机构与雇员之间的关系信息及其变化；内部机构是内部绩效考核的起点和关键。

作为一种特殊的当事人，机构信息作为业务活动主体的一方在经营活动中扮演了重要的角色，也是进行各种管理分析所需的重要数据来源。

⑤事件（EVENT）。事件是一种资金或非资金的活动，可能需要也可能不需要银行与客户的直接接触，它记录了详细的行为和交易数据。包括存款、提款、付款、信用/借记卡年费、利息和费用、投诉、产品查询、地址查询、余额查询、市场调查、网上交易等。

事件主题所包含的信息是进行经营分析所需的核心数据。

⑥渠道（CHANNEL）。用户通过渠道获取相关金融机构信息、产品信息以及使用金融产品。金融机构通过渠道向用户销售产品或提供服务。

渠道与当事人、产品、协议、事件等其他实体存在各种关系。

渠道分为若干渠道类型。如柜台、ATM、网上银行、电话银行等。

渠道主题的数据以及渠道与其他主题的关系（如渠道与产品、渠道与当事人、渠道与事件的关系等），可以构建一些关于渠道的分析应用。

⑦财务（FINANCE）。财务主题主要包括银行的总账信息，是描述科目组织、控制、内部核算等银行核心科目账务以及预算管理有关的内容。

本主题的数据可以很好地支持各种和财务管理相关分析应用，特别适合通过多维数据分析工具使用数据。

⑧资产（ASSET）。本主题包括当事人所有的、具有价值且获得收益的事物。主要包括当事人的抵押、质押的有价资产信息，是进行风险管理，计算风险敞口的基础数据。

⑨地址（LOCATION）。地址主题是指银行希望关注或考察的任何层次的地理区域和地址。如国家、省份、城市、县、乡、村等。

地址主题包含“具体地址”、“地区”、“地理位置”等不同层次的信息。

该主题和事件、产品、渠道、内部组织机构、营销活动等主题都有着密切的联系。

⑩营销（CAMPAIGN）。营销活动是为了获取、维护、增强银行与客户的关系而开展的一些促销的活动。

营销活动是一些有组织的活动，其目的可以是为了把某些产品推向市场，也有可能是为了树立银行在市场上的形象。

无论是参考哪种模型，模型的设计流程是相同的，如图4-5所示。

4）数据仓库的数据整合与数据标准的关系。Gartner对数据整合下了一个最简单的定义：数据整合就是将不同的、独立的数据集合合并到同一个数据集合的活动。数据整合是商业智能（BI）流程的关键组成部分，可将来自多个源系统的数据进行整合，并将它们合并到数据仓库以作分析。

数据仓库的模型是按照主题进行设计的，而面向业务主题进行数据整合的难点在于，同一业务主题的数据常常出现在银行的多个源系统中，并且这些业务实例数据可能一致也可能不一致。产生这种局面的因素有很多，涉及管理、流程、系统、应用等各个层面，启动数据标准化工作是解决这类困难的一种行之有效的方式。

数据标准定义，即依托行业经验，基于银行现状，站在全行高度，梳理涉及核心流程的关键业务系统，分析数据结构、数据字典，规范统一概念、定义、属性以及关系，最终形成全行一致的业务术语，达成各部门人员对关键业务的统一理解，更好地支撑内部管理和外部监管的应用需求。数据标准定义的主要流程如图4-6所示。

定义好数据标准后，在数据整合过程中对数据标准的参考执行策略如图4-7所示。

在此指导原则下，把数据的整合分为三个层面：

①实体级整合：基于同一个被描述对象的整合，放在同一数据主题内，采用同一个数据实体进行记录，这种整合在数据仓库中要求充分整合。

②记录级别整合：这种整合更多在于主数据在主数据管理系统和从属数据管理系统中分布后的整合，以及事件基于不同交流程环节的整合。这种整合的基础是数据标准的定义和主数据管理系统的实施，在基于这两个前提下需要审慎对待。

图4-5 数据仓库逻辑数据模型设计流程图

③代码级整合：同样是跨系统代码定义和代码应用一致性的问题，需要在数据标准定义的情况下，采用审慎对待的原则。

5）数据仓库与数据管控的关系。对于数据仓库而言，数据管控非常重要。主要有以下几个原因：

①数据仓库是企业的跨系统的数据整合，对数据质量的要求非常高。而且数据仓库是企业集中的数据质量检核平台。

图4-6 数据标准定义流程图(www.xing528.com)

图4-7 数据标准对数据整合的指导原则

②数据仓库的数据整合非常依赖数据标准的指导。

③数据仓库是元数据管理的重要环节，因为数据仓库是企业的数据中枢。

数据管控是为满足企业内部对信息的需求，提升企业信息服务的水准而制定的相关流程、政策、标准以及技术手段，从而使企业能将数据作为企业的核心资产。它是数据仓库系统充分发挥业务价值的保证，企业商务智能应用水平发展越高，就越能体现出数据管控的价值。

数据仓库作为全行业务数据的汇集地，承担着数据的应用、验证和反馈工作，数据管控与数据仓库的关系与主要工作切分如图4-8所示。

6）元数据和数据仓库的关系：

①为数据仓库提供最新的准确的源数据结构。

②制定模型设计和ETL开发的规范和模板，方便数据仓库元数据采集，同时提高数据仓库建设的质量。

③提供血缘分析，帮助数据仓库分析数据来源、定位数据质量原因、优化ETL任务依赖关系和ETL调度流程。

图4-8 数据仓库与数据管控关系示意图

④通过影响分析，帮助数据仓库制定基于元数据的开发变更管理流程。

7）数据质量和数据仓库的关系：

①为信息调研提供样本数据和初步的数据质量分析。

②帮助制定数据仓库内部数据质量问题管理流程。

③提供数据质量规则配置模板和接口。

④接收数据仓库不同数据层次的数据质量检查规则。

⑤共同确定数据质量检查脚本的调度执行机制。

⑥接收数据仓库的数据质量检测结果。

⑦数据标准和数据仓库的关系。

⑧为模型设计提供当前的数据标准定义和标准映射结果，供数据仓库参考。

⑨接收数据仓库关于标准执行的反馈结果。

（3）共性加工层

1）什么是共性加工层。共性加工层是解决多应用领域的共享性数据加工以及共享性汇总结果存储的区域。共性加工层的设计原则如下：

①需求驱动：共性加工层是因为需求而产生的，所以一定要基于需求，可以借鉴行业经验，但是每家银行的应用建设过程有所不同，所以本行的需求才是根本。

②提炼共性：共性加工层是提炼不同应用公共指标，提炼的程度太高会失去通用汇总层的意义，个性化程度太高会导致与应用层无区别，所以模型设计人员的经验很重要。

③架构分明：共性加工层再分明细加工层和汇总加工层，指标库三部分，明细层是主要是客户、协议、交易等主题的原始明细的扩展存储，是按照便于业务理解得宽表方式的重新呈现；汇总层是基于客户、产品、机构、渠道等维度的聚合；指标库则是有特定意义的度量值和固定维度的组合分析。

④迭代开发：共性加工层的建设是一个循环往复的过程，不可能一步到位。随着应用的增加和对应用理解的深入，共性加工层会不断地丰富，提升其业务价值。

2）共性加工层的设计思路。共性加工层的设计思路通常有视图和物理表两种方式。

①视图。视图的加工逻辑写在视图定义中，由数据平台开发人员建立。当业务应用人员需要访问时，直接通过视图进行检索。

视图的优势在于：视图本身并不存储数据，不需要额外的空间开销；视图的逻辑是写在视图定义中，不会提前按此逻辑预加工生成数据，修改逻辑时就很容易；视图本身不存储数据，对于稍有不同的需求就可以建多个视图来实现，不会形成任何额外存储开销。

视图的劣势在于：在实际操作访问时，是按视图定义中的逻辑展开，在基础数据库中进行查询。视图逻辑很复杂时，查询速度会比较慢；当多个人在同一天要多次访问同一个视图时，就会重复消耗数据库资源，同时每个人都会面对较长的查询等待时间。

②预加工物理表。预加工物理表将加工逻辑写在ETL程序中，由开发人员开发，定期运行这些程序将最终所需的数据加工好放在物理表中。当业务应用人员需要访问这些数据时，直接访问这些已经预加工好的物理表即可。

预加工物理表的优势在于：复杂的加工逻辑已经在ETL程序运行时一次性的处理完毕，访问效率会比视图要好；基于基础数据表的复杂的加工逻辑已经在ETL程序运行时一次性的处理完毕，当需要多次访问时节约开销和提高效率的优势就会体现得更充分。

预加工物理表的劣势在于：预加工物理表本身需要存储数据，需要额外的空间开销，特别是当目标数据集较大时，这些开销还是非常可观的；预加工物理表的逻辑是写在ETL程序定义中，会提前按此逻辑预加工生成数据，因此修改逻辑时就很复杂，而且还涉及历史数据的问题。

在共性加工层设计时视图和物理表的选择是一个比较复杂的问题，不可一概而论。最重要的决定因素是系统的配置情况，其次还有用户对于查询的效率期望，中间表数据被重用的可能性，表数据量的大小等。

3）共性加工层的实现方式。共性加工层的实现方式主要有三种，分别为预链接、预计算和预聚合。

①预连接。预连接指的是原来分散在近源模型层和整合模型层中的很多信息根据应用的需要进行预连接。

②预计算。预计算通常将规则比较复杂，或者计算时间较长的数据预先计算出来，比如日均、重定价日等。预计算的数据粒度不变，仍为最细的账户粒度。

③预聚合。预聚合维度建模方式对共性加工明细层进行汇总和聚合，不再是最细粒度了。共性加工层的数据并非都是来源于仓库整合模型层，同样可以基于ODS的贴源模型直接进行共性加工层的加工；在共享加工层还存在大量的数据集市加工结果的回流。这些回头到共性加工层存储的集市计算结果，意味着有在其他集市应用领域共享的必要性。

（4）实时数据决策层 实时数据决策层是用来支持实时决策的数据整合存储与处理平台。随着管理决策水平的提升，实时决策在商业银行的业务应用中越来越重要，特别是在营销、风险监控以及运营管理等多个业务领域。将实时决策区纳入数据整合部分主要原因如下：

1）实时决策越来越多地呈现跨系统数据需要被整合的特性，而不是依赖单一系统数据可以完成的。

2）实时决策的结果也可以被数据整合平台进行存储，并且服务于业务应用。实时决策当前在商业银行的应用中目前主要依赖于两种模式：

1）模式一：消息总线+内存规则引擎机制。该模式主要是指数据从消息总线获取，作为决策依赖的数据源；决策在数据驱动的情况下，依赖于部署在内存中的业务规则引擎进行快速计算和实时决策。

该模式响应的实时性高，对数据的整合性要求小。一般不依赖于数据整合平台的建设，更加作为业务生产系统的一个部件存在。但是该部件也和数据整合平台存在一定的关系，包括：

①在内存规则引擎的初始化的过程中，初始化数据可能来自数据整合平台，该数据参与实时决策。

②内存规则结算结果，如果需要参与长期的决策分析，同样需要回到数据整合平台进行永久化存储。

2）模式二：动态数据仓库模式（Real time DW/Active DW）。动态数据仓库则是通过数据的准实时加载，整合已经存储的数据和当前准实时小批量获取的数据，产生动态决策的计算结果。

动态数据仓库的实时性低于模式一、但是对于数据整合性是其优势。能够支持的数据计算范围和计算的复杂性更有伸缩性。

无论是模式一、还是模式二对于数据流转的依赖性都很强。都是属于数据流转平台和数据整合平台的强耦合性应用。因此，实时决策最大的代价就是实时流转的处理，无论是通过消息总线还是数据总线，都需要有额外的负荷。因此，在应用该技术的过程中，需要严格的评估成本。实时性要求越高，成本代价越大。

在目前商业银行的实践中，因为大量的商业银行已经部署了消息总线，而且基于模式一的实时性更强，所以在营销分析领域和风险侦测领域使用广泛。而模式二在主要应用在实时的业绩监控追踪等领域，因为这个领域要求的时效性没有那么高，同时又需要历史数据计算的支撑。这两种模式都有存在的价值和意义。

从准实时数据抽取角度看，目前采用的主要工具都是基于日志的数据抽取技术，典型的技术工具包括IBM公司的CDC，以及Oracle公司的GoldenGate。实时过程中，打开系统日志，基于日志的抽取和解析对生产系都有一定的性能消耗。部署这类工具的过程中应该慎重考虑。

（5）历史数据存储层 历史数据存储平台，主要是指支持历史数据存储与访问的数据平台。历史数据存储平台在银行数据存储中应该承担如下职能：

1）各个业务系统产生的原始业务数据的归档保存。

2）数据整合平台中ODS层、数据仓库整合层、以及共性加工层中有价值的数据的归档保存。

3）数据应用区域加工结果的历史数据归档保存。

历史数据存储平台在银行的数据访问和应用支持中的作用是什么呢？通常定义如下：

1）满足深度交易历史数据查询，为核心系统减负。

2）满足审计、司法查询中基于业务数据原貌的深度历史探索。

3）支持数据整合平台和数据分析的平台的历史数据获取。

4）支持业务系统和部分管理分析应用的初始化工作。

因此按照历史数据存储平台的特征，应该是贴源、深度历史存储、支持简单查询和少量复杂查询、支持数据大批量的导入导出，大数据量的低成本存储。

从目前技术发展路径看来，大数据技术应该是历史数据存储平台合理的选择。

2.数据整合领域的专题分析

在当前云计算、移动互联、大数据和社交技术综合应用的企业级数据化整体解决方案发展背景下，新的技术在银行也在快速的应用过程中。随着大数据技术日趋成熟，互联网和物联网推动着新形态数据的持续产生，新的数据仓库架构也悄然发生转变，即由传统关系型数据库支撑的结构化数据仓库，演变为由结构化、半结构化、非结构化、流状态数据处理等多种数据处理手段和模块相结合，构成的逻辑数据仓库。

这种新的企业级数据仓库平台应该理解为广义的大数据平台，也就是把基于传统的结构化数据的数据仓库和狭义的处理半结构化、非结构化信息的大数据技术融合形成的逻辑上的新的数据仓库体系，该平台应该具备以下的特征：

1）将传统关系型数据库技术和大数据技术的互补性整合的能力。

2）能够将结构化和非结构化数据进行无缝关联的分析能力。

3）信息量爆炸增长对线性扩展能力的要求。

4）低价值密度的数据存储对平台的开放性和成本降低的诉求。

5）实时数据处理和分析决策技术的采用，如内存数据库和流处理技术等。

以上技术手段，结合企业自身数据管控和综合利用的能力的提升，将让企业级数据仓库平台在大数据时代为企业创造新的价值。