银行向对象存储架构转型升级的思路和最佳实践

1、 银行向对象存储架构转型升级的思路和最佳实践 【摘要】本文从某银行非结构化数据存储的现状及痛点入手，深入剖析当前影像系统的架构方案瓶颈和不足，并对对象存储架构体系转型升级的需求进行深入分析，提出相应的转型思路，同时结合实际现状，抛出转型过程中需要克服的几个难点问题，希望对各位同行有所帮助。前言随着某银行数字化业务的持续开展和监管要求的不断提高，各线上线下业务渠道不断拓展，其产生的影像、音频、视频等非结构化数据急速增加，该行正面临现有的文件存储设施不能适应业务增长、系统管理复杂、扩展能力差、访问能力差等问题。因此亟需启动开放式海量非结构化数据的存储平台项目，来满足海量的非结构化数据存储、读取和管

2、理需求。本文将从某银行非结构化数据存储的现状及痛点入手，深入剖析该行当前影像系统的架构方案瓶颈和不足，以及对对象存储架构体系转型升级的需求进行深入分析，并提出相应的转型思路，同时结合实际现状，抛出转型过程中需要克服的几个难点问题，希望对各位同行有所帮助和借鉴。一、非结构化数据存储的现状及痛点目前某银行非结构化数据 （影像数据 ） 存储、调用和归档主要采用传统的在线、 近线和离线存储分层架构体系。从影像数据来源来看，某行的影像数据主要分两大块，一块是地市影像数据，主要用于事后督查业务，另一块是总行影像数据，主要是通过柜面、智能柜台和移动营销等线下渠道、信贷系统办理客户各项业务时产生的影像数据，以

3、及通过互联网金融 APP 、手机银行 APP 、ATM 等线上渠道进行人脸识别时产生的影像数据。地市影像数据目前分别存放于多个 SAN 存储当中，分别部署于不同的地市机房，根据地市的业务规模不一，存储容量也不一，平均每个 SAN 存储约 100TB 。总行影像数据通过存储分层架构实现在线、近线和离线数据的存储和隔离，如下图所示。在线存储存放于闪存 （ IBM FS900 ） 当中，约 10T ， 保存了近 7 天的影像数据，并通过 IBM ECM 客户端定期迁移至 ECM 系统所接入的近线存储 （ IBMDS8870 和 V7000 ） 当中，约 50T ，保存了近 30 天的影像数据，最后再

4、通过 IBM TSM 备份软件每日将近线存储中的影像数据归档至离线存储（ 华为 5300V3 、 IBM DCS3700 ）当中。当信贷系统或者柜面等线下渠道业务需要调取 7 天以内的影像数据时，直接访问影像系统，读取影像节点的后端在线存储；当需要调取 7 天以上， 30 天以内的数据时，将先通过部署在影像节点上的 ECM 客户端，从 ECM 系统中抽取数据至影像节点，再传给相应的线上或线下的渠道业务系统；当需要调取 30 天以上的数据时，则步骤更加繁琐，涉及链路节点更多，需先通过 TSM 备份软件抽取备份的影像数据至 ECM 系统，再传给影像节点，最终传给相应的渠道业务系统。此架构通过利用不

5、同性能的存储实现影像读写质量分层，不同性能的存储提供不同质量的 I/O 服务，闪存在影像数据写入和在线读取性能极佳，为各线上线下渠道业务系统的影像数据录入和调取缩短大量时间 （极致的响应速度 ），并大幅提升并发能力 （ IOPS ） ；离线的大容量存储则提供了较高的存储性价比，满足日益增长的海量影像数据永久存储需要。该架构也确实在某行影像平台上线后的3、4年内，提供了比较高效的非结构化数据存取能力。然而随着近两年存储的影像数据量的暴增，新增了多类业务的影像业务和数据，像互联网影像数据、手机银行及 ATM 人脸识别影像数据、移动营销及智慧柜台等智能终端办理业务时产生的影像数据、银企业务影像数据等

6、等，这样就导致影像系统尤其是再后端的 ECM 系统压力陡增，目前遇到以下几个痛点问题：其一在于 ECM 系统，无论是近线数据还是离线数据，影像数据的位置与影像数据间的关系等信息均存放于 ECM 数据库当中，该数据库为联机型关系数据库，随着数据量的剧增，ECM 数据库的数据量已达到近 8TB ， 7 天以上的数据调阅均需要访问先 ECM 数据 库，来获取数据位置，然而目前庞大 ECM 的数据库，即使经过多次数据库性能调优，并发读取性能已经越来越不满足业务的需求，因此数据调阅响应时间也越来越长；其二在于影像数据调阅所需经过的节点过多，链路过长，包括影像节点影像存储节点、影像数据库、 ECM 节点、

