BAT大數據面試題-不看後悔~~

Hadoop部分

• hadoop的map-reduce的實現原理？

首先map task會從本地文件系統讀取數據，轉換成key-value形式的鍵值對集合，使用的是hadoop內置的數據類型，好比longwritable、text等，將鍵值對集合輸入mapper進行業務處理過程，將其轉換成須要的key-value在輸出以後會進行一個partition分區操做，默認使用的是hashpartitioner，能夠經過重寫hashpartitioner的getpartition方法來自定義分區規則，以後會對key進行進行sort排序，grouping分組操做將相同key的value合併分組輸出，在這裏可使用自定義的數據類型，重寫WritableComparator的Comparator方法來自定義排序規則，重寫RawComparator的compara方法來自定義分組規則。

以後進行一個combiner歸約操做，其實就是一個本地段的reduce預處理，以減少後面shuffle和reduce的工做量，reduce task會經過網絡將各個數據收集進行reduce處理，最後將數據保存或者顯示，結束整個job

• hadoop和spark的都是並行計算，那麼他們有什麼相同和區別

二者都是用mr模型來進行並行計算，hadoop的一個做業稱爲job，job裏面分爲map task和reduce task，每一個task都是在本身的進程中運行的，當task結束時，進程也會結束

spark用戶提交的任務成爲application，一個application對應一個sparkcontext，app中存在多個job，每觸發一次action操做就會產生一個job

這些job能夠並行或串行執行，每一個job中有多個stage，stage是shuffle過程當中DAGSchaduler經過RDD之間的依賴關係劃分job而來的，每一個stage裏面有多個task，組成taskset有TaskSchaduler分發到各個executor中執行，executor的生命週期是和app同樣的，即便沒有job運行也是存在的，因此task能夠快速啓動讀取內存進行計算

hadoop的job只有map和reduce操做，表達能力比較欠缺並且在mr過程當中會重複的讀寫hdfs，形成大量的io操做，多個job須要本身管理關係

spark的迭代計算都是在內存中進行的，API中提供了大量的RDD操做如join，groupby等，並且經過DAG圖能夠實現良好的容錯

• 工做中，map-reduce程序運行的時候會有什麼比較常見的問題？如何解決？

好比說做業中大部分都完成了，可是總有幾個reduce一直在運行。這是由於這幾個reduce中的處理的數據要遠遠大於其餘的reduce，多是由於對鍵值對任務劃分的不均勻形成的數據傾斜。

解決的方法能夠在分區的時候從新定義分區規則對於value數據不少的key能夠進行拆分、均勻打散等處理，或者是在map端的combiner中進行數據預處理的操做

• hadoop的TextInputFormat做用是什麼，如何自定義實現

InputFormat會在map操做以前對數據進行兩方面的預處理 
1.是getSplits，返回的是InputSplit數組，對數據進行split分片，每片交給map操做一次 
2.是getRecordReader，返回的是RecordReader對象，對每一個split分片進行轉換爲key-value鍵值對格式傳遞給map

經常使用的InputFormat是TextInputFormat，使用的是LineRecordReader對每一個分片進行鍵值對的轉換，以行偏移量做爲鍵，行內容做爲值

自定義類繼承InputFormat接口，重寫createRecordReader和isSplitable方法 
在createRecordReader中能夠自定義分隔符

• 爲何要用flume導入hdfs，hdfs的構架是怎樣的

flume能夠實時的導入數據到hdfs中，當hdfs上的文件達到一個指定大小的時候會造成一個文件，或者超過指定時間的話也造成一個文件

文件都是存儲在datanode上面的，namenode記錄着datanode的元數據信息，而namenode的元數據信息是存在內存中的，因此當文件切片很小或者不少的時候會卡死

• 簡單說一下hadoop和spark的shuffle過程

hadoop：map端保存分片數據，經過網絡收集到reduce端 
spark：spark的shuffle是在DAGSchedular劃分Stage的時候產生的，TaskSchedule要分發Stage到各個worker的executor

減小shuffle能夠提升性能

Hbase部分

• hbase由哪幾部分組成

• hbase 插入一條數據，內部是如何處理的？

1. 首先，Client經過訪問ZK來請求目標數據的地址。
2. ZK中保存了-ROOT-表的地址，因此ZK經過訪問-ROOT-表來請求數據地址。
3. 一樣，-ROOT-表中保存的是.META.的信息，經過訪問.META.表來獲取具體的RS。
4. .META.表查詢到具體RS信息後返回具體RS地址給Client。
5. Client端獲取到目標地址後，而後直接向該地址發送數據請求。

• hbase某臺機器宕機了，會不會丟失數據，爲何？

HBase的RegionServer宕機超過必定時間後，HMaster會將其所管理的region從新分佈到其餘活動的RegionServer上，因爲數據和日誌都持久在HDFS中，該操做不會致使數據丟失。因此數據的一致性和安全性是有保障的。
可是從新分配的region須要根據日誌（LogFile）恢復原RegionServer中的內存MemoryStore表，這會致使宕機的region在這段時間內沒法對外提供服務。
而一旦重分佈，宕機的節點從新啓動後就至關於一個新的RegionServer加入集羣，爲了平衡，須要再次將某些region分佈到該server。 
所以，Region Server的內存表memstore如何在節點間作到更高的可用，是HBase的一個較大的挑戰。

