jxnxsdengyu
作者jxnxsdengyu2019-10-15 18:11
系统工程师, 江西农信

某银行非结构化数据存储痛点及对象存储需求分析

字数 5877阅读 13072评论 2赞 13

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

一、非结构化数据存储的现状及痛点

目前我行非结构化数据 (影像数据 ) 存储、调用和归档主要采用传统的在线、 近线和离线存储分层架构体系。从影像数据来源来看,我行的影像数据主要分两大块,一块是地市影像数据,主要用于事后督查业务,另一块是总行影像数据, 主要是通过柜面、智能柜台和移动营销等线下渠道、信贷系统办理客户各项业务 时产生的影像数据,以及通过互联网金融 APP 、手机银行 APP 、 ATM 等线上渠道进行人脸识别时产生的影像数据。

地市影像数据目前分别存放于多个 SAN 存储当中,分别部署于不同的地市机 房,根据地市的业务规模不一,存储容量也不一,平均每个 SAN 存储约 100TB 。 总行影像数据通过存储分层架构实现在线、近线和离线数据的存储和隔离,如下 图所示。在线存储存放于闪存 ( IBM FS900 ) 当中,约 10T , 保存了近 7 天的影 像数据,并通过 IBM ECM 客户端定期迁移至 ECM 系统所接入的近线存储 ( IBMDS8870 和 V7000 ) 当中,约 50T ,保存了近 30 天的影像数据,最后再通过 IBM TSM 备份软件每日将近线存储中的影像数据归档至离线存储( 华为 5300V3 、 IBM DCS3700 )当中。

当信贷系统或者柜面等线下渠道业务需要调取 7 天以内的影像数据时,直接访问影像系统,读取影像节点的后端在线存储;当需要调取 7 天以上, 30 天以内的数据时,将先通过部署在影像节点上的 ECM 客户端,从 ECM 系统中抽取数据 至影像节点,再传给相应的线上或线下的渠道业务系统;当需要调取 30 天以上 的数据时,则步骤更加繁琐,涉及链路节点更多,需先通过 TSM 备份软件抽取备 份的影像数据至 ECM 系统,再传给影像节点,最终传给相应的渠道业务系统。

此架构通过利用不同性能的存储实现影像读写质量分层,不同性能的存储提 供不同质量的 I/O 服务,闪存在影像数据写入和在线读取性能极佳,为各线上线 下渠道业务系统的影像数据录入和调取缩短大量时间 (极致的响应速度 ) ,并大 幅提升并发能力 ( IOPS ) ;离线的大容量存储则提供了较高的存储性价比,满足 日益增长的海量影像数据永久存储需要。该架构也确实在我行影像平台上线后的3 、 4 年内,提供了比较高效地非结构化数据存取能力。

然而随着近两年存储的影像数据量的暴增,新增了多类业务的影像业务和数 据,像互联网影像数据、手机银行及 ATM 人脸识别影像数据、移动营销及智慧柜 台等智能终端办理业务时产生的影像数据、银企业务影像数据等等,这样就导致 影像系统尤其是再后端的 ECM 系统压力陡增,目前遇到的痛点问题其一在于 ECM 系统,无论是近线数据还是离线数据,影像数据的位置与影像数据间的关系等信 息均存放于 ECM 数据库当中,该数据库为联机型关系数据库,随着数据量的剧增,ECM 数据库的数据量已达到近 8TB , 7 天以上的数据调阅均需要访问先 ECM 数据 库,来获取数据位置,然而目前庞大 ECM 的数据库,即使经过多次数据库性能调优,并发读取性能已经越来越不满足业务的需求,因此数据调阅响应时间也越来越长;其二在于影像数据调阅所需经过的节点过多,链路过长,包括影像节点影像存储节点、影像数据库、 ECM 节点、 ECM 数据库和 TSM 节点等,影像系统的服务耗时较长,随着影像数据量越来越大,耗时问题将越来越严峻,尤其是 7 天以上历史数据的调阅耗时过长问题,故障点多,且响应时间慢,若全用闪存来 完全取代近线存储,则性价比过低;其三在于影像系统的两地三中心建设难度大, 方案复杂,存储投入大,成本高,数据副本重复,且切换耗时较长, RPO 和 RTO 均不能满足监管机构的要求。

因此,基于以上的现状及痛点,我行迫切需要对现有影像以及 ECM 的数据存 储架构进行转型升级,精简该存储架构,全面提升影像数据的存储效率,并建设影像系统的两地三中心体系。

二、非结构化数据存储转型思路及需求分析

