2024年大數(shù)據(jù)面試題試卷

大數(shù)據(jù)面試題及答案匯總版

第1部分選擇題1.1Hadoop選擇題HDFS1．下面哪個(gè)程序負(fù)責(zé)HDFS數(shù)據(jù)存儲(chǔ)？A．NameNode

B．Jobtracker

C．DatanodeD．secondaryNameNode

E．tasktracker2.HDFS中的block默認(rèn)保留幾份？A．3份B．2份C．1份D．4份3.下列哪個(gè)程序一般與NameNode在一種節(jié)點(diǎn)啟動(dòng)？A.SecondaryNameNodeB．DataNodeC．TaskTrackerD.Jobtracker4.HDFS默認(rèn)BlockSize（新版本）A.32MB

B．64MBC．128MBD．256MB5.Client端上傳文獻(xiàn)的時(shí)候下列哪項(xiàng)對(duì)的A.數(shù)據(jù)通過(guò)NameNode傳遞給DataNodeB．Client

端將文獻(xiàn)切分為

Block，依次上傳C．Client只上傳數(shù)據(jù)到一臺(tái)DataNode，然後由NameNode負(fù)責(zé)Block復(fù)制工作6.下面與HDFS類似的框架是？A．NTFSB．FAT32C．GFSD．EXT37.的8.的集群管理1.下列哪項(xiàng)一般是集群的最重要瓶頸A.CPU

B．網(wǎng)絡(luò)

C．磁盤IO

D．內(nèi)存2.有關(guān)SecondaryNameNode哪項(xiàng)是對(duì)的的？A．它是NameNode的熱備B．它對(duì)內(nèi)存沒(méi)有規(guī)定C．它的目的是協(xié)助

NameNode

合并編輯曰志，減少

NameNode

啟動(dòng)時(shí)間D．SecondaryNameNode應(yīng)與NameNode布署到一種節(jié)點(diǎn)3.下列哪項(xiàng)不可以作為集群的管理？A.Puppet

B．Pdsh

C．ClouderaManager

D．Zookeeper4.配置機(jī)架感知的下面哪項(xiàng)對(duì)的A.假如一種機(jī)架出問(wèn)題，不會(huì)影響數(shù)據(jù)讀寫B(tài)．寫入數(shù)據(jù)的時(shí)候會(huì)寫到不一樣機(jī)架的DataNode中C．MapReduce會(huì)根據(jù)機(jī)架獲取離自已比較近的網(wǎng)絡(luò)數(shù)據(jù)5.下列哪個(gè)是Hadoop運(yùn)行的模式A.單機(jī)版

B．偽分布式

C．分布式6.Cloudera提供哪幾種安裝CDH的措施A.Clouderamanager

B．Tarball

C．Yum

D．Rpm7.1.2Hbase選擇題Hbase基礎(chǔ)1.HBase來(lái)源于哪篇博文？CATheGoogleFileSystemBMapReduceCBigTableDChubby2.下面對(duì)HBase的描述是錯(cuò)誤的？AA不是開(kāi)源的B是面向列的C是分布式的D是一種NoSQL數(shù)據(jù)庫(kù)3.HBase依托（）存儲(chǔ)底層數(shù)據(jù)AAHDFSBHadoopCMemoryDMapReduce4.HBase依賴（）提供消息通信機(jī)制AAZookeeperBChubbyCRPCDSocket5.HBase依賴（）提供強(qiáng)大的計(jì)算能力DAZookeeperBChubbyCRPCDMapReduce6.MapReduce與HBase的關(guān)系，哪些描述是對(duì)的的？B、CA兩者不可或缺，MapReduce是HBase可以正常運(yùn)行的保證B兩者不是強(qiáng)關(guān)聯(lián)關(guān)系，沒(méi)有MapReduce，HBase可以正常運(yùn)行CMapReduce可以直接訪問(wèn)HBaseD它們之間沒(méi)有任何關(guān)系7.下面哪些選項(xiàng)對(duì)的描述了HBase的特性？A、B、C、DA高可靠性B高性能C面向列D可伸縮8.下面哪些概念是HBase框架中使用的？A、CAHDFSBGridFSCZookeeperDEXT39.

D1.2.2

Hbase關(guān)鍵1.LSM含義是？AA曰志構(gòu)造合并樹B二叉樹C平衡二叉樹D長(zhǎng)平衡二叉樹2.下面對(duì)LSM構(gòu)造描述對(duì)的的是？A、CA次序存儲(chǔ)B直接寫硬盤C需要將數(shù)據(jù)Flush到磁盤D是一種搜索平衡樹3.LSM更能保證哪種操作的性能？BA讀B寫C隨機(jī)讀D合并4.LSM的讀操作和寫操作是獨(dú)立的？AA是。B否。CLSM并不辨別讀和寫DLSM中讀寫是同一種操作5.LSM構(gòu)造的數(shù)據(jù)首先存儲(chǔ)在（）。BA硬盤上B內(nèi)存中C磁盤陣列中D閃存中6.HFile數(shù)據(jù)格式中的Data字段用于（）。AA存儲(chǔ)實(shí)際的KeyValue數(shù)據(jù)B存儲(chǔ)數(shù)據(jù)的起點(diǎn)C指定字段的長(zhǎng)度D存儲(chǔ)數(shù)據(jù)塊的起點(diǎn)7.HFile數(shù)據(jù)格式中的MetaIndex字段用于（）。DAMeta塊的長(zhǎng)度BMeta塊的結(jié)束點(diǎn)CMeta塊數(shù)據(jù)內(nèi)容DMeta塊的起始點(diǎn)8.HFile數(shù)據(jù)格式中的Magic字段用于（）。AA存儲(chǔ)隨機(jī)數(shù)，防止數(shù)據(jù)損壞B存儲(chǔ)數(shù)據(jù)的起點(diǎn)C存儲(chǔ)數(shù)據(jù)塊的起點(diǎn)D指定字段的長(zhǎng)度9.HFile數(shù)據(jù)格式中的KeyValue數(shù)據(jù)格式，下列選項(xiàng)描述對(duì)的的是（）。A、DA是byte[]數(shù)組B沒(méi)有固定的構(gòu)造C數(shù)據(jù)的大小是定長(zhǎng)的D有固定的構(gòu)造10.

HFile數(shù)據(jù)格式中的KeyValue數(shù)據(jù)格式中Value部分是（）。CA擁有復(fù)雜構(gòu)造的字符串B字符串C二進(jìn)制數(shù)據(jù)D壓縮數(shù)據(jù)11.

D1.2.3

HBase高級(jí)應(yīng)用簡(jiǎn)介1.HBase中的批量加載底層使用（）實(shí)現(xiàn)。AAMapReduceBHiveCCoprocessorDBloomFilter2.HBase性能優(yōu)化包括下面的哪些選項(xiàng)？A、B、C、DA讀優(yōu)化B寫優(yōu)化C配置優(yōu)化DJVM優(yōu)化3.Rowkey設(shè)計(jì)的原則，下列哪些選項(xiàng)的描述是對(duì)的的？A、B、CA盡量保證越短越好B可以使用中文C可以使用字符串D自身是無(wú)序的4.HBase

構(gòu)建二級(jí)索引的實(shí)現(xiàn)方式有哪些？

A、BAMapReduceBCoprocessorCBloomFilterDFilter5.有關(guān)HBase二級(jí)索引的描述，哪些是對(duì)的的？A、BA關(guān)鍵是倒排表B二級(jí)索引概念是對(duì)應(yīng)Rowkey這個(gè)“一級(jí)”索引C二級(jí)索引使用平衡二叉樹D二級(jí)索引使用LSM構(gòu)造6.下列有關(guān)

BloomFilter

的描述對(duì)的的是？A、CA是一種很長(zhǎng)的二進(jìn)制向量和一系列隨機(jī)映射函數(shù)B沒(méi)有誤算率C有一定的誤算率D可以在BloomFilter中刪除元素7.D1.2.4

HBase安裝、布署、啟動(dòng)1.HBase官方版本可以安裝在什么操作系統(tǒng)上？A、B、CACentOSBUbuntuCRedHatDWindows2.HBase虛擬分布式模式需要（）個(gè)節(jié)點(diǎn)？AA1B2C3D至少3個(gè)3.HBase分布式模式最佳需要（）個(gè)節(jié)點(diǎn)？CA1B2C3D至少4.下列哪些選項(xiàng)是安裝HBase前所必須安裝的？A、BA操作系統(tǒng)BJDKCShellScriptDJavaCode5.解壓.tar.gz結(jié)尾的HBase壓縮包使用的Linux命令是？AAtar-zxvfBtar-zxCtar-sDtar-nf6.D7.D1.3Zookeeper選擇題1.3.1

