框架知识

概述
Hadoop Map/Reduce是一个使用简易的软件框架，基于它写出来的应用程序能够运行在由上千个商用机器组成的大型集群上，并以一种可靠容错的方式并行处理上T级别的数据集。
一个Map/Reduce 作业（job） 通常会把输入的数据集切分为若干独立的数据块，由 map任务（task）以完全并行的方式处理它们。框架会对map的输出先进行排序， 然后把结果输入给reduce任务。通常作业的输入和输出都会被存储在文件系统中。 整个框架负责任务的调度和监控，以及重新执行已经失败的任务。
通常，Map/Reduce框架和分布式文件系统是运行在一组相同的节点上的，也就是说，计算节点和存储节点通常在一起。这种配置允许框架在那些已经存好数据的节点上高效地调度任务，这可以使整个集群的网络带宽被非常高效地利用。
Map/Reduce框架由一个单独的master JobTracker 和每个集群节点一个slave TaskTracker共同组成。master负责调度构成一个作业的所有任务，这些任务分布在不同的slave上，master监控它们的执行，重新执行已经失败的任务。而slave仅负责执行由master指派的任务。
应用程序至少应该指明输入/输出的位置（路径），并通过实现合适的接口或抽象类提供map和reduce函数。再加上其他作业的参数，就构成了作业配置（job configuration）。然后，Hadoop的 job client提交作业（jar包/可执行程序等）和配置信息给JobTracker，后者负责分发这些软件和配置信息给slave、调度任务并监控它们的执行，同时提供状态和诊断信息给job-client。
虽然Hadoop框架是用JavaTM实现的，但Map/Reduce应用程序则不一定要用 Java来写 。
Hadoop Streaming是一种运行作业的实用工具，它允许用户创建和运行任何可执行程序 （例如：Shell工具）来做为mapper和reducer。
Hadoop Pipes是一个与SWIG兼容的C++ API （没有基于JNITM技术），它也可用于实现Map/Reduce应用程序。
Hadoop是一个大规模分布式批处理架构，虽然它在单台计算机上也能使用，但它的真正能力是在成百上千计算机上运行时才显现出来，Hadoop可以高效地将大量工作高效地分布到一组计算机上.
它能处理多大量的工作？Hadoop面对的处理工作比许多现在系统处理要高几个数量级，几百G的数据，只不过在Hadoop眼里不过是小数据量。实际上Hadoop是设计来对付“We级的”的数据，“Web级”数据大小范围在几百G到T级，甚至P级。在这种规模下，输入数据很可能甚至不能存入单个计算机的磁盘中，更不用说内在了，所以Hadoop中包括一个分布式文件系统，它将输入文件分成块，将这些块传输到你的集群中的计算机上保存，这样，原问题可以使用集群中所有计算机并行处理，那么得到计算结果的效率也就最高.
数据分块
在Hadoop集群中，数据被分布到集群的各个结点，Hadoop Distributed File System (HDFS)将大的数据文件分成块，将这些块交由集群中的结点处理，并且每个块都会复制到不同的几个机器上，所以一台机器崩溃不会导致数据丢失，监测系统会对结点崩溃做出反应，重新复制数据，即部分存储(partial storage)。即便文件块被复制分布到不同的机器，但它们形成了一个单一的命名空间，所以它们的内容还是全局可访问的。
在Hadoop的编程框架中，概念上来说，数据是面向记录的。每个输入文件都被以行或其它特定的应用逻辑格式分开。集群中的每个结点的每个进程都会处理这分开文件的一部分，Hadoop框架再根据分布式文件系统的信息调试进程到数据/记录的位置，因为文件以块的形式存在于分布式文件系统中，每个结点上的每个计算进程处理数据的一个子集。哪些数据要被一个结点处理是由数据本身的存放位置决定的。大部分数据是直接地从磁盘读入CPU，这减少了网络带宽的限制，也防止了不必要的网络传输。这种策略是将计算移动到数据，而不是将数据移动到计算，这使得Hadoop有丰很高的数据本地性，从而它就有着很高的性能。
< xmlnamespace prefix ="v" ns ="urn:schemas-microsoft-com:vml" />
Hadoop教程 第一章：教程介绍 - quweiprotoss - Koala++s blog
MapReduce：隔离的进程
Hadoop限制了进程的通信量，因为每个任务所处理的单个记录与其它记录无关，这初看起来似是一个极大的限制，但它是整个框架更可靠，Hadoop不会运行任意一个程序并将它分布到整个集群，程序必须符合一个特定的编程模型，称为MapReduce。
在MapReduce中，Mapper任务是将记录分开，Mapper的输出会作为Reducer任务的输入，Reducer再将不同的Mapper结果合并。
在一个Hadoop集群中，不同的结点仍会相互通信，但是与其它传统的分布式系统通信有所不同，传统的作法是应用设计者要显式地通过socket或MPI缓冲将字节流从一个结点传到另一个结点，但在Hadoop上的通信是隐式的，数据片断都有着key值，通过它Hadoop就知道如何将相关信息位发送到一个目标结点。Hadoop在内部管理数据传输和集群拓扑。
通过限制结点之间的通信，Hadoop使分布式系统更可靠，单个结点崩溃可以通过其它结点重新开始任务的方式正常工作。因为用户级任务不需要结点之间显式地通信，所以不需要用户程序交换信息，同样结点不需要回滚到预定义的检测点去部分地重新开始计算，在Hadoop中其它正常结点继续运行，好似没有错误发生，并将部分重新开始程序这个挑战的方面留到Hadoop层处理。

图1.1 在数据载入时数据分布到各个结点

# Struts2与Struts1对比
解答：

1、Action类的实现方式：
            Struts1的Action在实现的时候必须扩展Action类或者Action的子类，Struts2的Action类实现的时候可以不用实现任何类和接口，虽然Struts2中提供一个ActionSupport类，但是，不是必须的。
         2、Struts1的Action类是单例模式，必须设计成线程安全的，Struts2则为每一个请求产生一个实例
         3、Struts1的Action类依赖与Servlet API，从其execute的方法签名可看出，execute方法有两个Servlet的参数HttpServletRequest和HttpServletResponse，Struts2则不依赖于Servlet API
         4、以为Struts1依赖于Servlet API这些Web元素，因此对Struts1的Action进行测试的时候是很困难的，需要借助与其他的测试工具，Struts2的Action可以象测试其他的一些Model层的Service类一样进行测试
         5、Struts1的Action与View通过ActionForm或者其子类进行数据传递，虽然也有LazyValidationForm这样的ActionForm的出现，但是，还是不能象其他层面那样通过一个简单的POJO进行数据传递，而Struts2将这样的奢望变成了现实
         6、Struts1绑定了JSTL，为页面的编写带来方便，Struts2整合了ONGL，也可以使用JSTL，因此，Struts2下的表达式语言更加强大