银行信息系统架构中的数据架构

在商业银行的架构实践中，应用、数据、技术是三个不可或缺的因素，而其中数据又是连接应用和技术的纽带。应用架构决定或者影响了业务的实现，业务操作产生了数据，数据在银行各个应用系统之间进行流转，同时数据的存储、处理以及流转都需要技术的支撑。当商业银行的应用越来越多，数据之间的依赖关系也越来越复杂。数据从单一系统产生，在多个系统内进行传递，完成完整的业务流程，或者用于整合、分析和决策。在此过程中，银行越来越关注数据存储的有效性、处理的效率、流转的及时性和一致性等问题，这些问题就需要通过合理的数据架构设计来解决。

数据架构设计贯穿于数据的全生命周期（见图4-1），从数据产生、流转、整合、分析应用、归档和消亡各个环节，对数据的模型策略、访问机制和存储方式进行设计。无论数据的逻辑模型组织，还是数据的物理存储，其目的是为了满足不同的数据操作的有效和便捷性需求。

图4-1 按照数据生命周期的数据分层

下面就针对数据生命周期各环节的数据架构设计应考虑的问题进行简单的描述。

1.数据产生

数据的产生，源自于业务的发生。按照商业银行基本的业务定位，解决货币市场融资，经营信用和货币的时间成本，同时兼顾支付、结算等职能，是当前商业银行的主要业务本质。随着这些业务的发生，银行形成了其经营的金融产品与客户之间的契约关系。这些金融契约附着的是银行产品的定义、客户的描述、合同的约定、账户的形成、账户发生交易的渠道选择，以及一笔笔的对账户、客户、合同等信息进行增删改查的交易信息。

而这些数据信息在商业银行的不同业务处理的应用模块中产生，如存款、贷款、国际结算和信用卡等，这些信息看似模块化独立产生，但是又有很强的关联性。这种关联性体现在从开户、合同签署、账户形成、到交易核算等流程环节上的关联性，也体现在从数据产生到整合、分析、决策后再回归指导业务发生的关联性。

银行的数据产生机制既不等同于互联网的碎片化信息，又区别于物联网的传感器产生的结构简单的时序信息。而且随着业务创新和产品创新，数据在物理上越来越呈现离散化，从关联逻辑上的紧耦合成为并行发展的趋势。技术上的离散和业务上的紧耦合的双重趋势带来的对数据架构的不断挑战。特别是在数据产生环节，如何在此环节中进行合理的数据架构设计，直接影响到后续数据的整合和应用。

因此在数据产生环节，对数据架构提出的挑战主要包括：

1）数据产生必须有效地支持业务流程的运作。

2）数据产生环节直接影响了用户的业务体验，所以保证数据单笔增删改查效率是这个环节技术上需要重点考虑的因素。

3）尽量避免在数据产生的初始环节出现数据的不一致，从源头开始把控，因此在数据产生环节必须加强主数据管理。

4）在互联网金融时代，随着银行业务的互联网化，应该关注数据产生环节是否具备新的特征，以及如何满足这些特征。

2.数据流转

数据在产生之后，基于数据之间的关联性，数据需要被交换和流转。因此数据的流转是数据生命周期的第二个主要的环节。

数据的流转可以是支持业务流程运转需要的实时流转，同样也可以是支持从前台操作、中台控制到后台决策的准实时或者非实时的批量数据流转过程。

在数据流转环节中我们需要借助数据架构解决的问题包括：

1）支持不同数据流转的方式有哪些？这些不同的流转方式能帮助商业银行解决什么问题，支持什么业务场景？

2）如何保证数据流转的效率？在保证效率的前提下数据是否应该被适度的处理和暂存？

3）数据流转的过程中如何保证数据的一致性？

4）数据流转是否应该被管理？应该如何管理？

3.数据整合

数据在不同的业务系统中产生之后，完成业务流程的流转，在不同的应用系统中存在一个或者多个版本，不同的数据版本之间，可能存在冗余和不一致。同时即使是从产生环节看上去应该是独立的数据信息，从数据分析领域看可能要具备一定的整合性，如信用卡系统的客户和个人住房贷款的客户从银行营销角度看，应该整合为一个客户视图；国际结算系统的机构和支付系统的机构也应该被当作银行统一的内部机构来管理。因此从保持数据一致性和满足业务分析需求这两个角度看，数据存在整合的意义。

数据的整合分为物理集中和逻辑整合两个层次。物理集中是讲分散在各个业务系统中的数据进行集中存储，这个任务在银行通常由操作型数据存储系统（ODS系统）承担。而逻辑整合更多由企业级数据仓库（EDW）来承担。数据整合系统的建设，在企业数据架构中是非常重要的环节。

因此在这些银行基础数据的整合过程中对数据加工提出的挑战包括：

1）哪些数据需要整合？

2）应该如何整合？整合的业务指导和参考依据是什么？

3）如何整合才是高效的？

4）整合形成了数据的归集，这样作为企业级集中的数据基础平台是否又成为企业新的风险点？

5）如何定位ODS和数据仓库呢？它们的建设顺序是什么？