7、 ECM 数据库和 TSM 节点等，影像系统的服务耗时较长，随着影像数据量越来越大，耗时问题将越来越严峻，尤其是 7 天以上历史数据的调阅耗时过长问题，故障点多，且响应时间慢，若全用闪存来完全取代近线存储，则性价比过低；其三在于影像系统的两地三中心建设难度大，方案复杂，存储投入大，成本高，数据副本重复，且切换耗时较长， RPO 和 RTO 均不能满足监管机构的要求。因此，基于以上的现状及痛点，该行迫切需要对现有影像以及 ECM 的数据存储架构进行转型升级，精简该存储架构，全面提升影像数据的存储效率，并建设影像系统的两地三中心体系。二、非结构化数据存储转型思路及需求分析鉴于某行目前非结构化数据主

8、要存放在 SAN 集中式存储上，而传统存储采用集中式的元数据处理方式，因此，当某行影像系统在处理千万、亿级的文件量时就会出现陡峭的性能骤降拐点，直接表现就是前端影像平台处理效率降低，柜面、信贷、事后督查等涉及影像的业务效率的下降，最终导致客户满意度的下降，这显然不利于该行的健康持久发展。因此该行需要对现有存储中的海量数据进行整合、精简存储架构，目前非结构化海量数据存储较好的方案主要有传统分布式NAS 方案和对象存储方案。传统 NAS 存储方案由于和现有 SAN 存储方案类似，都是基于文件系统的方案，均为树形目录组织结构，随着数据量的增大，同样存在文件寻址越来越慢的瓶颈。另外如果将现有 SAN

9、方案改为 NAS 存储方案， IOPS 和 I/O 响应时间还有所降低，尤其是在线储存目前所用存储为闪存阵列，近线存储为 DS8870/V7000，离线存储和地市影像存储均为华为 5300V3 ， 通过 NAS 方案 显然不适合对现有架构进行改造，且存在越改越差的情况。至于 NAS 存储的两地三中心容灾备份方案，依旧是两套 NAS 镜像或者双活的方式，副本数较少，备份效率低，数据一致性校验困难。因此该行在非结构化存储架构转型方案上偏向于采用对象存储方案。该行期望通过使用分布式对象存储架构替换现有传统的 SAN 存储架构，能够解决海量非结构化数据的集中存储及访问问题，提升非结构化文件存取效率，解

10、决地市影像和总行影像存储单点问题，并尽可能的精简现有非机构化数据的存储架构。而分布式对象存储能够保证不丢失数据、不中断服务、提供良好的用户体验，解决存储扩容等一系列复杂问题。由于分布式对象存储采用扁平化的数据组织方式，所以目录架构扩展性强，耦合性低，增删节点时所需迁移的数据少。整体而言，在业务系统、 IT 性能以及运维方面都带了本质的提升。基于此，该行非结构化数据存储转型需求可以概括为以下三个方面：1 、精简非结构化数据存储架构。对总行影像数据而言，该行现有的存储架构为：IBM FS900 闪存 -IBM DS8870/V7000- 华为 5300V3 ，三层存储架构，且存储和现有生产交易类闪

11、存和 DS8870 存储共用，一来非结构化数据不适合放于 I/O 响应时间优异的存储当中，性能浪费严重，且占用过多的存储空间，其他对 I/O 响应时间要求更高的交易类系统，可能反而得不到高性能的存储。二来该存储架构过于冗余，数据存储存在大量迁移和调用的过程，如 7 天以上的数据由闪存迁移至 DS8870/V7000，30 天以上的数据由 DS8870/V7000 迁移至华为 5300V3 ，历史数据调阅的过程又反向，虽然均通过 ECM 系统和 TSM 软件实现了该过程，但效率较低。可以将该问题概括为：使用率性能比较优异存储，但整体数据存取效率反而不高，尤其是历史数据的调用方面。对地市分行而言，

12、不同地市分别部署了一套华为存储，独立使用，数据来源于事后监督系统通过部署在地市影像节点上的ECM 客户端来抽取总行 ECM 系统的历史数据，该数据和总行数据存在部分重合， 但却又并不是总行数据的副本，无法接管总行影像系统。而采用对象存储方案，可以通过总行和地市部署存储节点和访问节点的方式，将所有存储打通成一个大存储资源池，所有影像数据均放在该存储池，形成二层精简架构，所有数据的存取，包括柜面、信贷、后督等系统对影像数据的存储，均通过本地的访问节点访问，大大提升了访问效率。2 、提升非结构化数据的存取性能。虽然目前的架构方案中引入了闪存，对于 7 天以内的影像数据的存取效率大大提升，但历史影像数

