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要求高一些，
因此，两者建议分别放在两台机器中
集群图如下：
操作流程如下，个人总结，有待完善：
