客戶端跟namenode通訊請求上傳文件，namenode檢查目標文件是否已存在，父目錄是否存在
namenode返回是否能夠上傳
client請求第一個 block該傳輸到哪些datanode服務器上
namenode返回3個datanode服務器ABC
client請求3臺dn中的一臺A上傳數據（本質上是一個RPC調用，創建pipeline），A收到請求會繼續調用B，而後B調用C，將真個pipeline創建完成，逐級返回客戶端
client開始往A上傳第一個block（先從磁盤讀取數據放到一個本地內存緩存），以packet爲單位，A收到一個packet就會傳給B，B傳給C；A每傳一個packet會放入一個應答隊列等待應答
當一個block傳輸完成以後，client再次請求namenode上傳第二個block的服務器。

2.hdfs讀流程

client跟namenode通訊查詢元數據，找到文件塊所在的datanode服務器
挑選一臺datanode（就近原則，而後隨機）服務器，請求創建socket流
datanode開始發送數據（從磁盤裏面讀取數據放入流，以packet爲單位來作校驗）
客戶端以packet爲單位接收，如今本地緩存，而後寫入目標文件

3.hdfs的體系結構

hdfs有namenode、secondraynamenode、datanode組成。爲n+1模式

NameNode負責管理和記錄整個文件系統的元數據
DataNode 負責管理用戶的文件數據塊，文件會按照固定的大小（blocksize）切成若干塊後分布式存儲在若干臺datanode上，每個文件塊能夠有多個副本，並存放在不一樣的datanode上，Datanode會按期向Namenode彙報自身所保存的文件block信息，而namenode則會負責保持文件的副本數量
HDFS的內部工做機制對客戶端保持透明，客戶端請求訪問HDFS都是經過向namenode申請來進行
secondraynamenode負責合併日誌

4.一個datanode 宕機,怎麼一個流程恢復

Datanode宕機了後，若是是短暫的宕機，能夠實現寫好腳本監控，將它啓動起來。若是是長時間宕機了，那麼datanode上的數據應該已經被備份到其餘機器了，那這臺datanode就是一臺新的datanode了，刪除他的全部數據文件和狀態文件，從新啓動。

5.hadoop 的 namenode 宕機,怎麼解決

先分析宕機後的損失，宕機後直接致使client沒法訪問，內存中的元數據丟失，可是硬盤中的元數據應該還存在，若是隻是節點掛了，重啓便可，若是是機器掛了，重啓機器後看節點是否能重啓，不能重啓就要找到緣由修復了。可是最終的解決方案應該是在設計集羣的初期就考慮到這個問題，作namenode的HA。

6.namenode對元數據的管理

namenode對數據的管理採用了三種存儲形式：

內存元數據(NameSystem)
磁盤元數據鏡像文件(fsimage鏡像)
數據操做日誌文件（可經過日誌運算出元數據）(edit日誌文件)

7.元數據的checkpoint

每隔一段時間，會由secondary namenode將namenode上積累的全部edits和一個最新的fsimage下載到本地，並加載到內存進行merge（這個過程稱爲checkpoint）

namenode和secondary namenode的工做目錄存儲結構徹底相同，因此，當namenode故障退出須要從新恢復時，能夠從secondary namenode的工做目錄中將fsimage拷貝到namenode的工做目錄，以恢復namenode的元數據

8.yarn資源調度流程

用戶向YARN 中提交應用程序，其中包括ApplicationMaster 程序、啓動ApplicationMaster 的命令、用戶程序等。
ResourceManager 爲該應用程序分配第一個Container，並與對應的NodeManager 通訊，要求它在這個Container 中啓動應用程序的ApplicationMaster。
ApplicationMaster 首先向ResourceManager 註冊，這樣用戶能夠直接經過ResourceManage 查看應用程序的運行狀態，而後它將爲各個任務申請資源，並監控它的運行狀態，直到運行結束，即重複步驟4~7。
ApplicationMaster 採用輪詢的方式經過RPC 協議向ResourceManager 申請和領取資源。
一旦ApplicationMaster 申請到資源後，便與對應的NodeManager 通訊，要求它啓動任務。
NodeManager 爲任務設置好運行環境（包括環境變量、JAR 包、二進制程序等）後，將任務啓動命令寫到一個腳本中，並經過運行該腳本啓動任務。
各個任務經過某個RPC 協議向ApplicationMaster 彙報本身的狀態和進度，以讓ApplicationMaster 隨時掌握各個任務的運行狀態，從而能夠在任務失敗時從新啓動任務。在應用程序運行過程當中，用戶可隨時經過RPC 向ApplicationMaster 查詢應用程序的當前運行狀態。
應用程序運行完成後，ApplicationMaster 向ResourceManager 註銷並關閉本身。

9.hadoop中combiner和partition的做用

combiner是發生在map的最後一個階段，父類就是Reducer，意義就是對每個maptask的輸出進行局部彙總，以減少網絡傳輸量，緩解網絡傳輸瓶頸，提升reducer的執行效率。
partition的主要做用將map階段產生的全部kv對分配給不一樣的reducer task處理，能夠將reduce階段的處理負載進行分攤

10.用mapreduce怎麼處理數據傾斜問題？

數據傾斜：map /reduce程序執行時，reduce節點大部分執行完畢，可是有一個或者幾個reduce節點運行很慢，致使整個程序的處理時間很長，這是由於某一個key的條數比其餘key多不少（有時是百倍或者千倍之多），這條key所在的reduce節點所處理的數據量比其餘節點就大不少，從而致使某幾個節點遲遲運行不完，此稱之爲數據傾斜。

（1）局部聚合加全局聚合。

第一次在 map 階段對那些致使了數據傾斜的 key 加上 1 到 n 的隨機前綴，這樣原本相

同的 key 也會被分到多個 Reducer 中進行局部聚合，數量就會大大下降。

第二次 mapreduce，去掉 key 的隨機前綴，進行全局聚合。

思想：二次 mr，第一次將 key 隨機散列到不一樣 reducer 進行處理達到負載均衡目的。第

二次再根據去掉 key 的隨機前綴，按原 key 進行 reduce 處理。

這個方法進行兩次 mapreduce，性能稍差。

（2）增長 Reducer，提高並行度

JobConf.setNumReduceTasks(int)

（3）實現自定義分區

根據數據分佈狀況，自定義散列函數，將 key 均勻分配到不一樣 Reducer

11.shuffle 階段,你怎麼理解的

shuffle: 洗牌、發牌——（核心機制：緩存，數據分區，排序，Merge進行局部value的合併）；

具體來講：就是將maptask輸出的處理結果數據，分發給reducetask，並在分發的過程當中，對數據按key進行了分區和排序；

1）Map 方法以後 Reduce 方法以前這段處理過程叫 Shuffle

2）Map 方法以後，數據首先進入到分區方法，把數據標記好分區，而後把數據發送到環形緩衝區；環形緩衝區默認大小 100m，環形緩衝區達到 80%時，進行溢寫；溢寫前對數據進行排序，排序按照對 key 的索引進行字典順序排序，排序的手段快排；溢寫產生大量溢寫文件，須要對溢寫文件進行歸併排序；對溢寫的文件也能夠進行 Combiner 操做，前提是彙總操做，求平均值不行。最後將文件按照分區存儲到磁盤，等待 Reduce 端拉取。

3）每一個 Reduce 拉取 Map 端對應分區的數據。拉取數據後先存儲到內存中，內存不夠了，再存儲到磁盤。拉取完全部數據後，採用歸併排序將內存和磁盤中的數據都進行排序。

在進入 Reduce 方法前，能夠對數據進行分組操做。

12.Mapreduce 的 map 數量和 reduce 數量怎麼肯定 ,怎麼配置

map的數量由輸入切片的數量決定，128M切分一個切片，只要是文件也分爲一個切片，有多少個切片就有多少個map Task。

reduce數量本身配置。

13.MapReduce優化經驗

