认识Hadoop

Hadoop 2中YARN(Yet Another Resource Negotiator)的出现意味 着Hadoop有了新处理模型。

YARN是一个集群资源管理系统，允许任何一个分布式程序(不仅仅是MapReduce)基于Hadoop集群的数据而运行。
以下是一些能与Hadoop协同工作的处理模式。

协同处理模式：

Interactive SQL(交互式SQL)
利用MapReduce 进行分发并使用-一个分布式查询引擎，使得在Hadoop 上获得SQL查询低延迟响应的同时还能保持对大数据集规模的可扩展性。这个引擎使用指定的“总是开启(always on)”守护进程(如同impala)或容 器重用(如同Tez. 上的
Hive)。
Iterative processing(迭代处理)
许多算法，例如机器学习算法，自身具有迭代性，因此和那种每次迭代都从硬盘加载的方式相比，这种在内存中保存每次中间结果集的方式更加高效。MapReduce的架构不允许这样，但如果使用Spark 就会比较直接，它在使用数据集方面展现了一种高度探究的风格。
Stream processing(流处理)
流系统，例如Storm, Spark Streaming 或Samza使得在无边界数据流上运行实时、分布式的计算，并向Hadoop存储系统或外部系统发布结果成为可能。
Search(搜索)
Solr搜索平台能够在Hadoop 集群上运行，当文档加入HDFS后就可对其进行索引，且根据HDFS中存储的索引为搜索查询提供服务。

为什么需要Hadoop?

计算机硬盘的一个发展趋势:寻址时间的提升远远不敌于传输速率的提升。寻址是将磁头移动到特定硬盘位置进行读/写操作的过程。它是导致硬盘操作延迟的主要原因，而传输速率取决于硬盘的带宽。
如果数据访问模式中包含大量的硬盘寻址，那么读取大量数据集就必然会花更长的时间(相较于流数据读取模式，流读取主要取决于传输速率)。另-方面，如果数据库系统只更新- -小部分记录，那么传统的B树(关系型数据库中使用的一-种数据结构，受限于寻址的速率)就更有优势。但数据库系统如果有大量数据更新时, B树的效率就明显落后于MapReduce,因为需要使用“排序/合并”(sort/merge)来重建数据库。
在许多情况下，可以将MapReduce视为关系型数据库管理系统的补充。

MapReduce比较适合解决需要以批处理方式分析整个数据集的问题，尤其是- - 些特定目的的分析。RDBMS适用于索引后数据集的点查询(pointquery)和更新，建立索引的数据库系统能够提供对小规模数据的低延迟数据检索和快速更新。MapReduce 适合一次写人、多次读取数据的应用，关系型数据库则更适合持续更新的数据集。

 

读时模式 vs.写时模式

在传统数据库里，表的模式是在数据加载时强制确定的。如果在加载时发现数据不符合模式，则拒绝加载数据。因为数据是在写入数据库时对照模式进行检查,因此这- -设计有时被称为“写时模式”(schema on write)。
在另一方面，Hive对数据的验证并不在加载数据时进行，而在查询时进行，这称为“读时模式" (schema on read)。
用户需要在这两种方法之间进行权衡。读时模式可以使数据加载非常迅速。这是因为它不需要读取数据来进行“解析”(parse),再进行序列化并以数据库内部格式存入磁盘。数据加载操作仅仅是文件复制或移动。这-方法也更为灵活，试想，针对
不同的分析任务，同一个数据可能会有两个模式。Hive 使用“ 外部表”(externaltable)时，这种情况是可能发生的。
写时模式有利于提升查询性能。因为数据库可以对列进行索引，并对数据进行压缩。但是作为权衡，此时加载数据会花更多时间。