2.23. 我們開發job時，是否可以去掉reduce階段。
可以。設置reduce數為0 即可。
2.24. datanode在什么情況下不會備份
datanode在強制關閉或者非正常斷電不會備份。
2.25. combiner出現在那個過程
出現在map階段的map方法后等。
2.26. hdfs的體系結構
hdfs有namenode、secondraynamenode、datanode組成。
為n+1模式
namenode負責管理datanode和記錄元數據
secondraynamenode負責合並日志
datanode負責存儲數據
2.27. 3個datanode中有一個datanode出現錯誤會怎樣？
這個datanode的數據會在其他的datanode上重新做備份。
2.28. 描述一下hadoop中，有哪些地方使用了緩存機制，作用分別是什么？
在mapreduce提交job的獲取id之后，會將所有文件存儲到分布式緩存上，這樣文件可以被所有的mapreduce共享。
2.29. 如何確定hadoop集群的健康狀態
通過頁面監控,腳本監控。
2.30.生產環境中為什么建議使用外部表？
1、因為外部表不會加載數據到hive，減少數據傳輸、數據還能共享。
2、hive不會修改數據，所以無需擔心數據的損壞
3、刪除表時，只刪除表結構、不刪除數據。
3.15期新增
3.1.新增
1）hadoop的核心配置文件名稱是什么？
core-site.xml
2）“jps”命令的用處？
jps位於jdk的bin目錄下，其作用是顯示當前系統的java進程情況，及其id號。 jps相當於Solaris進程工具ps。不象”pgrep java”
或”ps -ef grep java”，jps並不使用應用程序名來查找JVM實例。因此，它查找所有的Java應用程序，包括即使沒有使用java執行
體的那種（例如，定制的啟動 器）。另外，jps僅查找當前用戶的Java進程，而不是當前系統中的所有進程。
3）如何檢查namenode是否正常運行？重啟namenode的命令是什么？
通過節點信息和瀏覽器查看，通過腳本監控
hadoop-daemon.sh start namenode
hdfs-daemon.sh start namenode
4）避免namenode故障導致集群宕機的解決方法是什么？
自己書寫腳本監控重啟
5）hbase數據庫對行鍵的設計要求是什么？
行健以字典序排列，設計時充分利用這個特點，將經常一起查詢的行健設計在一起，例如時間戳結尾，用戶名開頭（位置相關性）
6）請給出你的設計方案，比如使用哪些技術框架，該框架起到的作用等。
1、用hive分析業務數據即可
2、將數據導入到hive中
sql的設計思路：多表關聯
1、找到所有在2015-01-01到2015-01-31時間內訪問A頁面的用戶
2、在這些用戶中刪選在2015-01-01到2015-03-31下單的用戶
3、統計總數
3.2. 你們數據庫怎么導入hive 的,有沒有出現問題
在導入hive的時候，如果數據庫中有blob或者text字段，會報錯，解決方案在sqoop筆記中
在將數據由Oracle數據庫導入到Hive時，發現帶有clob字段的表的數據會錯亂，出現一些字段全為NULL的空行。
由於在項目中CLOB字段沒有實際的分析用途，因此考慮將CLOB字段去掉。
同時，為了防止CLOB字段產生一些問題，因此將HIVE中CLOB字段禁用，禁用的方式如下：
[Hadoop@master sqoop-1.4.5]cdcdSQOOP_HOME/conf
[hadoop@master conf]$ vi oraoop-site.xml
將以下屬性的注釋去掉，並且將value改為true
oraoop.import.omit.lobs.and.long
true
If true, OraOop will omit BLOB, CLOB, NCLOB and LONG columns during an Import.
有些表中雖然有clob字段，但是不能排除掉，因為其他字段使我們所需要，因此在導入的時候采用指定–columns的方式來進行導入
sqoop import –hive-import –hive-database test –create-hive-table –connect jdbc –username user–password user
–bindir //scratch –outdir /Java –table aaa –columns “ID,NAME” -m 1 –null-string ‘\N’ –null-non-string ‘\N’
3.3. 公司技術選型可能利用storm 進行實時計算,講解一下storm
描述下storm的設計模式，是基於work、excutor、task的方式運行代碼，由spout、bolt組成等等
3.4. 一個datanode 宕機,怎么一個流程恢復
將datanode數據刪除，重新當成新節點加入即可。
3.5. Hbase 的特性,以及你怎么去設計 rowkey 和 columnFamily ,怎么去建一個table
hbase是列式數據庫，rowkey是字典序的，設計時的規則同上。
每個列族是一個文件，將經常一起查詢的列放到同一個列族中，減少文件的尋址時間。
3.6. Redis,傳統數據庫,hbase,hive 每個之間的區別
redis：分布式緩存，強調緩存，內存中數據
傳統數據庫：注重關系
hbase：列式數據庫，無法做關系數據庫的主外鍵，用於存儲海量數據，底層基於hdfs
hive：數據倉庫工具，底層是mapreduce。不是數據庫，不能用來做用戶的交互存儲
3.7. shuffle 階段,你怎么理解的
shuffle過程包括在Map和Reduce兩端中。
在Map端的shuffle過程是對Map的結果進行分區（partition）、排序（sort）和分割（spill），然后將屬於同一個划分的輸出合並在一起
（merge）並寫在硬盤上，同時按照不同的划分將結果發送給對應的Reduce（Map輸出的划分與Reduce的對應關系由JobTracker確定）。
Reduce端又會將各個Map送來的屬於同一個划分的輸出進行合並（merge），然后對merge的結果進行排序，最后交給Reduce處理。通俗的講，
就是對Map輸出結果先進行分區（partition），如“aaa”經過Partitioner后返回0，也就是這對值應當交由第一個reducer來處理。接下來，
需要將數據寫入內存緩沖區中，緩沖區的作用是批量收集map結果，減少磁盤IO的影響。我們的key/value對以及Partition的結果都會被寫
入緩沖區。當然寫入之前，key與value值都會被序列化成字節數組。這個內存緩沖區是有大小限制的，默認是100MB。當map task的輸出結果
很多時，需要在一定條件下將緩沖區中的數據臨時寫入磁盤，然后重新利用這塊緩沖區。這個從內存往磁盤寫數據的過程被稱為Spill。
Spill可以認為是一個包括Sort和Combiner（Combiner是可選的，用戶如果定義就有）的過程。先進行sort可以把緩沖區中一段范圍key的數
據排在一起，（如果數據多的時候，多次刷新往內存緩沖區中寫入的數據可能會有屬於相同范圍的key，也就是說，多個spill文件中可能會
有統一范圍的key，這就是需要下面Map端merge的原因），這里有點繞，具體的介紹可以看下面的詳細過程，執行過sort之后，如果用戶定義
了combiner就會執行combine，然后執行merge操作，接着就是Reduce端。
3.8. Mapreduce 的 map 數量 和 reduce 數量 怎么確定 ,怎么配置
map的數量由數據塊決定，reduce數量隨便配置。
3.9. 唯一難住我的是他說實時計算,storm 如果碰上了復雜邏輯,需要算很長的時間,你怎么去優化,怎么保證實時性
3.10. Hive 你們用的是外部表還是內部表,有沒有寫過UDF,hive 的版本
3.11. Hadoop 的版本
1.04、1.20都為穩定版，是兩個常用的hadoop1版本。
3.12. 實時流式計算 的結果內容有哪些,你們需要統計出來么
3.13.
1）設計日志收集分析系統
日志分布在各個業務系統中，我們需要對當天的日志進行實時匯總統計，同時又能按天查詢歷史的匯總數據（可以圍繞PV、UV、IP等
指標進行闡述）
1、通過flume將不同系統的日志收集到kafka中
2、通過storm實時的處理PV、UV、IP
3、通過kafka的consumer將日志生產到hbase中。
4、通過離線的mapreduce或者hive，處理hbase中的數據
2）如果你來做技術分享，你會選擇什么主題，課程安排是什么樣的？
大體分為3個部分:
1、離線hadoop技術分享（mapreduce、hive）
2、nosql數據庫hbase分享
3、實時流計算分享
5）Hive語句實現WordCount。
假設數據存放在hadoop下，路徑為：/home/hadoop/worddata里面全是一些單詞
1、建表
2、分組（group by）統計wordcount
select word,count(1) from table1 group by word;
6）給定a、b兩個文件，各存放50億個url，每個url各占64字節，內存限制是4G，找出a、b文件共同的url？
可以估計每個文件的大小為50億×64=298G，遠遠大於內存限制的4G。所以不可能將其完全加載到內存中處理。考慮采取分而治之的方法。
1、將文件存儲到hdfs中，這樣每個文件為64M或者是128M
2、分別對兩個文件的url進行去重、排序輸出，這樣能排除a文件中相同的url，b文件也一樣
3、對a、b兩個文件處理后的結果進行wordcount，並且在reduce中判斷單詞個數，個數為2的時候輸出，這樣就找到了a、b文件中的相同url。
4、此計算步驟中的每一步加載到內存中的文件大小都不會超過64M，遠遠小於4G。
7）一億個數據獲取前100個最大值（步驟及算法復雜度）
兩種思路：
1. 根據快速排序划分的思想
a. 假設數組為 array[N] (N = 1 億)，首先利用quicksort的原理把array分成兩個部分，左邊部分比 array[N - 1] (array中的最后一個值，
即pivot) 大， 右邊部分比pivot 小。然后，可以得到 array[array.length - 1] (即 pivot) 在整個數組中的位置，假設是 k.
b. 如果 k 比 99 大，我們在數組[0, k - 1]里找前 100 最大值。 （繼續遞歸）
c. 如果 k 比 99 小， 我們在數組[k + 1, …, N ]里找前 100 - (k + 1) 最大值。（繼續遞歸）
d. 如果 k == 99, 那么數組的前 100 個值一定是最大的。（退出）
2.先取出前100個數，維護一個100個數的最小堆，遍歷一遍剩余的元素，在此過程中維護堆就可以了。具體步驟如下：
step1：取前m個元素（例如m=100），建立一個小頂堆。保持一個小頂堆得性質的步驟，運行時間為O（lgm);建立一個小頂堆運行時間為m*O（lgm）=O(m lgm);
step2:順序讀取后續元素，直到結束。每次讀取一個元素，如果該元素比堆頂元素小，直接丟棄
如果大於堆頂元素，則用該元素替換堆頂元素，然后保持最小堆性質。最壞情況是每次都需要替換掉堆頂的最小元素，因此需要維護堆的代價為(N-m)*O(lgm);
最后這個堆中的元素就是前最大的10W個。時間復雜度為O(N lgm）。
兩種思路比較：
基於最小堆方法運行時間很穩定（每次運行時間相差很小），基於quicksort原理的方法運行時間不穩定（每次運行時間相差大）。
Random rand = new Random(); PriorityQueue P = new PriorityQueue(); for(int i = 0,num = rand.nextInt(); (i < 100 && P.add(num)) || (i < 100000000 && (P.peek() < num && P.add(num) && P.remove() != null || 1==1));
i++,num = rand.nextInt()); //System.out.println(P);
top K問題
在大規模數據處理中，經常會遇到的一類問題：在海量數據中找出出現頻率最好的前k個數，或者從海量數據中找出最大的前k個數，這類問題通常被稱為top K問題。例如，在搜索引擎中，
統計搜索最熱門的10個查詢詞；在歌曲庫中統計下載最高的前10首歌等。
針對top K類問題，通常比較好的方案是分治+Trie樹/hash+小頂堆（就是上面提到的最小堆），即先將數據集按照Hash方法分解成多個小數據集，
然后使用Trie樹活着Hash統計每個小數據集中的query詞頻，之后用小頂堆求出每個數據集中出現頻率最高的前K個數，最后在所有top K中求出最終的top K。
eg：有1億個浮點數，如果找出期中最大的10000個？
最容易想到的方法是將數據全部排序，然后在排序后的集合中進行查找，最快的排序算法的時間復雜度一般為O（nlogn），如快速排序。但是在32位的機器上，
每個float類型占4個字節，1億個浮點數就要占用400MB的存儲空間，對於一些可用內存小於400M的計算機而言，很顯然是不能一次將全部數據讀入內存進行排序的。
其實即使內存能夠滿足要求（我機器內存都是8GB），該方法也並不高效，因為題目的目的是尋找出最大的10000個數即可，而排序卻是將所有的元素都排序了，做了很多的無用功。
第二種方法為局部淘汰法，該方法與排序方法類似，用一個容器保存前10000個數，然后將剩余的所有數字——與容器內的最小數字相比，如果所有后續的元素都比容器內的10000個數還小，
那么容器內這個10000個數就是最大10000個數。如果某一后續元素比容器內最小數字大，則刪掉容器內最小元素，並將該元素插入容器，最后遍歷完這1億個數，
得到的結果容器中保存的數即為最終結果了。此時的時間復雜度為O（n+m^2），其中m為容器的大小，即10000。
第三種方法是分治法，將1億個數據分成100份，每份100萬個數據，找到每份數據中最大的10000個，最后在剩下的100*10000個數據里面找出最大的10000個。如果100萬數據選擇足夠理想，
那么可以過濾掉1億數據里面99%的數據。100萬個數據里面查找最大的10000個數據的方法如下：用快速排序的方法，將數據分為2堆，如果大的那堆個數N大於10000個，
繼續對大堆快速排序一次分成2堆，如果大的那堆個數N大於10000個，繼續對大堆快速排序一次分成2堆，如果大堆個數N小於10000個，就在小的那堆里面快速排序一次，找第10000-n大的數字；
遞歸以上過程，就可以找到第1w大的數。參考上面的找出第1w大數字，就可以類似的方法找到前10000大數字了。此種方法需要每次的內存空間為10^6*4=4MB，一共需要101次這樣的比較。
第四種方法是Hash法。如果這1億個書里面有很多重復的數，先通過Hash法，把這1億個數字去重復，這樣如果重復率很高的話，會減少很大的內存用量，從而縮小運算空間，
然后通過分治法或最小堆法查找最大的10000個數。
第五種方法采用最小堆。首先讀入前10000個數來創建大小為10000的最小堆，建堆的時間復雜度為O（mlogm）（m為數組的大小即為10000），然后遍歷后續的數字，並於堆頂（最小）
數字進行比較。如果比最小的數小，則繼續讀取后續數字；如果比堆頂數字大，則替換堆頂元素並重新調整堆為最小堆。整個過程直至1億個數全部遍歷完為止。然后按照中序遍歷的方式輸出當前
堆中的所有10000個數字。該算法的時間復雜度為O（nmlogm），空間復雜度是10000（常數）。
實際運行：
實際上，最優的解決方案應該是最符合實際設計需求的方案，在時間應用中，可能有足夠大的內存，那么直接將數據扔到內存中一次性處理即可，也可能機器有多個核，這樣可以采用
多線程處理整個數據集。
下面針對不容的應用場景，分析了適合相應應用場景的解決方案。
（1）單機+單核+足夠大內存
如果需要查找10億個查詢次（每個占8B）中出現頻率最高的10個，考慮到每個查詢詞占8B，則10億個查詢次所需的內存大約是10^9 * 8B=8GB內存。如果有這么大內存，直接在內存中對
查詢次進行排序，順序遍歷找出10個出現頻率最大的即可。這種方法簡單快速，使用。然后，也可以先用HashMap求出每個詞出現的頻率，然后求出頻率最大的10個詞。
（2）單機+多核+足夠大內存
這時可以直接在內存總使用Hash方法將數據划分成n個partition，每個partition交給一個線程處理，線程的處理邏輯同（1）類似，最后一個線程將結果歸並。
該方法存在一個瓶頸會明顯影響效率，即數據傾斜。每個線程的處理速度可能不同，快的線程需要等待慢的線程，最終的處理速度取決於慢的線程。而針對此問題，解決的方法是，
將數據划分成c×n個partition（c>1），每個線程處理完當前partition后主動取下一個partition繼續處理，知道所有數據處理完畢，最后由一個線程進行歸並。
（3）單機+單核+受限內存
這種情況下，需要將原數據文件切割成一個一個小文件，如次啊用hash(x)%M，將原文件中的數據切割成M小文件，如果小文件仍大於內存大小，繼續采用Hash的方法對數據文件進行分割，
知道每個小文件小於內存大小，這樣每個文件可放到內存中處理。采用（1）的方法依次處理每個小文件。
（4）多機+受限內存
這種情況，為了合理利用多台機器的資源，可將數據分發到多台機器上，每台機器采用（3）中的策略解決本地的數據。可采用hash+socket方法進行數據分發。
從實際應用的角度考慮，（1）（2）（3）（4）方案並不可行，因為在大規模數據處理環境下，作業效率並不是首要考慮的問題，算法的擴展性和容錯性才是首要考慮的。
算法應該具有良好的擴展性，以便數據量進一步加大（隨着業務的發展，數據量加大是必然的）時，在不修改算法框架的前提下，可達到近似的線性比；算法應該具有容錯性，
即當前某個文件處理失敗后，能自動將其交給另外一個線程繼續處理，而不是從頭開始處理。
top K問題很適合采用MapReduce框架解決，用戶只需編寫一個Map函數和兩個Reduce 函數，然后提交到Hadoop（采用Mapchain和Reducechain）上即可解決該問題。
具體而言，就是首先根據數據值或者把數據hash(MD5)后的值按照范圍划分到不同的機器上，最好可以讓數據划分后一次讀入內存，這樣不同的機器負責處理不同的數值范圍，
實際上就是Map。得到結果后，各個機器只需拿出各自出現次數最多的前N個數據，然后匯總，選出所有的數據中出現次數最多的前N個數據，這實際上就是Reduce過程。
對於Map函數，采用Hash算法，將Hash值相同的數據交給同一個Reduce task；對於第一個Reduce函數，采用HashMap統計出每個詞出現的頻率，對於第二個Reduce 函數，統計所有Reduce task，
輸出數據中的top K即可。
直接將數據均分到不同的機器上進行處理是無法得到正確的結果的。因為一個數據可能被均分到不同的機器上，而另一個則可能完全聚集到一個機器上，同時還可能存在具有相同數目的數據。
以下是一些經常被提及的該類問題。
（1）有10000000個記錄，這些查詢串的重復度比較高，如果除去重復后，不超過3000000個。一個查詢串的重復度越高，說明查詢它的用戶越多，也就是越熱門。請統計最熱門的10個查詢串，
要求使用的內存不能超過1GB。
（2）有10個文件，每個文件1GB，每個文件的每一行存放的都是用戶的query，每個文件的query都可能重復。按照query的頻度排序。
（3）有一個1GB大小的文件，里面的每一行是一個詞，詞的大小不超過16個字節，內存限制大小是1MB。返回頻數最高的100個詞。
（4）提取某日訪問網站次數最多的那個IP。
（5）10億個整數找出重復次數最多的100個整數。
（6）搜索的輸入信息是一個字符串，統計300萬條輸入信息中最熱門的前10條，每次輸入的一個字符串為不超過255B，內存使用只有1GB。
（7）有1000萬個身份證號以及他們對應的數據，身份證號可能重復，找出出現次數最多的身份證號。
重復問題
在海量數據中查找出重復出現的元素或者去除重復出現的元素也是常考的問題。針對此類問題，一般可以通過位圖法實現。例如，已知某個文件內包含一些電話號碼，每個號碼為8位數字，
統計不同號碼的個數。
本題最好的解決方法是通過使用位圖法來實現。8位整數可以表示的最大十進制數值為99999999。如果每個數字對應於位圖中一個bit位，那么存儲8位整數大約需要99MB。因為1B=8bit，
所以99Mbit折合成內存為99/8=12.375MB的內存，即可以只用12.375MB的內存表示所有的8位數電話號碼的內容。
8）實時數據統計會用到哪些技術，它們各自的應用場景及區別是什么？
flume：日志收集系統，主要用於系統日志的收集
kafka：消息隊列，進行消息的緩存和系統的解耦
storm：實時計算框架，進行流式的計算。
1）String和StringBuffer的區別，StringBuffer與StringBuilder的區別
簡單地說，就是一個變量和常量的關系。StringBuffer對象的內容可以修改；而String對象一旦產生后就不可以被修改，重新賦值其實是兩個對象。
StringBuilder：線程非安全的
StringBuffer：線程安全的
當我們在字符串緩沖去被多個線程使用是，JVM不能保證StringBuilder的操作是安全的，雖然他的速度最快，但是可以保證StringBuffer是可以正確操作的。
當然大多數情況下就是我們是在單線程下進行的操作，所以大多數情況下是建議用StringBuilder而不用StringBuffer的，就是速度的原因。