HDFS 与 APFS：文件系统之禅
2017-09-20
我的 iPhone 刚更新了 ios11 ，可以看出存储空间比上一个版本多出来约 8 个 G ，我们知道这是因为 Apple 采用了全新的文件系统 APFS ，但还是忍不住惊讶与好奇： 同样是文件系统， APFS 到底是怎样的？与 HDFS 有什么差异？有没有互相借鉴再优化的可能？
我们看APFS在文件处理上是怎么做的：
APFS 通过克隆可以使文件系统快速、高效地在同个卷宗上复制文件，且不须占用额外存储空间。对数据的修改将写入其他位置，未修改的块则继续共享使用。对文件的更改将使用差分编码保存，减少文档修订和复制所需的存储空间。
根据过往的 HDFS 的使用经验，我迫不及待的想要将两个文件系统放在一起比较一下。
我们先来看 APFS(Apple File System)：
APFS
APFS 为闪存和固态存储设备优化，具有写入时复制等设计特点，使用I/O合并改进性能。
特点
苹果文件系统使用 64 位 inode 号码，并允许使用更安全的存储。与 HFS+ 类似，为了提供更好的空间管理与性能， APFS 的代码使用TRIM命令。由于 APFS 采用全新的数据计算方式，设备的读写速度与可用空间可能会因此提升。
克隆
克隆可以使文件系统快速、高效地在同个卷宗上复制文件，且不须占用额外存储空间。对数据的修改将写入其他位置，未修改的块则继续共享使用。对文件的更改将使用差分编码保存，减少文档修订和复制所需的存储空间。
快照
APFS 支持创建特定时间点、文件系统只读实例的快照。
加密
APFS 将实现文件和敏感元数据的磁盘加密。它对一个容器中的每个卷支持下列加密模型：
- 不加密
- 单密钥加密
- 多密钥加密，每个文件使用单独的密钥加密，元数据再使用另一个密钥加密。
数据完整性
APFS 利用现代硬件固件中强大的校验和和错误纠正的优势。为确保数据完整性， APFS 对元数据采用校验和技术，但未同时对用户数据采用。
崩溃防护
APFS 被设计为可以免受崩溃带来的数据损失。它使用“写入全新的元数据记录、指向新的记录、释放旧的记录”的逻辑，而非直接覆盖现有的记录。这能避免更新期间崩溃而导致的记录损坏，也能防止重复写入两次更改（ HFS+ 日志文件系统需要将更改先写入日志，再写入目录文件）。
限制与不足
第一代 APFS 不为用户数据提供校验和，但通过基于元数据的校验和检查来确保数据完整。另外，它并不利用易失性存储器可比特寻址这一特性，也不支持压缩。 与 HFS+ 不同的是，在 macOS High Sierra 测试版本之前， APFS 不进行 Unicode 正规化，无法支持大多数非英语语言。
我们再来看 HDFS (Hadoop Distributed File System)：
HDFS
特点
HDFS 与其他分布式文件系统有许多相似点，但也有几个不同点。一个明显的区别是 HDFS 的 “一次写入、多次读取（write-once-read-many）” 模型，该模型降低了并发性控制要求，简化了数据聚合性，支持高吞吐量访问。 HDFS 的另一个独特的特性是下面这个观点：将处理逻辑放置到数据附近通常比将数据移向应用程序空间更好。 HDFS 将数据写入严格限制为一次一个写入程序。字节总是被附加到一个流的末尾，字节流总是以写入顺序存储。
目标
- 通过检测故障和应用快速、自动的恢复实现容错性
- 通过 MapReduce 流进行数据访问
- 简单可靠的聚合模型
- 处理逻辑接近数据，而不是数据接近处理逻辑
- 跨异构普通硬件和操作系统的可移植性
- 可靠存储和处理大量数据的可伸缩性
- 通过跨多个普通个人计算机集群分布数据和处理来节约成本
- 通过分布数据和逻辑到数据所在的多个节点上进行平行处理来提高效率
- 通过自动维护多个数据副本和在故障发生时自动重新部署处理逻辑来实现可靠性
Name node 和 Data node
在 HDFS 中，一个给定的 Name node 管理一些文件系统名称空间操作，比如打开、关闭以及重命名文件和目录。 Name node 还将数据块映射到 Data node，处理来自 HDFS 客户端的读写请求。 Data node 还根据 Name node 的指令创建、删除和复制数据块。
数据复制
HDFS 复制文件块以便容错。应用程序可以在一个文件创建时指定该文件的副本数，这个数量可以在以后随时更改。 Name node 负责所有块复制决定。
HDFS 使用一个智能副本放置模型来提高可靠性和性能。优化副本放置使得 HDFS 不同于其他大多数分布式文件系统，而一个高效使用网络带宽的、具有机柜意识的副本放置策略将进一步促进这种优化。 大型 HDFS 环境通常跨多个计算机安装点运行。不同安装点中的两个 Data node 之间的通信通常比同一个安装中的 Data node 之间的通信缓慢。因此， Name node 试图优化 Data node 之间的通信。 Name node 通过 Data node 的机柜 ID 识别它们的位置。
数据组织
HDFS 的一个主要目标是支持大文件。一个典型的 HDFS 块的大小为 64MB。因此，每个 HDFS 文件包含一个或多个 64MB 块。HDFS 尝试将每个块都放置到独立的 Data node 上。
数据存储可靠性
HDFS 的一个重要目标是可靠存储数据，即使在 Name node、 Data node 或网络分区中出现故障。 HDFS 克服故障的第一个步骤是探测。HDFS 使用心跳消息来探测 Name node 和 Data node 之间的连通性。
HDFS 心跳
有几种情况可能会导致 Name node 和 Data node 之间的连通性丧失。因此，每个 Data node 都向它的 Name node 发送定期心跳消息，这样，如果 Name node 不能接收心跳消息，就表明连通性丧失。 Name node 将不能响应心跳消息的 Data node 标记为 “死 Data node ”，并不再向它们发送请求。存储在一个死节点上的数据不再对那个节点的 HDFS 客户端可用，该节点将被从系统有效地移除。如果一个节点的死亡导致数据块的复制因子降至最小值之下， Name node 将启动附加复制，将复制因子带回正常状态。
数据完整性
HDFS 在确保跨集群数据完整性方面做了许多工作。它在 HDFS 文件的内容上使用 checksum 验证，将计算出的 checksums 保存在实际数据所在的名称空间中的独立的隐藏文件中。当客户端检索文件数据时，它能验证收到的数据是否匹配关联文件中存储的 checksum。 HDFS 名称空间通过每个 Name node 保存的一个事务日志存储。文件系统名称空间，以及文件块映射和文件系统属性，一并保存在一个名为 FsImage 的文件中。当一个 Name node 初始化时，它读取 FsImage 文件以及其他文件，并应用这些文件中保存的事务和状态信息。
同步元数据更新
Name node 使用一个名为 EditLog 的日志文件持久记录对 HDFS 文件系统元数据发生的每个事务。如果 EditLog 或 FsImage 文件损坏，它们所属的 HDFS 实例将无法正常工作。因此，一个 Name node 支持多个 FsImage 和 EditLog 文件副本。对于这些文件的多个副本，对任一文件的任何更改都将同步传播到所有副本。当一个 Name node 重新启动时，它使用 FsImage 和 EditLog 的最新统一版本来初始化自身。
总结
通过应用场景来看，APFS 主要为便携式移动设备(iPhone & iPad & Mac)所设计，由于硬件所限，如何在有限的空间存储大量的富媒体资料数据，同时又兼顾容灾措施是设计者在设计之初就已经确立的。
HDFS 主要为目前企业生产环境存储大量用户数据并进行分析处理的一套文件系统，运行在由廉价机器组成的服务器集群上，所以硬件的存储空间并不是短板，由此带来的 HDFS 3个数据副本也就不再是核心痛点。