鉴于我行目前非结构化数据主要存放在 SAN 集中式存储上,而传统存储采用 集中式的元数据处理方式,因此,当我行影像系统在处理千万、亿级的文件量时 就会出现陡峭的性能骤降拐点,直接表现就是前端影像平台处理效率降低,柜面、 信贷、事后督查等涉及影像的业务效率的下降,最终导致客户满意度的下降,这 显然不利于我行的健康持久发展。因此我行需要对现有存储中的海量数据进行整合、精简存储架构,目前非结构化海量数据存储较好的方案主要有传统分布式NAS 方案和对象存储方案。传统 NAS 存储方案由于和现有 SAN 存储方案类似,都 是基于文件系统的方案,均为树形目录组织结构,随着数据量的增大,同样存在 文件寻址越来越慢的瓶颈。另外如果将现有 SAN 方案改为 NAS 存储方案 , IOPS 和 I/O 响应时间还有所降低,尤其是在线储存目前所用存储为闪存阵列,近线存 储为 DS8870/V7000 , 离线存储和地市影像存储均为华为 5300V3 , 通过 NAS 方案 显然不适合对现有架构进行改造,且存在越改越差的情况。至于 NAS 存储的两地 三中心容灾备份方案,依旧是两套 NAS 镜像或者双活的方式,副本数较少,备份效率低,数据一致性校验困难。因此我行在非结构化存储架构转型方案上偏向于采用对象存储方案。

我行期望通过使用分布式对象存储架构替换现有传统的 SAN 存储架构,能够 解决海量非结构化数据的集中存储及访问问题,提升非结构化文件存取效率,解 决地市影像和总行影像存储单点问题,并尽可能的精简现有非机构化数据的存储架构。而分布式对象存储能够保证不丢失数据、不中断服务、提供良好的用户体 验,解决存储扩容等一系列复杂问题。由于分布式对象存储采用扁平化的数据组 织方式,所以目录架构扩展性强,耦合性低,增删节点时所需迁移的数据少。整 体而言,在业务系统、 IT 性能以及运维方面都带了本质的提升。基于此,我行非结构化数据存储转型需求可以概括为以下三个方面:

1 、精简非结构化数据存储架构。对总行影像数据而言,我行现有的存储架构为: IBM FS900 闪存 -IBM DS8870/V7000- 华为 5300V3 ,三层存储架构,且存储 和现有生产交易类闪存和 DS8870 存储共用,一来非结构化数据不适合放于 I/O 响应时间优异的存储当中,性能浪费严重,且占用过多的存储空间,其他对 I/O 响应时间要求更高的交易类系统,可能反而得不到高性能的存储。二来该存储架 构过于冗余,数据存储存在大量迁移和调用的过程,如 7 天以上的数据由闪存迁 移至 DS8870/V7000,30 天以上的数据由 DS8870/V7000 迁移至华为 5300V3 ,历史 数据调阅的过程又反向,虽然均通过 ECM 系统和 TSM 软件实现了该过程,但效率较低。可以将该问题概括为:使用率性能比较优异存储,但整体数据存取效率反 而不高,尤其是历史数据的调用方面。对地市分行而言,不同地市分别部署了一 套华为存储,独立使用,数据来源于事后监督系统通过部署在地市影像节点上的ECM 客户端来抽取总行 ECM 系统的历史数据,该数据和总行数据存在部分重合, 但却又并不是总行数据的副本,无法接管总行影像系统。而采用对象存储方案, 可以通过总行和地市部署存储节点和访问节点的方式,将所有存储打通成一个大 存储资源池,所有影像数据均放在该存储池,形成二层精简架构,所有数据的存 取,包括柜面、信贷、后督等系统对影像数据的存储,均通过本地的访问节点访问,大大提升了访问效率。

2 、提升非结构化数据的存取性能。虽然目前的架构方案中引入了闪存,对 于 7 天以内的影像数据的存取效率大大提升,但历史影像数据的调阅性能依旧较差。导致该问题的一个主要原因在于历史影像数据调阅需要通过 ECM 客户端访问ECM 系统中的存储数据,而该访问的过程首先要读取 ECM 数据库,获取存储数据 的位置和地址,才能获取存储当中的数据,这样的弊端在于随着我行业务的拓展, 接入影像系统的渠道越来越多,影像系统每日的业务量越来越大, ECM 数据库中 相应的数据也与日俱增,进而导致 ECM 数据库访问效率大大降低, 30 天以内的历史影像数据的调阅也就越来越慢,无法满足柜面等渠道及信贷系统对影像数据 调阅的需求。对于 30 天以上的历史数据就更加如此,除了需要访问 ECM 数据库 之外,还需要访问 TSM 备份系统,通过 TSM 备份系统自动将要调阅的数据恢复至ECM 系统中,再上传给影像系统,供其他渠道和系统调阅。因此整个过程实际上 耗费了大量时间在数据查找和数据传输上,即使底层存储采用了 SAN 存储,性能 较对象存储强,但算上这些额外开销时间,总体调阅时间大大提高。因此倘若采 用了对象存储,访问时间就仅仅为对象存储的寻址时间,没有其他额外时间的消耗,总体性能也就大大提升。

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

