大数据 Hadoop:一把杀鸡用的宰牛刀

Hadoop是个庞大的重型解决方案,它的设计目标本来就是大规模甚至超大规模的集群,面对的是上百甚至上千个节点,这样就会带来两个问题:

自动化管理管任务分配机制:这样规模的集群,显然不大可能针对每个节点提供个性化的管理控制,否则工作量会大到累死人,必须采用自动化的管理和任务分配手段,而这并不是件简单的事情。

强容错能力:大规模集群在某个任务执行周期内,也就是几小时之内,都有可能发生设备故障。如果没有强容错能力可能任何任务都无法执行出来。而容错同样并不容易实现,同样非常消耗计算和存储资源。

而且,Hadoop的产品线丰富,这本来是好事情,但要把这些模块都放在一个平台上运行,还要梳理好各个模块之间的相互依赖性,就需要一个包罗万象的复杂框架,这也使得Hadoop体系显得很沉重。

但是,很多情况下,用户的数据并不总会有那么多。除了一些互联网巨头企业和国家级通信运营商及银行外,大多数用户的数据量并没有大到需要几百上千个节点才能处理的地步。而且,很多用户也只是为了常规的结构化数据运算(主要也就是SQL),用不着那么完整的产品线。

结果,我们经常看到的现象是:用户上了Hadoop,只有四个或八个节点,多的也就十来个,而且也只是安装个Hive(或别的类似解决方案)来跑跑SQL。

这就是“杀鸡用牛刀了”!

为什么会这样?

道理很简单。现在大数据平台是个业界趋势,而经过几年的宣传,用户都觉得传统关系数据库不再是未来的方向,即使现在还能用,但总觉得继续投资在关系数据库上就有被时代甩下的风险,于是都想去尝试新技术。但找来找去,也只有Hadoop勉强可用了,选择Hadoop变成一个政治正确的事情了。

那么,选用Hadoop有什么不好呢?牛刀就牛刀,牛刀也可以用来杀鸡,反正它开源不要钱,

不是这样的。虽然Hadoop软件本身是开源免费的(其实很多用户上的是商业公司的产品,本来也并不便宜),但因为它的复杂性,想配置用好它并不容易,维护支持的成本一点也不低。Hadoop事实上是个高端产品,并不很适合数据量规模没有大到需要上百节点的中小用户。

大集群和小集群的实现技术是完全不一样的,Hadoop为了解决大集群问题而付出的努力并不是没有成本的。

统一的自动化管理机制固然让管理工作变简单了,但也限制了程序员的灵活性。开发人员只能去适应,难以写出适合业务和数据特征的代码,这样无法发挥机器的最大效能。比如想控制HDFS的文件冗余方案,让不同文件的冗余数不同,而特定的冗余方案能有效地减少网络传输量从而提高性能。这也许能够通过修改Hadoop源码来实现,但并不轻松,而且随意修改底层源码又会影响升级。

对于小规模的集群,则没有必要采用统一管理方式,可以针对每个节点进行个性化配置,程序员也可以自由决定每个节点的计算任务和数据分布,这样可以更有效地利用硬件资源,获得最高的性能,虽然会需要更细致的工作,但对于小规模集群,这增加的工作量仍然是可以接受的。

Hadoop投入了相当多资源来实现超强的容错,这对于大集群当然也非常必要的。比如MapReduce为了容错把任务拆得太碎,而且每次执行结果都会写盘,以保证任务过程中有节点故障时仍然可以执行下去,这会严重影响性能。而且,这种体系也难以直接控制执行次序,在编写有序有关联运算时就很困难,需要费劲去绕(这个问题以后还会再谈到)。

而对于几个到十几个节点的小集群,就不需要这么强的容错能力了。在几小时的任务周期内,整个集群所有节点都能正常工作是个大概率事件。对于小集群,我们只要保证有少数节点故障时整个集群还能继续工作以接受新任务,而让当前正在执行的任务失败也是可以容忍的,毕竟这并不会经常发生。

复杂的框架本身也会消耗很多资源。小集群本来就没有几个节点,还要把有限的资源花费在这些不实际计算的事情上,显然是不划算的。在目标任务类型较为单一时,应当选择更适合的框架,没必要去追求大而全的东西。

