Hadoop简介

谁借莪１个温暖的怀抱￠ 2022-06-16 14:42 193阅读 0赞

**Hadoop的概要介绍**

Hadoop，是一个分布式系统基础架构，由Apache基金会开发。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力高速运算和存储。

简单地说来，Hadoop是一个可以更容易开发和运行处理大规模数据的软件平台。该平台使用的是面向对象编程语言Java实现的，具有良好的可移植性。

**Hadoop的发展历史**

Hadoop是Doug Cutting（Apache Lucene创始人）开发的使用广泛的文本搜索库。Hadoop起源于Apache Nutch，后者是一个开源的网络搜索引擎，本身也是由Lucene项目的一部分。那么我们接下来就先来看一下Nutch的一些发展状况，使得我们对Hadoop的前身有更多的了解。

Nutch项目开始于2002年，一个可工作的抓取工具和搜索系统很快浮出水面。但开发人员很快就意识到，他们的这个架构将无法扩展到拥有数十亿网页的网络。在2003年发表的一篇描述Google分布式文件系统(Google File System，简称GFS)的论文为他们提供了及时的帮助，文中称Google正在使用此文件系统。 GFS或类似的东西，可以解决他们在网络抓取和索引过程中产生的大量的文件的存储需求。具体而言，GFS会省掉管理所花的时间，如管理存储节点。在2004年，他们开始开发一个开放源码的应用，即Nutch的分布式文件系统(NDFS)，也就是后来耳熟能详的HDFS的前身。

2004年，Google又发表了一篇论文，向全世界介绍了MapReduce这一伟大的科技成果。 2005年初，Nutch的开发者们又在Nutch上增加了一个可工作的MapReduce应用，到当年的年中，所有主要的Nutch算法被移植到使用MapReduce和NDFS来运行。

Nutch中的NDFS和MapReduce实现的应用远不只是搜索领域，在2006年2月，他们从Nutch转移出来成为一个独立的Lucene子项目，就是现在流行的开源云计算平台Hadoop。大约在同一时间，Doug Cutting加入雅虎，Yahoo提供一个专门的团队和资源将Hadoop发展成一个可在网络上运行的系统。在2008年2月，雅虎宣布其搜索引擎产品部署在一个拥有1万个内核的Hadoop集群上。至此以后，Hadoop这个词在业界迅速升温，当大家提到云计算的时候就自然而然的想起这个词。

那么，接下来让我见识一下Hadoop这个分布式计算框架的威力吧！2008年4月，Hadoop打破世界纪录，成为最快排序1TB数据的系统。运行在一个910节点的群集，Hadoop在209秒内排序了1 TB的数据(还不到三分半钟)，击败了前一年的297秒冠军。同年11月，谷歌在报告中声称，它的MapReduce实现执行1TB数据的排序只用了68秒。 在2009年5月，有报道宣称Yahoo的团队使用Hadoop集群对1 TB的数据进行排序只花了62秒时间。就这样，奇迹一点一滴的在被它不断地创造出来~

**Hadoop的关键技术**

可以说，Hadoop发展到今天的地步，在很大程度上得益于Google的分布式集群的启发。Google的数据中心使用廉价的Linux PC机组成集群，在上面运行各种应用。即使是分布式开发的新手也可以迅速使用Google的基础设施。核心组件有3个：

1、GFS（Google File System）。一个分布式文件系统，隐藏下层负载均衡，冗余复制等细节，对上层程序提供一个统一的文件系统API接口。Google根据自己的需求对它进行了特别优化，包括：超大文件的访问，读操作比例远超过写操作，PC机极易发生故障造成节点失效等。GFS把文件分成64MB的块，分布在集群的机器上，使用Linux的文件系统存放。同时每块文件至少有3份以上的冗余。中心是一个Master节点，根据文件索引，找寻文件块。详见Google的工程师发布的GFS论文。

