分布式存储技术（上）：HDFS 与 Ceph 的架构原理、特性、优缺点解析

面对企业级数据量，单机容量太小，无法存储海量的数据，这时候就需要用到多台机器存储，并统一管理分布在集群上的文件，这样就形成了分布式文件系统。HDFS 是 Hadoop 下的分布式文件系统技术，Ceph 是能处理海量非结构化数据存储的对象存储技术，本文将对他们的架构原理、特性和优缺点做介绍。

— 分布式文件系统 HDFS —

HDFS 全称为 Hadoop Distributed File System，在 2006 年由 Doug Cutting 发布了第一个版本，是运行在通用硬件上的分布式文件系统。它提供了一个高度容错性和高吞吐量的海量数据存储解决方案。HDFS 的推出给当时的行业提供了一个低成本、高可扩展的数据存储方案，尤其适用于互联网行业的海量用户访问日志的存储和检索需求，因此一经推出就受到了互联网行业的欢迎，以 Yahoo 为代表的互联网企业快速构建了基于 HDFS 的企业数仓，从而加速了 Hadoop 在互联网行业内的快速落地（后来这个 Yahoo 团队独立出来创立了 Hortonworks）。此后经过 3~4 年的快速发展，海外的大型企业都开始拥抱 HDFS，各种新型应用场景开始出现并创造了较大的业务价值。从 2009 年开始，国内的 Hadoop 应用开始出现，并最早在运营商和互联网行业落地。作为 Hadoop 体系的最成功的项目，HDFS 已经在各种大型在线服务和数据存储系统中得到广泛应用，已经成为私有化部署领域海量数据存储的实施标准。

HDFS 通过一个高效的分布式算法，将数据的访问和存储分布在大量服务器之中，在可靠地多备份存储的同时还能将访问分布在集群中的各个服务器之上。在构架设计上，NameNode 管理元数据，包括文件目录树，文件->块映射，块->数据服务器映射表等。DataNode 负责存储数据、以及响应数据读写请求；客户端与 NameNode 交互进行文件创建/删除/寻址等操作，之后直接与 DataNode 交互进行文件 I/O。

HDFS 通过副本机制保证数据的存储安全与高可靠，默认如上图所示配置为 3 副本，每个数据块分布在不同的服务器之上。在用户访问时，HDFS 将会计算使用网络最近的和访问量最小的服务器给用户提供访问。HDFS 支持文件的创建、删除、读取与追加，对于一个较大的文件，HDFS 将文件的不同部分存放于不同服务器之上。在访问大型文件时，系统可以并行从服务器阵列中的多个服务器并行读入，增加了大文件读入的访问带宽。通过以上实现，HDFS 通过分布式计算的算法，将数据访问均摊到服务器阵列中的每个服务器的多个数据拷贝之上，单个硬盘或服务器的吞吐量限制都可以突破，提供了极高的数据吞吐量。

HDFS 将文件的数据块分配信息存放在 NameNode 服务器之上，文件数据块的信息分布地存放在 DataNode 服务器上。当整个系统容量需要扩充时，只需要增加 DataNode 的数量，HDFS 后续通过 balance 算法将数据块搬迁到新的 DataNode 实例中。通过以上实现，HDFS 可以做到在不停止服务的情况下横向扩容和数据重新分布。HDFS 文件系统假设系统故障（服务器、网络、存储故障等）是常态，并通过多方面措施来保证数据的可靠性。数据在写入时被复制多份，可以通过用户自定义的复制策略分布到物理位置不同的服务器上；数据在读写时将自动进行数据的校验，一旦发现数据校验错误将重新进行复制。

受限于当时的需求背景和硬件能力水平，HDFS 也有一些明显的架构问题，随着技术和需求的演进而逐渐成为瓶颈。通过 NameNode 来管理元数据有它的架构问题，首先是服务高可用问题，在 Hadoop 1.0 时代这是最大的架构问题，不过在 2013 年 Hadoop 2.0 中通过 Master-Slave 的方式得以解决；另外每个存储的文件都必须在 NameNode 的内存中维护一个描述符从而占据内存空间，当文件数据量太大时就会受限于单个 NameNode 的内存资源从而导致性能瓶颈（一般单个集群文件数量在亿级别以上时），社区在 2017 年推出的 Hadoop 2.9 版本提供 HDFS Router Federation 功能，通过不同的 NameService 处理挂载在 HDFS 上不同目录下的文件的方式来缓解这个问题。

存储成本问题对于大型 HDFS 集群是个更大的问题，HDFS 的三副本策略保证了性能和存储成本的均衡，适合于热数据和温数据的存储和处理，对于冷数据存储来说成本就偏高，尤其与对象存储类的解决方案相比。开源社区直到 2019 年 Hadoop 3.0 里才推出了 Erasure Code 技术（星环科技在 2014 年推出 HDFS EC 技术），但由于推出时间较晚和技术成熟度等原因，目前并没有大规模落地。与云计算的存储技术融合是另外一个重要的架构问题，公有云有成熟的云存储方案，相对 HDFS 成本更低，与云平台的调度系统协调的更好，而 HDFS 只能定位作为云上的企业存储的一个细分方案之一。如各个云平台都推出 EMR（Elastic MapReduce）类产品，如 Google Dataproc，阿里云 EMR 等，但总体受欢迎度比较一般，缺少与云上其他数据分析与处理系统的全方位的打通和互联。