“牛刀”应当去做它适合做的事,也就数据量大但运算简单的任务,用俗话说就是“傻大笨粗”。真到了几百个节点的集群,那还只有Hadoop能做了,而精细的活儿真不合适它来干。

对于小集群,我们需要更轻量级的大数据解决方案。

大数据的技术本质是高性能,而提高性能的需求无处不在,并不是只有那种规模的大数据。比即时查询设计的数据量就不会也不可能太大(否则不可能即时),这种场景会要求有很好的集成性,但Hadoop基本上不可能被嵌到应用程序里面,它只能在边上作为一个数据源工作;有些临时性数据处理时需要随时使用,也不可能再为之专门建设大数据平台,比如为了处理一批日志而搭建一个Hadoop,等环境搭好时任务已经过期了。

有一句话叫做三人行必有我师,其实做为一个开发者,有一个学习的氛围跟一个交流圈子特别重要这是一个我的大数据交流学习群531629188不管你是小白还是大牛欢迎入驻,正在求职的也可以加入,大家一起交流学习,话糙理不糙,互相学习,共同进步,一起加油吧。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏BestSDK

听云SDK发布《2017中国云计算评测报告》,一文读懂所有云服务的优劣势

听云发布《2017中国云计算评测报告》,本次报告从用户视角出发,对各家云服务提供商的综合用户体验、性能与可用性以及服务与易用性这三个方面进行了盘点,凸显出各家云...

4156
来自专栏程序人生

Service performance 101

最近一个月,我和一小撮不专业的美国银行从业人员就「我是不是清白地像于谦那样」(写石灰吟的于谦,不是有三大爱好的那位)反复拉锯,又赶上一大波功能上线和融资相关的事...

34214
来自专栏SDNLAB

SDN技术分享(十):GoogleFiber的宽带接入速率控制解决方案

本次分(zhuang)享(bi)呢,主要探讨一个新兴SP客户的案例。 G家,这是非传统的SP。我们一起来看一下G家的市场策略以及使用的关键技术. 内容比较多,我...

48113
来自专栏魏艾斯博客www.vpsss.net

搬瓦工香港机房 40G 套餐下架 目前最便宜套餐$39.9/月

盼望着搬瓦工补货,却收到了搬瓦工香港机房 40G 套餐下架的消息,真的是太让人失望啊。本来这款 40G 套餐已经缺货很久了,现在干脆被下架了估计以后也很难再有了...

1891
来自专栏鹅厂优文

鹅厂优文 | Cocos微信小游戏开发

微信小游戏终于准备对外开放了,有兴趣的独立游戏创作人终于有新的天地可以开辟了。

2.2K15
来自专栏SDNLAB

SDN初创公司Lumina将BGP/MPLS融入白盒交换机

1834
来自专栏大数据和云计算技术

数据库存储模型简述

数据库现在应该是无人不知,无人不晓,讲到数据库必然要提到两个人: 1、一个是E.F. Codd,这个是理论的开创者,来瞻仰下: ? 埃德加·弗兰克·科德(Ed...

4215
来自专栏知晓程序

鹅厂美女工程师来告诉你,小程序码是如何「绽放」的 | 晓组织 #20

腾讯 CDC 全称为「用户研究与体验设计中心」,是腾讯公司级设计团队,致力于提升腾讯产品的用户体验,探索互联网生态体验创新。

1382
来自专栏数据和云

电信核心系统去小型机化-去“I”

去“IOE”是一个甚嚣尘上的话题,在经年的渲染之后,很多企业都在以各自的方式在进行演绎。 云和恩墨最近帮助用户实施了一个重要的“去I”项目,引用恩墨一线负责人...

2573
来自专栏企鹅号快讯

OpenContrail 移交 Linux 基金会、TensorFlow 曝安全风险……

导读 本周开源云业内倒是出现一些比较有趣的消息。首先是Deepo项目在GitHub上的爆红。小编简单了解了一下该项目,用“强大”来形容并不为过,其不但能实现快速...

2115

扫码关注云+社区

领取腾讯云代金券