2、MapReduce。Google发现大多数分布式运算可以抽象为MapReduce操作。Map是把输入Input分解成中间的Key/Value对，Reduce把Key/Value合成最终输出Output。这两个函数由程序员提供给系统，下层设施把Map和Reduce操作分布在集群上运行，并把结果存储在GFS上。

3、BigTable。一个大型的分布式数据库，这个数据库不是关系式的数据库。像它的名字一样，就是一个巨大的表格，用来存储结构化的数据。

以上三个设施Google均有论文发表。正是因为有了以上的三项核心技术，才使得Google的分布式框架很有创造性、扩展性，而且在系统吞吐量上有很大的竞争力。

结合上面讲的一些背景，再来看一下Hadoop这个架构的核心技术吧！

主要是由HDFS、MapReduce和Hbase组成。HDFS是Google File System（GFS）的开源实现。MapReduce是Google MapReduce的开源实现。HBase是Google BigTable的开源实现。这里就不多说了，具体的每个核心技术的原理会在后续的文章里面一点一点的介绍，毕竟也是刚开始学，边学边成长吧！

**Hadoop的一些特点**

1、 扩容能力（Scalable）：能可靠地（reliably）存储和处理千兆字节（PB）数据。在不保证低延时的前提下，具有相当大的吞吐量，非常适合海量数据的运算。

2、 成本低（Economical）：可以通过普通机器组成的服务器群来分发以及处理数据。这些服务器群总计可达数千个节点。而且每个节点都是运行在开源操作系统Linux上面的。

3、 高效率（Efficient）：通过分发数据，hadoop可以在数据所在的节点上并行地（parallel）处理它们，这使得处理非常的快速。

4、 可靠性（Reliable）：hadoop能自动地维护数据的多份复制，并且在任务失败后能自动地重新部署（redeploy）计算任务。

**Hadoop的不足之处**

1、 该框架设计的初衷是针对海量数据的运算处理的问题。因此对于一些数据量很小的处理没有任何优势可言，甚至还不如单机串行的效果，性能也完全体现不出来。

2、 既然是海量数据的处理，优先考虑的是该系统的吞吐量等性能问题。所以也很难满足平常的低时延的需求，这点是不可避免的，只能说想办法尽量去权衡两者，进而优化。

3、 集群中存在大量的机器，所以节点故障是不可避免的。在Hadoop中有两种类型的结点：namenode和datanode。Hadoop集群采取的master/slave结构，分别对应namenode和datanode两种类型。Datanode故障一般是不会影响整个系统的，这个和它的存储策略有关。但是namenode故障是是极大的问题，如果namenode挂掉了，那问题就很严重。而且namenode的内存限制也是整个系统的瓶颈，这个在这里就不多说，后面随着慢慢的了解就知道了。

4、 其文件系统设计的前提是一次写入多次读取的情况，因此我们是无法修改某条详细的数据，只能overwrite全部的数据，或者是在文件末尾追加数据。

5、 集群内部是通过tcp/ip协议进行通信的，所以网络带宽也会成为系统的瓶颈之一。

6、 系统内部的调度策略。在使用了Hadoop一段时间之后，感觉它的job调度策略不是很完善，没能充分利用集群资源展现出其全部的性能。

7、 采用Java实现。Java的IO处理虽然没有性能瓶颈，但是对于CPU密集型的任务是一个噩耗。这点可以通过对比HBase和Hypertable两个开源的Bigtable实现来做初步的验证。

8、 开源项目。开源本身是一柄双刃剑，它方便了大多数人，但是对于一个有一定规模的公司，项目发展方向的把握，技术保密和支持等都是采用Hadoop这种开源项目必须考虑的问题。另外，Hadoop作为一个比较新的项目，性能和稳定性的提升还需要一定时间。

9、安全问题。如果对外提供服务就要对外开放端口，那就有可能成为被攻击的目标，所以这个问题在以后的商业应用中显得尤为重要。虽然并不清楚Hadoop的安全程度到底如何，但是这个是没有止境的。道高一尺，魔高一丈。

