一、大数据概念
次要解决海量数据的存储和数据分析计算的问题
8bite =1 Byte,1k=1024Byte,
Bite Byte KB MB,GB,TB,PB,EB,ZB,YB,BB,NB,DB
- 大数据特点:
Volume 大量 (局部企业数据量达 EB)
Velocity 高速(数据处理效率要高)
Variety 多样。(结构化 + 非结构化)
value 低价值密度
二、从 hadoop 框架探讨大数据生态
- Hadoop
hadoop 的初衷是采纳大量的便宜机器,组成一个集群!实现大数据的存储和计算!
1 hadoop 1.x 和 2.x 区别
1.x 和 2.x 的区别是将资源调度和治理进行拆散!由对立的资源调度平台 YARN 进行大数据计算资源的调度!
晋升了 Hadoop 的通用性!Hadoop 搭建的集群中的计算资源,不仅能够运行 Hadoop 中的 MR 程序!也能够运行其余计算框架的程序!
在 hadoop 不久之后,因为 MR 的低效性,呈现了许多更为高效的计算框架!
例如:Tez,Storm,Spark,Flink
实现大数据的计算
①写程序,程序须要复合计算框架的要求!
java---->main-----> 运行
MapReduce(编程模型)----->Map--Reducer
②运行程序,申请计算资源(cpu+ 内存,磁盘 IO,网络 IO)
java----->JVM------>OS-----> 申请计算资源
1.0: MapReduce(编程模型)---->JobTracker----->JVM-----> 申请计算资源
2.0: MapReduce(编程模型)---->jar------> 运行时,将 jar 包中的工作,提交给 YARN,和 YARN 进行通信
由 YARN 中的组件 -----JVM------> 申请计算资源
2 hadoop 的组件
HDFS(框架): 负责大数据的存储
YARN(框架):负责大数据的资源调度
MR(编程模型):应用 Hadoop 制订的编程要求,编写程序,实现大数据的计算!
2.1 HDFS:负责大数据的存储
-
Namenode(1 个):
- 负责文件,名称等元数据 (属性信息) 的存储!
文件名,大小,文件切分了多少块(block),创立和批改工夫等! - 职责:承受客户端的申请;承受 DN 的申请;向 DN 分配任务
- 负责文件,名称等元数据 (属性信息) 的存储!
-
DataNode(N 个)
- 负责文件中数据的存储!
- 负责承受 NM 调配的工作;负责数据块 (block) 的治理(读,写)!
- 可选过程:SecondaryNamenode(N 个): 负责辅助 NameNode 工作!
2.2 MapReduce
MapReduce(编程标准):程序中有 Mapper(简略解决) 和 Reducer(合并)
遵循 MapReduce 的编程标准,编写的程序,打包后,称为一个Job(工作)!
Job 须要提交到 YARN 上,向 YARN 申请计算资源,运行 Job 中的 Task(过程)!
Job 会先创立一个过程 MRAppMaster(mapreduce 利用管理者),由 MRAppMaster 向 YARN 申请资源!
MRAppMaster 负责监控 Job 中各个 Task 运行状况,进行容错治理!
2.3 Yarn:负责集群中所有计算资源的治理和调度!
-
ResourceManager(1 个): 负责整个集群所有资源的治理!
- 负责承受客户端的提交 Job 的申请!
- 负责向 NM 分配任务!
- 负责承受 NM 上报的信息!
-
NodeManager(N 个): 负责单台计算机所有资源的治理!
- 负责和 RM 进行通信,上报本机中的可用资源!
- 负责支付 RM 调配的工作!
- 负责为 Job 中的每个 Task 调配计算资源!
-
Container(容器): 对工作运行环境的形象
- NodeManager 为 Job 的某个 Task 调配了 2 个 CPU 和 2G 内存的计算资源!
,防止被其余的 task 抢占资源! - 将计算资源,封装到一个 Container 中,在 Container 中的资源,会被临时隔离
- 以后 Task 运行完结后,以后 Container 中的资源会被开释!容许其余 task 来应用
- NodeManager 为 Job 的某个 Task 调配了 2 个 CPU 和 2G 内存的计算资源!
- ApplicationMaster:数据切分,为应用程序申请资源,并调配给外部工作,工作监控与容错
三、Hadoop 的运行环境搭建
1、重要目录
(1)bin 目录:寄存对 Hadoop 相干服务(HDFS,YARN)进行操作的脚本
(2)etc 目录:Hadoop 的配置文件目录,寄存 Hadoop 的配置文件
(3)lib 目录:寄存 Hadoop 的本地库(对数据进行压缩解压缩性能)
(4)sbin 目录:寄存启动或进行 Hadoop 相干服务的脚本
(5)share 目录:寄存 Hadoop 的依赖 jar 包、文档、和官网案例
2、配置文件
(1)4 个默认的配置文件:
地位:HADOOP_HOME/share/xxxx.jar/xxx-default.xml
文件名:core-default.xml:设置 hadoop 最外围的参数!
hdfs-default.xml 保留的是 hdfs 相干的参数!
mapred-default.xml: MR 程序在运行时,须要应用的参数!
yarn-default.xml: yarn 在启动时,须要的参数!
(2)4 个可自定义的配置文件:xxx-site.xml
core-site.xml:用户自定义的设置 hadoop 最外围的参数!
hdfs-site.xml 用户自定义的保留的是 hdfs 相干的参数!
mapred-site.xml: 用户自定义的 MR 程序在运行时,须要应用的参数!
yarn-site.xml: 用户自定义的 yarn 在启动时,须要的参数!
(3)tips
能够自定义配置文件的目录:hadoop –config 配置文件的目录
如果没有配置,默认读取 HADOOP_HOME/etc/hadoop 中对应的配置文件!
Hadoop 在启动时,先加载 4 个默认的配置文件,再加载用户自定义的配置文件,如果用户自定义的配置文件中有和 4 个默认配置文件中门的参数,能够笼罩之前曾经加载的值!
hadoop-daemon.sh start namenode 脚本在执行时,只会去默认的目录中读取配置文件!
3、hadoop 的运行模式:本地模式、伪分布式模式以及齐全分布式模式
(1)本地模式:在本机上应用 hdfs,应用的就是本地的文件系统
设置办法:
core-site.xml
中fs.defaultFS=file:///
(默认,不必批改)
(2)伪分布式:NN 和 DN 在一台机器,且只有一个 DN 节点
设置办法:
- 配置集群
指定 HDFS 中 namenode 的地址,
core-site.xml
中fs.defaultFS=hdfs://hadoop101:9000
配置
hdfs-site.xml
指定 HDFS 正本的数量dfs.replication
-
启动集群
格式化 nameNode,
bin/hdfs namenode -format
, 启动 namenode,datanode启动 NN:hadoop-daemon.sh start namenode
进行 NN:hadoop-daemon.sh stop namenode 启动 DN:hadoop-daemon.sh start datanode 进行 DN:hadoop-daemon.sh stop datanode 应用:hadoop fs 命令 文件门路
- 查看集群 jps
jps 是 JDK 中的命令,不是 Linux 命令。不装置 JDK 不能应用 jps
-
Yarn 上运行 mapreduce 程序
实现大数据的计算!
①依照 MR 的标准编写一个程序 ②将程序打包为 jar ③运行 jar 中的程序
两种运行模式:
取决于参数:mapreduce.framework.name=local(默认)
①本地模式(在本机上运行 MR) mapreduce.framework.name=local在本机运行 MR!在本机应用多线程的形式,运行多个 Task!
②在 YARN 上运行 mapreduce.framework.name=yarn
将 MR 提交给 YARN,由 YARN 将 Job 中的多个 task 调配到多台机器中,启动 container 运行 task! 须要启动 YARN,YARN 由 RM 和 NM 过程组成!
(3)齐全分布式
筹备 3 台客户机 P0501&wo
四、HDFS(hadoop distributed file system)分布式文件系统
1. hfs 不反对对文件的随机读写,能够追加,但不能批改
起因:文件在 HDFS 上存储时,以 block 为根本单位存储的
a. 没有提供对文件的在线寻址性能
b. 文件以块模式存储,批改了一个块中的内容,就会影响以后块之后的所有块,效率低
2. HDFS 不适宜存小文件
起因:HDFS 存储了大量的小文件,会升高 NN 的服务能力
NN 负责文件元数据(属性,块的映射)的治理,NN 在运行时,必须将以后集群中存储的所有文件的元数据全副加载到内存,NN 须要大量的内存
4. 同一个文件在同一时刻只能有一个客户端写入
5. 块大小,取决于 dfs.blocksize,2.x 默认为 128M,1.x 默认为 64M
起因:基于最佳传输损耗实践(在一次传输中,寻址工夫占用总传输工夫的 1% 时,本次传输的损耗最小,为最佳性价比传输)
不管对磁盘的文件进行读还是写,都须要先进行寻址
目前硬件的倒退条件,一般磁盘写的速率大略为 100M/s,寻址工夫个别为 10ms
块在传输时,每 64k 还须要校验一次,因而块大小,必须为 2 的 n 次方
6. 块大小须要适合调节
不能太大,a. 在一些分块读取的场景,不够灵便,会带来额定的网络耗费;b. 在上传文件时,一旦产生故障,会造成资源的节约。
不能太小,a. 块太小,同样大小的文件,会占用过多的 NN 的元数据空间;b. 块太小,在进行读写操作时,会耗费额定的寻址空间
7 正本数的概念指的是最大正本数
默认块大小 128M,指的是块的最大大小。每个块最多存 128M,如果以后块存储的数据不满 128M,存了多少数据,就占用多少磁盘空间,一个块只属于一个文件。
8 shell 操作
hadoop fs 既能够对本地文件系统进行操作还能够操作分布式文件系统
hdfs dfs 只能操作分布式文件系统
hadoop fs -help + 命令,可查帮忙文档
9 HDFS 的写数据流程
①服务端启动 HDFS 中的 NN 和 DN 过程
②客户端创立一个分布式文件系统客户端,由客户端向 NN 发送申请,申请上传文件
③NN 解决申请,查看客户端是否有权限上传,门路是否非法等
④查看通过,NN 响应客户端能够上传
⑤客户端依据本人设置的块大小,开始上传第一个块,默认 0 -128M,
NN 依据客户端上传文件的正本数(默认为 3),依据机架感知策略选取指定数量的 DN 节点返回
⑥客户端依据返回的 DN 节点,申请建设传输通道
客户端向最近 (网络举例最近) 的 DN 节点发动通道建设申请,由这个 DN 节点顺次向通道中的(间隔以后 DN 间隔最近)
下一个节点发送建设通道申请,各个节点发送响应,通道建设胜利
⑦客户端每读取 64K 的数据,封装为一个 packet(数据包,传输的根本单位),将 packet 发送到通道的下一个节点
通道中的节点收到 packet 之后,落盘 (测验) 存储,将 packet 发送到通道的下一个节点!每个节点在收到 packet 后,向客户端发送 ack 确认音讯!
⑧一个块的数据传输实现之后,通道敞开,DN 向 NN 上报音讯,曾经收到某个块
⑨第一个块传输实现,第二块开始传输,顺次反复⑤-⑧,直到最初一个块传输实现,NN 向客户端响应传输实现!
客户端敞开输入流
10 异样写流程
①-⑥见上
⑦客户端每读取 64K 的数据,封装为一个 packet,封装胜利的 packet,放入到一个队列中,这个队列称为 dataQuene(待发送数据包)
在发送时,先将 dataQuene 中的 packet 按程序发送,发送后再放入到 ackquene(正在发送的队列)。
每个节点在收到 packet 后,向客户端发送 ack 确认音讯!
如果一个 packet 在发送后,曾经收到了所有 DN 返回的 ack 确认音讯,这个 packet 会在 ackquene 中删除!
如果一个 packet 在发送后,在收到 DN 返回的 ack 确认音讯时超时,传输停止,ackquene 中的 packet 会回滚到
dataQuene。
从新建设通道,剔除坏的 DN 节点。建设实现之后,持续传输!
只有有一个 DN 节点收到了数据,DN 上报 NN 曾经收完此块,NN 就认为以后块曾经传输胜利!
NN 会主动保护正本数!
11 机架感知
2.7.2 默认的策略:
第一个正本放在本地机架的一个 DN 节点
第二个正本放在本地机架的另一个 DN 节点
本地机架的网络拓扑举例最多为 2,速度快!
第三个正本放在其余机架的一个 DN 节点
为了安全性
tomcat 服务器日志
数据库服务卡 mysql 数据 客户端()
五、MapReduce
六、zookeeper
1、概述:zookeeper= 文件系统 + 告诉机制
开源的分布式的,为分布式应用提供协调服务的 apache 我的项目,多用作为集群提供服务的中间件
负责存储和治理大家都关怀的数据,eg,hdfs 的 url
Zookeeper 是 java 编写的一个开源的分布式的存储中间件!
Zookeeper 能够用来存储分布式系统中各个过程都关怀的外围数据!
Zookeeper 采取观察者模式设计,能够运行客户端在读取数据时,设置一个观察者一旦察看的节点触发了指定的事件,服务端会告诉客户端线程,客户端能够执行回调办法,执行对应的操作!
2、特点:
(1)一致性:zookpeer 中的数据按程序分批入库,并最终统一
(2)原子性:一次数据更新要么胜利要么失败
(3)繁多视图:client 无论连贯到哪个 zk 节点,数据都是统一的
(4)可靠性:每次对 zk 的操作状态都会保留到服务器,每个 server 保留一份雷同的数据正本(和 hdfs 不一样,dhfs 每个 datanode 数据不统一)
(5)更新申请程序进行,来自同一个 client 的更新申请按其发送程序顺次执行
(6)实时性:在肯定范畴内,client 能读取到最新数据
3、数据结构
与 unix 文件系统相似,整体可看作一棵树,每个节点称作一个 znode,每个 znode 能够相似看作一个目录,其余能够创立子目录
zookeeper 集群本身保护了一套数据结构,存储构造是一个树形构造,其上每个节点,成为 znode,每个 znode 默认能存 1M 的数据,每个 znode 能够通过其门路惟一标示
4、利用场景:
数据公布与订阅:实用于配置信息多设施共享,会产生动态变化
软负载平衡:负责收集服务信息与状态监控
集群治理:每台机器的运行状态收集
5、应用
启动:bin/zkServer.sh start
bin/zkCli.sh -server host:port
进行:bin/zkServer.sh stop
bin/zkCli.sh -server host:port close|exit
增:create [-s] [-e] path data
-s: 创立一个带序号的 znode
-e: 创立一个长期 znode,长期的 znode 被所创立的 session 领有,一旦 session 敞开,长期
节点会被删除
删:delete path
rmr path
改:set path data
查:get path
stat path
ls path
ls2 path
反对四字命令
nc hadoop101 2181 ruok
设置观察者
get path watch:监听指定节点数据的变动
ls path watch:监听以后门路子阶段数据的变动,一旦新增或删除了子节点,会触发事件
留神:观察者在设置后,只有当次无效!
二、ZK 集群的注意事项
-
ZK 在设计时,采纳了 paxos 协定设计,这个协定要求,集群半数以上服务实例存储,集群
才能够失常提供服务
-
ZK 集群中,server 有 Leader 和 Followwer 两种角色
Leader 只有一个,在集群启动时,主动选举产生!选举 Leader 时,只有数据和 Leader 放弃同步的 Follower 有权参加竞选 Leader! 在竞选 Leader 时,serverid 大的 Server 有劣势!
-
集群模式 ZK 的写流程
①客户端能够连贯任意的 zkserver 实例,向 server 发送写申请命令 ②如果以后连贯的 server 不是 Leader,server 会将写命令发送给 Leader ③Leader 将写操作命令播送到集群的其余节点,所有节点都执行写操作命令 ④一旦集群中半数以上的节点写数据胜利,Leader 会响应以后 Server,让以后 Server 响应客户端,写操作实现!