关于Hadoop的五个常见问题

关于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集群的成本。当然，运营成本也是要考虑的，但是，由于所有机器上的软件都是一样的，并且很少需要做单机的性能调整，所以，运营成本只会小幅度线性增长。