我在各处吐糟Hadoop是个渣，但是也没详细说过到底为什么，这里综合一下,算是对我自己的言行负责

</p>

吐糟为什么说Hadoop是个渣。

最近大数据概念流行，有个笑话曾经戏虐流行的也可能是感冒。除了那几个V被涛哥吐糟：原文是“大数据的4个V”，只是不痛不痒生搬硬套的无病呻吟”http://blog.sciencenet.cn/blog-3075-603325.html 。按下不表。

在国内有个现象“一窝蜂”上，好在我们人口基数多，指数现象明显，提及大数据，处理平台就须是Hadoop。好吧，就先说下Hadoop集群，国内用得起千台以上规模主机的大概也就只有BATS（百度阿里腾讯新浪），某易某狐某搜都别捉急，也欢迎其他够资格的加入。Hadoop 中三个基本构成要件 HDFS BigTable MapReduce，涉及某goo的篇论文。算了，抄别人概念这事儿就不接着吐了。

逐个来，先说HDFS，为了提高数据可靠性，所谓就近计算，将数据复制三份。即将整体数据存储的空间加三倍存。在运维时，如果主机存储空间利用率超过80%，一般都要开始考虑扩容了，如果是三倍的冗余，其实这里就有近四倍的物理空间需求。

考虑某宝实际运营中硬盘的损坏率10%/年，（还有网络损坏、内存损坏、和极少的CPU损坏），合并出来运营的成本是很惊人的。增加设备同时也增加了网络接口，就算每个网络接口100元，蚊子也是肉啊。

机房空间，42U机柜，理论上能装到21台2U的主机，除去网络设备、电源控制所占空间，方便按20台主机算。如果1000台规模，需要50个机柜。但是其中2/3都是多出来的。本来需要一整个机房的空间，其实只用一排机柜。

电力消耗，平均5台机架式服务器，24x7运行1年，就需要1台机架式服务器的电费，（工业用电那叫一个贵）。1000机器开一年就需要消耗200台机器的购置费，大概也就是才多出来超过千万点点/年吧。当然，还有财务上的设备购置费或者设备折旧费用比这个数额只多不少。

解决方法：

1.压缩。提及压缩，性能指标需要看压缩时间、解压时间、压缩比，还有不是很容易注意到的内存消耗和CPU消耗。

具体的技术比较细节猛击 http://compressionratings.com/sort.cgi?rating_sum.brief+6n

最快的LZ4解缩时间，比Copy 仅多20%多一点，平均压缩率是0.5倍原始空间大小。压缩不仅意味着存储空间需求的降低，还意味着磁盘IO时间的节省，网络传输时间的节省。看似费时费力，总体应该还是节省。且如果是列式的数据，压缩效率那是惊人的。我有用 LZ4 完成超过 10：1压缩的经验。

2.HDFS的效率，为了提高所谓整柜离线的可靠性保障，就随意地将数据放了三份，某虎，你这是极不负责任地，也是动辄几千万的随意。

古代，在单机多硬盘环境下，通常使用RAID提高数据可靠性，但是在分布环境下，一样也有分布式RAID,十几年前就有的分布式RAID论文：http://www.docin.com/p-70821444.html 都没有人看到过吗？

3.如果嫌弃2太学术，实现起来比较远，glusterfs听说过了没有？从3.3开始就能支持Hadoop直接挂接了，分布式RAID,不用三份数据的。不负责任脚注：如果用glusterfs 碰到全局共享锁的问题，别怪我没有提醒。其实实现一个远程分布式RAID对那些动辄就上千万人工费的开发队伍真的就很难么?

4.BigTable, 暂时还没什么好吐的，先冷着。

5.Map-Reduce，开发中使用MR有个方便之处，写一个模块，部署到各个节点，然后其并发运行。这个看似很不起眼的功能，其实后面隐含存在着模块分发、任务调度、数据的分布和计算系列的功能。数据分布计算不说，用C写一个模块分发、并能动态调度的过程就几十行代码的事啊。用的着大费周折地用则么不高效的实现么？

6.吐糟重点来了：国内的IT行业，已经从古老的习惯敏捷开发、到互联网的习惯快速迭代，已经没有意愿进行基础平台开发了，要么快，快到干脆用Rails，其实Java当初也是打着快速应对开发的旗帜而来的；要么死，裁撤。这是一个浮躁的时代，也就注定没有耐心的基础开发。一切也如毒瘤，尾大不掉。

 为什么发在这里，其实这与统计关系不大，不过是数据基础平台而已。这里我是版主，有编辑权利，【有权就是好】，可以控制。欢迎随时拍砖扔蛋。

</p>