|
为什么使用hadoop？
在单机程序设计中，为了快速处理一个大的数据集，通常采用多线程并行编程，如图所示，大体流程如下：先由操作系统启动一个主线程，由它负责数据切分、任务分
配、子线程启动和销毁等工作，而各个子线程只负责计算自己的数据，当所有子线程处理完数据后，主线程再退出。这种方式依然受限于一台计算机的处理能力，另外某些数据集的增长会超出一台计算机的处理能力。这时可以将大数据切分成多部分使用多台计算机来处理数据，当使用多台计算机时，整个大环境中的其他因素将对其产生影响，其中最主要是协调性和可靠性两大因素。哪个进程负责运行整个作业？我们如何处理失败的进程？因此，尽管可以实现并行处理，但是实际上非常复杂，使用hadoop框架来实现并行数据处理将很有帮助。
hadoop 2.0
hadoop2.0的组成：
 1：计算框架：MRv2:（与mrv1有相同的编程模型和数据处理引擎（优化过），唯一不同的是运行时环境。），dag，spark等。 mapreduce计算框架结构如下：
详细请参考文章另开帖子：hadoop2.0 yarn 之 mapreduce on yarn (MRv2) 传送门：http://blog.csdn.net/jiushuai/article/details/17733581 2:yarn通用资源管理框架（主要由resourcemanager,nodemanager,applicationMaster,Container等组成） 3：hdfs（还没整理好。。稍后整理）
yarn 说明：
随着互联网的高速发展，基于数据密集型应用的计算框架不断出现，从支持离线处理
的MapReduce，到支持在线处理的Storm，从迭代式计算框架Spark 到流式处理框架S4，
各种框架诞生于不同的公司或者实验室，它们各有所长，各自解决了某一类应用问题。而
在大部分互联网公司中，这几种框架可能同时被采用。比如在搜索引擎公司中，一种可能
的技术方案如下：网页建立索引采用MapReduce 框架，自然语言处理/ 数据挖掘采用 Spark
（如网页 PageRank 计算、聚类分类算法等），对性能要求很高的数据挖掘算法用MPI 等。
考虑到资源利用率、运维成本、数据共享等因素，公司一般希望将所有这些框架都部署到
一个公共的集群中，让它们共享集群的资源，并对资源进行统一使用，同时采用某种资源
隔离方案（如轻量级 cgroups）对各个任务进行隔离，这样便诞生了轻量级弹性计算平台。
 资源利用率高：如果每个框架一个集群，则往往由于应用程序数量
和资源需求的不均衡性，使得在某段时间内，有些计算框架的集群资源紧张，而另
外一些集群资源空闲。共享集群模式则通过多种框架共享资源，使得集群中的资源
得到更加充分的利用。
运维成本低：如果采用“一个框架一个集群”的模式，则可能需要多个管理员管理
这些集群，进而增加运维成本，而共享模式通常需要少数管理员即可完成多个框架
的统一管理
数据共享：。随着数据量的暴增，跨集群间的数据移动不仅需花费更长的时间，且硬
件成本也会大大增加，而共享集群模式可让多种框架共享数据和硬件资源，将大大
减小数据移动带来的成本。
组成结构：  resourcemanager（scheduler调度器，application manager（asm）应用程序管理器 2个 组件组成） rm调度器：另开帖子：hadoop2.0 yarn 之 资源调度器 基于hadoop2.2.0 传送门：http://blog.csdn.net/jiushuai/article/details/17733683 应用程序管理器: applicationmaster 1:用户提交的每个应用程序均包含一个am。 与rm调度器协商以获取资源（container） 将得到的任务进一步分配给内部任务 与nm通信以启动/停止任务 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以启动任务 当前默认的2个applicationmaster（演示am用的distributedshell,和MRAppMaster） Nodemanager 1：NM是每个二姐店上的资源和任务管理器 定时地向rm汇报本节点上的资源使用情况和各个container的运行状态； 接受并处理来自am的container启动/停止等请求。 Container 1：container是yarn资源的抽象，它封装了某个节点上的多维度资源（内存，cpu，磁盘，网络等），当am想rm申请资源时，rm为am返回的资源便是用container表示的。yarn会为每个任务分配一个container，且该任务只能使用该container描述的资源，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。（目前yarn只支持cpu和内存2种资源） yarn 工作流程  步骤 1 用户向YARN 中提交应用程序，
其中包括 ApplicationMaster 程序、启动
ApplicationMaster 的命令、用户程序等。
步骤 2 ResourceManager 为该应用程序分配第一个 Container，
并与对应的Node-
Manager 通信，要求它在这个Container 中启动应用程序的 ApplicationMaster。
步骤 3 ApplicationMaster 首先向ResourceManager 注册，
这样用户可以直接通过
ResourceManage 查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运
行状态，直到运行结束，即重复步骤 4~7。
步骤 4 ApplicationMaster 采用轮询的方式通过 RPC 协议向ResourceManager 申请和
领取资源。
步骤 5 一旦ApplicationMaster 申请到资源后，便与对应的 NodeManager 通信，要求
它启动任务。
步骤 6 NodeManager 为任务设置好运行环境（包括环境变量、 JAR 包、二进制程序
等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
步骤 7 各个任务通过某个RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以
让ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
在应用程序运行过程中，用户可随时通过 RPC 向ApplicationMaster 查询应用程序的当
前运行状态。
步骤 8 应用程序运行完成后， ApplicationMaster 向ResourceManager 注销并关闭自己。
|
|
|