Zookeeper基礎(chǔ)1.下面與Zookeeper類似的框架是？DAProtobufBJavaCKafkaDChubby2.的3.D4.D5.D6.D7.D8.D9.d

第2部分

判斷題第2部分2.1Hadoop判斷題2.1.1

集群管理1.Ganglia不僅可以進(jìn)行監(jiān)控，也可以進(jìn)行告警。（對(duì)的）解析：ganglia作為一款最常用的Linux環(huán)境中的監(jiān)控軟件，它擅長(zhǎng)的的是從節(jié)點(diǎn)中按照顧客的需求以較低的代價(jià)采集數(shù)據(jù)。不過(guò)ganglia在預(yù)警以及發(fā)生事件後告知顧客上并不擅長(zhǎng)。最新的ganglia已經(jīng)有了部分這方面的功能。不過(guò)更擅長(zhǎng)做警告的尚有Nagios。Nagios，就是一款精于預(yù)警、告知的軟件。通過(guò)將Ganglia和Nagios組合起來(lái)，把Ganglia采集的數(shù)據(jù)作為Nagios的數(shù)據(jù)源，然後運(yùn)用Nagios來(lái)發(fā)送預(yù)警告知，可以完美的實(shí)現(xiàn)一整套監(jiān)控管理的系統(tǒng)。2.Nagios不可以監(jiān)控Hadoop集群，由于它不提供Hadoop支持。（錯(cuò)誤）分析：Nagios是集群監(jiān)控工具，并且是雲(yún)計(jì)算三大利器之一3.假如NameNode意外終止，SecondaryNameNode會(huì)接替它使集群繼續(xù)工作。（錯(cuò)誤）分析：SecondaryNameNode是協(xié)助恢復(fù)，而不是替代4.ClouderaCDH是需要付費(fèi)使用的。（錯(cuò)誤）分析：第一套付費(fèi)產(chǎn)品是ClouderaEnterpris，ClouderaEnterprise在美國(guó)加州舉行的Hadoop大會(huì)(HadoopSummit)上公開(kāi)，以若干私有管理、監(jiān)控、運(yùn)作工具加強(qiáng)Hadoop的功能。收費(fèi)采用合約訂購(gòu)方式，價(jià)格隨用的Hadoop叢集大小變動(dòng)。5.NameNode負(fù)責(zé)管理metadata，client端每次讀寫祈求，它都會(huì)從磁盤中讀取或則會(huì)寫入metadata信息并反饋client端。（錯(cuò)誤）分析：NameNode不需要從磁盤讀取metadata，所有數(shù)據(jù)都在內(nèi)存中，硬盤上的只是序列化的成果，只有每次namenode啟動(dòng)的時(shí)候才會(huì)讀取。1）文獻(xiàn)寫入Client向NameNode發(fā)起文獻(xiàn)寫入的祈求。NameNode根據(jù)文獻(xiàn)大小和文獻(xiàn)塊配置狀況，返回給Client它所管理部分DataNode的信息。Client將文獻(xiàn)劃分為多種Block，根據(jù)DataNode的地址信息，按次序?qū)懭氲矫恳环NDataNode塊中。2）文獻(xiàn)讀取Client向NameNode發(fā)起文獻(xiàn)讀取的祈求。NameNode返回文獻(xiàn)存儲(chǔ)的DataNode的信息。Client讀取文獻(xiàn)信息。6.NameNode當(dāng)?shù)卮疟P保留了Block的位置信息。（個(gè)人認(rèn)為對(duì)的，歡迎提出其他意見(jiàn)）分析：DataNode是文獻(xiàn)存儲(chǔ)的基本單元，它將Block存儲(chǔ)在當(dāng)?shù)匚墨I(xiàn)系統(tǒng)中，保留了Block的Meta-data，同步周期性地將所有存在的Block信息發(fā)送給NameNode。7.DataNode通過(guò)長(zhǎng)連接與NameNode保持通信。錯(cuò)誤分析：通過(guò)心跳機(jī)制。（1）.長(zhǎng)連接Client方與Server方先建立通訊連接，連接建立後不停開(kāi)，然後再進(jìn)行報(bào)文發(fā)送和接受。這種方式下由于通訊連接一直存在，此種方式常用于點(diǎn)對(duì)點(diǎn)通訊。（2）.短連接Client方與Server每進(jìn)行一次報(bào)文收發(fā)交易時(shí)才進(jìn)行通訊連接，交易完畢後立即斷開(kāi)連接。此種方式常用于一點(diǎn)對(duì)多點(diǎn)通訊，例如多種Client連接一種Server.8.Hadoop自身具有嚴(yán)格的權(quán)限管理和安全措施保障集群正常運(yùn)行。（錯(cuò)誤）9.Slave節(jié)點(diǎn)要存儲(chǔ)數(shù)據(jù)，因此它的磁盤越大越好。（錯(cuò)誤）分析：一旦Slave節(jié)點(diǎn)宕機(jī)，數(shù)據(jù)恢復(fù)是一種難題10.

hadoopdfsadmin–report命令用于檢測(cè)HDFS損壞塊。（錯(cuò)誤）分析：hadoopdfsadmin-report用這個(gè)命令可以迅速定位出哪些節(jié)點(diǎn)down掉了，HDFS的容量以及使用了多少，以及每個(gè)節(jié)點(diǎn)的硬盤使用狀況。當(dāng)然NameNode有個(gè)http頁(yè)面也可以查詢，不過(guò)這個(gè)命令的輸出更適合我們的腳本監(jiān)控dfs的使用狀況11.

Hadoop默認(rèn)調(diào)度器方略為FIFO（對(duì)的）12.

集群內(nèi)每個(gè)節(jié)點(diǎn)都應(yīng)當(dāng)配RAID，這樣防止單磁盤損壞，影響整個(gè)節(jié)點(diǎn)運(yùn)行。（錯(cuò)誤）分析：首先明白什么是RAID：磁盤陣列（RedundantArraysofIndependentDisks，RAID．，有“獨(dú)立磁盤構(gòu)成的具有冗余能力的陣列”之意。這句話錯(cuò)誤的地方在于太絕對(duì)，詳細(xì)狀況詳細(xì)分析。題目不是重點(diǎn)，知識(shí)才是最重要的。由于hadoop自身就具有冗余能力，因此假如不是很嚴(yán)格不需要都配置RAID。13.

Hadoop環(huán)境變量中的HADOOP_HEAPSIZE用于設(shè)置所有Hadoop守護(hù)線程的內(nèi)存。它默認(rèn)是200GB。（錯(cuò)誤）分析：hadoop為各個(gè)守護(hù)進(jìn)程（namenode,secondarynamenode,jobtracker,datanode,tasktracker）統(tǒng)一分派的內(nèi)存在hadoop-env.sh中設(shè)置，參數(shù)為HADOOP_HEAPSIZE，默認(rèn)為1000M。14.

DataNode初次加入cluster的時(shí)候，假如log中匯報(bào)不兼容文獻(xiàn)版本，那需要NameNode執(zhí)行―Hadoopnamenode-format‖操作格式化磁盤。（錯(cuò)誤）分析：這個(gè)報(bào)錯(cuò)是闡明DataNode所裝的Hadoop版本和其他節(jié)點(diǎn)不一致，應(yīng)當(dāng)檢查DataNode的Hadoop版本

15.

D16.

D17.

的18.

D19.

的20.

D的21.

D的22.

D23.

d2.1.2

Hdfs1.BlockSize是不可以修改的。（錯(cuò)誤）解析：Hadoop的基礎(chǔ)配置文獻(xiàn)是hadoop-default.xml，默認(rèn)建立一種Job的時(shí)候會(huì)建立Job的Config，Config首先讀入hadoop-default.xml的配置，然後再讀入hadoop-site.xml的配置（這個(gè)文獻(xiàn)初始的時(shí)候配置為空），hadoop-site.xml中重要配置需要覆蓋的hadoop-default.xml的系統(tǒng)級(jí)配置。詳細(xì)配置可以參照下：<property>

<name>dfs.block.size</name>//block的大小，單位字節(jié)，背面會(huì)提到用處，必須是512的倍數(shù)，因?yàn)椴捎胏rc作文獻(xiàn)完整性校驗(yàn)，默認(rèn)配置512是checksum的最小單元。

<value>510</value>

