从Hadoop到云：大数据平台中存储与计算解耦的原因及方法

Apache Hadoop分布式文件系统(HDFS)的出现，彻底改变了企业数据的存储、处理和分析方式，极大地推动了大数据的发展，并对整个行业带来了革命性的变革。

起初，Hadoop将存储和计算紧密集成，但随着云计算的兴起，这两大组件开始分离。对象存储作为HDFS的替代品出现，但存在一定的局限性。为了弥补这些不足，JuiceFS这一开源的高性能分布式文件系统，为计算、分析和训练等数据密集型场景提供了经济高效的解决方案。是否采用存储-计算分离的决策，取决于可扩展性、性能、成本和兼容性等因素。

本文将回顾Hadoop架构，探讨存储-计算解耦的重要性与可行性，并分析市场上现有解决方案的优缺点。我们的目标是向正在进行存储-计算分离架构转型的企业提供洞见和启发。

Hadoop架构设计特点

Hadoop作为一体化框架

2006年，Hadoop作为一体化框架问世，包含三个主要组件：

• MapReduce用于计算
• YARN负责资源调度
• HDFS实现分布式文件存储

Core components of Hadoop

多样化的计算组件

在这三大组件中，计算层的发展尤为迅猛。起初仅有MapReduce，但很快行业内涌现出Tez、Spark等计算框架，Hive作为数据仓库，以及Presto、Impala等查询引擎。这些组件配合使用时，还有众多数据传输工具，如Sqoop。

Diverse computation components

HDFS主导存储系统

大约十年间，分布式文件系统HDFS一直是占据主导地位的存储系统。它几乎是所有计算组件的默认选择。大数据生态系统内的上述所有组件都是为HDFS API设计的。某些组件还深度利用了HDFS的特定能力，例如：

• HBase利用HDFS的低延迟写入特性来处理预写日志。
• MapReduce与Spark提供了数据本地性特性。

这些大数据组件基于HDFS API的设计选择，为将数据平台部署到云端带来了潜在挑战。

存储-计算耦合架构

下图展示了一个简化的HDFS架构，其中计算与存储紧密耦合。

Hadoop存储-计算耦合架构

在此图中，每个节点作为HDFS的DataNode用于存储数据。同时，YARN在每个节点上部署Node Manager进程，使得YARN能够将该节点识别为其管理资源的一部分，用于计算任务。这种架构使得存储和计算能够在同一台机器上共存，计算过程中可以直接从磁盘读取数据。

为何Hadoop采用存储与计算耦合

Hadoop设计时由于网络通信和硬件限制，采用了存储与计算耦合的方式.

2006年，云计算尚处于起步阶段，亚马逊刚刚推出其首个服务。在数据中心，主流的网络卡主要运行在100 Mbps的速度。用于大数据工作负载的数据磁盘达到约50 MB/s的吞吐量，相当于网络带宽的400 Mbps。

考虑一个配备八块硬盘且运行在满负荷状态下的节点，为了实现高效的数据传输，需要数吉比特每秒的网络带宽。然而，网络卡的最大容量限制在1 Gbps。因此，每个节点的网络带宽不足以充分挖掘该节点内所有硬盘的潜力。结果是，如果计算任务位于网络的一端，而数据位于另一端的数据节点上，网络带宽就成为了显著的瓶颈。

为何需要存储与计算解耦

从2006年到大约2016年，企业面临以下问题：

