Hadoop平臺搭建與應用項目2Hive環境搭建與基本操作PAGE68PAGE691.如何解決在使用Sqoop進行數據導入和導出時，null值處理的一致性問題？Hive中的Null在底層是以“\N”來存儲，而MySQL中的Null在底層就是Null，為了保證數據兩端的一致性。在導出數據時采用--input-null-string和--input-null-non-string兩個參數。導入數據時采用--null-string和--null-non-string。2.Sqoop導入到Hive時特殊字符導致數據變亂方法1:sqoop的sql中對含有特殊字符的字段進行replace操作方法2:使用hive-drop-import-delims，這是sqoop官方提供的一個參數，導入到hive時，遇到特殊字符就會將改字符丟棄。Sqoop還提供了另一個參數--hive-delims-replacement，它會將特殊字符替換為我們設定的字符。3.Sqoop導入到Hive時為什么會出現數據傾斜？怎么解決？（1）數據分布的不均勻，當涉及到多個map任務的時候，勢必有數據分配不均的可能，試想如果split-by的id字段是一個數字類型，首先sqoop會執行這么一條sql語句，selectmin(id),max(id)fromtable_name也就是先確定字段的范圍，再對這個范圍根據map數量劃分出等寬的區間（范圍是1-100，如果按照默認有4個map，就會分成1-25,26-50,51-75,75-100），如果數據大量分布到其中一個區間時，就會出現數據傾斜。（2）當split-by的字段是字符串時，可能出現數據傾斜。因為sqoop的split-by對字符串類型的支持不好，無法進行map劃分，可能導致數據都集中在一個map上。解決辦法：（1）增加并行度可以通過增加Sqoop導入任務的并行度來減少數據傾斜問題。可以通過增加map數或者使用--split-by參數指定合適的列進行切分數據，從而提高導入任務的并行度。（2）采用隨機切分使用--autoreset-to-one-mapper參數可以讓Sqoop在導入數據時對數據進行隨機切分，從而減少數據傾斜問題。（3）數據預處理可以在導入數據前對數據進行預處理，比如將數據按照某個字段進行分組，然后按照分組后的結果進行導入，從而減少數據傾斜問題。4.Pig邏輯計劃和物理計劃有什么區別？當PigLatinScript轉換為MapReduce作業時，Pig會經歷一些步驟。在執行基本的解析和語義檢查后，它會生成一個邏輯計劃。邏輯計劃描述了Pig在執行期間必須執行的邏輯運算符。在此之后，Pig生成了一個物理計劃。物理計劃描述了執行腳本所需的物理操作符。5.為什么在Pig編程時需要MapReduce？Pig使許多Hadoop數據分析問題更容易執行，其使用的語言是：PigLatin，用PigLatin編寫的程序就像用SQL編寫的查詢，需要一個執行引擎來執行查詢。所以，當一個程序用PigLatin編寫時，Pig編譯器會將程序轉換為MapReduce作業，也就是需要MapReduce充當執行引擎。簡述Flume的組成？Agent：一個jvm進程，以event（事件）為基本單元對數據進行傳輸。Agent主要有3個部分組成，Source、Channel、Sink。Source是負責接收數據到FlumeAgent的組件。Source組件可以處理各種類型、各種格式的日志數據，包括netcattcpsource:用來監聽端口數據；execsource表示執行linux命令來讀取文件，適合監控一個實時追加的文件，不能實現斷點續傳，如果Agent掛了會把所有文件內容重新讀一遍；spoolingDirectorySource適合同步新文件，但不適合對實時追加日志的文件監聽同步，讀取新文件后會標記.completed，但是這個文件無論是否有變化，都不會再讀取了；TaildirSource適合用于監聽多個實時追加的文件，Taildirsource維護了一個Json格式的PositionFile,會定期往PositionFile更新每個文件讀取到的最新的位置,因此能夠進行斷點續讀,Agent重啟后可以斷點續讀；kafkasource實現數據從Kafka到Flume的無縫傳輸。Sink不斷地輪詢Channel中的事件且批量地移除它們，并將這些事件批量寫入到存儲或索引系統、或者被發送到另一個FlumeAgent。常用的Sink有loggersink：將數據寫入日志；hdfssink：將輸出寫到hdfs上；Avrosink：將數據發送到其他的Flume；FileRollsink：將數據保存到本地磁盤。（3）Channel是位于Source和Sink之間的緩沖區。因此，Channel允許Source和Sink運作在不同的速率上。Channel是線程安全的，可以同時處理幾個Source的寫入操作和幾個Sink的讀取操作。Flume自帶兩種Channel：MemoryChannel：內存中的隊列，使用場景主要為不需要關心內存丟失的情況下，因為程序死亡和機器宕機或者重啟都會造成數據丟失。FileChannel:將所有事件寫到磁盤，使用場景主要為需要關心數據丟失的情況，因為事件被寫入到磁盤所以程序關閉、宕機并不會造成數據丟失。為什么要使用kafka，為什么要使用消息隊列？（1）緩沖和削峰：上游數據時有突發流量，下游可能來不及接收，或者下游沒有足夠多的機器來保證冗余，Kafka在中間可以起到一個緩沖的作用，把消息暫存在Kafka中，下游服務就可以按照自己的節奏進行數據的處理。（2）解耦和擴展性：項目開始的時候，并不能確定具體需求。消息隊列可以作為一個接口層，解耦重要的業務流程。只需要遵守約定，針對數據編程即可獲取擴展能力。（3）冗余：可以采用一對多的方式，一個生產者發布消息，可以被多個訂閱Topic的服務消費，供多個毫無關聯的業務使用。(4)健壯性：消息隊列可以堆積請求，所以消費端業務即使短時間死掉，也不會影響主要業務的正常進行。(5)異步通信：消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。可以在需要的時候再去處理它們。8.簡述Kafka中的Broker的作用？Broker是消息的代理，Producers往Brokers里面的指定Topic中寫消息，Consumers從Brokers里面拉取指定Topic的消息，然后進行業務處理，Broker在中間起到一個代理保存消息的中轉站。9.Kafka中的Zookeeper起到什么作用？Zookeeper是一個分布式的協調組件，早期版本的Kafka用ZK做Meta信息存儲，Consumer的消費狀態，Group的管理以及offset的值。考慮到ZK本身的一些因素以及整個架構較大概率存在單點問題，新版本中逐漸弱化了Zookeeper的作用。新的Consumer使用了Kafka內部的GroupCoordination協議，也減少了對Zookeeper的依賴，但是Broker依然依賴于ZK，Zookeeper在Kafka中還用來選舉Controller和檢測Broker是否存活等等。10.KafkaProducer發送數據時，ack為0，1，-1有什么含義？設置-1的時候，什么情況下，Leader會認為一條消息Commit了？（1）1（默認）數據發送到Kafka后，經過Leader成功接收消息的確認，即為發送成功。在這種情況下，如果Leader宕機了，則會丟失數據。(2)0生產者（Producer）將數據發送出去后不再等待任何返回。這種情況下數據傳輸效率最高，但是數據可靠性確是最低的。（3）-1生產者（Producer）將數據發送出去后，需要等待ISR中的所有Follower都確認接收到數據后才算一次發送完成，可靠性最高。當ISR中所有Replica都向Leader發送ACK時，Leader才Commit，這時候Producer才能認為請求中的一條消息Commit了。11.Flink數據傾斜如何查看？Flink出現數據傾斜如何處理？查看Flink數據傾斜：在Flink的WebUI中可以看到數據傾斜的情況，就是每個SubTask處理的數據量差距很大。解決方案：(1)KeyBy之前發生數據傾斜數據源的數據本身就不均勻,在KeyBy之前就存在數據傾斜（由于某些原因Kafka的Topic中某些Partition的數據量較大，某些Partition的數據量較少。對于不存在KeyBy的Flink任務也會出現該情況。這種情況需要讓Flink任務強制進行Shuffle。使用Shuffle、Rebalance或Rescale算子即可將數據均勻分配，從而解決數據傾斜的問題。(2)KeyBy后的聚合操作存在數據傾斜在KeyBy上游算子數據發送之前，首先在上游算子的本地對數據進行聚合后再發送到下游，使下游接收到的數據量大大減少，從而使得KeyBy之后的聚合操作不再是任務的瓶頸。但是這要求聚合操作必須是多條數據或者一批數據才能聚合，單條數據沒有辦法通過聚合來減少數據量。(3)KeyBy后的窗口聚合操作存在數據傾斜因為使用了窗口，變成了有界數據的處理，窗口默認觸發時才會輸出一條結果發往下游，所以可以使用兩階段聚合的方式,實現思路：第一階段聚合：Key拼接隨