关于数据库:云上大数据存储探究-JuiceFS-与-HDFS-的异同

HDFS 作为 Hadoop 提供存储组件，曾经成为大数据生态外面数据存储最罕用的抉择，通常在机房环境部署。

JuiceFS 是一个基于对象存储的分布式文件系统，用户能够在云上疾速地搭建按需扩容的弹性文件系统。

如果企业正在思考在云上构建大数据平台，理解这两种产品的差别和优缺点，能够为企业迁徙或切换存储产品提供参考。这篇文章将从技术架构、性能个性、应用场景等多个方面来解析 HDFS 和 JuiceFS 的异同。

1. 架构

1.1 HDFS 架构

HDFS（Hadoop Distributed File System）是 Hadoop 生态系统中的分布式文件系统。在 HDFS 的架构中，有两种类型的节点：NameNode 和 DataNode。一个最简略的 HDFS 集群就是由一个 NameNode 和一组 DataNode 组成。

NameNode 是 HDFS 的元数据管理节点，负责管理文件系统的命名空间和响应客户端对文件元数据的申请（比方 create，open，rename，delete 等申请），同时，NameNode 也负责管理 DataNode 和数据块的映射关系，保护所有文件和目录的层次结构，记录文件的名称、文件大小、文件块的地位等信息。在生产环境应用时，HDFS 须要部署多个 NameNode 并联合 ZooKeeper 和 JournalNode 来实现高可用。

DataNode 是 HDFS 的数据存储节点，负责存储理论的数据。一个文件会被宰割成一个或多个文件块，每个 DataNode 节点存储一部分数据块，并向 NameNode 汇报存储的块的列表和状态信息。DataNode 节点解决客户端的读写申请，向客户端提供文件块的数据。

1.2 JuiceFS 架构

与 HDFS 不同，JuiceFS 社区版采纳的是插件化架构，JuiceFS 的文件数据是被切分后并保留在对象存储（如 Amazon S3、MinIO）中，元数据则存储在用户抉择的数据库中，例如 Redis、TiKV、MySQL 等。这种架构的设计使得 JuiceFS 能够通过共享同一个数据库和对象存储实现强一致性保障的分布式文件系统。

JuiceFS 的元数据管理是齐全独立于数据存储的，这意味着 JuiceFS 能够反对大规模数据存储和疾速文件系统操作，同时放弃高可用性和数据的一致性。JuiceFS 提供了兼容于 Hadoop 生态的 Java SDK，反对 HDFS 到 JuiceFS 的无缝切换，与此同时，JuiceFS 还提供了包含 POSIX、S3 Gateway、Kubernetes CSI Driver 等多种 API 和工具，使其易于集成到现有的应用程序中。

JuiceFS 企业版有着与社区版统一的技术架构，不同之处在于 JuiceFS 企业版面向对性能、可靠性和可用性要求更高的企业级用户提供了一套自研的分布式元数据存储引擎。同时在社区版的根底上提供了一系列高级性能，包含 Web 控制台、快照、跨区数据复制、文件系统镜像等。

2. 根底能力

这部分内容将对 HDFS 与 JuiceFS 的架构外围进行拆解，进一步比照它们在元数据管理、数据管理以及拜访协定反对方面的特点和差别。

2.1 元数据

2.1.1 元数据存储

HDFS 将元数据存储在内存中，应用 FsImage 和 EditLog 两种技术来保障元数据不失落和重启后疾速复原。

JuiceFS 社区版采纳独立的第三方数据库来存储元数据，比方 Redis、MySQL、TiKV 等。截止本文公布，JuiceFS 社区版反对三类共 10 种事务型数据库。

JuiceFS 企业版采纳自研的高性能元数据存储引擎，JuiceFS 企业版将元数据存储在内存中，通过 changelog 和 checkpoint（相似于 HDFS 的 EditLog 和 FsImage）保证数据不失落和重启疾速复原。

2.1.2 元数据内存耗费

HDFS 每个文件的元数据约占用 300 字节内存空间。

