1. 面試問題:

1.從前到後從你教育背景(學過哪些課)到各個專案你負責的模組,問的很細(本以為他是物理學博士,但是所有的技術都懂)
2.hadoop 的 namenode 宕機,怎麼解決
先分析宕機後的損失，宕機後直接導致client無法訪問，記憶體中的元資料丟失，但是硬碟中的元資料應該還存在，如果只是節點掛了，
重啟即可，如果是機器掛了，重啟機器後看節點是否能重啟，不能重啟就要找到原因修復了。但是最終的解決方案應該是在設計叢集的初期
就考慮到這個問題，做namenode的HA。
3.一個datanode 宕機,怎麼一個流程恢復
Datanode宕機了後，如果是短暫的宕機，可以實現寫好指令碼監控，將它啟動起來。如果是長時間宕機了，那麼datanode上的資料應該已經
被備份到其他機器了，那這臺datanode就是一臺新的datanode了，刪除他的所有資料檔案和狀態檔案，重新啟動。
4.Hbase 的特性,以及你怎麼去設計 rowkey 和 columnFamily ,怎麼去建一個table
因為hbase是列式資料庫，列非表schema的一部分，所以在設計初期只需要考慮rowkey 和 columnFamily即可，rowkey有位置相關性，所以
如果資料是練習查詢的，最好對同類資料加一個字首，而每個columnFamily實際上在底層是一個檔案，那麼檔案越小，查詢越快，所以講經
常一起查詢的列設計到一個列簇，但是列簇不宜過多。
5.Redis,傳統資料庫,hbase,hive 每個之間的區別(問的非常細)
Redis是快取，圍繞著記憶體和快取說
Hbase是列式資料庫，存在hdfs上，圍繞著資料量來說
Hive是資料倉庫，是用來分析資料的，不是增刪改查資料的。
6.公司之後傾向用spark 開發,你會麼(就用java程式碼去寫)
會，spark使用scala開發的，在scala中可以隨意使用jdk的類庫，可以用java開發，但是最好用原生的scala開發，相容性好，scala更靈活。

1. 面試問題:
   1.筆試: java基礎(基本全忘,做的很爛,複習大資料連單例都忘了怎麼寫)
   複習java面試寶典
   2.開始介紹專案,直接用大資料專案介紹,專案經理也懂大資料
   3.Mapreduce 一些流程,經過哪些步驟
   Map—combiner—partition—sort—copy—sort—grouping—reduce
   4.說下對hadoop 的一些理解,包括哪些元件
   詳談hadoop的應用，包括的元件分為三類，分別說明hdfs，yarn，mapreduce
   5.詳細講解下你流式實時計算的專案部署以及收集的結果情況
   講解storm叢集的部署方案，專案的大小，使用的worker數，資料收集在hbase或者hdfs，好處是什麼
   6.你的資料庫是不是很大麼,有沒有分表,分割槽,你是怎麼實現的
   資料庫的分表在設計初期是按照月份進行拆分的，不同的月份查詢不同的表。分割槽沒弄過。
   7.開始問java的一些東西(從各種框架原理到各種複雜SQL)
   8.多執行緒,併發,垃圾回收機制,資料結構(問這些,基本覺得看你是不是高階程式設計師了)
   多執行緒要知道操作方式，執行緒安全的鎖，並且要知道lock鎖
   垃圾回收機制需要詳細瞭解（見雲筆記），主要從記憶體劃分，垃圾回收主要的工作區域，垃圾回收器的種類，各有什麼優缺點，
   用在哪裡合適。
   資料結構基本的要知道，複雜的參考相關的書籍。
