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

发表于:2018-11-29 10:01

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:中华石杉    来源:石杉的架构笔记

#
hadoop
分享:
  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 集群里
  此时它会先跟 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 了!
  
     上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号