作者：蒋步星
来源：数据蒋堂
本文共1800字，建议阅读6分钟。
通过本文为大家解读为什么Hadoop不适合小集群实现。
Hadoop是个庞大的重型解决方案，它的设计目标本来就是大规模甚至超大规模的集群，面对的是上百甚至上千个节点，这样就会带来两个问题：
自动化管理管任务分配机制：这样规模的集群，显然不大可能针对每个节点提供个性化的管理控制，否则工作量会大到累死人，必须采用自动化的管理和任务分配手段，而这并不是件简单的事情。
强容错能力：大规模集群在某个任务执行周期内，也就是几小时之内，都有可能发生设备故障。如果没有强容错能力可能任何任务都无法执行出来。而容错同样并不容易实现，同样非常消耗计算和存储资源。
而且，Hadoop的产品线丰富，这本来是好事情，但要把这些模块都放在一个平台上运行，还要梳理好各个模块之间的相互依赖性，就需要一个包罗万象的复杂框架，这也使得Hadoop体系显得很沉重。
但是，很多情况下，用户的数据并不总会有那么多。除了一些互联网巨头企业和国家级通信运营商及银行外，大多数用户的数据量并没有大到需要几百上千个节点才能处理的地步。而且，很多用户也只是为了常规的结构化数据运算（主要也就是SQL），用不着那么完整的产品线。
结果，我们经常看到的现象是：用户上了Hadoop，只有四个或八个节点，多的也就十来个，而且也只是安装个Hive（或别的类似解决方案）来跑跑SQL。
这就是“杀鸡用牛刀了”！
为什么会这样？
道理很简单。现在大数据平台是个业界趋势，而经过几年的宣传，用户都觉得传统关系数据库不再是未来的方向，即使现在还能用，但总觉得继续投资在关系数据库上就有被时代甩下的风险，于是都想去尝试新技术。但找来找去，也只有Hadoop勉强可用了，选择Hadoop变成一个政治正确的事情了。
那么，选用Hadoop有什么不好呢？牛刀就牛刀，牛刀也可以用来杀鸡，反正它开源不要钱，
不是这样的。虽然Hadoop软件本身是开源免费的（其实很多用户上的是商业公司的产品，本来也并不便宜），但因为它的复杂性，想配置用好它并不容易，维护支持的成本一点也不低。Hadoop事实上是个高端产品，并不很适合数据量规模没有大到需要上百节点的中小用户。
大集群和小集群的实现技术是完全不一样的，Hadoop为了解决大集群问题而付出的努力并不是没有成本的。
统一的自动化管理机制固然让管理工作变简单了，但也限制了程序员的灵活性。开发人员只能去适应，难以写出适合业务和数据特征的代码，这样无法发挥机器的最大效能。比如想控制HDFS的文件冗余方案，让不同文件的冗余数不同，而特定的冗余方案能有效地减少网络传输量从而提高性能。这也许能够通过修改Hadoop源码来实现，但并不轻松，而且随意修改底层源码又会影响升级。
对于小规模的集群，则没有必要采用统一管理方式，可以针对每个节点进行个性化配置，程序员也可以自由决定每个节点的计算任务和数据分布，这样可以更有效地利用硬件资源，获得最高的性能，虽然会需要更细致的工作，但对于小规模集群，这增加的工作量仍然是可以接受的。
Hadoop投入了相当多资源来实现超强的容错，这对于大集群当然也非常必要的。比如MapReduce为了容错把任务拆得太碎，而且每次执行结果都会写盘，以保证任务过程中有节点故障时仍然可以执行下去，这会严重影响性能。而且，这种体系也难以直接控制执行次序，在编写有序有关联运算时就很困难，需要费劲去绕（这个问题以后还会再谈到）。
而对于几个到十几个节点的小集群，就不需要这么强的容错能力了。在几小时的任务周期内，整个集群所有节点都能正常工作是个大概率事件。对于小集群，我们只要保证有少数节点故障时整个集群还能继续工作以接受新任务，而让当前正在执行的任务失败也是可以容忍的，毕竟这并不会经常发生。
复杂的框架本身也会消耗很多资源。小集群本来就没有几个节点，还要把有限的资源花费在这些不实际计算的事情上，显然是不划算的。在目标任务类型较为单一时，应当选择更适合的框架，没必要去追求大而全的东西。
“牛刀”应当去做它适合做的事，也就数据量大但运算简单的任务，用俗话说就是“傻大笨粗”。真到了几百个节点的集群，那还只有Hadoop能做了，而精细的活儿真不合适它来干。
对于小集群，我们需要更轻量级的大数据解决方案。
大数据的技术本质是高性能，而提高性能的需求无处不在，并不是只有那种规模的大数据。比如即时查询设计的数据量就不会也不可能太大（否则不可能即时），这种场景会要求有很好的集成性，但Hadoop基本上不可能被嵌到应用程序里面，它只能在边上作为一个数据源工作；有些临时性数据处理时需要随时使用，也不可能再为之专门建设大数据平台，比如为了处理一批日志而搭建一个Hadoop，等环境搭好时任务已经过期了。
专栏作者简介
润乾软件创始人、首席科学家
清华大学计算机硕士，著有《非线性报表模型原理》等，1989年，中国首个国际奥林匹克数学竞赛团体冠军成员，个人金牌；2000年，创立润乾公司；2004年，首次在润乾报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准；2014年，经过7年开发，润乾软件发布不依赖关系代数模型的计算引擎——集算器，有效地提高了复杂结构化大数据计算的开发和运算效率；2015年，润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”；2016年，荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业十大领军人物”；2017年, 自主创新研发新一代的数据仓库、云数据库等产品即将面世。
数据蒋堂
《数据蒋堂》的作者蒋步星，从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞，虚拟与现实的相互交织，产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点，站在研发人员的角度从浅入深，进行全方位、360度无死角深度剖析；对于一些业内观点，站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展，站在业内专家角度给予预测和推断。静下心来认真研读你会发现，《数据蒋堂》的文章，有的会让用户避免重复前人走过的弯路，有的会让攻城狮面对扎心的难题茅塞顿开，有的会为初入行业的读者提供一把开启数据世界的钥匙，有的甚至会让业内专家大跌眼镜，产生思想交锋。
往期回顾：
数据蒋堂 | 常规遍历语法
校对： 洪舒越
为保证发文质量、树立口碑，数据派现设立“错别字基金”，鼓励读者积极纠错。
若您在阅读文章过程中发现任何错误，请在文末留言，或到后台反馈，经小编确认后，数据派将向检举读者发8.8元红包。
同一位读者指出同一篇文章多处错误，奖金不变。不同读者指出同一处错误，奖励第一位读者。
感谢一直以来您的关注和支持，希望您能够监督数据派产出更加高质的内容。
97
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