10、任然使用的是行存储。从相关资料上了解到列存储在海量数据处理方面的优势，觉得未来在这方面会有所改变。

**Hadoop的发展前景**

我本人以前其实从来没接触过分布式计算这一块，偶然的一个机会来到淘宝的数据平台实习，才知道有这么个强大的东西存在。虽然它只是一个开源的项目，并不是很成熟。但是有这么多的强人在不断地做贡献，另外还有很多互联网巨头投入了巨大的人力物力来开发。

我个人还是很看好这个分布式计算平台未来的前景。而且很多大公司也在使用Hadoop，像国内的淘宝、百度、腾讯，国外的雅虎、亚马逊、Facebook等。事实证明这个分布式平台很有潜力的，虽然目前还是存在各种各样的不足和缺陷，但是有那么多人在为之付出，总是能够不断改进的。玉不琢不成器嘛~呵呵

**个人随想**

现在回想当年高考完了填志愿，好像当时对计算机一窍不通啊~但是那时候觉得计算机很强大，也许会改变未来人们的生活方式。所以最后就这么小不小心成了一个搞it的小菜鸟。不过既然选择了这行，就坚持下去吧！也不能说对技术特别痴迷，但是还是希望自己成为一个技术牛人嘛~

以前其实很少做笔记，作总结，再加上平常学到的东西也很少用，最后时间久了什么都忘了。所以这次淘宝的实习转正面试的悲剧是个教训。积累是成长的必须过程。以后有空就多就经常去学习，思考，总结。

万事开头难啊~不过今天算是迈出了第一步，写了一篇关于Hadoop的博文。千里之行始于足下~

注：本文是在我参考了网上很多相关资料之后，按我自己的思路整理而成的。具体的转载地址也没专门记录，敬请谅解~

内容来自：（http://blog.csdn.net/husthcb/article/details/5864769）

# 数据分析≠Hadoop+NoSQL，不妨先看完善现有技术的10条捷径 #

让业务搭乘大数据技术确实是件非常有吸引力的事情，而Apache Hadoop让这个诱惑来的更加的猛烈。Hadoop是个大规模可扩展数据存储平台，构成了大多数大数据项目基础。Hadoop是强大的，然而却需要公司投入大量的学习精力及其它的资源。

如果得到正确的应用，Hadoop确实能从根本上提升你公司的业务，然而这条Hadoop的应用之路却充满了荆棘。另一个方面，许多企业（当然不是Google、Facebook或者Twitter）的数据体积并没有大到需要巨型Hadoop集群去做分析，他们纯粹是被“大数据”这个热门的词语给吸引的。

就像Dabid Wheeler所说“计算机科学的所有问题都有另一个层次间接的解决方案”，而Hadoop正是类似间接解决方案；当你的上司被一些流行词汇所吸引时，做正确的软件架构决策将变的非常艰难。

下文将给出一些对Hadoop进行投资前需要尝试的替代方案：

**了解你的数据**

**数据的总体积**

Hadoop是为大型数据集所建立的有效解决方案。

*  GB级以上的文件系统HDFS。因此如果你的文件只是MB级的，你最好对数个文件进行整合（zip或者tar），让其达到数百兆或者是几GB。
 *  HDFS会将文件分割，并以64MB、128M或者更大的块进行存储。

如果你的数据集非常的小，那么使用这个巨型生态系统将不会很适合。这需要对自己的数据有足够的了解，并且分析需要什么类型的查询以及你的数据是否真的够大。

另一方面，鉴于你的计算指令可能很大，只通过数据库去测量数据的体积可能会存在误差。有时候数学计算或者分析小型数据集的排列可能会让得出的结果远大于实际数据体积，所以关键在于你对数据有切实的了解。

**数据增长的速度**

你可能在数据仓库或者其它的数据源中存有数TB数据，然而在建立Hadoop集群前有一个必须考虑的因素就是数据的增长速度。

对你的分析师提出几个简单的问题，比如：

