今天给大家带来的是百度沧海·文件存储CFS推出新一代Namespace架构的相关内容，下面我们一起来看具体详情！
随着移动互联网、物联网、AI计算等技术和市场的迅速发展，数据规模指数级膨胀，对于分布式文件系统作为大规模数据场景的存储底座提出了更高的要求。已有分布式文件系统解决方案存在着短板，只能适应有限的场景：
新型分布式文件系统无法承接传统领域内的所有WorkLoad：通过只支持部分POSIX接口来简化系统设计，无法完全兼容POSIX协议。
传统分布式文件系统无法支持海量小文件场景：为了保证低延迟，元数据的可扩展性较差、随文件规模性能和稳定性下降严重，无法支持如AI训练、自动驾驶等文件规模达到十亿甚至百亿规模的AI场景。
因此，设计出一款不仅能完美兼容传统应用，又能适应新的AI场景需求的分布式文件存储，显得意义重大。这样的分布式文件系统需要满足：
完全兼容POSIX协议。
在确保元数据低延迟、稳定的情况下，可线性扩展，支持百亿文件规模，具备超大规模文件数量元数据操作能力的同时具备超高的性能稳定性。
要想达到以上目标，百度沧海·文件存储CFS给出的技术解答是设计新一代的Namespace子系统，在实现创建文件每秒百万级QPS的同时，保证各项性能指标表现稳定。
这使得文件存储CFS不仅可以支持传统应用，作为传统业务上云的存储方案；也可以应用于最新的AI场景，满足海量文件规模处理的应用需求。
Namespace的技术现状
Namespace子系统的功能主要是维护文件系统的文件属性、目录树结构等元数据信息，同时支持兼容POSIX的目录树及文件操作，如：文件/目录创建、查找（Lookup/Getattr）删除及重命名（Rename）等。
当前，业界分布式文件系统领域衍生出各种类型的Namespace技术架构，可以归类为如下几种:
单机架构：配合单机全内存，可做到低延迟，无法横向扩展，最大规模仅支持5亿文件数，代表产品为HDFS。
并行架构：适用于HPC等并行文件系统应用场景，元数据静态切分到多机部署，单机利用一主一备保证可用性，缺乏弹性扩展能力。
分布式架构：将元数据按照某种方式切分和扩展到一组机器上，按照集群的方式管理。
相对于单机架构不可扩展及并行架构对扩展性的弱支持，分布式Namespace架构在扩展性上做的更加彻底。
那么直接引入一套现成的分布式Namespace架构是否可以直接解决上文提到的挑战呢?
答案是否定的，因为现有的分布式Namespace架构都存在各自的局限性和不足。
基于Hash Based架构尽管具有很好的扩展性及负载均衡效果，但是其牺牲了POSIX兼容语义的支持。该架构方案将文件全路径Hash来组织打散到分布式Meta集群，对于Lookup路径查找非常友好同时容易实现，但是缺点是牺牲了元数据的局部性，尤其是rename的实现复杂度高且性能很差，这类架构主要停留在学术研究，没有在工业界大规模应用，典型的系统如Dr.Hadoop,GiraffaFS；
基于子树划分架构保证了元数据的局部性，可兼容POSIX语义，但是扩展性不够好。该架构方案通过将层级目录树拆分成多个子树并将每颗子树按照相应的负载策略部署到不同的Meta节点中，单节点上具有很好的元数据局部性，但是缺点就是容易产生热点，负载均衡难以实现，扩展性不够好，典型的实现如CephFS、IndexFS;
相对于前两种架构都具有明显的局限性且难以弥补，近几年脱颖而出的基于分布式数据库或分布式KV的Namespace架构兼顾了扩展性及POSIX语义兼容支持。
该方案通常采用分层架构：上层维护了一层元数据处理层，该层将目录树POSIX操作转化为数据库事务请求。下层是分布式数据库或分布式KV层，负责元数据的存储管理，同时对上层的数据库事务请求进行语义处理。
通过这样的分层架构就做到了对POSIX语义的完整兼容。同时，利用分布式数据库或分布式KV本身的可扩展性，做到了NameSpace架构的可扩展。
另外，为了进一步提升POSIX语义的处理速度，通常会维护一层Hint Cache来加速元数据的处理。
虽然该架构方案可以在存储层面做到弹性可扩展且简化了元数据的处理，但由于现有架构对锁及数据库事务存在强依赖，Namespace在写延迟及写性能的扩展性层面仍然存在不足，难以支持每秒创建百万以上的文件的需求。
百度智能云CFS在此架构基础上改进和扩展出新一代的Namespace架构。
CFS的Namespace架构
百度沧海的文件存储CFS作为百度智能云提供的分布式文件存储服务，通过标准的文件访问协议（NFS/SMB），为云上的虚机、容器等计算资源提供无限扩展、高可靠、地域级别共享的文件存储能力。
为了兼顾传统及AI场景的用户需求，弹性可扩展且兼容POSIX一直被作为CFS架构尤其是Namespace子系统的重要设计目标。
基于分布式KV架构，CFS采用自研的分布式索引系统来支撑Namespace子系统，并基于该索引系统实现了分层架构，即POSIX语义层+分布式KV层。该索引系统经过CFS产品多年的打磨，目前可以非常好地解决Namespace层级结构扩展性与低延迟的需求。
相比于其他基于分布式数据库或分布式KV的分布式文件系统（比如HopsFS），CFS不直接依赖底层分布式数据库或分布式KV层的锁及事务机制来维持POSIX语义，而是通过以下创造性的设计配合来解决：
适配层级结构数据模型，定制化Schema来降低KV层数据之间的关联性。
在POSIX语义层设计一套针对Namespace层级结构、相对数据库锁及事务机制更轻量的一致性协议，保障所有Namespace层的读写操作不会破坏POSIX语义。
基于以上设计，CFS在Namespace层的读写操作都具备非常低的延迟和好的线性扩展能力，具体性能参考下文测试结果。
除此之外，为了进一步优化延迟，CFS团队在该架构的各个层面做了深入优化：
单机层面进一步优化延迟：单机KV引擎适配了AEP等高速硬件，确保Namespace关键路径低延迟。
一致性协议层面进一步优化扩展性及延迟：POSIX语义层一致性协议采用无状态实现，不同节点之间无需同步、无需单独部署，而是作为LIB编译到Client或者接入模块，简化了架构的维护及Namespace读写路径，同时进一步保障了架构的可扩展性。
Namespace性能测试
为了验证CFS产品Namespace架构的扩展性及性能稳定性，我们分别从扩展索引系统KV节点和Meta Client节点两个维度来测试，在验证扩展性同时给出相应单次请求的延迟数据及稳定性。
说明：以下测试workload均采用Mdtest作为元数据测试工具，其中Meta Client作为文件系统协议接入层对接标准的NFS协议，压测中的线程工作在相同FS不同路径上。
KV节点扩展
以下数据对比了10个KV节点和20个KV节点在并发mkdir的性能数据表现（图中BE对应分布式KV层一个后端KV节点）：
通过以上数据可以看出：
20个KV节点相对于10个KV节点在写吞吐上接近于两倍的提升；
当系统负载正常情况下一次Namespace写延迟只需要2ms左右；
当系统负载过高且瓶颈来到KV层，延迟长尾表现稳定；
综上，可以看出CFS的架构在KV层可以支持线性扩展。
Meta Client扩展
以下是基于集群的KV层固定为24个KV节点的对应数据，一方面通过扩展Meta Client数来验证架构在语义层的扩展性，另一方面验证架构在读和写是否具备突破百万QPS的能力。
通过以上数据可以看出：
Namespace写和读吞吐可以在POSIX语义层做到线性扩展，其中写操作（文件目录创建）可以达到100万QPS，即每秒可支持创建百万文件；路径查找（Lookup）可以达到400万QPS，目录/文件属性获取（Getattr）可以达到600万QPS。
延迟方面写延迟为2ms，读延迟只需要百us级。
CFS可以在元数据读写操作上都可以做到支持线性扩展的同时保证低延迟以及性能稳定性，并且在此基础上完成每秒创建百万文件的挑战。
更多百度沧海·文件存储CFS相关内容，百度云服务中心持续分享中！
产品详情页