hadoop学习一

hadoop学习一

标签（空格分隔）： hadoop

一，hadoop的起源

Doug Cutting—hadoop之父

• Apache Lucence:开源的高性能全文检索工具包
• Apache Nutch:开源的web搜索引擎
• Google的三篇论文:GFS–hdfs，mapreduce,big table
• Apache hadoop:大数据处理框架

二，hadoop的四大模块

hadoop—可靠的，可拓展，分布式
设计理念：
1，提供大数据存储
2，运行在成本低廉的服务器上面，数据可靠性
3，分布式运行计算能力

• Common:为其他模块提供支持的一些工具
• mapreduce：分布式计算框架
• Hdfs:hadoop分布式文件系统
  Linux默认的文件系统:ext4/windows默认的文件系统:ntfs
  分布式，可拓展
  一次写入，多次读取
  
  • Hadoop Yarn
    资源管理框架

三,HDFS的架构

• namenode:记录数据块的元数据（名次，权限，属性），hdfs集群访问的默认入口
• datanode:块（block）–128M 默认副本数3个

• secondarynamenode
  fsimage - 它是在NameNode启动时对整个文件系统的快照
  edit logs - 它是在NameNode启动后，对文件系统的改动序列
  只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。在这种情况下就会出现下面一些问题：
  edit logs文件会变的很大，怎么去管理这个文件是一个挑战。
  NameNode的重启会花费很长时间，因为有很多改动[笔者注:在edit logs中]要合并到fsimage文件上。
  如果NameNode挂掉了，那我们就丢失了很多改动因为此时的fsimage文件非常旧。[笔者注: 笔者认为在这个情况下丢失的改动不会很多, 因为丢失的改动应该是还在内存中但是没有写到edit logs的这部分。]
  因此为了克服这个问题，我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。
  

• HDFS数据的放置策略
  1，第一个副本放置在与client所在的同一节点上
  2，第二副本放在和第一个副本不同机架的节点上
  3，第三个副本放在和第一个副本同一机架的不同节点上

四,YARN介绍

• resourcemanage:资源管理
  1，处理客户的请求
  2，启动/监控ApplicationMaster
  3,监控NodeManager
  4,资源的分配和调度
• nodemanage：节点管理
  1，管理自身节点的资源
  2，处理来自resourcemanage的指令

五，mapreduce分布式计算框架