您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

大白话告诉你Hadoop架构原理

时间:2019-07-31 09:11:15  来源:  作者:

来自:石杉的架构笔记(id:shishan10)

目录

一、前奏

二、HDFS的NameNode架构原理

一、前奏

Hadoop是目前大数据领域最主流的一套技术体系,包含了多种技术。

包括HDFS(分布式文件系统),YARN(分布式资源调度系统),MapReduce(分布式计算系统),等等。

有些朋友可能听说过Hadoop,但是却不太清楚他到底是个什么东西,这篇文章就用大白话给各位阐述一下。

假如你现在公司里的数据都是放在MySQL里的,那么就全部放在一台数据库服务器上,我们就假设这台服务器的磁盘空间有2T吧,大家先看下面这张图。

兄弟,用大白话告诉你小白都能看懂的Hadoop架构原理

现在问题来了,你不停的往这台服务器的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要靠谱的多。

对于上述所说,老规矩,同样给大家来一张图,大伙儿跟着图来仔细捋一下整个过程。

兄弟,用大白话告诉你小白都能看懂的Hadoop架构原理

二、HDFS的NameNode架构原理

好了,前奏铺垫完之后,进入正题。本文其实主要就是讨论一下HDFS集群中的NameNode的核心架构原理。

NameNode有一个很核心的功能:管理整个HDFS集群的元数据,比如说文件目录树、权限的设置、副本数的设置,等等。

下面就用最典型的文件目录树的维护,来给大家举例说明,我们看看下面的图。现在有一个客户端系统要上传一个1TB的大文件到HDFS集群里。

兄弟,用大白话告诉你小白都能看懂的Hadoop架构原理

此时他会先跟NameNode通信,说:大哥,我想创建一个新的文件,他的名字叫“/usr/hive/warehouse/access_20180101.log”,大小是1TB,你看行不?

然后NameNode就会在自己内存的文件目录树里,在指定的目录下搞一个新的文件对象,名字就是“access_20180101.log”。

这个文件目录树不就是HDFS非常核心的一块元数据,维护了HDFS这个分布式文件系统中,有哪些目录,有哪些文件,对不对?

但是有个问题,这个文件目录树是在NameNode的内存里的啊!

这可坑爹了,你把重要的元数据都放在内存里,万一NameNode不小心宕机了可咋整?元数据不就全部丢失了?

可你要是每次都频繁的修改磁盘文件里的元数据,性能肯定是极低的啊!毕竟这是大量的磁盘随机读写!

没关系,我们来看看HDFS优雅的解决方案。

每次内存里改完了,写一条edits log,元数据修改的操作日志到磁盘文件里,不修改磁盘文件内容,就是顺序追加,这个性能就高多了。

每次NameNode重启的时候,把edits log里的操作日志读到内存里回放一下,不就可以恢复元数据了?

大家顺着上面的文字,把整个过程,用下面这张图跟着走一遍。

兄弟,用大白话告诉你小白都能看懂的Hadoop架构原理

但是问题又来了,那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来恢复元数据了!如下图所示。

兄弟,用大白话告诉你小白都能看懂的Hadoop架构原理

此外,大家看看上面这张图,现在咱们有俩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的大文件,可以高枕无忧了吧!

兄弟,用大白话告诉你小白都能看懂的Hadoop架构原理

OK,上面就是大白话加上一系列手绘图,给大家先聊聊小白都能听懂的Hadoop的基本架构原理。


现在人工智能非常火爆,很多朋友都想学,但是一般的教程都是为博硕生准备的,太难看懂了。最近发现了一个非常适合小白入门的教程,不仅通俗易懂而且还很风趣幽默。所以忍不住分享一下给大家。点下面可以跳转到教程。

https://www.captainbed.net/suga

文章来自:https://juejin.im/entry/5beb6ca7e51d450fa35d42b1



