不同的公司面試內容不同，有的注重基礎知識有的注重項目，對實習生，也就是應屆生，更多的是基礎
因為沒有什么工作經驗，項目很多也不怎么樣，所以也就問的少。下面是我的一點面試經驗
我面試次數不多，可能是運氣比較好，幾家就有了一個很滿意的。一共面過兩次大數據職位
一次java，一次商務智能，數據分析的。
第一次就是大數據的，數據平台開發，小公司，沒有筆試，就是拿着簡歷上的項目問。因為是自己
做的，不是公司的項目，所以有很多問題，具體問了什么就不詳說了，需要注意的是自己項目的一些
架構問題，是否合理，是否自己很清楚，或者說自己能很清楚的描述出來，自己畫出架構圖。問了一些
知識點的問題，比如sparkRDD，spark和hive的區別，spark的魯棒性，推薦系統的冷啟動問題，這么監控
推薦系統是准確的，怎么實時的監控，就是系統已經發布上線了，怎么知道推薦是有效的。此類問題。
解答：SparkRDD五大特性，
RDD是SparkCore的核心，底層操作的就是RDD
RDD也就是彈性分布式數據集，雖然是數據集但是卻不能存儲數據，只是存放的一段代碼邏輯
五大特性：
1、 RDD是由一系列partition組成
2、 RDD的算子作用在partition上
3、 RDD之間有依賴關系
4、 分區器作用在kv格式的RDD上
5、 partition對外提供最佳的計算位置，利於數據處理的本地化
彈性也就是容錯性，RDD有依賴關系，可以根據前面的RDD計算出后面的RDD
RDD中的partition個數可多可少
分布式是RDD中的partition是分布在多個節點上
這大概就是關於RDD的介紹
Spark和hive的區別其實就是Spark和MR的區別，我也簡單總結一下，
1、Spark可以基於內存計算，MR基於磁盤迭代處理數據
2、Spark中有DAG有向無環圖來切分stage的執行先后順序
3、MapReduce只有map和reduce。spark中各種算子
4、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
數據庫優化是一個都會問的問題