判斷題：
1.如果 NameNode 意外終止，SecondaryNameNode 會接替它使集群繼續工作。（錯誤）
分析：
SecondaryNameNode是幫助恢復，而不是替代
SecondaryNameNode所做的不過是在文件系統中設置一個檢查點來幫助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的備份
首先，它定時到NameNode去獲取edit logs，並更新到fsimage上。[注：Secondary NameNode自己的fsimage]
一旦它有了新的fsimage文件，它將其拷貝回NameNode中。
NameNode在下次重啟時會使用這個新的fsimage文件，從而減少重啟的時間。
它的職責是合並NameNode的edit logs到fsimage文件中。
2. NameNode 負責管理 元數據（Metadata），client 端每次讀寫請求，它都會從磁盤中讀取或會寫入metadata信息並反饋client 端。(錯誤)
分析：
NameNode 不需要從磁盤讀取 metadata，所有數據都在內存中，硬盤上的只是序列化的結果，只有每次 namenode 啟動的時候才會讀取。
1)文件寫入
Client向NameNode發起文件寫入的請求。
NameNode根據文件大小和文件塊配置情況，返回給Client它所管理部分DataNode的信息。
Client將文件划分為多個Block，根據DataNode的地址信息，按順序寫入到每一個DataNode塊中。
2)文件讀取
Client向NameNode發起文件讀取的請求。
3.hadoop dfsadmin –report 命令用於檢測 HDFS 損壞塊。（錯誤）
分析：
hadoop dfsadmin -report
用這個命令可以快速定位出哪些節點down掉了，HDFS的容量以及使用了多少，以及每個節點的硬盤使用情況，但是並不能定位HDFS損壞塊。
4.Hadoop 環境變量中的 HADOOP_HEAPSIZE 用於設置所有 Hadoop 守護線程的內存。它默認是 200 GB。（錯誤）
hadoop為各個守護進程(namenode,secondarynamenode,jobtracker,datanode,tasktracker)統一分配的內存在hadoop-env.sh中設置，參數為HADOOP_HEAPSIZE，默認為1000M。
5.DataNode 首次加入 集群(cluster) 的時候，如果 log 中報告不兼容文件版本，那需要 NameNode執行“Hadoop namenode -format”操作格式化磁盤。（錯誤）
分析：
這個報錯是說明 DataNode 所裝的Hadoop版本和其它節點不一致，應該檢查DataNode的Hadoop版本
簡答題：
1.請列出你所知道的hadoop調度器，並且簡要說明其工作方法。
參考：https://www.cnblogs.com/skyl/p/4785681.html
hadoop調度器的作用是將系統中空閑的資源按一定策略分配給作業.
比較流行的三種調度器有：默認調度器FIFO，計算能力調度器Capacity Scheduler，公平調度器Fair Scheduler
1) 默認調度器FIFO
hadoop中默認的調度器，采用先進先出的原則
2) 計算能力調度器Capacity Scheduler
選擇占用資源小，優先級高的先執行
3) 公平調度器Fair Scheduler
同一隊列中的作業公平共享隊列中所有資源
2.Hive有哪些方式保存元數據，各有哪些特點
通俗的講，元數據就是存儲在Hive中的數據的描述信息。
Hive中的元數據通常包括：表的名字，表的列和分區及其屬性，表的屬性（內部表和 外部表），表的數據所在目錄。Hive元存儲（Metastore）管理參數默認儲存在自帶的Derby數據庫中。缺點就是不適合多用戶操作，並且數據存儲目錄不固定。數據庫和Hive所在的機器綁定，極度不方便管理。通常將元數據存儲在我們自己創建的MySQL數據庫（本地或遠程）當中。
元數據存儲兩種方法：
（1）derby數據庫
默認內存數據庫，一次只能打開一個會話，會話關閉metastore數據消失
（2）MySQL數據庫
外部metastore存儲引擎，可以讓多個會話使用
即:
自帶的Derby數據庫
本地RDBMS數據庫,即關系數據庫管理系統(Relational Database Management System), 如MySQL
遠程MySQL
26.flume介紹，采集日志時中間停了，怎么記錄之前的日志？
當節點出現故障時，日志能夠被傳送到其他節點上而不會丟失
事件在通道中進行，該通道管理從故障中恢復。Flume支持一個由本地文件系統支持的持久文件通道。還有一個內存通道，它只是將事件存儲在內存中的隊列中，這更快，但是當代理進程死亡時仍然留在內存通道中的任何事件都無法恢復。
a)Flume提供了三種級別的可靠性保障，從強到弱依次分別為
i.end-to-end（收到數據agent首先將event寫到磁盤上，當數據傳送成功后，再刪除；如果數據發送失敗，可以重新發送）
ii.Store on failure（這也是scribe采用的策略，當數據接收方crash時，將數據寫到本地，待恢復后，繼續發送）
iii.Best effort（數據發送到接收方后，不會進行確認）
27.Sqoop在導入數據到mysql中，如何讓數據不重復導入？如果存在數據問題sqoop如何處理？
答：增量導入。
指定--last-value
增量更新時指定增量或更新的鍵
在實際應用中還存在這樣一個問題，比如導入數據的時候，Map Task 執行失敗， 那么該 Map 任務會轉移到另外一個節點執行重新運行，這時候之前導入的數據又要重新導入一份，造成數據重復導入。 因為 Map Task 沒有回滾策略，一旦運行失敗，已經導入數據庫中的數據就無法恢復。
Sqoop export 提供了一種機制能保證原子性， 使用--staging-table 選項指定臨時導入的表。
Sqoop export 導出數據的時候會分為兩步：
第一步，將數據導入數據庫中的臨時表，如果導入期間 Map Task 失敗，會刪除臨時表數據重新導入；
第二步，確認所有 Map Task 任務成功后，會將臨時表名稱為指定的表名稱。
sqoop export \--connect jdbc:mysql://db.dajiangtai.net:3306/djtdb_hadoop \--username sqoop \--password sqoop \--table user \--staging-table staging_user