• rowkey的設計原則

• hbase 過濾器有哪些？你經常使用哪一個？什麼功能？

Hbase的過濾器有：RowFilter、PrefixFilter、KeyOnlyFilter、RandomRowFilter、InclusiveStopFilter、FirstKeyOnlyFilter、ColumnPrefixFilter、ValueFilter、ColumnCountGetFilter、SingleColumnValueFilter、SingleColumnValueExcludeFilter、WhileMatchFilter、FilterList 

比較經常使用的過濾器有：RowFilter 用來對rowkey進行過濾的。
http://blog.csdn.net/xugen12/article/details/44747465

• hbase 中cell的結構

cell中的數據是沒有類型的，所有是字節碼形式存貯。

• hbase 中region 太大問題

Hbase的region會自動split

Hive部分

• Hive中存放是什麼？

表。 存的是和hdfs的映射關係，hive是邏輯上的數據倉庫，實際操做的都是hdfs上的文件，HQL就是用sql語法來寫的mr程序。

• Hive與關係型數據庫的關係？

沒有關係，hive是數據倉庫，不能和數據庫同樣進行實時的CURD操做。 是一次寫入屢次讀取的操做，能夠當作是ETL工具。

Spark 部分

• spark有哪些組件？

（1）master：管理集羣和節點，不參與計算。 
（2）worker：計算節點，進程自己不參與計算，和master彙報。 
（3）Driver：運行程序的main方法，建立spark context對象。 一個驅動程序能夠在spark集羣上啓動一個或多個做業。
（4）spark context：控制整個application的生命週期，包括dagsheduler和task scheduler等組件。 
（5）client：用戶提交程序的入口。

• spark工做機制？

用戶在client端提交做業後，會由Driver運行main方法並建立spark context上下文。 執行add算子，造成dag圖輸入dagscheduler，按照add之間的依賴關係劃分stage輸入task scheduler。 task scheduler會將stage劃分爲task set分發到各個節點的executor中執行。

• spark的優化怎麼作？

經過spark-env文件、程序中sparkconf和set property設置。 
（1）計算量大，造成的lineage過大應該給已經緩存了的rdd添加checkpoint，以減小容錯帶來的開銷。 
（2）小分區合併，太小的分區形成過多的切換任務開銷，使用repartition。

• spark sql比hive快至少10倍，緣由是什麼？

• mr 和 spark 區別，怎麼理解 spark-rdd

Mr 是文件方式的分佈式計算框架，是將中間結果和最終結果記錄在文件中，map 和 reduce的數據分發也是在文件中。
spark 是內存迭代式的計算框架，計算的中間結果能夠緩存內存，也能夠緩存硬盤，可是不是每一步計算都須要緩存的。
Spark-rdd 是一個數據的分區記錄集合，是利用內存來計算的，spark之因此快是由於有內存的模式

• Spark程序的性能和調優方面有什麼須要注意的

首先，對於大部分數據處理應用程序，磁盤I/O都是影響應用程序執行速度的決定性因素。Spark可讓用戶在內存中建立數據，請儘可能利用這一特性。將數據緩存在內存中可讓應用程序提速100倍以上。固然這也意味着最好使用具備大量內存的計算機搭建Spark集羣。

其次，請避免須要進行數據重排（Data shuffling）的操做。跨越網絡進行數據重排是一種開銷很高的操做，在編寫數據處理邏輯時必定要注意這一點。有時候相同的邏輯也能夠經過更高效的操做實現，例如不要使用groupByKey操做，而是可使用reduceByKey操做。

第三，優化數據中的分區數量。若是數據還沒有分區，就沒法充分利用Spark在並行數據處理方面的優點。例如，假設有一個100內核的Spark集羣，但若是數據只有2個分區，此時將沒法充分運用全部計算能力。

第四，經過共置的數據節點和計算節點能夠得到更好的性能。舉例來講，若是數據在HDFS中，請在同一個HDFS集羣中安裝Spark。Spark會在距離數據儘量近的位置處理這些數據。例如，它首先會嘗試在數據所在計算機上執行任務。若是該計算機沒法執行任務，隨後會嘗試使用同一機機櫃的其餘計算機。若是依然不可行，最後纔會選擇使用任意一臺計算機。請儘可能將磁盤和網絡I/O降至最低。

• Spark會取代Hadoop嗎？爲何？

不會。今天的Hadoop表明了多個產品組成的生態系統，Spark也是這個生態系統的成員。就算最核心的Hadoop也包含三個組件：一個集羣管理器，一個分佈式計算框架，以及一個分佈式文件系統。其中集羣管理器是YARN，計算框架是MapReduce，分佈式文件系統是HDFS。Spark是Hadoop MapReduce組件的繼任者。

不少人在使用Spark做業取代原有的MapReduce做業，或在Spark中編寫新的做業。所以能夠說Spark會取代MapReduce，但沒法取代Hadoop。

