Hadoop平臺搭建與應(yīng)用第2版微課版米洪課后參考答案

Hadoop平臺搭建與應(yīng)用PAGE12課后練習(xí)1.簡述Docker的常用命令及其作用？ dockerpull拉去或更新指定的鏡像dockerpush將鏡像推送到遠(yuǎn)程倉庫dockerrm刪除容器dockerrmi刪除鏡像dockerimages列出所有鏡像dockerps列出所有容器2.本地的鏡像文件存放在那些目錄中？如何更改Docker的默認(rèn)存儲設(shè)置？（1）Docker相關(guān)的本地資源存在/var/lib/docker/目錄下，其中container目錄存放容器信息，graph目錄存放鏡像信息，aufs目錄下存放具體的鏡像底層文件。（2）Docker的默認(rèn)存放位置是/var/lib/docker，如果希望將Docker的本地文件存儲到其他分區(qū)，可以使用Linux軟連接的方式來實現(xiàn)。3.Docker的配置文件放在哪里？Ubuntu系統(tǒng)下Docker的配置文件是/etc/default/docker；CentOS系統(tǒng)配置文件存放在/etc/sysconfig/docker。4.hadoop的三種運行模式是什么？它們的主要區(qū)別是？(1)獨立（本地）運行模式：無需任何守護(hù)進(jìn)程，所有的程序都運行在同一個JVM上執(zhí)行。在獨立模式下調(diào)試MR程序非常高效方便。所以一般該模式主要是在學(xué)習(xí)或者開發(fā)階段調(diào)試使用。(2)偽分布式模式：Hadoop守護(hù)進(jìn)程運行在本地機(jī)器上，模擬一個小規(guī)模的集群，換句話說，可以配置一臺機(jī)器的Hadoop集群,偽分布式是完全分布式的一個特例。(3)完全分布式模式：Hadoop守護(hù)進(jìn)程運行在一個集群上。所謂分布式要啟動守護(hù)進(jìn)程，即：使用分布式hadoop時，要先啟動一些準(zhǔn)備程序進(jìn)程，然后才能使用比如start-dfs.sh,start-yarn.sh。而本地模式不需要啟動這些守護(hù)進(jìn)程。5.簡述Hadoop的組件？

Hadoop是一個開源分布式計算平臺架構(gòu)，其組件主要包括：（1）HDFS（分布式文件管理系統(tǒng)）

（2）MapReduce（分布式計算框架）

（3）Hive（基于Hadoop的數(shù)據(jù)倉庫）

（4）Pig（基于Hadoop的數(shù)據(jù)流系統(tǒng)）

（5）HBase（一個分布式面向列的數(shù)據(jù)庫）

（6）Spark（快速和通用計算的Hadoop數(shù)據(jù)引擎）

（7）ZooKeeper（分布式協(xié)作服務(wù)）6.Hadoop2.x的守護(hù)進(jìn)程有哪些？（1）NameNode（元數(shù)據(jù)服務(wù)器）

主節(jié)點，存儲文件的元數(shù)據(jù)（文件名，文件目錄結(jié)構(gòu)，文件屬性-生成時間，副本數(shù)，文件權(quán)限），以及每個文件的塊列表和塊所在的DataNode等。（2）SecondaryNameNode（輔助元數(shù)據(jù)服務(wù)器）

用來監(jiān)控HDFS狀態(tài)的輔助后臺程序，每隔一段時間獲取HDFS元數(shù)據(jù)快照。（3）DataNodes（塊存儲）

