首页 理论教育 银行信息系统设计原则

银行信息系统设计原则

时间:2023-08-03 理论教育 版权反馈
【摘要】:数据架构的设计原则在遵循架构设计通用原则的情况下,有数据架构自身的特殊考虑。合理的数据架构设计应该是解决以下问题:功能定位合理性问题;面向未来发展的可扩展性问题;处理效率高效,或者说高性价比的问题;数据合理分布和数据一致性问题。

银行信息系统设计原则

数据架构的设计原则在遵循架构设计通用原则的情况下,有数据架构自身的特殊考虑。合理的数据架构设计应该是解决以下问题:功能定位合理性问题;面向未来发展的可扩展性问题;处理效率高效,或者说高性价比的问题;数据合理分布和数据一致性问题。

按照业务数据架构设计的实践,通常在数据架构设计中,遵循以下原则进行处理:

1.数据分层原则

首先,银行数据按照生命周期就是分层次的,因此数据分层原则更多应该解决的是层次定位合理性的问题。在给每个层次进行定位的同时,对每个层次的建设目标、设计方法、模型、数据存储策略及对外服务原则进行一定的约束性定义和控制。

按照之前对数据生命周期的阐述,数据基本分层应该包括:

(1)数据产生层(源业务系统层) 原始数据产生,通过应用对支持业务全流程操作的满足进行原始数据发生的记录,同时数据记录的方式直接影响了业务流程处理的效率。而对于银行这样用户要求快速响应的架构,在数据产生环节如何保证每笔交易处理的效率是首要应该考虑的问题;其次银行业务涉及“钱”的问题,所以对业务发生过程中数据记录的事务完整性和准确性也有很高的要求。

(2)数据流转层(数据交换层) 支持数据实时流转和非实时交换。在交换过程中可能有数据的简单处理与存储,该存储仍然是为了支持交换为目的,而不是以数据整合、分析为目的。在数据流转过程中最需要保障的数据流转的效率。

(3)数据整合层 可以分解为五个方面:

1)实时决策层:解决在业务发生的过程中,通过近实时的数据流转支持的业务高时效性分析与决策的数据存储与处理层。

2)操作型数据存储层(ODS):通过贴源模型的短期历史存储,满足企业数据时效性高的导出以及应用接入服务;满足数据的物理集中的需求。我们把这一层又叫作贴源模型层或者近源模型层。

3)企业级数据仓库层(EDW):通过面向主题的、范式化的模型设计,满足银行基础明细数据整合、长期历史存储的需求,适度屏蔽业务系统变化对数据分析应用的影响。通常把这一层又叫作数据仓库层、基础数据层或者整合模型层。

4)通用汇总层(GDM):这一层主要负责跨应用领域的共享性加工逻辑处理和共享性汇总数据与指标数据存储。通过对多个应用领域共享加工逻辑的共享性计算与存储,解决数据重复加工计算、冗余存储,因此也把这一层叫作共性加工层。

5)历史数据存储层:通过低成本存储技术解决历史数据存储的问题,满足针对历史数据的基本建设和简单访问功能。

(4)数据应用层 面向应用逻辑加工和应用访问为目标的数据加工和存储体系。通常又叫作数据集市层(DM)。

(5)数据归档层 支持数据归档以及基于归档的数据简单查询访问的数据存储体系。

在整合层中提到了历史数据存储层和数据归档层有一定的重复。因此,数据归档只进行按照数据生命周期管理策略进行归档策略的讨论,而面向访问的部分,在历史数据存储中进行阐述。

在数据架构中,尽量避免数据的混合型存储,即用一个数据层次,满足多种数据功能的混合层次化设计。如果数据架构层次不清晰,可能导致局面混乱、不易管理以及对技术架构体系选择的干扰。

在这些数据层次中,最重要的是数据整合层、数据应用层的建设,整个企业绝大部分的数据决策是由这两层来支持的。在这两层中,最重要的就是:操作型数据存储层、数据整合层、通用汇总层、数据集市层的定位和建设。理解和区分这四层的业务目标、存储数据内容、存储格式、存储模型、存储时间周期等角度的差异性,是设计好的数据架构的核心。

2.数据处理效率原则

合理的数据架构需要解决数据处理效率的问题。所谓的数据处理效率并不是追求高,而是追求合理,因为所有的数据存储和处理都是有代价的。换句话讲:数据处理效率的问题可以说也是解决满足数据处理效率要求的成本合理化的问题。

数据处理的代价主要就是数据存储与数据变迁的成本,在实践中,真正影响数据处理效率的是大规模的原始数据的存储与处理。在这些原始明细数据的加工、处理、访问的过程中尽量减少明细数据的冗余存储和大规模的搬迁操作,可以提升数据处理效率。

减少明细数据的冗余存储和搬迁,通常应该采取的策略如下:

1)跨平台、跨层次允许访问。应用更多是逻辑上的概念,统一的数据存储跨层次、跨平台、跨应用的被访问可以减少不必要的数据冗余存储和搬迁。在这种访问的过程中,尽量采用逻辑视图映射的方式,保证数据源统一。

2)加强综合性数据服务平台建设,通过数据分析访问手段的多样性,满足用户对存储在不同层次中,不同形态数据的获取和访问。特别需要减少针对临时性分析需求的固定加工处理,而是通过即席查询体系来满足用户。

3)即使存在数据的搬迁,尽量采用先加工,后搬迁的策略,这样可以只搬迁处理后缩小的结果数据。

4)定期对数据加工进行清理,对不必要的数据加工逻辑以及中间结果和最终结果进行清理,保证存储的有效性。

当然,尽量减少明细数据的搬迁和冗余存储,并不是绝对的,适度的数据搬迁也是必须的,例如:(www.xing528.com)

