一、调研基本信息

调研目的：

了解集团内各类业务对存储系统的现状和需求，为公技存储团队提供优化和改进的方向和建议。

调研主题：集团业务需要的是什么样的存储系统？

调研方法/形式：

通过日常popo交流、面对面需求沟通、数据分析等方式，收集和整理各业务线的存储系统类型、规模、性能、成本、问题、期望等信息。

调研用户情况：

调研对象包括集团内各大业务线的研发、运维人员等，基本涵盖了互联网业务线、游戏基础设施、数帆商业化团队等多个领域。

前言

近两年公技存储团队对接的集团各类业务线越来越多，沟通的频次和深度也逐步加强，也让我们有机会能了解到各类业务的存储系统现状和需求，目前各大业务线的存储系统现状可以说是五花八门、类型繁多，因此不得不考虑一个问题，集团内各业务到底需要的是什么样的存储系统？

本文主要探讨以下几个方面的问题：

集团内各类业务对存储的需求到底是什么样的？
能不能用一套存储搞定所有业务场景？
各个业务线自己维护甚至自己开发存储系统是否真的有必要？
公技存储团队存在的价值是什么？

为了不暴露业务细节，文中所有业务均用业务A、B、C等替代。

二、用户洞察与业务思考

基于用户调研的核心发现：

集团内各类业务对存储的需求到底是什么样的？

业界选型存储系统的关注点通常包括性能、成本、稳定性、易用性、可靠性、可扩展性等几个方面。集团内部一般都是托管运维或者半托管运维，所以易用性的关注不太强烈。

业务对存储系统的性能、成本、稳定性/可靠性 3个指标如何排序？

经过我的调研了解，不同的业务诉求是不一样的，块存储场景下，只有极个别的业务如业务H，因为涉及到用户体验才对性能有较高需求，但对数据可靠性和成本关注稍低；而数据库业务B则不但要有极高的iops性能，还需要极低的时延、极高的数据可靠性。普通的云主机云盘块存储场景下，则以成本和稳定性诉求为主（价格便宜稳定不抖动）。

对象存储场景下，几乎所有业务都是以成本优先，稳定性次之，对性能几乎没有太多诉求，因为大部分业务前端都是CDN加速服务，而没有CDN加速的业务则通常都是内网访问为主。

对于共享文件存储，业务使用场景通常是AI训练和少量其他存储，通常是稳定性和成本优先，在这两个前提下性能尽量好即可。

对于使用本地盘存储的业务，如本地盘、ES/CK等，主要考虑的也是稳定性和成本，对性能的需求只要能达到或接近本地盘的性能即可。尤其是当前使用本地盘的业务，他们最担心的是替换成分布式存储之后，一旦故障会导致业务集群不可用，影响范围太广不能接受，另外分布式存储也可能会带来多副本的成本增加问题。

目前为止，尚未了解到集团内有业务使用硬件存储阵列的，可见互联网公司通常仍然会选择软件定义存储或者分布式存储方案。

业务对当前使用的存储系统满意吗？

业务H：性能不满意，受限于软硬件限制，吞吐总是有瓶颈，影响用户体验。满意度：中
业务B：数据库对iops的需求是越高越好，因此希望继续提升；另外数据库有主从高可用、高可靠，底层存储的副本数应该尽量低，以便降低成本。满意度：中
业务D：AI业务，训练时长要尽量短，存储数据的成本要尽量低，因此要提升性能降低成本，并且要保证存储服务稳定性。满意度：中高
业务F：同样是AI业务，除了对训练时长（也就是存储性能）有需求之外，最大的痛点是现有开源存储服务不稳定，经常出故障，用户抱怨很大。满意度：低
业务E：冷数据存储要方便易用，成本足够低，性能需求不高，因为是周期性转存冷数据，所以对服务的稳定性要求也不太高（偶尔停服问题不大），但不能导致数据丢失或错误。满意度：中高
业务C：对象存储只要求存储成本越低越好，不要丢数据，期望用成本更低的对象存储替换HDFS存储。满意度：高
业务Y：合规要求高，不能使用公共存储服务，要独立部署集群，对性能和稳定性有一定的要求，数据可靠性要求高。满意度：高
业务S：商业化项目对底层存储服务有依赖，要简单易运维，并且相比业界存储系统有对标优势（控标项需求强烈），当前是使用开源存储项目，优势不足。满意度：中低

从上面的业务情况可以看出，影响业务满意度的几个方面按严重程度通常是：

稳定性：这是对存储系统的最基础要求，不稳定的系统几乎大部分业务都不能接受
成本：这是进阶诉求，成本要尽量低，越低越好，降本诉求在还有增量的存储系统上尤其明显
性能：这是高阶诉求，成本和稳定性保证之后，性能要尽量能提升上去，但通常受限于成本，很难达到二者兼得

业务如果对现有存储系统不满意，会怎么做？

通常是选择调研新的存储项目（开源项目为主），并在内部尝试部署落地，如有短板则有部分业务会动手定制开发进行增强。

选择自研存储系统的业务几乎没有，因为投入产出比太低，不合算，本身存储的数据量就不太大，而开发一套稳定可靠、成本低、性能优的存储系统的人力投入和时间成本都极高。

