1、MR和关系型数据

MR和传统的关系型数据库处理的数据是不同，传统关系型数据库处理的是较结构化数据，对于半结构化和非机构话数据处理的还不是很好，MR正好对关系型数据不擅长领域做了补充，MR输入的键值并不是数据的固有属性，而是由分析数据人员来选择的，就目前看来他们是互补的关系，MR通过HIVE实现了hadoop固有的SQL,不过mr的适应性更强一些，不过随着以后的发展关系型数据库也会慢慢不断发展的。另外一个值得注意的就是MR是基于数据流的数据处理,处理的是一种非结构化的数据，比SQL结构性数据更具有适用性，是这种编程更加具有伸缩性。

2、MR的核心是实现数据本地化，由于MR是基于数据流式处理，所以带宽资源就显得尤为重要。

3、由于MR采用的是无共享的框架，各节点之间都是相对独立的，所以MR可以检测出节点失败的情况，在MR过程中，R阶段是要以M的结果为输入的，所以如果R没有获取到M的结果的时候会重新执行。在MR过程中，R的output输出目录是不能存在的，否则无法执行，一个长时间执行后的结果被覆盖是一件很懊恼的事情。

4、MR过程中有两个很重要的角色JobTracker和TaskTracker，可以打个比喻，J相当于管理员（负责分配任务），管理者一批员工T（负责执行任务）,员工执行任务要从J那边得到任务编号才可以进行任务执行。

5、hadoop将输入数据分成等长的数据分片，每一个分片都是一个map任务，并由用户自定义的函数MR来处理分片中的的每一条记录。

6、决定整个作业时间的主要因素分为两种1、管理分片的时间2、map创建任务的时间

7、数据本地优化，各节点执行map,各个节点存有的数据分片越趋向于HDFS分块可以获得最佳性能，这样确保了单个节点的最大输出块。输出块的大小根据硬件和集群的实际情况而定，磁盘的读取量。R阶段并不具备本地化的优势，他的输入通常是来自M的结果，因此需要通过网络进行传输发送到任务R节点上，这里就涉及到带宽问题了，因为我们应该尽量减少M向R的输入，通过一些其他的手段如COMBINER或者并行输入或者通过压缩数据流的手段等。

8、hadoop目前不适用的场景 1、低时间延迟的 可以考虑Storm 或者Spark 2、大量小文件，主要原因是所有的数据块元数据信息都存放在namenode文件夹下，这样大量的小文件会造成namenode文件内存被占用 3、多用户写入，任意修改的，因为hadoop设计的初衷是为了一次写入，多次读取的。

9、HDFS的数据块大于磁盘的块是为了减少寻址。

10、namenode管理着所有datanode的域名空间，他维护着文件系统及整棵树的文件目录，这些信息被永久的保存在本地磁盘上，namenode也记录着各个节点的数据信息，但是他并不保存在本地磁盘上，随着每次重启都要重构节点信息。更要命的是namenode是单节点，一个集群只有一个namenode所以一旦namenode出现问题，整个集群瘫痪了，如果使用keepalived的话，可以作为辅助节点，但是难免还是会有数据的丢失。据说hadoop2.x已经解决了这个问题。

11、HDFS客户端通过DistributedFileSystem 获得一个FsDataInputStream对象，从na

menode那里获取到datanode的文件位置信息。DFSoutputStream处理datanode和namenode之间的通信。

12、一致模型：在读取数据的时候，FSDdataoutputstream得到的数据是按块来显示的就是说，块在读取的时候不能立即显示需要等该块读完了，这样就造成了数据缓存，一旦集群发生故障数据块丢失生产环境下是不允许的，HDFS提供了一个方法来强制所有的缓存与数据节点保持同步即对FSDataOutPutStream调用sync(),能保证到目前为止写入数据的一致性，不过这样会对应用增加一些额外的性能开销，所以引用该方法还需要根据集群性能的均衡而定。

13、并行复制，典型的应用就是两个HDFS之间的传输，该方法可以从hadoop文件系统复制大量的数据，也可以将大量数据从hadoop复制出来。这里我们可以优化尽量的减少MAP构建，尽量让他多复制。