A.NameNodehtml
B.JobTrackerjava
C.DataNodenode
D.SecondaryNameNodelinux
E.tasktracker程序員
A.3 份web
B.2 份算法
C.1 份sql
D.不肯定數據庫
A.SecondaryNameNodeapache
B.DataNode
C.TaskTracker
D.JobTracker
hadoop的集羣是基於master/slave模式，namenode和jobtracker屬於master，datanode和tasktracker屬於slave，master只有一個，而slave有多個. SecondaryNameNode內存需求和NameNode在一個數量級上，因此一般secondary NameNode（運行在單獨的物理機器上）和 NameNode 運行在不一樣的機器上。 JobTracker對應於NameNode,TaskTracker對應於DataNode. DataNode和NameNode是針對數據存放來而言的.JobTracker和TaskTracker是對於MapReduce執行而言的. mapreduce中幾個主要概念，mapreduce 總體上能夠分爲這麼幾條執行線索： jobclient，JobTracker與TaskTracker。 一、JobClient會在用戶端經過JobClient類將已經配置參數打包成jar文件的應用存儲到hdfs，並把路徑提交到Jobtracker,而後由JobTracker建立每個Task（即 MapTask 和 ReduceTask） 並將它們分發到各個TaskTracker服務中去執行。 二、JobTracker是一master服務，軟件啓動以後JobTracker接收Job，負責調度Job的每個子任務。task運行於TaskTracker上，並監控它們，若是發現有失敗的task就從新運行它。通常狀況應該把JobTracker 部署在單獨的機器上。 三、TaskTracker是運行在多個節點上的slaver服務。TaskTracker主動與JobTracker通訊，接收做業，並負責直接執行每個任務。 TaskTracker 都須要運行在HDFS的DataNode上。
A.它是 NameNode 的熱備
B.它是內存沒有要求
C.他的目的使幫助 NameNode 合併編輯日誌，減小 NameNode 啓動時間
D. SecondaryNameNode 應與 NameNode 部署到一個節點
A.32MB
B.64MB
C.128MB
注 : Hadoop在1.X版本中塊的大小默認64M,在hadoop2.X版本中,默認128M
A.CPU
B.網絡
C.磁盤 IO
D.內存
A.Puppet
B.Pdsh
C.ClouderaManager
D.Zookeeper
A.數據通過 NameNode 傳遞 DataNode
B.Client 端將文件切分爲 Block，依次上傳
C.Client 只上傳數據到一臺 DataNode，而後由 NameNode 負責 Block 複製工做
A.單機版
B.僞分佈式
C.分佈式
A、 TextInputFormat
B、 KeyValueInputFormat
C、 SequenceFileInputFormat
Zookeeper:是一個開源的分佈式應用程序協調服務,基於zookeeper能夠實現同步服務，配置維護，命名服務。
Flume:一個高可用的，高可靠的，分佈式的海量日誌採集、聚合和傳輸的系統。
Hbase:是一個分佈式的、面向列的開源數據庫, 利用Hadoop HDFS做爲其存儲系統.
Hive:基於Hadoop的一個數據倉庫工具，能夠將結構化的數據檔映射爲一張數據庫表，並提供簡單的sql 查詢功能，能夠將sql語句轉換爲MapReduce任務進行運行。
Sqoop:將一個關係型數據庫中的數據導進到Hadoop的 HDFS中，也能夠將HDFS的數據導進到關係型數據庫中。
1>.Core-site.xml：
(1)fs.defaultFS:hdfs://cluster1(域名)，這裏的值指的是默認的HDFS路徑 。
(2)hadoop.tmp.dir:/export/data/hadoop_tmp,這裏的路徑默認是NameNode、DataNode、JournalNode等存放數據的公共目錄。用戶也能夠本身單獨指定這三類節點的目錄。
(3)ha.zookeeper.quorum:hadoop101:2181,hadoop102:2181,hadoop103:2181,這裏是ZooKeeper集羣的地址和端口。注意，數量必定是奇數，且很多於三個節點 。
2>.Hadoop-env.sh: 只需設置jdk的安裝路徑，如：export JAVA_HOME=/usr/local/jdk 本機j位置
3>.Hdfs-site.xml：
(1) dfs.replication:他決定着系統裏面的文件塊的數據備份個數，默認爲3個。
(2) dfs.data.dir:datanode節點存儲在文件系統的目錄 。
(3) dfs.name.dir:是namenode節點存儲hadoop文件系統信息的本地系統路徑 。
4>.Mapred-site.xml：
(1)mapred.job.tracker:是jobtracker的主機和端口配置 。
a) NameNode它是hadoop中的主服務器，管理文件系統名稱空間和對集羣中存儲的文件的訪問，保存有 metadate.
b).SecondaryNameNode它不是namenode的冗餘守護進程，而是提供週期檢查點和清理任務。幫助NN合併editslog，減小NN啓動時間。
c)DataNode它負責管理鏈接到節點的存儲（一個集羣中能夠有多個節點）。每一個存
儲數據的節點運行一個datanode守護進程。
d)ResourceManager（JobTracker）JobTracker負責調度DataNode上的工做。每一個DataNode有一個TaskTracker，它們執行實際工做。
e) NodeManager（TaskTracker）執行任務
f) DFSZKFailoverController高可用時它負責監控NN的狀態，並及時的把狀態信息寫入ZK。它經過一個獨立線程週期性的調用NN上的一個特定接口來獲取NN的健康狀態。FC也有選擇誰做爲Active NN的權利，由於最多隻有兩個節點，目前選擇策略還比較簡單（先到先得，輪換）。
g) JournalNode 高可用狀況下存放namenode的editlog文件.
寫入HDFS過程：
Client調用DistributedFileSystem對象的create方法，建立一個文件輸出流（FSDataOutputStream）對象，經過DistributedFileSystem對象與Hadoop集羣的NameNode進行一次RPC遠程調用，在HDFS的Namespace中建立一個文件條目（Entry），該條目沒有任何的Block，經過FSDataOutputStream對象，向DataNode寫入數據，數據首先被寫入FSDataOutputStream對象內部的Buffer中，而後數據被分割成一個個Packet數據包，以Packet最小單位，基於Socket鏈接發送到按特定算法選擇的HDFS集羣中一組DataNode（正常是3個，可能大於等於1）中的一個節點上，在這組DataNode組成的 Pipeline上依次傳輸 Packet， 這組 DataNode 組成的 Pipeline反方向上，發送 ack，最終由 Pipeline 中第一個 DataNode 節點將 Pipeline ack發送給Client，完成向文件寫入數據，Client 在文件輸出流（FSDataOutputStream）對象上調用close方法，關閉流.調用DistributedFileSystem對象的complete 方法，通知 NameNode 文件寫入成功.
讀取文件過程：
使用HDFS提供的客戶端開發庫Client，向遠程的Namenode發起RPC請求；Namenode會視狀況返回文件的部分或所有block列表，對於每一個block，Namenode都會返回有該block拷貝的DataNode地址；客戶端開發庫Client會選取離客戶端最接近的DataNode來讀取block；若是客戶端自己就是DataNode,那麼將從本地直接獲取數據.讀取完當前block的數據後，關閉與當前的DataNode鏈接，併爲讀取下一個block尋找最佳的DataNode；當讀完列表的block後，且文件讀取尚未結束，客戶端開發庫會繼續向Namenode獲取下一批的block列表。讀取完一個block都會進行 checksum 驗證，若是讀取 datanode 時出現錯誤，客戶端會通知 Namenode，而後再從下一個擁有該 block 拷貝的 datanode 繼續讀。
hadoop 是一套處理大數據的生態系統，包括文件存儲HDFS ，計算框架MapReduce調度框架Yarn，數據庫Hbase ，數據倉庫Hive，協調與鎖服務zookeeper，關係型數 據庫與Hbase轉換工具sqoop，工做流模塊Oozie,機器學習模塊mahout.
客戶端經過把請求發送給NameNode active，NN會把文件切成1個到N個固定大小的block（通常默認爲128M）並上傳到DN中。當全部block拷貝結束時，NN會當即通知客戶端上傳結果。但此時上傳的流程還未結束。DN還須要根據配置信息的副本數量，在不一樣的機架節點上經過局域網做數據拷貝工做。
節點上線操做：
當要新上線數據節點的時候，須要把數據節點的名字追加在 dfs.hosts 文件中
一，關閉新增節點的防火牆
二，在 NameNode 節點的 hosts 文件中加入新增數據節點的 hostname
三，在每一個新增數據節點的 hosts 文件中加入 NameNode 的 hostname
四，在 NameNode 節點上增長新增節點的 SSH 免密碼登陸的操做
五，在 NameNode 節點上的 dfs.hosts 中追加上新增節點的 hostname,
六，在其餘節點上執行刷新操做：hdfs dfsadmin -refreshNodes
七，在 NameNode 節點上，更改 slaves 文件，將要上線的數據節點 hostname 追加
到 slaves 文件中
八，啓動 DataNode 節點
九，查看 NameNode 的監控頁面看是否有新增長的節點
節點下線操做：
一，修改/conf/hdfs-site.xml 文件
二，肯定須要下線的機器，dfs.osts.exclude 文件中配置好須要下架的機器，這個是阻
止下架的機器去鏈接 NameNode
三，配置完成以後進行配置的刷新操做./bin/hadoop dfsadmin -refreshNodes,這個
操做的做用是在後臺進行 block 塊的移動
四，當執行三的命令完成以後，須要下架的機器就能夠關閉了，能夠查看如今集
羣上鍊接的節點，正在執行 Decommission，會顯示：
Decommission Status : Decommission in progress 執行完畢後，會顯示：
Decommission Status : Decommissioned
五，機器下線完畢，將他們從 excludes 文件中移除。
JobTracker 是一個 master 服務，軟件啓動以後 JobTracker 接收 Job，負責調度 Job的每個子任務 task 運行於 TaskTracker 上，並監控它們，若是發現有失敗的 task 就從新運行它。通常狀況應該把 JobTracker 部署在單獨的機器上。
TaskTracker 是運行在多個節點上的 slaver 服務。TaskTracker 主動與 JobTracker 通訊，接收做業，並負責直接執行每個任務
推測執行機制是 Hadoop 對「拖後腿」的任務的一種優化機制，當一個做業的某些任務運行速度明顯慢於同做業的其餘任務時，Hadoop 會在另外一個節點 上爲「慢任務」啓動一個備份任務，這樣兩個任務同時處理一份數據，而 Hadoop 最終會將優先完成的那個任務的結果做爲最終結果，並將另外一個任務殺掉
鏈接jobtrack服務器的配置項，默認不寫是local，在本地運行，默認 map 數1，reduce數1。
splitSize=max{minSize,min{maxSize,blockSize}}
map數量由處理的數據分紅的block數量決定default_num = total_size / split_size;
reduce的數量job.setNumReduceTasks(x);x 爲reduce的數量
具體的數據分片是這樣的，InputFormat在默認狀況下會根據hadoop集羣HDFS塊大小進行分片，每個分片會由一個map任務來進行處理，固然用戶仍是能夠經過參數mapred.min.split.size參數在做業提交客戶端進行自定義設置。還有一個重要參數就是mapred.map.tasks，這個參數設置的map數量僅僅是一個提示，只有當InputFormat決定了map任務的個數比mapred.map.tasks值小時才起做用。一樣，Map任務的個數也能經過使用JobConf的conf.setNumMapTasks(int num)方法來手動地設置。這個方法可以用來增長map任務的個數，可是不能設定任務的個數小於Hadoop系統經過分割輸入數據獲得的值
純粹的 mapreduce task 的 reduce task 數很簡單，就是參數 mapred.reduce.tasks
的值，hadoop-site.xml 文件中和 mapreduce job 運行時。不設置的話默認爲 1
ResourceManager HA：在apache hadoop 4.4 或者CDH5.0.0 版本以後，增長了ResourceMangerHA 特性，支持基於Zookeeper 的熱主備切換。
磁盤容錯：增長了幾個對多磁盤很是友好地參數，這些參數容許YARN 更好地使用NodeManager 上的多塊磁盤.
資源調度器：Fair Scheduler 增長了容許用戶在線將一個應用程序從一個隊列轉移到另一個隊列。
reduce side join : 在map 階段，map 函數同時讀取兩個文件File1 和File2，爲了區分
兩種來源的key/value 數據對，對每條數據打一個標籤（tag）,好比：tag=0 表示來自文件File1，
tag=2 表示來自文件File2。
map side join : Map side join 是針對如下場景進行的優化：兩個待鏈接表中，有一個表很是大，而另外一個表很是小，以致於小表能夠直接存放到內存中。這樣，咱們能夠將小表複製多份，讓每一個map task 內存中存在一份（好比存放到hash table 中），而後只掃描大表：對於大表中的每一條記錄key/value，在hash table 中查找是否有相同的key 的記錄，若是有，
則鏈接後輸出便可。
Semi Join : Semi Join，也叫半鏈接，是從分佈式數據庫中借鑑過來的方法。它的產生動機是：對於reduce side join，跨機器的數據傳輸量很是大，這成了join 操做的一個瓶頸，
若是可以在map 端過濾掉不會參加join 操做的數據，則能夠大大節省網絡IO。
reduce side join + BloomFilter : BloomFilter 最多見的做用是：判斷某個元素是否在一個集合裏面。它最重要的兩個方法是：add() 和contains()。最大的特色是不會存在 falsenegative，即：若是contains()返回false，則該元素必定不在集合中，但會存在必定的 falsepositive，即：若是contains()返回true，則該元素必定可能在集合中。
SequenceFile文件是Hadoop用來存儲二進制形式的key-value 對而設計的一種平面文件;Hadoop 的HDFS 和MapReduce子框架主要是針對大數據文件來設計的，在小文件的處理上不但效率低下，並且十分消耗磁盤空間(每個小文件佔用一個Block,HDFS 默認block大小爲64M)。
解決辦法一般是選擇一個容器，將這些小文件組織起來統一存儲。HDFS提供了兩種類型的容器，分別是SequenceFile和MapFile。
SequenceFile的每條記錄是可序列化的字符數組。
序列化是指將結構化的對象轉化爲字節流以便在網絡上傳輸或寫入到磁盤進行永久存 儲的過程，反序列化是指將字節流轉回結構化對象的過程.
加入了yarn 解決了資源調度的問題。
加入了對zookeeper 的支持實現比較可靠的高可用.
二次排序:就是首先按照第一字段排序，而後再對第一字段相同的行按照第二字段排序，注意不能破壞第一次排序的結果。
在Hadoop中，默認狀況下是按照key進行排序。對於同一個key，reduce函數接收到的value list是按照value 排序的。
有兩種方法進行二次排序，分別爲：buffer and in memory sort和value-to-key conversion。
對於buffer and in memory sort，主要思想是：在reduce()函數中，將某個key對應的全部value保存下來，而後進行排序。 這種方法最大的缺點是：可能會形成 out of memory。
對於value-to-key conversion，主要思想是：將key和部分value拼接成一個組合key（實現WritableComparable接口或者調用setSortComparatorClass函數），這樣reduce獲取的結果即是先按key排序，後按value排序的結果，須要注意的是，用戶須要本身實現Paritioner，以便只按照key進行數據劃分。Hadoop顯式的支持二次排序，在Configuration 類中有個 setGroupingComparatorClass()方法，可用於設置排序 group的 key 值。
具體參考：http://www.cnblogs.com/xuxm2007/archive/2011/09/03/2165805.html
參考網址：http://my.oschina.net/leejun2005/blog/95186?fromerr=cDqkUyup
一個是在map side發生在spill後partition前。
一個是在reduce side發生在copy後 reduce前。
mapReduce的四個階段：
Splitting :在進行map 計算以前，mapreduce 會根據輸入文件計算輸入分片（inputsplit），每一個輸入分片（input split）針對一個map 任務。輸入分片（input split）存儲的並不是數據自己，而是一個分片長度和一個記錄數據位置的數組，輸入分片（input split）每每和hdfs 的block（塊）關係很密切，假如咱們設定hdfs 的塊的大小是64mb，若是咱們輸入有三個文件，大小分別是3mb、65mb 和127mb，那麼mapreduce 會把3mb 文件分爲一個輸入分片（input split），65mb 則是兩個輸入分片（input split）而127mb 也是兩個輸入分片（input split），換句話說咱們若是在map 計算前作輸入分片調整，例如合併小文件，那麼就會有5 個map 任務將執行，並且每一個map 執行的數據大小不均，這個也是mapreduce 優化計算的一個關鍵點。
Mapping:就是程序員編寫好的map 函數了，所以map 函數效率相對好控制，並且通常map 操做都是本地化操做也就是在數據存儲節點上進行；
Shuffle:描述着數據從map task 輸出到reduce task 輸入的這段過程。
Reduce:對Map階段多個文件的數據進行合併
分區，排序，溢寫，拷貝到對應reduce機器上，增長combiner，壓縮溢寫的文件
在MR做業中的Map階段會輸出結果數據到磁盤中。
Combiner只應該適用於那種Reduce的輸入（key：value與輸出（key：value）類型徹底一致，且不影響最終結果的場景。好比累加，最大值等，也能夠用於過濾數據，在 map端將無效的數據過濾掉。
在這些需求場景下，輸出的數據是能夠根據key值來做合併的，合併的目的是減小輸出的數據量，減小IO的讀寫，減小網絡傳輸,以提升MR的做業效率。
1.combiner的做用就是在map端對輸出先作一次合併,以減小傳輸到reducer的數據量.
2.combiner最基本是實現本地key的歸併,具備相似本地reduce,那麼全部的結果都是reduce完成,效率會相對下降。
3.使用combiner,先完成的map會在本地聚合,提高速度
dfs.namenode.http-address:50070
dfs.datanode.address:50010
fs.defaultFS:8020
yarn.resourcemanager.webapp.address:8088
一.mapper調優
mapper調優主要就一個目標：減小輸出量。
咱們能夠經過增長combine階段以及對輸出進行壓縮設置進行mapper調優。
1>combine合併： 實現自定義combine要求繼承reducer類。比較適合map的輸出是數值型的，方便進行統計。
2>壓縮設置：在提交job的時候分別設置啓動壓縮和指定壓縮方式。
二.reducer調優
reducer調優主要是經過參數調優和設置reducer的個數來完成。
reducer個數調優：
要求：一個reducer和多個reducer的執行結果一致，不能由於多個reducer致使執行結果異常。
規則：通常要求在hadoop集羣中的執行mr程序，map執行完成100%後，儘可能早的看到reducer執行到33%，能夠經過命令hadoop job -status job_id或者web頁面來查看。
緣由：map的執行process數是經過inputformat返回recordread來定義的；而reducer是有三部分構成的，分別爲讀取mapper輸出數據、合併全部輸出數據以及reduce處理，其中第一步要依賴map的執行，因此在數據量比較大的狀況下，一個reducer沒法知足性能要求的狀況下，咱們能夠經過調高reducer的個數來解決該問題。
優勢：充分利用集羣的優點。
缺點：有些mr程序無法利用多reducer的優勢，好比獲取top n的mr程序
hadoop和R語言在各自的領域都至關的強大，由RevolutionAnalytics發起的一個開源項目RHadoop將R語言與Hadoop結合在一塊兒，很好發揮了R語言特長。廣大R語言愛好者藉助強大工具RHadoop，能夠在大數據領域大展拳腳。
1. Hadoop家族的強大之處，在於對大數據的處理，讓原來的不可能（TB,PB數據量計算），成爲了可能。
2.R語言的強大之處，在於統計分析，在沒有Hadoop以前，咱們對於大數據的處理，要取樣本，假設檢驗，作迴歸，長久以來R語言都是統計學家專屬的工具。
3. hadoop重點是全量數據分析，而R語言重點是樣本數據分析。 兩種技術放在一塊兒，恰好是取長補短。 4.用R語言，經過分析少許數據，對業務目標迴歸建模，並定義指標，用Hadoop從海量日誌數據中，提取指標數據，用R語言模型，對指標數據進行測試和調優
5.R和Hadoop分別都起着很是重要的做用，以計算機開發人員的思路，全部有事情都用Hadoop去作，沒有數據建模和證實，」預測的結果」必定是有問題的。以統計人員的思路，全部的事情都用R去作，以抽樣方式，獲得的「預測的結果」也必定是有問題的。因此讓兩者結合，是產界業的必然的導向，也是產界業和學術界的交集，同時也爲交叉學科的人才提供了更廣闊的發展空間
離線計算框架，過程分爲split map shuffle reduce四個過程 。
架構節點有：Jobtracker TaskTracker 。
Split將文件分割，傳輸到mapper，mapper接收KV形式的數據，通過處理，再傳到shuffle過程。
Shuffle先進行HashPartition或者自定義的partition，會有數據傾斜和reduce的負載均衡問題；再進行排序，默認按字典排序；爲減小mapper輸出數據，再根據key進行合併，相同key的數據value會被合併；最後分組造成（key,value{}）形式的數據，輸出到下一階段 。
Reduce輸入的數據就變成了，key+迭代器形式的數據，再進行處理
相同點：
TextInputformat和KeyValueTextInputFormat都繼承了FileInputFormat類，都是每一行做爲一個記錄；
區別：
TextInputformat將每一行在文件中的起始偏移量做爲 key，每一行的內容做爲value。默認以\n或回車鍵做爲一行記錄。
KeyValueTextInputFormat 適合處理輸入數據的每一行是兩列，並用 tab 分離的形式
在執行 mapreduce 以前，原始數據被分割成若干個 split，每一個 split 做爲一個 map
任務的輸入，在 map 執行過程當中 split 會被分解成一個個記錄（key-value 對）。
InputFormat 是 MapReduce 中一個很經常使用的概念是文件拆分必須實現的一個接口，包含了兩個方法：
public interface InputFormat<K, V> {
InputSplit[] getSplits(JobConf job, int numSplits) throws IOException;
RecordReader<K, V> createRecordReader(InputSplit split, TaskAttemptContext
context) throws IOException;
}
這兩個方法分別完成如下工做：
方法 getSplits 將輸入數據切分紅 splits，splits 的個數即爲 map tasks 的個數，
splits 的大小默認爲塊大小，即 64M
方法 getRecordReader 將每一個 split 解析成 records, 再依次將 record 解析成
<K,V>對，也就是說 InputFormat 完成如下工做：InputFile --> splits --> <K,V>
系 統 常 用 的 InputFormat 又 有 哪 些 呢 ？ TextFileInputFormat ，
KeyValueTextFileInputFormat，SequenceFileInputFormat<key,value>,
NLineInputFormat 其中 Text InputFormat 即是最經常使用的，它的 <K,V>就表明 <行偏移,
該行內容>
然而系統所提供的這幾種固定的將 InputFile 轉換爲 <K,V>的方式有時候並不能知足我
們的需求：
此時須要咱們自定義 InputFormat ，從而使 Hadoop 框架按照咱們預設的方式來將
InputFile 解析爲<K,V>
在領會自定義 InputFormat 以前，須要弄懂一下幾個抽象類、接口及其之間的關係：
InputFormat(interface), FileInputFormat(abstract class), TextInputFormat(class),
RecordReader (interface), Line RecordReader(class)的關係FileInputFormat implements InputFormat
TextInputFormat extends FileInputFormat
TextInputFormat.get RecordReader calls Line RecordReader
Line RecordReader implements RecordReader
對於 InputFormat 接口，上面已經有詳細的描述
再看看 FileInputFormat，它實現了 InputFormat 接口中的 getSplits 方法，而將
getRecordReader 與 isSplitable 留給具體類(如 TextInputFormat )實現， isSplitable 方
法一般不用修改，因此只須要在自定義的 InputFormat 中實現
getRecordReader 方 法 即 可 ， 而 該 方 法 的 核 心 是 調 用 Line RecordReader( 即 由
LineRecorderReader 類來實現 " 將每一個 s plit 解析成 records, 再依次將 record 解析成
<K,V>對" )，該方法實現了接口 RecordReader
public interface RecordReader<K, V> {
boolean next(K key, V value) throws IOException;
K createKey();
V createValue();
long getPos() throws IOException;
public void close() throws IOException;
float getProgress() throws IOException;
}
定義一個 InputFormat 的核心是定義一個相似於LineRecordReader的RecordReader
Hadoop 的 MapReduce 框架來處理數據，主要是面向海量大數據，對於這類數據，Hadoop 可以使其真正發揮其能力。對於海量小文件，不是說不能使用 Hadoop 來處理，只不過直接進行處理效率不會高，實際應用中，咱們在使用 Hadoop 進行計算的時候，須要考慮將小數據轉換成大數據，好比經過合併壓縮等方法，咱們經過自定義 InputFormat和RecordReader來實現對海量小文件的並行處理
若是沒有自定義的 partitioning，則默認的 partition 算法，即根據每一條數據的 key
的 hashcode 值摸運算（%）reduce 的數量，獲得的數字就是「分區號「
map task上的洗牌（shuffle）結束，此時 reducer task 上的洗牌開始，抓取 fetch 所
屬於本身分區的數據，同時將這些分區的數據進行排序sort（默認的排序是根據每一條數據的鍵的字典
排序），進而將數據進行合併merge，即根據key相同的，將其 value 組成一個集合，最後輸出結果
（1）默認的調度器 FIFO
Hadoop中默認的調度器，它先按照做業的優先級高低，再按照到達時間的前後選擇被執行的做業。
（2）計算能力調度器 Capacity Scheduler
支持多個隊列，每一個隊列可配置必定的資源量，每一個隊列採用FIFO調度策略，爲了防止同一個用戶的做業獨佔隊列中的資源，該調度器會對同一用戶提交的做業所佔資源量進行限定。調度時，首先按如下策略選擇一個合適隊列：計算每一個隊列中正在運行的任務數與其應該分得的計算資源之間的比值，選擇一個該比值最小的隊列；而後按如下策略選擇該隊列中一個做業：按照做業優先級和提交時間順序選擇，同時考慮用戶資源量限制和內存限制。
（3）公平調度器 Fair Scheduler
同計算能力調度器相似，支持多隊列多用戶，每一個隊列中的資源量能夠配置，同一隊列中的做業公平共享隊列中全部資源。實際上， Hadoop的調度器遠不止以上三種，最近，出現了不少針對新型應用的Hadoop調度器。
（4）適用於異構集羣的調度器LATE
現有的 Hadoop 調度器都是創建在同構集羣的假設前提下，具體假設以下：
1）集羣中各個節點的性能徹底同樣
2）對於 reduce task，它的三個階段：copy、 sort 和 reduce，用時各佔 1/3
3）同一 job 的同類型的 task 是一批一批完成的，他們用時基本同樣。
現有的Hadoop調度器存在較大缺陷，主要體如今探測落後任務的算法上：若是一個task 的進度落後於同類型 task進度的20%，則把該task當作落後任務(這種任務決定了job的完成時間，需儘可能縮短它的執行時間)，從而爲它啓動一個備份任務（speculative task）。
若是集羣異構的，對於同一個task，即便是在相同節點上的執行時間也會有較大差異，於是在異構集羣中很容易產生大量的備份任務。
LATE調度器從某種程度上解決了現有調度器的問題，它定義三個閾值 ：
SpeculativeCap，系統中最大同時執行的speculative task 數目（做者推薦值爲總slot數的10%）； SlowNodeThreshold（做者推薦值爲25%）：得分（分數計算方法見論文）低於該閾值的node（快節點）上不會啓動 speculative task；SlowTaskThreshold（做者推薦值爲 25%）：當 task 進度低於同批同類 task 的平均進度的 SlowTaskThreshold 時，會爲該 task 啓動 speculative task。它的調度策略是：當一個節點出現空閒資源且系統中總的備份任務數小 於 SpeculativeCap 時， a.若是該節點是慢節點（節點得分高 於SlowNodeThreshold），則忽略這個請求。 b.對當前正在運行的 task 按估算的剩餘完成時間排序 c.選擇剩餘完成時間最大且進度低於 SlowTaskThreshold 的 task，爲該 task 啓動備份任務。
（5）適用於實時做業的調度器Deadline Scheduler和Constraint-based Scheduler
這種調度器主要用於有時間限制的做業（Deadline Job），即給做業一個deadline時間，讓它在該時間內完成。實際上，這類調度器分爲兩種，軟實時（容許做業有必定的超時）做業調度器和硬實時（做業必須嚴格按時完成）做業調度器。
Deadline Scheduler 主要針對的是軟實時做業，該調度器根據做業的運行進度和剩餘時間動態調整做業得到的資源量，以便做業儘量的在 deadline 時間內完成。
Constraint-based Scheduler 主要針對的是硬實時做業，該調度器根據做業的deadline和當前系統中的實時做業運行狀況，預測新提交的實時做 業能不能在 deadline時間內完成，若是不能，則將做業反饋給用戶，讓他重調整做業的 deadline
Hadoop 內置的輸出文件格式有：
MultipleOutputs<K,V> 能夠把輸出數據輸送到不一樣的目錄；
在自定義的reduce的函數中首先使用setup函數（注：該函數在task啓動後數據處理前就調用一次）new出MultipleOutputs 對象，利用該對象調用 write 方法定義輸出的目錄
Hadoop序列化機制，支持多語言的交互
Hadoop 集羣從三個角度劃分爲兩個角色。 Hadoop 集羣包括 hdfs 做爲文件存儲系統，mapreduce 做爲分佈式計算框架。
(1)最基本的劃分爲主節點和從節點
(2)在 hdfs 中，Namenode 做爲主節點，接收客戶端的讀寫服務。 存儲文件的的元數據如文件名，文件目錄結構，文件屬性(生成時間，副本數，文件權限)，以及 block所在的datanode 等等，namenode 的元數據信息會在啓動後加載到內存，metadata存儲到磁盤文件名爲」 fsimage」 ,block 的信息不會保存到 fsimage,edits 記錄對metadata 的操做日誌datanode 做爲從節點。 Datanode 的做用是存儲數據即 block，啓動 datanode 線程的時候會向 namenode 彙報 block 信息，經過向 namenode 發送心跳保持與其聯繫，若是 namenode10 分鐘沒有收到 datanode 的心跳，則認爲 datanode 掛了，並複製其上的 block 到其餘 datanode。
(3)在 mapreduce 中的主節點爲 jobTracker 和 tasktracker。
JobTracker 做爲主節點，負責調度分配每個子任務 task 運行於 taskTracker上，若是發現有失敗的task 就從新分配到其餘節點，每一個 Hadoop 集羣通常有一個JobTaskTracker，運行在 master 節點上。
TaskTracker主動與JobTracker通訊，接收做業，並負責直接執行每個任務，爲了減小網絡帶寬TaskTracker 最好運行在 datanode 上
Mapreduce 程序效率的瓶頸在於兩點：
一計算機性能
二 I/O 操做優化
優化分爲時間和空間兩種常見的優化策略以下：
1,輸入的文件儘可能使用大文件，衆多的小文件會致使map的數量衆多，每一個map任務都會形成一些性能的損失，若是輸入的是小的文件能夠在進行mapreduce處理以前整合成爲大文件，或者直接採用ConbinFileInputFormat來做爲輸入方式，此時，hadoop 會考慮節點和集羣的位置信息，決定將哪些文件打包到一個單元中。
2,合理的分配 map 和 reduce 的任務的數量.
3,壓縮中間數據，減小 I/O.
4,在 map 以後先進行 combine 處理，減小 I/O
mapreduce 分佈式計算 mapreduce 的思想就是分而治之
倒排索引:一種索引方法，用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射，在倒排索引中單詞指向了包含單詞的文檔。
消息隊列:大量的數據寫入首先存入消息隊列進行緩衝，再把消息隊列做爲數據來源進行數據讀取。
數據庫讀寫分離:向一臺數據庫寫入數據，另外的多臺數據庫從這臺數據庫中進行讀取
user,ip,time,oper(枚舉值:1 爲上線， 2 位下線 )；
訪問日誌格式:ip,time,url,假設登陸日誌中user上下線信息完整，且同一上下線時間段內使用的ip惟一，要計算訪問日誌中獨立 user 數量最多的前 10個url，請給出MapReduce設計思路，如須要幾個MapReduce，及每一個 MapReduce 算法僞代碼。
思路:
將 userid ,ip ,url 封裝成一個對象，map 類輸入數據，按照 userid 爲 key 輸出，value
爲 1（intwritable）,按照 reduce 計算寫一個排序類而後按照 value 降序輸出前十個
一、 導入數據對需分析的數據進行分片，片的大小默認與 datanode 塊大小相同。
二、 每一個數據片由一個 mapper 進行分析，mapper 按照需求將數據拆分爲一個個 keyvalue 格式的數據。
三、 每一個 key-value 數據調用一次 map 方法，對數據進行相應的處理後輸出。
四、 將輸出的數據複製到對應的分區，默認一個鍵一個區，相同鍵放在同一個區中。
五、 將輸出的數據進行合併爲 key-Iterable 格式。
六、 每一個分區有一個 reduce，每一個 reduce 將同一個分區的數據進行合併處理爲本身所需的數據格式。
七、 將數據輸出至 hdfs
一、 secondary namenode 在 namenode 的 edits log 文件超過規定值（默認 64M）時，或者每隔3600秒（默認值）時會剪切 edits log 文件，複製 namenode 上的 fsimage文件（若沒有 fsimage）。
二、 namenode 節點建立一個新的 edits 文件。
三、 將 edits log 文件及 fsimage 文件進行合併爲一個新 fsimage。
四、 將 fsimage 文件回傳至 namenode 節點。
五、 Namenode 節點使用 seconday namenode 節點回傳的 fsimage 文件覆蓋本地的fsimage 文件。
六、 當 namenode 節點啓動時能夠從 seconday namenode 節點複製 fsimage 文件達到快速啓動的目的
一、 數據量很小。
二、 繁雜的小文件。
三、 索引是更好的存取機制的時候。
四、 事務處理。
五、 只有一臺機器的時候
mr跑的慢可能有不少緣由，如：數據傾斜、map和reduce數設置不合理、reduce等待太久、小文件過多、spill 次數過多、 merge 次數過多等。
一、解決數據傾斜：數據傾斜多是partition不合理，致使部分partition中的數據過多，部分過少。可經過分析數據，自定義分區器解決。
二、合理設置map和reduce數：兩個都不能設置太少，也不能設置太多。太少，會致使task等待，延長處理時間；太多，會致使 map、 reduce 任務間競爭資源，形成處理超時等錯誤。
三、設置map、reduce共存：調整slowstart.completedmaps參數，使map運行到必定程度後，reduce也開始運行，減小 reduce 的等待時間。
四、合併小文件：在執行mr任務前將小文件進行合併，大量的小文件會產生大量的map任務，增大map任務裝載次數，而任務的裝載比較耗時，從而致使 mr 運行較慢。
五、減小spill次數：經過調整io.sort.mb及sort.spill.percent參數值，增大觸發spill的內存上限，減小spill 次數，從而減小磁盤 IO。
六、減小merge次數：經過調整io.sort.factor參數，增大merge的文件數目，減小merge的次數，從而縮短mr處理時間
一、 namenode 單點故障：經過 zookeeper 搭建 HA 高可用，可自動切換 namenode。
二、ResourceManager單點故障：可經過配置YARN的HA，並在配置的namenode上手動啓動ResourceManager做爲Slave，在 Master 故障後，Slave 會自動切換爲Master。
三、reduce階段內存溢出：是因爲單個reduce任務處理的數據量過多，經過增大reducetasks數目、優化partition 規則使數據分佈均勻進行解決。
四、datanode內存溢出：是因爲建立的線程過多，經過調整linux的maxuserprocesses參數，增大可用線程數進行解決。
五、 集羣間時間不一樣步致使運行異常：經過配置內網時間同步服務器進行解決
當 jobtracker.restart.recover 參數值設置爲 true， jobtracker 重啓之時會觸發recovery。
在JobTracker重啓前，會在history log中記錄各個做業的運行狀態，這樣在JobTracker關閉後，系統中全部數據目錄、 臨時目錄均會被保留，待 JobTracker 重啓以後，JobTracker 自動從新提交這些做業，並只對未運行完成的 task 進行從新調度，這樣可避免已經計算完的 task 從新計算
一、 不支持文件的併發寫入和對文件內容的隨機修改。
二、 不支持低延遲、高吞吐的數據訪問。
三、 存取大量小文件，會佔用 namenode 大量內存，小文件的尋道時間超過讀取時間。
四、 hadoop 環境搭建比較複雜。
五、 數據沒法實時處理。
六、 mapreduce 的 shuffle 階段 IO 太多。
七、 編寫 mapreduce 難度較高，實現複雜邏輯時，代碼量太大