13、据的调阅性能依旧较差。导致该问题的一个主要原因在于历史影像数据调阅需要通过 ECM 客户端访问ECM 系统中的存储数据，而该访问的过程首先要读取 ECM 数据库，获取存储数据的位置和地址，才能获取存储当中的数据，这样的弊端在于随着该行业务的拓展， 接入影像系统的渠道越来越多，影像系统每日的业务量越来越大， ECM 数据库中 相应的数据也与日俱增，进而导致 ECM 数据库访问效率大大降低， 30 天以内的历史影像数据的调阅也就越来越慢，无法满足柜面等渠道及信贷系统对影像数据 调阅的需求。对于 30 天以上的历史数据就更加如此，除了需要访问 ECM 数据库 之外，还需要访问 TSM 备份系统，通过

14、 TSM 备份系统自动将要调阅的数据恢复至ECM 系统中，再上传给影像系统，供其他渠道和系统调阅。因此整个过程实际上耗费了大量时间在数据查找和数据传输上，即使底层存储采用了 SAN 存储，性能 较对象存储强，但算上这些额外开销时间，总体调阅时间大大提高。因此倘若采用了对象存储，访问时间就仅仅为对象存储的寻址时间，没有其他额外时间的消耗，总体性能也就大大提升。3 、提升非结构化数据的副本数和冗余度。相较于现有存储架构中的单副本数据，要提升副本数，建设非结构化数据的两地三中心体系，必须通过存储级的复制技术实现，多副本间为完全拷贝，相同的一份数据在生产、同城和异地站点的存储中均保留一份，对于海量的影

15、像数据而言，容量起步 PB 级，建设两地三中心，需要大量的存储成本投入，性价比低。而采用对象存储方案，其天生具有地理容灾性，通过独特的纠删码技术，将每份影像数据通过切片的方式切成若干份，分布于多个数据中心的多个存储节点当中，同时保留一定切片冗余。例如经典的 7/12 的切片规则，一份数据被切为 12 个切片，只要任意的 7 个切片数据完 整，则原始数据就能正常访问，这样能够容忍任意 5 个切片数据失效。因此数据的冗余度也大大提升，即使某个数据中心的存储节点发生故障，或者访问节点发生故障，均可以通过其他存储节点和访问节点获取原始数据。该技术易于构建非结构化数据的两地三中心部署方案，提升数据可靠性

16、，同时极大降低存储投入成本。三、非结构化数据存储转型难点分析基于以上的需求分析和转型思路，对该行的非结构化数据存储架构的改造而言，采用对象存储方案是最优的方案，转型后的架构如下图所示。但同时，另一方面，采用对象存储，也将给该行带来三个方面的难点问题，需要提前妥善解决。1 、传统的文件系统读取的方式需要改为对象存储 API 的方式。无论是采用SAN 存储或者 NAS 存储，各渠道系统访问影像系统，是经影像应用节点处理后， 读写影像应用节点后端 SAN 或 NAS 存储，读写接口方式为传统的文件系统读写。对于大多数文件系统来说，尤其是 POSIX 兼容的文件系统，提供 open 、 close 、

17、read 、 write 和 lseek 等接口。而对象存储的接口是 REST 风格的，通常是基于HTTP 协议的 RESTful Web API ，通过 HTTP 请求中的 PUT 和 GET 等操作进行文件的上传即写入和下载即读取，通过 DELETE 操作删除文件。对象存储和文件系统在接口上的本质区别是对象存储不支持和 fread 和 fwrite 类似的随机位置读写操作，即一个文件 PUT 到对象存储里以后，如果要读取，只能 GET 整个文件，如果要修改一个对象，只能重新 PUT 一个新的到对象存储里，覆盖之前的对象或者形成一个新的版本。因此，要将文件系统读写方式转为对象存储 API 方

18、式，需要对现有影像系统应用进行大规模改造，增加新的对象存储 API 接口，修改大量程序代码，时间周期和工作量需要提前计划好，并进行充分测试。2 、非结构化数据存储迁移问题。原闪存、 DS8870 、 5300V3 中的非结构化存储数据需要通过调阅的方式迁移至对象存储当中，涉及的数据量较多，耗时较长， 且影像系统在数据迁移过程中，不能影响各渠道业务的正常办理，业务不允许中断，迁移时也要对其他业务系统提供影像服务，因此，整个平滑迁移与过渡的方案要理清和妥善计划。另外，值得考虑的一点是，在迁移过程中，涉及历史数据调阅并重新通过 API 写入对象存储，同时正常的业务办理也需要调阅 7 天以上的影像数据至影像节点后端的文件系统，因此影像应用在改造时，需先同时兼容两种接口方式，并以拷贝的方式将数据备份至对象存储，而非直接迁移。3 、带宽扩容问题。由于