大數據實習生的面試總結

      不一樣的公司面試內容不一樣，有的注重基礎知識有的注重項目，對實習生，也就是應屆生，更多的是基礎

由於沒有什麼工做經驗，項目不少也不怎麼樣，因此也就問的少。下面是個人一點面試經驗

我面試次數很少，多是運氣比較好，幾家就有了一個很滿意的。一共面過兩次大數據職位

一次java，一次商務智能，數據分析的。

       第一次就是大數據的，數據平臺開發，小公司，沒有筆試，就是拿着簡歷上的項目問。由於是本身

作的，不是公司的項目，因此有不少問題，具體問了什麼就不詳說了，須要注意的是本身項目的一些

架構問題，是否合理，是否本身很清楚，或者說本身能很清楚的描述出來，本身畫出架構圖。問了一些

知識點的問題，好比sparkRDD，spark和hive的區別，spark的魯棒性，推薦系統的冷啓動問題，這麼監控

推薦系統是準確的，怎麼實時的監控，就是系統已經發布上線了，怎麼知道推薦是有效的。此類問題。

解答：SparkRDD五大特性，

RDD是SparkCore的核心，底層操做的就是RDD

RDD也就是彈性分佈式數據集，雖然是數據集可是卻不能存儲數據，只是存放的一段代碼邏輯

五大特性：

一、 RDD是由一系列partition組成

二、 RDD的算子做用在partition上

三、 RDD之間有依賴關係

四、 分區器做用在kv格式的RDD上

五、 partition對外提供最佳的計算位置，利於數據處理的本地化

彈性也就是容錯性，RDD有依賴關係，能夠根據前面的RDD計算出後面的RDD

RDD中的partition個數可多可少

分佈式是RDD中的partition是分佈在多個節點上

 這大概就是關於RDD的介紹

Spark和hive的區別其實就是Spark和MR的區別，我也簡單總結一下，

一、Spark能夠基於內存計算，MR基於磁盤迭代處理數據

二、Spark中有DAG有向無環圖來切分stage的執行前後順序

三、MapReduce只有map和reduce。spark中各類算子

四、Spark是粗粒度資源申請，MapReduce是細粒度資源申請

簡單的總結了一些

對於Spark的魯棒性，也能夠說就是穩定性，找了不少資料，按照個人理解

和RDD的血統，也就是依賴有關，對於推薦系統的冷啓動問題有些博客也詳細介紹過

我就簡單總結一下簡要說明一下

 

冷啓動問題）
冷啓動通常分爲三種
用戶冷啓動，就是如何給新用戶作個性化推薦
物品冷啓動，如何將新的物品推薦給可能會對它感興趣的用戶
系統冷啓動，如何在一個新開發的網站上作個性化推薦系統
方案一：提供非個性化的推薦，給新用戶推薦熱門排行，等用戶數據收集到必定程度以後再切換
爲個性化推薦系統

方案二：利用用戶的註冊信息，
獲取用戶的註冊信息，
根據用戶的註冊信息對用戶分類
給用戶推薦他所屬分類中用戶喜歡的物品
方案三：選擇合適的物品啓動用戶的興趣
就是在用戶登陸的時候對一些物品作一些興趣測試和
反饋。根據這些反饋信息獲得用戶感興趣的物品

方案四：對於新的物品的個性化推薦
兩種協同過濾算法，基於用戶的協同過濾，和基於物品的協同過濾
UserCF的核心思想是給用戶推薦和他興趣類似的其餘用戶喜歡的物品
能夠考慮利用物品的內容信息，將新物品先投放給曾經喜歡過和它內容類似的其餘物品的用戶

ItemCF的核心思想是：給用戶推薦和其過去感興趣的物品類似的物品
基本思路就是將物品轉換成關鍵詞向量，經過計算向量之間的類似度（例如計算餘弦類似度），獲得物品的相關程度。
方案五：對於新的系統，採用專家標註，進行人爲的進行物品特徵標註，而後計算物品之間的類似度，關聯度

至於怎麼監控就不知道了。

以上是第一家大數據面試，不過他們公司並無環境，哈哈

第二家，公司還挺大，環境不錯。一樣沒有筆試。一共面了兩輪，一天，原本是還有最後一輪boss的，不過boss沒時間

兩輪面試的問題我就一塊兒說吧

hashmap原理：這一部分能夠本身找找，什麼哈希表，哈希衝突，數組，鏈表，紅黑樹等等

抽象類和接口的應用場景區別，在設計模式的

kafka怎麼保證數據不丟失，重複消費這麼解決，爲何會發生，發生在什麼地方等等，數據庫優化

1.生產者數據的不丟失

kafka的ack機制：在kafka發送數據的時候，每次發送消息都會有一個確認反饋機制，確保消息正常的可以被收到，其中狀態有0,1，-1。

• 若是是同步模式：ack機制可以保證數據的不丟失，若是ack設置爲0，風險很大，通常不建議設置爲0。即便設置爲1，也會隨着leader宕機丟失數據。

producer.type=sync

request.required.acks=1

