金融行业批量系统存储架构技术选型分析

一、金融行业批量系统业务特征提起批量业务，从事银行业科技的人员都会非常熟悉。白天的柜台、终端以及其他渠道的交易业务需要实时修改账户信息，晚上需要跑批来完成例如账务清算、利息计算、报表生成等系列业务。这就是银行典型批量业务需要完成的事情。而对于其他的保险及证券等金融行业，同样会有类似的批量业务。通常金融行业业务系统产生的明细数据要经过加工处理，按照一定逻辑计算成需要的结果，用以支持企业的经营活动。这类数据的加工任务一般会有很多个，需要批量完成计算。大部分业务统计都会要求以某日作为截止点，而且为了不影响生产系统的运行，跑批任务一般会在夜间进行，这时候才能将生产系统当天产生的新明细数据导出来，送到专门的数据库或数据仓库完成跑批计算。第二天早上，跑批结果就可以提供给业务人员使用了。和在线查询不同，跑批计算是定时自动执行的离线任务，不会出现多人同时访问一个任务的情况，所以没有并发问题，也不必实时返回结果。但是，跑批必须在规定的窗口时间内完成。比如某银行的跑批窗口时间是晚上到第二天早上，如果到了早上跑批任务还没有完成，就会造成业务人员无法正常工作的严重后果。而且跑批任务涉及的数据量非常大，通常是需要很多系统的数据，同时包含历史数据；计算逻辑通常非常复杂，不仅处理较长、步骤较多、而且计算频繁，是需要在某些业务模型基础之上去完成的；跑批时间经常是以小时甚至更长时间粒度来计算的。随着业务的发展，数据量还在不断增加，跑批数据库的负担快速增长，就会发生整晚都跑不完的情况，严重影响用户的业务，这是无法接受的。二、金融行业批量业务的数据管理要求2.1数据处理量级提升的要求近些年来，对金融行业批量业务挑战最大的可能就是数据量的剧增了。以某消费金融公司为例，该消费金融公司于2015年营业，截止到2020年，历经4年多风雨，总注册用户数8000万，活跃用户数2500万，账务系统的核心表累计数据量已达到单表15亿行以上，而且还在高速增长中。这是大多数金融企业面对互联网业务时都会遇到的巨大挑战。很多金融行业批量业务系统在面对海量数据的不断挑战，数据库从传统的Oracle单库模式走向集群模式，从单表单库走向分库分表切片模式，甚至开始选择NoSQL、NewSQL解决方案；基础架构从从前的小型机走向一体机，从一体机走向分布式模式。总而言之，金融行业批量业务在当前以及未来一段时间内面临的最大挑战还是数据量的升级，这必然要求数据处理层面具备更强的数据容纳以及过程处理能力。2.2数据批量读写效率提升的要求对于金融行业的批量业务，从业务层面来讲，它是账务清算、利息核算、报表分析之类的分析业务。从数据处理层面来讲，它是对多系统多维度数据进行读取、归类、统计、分析、写入的整体过程，里面伴随着大量的顺序读写全表操作，数据量会非常大。而传统的关系型数据库最忌讳的却是数据库当中的全表扫描操作，当单表数据量达到一定程度之后，必然会影响数据库的整体检索效率，这二者之间似乎是有不可调和的矛盾。于是行业内企业开始寻求相应的解决方法，一方面通过各种方法来提升数据处理平台本身对数据读写的处理效率，例如利用全闪存储架构从物理层提升数据的处理效率，利用分布式存储架构来提升存储引擎的吞吐效率；另外一方面通过对业务逻辑及模型的革新创新来寻求新的整体解决方案。2.3数据处理逻辑多样化融合的要求以银行的批量业务为例，传统的批量业务系统，无论是账务类的总账跑批，还是监管报送类的报表跑批，它们都是基于传统的二维关系数据模型，跑批的逻辑都是基于银行特有的业务模型。这种模式下的批量业务都会涉及到数据一致性的问题，典型的场景就是外键关联的场景。当我们对其中一张表的数据进行更改的时候，如果它有相关的外键约束或者关联约束，那么必然会涉及数据库对数据一致性的检查及处理。对于传统的账务类批量来讲，这是必然的选择，但是对于其他统计分析类的报表类批量业务，尤其是基于互联网业务系统数据设计的批量报表业务，对数据间的相互约束并不敏感，而是聚焦数据在其他维度的总体特征分析，因此某些列式数据存储解决方案反而更契合。因此，金融行业在坚持批量业务系统既有载体架构方案升级改善的同时，探讨新型的数据处理解决方案，并且能将这集中元素应用到数据后台批量业务当中，是一种必然的趋势。三、金融行业批量业务存储架构选型技术分析3.1列式存储的存储方式与批量查询之间的契合点对于某些需要根据字段特点进行统计、排序、筛选的批量分析类业务，列式存储的效率要比行式存储的效率高很多。数据量越大，这个优势越明显，到了单机资源无法处理的规模，这个优势就更加突出了。但是如果遇到需要精准定位到某一条数据，并且进行多字段处理的场景，列式存储就显得笨重很多。以传统关系数据库为载体的批量业务系统，必然会涉及到相关的外键约束或者关联约束，这会带来两个问题：一是数据处理效率的问题，关联约束的检查及关联操作必然带来多余的操作代价。二是数据处理过度依赖单节点资源，无法实现分布式处理。既然我们要顾及数据之间的横向联系，那么必然导致数据无法切分，分布式处理也无法保障关联约束。而列式数据库的原则是要抛弃数据之间的外键关联约束，希望将数据切分为相互之间独立的数据表。这样的优势有很多，首先我们可以对数据进行切片，无论是通过哈希算法还是通过其他算法，数据更容易切片交由不同节点分布式处理。其次，当我们对数据进行批量的插入、删除、更新的时候，我们无需付出不可估量的关联性代价。或许在数据量可观的情况下，这个优势不会被人过于关注。但是一旦当数据量的处理超过单节点资源能够完成的边界，我们唯一可以选择的就是列式存储，甚至我们不惜花费大量的开发代价去改变业务逻辑，使之前下沉到数据库的关联性约束上浮到业务控制层面。3.2列式存储与数据存取效率的契合性首先，列式存储最大特点在于其数据压缩消重的优势，因为按照现实世界的特点来看，大部分重复数据在某一个维（列）上，那么这就给了列式存储消重最大的优势。在一片连续的物理存储空间上处理一些重复数据，总比在杂乱无序的物理存储空间上处理一些随机的重复数据要提高很多效率。这个效率的提高带来的是CPU、内存、磁盘等各个资源的代价减少。其次，当我们要对数据的维和度进行具体的OLAP分析的时候，我们需要把大量的数据读入到内存进行深度的处理，比如排序、分类、分组、筛选、统计等等。从物理存储读入数据到内存本身的效率是非常可观的，在内存当中处理少量的数据要比处理带有重复数据的大量数据要效率得多。很多事情就是因为这不同环节上的少量提高而发生了整体上的指数级别的改变，将不可能变成可能。或许我们可以通过微观和宏观的理论来解释其中的细节。再有，忽略数据字段之间的关联性的列式存储解决方案，使得数据具备了切片分库的基本条件，也具备了分布式架构的应用前提，而且分布式的扩展性会更好，无疑这又提高了批量系统对数据处理的整体吞吐量和引擎的整体处理效率。或许我们可以说这个是通过牺牲了数据的完整性约束来换取的，如果业务本身没有这种需求，我们丢掉这个特性换取“分布式”的特性，又有何妨呢？很多人可能会抬出CAP理论来讲，没错，我们承认CAP理论的正确性，但是在OLAP业务场景当中，我们看到的更多的是数据宏观维度的抽象属性，是基于大量数据的同纬同度分析之后的价值，而不在于单个数据之间的严格约束，所