設置合理的map和reduce的個數。合理設置blocksize
避免出現數據傾斜
combine函數
對數據進行壓縮
小文件處理優化：事先合併成大文件，combineTextInputformat，在hdfs上用mapreduce將小文件合併成SequenceFile大文件（key:文件名，value：文件內容）
參數優化

14.分別舉例什麼狀況要使用 combiner，什麼狀況不使用？

求平均數的時候就不須要用combiner，由於不會減小reduce執行數量。在其餘的時候，能夠依據狀況，使用combiner，來減小map的輸出數量，減小拷貝到reduce的文件，從而減輕reduce的壓力，節省網絡開銷，提高執行效率

15.MR運行流程解析

一個mr程序啓動的時候，最早啓動的是MRAppMaster，MRAppMaster啓動後根據本次job的描述信息，計算出須要的maptask實例數量，而後向集羣申請機器啓動相應數量的maptask進程
maptask進程啓動以後，根據給定的數據切片範圍進行數據處理，主體流程爲：
1. 利用客戶指定的inputformat來獲取RecordReader讀取數據，造成輸入KV對
2. 將輸入KV對傳遞給客戶定義的map()方法，作邏輯運算，並將map()方法輸出的KV對收集到緩存
3. 將緩存中的KV對按照K分區排序後不斷溢寫到磁盤文件
MRAppMaster監控到全部maptask進程任務完成以後，會根據客戶指定的參數啓動相應數量的reducetask進程，並告知reducetask進程要處理的數據範圍（數據分區）
Reducetask進程啓動以後，根據MRAppMaster告知的待處理數據所在位置，從若干臺maptask運行所在機器上獲取到若干個maptask輸出結果文件，並在本地進行從新歸併排序，而後按照相同key的KV爲一個組，調用客戶定義的reduce()方法進行邏輯運算，並收集運算輸出的結果KV，而後調用客戶指定的outputformat將結果數據輸出到外部存儲

16.簡單描述一下HDFS的系統架構，怎麼保證數據安全?

HDFS數據安全性如何保證？

存儲在HDFS系統上的文件，會分割成128M大小的block存儲在不一樣的節點上，block的副本數默認3份，也可配置成更多份；
第一個副本通常放置在與client（客戶端）所在的同一節點上（若客戶端無datanode，則隨機放），第二個副本放置到與第一個副本同一機架的不一樣節點，第三個副本放到不一樣機架的datanode節點，當取用時遵循就近原則；
datanode已block爲單位，每3s報告心跳狀態，作10min內不報告心跳狀態則namenode認爲block已死掉，namonode會把其上面的數據備份到其餘一個datanode節點上，保證數據的副本數量；
datanode會默認每小時把本身節點上的全部塊狀態信息報告給namenode；
採用safemode模式：datanode會週期性的報告block信息。Namenode會計算block的損壞率，當閥值<0.999f時系統會進入安全模式，HDFS只讀不寫。 HDFS元數據採用secondaryname備份或者HA備份

17.在經過客戶端向hdfs中寫數據的時候，若是某一臺機器宕機了，會怎麼處理

在寫入的時候不會從新從新分配datanode。若是寫入時，一個datanode掛掉，會將已經寫入的數據放置到queue的頂部，並將掛掉的datanode移出pipline，將數據寫入到剩餘的datanode，在寫入結束後， namenode會收集datanode的信息，發現此文件的replication沒有達到配置的要求（default=3）,而後尋找一個datanode保存副本。

18.Hadoop優化有哪些方面

0）HDFS 小文件影響

（1）影響 NameNode 的壽命，由於文件元數據存儲在 NameNode 的內存中

（2）影響計算引擎的任務數量，好比每一個小的文件都會生成一個 Map 任務

1）數據輸入小文件處理：

（1）合併小文件：對小文件進行歸檔（Har）、自定義 Inputformat 將小文件存儲成SequenceFile 文件。

（2）採用 ConbinFileInputFormat 來做爲輸入，解決輸入端大量小文件場景。

（3）對於大量小文件 Job，能夠開啓 JVM 重用。

2）Map 階段

（1）增大環形緩衝區大小。由 100m 擴大到 200m

（2）增大環形緩衝區溢寫的比例。由 80%擴大到 90%

（3）減小對溢寫文件的 merge 次數。（10 個文件，一次 20 個 merge）

（4）不影響實際業務的前提下，採用 Combiner 提早合併，減小 I/O。

3）Reduce 階段

（1）合理設置 Map 和 Reduce 數：兩個都不能設置太少，也不能設置太多。太少，會致使 Task 等待，延長處理時間；太多，會致使 Map、Reduce 任務間競爭資源，形成處理超時等錯誤。

（2）設置 Map、Reduce 共存：調整 slowstart.completedmaps 參數，使 Map 運行到必定程度後，Reduce 也開始運行，減小 Reduce 的等待時間。

（3）規避使用 Reduce，由於 Reduce 在用於鏈接數據集的時候將會產生大量的網絡消耗。

（4）增長每一個 Reduce 去 Map 中拿數據的並行數

（5）集羣性能能夠的前提下，增大 Reduce 端存儲數據內存的大小。

4）IO 傳輸

（1）採用數據壓縮的方式，減小網絡 IO 的的時間。安裝 Snappy 和 LZOP 壓縮編碼器。

（2）使用 SequenceFile 二進制文件

5）總體

（1）MapTask 默認內存大小爲 1G，能夠增長 MapTask 內存大小爲 4-5g

（2）ReduceTask 默認內存大小爲 1G，能夠增長 ReduceTask 內存大小爲 4-5g

（3）能夠增長 MapTask 的 cpu 核數，增長 ReduceTask 的 CPU 核數

（4）增長每一個 Container 的 CPU 核數和內存大小

（5）調整每一個 Map Task 和 Reduce Task 最大重試次數