从 2012 年开始，国内重点行业的中大型企业都已经开始了大数据的布局，到 2019 年像金融、运营商、能源、政府公安等重要行业大部分企业都已经构建了基于 HDFS 的数据存储系统，推动了一批重点的数字化应用的推广。如金融行业的 ODS、历史数据存储、数据湖、科技监管类应用，运营商的经分系统、电子围栏、数字营销系统等，都已经是广泛使用的业务系统。由于国内外行业需求的差异性以及对公有云的接受程度不同，HDFS 在国内仍然是一个非常重要的数据存储技术，也拥有更好的技术和应用生态，因此有着更为完善的技术生命力。

— 对象存储 Ceph —

对象存储的设计目标是为了处理海量非结构化数据的存储问题，如邮件、图谱、视频、音频以及其他多媒体文件，并在社交、移动等应用中大量被使用，此外也大量被用于数据备份和灾备场景。

在业务开发层一般提供基于 S3 协议的开发接口，这套 API 提供了一整套的 RESTful API，可以让应用可以通过 HTTP PUT 或 GET 命令来操作数据对象，每个对象有个自己的访问地址。与 HDFS 等文件类存储采用目录结构或多层级树形结构不同，对象存储在物理存储上一般采用一个扁平的数据存储结构，每个对象都是一个包括元数据、数据和唯一标识 ID 的完备数据描述，这样应用可以非常方便的去找到并访问这个数据对象，在存储的管理上也相对比较简单，尤其是大部分应用场景下数据对象都存储在远端的云服务器上。对象存储管理软件会将所有的硬盘资源抽象为一个存储池，用于数据的物理化存储。相对于文件类存储，对象存储相对来说成本更低，但相对数据分析的性能不佳，需要配套各种分析的缓存技术来能提供比较好的数据分析性能。

Ceph 是一个开源的对象存储项目，诞生于 2004 年，提供对象、块和文件存储，其中对象存储功能在业内非常受欢迎，在国内已经有很多私有化云平台的对象存储生产落地案例。一个 Ceph 的存储集群一般包括三个部分：

• Ceph 存储集群服务端：在 Ceph 存储集群服务端架构中核心组件有 Monitor 服务、OSD(Object Storage Daemons)服务和 Manager 服务等。其中 Mon 服务用于维护存储系统的硬件逻辑关系，主要是服务器和硬盘等在线信息。Mon 服务通过集群的方式保证其服务的可用性。OSD 服务用于实现对磁盘的管理并实现真正的数据读写，通常一个磁盘对应一个 OSD 服务。

• Ceph Clients：以 library 方式提供的客户端，可以用于访问 Ceph 服务端，它提供了 3 种协议来访问，包括对象存储的 RADOSGW、块存储端的 RBD 以及文件存储的 CephFS。

• Ceph 协议：用于服务端和 Client 的通信协议。

由于一个分布式存储集群管理的对象数量非常多，可能是百万级甚至是千万级以上，因此 OSD 的数量也会比较多，为了有好的管理效率，Ceph 引入了 Pool、Place Groups（PGs）、对象这三级逻辑。PG 是一个资源池的子集，负责数据对象的组织和位置映射，一个 PG 负责组织一批对象（数据在千级以上）。同时一个 PG 会被映射到多个 OSD，也就是由多个 OSD 来负责其组织的对象的存储和查询，而每个 OSD 都会承载大量的 PG，因此 PG 和 OSD 之间是多对多的映射关系。

当用户要将数据存储到 Ceph 集群时，存储数据会被分割成多个对象（Ceph 的最小存储单元），每个对象都有一个唯一的 id，每个对象的大小是可以配置的，默认为 4MB。Ceph 通过自创的 CRUSH 哈希算法，将若干个对象映射到 PG 上，形成一个对象与 PG 的逻辑组合，并根据 PG 所在的 Pool 的副本数，将数据复制到多个 OSD 上，保证数据的高可用。

图片来源于：https://www.wenjiangun.com/blog/952/

在集群的可扩展性上，Ceph 可以做到几乎线性扩展。CRUSH 通过一种伪随机的方式将数据进行分布，因此 OSD 的利用就能够准确地通过二项式建模或者常规方式分配。无论哪一个都可以取得完美的随机过程。随着 PG 的增加，差异就下降：对于每个 OSD 100 个 PG 的情况下，标准差是 10%；对于 1000 个的情况下为 3%。线性的分布策略极好地将负载在集群中平衡。CRUSH 通过卸载所有的分配碎片到一个特定的 OSD 上从而来修正这样的问题。与哈希以及线性策略不同，CRUSH 同时也最小化了数据在集群扩展产生的迁移，同时又保证了负载的平衡。CRUSH 的计算复杂度为 O（log(n)）（对于有 n 个 OSD 的集群），因此只需要 10 几个微秒就可以使集群增长到好几千个 OSDs。

值得关注的是，Ceph 客户端所有的读写操作都需要经过代理节点，一旦集群并发量较大，代理节点就容易成为单点瓶颈。在数据的一致性方面，Ceph 只能支持数据的最终一致性。

— 小结—

本文从架构和原理介绍了高度容错性、高吞吐量的分布式文件系统 HDFS，和处理海量非结构化数据存储的对象存储技术 Ceph（现在各项技术发展比较快，可能存在技术描述跟最新技术发展情况不太一致的情况）。那么在特定场景下，数据的快速查询、快速写入和可扩展性也是必不可少的，下一篇我们将介绍搜索引擎技术和宽表存储技术。