Hadoop平臺搭建與應(yīng)用（第2版）（微課版）-課后習(xí)題及答案 項(xiàng)目5

Hadoop平臺搭建與應(yīng)用項(xiàng)目2Hive環(huán)境搭建與基本操作PAGE68PAGE691.如何解決在使用Sqoop進(jìn)行數(shù)據(jù)導(dǎo)入和導(dǎo)出時(shí)，null值處理的一致性問題？Hive中的Null在底層是以“\N”來存儲，而MySQL中的Null在底層就是Null，為了保證數(shù)據(jù)兩端的一致性。在導(dǎo)出數(shù)據(jù)時(shí)采用--input-null-string和--input-null-non-string兩個(gè)參數(shù)。導(dǎo)入數(shù)據(jù)時(shí)采用--null-string和--null-non-string。2.Sqoop導(dǎo)入到Hive時(shí)特殊字符導(dǎo)致數(shù)據(jù)變亂方法1:sqoop的sql中對含有特殊字符的字段進(jìn)行replace操作方法2:使用hive-drop-import-delims，這是sqoop官方提供的一個(gè)參數(shù)，導(dǎo)入到hive時(shí)，遇到特殊字符就會(huì)將改字符丟棄。Sqoop還提供了另一個(gè)參數(shù)--hive-delims-replacement，它會(huì)將特殊字符替換為我們設(shè)定的字符。3.Sqoop導(dǎo)入到Hive時(shí)為什么會(huì)出現(xiàn)數(shù)據(jù)傾斜？怎么解決？（1）數(shù)據(jù)分布的不均勻，當(dāng)涉及到多個(gè)map任務(wù)的時(shí)候，勢必有數(shù)據(jù)分配不均的可能，試想如果split-by的id字段是一個(gè)數(shù)字類型，首先sqoop會(huì)執(zhí)行這么一條sql語句，selectmin(id),max(id)fromtable_name也就是先確定字段的范圍，再對這個(gè)范圍根據(jù)map數(shù)量劃分出等寬的區(qū)間（范圍是1-100，如果按照默認(rèn)有4個(gè)map，就會(huì)分成1-25,26-50,51-75,75-100），如果數(shù)據(jù)大量分布到其中一個(gè)區(qū)間時(shí)，就會(huì)出現(xiàn)數(shù)據(jù)傾斜。（2）當(dāng)split-by的字段是字符串時(shí)，可能出現(xiàn)數(shù)據(jù)傾斜。因?yàn)閟qoop的split-by對字符串類型的支持不好，無法進(jìn)行map劃分，可能導(dǎo)致數(shù)據(jù)都集中在一個(gè)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í)對數(shù)據(jù)進(jìn)行隨機(jī)切分，從而減少數(shù)據(jù)傾斜問題。（3）數(shù)據(jù)預(yù)處理可以在導(dǎo)入數(shù)據(jù)前對數(shù)據(jù)進(jìn)行預(yù)處理，比如將數(shù)據(jù)按照某個(gè)字段進(jìn)行分組，然后按照分組后的結(jié)果進(jìn)行導(dǎo)入，從而減少數(shù)據(jù)傾斜問題。4.Pig邏輯計(jì)劃和物理計(jì)劃有什么區(qū)別？當(dāng)PigLatinScript轉(zhuǎn)換為MapReduce作業(yè)時(shí)，Pig會(huì)經(jīng)歷一些步驟。在執(zhí)行基本的解析和語義檢查后，它會(huì)生成一個(gè)邏輯計(jì)劃。邏輯計(jì)劃描述了Pig在執(zhí)行期間必須執(zhí)行的邏輯運(yùn)算符。在此之后，Pig生成了一個(gè)物理計(jì)劃。物理計(jì)劃描述了執(zhí)行腳本所需的物理操作符。5.為什么在Pig編程時(shí)需要MapReduce？Pig使許多Hadoop數(shù)據(jù)分析問題更容易執(zhí)行，其使用的語言是：PigLatin，用PigLatin編寫的程序就像用SQL編寫的查詢，需要一個(gè)執(zhí)行引擎來執(zhí)行查詢。所以，當(dāng)一個(gè)程序用PigLatin編寫時(shí)，Pig編譯器會(huì)將程序轉(zhuǎn)換為MapReduce作業(yè)，也就是需要MapReduce充當(dāng)執(zhí)行引擎。簡述Flume的組成？Agent：一個(gè)jvm進(jìn)程，以event（事件）為基本單元對數(shù)據(jù)進(jìn)行傳輸。Agent主要有3個(gè)部分組成，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)控一個(gè)實(shí)時(shí)追加的文件，不能實(shí)現(xiàn)斷點(diǎn)續(xù)傳，如果Agent掛了會(huì)把所有文件內(nèi)容重新讀一遍；spoolingDirectorySource適合同步新文件，但不適合對實(shí)時(shí)追加日志的文件監(jiān)聽同步，讀取新文件后會(huì)標(biāo)記.completed，但是這個(gè)文件無論是否有變化，都不會(huì)再讀取了；TaildirSource適合用于監(jiān)聽多個(gè)實(shí)時(shí)追加的文件，Taildirsource維護(hù)了一個(gè)Json格式的PositionFile,會(huì)定期往PositionFile更新每個(gè)文件讀取到的最新的位置,因此能夠進(jìn)行斷點(diǎn)續(xù)讀,Agent重啟后可以斷點(diǎn)續(xù)讀；kafkasource實(shí)現(xiàn)數(shù)據(jù)從Kafka到Flume的無縫傳輸。Sink不斷地輪詢Channel中的事件且批量地移除它們，并將這些事件批量寫入到存儲或索引系統(tǒng)、或者被發(fā)送到另一個(gè)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運(yùn)作在不同的速率上。Channel是線程安全的，可以同時(shí)處理幾個(gè)Source的寫入操作和幾個(gè)Sink的讀取操作。Flume自帶兩種Channel：MemoryChannel：內(nèi)存中的隊(duì)列，使用場景主要為不需要關(guān)心內(nèi)存丟失的情況下，因?yàn)槌绦蛩劳龊蜋C(jī)器宕機(jī)或者重啟都會(huì)造成數(shù)據(jù)丟失。FileChannel:將所有事件寫到磁盤，使用場景主要為需要關(guān)心數(shù)據(jù)丟失的情況，因?yàn)槭录粚懭氲酱疟P所以程序關(guān)閉、宕機(jī)并不會(huì)造成數(shù)據(jù)丟失。為什么要使用kafka，為什么要使用消息隊(duì)列？（1）緩沖和削峰：上游數(shù)據(jù)時(shí)有突發(fā)流量，下游可能來不及接收，或者下游沒有足夠多的機(jī)器來保證冗余，Kafka在中間可以起到一個(gè)緩沖的作用，把消息暫存在Kafka中，下游服務(wù)就可以按照自己的節(jié)奏進(jìn)行數(shù)據(jù)的處理。（2）解耦和擴(kuò)展性：項(xiàng)目開始的時(shí)候，并不能確定具體需求。消息隊(duì)列可以作為一個(gè)接口層，解耦重要的業(yè)務(wù)流程。只需要遵守約定，針對數(shù)據(jù)編程即可獲取擴(kuò)展能力。（3）冗余：可以采用一對多的方式，一個(gè)生產(chǎn)者發(fā)布消息，可以被多個(gè)訂閱Topic的服務(wù)消費(fèi)，供多個(gè)毫無關(guān)聯(lián)的業(yè)務(wù)使用。(4)健壯性：消息隊(duì)列可以堆積請求，所以消費(fèi)端業(yè)務(wù)即使短時(shí)間死掉，也不會(huì)影響主要業(yè)務(wù)的正常進(jìn)行。(5)異步通信：消息隊(duì)列提供了異步處理機(jī)制，允許用戶把一個(gè)消息放入隊(duì)列，但并不立即處理它?？梢栽谛枰臅r(shí)候再去處理它們。8.簡述Kafka中的Broker的作用？Broker是消息的代理，Producers往Brokers里面的指定Topic中寫消息，Consumers從Brokers里面拉取指定Topic的消息，然后進(jìn)行業(yè)務(wù)處理，Broker在中間起到一個(gè)代理保存消息的中轉(zhuǎn)站。9.Kafka中的Zookeeper起到什么作用？Zookeeper是一個(gè)分布式的協(xié)調(diào)組件，早期版本的Kafka用ZK做Meta信息存儲，Consumer的消費(fèi)狀態(tài)，Group的管理以及offset的值?？紤]到ZK本身的一些因素以及整個(gè)架構(gòu)較大概率存在單點(diǎn)問題，新版本中逐漸弱化了Zookeeper的作用。新的Consumer使用了Kafka內(nèi)部的GroupCoordination協(xié)議，也減少了對Zookeeper的依賴，但是Broker依然依賴于ZK，Zookeeper在Kafka中還用來選舉Controller和檢測Broker是否存活等等。10.KafkaProducer發(fā)送數(shù)據(jù)時(shí)，ack為0，1，-1有什么含義？設(shè)置-1的時(shí)候，什么情況下，Leader會(huì)認(rèn)為一條消息Commit了？（1）1（默認(rèn)）數(shù)據(jù)發(fā)送到Kafka后，經(jīng)過Leader成功接收消息的確認(rèn)，即為發(fā)送成功。在這種情況下，如果Leader宕機(jī)了，則會(huì)丟失數(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時(shí)，Leader才Commit，這時(shí)候Producer才能認(rèn)為請求中的一條消息Commit了。11.Flink數(shù)據(jù)傾斜如何查看？Flink出現(xiàn)數(shù)據(jù)傾斜如何處理？查看Flink數(shù)據(jù)傾斜：在Flink的WebUI中可以看到數(shù)據(jù)傾斜的情況，就是每個(gè)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ù)也會(huì)出現(xiàn)該情況。這種情況需要讓Flink任務(wù)強(qiáng)制進(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ù)傾斜因?yàn)槭褂昧舜翱冢兂闪擞薪鐢?shù)據(jù)的處理，窗口默認(rèn)觸發(fā)時(shí)才會(huì)輸出一條結(jié)果發(fā)往下游，所以可以使用兩階段聚合的方式,實(shí)現(xiàn)思路：第一階段聚合：Key拼接隨