19.大量數據求topN(寫出mapreduce的實現思路）

20.列出正常工做的hadoop集羣中hadoop都分別啓動哪些進程以及他們的做用

1.NameNode它是hadoop中的主服務器，管理文件系統名稱空間和對集羣中存儲的文件的訪問，保存有metadate。

2.SecondaryNameNode它不是namenode的冗餘守護進程，而是提供週期檢查點和清理任務。幫助NN合併editslog，減小NN啓動時間。

3.DataNode它負責管理鏈接到節點的存儲（一個集羣中能夠有多個節點）。每一個存儲數據的節點運行一個datanode守護進程。

4.ResourceManager（JobTracker）JobTracker負責調度DataNode上的工做。每一個DataNode有一個TaskTracker，它們執行實際工做。

5.NodeManager（TaskTracker）執行任務

6.DFSZKFailoverController高可用時它負責監控NN的狀態，並及時的把狀態信息寫入ZK。它經過一個獨立線程週期性的調用NN上的一個特定接口來獲取NN的健康狀態。FC也有選擇誰做爲Active NN的權利，由於最多隻有兩個節點，目前選擇策略還比較簡單（先到先得，輪換）。

7.JournalNode 高可用狀況下存放namenode的editlog文件.

21.Hadoop總job和Tasks之間的區別是什麼？

Job是咱們對一個完整的mapreduce程序的抽象封裝

Task是job運行時，每個處理階段的具體實例，如map task，reduce task，maptask和reduce task都會有多個併發運行的實例

22.Hadoop高可用

23.簡要描述安裝配置一個hadoop集羣的步驟

使用root帳戶登陸。
修改IP。
修改Host主機名。
配置SSH免密碼登陸。
關閉防火牆。
安裝JDK。
上傳解壓Hadoop安裝包。
配置Hadoop的核心配置文件hadoop-evn.sh，core-site.xml，mapred-site.xml，hdfs-site.xml，yarn-site.xml
配置hadoop環境變量
格式化hdfs # bin/hadoop namenode -format
啓動節點start-all.sh

24.fsimage和edit的區別

fsimage：filesystem image 的簡寫，文件鏡像。

客戶端修改文件時候，先更新內存中的metadata信息,只有當對文件操做成功的時候，纔會寫到editlog。

fsimage是文件meta信息的持久化的檢查點。secondary namenode會按期的將fsimage和editlog合併dump成新的fsimage

二.Hive

1.hive優化

hive最終都會轉化爲mapreduce的job來運行，要想hive調優，實際上就是mapreduce調優，能夠有下面幾個方面的調優。解決收據傾斜問題，減小job數量，設置合理的map和reduce個數，對小文件進行合併，優化時把我總體，單個task最優不如總體最優。按照必定規則分區。

reducer 會緩存 join 序列中除了最後一個表的全部表的記錄，再經過最後一個表將結果序列化到文件系統。這一實現有助於在 reduce 端減小內存的使用量。實踐中，應該把最大的那個表寫在最後（不然會由於緩存浪費大量內存
當對3個或者更多個表進行join鏈接時，若是每一個on子句都使用相同的鏈接鍵的話，那麼只會產生一個MapReduce job。
儘可能儘早的過濾數據，減小每一個階段的數據量,對於分區表要加分區，同時只選擇須要使用到的字段。

4. order by & sort by

order by : 對查詢結果進行全局排序，消耗時間長。須要 set hive.mapred.mode=nostrict

sort by : 局部排序，並不是全局有序，提升效率。

5.避免數據傾斜

6.減小job數，對jobs數比較多的做業運行效率相對比較低，好比即便有幾百行的表，若是屢次關聯屢次彙總，產生十幾個jobs，沒半小時是跑不完的。map reduce做業初始化的時間是比較長的。

7.對小文件進行合併，是行至有效的提升調度效率的方法，假如咱們的做業設置合理的文件數，對雲梯的總體調度效率也會產生積極的影響。

2.udf udaf udtf區別

UDF操做做用於單個數據行，而且產生一個數據行做爲輸出。大多數函數都屬於這一類（好比數學函數和字符串函數）。

UDAF 接受多個輸入數據行，併產生一個輸出數據行。像COUNT和MAX這樣的函數就是彙集函數。

UDTF 操做做用於單個數據行，而且產生多個數據行-------一個表做爲輸出。lateral view explore()

簡單來講：

UDF:返回對應值，一對一

UDAF：返回聚類值，多對一

UDTF：返回拆分值，一對多

3.hive有哪些保存元數據的方式，個有什麼特色。

內存數據庫derby，安裝小，可是數據存在內存，不穩定
mysql數據庫，數據存儲模式能夠本身設置，持久化好，查看方便。

4.hive內部表和外部表的區別

內部表：加載數據到hive所在的hdfs目錄，刪除時，元數據和數據文件都刪除

外部表：不加載數據到hive所在的hdfs目錄，刪除時，只刪除表結構。

這樣外部表相對來講更加安全些，數據組織也更加靈活，方便共享源數據。

5.生產環境中爲何建議使用外部表？

由於外部表不會加載數據到hive，減小數據傳輸、數據還能共享。
hive不會修改數據，因此無需擔憂數據的損壞
刪除表時，只刪除表結構、不刪除數據。

6.insert into 和 override write區別？

insert into：將數據寫到表中

override write：覆蓋以前的內容。

7.hive的判斷函數有哪些

hive 的條件判斷（if、coalesce、case）

8.簡單描述一下HIVE的功能？用hive建立表有幾種方式？hive表有幾種？

hive主要是作離線分析的

hive建表有三種方式

直接建表法
查詢建表法(經過AS 查詢語句完成建表：將子查詢的結果存在新表裏，有數據，通常用於中間表)
like建表法(會建立結構徹底相同的表，可是沒有數據)

hive表有2種：內部表和外部表

9.線上業務天天產生的業務日誌（壓縮後>=3G），天天須要加載到hive的log表中，將天天產生的業務日誌在壓縮以後load到hive的log表時，最好使用的壓縮算法是哪一個,並說明其緣由

10.若在hive中創建分區仍不能優化查詢效率，建表時如何優化

11.簡述拉鍊表，流水錶以及快照表的含義和特色

拉鍊表：

（1）記錄一個事物從開始，一直到當前狀態的全部變化的信息；
（2）拉鍊表每次上報的都是歷史記錄的最終狀態，是記錄在當前時刻的歷史總量；
（3）當前記錄存的是當前時間以前的全部歷史記錄的最後變化量（總量）；
（4）封鏈時間能夠是2999，3000，9999等等比較大的年份；拉鍊表到期數據要報0；

流水錶：對於表的每個修改都會記錄，能夠用於反映實際記錄的變動
　區別於拉鍊表：　
拉鍊表一般是對帳戶信息的歷史變更進行處理保留的結果，流水錶是天天的交易造成的歷史；
流水錶用於統計業務相關狀況，拉鍊表用於統計帳戶及客戶的狀況

快照表：
按天分區，每一天的數據都是截止到那一天mysql的全量數據

12.如何解決hive數據傾斜的問題

1）group by

注：group by 優於 distinct group

情形：group by 維度太小，某值的數量過多

後果：處理某值的 reduce 很是耗時

解決方式：採用 sum() group by 的方式來替換 count(distinct)完成計算。

2）count(distinct)

count(distinct xx)

情形：某特殊值過多

後果：處理此特殊值的 reduce 耗時；只有一個 reduce 任務

解決方式：count distinct 時，將值爲空的狀況單獨處理，好比能夠直接過濾空值的行，

在最後結果中加 1。若是還有其餘計算，須要進行 group by，能夠先將值爲空的記錄單獨處

理，再和其餘計算結果進行 union。

3）mapjoin

4）不一樣數據類型關聯產生數據傾斜

情形：好比用戶表中 user_id 字段爲 int，log 表中 user_id 字段既有 string 類型也有 int 類型。當按照 user_id 進行兩個表的 Join 操做時。

後果：處理此特殊值的 reduce 耗時；只有一個 reduce 任務

默認的 Hash 操做會按 int 型的 id 來進行分配，這樣會致使全部 string 類型 id 的記錄都分配

到一個 Reducer 中。

解決方式：把數字類型轉換成字符串類型

select * from users a

left outer join logs b

on a.usr_id = cast(b.user_id as string)

5）開啓數據傾斜時負載均衡

set hive.groupby.skewindata=true;

思想：就是先隨機分發並處理，再按照 key group by 來分發處理。

操做：當選項設定爲 true，生成的查詢計劃會有兩個 MRJob。

第一個 MRJob 中，Map 的輸出結果集合會隨機分佈到 Reduce 中，每一個 Reduce 作部分

聚合操做，並輸出結果，這樣處理的結果是相同的 GroupBy Key 有可能被分發到不一樣的

Reduce 中，從而達到負載均衡的目的；

第二個 MRJob 再根據預處理的數據結果按照 GroupBy Key 分佈到 Reduce 中（這個過

程能夠保證相同的原始 GroupBy Key 被分佈到同一個 Reduce 中），最後完成最終的聚合操

做。

點評：它使計算變成了兩個 mapreduce，先在第一個中在 shuffle 過程 partition 時隨機

給 key 打標記，使每一個 key 隨機均勻分佈到各個 reduce 上計算，可是這樣只能完成部分

計算，由於相同 key 沒有分配到相同 reduce 上。

因此須要第二次的 mapreduce,此次就回歸正常 shuffle,可是數據分佈不均勻的問題在第

一次 mapreduce 已經有了很大的改善，所以基本解決數據傾斜。由於大量計算已經在第一次

mr 中隨機分佈到各個節點完成。

6）控制空值分佈

將爲空的 key 轉變爲字符串加隨機數或純隨機數，將因空值而形成傾斜的數據分不到多

個 Reducer。

注：對於異常值若是不須要的話，最好是提早在 where 條件裏過濾掉，這樣可使計算

量大大減小

13.hive性能優化經常使用的方法

1）MapJoin

若是不指定 MapJoin 或者不符合 MapJoin 的條件，那麼 Hive 解析器會將 Join 操做轉換

成 Common Join，即：在 Reduce 階段完成 join。容易發生數據傾斜。能夠用 MapJoin 把小

表所有加載到內存在 map 端進行 join，避免 reducer 處理。

2）行列過濾

列處理：在 SELECT 中，只拿須要的列，若是有，儘可能使用分區過濾，少用 SELECT *。

行處理：在分區剪裁中，當使用外關聯時，若是將副表的過濾條件寫在 Where 後面，那

麼就會先全表關聯，以後再過濾。

3）列式存儲

4）採用分區技術

5）合理設置 Map 數

（1）一般狀況下，做業會經過 input 的目錄產生一個或者多個 map 任務。

主要的決定因素有：input 的文件總個數，input 的文件大小，集羣設置的文件塊大小。

（2）是否是 map 數越多越好？

答案是否認的。若是一個任務有不少小文件（遠遠小於塊大小 128m），則每一個小文件

也會被當作一個塊，用一個 map 任務來完成，而一個 map 任務啓動和初始化的時間遠遠大

於邏輯處理的時間，就會形成很大的資源浪費。並且，同時可執行的 map 數是受限的。

（3）是否是保證每一個 map 處理接近 128m 的文件塊，就高枕無憂了？

答案也是不必定。好比有一個 127m 的文件，正常會用一個 map 去完成，但這個文件只

有一個或者兩個小字段，卻有幾千萬的記錄，若是 map 處理的邏輯比較複雜，用一個 map

任務去作，確定也比較耗時。

針對上面的問題 2 和 3，咱們須要採起兩種方式來解決：即減小 map 數和增長 map 數；

6）小文件進行合併

在 Map 執行前合併小文件，減小 Map 數：CombineHiveInputFormat 具備對小文件進行

合併的功能（系統默認的格式）。HiveInputFormat 沒有對小文件合併功能。

7）合理設置 Reduce 數

Reduce 個數並非越多越好

（1）過多的啓動和初始化 Reduce 也會消耗時間和資源；

（2）另外，有多少個 Reduce，就會有多少個輸出文件，若是生成了不少個小文件，那

麼若是這些小文件做爲下一個任務的輸入，則也會出現小文件過多的問題；

在設置 Reduce 個數的時候也須要考慮這兩個原則：處理大數據量利用合適的 Reduce

數；使單個 Reduce 任務處理數據量大小要合適；

8）經常使用參數

// 輸出合併小文件

SET hive.merge.mapfiles = true; -- 默認 true，在 map-only 任務結束時合併

小文件

SET hive.merge.mapredfiles = true; -- 默認 false，在 map-reduce 任務結

束時合併小文件

SET hive.merge.size.per.task = 268435456; -- 默認 256M

SET hive.merge.smallfiles.avgsize = 16777216; -- 當輸出文件的平均大小

小於 16m 該值時，啓動一個獨立的 map-reduce 任務進行文件 merge

9）開啓 map 端 combiner（不影響最終業務邏輯）

set hive.map.aggr=true；

10）壓縮（選擇快的）

設置 map 端輸出、中間結果壓縮。（不徹底是解決數據傾斜的問題，可是減小了 IO 讀

寫和網絡傳輸，能提升不少效率）

11）開啓 JVM 重用

14.簡述delete，drop，truncate的區別

15.四個by的區別

Sort By：分區內有序；
Order By：全局排序，只有一個 Reducer；
Distrbute By：相似 MR 中 Partition，進行分區，結合 sort by 使用。
Cluster By：當 Distribute by 和 Sorts by 字段相同時，可使用 Cluster by 方式。Cluster by 除了具備 Distribute by 的功能外還兼具 Sort by 的功能。可是排序只能是升序排序，不能指定排序規則爲 ASC 或者 DESC。

16.Hive 裏邊字段的分隔符用的什麼？爲何用\t？有遇到過字段裏邊有\t 的狀況嗎，怎麼處理的？爲何不用 Hive 默認的分隔符，默認的分隔符是什麼？

hive 默認的字段分隔符爲 ascii 碼的控制符\001（^A）,建表的時候用 fields terminated by '\001'

遇到過字段裏邊有\t 的狀況，自定義 InputFormat，替換爲其餘分隔符再作後續處理

三.Spark

1.rdd的屬性

一組分片（Partition），即數據集的基本組成單位。對於RDD來講，每一個分片都會被一個計算任務處理，並決定並行計算的粒度。用戶能夠在建立RDD時指定RDD的分片個數，若是沒有指定，那麼就會採用默認值。默認值就是程序所分配到的CPU Core的數目。
一個計算每一個分區的函數。Spark中RDD的計算是以分片爲單位的，每一個RDD都會實現compute函數以達到這個目的。compute函數會對迭代器進行復合，不須要保存每次計算的結果。
RDD之間的依賴關係。RDD的每次轉換都會生成一個新的RDD，因此RDD之間就會造成相似於流水線同樣的先後依賴關係。在部分分區數據丟失時，Spark能夠經過這個依賴關係從新計算丟失的分區數據，而不是對RDD的全部分區進行從新計算。
一個Partitioner，即RDD的分片函數。當前Spark中實現了兩種類型的分片函數，一個是基於哈希的HashPartitioner，另一個是基於範圍的RangePartitioner。只有對於於key-value的RDD，纔會有Partitioner，非key-value的RDD的Parititioner的值是None。Partitioner函數不但決定了RDD自己的分片數量，也決定了parent RDD Shuffle輸出時的分片數量。
一個列表，存儲存取每一個Partition的優先位置（preferred location）。對於一個HDFS文件來講，這個列表保存的就是每一個Partition所在的塊的位置。按照「移動數據不如移動計算」的理念，Spark在進行任務調度的時候，會盡量地將計算任務分配到其所要處理數據塊的存儲位置。

2.算子分爲哪幾類(RDD支持哪幾種類型的操做)

轉換（Transformation）現有的RDD經過轉換生成一個新的RDD。lazy模式，延遲執行。

轉換函數包括：map，filter，flatMap，groupByKey，reduceByKey，aggregateByKey，union,join, coalesce 等等。

動做（Action）在RDD上運行計算，並返回結果給驅動程序(Driver)或寫入文件系統。

動做操做包括：reduce，collect，count，first，take，countByKey以及foreach等等。

collect 該方法把數據收集到driver端 Array數組類型

全部的transformation只有遇到action才能被執行。

當觸發執行action以後，數據類型再也不是rdd了，數據就會存儲到指定文件系統中，或者直接打印結果或者收集起來。

3.建立rdd的幾種方式

1.集合並行化建立(有數據)

val arr = Array(1,2,3,4,5)

val rdd = sc.parallelize(arr)

val rdd =sc.makeRDD(arr)

2.讀取外部文件系統，如hdfs，或者讀取本地文件(最經常使用的方式)(沒數據)

val rdd2 = sc.textFile("hdfs://hdp-01:9000/words.txt")

// 讀取本地文件

val rdd2 = sc.textFile(「file:///root/words.txt」)

3.從父RDD轉換成新的子RDD

調用Transformation類的方法，生成新的RDD

4.spark運行流程

Worker的功能：定時和master通訊；調度並管理自身的executor

executor：由Worker啓動的，程序最終在executor中運行，（程序運行的一個容器）

spark-submit命令執行時，會根據master地址去向 Master發送請求，

Master接收到Dirver端的任務請求以後，根據任務的請求資源進行調度，（打散的策略），儘量的把任務資源平均分配，而後向WOrker發送指令

Worker收到Master的指令以後，就根據相應的資源，啓動executor（cores,memory）

executor會向dirver端創建請求，通知driver，任務已經能夠運行了

driver運行任務的時候，會把任務發送到executor中去運行。

5.Spark中coalesce與repartition的區別

1）關係：

二者都是用來改變 RDD 的 partition 數量的，repartition 底層調用的就是 coalesce 方法：coalesce(numPartitions, shuffle = true)

2）區別：

repartition 必定會發生 shuffle，coalesce 根據傳入的參數來判斷是否發生 shuffle

通常狀況下增大 rdd 的 partition 數量使用 repartition，減小 partition 數量時使用coalesce

6.sortBy 和 sortByKey的區別

sortBy既能夠做用於RDD[K] ，還能夠做用於RDD[(k,v)]

sortByKey 只能做用於 RDD[K,V] 類型上。

7.map和mapPartitions的區別

8.數據存入Redis 優先使用map mapPartitions foreach foreachPartions哪一個

使用 foreachPartition

* 1,map mapPartition 是轉換類的算子，有返回值

* 2, 寫mysql,redis 的鏈接

foreach * 100萬 100萬次的鏈接

foreachPartions * 200 個分區 200次鏈接一個分區中的數據，共用一個鏈接

foreachParititon 每次迭代一個分區，foreach每次迭代一個元素。

該方法沒有返回值，或者Unit

主要做用於，沒有返回值類型的操做（打印結果，寫入到mysql數據庫中）

在寫入到redis,mysql的時候，優先使用foreachPartititon

9.reduceByKey和groupBykey的區別

reduceByKey會傳一個聚合函數，至關於 groupByKey + mapValues

reduceByKey 會有一個分區內聚合，而groupByKey沒有最核心的區別

結論： reduceByKey有分區內聚合，更高效，優先選擇使用reduceByKey。

10.cache和checkPoint的比較

都是作 RDD 持久化的

1.緩存，是在觸發action以後，把數據寫入到內存或者磁盤中。不會截斷血緣關係

（設置緩存級別爲memory_only：內存不足，只會部分緩存或者沒有緩存，緩存會丟失,memory_and_disk :內存不足，會使用磁盤）

2.checkpoint 也是在觸發action以後，執行任務。單獨再啓動一個job，負責寫入數據到hdfs中。（把rdd中的數據，以二進制文本的方式寫入到hdfs中，有幾個分區，就有幾個二進制文件）

3.某一個RDD被checkpoint以後，他的父依賴關係會被刪除，血緣關係被截斷，該RDD轉換成了CheckPointRDD，之後再對該rdd的全部操做，都是從hdfs中的checkpoint的具體目錄來讀取數據。緩存以後，rdd的依賴關係仍是存在的。

11.spark streaming流式統計單詞數量代碼

object WordCountAll {
  // newValues當前批次的出現的單詞次數， runningCount表示以前運行的單詞出現的結果
 /* def updateFunction(newValues: Seq[Int], runningCount: Option[Int]): Option[Int] = {
    val newCount =  newValues.sum + runningCount.getOrElse(0)// 將歷史前幾個批次的值和當前批次的值進行累加返回當前批次最終的結果
    Some(newCount)
  }*/
  /**
    * String : 單詞 hello
    * Seq[Int] ：單詞在當前批次出現的次數
    * Option[Int] ： 歷史結果
    */
  val updateFunc = (iter: Iterator[(String, Seq[Int], Option[Int])]) => {
    //iter.flatMap(it=>Some(it._2.sum + it._3.getOrElse(0)).map(x=>(it._1,x)))
    iter.flatMap{case(x,y,z)=>Some(y.sum + z.getOrElse(0)).map(m=>(x, m))}
  }
  // 屏蔽日誌
  Logger.getLogger("org.apache").setLevel(Level.ERROR)
  def main(args: Array[String]) {
    // 必需要開啓2個以上的線程，一個線程用來接收數據，另一個線程用來計算
    val conf = new SparkConf().setMaster("local[2]").setAppName("NetworkWordCount")
      // 設置sparkjob計算時所採用的序列化方式
      .set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
      .set("spark.rdd.compress", "true") // 節約大量的內存內容
    // 若是你的程序出現垃圾回收時間過程，能夠設置一下java的垃圾回收參數
    // 同時也會建立sparkContext對象
    // 批次時間 >= 批次處理的總時間 (批次數據量，集羣的計算節點數量和配置)
    val ssc = new StreamingContext(conf, Seconds(5))

    //作checkpoint 寫入共享存儲中
    ssc.checkpoint("c://aaa")

    // 建立一個將要鏈接到 hostname:port 的 DStream，如 localhost:9999
    val lines: ReceiverInputDStream[String] = ssc.socketTextStream("192.168.175.101", 44444)
    //updateStateByKey結果能夠累加可是須要傳入一個自定義的累加函數：updateFunc
    val results = lines.flatMap(_.split(" ")).map((_,1)).updateStateByKey(updateFunc, new HashPartitioner(ssc.sparkContext.defaultParallelism), true)
    //打印結果到控制檯
    results.print()
    //開始計算
    ssc.start()
    //等待中止
    ssc.awaitTermination()
  }
}

12.簡述map和flatMap的區別和應用場景

map是對每個元素進行操做，flatmap是對每個元素操做後並壓平

13.計算曝光數和點擊數

14.分別列出幾個經常使用的transformation和action算子

轉換算子：map,map,filter,reduceByKey,groupByKey,groupBy

行動算子：foreach，foreachpartition,collect,collectAsMap,take,top,first,count,countByKey

15.按照需求使用spark編寫如下程序，要求使用scala語言

當前文件a.txt的格式，請統計每一個單詞出現的次數

A,b,c

B,b,f,e

object WordCount {

  def main(args: Array[String]): Unit = {

    val conf = new SparkConf()
      .setAppName(this.getClass.getSimpleName)
      .setMaster("local[*]")
    val sc = new SparkContext(conf)

    var sData: RDD[String] = sc.textFile("a.txt")
    val sortData: RDD[(String, Int)] = sData.flatMap(_.split(",")).map((_,1)).reduceByKey(_+_)
    sortData.foreach(print)
  }
}

16.spark應用程序的執行命令是什麼？

/usr/local/spark-current2.3/bin/spark-submit \

--class com.wedoctor.Application \

--master yarn \

--deploy-mode client \

--driver-memory 1g \

--executor-memory 2g \

--queue root.wedw \

--num-executors 200 \

--jars /home/pgxl/liuzc/config-1.3.0.jar,/home/pgxl/liuzc/hadoop-lzo-0.4.20.jar,/home/pgxl/liuzc/elasticsearch-hadoop-hive-2.3.4.jar \

/home/pgxl/liuzc/sen.jar

17.Spark應用執行有哪些模式，其中哪幾種是集羣模式

18.請說明spark中廣播變量的用途

使用廣播變量，每一個 Executor 的內存中，只駐留一份變量副本，而不是對每一個 task 都傳輸一次大變量，省了不少的網絡傳輸，對性能提高具備很大幫助，並且會經過高效的廣播算法來減小傳輸代價。

19.如下代碼會報錯嗎？若是會怎麼解決 val arr = new ArrayList[String]; arr.foreach(println)

20.寫出你用過的spark中的算子，其中哪些會產生shuffle過程

reduceBykey：

groupByKey：

…ByKey:

21.Spark中rdd與partition的區別

22.請寫出建立Dateset的幾種方式

23.描述一下RDD，DataFrame，DataSet的區別？

1）RDD

優勢:

編譯時類型安全

編譯時就能檢查出類型錯誤

面向對象的編程風格

直接經過類名點的方式來操做數據

缺點:

序列化和反序列化的性能開銷

不管是集羣間的通訊, 仍是 IO 操做都須要對對象的結構和數據進行序列化和反序列化。

GC 的性能開銷，頻繁的建立和銷燬對象, 勢必會增長 GC

2）DataFrame

DataFrame 引入了 schema 和 off-heap

schema : RDD 每一行的數據, 結構都是同樣的，這個結構就存儲在 schema 中。 Spark 經過 schema 就可以讀懂數據, 所以在通訊和 IO 時就只須要序列化和反序列化數據, 而結構的部分就能夠省略了。

3）DataSet

DataSet 結合了 RDD 和 DataFrame 的優勢，並帶來的一個新的概念 Encoder。

當序列化數據時，Encoder 產生字節碼與 off-heap 進行交互，可以達到按需訪問數據的效果，而不用反序列化整個對象。Spark 尚未提供自定義 Encoder 的 API，可是將來會加入。

三者之間的轉換：

24.描述一下Spark中stage是如何劃分的？描述一下shuffle的概念

25.Spark 在yarn上運行須要作哪些關鍵的配置工做？如何kill -個Spark在yarn運行中Application

26.一般來講，Spark與MapReduce相比，Spark運行效率更高。請說明效率更高來源於Spark內置的哪些機制？並請列舉常見spark的運行模式？

27.RDD中的數據在哪？

RDD中的數據在數據源，RDD只是一個抽象的數據集，咱們經過對RDD的操做就至關於對數據進行操做。

28.若是對RDD進行cache操做後，數據在哪裏？

數據在第一執行cache算子時會被加載到各個Executor進程的內存中，第二次就會直接從內存中讀取而不會區磁盤。

29.Spark中Partition的數量由什麼決定

和Mr同樣，可是Spark默認最少有兩個分區。

30.Scala裏面的函數和方法有什麼區別

31.SparkStreaming怎麼進行監控?

32.Spark判斷Shuffle的依據?

父RDD的一個分區中的數據有可能被分配到子RDD的多個分區中

33.Scala有沒有多繼承？能夠實現多繼承麼？

34.Sparkstreaming和flink作實時處理的區別

35.Sparkcontext的做用

36.Sparkstreaming讀取kafka數據爲何選擇直連方式

37.離線分析何時用sparkcore和sparksql

38.Sparkstreaming實時的數據不丟失的問題

39.簡述寬依賴和窄依賴概念，groupByKey,reduceByKey,map,filter,union五種操做哪些會致使寬依賴，哪些會致使窄依賴

40.數據傾斜可能會致使哪些問題，如何監控和排查，在設計之初，要考慮哪些來避免

41.有一千萬條短信，有重複，以文本文件的形式保存，一行一條數據，請用五分鐘時間，找出重複出現最多的前10條

42.現有一文件，格式以下，請用spark統計每一個單詞出現的次數

18619304961，18619304064，186193008，186193009

18619304962，18619304065，186193007，186193008

18619304963，18619304066，186193006，186193010

43.共享變量和累加器

累加器（accumulator）是 Spark 中提供的一種分佈式的變量機制，其原理相似於mapreduce，即分佈式的改變，而後聚合這些改變。累加器的一個常見用途是在調試時對做業執行過程當中的事件進行計數。而廣播變量用來高效分發較大的對象。

共享變量出現的緣由：

一般在向 Spark 傳遞函數時，好比使用 map() 函數或者用 filter() 傳條件時，可使用驅動器程序中定義的變量，可是集羣中運行的每一個任務都會獲得這些變量的一份新的副本，更新這些副本的值也不會影響驅動器中的對應變量。

Spark 的兩個共享變量，累加器與廣播變量，分別爲結果聚合與廣播這兩種常見的通訊模式突破了這一限制。

44.當 Spark 涉及到數據庫的操做時，如何減小 Spark 運行中的數據庫鏈接數？

使用 foreachPartition 代替 foreach，在 foreachPartition 內獲取數據庫的鏈接。

四.Kafka

1.Kafka名詞解釋和工做方式

Producer ：消息生產者，就是向kafka broker發消息的客戶端。
Consumer ：消息消費者，向kafka broker取消息的客戶端
Topic ：咋們能夠理解爲一個隊列。
Consumer Group （CG）：這是kafka用來實現一個topic消息的廣播（發給全部的consumer）和單播（發給任意一個consumer）的手段。一個topic能夠有多個CG。topic的消息會複製（不是真的複製，是概念上的）到全部的CG，但每一個partion只會把消息發給該CG中的一個consumer。若是須要實現廣播，只要每一個consumer有一個獨立的CG就能夠了。要實現單播只要全部的consumer在同一個CG。用CG還能夠將consumer進行自由的分組而不須要屢次發送消息到不一樣的topic。
Broker ：一臺kafka服務器就是一個broker。一個集羣由多個broker組成。一個broker能夠容納多個topic。
Partition：爲了實現擴展性，一個很是大的topic能夠分佈到多個broker（即服務器）上，一個topic能夠分爲多個partition，每一個partition是一個有序的隊列。partition中的每條消息都會被分配一個有序的id（offset）。kafka只保證按一個partition中的順序將消息發給consumer，不保證一個topic的總體（多個partition間）的順序。
Offset：kafka的存儲文件都是按照offset.kafka來命名，用offset作名字的好處是方便查找。例如你想找位於2049的位置，只要找到2048.kafka的文件便可。固然the first offset就是00000000000.kafka

2.Consumer與topic關係

本質上kafka只支持Topic；

每一個group中能夠有多個consumer，每一個consumer屬於一個consumer group；

一般狀況下，一個group中會包含多個consumer，這樣不只能夠提升topic中消息的併發消費能力，並且還能提升"故障容錯"性，若是group中的某個consumer失效那麼其消費的partitions將會有其餘consumer自動接管。

對於Topic中的一條特定的消息，只會被訂閱此Topic的每一個group中的其中一個consumer消費，此消息不會發送給一個group的多個consumer；

那麼一個group中全部的consumer將會交錯的消費整個Topic，每一個group中consumer消息消費互相獨立，咱們能夠認爲一個group是一個"訂閱"者。

在kafka中,一個partition中的消息只會被group中的一個consumer消費(同一時刻)；

一個Topic中的每一個partions，只會被一個"訂閱者"中的一個consumer消費，不過一個consumer能夠同時消費多個partitions中的消息。

kafka的設計原理決定,對於一個topic，同一個group中不能有多於partitions個數的consumer同時消費，不然將意味着某些consumer將沒法獲得消息。

kafka只能保證一個partition中的消息被某個consumer消費時是順序的；事實上，從Topic角度來講,當有多個partitions時,消息仍不是全局有序的。

3.kafka消息發送的應答機制

設置發送數據是否須要服務端的反饋,有三個值0,1,-1

0: producer不會等待broker發送ack

1: 當leader接收到消息以後發送ack

-1: 當全部的follower都同步消息成功後發送ack

request.required.acks=0

4.如何保證kafka消費者消費數據是全局有序的

僞命題

若是要全局有序的，必須保證生產有序，存儲有序，消費有序。

因爲生產能夠作集羣，存儲能夠分片，消費能夠設置爲一個consumerGroup，要保證全局有序，就須要保證每一個環節都有序。

只有一個可能，就是一個生產者，一個partition，一個消費者。這種場景和大數據應用場景相悖。

5.有兩個數據源，一個記錄的是廣告投放給用戶的日誌，一個記錄用戶訪問日誌，另外還有一個固定的用戶基礎表記錄用戶基本信息（好比學歷，年齡等等）。如今要分析廣告投放對與哪類用戶更有效，請採用熟悉的技術描述解決思路。另外若是兩個數據源都是實時數據源（好比來自kafka），他們數據在時間上相差5分鐘，須要哪些調整來解決實時分析問題？

6.Kafka和SparkStreaing如何集成?

7.列舉Kafka的優勢，簡述Kafka爲何能夠作到每秒數十萬甚至上百萬消息的高效分發？

8.爲何離線分析要用kafka？

Kafka的做用是解耦，若是直接從日誌服務器上採集的話，實時離線都要採集，等於要採集兩份數據，而使用了kafka的話，只須要從日誌服務器上採集一份數據，而後在kafka中使用不一樣的兩個組讀取就好了

9.Kafka怎麼進行監控?

10.Kafka與傳統的消息隊列服務有很麼不一樣

11.Kafka api low-level與high-level有什麼區別，使用low-level須要處理哪些細節

五.Hbase

1.Hbase調優

在庫表設計的時候，儘可能考慮rowkey和columnfamily的特性

進行hbase集羣的調優：見hbase調優

2.hbase的rowkey怎麼建立好？列族怎麼建立比較好？

hbase存儲時，數據按照Row key的字典序(byte order)排序存儲。設計key時，要充分排序存儲這個特性，將常常一塊兒讀取的行存儲放到一塊兒。(位置相關性)

一個列族在數據底層是一個文件，因此將常常一塊兒查詢的列放到一個列族中，列族儘可能少，減小文件的尋址時間。

設計原則

1）rowkey 長度原則

2）rowkey 散列原則

3）rowkey 惟一原則

如何設計

1）生成隨機數、hash、散列值

2）字符串反轉

3.hbase過濾器實現用途

加強hbase查詢數據的功能

減小服務端返回給客戶端的數據量

4.HBase宕機如何處理

答：宕機分爲HMaster宕機和HRegisoner宕機，若是是HRegisoner宕機，HMaster會將其所管理的region從新分佈到其餘活動的RegionServer上，因爲數據和日誌都持久在HDFS中，該操做不會致使數據丟失。因此數據的一致性和安全性是有保障的。

若是是HMaster宕機，HMaster沒有單點問題，HBase中能夠啓動多個HMaster，經過Zookeeper的Master Election機制保證總有一個Master運行。即ZooKeeper會保證總會有一個HMaster在對外提供服務。

5.hive跟hbase的區別是？

共同點：
1.hbase與hive都是架構在hadoop之上的。都是用hadoop做爲底層存儲

區別：
2.Hive是創建在Hadoop之上爲了減小MapReduce jobs編寫工做的批處理系統，HBase是爲了支持彌補Hadoop對實時操做的缺陷的項目。
3.想象你在操做RMDB數據庫，若是是全表掃描，就用Hive+Hadoop,若是是索引訪問，就用HBase+Hadoop 。
4.Hive query就是MapReduce jobs能夠從5分鐘到數小時不止，HBase是很是高效的，確定比Hive高效的多。
5.Hive自己不存儲和計算數據，它徹底依賴於HDFS和MapReduce，Hive中的表純邏輯。
6.hive借用hadoop的MapReduce來完成一些hive中的命令的執行
7.hbase是物理表，不是邏輯表，提供一個超大的內存hash表，搜索引擎經過它來存儲索引，方便查詢操做。
8.hbase是列存儲。
9.hdfs做爲底層存儲，hdfs是存放文件的系統，而Hbase負責組織文件。
10.hive須要用到hdfs存儲文件，須要用到MapReduce計算框架。

6.hbase寫流程

client向hregionserver發送寫請求。
hregionserver將數據寫到hlog（write ahead log）。爲了數據的持久化和恢復。
hregionserver將數據寫到內存（memstore）
反饋client寫成功。

7.hbase讀流程

經過zookeeper和-ROOT- .META.表定位hregionserver。
數據從內存和硬盤合併後返回給client
數據塊會緩存

8.hbase數據flush過程

當memstore數據達到閾值（默認是64M），將數據刷到硬盤，將內存中的數據刪除，同時刪除Hlog中的歷史數據。
並將數據存儲到hdfs中。

在hlog中作標記點。

9.數據合併過程

當數據塊達到4塊，hmaster將數據塊加載到本地，進行合併
當合並的數據超過256M，進行拆分，將拆分後的region分配給不一樣的hregionserver管理
當hregionser宕機後，將hregionserver上的hlog拆分，而後分配給不一樣的hregionserver加載，修改.META.
注意：hlog會同步到hdfs

10.Hmaster和Hgionserver職責

Hmaster

一、管理用戶對Table的增、刪、改、查操做；

二、記錄region在哪臺Hregion server上

三、在Region Split後，負責新Region的分配；

四、新機器加入時，管理HRegion Server的負載均衡，調整Region分佈

五、在HRegion Server宕機後，負責失效HRegion Server 上的Regions遷移。

Hgionserver

HRegion Server主要負責響應用戶I/O請求，向HDFS文件系統中讀寫數據，是HBASE中最核心的模塊。

HRegion Server管理了不少table的分區，也就是region。

11.HBase列族和region的關係？

HBase有多個RegionServer，每一個RegionServer裏有多個Region，一個Region中存放着若干行的行鍵以及所對應的數據，一個列族是一個文件夾，若是常常要搜索整個一條數據，列族越少越好，若是隻有一部分的數據須要常常被搜索，那麼將常常搜索的創建一個列族，其餘不常搜索的創建列族檢索較快。

12.請簡述Hbase的物理模型是什麼

13.請問若是使用Hbase作即席查詢，如何設計二級索引

六.Flink

1.Flink實時計算時落磁盤嗎

2.日活DAU的統計須要注意什麼

3.Flink調優

4.Flink的容錯是怎麼作的

5.Parquet格式的好處？何時讀的快何時讀的慢

七.Java

1.HashMap實現原理，比較ArrayList，LinkedList的存儲特性和讀寫性能

2.寫出你用過的設計模式，並舉例說明解決的實際問題

3.Java建立線程的幾種方式

繼承Thread類，重寫run方法
實現Runnable接口，實現run方法
經過線程池獲取線程
實現Callable接口並實現call方法，建立該類的實例，使用FutureTask類包裝Callable對象，使用FutureTask對象做爲Thread對象的target建立並啓用新線程

4.請簡述操做系統的線程和進程的區別

5.Java程序出現OutOfMemoryError:unable to create new native thread 的緣由可能有哪些？如何分析和解決？

6.採用java或本身熟悉的任何語言分別實現簡單版本的線性表和鏈表，只需實現add,remove方法便可

7.ArrayList，LinkedList和Vector都實現了List接口，對於添加或刪除元素哪一個效率更高？

8.簡述JVM GC算法

1）引用計數法 應用於：微軟的 COM/ActionScrip3/Python 等

a) 若是對象沒有被引用，就會被回收，缺點：須要維護一個引用計算器

2）複製算法 年輕代中使用的是 Minor GC，這種 GC 算法採用的是複製算法(Copying)

a) 效率高，缺點：須要內存容量大，比較耗內存