<description>Thedefaultblocksizefornewfiles.</description></property>2.Hadoop支持?jǐn)?shù)據(jù)的隨機(jī)讀寫。（錯(cuò)）分析：lucene是支持隨機(jī)讀寫的，而hdfs只支持隨機(jī)讀。不過(guò)HBase可以來(lái)補(bǔ)救。HBase提供隨機(jī)讀寫，來(lái)處理Hadoop不能處理的問(wèn)題。HBase自底層設(shè)計(jì)開(kāi)始即聚焦于多種可伸縮性問(wèn)題：表可以很―高‖，有數(shù)拾億個(gè)數(shù)據(jù)行；也可以很―寬‖，有數(shù)百萬(wàn)個(gè)列；水平分區(qū)并在上仟個(gè)一般商用機(jī)節(jié)點(diǎn)上自動(dòng)復(fù)制。表的模式是物理存儲(chǔ)的直接反應(yīng)，使系統(tǒng)有也許提高高效的數(shù)據(jù)構(gòu)造的序列化、存儲(chǔ)和檢索。3.由于HDFS有多種副本，因此NameNode是不存在單點(diǎn)問(wèn)題的。（錯(cuò)誤）分析：副本針對(duì)DataName而講的

4.的5.的6.的2.1.3

MapReduce1.Hadoop是Java開(kāi)發(fā)的，因此MapReduce只支持Java語(yǔ)言編寫。（錯(cuò)誤）分析：支持c++等語(yǔ)言，需要通過(guò)接口。2.每個(gè)map槽就是一種線程。（錯(cuò)誤）分析：一種task對(duì)應(yīng)一種線程分析：首先我們懂得什么是map槽,map槽->mapslot，mapslot只是一種邏輯值(org.apache.hadoop.mapred.TaskTracker.TaskLauncher.numFreeSlots)，而不是對(duì)應(yīng)著一種線程或者進(jìn)程3.Mapreduce的inputsplit就是一種block。（錯(cuò)誤）分析：

應(yīng)當(dāng)是一種block數(shù)組1、運(yùn)行mapred程序；

2、本次運(yùn)行將生成一種Job，于是JobClient向JobTracker申請(qǐng)一種JobID以標(biāo)識(shí)這個(gè)Job；

3、JobClient將Job所需要的資源提交到HDFS中一種以JobID命名的目錄中。這些資源包括JAR包、配置文獻(xiàn)、InputSplit、等；

4、JobClient向JobTracker提交這個(gè)Job；

5、JobTracker初始化這個(gè)Job；

6、JobTracker從HDFS獲取這個(gè)Job的Split等信息；

7、JobTracker向TaskTracker分派任務(wù)；

8、TaskTracker從HDFS獲取這個(gè)Job的有關(guān)資源；

9、TaskTracker啟動(dòng)一種新的JVM；

10、TaskTracker用新的JVM來(lái)執(zhí)行Map或Reduce；

InputSplit也是一種interface，詳細(xì)返回什么樣的implement，這是由詳細(xì)的InputFormat來(lái)決定的。InputSplit也只有兩個(gè)接口函數(shù)：

longgetLength()throwsIOException;

String[]getLocations()throwsIOException;

這個(gè)interface僅僅描述了Split有多長(zhǎng)，以及寄存這個(gè)Split的Location信息（也就是這個(gè)Split在HDFS上寄存的機(jī)器。它也許有多種replication，存在于多臺(tái)機(jī)器上）。除此之外，就再?zèng)]有任何直接描述Split的信息了。例如：Split對(duì)應(yīng)于哪個(gè)文獻(xiàn)？在文獻(xiàn)中的起始和結(jié)束位置是什么？等等重要的特性都沒(méi)有描述到。

為何會(huì)這樣呢？由于有關(guān)Split的那些描述信息，對(duì)于MapReduce框架來(lái)說(shuō)是不需要關(guān)懷的?？蚣苤魂P(guān)懷Split的長(zhǎng)度（重要用于某些記錄信息）和Split的Location（重要用于Split的調(diào)度，背面會(huì)細(xì)說(shuō)）。

而Split中真正重要的描述信息還是只有InputFormat會(huì)關(guān)懷。在需要讀取一種Split的時(shí)候，其對(duì)應(yīng)的InputSplit會(huì)被傳遞到InputFormat的第二個(gè)接口函數(shù)getRecordReader，然後被用于初始化一種RecordReader，以解析輸入數(shù)據(jù)。也就是說(shuō)，描述Split的重要信息都被隱藏了，只有詳細(xì)的InputFormat自已懂得。它只需要保證getSplits返回的InputSplit和getRecordReader所關(guān)懷的InputSplit是同樣的implement就行了。這就給InputFormat的實(shí)現(xiàn)提供了巨大的靈活性。4.的5.的6.的7.D8.的第3部分

論述題第3部分3.1Hadoop論述題3.1.1

Hadoop布署1.hdfs的體系構(gòu)造解答：hdfs有namenode、secondraynamenode、datanode構(gòu)成。為n+1模式namenode負(fù)責(zé)管理datanode和記錄元數(shù)據(jù)secondraynamenode負(fù)責(zé)合并曰志datanode負(fù)責(zé)存儲(chǔ)數(shù)據(jù)

2.簡(jiǎn)要描述怎樣安裝配置一種apache開(kāi)原本hadoop，只描述即可，無(wú)需列出完整環(huán)節(jié)，能列出環(huán)節(jié)更好。流程：1.創(chuàng)立hadoop顧客2.修改IP3.安裝JDK，并配置環(huán)境變量4.修改host文獻(xiàn)映射5.安裝SSH，配置無(wú)秘鑰通信6.上傳解壓hadoop安裝包7.配置conf文獻(xiàn)夾下的hadoop-env.sh、core-site.xlmapre-site.xml、hdfs-site.xml8.配置hadoop的環(huán)境變量9.Hadoopnamenode-format10.start-all3.啟動(dòng)hadoop集群時(shí)報(bào)下圖錯(cuò)誤，分析什么原因：解答：1、權(quán)限問(wèn)題，也許曾經(jīng)用root啟動(dòng)過(guò)集群。(例如hadoop搭建的集群,是tmp/hadoop-hadoop/.....)2、也許是文獻(xiàn)夾不存在3、處理:刪掉tmp下的那個(gè)文獻(xiàn),或改成目前顧客

4.請(qǐng)列出hadoop的進(jìn)程名稱解答：1.namenode:管理集群，并記錄datanode文獻(xiàn)信息。2.Secondname:可以做冷備，對(duì)一定范圍內(nèi)的數(shù)據(jù)做快照性備份。3.Datanode：存儲(chǔ)數(shù)據(jù)。4.Jobtracker：管理任務(wù)，并將任務(wù)分派給tasktracker。5.Tasktracker:任務(wù)執(zhí)行者

5.Hadoop的關(guān)鍵配置是什么？解答：Hadoop的關(guān)鍵配置通過(guò)兩個(gè)xml文獻(xiàn)來(lái)完畢：1.hadoop-default.xml；2.hadoop-site.xml。這些文獻(xiàn)都使用xml格式，因此每個(gè)xml中均有某些屬性，包括名稱和值，不過(guò)當(dāng)下這些文獻(xiàn)都已不復(fù)存在。6.那當(dāng)下又該怎樣配置？解答：Hadoop目前擁有3個(gè)配置文獻(xiàn)：1，core-site.xml；2，hdfs-site.xml；3，mapred-site.xml。這些文獻(xiàn)都保留在conf/子目錄下。7.“jps”命令的用處？解答：這個(gè)命令可以檢查Namenode、Datanode、TaskTracker、JobTracker與否正常工作。

8.簡(jiǎn)要描述怎樣安裝配置一種apache開(kāi)源版hadoop，描述即可，列出環(huán)節(jié)更好解答：9.請(qǐng)列出正常工作的hadoop集群中hadoop都需要啟動(dòng)哪些進(jìn)程，他們的作用分別是什么？解答：10.

啟動(dòng)hadoop報(bào)如下錯(cuò)誤，該怎樣處理？errororg.apacheorg.apachenDirectory/tmp/hadoop-root/dfs/nameisinaninconsistentstatestoragedirectiondoesnotexistorisnotaccessible?11.

請(qǐng)寫出如下執(zhí)行命令1)殺死一種job?2)刪除hdfs上的/tmp/aaa目錄3)加入一種新的存儲(chǔ)節(jié)點(diǎn)和刪除一種計(jì)算節(jié)點(diǎn)需要刷新集群狀態(tài)命令？解答：hadoopjob-list記錄job-id、hadoopjob-killjob-id

hadoopfs-rmr/tmp/aaa

添加新節(jié)點(diǎn)：hadoop-daemon.shstartdatanodehadoop-daemon.shstarttasktracker