1)业务系统不适合进行长期的明细数据存储,历史数据保留太久,会降低系统的处理效率,所以定期必须进行历史数据的搬迁操作。

2)某些特殊的应用系统,需要特殊数据安全隔离防护手段,这样为了保证它对明细数据的访问,不得不进行独立的明细数据存储。

3)某些特殊的计算规则引擎需要明细数据的支撑才能进行处理,可以进行明细数据搬迁。

4)某些应用场景需要保证访问的效率,可以采用空间换取时间的方式进行处理,采用适度冗余的方式来换取访问的效率。

以上也仅仅是一些常见的特殊场景,而不是穷举。因此,这是一个相对性原则,而不是绝对性原则,需要在具体的场景中灵活把握。总之,明细数据的冗余存储和搬迁操作是数据架构中解决数据处理效率问题的关键

3.保障数据一致性原则

合理的数据架构能够有效地支持数据管控体系,很多的数据不一致性是因为数据架构不合理所导致的。其中,最大的原因就是数据在不同层次分布中的冗余存储以及按照不同业务逻辑的重复加工。因此,如何在数据架构中减少数据重复加工和冗余存储,能够有效地保障数据一致性。

在这个原则中需要重点关注以下几点:

(1)推动数据产生环节的主数据管理策略 首先应该在数据产生环节坚持推动主数据管理策略,借助于合理的数据分布,解决主数据在主数据系统与从属系统之间的逻辑引用关系。其中,最重要的环节是主数据的数据识别,以及主从系统数据分布的管理策略。在不同的业务系统引用主数据的过程中,减少主数据的识别信息以及属性信息的冗余存储,保证主数据一致性。

这个原则重点应用于业务产生的原始业务系统,同样在数据整合层的基础数据整合层也非常重要。

当然主数据的管理带来的是数据在不同系统分布情况下的访问策略的调整,不排除增加了某些主数据系统的系统关键性风险以及其他从属系统的访问效率下降,但是质量和效率有时候就是一对不可调和的矛盾。因此,哪些数据才应该作为主数据被强制要求一致性保证,哪些数据是可以非强制性要求的,哪些系统必须实时同步,哪些系统可以采用非实时同步策略,哪些系统之间存在紧耦合,哪些系统之间是松耦合,以上是架构在具体设计过程中需要去把握平衡的。

(2)数据标准参考策略 主数据一致性的保证严格依赖于对数据标准的定义,数据标准中应该严格定义主数据定义、主数据分类、主数据编码、主数据识别和归并策略、主数据信息属性、主数据信息属性的覆盖原则和取用策略。这些数据标准的定义决定了主数据系统建设的业务逻辑。

当然,主数据系统的实现同样依赖于业务流程的详细梳理。

(3)避免管理分析类的重复加工和冗余存储 商业银行在数据应用中经常存在的指标差异和口径不一致的问题,都是由于重复加工和冗余存储造成的。因此,将基础模型层、通用汇总层定义为基础数据、汇总数据共享加工和共享存储的层次,解决跨应用领域业务加工逻辑不一致的问题。

4.保证数据架构可扩展性原则

数据架构设计的可扩展性原则可以从以下几个角度来保证:

1)首先是基于分层定位的合理性原则之上的。只有清晰的数据层次定位,以及每个数据层次合理的模型和存储技术策略,才能更好地保证数据架构在未来支持新增业务类型、新增数据整合要求、新增数据应用要求的过程中的可扩展性。

2)其次,架构的可扩展性需要对数据存储模型和数据存储技术也进行考虑。其中,最重要的数据仓库模型的可扩展性:对于数据仓库的数据模型而言,如何具备一定的可扩展性,在随着原始业务变化,尽量保证模型的稳定性,减少对下游数据应用的冲击是必须被考虑的问题,因为商业银行的业务总在面临不断的新增业务和业务创新。有数据“仓库之父”之称的BillImon经过对关系型数据存储理论的研究,在其提出的数据仓库理论中很早就提出在数据仓库的模型设计中遵从数据库理论的第三范式的设计要求,提出了第三范式的数据建模策略在保证数据关系完整性的同时,具备很好的模型可扩展性。

从数据存储技术的角度而言,无论是数据整合平台还是数据应用平台,都把它归纳于OLAP处理领域。这个领域长期面临的就是数据的不断的膨胀,以及数据膨胀过程中复杂访问和并行处理的需求。通常建议在这个领域尽量采用可扩展的系统架构。

5.服务于业务原则

合理的数据架构、数据模型、数据存储策略,最终目标都是服务于业务。商业银行快速的业务流程运转,以及高效而且精准的业务决策支持是商业银行两方面的业务目标。因此,有时候在面临满足某种业务特殊目标的时候,可以为了业务的体验,放弃之前的某些原则。

例如,不建议数据的冗余存储,但是为了保证某些访问的效率,我们可以采用“空间换取时间”的策略,借助适度的数据冗余来换取数据访问的效率。

所以“打破原则”和“架构管控”是相互依存的两个策略。一味地打破架构设计原则会导致架构的失控、处理的混乱,而严格的遵守原则又有恪守成规的问题,不能满足某些业务的最佳体验。在打破原则的同时,需要增加的是管控策略。即对所有打破原则的设计进行记录以及管理,尽量减少打破原则的混乱,让原则在被打破过程中做到架构可控,成本收益分析合理,通过管控手段,保证对特殊场景的运行维护策略,以及一致性的保护。

以上是在数据架构设计过程遵循的一些基本的原则。可以在数据架构设计过程中参考使用。

遵循架构设计的原则,进行数据架构的设计。在数据架构设计过程中,首先,要采用正确的数据架构设计方法,其次,需要把数据架构和应用架构、技术架构相融合。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