b) 使用在佔空間比較小、刷新次數多的新生區

3）標記清除 老年代通常是由標記清除或者是標記清除與標記整理的混合實現

a) 效率比較低，會差生碎片。

4）標記壓縮 老年代通常是由標記清除或者是標記清除與標記整理的混合實現

a) 效率低速度慢，須要移動對象，但不會產生碎片。

5）標記清除壓縮標記清除-標記壓縮的集合，屢次 GC 後才 Compact

a) 使用於佔空間大刷新次數少的養老區，是 3 4 的集合體

9.Java中迭代器和集合的區別？

集合是將全部數據加載到內存，而後經過集合的方法去內存中獲取，而迭代器是一個對象，實現了Iterator接口，實現了接口的hasNext和Next方法。

10.HashMap 和 HashTable 區別

1) 線程安全性不一樣

HashMap 是線程不安全的，HashTable 是線程安全的，其中的方法是 Synchronize 的，

在多線程併發的狀況下，能夠直接使用 HashTabl，可是使用 HashMap 時必須本身增長同步

處理。

2) 是否提供 contains 方法

HashMap 只有 containsValue 和 containsKey 方法；HashTable 有 contains、containsKey

和 containsValue 三個方法，其中 contains 和 containsValue 方法功能相同。

3) key 和 value 是否容許 null 值