Tags:Hadoop架构   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
我今天花了大半个下午的时间,写了这篇hadoop的架构,全篇都是以大白话的形式,也算是为后面更加详细的每一部分开了个好头吧,如果喜欢请点转发和关注,如果有疑问,直接在评论里说出来...【详细内容】
2019-10-24  Tags: Hadoop架构  点击:(114)  评论:(0)  加入收藏
来自:石杉的架构笔记(id:shishan10)目录一、前奏二、HDFS的NameNode架构原理一、前奏Hadoop是目前大数据领域最主流的一套技术体系,包含了多种技术。包括HDFS(分布式文件系统),YARN(...【详细内容】
2019-07-31  Tags: Hadoop架构  点击:(240)  评论:(0)  加入收藏
▌简易百科推荐
为了构建高并发、高可用的系统架构,压测、容量预估必不可少,在发现系统瓶颈后,需要有针对性地扩容、优化。结合楼主的经验和知识,本文做一个简单的总结,欢迎探讨。1、QPS保障目标...【详细内容】
2021-12-27  大数据架构师    Tags:架构   点击:(5)  评论:(0)  加入收藏
前言 单片机开发中,我们往往首先接触裸机系统,然后到RTOS,那么它们的软件架构是什么?这是我们开发人员必须认真考虑的问题。在实际项目中,首先选择软件架构是非常重要的,接下来我...【详细内容】
2021-12-23  正点原子原子哥    Tags:架构   点击:(7)  评论:(0)  加入收藏
现有数据架构难以支撑现代化应用的实现。 随着云计算产业的快速崛起,带动着各行各业开始自己的基于云的业务创新和信息架构现代化,云计算的可靠性、灵活性、按需计费的高性价...【详细内容】
2021-12-22    CSDN  Tags:数据架构   点击:(10)  评论:(0)  加入收藏
▶ 企业级项目结构封装释义 如果你刚毕业,作为Java新手程序员进入一家企业,拿到代码之后,你有什么感觉呢?如果你没有听过多模块、分布式这类的概念,那么多半会傻眼。为什么一个项...【详细内容】
2021-12-20  蜗牛学苑    Tags:微服务   点击:(9)  评论:(0)  加入收藏
我是一名程序员关注我们吧,我们会多多分享技术和资源。进来的朋友,可以多了解下青锋的产品,已开源多个产品的架构版本。Thymeleaf版(开源)1、采用技术: springboot、layui、Thymel...【详细内容】
2021-12-14  青锋爱编程    Tags:后台架构   点击:(21)  评论:(0)  加入收藏
在了解连接池之前,我们需要对长、短链接建立初步认识。我们都知道,网络通信大部分都是基于TCP/IP协议,数据传输之前,双方通过“三次握手”建立连接,当数据传输完成之后,又通过“四次挥手”释放连接,以下是“三次握手”与“四...【详细内容】
2021-12-14  架构即人生    Tags:连接池   点击:(17)  评论:(0)  加入收藏
随着移动互联网技术的快速发展,在新业务、新领域、新场景的驱动下,基于传统大型机的服务部署方式,不仅难以适应快速增长的业务需求,而且持续耗费高昂的成本,从而使得各大生产厂商...【详细内容】
2021-12-08  架构驿站    Tags:分布式系统   点击:(23)  评论:(0)  加入收藏
本系列为 Netty 学习笔记,本篇介绍总结Java NIO 网络编程。Netty 作为一个异步的、事件驱动的网络应用程序框架,也是基于NIO的客户、服务器端的编程框架。其对 Java NIO 底层...【详细内容】
2021-12-07  大数据架构师    Tags:Netty   点击:(17)  评论:(0)  加入收藏
前面谈过很多关于数字化转型,云原生,微服务方面的文章。虽然自己一直做大集团的SOA集成平台咨询规划和建设项目,但是当前传统企业数字化转型,国产化和自主可控,云原生,微服务是不...【详细内容】
2021-12-06  人月聊IT    Tags:架构   点击:(23)  评论:(0)  加入收藏
微服务看似是完美的解决方案。从理论上来说,微服务提高了开发速度,而且还可以单独扩展应用的某个部分。但实际上,微服务带有一定的隐形成本。我认为,没有亲自动手构建微服务的经历,就无法真正了解其复杂性。...【详细内容】
2021-11-26  GreekDataGuy  CSDN  Tags:单体应用   点击:(35)  评论:(0)  加入收藏
相关文章
    无相关信息
最新更新
栏目热门
栏目头条