Hadoop是个庞大的重型解决方案，它的设计目标本来就是大规模甚至超大规模的集群，面对的是上百甚至上千个节点，这样就会带来两个问题：
- 自动化管理管任务分配机制：这样规模的集群，显然不大可能针对每个节点提供个性化的管理控制，否则工作量会大到累死人，必须采用自动化的管理和任务分配手段，而这并不是件简单的事情。
- 强容错能力：大规模集群在某个任务执行周期内，也就是几小时之内，都有可能发生设备故障。如果没有强容错能力可能任何任务都无法执行出来。而容错同样并不容易实现，同样非常消耗计算和存储资源。
而且，Hadoop的产品线丰富，这本来是好事情，但要把这些模块都放在一个平台上运行，还要梳理好各个模块之间的相互依赖性，就需要一个包罗万象的复杂框架，这也使得Hadoop体系显得很沉重。
一
但是，很多情况下，用户的数据并不总会有那么多。除了一些互联网巨头企业和***通信运营商及银行外，大多数用户的数据量并没有大到需要几百上千个节点才能处理的地步。而且，很多用户也只是为了常规的结构化数据运算(主要也就是SQL)，用不着那么完整的产品线。
结果，我们经常看到的现象是：用户上了Hadoop，只有四个或八个节点，多的也就十来个，而且也只是安装个Hive(或别的类似解决方案)来跑跑SQL。
这就是“杀鸡用牛刀了”!
二
为什么会这样?
道理很简单。现在大数据平台是个业界趋势，而经过几年的宣传，用户都觉得传统关系数据库不再是未来的方向，即使现在还能用，但总觉得继续投资在关系数据库上就有被时代甩下的风险，于是都想去尝试新技术。但找来找去，也只有Hadoop勉强可用了，选择Hadoop变成一个政治正确的事情了。
三
那么，选用Hadoop有什么不好呢?牛刀就牛刀，牛刀也可以用来杀鸡，反正它开源不要钱，
不是这样的。虽然Hadoop软件本身是开源免费的(其实很多用户上的是商业公司的产品，本来也并不便宜)，但因为它的复杂性，想配置用好它并不容易，维护支持的成本一点也不低。Hadoop事实上是个高端产品，并不很适合数据量规模没有大到需要上百节点的中小用户。
大集群和小集群的实现技术是完全不一样的，Hadoop为了解决大集群问题而付出的努力并不是没有成本的。
四
统一的自动化管理机制固然让管理工作变简单了，但也限制了程序员的灵活性。开发人员只能去适应，难以写出适合业务和数据特征的代码，这样无法发挥机器的***效能。比如想控制HDFS的文件冗余方案，让不同文件的冗余数不同，而特定的冗余方案能有效地减少网络传输量从而提高性能。这也许能够通过修改Hadoop源码来实现，但并不轻松，而且随意修改底层源码又会影响升级。
对于小规模的集群，则没有必要采用统一管理方式，可以针对每个节点进行个性化配置，程序员也可以自由决定每个节点的计算任务和数据分布，这样可以更有效地利用硬件资源，获得***的性能，虽然会需要更细致的工作，但对于小规模集群，这增加的工作量仍然是可以接受的。
五
Hadoop投入了相当多资源来实现超强的容错，这对于大集群当然也非常必要的。比如MapReduce为了容错把任务拆得太碎，而且每次执行结果都会写盘，以保证任务过程中有节点故障时仍然可以执行下去，这会严重影响性能。而且，这种体系也难以直接控制执行次序，在编写有序有关联运算时就很困难，需要费劲去绕(这个问题以后还会再谈到)。
而对于几个到十几个节点的小集群，就不需要这么强的容错能力了。在几小时的任务周期内，整个集群所有节点都能正常工作是个大概率事件。对于小集群，我们只要保证有少数节点故障时整个集群还能继续工作以接受新任务，而让当前正在执行的任务失败也是可以容忍的，毕竟这并不会经常发生。
六
复杂的框架本身也会消耗很多资源。小集群本来就没有几个节点，还要把有限的资源花费在这些不实际计算的事情上，显然是不划算的。在目标任务类型较为单一时，应当选择更适合的框架，没必要去追求大而全的东西。
“牛刀”应当去做它适合做的事，也就数据量大但运算简单的任务，用俗话说就是“傻大笨粗”。真到了几百个节点的集群，那还只有Hadoop能做了，而精细的活儿真不合适它来干。
七
对于小集群，我们需要更轻量级的大数据解决方案。
大数据的技术本质是高性能，而提高性能的需求无处不在，并不是只有那种规模的大数据。比即时查询设计的数据量就不会也不可能太大(否则不可能即时)，这种场景会要求有很好的集成性，但Hadoop基本上不可能被嵌到应用程序里面，它只能在边上作为一个数据源工作;有些临时性数据处理时需要随时使用，也不可能再为之专门建设大数据平台，比如为了处理一批日志而搭建一个Hadoop，等环境搭好时任务已经过期了。
