通俗易懂了解Hadoop

苏黎世的民谣

已于 2023-03-21 07:35:20 修改

阅读量626

点赞数

文章标签： hadoop 大数据分布式

于 2023-03-19 11:00:51 首次发布

本文链接：https://blog.csdn.net/qq_50209297/article/details/129647788

版权

从本书第5、6、7、8章，学习云计算开发相关知识

这是第五章

文章目录

- Hadoop：主流开源云架构

Hadoop：主流开源云架构

什么是分布式？

书中模拟了一个场景，提出了四个划时代的问题。

场景：我们现在有一些完全相同的计算机C1~Cn，每台计算机可以存5GB内容。另有两个均为2GB的文件f0和f1。

Q1：将f0和f1分别存入不同计算机，但对外显示存储在同一块硬盘；

Q2：另有一个6GB的文件f2，将它存入计算机，但对外显示为一个完整文件；

Q3：在Q1的前提下，统计f0和f1每个单词的出现次数（以下简称词频）；

Q4：如果某个机器宕机，如何保证数据不丢失。

这四个问题，如果我们按照常规思路，似乎都是很难解决的。哎不对，Q3可以哦，只需要把f0复制到存储f1的计算机上，把它们放在一起统计即可，这确实没错。但如果是100个文件，每个文件1TB，就是复制文件这一步，我们都很难做到。这四个问题似乎没有了解决方法~

在这种情况下，分布式应运而生，下面是分布式思想来解决问题：

A1、A2：从这些相同的计算机中取出一台作为管理者，记为Master；其他计算机作为被管理者，记为Slave1~Slave（n-1）。Master中仅存储所有Slave机器的地址（也叫元数据），而不存储真实数据；所有Slave存储真实数据。这样设计，如果后期存储或计算需求增大，我们只需要在Master中再加入几个对应其他机器的地址映射，构建更庞大的集群，就可以完成需要。

如图，整个集群就像是一台机器Master、一片云。对外显示为一个硬盘空间，Q1、Q2解决。

A3：针对计算问题，Google提出“移动计算比移动数据更划算”，想想也是，数据动辄几个TB，代码一般就几个MB。基于此，我们假设f0存储在Slave0，f1存储在Slave1，先让两个文件在它们自己所在的机器中计算词频，将得到的结果在另一台机器中将同一个词的词频求和，就得到了这个词在两个文件中的词频，Q3解决（具体实现方法见MapReduce）。

A4：要想数据不丢失，唯一的办法就是备份。我们再取两台机器，记为Slave2和Slave3，Slave2存储文件f0，Slave3存储文件f1，将它们也归于Master管理。当Master启动计算时，四台机器同时工作，因为Slave0和Slave2的作用相同，当其中一台完成计算任务提交给Master，Master立即停止另一台的计算，使用前者提交的结果即可。

这样的话，我们岂不是白白浪费了很多资源？

确实是这样，但在绝大多数情况下，冗余存储和计算是必要的，因为数据丢失是不可逆过程，一旦出现，对企业甚至国家造成的影响太大了。

Hadoop体系架构

下面介绍它的四个组成成分：

Hadoop公共组件 -> Common

分布式文件系统 -> HDFS

分布式计算框架 -> MapReduce

分布式操作系统 -> Yarn

Common——制片人

可以说，没有Common，就没有这部“电影”。Common的定位是其他模块的公共组件，为其他模块提供公用API，观众看不到他，而他，一直在后台为剧组人员默默付出~

Common通过设计方式，降低了Hadoop设计的复杂性，减少了其他模块之间的耦合性，大大增强了Hadoop的健壮性。

HDFS——编剧

电影开拍前，HDFS会将所有的文件妥善存储，作为”剧本“，方便导演后期导戏。

首先引入两个实体：namenode和datanode，Master运行主进程namenode，所有Slave运行从属进程datanode。namenode只存储元数据信息：文件块位置、大小、拥有者信息；datanode以块（block）为单位存储实际数据，这里的块通常为128MB，要存入的文件被切分成块，存入不同的datanode中。

当客户端（Client）要访问一个文件，先“拜访”namenode，问问数据在哪个datanode中？然后直接去相应的datanode读取数据。（不再需要namenode引荐）

事务日志（EditLog）记录HDFS元数据的变化，存储在namenode本地文件系统中。