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

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
大数据分析系统Hadoop的13个开源工具
Hadoop是由Apache基金会开发的一个大数据分布式系统基础架构,最早版本是2003年原Yahoo!DougCutting根据Google发布的学术论文研究而来。 用户可以在不了解分布式底层细节的情况下,轻松地在Hadoop上开发和运行处理海量数据的应用程序。低成本、高可靠、高扩展、高有效、高容错等特性让Hadoop成为最流行的大数据分析系统,然而其赖以生存的HDFS和MapReduce组件却让其一度陷入困境——批处理的工作方式让其只适用于离线数据处理,在要求实时性的场景下毫无用武之地。 因此,各种基于Hadoop的工具应运而生,本次为大家分享Hadoop生态系统中最常用的13个开源工具,其中包括资源调度、流计算及各种业务针对应用场景。首先,我们看资源管理相关。 资源统一管理/调度系统 在公司和机构中,服务器往往会因为业务逻辑被拆分为多个集群,基于数据密集型的处理框架也是不断涌现,比如支持离线处理的MapReduce、支持在线处理的Storm及Impala、支持迭代计算的Spark及流处理框架S4,它们诞生于不同的实验室,并各有所长。 为了减少管理成本,提升资源的利用率,一个共同的...
- 下一篇
Spark读取压缩文件
版权声明:本文由董可伦首发于https://dongkelun.com,非商业转载请注明作者及原创出处。商业转载请联系作者本人。 https://blog.csdn.net/dkl12/article/details/80588445 我的原创地址:https://dongkelun.com/2018/05/30/sparkGZ/ 前言 本文讲如何用spark读取gz类型的压缩文件,以及如何解决我遇到的各种问题。 1、文件压缩 下面这一部分摘自Spark快速大数据分析: 在大数据工作中,我们经常需要对数据进行压缩以节省存储空间和网络传输开销。对于大多数Hadoop输出格式来说,我们可以指定一种压缩编解码器来压缩数据。 选择一个输出压缩编解码器可能会对这些数据以后的用户产生巨大影响。对于像Spark 这样的分布式系统,我们通常会尝试从多个不同机器上一起读入数据。要实现这种情况,每个工作节点都必须能够找到一条新记录的开端。有些压缩格式会使这变得不可能,而必须要单个节点来读入所有数据,这就很容易产生性能瓶颈。可以很容易地从多个节点上并行读取的格式被称为“可分割”的格式。下表列出了可用...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Mario游戏-低调大师作品
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS8安装Docker,最新的服务器搭配容器使用