移除一種節(jié)點(diǎn)：hadoopmradmin-refreshnodeshadoopdfsadmin-refreshnodes12.

請(qǐng)列出你所懂得的hadoop調(diào)度器，并簡(jiǎn)要闡明其工作措施？解答：1.FIFOschedular:默認(rèn)，先進(jìn)先出的原則2.Capacityschedular:計(jì)算能力調(diào)度器，選擇占用最小，優(yōu)先級(jí)高的先執(zhí)行，以此類推。3.Fairschedular:公平調(diào)度，所有的job具有相似的資源。13.

請(qǐng)列出在你此前工作中所使用過(guò)的開(kāi)發(fā)mapreduce的語(yǔ)言？解答：14.

你認(rèn)為用Java，Streaming,pipe方式開(kāi)發(fā)mapreduce,各有哪些優(yōu)缺陷？解答：15.

hadoop框架中怎么來(lái)優(yōu)化解答：（1）

從應(yīng)用程序角度進(jìn)行優(yōu)化。由于mapreduce是迭代逐行解析數(shù)據(jù)文獻(xiàn)的，怎樣在迭代的狀況下，編寫高效率的應(yīng)用程序，是一種優(yōu)化思緒。（2）

對(duì)Hadoop參數(shù)進(jìn)行調(diào)優(yōu)。目前hadoop系統(tǒng)有190多種配置參數(shù)，怎樣調(diào)整這些參數(shù)，使hadoop作業(yè)運(yùn)行盡量的快，也是一種優(yōu)化思緒。（3）從系統(tǒng)實(shí)現(xiàn)角度進(jìn)行優(yōu)化。這種優(yōu)化難度是最大的，它是從hadoop實(shí)現(xiàn)機(jī)制角度，發(fā)現(xiàn)目前Hadoop設(shè)計(jì)和實(shí)現(xiàn)上的缺陷，然後進(jìn)行源碼級(jí)地修改。該措施雖難度大，但往往效果明顯。（4）linux內(nèi)核參數(shù)調(diào)整1.使用自定義Writable自帶的Text很好用，不過(guò)字符串轉(zhuǎn)換開(kāi)銷較大，故根據(jù)實(shí)際需要自定義Writable，注意作為Key時(shí)要實(shí)現(xiàn)WritableCompareable接口防止output.collect(newText(),newText())倡導(dǎo)key.set()value.set()output.collect(key,value)前者會(huì)產(chǎn)生大量的Text對(duì)象，使用完後Java垃圾回收器會(huì)花費(fèi)大量的時(shí)間去搜集這些對(duì)象

2.使用StringBuilder不要使用FormatterStringBuffer（

線程安全）StringBuffer盡量少使用多種append措施，合適使用+

3.使用DistributedCache加載文獻(xiàn)例如配置文獻(xiàn)，詞典，共享文獻(xiàn)，防止使用static變量

4.充足使用CombinerParttitionerComparator。Combiner:對(duì)map任務(wù)進(jìn)行當(dāng)?shù)鼐酆螾arttitioner：合適的Parttitioner防止reduce端負(fù)載不均Comparator：二次排序例如求每天的最大氣溫，map成果為曰期：氣溫，若氣溫是降序的，直接取列表首元素即可

5.使用自定義InputFormat和OutputFormat

6.MR應(yīng)防止

靜態(tài)變量：不能用于計(jì)數(shù)，應(yīng)使用Counter

大對(duì)象：MapList

遞歸：防止遞歸深度過(guò)大

超長(zhǎng)正則體現(xiàn)式：消耗性能，要在map或reduce函數(shù)外編譯正則體現(xiàn)式

不要?jiǎng)?chuàng)立當(dāng)?shù)匚墨I(xiàn)：變向的把HDFS裏面的數(shù)據(jù)轉(zhuǎn)移到TaskTracker，占用網(wǎng)絡(luò)帶寬

不要大量創(chuàng)立目錄和文獻(xiàn)

不要大量使用System.out.println，而使用Logger

不要自定義過(guò)多的Counter，最佳不要超過(guò)100個(gè)

不要配置過(guò)大內(nèi)存，mapred.-Xmxm是用來(lái)設(shè)置mapreduce任務(wù)使用的最大heap量

7.有關(guān)map的數(shù)目map數(shù)目過(guò)大[創(chuàng)立和初始化map的開(kāi)銷]，一般是由大量小文獻(xiàn)導(dǎo)致的，或者dfs.block.size設(shè)置的太小，對(duì)于小文獻(xiàn)可以archive文獻(xiàn)或者Hadoopfs-merge合并成一種大文獻(xiàn).map數(shù)目過(guò)少，導(dǎo)致單個(gè)map任務(wù)執(zhí)行時(shí)間過(guò)長(zhǎng)，頻繁推測(cè)執(zhí)行，且輕易內(nèi)存溢出，并行性優(yōu)勢(shì)不能體現(xiàn)出來(lái)。dfs.block.size一般為256M-512M壓縮的Text文獻(xiàn)是不能被分割的，因此盡量使用SequenceFile，可以切分

8.有關(guān)reduce的數(shù)目reduce數(shù)目過(guò)大，產(chǎn)生大量的小文獻(xiàn)，消耗大量不必要的資源，reduce數(shù)目過(guò)低呢，導(dǎo)致數(shù)據(jù)傾斜問(wèn)題，且一般不能通過(guò)修改參數(shù)變化?？蛇x方案：mapred.reduce.tasks設(shè)為-1變成AutoReduce。Key的分布，也在某種程度上決定了Reduce數(shù)目，因此要根據(jù)Key的特點(diǎn)設(shè)計(jì)相對(duì)應(yīng)的Parttitioner防止數(shù)據(jù)傾斜

9.Map-side有關(guān)參數(shù)優(yōu)化io.sort.mb（100MB．：一般k個(gè)maptasks會(huì)對(duì)應(yīng)一種buffer，buffer重要用來(lái)緩存map部分計(jì)算成果，并做某些預(yù)排序提高map性能，若map輸出成果較大，可以調(diào)高這個(gè)參數(shù)，減少map任務(wù)進(jìn)行spill任務(wù)個(gè)數(shù)，減少I/O的操作次數(shù)。若map任務(wù)的瓶頸在I/O的話，那么將會(huì)大大提高map性能。怎樣判斷map任務(wù)的瓶頸？io.sort.spill.percent(0.8)：spill操作就是當(dāng)內(nèi)存buffer超過(guò)一定閾值（這裏一般是比例）的時(shí)候，會(huì)將buffer中得數(shù)據(jù)寫到Disk中。而不是等buffer滿後在spill，否則會(huì)導(dǎo)致map的計(jì)算任務(wù)等待buffer的釋放。一般來(lái)說(shuō)，調(diào)整io.sort.mb而不是這個(gè)參數(shù)。io.sort.factor（10）：map任務(wù)會(huì)產(chǎn)生諸多的spill文獻(xiàn)，而map任務(wù)在正常退出之前會(huì)將這些spill文獻(xiàn)合并成一種文獻(xiàn)，即merger過(guò)程，缺省是一次合并10個(gè)參數(shù)，調(diào)大io.sort.factor，減少merge的次數(shù)，減少DiskI/O操作，提高map性能。：一般為了減少map和reduce數(shù)據(jù)傳播量，我們會(huì)制定一種combiner，將map成果進(jìn)行當(dāng)?shù)貐R集。這裏combiner也許在merger之前，也也許在其之後。那么什么時(shí)候在其之前呢？當(dāng)spill個(gè)數(shù)至少為bine指定的數(shù)目時(shí)同步程序指定了Combiner，Combiner會(huì)在其之前運(yùn)行，減少寫入到Disk的數(shù)據(jù)量，減少I/O次數(shù)。

10.壓縮（時(shí)間換空間）MR中的數(shù)據(jù)無(wú)論是中間數(shù)據(jù)還是輸入輸出成果都是巨大的，若不使用壓縮不僅揮霍磁盤空間且會(huì)消耗大量網(wǎng)絡(luò)帶寬。同樣在spill，merge（reduce也對(duì)有一種merge）亦可以使用壓縮。若想在cpu時(shí)間和壓縮比之間尋找一種平衡，LzoCodec比較適合。一般MR任務(wù)的瓶頸不在CPU而在于I/O，因此大部分的MR任務(wù)都適合使用壓縮。

