一、簡史
1、Hadoop主要爲了解決兩個問題
- 海量數據存儲 HDFS
- 海量數據運算 MapReduce
2、hadoop的起源
起源於一個開源的項目nutch,
Hadoop源於谷歌的三篇論文:
- GFS(google fileSystem)，
- BigTable(key,value對的非關係型數據庫)
- MapReduce(分佈式計算框架)
狹義的Hadoop：
- HDFS+MapReduce
廣義的Hadoop：
- 指代一個大數據軟件的生態圈，包括各種周邊的其他框架（Hive，HBase，Spark....）
3、三大主流公司
hadoop的發行版本：主要從0.x到1.x到2.x這三個主流的版本
- apache開源版本：commiter
- 優點：版本更新迭代比較快，所有的軟件都有對應的迭代
- 缺點：版本的升級，兼容，維護等都比較麻煩
- 實際生產環境當中，儘量不要使用apache的版本
- 免費開源版本hortonworks：軟件的安裝，升級等都做了
- 服務收費版本cloudera：軟件有收費版，也有免費版
- MapR:大數據軟件廠商
4、hadoop的架構模型
1.x的版本架構模型介紹
文件系統核心模塊：
- NameNode：集羣當中的主節點，主要用於管理集羣當中的各種數據（主要維護元數據信息，元數據信息就是表述數據的數據）
- secondaryNameNode：主要能用於hadoop當中元數據信息的輔助管理
- DataNode：集羣當中的從節點，主要用於存儲集羣當中的各種數據
數據計算核心模塊：
- JobTracker：接收用戶的計算請求任務，並分配任務給從節點
- TaskTracker：負責執行主節點JobTracker分配的任務
1.x當中，主節點 namenode jobtracker都存在單節點故障問題
2.x的版本架構模型介紹
第一種：NameNode與ResourceManager單節點架構模型
第二種：NameNode單節點與ResourceManager高可用架構模型
第三種：NameNode高可用與ResourceManager單節點架構模型
第四種：NameNode與ResourceManager高可用架構模型
文件系統核心模塊：
- NameNode：集羣當中的主節點，主要用於管理集羣當中的各種數據，一般都是使用兩個，實現HA高可用
- DataNode：從節點，用於數據的存儲
- secondaryNameNode：主要負責瞄着active什麼時候死了，趕緊上位 兩個namenode組成主備的架構
- 如果namenode高可用：就沒有secondaryNamenode了，取而代之的是journalNode：主要用於同步元數據信息，保證兩個namenode的元數據信息是一致的
- nameNode active狀態：主要負責用戶的寫請求
- namenode高可用的自動切換，主要是通過兩個守護進程zkfc來實現的
數據計算核心模塊：
- ResourceManager：Yarn平臺的主節點，主要用於接收各種任務，通過兩個，構建成高可用
- NodeManager：Yarn平臺的從節點，主要用於處理ResourceManager分配的任務
二 、拓展
1、FastLeaderElection是zookeeper默認提供的選舉算法
選舉流程
目前有5臺服務器，每臺服務器均沒有數據，它們的編號分別是1,2,3,4,5,按編號依次啓動，它們的選擇舉過程如下：
- 1. 服務器1啓動，給自己投票，然後發投票信息，由於其它機器還沒有啓動所以它收不到反饋信息，服務器1的狀態一直屬於Looking。
- 2. 服務器2啓動，給自己投票，同時與之前啓動的服務器1交換結果，由於服務器2的編號大所以服務器2勝出，但此時投票數沒有大於半數，所以兩個服務器的狀態依然是LOOKING。
- 3. 服務器3啓動，給自己投票，同時與之前啓動的服務器1,2交換信息，由於服務器3的編號最大所以服務器3勝出，此時投票數正好大於半數，所以服務器3成爲leader，服務器1,2成爲follower。
- 4. 服務器4啓動，給自己投票，同時與之前啓動的服務器1,2,3交換信息，儘管服務器4的編號大，但之前服務器3已經勝出，所以服務器4只能成爲follower。
- 5. 服務器5啓動，後面的邏輯同服務器4成爲follower。
2、zookeeper四種類型的znode
1、PERSISTENT-持久化目錄節點
客戶端與zookeeper斷開連接後，該節點依舊存在
2、PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點
客戶端與zookeeper斷開連接後，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號
3、EPHEMERAL-臨時目錄節點
客戶端與zookeeper斷開連接後，該節點被刪除
4、EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點
客戶端與zookeeper斷開連接後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號
3、Zookeeper對節點的watch監聽通知是永久的嗎？
不是。官方聲明：一個Watch事件是一個一次性的觸發器，當被設置了Watch的數據發生了改變的時候，則服務器將這個改變發送給設置了Watch的客戶端，以便通知它們。
爲什麼不是永久的，舉個例子，如果服務端變動頻繁，而監聽的客戶端很多情況下，每次變動都要通知到所有的客戶端，這太消耗性能了。
4、集羣如果有3臺機器，掛掉一臺集羣還能工作嗎？掛掉兩臺呢
過半存活即可用。
5、集羣支持動態添加機器嗎
其實就是水平擴容了，Zookeeper在這方面不太好。
兩種方式：
全部重啓：關閉所有Zookeeper服務，修改配置之後啓動。不影響之前客戶端的會話。
逐個重啓：在重啓的過程中，需要保證一臺機器重啓完成後，再進行下一臺機器的重啓。這樣就整個集羣中每個時刻只有一臺機器不能正常工作，而集羣中有過半的機器是正常工作的，那麼整個集羣對外就是可用的。所以這個時候不會出現錯誤，也不會出現停止服務，整個擴容過程對用戶是無感知的。
三、環境搭建
apache軟件下載地址：
http://archive.apache.org/dist/
cdh所有軟件下載地址：
http://archive.cloudera.com/cdh5/cdh/5/
分佈式環境搭建（適用於工作當中正式環境搭建）
使用完全分佈式，實現namenode高可用，ResourceManager的高可用
|
|
192.168.1.100 |
192.168.1.110 |
192.168.1.120 |
|
zookeeper |
zk |
zk |
zk |
|
HDFS |
JournalNode |
JournalNode |
JournalNode |
|
NameNode |
NameNode |
|
|
|
ZKFC |
ZKFC |
|
|
|
DataNode |
DataNode |
DataNode |
|
|
YARN |
|
ResourceManager |
ResourceManager |
|
NodeManager |
NodeManager |
NodeManager |
|
|
MapReduce |
|
|
JobHistoryServer |
hadoop安裝包結構
hadoop-2.7.5/bin:一些shell腳本，供我們使用
hadoop-2.7.5/sbin:一些shell腳本，供我們使用
hadoop-2.7.5/etc/hadoop:所有的配置文件的路徑
hadoop-2.7.5/lib/native:本地的C程序庫
檢測hadoop的本地程序庫
bin/hadoop checknative
hadoop: true 本地庫，支持我們使用C程序來訪問hadoop
zlib: true 壓縮庫
snappy: false 壓縮庫 谷歌出品的一種壓縮算法，谷歌出品，必屬精品
lz4: true 壓縮庫
bzip2: false 壓縮庫
hadoop 六個核心配置文件的作用：
core-site.xml：核心配置文件，主要定義了我們文件訪問的格式 hdfs://
hadoop-env.sh：主要配置我們的java路徑
hdfs-site.xml：主要定義配置我們的hdfs的相關配置
mapred-site.xml 主要定義我們的mapreduce相關的一些配置
slaves：控制我們的從節點在哪裏 datanode nodemanager在哪些機器上
yarn-site.xml：配置我們的resourcemanager資源調度
安裝包解壓
修改配置文件
啓動集羣