Hadoop大數(shù)據(jù)處理技術(shù)基礎(chǔ)與實(shí)踐微課版第3版安俊秀習(xí)題答案

第一章1.1Hadoop的核心組件是什么，它們各自有承擔(dān)什么樣的角色？答：Hadoop的核心組件包括兩個(gè)部分，HDFS分布式文件存儲系統(tǒng)和MapReduce編程模型。HDFS負(fù)責(zé)底層存儲，MapReduce則是一個(gè)封裝的分布式計(jì)算框架，能讓用戶在不知道底層實(shí)現(xiàn)的基礎(chǔ)上編寫分布式程序。1.2Hadoop處理數(shù)據(jù)的特點(diǎn)是什么？答：批處理、本地性、高延遲。1.3如何簡單開發(fā)Hadoop應(yīng)用？答：一般來說，只需要實(shí)現(xiàn)相應(yīng)的mapper與reducer函數(shù)即可。第二章2.1圖2-40是一張全局網(wǎng)絡(luò)拓?fù)鋱D，請說出里面用到了哪幾種VMWare網(wǎng)絡(luò)連接方式，其中虛擬機(jī)A82處于哪種連接方式之中。答：三種連接方式都用到，其中Vmnet0是bridge橋接模式，Vmnet1是host-only模式，Vmnet8是NAT模式。虛擬機(jī)A82處于NAT模式網(wǎng)絡(luò)中嗎，可以通過虛擬NAT路由器訪問外網(wǎng)。2.2小君在配置集群的時(shí)候給其中一個(gè)節(jié)點(diǎn)命名為xiaojun2，使用命令hostnamexiaojun2，重啟之后發(fā)現(xiàn)主機(jī)名沒有變更，有什么辦法可以讓這個(gè)節(jié)點(diǎn)重啟之后變成xiaojun2?答：參見2.2.6節(jié)。2.3小君配置了NAT模式連接的節(jié)點(diǎn)后可以連接外網(wǎng)，為什么在外網(wǎng)上無法ping通該節(jié)點(diǎn)？答：引入NAT的場合會造成單向Ping通。NAT可以起到隱蔽內(nèi)部地址的作用，當(dāng)由內(nèi)Ping外時(shí)，可以Ping通是因?yàn)镹AT表的映射關(guān)系存在，當(dāng)由外發(fā)起Ping內(nèi)網(wǎng)主機(jī)時(shí)，就無從查找邊界路由器的NAT表項(xiàng)了。（1）小超給小君和小濤提供了自己的公鑰，小君向小超發(fā)送報(bào)文，使用小超的公鑰加密，這個(gè)報(bào)文是否安全？答：安全，即使小濤截獲了這個(gè)報(bào)文，沒有小超的私鑰也無法解密。（2）接上題，小超收到報(bào)文后使用私鑰解密，就看到了報(bào)文內(nèi)容，給小君回信，用自己的私鑰對回信加密發(fā)送給小軍，這個(gè)回信報(bào)文安全嗎？答：不安全。如果小濤截獲這條報(bào)文后，可以用小超的公鑰解密后信息就泄露了。要解決回信的問題就要通過hash函數(shù)對回信生成摘要（digest），然后小超對這個(gè)摘要用私鑰加密生成數(shù)字簽名（signature），然后將這個(gè)數(shù)字簽名附在回信中發(fā)送給小君。小君收到回信后取下數(shù)字簽名，再用小超的公鑰解密得到信息摘要，證明是小超發(fā)過來的。小君再對回信本身通過hash函數(shù)得到的摘要與上一步的信息摘要進(jìn)行對比，如果一致就證明沒有被修改過。當(dāng)然這樣還不能保證絕對安全，因?yàn)闊o法保證小君手里的小超的公鑰一定是小超的，還需要對這個(gè)公鑰進(jìn)行證書認(rèn)證，也就是常見的“數(shù)字證書”。2.4在core_site.xml配置文檔中對臨時(shí)文件目錄進(jìn)行配置，值為：/home/hadoop/tmp/hadoop-${}，一主機(jī)名為node1，當(dāng)前Hadoop集群權(quán)限屬于trucy，那么實(shí)際生成的臨時(shí)目錄是什么？答：實(shí)際臨時(shí)目錄為/home/hadoop/tmp/hadoop-trucy。第三章3.1HDFS上默認(rèn)的一個(gè)數(shù)據(jù)塊（Block）大小為多大？答：64M。3.2Windows上檢測磁盤使用命令chkdsk，那么在HDFS集群上檢測塊信息應(yīng)用什么命令？答：fsck。3.3在HDFS上刪除的文件會先放入“回車站”，并在刪除的文件狀態(tài)沒有變更的情況下一定時(shí)效內(nèi)徹底刪除該文件。假如用戶trucy刪除了HDFS上的一個(gè)叫test.dat這個(gè)文件，但馬上后悔了，應(yīng)該檢索什么路徑找到這個(gè)文件，并取回到本地當(dāng)前目錄？請用shell命令表示。答：hdfsdfs–get/user/trucy/.Trash/Current/test.dat。3.4在啟動(dòng)集群后馬上通過Web端口登陸到Hadoop界面，但是單擊FileSystem卻無法進(jìn)去瀏覽分布式文件，這是為什么？答：參見本章3.2.4節(jié)。3.5畫出HDFS的基礎(chǔ)架構(gòu)圖。答：參見本章3.2節(jié)開頭。第四章4.1YARN體系結(jié)構(gòu)主要由哪幾個(gè)組件組成？答：YARN的基本框架也是Master/Slave結(jié)構(gòu)，主要由ResourceManager（RM）、NodeManager（NM）、ApplicationMaster(AM)和Container等幾個(gè)組件構(gòu)成。4.2ResourceManager組件的作用？答：RM全局管理計(jì)算程序的資源分配調(diào)度，即這個(gè)實(shí)體控制整個(gè)集群并管理應(yīng)用程序向基礎(chǔ)計(jì)算資源的分配，處理客戶端請求、啟動(dòng)并監(jiān)控AM、監(jiān)控NM、資源的分配與調(diào)度。它主要由兩個(gè)組件構(gòu)成：調(diào)度器（Scheduler）和應(yīng)用程序管理器（ApplicationsManager，ASM）。RM將各個(gè)資源部分（計(jì)算、內(nèi)存、帶寬等）精心安排給基礎(chǔ)NM（YARN的節(jié)點(diǎn)代理）。RM還與AM一起分配資源，與NM一起啟動(dòng)和監(jiān)視它們的基礎(chǔ)應(yīng)用程序。4.3MRv1的局限性有哪些？答：（1）擴(kuò)展性差。（2）可靠性差。（3）資源利用率低。（4）無法支持多種計(jì)算框架。4.4YARN主要由哪幾個(gè)RPC協(xié)議組成？答：YARN主要由以下幾個(gè)RPC協(xié)議組成：(1)作業(yè)提交客戶端（JobClient）與RM之間的協(xié)議是ApplicationClientProtocol，JobClient通過該RPC提交應(yīng)用程序、查詢應(yīng)用程序狀態(tài)等。(2)管理員(Admin)與RM之間的通信協(xié)議是ResourceManagerAdministrationProtocol，Admin通過該RPC更新系統(tǒng)配置文件，如節(jié)點(diǎn)黑白名單、用戶隊(duì)列權(quán)限等。（3）AM與RM之間的協(xié)議是ApplicationMasterProtocol，AM通過該RPC向RM注冊和撤銷自己，并為各個(gè)任務(wù)申請資源。（4）AM與NM之間的協(xié)議是ContainerManagementProtocol，AM通過該RPC要求NM啟動(dòng)或者停止Container，獲取各個(gè)Container的使用狀態(tài)等信息。（5）NM與RM之間的協(xié)議是ResourceTracker，NM通過該RPC向RM注冊，并定時(shí)發(fā)送心跳信息匯報(bào)當(dāng)前節(jié)點(diǎn)的資源使用情況和Container運(yùn)行情況。4.5YARN資源調(diào)度器提供了哪三種可用資源調(diào)度器？答：YARN資源調(diào)度器提供了三種可用資源調(diào)度器，分別是FIFO、CapacityScheduler和FairScheduler。4.6分別概括下三種資源調(diào)度器的工作流程。答：(1)FIFO調(diào)度器采用隊(duì)列方式將一個(gè)一個(gè)任務(wù)（job）按照時(shí)間先后順序進(jìn)行服務(wù),排在最前面的任務(wù)需要若干maptask和若干reducetask，當(dāng)發(fā)現(xiàn)有空閑的服務(wù)器節(jié)點(diǎn)就分配給這個(gè)任務(wù)，直到該任務(wù)執(zhí)行完畢。Capacity調(diào)度器支持多個(gè)隊(duì)列，每個(gè)隊(duì)列可配置一定量的資源，每個(gè)采用FIFO的方式調(diào)度。為了防止同一個(gè)用戶的任務(wù)獨(dú)占隊(duì)列中的資源，調(diào)度器會對同一用戶提交的任務(wù)所占資源進(jìn)行限制。按照任務(wù)的優(yōu)先級和時(shí)間順序，同時(shí)要考慮到用戶的資源量和內(nèi)存的限制，對隊(duì)列中的任務(wù)進(jìn)行排序執(zhí)行。多個(gè)隊(duì)列同時(shí)按照任務(wù)隊(duì)列內(nèi)的先后順序一次執(zhí)行。Fair調(diào)度器支持多個(gè)隊(duì)列，每個(gè)隊(duì)列可以配置一定的資源，每個(gè)隊(duì)列中的任務(wù)公平共享其所在隊(duì)列的所有資源，隊(duì)列中的任務(wù)都是按照優(yōu)先級分配資源，優(yōu)先級越高分配的資源越多，但是為了確保公平，每個(gè)任務(wù)都會分配到資源。優(yōu)先級是根據(jù)每個(gè)任務(wù)的理想獲取資源量減去實(shí)際獲取資源量的差值決定的，差值越大優(yōu)先級越高。4.7簡單概括下YARN的工作流程。答：ResourceManager通過每臺機(jī)器上的資源管理器代理NodeManager管理每個(gè)節(jié)點(diǎn)上所有應(yīng)用的CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等資源使用情況，NodeManager將資源使用信息不定期反饋給ResourceManager。當(dāng)應(yīng)用程序的ApplicationMaster進(jìn)程向ResourceManager發(fā)起資源申請請求時(shí)，ResourceManager將資源管理信息發(fā)送給每臺機(jī)器上的NodeManager，授權(quán)其執(zhí)行實(shí)際的資源分配或回收操作。4.8練習(xí)YARN的應(yīng)用程序編程實(shí)例—DistributedShell。答：參見本章4.5.1節(jié)。第五章5.1簡述MapReduce基本思想，想想看生活中有沒有相似的例子。答：MapReduce采用“分而治之”的思想，把一個(gè)大而重的任務(wù)拆解開來，分成一系列小而輕的任務(wù)并行處理，這樣就使得任務(wù)可以快速解決。例子略5.2MapReduce有哪些編程模型？答：簡單編程模型和復(fù)雜編程模型，在簡單編程模型中，沒有Reducer，數(shù)據(jù)經(jīng)由Mapper處理后直接寫入HDFS，此模型沒有Shuffle過程；在復(fù)雜編程模型中，會有多個(gè)Reducer來匯總Mapper的中間結(jié)果，此模型有Shuffle過程。5.3MapReduce如何保證結(jié)果文件中key的唯一性？答：簡單來說，由不同Mapper產(chǎn)生的相同的key值會集中到同一個(gè)Reducer中進(jìn)行匯總處理。細(xì)節(jié)實(shí)現(xiàn)是在Partition操作中，因?yàn)闅w并后的中間結(jié)果文件是基于key整體有序的，所以對于劃分的某一分區(qū)，其所有的key值均是小于/大于另一分區(qū)的key值，這時(shí)把對應(yīng)的分區(qū)始終分配給相應(yīng)的Reducer，那么這個(gè)Reducer所接受的數(shù)據(jù)的key值總是會小于/大于其他Reducer接受的數(shù)據(jù)的Key值，所有由Reducer歸約后，某一key值只會出現(xiàn)一次。5.4MapReduce的Partition操作是怎樣實(shí)現(xiàn)的？答：在歸并由Mapper產(chǎn)生的多個(gè)spill文件時(shí)，根據(jù)文件的大小和Reducer的個(gè)數(shù)對中間結(jié)果文件進(jìn)行分區(qū)，盡量保證劃分給各Reducer的數(shù)據(jù)大小的均衡，之后產(chǎn)生相應(yīng)的index索引文件。5.5用自己熟悉的語言編寫兩個(gè)可執(zhí)行腳本或文件：Mapper和Reducer，然后使用Hadoop的Streaming提交任務(wù)到集群運(yùn)行。答：略。第六章6.1SequenceFile類型文件可以用記事本打開嗎？答：不可以，SequenceFile類型文件類似于日志文件，是一種半結(jié)構(gòu)化數(shù)據(jù)的文件，里面可以存放壓縮后的數(shù)據(jù)，不同于普通的字符文本文件。如果直接打開會有亂碼。6.2MapFile與SequenceFile有什么區(qū)別。答：MapFile是排序后的SequenceFile，并且它會額外生成一個(gè)索引文件提供按鍵的查找。6.3Hadoop常用壓縮算法對比。答：參見表6-1。6.4Java的基本類型都支持序列化操作，那為什么Hadoop的基本類型還要重新定義序列化呢？答：Hadoop在集群之間進(jìn)行通訊或者RPC調(diào)用時(shí)需要序列化，而且要求序列化要快，且體積要小，占用帶寬要小。而Java的序列化機(jī)制占用大量計(jì)算開銷，且序列化結(jié)果體積過大；它的引用（reference）機(jī)制也導(dǎo)致大文件不能被切分，浪費(fèi)空間；此外，Java的序列化機(jī)制很難對其他語言進(jìn)行擴(kuò)展使用；更重要的是Java的反序列化過程每次會構(gòu)造新的對象，不能復(fù)用對象。6.5比較Java基本類型和writable。答：參見表6-5。第七章7.1HBase和一般關(guān)系型數(shù)據(jù)庫有什么不同？答：HBase是面向列的，HBase是稀疏的，HBase是非結(jié)構(gòu)化的。7.2HBase的一張表在物理上的結(jié)構(gòu)是什么？答：HBase在存儲上以列族為單位，如果一個(gè)表有3個(gè)列族，那么在進(jìn)行物理存儲時(shí)就會有3個(gè)存儲單元，每個(gè)單元對應(yīng)一個(gè)列族。7.3Zookeeper在HBase中有什么作用？答：Zookeeper為HBase提供協(xié)同管理服務(wù)，所有Region的行鍵信息、位置及該Region由哪個(gè)HRegionServer進(jìn)行管理均由Zookeeper分配和管理。7.4HBase的表由多個(gè)列族構(gòu)成，所以記錄也分散在多個(gè)列族中，那么在完全分布式的HBase中，一條行鍵的記錄是存儲在一個(gè)節(jié)點(diǎn)（DataNode）中嗎？一個(gè)列族呢？答：在完全分布式的HBase中，一條行鍵的所有記錄存在于一個(gè)節(jié)點(diǎn)中，但是一個(gè)列族的數(shù)據(jù)會存在于多個(gè)節(jié)點(diǎn)中。7.5HBase中對刪除的記錄是如何處理的？答：在操作提交時(shí)，并不會將相應(yīng)的記錄刪除，而是在記錄前加上刪除標(biāo)記，然后在StoreFile合并時(shí)進(jìn)行刪除處理，這時(shí)才會真正地刪除數(shù)據(jù)。7.6在Hadoop集群中安裝HBase，然后自己設(shè)計(jì)一個(gè)表，并在HBase中執(zhí)行創(chuàng)建表，添加、修改數(shù)據(jù)等操作。答：略。第八章8.1Chubby和Zookeeper的關(guān)系。答：參見本章8.2節(jié)。8.2Znode由哪幾部分組成？答：（1）stat：此為狀態(tài)信息，描述該Znode的版本，權(quán)限等信息。（2）data：與該Znode關(guān)聯(lián)的數(shù)據(jù)。（3）children：該Znode下的子節(jié)點(diǎn)。8.3Znode主要分為哪幾類？答：ZooKeeper中的節(jié)點(diǎn)有兩種，分別為臨時(shí)節(jié)點(diǎn)（EphemeralNodes）和永久節(jié)點(diǎn)（PersistentNodes）。8.4Watch主要處理哪幾類事件？答：（1）連接狀態(tài)事件(type=None,path=null)，這類事件不需要注冊，也不需要連續(xù)觸發(fā)，我們只要處理就行了。（2）節(jié)點(diǎn)事件，節(jié)點(diǎn)的建立，刪除，數(shù)據(jù)的修改。它是onetimetrigger，需要不停地注冊觸發(fā)，還可能發(fā)生事件丟失的情況。8.5自己搭建一個(gè)Zookeeper集群。答：略。第九章9.1簡述Hive產(chǎn)生背景。答：Hive是為了解決傳統(tǒng)SQL數(shù)據(jù)庫開發(fā)人員快速地向Hadoop海量數(shù)據(jù)處理平臺過渡而提出的一種折中解決方案，實(shí)現(xiàn)熟悉傳統(tǒng)SQL技術(shù)的程序開發(fā)人員在Hadoop平臺上進(jìn)行大數(shù)據(jù)相關(guān)技術(shù)的操作，將傳統(tǒng)數(shù)據(jù)倉庫技術(shù)遷移到Hadoop平臺上，降低人員的技術(shù)培訓(xùn)成本和經(jīng)濟(jì)成本。8.2簡述Hive的服務(wù)結(jié)構(gòu)組成及其對應(yīng)的功能。答：Hive服務(wù)組成分為Hive客戶端和Hive服務(wù)端?？蛻舳颂峁┝薚hrift、JDBC、ODBC應(yīng)用程序驅(qū)動(dòng)工具，可以方便地編寫使用Thrift、JDBC和ODBC驅(qū)動(dòng)的Python、Java或C++程序，使用Hive對存儲在Hadoop上的海量數(shù)據(jù)進(jìn)行分析；服務(wù)端提供了HiveShell命令行接口、HiveWeb接口和為不同應(yīng)用程序（包括上層Thrift應(yīng)用程序、JDBC應(yīng)用程序以及ODBC應(yīng)用程序）提供多種服務(wù)的HiveServer。9.3MySQL數(shù)據(jù)庫針對Hive的用途是什么？答：由于Hive元數(shù)據(jù)metastore根據(jù)不同用戶的應(yīng)用需求不同而具有很大差異，并且metastore內(nèi)容所需的存儲容量需求很小，甚至可能需要經(jīng)歷頻繁的更新、修改和讀取操作，顯然不適合于使用Hadoop文件系統(tǒng)來存儲。因此，可以將Hive的元數(shù)據(jù)存儲在類似MySQL的關(guān)系型數(shù)據(jù)庫中，提高Hive的整個(gè)應(yīng)用性能。9.4Hive是如何操作和管理數(shù)據(jù)的，其管理數(shù)據(jù)的方式有哪些？答：Hive并不存儲數(shù)據(jù)，而是管理存儲在HDFS上的數(shù)據(jù)，通過Hive表導(dǎo)入數(shù)據(jù)只是簡單的將數(shù)據(jù)移動(dòng)（如果數(shù)據(jù)是在HDFS上）或復(fù)制（如果數(shù)據(jù)是在本地文件系統(tǒng)中）到Hive表所在的HDFS目錄中。Hive管理數(shù)據(jù)的方式有ManagedTable（內(nèi)部表），ExternalTable（外部表），Partition（分區(qū)），Bucket（桶）等幾種。第十章10.1簡要描述Sqoop的功能。答：Sqoop是一個(gè)實(shí)現(xiàn)Hadoop與關(guān)系型數(shù)據(jù)庫（RDBMS）之間進(jìn)行數(shù)據(jù)遷移的工具，通過Sqoop可以簡單、快速地從諸如MySQL、Oracle等傳統(tǒng)關(guān)系型數(shù)據(jù)庫中把數(shù)據(jù)導(dǎo)入（import）到諸如HDFS、HBase、Hive等Hadoop分布式存儲環(huán)境下，使用HadoopMapReduce等分布式處理工具對數(shù)據(jù)進(jìn)行加工處理，然后可以將最終處理結(jié)果導(dǎo)出（export）到RDBMS中。10.2簡要描述Sqoop所支持的功能操作有哪些？答：Sqoop提供了一系列工具命令（toolscommand），包括導(dǎo)入操作（import）、導(dǎo)出操作（export）、導(dǎo)入所有表（import-all-tables）、列出所有數(shù)據(jù)庫實(shí)例（list-databases）、列出特定數(shù)據(jù)庫實(shí)例中的所有表（list-tables）等，在Linux命令提示符下輸入sqoophelp會輸出Sqoop所支持的所有工具命令。10.3分別安裝MySQL數(shù)據(jù)庫和Sqoop工具，實(shí)現(xiàn)MySQL數(shù)據(jù)庫和HDFS之間的數(shù)據(jù)導(dǎo)入、導(dǎo)出操作。答：略。第十一章11.1Flink和Spark的功能分別是什么？答：Flink的主要功能包括：流處理：Flink是一種流處理引擎，可以處理實(shí)時(shí)數(shù)據(jù)流，并提供了類似于SQL的API，方便處理復(fù)雜的數(shù)據(jù)流計(jì)算。批處理：Flink也可以處理大規(guī)模的批處理任務(wù)，與流處理共享相同的API和底層引擎。分布式數(shù)據(jù)處理：Flink可以分布式地處理大規(guī)模的數(shù)據(jù)集。支持多種數(shù)據(jù)源：Flink可以從多種數(shù)據(jù)源讀取和寫入數(shù)據(jù)，包括HDFS、Kafka、Elasticsearch等。支持高可用性：Flink提供了容錯(cuò)機(jī)制，可以保證在節(jié)點(diǎn)故障的情況下繼續(xù)進(jìn)行計(jì)算。支持多種語言：Flink支持Java、Scala和Python等多種編程語言。Spark的主要功能包括：批處理：Spark是一種批處理引擎，可以處理大規(guī)模的數(shù)據(jù)集，支持高效的內(nèi)存計(jì)算和磁盤計(jì)算。流處理：Spark提供了流處理框架SparkStreaming，可以處理實(shí)時(shí)數(shù)據(jù)流，通過微批處理方式實(shí)現(xiàn)近似實(shí)時(shí)處理。機(jī)器學(xué)習(xí)：Spark提供了機(jī)器學(xué)習(xí)庫MLlib，可以進(jìn)行分類、聚類、回歸等多種機(jī)器學(xué)習(xí)算法的訓(xùn)練和預(yù)測。圖計(jì)算：Spark提供了圖計(jì)算庫GraphX，可以進(jìn)行大規(guī)模的圖計(jì)算任務(wù)。支持多種數(shù)據(jù)源：Spark可以從多種數(shù)據(jù)源讀取和寫入數(shù)據(jù)，包括HDFS、Hive、Cassandra等。支持多種語言：Spark支持Java、Scala、Python和R等多種編程語言。11.2Flink集群的組成及其對應(yīng)功能分別是什么？答：Flink集群是由多個(gè)組件組成的，每個(gè)組件有不同的功能。以下是Flink集群的主要組成部分及其對應(yīng)的功能：JobManager：JobManager是Flink集群的主控節(jié)點(diǎn)，負(fù)責(zé)接收和調(diào)度用戶提交的作業(yè)，并協(xié)調(diào)作業(yè)的執(zhí)行。它還管理著集群中的資源，如任務(wù)槽（TaskSlot），并負(fù)責(zé)協(xié)調(diào)任務(wù)槽的分配和回收。TaskManager：TaskManager是Flink集群中的工作節(jié)點(diǎn)，負(fù)責(zé)接收J(rèn)obManager分配的任務(wù)，并執(zhí)行任務(wù)中的計(jì)算邏輯。每個(gè)TaskManager可以運(yùn)行多個(gè)任務(wù)，每個(gè)任務(wù)在一個(gè)任務(wù)槽中運(yùn)行，一個(gè)任務(wù)槽只能運(yùn)行一個(gè)任務(wù)。ResourceManager：ResourceManager是Flink集群的資源管理組件，負(fù)責(zé)分配和管理集群的資源，如CPU、內(nèi)存、網(wǎng)絡(luò)帶寬等。ResourceManager還可以通過與外部資源管理器（如YARN或Mesos）集成來管理集群資源。BlobServer：BlobServer是Flink集群的二進(jìn)制大對象（BinaryLargeOb