Hashtable 中，key 和 value 都不容許出現 null 值。HashMap 中，null 能夠做爲鍵，這

樣的鍵只有一個；能夠有一個或多個鍵所對應的值爲 null。

4) 數組初始化和擴容機制

HashTable 在不指定容量的狀況下的默認容量爲 11，而 HashMap 爲 16，Hashtable 不

要求底層數組的容量必定要爲 2 的整數次冪，而 HashMap 則要求必定爲 2 的整數次冪。

Hashtable 擴容時，將容量變爲原來的 2 倍加 1，而 HashMap 擴容時，將容量變爲原

來的 2 倍。

11.線程池使用注意哪些方面？

線程池分爲單線程線程池，固定大小線程池，可緩衝的線程池

12.HashMap和TreeMap的區別？TreeMap排序規則？

TreeMap會自動進行排序，根據key的Compare方法進行排序

13.用java實現單例模式

14.使用遞歸算法求n的階乘：n! ,語言不限

15.HashMap和Hashtable的區別是什麼

16.TreeSet 和 HashSet 區別

HashSet 是採用 hash 表來實現的。其中的元素沒有按順序排列，add()、remove()以及

contains()等方法都是複雜度爲 O(1)的方法。

TreeSet 是採用樹結構實現（紅黑樹算法）。元素是按順序進行排列，可是 add()、

