关于
Hadoop
的五个常见问题
(本文译自
Cloudera
公司
Christophe Bisciglia的一篇博客
,我做了一些调整和注释)
最近关于
Hadoop
有很多各种各样的传言,几天前,
Yahoo
的一些朋友声称
Google
的
Terasort
记录用的也是
Hadoop, Facebook
的人也声明他们的
2.5 Petabyte
的“
Hadoop Powered Data Warehouse”
一天能吞下
15 Terabytes
的数据。
但是很多人还是弄不清楚这些工作时怎么做到的,以及这些东西对他们来说意义何在。在我们与客户一起工作时、在大会上发言时、对
Hadoop
的新用户做培训时,我们碰到了一些同样的问题。如果你,或者你的朋友,对
Hadoop
感兴趣,希望这个帖子对你有些帮助。
介绍:扔掉这些基本的假设
Google
每天都在吞下并处理整个互联网,开始的时候,没有一个系统可以用来完成这个任务。处理如此大规模的数据的需求在以前是从来没有遇到过的,它是随着互联网的发展而出现的。然而到了今天,很多行业都有类似的处理海量数据的需求
(
注:运营商业务支撑的数据压力就是一个例子
)
。
为了可靠地存储和处理
Peta
级数据,
Google
从底层开始建造了自己的系统。
传统的
IT
系统设计是以一些假设为依据的。我们中的很多人所接受过的培训,或者所处的环境,让我们接受、认可了这些假设。而
Hadoop
却扔掉了这些假设,如果你也能把这些假设条件放到一边,你对
Hadoop
的威力的理解就又进了一步。
假设一:硬件可以是很可靠的
你可以花很多钱去采购平均初次故障时间(
Mean Time to Failure,
简称
MTTF
)长于其期望寿命
(Expected Lifespan)
的硬件设备,但是,别忘了要处理互联网级的数据需要数以千计的磁盘和服务器(注:运营商的业务数据应该也是这种规模吧
),在这种情况下,即便你用的
MTTF
达到
4
年的设备,在一个拥有
1000
个节点的集群中,每一周就会发生近
5
次故障。考虑到成本因素而采用
MTTF
为
2
年的设备的话,每周的故障次数将达到近
10
次。这两种由硬件引起的系统故障问题是无法避免的,无论是那种情况,都需要从根本上对系统容错能力进行重新思考。为了提供超大规模的可靠存储和计算,系统容错问题必须采用软件的方式来解决。当这一点得到实现后,“可靠硬件”的市场也就不复存在了。
假设二:
机器可以唯一识别
一旦你接受所有硬件机器早晚都会出故障,你就需求停止尝试用唯一识别号去定位单个机器,否则不久你就会发现,你正在尝试定位一个不再存在的设备。当你尝试用很多机器来完成一个任务时,这些机器之间必须能够彼此通讯,这是显而易见的,然而,要想高效的处理不可靠硬件设备之间的通讯,通讯必须以“隐式”的方式处理(注:所谓机器间的“隐式通讯”,就是说不必给各个机器唯一识别
),不能依赖于“机器
X
发送数据
Y
给机器
Z
”的模式,而应该是“一些机器说其它一些机器必须处理一些数据
Y
”。在大规模部署的场景中,“显示通讯”所面临的识别验证困难不比数据处理困难小。“显示通讯”到“隐式通讯”的转变,使得底层软件系统可以高可靠地存储和处理数据,而不要求程序员验证单个通讯是否成功,重要的是,这样做是非常容易出错的。
假设三:单个机器可以存储一个数据集
当我们处理大数据时,会面临单台机器的存储和处理能力无法满足大数据集的容量要求的情况。要解决这个问题,需要改变我们对数据如何存储和被处理的假定条件。一个大数据集可以被分割为若干的“数据片”,这些“数据片”在多台机器上分布存储和计算。集群中的计算机每台都存储一个数据集的一小片,那么,每台机器就可以从本地硬盘上读取任何数据集的一部分进行处理。当这些机器并行运行时,就实现了把计算推向数据,而不是把数据推向计算,因此也就节省了宝贵的带宽资源。
“
Shared Nothing
”架构原则是如何让
Hadoop
在不可靠的低端硬件上提供可靠地计算基础结构,在扔掉这三个假设后,也就很好理解了。
在解决了上述问题后,我们来看看一些经常听到的问题
Hadoop
是用来替换数据库或者其它已经存在的系统吗?
不。
Hadoop
不是一个数据库,它也不需要替换任何已经存在的数据系统。
Hadoop
是一个海量数据存储和批量数据处理系统。它提供一个可在低端硬件设备上横向伸缩的集成的存储和计算网格,并通过软件来提供容错能力。
Hadoop
不替换已有系统,而是增强它们的处理能力。
一方面,
Hadoop
从已有系统上接手一些高压力问题来使得已有系统可以专注处理其设计用来做的事情,比如事实交易数据处理或者交互式商业智能。这些高压力问题包括但不限于:同步数据吞吐、处理、交换大尺寸数据等。另一方面,
Hadoop
可以从任意多的数据源来吞入任何类型的数据,可以使结构化数据,也可以不是。来自多个数据源的数据可以按任何所需的方式来进行合并或者聚合,从而可以实现任一单一系统均无法处理的深度数据分析。还有,处理的结果可以被传递到任意已有的与
Hadoop
无关的企业系统中做进一步处理。
举一个例子,假设我们有一个
RDBMS
系统,用来处理实时数据、保证交易过程中的数据一致性。如果我们要求同一个数据库系统从大容量数据中生成复杂的分析报表显然是不合适的。因为对大容量数据进行分析加工非常消耗计算资源,降低系统性能,降低了其处理本职工作的能力。
Hadoop
被设计用来存储海量数据、按任意方式处理海量数据、以及按需向任意系统传递数据。数据可以经常性地从
RDBMS
系统导出到
Hadoop
中,
RDBMS
系统可以经过调整,专门用来处理交互式任务,而复杂的分析工作就可以按离线的方式交由
Hadoop
来完成,对实施系统没有任何影响。
(注:
Hadoop
可以吞入任何数据源的任何数据,也可以按任意方式向外部系统传递数据,意味着
Hadoop
可以用来备份业务系统的全局全量数据
)
MapReduce
和
Hadoop
以及其他系统的关系是什么?
Hadoop
是
Google
开发的用来支持互联网级数据处理的
MapReduce
编程模型和底层文件系统
GFS
的开源实现。
在高可靠性要求极高的超大规模计算环境中,
MapReduce
建立了一个清晰地抽象层,解决大规模数据分析任务和底层的系统支撑能力之间的存在的矛盾和挑战。使用
MapReduce
模型,可以非常容易地实现并行数据处理任务,程序员不必考虑诸如同步、并发、硬件失败等底层系统细节。
RDBMS
的索引、关系以及事务处理等系统开销会限制系统的横向伸缩性,降低半结构化、非结构化数据的载入和批处理效率,而且在批处理任务中是用不到的,所以,
Google
刻意舍弃了索引、关系以及事务处理等
RDBMS
特性,从一开始就没有选择
RDBMS
,而是按照“
Shared Nothing
”架构原则,从底层开始设计了一个全新的分布式文件系统。
有些
RDBMS
系统也能提供
MapReduce
功能,允许程序员方便的创建比
SQL
更加有表达力的查询,而且不会给数据库系统本身带来额外的伸缩性限制。
MapReduce
自身并不关心
RDBMS
自身的横向伸缩性挑战。
如果你需要索引,关系和事务保障,就要用到数据库;如果你需要用到数据库,一个支持
MapReduce
的数据库就比一个不支持
MapReduce
的数据库能提供更有表达力的查询。
如果你的基本需求是一个高伸缩性的存储和批数据处理系统,你就会发现
Hadoop
是一个可以在低端硬件设备商高效地、低价地提供数据存储和处理的系统。
已有系统如何与
Hadoop
交互?
由于
Hadoop
允许以低成本的方式高效存储数据,并且其后可以以任意方式处理数据,所以,
Hadoop
经常会被当做多种数据源的数据池。因为
Hadoop
不处理索引和关系,所以在
Hadoop
中存储数据的时候,就不用考虑将来如何分析这些数据。
接下来,我们看一下各种系统如何将数据送到
Hadoop
中。
数据库:
Hadoop
本身就支持通过
JDBC
从数据库中抽取数据。大部分数据库系统有批量导出、导入功能。无论是那种情况,将整个数据库中的数据经常性地、或者以增量的方式导入到
Hadoop
中来都是很容易的。这样做的同时你会发现,由于数据库系统存储的数据减少,数据库系统的软件授权成本也会得到降低。
日志生成器:
Web
服务器或者传感器系统往往会生成大量的日志数据,有些日志的生成频度甚至超出预料。这些日志记录通常是半结构化的,而且随着时间经常变化。
由于这些数据与关系型数据库并不能很好的匹配,而且在单一机器上需要很长的时间进行处理,所以,对日志信息的处理往往比较困难。
Hadoop
使得从任意数量的系统中可靠地将大量日志信息存到一个中央存储中用于后续分析变得非常容易。
科学设备:
随着传感器技术的发展,很多科学设备,象图像处理系统(医疗、卫星等),
DNS
测序设备,高能物理探测设备等所要求的数据生成频率和数据写入速度都往往会超出单个硬盘的能力。这些系统可以直接将数据写入到
Hadoop
中来,随着数据采样频度和数据量的不断提升,只需简单地向
Hadoop
集群添加更多的低端设备就可以满足这些应用的需求。
Hadoop
对所存入数据的类型是“不可知”的。它将数据打散到可管理的数据块中,这些数据块被复制并分发到集群中的各个节点上,接下来,就可以使用
MapReduce
处理所有的数据,最终的结果、汇总、报表可以按原始文件、
JDBC
或者定制化的连接器方式导出到其它系统中。
组织中的各类用户如何使用
Hadoop?
Hadoop
的一个亮点是它可以同时将海量数据呈现给组织中的所有人。它帮助形成一种“数据文化”,增强了组织中各层次人员使用数据来做出更好地商业决策的能力。
当
DBA
设计和优化数据库时,需要考虑到系统的方方面面。首先就是数据的结构,数据的访问模式,以及数据的视图、报表等。这些前置要求限制了数据库的查询类型。既要满足数据库的性能要求,又要满足业务人员不断提出的新的数据视图类型,这的确是一个挑战。使用
Hadoop, DBA
可以优化数据库系统用户处理核心工作,而把数据导出到
Hadoop
中进行分析处理。
对程序员来说,一旦数据放到
Hadoop
中,他们就可以轻松地创建更富表达力的查询,而不影响生产系统的效率。程序员可以使用
Hadoop
来建立包括研发系统和业务系统在内的多个数据源的数据管道。
通过提供高层次的界面,即便是对技术不怎么了解到业务人员,包括产品经理、分析师、或者管理层等,都可以快速地或者点对点地使用企业中的任意数据。比如,
Hive
是一个基于
Hadoop
并提供
SQL
界面的数据仓库系统,
Pig
则提供一个高层语言,可用于单点分析。
使用
Hadoop
的成本怎样测算?
Hadoop
的成本预算非常简单,它运行在简单的低成本设备上,并已经被证实可以处理数十
Peta
的数据,更重要的是,实现如此规模的数据存储和处理能力时,它的性能和成本是线性的。
例如,使用一个具有两个四核
CPU
(共八核),
4
个
1TB SATA
硬盘的机器,至于使用
8G
还是
16G
内存依赖于你的预算和工作负载。由于
Hadoop
是三重复制的,所以实际可用的容量大约是原始硬盘容量的三分之一,对一个拥有
4TB
存储的磁盘来说,
1TB
的实际可用空间是一个合理的推算。
同时考虑到初始数据量的大小,数据量的增长率,以及每实际可用
TB
存储的成本,就可以很容易地测算出整个
Hadoop
集群的成本。当然,运营成本也是要考虑的,但是,由于所有机器上的软件都是一样的,并且很少需要做单机的性能调整,所以,运营成本只会小幅度线性增长。
原文链接http://blog.sina.com.cn/s/blog_5ce0e3b60100eqly.html
- 大小: 15.8 KB
分享到:
相关推荐
Hadoop使用常见问题以及解决方法,简单实用
安装hadoop的时候或者使用的时候,会出现hadoop常见问题及解决方法
Hadoop使用常见问题以及解决方法.doc Hadoop使用常见问题以及解决方法.doc
在网上搜集的以及本人自己总结的hadoop集群常见问题及解决办法,融合了网上常常搜到的一些文档以及个人自己的经验。
(完整版)hadoop常见笔试题答案.docx(完整版)hadoop常见笔试题答案.docx(完整版)hadoop常见笔试题答案.docx(完整版)hadoop常见笔试题答案.docx(完整版)hadoop常见笔试题答案.docx(完整版)hadoop常见笔试题答案.docx...
windows下hadoop2.7.3环境问题的解决,亲测win10、win7皆可使用
本书结合丰富的案例来展示如何用hadoop解决特殊问题,它将帮助您: ·使用hadoop分布式文件系统(hdfs)来存储海量数据集, 通过mapreduce对这些数据集运行分布式计算 ·熟悉hadoop的数据和ilo构件,用于压缩...
Hadoop、hive、hbase常见面试题!!! Hadoop、hive、hbase常见面试题!!! Hadoop、hive、hbase常见面试题!!! Hadoop、hive、hbase常见面试题!!!
Hadoop大数据常见面试题库
Hadoop安装及常见异常处理,记录了在Hadoop安装中可能出现的几类常见异常及其解决方案
Hadoop大数据平台安全问题和解决方案的综述,可以从这里学习到处理问题的思路。
hadoop学习常见问题(手动整理)
Hadoop常见异常,以及hadoop配置,等资料
从作者自己的经验出发,整理了hadoop应用的一些误区和经验
Hadoop快速入门和常见问题相关资料都在这里面包含了,自己觉得很有用就拿来和大家分享了,
NULL 博文链接:https://shirley-ren.iteye.com/blog/1174622
Hadoop大数据平台安全问题和解决方案的综述
hadoop文档常见问题,可以解决hadoop常见的一系列问题
Hadoop大数据常见问题及处理方法,使用 hive 自带的 concatenate 命令,自动合并小文件
Hadoop常见的45个面试题