1、集群的最主要瓶頸是：磁盤IO
面對大數據，讀取數據需要經過IO，這里可以把IO理解為水的管道。管道越大越強，我們對於T級的數據讀取就越快。所以IO的好壞，直接影響了集群對於數據的處理。
下面詳細介紹IO
讀/寫IO
磁盤控制器向磁盤發出一次讀/寫指令，給出開始扇區的地址和向后連續讀/寫的扇區的個數。讀/寫IO是一次IO，操作的扇區編號必須是連續的，如過上層文件系統的IO請求是多個不連續的扇區，將會被磁盤控制器拆分成多個讀/寫IO來執行。（層次模型是理解一個系統最重要的思想，層次模型從底層到高層是一個化繁為簡的過程，低層模塊把復雜封裝，向上層提供簡易的使用接口；從高層到底層是一個逐層細分，逐層細化的過程。各層之間邏輯內聚，通過協議通訊降低耦合。文件系統層的一次IO會被磁盤存儲層拆分成多次IO執行，不同層次之間的一次IO概念是不同的。）
大/小塊IO
小塊IO：指一次讀/寫IO操作的連續扇區數目較小；
大塊IO： 指一次讀/寫IO操作的連續扇區數目較大；
大塊和小塊並沒有明確區分。
連續隨機IO
連續IO：指兩次不同的讀/寫IO，前一次的結束地址與后一次的起始地址相差不大；
隨機IO： 指兩次不同的讀/寫IO，前一次的結束地址與后一次的起始地址相差很大；
順序/並發IO
順序IO：指磁盤控制器必須在一次IO指令完成后才能進行下一個IO指令，指令的執行是順序的，同步的。對於單磁盤的存儲系統，所用的IO都是順序IO；
並發IO：並發IO是針對多磁盤的存儲系統而言的， 指磁盤控制器在發出一次IO指令后，檢查下一個IO指令，如果不是操作的磁盤不是正在進行的磁盤，就可以進行下一個IO指令，指令的執行是順序的，異步的。
持續/間斷IO
穩定/突發IO
實/虛IO
實IO：IO請求中包含對應實際數據的地址，讀/寫了扇區的數據；
虛IO：非實體數據的IO請求，只是請求一些狀態信息，元數據等；
IO並發幾率
書上的描述：單盤，IO並發幾率為0，因為一塊磁盤同時只可以進行一次IO。對於raid0，2塊盤情況下，條帶深度比較大的時候（條帶太小不能並發IO，下面會講到），並發2個IO的幾率為1/2。其他情況請自行運算。
個人理解：磁盤的IO並發是指磁盤控制器處理IO請求時是否能並發的執行，而不需要等待上一個IO請求執行結束再執行下一個IO請求。單盤的存儲系統肯定是不能並發處理IO的，多盤存儲系統在IO請求只占用了部分磁盤的時候能並發的處理IO請求。至於並發幾率是怎么算的還沒搞明白。
IOPS
設t=磁盤控制器完成一次IO所需要的時間。則t=尋道時間+旋轉延遲+數據傳輸時間；IOPS=IO並發系數/t. (IO並發系數暫時還沒有找到解釋，用the concurrent coefficient of IO去google也沒找到…）
每秒IO吞吐量
每秒處理IO的大小，等於IOPS*平均IOSIZE。而IOSIZE的大小與磁頭的讀寫速度有關。
參考鏈接：
https://www.aboutyun.com//forum.php/?mod=viewthread&tid=6874
https://www.aboutyun.com//forum.php/?mod=viewthread&tid=6802
2、Hadoop運行模式：
單機版：無需任何守護進程，所有的程序都運行在同一個JVM上執行。在獨立模式下調試MR程序非常高效方便。所以一般該模式主要是在學習或者開發階段調試使用 。
偽分布式模式：Hadoop守護進程運行在本地機器上，模擬一個小規模的集群，換句話說，可以配置一台機器的Hadoop集群,偽分布式是完全分布式的一個特例。
完全分布式模式：Hadoop守護進程運行在一個集群上。
3、Hadoop生態圈的組件並做簡要描述
1）Zookeeper：是一個開源的分布式應用程序協調服務,基於zookeeper可以實現同步服務，配置維護，命名服務。
2）Flume：一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸的系統。
3）Hbase：是一個分布式的、面向列的開源數據庫, 利用Hadoop HDFS作為其存儲系統。
4）Hive：基於Hadoop的一個數據倉庫工具，可以將結構化的數據檔映射為一張數據庫表，並提供簡單的sql 查詢功能，可以將sql語句轉換為MapReduce任務進行運行。
5）Sqoop：將一個關系型數據庫中的數據導進到Hadoop的 HDFS中，也可以將HDFS的數據導進到關系型數據庫中。
4、解釋“hadoop”和“hadoop 生態系統”兩個概念
Hadoop是指Hadoop框架本身；hadoop生態系統，不僅包含hadoop，還包括保證hadoop框架正常高效運行其他框架，比如zookeeper、Flume、Hbase、Hive、Sqoop等輔助框架。
5、 請列出正常工作的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文件.
6、 HDFS 中的 block 默認保存幾份？
默認保存3份
7、HDFS 默認 BlockSize 是多大？
從Hadoop 2.x 開始，默認128MB。
8、負責HDFS數據存儲的是哪一部分？
DataNode負責數據存儲
9、SecondaryNameNode的目的是什么？
它的目的使幫助NameNode合並編輯日志，減少NameNode 啟動時間
10、文件大小設置，增大有什么影響？
HDFS中的文件在物理上是分塊存儲（block），塊的大小可以通過配置參數( dfs.blocksize)來規定，默認大小在hadoop2.x版本中是128M，老版本中是64M。
思考：為什么塊的大小不能設置的太小，也不能設置的太大？
HDFS的塊比磁盤的塊大，其目的是為了最小化尋址開銷。如果塊設置得足夠大，從磁盤傳輸數據的時間會明顯大於定位這個塊開始位置所需的時間。因而，傳輸一個由多個塊組成的文件的時間取決於磁盤傳輸速率。
如果尋址時間約為10ms，而傳輸速率為100MB/s，為了使尋址時間僅占傳輸時間的1%，我們要將塊大小設置約為100MB。默認的塊大小128MB。
11、hadoop的塊大小，從哪個版本開始是128M？
Hadoop1.x都是64M，hadoop2.x開始都是128M。
12、HDFS的存儲機制（☆☆☆☆☆）
HDFS存儲機制，包括HDFS的寫入數據過程和讀取數據過程兩部分
HDFS寫數據過程
- 客戶端通過Distributed FileSystem模塊向NameNode請求上傳文件，NameNode檢查目標文件是否已存在，父目錄是否存在。
- NameNode返回是否可以上傳。
- 客戶端請求第一個 block上傳到哪幾個datanode服務器上。
- NameNode返回3個datanode節點，分別為dn1、dn2、dn3。
- 客戶端通過FSDataOutputStream模塊請求dn1上傳數據，dn1收到請求會繼續調用dn2，然后dn2調用dn3，將這個通信管道建立完成。
- dn1、dn2、dn3逐級應答客戶端。
- 客戶端開始往dn1上傳第一個block（先從磁盤讀取數據放到一個本地內存緩存），以packet為單位，dn1收到一個packet就會傳給dn2，dn2傳給dn3；dn1每傳一個packet會放入一個應答隊列等待應答。
- 當一個block傳輸完成之后，客戶端再次請求NameNode上傳第二個block的服務器。（重復執行3-7步）。
HDFS讀數據過程
- 客戶端通過Distributed FileSystem向NameNode請求下載文件，NameNode通過查詢元數據，找到文件塊所在的DataNode地址。
- 挑選一台DataNode（就近原則，然后隨機）服務器，請求讀取數據。
- DataNode開始傳輸數據給客戶端（從磁盤里面讀取數據輸入流，以packet為單位來做校驗）。
- 客戶端以packet為單位接收，先在本地緩存，然后寫入目標文件。
13、secondary namenode工作機制（☆☆☆☆☆）
1）第一階段：NameNode啟動
（1）第一次啟動NameNode格式化后，創建fsimage和edits文件。如果不是第一次啟動，直接加載編輯日志和鏡像文件到內存。
（2）客戶端對元數據進行增刪改的請求。
（3）NameNode記錄操作日志，更新滾動日志。
（4）NameNode在內存中對數據進行增刪改查。
2）第二階段：Secondary NameNode工作
（1）Secondary NameNode詢問NameNode是否需要checkpoint。直接帶回NameNode是否檢查結果。
（2）請求執行checkpoint。
（3）NameNode滾動正在寫的edits日志。
（4）先將滾動前的編輯日志和鏡像文件拷貝到Secondary NameNode。
（5）Secondary NameNode加載編輯日志和鏡像文件到內存，並合並。
（6）生成新的鏡像文件fsimage.chkpoint。
（7）拷貝fsimage.chkpoint到NameNode。
（8）NameNode將fsimage.chkpoint重新命名成fsimage。
14、NameNode與SecondaryNameNode 的區別與聯系？（☆☆☆☆☆）
區別：
（1）NameNode負責管理整個文件系統的元數據，以及每一個路徑（文件）所對應的數據塊信息。
（2）SecondaryNameNode主要用於定期合並命名空間鏡像和命名空間鏡像的編輯日志。
聯系：
（1）SecondaryNameNode中保存了一份和namenode一致的鏡像文件（fsimage）和編輯日志（edits）。
（2）在主namenode發生故障時（假設沒有及時備份數據），可以從SecondaryNameNode恢復數據。
15、HDFS組成架構（☆☆☆☆☆）
架構主要由四個部分組成，分別為HDFS Client、NameNode、DataNode和Secondary NameNode。下面我們分別介紹這四個組成部分。
1）Client：就是客戶端。
（1）文件切分。文件上傳HDFS的時候，Client將文件切分成一個一個的Block，然后進行存儲；
（2）與NameNode交互，獲取文件的位置信息；
（3）與DataNode交互，讀取或者寫入數據；
（4）Client提供一些命令來管理HDFS，比如啟動或者關閉HDFS；
（5）Client可以通過一些命令來訪問HDFS；
2）NameNode：就是Master，它是一個主管、管理者。
（1）管理HDFS的名稱空間；
（2）管理數據塊（Block）映射信息；
（3）配置副本策略；
（4）處理客戶端讀寫請求。
3） DataNode：就是Slave。NameNode下達命令，DataNode執行實際的操作。
（1）存儲實際的數據塊；
（2）執行數據塊的讀/寫操作。
4） Secondary NameNode：並非NameNode的熱備。當NameNode掛掉的時候，它並不能馬上替換NameNode並提供服務。
（1）輔助NameNode，分擔其工作量；
（2）定期合並Fsimage和Edits，並推送給NameNode；
（3）在緊急情況下，可輔助恢復NameNode。
16、HAnamenode如何工作? （☆☆☆☆☆）
ZKFailoverController主要職責
1）健康監測：周期性的向它監控的NN發送健康探測命令，從而來確定某個NameNode是否處於健康狀態，如果機器宕機，心跳失敗，那么zkfc就會標記它處於一個不健康的狀態。
2）會話管理：如果NN是健康的，zkfc就會在zookeeper中保持一個打開的會話，如果NameNode同時還是Active狀態的，那么zkfc還會在Zookeeper中占有一個類型為短暫類型的znode，當這個NN掛掉時，這個znode將會被刪除，然后備用的NN，將會得到這把鎖，升級為主NN，同時標記狀態為Active。
3）當宕機的NN新啟動時，它會再次注冊zookeper，發現已經有znode鎖了，便會自動變為Standby狀態，如此往復循環，保證高可靠，需要注意，目前僅僅支持最多配置2個NN。
4）master選舉：如上所述，通過在zookeeper中維持一個短暫類型的znode，來實現搶占式的鎖機制，從而判斷那個NameNode為Active狀態