remove()以及 contains()等方法都是複雜度爲 O(log (n))的方法。它還提供了一些方法來處理

排序的 set，如 first()，last()，headSet()，tailSet()等等。

17.Stringbuffer 和 Stringbuild 區別

1、StringBuffer 與 StringBuilder 中的方法和功能徹底是等價的。

2、只是 StringBuffer 中的方法大都採用了 synchronized 關鍵字進行修飾，所以是線程

安全的，而 StringBuilder 沒有這個修飾，能夠被認爲是線程不安全的。

3、在單線程程序下，StringBuilder 效率更快，由於它不須要加鎖，不具有多線程安全

而 StringBuffer 則每次都須要判斷鎖，效率相對更低

18.Final、Finally、Finalize

final：修飾符（關鍵字）有三種用法：修飾類、變量和方法。修飾類時，意味着它不

能再派生出新的子類，即不能被繼承，所以它和 abstract 是反義詞。修飾變量時，該變量

使用中不被改變，必須在聲明時給定初值，在引用中只能讀取不可修改，即爲常量。修飾

方法時，也一樣只能使用，不能在子類中被重寫。

finally：一般放在 try…catch 的後面構造最終執行代碼塊，這就意味着程序不管正常執

行仍是發生異常，這裏的代碼只要 JVM 不關閉都能執行，能夠將釋放外部資源的代碼寫在

