初学hadoop的一些学习记录

最新推荐文章于 2024-04-26 22:54:41 发布

置顶 Tech_Hog

最新推荐文章于 2024-04-26 22:54:41 发布

阅读量3.1k

点赞数 1

分类专栏： Hadoop 文章标签： hadoop google file system nosql数据库

本文链接：https://blog.csdn.net/whaoxysh/article/details/17878401

版权

Hadoop 专栏收录该内容

41 篇文章 0 订阅

订阅专栏

倒排索引

简介

倒排索引（英语：Inverted index），也常被称为反向索引、置入档案或反向档案，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。

有两种不同的反向索引形式：

· 一条记录的水平反向索引（或者反向档案索引）包含每个引用单词的文档的列表。

· 一个单词的水平反向索引（或者完全反向索引）又包含每个单词在一个文档中的位置。

例子

以英文为例，下面是要被索引的文本：

· "it is what it is"

· "what is it"

· "it is a banana"

我们就能得到下面的反向文件索引：

"a": {2}

"banana": {2}

"is": {0, 1, 2}

"it": {0, 1, 2}

"what": {0, 1}

检索的条件"what", "is" 和 "it" 将对应这个集合：。

对相同的文字，我们得到后面这些完全反向索引，有文档数量和当前查询的单词结果组成的的成对数据。同样，文档数量和当前查询的单词结果都从零开始。所以，"banana":{(2, 3)} 就是说 "banana"在第三个文档里 ()，而且在第三个文档的位置是第四个单词(地址为 3)。

"a": {(2, 2)}

"banana": {(2, 3)}

"is": {(0, 1), (0, 4), (1, 1), (2, 1)}

"it": {(0, 0), (0, 3), (1, 2), (2, 0)}

"what": {(0, 2), (1, 0)}

应用

· 反向索引数据结构是典型的搜索引擎检索算法重要的部分。

· 一个搜索引擎执行的目标就是优化查询的速度：找到某个单词在文档中出现的地方。以前，正向索引开发出来用来存储每个文档的单词的列表，接着掉头来开发了一种反向索引。正向索引的查询往往满足每个文档有序频繁的全文查询和每个单词在校验文档中的验证这样的查询。

· 实际上，时间、内存、处理器等等资源的限制，技术上正向索引是不能实现的。

· 为了替代正向索引的每个文档的单词列表，能列出每个查询的单词所有所在文档的列表的反向索引数据结构开发了出来。

· 随着反向索引的创建，如今的查询能通过立即的单词标示迅速获取结果（经过随机存储）。随机存储也通常被认为快于顺序存储。

Lucene

简介

Lucene是apache软件基金会4 jakarta项目组的一个子项目，是一个开放源代码的全文检索引擎工具包，即它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。

优点

索引文件格式独立于应用平台。Lucene定义了一套以8位字节为基础的索引文件格式，使得兼容系统或者不同平台的应用能够共享建立的索引文件。

在传统全文检索引擎的倒排索引的基础上，实现了分块索引，能够针对新的文件建立小文件索引，提升索引速度。然后通过与原有索引的合并，达到优化的目的。

设计了独立于语言和文件格式的文本分析接口，索引器通过接受Token流完成索引文件的创立，用户扩展新的语言和文件格式，只需要实现文本分析的接口。

已经默认实现了一套强大的查询引擎，用户无需自己编写代码即可使系统获得强大的查询能力，Lucene的查询实现中默认实现了布尔操作、模糊查询（Fuzzy Search[11]）、分组查询等等。

导入jar包

7个包需要导入：analysis，document，index，queryParser，search，store，util

Nutch

简介

Nutch 是一个开源Java实现的搜索引擎。它提供了我们运行自己的搜索引擎所需的全部工具。包括全文搜索和Web爬虫。

组成

爬虫Crawler和查询searcher。Crawler主要用于从网络上抓取网页并为这些网页建立索引。Searcher主要利用这些索引检索用户的查找关键词来产生查找结果。两者之间的接口是索引，所以除去索引部分，两者之间的耦合度很低。

Crawler和Searcher两部分尽量分开的目的主要是为了使两部分可以分布式配置在硬件平台上，例如将Crawler和Searcher分别放在两个主机上，这样可以提升性能。

爬虫crawler

Crawler的重点在两个方面，Crawler的工作流程和涉及的数据文件的格式和含义。数据文件主要包括三类，分别是web database，一系列的segment加上index，三者的物理文件分别存储在爬行结果目录下的db目录下webdb子文件夹内，segments文件夹和index文件夹。那么三者分别存储的信息是什么呢？

