千鋒大數據培訓老師整理的純干貨總結：2018常見大數據面試題，助正在找工作的小伙伴一臂之力!

　　1、RDD中reduceBykey與groupByKey哪個性能好，為什么

　　reduceByKey：reduceByKey會在結果發送至reducer之前會對每個mapper在本地進行merge，有點類似于在MapReduce中的combiner。這樣做的好處在于，在map端進行一次reduce之后，數據量會大幅度減小，從而減小傳輸，保證reduce端能夠更快的進行結果計算。

　　groupByKey：groupByKey會對每一個RDD中的value值進行聚合形成一個序列(Iterator)，此操作發生在reduce端，所以勢必會將所有的數據通過網絡進行傳輸，造成不必要的浪費。同時如果數據量十分大，可能還會造成OutOfMemoryError。

　　通過以上對比可以發現在進行大量數據的reduce操作時候建議使用reduceByKey。不僅可以提高速度，還是可以防止使用groupByKey造成的內存溢出問題。

　　2、講述一下hdfs上傳文件的流程。

　　答：這里描述的 是一個256M的文件上傳過程

　　① 由客戶端 向 NameNode節點節點 發出請求;

　　②NameNode 向Client返回可以可以存數據的 DataNode 這里遵循機架感應原則;

　　③客戶端 首先 根據返回的信息 先將 文件分塊(Hadoop2.X版本 每一個block為 128M 而之前的版本為 64M;

　　④然后通過那么Node返回的DataNode信息 直接發送給DataNode 并且是 流式寫入同時會復制到其他兩臺機器;

　　⑤dataNode 向 Client通信 表示已經傳完 數據塊 同時向NameNode報告 ⑥依照上面(④到⑤)的原理將 所有的數據塊都上傳結束 向 NameNode 報告 表明 已經傳完所有的數據塊 。

　　3、了解zookeeper嗎?介紹一下它，它的選舉機制和集群的搭建。

　　答：那當然是熟悉啦，ZooKeeper 是一個開源的分布式協調服務，是 Google Chubby 的開源實現。分布式應用程序可以基于 ZooKeeper 實現諸如數據發布/訂閱、負載均衡、命名服務、分布式協調/通知、集群管理、Master 選舉、分布式鎖和分布式隊列等功能。我們公司使用的flume集群，Kafka集群等等，都離不開ZooKeeper呀。每個節點上我們都要搭建ZooKeeper服務。首先我們要在每臺pc上配置zookeeper環境變量，在cd到zookeeper下的conf文件夾下在zoo_simjle.cfg文件中添加datadir路徑，再到zookeeper下新建data文件夾，創建myid，在文件里添加上server的ip地址。在啟動zkserver.sh start便ok了。

　　4、spark streming在實時處理時會發生什么故障，如何停止，解決

　　答：和Kafka整合時消息無序：

　　修改Kafka的ack參數，當ack=1時，master確認收到消息就算投遞成功。ack=0時，不需要收到消息便算成功，高效不準確。sck=all，master和server都要受到消息才算成功，準確不高效。

　　StreamingContext.stop會把關聯的SparkContext對象也停止，如果不想把SparkContext對象也停止的話可以把StremingContext.stop的可選參數stopSparkContext設為flase。一個SparkContext對象可以和多個streamingcontext對象關聯。只要對前一個stremingcontext.stop(stopsparkcontext=false),然后再創建新的stremingcontext對象就可以了。