兄弟，用大白话告诉你小白都能看懂的Hadoop架构原理
欢迎关注我的微信号：石杉的架构笔记（id：shishan100）面试
周一至周五早8点半！精品技术文章准时送上！数据库
往期文章一、拜托！面试请不要再问我Spring Cloud底层原理性能优化
二、【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？服务器
三、【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战微信
目录
1、前奏并发
2、HDFS的NameNode架构原理分布式
1、前奏
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要靠谱的多。
对于上述所说，老规矩，一样给你们来一张图，大伙儿跟着图来仔细捋一下整个过程。
2、HDFS的NameNode架构原理
好了，前奏铺垫完以后，进入正题。本文其实主要就是讨论一下HDFS集群中的NameNode的核心架构原理。
NameNode有一个很核心的功能：管理整个HDFS集群的元数据，好比说文件目录树、权限的设置、副本数的设置，等等。
下面就用最典型的文件目录树的维护，来给你们举例说明，咱们看看下面的图。如今有一个客户端系统要上传一个1TB的大文件到HDFS集群里。
此时他会先跟NameNode通讯，说：大哥，我想建立一个新的文件，他的名字叫“/usr/hive/warehouse/access_20180101.log”，大小是1TB，你看行不？
而后NameNode就会在本身内存的文件目录树里，在指定的目录下搞一个新的文件对象，名字就是“access_20180101.log”。
这个文件目录树不就是HDFS很是核心的一块元数据，维护了HDFS这个分布式文件系统中，有哪些目录，有哪些文件，对不对？
可是有个问题，这个文件目录树是在NameNode的内存里的啊！
这可坑爹了，你把重要的元数据都放在内存里，万一NameNode不当心宕机了可咋整？元数据不就所有丢失了？
可你要是每次都频繁的修改磁盘文件里的元数据，性能确定是极低的啊！毕竟这是大量的磁盘随机读写！
不要紧，咱们来看看HDFS优雅的解决方案。
每次内存里改完了，写一条edits log，元数据修改的操做日志到磁盘文件里，不修改磁盘文件内容，就是顺序追加，这个性能就高多了。
每次NameNode重启的时候，把edits log里的操做日志读到内存里回放一下，不就能够恢复元数据了？
你们顺着上面的文字，把整个过程，用下面这张图跟着走一遍。
可是问题又来了，那edits log若是愈来愈大的话，岂不是每次重启都会很慢？由于要读取大量的edits log回放恢复元数据！
因此HDFS说，我能够这样子啊，我引入一个新的磁盘文件叫作fsimage，而后呢，再引入一个JournalNodes集群，以及一个Standby NameNode（备节点）。
每次Active NameNode（主节点）修改一次元数据都会生成一条edits log，除了写入本地磁盘文件，还会写入JournalNodes集群。
而后Standby NameNode就能够从JournalNodes集群拉取edits log，应用到本身内存的文件目录树里，跟Active NameNode保持一致。
而后每隔一段时间，Standby NameNode都把本身内存里的文件目录树写一份到磁盘上的fsimage，这可不是日志，这是完整的一份元数据。这个操做就是所谓的checkpoint检查点操做。
而后把这个fsimage上传到到Active NameNode，接着清空掉Active NameNode的旧的edits log文件，这里可能都有100万行修改日志了！
而后Active NameNode继续接收修改元数据的请求，再写入edits log，写了一小会儿，这里可能就几十行修改日志而已！
若是说此时，Active NameNode重启了，bingo！不要紧，只要把Standby NameNode传过来的fsimage直接读到内存里，这个fsimage直接就是元数据，不须要作任何额外操做，纯读取，效率很高！
而后把新的edits log里少许的几十行的修改日志回放到内存里就ok了！
这个过程的启动速度就快的多了！由于不须要回放大量上百万行的edits log来恢复元数据了！以下图所示。
此外，你们看看上面这张图，如今我们有俩NameNode。
- 一个是主节点对外提供服务接收请求
- 另一个纯就是接收和同步主节点的edits log以及执行按期checkpoint的备节点。
你们有没有发现！他们俩内存里的元数据几乎是如出一辙的啊！
因此呢，若是Active NameNode挂了，是否是能够立马切换成Standby NameNode对外提供服务？
这不就是所谓的NameNode主备高可用故障转移机制么！
接下来你们再想一想，HDFS客户端在NameNode内存里的文件目录树，新加了一个文件。
可是这个时候，人家要把数据上传到多台DataNode机器上去啊，这但是一个1TB的大文件！咋传呢？
很简单，把1TB的大文件拆成N个block，每一个block是128MB。1TB = 1024GB = 1048576MB，一个block是128MB，那么就是对应着8192个block。
这些block会分布在不一样的机器上管理着，好比说一共有100台机器组成的集群，那么每台机器上放80个左右的block就ok了。
可是问题又来了，那若是这个时候1台机器宕机了，不就致使80个block丢失了？
也就是说上传上去的1TB的大文件，会丢失一小部分数据啊。不要紧！HDFS都考虑好了！
它会默认给每一个block搞3个副本，如出一辙的副本，分放在不一样的机器上，若是一台机器宕机了，同一个block还有另外两个副本在其余机器上呢！
大伙儿看看下面这张图。每一个block都在不一样的机器上有3个副本，任何一台机器宕机都没事！还能够从其余的机器上拿到那个block。
这下子，你往HDFS上传一个1TB的大文件，能够高枕无忧了吧！
OK，上面就是大白话加上一系列手绘图，给你们先聊聊小白都能听懂的Hadoop的基本架构原理
接下来会给你们聊聊HDFS，这个做为世界上最优秀的分布式存储系统，承载高并发请求、高性能文件上传的一些核心机制以及原理。
《大规模集群下Hadoop如何承载每秒上千次的高并发访问》，敬请期待
《【冰山下的秘密】Hadoop如何将TB级大文件的上传性能提高上百倍？》，敬请期待
若有收获，请帮忙转发，您的鼓励是做者最大的动力，谢谢！
一大波微服务、分布式、高并发、高可用的原创系列文章正在路上,
欢迎扫描下方二维码，持续关注：
石杉的架构笔记（id:shishan100）
十余年BAT架构经验倾囊相授