三、非结构化数据存储转型难点分析

基于以上的需求分析和转型思路,对我行的非结构化数据存储架构的改造而 言,采用对象存储方案是最优的方案,转型后的架构如下图所示。但同时,另一 方面,采用对象存储,也将给我行带来三个方面的难点问题,需要提前妥善解决。

1 、传统的文件系统读取的方式需要改为对象存储 API 的方式。无论是采用SAN 存储或者 NAS 存储,各渠道系统访问影像系统,是经影像应用节点处理后, 读写影像应用节点后端 SAN 或 NAS 存储,读写接口方式为传统的文件系统读写。 对于大多数文件系统来说,尤其是 POSIX 兼容的文件系统,提供 open 、 close 、read 、 write 和 lseek 等接口。而对象存储的接口是 REST 风格的,通常是基于HTTP 协议的 RESTful Web API ,通过 HTTP 请求中的 PUT 和 GET 等操作进行文件 的上传即写入和下载即读取,通过 DELETE 操作删除文件。对象存储和文件系统 在接口上的本质区别是对象存储不支持和 fread 和 fwrite 类似的随机位置读写 操作,即一个文件 PUT 到对象存储里以后,如果要读取,只能 GET 整个文件,如 果要修改一个对象,只能重新 PUT 一个新的到对象存储里,覆盖之前的对象或者 形成一个新的版本。 因此,要将文件系统读写方式转为对象存储 API 方式,需要 对现有影像系统应用进行大规模改造,增加新的对象存储 API 接口,修改大量程序代码,时间周期和工作量需要提前计划好,并进行充分测试。

2 、非结构化数据存储迁移问题。原闪存、 DS8870 、 5300V3 中的非结构化存 储数据需要通过调阅的方式迁移至对象存储当中,涉及的数据量较多,耗时较长, 且影像系统在数据迁移过程中,不能影响各渠道业务的正常办理,业务不允许中 断,迁移时也要对其他业务系统提供影像服务,因此,整个平滑迁移与过渡的方案要理清和妥善计划。另外,值得考虑的一点是,在迁移过程中,涉及历史数据 调阅并重新通过 API 写入对象存储,同时正常的业务办理也需要调阅 7 天以上的 影像数据至影像节点后端的文件系统,因此影像应用在改造时,需先同时兼容两种接口方式,并以拷贝的方式将数据备份至对象存储,而非直接迁移。

3 、带宽扩容问题。由于我行多个地市目前分别部署了 SAN 存储用于存放当 地市事后监督系统的影像数据,该方式设计的初衷也是为了规避集中在总行存放 影像数据,带来地市到总行的流量带宽瓶颈问题,影像业务传输的大部分是图片, 比特率较其他业务类型要大很多,在高峰时期可能会对地市其他线下渠道,如ATM 、柜面、智能柜台、移动营销等业务造成影响。若采用了统一的对象存储方案,且对象存储统一部署在我行生产和同城数据中心,又将引入带宽瓶颈问题。 因此,需要提前对所有地市的带宽和影像业务情况进行预估,提前对地市带宽进 行扩容升级。另一方面,由于对象存储分布式部署于两个数据中心,生产数据中 心的影像系统读写后端对象存储,存在跨中心访问的情况,需要通过两个数据中心的大二层网络进行。因此,为了不对其他业务系统的同城容灾复制和正常网络 传输造成影响,需要合理评估影像数据跨中心访问的情况,并对跨中心波分带宽进行提前扩容。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

13

添加新评论2 条评论

匿名用户匿名用户其它, 某银行
2021-02-03 16:34
感谢大佬,文章在思路考量上有很好的借鉴作用,另外我看了下文章时间是19年,那么到目前为止,不知道贵行的对象存储引进上,有没有进展?尤其是在技术技术选型上,结合银行业的非结构化数据的适用性、高可用性,乃至于监管要求等,有没有一些经验,望不吝赐教,感谢
djl2020djl2020高级后端开发工程师, 天翼云科技有限公司
2020-02-28 18:19
很全面,贴合银行使用场景,详细的介绍了分布式存储在非结构化数据的应用优势及注意事项。

wmchoa@wmchoa 对了,作为银行的运维,对存储侧提供的运维平台上的对象存储,有什么样的需求呢

2020-06-04 14:06

wmchoa@djl2020 感谢分享,需求分析很详细,请问一下,从文件向对象的应用侧接口改造,最终是银行的研发队伍改造的还是存储厂商协助改造的

2020-06-04 14:04
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

作者其他文章

相关文章

相关问题

相关资料

X社区推广