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要求高一些，

因此，两者建议分别放在两台机器中

 

 

集群图如下：

 

 

 

 

操作流程如下，个人总结，有待完善：