内容大纲:
1. namenode的工作原理 //即: 它是如何维护元数据的
2. SecondaryNameNode的工作原理 //即: 如何辅助namenode管理元数据.
3. MR思想-分而治之
4. MR的核心设计原则
5. MR的流程介绍 //核心八步, 也有一些老师会称之为 天龙八部
6. MR的案例 //计算pi(圆周率)
7. MR的执行流程(原理) //至少30分钟起步
//细节: 因为MR对于大多数的程序员来说, 学习成本相对较高, 于是有了Hive, 我们可以通过写HiveSQL的方式, 内部转成MR程序来执行.
8. Yarn简介
9. Yarn的三大组件介绍 //ResourceManager, nodemanager, AppMaster(进程)
10. Yarn的执行原理 //20分钟
11. Yarn的三大调度模型详解. //FIFO(先进先出调度器), Capacity(容量调度, Apache版默认的), Fair(公平调度器, CDH默认的)
12. Hadoop的HA模式介绍
-
namenode的原理图,它是如何管理元数据的(要求能说出来)
//即: 如何管理元数据的.
//详见图片. -
如何查看元数据 (了解即可,平时也基本不会用)
//即: 如何查看 edits文件 和 fsimage文件, 注意: 这里只是让你看看在哪里, 大概看下文件内容, 以后实际开发中, 大概率你是不看的.我们的集群, namenode在node1上, 所以源数据也存储在node1上, 路径为:
/export/data/hadoop-3.3.0/dfs/name/current我们拷贝两个文件到root下:
cp edits_0000000000000001065-0000000000000001385 fsimage_0000000000000001385 /rootcd /root把上述的两个文件, 转成我们能看懂的格式 //通过HDFS的内置命令, oev(操作Edits文件的), oiv(操作fsimage文件的)实现
hdfs oev -i edits_0000000000000001065-0000000000000001385 -o edits.xml //input(输入), ouput(输出)
hdfs oiv -i fsimage_0000000000000001385 -p XML -o fsimage.xml //i-->input(输入),o--> ouput(输出)sz edits.xml fsimage.xml扩展: 本机的Block块信息, 存储在哪里呢?
/export/data/hadoop-3.3.0/dfs/data/current/BP-1767623974-192.168.88.161-1655798356348/current/finalized/subdir0/subdir0
为什么放这么深?显然就是不想让你动呗 -
SecondaryNameNode的作用原理图(要求能说出来)
//它是辅助namenode管理元数据的, 在紧急情况下, 可以做数据恢复,就是把Sencondrarynode中的文件重新取回namenode中(指的是: 帮namenode恢复元数据).
//详见图解其中将小文件edits和大文件fsimage合并的机制又叫做checkpoint机制
checkpoint机制:监听edits文件的状态，满足条件，就拉取两个文件做合并，并将合并结果(最终fsimage文件)推送给namenode.,edits 和fsimage 在内存中还是硬盘中?
答:硬盘中 -
HDFS的安全模式
结论:
1. 安全模式下, 只能读, 不能写.
2. 进入安全模式有两种方式:
方式1: 刚启动Hadoop集群的时候, 会自动进入到安全模式下, 进行自检, 没问题后, 会退出安全模式.
方式2: 手动进入
hdfs dfsadmin -safemode enter //进入安全模式
hdfs dfsadmin -safemode get //查看安全模式的状态
hdfs dfsadmin -safemode leave //退出安全模式. -
MapReduce简介
概述:
它是 大数据分布式计算框架, 用的是 分而治之的思想.
//大白话: 把大任务拆分成n个小任务, 然后计算每个小任务的结果, 再做合并, 从而就解决了 大任务.举例:
原始需求: 你自己1个人, 计算 1 ~ 1000之间的所有质数和. //大问题任务拆分: 找9个朋友帮忙 //把 大问题 => 拆分成n个小问题 第1个人: 计算 1 ~ 100的质数和 //小问题解决了 第2个人: 计算 101 ~ 200的质数和 //小问题解决了 ...... 上述结果再累加, 就解决了大问题.是不是所有的场景(需求)都可以用 分而治之解决, 即: 是不是所有的需求都可以用MR程序实现:
不是的, 如果 拆分成小任务之后, 各个小任务之间的依赖性很强, 就不推荐使用 分而治之思想, 例如: 求平均值.需求: 求 1 ~ 7之间所有数字的平均值. 正确结果: 1 + 2 + 3 + 4 + 5 + 6 + 7 = 28 / 7 = 4 分而治之思想: 任务1: 求 1, 2, 3 的平均值. // 6 / 3 = 2 任务2: 求 4, 5 的平均值. // 9 / 2 = 4.5 任务3: 求 6, 7 的平均值. // 13 / 2 = 6.5 最终结果: (2 + 4.5 + 6.5) / 3 = 13 / 3 = 4.33333 -
MR的设计流程
- 如何对付大数据处理：分而治之
- 构建抽象模型：Map和Reduce
MR一共核心8步, 其中Map是负责拆分的, Reduce是负责合并的, 这两步是用户必须自定义的, 剩下的6步可以用MR默认的组件, 也可以是自定义的逻辑. - 统一构架，隐藏系统层细节
//MapReduce最大的亮点在于通过抽象模型和计算框架把需要做什么(what need to do)与具体怎么做(how to do)分开了，为程序员提供一个抽象和高层的编程接口和框架
-
MR的案例: 计算圆周率(不用管).
cd /export/server/hadoop-3.3.0/share/hadoop/mapreduce
yarn jar hadoop-mapreduce-examples-3.3.0.jar pi 2 10 //计算圆周率, 2: 表示有几个MapTask任务, 10表示投点数(越高数据越精准)
//圆周率计算具体的可以参考 蒙特卡洛算法, 随机投点, 然后算四分之一区域的投点数. -
MR的案例: WordCount案例(不用管)
版本1: hadoop自带的测试用例.
1. 在HDFS中创建 /input 文件夹.
2. 把今天资料下的 1.txt(里边是一堆单词) 上传到 /input 下.
1.txt内容:
hello tom hello allen hello
allen tom mac apple
hello allen apple
hello apple spark allen hadoop spark
3. 执行Hadoop命令, 统计每个单词的总次数(WordCount), 结果写到: /output目录下
yarn jar hadoop-mapreduce-examples-3.3.0.jar wordcount /input/1.txt /output //注意: 是小写的wordcount,这是系统自带的功能
4. 细节: /output目录必须不存在, 因为 MR规定, 目的地目录的父目录必须存在, 但是子目录必须不存在.
例如: 我要把最终结果写到 /aa/bb文件夹中, 则/aa必须存在, /aa/bb 必须不存在.版本2: Java版. //看看就行了, 主要是想给你看清晰的每一步设置(核心八步), 及表达代码有点"多"
//往后看.
版本3: Python版. //理解, 因为现在它的效率比较低, 实际开发中大多数是用的Spark.
//往后看. -
MR案例-WordCount案例核心8步详解(多看看,基本能说即可)
流程:
数据源:
hello tom hello teacher hello //第1行
allen tom mac apple //第2行
hello allen apple //第3行
hello apple spark allen hadoop spark //第4行MR第1步: 定义输入组件, 从数据源文件中读取数据, 一次读取一行, 获取: K1, V1 //这个是默认的. K1: 行偏移量,LongWritable类型, 表示从哪个索引(即行偏移量)开始读 V1: 整行数据(Text) 0 hello tom hello teacher hello 31 allen tom mac apple ...... MR第2步: 负责拆分的, 即: 把 K1, V1 => K2, V2 //核心细节: 必须设计好K2的类型, 因为后续的 分区, 排序, 规约, 分组都是围绕它的. //这个步骤是逐行处理的, 即: 每行数据都要经历一次这个动作. 整行数据格式为: 'hello tom hello teacher hello' K2:Text(表示每个单词) V2: 每个单词的次数 hello 1 tom 1 hello 1 teacher 1 hello 1 这里往下又叫shuffle阶段:即分区,排序,规约,分组. MR第3步: 分区, 就是给上述的每条数据打标记的, 不同分区的数据, 会被不同的Reduce拉取. //默认只有1个分区, 即: 分区编号 0 一个分区对应一个Reduce //这个步骤是逐行处理的. K2:Text(表示每个单词) V2: 每个单词的次数 分区标记 hello 1 0 tom 1 0 hello 1 0 teacher 1 0 hello 1 0 MR第4步: 排序, 默认是按照K2内容, 升序排列的. //可以自定义 //这个步骤是逐行处理的. K2:Text(表示每个单词) V2: 每个单词的次数 分区标记 hello 1 0 hello 1 0 hello 1 0 teacher 1 0 tom 1 0 MR第5步: 规约, 就是用来对Map端的数据做局部合并, 降低Reduce拉取数据的次数, 从而提高效率的. //默认不规约, 如果需要, 自己设置. //这个步骤是逐行处理的. K2:Text(表示每个单词) V2: 每个单词的次数 分区标记 hello 1 0 hello 1 0 hello 1 0 teacher 1 0 tom 1 0 //可以理解为, 到这, Map任务就完全结束了, 即: 每个MapTask执行结束后, 都会获取1个 分好区, 排好序, 规好约的 文件. 等待Reduce处理. MR第6步: 分组, 默认按照K2分组的. //如果需要, 可以自定义. K2:Text(表示每个单词) V2: 每个单词的次数 分区标记 [hello, hello, hello] [1, 1, 1] 0 [teacher] [1] 0 [tom] [1] 0 MR第7步: Reduce阶段, 负责 合并的, 用户必须自定义. 目的: 把 K2,V2 => K3, V3, 且每个Reduce只会拉取属于自己的数据(根据 分区标号区分) K3:Text(表示每个单词) V3: 每个单词的总次数 hello 3 teacher 1 tom 1 MR第8步: 定义输出组件, 把结果写到目的地文件中. //要求: 目的地目录的父目录必须存在, 子目录必须不存在. hello 3 teacher 1 tom 1 看完这里可以直接去看图片中图3,加深印象 在Linux中执行Java版本的WordCount:(不用理) 1. 上传Java版的WordCount案例的jar包到Linux中. 拖拽即可. //example-mr-1.0.jar 2. 执行即可. yarn jar example-mr-1.0.jar /input/1.txt /outputJava -
MR案例-WordCount案例(Python版,看看就好)
-
编写源代码, 我们自己必须写 map 和 reduce这两个动作, 具体如下:
mapper.py
import sysfor line in sys.stdin: # 捕获输入流 line = line.strip() # 根据分隔符切割单词 words = line.split() # 遍历单词列表 每个标记1 for word in words: print("%s\t%s" % (word, 1))reducer.py
import sys
# 保存单词次数的字典 key:单词 value：总次数
word_dict = {}for line in sys.stdin: line = line.strip() word, count = line.split('\t') # count类型转换 try: count = int(count) except ValueError: continue # 如果单词位于字典中 +1，如果不存在 保存并设初始值1 if word in word_dict: word_dict[word] += 1 else: word_dict.setdefault(word, 1) # 结果遍历输出 for k, v in word_dict.items(): print('%s\t%s' % (k, v)) -
把这两个文件, 1.txt(记录单词的文件)上传到Linux中, 我们在Linux中执行, 有两种执行方式:
方式1: 本地模式.
cat 1.txt | python mapper.py | sort | python reducer.py //因为Linux默认安装的是Python2.7.5, 所以排序效果你看不到.
//解决方案: 把Linux自带的Python2.X给卸载了, 单独安装Python3.X
//但是有些命令(例如: yum)底层必须用Python2.X, 不然实现不了.
//最终解决方案: 我们不卸载Python2.X, 直接装Python3.X, 然后把默认版本从2.X改成3.X, 那些需要用2.X的(3个), 我们单独修改下即可.方式2: 在Yarn集群中运行.
hadoop jar /export/server/hadoop-3.3.0/share/hadoop/tools/lib/hadoop-streaming-3.3.0.jar
-D mapred.reduce.tasks=1
-mapper "python mapper.py"
-reducer "python reducer.py"
-file mapper.py -file reducer.py
-input /input/*
-output /outputpy细节:
1. 无论是本地模式, 还是Yarn集群模式, 都需要你先安装Python3.X环境.
2. python -V 可以查看Python版本. */
-
-
在Linux中安装Python3
//我们用的是 Python3.8.5, 具体过程, 详见笔记, 逐个执行命令就好了, 没啥难度, 因为要下载大量的插件, 要求你的网络好点, 不行开热点. -
MR的执行原理
//详见图解, 环形缓冲区... -
Yarn的简介
//什么是资源? 通用性? 资源调度? --->详见图片 -
Yarn的三大组件介绍
//ResourceManager, nodemanager, AppMaster-->详见图片,要知道它们大体是干嘛的 -
Yarn的执行流程(原理)
//详见图片 --->要能简单的说出来 -
Yarn的资源调度器详解(掌握)
概述:
所谓的资源调度器, 就是资源调度策略, 当系统比较繁忙的时候, 如果有多个执行任务同时请求执行, 谁先, 谁后, 怎么安排和管理?Yarn中资源调度器主要有3种:
1. FIFO Scheduler(First Input First Output) //先进先出调度器.
特点:
采用队列的方式, 即: 先进先出, 谁先来, 谁先执行, 且每个任务都是占用100%的资源.
当第1个任务执行结束, 才会执行第2个任务.
弊端:
资源分配不均衡. //假设第1个任务需要执行2个小时, 但是第2个任务需要执行2秒, 则第2个任务的总执行时间是: 2个小时零2秒.2. Capacity Scheduler(容量调度器) //雅虎搞出来的, 但是现在是 Apache版(社区版)Hadoop集群默认的 调度策略. 特点: 相当于开启两个队列, 假设: A, B. A占80%的资源, B个占20%的资源. //注意: 这个比例是我自己随便写的, 我们可以设置. 大任务走A队列, 小任务走B队列. 弊端: 因为开启了2个队列, 当某个队列没有任务执行的时候, 该部分资源也不会分配给另1个队列, 造成资源浪费. 3. Fair Scheduler(公平调度) //FaceBook(现已更名Meta)搞出来的, 现在是 CDH版(Cloudera公司的, 商业版)集群默认的. 特点: 跟 容量调度器比较相似, 只不过当A队列没有执行任务的时候, 它的资源会被B队列占用, 即: 相当于B队列100%的资源, 当A队列有执行任务的时候, B队列会归还一半(50%)的资源给A, 当A执行结束后, B又会独占100%的资源. 忘了可以看视频day7最后一集(19集)18分钟之后