- 相關(guān)推薦
hadoop面試題總結(jié)1
1. 下面哪個(gè)程序負(fù)責(zé) HDFS 數(shù)據(jù)存儲(chǔ)。
a)NameNode b)Jobtracker c)Datanode d)secondaryNameNode e)tasktracker
答案C datanode
2. HDfS 中的 block 默認(rèn)保存幾份?
a)3 份 b)2 份c)1 份d)不確定
答案A默認(rèn)3分
3. 下列哪個(gè)程序通常與 NameNode 在一個(gè)節(jié)點(diǎn)啟動(dòng)?
a)SecondaryNameNode b)DataNode c)TaskTracker d)Jobtracker
答案D
分析：
hadoop的集群是基于master/slave模式，namenode和jobtracker屬于master，datanode和tasktracker屬于slave，master只有一個(gè)，而slave有多個(gè)
SecondaryNameNode內(nèi)存需求和NameNode在一個(gè)數(shù)量級(jí)上，所以通常secondary NameNode(運(yùn)行在單獨(dú)的物理機(jī)器上)NameNode運(yùn)行在不同的機(jī)器上。
JobTracker和TaskTracker
JobTracker 對(duì)應(yīng)于 NameNode
TaskTracker 對(duì)應(yīng)于 DataNode
DataNode 和NameNode 是針對(duì)數(shù)據(jù)存放來(lái)而言的JobTracker和TaskTracker是對(duì)于MapReduce執(zhí)行而言的mapreduce中幾個(gè)主要概念，mapreduce整體上可以分為這么幾條執(zhí)行線索：jobclient，JobTracker與TaskTracker。
1、JobClient會(huì)在用戶端通過(guò)JobClient類(lèi)將應(yīng)用已經(jīng)配置參數(shù)打包成jar文件存儲(chǔ)到hdfs，
并把路徑提交到Jobtracker,然后由JobTracker創(chuàng)建每一個(gè)Task(即MapTask和ReduceTask)
并將它們分發(fā)到各個(gè)TaskTracker服務(wù)中去執(zhí)行
2、JobTracker是一個(gè)master服務(wù)，軟件啟動(dòng)之后JobTracker接收J(rèn)ob，負(fù)責(zé)調(diào)度Job的每一個(gè)子任務(wù)task運(yùn)行于TaskTracker上，
并監(jiān)控它們，如果發(fā)現(xiàn)有失敗的task就重新運(yùn)行它。一般情況應(yīng)該把JobTracker部署在單獨(dú)的機(jī)器上。
3、TaskTracker是運(yùn)行在多個(gè)節(jié)點(diǎn)上的slaver服務(wù)。TaskTracker主動(dòng)與JobTracker通信，接收作業(yè)，并負(fù)責(zé)直接執(zhí)行每一個(gè)任務(wù)。
TaskTracker都需要運(yùn)行在HDFS的DataNode上
4. Hadoop 作者
a)Martin Fowler b)Kent Beck c)Doug cutting
答案C Doug cutting
5. HDFS 默認(rèn) Block Size
a)32MB b)64MB c)128MB
答案：B
(因?yàn)榘姹靖鼡Q較快，這里答案只供參考)
6. 下列哪項(xiàng)通常是集群的最主要瓶頸
a)CPU b)網(wǎng)絡(luò) c)磁盤(pán)IO d)內(nèi)存
答案：C磁盤(pán)
首先集群的目的是為了節(jié)省成本，用廉價(jià)的pc機(jī)，取代小型機(jī)及大型機(jī)。小型機(jī)和大型機(jī)有什么特點(diǎn)?
1.cpu處理能力強(qiáng)
2.內(nèi)存夠大
所以集群的瓶頸不可能是a和d
3.網(wǎng)絡(luò)是一種稀缺資源，但是并不是瓶頸。
4.由于大數(shù)據(jù)面臨海量數(shù)據(jù)，讀寫(xiě)數(shù)據(jù)都需要io，然后還要冗余數(shù)據(jù)，hadoop一般備3份數(shù)據(jù)，所以IO就會(huì)打折扣。
同樣可以參考下面內(nèi)容(磁盤(pán)IO：磁盤(pán)輸出輸出)
對(duì)于磁盤(pán)IO：當(dāng)我們面臨集群作戰(zhàn)的時(shí)候，我們所希望的是即讀即得�？墒敲鎸�(duì)大數(shù)據(jù)，讀取數(shù)據(jù)需要經(jīng)過(guò)IO，這里可以把IO理解為水的管道。管道越大越強(qiáng)，我們對(duì)于T級(jí)的數(shù)據(jù)讀取就越快。所以IO的好壞，直接影響了集群對(duì)于數(shù)據(jù)的處理。
集群瓶頸：磁盤(pán)IO必讀
集群瓶頸為什么磁盤(pán)io
7. 關(guān)于 SecondaryNameNode 哪項(xiàng)是正確的?
a)它是 NameNode 的熱備 b)它對(duì)內(nèi)存沒(méi)有要求
c)它的目的是幫助 NameNode 合并編輯日志，減少 NameNode 啟動(dòng)時(shí)間
d)SecondaryNameNode 應(yīng)與 NameNode 部署到一個(gè)節(jié)點(diǎn)
答案C。
D答案可以參考第三題
多選題：
8. 下列哪項(xiàng)可以作為集群的管理?
a)Puppet b)Pdsh c)Cloudera Manager d)Zookeeper
答案1：ABD
具體可查看
什么是Zookeeper，Zookeeper的作用是什么，在Hadoop及hbase中具體作用是什么
二次整理
修改后答案：ABC
分析：
A：puppetpuppet是一種Linux、Unix、windows平臺(tái)的集中配置管理系統(tǒng)
B：pdsh可以實(shí)現(xiàn)在在多臺(tái)機(jī)器上執(zhí)行相同的命令
詳細(xì)參考：集群管理小工具介紹-pdsh
C：可以參考Cloudera Manager四大功能【翻譯】
首先這里給管理下一個(gè)定義：部署、配置、調(diào)試、監(jiān)控，屬于管理
因?yàn)閦ookeeper不滿足上面要求，所以不納入管理范圍。
9. 配置機(jī)架感知的下面哪項(xiàng)正確
a)如果一個(gè)機(jī)架出問(wèn)題，不會(huì)影響數(shù)據(jù)讀寫(xiě)
b)寫(xiě)入數(shù)據(jù)的時(shí)候會(huì)寫(xiě)到不同機(jī)架的 DataNode 中
c)MapReduce 會(huì)根據(jù)機(jī)架獲取離自己比較近的網(wǎng)絡(luò)數(shù)據(jù)
答案ABC
具體可以參考
hadoop機(jī)架感知--加強(qiáng)集群穩(wěn)固性，該如何配置hadoop機(jī)架感知
10. Client 端上傳文件的時(shí)候下列哪項(xiàng)正確
a)數(shù)據(jù)經(jīng)過(guò) NameNode 傳遞給 DataNode
b)Client 端將文件切分為 Block，依次上傳
c)Client 只上傳數(shù)據(jù)到一臺(tái) DataNode，然后由 NameNode 負(fù)責(zé) Block 復(fù)制工作
答案B
分析：
Client向NameNode發(fā)起文件寫(xiě)入的請(qǐng)求。
NameNode根據(jù)文件大小和文件塊配置情況，返回給Client它所管理部分DataNode的信息。
Client將文件劃分為多個(gè)Block，根據(jù)DataNode的地址信息，按順序?qū)懭氲矫恳粋�(gè)DataNode塊中。
具體查看
HDFS體系結(jié)構(gòu)簡(jiǎn)介及優(yōu)缺點(diǎn)
11. 下列哪個(gè)是 Hadoop 運(yùn)行的模式
a)單機(jī)版 b)偽分布式 c)分布式
答案ABC
12. Cloudera 提供哪幾種安裝 CDH 的方法
a)Cloudera manager b)Tarball c)Yum d)Rpm
答案：ABCD具體可以參考
Hadoop CDH四種安裝方式總結(jié)及實(shí)例指導(dǎo)
判斷題：
13. Ganglia 不僅可以進(jìn)行監(jiān)控，也可以進(jìn)行告警。( 正確)
分析：
此題的目的是考Ganglia的了解。嚴(yán)格意義上來(lái)講是正確。
ganglia作為一款最常用的Linux環(huán)境中的監(jiān)控軟件，它擅長(zhǎng)的的是從節(jié)點(diǎn)中按照用戶的需求以較低的代價(jià)采集數(shù)據(jù)。但是ganglia在預(yù)警以及發(fā)生事件后通知用戶上并不擅長(zhǎng)。最新的ganglia已經(jīng)有了部分這方面的功能。但是更擅長(zhǎng)做警告的還有Nagios。Nagios，就是一款精于預(yù)警、通知的軟件。通過(guò)將Ganglia和Nagios組合起來(lái)，把Ganglia采集的數(shù)據(jù)作為Nagios的數(shù)據(jù)源，然后利用Nagios來(lái)發(fā)送預(yù)警通知，可以完美的實(shí)現(xiàn)一整套監(jiān)控管理的系統(tǒng)。
具體可以查看完美集群監(jiān)控組合ganglia和nagios
14. Block Size 是不可以修改的。(錯(cuò)誤 )
它是可以被修改的
Hadoop的基礎(chǔ)配置文件是hadoop-default.xml，默認(rèn)建立一個(gè)Job的時(shí)候會(huì)建立Job的Config，Config首先讀入hadoop-default.xml的配置，然后再讀入hadoop-site.xml的配置(這個(gè)文件初始的時(shí)候配置為空)，hadoop-site.xml中主要配置需要覆蓋的hadoop-default.xml的系統(tǒng)級(jí)配置。具體配置可以參考下
dfs.block.size//block的大小，單位字節(jié)，后面會(huì)提到用處，必須是512的倍數(shù)，因?yàn)椴捎胏rc作文件完整性校驗(yàn)，默認(rèn)配置512是checksum的最小單元。
5120000
The default block size for new files.
15. Nagios 不可以監(jiān)控 Hadoop 集群，因?yàn)樗惶峁?Hadoop 支持。(錯(cuò)誤 )
分析：
Nagios是集群監(jiān)控工具，而且是云計(jì)算三大利器之一
16. 如果 NameNode 意外終止，SecondaryNameNode 會(huì)接替它使集群繼續(xù)工作。(錯(cuò)誤 )
分析：
SecondaryNameNode是幫助恢復(fù)，而不是替代，如何恢復(fù)，可以查看
hadoop 根據(jù)SecondaryNameNode恢復(fù)Namenode
17. Cloudera CDH 是需要付費(fèi)使用的。(錯(cuò)誤 )
分析：
第一套付費(fèi)產(chǎn)品是Cloudera Enterpris，Cloudera Enterprise在美國(guó)加州舉行的 Hadoop 大會(huì) (Hadoop Summit) 上公開(kāi)，以若干私有管理、監(jiān)控、運(yùn)作工具加強(qiáng) Hadoop 的功能。收費(fèi)采取合約訂購(gòu)方式，價(jià)格隨用的 Hadoop 叢集大小變動(dòng)。
18. Hadoop 是 Java 開(kāi)發(fā)的，所以 MapReduce 只支持 Java 語(yǔ)言編寫(xiě)。(錯(cuò)誤 )
分析：
rhadoop是用R語(yǔ)言開(kāi)發(fā)的，MapReduce是一個(gè)框架，可以理解是一種思想，可以使用其他語(yǔ)言開(kāi)發(fā)。
具體可以查看
Hadoop簡(jiǎn)介(1):什么是Map/Reduce
19. Hadoop 支持?jǐn)?shù)據(jù)的隨機(jī)讀寫(xiě)。(錯(cuò) )
分析：
lucene是支持隨機(jī)讀寫(xiě)的，而hdfs只支持隨機(jī)讀。但是HBase可以來(lái)補(bǔ)救。
HBase提供隨機(jī)讀寫(xiě)，來(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ǔ)的直接反映，使系統(tǒng)有可能提高高效的數(shù)據(jù)結(jié)構(gòu)的序列化、存儲(chǔ)和檢索。
20. NameNode 負(fù)責(zé)管理 metadata，client 端每次讀寫(xiě)請(qǐng)求，它都會(huì)從磁盤(pán)中讀取或則會(huì)寫(xiě)入 metadata 信息并反饋 client 端。(錯(cuò)誤)
修改后分析：
分析：
NameNode 不需要從磁盤(pán)讀取 metadata，所有數(shù)據(jù)都在內(nèi)存中，硬盤(pán)上的只是序列化的結(jié)果，只有每次 namenode 啟動(dòng)的時(shí)候才會(huì)讀取。
1)文件寫(xiě)入
Client向NameNode發(fā)起文件寫(xiě)入的請(qǐng)求。
NameNode根據(jù)文件大小和文件塊配置情況，返回給Client它所管理部分DataNode的信息。
Client將文件劃分為多個(gè)Block，根據(jù)DataNode的地址信息，按順序?qū)懭氲矫恳粋�(gè)DataNode塊中。
2)文件讀取
Client向NameNode發(fā)起文件讀取的請(qǐng)求。
NameNode返回文件存儲(chǔ)的DataNode的信息。
Client讀取文件信息。
具體查看
hadoop中NameNode、DataNode和Client三者之間協(xié)作關(guān)系
21. NameNode 本地磁盤(pán)保存了 Block 的位置信息。( 個(gè)人認(rèn)為正確，歡迎提出其它意見(jiàn))
分析：
DataNode是文件存儲(chǔ)的基本單元，它將Block存儲(chǔ)在本地文件系統(tǒng)中，保存了Block的Meta-data，同時(shí)周期性地將所有存在的Block信息發(fā)送給NameNode。
具體同樣查看
hadoop中NameNode、DataNode和Client三者之間協(xié)作關(guān)系
22. DataNode 通過(guò)長(zhǎng)連接與 NameNode 保持通信。( )
這個(gè)有分歧：具體正在找這方面的有利資料。下面提供資料可參考。
首先明確一下概念：
(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)通訊，比如多個(gè)Client連接一個(gè)Server.
23. Hadoop 自身具有嚴(yán)格的權(quán)限管理和安全措施保障集群正常運(yùn)行。(錯(cuò)誤 )hadoop只能阻止好人犯錯(cuò)，但是不能阻止壞人干壞事
具體可查看
hadoop安全性需不斷加強(qiáng)
24. Slave 節(jié)點(diǎn)要存儲(chǔ)數(shù)據(jù)，所以它的磁盤(pán)越大越好。( 錯(cuò)誤)
分析：
一旦Slave節(jié)點(diǎn)宕機(jī)，數(shù)據(jù)恢復(fù)是一個(gè)難題
25. hadoop dfsadmin –report 命令用于檢測(cè) HDFS 損壞塊。(錯(cuò)誤 )
分析：
hadoop dfsadmin -report
用這個(gè)命令可以快速定位出哪些節(jié)點(diǎn)down掉了，HDFS的容量以及使用了多少，以及每個(gè)節(jié)點(diǎn)的硬盤(pán)使用情況。
當(dāng)然NameNode有個(gè)http頁(yè)面也可以查詢，但是這個(gè)命令的輸出更適合我們的腳本監(jiān)控dfs的使用狀況
Configured Capacity: 77209395855360 (70.22 TB)
Present Capacity: 76079914600683 (69.19 TB)
DFS Remaining: 60534707015680 (55.06 TB)
DFS Used: 15545207585003 (14.14 TB)
DFS Used%: 20.43%
-------------------------------------------------
Datanodes available: 107 (109 total, 2 dead)
Name: 172.16.218.232:50010
Rack: /lg/dminterface0
Decommission Status : Normal
Configured Capacity: 1259272216576 (1.15 TB)
DFS Used: 185585852416 (172.84 GB)
Non DFS Used: 39060951040 (36.38 GB)
DFS Remaining: 1034625413120(963.57 GB)
DFS Used%: 14.74%
DFS Remaining%: 82.16%
Last contact: Wed Nov 18 10:19:44 CST 2009
Name: 172.16.216.126:50010
Rack: /lg/dminterface2
Decommission Status : Normal
Configured Capacity: 661261402112 (615.85 GB)
DFS Used: 123147280384 (114.69 GB)
Non DFS Used: 8803852288 (8.2 GB)
DFS Remaining: 529310269440(492.96 GB)
DFS Used%: 18.62%
DFS Remaining%: 80.05%
Last contact: Wed Nov 18 10:19:46 CST 2009
26. Hadoop 默認(rèn)調(diào)度器策略為 FIFO(正確 )
具體參考
Hadoop集群三種作業(yè)調(diào)度算法介紹
27. 集群內(nèi)每個(gè)節(jié)點(diǎn)都應(yīng)該配 RAID，這樣避免單磁盤(pán)損壞，影響整個(gè)節(jié)點(diǎn)運(yùn)行。(錯(cuò)誤 )
分析：
首先明白什么是RAID，可以參考百科磁盤(pán)陣列。
這句話錯(cuò)誤的地方在于太絕對(duì)，具體情況具體分析。題目不是重點(diǎn)，知識(shí)才是最重要的。
因?yàn)閔adoop本身就具有冗余能力，所以如果不是很?chē)?yán)格不需要都配備RAID。具體參考第二題。
28. 因?yàn)?HDFS 有多個(gè)副本，所以 NameNode 是不存在單點(diǎn)問(wèn)題的。(錯(cuò)誤 )
分析：
NameNode存在單點(diǎn)問(wèn)題。了解詳細(xì)信息，可以參考
Hadoop中Namenode單點(diǎn)故障的解決方案及詳細(xì)介紹AvatarNode
29. 每個(gè) map 槽就是一個(gè)線程。(錯(cuò)誤 )
分析：首先我們知道什么是map 槽,map 槽->map slot
map slot 只是一個(gè)邏輯值 ( org.apache.hadoop.mapred.TaskTracker.TaskLauncher.numFreeSlots )，而不是對(duì)應(yīng)著一個(gè)線程或者進(jìn)程
具體見(jiàn)：
hadoop中槽-slot是線程還是進(jìn)程討論
30. Mapreduce 的 input split 就是一個(gè) block。(錯(cuò)誤 )
InputFormat的數(shù)據(jù)劃分、Split調(diào)度、數(shù)據(jù)讀取三個(gè)問(wèn)題的淺析
31. NameNode 的 Web UI 端口是 50030，它通過(guò) jetty 啟動(dòng)的 Web 服務(wù)。(錯(cuò)誤 )
分析：
根據(jù)下面，很顯然JOBTRACKER的 Web UI 端口是 50030
端口說(shuō)明：
默認(rèn)端口 設(shè)置位置
9000 namenode
8020 namenode
8021 JT RPC
50030 mapred.job.tracker.http.address JobTracker administrative web GUI
50070 dfs.http.address NameNode administrative web GUI
50010 dfs.datanode.address DataNode control port
50020 dfs.datanode.ipc.address DataNode IPC port, used for block transfer
50060 mapred.task.tracker.http.address Per TaskTracker web interface
50075 dfs.datanode.http.address Per DataNode web interface
50090 dfs.secondary.http.address Per secondary NameNode web interface
設(shè)置位置 描述信息
namenode 交互端口
namenode RPC交互端口
JT RPC 交互端口
mapred.job.tracker.http.address JobTracker administrative web GUI JOBTRACKER的HTTP服務(wù)器和端口
dfs.http.address NameNode administrative web GUI NAMENODE的HTTP服務(wù)器和端口
dfs.datanode.address DataNode control port DATANODE控制端口，主要用于DATANODE初始化時(shí)向NAMENODE提出注冊(cè)和應(yīng)答請(qǐng)求
dfs.datanode.ipc.address DataNode IPC port, used for block transfer DATANODE的RPC服務(wù)器地址和端口
mapred.task.tracker.http.address Per TaskTracker web interface TASKTRACKER的HTTP服務(wù)器和端口
dfs.datanode.http.address Per DataNode web interface DATANODE的HTTP服務(wù)器和端口
dfs.secondary.http.address Per secondary NameNode web interface 輔助DATANODE的HTTP服務(wù)器和端口
32. Hadoop 環(huán)境變量中的 HADOOP_HEAPSIZE 用于設(shè)置所有 Hadoop 守護(hù)線程的內(nèi)存。它默
認(rèn)是 200 GB。( 錯(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。
具體參考hadoop集群內(nèi)存設(shè)置
33. DataNode 首次加入 cluster 的時(shí)候，如果 log 中報(bào)告不兼容文件版本，那需要 NameNode
執(zhí)行“Hadoop namenode -format”操作格式化磁盤(pán)。(錯(cuò)誤 )
分析：
首先明白介紹，什么ClusterID
ClusterID
添加了一個(gè)新的標(biāo)識(shí)符ClusterID用于標(biāo)識(shí)集群中所有的節(jié)點(diǎn)。當(dāng)格式化一個(gè)Namenode，需要提供這個(gè)標(biāo)識(shí)符或者自動(dòng)生成。這個(gè)ID可以被用來(lái)格式化加入集群的其他Namenode。
二次整理
有的同學(xué)問(wèn)題的重點(diǎn)不是上面分析內(nèi)容：內(nèi)容如下：
這個(gè)報(bào)錯(cuò)是說(shuō)明 DataNode 所裝的Hadoop版本和其它節(jié)點(diǎn)不一致，應(yīng)該檢查DataNode的Hadoop版本
詳細(xì)內(nèi)容可參考
hadoop集群添加namenode的步驟及常識(shí)
以上答案通過(guò)多個(gè)資料驗(yàn)證，對(duì)于資料不充分的內(nèi)容，都標(biāo)有”個(gè)人觀點(diǎn)“，給出本測(cè)試題抱著謹(jǐn)慎的態(tài)度，希望大家多批評(píng)指正。
上面只是選擇與判斷，可以看另外一套實(shí)戰(zhàn)面試實(shí)戰(zhàn)面試題
[hadoop面試題總結(jié)1]