Hadoop不是低成本方案

         Hadoop是流行的大数据并行计算体系，廉价横向扩展是它的主要特点。但Hadoop的廉价指的是硬件和软件授权成本，而不是总体成本。在学习成本、开发成本、管理成本上Hadoop并不总是占优，有时候甚至连硬件成本也不占优。

         学习成本高。Hadoop的生态系统庞大，包括了几十种相关的产品，常见的就有：MapReduce、HDFS、Hive、hbase、YARN、Zookeeper、Avro、JAQL、PIG、solr、mesos、shark、stream、storm。熟悉这些产品的部署步骤、功能特性、开发方法都需要付出高昂的学习成本。

       挑选与产品匹配的Hadoop版本也不轻松。Hadoop版本混乱，有一代和二代之分，每一代有十几个版本，各有不同的新特性，比较稳定的有：0.20.x、0.21.x、0.22.x、1.0.x、0.23.x、2.x等。

       由于Hadoop不够成熟，商品化程度不足，用户在进入开发阶段后必须持续学习，这样才能及时替换有bug或有性能缺陷的产品和版本。虽然有些商业化较成熟的版本，如Cloudera或HorontWorks，但仍然不能做到足够稳定。另外，在设计和开发前不要忘记学习Hadoop的开发框架，它的结构非常复杂，经常要深读源代码才能恍然大悟。

         开发成本高。Hadoop以MapReduce编程为基础。MapReduce缺乏底层函数，计算功能不专业，尤其是结构化数据的计算函数，它几乎一个都没有提供，程序员需要自行实现这些算法：过滤、统计、唯一值、交集、排序、排名、比上期、同期比、相对位置计算、区间计算等，随便哪个都要写出几十甚至上百行的代码，而且还难以通用，每次有新任务时又要重写。

       为了弥补结构化计算函数缺乏的弱点，Hive等工具诞生了，为Hadoop增加了类SQL的特性。但这种类SQL功能有限，比起窗口函数、存储过程来还有很大差距，用户仍然要经常通过MapReduce来解决HiveQL难以实现的功能。为了实现商业计算中常见的业务逻辑，Hadoop用户需要聘请更多的资深程序员，需要组建一只豪华的开发团队，时间成本和人力成本耗费巨大。即使这样，仍然有很多复杂的业务逻辑是Hadoop难以实现的。

       小集群硬件成本高。如果集群规模较小，比如十台以下， Hadoop的硬件成本有时候会比数据库还高。这是因为Hadoop的强容错机制会把任务拆分得很细再分给不同节点机去处理，并将中间结果存储在文件系统，如此一来就会出现调度成本高且硬盘IO频繁的现象，从而导致性能降低，需要更多的机器才能达到期望的性能。而数据库主要是批量数据内存计算，性能高得多，同配置情况下单台数据库相当于数台Hadoop节点机，成本有时更低。

       管理成本高。Hadoop在小集群时硬件成本高，只有集群规模大到一定地步后才能摊低硬件成本，这也是Hadoop的核心优势：廉价横向扩展。大集群的硬件单位成本低，但昂贵的管理成本往往会抵消这种优势。比如在小规模情况下可被忽略的电费在这种场合就变成很重要了，大集群意味着庞大的节点数量，意味着巨大的电能消耗，所以数据中心常常建设在发电厂附近。另外场地费也不容忽视，大集群需要更多的机架、更大的机房、更复杂的冗余电力系统，建造成本或租金自然昂贵。最后是人力，大集群需要更多的维护管理人员才能运转，费用同样不低。

 

       总体来看，Hadoop并不是个低成本的方案，用户也不应该被硬件成本低所迷惑，而是应该根据自身的实际情况选择总成本更低的解决方案，数据库、开源或免费软件都可以在选择之列。

         在电力、场地、人力等管理成本昂贵的地区，用户可以考虑使用数据库。除了建造数据中心可以节省开支，数据库的学习成本和开发成本也比Hadoop低得多。

         如果要实时分析流式大数据，开源项目Hydra是个更好的选择，它的底层架构就是为日志类的流数据设计的，性能比Hadoop更高。

         对于中小集群而言，免费软件集算器是个更好的选择，它开发成本低，擅长业务规则较复杂的商业计算，性能比Hadoop高数倍。

         总之，我们应该谨记Hortonworks首席技术官EricBaldeschwieler关于成本的陈述：硬件成本只占Hadoop数据中心总成本的20%。