finally 塊中。

finalize：Object 類中定義的方法，Java 中容許使用 finalize() 方法在垃圾收集器將對象

從內存中清除出去以前作必要的清理工做。這個方法是由垃圾收集器在銷燬對象時調用

的，經過重寫 finalize() 方法能夠整理系統資源或者執行其餘清理工做。

19..==和 Equals 區別

== : 若是比較的是基本數據類型，那麼比較的是變量的值

若是比較的是引用數據類型，那麼比較的是地址值（兩個對象是否指向同一塊內

存）

equals:若是沒重寫 equals 方法比較的是兩個對象的地址值。

若是重寫了 equals 方法後咱們每每比較的是對象中的屬性的內容

equals 方法是從 Object 類中繼承的，默認的實現就是使用==

八.Elasticsearch

1.爲何要用es？存進es的數據是什麼格式的，怎麼查詢

九.Flume

1.什麼是flume

a.Flume是一個分佈式、可靠、和高可用的海量日誌採集、聚合和傳輸的系統。

b.Flume能夠採集文件，socket數據包等各類形式源數據，又能夠將採集到的數據輸出到HDFS、hbase、hive、kafka等衆多外部存儲系統中

c.通常的採集需求，經過對flume的簡單配置便可實現

d.ume針對特殊場景也具有良好的自定義擴展能力，所以，flume能夠適用於大部分的平常數據採集場景