2. 面試問題:
   1.BI小組的3個年輕學生一起技術面試(一個是南開博士）
   2.資料量多少,叢集規模多大,型號
   一般中型的電商或者網際網路企業，日誌量每天在200-500M左右，叢集規模在30-50臺左右，機器一般為dell的2000左右的伺服器，型號不定
   大型的網際網路公司據網上資料顯示，日誌量在GP-PB不等，叢集規模在500-4000不等，甚至更多，機器型號不確定。
   3.專案,mapreduce
   介紹整個mapreduce專案流程，資料採集—資料聚合—資料分析—資料展示等
   4.實時流式計算框架,幾個人,多長時間,細節問題,包括講flume ,kafka ,storm 的各個的元件組成,你負責那一塊,如果需要你搭建你可以
   完成麼?
   5.你覺得spark 可以完全替代hadoop 麼?
3. 面試問題:
   1.一些傳統的hadoop 問題,mapreduce 他就問shuffle 階段,你怎麼理解的
   Shuffle意義在於將不同map處理後的資料進行合理分配，讓reduce處理，從而產生了排序、分割槽。
   2.Mapreduce 的 map 數量 和 reduce 數量 怎麼確定 ,怎麼配置
   Map無法配置，reduce隨便配置
   3.唯一難住我的是他說實時計算,storm 如果碰上了複雜邏輯,需要算很長的時間,你怎麼去優化
   拆分複雜的業務到多個bolt中，這樣可以利用bolt的tree將速度提升
   4.Hive 你們用的是外部表還是內部表,有沒有寫過UDF(當然吹自己寫過了),hive 的版本
   外部表，udf，udaf等，hive版本為1.0
   5.Hadoop 的版本
   如果是1.0版本就說1.2，如果是2.0版本，就說2.6或者2.7
   1.2為官方穩定版本，2.7為官方穩定版本。
   Apache Hadoop 2.7.1於美國時間2015年07月06日正式釋出，本版本屬於穩定版本，是自Hadoop 2.6.0以來又一個穩定版，同時也是
   Hadoop 2.7.x版本線的第一個穩定版本，也是 2.7版本線的維護版本，變化不大，主要是修復了一些比較嚴重的Bug
   6.實時流式計算的結果內容有哪些,你們需要統計出來麼(我就說highchart展示)
   簡單介紹日誌監控、風控等結果內容，統計出來顯示在報表或者郵件中。
   7.開始問java相關,包括luecne,solr(倒排索引的原理),框架呀,redis呀
4. 京東商城 - 大資料

（1）Java篇
1、JVM，GC（演算法，新生代，老年代），JVM結構
2、hashcode，hashMap，list，hashSet，equals（結構原理），A extends B（類的載入順序）
1.父類靜態程式碼塊；
2.子類靜態程式碼塊；
3.父類非靜態程式碼塊；
4.父類建構函式；
5.子類非靜態程式碼塊；
6.子類建構函式；
3、多執行緒，主執行緒，次執行緒，喚醒，睡眠
略
4、常見演算法：冒泡演算法，排序演算法，二分查詢，時間複雜度
略
（2）Flume篇
1、資料怎麼採集到Kafka，實現方式
使用官方提供的flumeKafka外掛，外掛的實現方式是自定義了flume的sink，將資料從channle中取出，通過kafka的producer寫入到kafka中，
可以自定義分割槽等。
2、flume管道記憶體，flume宕機了資料丟失怎麼解決
1、Flume的channel分為很多種，可以將資料寫入到檔案
2、防止非首個agent宕機的方法數可以做叢集或者主備
3、flume配置方式，flume叢集（問的很詳細）
Flume的配置圍繞著source、channel、sink敘述，flume的叢集是做在agent上的，而非機器上。
4、flume不採集Nginx日誌，通過Logger4j採集日誌，優缺點是什麼？
優點：Nginx的日誌格式是固定的，但是缺少sessionid，通過logger4j採集的日誌是帶有sessionid的，而session可以通過redis共享，
保證了叢集日誌中的同一session落到不同的tomcat時，sessionId還是一樣的，而且logger4j的方式比較穩定，不會宕機。
缺點：不夠靈活，logger4j的方式和專案結合過於緊密，而flume的方式比較靈活，拔插式比較好，不會影響專案效能。
5、flume和kafka採集日誌區別，採集日誌時中間停了，怎麼記錄之前的日誌。
Flume採集日誌是通過流的方式直接將日誌收集到儲存層，而kafka試講日誌快取在kafka叢集，待後期可以採集到儲存層。
Flume採集中間停了，可以採用檔案的方式記錄之前的日誌，而kafka是採用offset的方式記錄之前的日誌。
（3）Kafka篇
1、容錯機制
分割槽備份，存在主備partition
2、同一topic不同partition分割槽
？？？？
3、kafka資料流向
Producer leader partition follower partition(半數以上) consumer
4、kafka+spark-streaming結合丟資料怎麼解決？
spark streaming從1.2開始提供了資料的零丟失，想享受這個特性，需要滿足如下條件：

1. 資料輸入需要可靠的sources和可靠的receivers

2. 應用metadata必須通過應用driver checkpoint

3. WAL（write ahead log）

1.1. 可靠的sources和receivers

spark streaming可以通過多種方式作為資料sources（包括kafka），輸入資料通過receivers接收，通過replication儲存於spark中（為了faultolerance，預設複製到兩個spark executors），如果資料複製完成，receivers可以知道（例如kafka中更新offsets到zookeeper中）。這樣當receivers在接收資料過程中crash掉，不會有資料丟失，receivers沒有複製的資料，當receiver恢復後重新接收。

1.2. metadata checkpoint

可靠的sources和receivers，可以使資料在receivers失敗後恢復，然而在driver失敗後恢復是比較複雜的，一種方法是通過checkpoint metadata到HDFS或者S3。metadata包括：

· configuration

· code

· 一些排隊等待處理但沒有完成的RDD（僅僅是metadata，而不是data）

這樣當driver失敗時，可以通過metadata checkpoint，重構應用程式並知道執行到那個地方。

1.3. 資料可能丟失的場景

可靠的sources和receivers，以及metadata checkpoint也不可以保證資料的不丟失，例如：

· 兩個executor得到計算資料，並儲存在他們的記憶體中

· receivers知道資料已經輸入

· executors開始計算資料

· driver突然失敗

· driver失敗，那麼executors都會被kill掉

· 因為executor被kill掉，那麼他們記憶體中得資料都會丟失，但是這些資料不再被處理

· executor中的資料不可恢復

1.4. WAL

為了避免上面情景的出現，spark streaming 1.2引入了WAL。所有接收的資料通過receivers寫入HDFS或者S3中checkpoint目錄，這樣當driver失敗後，executor中資料丟失後，可以通過checkpoint恢復。

1.5. At-Least-Once

儘管WAL可以保證資料零丟失，但是不能保證exactly-once，例如下面場景：

· Receivers接收完資料並儲存到HDFS或S3

· 在更新offset前，receivers失敗了

· Spark Streaming以為資料接收成功，但是Kafka以為資料沒有接收成功，因為offset沒有更新到zookeeper

· 隨後receiver恢復了

· 從WAL可以讀取的資料重新消費一次，因為使用的kafka High-Level消費API，從zookeeper中儲存的offsets開始消費

1.6. WAL的缺點

通過上面描述，WAL有兩個缺點：

· 降低了receivers的效能，因為資料還要儲存到HDFS等分散式檔案系統

· 對於一些resources，可能存在重複的資料，比如Kafka，在Kafka中存在一份資料，在Spark Streaming也存在一份（以WAL的形式儲存在hadoop API相容的檔案系統中）

1.7. Kafka direct API

為了WAL的效能損失和exactly-once，spark streaming1.3中使用Kafka direct API。非常巧妙，Spark driver計算下個batch的offsets，指導executor消費對應的topics和partitions。消費Kafka訊息，就像消費檔案系統檔案一樣。

1. 不再需要kafka receivers，executor直接通過Kafka API消費資料

2. WAL不再需要，如果從失敗恢復，可以重新消費

3. exactly-once得到了保證，不會再從WAL中重複讀取資料

1.8. 總結

主要說的是spark streaming通過各種方式來保證資料不丟失，並保證exactly-once，每個版本都是spark streaming越來越穩定，越來越向生產環境使用發展。

5、kafka中儲存目錄data/dir…..topic1和topic2怎麼儲存的，儲存結構，data…..目錄下有多少個分割槽，每個分割槽的儲存格式是什麼樣的？
1、topic是按照“主題名-分割槽”儲存的
2、分割槽個數由配置檔案決定
3、每個分割槽下最重要的兩個檔案是0000000000.log和000000.index，0000000.log以預設1G大小回滾。
（4）Hive篇
1、hive partition分割槽
分割槽表，動態分割槽
2、insert into 和 override write區別？
insert into：將某一張表中的資料寫到另一張表中
override write：覆蓋之前的內容。
3、假如一個分割槽的資料主部錯誤怎麼通過hivesql刪除hdfs
alter table ptable drop partition (daytime=’20140911’,city=’bj’);
元資料，資料檔案都刪除，但目錄daytime= 20140911還在
（5）Storm篇
1、開發流程，容錯機制
開發流程：
1、寫主類（設計spout和bolt的分發機制）
2、寫spout收集資料
3、寫bolt處理資料，根據資料量和業務的複雜程度，設計並行度。
容錯機制：採用ack和fail進行容錯，失敗的資料重新發送。
2、storm和spark-streaming：為什麼用storm不同spark-streaming
3、mr和spark區別，怎麼理解spark-rdd
Mr是檔案方式的分散式計算框架，是將中間結果和最終結果記錄在檔案中，map和reduce的資料分發也是在檔案中。
spark是記憶體迭代式的計算框架，計算的中間結果可以快取記憶體，也可以快取硬碟，但是不是每一步計算都需要快取的。
Spark-rdd是一個數據的分割槽記錄集合………………
4、sqoop命令

sqoop import –connect jdbc:mysql://192.168.56.204:3306/sqoop –username hive –password hive –table jobinfo –target-dir /sqoop/test7 –inline-lob-limit 16777216 –fields-terminated-by ‘\t’ -m 2

sqoop create-hive-table –connect jdbc:mysql://192.168.56.204:3306/sqoop –table jobinfo –username hive –password hive –hive-table sqtest –fields-terminated-by “\t” –lines-terminated-by “\n”;

（6）Redis篇
1、基本操作，儲存格式
略
（7）Mysql篇
1、mysql叢集的分散式事務
京東自主開發分散式MYSQL集群系統
2、mysql效能優化（資料方面）
資料的分表、分庫、分割槽
（6）Hadoop篇
1、hadoop HA 兩個namenode和zk之間的通訊，zk的選舉機制？
HA是通過先後獲取zk的鎖決定誰是主
Zk的選舉機制，涉及到全新機群的選主和資料恢復的選主
2、mr執行機制

3、yarn流程

1) 使用者向YARN 中提交應用程式， 其中包括ApplicationMaster 程式、啟動ApplicationMaster 的命令、使用者程式等。
2) ResourceManager 為該應用程式分配第一個Container， 並與對應的NodeManager 通訊，要求它在這個Container 中啟動應用程式
的ApplicationMaster。
3) ApplicationMaster 首先向ResourceManager 註冊， 這樣使用者可以直接通過ResourceManage 檢視應用程式的執行狀態，然後它將
為各個任務申請資源，並監控它的執行狀態，直到執行結束，即重複步驟4~7。
4) ApplicationMaster 採用輪詢的方式通過RPC 協議向ResourceManager 申請和領取資源。
5) 一旦ApplicationMaster 申請到資源後，便與對應的NodeManager 通訊，要求它啟動任務。
6) NodeManager 為任務設定好執行環境（包括環境變數、JAR 包、二進位制程式等）後，將任務啟動命令寫到一個指令碼中，並通過執行
該指令碼啟動任務。
7) 各個任務通過某個RPC 協議向ApplicationMaster 彙報自己的狀態和進度，以讓ApplicationMaster 隨時掌握各個任務的執行狀態，
從而可以在任務失敗時重新啟動任務。在應用程式執行過程中，使用者可隨時通過RPC 向ApplicationMaster 查詢應用程式的當前執行狀態。
8) 應用程式執行完成後，ApplicationMaster 向ResourceManager 登出並關閉自己。
（7）Hbase
1、涉及到概念，文件
（8）Spark篇
1、spark原理