JuiceFS 社区版应用 Redis 作为元数据引擎时，每个文件的元数据约占用 300 字节 内存空间;

JuiceFS 企业版热数据每个文件的元数据约占用 300 字节 内存空间。JuiceFS 企业版反对内存压缩，针对不常应用的冷数据，内存占用能够升高到每个文件 80 字节左右。

2.1.3 元数据扩容

元数据存储是一个要害的组件，因为它蕴含了文件系统中所有文件和目录的信息。如果元数据存储的容量有余，那么就会对文件系统的性能和可靠性造成影响。

HDFS 能够采纳联邦的形式来解决单个 NameNode 的容量限度问题。联邦中的每个 NameNode 是独立的命名空间，它们能够共享同一个 DataNode 集群来简化治理。利用须要拜访指定的 NameNode 或者通过动态配置的 ViewFS 来形成对立命名空间，但垮 NameNode 的操作都是不反对的。

JuiceFS 社区版应用第三方数据库作为元数据存储，这些数据库系统通常都有较为成熟的扩容计划，一般来说只需简略的减少数据库的容量或者增加数据库的集群节点即可实现存储扩容。

JuiceFS 企业版也反对元数据集群的程度扩容，多个元数据服务节点独特组成繁多命名空间，以撑持更大规模的数据和解决更多的拜访申请，进行横向扩大时无需客户端做任何批改。

2.1.4 元数据操作

HDFS 对文件门路的解析是基于残缺门路的。HDFS 客户端会将须要拜访的残缺门路间接发送到 NameNode，因而，任何深度文件的申请都只须要进行一 RPC 次调用。

JuiceFS 社区版基于 inode 进行文件门路拜访，依据文件层级从根目录开始逐层查找，直到找到最终文件。因而，依据文件深度可能存在屡次 RPC 调用。为了减速此过程，一些反对疾速门路解析的元数据引擎，如 Redis，服务端可能间接解析最终文件。如果应用的数据库不反对疾速门路解析，能够通过启用元数据缓存来减速此过程。同时，启用元数据缓存后，能够加重元数据服务的压力。然而，启用元数据缓存后会导致一致性语义有所扭转，须要依据具体场景调节参数。

JuiceFS 企业版反对服务端门路解析，申请任何深度的文件都只需一次 RPC 调用即可。

2.1.5 元数据缓存

元数据缓存能够显著进步文件系统的性能和吞吐量，通过将最罕用的文件元数据存储在缓存中，元数据缓存能够防止频繁地从元数据服务器获取元数据，从而缩小 RPC 调用，进步性能。

HDFS 不反对客户端元数据缓存。

JuiceFS 社区版和企业版均反对在客户端缓存元数据，以减速 open、list、getattr 等元数据操作，升高元数据服务的负载。

2.2 数据管理

2.2.1 数据存储

HDFS 默认以 128M 的块来存储文件，会在三个不同的 DataNode 上存储每个数据块的三个正本进行容错，以此来保障存储的可靠性，能够通过批改配置来调整正本数量。此外，HDFS 还反对纠删码（Erasure Coding），一种高效的数据编码技术，通过将数据块切分成多个数据块并编码存储来提供容错机制。与正本相比，纠删码能够节俭存储空间，但会减少计算负载。

JuiceFS 则将数据拆分成 4M 的块存储在对象存储中，同时为大数据场景引入了 128 M 的逻辑分块用来做计算工作划分。因为 JuiceFS 采纳对象存储作为数据存储层，数据的可靠性取决于选用的对象存储，个别的对象存储服务会通过多正本复制、纠删码等技术为存储的可靠性提供保障。

2.2.2 数据缓存

HDFS 能够将指定数据缓存在服务端 DataNode 的堆外内存中，从而来进步数据拜访的速度和效率。比方 Hive 场景下，能够将小表缓存在 DataNode 内存中，进步 join 速度。