2.flume運行機制

Flume分佈式系統中最核心的角色是agent，flume採集系統就是由一個個agent所鏈接起來造成
每個agent至關於一個數據傳遞員，內部有三個組件：
1. 1. Source：採集源，用於跟數據源對接，以獲取數據
  2. Sink：下沉地，採集數據的傳送目的，用於往下一級agent傳遞數據或者往最終存儲系統傳遞數據
  3. Channel：angent內部的數據傳輸通道，用於從source將數據傳遞到sink

3.Flume採集數據到Kafka中丟數據怎麼辦

4.Flume怎麼進行監控?

5.Flume的三層架構，collector、agent、storage

十.Sqoop

1.sqoop工做機制(原理)

Sqoop的原理其實就是將導入導出命令轉化爲mapreduce程序來執行，sqoop在接收到命令後，都要生成mapreduce程序

在翻譯出的mapreduce中主要是對inputformat和outputformat進行定製

十一.Zookeeper

十二.Kylin

十三.Logstash

十四.Python

十五.Shell

十六.Redis

1.緩存穿透、緩存雪崩、緩存擊穿

1）緩存穿透是指查詢一個必定不存在的數據。因爲緩存命不中時會去查詢數據庫，查不到

數據則不寫入緩存，這將致使這個不存在的數據每次請求都要到數據庫去查詢，形成緩存穿

透。

解決方案：

① 是將空對象也緩存起來，並給它設置一個很短的過時時間，最長不超過 5 分鐘

② 採用布隆過濾器，將全部可能存在的數據哈希到一個足夠大的 bitmap 中，一個必定

不存在的數據會被這個 bitmap 攔截掉，從而避免了對底層存儲系統的查詢壓力

2）若是緩存集中在一段時間內失效，發生大量的緩存穿透，全部的查詢都落在數據庫上，

就會形成緩存雪崩。

解決方案：

儘可能讓失效的時間點不分佈在同一個時間點

3）緩存擊穿，是指一個 key 很是熱點，在不停的扛着大併發，當這個 key 在失效的瞬間，

持續的大併發就穿破緩存，直接請求數據庫，就像在一個屏障上鑿開了一個洞。

能夠設置 key 永不過時

2.數據類型

3.持久化

1）RDB 持久化：

① 在指定的時間間隔內持久化

② 服務 shutdown 會自動持久化

③ 輸入 bgsave 也會持久化

2）AOF : 以日誌形式記錄每一個更新操做

Redis 從新啓動時讀取這個文件，從新執行新建、修改數據的命令恢復數據。

保存策略：

推薦（而且也是默認）的措施爲每秒持久化一次，這種策略能夠兼顧速度和安全性。

缺點：

1 比起 RDB 佔用更多的磁盤空間

2 恢復備份速度要慢

3 每次讀寫都同步的話，有必定的性能壓力

4 存在個別 Bug，形成恢復不能

選擇策略：

官方推薦：

string

字符串

list

能夠重複的集合

set

不能夠重複的集合

hash

相似於 Map<String,String>

zset(sorted set）

帶分數的 set

若是對數據不敏感，能夠選單獨用 RDB；不建議單獨用 AOF，由於可能出現 Bug;若是隻是作純內存緩存，能夠都不用

4.悲觀鎖和樂觀鎖

悲觀鎖：執行操做前假設當前的操做確定（或有很大概率）會被打斷（悲觀）。基於這個假設，咱們在作操做前就會把相關資源鎖定，不容許本身執行期間有其餘操做干擾。

樂觀鎖：執行操做前假設當前操做不會被打斷（樂觀）。基於這個假設，咱們在作操做前不會鎖定資源，萬一發生了其餘操做的干擾，那麼本次操做將被放棄。Redis 使用的就是樂觀鎖。

5.redis 是單線程的，爲何那麼快

1)徹底基於內存，絕大部分請求是純粹的內存操做，很是快速。

2)數據結構簡單，對數據操做也簡單，Redis 中的數據結構是專門進行設計的

3)採用單線程，避免了沒必要要的上下文切換和競爭條件，也不存在多進程或者多線程致使的切換而消耗 CPU，不用去考慮各類鎖的問題，不存在加鎖釋放鎖操做，沒有由於可能出現死鎖而致使的性能消耗

4)使用多路 I/O 複用模型，非阻塞 IO

5)使用底層模型不一樣，它們之間底層實現方式以及與客戶端之間通訊的應用協議不同，

Redis 直接本身構建了 VM 機制，由於通常的系統調用系統函數的話，會浪費必定的時間去移動和請求

十七.Datax

十八.Mysql

1.請寫出mysql登陸命令，用戶名user，密碼123456，地址192.168.1.130

mysql -h 192.168.1.130 -uuser -p123456 -P3306 -Dwemeta_test

十九.數據結構與算法

1.在python，scala，java中任選兩種實現快速排序和二分查找(接受僞代碼)

2.快排的空間複雜度和原理

3.手寫歸併排序

4.二叉樹的前中後序遍歷

5.鏈表轉置/二叉樹轉置

6.單向鏈表反轉

7.字符串反轉

8.冒泡的時間空間複雜度，原理

9.實現堆棧push pop min複雜度0（1）

二十.機器學習

1.請描述K鄰近算法的原理

胖若兩人zc

發佈了79 篇原創文章 · 獲贊 108 · 訪問量 8萬+

私信關注

大數據 面試題 知識點

一.Hadoop

1.hdfs寫流程