*  数据增速究竟有多快？这些数据是否以非常快的速度增长？
 *  几月或者几年后数据的体积究竟会有多大？

许多公司的数据增长都是按年算的。这种情况下，你的数据增长速度其实并不快；所以这里建议考虑归档和清除选项，而不是直接的奔往Hadoop。

**如何减少需处理的数据**

如果你确实有非常大体积的数据，你可以考虑通过以下的途径将数据缩减到非常适合管理的体积，以下的几个选项已经过产业几十年考验。

**考虑归档**

数据存档是对过期的数据进行分开存储，当然存储的时间根据实际需求制定。这需要对数据以及应用程序对数据的使用情况，有非常充分的了解。比如电子商务公司的大数据处理只将3个月内的数据存入活跃数据库，而旧订单则被存入单独的存储。

这个途径同样可以运用于你的数据仓库。当然你可以存储更多的近期数据用于报告和查询，使用频度少的数据可以被存入单独的存储设备。

**考虑清除数据**

有时候我们一直忙于收集数据而不清楚究竟需要保存多少数据，如果你存储了非常多用不到的数据，那么这将毫无疑问的降低你有效数据的处理速度。弄清你的业务需求并且审查数据是否可以被删除，从中分析出你需要储存数据的类型，这不仅会节省你的存储空间，同样会提升有效数据的分析速度。

一个经常用到的最佳实践就是给数据仓库建立附加列，比如created\_date、created\_by、update\_date及updated\_by。通过这些附加列可以对数据进行阶段性的访问统计，这样就可以清楚数据的有效周期。这里需要着重对待的是数据清除的逻辑，切记先思考再实现。如果你使用了一个归档工具，那么数据的清除将会变得非常容易。

**不是所有的数据都很重要**

你可能受不了储存所有业务相关数据的诱惑，你可能有很多的数据来源，比如：日志文件、营销活动数据、ETL作业等。你需要明白不是所有数据都对业务起关键作用，而且在数据仓库中保存所有的数据并不是有益的。在数据源过滤掉不需要的数据，甚至是在储存到数据仓库之前。不要对所有的数据进行存储，只分析你所需的数据。

**注意哪些数据是你想要收集的**

拿在线视频编辑业务来说，你会需要保存你用户做出的所有操作吗？这样的话可能会产生非常大的数据体积，如果你发现你的数据仓库不足以应对这些数据，你可能会考虑只存储元数据。虽然视频编辑是个非常极端的例子，然而并不妨碍我们在其它用例中考虑这些信息。

总而言之，根据业务的需求只收集所需要的数据。

**智能分析**

**聘请了解业务的分析师**

到目前为止，你应该已经清楚理解数据的重要性；所以在你做了上面所有步骤后并决定使用Hadoop时，聘请1个了解业务的分析师将会对你业务产生巨大帮助。

如果数据分析师不懂如何从中获取价值，那么Hadoop将不会产生任何作用，不要吝啬对业务有深刻认识的雇员投资。鼓励他们多做实验，并且使用新的方式去分析同一个数据，找出使用现有基础设施获利的途径。

**为决策制定使用统计抽样**

统计抽样可以说是非常古老的技术，研究者及数学家运用它在大体积数据上推断合理的结论。通过这个步骤，我们可以大幅度的缩减数据体积。取代追踪数十亿或者数百万的数据点，只需要跟踪其中数千或者数百的数据点就可以了。这个手段虽然不会给我们提供精准的结果，但是却可以对大型的数据集有一个高等级的理解。

**提升技术**

你真的已经达到关系型数据库处理的极限了吗？

在探索其它领域之前，你更应该审视关系数据库是否可以继续处理问题。传统的关系型数据库已经被使用了很长一段时间，而很多机构已经可以使用它管理TB级的数据仓库。所以在迁往Hadoop之前，不妨考虑以下的方法。

**分割数据**

数据切分是从逻辑上或物理上将数据分割成数个更好维护或访问的部分，同时很多流行的开源关系型数据库都支持分片（比如MySQL Partitioning及Postgres Partitionging）。