11.reduce-side有關(guān)參數(shù)優(yōu)化reduce：copy->sort->reduce，也稱shufflemapred.reduce.parellel.copies（5）：任一種map任務(wù)也許包括一種或者多種reduce所需要數(shù)據(jù)，故一種map任務(wù)完畢後，對(duì)應(yīng)的reduce就會(huì)立即啟動(dòng)線程下載自已所需要的數(shù)據(jù)。調(diào)大這個(gè)參數(shù)比較適合map任務(wù)比較多且完畢時(shí)間比較短的Job。mapred.reduce.copy.backoff：reduce端從map端下載數(shù)據(jù)也有也許由于網(wǎng)絡(luò)故障，map端機(jī)器故障而失敗。那么reduce下載線程肯定不會(huì)無(wú)限等待，當(dāng)?shù)却龝r(shí)間超過(guò)mapred.reduce.copy.backoff時(shí)，便放棄，嘗試從其他地方下載。需注意：在網(wǎng)絡(luò)狀況比較差的環(huán)境，我們需要調(diào)大這個(gè)參數(shù)，防止reduce下載線程被誤判為失敗。io.sort.factor：recude將map成果下載到當(dāng)?shù)貢r(shí)，亦需要merge，假如reduce的瓶頸在于I/O，可嘗試調(diào)高增長(zhǎng)merge的并發(fā)吞吐，提高reduce性能、.input.buffer.percent（0.7）：reduce從map下載的數(shù)據(jù)不會(huì)立即就寫到Disk中，而是先緩存在內(nèi)存中，mapred.job.shuffle.input.buffer.percent指定內(nèi)存的多少比例用于緩存數(shù)據(jù)，內(nèi)存大小可通過(guò)mapred.child.java.opts來(lái)設(shè)置。和map類似，buffer不是等到寫滿才往磁盤中寫，也是抵達(dá)閾值就寫，閾值由mapred.job,shuffle.merge.percent來(lái)指定。若Reduce下載速度很快，輕易內(nèi)存溢出，合適增大這個(gè)參數(shù)對(duì)增長(zhǎng)reduce性能有些協(xié)助。.input.buffer.percent(0)：當(dāng)Reduce下載map數(shù)據(jù)完畢之後，就會(huì)開(kāi)始真正的reduce的計(jì)算，reduce的計(jì)算必然也是要消耗內(nèi)存的，那么在讀物reduce所需要的數(shù)據(jù)時(shí)，同樣需要內(nèi)存作為buffer，這個(gè)參數(shù)是決定多少的內(nèi)存比例作為buffer。默認(rèn)為0，也就是說(shuō)reduce所有從磁盤讀數(shù)據(jù)。若redcue計(jì)算任務(wù)消耗內(nèi)存很小，那么可以設(shè)置這個(gè)參數(shù)不小于0，使一部分內(nèi)存用來(lái)緩存數(shù)據(jù)。

16.

從應(yīng)用程序角度進(jìn)行優(yōu)化解答：（1）防止不必要的reduce任務(wù)假如mapreduce程序中reduce是不必要的，那么我們可以在map中處理數(shù)據(jù),Reducer設(shè)置為0。這樣防止了多出的reduce任務(wù)。（2）為job添加一種Combiner為job添加一種combiner可以大大減少shuffle階段從maptask拷貝給遠(yuǎn)程reducetask的數(shù)據(jù)量。一般而言，combiner與reducer相似。（3）根據(jù)處理數(shù)據(jù)特性使用最適合和簡(jiǎn)潔的Writable類型Text對(duì)象使用起來(lái)很以便，但它在由數(shù)值轉(zhuǎn)換到文本或是由UTF8字符串轉(zhuǎn)換到文本時(shí)都是低效的，且會(huì)消耗大量的CPU時(shí)間。當(dāng)處理那些非文本的數(shù)據(jù)時(shí)，可以使用二進(jìn)制的Writable類型，如IntWritable，F(xiàn)loatWritable等。二進(jìn)制writable好處：防止文獻(xiàn)轉(zhuǎn)換的消耗；使maptask中間成果占用更少的空間。（4）重用Writable類型諸多MapReduce顧客常犯的一種錯(cuò)誤是，在一種map/reduce措施中為每個(gè)輸出都創(chuàng)立Writable對(duì)象。例如，你的Wordcoutmapper措施也許這樣寫：

publicvoidmap(...){

…

for(Stringword:words){

output.collect(newText(worD．,newIntWritable(1));

}}這樣會(huì)導(dǎo)致程序分派出成仟上萬(wàn)個(gè)短周期的對(duì)象。Java垃圾搜集器就要為此做諸多的工作。更有效的寫法是：classMyMapper…{

TextwordText=newText();

IntWritableone=newIntWritable(1);

publicvoidmap(...){

for(Stringword:words){wordText.set(worD．;output.collect(wordText,one);

}

}}（5）使用StringBuffer而不是String當(dāng)需要對(duì)字符串進(jìn)行操作時(shí)，使用StringBuffer而不是String，String是read-only的，假如對(duì)它進(jìn)行修改，會(huì)產(chǎn)生臨時(shí)對(duì)象，而StringBuffer是可修改的，不會(huì)產(chǎn)生臨時(shí)對(duì)象。17.

datanode在什么狀況下不會(huì)備份解答：當(dāng)分備份數(shù)為1時(shí)。18.

combiner出目前那個(gè)過(guò)程解答：出目前map階段的map措施後。19.

3個(gè)datanode中有一種datanode出現(xiàn)錯(cuò)誤會(huì)怎樣？解答：這個(gè)datanode的數(shù)據(jù)會(huì)在其他的datanode上重新做備份。20.

描述一下hadoop中，有哪些地方使用了緩存機(jī)制，作用分別是什么？解答：

21.

怎樣確定hadoop集群的健康狀態(tài)解答：

22.

hadoop的namenode宕機(jī),怎么處理解答：先分析宕機(jī)後的損失，宕機(jī)後直接導(dǎo)致client無(wú)法訪問(wèn)，內(nèi)存中的元數(shù)據(jù)丟失，不過(guò)硬盤中的元數(shù)據(jù)應(yīng)當(dāng)還存在，假如只是節(jié)點(diǎn)掛了，重啟即可，假如是機(jī)器掛了，重啟機(jī)器後看節(jié)點(diǎn)與否能重啟，不能重啟就要找到原因修復(fù)了。不過(guò)最終的處理方案應(yīng)當(dāng)是在設(shè)計(jì)集群的初期就考慮到這個(gè)問(wèn)題，做namenode的HA。

23.

一種datanode宕機(jī),怎么一種流程恢復(fù)解答：Datanode宕機(jī)了後，假如是短暫的宕機(jī)，可以實(shí)現(xiàn)寫好腳本監(jiān)控，將它啟動(dòng)起來(lái)。假如是長(zhǎng)時(shí)間宕機(jī)了，那么datanode上的數(shù)據(jù)應(yīng)當(dāng)已經(jīng)被備份到其他機(jī)器了，那這臺(tái)datanode就是一臺(tái)新的datanode了，刪除他的所有數(shù)據(jù)文獻(xiàn)和狀態(tài)文獻(xiàn)，重新啟動(dòng)。24.

的25.

D26.

的27.

的28.

的29.

的30.

d3.1.2

Hadoop原理1.請(qǐng)簡(jiǎn)述hadoop怎么樣實(shí)現(xiàn)二級(jí)排序？解答：在Reduce階段，先對(duì)Key排序，再對(duì)Value排序最常用的措施是將Value放到Key中，實(shí)現(xiàn)一種組合Key，然後自定義Key排序規(guī)則（為Key實(shí)現(xiàn)一種WritableComparable）。2.怎樣使用MapReduce實(shí)現(xiàn)兩個(gè)表join，可以考慮一下幾種狀況：（1）一種表大，一種表?。煞诺絻?nèi)存中）；（2）兩個(gè)表都是大表？解答：第一種狀況比較簡(jiǎn)樸，只需將小表放到DistributedCache中即可；第二種狀況常用的措施有：map-sidejoin（規(guī)定輸入數(shù)據(jù)有序，一般顧客Hbase中的數(shù)據(jù)表連接），reduce-sidejoin，semijoin（半連接）3.MapReduce中排序發(fā)生在哪幾種階段？這些排序與否可以防止？為何？解答：一種MapReduce作業(yè)由Map階段和Reduce階段兩部分構(gòu)成，這兩階段會(huì)對(duì)數(shù)據(jù)排序，從這個(gè)意義上說(shuō)，MapReduce框架本質(zhì)就是一種DistributedSort。在Map階段，在Map階段，MapTask會(huì)在當(dāng)?shù)卮疟P輸出一種按照key排序（采用的是迅速排序）的文獻(xiàn)（中間也許產(chǎn)生多種文獻(xiàn)，但最終會(huì)合并成一種），在Reduce階段，每個(gè)ReduceTask會(huì)對(duì)收到的數(shù)據(jù)排序，這樣，數(shù)據(jù)便按照Key提成了若干組，之後以組為單位交給reduce（）處理。諸多人的誤解在Map階段，假如不使用Combiner便不會(huì)排序，這是錯(cuò)誤的，不管你用不用Combiner，MapTask均會(huì)對(duì)產(chǎn)生的數(shù)據(jù)排序（假如沒(méi)有ReduceTask，則不會(huì)排序，實(shí)際上Map階段的排序就是為了減輕Reduce端排序負(fù)載）。由于這些排序是MapReduce自動(dòng)完畢的，顧客無(wú)法控制，因此，在hadoop1.x中無(wú)法防止，也不可以關(guān)閉，但hadoop2.x是可以關(guān)閉的。

