某银行向对象存储架构转型升级的思路和难点分享 | 最佳实践
【摘要】本文从某银行非结构化数据存储的现状及痛点入手，深入剖析当前影像系统的架构方案瓶颈和不足，并对对象存储架构体系转型升级的需求进行深入分析，提出相应的转型思路，同时结合实际现状，抛出转型过程中需要克服的几个难点问题，希望对各位同行有所帮助。
【作者】邓毓，现就职于某银行信息科技部，资深运维工程师，农信银支付清算先进个人，荣获银行业信息科技风险管理课题研究四类成果奖。精通各项运维技术和 IT 基础架构设计，项目经验丰富，运维技术全面，在云计算、双活数据中心、软件定义存储、自动化运维、监控和 OLTP 数据库等领域有深刻的见解和广泛的涉猎。
前言
随着某银行数字化业务的持续开展和监管要求的不断提高，各线上线下业务渠道不断拓展，其产生的影像、音频、视频等非结构化数据急速增加，该行正面临现有的文件存储设施不能适应业务增长、系统管理复杂、扩展能力差、访问能力差等问题。因此亟需启动开放式海量非结构化数据的存储平台项目，来满足海量的非结构化数据存储、读取和管理需求。本文将从某银行非结构化数据存储的现状及痛点入手，深入剖析该行当前影像系统的架构方案瓶颈和不足，以及对对象存储架构体系转型升级的需求进行深入分析，并提出相应的转型思路，同时结合实际现状，抛出转型过程中需要克服的几个难点问题，希望对各位同行有所帮助和借鉴。
一、非结构化数据存储的现状及痛点
目前某银行非结构化数据 （影像数据 ） 存储、调用和归档主要采用传统的在线、 近线和离线存储分层架构体系。从影像数据来源来看，某行的影像数据主要分两大块，一块是地市影像数据，主要用于事后督查业务，另一块是总行影像数据，主要是通过柜面、智能柜台和移动营销等线下渠道、信贷系统办理客户各项业务时产生的影像数据，以及通过互联网金融 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 、柜面、智能柜台、移动营销等业务造成影响。若采用了统一的对象存储方案，且对象存储统一部署在该行生产和同城数据中心，又将引入带宽瓶颈问题。因此，需要提前对所有地市的带宽和影像业务情况进行预估，提前对地市带宽进行扩容升级。另一方面，由于对象存储分布式部署于两个数据中心，生产数据中心的影像系统读写后端对象存储，存在跨中心访问的情况，需要通过两个数据中心的大二层网络进行。因此，为了不对其他业务系统的同城容灾复制和正常网络传输造成影响，需要合理评估影像数据跨中心访问的情况，并对跨中心波分带宽进行提前扩容。
如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
某大型金融集团对象存储需求分析和架构设计
http://www.talkwithtrend.com/Document/detail/tid/419831
某券商基金非结构化数据存储现状、难点分析及未来规划
http://www.talkwithtrend.com/Document/detail/tid/419433
非结构化数据存储在制造企业中的实践
http://www.talkwithtrend.com/Document/detail/tid/422561
欢迎关注社区以下“技术主题”，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。地址：
非结构化数据存储：http://www.talkwithtrend.com/Topic/27459
对象存储：http://www.talkwithtrend.com/Topic/24493
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场