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

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

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

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

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

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

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

　　① 由客戶端 向 NameNode節(jié)點節(jié)點 發(fā)出請求;

　?、贜ameNode 向Client返回可以可以存數(shù)據(jù)的 DataNode 這里遵循機架感應(yīng)原則;

　?、劭蛻舳?首先 根據(jù)返回的信息 先將 文件分塊(Hadoop2.X版本 每一個block為 128M 而之前的版本為 64M;

　?、苋缓笸ㄟ^那么Node返回的DataNode信息 直接發(fā)送給DataNode 并且是 流式寫入同時會復(fù)制到其他兩臺機器;

　?、載ataNode 向 Client通信 表示已經(jīng)傳完 數(shù)據(jù)塊 同時向NameNode報告 ⑥依照上面(④到⑤)的原理將 所有的數(shù)據(jù)塊都上傳結(jié)束 向 NameNode 報告 表明 已經(jīng)傳完所有的數(shù)據(jù)塊 。

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

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

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

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

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

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