6）ODS和数据仓库一个面向物理集中，一个面向逻辑整合，它们的建设方法分别是什么？(https://www.xing528.com)

另外企业的数据整合是否仅仅是指ODS和数据仓库呢？

其实，ODS和数据仓库仅仅是基础数据整合的概念，在银行的数据应用过程中的还有很多共性加工逻辑，这些汇总加工的数据具备相同的业务口径和业务加工逻辑，同时又是多个应用领域的统计分析的需求，通常称之为共性加工层或者通用汇总层。一般理解，我们把这一层数据的构建划分为数据仓库基础数据整合层之上的一个独立的数据层次，纳入数据仓库的建设和管理体系。

无论是基础数据整合层还是共性加工层，除了物理存储和逻辑模型外，对它们更有指导意义的就是数据标准，包括指导基础数据整合的基础数据标准和指导共性加工层建设的统计指标标准。因此数据管控领域的数据标准化的定义也是需要在数据整合中重点讨论的内容。

随着互联网金融和大数据时代的到来，数据整合的概念已经不仅仅局限在针对银行传统线下结构化数据的整合，而应该逐步包括针对线上或者其他业务环节产生的非结构化、半结构化数据处理能力的提升。这种整合能力提升的需求，源自于银行对从原始业务产生的非结构化信息、互联网金融产生的数据、外部购买的大数据信息等原来关系型数据库不适合处理的信息中挖掘新的业务价值的需求。因此，以传统的ODS+EDW为内涵，以大数据为外延的新的内部、外部、结构化、非结构化数据整合的大数据平台成为未来企业级数据整合的目标，业内把这种新的数据整合平台叫作“逻辑数据仓库”体系。因此，逻辑数据仓库也是在数据整合的数据架构中需要涉及的内容。

当然在逻辑数据仓库完成数据多样性和综合性整合的同时，银行对营销和风险监控领域的实时决策和历史数据存储也有需求。实时决策系统RDSS（Real time Data Sup-porting System）和历史数据存储HDS（Historical Data Storage）对数据获取的时间成本和处理成本的平衡提出了挑战。实时决策系统要求数据高效获取和处理，因此数据的处理成本高，这种情况下应该被整合处理的数据量应该减小，也就是用高成本的处理技术去处理价值密度高的数据；而历史数据存储则恰恰相反，是用低成本存储和低成本的数据处理技术，处理价值密度低的数据，来满足业务对长期积累的大量历史数据简单查询和对时效性要求比较低的数据探索的需求。

由此可以看到，数据整合是数据架构中内容最多也是最重要的环节。

4.数据应用

按照银行业通用的实践，商业银行通常会参考银行业务能力模型来判断需要从哪些领域提升业务能力。业务能力主要集中在客户关系管理、风险控制、运营绩效、财务分析、合规管理、监管报送和资产负债管理等领域，银行通过数据将上述领域的业务能力表达出来。这些管理分析大多侧重于后台，同时数据也被应用于银行中台对缺口、收益、风险、价值等实时计量和估算过程中。

数据应用在银行目的是通过数据分析和应用建设，服务于银行的管理决策、精准营销和风险控制等要求，这是银行对自身业务的不断统计、分析、优化的过程，也就是数据逐步转为业务价值的过程。这个过程可以简化理解为以下的模型，如图4-2所示。数据价值在被挖掘的过程中，可以沿着以下两个维度逐步得到提升：

图4-2 数据价值转化过程

1）数据按照业务逻辑加工的“深度”：从原始的明细，到汇总和统计，深入地构建数据模型探索的过程，就是数据逐步被深度加工、探索价值的过程。

2）数据价值被探索后，还需要通过有效的机制传导出去，以支持业务决策：信息的传导又区分为被动推送、主动探索、智能交互三种模式。

在数据应用环节，从数据架构角度应该讨论的主要问题如下：

1）什么是银行的业务能力模型，银行的业务能力应该包括哪些方面？

2）哪些业务能力是当前数据应用支撑的重点？

3）在不同的领域，数据集市如何支撑管理分析类应用建设？

4）数据集市和数据整合平台之间的定位有什么差异性？

5）数据集市的建设方法是什么？有多少种数据集市类型，不同的数据集市类型的优劣势是什么？

数据应用价值的发挥，除了直接依赖价值发掘的过程外，还有另外一个角度就是对数据管控和治理的依赖。

数据产生决定了数据应用过程中数据有没有的问题；数据整合决定了数据应用过程中数据获取难易程度、时效性的问题；数据治理决定了数据应用过程中数据是否可用、好用的问题。数据应用是建立在数据产生、数据整合和数据治理基础之上的。

数据应用通过商业智能门户为用户提供服务，主要服务手段包括：报表和查询、专业计算引擎、数据分析和数据挖掘等。

5.数据归档与消亡

从某种意义上讲，数据归档与消亡和历史数据存储一样，是基于数据时间价值评估和存储成本之间的平衡。对于基本不具备时间价值的数据，即使偶尔有查询访问的需求，也可以纳入归档管理系统。但是当前随着存储的低成本化，以及基于低成本存储的数据访问手段的完善，归档数据同样可以被查询、访问甚至简单分析处理。

对于被销毁的数据，无论是电子化数据，还是纸质保存的原始凭证，从业务意义上来说就是完全不具备任何访问价值的数据，但是要参考国家针对信息在线保存、档案管理等法律法规的要求进行管理和处置。

除了依托于完整数据生命管理流程的考虑外，在数据架构的设计过程中同时也要考虑数据分类、数据被操作的方式、当前数据处理技术成熟度特征等多种因素，这些因素同样会影响数据架构的设计合理性。

以上分析了在数据架构的每个层次中，商业银行需要考虑的问题。经过这样的分析，其实已经从基本的数据分层初步勾勒出数据架构的基础版本，如图4-3所示。

在下列章节会结合数据架构原则、数据架构设计的方法、数据架构的最佳实践参考对每个层次的数据架构特征进行详细的阐述。同时也会结合新的业务、技术发展特征给出趋势性的分析。

图4-3 数据架构设计流程