**在传统数据库上考虑数据库分片**

数据库分片是提升传统关系型数据库性能极限的最后一招，适用于数据可以逻辑分片在不同节点上并且很少做跨节点join分享的情况。在网络应用程序中，基于用户分片，并将用户相关信息储存在同一个节点上是提升性能的常见途径。

分片有很多限制条件，所以并不是适合所有场景，同样在用例中存在太多的跨节点jion，分片将发挥不了任何作用。

**总结**

Hadoop的部署将耗费公司巨量的人力和物力，如果能通过提升现有基础设施来达到目标也不失为一良策。

原文：http://www.csdn.net/article/2013-07-19/2816277-hadoop-when-to-use

[你的数据根本不够大，别老扯什么Hadoop了][Hadoop]

**本文原名**[“Don’t use Hadoop when your data isn’t that big ”][Don_t use Hadoop when your data isn_t that big]**，出自有着多年从业经验的数据科学家**[Chris Stucchio][]**，纽约大学柯朗研究所博士后，搞过高频交易平台，当过创业公司的CTO，更习惯称自己为统计学者。对了，他现在自己创业，提供数据分析、推荐优化咨询服务，他的邮件是：stucchio@gmail.com 。**

有人问我，“你在大数据和Hadoop方面有多少经验？”我告诉他们，我一直在使用Hadoop，但是很少处理几TB以上数据的任务 。我基本上只是一个大数据新手——知道概念，写过代码，但是没有大规模经验。  
  
      他们又问我，“你能使用Hadoop做简单的 group by(分组)和sum(统计)吗？”我说当然可以，但我会说需要看具体的文件格式。

他们给我一个U盘，里面存储600MB数据（他们所有的数据，而不是样本数据）。不知道为什么， 我用 [pandas.read\_csv][pandas.read_csv] （ [Pandas][] 是一 种 Python数据分析库）解决方案，而不是Hadoop完成了这个任务后， 他们显得很不满意。

Hadoop实际上是有很多局限性的。Hadoop可以运行一个通用的计算，下面我用伪码进行说明：

Scala风格的伪码：

1.  collection.flatMap( (k,v) => F(k,v) ).groupBy( \_.\_1 ).map( \_.reduce( (k,v) => G(k,v) ) )

使用SQL风格的伪码表示：

1.  **SELECT** G(...) **FROM** **table** **GROUP** **BY** F(...)

或者想我多年解释一样：

1.  目标：统计计算图书馆书籍的数量  
2.  Map：你统计奇数书架上书的数量，我统计偶数书架上书的数量。（做统计的人越多，统计出结果越快，就是机器越多，效率越高）  
3.  Reduce：把我们每个人单独统计的结果数据加在一起。

我们所做的只有两个：F(k,v)和G(k,v)，除非要在中间步骤中做性能优化，其他一切都是固定的。

在Hadoop里，所有计算都必须按照一个map、一个group by、一个aggregate或者这种计算序列来写。这和穿上紧身衣一样，多憋得慌啊。许多计算用其他模型其实更适合。穿上紧身衣（使用hadoop）的唯一原因就是，可以扩展到极大的数据集。可大多数情况，你的数据集很可能根本远远够不上那个数量级。

可是呢，因为Hadoop和大数据是热词，世界有一半的人都想穿上紧身衣，即使他们实际不需要Hadoop。

**一、如果我的数据量是几百兆，Excel可能没法加载它**  
        对于Excel来说的“很大的数据”并非大数据，其实还有其它极好的工具可以使用——我喜欢的是基于Numpy库之上Pandas。 它可以将几百MB数据以高效的向量化格式加载到内存，在我购买已3年的笔记本上，一眨眼的功夫，Numpy就能完成1亿次浮点计算。Matlab和R也是极好的工具。