• 应用中对计算能力和存储的需求不平衡，且增长速度各异。尽管企业数据增长迅速，计算需求的增长速度却并未同步。这些由人类开发的任务并未在短时间内呈指数级增长。然而，这些任务产生的数据却迅速积累，可能是以指数方式增长。此外，某些数据对企业当前可能并无直接价值，但在未来可能具有重要意义。因此，企业全面存储数据以探索其潜在价值。
• 在扩容过程中，企业需同时增加计算与存储资源，这常导致计算资源浪费。存储-计算耦合的硬件结构影响了扩展灵活性。当存储不足时，不仅需添加机器，还需升级CPU和内存，因耦合架构中的数据节点承担计算任务。因此，机器通常配置均衡的计算与存储能力，既提供充足存储，也具备相当的计算力。然而，实际计算需求并未如预期增长，导致扩充的计算能力对企业造成巨大浪费。
• 平衡计算与存储、选择合适机型变得困难。整个集群在存储和I/O资源利用上可能极不均衡，且随着集群扩大，这种不平衡加剧。此外，采购恰当的机器也颇具挑战，因为机器需在计算与存储需求间找到平衡点。
• 由于数据分布不均，有效调度位于数据所在实例上的计算任务变得困难。数据局部性调度策略可能因数据分布不均而难以应对实际场景。例如，某些节点可能成为局部热点，需要更多计算资源。因此，即便大数据平台的任务被调度至这些热点节点，I/O性能仍可能成为瓶颈。

为何存储与计算解耦是可行的

2006至2016年间，硬件与软件的进步将存储与计算分离的可行性变为现实。这些进步是：

网络卡

10 Gb网络卡的广泛采用，以及数据中心和云环境中20 Gb、40 Gb甚至50 Gb更高容量的日益普及。在AI场景中，100 GB容量的网络卡也被使用。这代表了网络带宽的显著提升，增长超过100倍。

磁盘

许多企业在大数据集群中仍依赖基于磁盘的存储解决方案。磁盘的吞吐量已翻倍，从50 MB/s增加到100 MB/s。配备10 GB网络卡的实例可支持约12块磁盘的峰值吞吐量，这对于大多数企业而言已足够，因此网络传输不再是瓶颈。

软件

采用如Snappy、LZ4和Zstandard等高效压缩算法，以及Avro、Parquet和Orc等列式存储格式，进一步缓解了I/O压力。大数据处理的瓶颈已从I/O转向CPU性能。

如何实现存储与计算分离

初步尝试：HDFS独立部署至云端

HDFS的独立部署

自2013年起，业界开始尝试将存储与计算分离。最初的方案相当直接，即独立部署HDFS而不与计算节点整合。这一方案并未向Hadoop生态系统引入新的组件。如图所示，NodeManager不再部署于DataNodes上，这意味着计算任务不再直接发往DataNodes。存储形成独立的集群，计算所需数据通过网络传输，依托端到端的10Gb网卡支持。（注意图中未标注网络传输线路。）

尽管此方案放弃了HDFS最具巧思的数据本地性设计，但网络通信速度的提升极大地简化了集群配置。这一点由

Separating storage from compute

Davies，Juicedata联合创始人，及其在Facebook时期的团队于2013年进行的实验所证实。实验结果验证了计算节点独立部署与管理的可行性。

然而，这一尝试并未得到进一步发展。主要原因是将HDFS部署至云端所面临的挑战。

云端部署HDFS的挑战

将HDFS部署至云端面临以下问题：

• HDFS多副本机制增加企业云上成本：过去，企业使用裸盘在自有数据中心搭建HDFS系统。为降低磁盘损坏风险，HDFS采用多副本机制确保数据安全和可用性。然而，将数据迁移至云端时，云服务商提供的云盘已内置多副本保护机制。因此，企业需在云内对数据进行三重复制，导致成本显著上升。
• 裸盘部署选项受限：尽管云服务商提供部分带裸盘的机型，但可选范围有限。例如，在云上100种虚拟机类型中，仅5-10种支持裸盘。这种有限的选择可能无法满足企业集群的特定需求。
• 未能充分利用云的独特优势：将HDFS部署至云端需手动创建机器、部署、维护、监控及运维，无法享受弹性伸缩和按需付费模式带来的便利。这些正是云计算的核心优势。因此，实现存储与计算分离的HDFS云部署并非易事。

HDFS局限性

HDFS本身存在以下限制：

