2018.10.22
1.抽象類與接口的區別？
1.語法層面上的區別
1）抽象類可以提供成員方法的實現細節，而接口中只能存在public abstract 方法；
2）抽象類中的成員變量可以是各種類型的，而接口中的成員變量只能是public static final類型的；
3）接口中不能含有靜態代碼塊以及靜態方法，而抽象類可以有靜態代碼塊和靜態方法；
4）一個類只能繼承一個抽象類，而一個類卻可以實現多個接口。
2.設計層面上的區別
1）抽象類是對一種事物的抽象，即對類抽象，而接口是對行爲的抽象。抽象類是對整個類整體進行抽象，包括屬性、行爲，但是接口卻是對類局部（行爲）進行抽象。例如將鳥，飛機各定義爲一個類，將飛行定義爲一個接口。
2）設計層面不同，抽象類作爲很多子類的父類，它是一種模板式設計。而接口是一種行爲規範，它是一種輻射式設計。對於抽象類，如果需要添加新的方法，可以直接在抽象類中添加具體的實現，子類可以不進行變更；而對於接口則不行，如果接口進行了變更，則所有實現這個接口的類都必須進行相應的改動。
2.構造方法的定義規則
定義時候的基本構成
修飾詞 方法名（參數列表）{
方法體
}
注意點：1.沒有返回值這一項 2.方法名必須與類名保持一致 3.不能被static、final、synchronized、abstract和native修飾。
3.List接口與Set接口的區別以及常用子類。
List中的元素，有序（元素的順序與添加元素的順序一致）、可重複、可爲空；
Set中的元素，無序、不重複、只有一個空元素；
Map中的元素，無序、鍵不重，值可重、可一個空鍵、多可空值。
List常用子類ArrayList、Vector、LinkedList，其中ArrayList、Vector底層爲數組，查詢速度快，插入刪除速度慢，LinkedList底層爲雙向鏈表，查詢速度慢，插入刪除速度快。Vector線程安全。
Set常用子類HashSet與TreeSet，其中HashSet底層是哈希表；TreeSet底層是二叉樹。
Map常用子類HashMap與TreeMap。
2018.10.23
HDFS 和YARN 的基本概念。
1 HDFS
分佈式文件系統，主/從架構
NameNode 負責管理元數據（文件名稱，副本數量，文件位置，塊大小）。HDFS 存儲是以塊存儲 默認塊大小 128MB，hadoop1 中默認的塊大小是64MB。一個節點。
DataNode：主要存儲真正的數據，多節點。
secondaryNamenode 輔助節點，用於合併兩類文件。
Fsimage ,edits 作爲元數據的鏡像和操作的日誌記錄。
在HDFS第一次使用的時候需要對其進行格式化，目的是生成fsimage 和 edits 文件。
2 YARN 資源管理器，操作系統 可以在YARN進行任務的運行，YARN爲這些運行的任務分配資源，管理。
主節點： resourceManager 負責全部集羣中的資源管理，和任務分配
從節點： nodeManager 負責每個機器上的資源管理
2018.10.23
hadoop常用配置文件位置及其含義。
2018.10.24
1.HDFS的副本複製策略
hadoop官網描述如下：
對於常見情況，當複製因子爲3時，HDFS的放置策略是在編寫器位於datanode上時將一個副本放在本地計算機上，否則放在隨機datanode上，另一個副本放在另一個（遠程）機架上的節點上，最後一個在同一個遠程機架的不同節點上。此策略可以減少機架間寫入流量，從而提高寫入性能。機架故障的可能性遠小於節點故障的可能性; 此策略不會影響數據可靠性和可用性保證。但是，它確實減少了讀取數據時使用的聚合網絡帶寬，因爲塊只放在兩個唯一的機架而不是三個。使用此策略時，文件的副本不會均勻分佈在機架上。三分之一的副本位於一個節點上，三分之二的副本位於一個機架上，另外三分之一均勻分佈在剩餘的機架上。此策略可提高寫入性能，而不會影響數據可靠性或讀取性能。
如果複製因子大於3，則隨機確定第4個及以下副本的放置，同時保持每個機架的副本數量低於上限（基本上是（副本-1）/機架+ 2）。
由於NameNode不允許DataNode具有同一塊的多個副本，因此創建的最大副本數是此時DataNode的總數。
在將存儲類型和存儲策略的支持添加到HDFS之後，除了上述機架感知之外，NameNode還會考慮策略以進行副本放置。NameNode首先根據機架感知選擇節點，然後檢查候選節點是否具有與文件關聯的策略所需的存儲。如果候選節點沒有存儲類型，則NameNode將查找另一個節點。如果在第一個路徑中找不到足夠的節點來放置副本，則NameNode會在第二個路徑中查找具有回退存儲類型的節點。
此處描述的當前默認副本放置策略是正在進行的工作。
概括爲：
2.HDFS寫數據流程，畫圖加文字描述。
1.客戶端向namenode請求上傳文件，namenode檢測該文件是否已存在，父目錄是否存在，然後返回是否可以上傳。
2.客戶端請求上傳第一個block，namenode返回三個節點（dn1,dn2,dn3）。
3.客戶端向dn1請求上傳數據，dn1收到請求後會調用dn2，dn2調用dn3，建立傳輸通道，dn1、dn2、dn3逐級應答。
4.客戶端開始往dn1上傳第一個block（先從磁盤讀取放到一個本地內存緩存），以packet爲單位。dn1收到一個block就會傳給dn2，dn2傳給dn3。dn1每傳完一個packet會被放入一個應答隊列等待應答。
5.當一個block傳輸完成之後，客戶端再次向namenode請求上傳第二、第三個block，重複上面的步驟（2-4步），直至文件上傳完成。
HDFS讀數據流程
文字描述：
1 客戶端通過向namenode請求下載文件 ，namenode 收到請求之後查詢元數據信息,找到datanode數據塊的信息。
2 客戶端挑選一臺就近的datanode,進行請求數據。
3 datanode開始傳輸數據給客戶端，是以packet 爲單位進行讀取。
4 客戶端 接收packet 數據,先在本地緩存，最後寫入到目標文件。
3.NameNode與DataNode的工作機制。
NameNode工作機制
1.第一次啓動:第一次啓動都需要格式化nameNode ,創建fsimage,edits. 第一次啓動只需要加載fsiamge。
2.如果不是第一次啓動： 直接加載edits ,fsimage鏡像文件 ，合併成一個新的fsimage 文件，再創建edits 文件記錄新的操作行爲。
啓動的過程中，會存在30秒鐘等待時間 ，這個等待的時間就是安全模式。
DataNode工作機制
文字描述：
1.一個數據塊在datanode上是以文件形式存儲在磁盤上的，包括了兩個文件，一個數據本身，一個是元數據包 包括數據塊的長度，,數據塊的校驗和,由於HDFS上的數據是不允許被重複上傳的所以在上傳之前會對上傳的數據進行檢查 ,時間戳。
2.DataNode啓動後會向nameNode進行註冊，通過後，會週期性的向namenode上報自己的datanode上的塊信息。
3.心跳報告，每3秒鐘向nameNode進行彙報,心跳的返回結果中帶有NameNode 帶給該datanode複製數據塊，移動數據塊的命令, 如果說超過了10分鐘datanode沒有響應 ，則就會認爲這個datanode節點不可用,會選擇其他的機器。
2018.10.26
如果NameNode意外終止，secondaryNameNode的工作是什麼？它是如何工作的？
secondaryNameNode
1.並非NameNode的熱備；
2.輔助NameNode，分擔其工作量；
3.定期合併fsimage和edits，推送給NameNode；
4.在緊急情況下，可輔助恢復NameNode。
2018.10.28
HDFS安全模式
在系統的正常操作期間，namenode會在內存中保留所有塊位置的映射信息。在安全模式下，各個datanode會向namenode發送最新的塊列表信息，namenode瞭解到足夠多的塊位置信息之後，即可高效運行文件系統。
如果滿足“最小副本條件”，namenode會在30秒鐘之後就退出安全模式。所謂的最小副本條件指的是在整個文件系統中99.9%的塊滿足最小副本級別（默認值：dfs.replication.min=1）。在啓動一個剛剛格式化的HDFS集羣時，因爲系統中還沒有任何塊，所以namenode不會進入安全模式。
2018.10.30
Writable序列化（Hadoop序列化）與java序列化的區別
1.java序列化的時候會保存類的相關和依賴關係等類的基本信息，但是hadoop序列化的時候不會保存類的信息只會保存字段值。
2.java反序列化相當於每次重新創建一個對象，而Hadoop反序列化的時候是重用對象的，會降低創建對象的資源消耗。
3.Hadoop序列化中定製序列化格式很容易，java比較困難。
4.Hadoop序列化後的數據量小，java序列化後的數據量大。
5.序列化/反序列化方式不同。
MapReduce工作流程（shuffle流程）
2018.11.05
job在yarn上提交流程
2018.11.07
zookeeper選舉（投票）機制
1.沒有數據
通過myid給自己投票，根據myid的大小決定票數（比如myid爲1，就給自己投1票），誰的票數多，誰就是leader，其餘的爲follower。半數以上的節點運行成功之後，才提供服務。
2.有數據
根據xid數據的更新版本號爲標準，xid最大的爲leader（因爲follower要同步leader上的數據，所以要確保leader的數據爲最新版本），如果xid一樣則判斷myid的票數。
HA 高可用原理
所謂HA（high available），即高可用（7*24小時不中斷服務）。實現高可用最關鍵的策略是消除單點故障。
Active standby 解決了namenode 單點故障。
存在的服務 ： zookeeper（解決一致性問題） ； journalnode（解決edits同步問題）； zkfc（解決切換問題，負責監測）。
同步： 元數據（edits ,fsimage ）, journalnode 節點，同步edits 編輯日誌 。集羣中安全性得到了保證，但是一致性卻減弱了，爲了解決一致性的問題，必須存在zookeeper 。
切換機制： 首先要監控到 namenode 掛了，才能進行切換。如何知道掛掉了： 通過ZKFC RPC 調用監控namenode ，一旦namenode掛掉了，zookeeper 就會通知另外一個namenode 的zkfc 進程啓動 standby切換爲active，在切換之前會先殺掉之前的active（通過執行一個ssh遠程調用）。
2018.11.12
hive的4種排序方式
1.order by全局排序。全部數據劃分到一個reduce上。與sql中的order by類似，不同的是，hive中的order by在嚴格模式下，必須跟limit。
2.sort by 每個mapreduce內部排序。
3.distributed by分區排序，與sql中的group by類似，常與sort by組合使用，distributed by控制map的輸出在reduce中如何劃分，sort by控制reduce中的數據如何排序。hive要求distributed by語句出現在sort by語句之前。
4.cluster by，當distributed by與sort by字段相同，可以用cluster by代替該組合，但cluster by 不能跟desc，asc。補充：可以這樣書寫select a.* from (select * from test cluster by id ) a order by a.id ;
2018.11.13
hive調優方式
1.Fetch抓取：把不需要MR任務計算的查詢語句設置成不執行MR任務。三個參數，none表示禁用Fetch，所有查詢都執行MR任務；more在進行select/filter/limit查詢時不會運行MR任務；minimal在select/limit的時候不會運行MR任務，但是filter會運行MR任務。
hive.fetch.task.conversion
2.本地模式：讓輸入的數據量特別小的任務直接在本地節點上進行處理，而不提交到集羣。本地模式通過判斷文件的大小（默認128MB）和已輸入文件的個數（默認4個）來判斷是否在本地執行。
set hive.exec.mode.local.auto=true; //開啓本地 mr
set hive.exec.mode.local.auto.inputbytes.max=50000000;
set hive.exec.mode.local.auto.input.files.max=10;
3.表的優化：優化手段有join、行列過濾、分區、分桶、動態分區等等。
4.避免數據傾斜：通過合理設置map和reduce數、小文件合併等方式儘量保證負載均衡。或爲了避免因爲map或reduce任務卡死導致數據傾斜，通常也設置推測執行。
5.推測執行：爲了避免因爲程序的BUG/負載不均衡/資源分佈不均等原因導致同一作業中某一任務運行速度過慢，設置推測執行，爲該任務啓動一個備份任務，同時執行，最先運行完成的計算結果作爲最終結果。分爲map端和reduce端的推測執行。
set mapreduce.map.speculative=true
set mapreduce.reduce.speculative=true
6.並行執行：把沒有依賴關係的MR任務設置爲並行執行，提高多任務運行時的效率。
set hive.exec.parallel=true ; // 開啓任務並行執行
set hive.exec.parallel.thread.number=8; //默認值爲8個任務可以同時運行
7.嚴格模式：爲了防止一些不正常的查詢語句的執行。
hive.mapred.mode= strict
8.JVM重用：當有很多小文件的時候，每次運行MR任務都會開啓一個JVM進程，JVM頻繁的開啓關閉消耗大量的性能，所以在處理小文件的時候，可以設置JVM重用，讓一個JVM處理多個任務後再關閉。
mapreduce.job.jvm.numtasks
9.壓縮：通過壓縮對項目進行優化。例如開啓 map 輸出階段壓縮可以減少 job 中 map 和 Reduce task 間數據傳輸量。
10.執行計劃：Hive中提供的可以查看Hql語句的執行計劃，在執行計劃中會生成抽象語法樹，在語法樹中會顯示HQL語句之間的依賴關係以及執行過程。通過這些執行的過程和依賴可以對HQL語句進行優化。
2018.11.16
final、finally、finalize的區別
final
可以用來修飾類，方法和變量（成員變量或局部變量）。
用final修飾類：表明該類不能被其他類所繼承。final類中所有的成員方法都會隱式的定義爲final方法。
用final修飾方法：1.把方法鎖定，以防止繼承類對其進行更改。2.提高效率，在早期的java版本中，會將final方法轉爲內嵌調用。不過現在已經棄用。
final修飾變量：final成員變量表示常量，只能被賦值一次，賦值後其值不再改變。
finally
異常處理時“善後”的代碼：用於資源的釋放，比如多線程中鎖對象，流的釋放，數據庫的關閉等。
一般情況下finally都會執行。但特殊情況也可能不會執行：比如try沒有執行，或在finally之前執行system.exit(0)終止了java虛擬機的運行，或者在try-catch時線程中斷。
finalize
finalize()是在java.lang.Object裏定義的，也就是說每一個對象都有這麼個方法。這個方法在gc啓動，該對象被回收的時候被調用。
gc可以回收大部分的對象（凡是new出來的對象，gc都能搞定，一般情況下我們又不會用new以外的方式去創建對象），所以一般是不需要程序員去實現finalize的。
特殊情況下，需要程序員實現finalize，當對象被回收的時候釋放一些資源，比如：一個socket鏈接，在對象初始化時創建，整個生命週期內有效，那麼就需要實現finalize，關閉這個鏈接。
使用finalize還需要注意一個事，調用super.finalize();一個對象的finalize()方法只會被調用一次，而且finalize()被調用不意味着gc會立即回收該對象，所以有可能調用finalize()後，該對象又不需要被回收了，然後到了真正要被回收的時候，因爲前面調用過一次，所以不會調用finalize()，產生問題。 所以，推薦不要使用finalize()方法，它跟析構函數不一樣。
Hbase中的rowkey以及熱點問題
hbase熱點現象：
檢索hbase的記錄首先要通過rowkey來定義數據行，當大量的client訪問hbase集羣的一個或少數幾個節點，造成少數region server的讀/寫請求過多，負載過大，最終導致單個主機負載過大，引來性能下降甚至region不可用。
熱點產生原因：
有大量連續編號的rowkey，導致大量記錄集中在個別region。
避免熱點方法：
1.加鹽：在rowkey的前面增加隨機數。此方式適用於將hbase作爲海量存儲數據而不頻繁查詢的業務場景。
2.哈希：Hash散列，將數據打亂。
3.反轉：包括rowkey字段反轉和時間戳反轉。例如聯通就是這樣。時間戳加手機號20181123_13191***，引入一張索引表存儲以上字段，hbase中的rowkey則是以上字段的反轉。
rowkey設計原則：
1.rowkey唯一原則
2.rowkey長度原則：
二進制數，可以是任意字符，最多給到64kb，建議10-100個字節，但是越短越好，最好不要超過16個字節。
原因：
1）數據都是存在Hfile中按照key-value進行存儲的，如果rowkey超過了100個字節，1000萬條數據，100*1000萬=10億個字節，約爲1G，極大浪費Hfile的存儲資源。
2）memstore將緩存部分數據到內存，如果rowkey過大，內存的有效利用率就會降低，從而降低檢索效率。