一次爬行会产生很多个segment，每个segment内存储的是爬虫Crawler在单独一次抓取循环中抓到的网页以及这些网页的索引。Crawler爬行时会根据WebDB中的link关系按照一定的爬行策略生成每次抓取循环所需的fetchlist，然后Fetcher通过fetchlist中的URLs抓取这些网页并索引，然后将其存入segment。Segment是有时限的，当这些网页被Crawler重新抓取后，先前抓取产生的segment就作废了。在存储中。Segment文件夹是以产生时间命名的，方便我们删除作废的segments以节省存储空间。

Index是Crawler抓取的所有网页的索引，它是通过对所有单个segment中的索引进行合并处理所得的。Nutch利用Lucene技术进行索引，所以Lucene中对索引进行操作的接口对Nutch中的index同样有效。但是需要注意的是，Lucene中的segment和Nutch中的不同，Lucene中的segment是索引index的一部分，但是Nutch中的segment只是WebDB中各个部分网页的内容和索引，最后通过其生成的index跟这些segment已经毫无关系了。

Web database，也叫WebDB，其中存储的是爬虫所抓取网页之间的链接结构信息，它只在爬虫Crawler工作中使用而和Searcher的工作没有任何关系。WebDB内存储了两种实体的信息：page和link。Page实体通过描述网络上一个网页的特征信息来表征一个实际的网页，因为网页有很多个需要描述，WebDB中通过网页的URL和网页内容的MD5两种索引方法对这些网页实体进行了索引。Page实体描述的网页特征主要包括网页内的link数目，抓取此网页的时间等相关抓取信息，对此网页的重要度评分等。同样的，Link实体描述的是两个page实体之间的链接关系。WebDB构成了一个所抓取网页的链接结构图，这个图中Page实体是图的结点，而Link实体则代表图的边。

Crawler的工作原理

首先Crawler根据WebDB生成一个待抓取网页的URL集合叫做Fetchlist，接着下载线程Fetcher根据Fetchlist将网页抓取回来，如果下载线程有很多个，那么就生成很多个Fetchlist，也就是一个Fetcher对应一个Fetchlist。然后Crawler用抓取回来的网页更新WebDB，根据更新后的WebDB生成新的Fetchlist，里面是未抓取的或者新发现的URLs，然后下一轮抓取循环重新开始。这个循环过程可以叫做“产生/抓取/更新”循环。

指向同一个主机上Web资源的URLs通常被分配到同一个Fetchlist中，这可防止过多的Fetchers对一个主机同时进行抓取造成主机负担过重。另外Nutch遵守Robots ExclusionProtocol，网站可以通过自定义Robots.txt控制Crawler的抓取。

在Nutch中，Crawler操作的实现是通过一系列子操作的实现来完成的。这些子操作Nutch都提供了子命令行可以单独进行调用。下面就是这些子操作的功能描述以及命令行，命令行在括号中。

1. 创建一个新的WebDb (admin db -create).

2. 将抓取起始URLs写入WebDB中 (inject).

3. 根据WebDB生成fetchlist并写入相应的segment(generate).

4. 根据fetchlist中的URL抓取网页 (fetch).

5. 根据抓取网页更新WebDb (updatedb).

6. 循环进行3－5步直至预先设定的抓取深度。

7. 根据WebDB得到的网页评分和links更新segments (updatesegs).

8. 对所抓取的网页进行索引(index).

9. 在索引中丢弃有重复内容的网页和重复的URLs (dedup).

10. 将segments中的索引进行合并生成用于检索的最终index(merge).

Nutch和Lucene

Nutch是基于Lucene的。Lucene为Nutch提供了文本索引和搜索的API。

一个常见的问题是：我应该使用Lucene还是Nutch？

最简单的回答是：如果你不需要抓取数据的话，应该使用Lucene。

常见的应用场合是：你有数据源，需要为这些数据提供一个搜索页面。在这种情况下，最好的方式是直接从数据库中取出数据并用Lucene API建立索引。

在你没有本地数据源，或者数据源非常分散的情况下，应该使用Nutch。

Hadoop

Hadoop的构成

l 最底部是Hadoop Distributed File System（HDFS），存储 Hadoop 集群中所有存储节点上的文件。

l HDFS（对于本文）的上一层是MapReduce 引擎，由 JobTrackers 和 TaskTrackers组成。

