本文来自微信公众号“twt企业IT社区”。
【栏目主编】赵海某金融系统高级主管：本议题由光大科技有限公司高级工程师牛凯源、某金融科技公司资深集成工程师孙伟光、某金融机构架构师李威分别发表自己的主张，几位专家的主张在某股份制银行系统架构师老谷、江西银行信息科技部系统管理岗资深运维工程师谢茜茜、以及我本人的复议后，形成了一定的共识，希望可以对同行有一定的参考。
牛凯源光大科技有限公司高级工程师：
金融机构关键业务存储架构在选型时，需充分考虑到业务场景的特点，有针对性地选取适合的存储产品以及架构，不能一味的求新、求变，应以科技为金融服务为宗旨，通过技术，提高金融机构服务的质量和效率。
一、引言
金融机构在多种场景有着关键应用，银行业更多关注交易类与账务系统，保险行业则将投保理赔类系统视为关键系统，而如何选择适合各场景下的存储？如何设计适合特定业务场景的存储架构？对于企业IT人员来说尤为重要。
二、当前主流存储架构分析
现有的存储系统经过长期发展，种类极其繁多，架构也各不相同，限于篇幅，本文主要针对架构进行相关讨论。
当前主流架构主要分为集中式存储和分布式存储两种。集中式存储技术成熟，架构简单，有足够的稳定性，对高IOPS、低延时、数据强一致性有很好的支持。但是集中式架构决定了其扩展能力有限，无法很好支撑高并发访问性能。随着数据量不断增长，集中式存储增长空间越来越有限。分布式存储是采用分布式架构的存储集群，将数据分布在不同物理位置，并通过网络把它们连接起来，横向扩展能力很强。分布式存储有效解决了传统集中式存储的可扩展性问题，规模可扩展至上千个节点，容量扩展到上百PB甚至EB级，性能随容量线性提升。按需在线扩容后，自动实现数据再均衡。分布式存储的多个存储节点能够同时提供读写服务，因此具有很高的吞吐率，可达到几十GB/s。主流分布式存储产品主要有以下几种：
･Ceph：适合云平台块存储和对象存储
･HDFS：适用于大数据场景
･GlusterFS：适用视频，音频等大文件和以读为主的场景
･BeeGFS/Luster：适用于高性能计算场景
三、金融机构业务场景分析与架构选型思路
首先，需要明确不同金融机构不同场景下的业务特点，此处，以银行业与保险行业为例，比如：银行业的联机交易业务或核心业务主要体现在客户层面对于业务响应的快慢，故而对于读写的性能要求极高；此外，对于事务性也有极高的要求，交易业务要求数据必须是强一致的，不允许出现脏读，脏写的情况。针对上述出现的这类核心业务系统，可采用传统的集中式存储架构，以便对高IOPS、低延时和数据强一致性的需求能够有效支持。
而像银行业或保险行业的影像类系统，主要存储的是客户的影像媒体数据，数据多以大文件、非结构化数据为主，业务特点也多以影像数据的查询为主，对性能有较高要求。对于此类业务，以个人实践情况来看，以GlusterFS为代表的分布式存储最为适合该业务，GlusterFS具有高扩展性、高可用性、高性能、可横向扩展等特点，其根据场景不同，可设置不同类型的卷，如：分布式复制卷，分布式条带卷等，以此来达到高性能读写的目的。
个人曾对GlusterFS存储进行过相关读写性能测试，在分布式复制卷模式，同/异步写入，读取数据的场景下，发现其对于大文件的读写支持很好，测试数据如表1，表2所示：
表1同步读写测试数据
表2异步读写测试数据
根据表1可以看出，GlusterFS存储对于小文件的读写性能支持并不是很好，但是对于大文件来说，读写性能很强，适合视频流媒体等影像文件的读写
根据表2可以看出，虽然GlusterFS适合大文件读写，但是异步读写下，并不是文件越大，读写性能越好，反而在笔者的测试环境下，2G大小的文件，读写性能达到最佳。
该测试数据是基于分布式复制卷进行的数据读写，理论上来讲，该模式下相对于分布式条带卷，读写性能要略微差一些，但是由于采用了多副本机制，所以保证了数据的高可用，但随之带来的是存储容量有效利用率较低以及数据查询效率的降低。
所以，在实际场景中，选择分布式存储时，是否采用多副本，副本数量设置多少，需要结合具体业务场景来确定。
四、结语
综上所述，金融机构业务存储架构在选型时，需充分考虑到业务场景的特点，有针对性地选取适合的存储产品以及架构，不能一味的求新、求变，应以科技为金融服务为宗旨，通过技术，提高金融机构服务的质量和效率。
孙伟光某金融科技公司资深集成工程师：
数据作为企业的核心要素和资产，在解决如何存储管理大数据以及海量文件数量之外，更重要的是根据应用的访问特点，在保证数据安全性的同时，进行简易化合理的数据存储管理以及提高存储系统读写性能，提升数据处理效率，将存储系统的价值发挥到最大。让存储在保险业发挥重要的压舱石作用。
一、保险行业影像类业务应用特点
数字化转型大势下，作为数字经济的重要参与者，保险公司面临诸多数字化转型的挑战，如何通过“数据”驱动实际业务以实现保险企业的数字化转型成为关键所在。影像平台为保险企业提供了全面影像技术支撑，包括：影像采集、影像存储、影像处理、影像调阅。影像平台系统需要管理海量内容数据，内容通常是传统关系型数据库信息的几十乃至上百倍，保险企业生产业务系统生成的电子保单是以文件为单位的非结构化数据，不论是单个文件大小还是文件总数据量，其增长都非常迅速。而且为了方便用户在调取经常被访问的数据时可以直接从缓存调取，会将所有经常被访问的数据都存储在缓存池中，当数据量不断增长时（如图片类与结构化数据），存储系统中的文件数量也会快速增长。当存储系统内的文件数量增长到数千万以上时，文件的检索查找等操作将会给文件系统带来巨大的压力，特别是当一个目录下面存放的文件超过一定数量时，甚至会造成文件查找效率的急剧下降。
数据作为企业的核心要素和资产，在解决如何存储管理大数据以及海量文件数量之外，更重要的是根据应用的访问特点，在保证数据安全性的同时，进行简易化合理的数据存储管理以及提高存储系统读写性能，提升数据处理效率，将存储系统的价值发挥到最大。让存储在保险业发挥重要的压舱石作用。
二、保险行业影像系统架构分析
存储架构是实现数据存储关系各个系统读写性能的关键环节。存储架构重点是在建立起统一的存储平台上，更有效的完成业务处理，并极大地提高系统的可管理性，降低系统的管理难度及管理开销，提高信息的可用性和共享性。金融机构关键业务系统在存储规划设计上一般需要考虑如下两个重要因素：
1）系统运行性能：系统应能满足的性能需求，包括在线用户数，并发用户数，综合处理能力（TPS）、重要业务的平均响应时间、重要数据的联机存储能力等内容。
2）系统安全性：应能满足的用户接入系统的安全性要求，应能满足的系统关键数据的保存和恢复等安全性要求，应能满足的系统关键数据的被查询的安全性要求。
按照影像平台数据存储结构可将数据分为两大类：结构化数据和非结构化数据。结构化数据主要包括应用系统直接产生的数据，即行数据，是存储在数据库里可以用二维表结构来逻辑表达实现的数据，包括：业务数据、基础库数据等。非结构化数据是指不方便用数据库二维逻辑表来表现的数据，主要包括：音频、视频、日志与图像文件等。
保险业影像平台由于其应用功能固有特点，将产生大量的扫描图片、影音等非结构化、半结构化的数据，对这类数据的采集、存储、检索、分发、分析等管理提出了很高的要求。因此，非结构化数据根据法规要求，需要对数据集中归档备份。重点在于平衡数据存储成本效率与计算处理效率，配合结构化数据的分析，提供分析应用场景下的非结构化数据支持。
根据数据分类原则，影像平台的数据划分为两个层级，如表3所示：
表3影像平台数据划分表
三、业务应用场景下存储架构设计
存储系统应该以存储资源池的形态进行应用系统存储资源的调配和存储资源的管理。存储资源的调配应该以一种灵活、高效的方式出现，尤其是在影像平台，存储系统中虚拟资源调配功能完全满足这些需求，为了便于管理，应该提供一个统一的存储平台对系统进行统一配置管理、系统状态监控和性能监控。通过统一管理平台，用户可以清晰地了解到整个存储资源池的设备运行状态、容量资源利用率和性能状态等。
存储系统作为云平台的重要组成部分，需要与计算资源有良好的集成，尤其是需要将存储管理与云平台管理有机地集成在一起。SAN网络中网络层是非常关键的一个部分，它负责将主机和存储系统连接在一起，并且提供一个高灵活性、高扩展性的环境，以适应业务系统不断发展带来的主机和存储系统的扩展。
对于NAS存储层来说，NAS作为最成熟的网络存储解决方案，而且是唯一一种通过网络连接主机系统共享数据的存储技术。它采用文件为基本读写单位，文件管理由高效的专用硬件模块负责，可以降低应用服务器主机对文件管理的开销，因此最适合做海量文件的存储构架。优秀的NAS存储设备可以提供每秒近万次文件读写，在处理海量文件时性能更优于SAN存储。NAS采用高速以太网作为连接访问的形式，因此在系统容量扩展时，不需为应用主机添加诸如FC光纤卡等昂贵配件，性价比高且不论是增加主机还是存储容量都十分便捷，通过快照方式还可以方便地进行高速文件备份。
对象存储是一种灵活的可扩展存储结构，它将所有数据都作为独立对象存储在平面层空间中。对象存储支持同时存储和管理各种类型的数据，包括结构化数据（如数据库）、非结构化数据（如图像和视频）和半结构化数据（如电子邮件和社交媒体消息）。鉴于其可扩展性高且访问速度快，主要云存储服务全都以对象存储为基础。
从数据生命周期角度看，影像系统业务发起产生结构数据和非结构化数据，这部分数据作为在线数据，分别进入不同的存储池，结构化数据写入SAN闪存存储，非结构化数据写入NAS存储。业务完成一段时间后，非结构化数据因很少在被调用可作为近线数据写入对象存储或者作为离线数据写入磁带库等。
四、存储选型应用基本思路总结
存储选型方法论：
1.存储性能保障原则
1）设备利用率通用原则控制在70%以下，部件利用率在30%以上仍然可以处理相同吞吐负载但是带来处理延时的增加，延时大带来联机交易延时失败。
2）不同的转速的磁盘设备，在不同IO特征下能够完成的吞吐量和流量差距很大。
2.存储分配规则
每台存储需预留20%的空间，满足存储内系统扩容和变更的要求。对于重要系统和性能压力大的系统，为确保磁盘性能，存储底层RAID组尽量分散。同一RAID组的LUN为避免相互干扰不能分配给两个繁忙的系统。对于数据量大的应用，尽量独占RAID组。根据存储性能数据优化后端磁盘，减少热点盘的出现。存储前端端口：IO负载高的应用，使用专有的存储前端口。对于高端存储IOPS≥4000应分配1对独立存储前端端口，IOPS≥8000应分配2对独立存储前端端口。数据流量高的应用，分配在不同存储前端板卡上，避免存储前端板卡到后端交换机的带宽成为瓶颈。服务器HBA卡和存储前端口是可以1对1或多对1，避免1对多。IO压力小的业务系统可共享存储前端口，每个存储前端口最多为3个HBA共享。服务器端访问每个LUN的多路径≤4条，如果4条仍无法满足性能要求，应将LUN进行分组，不同的组对应不同的前端口。
3.存储使用规则
1）操作系统层条带化：为了提高性能，主机层LV建议做条带，条带的PV应分配到不同RAID组。操作系统群集识别相同共享存储群集HA或者RAC系统，两个节点识别相同的存储磁盘，尽量避免出现群集节点磁盘个数不一致情况。
2）数据库层空间分配原则：数据库空间一般有IO较小，随机IO多的特点，采用RAID1空间。数据和索引表空间要分配在不同RAID组上。TEMP表空间功能是查询排序和存放临时表，较忙，采用性能好的LUN。REDO表空间采用RAID1空间、UNDO表空间采用RAID1组、ARCHIVE归档日志建议用RAID5空间。
李威某金融机构架构师：
海量小文件，为什么会成为世界性难题？一切的根源探索还得从海量小文件的实际场景出发，如何产生、如何存储、如何成难题。透过现象看本质，优化才有方向，目标才能明确。
海量小文件，不仅是一个行业难题，更是一个世界性难题，各行各业的诸多场景下都存在类似困境。此类问题难以根治，一部分原因是传统存储解决方案无法高效匹配海量小文件的场景，另一部分原因是从传统存储切换到对象存储的成本略高。此前，针对影像系统和打印系统的海量小文件场景，我们曾花费大量的时间和精力来优化海量小文件的业务存储。借此机会抛砖引玉，来深入聊一下海量小文件问题，分享些许我们在海量小文件优化上的一点心得。
对于海量小文件的定义，行业上尚未有精确规定，更像一个事实标准，而非定义标准。一般情况下，单个文件的体积并不大，一般为数十KB至数MB，但数量规模数十万甚至百万以上级别之巨，这类场景我们称为“海量小文件”。海量小文件通常呈现出一种非结构化文件的大小与数量极不平衡的特性，也正是难以根治的症结所在。
在金融保险的业务系统中，以寿险为例，有两大核心系统最易形成海量小文件场景：一是影像系统，影像系统中需要存储大量非结构化数据，如保险人相关的证件、图片、PDF文件等，同时还有海量的业务过程文件，如交易报文、日志记录等；二是打印系统，打印系统会生成大量的电子保单，同样存在大量过程文件，如渠道交易图像、电子签名照片、电子合同、相关OCR文件等。这两大系统中图像类文件在MB级别，中间过程文件在KB级别，相对比之下中间过程文件的数量级远高于影像类文件，单个系统存储的非结构化数据量在TB级别以上。伴随业务高峰期的到来，单目录下小文件数量可达百万级别，严重影响目录的读写效率，甚至长时间无响应。
在我们的业务实践中，单目录下小文件数量达到一定规模后，该共享存储目录的读写效率会出现显著下降，但影像系统与打印系统对这些非结构化数据的IOPS要求并不低。根据业务险种及渠道的不同，对保险人影像件的调取、电子保单的合成一般都要求在数秒之间，实时单批次电子保单合成同样如此，非实时大批量电子保单合成不超过数分钟。
海量小文件不仅会对在线业务的IOPS有很大影响，而且对这部分业务数据的连续数据保护也构成巨大挑战。根据监管单位的关键业务数据保留要求，近三年至五年的数据均需要可回溯，所有数据均需要永久保留。夜间闲时窗口，是数据备份的重要时间段，错开核心业务夜间核心批处理作业时间后，数据保护的执行窗口相当有限。然而当使用备份软件对海量小文件进行备份、归档时，发现在数据扫描阶段会消耗大量时间扫描小文件来建立备份索引。数据备份阶段，数百万计的小文件将写入磁带或归档存储，速率极其低效。若再加上网络等相关因素影响，海量小文件的备份归档窗口将远超计划，甚至以天计算。
造成海量小文件存储如此低效的根源到底是什么？为什么至今还能成为一个世界性的难题？
要想明白这个问题，就得回到存储本身来追根溯源了。首先，主要是存储介质问题。传统的存储以机械磁盘为主要介质，而机械磁盘适合顺序的大文件IO读写，不适合随机的小文件IO读写。因此海量小文件的体积、数量都会进一步加剧机械磁盘的劣势。
其次是数据效率问题。传统磁盘文件系统体系结构依靠目录项(Dentry)、索引节点(Inode)以及数据块(Data)来指导、定位、读写文件系统的数据，而目录项(Dentry)、索引节点(Inode)以及数据块(Data)均存储在不同地方，也就是说一次随机文件读写至少进行3次独立访问。面对海量小文件场景时，海量小文件的并发读写汇聚形成了大量的随机访问，磁盘文件系统的体系机制放大了IO的体量，大幅降低磁盘的吞吐。
再者，磁盘文件系统的索引结构在海量小文件场景下无法发挥优势。磁盘文件系统通常采用Hash、B+树组织索引，当面对单目录下数以百万计的小文件时，索引的增删改查将消耗非常多系统资源，甚至耗尽。这一点在对象存储的体系结构里得到了极大的优化和改善，如图1。
图1传统NAS存储与对象存储体系结构
最后是操作系统IO访问机制受制。以LinuxVirtual Filesystem（简称VFS）为例，VFS提供了统一访问接口和流程，方便与不同磁盘文件系统的对接与扩展。VFS的四种对象的交互太复杂，我们重点关注Process与VFS之间的交互操作，简化Linux I/O堆栈（如图2）。
图2 Linux I/O Stack简化版
当应用触发文件的随机访问时，会调用一组Syscall去完成文件的操作访问，如open()/seek()/read()/write()/close()等。在这组Syscall中，open()将对文件进行路径查找，将操作系统层级上的路径名转换成其在内核中的表示。open()涉及大量的关联操作，非常消耗系统资源，尤其是针对深层次目录下的文件进行访问。在海量小文件场景下，大量深层次文件的检索直接劣化了open()操作的效率。
随着IT信息科技的发展，针对海量小文件场景已经推出了对象存储。与传统存储不同，对象存储在体系结构上更加扁平，OIDs映射Object对象，直接通过唯一标识定位文件,不论访问什么数据，都能实高效响应,既解决了文件系统体系结构的低效，又屏蔽了文件目录深度带来的巨大开销。
然而，使用对象存储虽然优化了海量小文件场景的访问效率问题，但作为非结构化文件的主存储也会面临些许问题：数据保护手段薄弱、主流备份软件对对象存储的备份支持尚未完善、无法实现全功能数据保护等。虽然可以借助对象存储的跨域复制形成数据冗余，但不满足监管单位对关键数据离线保存的要求。同时，不同于传统NAS存储，对象存储的读写方式也发生了变化，因此涉及业务代码改造。存储更替的过程还涉及大量的业务数据迁移等。
且由传统存储切换到对象存储，对于企业的代价也是相当大的。影像系统和打印系统，都属于保险业务核心，多采用NAS存储业务数据，数十年的更迭都未曾改变。影像、打印系统牵一发而动全身，若需更替存储，涉及大量业务代码改造。影像、打印系统的割接也必须“一刀切”快速切换，无法容忍长时间的业务中断。
那么该如何优化海量小文件呢？
海量小文件所在的环境及链路若未更改，优化的范围就相当有限，唯有从海量小文件结构入手，优化实践的思路大概分为三步：
（1）优化目录层次结构。
深层次的目录结构极大劣化了IO效率，使得文件寻址定位消耗大量的系统资源。过深的目录层次更加剧了海量小文件的归档难度。结合业务实际，我们对影像的存储目录进行了最多6层级的设计，以存储挂载点目录为根，第一级子目录为渠道目录，从不同渠道上传、回写的数据存放至对应目录。第二级子目录为业务功能目录，建立各场景对应的数据目录，数据按照既定的规则写入。第三级至第六级，分别对应年—月—周，方便数据以时间单位归档。值得一提的是“周”目录逻辑作了简化，我们始终以每月的1-7日为第一个周目录，8-14为第二个周目录，以此类推。
目录层次的设计需要贴合业务实际。在我们的设计中，渠道目录为第一级子目录，兼顾了各渠道下的差异，方便各渠道已开展的差异化业务都能有对应数据存储目标。“周”目录的设计没有按照常规周的方式设置，直接规定7天为一个周目录，保持最末子目录的统一性，也屏蔽星期几带来的难度升级。
（2）冷热分离、使用SSD缓存热数据，数据遇冷后转移至NAS存储。
冷热分离能最大化生产实时业务的IO效率，实时业务数据写入SSD上经过优化的目录层次，小文件不会明显大量堆积，IO效率保持稳定。同时SSD高吞吐优势，提供了冷热分离操作的性能基础，分离时不会大幅降低实时业务IO。冷热分离策略可通过脚本或者应用完成，建议至少保证1个月的业务数据作为在线数据。
（3）数据归档。
数据归档是优化的核心之一，其维系着SSD性能发挥与NAS存储效率的平衡。数据由热转冷时，同步进行打包、压缩、归档处理，进在“周”目录对冷数据目录进行打包压缩，将小文件压缩汇聚成大文件。离散的小文件数据都在“周”目录层级，打包压缩后会大幅降低小文件的量级，将离散的小文件转换为数据块连续的大文件，既方便数据归档离线，也大大提高了备份恢复的效率，如图3。
图3影像海量小文件优化实践示意图
针对传统共享存储海量小文件场景，数据目录结构的设计存在局限性和可维护性差的劣势，有同行反馈可以借鉴一些中高端存储的功能设计，如：访问目录优化，大小IO识别，冷热缓存，自动归档等等特性。
在我们对影像、打印系统的海量小文件进行治理时，就想到了这些优化手段并将其中的部分思路进行了实践，简单分享下我们的优化心得：
1.数据目录优化
优化前我们对影像、打印系统的业务逻辑和数据逻辑进行了调研，涉及分支机构、合作单位、各级渠道类别繁多，每家实现业务功能、交互数据有明显区别。因此，我们结合系统实际重新设计了共享存储的数据目录结构，以渠道目录为主要区分，按照业务功能做数据归集，同时对业务功能内数据按照“年-月-周”分类，减轻单一目录下小文件聚集的问题。目录结构的设计方法是多样化的，怎么减轻目录优化给业务数据处理逻辑代码的改动最小才是关键。
2.大小IO识别
NAS存储的大小IO识别功能，在海量小文件场景下发挥的效能十分有限，我们曾进行简单测试，百万级别小文件随机读写效率在开启NAS IO优化功能前后并没有拉开差距，这也说明“IO数据流”读写效率并不是海量小文件的根因。
由于共享目录的数据读写已经是在文件系统层之上的实现，做大小IO智能识别就不现实了，但这也给我们提供了一种思路：可以把小文件的随机IO聚合成大文件的连续IO。在数据目录优化之后，根据各系统模块对历史数据保留的需求，对“年”“月”“周”目录进行周期性打包压缩，方便后续对历史数据的处理。
3.冷热缓存
在共享存储IO优化的测试后，我们紧跟了冷热分层的缓存功能测试，测试效果如预期一致，也没有明显改善。在这一部分，我们想到了在OS层面做了冷热分离，近期数据在SSD磁盘上，历史数据在NAS上。这种冷热存储分层的优化，并没有改变小文件的存取效率，但提供了对历史数据打包、压缩、归档以及备份等综合处理的性能基础。
4.自动归档
归档最初的设计是针对历史数据的永久性保存，将时间久远的历史数据处理完成后转存至NAS上，再由备份恢复软件进行离线出库。后来根据业务的调研，发现可以将部分非实时数据异步处理后归档至NAS，进一步减缓海量小文件的发生。热数据转冷后一连串的打包、压缩、归档，我们使用统一的定制化脚本实现或直接由应用程序的数据处理部分代码实现，若操作失败则发送告警信息。离线出库也是如此，正式备份前会调用特定脚本去检查数据的完整性，若缺失数据目录也告警通知负责人介入。
结束语
金融行业的信息化，有其对数据一致性及安全性等方面的共性要求，同时因为不同应用场景下的交易行为存在差异，因此必然对存储架构组成、读写性能、安全配置等方面有所区别。根据各自的应用场景特点选择适合业务的存储平台已经成为大家的共识。