Spark應用轉換流程

1、 spark應用提交後，經歷了一系列的轉換，最後成為task在每個節點上執行

2、 RDD的Action運算元觸發Job的提交，生成RDD DAG

3、 由DAGScheduler將RDD DAG轉化為Stage DAG，每個Stage中產生相應的Task集合

4、 TaskScheduler將任務分發到Executor執行

5、 每個任務對應相應的一個數據塊，只用使用者定義的函式處理資料塊

Driver執行在Worker上

通過org.apache.spark.deploy.Client類執行作業，作業執行命令如下：

作業執行流程描述：

1、客戶端提交作業給Master

2、Master讓一個Worker啟動Driver，即SchedulerBackend。Worker建立一個DriverRunner執行緒，DriverRunner啟動SchedulerBackend程序。

3、另外Master還會讓其餘Worker啟動Exeuctor，即ExecutorBackend。Worker建立一個ExecutorRunner執行緒，ExecutorRunner會啟動ExecutorBackend程序。

4、ExecutorBackend啟動後會向Driver的SchedulerBackend註冊。SchedulerBackend程序中包含DAGScheduler，它會根據使用者程式，生成執行計劃，並排程執行。對於每個stage的task，都會被存放到TaskScheduler中，ExecutorBackend向SchedulerBackend彙報的時候把TaskScheduler中的task排程到ExecutorBackend執行。

5、所有stage都完成後作業結束。

Driver執行在客戶端

作業執行流程描述：

1、客戶端啟動後直接執行使用者程式，啟動Driver相關的工作：DAGScheduler和BlockManagerMaster等。

2、客戶端的Driver向Master註冊。

3、Master還會讓Worker啟動Exeuctor。Worker建立一個ExecutorRunner執行緒，ExecutorRunner會啟動ExecutorBackend程序。

4、ExecutorBackend啟動後會向Driver的SchedulerBackend註冊。Driver的DAGScheduler解析作業並生成相應的Stage，每個Stage包含的Task通過TaskScheduler分配給Executor執行。

5、所有stage都完成後作業結束。