JuiceFS 的数据长久化层个别在对象存储上，而对象存储通常都有较高的根底时延。为了解决这个问题，JuiceFS 提供了客户端数据缓存性能，通过将对象存储上的数据块缓存在本地磁盘上，从而进步数据拜访的速度和效率。

JuiceFS 企业版除了根本的客户端缓存能力外，还提供了缓存共享性能，多个客户端能够组成缓存集群，共享本地缓存。此外，JuiceFS 企业版还能够搭建独立的缓存集群，为弹性伸缩的计算节点提供稳固的缓存能力。

2.2.3 数据亲和性

HDFS 为每个数据块提供存储地位信息，能够被 YARN 等资源调度器用于实现亲和性调度。

JuiceFS 反对应用本地磁盘缓存来减速数据拜访。它通过事后设置的计算节点列表为每个数据块计算生成偏好的地位信息，让 YARN 等资源调度器将同一个数据调配的计算调度到固定节点，以进步缓存数据的命中率。

JuiceFS 企业版还反对在多个计算节点之间共享数据缓存，即便计算工作没有调度到偏好的节点，也能够通过计算节点间的网络拜访其余节点上缓存的数据。

3. 性能与个性

3.1 数据一致性

HDFS 和 JuiceFS 的元数据都是保障强一致性的（CP 零碎），能够为文件系统数据提供强一致性保障。

JuiceFS 反对元数据的客户端缓存，当启用客户端缓存时，可能会影响数据一致性，须要利用的一致性要求正当设置。

对于读写混合场景，HDFS 和 JuiceFS 均提供 open-after-close 语义，即保障新关上的文件，可能读到之前曾经 close 的文件所写入的数据。而当一个文件继续关上时，它可能读不到其余客户端写入的数据。

3.2 数据可靠性

个别利用往 HDFS 写数据时，都是依赖胜利的敞开文件来确保数据被长久化，JuiceFS 也是一样的。

为了给 HBase 提供低时延的数据写入形式（通常在 HBase 的 WAL 文件应用），HDFS 提供 hflush 办法来就义数据长久化（只写入到多个 DataNode 的内存中）以取得低时延。

JuiceFS 的 hflush 会将数据长久化到客户端的缓存盘上（writeback 模式），依赖于缓存盘的性能和可靠性。另外，当往对象存储上传的速度更不上时，或者客户端退出，可能导致其余节点读不到刚写入的数据，会影响 HBase 的故障恢复能力。

为了更高的数据可靠性，HBase 能够通过 HDFS 的 hsync 接口来保证数据长久化。JuiceFS 也反对 hsync, 此时 JuiceFS 会将数据长久化到对象存储中。

3.3 并发读写

HDFS 和 JuiceFS 都反对多机并发读同一个文件，能够取得比拟高的读性能。

在并发写方面，HDFS 不反对多个客户端同时对同一个文件进行写操作。而 JuiceFS 反对并发写，但须要利用本人管理文件的偏移量 (offset)，如果多个客户端同时向雷同的偏移量写入数据，可能会导致数据的互相笼罩。

HDFS 和 JuiceFS 一样，如果多个客户端同时关上一个文件，其中一个客户端对文件进行了批改，其余客户端可能不能读到最新的批改。

3.4 安全性

Kerberos 用于身份认证。HDFS 和 JuiceFS 企业版均反对。JuiceFS 社区版本仅反对应用认证后的用户名，无奈判断用户真伪。

Apache Ranger 用于受权。HDFS 和 JuiceFS 企业版均反对。JuiceFS 社区版不反对。

HDFS 和 JuiceFS 企业版均反对给目录和文件设置额定的拜访规定（ACL），JuiceFS 社区版不反对。

3.5 数据加密

HDFS 实现了通明的端到端加密。一旦配置实现，用户从非凡的 HDFS 目录中读写数据时，数据会被主动加密和解密，无需对利用程序代码进行批改，操作过程对用户通明。详见：Apache Hadoop 3.3.4 – Transparent Encryption in HDFS

