云计算与大数据课程笔记（二）之Google云计算框架辅助笔记（上）

Chunk & Block

在GFS中，Chunk默认大小是64MB。作者在参加云计算相关竞赛时发现有题目说Hadoop的Block默认是64MB，这和作者之前学的128MB不太一样，故进行以下整理：

在Hadoop分布式文件系统（HDFS）中，块（BLOCK）的默认大小曾经是64MB，在较新版本的Hadoop中，默认块大小通常是128MB。不过，这个值是可以配置的，具体取决于你使用的Hadoop发行版本以及系统的配置。

在Hadoop的较新版本中（例如2.x及之后），默认的块大小确实是128MB。这种较大的块大小可以减少文件系统的元数据数量，同时提高大规模数据处理的效率。（这就说明现在的数据趋势是：单个文件的平均文件大小迅速上升，作者预估后续默认256MB不会遥远）块大小可以在Hadoop的配置文件中自定义设置，通常在hdfs-site.xml文件中配置dfs.blocksize属性来指定。

例如，要设置块大小为128MB，可以在hdfs-site.xml中设置如下：

<property><name>dfs.blocksize</name><value>134217728</value> <!-- 128MB in bytes -->
</property>

这个配置决定了HDFS在存储文件时的块分割策略。选择适当的块大小对于Hadoop集群的性能和效率至关重要，因为它影响到文件的并行处理能力和存储效率。在处理大量小文件时，较大的块大小可能导致存储空间的浪费，而在处理大文件时，较大的块大小可以提高处理效率。因此，选择块大小时需要根据具体的使用场景和数据特点来决定。

Master & Chunk Server：存储与计算的解耦？

不准确！

作者在学习过程中发现这样一句话，GFS中的Master和Chunk Server的设立是一种存储与计算的解耦，作者觉得怪怪的。想起之前的SAN网络不知道RAID/SAN/NAS的小可爱来看看这个吧！_nas跟san都可以组成raid-CSDN博客，它确实实现了服务器（计算）与硬件资源（存储）的解耦。但是，Master没有进行计算的相关任务，重点就是元数据存储。所以作者认为，这句话的解耦主要指的是管理（元数据管理）与实际数据存储的物理隔离。

在GFS中，"存储与计算的解耦"更多地指的是元数据管理与数据存储处理的分离。而在SAN框架中，解耦则是指物理存储资源与使用这些资源的服务器之间的物理和逻辑分离。两者都实现了解耦的概念，但侧重点和实现方式有所不同。GFS是为了大规模数据处理设计的文件系统，而SAN是为了提高大型网络中存储资源的使用效率和灵活性设计的存储网络。

调度与存储处理的解耦

综上，在GFS（Google File System）的上下文中，谈论“存储与计算的解耦”确实可能造成一些误解。更准确的描述应该是“元数据管理与数据存储/处理的解耦”，或者说是“调度与存储处理的解耦”。

解耦的具体含义

元数据管理与数据存储/处理的解耦：在GFS中，master节点负责元数据的管理，这包括文件和块的命名空间、文件到块的映射、块的位置等，而chunk server节点负责实际数据块的存储和处理。这种设计意味着系统的管理操作（调度、命名空间管理等）与数据的实际存储和处理是分开的。

调度与存储处理的解耦：调度指的是管理数据存储和访问的决策过程，例如决定哪个chunk server存储哪个数据块，或者如何处理读写请求。这些调度操作是由GFS的master节点负责的。存储处理则是指实际的数据读写操作，由chunk server节点完成。

为什么这样设计？

这种解耦设计有几个优点：

扩展性：通过解耦，GFS可以更容易地在多个chunk server上扩展数据存储，因为数据管理（由master负责）与数据存储（由chunk server负责）是分开的。

性能优化：元数据操作通常需要更快的访问速度和更多的计算资源，而数据存储则需要更大的存储空间和高效的数据传输。分开处理可以针对这些操作进行优化。

容错性：解耦还意味着系统的不同部分可以独立失败和恢复，从而提高了系统的总体可靠性。

NameNode & DataNode

Hadoop的HDFS（Hadoop Distributed File System）中的NameNode和DataNode体现了类似于GFS中master和chunk server的设计，实现了元数据管理与数据存储/处理的解耦。

NameNode（元数据管理）

NameNode 在HDFS中扮演的角色类似于GFS中的master节点。它负责管理文件系统的命名空间。具体而言，NameNode存储了文件系统树及所有文件和目录的元数据。这些信息包括文件的目录结构、文件的属性（如权限、修改时间等）以及文件的块（block）信息和它们对应的DataNode位置。
NameNode不存储实际的数据，而只管理元数据。这意味着，对于文件系统的结构和数据的查找、定位操作都是通过与NameNode交互来完成的。

