君，已阅读到文档的结尾了呢~~
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
数据库系统中有向图的存储及其应用
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口Hadoop的辉煌还能延续多久？
发表于 16:03|
作者Mike Miller
摘要：Hadoop已经成为大数据的代名词。短短几年间，Hadoop从一种边缘技术成为事实上的标准。而另一方面，MapReduce在谷歌已不再显赫。当企业瞩目MapReduce的时候，谷歌好像早已进入到了下一个时代。
Hadoop技术已经无处不在。不管是好是坏，Hadoop已经成为大数据的代名词。短短几年间，Hadoop从一种边缘技术成为事实上的标准。看来，不仅现在Hadoop是企业大数据的标准，而且在未来，它的地位似乎一时难以动摇。
谷歌文件系统与MapReduce
我们先来探讨一下Hadoop的灵魂&&MapReduce。面对数据的爆炸性增长，谷歌的工程师Jeff Dean和Sanjay Ghemawat架构并发布了两个开创性的系统：谷歌文件系统（GFS）和谷歌MapReduce（GMR）。前者是一个出色而实用的解决方案-使用常规的硬件扩展并管理数据，后者同样辉煌，造就了一个适用于大规模并行处理的计算框架。
谷歌MapReduce（GMR）为普通开发者/用户进行大数据处理提供了简易的方式，并使之快速、具备容错性。谷歌文件系统（GFS）和谷歌MapReduce（GMR）也为谷歌搜索引擎对网页进行抓取、分析提供了核心动力。
再回头看看开源世界中的Hadoop，Apache Hadoop的分布式文件系统（HDFS）和Hadoop MapReduce完全是谷歌文件系统（GFS）和谷歌MapReduce（GMR）的开源实现。Hadoop项目已经发展成为一个生态系统，并触及了大数据领域的方方面面。但从根本上，它的核心是MapReduce。
Hadoop是否可以赶超谷歌？
一个有趣的现象是，MapReduce在谷歌已不再显赫。当企业瞩目MapReduce的时候，谷歌好像早已进入到了下一个时代。事实上，我们谈论的这些技术早就不是新技术了，MapReduce也不例外。
我希望在后Hadoop时代下面这些技术能够更具竞争性。尽管许多Apache社区的项目和商业化Hadoop项目都非常活跃，并以来自HBase、Hive和下一代MapReduce（YARN）的技术不断完善着Hadoop体系，我依然认为，Hadoop核心（HDFS和Zookeeper）需要脱离MapReduce并以全新的架构增强自己的竞争力，真正与谷歌技术一较高下。
过滤不断增长的索引，分析不断变化的数据集。Hadoop的伟大之处在于，它一旦开始运行，就会飞速地分析你的数据。尽管如此，在每次分析数据之前，即添加、更改或删除数据之后，我们都必须将整个数据集进行流式处理。这意味着，随着数据集的膨胀，分析时间也会随之增加，且不可预期。
那么，谷歌又是怎么做到搜索结果越来越实时呈现呢？一个名为Percolator的增量处理引擎取代了谷歌MapReduce（GMR）。通过对新建、更改和已删除文档的处理，并使用二级索引进行高效的分类、查询，谷歌能够显著地降低实现其目标的时间。
Percolator的作者写道：&将索引系统转化为一个增量系统&&文档平均处理延迟的因子降低到了现在的100。&这句话的意思是，索引Web上新内容的速度比之前MapReduce系统快了100倍。
谷歌Dremel即时数据分析解决方案
谷歌和Hadoop社区曾致力于构建基于MapReduce的易用性即时数据分析工具，如谷歌的并行处理语言Sawzall，Apache Pig和Hive。但对熟知SQL的人们而言，他们忽略了一个基本事实-构建MapReduce的目标就在于管理数据处理工作。它的核心能力在于工作流管理，而不是即时数据分析。
与之形成鲜明对比的是，很多BI或数据分析查询基本上都要求即时、交互和低延迟。这意味着，使用Hadoop不仅需要规划流程图，而且需要为许多查询分析裁减不必要的工作流。即便如此，我们也要花费数分钟等待工作开始，然后花费数小时等待工作流完成，并且这个过程也非常不利于交互式体验。因此，谷歌研发了Dremel予以应对。Dremel是Google 的&交互式&数据分析系统，可以在几秒钟内处理PB级别的数据，并能轻松应对即时查询。
Google Dremel的设计特点：
Dremel是一个可扩展的大型系统。在一个PB级别的数据集上面，将任务缩短到秒级，无疑需要大量的并发。磁盘的顺序读速度在100MB/S上下，那么在1S内处理1TB数据，意味着至少需要有1万个磁盘的并发读! Google一向是用廉价机器办大事的好手。但是机器越多，出问题概率越大，如此大的集群规模，需要有足够的容错考虑，保证整个分析的速度不被集群中的个别节点影响。&
Dremel是MapReduce的补充。和MapReduce一样，Dremel也需要GFS这样的文件系统作为存储层。在设计之初，Dremel并非是MapReduce的替代品，它只是可以执行非常快的分析，在使用的时候，常常用它来处理MapReduce的结果集或者用来建立分析原型。&
Dremel的数据模型是嵌套的。互联网数据常常是非关系型的。Dremel还需要有一个灵活的数据模型，这个数据模型至关重要。Dremel支持一个嵌套的数据模型，类似于JSON。而传统的关系模型，由于不可避免的有大量的JOIN操作，在处理如此大规模的数据的时候，往往是有心无力的。
Dremel中的数据是采用列式存储的。使用列式存储，分析的时候，可以只扫描需要的那部分数据的时候，减少CPU和磁盘的访问量。同时列式存储是压缩友好的，使用压缩，可以综合CPU和磁盘，发挥最大的效能。
Dremel结合了Web搜索和并行DBMS的技术。Dremel借鉴了Web搜索中的&查询树&的概念，将一个相对巨大复杂的查询，分割成较小较简单的查询。大事化小，小事化了，能并发的在大量节点上跑。另外，和并行DBMS类似，Dremel可以提供了一个SQL-like的接口，就像Hive和Pig那样。
谷歌的图数据计算框架Pregel
谷歌MapReduce是专门为抓取、分析世界上最庞大的图形架构-internet而设计的，但针对大规模图算法（如图遍历（BFS）、PageRank，最短路径（SSSP）等）的计算则显得效率低下。因此，谷歌构建了Pregel。
Pregel给人的印象非常深刻。Pregel不仅能高效执行SSSP或PageRank算法，更令人惊讶的是，公布的数据显示Pregel处理一个有着几十亿节点、上万亿条边的图，只需数分钟即可完成，其执行时间随着图的大小呈线性增长。
Pregel基于BSP模型，就是&计算&-&通信&-&同步&的模式：
输入输出为有向图
以节点为中心计算，超步内每个节点执行自己的任务，执行节点的顺序不确定
两个超步之间是通信阶段
在Pregel中，以节点为中心计算。Step 0时每节点都活动着，每个节点主动&给停止投票&进入不活动状态。如果接收到消息，则激活。没有活动节点和消息时，整个算法结束。容错是通过检查点来做的。在每个超步开始的时候，对主从节点分别备份。
尽管当前大数据技术的核心依然是Hadoop，但谷歌却已经为我们展现了许多更先进的大数据技术。谷歌开发这些技术的本意并不是要立刻抛弃掉MapReduce，但毫无疑问这是未来大数据技术的趋势。尽管已经出现了上述大数据技术的开源实现，但我们不禁要问，Hadoop的辉煌还能延续多久？（张志平/编译）
原文链接：
推荐阅读相关主题：
网友评论有（0）
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章Hadoop原理（9）
HDFS（ Distributed File System）是Hadoop分布式计算中的数据存储系统，是基于流数据模式访问和处理超大文件的需求而开发的。下面我们首先介绍HDFS中的一些基础概念，然后介绍HDFS中读写操作的过程，最后分析了HDFS的优缺点。
1. HDFS中的基础概念
Block：HDFS中的存储单元是每个数据块block，HDFS默认的最基本的存储单位是64M的数据块。和普通的文件系统相同的是，HDFS中的文件也是被分成64M一块的数据块存储的。不同的是，在HDFS中，如果一个文件大小小于一个数据块的大小，它是不需要占用整个数据块的存储空间的。
NameNode：元数据节点。该节点用来管理文件系统中的命名空间，是master。其将所有的文件的元数据保存在一个文件系统树中，这些信息在硬盘上保存的方式是命名空间镜像（fsimage）以及修改日志（edit log），后面还会讲到。此外，NameNode还保存了一个文件包括哪些数据块，分布在哪些数据节点上。然而，这些信息不存放在硬盘上，而是在系统启动的时候从数据节点收集而成的。
DataNode：数据节点，是HDFS真正存储数据的地方。客户端（client）和元数据节点（NameNode）可以向数据节点请求写入或者读出数据块。此外，DataNode需要周期性的向元数据节点回报其存储的数据块信息。
Secondary NameNode:从元数据节点。从元数据节点并不是NameNode出现问题时候的备用节点，它的主要功能是周期性的将NameNode中的fsimage和edit log合并，以防log文件过大。此外，合并过后的fsimage文件也会在Secondary NameNode上保存一份，以防NameNode失败的时候，可以恢复。
edit log：修改日志，当文件系统客户端client进行写操作的时候，我们就要把这条记录放在修改日志中。在记录了修改日志后，NameNode则修改内存中的edit log数据结构。每次写操作成功之前，edit log都会被保存。
fsimage：命名空间镜像，它是内存中的元数据在硬盘上的checkpoint。当NameNode失败的时候，最新的checkpoint的元数据信息就会从fsimage加载到内存中，然后注意重新执行修改日志中的操作。而Secondary NameNode就是用来帮助元数据节点将内存中的元数据信息checkpoint到硬盘上的。
具体checkpoint的过程如下图：（参考hadoop集群的博客）
checkpoint的过程如下：Secondary NameNode通知NameNode生成新的日志文件，以后的日志都写到新的日志文件中。Secondary NameNode用http get从NameNode获得fsimage文件及旧的日志文件。Secondary NameNode将fsimage文件加载到内存中，并执行日志文件中的操作，然后生成新的fsimage文件。Secondary NameNode将新的fsimage文件用http post传回NameNode。NameNode可以将旧的fsimage文件及旧的日志文件，换为新的fsimage文件和新的日志文件(第一步生成的)，然后更新fstime文件，写入此次checkpoint的时间。这样NameNode中的fsimage文件保存了最新的checkpoint的元数据信息，日志文件也重新开始，不会变的很大了。
2. HDFS中文件读写操作流程
在HDFS中，文件的读写过程就是client和NameNode以及DataNode一起交互的过程。我们已经知道NameNode管理着文件系统的元数据，DataNode存储的是实际的数据，那么client就会联系NameNode以获取文件的元数据，而真正的文件读取操作是直接和DataNode进行交互的。
写文件的过程：
客户端调用create()来创建文件
DistributedFileSystem用RPC调用元数据节点，在文件系统的命名空间中创建一个新的文件。
元数据节点首先确定文件原来不存在，并且客户端有创建文件的权限，然后创建新文件。
DistributedFileSystem返回DFSOutputStream，客户端用于写数据。
客户端开始写入数据，DFSOutputStream将数据分成块，写入data queue。
Data queue由Data Streamer读取，并通知元数据节点分配数据节点，用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。
Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。
DFSOutputStream为发出去的数据块保存了ack queue，等待pipeline中的数据节点告知数据已经写入成功。
如果数据节点在写入的过程中失败：
关闭pipeline，将ack queue中的数据块放入data queue的开始。
当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后能够察觉其数据块是过时的，会被删除。
失败的数据节点从pipeline中移除，另外的数据块则写入pipeline中的另外两个数据节点。
元数据节点则被通知此数据块是复制块数不足，将来会再创建第三份备份。
当客户端结束写入数据，则调用stream的close函数。此操作将所有的数据块写入pipeline中的数据节点，并等待ack queue返回成功。最后通知元数据节点写入完毕。
读取文件的过程：
客户端(client)用FileSystem的open()函数打开文件
DistributedFileSystem用RPC调用元数据节点，得到文件的数据块信息。
对于每一个数据块，元数据节点返回保存数据块的数据节点的地址。
DistributedFileSystem返回FSDataInputStream给客户端，用来读取数据。
客户端调用stream的read()函数开始读取数据。
DFSInputStream连接保存此文件第一个数据块的最近的数据节点。
Data从数据节点读到客户端(client)
当此数据块读取完毕时，DFSInputStream关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点。
当客户端读取完毕数据的时候，调用FSDataInputStream的close函数。
在读取数据的过程中，如果客户端在与数据节点通信出现错误，则尝试连接包含此数据块的下一个数据节点。失败的数据节点将被记录，以后不再连接。
3. HDFS的优缺点分析
1）能够处理超大的文件；
2）流式访问数据。HDFS能够很好的处理“一次写入，多次读写”的任务。也就是说，一个数据集一旦生成了，就会被复制到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及到数据集中的大部分数据。所以，HDFS请求读取整个数据集要比读取一条记录更加高效。
3）可以运行在比较廉价的商用机器集群上。
缺点和改进策略：
1）不适合低延迟数据访问：HDFS是为了处理大型数据集分析任务的，主要是为达到大数据分析，所以延迟时间可能会较高。改进策略：对于那些有低延时要求的应用程序，HBase是一个更好的选择。通过上层数据管理项目来尽可能地弥补这个不足。在性能上有了很大的提升，它的口号就是goes real time。使用缓存或多master设计可以降低client的数据请求压力，以减少延时。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延时了。
2）无法高效存储大量小文件：因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。改进策略：要想让HDFS能处理好小文件，有不少方法。利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。多Master设计，这个作用显而易见了。正在研发中的GFS
II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件啊。
附带个Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成。
3）不支持多用户写入以及任意修改文件：在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。
1. HDFS开创性地设计出一套文件存储方式，即对文件分割后分别存放；
2. HDFS将要存储的大文件进行分割，分割后存放在既定的存储块（Block）中，并通过预先设定的优化处理，模式对存储的数据进行预处理，从而解决了大文件储存与计算的需求；
3. 一个HDFS集群包括两大部分，即NameNode与DataNode。一般来说，一个集群中会有一个NameNode和多个DataNode共同工作；
4. NameNode是集群的主服务器，主要是用于对HDFS中所有的文件及内容数据进行维护，并不断读取记录集群中DataNode主机情况与工作状态，并通过读取与写入镜像日志文件的方式进行存储；
5. DataNode在HDFS集群中担任任务具体执行角色，是集群的工作节点。文件被分成若干个相同大小的数据块，分别存储在若干个DataNode上，DataNode会定期向集群内NameNode发送自己的运行状态与存储内容，并根据NameNode发送的指令进行工作；
6. NameNode负责接受客户端发送过来的信息，然后将文件存储位置信息发送给提交请求的客户端，由客户端直接与DataNode进行联系，从而进行部分文件的运算与操作。
7. Block是HDFS的基本存储单元，默认大小是64M；
8. HDFS还可以对已经存储的Block进行多副本备份，将每个Block至少复制到3个相互独立的硬件上，这样可以快速恢复损坏的数据；
9. 用户可以使用既定的API接口对HDFS中的文件进行操作；
10. 当客户端的读取操作发生错误的时候，客户端会向NameNode报告错误，并请求NameNode排除错误的DataNode后后重新根据距离排序，从而获得一个新的DataNode的读取路径。如果所有的DataNode都报告读取失败，那么整个任务就读取失败；
11. 对于写出操作过程中出现的问题，FSDataOutputStream并不会立即关闭。客户端向NameNode报告错误信息，并直接向提供备份的DataNode中写入数据。备份DataNode被升级为首选DataNode，并在其余2个DataNode中备份复制数据。NameNode对错误的DataNode进行标记以便后续对其进行处理。
本文转载自：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：36766次
积分：2116
积分：2116
排名：第14848名
原创：165篇
转载：95篇
Jack holds a degree in Computer Engineering and is a passionate software programmer. He has good experience in Java/J2EE Web-Application development for Banking and Financial Domains.
(7)(25)(15)(27)(25)(29)(32)(50)(58)您的位置： &
基于Hadoop的电信频繁交往圈算法研究
优质期刊推荐当前位置： >
> Hadoop集群学习过程中常见的45个问题及解决方法
Hadoop集群学习过程中常见的45个问题及解决方法
导读：在Hadoop集群学习与使用过程中经常遇见这样那样的小问题，这里为大家分享Hadoop集群设置中经常出现的一些问题，以下为译文：1.Hadoop集群可以运行的3个模式？单机（本地）模式伪分布式模式
分享Hadoop集群设置中经常出现的一些问题，以下为译文：
　1.Hadoop集群可以运行的3个模式？
单机（本地）模式
伪分布式模式
全分布式模式
　　2. &单机（本地）模式中的注意点？
在单机模式（standalone）中不会存在守护进程，所有东西都运行在一个JVM上。这里同样没有DFS，使用的是本地文件系统。单机模式适用于开发过程中运行MapReduce程序，这也是最少使用的一个模式。
　3. &伪分布模式中的注意点？
伪分布式（Pseudo）适用于开发和测试环境，在这个模式中，所有守护进程都在同一台机器上运行。
　　4. &VM是否可以称为Pseudo？
不是，两个事物，同时Pseudo只针对Hadoop。
　　5. &全分布模式又有什么注意点？
全分布模式通常被用于生产环境，这里我们使用N台主机组成一个Hadoop集群，Hadoop守护进程运行在每台主机之上。这里会存在Namenode运行的主机，Datanode运行的主机，以及task tracker运行的主机。在分布式环境下，主节点和从节点会分开。
　6. &Hadoop是否遵循UNIX模式？
是的，在UNIX用例下，Hadoop还拥有&conf&目录。
7. &Hadoop安装在什么目录下？
Cloudera和Apache使用相同的目录结构，Hadoop被安装在cd/usr/lib/hadoop-0.20/。
　8. &Namenode、Job tracker和task tracker的端口号是？
Namenode，70；Job tracker，30；Task tracker，60。
　9. &Hadoop的核心配置是什么？
Hadoop的核心配置通过两个xml文件来完成：1，hadoop-default.xml；2，hadoop-site.xml。这些文件都使用xml格式，因此每个xml中都有一些属性，包括名称和值，但是当下这些文件都已不复存在。
　10. &那当下又该如何配置？
Hadoop现在拥有3个配置文件：1，core-site.xml；2，hdfs-site.xml；3，mapred-site.xml。这些文件都保存在conf/子目录下。
　　11. &RAM的溢出因子是？
溢出因子（Spill factor）是临时文件中储存文件的大小，也就是Hadoop-temp目录。
　　12. &fs.mapr.working.dir只是单一的目录？
fs.mapr.working.dir只是一个目录。
　13. &hdfs-site.xml的3个主要属性？
dfs.name.dir决定的是元数据存储的路径以及DFS的存储方式（磁盘或是远端）
dfs.data.dir决定的是数据存储的路径
fs.checkpoint.dir用于第二Namenode
　　14. &如何退出输入模式？
退出输入的方式有：1，按ESC；2，键入:q（如果你没有输入任何当下）或者键入:wq（如果你已经输入当下），并且按下Enter。
　　15. &当你输入hadoopfsck /造成&connection refused java exception&&时，系统究竟发生了什么？
这意味着Namenode没有运行在你的VM之上。
　　16. &我们使用Ubuntu及Cloudera，那么我们该去哪里下载Hadoop，或者是默认就与Ubuntu一起安装？
这个属于Hadoop的默认配置，你必须从Cloudera或者Edureka的dropbox下载，然后在你的系统上运行。当然，你也可以自己配置，但是你需要一个Linux box，Ubuntu或者是Red Hat。在Cloudera网站或者是Edureka的Dropbox中有安装步骤。
　　17. &&jps&命令的用处？
这个命令可以检查Namenode、Datanode、Task Tracker、 Job Tracker是否正常工作。
　　18. &如何重启Namenode？
点击stop-all.sh，再点击start-all.sh。
键入sudo hdfs（Enter），su-hdfs （Enter），/etc/init.d/ha（Enter），及/etc/init.d/hadoop-0.20-namenode start（Enter）。
　19. &Fsck的全名？
全名是：File System Check。
　　20. &如何检查Namenode是否正常运行？
如果要检查Namenode是否正常工作，使用命令/etc/init.d/hadoop-0.20-namenode status或者就是简单的jps。
　21. &mapred.job.tracker命令的作用？
可以让你知道哪个节点是Job Tracker。
　　22. &/etc /init.d命令的作用是？
/etc /init.d说明了守护进程（服务）的位置或状态，其实是LINUX特性，和Hadoop关系不大。
　　23. &如何在浏览器中查找Namenode？
如果你确实需要在浏览器中查找Namenode，你不再需要localhost:8021，Namenode的端口号是50070。
　24. &如何从SU转到Cloudera？
从SU转到Cloudera只需要键入exit。
　　25. &启动和关闭命令会用到哪些文件？
Slaves及Masters。
　　26. &Slaves由什么组成？
Slaves由主机的列表组成，每台1行，用于说明数据节点。
　　27. &Masters由什么组成？
Masters同样是主机的列表组成，每台一行，用于说明第二Namenode服务器。
28. &hadoop-env.sh是用于做什么的？
hadoop-env.sh提供了Hadoop中. JAVA_HOME的运行环境。
　　29. &Master文件是否提供了多个入口？
是的你可以拥有多个Master文件接口。
　　30. &hadoop-env.sh文件当下的位置？
hadoop-env.sh现在位于conf。
　　31. &在Hadoop_PID_DIR中，PID代表了什么？
PID代表了&Process ID&。
　　32. &/var/hadoop/pids用于做什么？
/var/hadoop/pids用来存储PID。
　　33. &hadoop-metrics.properties文件的作用是？
hadoop-metrics.properties被用做&Reporting&，控制Hadoop报告，初始状态是&not to report&。
　　34. &Hadoop需求什么样的网络？
Hadoop核心使用Shell（SSH）来驱动从节点上的服务器进程，并在主节点和从节点之间使用password-less SSH连接。
　　35. &全分布式环境下为什么需求password-less SSH？
这主要因为集群中通信过于频繁，Job Tracker需要尽可能快的给Task Tracker发布任务。
　　36. &这会导致安全问题吗？
完全不用担心。Hadoop集群是完全隔离的，通常情况下无法从互联网进行操作。与众不同的配置，因此我们完全不需要在意这种级别的安全漏洞，比如说通过互联网侵入等等。Hadoop为机器之间的连接提供了一个相对安全的方式。
　　37. &SSH工作的端口号是？
SSH工作的端口号是NO.22，当然可以通过它来配置，22是默认的端口号。
　　38. &SSH中的注意点还包括？
SSH只是个安全的shell通信，可以把它当做NO.22上的一种协议，只需要配置一个密码就可以安全的访问。
　　39. &为什么SSH本地主机需要密码？
在SSH中使用密码主要是增加安全性，在某些情况下也根本不会设置密码通信。
　　40. &如果在SSH中添加key，是否还需要设置密码？
是的，即使在SSH中添加了key，还是需要设置密码。
　　41. &假如Namenode中没有数据会怎么样？
没有数据的Namenode就不能称之为Namenode，通常情况下，Namenode肯定会有数据。
　42. &当Job Tracker宕掉时，Namenode会发生什么？
当Job Tracker失败时，集群仍然可以正常工作，只要Namenode没问题。
　43. &是客户端还是Namenode决定输入的分片？
这并不是客户端决定的，在配置文件中以及决定分片细则。
　　44. &是否可以自行搭建Hadoop集群？
是的，只要对Hadoop环境足够熟悉，你完全可以这么做。
　　45. &是否可以在Windows上运行Hadoop？
你最好不要这么做，Red Hat Linux或者是Ubuntu才是Hadoop的最佳操作系统。在Hadoop安装中，Windows通常不会被使用，因为会出现各种各样的问题。因此，Windows绝对不是Hadoop的推荐系统。
￥27500.00
￥21600.00
￥25080.00
其他资源->
Copyright @ 2006- 版权所有 ICP经营许可证号
存储第一站，存储门户，存储在线交流平台