Hadoop笔记（一）

1.大数据处理不是神话，Hadoop也不是神话。他们不是指在原有的硬件资源（单机，比较少的CPU）就可以迅速的处理TB甚至PB级别的数据。
本身TB甚至PB级别的数据就已经超过了现有计算资源的处理能力（或者说，可以处理完，但是要花费难以容忍的时间），办法就是两个：
a.提升现有单机的能力
b.变为集群，联合使用多台机器的CPU、硬盘
a的提升是有限的，而b的提升才是无限的。
但联合使用多台机器的硬盘和CPU是很复杂的，文件的拆分和管理，计算任务的拆分和计算结果的归并。所以Hadoop的HDFS和MapReduce就很好的帮忙处理了这两件事情，可以让开发人员不用太关心底层的实现，而把更多的精力放在自己业务的实现上。
所以，Hadoop并不是帮你用很烂的机器来完成很大数据量分析的工具，它只是一个帮你管理和使用你的集群的工具。


2.速度
什么样的处理速度是快，什么样的处理速度是慢。
一个可供参考的标准：
2008年，Hadoop打破世界纪录，在一个910节点到集群，用209秒完成1TB数据到排序。
同年，Google在报告中称，它完成1TB排序只用了68秒。（集群规模不可考；但你知道，它的机器恐怕是遍布世界吧）
2009年，有报道称雅虎有一个团队用Hadoop对1TB的数据排序只花了62秒。（集群规模同样不可考）
所以，就可以用：1TB+910节点=209秒排序 作为一个衡量的指标。


3.集群规模
小型集群10台
中型集群50台
大型集群100台以上
大数据处理就是一个舍不得孩子套不住狼的事情。如果你的数据够大够有价值，就不要吝啬机器。


4.Mapreduce计算需要将计算任务分片，理想分片大小应该倾向于HADOOP的块大小，即64M。如果一个分片大于块大小，则很有可能这样一个分片位于两台计算机上，这样在计算时数据就需要经过网络传递给MAP任务节点，这样对于性能到损耗就比较大。


5.可以为map指定一个combiner,combiner的输出就是reducer的输入。这样可以减少map->reduce之间传递的数据。
PS：其实combiner的实现和reducer一模一样，只不过它是对每一个map任务的输出reduce出一个结果。最后再把所有map任务的reduce结果（即combiner的输出）传给reducer最后再总的reduce出一个结果。
不过在集群繁忙的情况下，Hadoop可能会不执行combiner。


6.Hadoop的HDFS并不适合要求低时延的访问（例如几十毫秒），它是为高吞吐量做优化的，可能会以提高时延为代价。namenode将文件的元数据存储在内存中，因此能够支持的文件数目取决于namenode所在机器的内存大小。