Hadoop介绍
Hadoop
是一个由Apache基金会所开放的
分布式系统
基础架构。
解决问题：
海量数据存储（HDFS-Hadoop Distributed File System）
海量数据分析计算（MapReduce）
资源管理调度（YARN）
作者： Doug Cutting
受Google三篇论文启发（2003年发布GFS、2004年发布MapReduce、2006年发布Big Table)
GFS： HDFSMapReduce：MapReduceBig Table：HBase
传统和现在海量数据存储如图：
hadoop具体干什么？
Facebook用Hive进行日志分析Amazon:用hadoop推荐
Yahoo： 用hadoop垃圾邮件过滤天猫： 期初hadoop进行 离线数据处理。2012年使用 storm进行进行实时分析和 推荐。淘宝： 搜索中自定义筛选用 Hive。09年开始，用于对海量数据的离线处理，例如对日志的分析，交易记录的分析等。支付宝使用 Hbase对用户的消费记录可以实现 毫秒级查询。
hadoop薪水范围，招聘网站
智联招聘-搜索职位，高级搜索猎聘网-找职位
淘宝Hadoop使用案例分享
数据魔方
双11解决方案
hadoop版本
官方版本（2.4.1)Cloudera CDH5-商业支持，由商业支持，目前京东在用。
hadoop核心
HDFS：Hadoop Distributed File System 分布式文件系统YARN：Yet Another Resource Negotiator 资源管理调度系统
问题： 如何解决海量数据存储？
NFS飞秋模式
HDFS的架构
主从结构主节点：namenode从节点：datanodehadoop1.x 中namenode就一个节点，hadoop2.x中namenode可以由多个节点，组成一个集群namenode负责1. 接收用户操作请求2. 维护文件系统目录结构3. 管理文件与block之间关系datanode负责1. 存储文件2. 文件被分成block存储在磁盘上3. 为保证数据安全，文件会有多个副本
namenode和datanode关系
1. 如图开发经理和开发人员的关系2. 如仓库和管理员的管理
问题： 怎样解决海量数据计算
多进程+多线程方法，采用MapReduce
Hadoop的特点
1.扩容能力（Scalable）：能可靠地（reliably）存储和处理千兆字节（PB）数据。2.成本低（Economical）：可以通过普通机器组成的服务器群来分发以及处理数据。这些服务器群总计可达数千个节点。3.高效率（Efficient）：通过分发数据，hadoop可以在数据所在的节点上并行地（parallel）处理它们，这使得处理非常的快速。4.可靠性（Reliable）：hadoop能自动地维护数据的多份副本，并且在任务失败后能自动地重新部署（redeploy）计算任务。
Hadoop的1.0 和 hadoop2.0 比较
自成为大数据工具以来，Hadoop 就是一个非常棒的数据存储系统，但是需要开发 Java 应用来访问数据的 MapReduce 学习起来却比较困难。
当然，还有别的办法可以从 Hadoop 中获取信息。Hbase数据是 Hadoop 的一部分，它可以让用户按照数据库范式来处理数据。Hive数据仓库则可以让你用类 SQL 的 HiveSQL 查询语言来创建查询并转化为 MapReduce 任务。不过 Hadoop 仍受限于单线程性。MapReduce 任务、Hive 查询、Hbase 操作，等等，这些都要轮流进行。
- 首先用户程序 (JobClient) 提交了一个 job，job 的信息会发送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要与集群中的机器定时通信 (heartbeat), 需要管理哪些程序应该跑在哪些机器上，需要管理所有 job 失败、重启等操作。
- TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。
- TaskTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heartbeat 发送给 JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。上图虚线箭头就是表示消息的发送 - 接收的过程。
主要的问题集中如下：
- JobTracker 是 Map-reduce 的集中处理点，存在单点故障。
- JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
- 在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。
- 在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。
- 源代码层面分析的时候，会发现代码非常的难读，常常因为一个 class 做了太多的事情，代码量达 3000 多行，，造成 class 的任务不清晰，增加 bug 修复和版本维护的难度。
- 从操作的角度来看，现在的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复，性能提升和特性化 ) 时，都会强制进行系统级别的升级更新。更糟的是，它不管用户的喜好，强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的 Hadoop 版本而浪费大量时间。
YARN解决方案
在 Hadoop 2.0 发布经理 Arun Murthy 看来，其最重要的变化是 MapReduce 框架升级为Apache YARN。扩展 Hadoop 中可以应用的软件种类和应用程度。Arun Murthy 本人就是 YARN 项目主管，他指出，Hadoop 1.0 和 2.0 的区别在于，前者所有的事情都是面向批处理的，而后者则允许多个应用同时在内部访问数据。
相对于当前 MapReduce 系统能处理的事情，把这些功能分开使得 Hadoop 集群资源的管理更加强大。
重构根本的思想是将 JobTracker 两个主要的功能分离成单独的组件，这两个功能是资源管理和任务调度 / 监控。新的资源管理器全局管理所有应用程序计算资源的分配，每一个应用的 ApplicationMaster 负责相应的调度和协调。一个应用程序无非是一个单独的传统的 MapReduce 任务或者是一个 DAG( 有向无环图 ) 任务。ResourceManager 和每一台机器的节点管理服务器能够管理用户在那台机器上的进程并能对计算进行组织。
事实上，每一个应用的 ApplicationMaster 是一个详细的框架库，它结合从 ResourceManager 获得的资源和 NodeManager 协同工作来运行和监控任务。
上图中 ResourceManager 支持分层级的应用队列，这些队列享有集群一定比例的资源。从某种意义上讲它就是一个纯粹的调度器，它在执行过程中不对应用进行监控和状态跟踪。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务。
ResourceManager 是基于应用程序对资源的需求进行调度的 ; 每一个应用程序需要不同类型的资源因此就需要不同的容器。资源包括：内存，CPU，磁盘，网络等等。可以看出，这同现 Mapreduce 固定类型的资源使用模型有显著区别，它给集群的使用带来负面的影响。资源管理器提供一个调度策略的插件，它负责将集群资源分配给多个队列和应用程序。调度插件可以基于现有的能力调度和公平调度模型。
上图中 NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况 (CPU，内存，硬盘，网络 ) 并且向调度器汇报。
每一个应用的 ApplicationMaster 的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控它们的进程，处理任务的失败原因。
扫一扫
2318
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
