背景介绍
盘古是阿里云自主研发的高可靠、高可用、高性能分布式文件系统，距今已经有将近10年的历史。盘古1.0作为阿里云的统一存储核心，稳定高效的支撑着阿里云ECS、NAS、OSS、OTS、ODPS、ADS等多条业务线的迅猛发展。但最近几年，基于如下两方面的原因，盘古还是重新设计实现了第二代存储引擎盘古2.0，其不只为阿里云，也为集团、蚂蚁金服的多种业务提供了更佳优异的存储服务
底层硬件的快速发展
最近两三年时间，分布式存储相关硬件的性能爆发式提升
- 存储介质经历了HDD、SATA SSD及NVME SSD的快速进化，IOPS提高了两个数量级，latency降低了两个数量级，4K顺序写性能低至7us，内存接口的optane存储即将进入ns时代
- 网络从千兆网、万兆网飞速发展到了25G、40G、50G甚至100G级别。网络一跳的耗时低至5us
底层硬件的快速发展为盘古提供了机遇，同时带来了严峻的挑战——为了保持业界领先的能力，盘古需要充分利用硬件的能力。
上层业务的压力
当前，越来越多的业务已经或者正在接入盘古，而业务对存储的需求千差万别，完美的支持各种业务给盘古带来了极大的压力。
- 首先，存储计算分离已经成为公司的战略，一个存储集群将为多个计算集群提供存储服务，这对存储集群提出了更高的性能需求，用最小的存储集群服务最多的计算集群是盘古未来的目标
- 其次，存储计算分离后，计算集群希望尽可能统一存储的namespace，从而存储集群内部的架构、管控等对用户透明。盘古1.0中，数据节点已经支持弹性扩展，但元数据节点仍然依赖于高配置的特殊机型，而这就限制了节点规模，进而导致单文件系统支持文件数受限。此外，过于集中的元数据服务器成为系统最脆弱的地方，部分元数据服务器的故障有可能造成整个存储集群无法正常服务。
- 再次，业务多样性也带来了接入形式多样性的需求，兼容成熟的公开接口是扩大接入范围的必要能力，支持HDFS接入的需求日渐强烈，支持POSIX接入也被多个应用方提出。
- 最后，市场竞争日趋激烈，盘古作为集团统一存储平台，必须用技术把成本压到极致，进而为商业赢得主动。
这些全方位的高要求，需要盘古在架构设计、工程实践等多个维度设立新的目标，实现新的突破。
设计目标
为了应对上述新趋势和新挑战，盘古2.0确立了四大核心设计目标：
- 卓越性能
面向新一代网络和存储软硬件进行架构设计和工程优化，释放软硬件技术发展的红利。提供高吞吐、低延迟的超高性能分布式文件系统 - 全分布式元数据管理
通过元数据的全分布式管理及动态切分和迁移，大幅提升管理的文件数规模，解决元数据节点特殊机型依赖，也进一步降低故障“爆炸半径”，提高平台稳定性。 - 系统具有充分弹性
支持多种产品形态，共享核心路径，为未来更多的业务接入留下灵活的扩展能力，避免业务接入引起架构的调整；统一硬件访问接口，支持当前及未来新硬件以最优的方式接入盘古。 - 优化成本
全面采取分层、EC，压缩、去重等技术，降低存储成本，为日益激烈的商业竞争赢得主动权，为应对数据量爆炸式增长赢得技术优势。
架构设计
为了达成前述目标，盘古2.0采取了如下图所示的分层架构。
其中，最下面一层是软硬件一体化层，负责和硬件交互，新硬件、新介质的快速引进由本层独立完成；利用软硬件一体化层提供的标准服务，结合存储业务逻辑，每台存储服务器成为一个单机存储引擎，负责数据的持久化；之上的盘古元数据层负责元数据、数据placement、一致性、可靠性等管理。此外，client、元数据层、单机存储引擎相互配合完成多副本协议、纠删码等更加复杂的功能。
使用盘古作为底层存储的业务迥异不同，为了更好的适配不同产品，充分发挥盘古的优势，盘古根据不同的业务特点提供了多种产品适配层。比如，为了更好的支持块存储相关业务，盘古提供了BlockFS接入层，其对应的ESSD云盘产品已经上线，单云盘4K极限性能测试能够达到100万IOPS，跑满双25G网络；某些业务，比如OSS、OTS及数据库使用了类似LogStream的方式访问盘古，盘古为其提供了LogFile适配层；为了接入开源生态，让Hadoop社区也能无缝的使用盘古，盘古提供了HDFS兼容适配层。适配层桥接产品层及盘古核心基础层，帮助业务简单、高效的接入盘古，进而享受到盘古带来的高性能、高可靠的分布式存储服务。
基础核心
盘古的核心基础层主要由client、MetaServer及Chunkserver三个角色组成。
如上图所示，MetaServer负责目录树、数据placement等元数据管理；Chunkserver负责数据的读写及维护；client通过少量MetaServer的元数据交互，主要和Chunkserver协作完成数据持久化工作。盘古的整体架构和HDFS很相似，从而能够在语义上完美兼容HDFS，避免Amazon S3等对象存储在适配HDFS时遇到的多种问题，例如rename/delete的原子性问题。
当然，如果盘古只是HDFS的简单复制的话，那么上层业务是没有动力接入盘古的。盘古在多个方面超前的设计及实现吸引了越来越多的用户，简单介绍如下：
全分布式元数据管理
盘古2.0使用了全分布式元数据管理策略，MetaServer可以水平扩展。根据预设策略进行partition，每个partition内部的多个MetaServer使用RAFT协议来实现服务高可靠和高可用，MetaServer的持久化数据通过metachunk的形式在Chunkserver持久化。
这种scale-out的设计，使得单集群不再有文件数上限。同时由于MetaServer故障只会影响一部分meta partition，减小了故障的爆炸半径，而且在MetaServer快速迁移后，能够进一步减少故障的影响时间。
高效的IO路径
全分布式元数据管理为盘古带来了更高的稳定性和扩展性，而高效的IO路径为盘古解决了性能问题。
在充分比较了基于Raft及Client协调一致的IO路径后，盘古使用了后者，因为Raft方式存在一些较难解决的问题，比如EC的支持、多数副本failure时服务不可用、大集群RaftRing数据爆炸等。而Client协调方式完美的回避了这些问题，简化了逻辑，提升了性能。
优异的线程模型
盘古2.0的架构已经有足够的优越性，工程实现同样重要，为了更好的性能，盘古的Data path采用了run-to-completion并发模型，IO请求的整个处理都在同一个线程中完成，节省了线程间同步、CPU的cache miss、context switch等开销。为了利用此并发模型获得极致性能，盘古从底层的RDMA/TCP网络库、SPDK IO库，到业务层的各个模块都精心设计，全链路打通。
高性能网络库
盘古的性能开销已经最低，灵活高效的压榨硬件性能，才能打造极致性能存储系统。在提供高速网络的环境，盘古支持使用RDMA进行RPC通讯，而且RDMA的支持被封装到RPC内部，对上层业务透明，盘古可以根据业务需求对不同的请求灵活使用TCP及RDMA通讯
成本控制
高可靠、高性能的分布式文件系统保障了盘古的地位，而有效的控制成本，能够更进一步为商业带来主动，所以盘古尽其可能的利用各种策略压缩成本
- 支持多介质大存储池
盘古2.0支持异构介质的大存储池，在Chunkserver内部能够混合使用SSD、HDD等多种介质，支持将不同文件或文件的不同replica放置到指定的不同介质上。从而满足业务元数据/数据，前台/后台数据等对容量、性能、成本等维度的不同要求。另外，大存储池用于多个业务的混布，在更大的存储池里实现资源分配利于提高资源利用率。 - Erasure Coding
在最新的HDFS 3.0中加入了EC的支持，而盘古在1.0中就支持了后台EC，2.0中完成了前台EC的支持，同多副本相比，这能够显著的降低IO及网络的流量，在某些场景下，在降低成本的同时，能够带来更高的throughput。
DFS
在阿里云，有很多用户购买ECS的虚拟机搭建Hadoop生态做大数据分析，其中HDFS是必不可少的组件。但HDFS做为非云化存储系统，弹性差，管理成本高，同时存在小文件性能差，缺乏企业级容灾功能等问题。此外，云上用户也有HDFS和其他云上数据互联互通的需求。
盘古作为阿里云的企业级存储，已经较完美的解决上述问题。为了让开源生态的各种应用方便的接入盘古，盘古开发了HDFS兼容的高性能云化分布式文件系统DFS。它能够提供海量数据无缝接入，和阿里云的其他存储产品打通等优势。利用盘古的软硬件一体化设计，提供了端到端的极致性能和超低成本。另外，盘古独特的智能化管理运维能力，降低了用户的运维成本，提供优秀用户体验。
DFS的架构很简单，底层依托于盘古分布式文件系统，用户通过定制的DFS Client把HDFS文件系统的访问转发给DFS Server，DFS Server把HDFS请求翻译成盘古请求。所以和盘古源生业务相比，DFS理论只增加了一层网络消耗。
当前DFS已经完成多个开源生态兼容性测试，比如
- Hadoop fs commands
- MapReduce without YARN + DFS
- MapReduce with YARN + DFS
- Hive without YARN + DFS
- Hive with YARN + DFS
- Spark without YARN + DFS
- Spark with YARN + DFS
- TPC-DS测试SparkSQL + DFS
- TPC-DS测试Impala + DFS
因为有底层的盘古做保障，DFS支持强大的弹性伸缩能力，单存储集群能够达到上万台的规模，容量能够突破1EB，性能是HDFS的5-7倍。此外，99.95%的可用性、11个9的可靠性、3AZ更功能为用户提供更高的安全保障。
未来展望
盘古虽然在当前达到了业界领先的水平，但是新技术、新需求层出不穷，如果我们不紧紧跟随的话，有可能很快会被淘汰出局。因此，盘古一直关注底层依赖硬件、上层业务特点的演进，比如盘古正在尝试把Device-Based SSD换成Host-Based SSD，从而软硬件结合，更好的利用硬件性能；同时开发全链路QoS功能，解决存储计算分离场景的多用户多任务资源争抢问题
