大白话告诉你Hadoop架构原理 _Hadoop架构

来自：石杉的架构笔记（id：shishan10）
目录一、前奏
二、HDFS的NameNode架构原理
一、前奏Hadoop是目前大数据领域最主流的一套技术体系，包含了多种技术。
包括HDFS（分布式文件系统），YARN（分布式资源调度系统），MapReduce（分布式计算系统），等等。
有些朋友可能听说过Hadoop，但是却不太清楚他到底是个什么东西，这篇文章就用大白话给各位阐述一下。
假如你现在公司里的数据都是放在MySQL里的，那么就全部放在一台数据库服务器上，我们就假设这台服务器的磁盘空间有2T吧，大家先看下面这张图。

文章插图
现在问题来了，你不停的往这台服务器的MySQL里放数据，结果数据量越来越大了，超过了2T的大小了，现在咋办？
你说，我可以搞多台MySQL数据库服务器，分库分表啊！每台服务器放一部分数据不就得了。如上图所示！
好，没问题，那咱们搞3台数据库服务器，3个MySQL实例，然后每台服务器都可以2T的数据。
现在我问你一个问题，所谓的大数据是在干什么？
我们来说一下大数据最初级的一个使用场景。假设你有一个电商网站，现在要把这个电商网站里所有的用户在页面和App上的点击、购买、浏览的行为日志都存放起来分析。
你现在把这些数据全都放在了3台MySQL服务器，数据量很大，但还是勉强可以放的下。
某天早上，你的boss来了。要看一张报表，比如要看每天网站的X指标、Y指标、Z指标，等等，二三十个数据指标。
好了，兄弟，现在你尝试去从那些点击、购买、浏览的日志里，通过写一个SQL来分析出那二三十个指标试试看？
我跟你打赌，你绝对会写出来一个几百行起步，甚至上千行的超级复杂大SQL 。这个SQL，你觉得他能运行在分库分表后的3台MySQL服务器上么？
如果你觉得可以的话，那你一定是不太了解MySQL分库分表后有多坑，几百行的大SQL跨库join，各种复杂的计算，根本不现实。
所以说，大数据的存储和计算压根儿不是靠MySQL来搞的，因此，Hadoop、Spark等大数据技术体系才应运而生。
本质上，Hadoop、Spark等大数据技术，其实就是一系列的分布式系统。
比如hadoop中的HDFS，就是大数据技术体系中的核心基石，负责分布式存储数据，这是啥意思？别急，继续往下看。
HDFS全称是Hadoop Distributed File System，是Hadoop的分布式文件系统。
它由很多机器组成，每台机器上运行一个DataNode进程，负责管理一部分数据。
然后有一台机器上运行了NameNode进程，NameNode大致可以认为是负责管理整个HDFS集群的这么一个进程，他里面存储了HDFS集群的所有元数据。
然后有很多台机器，每台机器存储一部分数据！好，HDFS现在可以很好的存储和管理大量的数据了。
这时候你肯定会有疑问：MySQL服务器也不是这样的吗？你要是这样想，那就大错特错了。
这个事情不是你想的那么简单的，HDFS天然就是分布式的技术，所以你上传大量数据，存储数据，管理数据，天然就可以用HDFS来做。
如果你硬要基于MySQL分库分表这个事儿，会痛苦很多倍，因为MySQL并不是设计为分布式系统架构的，他在分布式数据存储这块缺乏很多数据保障的机制。
好，你现在用HDFS分布式存储了数据，接着不就是要分布式来计算这些数据了吗？
对于分布式计算：

很多公司用Hive写几百行的大SQL（底层基于MapReduce）
也有很多公司开始慢慢的用Spark写几百行的大SQL（底层是Spark Core引擎）。

总之就是写一个大SQL，人家会拆分为很多的计算任务，放到各个机器上去，每个计算任务就负责计算一小部分数据，这就是所谓的分布式计算。
这个，绝对比你针对分库分表的MySQL来跑几百行大SQL要靠谱的多。
对于上述所说，老规矩，同样给大家来一张图，大伙儿跟着图来仔细捋一下整个过程。

文章插图
二、HDFS的NameNode架构原理好了，前奏铺垫完之后，进入正题。本文其实主要就是讨论一下HDFS集群中的NameNode的核心架构原理。
NameNode有一个很核心的功能：管理整个HDFS集群的元数据，比如说文件目录树、权限的设置、副本数的设置，等等。
下面就用最典型的文件目录树的维护，来给大家举例说明，我们看看下面的图。现在有一个客户端系统要上传一个1TB的大文件到HDFS集群里。