4.請(qǐng)簡(jiǎn)述mapreduce中，combiner，partition作用？解答：combiner是reduce的實(shí)現(xiàn)，在map端運(yùn)行計(jì)算任務(wù)，減少map端的輸出數(shù)據(jù)。作用就是優(yōu)化。不過(guò)combiner的使用場(chǎng)景是mapreduce的map輸出成果和reduce輸入輸出同樣。

partition的默認(rèn)實(shí)現(xiàn)是hashpartition，是map端將數(shù)據(jù)按照reduce個(gè)數(shù)取余，進(jìn)行分區(qū)，不一樣的reduce來(lái)copy自已的數(shù)據(jù)。partition的作用是將數(shù)據(jù)分到不一樣的reduce進(jìn)行計(jì)算，加緊計(jì)算效果。

1、combiner最基本是實(shí)現(xiàn)當(dāng)?shù)豮ey的聚合，對(duì)map輸出的key排序，value進(jìn)行迭代。如下所示：map:(K1,V1)→list(K2,V2)combine:(K2,list(V2))→list(K2,V2)reduce:(K2,list(V2))→list(K3,V3)2、combiner還具有類似當(dāng)?shù)氐膔educe功能.例如hadoop自帶的wordcount的例子和找出value的最大值的程序，combiner和reduce完全一致。如下所示：map:(K1,V1)→list(K2,V2)combine:(K2,list(V2))→list(K3,V3)reduce:(K3,list(V3))→list(K4,V4)3、假如不用combiner，那么，所有的成果都是reduce完畢，效率會(huì)相對(duì)低下。使用combiner，先完畢的map會(huì)在當(dāng)?shù)鼐酆?，提高速度?、對(duì)于hadoop自帶的wordcount的例子，value就是一種疊加的數(shù)字，因此map一結(jié)束就可以進(jìn)行reduce的value疊加，而不必要等到所有的map結(jié)束再去進(jìn)行reduce的value疊加。combiner使用的合適，可以在滿足業(yè)務(wù)的狀況下提高job的速度，假如不合適，則將導(dǎo)致輸出的成果不對(duì)的。

5.解釋―hadoop‖和―hadoop生態(tài)系統(tǒng)‖兩個(gè)概念解答：6.闡明Hadoop2.0的基本構(gòu)成解答：分別闡明hdfs，yarn，mapreduce7.相比于HDFS1.0,HDFS2.0最重要的改善在哪幾方面？解答：8.試使用―環(huán)節(jié)1，環(huán)節(jié)2，環(huán)節(jié)3…..‖闡明YARN中運(yùn)行應(yīng)用程序的基本流程解答：9.―MapReduce2.0‖與―YARN‖與否等同，嘗試解釋闡明解答：10.

MapReduce2.0中，MRAppMaster重要作用是什么，MRAppMaster怎樣實(shí)現(xiàn)任務(wù)容錯(cuò)的？解答：11.

hdfs原理，以及各個(gè)模塊的職責(zé)解答：12.

mr的工作原理解答：Map—combiner—partition—sort—copy—sort—grouping—reduce13.

map措施是怎樣調(diào)用reduce措施的解答：14.

shell怎樣判斷文獻(xiàn)與否存在，假如不存在該怎樣處理？解答：15.

fsimage和edit的區(qū)別？解答：16.

hadoop1和hadoop2的區(qū)別？解答：17.

hdfs中的block默認(rèn)報(bào)錯(cuò)幾份？解答：18.

哪個(gè)程序一般與nn在一種節(jié)點(diǎn)啟動(dòng)？并做分析解答：19.

列舉幾種配置文獻(xiàn)優(yōu)化？解答：20.

datanode初次加入cluster的時(shí)候，假如log匯報(bào)不兼容文獻(xiàn)版本，那需要namenode執(zhí)行格式化操作，這樣處理的原因是？解答：21.

用mapreduce怎么處理數(shù)據(jù)傾斜問(wèn)題？解答：數(shù)據(jù)傾斜：map/reduce程序執(zhí)行時(shí)，reduce節(jié)點(diǎn)大部分執(zhí)行完畢，不過(guò)有一種或者幾種reduce節(jié)點(diǎn)運(yùn)行很慢，導(dǎo)致整個(gè)程序的處理時(shí)間很長(zhǎng)，這是由于某一種key的條數(shù)比其他key多諸多（有時(shí)是百倍或者仟倍之多），這條key所在的reduce節(jié)點(diǎn)所處理的數(shù)據(jù)量比其他節(jié)點(diǎn)就大諸多，從而導(dǎo)致某幾種節(jié)點(diǎn)遲遲運(yùn)行不完，此稱之為數(shù)據(jù)傾斜。

用hadoop程序進(jìn)行數(shù)據(jù)關(guān)聯(lián)時(shí)，常碰到數(shù)據(jù)傾斜的狀況，這裏提供一種處理措施。自已實(shí)現(xiàn)partition類，用key和value相加取hash值：方式1：源代碼：public

int

getPartition(K

key,V

value,

int

numReduceTasks){

return

(key.hashCode()&Integer.MAX_VALUE)%

numReduceTasks;

}修改後public

int

getPartition(K

key,V

value,

int

numReduceTasks){

return

((（key).hashCode()+value.hashCode()）

&Integer.MAX_VALUE)%

numReduceTasks;

}

方式2：public

class

HashPartitioner<K,V>

extends

Partitioner<K,V>{private

int

aa=0;

/**Use

{@linkObject#hashCode()}

topartition.*/

public

int

getPartition(K

key,V

value,

int

numReduceTasks){

return

(key.hashCode()+(aa++)&Integer.MAX_VALUE)%

numReduceTasks;

}

22.

談?wù)剶?shù)據(jù)傾斜，怎樣發(fā)生的，并給出優(yōu)化方案解答：23.

mapreduce基本執(zhí)行過(guò)程解答：24.

談?wù)刪adoop1和hadoop2的區(qū)別解答：25.

hadoop中Combiner的作用?解答：combiner是reduce的實(shí)現(xiàn)，在map端運(yùn)行計(jì)算任務(wù)，減少map端的輸出數(shù)據(jù)。作用就是優(yōu)化。不過(guò)combiner的使用場(chǎng)景是mapreduce的map和reduce輸入輸出同樣。26.

Mapreduce的map數(shù)量和reduce數(shù)量怎么確定,怎么配置解答：map的數(shù)量有數(shù)據(jù)塊決定，reduce數(shù)量隨便配置。27.

在hadoop中文獻(xiàn)的壓縮帶來(lái)了兩大好處：解答：（1）它減少了存儲(chǔ)文獻(xiàn)所需的空間；（2）加緊了數(shù)據(jù)在網(wǎng)絡(luò)上或者從磁盤上或到磁盤上的傳播速度；28.

mapreduce的調(diào)度模式解答：一種MapReduce作業(yè)的生命周期大體分為5個(gè)階段

【1】

：1.

作業(yè)提交與初始化2.

