Hadoop的应用前提是”数据是有价值的!”，当然，这一点已经得到了几乎所有人的认可，并且在实际环境中，也都是这样在做的，我们都希望从系统日志，网络数据，社交信息等海量数据中发掘出有价值的信息，比如，用户的行为，习惯等，而这些是做下一步市场营销的有效决策依据。在Hadoop出现后，对于数据的发掘更是体现的淋漓尽致，尤其是从知名的互联网公司开始，都已经在使用或部署Hadoop环境。
面对如此诱惑，很多传统的企业用户都想参考互联网企业的做法，非常快速的部署Hadoop，从而快速整合和发掘既有数据的价值。但现实情况却正应了”理想很丰满，现实太骨感“那句网络流行语，想快速部署Hadoop，却没那么容易。为什么会出现这样的问题呢，我想到的原因大概有几点：
1. Hadoop提供给我们的只是一个框架，而不是一套完整的解决方案。
就像购买一套房子，建筑商交付的永远那都是一个基础结构，整体装修部分还是要靠户主自己按照自己的风格和喜好进行设计和实施，而且，每个户主对于装修部分都会有自己的定义。Hadoop的部署恰是如此，每个企业中的Hadoop环境都可以说是唯一的，需要企业用户对自己的数据环境有一个非常好的梳理和认知。我需要分析哪些数据?需要得到什么样的信息?这些信息我用来做什么?只有想明白这些问题后，Hadoop部署才会体现出它的价值。而这些，不仅仅是技术层面的问题，还要有管理层的认知甚至是业务层面的配合。
2. 人力上的问题。
Hadoop属于开源架构，而开源有它先天不足或无法解决的问题，例如，由于场景的的唯一性导致的开源架构下的开发和维护问题。Hadoop同样会面对这样的问题，而且，市场上当前Hadoop方面的人才相对比较少，这些对于企业而言，都会增加不少部署和应用上的难度。大量的开发工作需要大量的开发人员，个体的稀缺性又加重了开发方面的成本和难度。
3. 只有适合分布式架构解决的问题才可以由Hadoop解决。
Hadoop不是”仙丹”，不能解决一切数据分析问题。面向结构化的数据查询和分析，传统数据库结构还有它特有的优势。Hadoop是一个分布式架构，而分布式架构决定了其”只有适合分布式架构解决的问题才可以由Hadoop解决”。例如，一个孕妇，需要10月怀胎才会有一个baby，而不是通过10个孕妇在1个月内拥有一个baby。说到底，只有问题可以被拆分成若干子问题，且子问题是独立的，也就是可以适用用 “key-value”的迭代方式进行处理，最终可以推导出我们需要的结果。这样的问题才是Haodop可以去解决的问题。
4. Hadoop不适合处理小文件。
其实大和小只是一个相对的概念，不存在绝对值的对比，之所以说Hadoop不适合处理小文件是由HDFS中的namenode局限性决定的，每个文件都会在namenode中保存相应的元数据信息，为了提升效率，这些信息在使用的过程中都是被保存在内存中的，如果小文件很多，则会消耗大量的 namenode节点的内存，而对于单节点来讲，内存的扩展是有其上限的。反之，如果是相对较大，例如上GB或更大的文件，相对消耗的内存则会比较少。同时，在数据处理的过程中，系统开销的占比会小很多。这些架构上的特点和限制，决定了Hadoop更适合于处理“大”数据。当然在技术实现上来看，杀鸡用牛刀也是可以的，就看值不值得而已。