hadoop1架构基本理解
0 出现原因:
业务场景:在1T数据中,找最小值
a) 集中式处理方式:
不断从硬盘加载部分数据放在机器内存中处理,然后丢弃内存数据,继续加载处理,
这样CPU真正计算时间是很少的,大部分时间都用在了磁盘IO上,
硬盘转速是固定的7200转,相对于内存速度和CPU速度,这种物理瓶颈无法处理,影响了整个作业速率。
特点: 将数据加载到计算区
b) 分布式处理方式:
1T的数据分散到多台机器上存储,后将计算请求分散到多台机器上来执行,然后分结果在汇总做一次处理
为了防止分散数据丢失,每一个存储数据节点在弄2个备份节点
特点: 将计算逻辑加载到数据区
明显b方案更适合,但是问题又来了:这种操作模式对于操作人而言,是不是复杂了很多,答案是肯定的,
人们有提成了一个目标:
数据虽然分散存储,但是对操作人员而言,看不到数据的分散状况,
操作人员只需要配置一个分配策略,然后再来服务的时候,服务会交给一堆集群的机器来执行。
此时Hadoop就应运而生,既满足b方案,同时也达到了人们提出简洁操作,分布屏蔽相对于人封装的目的。
1 hadoop 架构简介:
分为hdfs mapreduce 两部分, 两者都是主从结构,
hdfs:
主从结构
主节点,只有一个: namenode
从节点,有很多个: datanode
namenode负责:
接收用户操作请求,是用户操作的入口
维护文件系统的目录结构,称作命名空间
datanode负责:
存储文件
namenode相当于库管,你去存货取货,需要问库管明确要存/取的具体仓库位置,一旦明确后,你就直接去仓库(datanode)做的你的事情,因此真正存取操作是 客户端和datanode的直接交互。
在存储的时候,比如数据很大,被分在两个datanode节点上, 那么A节点存一半,B节点存一半,
同时hdfs 又会拿出A1,A2节点备份A的这一份数据, B1,B2备份B的这一份数据
mapreduce:
主从结构
主节点,只有一个: JobTracker
从节点,有很多个: TaskTracker
JobTracker负责:
接收客户提交的计算任务
把计算任务分给TaskTrackers执行,即任务调度
监控TaskTracker的执行情况
TaskTrackers负责:
执行JobTracker分配的计算任务
namenode对内存要求较高,
jobtracker因为一直要接收用户请求,对CPU要求高一些,
因此,两者建议分别放在两台机器中
集群图如下:
操作流程如下,个人总结,有待完善: