大資料工程師面試題--7
轉載自:https://blog.csdn.net/u011682879/article/details/55803847
9. 面試問題:
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更靈活。
10. 面試問題:
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鎖
垃圾回收機制需要詳細瞭解(見雲筆記),主要從記憶體劃分,垃圾回收主要的工作區域,垃圾回收器的種類,各有什麼優缺點,
用在哪裡合適。
資料結構基本的要知道,複雜的參考相關的書籍。
11. 面試問題:
1.BI小組的3個年輕學生一起技術面試(一個是南開博士)
2.資料量多少,叢集規模多大,型號
一般中型的電商或者網際網路企業,日誌量每天在200-500M左右,叢集規模在30-50臺左右,機器一般為dell的2000左右的伺服器,型號不定
大型的網際網路公司據網上資料顯示,日誌量在GP-PB不等,叢集規模在500-4000不等,甚至更多,機器型號不確定。
3.專案,mapreduce
介紹整個mapreduce專案流程,資料採集—資料聚合—資料分析—資料展示等
4.實時流式計算框架,幾個人,多長時間,細節問題,包括講flume ,kafka ,storm 的各個的元件組成,你負責那一塊,如果需要你搭建你可以
完成麼?
5.你覺得spark 可以完全替代hadoop 麼?
12. 面試問題:
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呀
13. 京東商城 - 大資料
(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流程
-
- 使用者向YARN 中提交應用程式, 其中包括ApplicationMaster 程式、啟動ApplicationMaster 的命令、使用者程式等。
-
- ResourceManager 為該應用程式分配第一個Container, 並與對應的NodeManager 通訊,要求它在這個Container 中啟動應用程式
的ApplicationMaster。
- ResourceManager 為該應用程式分配第一個Container, 並與對應的NodeManager 通訊,要求它在這個Container 中啟動應用程式
-
- ApplicationMaster 首先向ResourceManager 註冊, 這樣使用者可以直接通過ResourceManage 檢視應用程式的執行狀態,然後它將
為各個任務申請資源,並監控它的執行狀態,直到執行結束,即重複步驟4~7。
- ApplicationMaster 首先向ResourceManager 註冊, 這樣使用者可以直接通過ResourceManage 檢視應用程式的執行狀態,然後它將
-
- ApplicationMaster 採用輪詢的方式通過RPC 協議向ResourceManager 申請和領取資源。
-
- 一旦ApplicationMaster 申請到資源後,便與對應的NodeManager 通訊,要求它啟動任務。
-
- NodeManager 為任務設定好執行環境(包括環境變數、JAR 包、二進位制程式等)後,將任務啟動命令寫到一個指令碼中,並通過執行
該指令碼啟動任務。
- NodeManager 為任務設定好執行環境(包括環境變數、JAR 包、二進位制程式等)後,將任務啟動命令寫到一個指令碼中,並通過執行
-
- 各個任務通過某個RPC 協議向ApplicationMaster 彙報自己的狀態和進度,以讓ApplicationMaster 隨時掌握各個任務的執行狀態,
從而可以在任務失敗時重新啟動任務。在應用程式執行過程中,使用者可隨時通過RPC 向ApplicationMaster 查詢應用程式的當前執行狀態。
- 各個任務通過某個RPC 協議向ApplicationMaster 彙報自己的狀態和進度,以讓ApplicationMaster 隨時掌握各個任務的執行狀態,
-
- 應用程式執行完成後,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都完成後作業結束。