• 若是是異步模式：也會考慮ack的狀態，除此以外，異步模式下的有個buffer，經過buffer來進行控制數據的發送，有兩個值來進行控制，時間閾值與消息的數量閾值，若是buffer滿了數據尚未發送出去，有個選項是配置是否當即清空buffer。能夠設置爲-1，永久阻塞，也就數據再也不生產。
• 異步模式下，即便設置爲-1。也可能由於程序員的不科學操做，操做數據丟失，好比kill -9，但這是特別的例外狀況。

 

結論：producer有丟數據的可能，可是能夠經過配置保證消息的不丟失

2.消費者數據的不丟失

經過offset commit 來保證數據的不丟失，kafka本身記錄了每次消費的offset數值，下次繼續消費的時候，會接着上次的offset進行消費。

而offset的信息在kafka0.8版本以前保存在zookeeper中，在0.8版本以後保存到topic中，即便消費者在運行過程當中掛掉了，再次啓動的時候會找到offset的值，找到以前消費消息的位置，接着消費，因爲offset的信息寫入的時候並非每條消息消費完成後都寫入的，因此這種狀況有可能會形成重複消費，可是不會丟失消息。

惟一例外的狀況是，咱們在程序中給本來作不一樣功能的兩個consumer組設置KafkaSpoutConfig.bulider.setGroupid的時候設置成了同樣的groupid，這種狀況會致使這兩個組共享同一份數據，就會產生組A消費partition1，partition2中的消息，組B消費partition3的消息，這樣每一個組消費的消息都會丟失，都是不完整的。  爲了保證每一個組都獨享一份消息數據，groupid必定不要重複才行。

2.kafka集羣中的broker的數據不丟失

每一個broker中的partition咱們通常都會設置有replication（副本）的個數，生產者寫入的時候首先根據分發策略（有partition按partition，有key按key，都沒有輪詢）寫入到leader中，follower（副本）再跟leader同步數據，這樣有了備份，也能夠保證消息數據的不丟失。

這是從別人博客上找到的

數據重複消費出來在那些地方，

底層根本緣由：已經消費了數據，可是offset沒提交。

緣由1：強行kill線程，致使消費後的數據，offset沒有提交。

緣由2：設置offset爲自動提交，關閉kafka時，若是在close以前，調用 consumer.unsubscribe() 則有可能部分offset沒提交，下次重啓會重複消費。會致使部分offset沒提交，下次啓動時會重複消費。

緣由3（重複消費最多見的緣由）：消費後的數據，當offset尚未提交時，partition就斷開鏈接。好比，一般會遇到消費的數據，處理很耗時，致使超過了Kafka的session timeout時間（0.10.x版本默認是30秒），那麼就會re-blance重平衡，此時有必定概率offset沒提交，會致使重平衡後重復消費。

緣由4：當消費者從新分配partition的時候，可能出現從頭開始消費的狀況，致使重發問題。

緣由5：當消費者消費的速度很慢的時候，可能在一個session週期內還未完成，致使心跳機制檢測報告出問題。

kafka怎麼保證副本有三份或者全部副本都保存成功了，或者失敗以後怎麼辦

kafka生成數據，有了一個副本以後，是否是就能夠消費了

一個分區能夠有多個副本，這些副本保存在不一樣的broker上。每一個分區的副本中都會有一個做爲Leader。當一個broker失敗時，Leader在這臺broker上的分區都會變得不可用，kafka會自動移除Leader，再其餘副本中選一個做爲新的Leader。

kafka建立副本的2種模式——同步複製和異步複製

    Kafka動態維護了一個同步狀態的副本的集合（a set of In-Sync Replicas），簡稱ISR，在這個集合中的節點都是和leader保持高度一致的，任何一條消息只有被這個集合中的每一個節點讀取並追加到日誌中，纔會向外部通知說「這個消息已經被提交」。

    只有當消息被全部的副本加入到日誌中時，纔算是「committed」，只有committed的消息纔會發送給consumer，這樣就不用擔憂一旦leader down掉了消息會丟失。

    消息從leader複製到follower, 咱們能夠經過決定Producer是否等待消息被提交的通知(ack)來區分同步複製和異步複製。同步複製流程：

              1.producer聯繫zk識別leader

              2.向leader發送消息

              3.leadr收到消息寫入到本地log

              4.follower從leader pull消息

              5.follower向本地寫入log

              6.follower向leader發送ack消息

              7.leader收到全部follower的ack消息

              8.leader向producer回傳ack

       異步複製流程：

              和同步複製的區別在於，leader寫入本地log以後，

              直接向client回傳ack消息，不須要等待全部follower複製完成。

kafka支持副本模式，那麼其中一個Broker裏的掛掉，一個新的leader就能經過ISR機制推選出來，繼續處理讀寫請求。

4.3 kafka判斷一個broker節點是否存活，依據2個條件：

    1.節點必須能夠維護和ZooKeeper的鏈接，Zookeeper經過心跳機制檢查每一個節點的鏈接

    2. 若是節點是個follower,他必須能及時的同步leader的寫操做，延時不能過久。Leader會追蹤全部「同步中」的節點，一旦一個down掉了，或是卡住了，或是延時過久，leader就會把它移除

hive執行一個SQL，有where，有groupby，order，執行過程，有多少reduce，只要有order by最後都只有一個reduce

數據庫優化是一個都會問的問題

因爲時間緣由下次更新，很快