JuiceFS 也反对通明的端到端加密，包含传输加密（encryption in transit）及动态加密（encryption at rest）。在用户开启了动态加密时，须要用户一个自行治理的密钥，所有写入的数据都会基于此密钥进行数据加密，详情见《数据加密》。这些加密都利用都是通明的，无需批改利用代码。

3.6 快照

HDFS 的快照是指对某个目录的只读镜像，可能让用户继续不便一个目录在某个工夫点上的状态。快照中的数据是只读的，任何原目录的批改都不会影响到快照。在 HDFS 中，快照是通过记录文件系统目录树上的元数据信息来实现的，具备以下特点：

• 快照的创立是即时的：老本是 O(1)，不包含节点查问工夫。
• 只有在绝对于快照进行批改时才会应用额定的内存：内存使用量为 O(M)，其中 M 是批改的文件 / 目录的数量。
• 数据节点中的块不被复制：快照文件记录了块列表和文件大小。没有数据复制。
• 快照不会对惯例的 HDFS 操作产生不利影响：批改是按工夫程序倒过去记录的，因而能够间接拜访以后数据。快照数据是通过从以后数据中减去批改内容来计算的。

另外利用快照差别（snapshot diff），能够疾速的拷贝增量数据。

JuiceFS 企业版快照性能采纳了相似克隆的形式实现，疾速复制元数据而不复制底层数据，创立快照是 O(N), 内存使用量也是 O(N)。与 HDFS 的快照不同，JuiceFS 的快照能够被批改的。

3.7 存储配额

HDFS 和 JuiceFS 均反对文件数和存储空间配额。JuiceFS 社区版须要降级到行将公布的 1.1 版本。

3.8 符号链接

HDFS 不反对符号连贯。

JuiceFS 社区版反对符号链接，Java SDK 能够拜访通过 POSIX 接口创立的符号链接（相对路径）。

JuiceFS 企业版除了反对相对路径的符号链接外，还反对链接到内部存储系统（HDFS 兼容），实现相似于 Hadoop 的 ViewFS 的成果。

3.9 目录使用量统计

HDFS 提供 du 命令能够取得某个目录的实时使用量统计，JuiceFS 也反对 du 命令，企业版能够提供跟 HDFS 相似的实时后果，社区版则须要在客户端遍历子目录来统计。

3.10 弹性伸缩

HDFS 在存储空间的弹性伸缩方面反对动静节点调整，但这可能波及数据迁徙和负载平衡问题。相比之下，JuiceFS 通常应用云上对象存储，其人造的弹性使得存储空间能够按需应用。

3.11 运维治理

在运维治理方面，HDFS 各个大版本存在不兼容性，同时须要匹配其余生态组件版本，降级过程较为简单。相比之下，JuiceFS 社区版和企业版均反对 hadoop2 和 hadoop3，降级简便，只须要替换 jar 文件即可。此外，JuiceFS 提供工具来导出和导入元数据，不便在不同集群之间进行数据迁徙。

4. 实用场景

在比拟抉择 HDFS 和 JuiceFS 时，须要思考不同的应用场景和需要。

HDFS 更适宜规模比拟固定的机房环境，应用裸盘作为存储介质，无需思考弹性和存算拆散需要的应用场景。而在私有云环境下，私有云可提供的裸盘节点类型比拟少，对象存储成为了更好的存储抉择，通过 JuiceFS 能够实现存算拆散以取得更好的弹性，同时反对 Hadoop 大数据生态的绝大部分利用，会是更高效的抉择。

此外，当大数据场景还须要跟其余利用（比方 AI) 共享数据时，因为 JuiceFS 提供了更丰盛的接口协议，能够很不便地在各个利用之间共享数据，省去了数据拷贝的麻烦，也会是更不便的抉择。

5. 总结：

个性

拜访协定

尽管 HDFS 也提供了 NFS Gateway 和 基于 FUSE 的客户端，但因为跟 POSIX 的兼容性比拟差，性能也不够好而很少被应用。

如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)