HDFS介绍

对外部客户机而言，HDFS就像一个传统的分级文件系统。可以创建、删除、移动或重命名文件等。但 HDFS 的架构是基于一组特定的节点构建的，节点包括 NameNode（仅一个，因此存在“单点失效”的缺陷），它在HDFS内部提供元数据服务；DataNode，它为 HDFS提供存储块。

存储在 HDFS 中的文件被分成块，然后将这些块复制到多个计算机中（DataNode）。这与传统的RAID架构大不相同。块的大小（通常为 64MB）和复制的块数量在创建文件时由客户机决定。NameNode可以控制所有文件操作。HDFS内部的所有通信都基于标准的 TCP/IP 协议。

目的：支持以流的形式访问写入的大型文件。

NameNode

NameNode 是一个通常在 HDFS 实例中的单独机器上运行的软件。

负责管理文件系统名称空间和控制外部客户机的访问。

NameNode 决定是否将文件映射到 DataNode上的复制块上。对于最常见的 3个复制块，第一个复制块存储在同一机架的不同节点上，最后一个复制块存储在不同机架的某个节点上。这里需要了解集群架构。

实际的 I/O事务并没有经过NameNode，只有表示 DataNode 和块的文件映射的元数据经过 NameNode。当外部客户机发送请求要求创建文件时，NameNode会以块标识和该块的第一个副本的 DataNode IP 地址作为响应。这个 NameNode还会通知其他将要接收该块的副本的 DataNode。

NameNode 在一个称为 FsImage的文件中存储所有关于文件系统名称空间的信息。这个文件和一个包含所有事务的记录文件（这里是 EditLog）将存储在NameNode的本地文件系统上。FsImage和EditLog文件也需要复制副本，以防文件损坏或 NameNode系统丢失。

NameNode本身不可避免地具有SPOF（SinglePoint Of Failure）单点失效的风险，主备模式并不能解决这个问题，通过HadoopNon-stop namenode才能实现100% uptime可用时间。

DataNode

DataNode 也是一个通常在 HDFS实例中的单独机器上运行的软件。Hadoop集群包含一个 NameNode和大量DataNode。DataNode通常以机架的形式组织，机架通过一个交换机将所有系统连接起来。

Hadoop 的一个假设是：机架内部节点之间的传输速度快于机架间节点的传输速度。

DataNode 响应来自 HDFS客户机的读写请求。它们还响应来自 NameNode的创建、删除和复制块的命令。NameNode依赖来自每个DataNode的定期心跳（heartbeat）消息。每条消息都包含一个块报告，NameNode可以根据这个报告验证块映射和其他文件系统元数据。如果DataNode不能发送心跳消息，NameNode将采取修复措施，重新复制在该节点上丢失的块。

文件操作

如果客户机想将文件写到 HDFS上，首先需要将该文件缓存到本地的临时存储。如果缓存的数据大于所需的HDFS块大小，创建文件的请求将发送给 NameNode。NameNode将以DataNode标识和目标块响应客户机。

同时也通知将要保存文件块副本的 DataNode。当客户机开始将临时文件发送给第一个 DataNode 时，将立即通过管道方式将块内容转发给副本 DataNode。客户机也负责创建保存在相同 HDFS名称空间中的校验和（checksum）文件。

在最后的文件块发送之后，NameNode将文件创建提交到它的持久化元数据存储（在 EditLog 和FsImage文件）。

优点

l Hadoop是一个能够对大量数据进行分布式处理的软件框架。Hadoop是以一种可靠、高效、可伸缩的方式进行处理的。

l Hadoop是可靠的，因为它假设计算元素和存储会失败，因此它维护多个工作数据副本，确保能够针对失败的节点重新分布处理。

l Hadoop是高效的，因为它以并行的方式工作，通过并行处理加快处理速度。

l Hadoop还是可伸缩的，能够处理 PB级数据。

l Hadoop依赖于社区服务器，因此它的成本比较低，任何人都可以使用。

⒈高可靠性。Hadoop按位存储和处理数据的能力值得人们信赖。

⒉高扩展性。Hadoop是在可用的计算机集簇间分配数据并完成计算任务的，这些集簇可以方便地扩展到数以千计的节点中。

⒊高效性。Hadoop能够在节点之间动态地移动数据，并保证各个节点的动态平衡，因此处理速度非常快。

⒋高容错性。Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配。