任務(wù)調(diào)度與監(jiān)控3.任務(wù)運(yùn)行環(huán)境準(zhǔn)備4.任務(wù)執(zhí)行5.作業(yè)完畢我們假設(shè)JobTracker已經(jīng)啟動(dòng)，那么調(diào)度器是怎么啟動(dòng)的？JobTracker在啟動(dòng)時(shí)有如下代碼：JobTrackertracker=startTracker(newJobConf());tracker.offerService();其中offerService措施負(fù)責(zé)啟動(dòng)JobTracker提供的各個(gè)服務(wù)，有這樣一行代碼：taskScheduler.start();taskScheduler即為任務(wù)調(diào)度器。start措施是抽象類TaskScheduler提供的接口，用于啟動(dòng)調(diào)度器。每個(gè)調(diào)度器類都要繼承TaskScheduler類?；貞浺幌拢{(diào)度器啟動(dòng)時(shí)會(huì)將各個(gè)監(jiān)聽(tīng)器對(duì)象注冊(cè)到JobTracker，以FIFO調(diào)度器JobQueueTaskScheduler為例：@Override

publicsynchronizedvoidstart()throwsIOException{

super.start();

taskTrackerManager.addJobInProgressListener(jobQueueJobInProgressListener);

eagerTaskInitializationListener.setTaskTrackerManager(taskTrackerManager);

eagerTaskInitializationListener.start();

taskTrackerManager.addJobInProgressListener(

eagerTaskInitializationListener);

}這裏注冊(cè)了兩個(gè)監(jiān)聽(tīng)器，其中eagerTaskInitializationListener負(fù)責(zé)作業(yè)初始化，而jobQueueJobInProgressListener則負(fù)責(zé)作業(yè)的執(zhí)行和監(jiān)控。當(dāng)有作業(yè)提交到JobTracker時(shí)，JobTracker會(huì)執(zhí)行所有訂閱它消息的監(jiān)聽(tīng)器的jobAdded措施。對(duì)于eagerTaskInitializationListener來(lái)說(shuō)：

@Override

publicvoidjobAdded(JobInProgressjoB．{

synchronized(jobInitQueue){jobInitQueue.add(joB．;resortInitQueue();jobInitQueue.notifyAll();

}

}提交的作業(yè)的JobInProgress對(duì)象被添加到作業(yè)初始化隊(duì)列jobInitQueue中，并喚醒初始化線程（若本來(lái)沒(méi)有作業(yè)可以初始化）：classJobInitManagerimplementsRunnable{

publicvoidrun(){JobInProgressjob=null;while(true){

try{synchronized(jobInitQueue){while(jobInitQueue.isEmpty()){

jobInitQueue.wait();}job=jobInitQueue.remove(0);}threadPool.execute(newInitJob(joB．);

}catch(InterruptedExceptiont){LOG.info("JobInitManagerThreadinterrupted.");break;

}}threadPool.shutdownNow();

}

}這種工作方式是一種“生產(chǎn)者-消費(fèi)者”模式：作業(yè)初始化線程是消費(fèi)者，而監(jiān)聽(tīng)器eagerTaskInitializationListener是生產(chǎn)者。這裏可以有多種消費(fèi)者線程，放到一種固定資源的線程池中，線程個(gè)數(shù)通過(guò)mapred.jobinit.threads參數(shù)配置，默認(rèn)為4個(gè)。下面我們重點(diǎn)來(lái)看調(diào)度器中的另一種監(jiān)聽(tīng)器。

jobQueueJobInProgressListener對(duì)象在調(diào)度器中初始化時(shí)持續(xù)執(zhí)行了兩個(gè)構(gòu)造器完畢初始化：publicJobQueueJobInProgressListener(){

this(newTreeMap<JobSchedulingInfo,JobInProgress>(FIFO_JOB_QUEUE_COMPARATOR));

}

/**

*Forclientsthatwanttoprovidetheirownjobpriorities.

*@paramjobQueueAcollectionwhoseiteratorreturnsjobsinpriorityorder.

*/

protectedJobQueueJobInProgressListener(Map<JobSchedulingInfo,JobInProgress>jobQueue){

this.jobQueue=Collections.synchronizedMap(jobQueue);

}其中，第一種構(gòu)造器調(diào)用重載的第二個(gè)構(gòu)造器。可以看到，調(diào)度器使用一種隊(duì)列jobQueue來(lái)保留提交的作業(yè)。這個(gè)隊(duì)列使用一種TreeMap對(duì)象實(shí)現(xiàn)，TreeMap的特點(diǎn)是底層使用紅黑樹實(shí)現(xiàn)，可以按照鍵來(lái)排序，并且由于是平衡樹，效率較高。作為鍵的是一種JobSchedulingInfo對(duì)象，作為值就是提交的作業(yè)對(duì)應(yīng)的JobInProgress對(duì)象。此外，由于TreeMap自身不是線程安全的，這裏使用了集合類的同步措施構(gòu)造了一種線程安全的Map。使用帶有排序功能的數(shù)據(jù)構(gòu)造的目的是使作業(yè)在隊(duì)列中按照優(yōu)先級(jí)的大小排列，這樣每次調(diào)度器只需從隊(duì)列頭部獲得作業(yè)即可。作業(yè)的次序由優(yōu)先級(jí)決定，而優(yōu)先級(jí)信息包括在JobSchedulingInfo對(duì)象中：staticclassJobSchedulingInfo{

privateJobPrioritypriority;

privatelongstartTime;

privateJobIDid;...}該對(duì)象包括了作業(yè)的優(yōu)先級(jí)、ID和開(kāi)始時(shí)間等信息。在Hadoop中，作業(yè)的優(yōu)先級(jí)有如下五種：VERY_HIGH、HIGH、NORMAL、LOW、VERY_LOW。這些字段是通過(guò)作業(yè)的JobStatus對(duì)象初始化的。由于該對(duì)象作為TreeMap的鍵，因此要實(shí)現(xiàn)自已的equals措施和hashCode措施：@Override

publicbooleanequals(Objectobj){if(obj==null||obj.getClass()!=JobSchedulingInfo.class){

returnfalse;}elseif(obj==this){

returntrue;}elseif(objinstanceofJobSchedulingInfo){

JobSchedulingInfothat=(JobSchedulingInfo)obj;

return((that.iD．&&this.startTime==that.startTime&&this.priority==that.priority);}returnfalse;

}我們看到，兩個(gè)JobSchedulingInfo對(duì)象相等的條件是類型一致，并且作業(yè)ID、開(kāi)始時(shí)間和優(yōu)先級(jí)都相等。hashCode的計(jì)算比較簡(jiǎn)樸：@Override

publicinthashCode(){return(int)(id.hashCode()*priority.hashCode()+startTime);

}注意，監(jiān)聽(tīng)器的第一種構(gòu)造器有一種比較器參數(shù)，用于定義

JobSchedulingInfo的比較方式：staticfinalComparator<JobSchedulingInfo>FIFO_JOB_QUEUE_COMPARATOR

=newComparator<JobSchedulingInfo>(){

publicintcompare(JobSchedulingInfoo1,JobSchedulingInfoo2){intres=o1.getPriority().compareTo(o2.getPriority());if(res==0){

if(o1.getStartTime()<o2.getStartTime()){res=-1;

}else{res=(o1.getStartTime()==o2.getStartTime()?0:1);}}if(res==0){

res=o1.getJobID().compareTo(o2.getJobID());}returnres;

}

};從上面看出，首先比較作業(yè)的優(yōu)先級(jí)，若優(yōu)先級(jí)相等則比較開(kāi)始時(shí)間（FIFO），若再相等則比較作業(yè)ID。

我們?cè)趯?shí)現(xiàn)自已的調(diào)度器時(shí)也許要定義自已的作業(yè)隊(duì)列，那么作業(yè)在隊(duì)列中的次序（即

JobSchedulingInfo的比較器

）就要仔細(xì)定義，這是調(diào)度器可以正常運(yùn)行基礎(chǔ)。Hadoop中的作業(yè)調(diào)度采用pull方式，即TaskTracker定期向JobTracker發(fā)送心跳信息索取一種新的任務(wù)，這些信息包括數(shù)據(jù)結(jié)點(diǎn)上作業(yè)和任務(wù)的運(yùn)行狀況，以及該TaskTracker上的資源使用狀況。JobTracker會(huì)根據(jù)以上信息更新作業(yè)隊(duì)列的狀態(tài)，并調(diào)用調(diào)度器選擇一種或多種任務(wù)以心跳響應(yīng)的形式返回給TaskTracker。從上面描述可以看出，JobTracker和taskScheduler之間的互相運(yùn)用關(guān)系：前者運(yùn)用後者為TaskTracker分派任務(wù)；後者運(yùn)用前者更新隊(duì)列和作業(yè)信息。接下來(lái)，我們一步步詳述該過(guò)程。首先，當(dāng)一種心跳抵達(dá)JobTracker時(shí)（實(shí)際上這是一種來(lái)自TaskTracker的遠(yuǎn)程過(guò)程調(diào)用

heartbeat措施

，協(xié)議接口是InterTrackerProtocol），會(huì)執(zhí)行兩種動(dòng)作：更新?tīng)顟B(tài)和下達(dá)命令

【1】

。下達(dá)命令稍後關(guān)注。有關(guān)更新?tīng)顟B(tài)的某些代碼片段如下：if(!processHeartbeat(status,initialContact,now)){if(prevHeartbeatResponse!=null){

trackerToHeartbeatResponseMap.remove(trackerName);}returnnewHeartbeatResponse(newResponseId,newTaskTrackerAction[]{newReinitTrackerAction()});

}詳細(xì)的心跳處理，由私有函數(shù)processHeartbeat完畢。該函數(shù)中有如下兩個(gè)措施調(diào)用：updateTaskStatuses(trackerStatus);

updateNodeHealthStatus(trackerStatus,timeStamp);分別用來(lái)更新任務(wù)的狀態(tài)和結(jié)點(diǎn)的健康狀態(tài)。在第一種措施中有下面代碼片段：TaskInProgresstip=taskidToTIPMap.get(taskID．;//Checkifthetipisknowntothejobtracker.Incaseofarestarted//jt,sometasksmightjoininlaterif(tip!=null||hasRestarted()){

if(tip==null){tip=job.getTaskInProgress(taskId.getTaskID());job.addRunningTaskToTIP(tip,taskId,status,false);

}

//Updatethejobandinformthelistenersifnecessary

JobStatusprevStatus=(JobStatus)job.getStatus().clone();

//CloneTaskStatusobjecthere,becauseJobInProgress

//orTaskInProgresscanmodifythisobjectand

//thechangesshouldnotgetreflectedinTaskTrackerStatus.

//AnoldTaskTrackerStatusisusedlaterincountMapTasks,etc.

job.updateTaskStatus(tip,(TaskStatus)report.clone());

JobStatusnewStatus=(JobStatus)job.getStatus().clone();

//Updatethelistenersifanincompletejobcompletes

if(prevStatus.getRunState()!=newStatus.getRunState()){JobStatusChangeEventevent=newJobStatusChangeEvent(job,EventType.RUN_STATE_CHANGED,prevStatus,newStatus);updateJobInProgressListeners(event);

}}else{

LOG.info("Seriousproblem.

Whileupdatingstatus,cannotfindtaskid"

+report.getTaskID());}這裏的job對(duì)象通過(guò)從TaskTracker那裏得到的task狀態(tài)信息中抽取出來(lái)。注意，這裏拷貝了原有作業(yè)狀態(tài)的一種副本，然後修改這個(gè)副本的有關(guān)信息，調(diào)用的是updateJobStatus措施，更新任務(wù)的狀態(tài)信息和JobInProgress的有關(guān)信息，如map和reduce任務(wù)的進(jìn)度等，這裏不展開(kāi)了。這些信息的更新可認(rèn)為調(diào)度器的工作提供根據(jù)。作業(yè)狀態(tài)的更新是通過(guò)updateJobInProgressListeners措施實(shí)現(xiàn)，該措施的參數(shù)是一種JobStatusChangeEvent對(duì)象，表達(dá)作業(yè)狀態(tài)變化的事件。這種事件的類型可以是運(yùn)行狀態(tài)變化、開(kāi)始時(shí)間變化、優(yōu)先級(jí)變化等等。顧客也可以根據(jù)需要自定義事件類型。事件對(duì)象維護(hù)了兩個(gè)JobStatus對(duì)象，分別表達(dá)事件發(fā)生前後作業(yè)的狀態(tài)。

進(jìn)入該措施後，我們又看到了熟悉的觀測(cè)者模式：//Updatethelistenersaboutthejob

//AssumingJobTrackerislockedonentry.

privatevoidupdateJobInProgressListeners(JobChangeEventevent){

for(JobInProgressListenerlistener:jobInProgressListeners){listener.jobUpdated(event);

}

}這次每個(gè)監(jiān)聽(tīng)器要回調(diào)jobUpdated措施，表達(dá)作業(yè)有更新。對(duì)于jobQueueJobInProgressListener來(lái)說(shuō)是這樣做的：@Override

publicsynchronizedvoidjobUpdated(JobChangeEventevent){

JobInProgressjob=event.getJobInProgress();

if(eventinstanceofJobStatusChangeEvent){//Checkiftheorderingofthejobhaschanged//Fornowpriorityandstart-timecanchangethejoborderingJobStatusChangeEventstatusEvent=(JobStatusChangeEvent)event;JobSchedulingInfooldInfo=

newJobSchedulingInfo(statusEvent.getOldStatus());if(statusEvent.getEventType()==EventType.PRIORITY_CHANGED||statusEvent.getEventType()==EventType.START_TIME_CHANGED．{

//Makeaprioritychange

reorderJobs(job,oldInfo);}elseif(statusEvent.getEventType()==EventType.RUN_STATE_CHANGED．{

//Checkifthejobiscomplete

intrunState=statusEvent.getNewStatus().getRunState();

if(runState==JobStatus.SUCCEEDED||runState==JobStatus.FAILED||runState==JobStatus.KILLED．{jobCompleted(oldInfo);

}}

}

}首先，獲取作業(yè)更新

前

的狀態(tài)。然後根據(jù)事件的類型，進(jìn)行對(duì)應(yīng)的處理。例如，假如優(yōu)先級(jí)變化了，則要重新排列隊(duì)列中作業(yè)的次序。這裏直接取出原有作業(yè)，重新插入隊(duì)列。插入後，作業(yè)會(huì)自動(dòng)重新排序，體現(xiàn)了TreeMap的優(yōu)越性。再例如，假如作業(yè)狀態(tài)變?yōu)橥戤?，那么就從?duì)列中刪除該作業(yè)。privatevoidreorderJobs(JobInProgressjob,JobSchedulingInfooldInfo){

synchronized(jobQueue){jobQueue.remove(oldInfo);jobQueue.put(newJobSchedulingInfo(joB．,joB．;

}

}下面就是調(diào)度器中最關(guān)鍵的一步了：任務(wù)選擇。此時(shí)，作業(yè)隊(duì)列中信息已經(jīng)更新完畢，可以選擇某些任務(wù)返回給TaskTracker執(zhí)行了。heartbeat措施接下來(lái)會(huì)有這樣的代碼：List<Task>tasks=getSetupAndCleanupTasks(taskTrackerStatus);

if(tasks==null){

tasks=taskScheduler.assignTasks(taskTrackers.get(trackerName));

}假如不需要setup和cleanup，就闡明需要選擇map或reduce任務(wù)。調(diào)用TaskScheduler的assignTasks措施完畢任務(wù)選擇。由于篇幅限制，我打算將這部分內(nèi)容放到下一篇文章中，并關(guān)注heartbeat中JobTracker下達(dá)的命令過(guò)程以及JobInProgress和TaskInProgress對(duì)調(diào)度有影響的某些字段。

29.

是30.

3.1.3

Hadoop使用1.hdfs寫流程流程：1.client鏈接namenode存數(shù)據(jù)2.namenode記錄一條數(shù)據(jù)位置信息（元數(shù)據(jù)），告訴client存哪。3.client用hdfs的api將數(shù)據(jù)塊（默認(rèn)是64M）存儲(chǔ)到datanode上。4.datanode將數(shù)據(jù)水平備份。并且備份完將反饋client。5.client告知namenode存儲(chǔ)塊完畢。6.namenode將元數(shù)據(jù)同步到內(nèi)存中。7.另一塊循環(huán)上面的過(guò)程。

2.hdfs讀流程流程：1.client鏈接namenode，查看元數(shù)據(jù)，找到數(shù)據(jù)的存儲(chǔ)位置。2.client通過(guò)hdfs的api并發(fā)讀取數(shù)據(jù)。3.關(guān)閉連接。

3.舉一種簡(jiǎn)樸的例子闡明mapreduce是怎么來(lái)運(yùn)行的?解答：

Wordcount例子接口============================一種MapReduce作業(yè)（joB．一般會(huì)把輸入的數(shù)據(jù)集切分為若干獨(dú)立的數(shù)據(jù)塊，由map任務(wù)（task）以完全并行的方式處理它們?？蚣軙?huì)對(duì)map的輸出先進(jìn)行排序，然後把成果輸入給reduce任務(wù)。一般作業(yè)的輸入和輸出都會(huì)被存儲(chǔ)在文獻(xiàn)系統(tǒng)中。整個(gè)框架負(fù)責(zé)任務(wù)的調(diào)度和監(jiān)控，以及重新執(zhí)行已經(jīng)失敗的任務(wù)。一般，MapReduce框架和分布式文獻(xiàn)系統(tǒng)是運(yùn)行在一組相似的節(jié)點(diǎn)上的，也就是說(shuō)，計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)一般在一起。這種配置容許框架在那些已經(jīng)存好數(shù)據(jù)的節(jié)點(diǎn)上高效地調(diào)度任務(wù)，這可以使整個(gè)集群的網(wǎng)絡(luò)帶寬被非常高效地運(yùn)用。MapReduce框架由一種單獨(dú)的masterJobTr