Pandas构建于Numpy库之上，可以以矢量格式的方式有效地把数百兆的数据载入到内存中。在我购买已3年的笔记本上，它可以用Numpy在一眨眼的功夫把1亿的浮点数乘在一起。Matlab和R也是极好的工具。  
       因此，对于几百兆的数据量，典型的做法是写一个简单的Python脚本逐行读取，处理， 然后写到了一个文件就行了

**二、可我的数据是10GB呢？**  
        我买了台新笔记本，它有16GB的内存（花$141.98）和256GB的SSD(额外200美元)。，如果在Pandas里加载一个10GB的csv文件，实际在内存里并没有那么大（内存不是占有10G）——可以将 “17284932583” 这样的数值串存为4位或者8位整数，“284572452.2435723”存为8位双精度。

最坏的情况下你还可以不同时将所有数据都一次加载到内存里。

**三、可我的数据是100GB、500GB或1TB呢？**

一个2T的硬盘才94.99美元，4T是169.99。买一块，加到桌面PC或者服务器上，然后装上PostgreSQL来解决它  
  
**四、Hadoop << SQL或Python脚本**  
  
       在计算的表达能力来说，Hadoop比SQL差 。Hadoop里能写的计算，在SQL或者简单的Python脚本都可以更轻松地写出来。  
        SQL是一个直观的查询语言，适合做业务分析，业务分析师和程序员都很常用。SQL查询非常简单，而且还非常快——只有数据库使用了正确的索引，要花几秒钟的sql查询都不太常见。

Hadoop没有索引的概念，Hadoop只有全表扫描，而且Hadoop抽象层次太多了——我之前的项目尽在应付Java内存错误（ [java memory errors][]）、内存碎片和集群竞用了，而这些时间远多于实际的数据分析工作。

如果你的数据并不是像SQL表那样的结构化数据（比如纯文本、JSON对象、二进制对象），通常是直接写一个小的Python脚本或者Ruby脚本逐行处理更直接。保存到多个文件，然后逐个处理即可，SQL不适用的情况下，从编程来说Hadoop也没那么糟糕，但相比Python脚本仍然没有什么优势。

除了难以编程，Hadoop还一般总是比其他技术方案要慢。只要索引用得好，SQL查询非常快。比如要计算join，PostgreSQL只需查看索引（如果有），然后查询所需的每个键。而Hadoop呢，必须做全表扫描，然后重排整个表。排序通过多台机器之间分片可以加速，但也带来了跨多机数据流处理的开销。如果要处理二进制文件，Hadoop必须反复访问namenode。而简单的Python脚本只要反复访问文件系统即可。

**五、我的数据超过了5TB**  
  
     只能使用Hadoop，而无需做过多的选择。

你的命可真苦——只能苦逼地折腾Hadoop了，没有太多其他选择（可能还能用许多硬盘容量的高富帅机器来扛），而且其他选择往往贵得要命（脑海中浮现出IOE等等字样……）。

用Hadoop唯一的好处是扩展。如果你的数据是一个数TB的单表，那么全表扫描是Hadoop的强项。此外的话（如果你没有这样大数据量的表），请关爱生命，尽量远离Hadoop。它带来的烦恼根本不值，用传统方法既省时又省力。

**六、Hadoop是一个极好的工具**  
  
         我并不讨厌Hadoop，当我用其它工具不能很好处理数据时我会选择Hadoop。另外，我推荐使用Scalding，不要使用Hive或Pig。Scalding支持使用Scala语言来编写Hadoop任务链，隐藏了其下的MapReduce。

[Hadoop]: http://blog.csdn.net/hguisu/article/details/12585313
[Don_t use Hadoop when your data isn_t that big]: http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html
[Chris Stucchio]: http://www.chrisstucchio.com/work.html
[pandas.read_csv]: http://pandas.pydata.org/pandas-docs/stable/generated/pandas.io.parsers.read_csv.html
[Pandas]: http://pandas.pydata.org/
[java memory errors]: http://www.chrisstucchio.com/blog/2013/gc_overhead_limit.html