5.低成本。与一体机、商用数据仓库以及QlikView、Yonghong Z-Suite等数据集市相比，hadoop是开源的，项目的软件成本因此会大大降低。

集群系统

Google的数据中心使用廉价的Linux PC机组成集群，在上面运行各种应用。即使是分布式开发的新手也可以迅速使用Google的基础设施。核心组件是3个：

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

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

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

以上三个设施Google均有论文发表。

1. 《The Google File System》2003年

2. 《MapReduce: Simplified DataProcessing on Large Clusters》 2004年

3. 《Bigtable: A Distributed StorageSystem for Structured Data》 2006年

Hadoop各子项目介绍

1. Hadoop Common:在0.20及以前的版本中，包含HDFS、MapReduce和其他项目公共内容，从0.21开始HDFS和MapReduce被分离为独立的子项目，其余内容为Hadoop Common

2. HDFS: Hadoop分布式文件系统(Distributed File System)－ HDFS (Hadoop Distributed FileSystem)

3. MapReduce：并行计算框架，0.20前使用org.apache.hadoop.mapred旧接口，0.20版本开始引入org.apache.hadoop.mapreduce的新API

4. HBase:类似Google BigTable的分布式NoSQL列数据库。（HBase和Avro已经于2010年5月成为顶级Apache项目）

5. Hive：数据仓库工具，由Facebook贡献。

6. Zookeeper：分布式锁设施，提供类似Google Chubby的功能，由Facebook贡献。

7. Avro：新的数据序列化格式与传输工具，将逐步取代Hadoop原有的IPC机制。

8. Pig: 大数据分析平台，为用户提供多种接口。

9. Ambari：Hadoop管理工具，可以快捷的监控、部署、管理集群。

10. Sqoop：于在HADOOP与传统的数据库间进行数据的传递。

认证

Cloudera

Cloudera公司主要提供Apache Hadoop开发工程师认证（Cloudera CertifiedDeveloper for Apache Hadoop，CCDH^[9]）和ApacheHadoop管理工程师认证（Cloudera CertifiedAdministrator for Apache Hadoop ，CCAH），更多相关信息，请参阅Cloudera公司官方网站。

Hortonworks

Hortonworks Hadoop培训课程是由Apache Hadoop项目的领导者和核心开发人员所设计，代表了这一行业的最高水平。

Hortonworks是国际领先的开发、推广和支持Apache Hadoop的商业供应商，它的Hadoop认证也是业界公认的Hadoop权威认证，分为开发者认证(HCAHD^[10], Hortonworks Certified ApacheHadoopDeveloper)和管理员认证(HCAHA, Hortonwork CertifiedApache HadoopAdministrator)。

NoSQL

简介

NoSQL，指的是非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。

NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储。

计算机体系结构在数据存储方面要求具备庞大的水平扩展性，而NoSQL致力于改变这一现状。Google的 BigTable和Amazon的Dynamo使用的就是NoSQL型数据库。

水平扩展性(horizontalscalability)指能够连接多个软硬件的特性,这样可以将多个服务器从逻辑上看成一个实体。

发展

随着互联网web2.0网站的兴起，非关系型的数据库成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，问题如下：

l High performance -对数据库高并发读写的需求

web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求。

l Huge Storage -对海量数据的高效率存储和访问的需求

对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。

l High Scalability && High Availability-对数据库的高可扩展性和高可用性的需求

在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

1、数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。

2、数据库的写实时性和读实时性需求

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的。并不要求这么高的实时性。

3、对复杂的SQL查询，特别是多表关联查询的需求

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

特点

l 它们可以处理超大量的数据。

l 它们运行在便宜的PC服务器集群上。

PC集群扩充起来非常方便并且成本很低，避免了“sharding”操作的复杂性和成本。

l 它们击碎了性能瓶颈。

NoSQL的支持者称，通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间，执行速度变得更快。

“SQL并非适用于所有的程序代码，”对于那些繁重的重复操作的数据，SQL值得花钱。但是当数据库结构非常简单时，SQL可能没有太大用处。

l 没有过多的操作。

虽然NoSQL的支持者也承认关系数据库提供了无可比拟的功能集合，而且在数据完整性上也发挥绝对稳定，他们同时也表示，企业的具体需求可能没有那么多。

l Bootstrap支持

因为NoSQL项目都是开源的，因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样，不得不从社区中寻求支持。

优点

l 易扩展

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

l 大数据量，高性能

NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用 Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的 Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。