我面試的職位是數據研發工程師。html
前幾天投了螞蟻金服的簡歷,以後打電話通知我次日進行電話面試。因爲只剩一夜的時間了準備不夠充分,回答的不是很好,在此再次重溫一下面試過程。java
剛開始面試官就讓我自我介紹嘛,就是說了說本身的狀況以及作過的項目。(這點包括簡歷上寫的很重要,由於面試官會根據你的回答來進行下一步的提問,沒有作過的千萬不要去說)。node
由於投的是大數據方向的,因此面試官問的全是大數據方向的。面試
1.阿里雲和騰訊雲的區別。(因爲我是有阿里雲和騰訊雲服務器搭建大數據平臺的,因此面試官問了這個)算法
操做系統
阿里雲:CentOS、openSUSE、Ubuntu、Windows Server 2008 R二、Aliyun Linux、Debian(所Aliyun Linux外,全部系統均提供32位和64位版本、Win2008提供中/英文)
騰訊雲:CentOS、SUSE、Ubuntu、Windows Server 2008 R2(全部系統僅支持64位)
特點系統
阿里雲:北京、杭州、青島機房支持「鏡像市場」,可選擇已集成建站系統、開發環境的系統,如集成wordpress、LAMP、LNMP、ASP/.NET、JDK、WEB管理面板等等。
數據盤
阿里雲:購買時最多可添加4塊,每塊最高2000GB,購買後不支持卸載。
騰訊雲:購買時可購一塊,最高500G
獨立磁盤
阿里雲:可添加「獨立的磁盤」,不限數量與容量,「獨立雲磁盤能夠單獨購買,按需付費,獨立存在。獨立雲磁盤能夠在同一可用區內的不一樣ECS實例間自由掛載和卸載。」
騰訊雲:暫無緩存
2.HDFS上傳文件的過程(工做機制)服務器
1)客戶端向namenode發送上傳文件請求,namenode對要上傳目錄和文件進行檢查,判斷是否能夠上傳,並向客戶端返回檢查結果。框架
2)客戶端獲得上傳文件的容許後讀取客戶端配置,若是沒有指定配置則會讀取默認配置(例如副本數和塊大小默認爲3和128M,副本是由客戶端決定的)。向namenode請求上傳一個數據塊。分佈式
3)namenode會根據客戶端的配置來查詢datanode信息,若是使用默認配置,那麼最終結果會返回同一個機架的兩個datanode和另外一個機架的datanode。這稱爲「機架感知」策略。wordpress
4)客戶端在開始傳輸數據塊以前會把數據緩存在本地,當緩存大小超過了一個數據塊的大小,客戶端就會從namenode獲取要上傳的datanode列表。以後會在客戶端和第一個datanode創建鏈接開始流式的傳輸數據,這個datanode會一小部分一小部分(4K)的接收數據而後寫入本地倉庫,同時會把這些數據傳輸到第二個datanode,第二個datanode也一樣一小部分一小部分的接收數據並寫入本地倉庫,同時傳輸給第三個datanode,依次類推。這樣逐級調用和返回以後,待這個數據塊傳輸完成客戶端後告訴namenode數據塊傳輸完成,這時候namenode纔會更新元數據信息記錄操做日誌。
5)第一個數據塊傳輸完成後會使用一樣的方式傳輸下面的數據塊直到整個文件上傳完成。
3.yarn的工做原理
·當用戶向YARN中提交一個應用程序後,YARN將分兩個階段運行該應用程序:
第一個階段是啓動ApplicationMaster;
第二個階段是由ApplicationMaster建立應用程序,爲它申請資源,並監控它的整個運行過程,直到運行完成。
步驟1 用戶向YARN中提交應用程序,其中包括ApplicationMaster程序、啓動ApplicationMaster的命令、用戶程序等。
步驟2 ResourceManager爲該應用程序分配第一個Container,並與對應的Node-Manager通訊,要求它在這個Container中啓動應用程序的ApplicationMaster。
步驟3 ApplicationMaster首先向ResourceManager註冊,這樣用戶能夠直接經過ResourceManager查看應用程序的運行狀態,而後它將爲各個任務申請資源,並監控它的運行狀態,直到運行結束,即重複步驟4~7。
步驟4 ApplicationMaster採用輪詢的方式經過RPC協議向ResourceManager申請和領取資源。
步驟5 一旦ApplicationMaster申請到資源後,便與對應的NodeManager通訊,要求它啓動任務。
步驟6 NodeManager爲任務設置好運行環境(包括環境變量、JAR包、二進制程序等)後,將任務啓動命令寫到一個腳本中,並經過運行該腳本啓動任務。
步驟7 各個任務經過某個RPC協議向ApplicationMaster彙報本身的狀態和進度,以讓ApplicationMaster隨時掌握各個任務的運行狀態,從而能夠在任務失敗時從新啓動任務。
在應用程序運行過程當中,用戶可隨時經過RPC向ApplicationMaster查詢應用程序的當前運行狀態。
步驟8 應用程序運行完成後,ApplicationMaster向ResourceManager註銷並關閉本身。
參考博客:https://blog.csdn.net/zmx729618/article/details/73321316
4.Hadoop的僞分佈式運行模式
僞分佈式只有一個節點
請注意分佈式運行中的這幾個結點的區別:
5.HDFS和Spark的對比
參考博客:https://blog.csdn.net/yanjiangdi/article/details/78260186
6.除了spark你還了解過其餘大數據框架麼,有什麼區別
Hadoop框架
提起大數據,第一個想起的確定是Hadoop,由於Hadoop是目前世界上應用最普遍的大數據工具,他憑藉極高的容錯率和極低的硬件價格,在大數據市場上風生水起。Hadoop仍是第一個在開源社區上引起高度關注的批處理框架,他提出的Map和Reduce的計算模式簡潔而優雅。迄今爲止,Hadoop已經成爲了一個廣闊的生態圈,實現了大量算法和組件。因爲Hadoop的計算任務須要在集羣的多個節點上屢次讀寫,所以在速度上會稍顯劣勢,可是其吞吐量也一樣是其餘框架所不能匹敵的。
Storm框架
與Hadoop的批處理模式不一樣,Storm採用的是流計算框架,由Twitter開源而且託管在GitHub上。與Hadoop相似的是,Storm也提出了兩個計算角色,分別爲Spout和Bolt。
若是說Hadoop是水桶,只能一桶一桶的去井裏扛,那麼Storm就是水龍頭,只要打開就能夠源源不斷的出水。Storm支持的語言也比較多,Java、Ruby、Python等語言都能很好的支持。因爲Storm是流計算框架,所以使用的是內存,延遲上有極大的優點,可是Storm不會持久化數據。
Samza框架
Smaza也是一種流計算框架,但他目前只支持JVM語言,靈活度上略顯不足,而且Samza必須和Kafka共同使用。可是響應的,其也繼承了Kafka的低延時、分區、避免回壓等優點。對於已經有Hadoop+Kafka工做環境的團隊來講,Samza是一個不錯的選擇,而且Samza在多個團隊使用的時候能體現良好的性能。
Spark框架
Spark屬於前兩種框架形式的集合體,是一種混合式的計算框架。它既有自帶的實時流處理工具,也能夠和Hadoop集成,代替其中的MapReduce,甚至Spark還能夠單獨拿出來部署集羣,可是還得藉助HDFS等分佈式存儲系統。Spark的強大之處在於其運算速度,與Storm相似,Spark也是基於內存的,而且在內存滿負載的時候,硬盤也能運算,運算結果表示,Spark的速度大約爲Hadoop的一百倍,而且其成本可能比Hadoop更低。可是Spark目前尚未像Hadoop哪有擁有上萬級別的集羣,所以現階段的Spark和Hadoop搭配起來使用更加合適。
Flink框架
Flink也是一種混合式的計算框架,可是在設計初始,Fink的側重點在於處理流式數據,這與Spark的設計初衷偏偏相反,而在市場需求的驅使下,二者都在朝着更多的兼容性發展。Flink目前不是很成熟,更多狀況下Flink仍是起到一個借鑑的做用。
6.Java的內容泄漏
內存泄露是指無用對象(再也不使用的對象)持續佔有內存或無用對象的內存得不到及時釋放,從而形成的內存空間的浪費稱爲內存泄露。內存泄露有時不嚴重且不易察覺,這樣開發者就不知道存在內存泄露,但有時也會很嚴重,會提示你Out of memory。
參考博客:https://www.cnblogs.com/panxuejun/p/5883044.html