为什么不愿意用内部开发的存储项目？而是去调研开源的存储？

这方面的问题有很多：

首先，内部开发的存储项目也不一定符合业务需求，从上面的调研来看，业务的需求也是各有不同的，一套系统很难满足全部业务。
其次，也有少量业务考虑到自身团队的人员工作产出，占地盘的思想还是存在的，部门墙很难打破。
最后，历史包袱问题，部分业务的存储系统很难切换，甚至业务的开发人员都已经更换了好几批，当前维护人已经对这些系统完全不熟悉了，这类情况是连调研新的存储项目一般都不会做。

基于用户调研的业务思考：

大一统的存储系统能不能解决所有业务场景的存储需求？

大一统的存储系统，开源的有Ceph，包括了块存储、文件存储、对象存储 3大存储形态，从功能层面基本上覆盖了所有业务的存储场景。Ceph的应用场景和用户群体规模都是首屈一指的，但Ceph能解决所有存储需求吗？显然不能，否则就没有其他分布式存储项目的立足之地了。

看业界情况的话，一般的互联网大厂都是有自研的存储系统的，通常也都是大一统的。以阿里为例，盘古是国内最知名的存储系统了，阿里基于它构建了ebs、nas、oss等存储形态，但是盘古+上层这几个存储形态解决了他们所有的业务需求吗？据我了解也没有，比如边缘计算场景，就不适合用盘古搞定，他们也是用ceph来搞定的。另外还有类似polardb开源生态，也没办法用盘古搞定，因为盘古太重了，一般的中小型业务规模都没办法部署。

我们公技存储团队目前还没有自研大一统的存储系统，我们有Curve块存储和文件存储，以及NOS对象存储，当然目前还维护一批存量的Ceph rbd/fs 集群。既然大一统的存储系统并不能解决所有业务的存储需求，那也就没有必要费时费力去做一个出来。即使要做一个自研存储，能解决内部大部分业务诉求即可。

各个业务线自己维护甚至自己开发存储系统是否真的有必要？

首先，我是不赞同业务线自己开发存储系统的，这不是业务线的主业，除非主业已经发展到足够大的量级，对存储的依赖已经到了阻碍主业发展的程度，才适合考虑自研。

其次，对于各业务线自行维护开源存储系统是否合适，我认为要分为几种情况详细讨论：

对于内部业务，存储系统对主业的重要性一般，比如只是存储一些周边数据，即使故障也不影响核心业务，并且存储系统的运维工作量不大兼职即可，数据量不大，能用就行。对于这种情况自己维护问题不大，毕竟投入少，对核心系统影响小。
对于内部业务，存储了重要业务数据，一旦故障会造成业务停顿，并且数据量比较大（PB级），这种业务就不建议自己维护了，还是交给专业的团队来做更合适，毕竟术业有专攻
对于有商业化交付需求的业务，底层存储是否要作为交付组件，甚至是否要作为控标项来体现到标书里，也需要综合考量，如果存储的数据量较小且存储系统的优势对主干业务影响不大（说白了就是够用就行，不影响用户体验），那完全没必要自己维护甚至开发存储系统，因为投入产出比太低（存储容量低收不到钱，底层存储对用户感知度低价值体验不到）。如果是严重依赖底层存储的业务（目前还没有发现集团内有类似业务），并且存储容量大，用户体验敏感，倒是可以考虑投入人力维护开发。

简单总结下：非核心业务依赖且数据量太少没必要折腾，开源项目部署凑合用或者所在业务线有基础设施部门提供服务直接用。重要且是核心依赖的业务可以自研或与专业的存储团队共建。商业化看能不能帮团队赚到更多利润，能就做不能就拉倒。

公技存储团队存在的价值是什么？

提供存储基础设施服务，减少各业务线的存储维护成本，提升服务稳定性和可靠性
统一资源池，通过软硬件优化提升存储密度降低单位存储成本
提供能满足大多数业务存储需求，且相比外部服务商更有性价比的存储服务

根据上面调研，存储服务的需求多样性和业务定制化需求较多，数据规模、存储形态、接口格式、性能要求、可靠性要求、成本诉求等等，不同业务之间有差异，一个存储项目很难同时满足，公技存储团队同时维护多种存储产品的代价太高，受限人力就无法做到专精深，因此应该寻求开发维护相对普适的存储系统，对多数业务有价值即可，以做到投入产出比最优。对于有特殊需求的业务，可以根据业务规模和需求特点选择开源或定制甚至商业存储产品来满足。

NOS对象存储服务是这方面的代表，我们的目标是做到成本最优，稳定可靠，而不是追求极致性能，相比公有云或其他对象存储商业软件产品，NOS具备极高的性价比优势，因此能在集团内各大业务线广泛使用，也实实在在并且持续的为业务降本，业务满意度近几年持续超过4分。

另外我们当前主推的CurveFS，也是基于上述考量而投入研发的，重点解决的是业务冷数据的低成本存储问题，通过多级的缓存架构支持冷热分离、AI训练加速，当前也在探索小规模、中低负载数据量场景下HDFS替换，由于数据存储在成本较低且非常通用的对象存储上，因此公有云上使用也非常适合。