在本地文件系統(tǒng)存儲文件塊數(shù)據(jù)，以及塊數(shù)據(jù)校驗（4）ResourceManageResourceManage是一個中心的服務(wù)，它做的事情是調(diào)度、啟動每一個Job所屬的ApplicationMaster、另外監(jiān)控ApplicationMaster的存在情況。ResourceManager負(fù)責(zé)作業(yè)與資源的調(diào)度，接收J(rèn)obSubmitter提交的作業(yè)，按照作業(yè)的上下文（Context）信息，以及從NodeManager收集來的狀態(tài)信息，啟動調(diào)度過程，分配一個Container作為ApplicationMaster。（5）NodeManager負(fù)責(zé)Container狀態(tài)的維護(hù)，并向ResourceManage保持心跳。1.hive內(nèi)部表和外部表的區(qū)別？未被external修飾的是內(nèi)部表，被external修飾的為外部表。區(qū)別:（1）內(nèi)部表數(shù)據(jù)由Hive自身管理，外部表數(shù)據(jù)由HDFS管理；（2）內(nèi)部表數(shù)據(jù)存儲的位置是hive.metastore.warehouse.dir（默認(rèn)：/user/hive/warehouse），外部表數(shù)據(jù)的存儲位置由自己制定（如果沒有LOCATION，Hive將在HDFS上的/user/hive/warehouse文件夾下以外部表的表名創(chuàng)建一個文件夾，并將屬于這個表的數(shù)據(jù)存放在這里）；（3）刪除內(nèi)部表會直接刪除元數(shù)據(jù)（metadata）及存儲數(shù)據(jù)；刪除外部表僅僅會刪除元數(shù)據(jù)，HDFS上的文件并不會被刪除。2.Hive有哪些方式保存元數(shù)據(jù)，各有哪些特點？Hive支持三種不同的元存儲服務(wù)器，分別為：內(nèi)嵌式元存儲服務(wù)器、本地元存儲服務(wù)器、遠(yuǎn)程元存儲服務(wù)器，每種存儲方式使用不同的配置參數(shù)。（1）內(nèi)嵌式元存儲主要用于單元測試，在該模式下每次只有一個進(jìn)程可以連接到元存儲，Derby是內(nèi)嵌式元存儲的默認(rèn)數(shù)據(jù)庫。（2）在本地模式下，每個Hive客戶端都會打開到數(shù)據(jù)存儲的連接并在該連接上請求SQL查詢。（3）在遠(yuǎn)程模式下，所有的Hive客戶端都將打開一個到元數(shù)據(jù)服務(wù)器的連接，該服務(wù)器依次查詢元數(shù)據(jù)，元數(shù)據(jù)服務(wù)器和客戶端之間使用Thrift協(xié)議通信。3.請分析Hive表關(guān)聯(lián)查詢中出現(xiàn)的數(shù)據(jù)傾斜的原因？如何解決數(shù)據(jù)傾斜的問題？數(shù)據(jù)傾斜問題在MapReduce編程模型中十分常見，根本原因就是大量相同的key被分配到一個reduce里，造成一個reduce任務(wù)較多，處理時間較長，而其他的reduce任務(wù)較少。常見的數(shù)據(jù)傾斜有哪些原因：（1）key分布不均衡；（2）業(yè)務(wù)問題后者業(yè)務(wù)數(shù)據(jù)本身的問題，某些數(shù)據(jù)比較集中；（3）建表的時候考慮不周；（4）某些sql語句本身就有數(shù)據(jù)傾斜，例如：大表join小表：其實小表的key集中，分發(fā)到某一個或者幾個reduce上的數(shù)據(jù)遠(yuǎn)遠(yuǎn)高于平均值大表join大表：空值或無意義值：如果缺失的項很多，在做join時這些空值就會非常集中，拖累進(jìn)度。groupby：groupby的時候維度過小，某值的數(shù)量過多，處理某值的reduce非常耗時間。Countdistinct：某特殊值過多，處理此特殊值的reduce耗時。Hive數(shù)據(jù)傾斜解決方法：（1）參數(shù)調(diào)節(jié)：hive.map.aggr=true；有數(shù)據(jù)傾斜的時候進(jìn)行負(fù)載均衡，當(dāng)選項設(shè)定為true，生成的查詢計劃會有兩個MRJob。第一個MRJob中，Map的輸出結(jié)果集合會隨機(jī)分不到Reduce中，每個Reduce做部分聚合操作，并輸出結(jié)果，這樣處理的結(jié)果是相同于GroupByKey有可能被分發(fā)到不同的Reduce中，從而達(dá)到負(fù)載均衡的目的；第二個MRJob再根據(jù)預(yù)處理的數(shù)據(jù)結(jié)果按照GroupByKey分不到Reduce中(這個過程可以保證相同的GroupByKey被分布到同一個Reduce中)，最后完成最終的聚合操作。（2）SQL調(diào)整如何join：關(guān)于驅(qū)動表的選取，選用joinkey分布最均勻的表作為驅(qū)動表，做好列裁剪和filter操作，以達(dá)到兩表做join的時候，數(shù)據(jù)量相對變小的效果。大小表join的時候：使用mapjoin讓小的維度表先進(jìn)內(nèi)存，在map端完成reduce。效率很高。大表join大表的時候：把空值的key變成一個字符串加上隨機(jī)數(shù)，把傾斜的數(shù)據(jù)分到不同的reduce上，由于null值關(guān)聯(lián)不上，處理后不影響最終的結(jié)果。countdistinct大量相同特殊值，將這些值為空的情況單獨處理，如果是計算countdistinct，可以不用處理，直接過濾，在最后結(jié)果中加1即可。如果還有其他的計算，需要進(jìn)行g(shù)roupby，可以先將那些值為空的記錄單獨處理，再和其他計算結(jié)果進(jìn)行union。groupby維度過小的時候：采用sum()groupby的方法來替換count(distinct)完成計算。單獨處理傾斜key：一般來講傾斜的key都很少，我們可以將它們抽樣出來，對應(yīng)的行單獨存入臨時表中，然后打上隨機(jī)數(shù)前綴，最后再進(jìn)行聚合?；蛘呤窍葘ey做一層hash，先將數(shù)據(jù)隨機(jī)打散讓它的并行度變大，再匯集。其實辦法一樣。Zookeeper集群中有哪些角色？在一個集群中，最少需要3臺?；蛘弑ＷC2N+1臺，保證集群中有奇數(shù)臺的主要原因是為了選舉算法。Zookeeper集群是一個主從集群，它一般是由一個Leader(領(lǐng)導(dǎo)者)和多個Follower(跟隨者)組成。此外，針對訪問量比較大的Zookeeper集群，還可新增Observer(觀察者)。Zookeeper集群中的三種角色各司其職，共同完成分布式協(xié)調(diào)服務(wù)，如下圖所示。Zookeeper集群架構(gòu)圖（1）Leader它是Zookeeper集群工作的核心，也是事務(wù)性請求(寫操作)的唯一調(diào)度和處理者，它保證集群事務(wù)處理的順序性，同時負(fù)責(zé)進(jìn)行投票的發(fā)起和決議，以及更新系統(tǒng)狀態(tài)。（2）Follower它負(fù)責(zé)處理客戶端的非事務(wù)(讀操作)請求，如果接收到客戶端發(fā)來的事務(wù)性請求，則會轉(zhuǎn)發(fā)給Leader，讓Leader進(jìn)行處理，同時還負(fù)責(zé)在Leader選舉過程中參與投票。（3）Observer它負(fù)責(zé)觀察Zookeeper集群的最新狀態(tài)的變化，并且將這些狀態(tài)進(jìn)行同步。對于非事務(wù)性請求可以進(jìn)行獨立處理;對于事務(wù)性請求，則會轉(zhuǎn)發(fā)給Leader服務(wù)器進(jìn)行處理。它不會參與任何形式的投票，只提供非事務(wù)性的服務(wù)，通常用于在不影響集群事務(wù)處理能力的前提下，提升集群的非事務(wù)處理能力(提高集群讀的能力，也降低了集群選主的復(fù)雜程度)。什么是Zookeeper中的腦裂？對于Zookeeper來說有一個重要問題，就是根據(jù)什么來判斷一個節(jié)點死亡(down掉)了？Zookeeper通過內(nèi)部心跳機(jī)制來確定leader的狀態(tài)，一旦leader出現(xiàn)意外Zookeeper能很快獲悉并且通知其他的follower，其他follower在之后作出相關(guān)反應(yīng)，這樣就完成了一個切換，這種模式也是比較通用的模式。但是這里面有個很嚴(yán)重的問題，因為心跳出現(xiàn)超時可能是leader掛了，也可能是zookeeper節(jié)點之間網(wǎng)絡(luò)出現(xiàn)了問題，導(dǎo)致leader假死的情況，leader其實并未死掉，但是由于假死會發(fā)起新的leader選舉，選舉出一個新的leader，但舊的leader網(wǎng)絡(luò)又通了，導(dǎo)致出現(xiàn)了兩個leader，有的客戶端連接到老的leader，而有的客戶端則連接到新的leader。這樣就會出現(xiàn)很嚴(yán)重問題。Zookeeper是如何解決腦裂問題的？要解決Split-Brain腦裂的問題，一般有下面幾種種方法：（1）Quorums(法定人數(shù))方式:比如3個節(jié)點的集群，Quorums=2,也就是說集群可以容忍1個節(jié)點失效，這時候還能選舉出1個leader，集群還可用。比如4個節(jié)點的集群，它的Quorums=3，Quorums要超過3，相當(dāng)于集群的容忍度還是1，如果2個節(jié)點失效，那么整個集群還是無效的。這是zookeeper防止"腦裂"默認(rèn)采用的方法。（2）Redundantcommunications(冗余通信)方式：集群中采用多種通信方式，防止一種通信方式失效導(dǎo)致集群中的節(jié)點無法通信。4.Zookeeper有哪幾種部署模式？Zookeeper有三種部署模式：（1）單機(jī)部署：一臺集群上運行；（2）偽集群部署：一臺集群啟動多個Zookeeper實例運行。（3）集群部署：多臺集群運行；5.Zookeeper的工作原理？Zookeeper的核心是原子廣播，這個機(jī)制保證了各個Server之間的同步。實現(xiàn)這個機(jī)制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式（選主）和廣播模式（同步）。Zab協(xié)議的全稱是ZookeeperAtomicBroadcast（Zookeeper原子廣播）。Zookeeper是通過Zab協(xié)議來保證分布式事務(wù)的最終一致性。Zab協(xié)議要求每個Leader都要經(jīng)歷三個階段：發(fā)現(xiàn)，同步，廣播。當(dāng)服務(wù)啟動或者在領(lǐng)導(dǎo)者崩潰后，Zab就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來，且大多數(shù)Server完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。為了保證事務(wù)的順序一致性，zookeeper采用了遞增的事務(wù)id號（zxid）來標(biāo)識事務(wù)。所有的提議（proposal）都在被提出的時候加上了zxid。實現(xiàn)中zxid是一個64位的數(shù)字，它高32位是epoch用來標(biāo)識leader關(guān)系是否改變，每次一個leader被選出來，它都會有一個新的epoch，標(biāo)識當(dāng)前屬于那個leader的時期。低32位用于遞增計數(shù)。每個Server在工作過程中有四種狀態(tài)：LOOKING：當(dāng)前Server不知道leader是誰，正在搜尋。LEADING：當(dāng)前Server即為選舉出來的leader。FOLLOWING：leader已經(jīng)選舉出來，當(dāng)前Server與之同步。OBSERVING：觀察者狀態(tài)；表明當(dāng)前服務(wù)器角色是ObserverHRegionServer宕機(jī)如何處理？（1）ZooKeeper會監(jiān)控HRegionServer的上下線情況，當(dāng)ZK發(fā)現(xiàn)某個HRegionServer宕機(jī)之后會通知HMaster進(jìn)行失效備援；（2）該HRegionServer會停止對外提供服務(wù)，就是它所負(fù)責(zé)的region暫時停止對外提供服務(wù)；（3）HMaster會將該HRegionServer所負(fù)責(zé)的region轉(zhuǎn)移到其他HRegionServer上，并且會對HRegionServer上存在內(nèi)存中還未持久化到磁盤中的數(shù)據(jù)進(jìn)行恢復(fù)；（4）這個恢復(fù)的工作是由WAL重播來完成，這個過程如下：①WAL實際上就是一個文件，存在/hbase/WAL/對應(yīng)RegionServer路徑下。②宕機(jī)發(fā)生時，讀取該RegionServer所對應(yīng)的路徑下的WAL文件，然后根據(jù)不同的region切分成不同的臨時文件recover.edits。③當(dāng)region被分配到新的RegionServer中，RegionServer讀取region時會進(jìn)行判斷是否存在recover.edits，如果存在則進(jìn)行恢復(fù)。2.請描述HBase讀寫流程？（1）讀操作如下：①HRegionServer保存著Meta表以及表數(shù)據(jù)，要訪問表數(shù)據(jù)，首先Client先去訪問Zookeeper，從Zookeeper里面獲取Meta表所在的位置信息，即找到這個Meta表在哪個HRegionServer上保存著。②接著Client通過剛才獲取到的HRegionServer的IP來訪問Meta表所在的HRegionServer，從而讀取到Meta，進(jìn)而獲取到Meta表中存放的元數(shù)據(jù)。③Client通過元數(shù)據(jù)中存儲的信息，訪問對應(yīng)的HRegionServer，然后掃描所在HRegionServer的Memstore和Storefile來查詢數(shù)據(jù)。④最后HRegionServer把查詢到的數(shù)據(jù)響應(yīng)給Client。（2）寫操作如下：①Client先訪問Zookeeper，找到Meta表，并獲取Meta表元數(shù)據(jù)。②確定當(dāng)前將要寫入的數(shù)據(jù)所對應(yīng)的HRegion和HRegionServer服務(wù)器。③Client向該HRegionServer服務(wù)器發(fā)起寫入數(shù)據(jù)請求，然后HRegionServer收到請求并響應(yīng)。④Client先把數(shù)據(jù)寫入到HLog，以防止數(shù)據(jù)丟失。⑤然后將數(shù)據(jù)寫入到Memstore。⑥如果HLog和Memstore均寫入成功，則這條數(shù)據(jù)寫入成功⑦如果Memstore達(dá)到閾值，會把Memstore中的數(shù)據(jù)Flush到Storefile中。⑧當(dāng)Storefile越來越多，會觸發(fā)Compact合并操作，把過多的Storefile合并成一個大的Storefile。⑨當(dāng)Storefile越來越大，Region也會越來越大，達(dá)到閾值后，會觸發(fā)Split操作，將Region一分為二。3.如何提高HBase客戶端的讀寫性能？（1）開啟Bloomfilter過濾器，開啟Bloomfilter比沒開啟要快得多。（2）HBase對于內(nèi)存有特別的需求，在硬件允許的情況下配足夠多的內(nèi)存給它（3）通過修改hbase-env.sh中的exportHBASE_HEAPSIZE=3000#默認(rèn)為1000（4）增大RPC數(shù)量通過修改hbase-site.xml中的hbase.regionserver.handler.count屬性，可以適當(dāng)?shù)姆糯驲PC數(shù)量，默認(rèn)值為10有點小。請描述HBase實時查詢的原理。實時查詢，可以認(rèn)為是從內(nèi)存中查詢，HBase的機(jī)制是數(shù)據(jù)先寫入到內(nèi)存中，當(dāng)數(shù)據(jù)量達(dá)到一定的量（如128M），再寫入磁盤中，在內(nèi)存中，是不進(jìn)行數(shù)據(jù)的更新或合并操作的，只增加數(shù)據(jù)，這使得用戶的寫操作只要進(jìn)入內(nèi)存中就可以立即返回，保證了HBaseI/O的高性能。HBase如何導(dǎo)入數(shù)據(jù)？（1）通過HBaseAPI進(jìn)行批量寫入數(shù)據(jù)；（2）使用Sqoop工具批量導(dǎo)數(shù)到HBase集群；（3）使用MapReduce批量導(dǎo)入：通常MapReduce在寫HBase時使用的是TableOutputFormat方式，在Reduce中直接生成Put對象寫入HBase。（4）HBaseBulkLoad的方式:利用HBase數(shù)據(jù)按照HFile格式存儲在HDFS的原理，使用Mapreduce直接生成HFile格式文件后，RegionServers再將HFile文件移動到相應(yīng)的Region目錄下。6.請描述HBase的存儲結(jié)構(gòu)？HBase中的每張表都通過行鍵(RowKey)按照一定的范圍被分割成多個子表（HRegion），默認(rèn)一個HRegion超過256M就要被分割成兩個，由HRegionServer管理，HRegionServer管理哪些HRegion由Hmaster分配。HRegion存取一個子表時，會創(chuàng)建一個HRegion對象，然后對表的每個列族（ColumnFamily）創(chuàng)建一個Store實例，每個Store都會有0個或多個StoreFile與之對應(yīng)，每個StoreFile都會對應(yīng)一個HFile，HFile就是實際的存儲文件，因此，一個HRegion還擁有一個MemStore實例。7.HBase適用于怎樣的情景？（1）半結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)對于數(shù)據(jù)結(jié)構(gòu)字段不夠確定或雜亂無章很難按一個概念去進(jìn)行抽取的數(shù)據(jù)適合用HBase。2）記錄非常稀疏RDBMS的行有多少列是固定的，為Null的列浪費了存儲空間。而HBase為Null的Column不會被存儲，這樣既節(jié)省了空間又提高了讀性能。3）多版本數(shù)據(jù)根據(jù)Rowkey和Columnkey定位到的Value可以有任意數(shù)量的版本值，因此對于需要存儲變動歷史記錄的數(shù)據(jù)，用HBase就非常方便了。業(yè)務(wù)上一般只需要最新的值，但有時可能需要查詢到歷史值。4）超大數(shù)據(jù)量當(dāng)數(shù)據(jù)量越來越大，RDBMS數(shù)據(jù)庫撐不住了，就出現(xiàn)了讀寫分離策略，通過一個Master專門負(fù)責(zé)寫操作，多個Slave負(fù)責(zé)讀操作，服務(wù)器成本倍增。隨著壓力增加，Master撐不住了，這時就要分庫了，把關(guān)聯(lián)不大的數(shù)據(jù)分開部署，一些join查詢不能用了，需要借助中間層。隨著數(shù)據(jù)量的進(jìn)一步增加，一個表的記錄越來越大，查詢就變得很慢，于是又得搞分表，比如按ID取模分成多個表以減少單個表的記錄數(shù)。采用HBase就簡單了，只需要增加機(jī)器即可，HBase會自動水平切分?jǐn)U展，跟Hadoop的無縫集成保障了其數(shù)據(jù)可靠性（HDFS）和海量數(shù)據(jù)分析的高性能（MapReduce）。1.如何解決在使用Sqoop進(jìn)行數(shù)據(jù)導(dǎo)入和導(dǎo)出時，null值處理的一致性問題？Hive中的Null在底層是以“\N”來存儲，而MySQL中的Null在底層就是Null，為了保證數(shù)據(jù)兩端的一致性。在導(dǎo)出數(shù)據(jù)時采用--input-null-string和--input-null-non-string兩個參數(shù)。導(dǎo)入數(shù)據(jù)時采用--null-string和--null-non-string。2.Sqoop導(dǎo)入到Hive時特殊字符導(dǎo)致數(shù)據(jù)變亂方法1:sqoop的sql中對含有特殊字符的字段進(jìn)行replace操作方法2:使用hive-drop-import-delims，這是sqoop官方提供的一個參數(shù)，導(dǎo)入到hive時，遇到特殊字符就會將改字符丟棄。Sqoop還提供了另一個參數(shù)--hive-delims-replacement，它會將特殊字符替換為我們設(shè)定的字符。3.Sqoop導(dǎo)入到Hive時為什么會出現(xiàn)數(shù)據(jù)傾斜？怎么解決？（1）數(shù)據(jù)分布的不均勻，當(dāng)涉及到多個map任務(wù)的時候，勢必有數(shù)據(jù)分配不均的可能，試想如果split-by的id字段是一個數(shù)字類型，首先sqoop會執(zhí)行這么一條sql語句，selectmin(id),max(id)fromtable_name也就是先確定字段的范圍，再對這個范圍根據(jù)map數(shù)量劃分出等寬的區(qū)間（范圍是1-100，如果按照默認(rèn)有4個map，就會分成1-25,26-50,51-75,75-100），如果數(shù)據(jù)大量分布到其中一個區(qū)間時，就會出現(xiàn)數(shù)據(jù)傾斜。（2）當(dāng)split-by的字段是字符串時，可能出現(xiàn)數(shù)據(jù)傾斜。因為sqoop的split-by對字符串類型的支持不好，無法進(jìn)行map劃分，可能導(dǎo)致數(shù)據(jù)都集中在一個map上。解決辦法：（1）增加并行度可以通過增加Sqoop導(dǎo)入任務(wù)的并行度來減少數(shù)據(jù)傾斜問題。可以通過增加map數(shù)或者使用--split-by參數(shù)指定合適的列進(jìn)行切分?jǐn)?shù)據(jù)，從而提高導(dǎo)入任務(wù)的并行度。（2）采用隨機(jī)切分使用--autoreset-to-one-mapper參數(shù)可以讓Sqoop在導(dǎo)入數(shù)據(jù)時對數(shù)據(jù)進(jìn)行隨機(jī)切分，從而減少數(shù)據(jù)傾斜問題。（3）數(shù)據(jù)預(yù)處理可以在導(dǎo)入數(shù)據(jù)前對數(shù)據(jù)進(jìn)行預(yù)處理，比如將數(shù)據(jù)按照某個字段進(jìn)行分組，然后按照分組后的結(jié)果進(jìn)行導(dǎo)入，從而減少數(shù)據(jù)傾斜問題。4.Pig邏輯計劃和物理計劃有什么區(qū)別？當(dāng)PigLatinScript轉(zhuǎn)換為MapReduce作業(yè)時，Pig會經(jīng)歷一些步驟。在執(zhí)行基本的解析和語義檢查后，它會生成一個邏輯計劃。邏輯計劃描述了Pig在執(zhí)行期間必須執(zhí)行的邏輯運算符。在此之后，Pig生成了一個物理計劃。物理計劃描述了執(zhí)行腳本所需的物理操作符。5.為什么在Pig編程時需要MapReduce？Pig使許多Hadoop數(shù)據(jù)分析問題更容易執(zhí)行，其使用的語言是：PigLatin，用PigLatin編寫的程序就像用SQL編寫的查詢，需要一個執(zhí)行引擎來執(zhí)行查詢。所以，當(dāng)一個程序用PigLatin編寫時，Pig編譯器會將程序轉(zhuǎn)換為MapReduce作業(yè)，也就是需要MapReduce充當(dāng)執(zhí)行引擎。簡述Flume的組成？Agent：一個jvm進(jìn)程，以event（事件）為基本單元對數(shù)據(jù)進(jìn)行傳輸。Agent主要有3個部分組成，Source、Channel、Sink。Source是負(fù)責(zé)接收數(shù)據(jù)到FlumeAgent的組件。Source組件可以處理各種類型、各種格式的日志數(shù)據(jù)，包括netcattcpsource:用來監(jiān)聽端口數(shù)據(jù)；execsource表示執(zhí)行l(wèi)inux命令來讀取文件，適合監(jiān)控一個實時追加的文件，不能實現(xiàn)斷點續(xù)傳，如果Agent掛了會把所有文件內(nèi)容重新讀一遍；spoolingDirectorySource適合同步新文件，但不適合對實時追加日志的文件監(jiān)聽同步，讀取新文件后會標(biāo)記.completed，但是這個文件無論是否有變化，都不會再讀取了；TaildirSource適合用于監(jiān)聽多個實時追加的文件，Taildirsource維護(hù)了一個Json格式的PositionFile,會定期往PositionFile更新每個文件讀取到的最新的位置,因此能夠進(jìn)行斷點續(xù)讀,Agent重啟后可以斷點續(xù)讀；kafkasource實現(xiàn)數(shù)據(jù)從Kafka到Flume的無縫傳輸。Sink不斷地輪詢Channel中的事件且批量地移除它們，并將這些事件批量寫入到存儲或索引系統(tǒng)、或者被發(fā)送到另一個FlumeAgent。常用的Sink有l(wèi)oggersink：將數(shù)據(jù)寫入日志；hdfssink：將輸出寫到hdfs上；Avrosink：將數(shù)據(jù)發(fā)送到其他的Flume；FileRollsink：將數(shù)據(jù)保存到本地磁盤。（3）Channel是位于Source和Sink之間的緩沖區(qū)。因此，Channel允許Source和Sink運作在不同的速率上。Channel是線程安全的，可以同時處理幾個Source的寫入操作和幾個Sink的讀取操作。Flume自帶兩種Channel：MemoryChannel：內(nèi)存中的隊列，使用場景主要為不需要關(guān)心內(nèi)存丟失的情況下，因為程序死亡和機(jī)器宕機(jī)或者重啟都會造成數(shù)據(jù)丟失。FileChannel:將所有事件寫到磁盤，使用場景主要為需要關(guān)心數(shù)據(jù)丟失的情況，因為事件被寫入到磁盤所以程序關(guān)閉、宕機(jī)并不會造成數(shù)據(jù)丟失。為什么要使用kafka，為什么要使用消息隊列？（1）緩沖和削峰：上游數(shù)據(jù)時有突發(fā)流量，下游可能來不及接收，或者下游沒有足夠多的機(jī)器來保證冗余，Kafka在中間可以起到一個緩沖的作用，把消息暫存在Kafka中，下游服務(wù)就可以按照自己的節(jié)奏進(jìn)行數(shù)據(jù)的處理。（2）解耦和擴(kuò)展性：項目開始的時候，并不能確定具體需求。消息隊列可以作為一個接口層，解耦重要的業(yè)務(wù)流程。只需要遵守約定，針對數(shù)據(jù)編程即可獲取擴(kuò)展能力。（3）冗余：可以采用一對多的方式，一個生產(chǎn)者發(fā)布消息，可以被多個訂閱Topic的服務(wù)消費，供多個毫無關(guān)聯(lián)的業(yè)務(wù)使用。(4)健壯性：消息隊列可以堆積請求，所以消費端業(yè)務(wù)即使短時間死掉，也不會影響主要業(yè)務(wù)的正常進(jìn)行。(5)異步通信：消息隊列提供了異步處理機(jī)制，允許用戶把一個消息放入隊列，但并不立即處理它?？梢栽谛枰臅r候再去處理它們。8.簡述Kafka中的Broker的作用？Broker是消息的代理，Producers往Brokers里面的指定Topic中寫消息，Consumers從Brokers里面拉取指定Topic的消息，然后進(jìn)行業(yè)務(wù)處理，Broker在中間起到一個代理保存消息的中轉(zhuǎn)站。9.Kafka中的Zookeeper起到什么作用？Zookeeper是一個分布式的協(xié)調(diào)組件，早期版本的Kafka用ZK做Meta信息存儲，Consumer的消費狀態(tài)，Group的管理以及offset的值?？紤]到ZK本身的一些因素以及整個架構(gòu)較大概率存在單點問題，新版本中逐漸弱化了Zookeeper的作用。新的Consumer使用了Kafka內(nèi)部的GroupCoordination協(xié)議，也減少了對Zookeeper的依賴，但是Broker依然依賴于ZK，Zookeeper在Kafka中還用來選舉Controller和檢測Broker是否存活等等。10.KafkaProducer發(fā)送數(shù)據(jù)時，ack為0，1，-1有什么含義？設(shè)置-1的時候，什么情況下，Leader會認(rèn)為一條消息Commit了？（1）1（默認(rèn)）數(shù)據(jù)發(fā)送到Kafka后，經(jīng)過Leader成功接收消息的確認(rèn)，即為發(fā)送成功。在這種情況下，如果Leader宕機(jī)了，則會丟失數(shù)據(jù)。(2)0生產(chǎn)者（Producer）將數(shù)據(jù)發(fā)送出去后不再等待任何返回。這種情況下數(shù)據(jù)傳輸效率最高，但是數(shù)據(jù)可靠性確是最低的。（3）-1生產(chǎn)者（Producer）將數(shù)據(jù)發(fā)送出去后，需要等待ISR中的所有Follower都確認(rèn)接收到數(shù)據(jù)后才算一次發(fā)送完成，可靠性最高。當(dāng)ISR中所有Replica都向Leader發(fā)送ACK時，Leader才Commit，這時候Producer才能認(rèn)為請求中的一條消息Commit了。11.Flink數(shù)據(jù)傾斜如何查看？Flink出現(xiàn)數(shù)據(jù)傾斜如何處理？查看Flink數(shù)據(jù)傾斜：在Flink的WebUI中可以看到數(shù)據(jù)傾斜的情況，就是每個SubTask處理的數(shù)據(jù)量差距很大。解決方案：(1)KeyBy之前發(fā)生數(shù)據(jù)傾斜數(shù)據(jù)源的數(shù)據(jù)本身就不均勻,在KeyBy之前就存在數(shù)據(jù)傾斜（由于某些原因Kafka的Topic中某些Partition的數(shù)據(jù)量較大，某些Partition的數(shù)據(jù)量較少。對于不存在KeyBy的Flink任務(wù)也會出現(xiàn)該情況。這種情況需要讓Flink任務(wù)強制進(jìn)行Shuffle。使用Shuffle、Rebalance或Rescale算子即可將數(shù)據(jù)均勻分配，從而解決數(shù)據(jù)傾斜的問題。(2)KeyBy后的聚合操作存在數(shù)據(jù)傾斜在KeyBy上游算子數(shù)據(jù)發(fā)送之前，首先在上游算子的本地對數(shù)據(jù)進(jìn)行聚合后再發(fā)送到下游，使下游接收到的數(shù)據(jù)量大大減少，從而使得KeyBy之后的聚合操作不再是任務(wù)的瓶頸。但是這要求聚合操作必須是多條數(shù)據(jù)或者一批數(shù)據(jù)才能聚合，單條數(shù)據(jù)沒有辦法通過聚合來減少數(shù)據(jù)量。(3)KeyBy后的窗口聚合操作存在數(shù)據(jù)傾斜因為使用了窗口，變成了有界數(shù)據(jù)的處理，窗口默認(rèn)觸發(fā)時才會輸出一條結(jié)果發(fā)往下游，所以可以使用兩階段聚合的方式,實現(xiàn)思路：第一階段聚合：Key拼接隨機(jī)數(shù)前綴或后綴，再進(jìn)行KeyBy、開窗。需要注意，聚合完不再是WindowedStream要獲取WindowEnd作為窗口標(biāo)記作為第二階段分組依據(jù)，避免不同窗口的結(jié)果聚合到一起）。第二階段聚合：去掉隨機(jī)數(shù)前綴或后綴，按照原來的Key及WindowEnd作KeyBy進(jìn)行聚合操作。12.Flink提交的時候并行度如何確定，資源如何配置？并行度根據(jù)KafkaTopic的并行度確定，資源按照一個并行度3個G進(jìn)行配置。1.HadoopHA如何保證NameNode數(shù)據(jù)存儲安全？HadoopHA的高可用架構(gòu)主要分為下面幾個部分：Active（活躍狀態(tài)）NameNode和Standby（待命）NameNode：兩臺NameNode形成互備，一臺處于Active狀態(tài)，為主NameNode，另外一臺處于Standby狀態(tài)，為備用NameNode，只有主NameNode才能對外提供讀寫服務(wù)。主備切換控制器ZKFailoverController作為獨立的進(jìn)程運行，對NameNode的主備切換進(jìn)行總體控制。ZKFailoverController能及時檢測到NameNode的健康狀況，在主NameNode故障時借助Zookeeper實現(xiàn)自動的主備選舉和切換。元數(shù)據(jù)信息同步在HA方案中采用的是“共享存儲”，兩個NameNode為了數(shù)據(jù)同步，會通過一組稱作JournalNodes的獨立進(jìn)程進(jìn)行相互通信。每次NameNode寫EditLog的時候，除了向本地磁盤寫入EditLog之外，也會并行地向JournalNode集群之中的每一個JournalNode發(fā)送寫請求，只要大多數(shù)的JournalNode節(jié)點返回成功就認(rèn)為向JournalNode集群寫入EditLog成功。當(dāng)ActiveNN故障時，Zookeeper創(chuàng)建的臨時節(jié)點ActiveStandbyElectorLock將要被刪除，其他NN節(jié)點注冊的Watcher來監(jiān)聽到該變化，NN節(jié)點的ZKFailoverController會馬上再次進(jìn)入到創(chuàng)建/hadoop-ha/${services}/ActiveStandbyElectorLock節(jié)點的流程，如果創(chuàng)建成功，這個本來處于Standby狀態(tài)的NameNode就選舉為主NameNode，并隨后開始切換為Active狀態(tài)。新當(dāng)選的ActiveNN將確保從QJM(QuorumJournalManager)同步完所有的元數(shù)據(jù)文件EditLog文件，然后切換為主節(jié)點，并向外提供服務(wù)。HadoopHA集群都要啟動哪些進(jìn)程，請分別簡述它們的作用？Namenode：(1)維護(hù)文件系統(tǒng)的目錄樹，管理文件系統(tǒng)的NameSpace、(2)管理元數(shù)據(jù)信息、(3)接收用戶的請求。DFSZKFailoverController(ZKFC)：負(fù)責(zé)NameNode的故障切換。QuorumPeerMain：Zookeeper進(jìn)程。DataNode：HDFS的工作節(jié)點，負(fù)責(zé)實際的數(shù)據(jù)存儲。ResourceManager：YARN集群中負(fù)責(zé)資源協(xié)調(diào)和管理的進(jìn)程。NodeManager：ResourceManager在每臺機(jī)器上的代理，負(fù)責(zé)容器管理，并監(jiān)控它們的資源使用情況，以及向ResourceManager/Scheduler提供資源使用情況報告。JournalNode：用來同步ActiveNameNode和StandbyNameNode之間的元數(shù)據(jù)。3.請簡述HadoopHA模式下集群啟動的步驟？（1）啟動ZooKeeper集群，命令：zkServer.shstart。（2）格式化ZooKeeper集群，目的是在ZooKeeper集群上建立HA的相應(yīng)節(jié)點，命令：hdfszkfc–formatZK。（3）啟動JournalNode集群，命令：hadoop-daemon.shstartjournalnode。（4）格式化master1的NameNode，命令：hdfsnamenode-format。（5）在master1上啟動集群的NameNode，命令：hadoop-daemon.shstartnamenode。（6）在slave1上執(zhí)行，將master1上的NameNode數(shù)據(jù)同步到slave1上，命令：hdfsnamenode-bootstrapStandby。（7）啟動slave1的NameNode，命令：hadoop-daemon.shstartnamenode。（8）將master1的NameNode置成active狀態(tài)，分別在active和standby上執(zhí)行命令：hadoop-daemon.shstartzkfc。（9）啟動所有的DataNode，命令：hadoop-daemon.shstartdatanode。（10）啟動Yarn,命令：start-yarn.sh。1．請簡述Ambari系統(tǒng)的作用？Ambari使得系統(tǒng)管理員能夠進(jìn)行以下操作。（1）提供Hadoop集群①Ambari提供了跨任意數(shù)量的主機(jī)安裝Hadoop服務(wù)的分步向?qū)?。②Ambari可處理集群的Hadoop服務(wù)配置。（2）管理Hadoop集群Ambari提供集中管理，用于在整個集群中啟動、停止和重新配置Hadoop服務(wù)。（3）監(jiān)控Hadoop集群①Ambari提供了一個儀表板，用于監(jiān)控Hadoop集群的運行狀況和狀態(tài)。②Ambari可利用Ambari指標(biāo)系統(tǒng)進(jìn)行指標(biāo)收集。③Ambari可利用AmbariAlertFramework進(jìn)行系統(tǒng)警報，并在需要管理員注意時通知管理員（例如，節(jié)點出現(xiàn)故障、剩余磁盤空