另外有個重要的事情須要注意，Spark能夠配合Hadoop使用，但也能夠在不具有Hadoop的狀況下使用。例如，可使用Mesos或獨立集羣管理器替代YARN，同理也可使用S3或其餘數據源代替HDFS。所以使用Spark並不是必需要同時使用Hadoop。

• 爲何有人使用Spark代替MapReduce？

相比MapReduce，Spark能夠提供更多優點。

首先，Spark比MapReduce速度快不少。取決於具體應用，可能會比MapReduce快100倍。Spark如此之快的一個緣由在於其先進的做業執行引擎。Spark做業能夠劃分爲任意數量的階段（Stage），而MapReduce做業只能分爲兩個階段。另外Spark可讓應用程序將數據緩存在內存中。緩存機制可極大改進應用程序性能。磁盤I/O會大幅影響數據處理應用程序的執行速度，Spark則能將磁盤I/O降至最低。

其次，Spark很易用。Spark提供了豐富的API和超過80種操做，MapReduce只能提供兩種操做：Map和Reduce。Spark API能夠經過Scala、Python、Java和R四種語言使用。相比在MapReduce中編寫的做業，相同數據處理做業使用Scala/Spark編寫時代碼量能夠減小5-10倍。所以Spark也能大幅提升開發者的生產力。

第三，Spark針對不一樣類型的數據處理任務提供了統一的工具。該產品內置了用於批處理、交互式分析、機器學習、流處理，以及圖表分析的集成庫，用戶再也不須要學習多種工具。也不須要將代碼和數據複製到多個位置。另外從運營的角度來講，一個集羣的管理，無疑要比針對不一樣類型做業建立多個專用集羣管理起來更簡單。

• 如何解決數據傾斜問題？

• Spark Streaming和Storm有何區別？

一個實時毫秒一個準實時亞秒，不過storm的吞吐率比較低。

• mllib支持的算法？

大致分爲四大類，分類、聚類、迴歸、協同過濾。

案例

• 給定a、b兩個文件，各存放50億個url，每一個url各佔64字節，內存限制是4G，讓你找出a、b文件共同的url?

每一個url大小爲64 bytes，那麼能夠估計每一個文件的大小爲50G×64=320G，遠遠大於內存限制的4G，因此不可能將其徹底加載到內存中處理，能夠採用分治的思想來解決。

　　Step1：遍歷文件a，對每一個url求取hash(url)%1000，而後根據所取得的值將url分別存儲到1000個小文件(記爲a0,a1,...,a999，每一個小文件約300M);

　　Step2:遍歷文件b，採起和a相同的方式將url分別存儲到1000個小文件(記爲b0,b1,...,b999);

　　巧妙之處：這樣處理後，全部可能相同的url都被保存在對應的小文件(a0vsb0,a1vsb1,...,a999vsb999)中，不對應的小文件不可能有相同的url。而後咱們只要求出這個1000對小文件中相同的url便可。

　　Step3：求每對小文件ai和bi中相同的url時，能夠把ai的url存儲到hash_set/hash_map中。而後遍歷bi的每一個url，看其是否在剛纔構建的hash_set中，若是是，那麼就是共同的url，存到文件裏面就能夠了。

• 有一個1G大小的一個文件，裏面每一行是一個詞，詞的大小不超過16字節，內存限制大小是1M，要求返回頻數最高的100個詞。

Step1：順序讀文件中，對於每一個詞x，取hash(x)%5000，而後按照該值存到5000個小文件(記爲f0,f1,...,f4999)中，這樣每一個文件大概是200k左右，若是其中的有的文件超過了1M大小，還能夠按照相似的方法繼續往下分，直到分解獲得的小文件的大小都不超過1M;

Step2：對每一個小文件，統計每一個文件中出現的詞以及相應的頻率(能夠採用trie樹/hash_map等)，並取出出現頻率最大的100個詞(能夠用含100個結點的最小堆)，並把100詞及相應的頻率存入文件，這樣又獲得了5000個文件;

Step3：把這5000個文件進行歸併(相似與歸併排序);

• 現有海量日誌數據保存在一個超級大的文件中，該文件沒法直接讀入內存，要求從中提取某天出訪問百度次數最多的那個IP

•  須要更多大數據開發相關學習資料（Hadoop，spark，kafka，MapReduce，scala，，推薦算法，實時交易監控系統，用戶分析行爲，推薦系統）加圈免費獲取：792133408 大數據開發交流圈

問題解法同上，算法思想：分而治之+Hash

1)IP地址最多有2^32=4G種取值狀況，因此不能徹底加載到內存中處理;

2)能夠考慮採用「分而治之」的思想，按照IP地址的Hash(IP)%1024值，把海量IP日誌分別存儲到1024個小文件中。這樣，每一個小文件最多包含4MB個IP地址;

3)對於每個小文件，能夠構建一個IP爲key，出現次數爲value的Hashmap，同時記錄當前出現次數最多的那個IP地址;

4)能夠獲得1024個小文件中的出現次數最多的IP，再依據常規的排序算法獲得整體上出現次數最多的IP;

參考：

• https://github.com/devuser/spark-notes