Hadoop平臺搭建與應用（第2版）（微課版）-課后習題及答案 項目5

Hadoop平臺搭建與應用項目2Hive環(huán)境搭建與基本操作PAGE68PAGE691.如何解決在使用Sqoop進行數(shù)據(jù)導入和導出時，null值處理的一致性問題？Hive中的Null在底層是以“\N”來存儲，而MySQL中的Null在底層就是Null，為了保證數(shù)據(jù)兩端的一致性。在導出數(shù)據(jù)時采用--input-null-string和--input-null-non-string兩個參數(shù)。導入數(shù)據(jù)時采用--null-string和--null-non-string。2.Sqoop導入到Hive時特殊字符導致數(shù)據(jù)變亂方法1:sqoop的sql中對含有特殊字符的字段進行replace操作方法2:使用hive-drop-import-delims，這是sqoop官方提供的一個參數(shù)，導入到hive時，遇到特殊字符就會將改字符丟棄。Sqoop還提供了另一個參數(shù)--hive-delims-replacement，它會將特殊字符替換為我們設(shè)定的字符。3.Sqoop導入到Hive時為什么會出現(xiàn)數(shù)據(jù)傾斜？怎么解決？（1）數(shù)據(jù)分布的不均勻，當涉及到多個map任務(wù)的時候，勢必有數(shù)據(jù)分配不均的可能，試想如果split-by的id字段是一個數(shù)字類型，首先sqoop會執(zhí)行這么一條sql語句，selectmin(id),max(id)fromtable_name也就是先確定字段的范圍，再對這個范圍根據(jù)map數(shù)量劃分出等寬的區(qū)間（范圍是1-100，如果按照默認有4個map，就會分成1-25,26-50,51-75,75-100），如果數(shù)據(jù)大量分布到其中一個區(qū)間時，就會出現(xiàn)數(shù)據(jù)傾斜。（2）當split-by的字段是字符串時，可能出現(xiàn)數(shù)據(jù)傾斜。因為sqoop的split-by對字符串類型的支持不好，無法進行map劃分，可能導致數(shù)據(jù)都集中在一個map上。解決辦法：（1）增加并行度可以通過增加Sqoop導入任務(wù)的并行度來減少數(shù)據(jù)傾斜問題?？梢酝ㄟ^增加map數(shù)或者使用--split-by參數(shù)指定合適的列進行切分數(shù)據(jù)，從而提高導入任務(wù)的并行度。（2）采用隨機切分使用--autoreset-to-one-mapper參數(shù)可以讓Sqoop在導入數(shù)據(jù)時對數(shù)據(jù)進行隨機切分，從而減少數(shù)據(jù)傾斜問題。（3）數(shù)據(jù)預處理可以在導入數(shù)據(jù)前對數(shù)據(jù)進行預處理，比如將數(shù)據(jù)按照某個字段進行分組，然后按照分組后的結(jié)果進行導入，從而減少數(shù)據(jù)傾斜問題。4.Pig邏輯計劃和物理計劃有什么區(qū)別？當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í)行查詢。所以，當一個程序用PigLatin編寫時，Pig編譯器會將程序轉(zhuǎn)換為MapReduce作業(yè)，也就是需要MapReduce充當執(zhí)行引擎。簡述Flume的組成？Agent：一個jvm進程，以event（事件）為基本單元對數(shù)據(jù)進行傳輸。Agent主要有3個部分組成，Source、Channel、Sink。Source是負責接收數(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)聽同步，讀取新文件后會標記.completed，但是這個文件無論是否有變化，都不會再讀取了；TaildirSource適合用于監(jiān)聽多個實時追加的文件，Taildirsource維護了一個Json格式的PositionFile,會定期往PositionFile更新每個文件讀取到的最新的位置,因此能夠進行斷點續(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)存丟失的情況下，因為程序死亡和機器宕機或者重啟都會造成數(shù)據(jù)丟失。FileChannel:將所有事件寫到磁盤，使用場景主要為需要關(guān)心數(shù)據(jù)丟失的情況，因為事件被寫入到磁盤所以程序關(guān)閉、宕機并不會造成數(shù)據(jù)丟失。為什么要使用kafka，為什么要使用消息隊列？（1）緩沖和削峰：上游數(shù)據(jù)時有突發(fā)流量，下游可能來不及接收，或者下游沒有足夠多的機器來保證冗余，Kafka在中間可以起到一個緩沖的作用，把消息暫存在Kafka中，下游服務(wù)就可以按照自己的節(jié)奏進行數(shù)據(jù)的處理。（2）解耦和擴展性：項目開始的時候，并不能確定具體需求。消息隊列可以作為一個接口層，解耦重要的業(yè)務(wù)流程。只需要遵守約定，針對數(shù)據(jù)編程即可獲取擴展能力。（3）冗余：可以采用一對多的方式，一個生產(chǎn)者發(fā)布消息，可以被多個訂閱Topic的服務(wù)消費，供多個毫無關(guān)聯(lián)的業(yè)務(wù)使用。(4)健壯性：消息隊列可以堆積請求，所以消費端業(yè)務(wù)即使短時間死掉，也不會影響主要業(yè)務(wù)的正常進行。(5)異步通信：消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它?？梢栽谛枰臅r候再去處理它們。8.簡述Kafka中的Broker的作用？Broker是消息的代理，Producers往Brokers里面的指定Topic中寫消息，Consumers從Brokers里面拉取指定Topic的消息，然后進行業(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會認為一條消息Commit了？（1）1（默認）數(shù)據(jù)發(fā)送到Kafka后，經(jīng)過Leader成功接收消息的確認，即為發(fā)送成功。在這種情況下，如果Leader宕機了，則會丟失數(shù)據(jù)。(2)0生產(chǎn)者（Producer）將數(shù)據(jù)發(fā)送出去后不再等待任何返回。這種情況下數(shù)據(jù)傳輸效率最高，但是數(shù)據(jù)可靠性確是最低的。（3）-1生產(chǎn)者（Producer）將數(shù)據(jù)發(fā)送出去后，需要等待ISR中的所有Follower都確認接收到數(shù)據(jù)后才算一次發(fā)送完成，可靠性最高。當ISR中所有Replica都向Leader發(fā)送ACK時，Leader才Commit，這時候Producer才能認為請求中的一條消息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ù)強制進行Shuffle。使用Shuffle、Rebalance或Rescale算子即可將數(shù)據(jù)均勻分配，從而解決數(shù)據(jù)傾斜的問題。(2)KeyBy后的聚合操作存在數(shù)據(jù)傾斜在KeyBy上游算子數(shù)據(jù)發(fā)送之前，首先在上游算子的本地對數(shù)據(jù)進行聚合后再發(fā)送到下游，使下游接收到的數(shù)據(jù)量大大減少，從而使得KeyBy之后的聚合操作不再是任務(wù)的瓶頸。但是這要求聚合操作必須是多條數(shù)據(jù)或者一批數(shù)據(jù)才能聚合，單條數(shù)據(jù)沒有辦法通過聚合來減少數(shù)據(jù)量。(3)KeyBy后的窗口聚合操作存在數(shù)據(jù)傾斜因為使用了窗口，變成了有界數(shù)據(jù)的處理，窗口默認觸發(fā)時才會輸出一條結(jié)果發(fā)往下游，所以可以使用兩階段聚合的方式,實現(xiàn)思路：第一階段聚合：Key拼接隨