• NameNodes可扩展性有限：HDFS中的NameNodes仅能垂直扩展，无法进行分布式扩展。这一限制制约了单个HDFS集群所能管理文件的数量。
• 存储超过5亿文件带来高昂的运维成本：根据我们的经验，通常操作和维护HDFS在3亿文件以下是比较容易的。当文件数量超过5亿时，就需要实施HDFS Federation机制，但这会引入高昂的运维和管理成本。
• NameNode高资源占用和重负载影响HDFS集群可用性：当NameNode因高负载占用过多资源时，可能会触发完全垃圾回收（GC），这会影响整个HDFS集群的可用性。系统存储可能会停机，无法读取数据，且无法干预GC过程。系统冻结的持续时间无法预知，这是高负载HDFS集群中一直存在的问题。

公有云+对象存储

随着云计算的发展，企业现在可以选择使用对象存储作为HDFS的替代方案。对象存储专为存储大规模非结构化数据设计，提供便于数据上传和下载的架构，具备高度可扩展的存储容量，确保成本效益。

对象存储作为HDFS替代方案的优势

对象存储自AWS开始流行，并被其他云服务提供商采纳作为HDFS的替代品，其显著优势包括：

• 服务导向且开箱即用：对象存储无需部署、监控或维护工作，提供便捷且友好的用户体验。
• 弹性扩展与按需付费：企业根据实际使用量支付对象存储费用，无需进行容量规划。他们可以创建一个对象存储桶，并根据需要存储任意数量的数据，无需担心存储容量限制。

对象存储的缺点

然而，在利用对象存储支持如Hadoop这样的复杂数据系统时，会遇到以下挑战：

缺点一：文件列表性能低下

列表操作是文件系统中最基本的操作之一，在如HDFS这样的树状结构中轻量且快速。

相反，对象存储采用扁平结构，需要通过键（唯一标识符）来索引存储和检索成千上万甚至数十亿的对象。因此，在进行列表操作时，对象存储只能在此索引内搜索，导致其性能远逊于树状结构。

Tree-like structure vs. flat structure

缺点二：缺乏原子重命名能力，影响任务性能与稳定性

在提取、转换、加载（ETL）计算模型中，每个子任务将其结果写入临时目录。当整个任务完成后，该临时目录可被重命名为最终目录名称。

这些重命名操作在HDFS等文件系统中是原子且快速的，并能保证事务性。然而，由于对象存储没有原生的目录结构，处理重命名操作是一个模拟过程，涉及大量内部数据复制。这一过程耗时且不提供事务保证。

用户在使用对象存储时，常采用传统文件系统的路径格式作为对象键，如”/order/2-22/8/10/detail”。进行重命名操作时，需查找所有键中包含该目录名的对象，并使用新目录名作为键复制所有对象。此过程涉及数据复制，导致性能远低于文件系统，可能慢上一到两个数量级。

此外，因缺乏事务保证，过程中存在失败风险，可能导致数据错误。这些微小差异对整个任务管道的性能和稳定性产生影响。

缺点三：最终一致性机制影响数据正确性和任务稳定性

例如，当多个客户端同时在一个路径下创建文件时，通过List API获取的文件列表可能不会立即包含所有已创建文件。对象存储内部系统需要时间来实现数据一致性。这种访问模式在ETL数据处理中常见，最终一致性可能影响数据正确性和任务稳定性。

为了解决对象存储无法保持强数据一致性的问题，AWS推出了一款名为EMRFS的产品。其做法是额外使用一个DynamoDB数据库。例如，当Spark写入文件时，会同步将文件列表副本写入DynamoDB。随后建立一个机制，不断调用对象存储的List API，并将获取的结果与数据库中存储的结果进行对比，直到两者一致时才返回结果。然而，这一机制的稳定性并不理想，其性能会受到对象存储所在区域负载的影响，导致性能波动。因此，这并非一个完美的解决方案。

缺点四：与Hadoop组件兼容性有限

在Hadoop生态系统的早期阶段，HDFS是主要的存储选择，各组件均基于HDFS API开发。对象存储的引入改变了数据存储结构及API。

云服务提供商需对组件与云对象存储之间的连接器进行修改，并对上层组件打补丁以确保兼容性。这项任务给公共云提供商带来了巨大的工作量。