DataNode（数据存储/处理）

DataNode 在HDFS中的作用类似于GFS的chunk server。它们负责存储实际的数据块。在HDFS中，文件被切分成一个或多个块，并且这些块存储在一组DataNode上。
DataNode负责处理文件系统客户端的读写请求，并执行与这些数据块相关的操作，比如创建、删除、复制块等。

作者的脑回路又开始工作了：我们完全可以将数据比作糖原，NameNode比作大脑，DataNode比作处理糖原的肌肉。NameNode负责文件系统的“大脑”部分，即元数据和命名空间的管理，而DataNode则承担了实际存储和处理数据的“肌肉”工作。这种设计模式是为了优化大规模数据处理的性能、可靠性和可管理性。

数据作为糖原

在这个类比中，数据（糖原）是能量的来源，就像在计算环境中，数据是进行计算和分析的基础资源。糖原在生物体中被存储，并在需要时被转换为能量，类似地，数据被存储在分布式文件系统中，并在需要时被访问和处理。

NameNode作为大脑

NameNode（大脑）管理和控制整个系统的元数据信息，这包括数据的位置、状态等。就像大脑通过神经系统控制和协调身体的各个部分，NameNode通过网络协调DataNode的数据存储和处理活动。它不直接涉及能量（数据）的生产或消耗，但负责调度和指挥。

DataNode作为肌肉

DataNode（肌肉）负责存储和处理数据，类似于肌肉存储糖原并在需要时将其转化为能量。肌肉在需要时劳作以产生动力，DataNode在需要时进行数据的读写操作以提供服务。它们是执行具体任务的实体，负责实际的“工作负荷”。

高可用和高容错性有什么区别

在分布式存储系统中，高可用性（High Availability）和高容错性（High Fault Tolerance）是两个密切相关但有区别的概念。它们都是系统设计的重要目标，旨在确保系统能够持续稳定地提供服务，即使在面临故障和异常时也是如此。

高可用性（High Availability）

高可用性关注的是系统能够持续不间断地提供服务的能力。一个高可用的系统能够在面对硬件故障、软件故障或网络问题时，通过快速恢复或自动切换到备份系统来维持服务的连续性。目标是减少系统停机时间，确保用户或客户端能够尽可能持续地访问系统和数据。

在分布式存储系统中，高可用性通常通过如下方式实现：

冗余：通过在不同节点或位置复制数据来确保数据的可用性。
快速故障恢复：系统能够快速检测到故障并自动切换到正常运行的组件。
负载均衡：分散请求，避免单点故障导致的服务中断。

高容错性（High Fault Tolerance）

高容错性指的是系统在部分组件发生故障时仍能正常运行的能力。容错性的重点在于系统设计应能够容纳一定程度的故障，而不影响整个系统的功能。高容错系统可以在不依赖立即修复故障的情况下继续运行。

在分布式存储系统中，高容错性可以通过以下方式实现：

数据复制：在多个节点存储数据副本，从而在某些节点失败时仍能从其他节点访问数据。
自动故障检测与恢复：系统可以自动检测到故障节点并将任务转移至健康节点。
分布式设计：通过分布式架构减少单点故障的风险。

区别

焦点差异：高可用性更侧重于减少系统停机时间，确保服务的连续性；而高容错性更侧重于系统对故障的抵抗能力，即使在部分系统组件失败的情况下仍能继续运行。
实现方式：虽然两者都可能涉及到如数据复制、故障切换等技术，但高可用性更注重快速恢复正常服务，而高容错性则强调即使在故障情况下也能保持服务运行。

相互关系

互补性：虽然高可用性和高容错性在技术和策略上可能有所不同，但它们在实现稳定可靠的系统中是互补的。高容错性通过降低系统对单点故障的敏感度来增强系统的整体鲁棒性，而高可用性则确保在出现故障时能够快速恢复服务。
相辅相成：在实际应用中，强大的容错机制可以减少系统出现严重问题的频率，这反过来减轻了对高可用性机制的依赖。但即便有着强大的容错机制，系统仍然需要高可用性措施来处理无法预料或无法“容忍”的故障情况。

在设计分布式存储系统时，高可用性和高容错性都是重要的设计目标。它们共同确保了系统在面对故障和挑战时能够保持稳定和可靠的服务。尽管它们的关注点和实现策略有所不同，但在实践中，这两个概念往往是互相交织和支持的。