因此，公共云提供商所提供的大数据平台中，支持的计算组件数量有限，通常只包括少数版本的Spark、Hive和Presto。这一限制为将大数据平台迁移至云端或对自有分发和组件有特定需求的用户带来了挑战。

为了兼顾对象存储的强大性能和文件系统的可靠性，企业可以采用对象存储+JuiceFS的组合。

对象存储+JuiceFS

当用户需要在对象存储上进行复杂的数据计算、分析和训练时，单纯的对象存储可能无法完全满足企业需求。正是基于这一关键动因，Juicedata开发了JuiceFS，旨在弥补对象存储的局限性。

JuiceFS是一款专为云设计的开源高性能分布式文件系统。与对象存储结合，JuiceFS为计算、分析和训练等数据密集型场景提供了经济高效的解决方案。

JuiceFS与对象存储的工作原理

下图展示了JuiceFS在Hadoop集群中的部署情况。

JuiceFS deployment in the Hadoop cluster

从图中我们可以看出：

• 所有由YARN管理的worker节点都搭载了JuiceFS Hadoop SDK，确保了与HDFS的完全兼容性。
• SDK访问的两个组件包括：

  • JuiceFS元数据引擎：该引擎相当于HDFS的NameNode，负责存储整个文件系统的元数据信息，包括目录数量、文件名、权限和时间戳，并解决了HDFS NameNode面临的扩展性和GC挑战。

  • S3存储桶：数据存储在S3存储桶中，类似于HDFS的DataNode。它可以作为大量磁盘使用，管理数据存储和复制任务。

• JuiceFS由三个组件组成：

  • JuiceFS Hadoop SDK
  • 元数据引擎
  • S3存储桶

相较于直接使用对象存储，JuiceFS的优势

与直接使用对象存储相比，JuiceFS具有多项优势：

• 完全兼容HDFS：这得益于JuiceFS最初设计时就全面支持POSIX。POSIX API的覆盖范围和复杂性均超过HDFS。
• 可与现有HDFS及对象存储系统协同使用：得益于Hadoop系统的设计，JuiceFS能在不全面替换的情况下与现有的HDFS和对象存储系统并存。在Hadoop集群中，可以配置多个文件系统，使得JuiceFS与HDFS共存并协作。这种架构避免了完全替换现有HDFS集群所需的大量工作和高风险，用户可根据应用需求和集群状况逐步集成JuiceFS。
• 强大的元数据性能：JuiceFS将元数据引擎与S3分离，不再依赖S3的元数据性能，确保了元数据的最佳性能。使用JuiceFS时，与底层对象存储的交互简化为Get、Put、Delete等基本操作。此架构克服了对象存储元数据的性能限制，并解决了最终一致性相关的问题。
• 支持原子性重命名：JuiceFS因其独立的元数据引擎，支持原子性的重命名操作。缓存功能提升了热数据的访问性能，并提供了数据局部性特性：通过缓存，热数据无需每次都从对象存储中通过网络检索。此外，JuiceFS实现了HDFS特有的数据局部性API，使得所有支持数据局部性的上层组件能够恢复对数据亲和性的感知。这使得YARN能够优先在已建立缓存的节点上调度任务，从而达到与存储计算耦合的HDFS相媲美的整体性能。
• JuiceFS兼容POSIX，便于与机器学习和AI相关应用集成。

结论

随着企业需求的变化，以及技术的进步，存储与计算的架构已从耦合走向分离。

实现存储与计算分离的方式多样，各有优劣。从部署HDFS到云端，到利用兼容Hadoop的公有云解决方案，再到采用对象存储+JuiceFS这样的组合，适用于云上复杂的大数据计算与存储。

对企业而言，没有一劳永逸的解决方案，关键在于根据自身需求选择合适的架构。然而，无论选择何种方案，简洁性始终是安全的选择。

关于作者

瑞苏（Rui Su），作为Juicedata的合伙人，自2017年起便是JuiceFS产品的创始成员之一，深度参与了该产品的全周期开发、市场拓展及开源社区建设。拥有16年行业经验的他，曾在软件、互联网及非政府组织等多个领域担任研发、产品经理及创始人等职务。