Hadoop CAP理論
大數據技術原理與應用——概念、存儲、處理、分析與應用
C (強一致性) ：系統在執行過某項操作后仍然處于一致的狀態。在分布式系統中，更新操作執行成功后所有的用戶都應該讀取到最新的值，這樣的系統被認為具有強一致性。
A (可用性) ：每一個操作總是能夠在一定的時間內返回結果，這里需要注意的是“一定時間內”和“返回結果”。
P (分區容錯性)：分區容錯性可以理解為系統在存在網絡分區的情況下仍然可以接受請求(滿足一致性和可用性)。
Hadoop的HDFS只支持數據增加，而Mapeduce卻進行全局計算，完美地符合了他對數據處理的期望！
Hadoop也存在某個節點數據丟失的問題，但隨著流式計算，丟失的數據終究會隨著系統的正常而被最終合并，因此數據最終是一致的。
Hadoop不能進行實時計算咋辦？作者又構建了一套基于Cassandra和ElephantDB的實時數據處理系統。。。。搞的無比復雜！
具體關于分布式系統CAP理論的質疑推薦一個博客和一些參考文獻：
CAP理論
參考資料：
【1】
【2】
【3】
【4】
【5】
【6】
【7】
【8】
Hadoop 組件
核心組件
- HDFS ----Hadoop生態系統的基礎組件是Hadoop分布式文件系統(HDFS)。HDFS的機制是將大量數據分布到計算機集群上，數據一次寫入，但可以多次讀取用于分析。它是其他一些工具的基礎，例如HBase。
- MapReduce ----Hadoop的主要執行框架即MapReduce，它是一個用于分布式并行數據處理的編程模型，將作業分為mapping階段和reduce階段(因此而得名)。開發人員為Hadoop編寫MapReduce作業，并使用HDFS中存儲的數據，而HDFS可以保證快速的數據訪問。鑒于MapReduce作業的特性，Hadoop以并行的方式將處理過程移向數據，從而實現快速處理。
其他組件
Hbase ----一個構建在HDFS之上的面向列的NoSQL數據庫，HBase用于對大量數據進行快速讀取/寫入。HBase將Zookeeper用于自身的管理，以保證其所有組件都正在運行。
Zookeeper ----Zookeeper是Hadoop的分布式協調服務。Zookeeper被設計成可以在機器集群上運行，是一個具有高度可用性的服務，用于Hadoop操作的管理，而且很多Hadoop組件都依賴它。
Oozie ----一個可擴展的Workflow系統，Oozie已經被集成到Hadoop軟件棧中，用于協調多個MapReduce作業的執行。它能夠處理大量的復雜性，基于外部事件(包括定時和所需數據是否存在)來管理執行。
Pig ----對MapReduce編程復雜性的抽象，Pig平臺包含用于分析Hadoop數據集的執行環境和腳本語言(Pig Latin)。它的編譯器將Pig Latin翻譯為MapReduce程序序列。
Hive ----類似于SQL的高級語言，用于執行對存儲在Hadoop中數據的查詢，Hive允許不熟悉MapReduce的開發人員編寫數據查詢語句，它會將其翻譯為Hadoop中的MapReduce作業。類似于Pig，Hive是一個抽象層，但更傾向于面向較熟悉SQL而不是Java編程的數據庫分析師。
Hadoop HDFS 分布式文件系統 兩大部件
- ** NameNode**
HdFS中主節點，存儲文件的元數據，如文件名，文件目錄結構，文件屬性（生成時間，副本個數，文件權限），以及每個文件的塊列表和塊所在的DataNode等等。 -
DataNode
在HDFS中存儲文件塊數據，以及塊數據的校驗和。
HDFS 讀寫機制
HDFS讀文件數據流
在讀取HDFS的文件時，首先客戶端調用FileSystem的open()函數打開文件，DistributedFileSystem用RPC調用元數據節點，得到文件的數據塊信息。對于每一個數據塊，元數據節點返回保存數據塊的數據節點的地址。DistributedFileSystem返回FSDataInputStream給客戶端，用來讀取數據。客戶端調用stream的read()函數開始讀取數據。DFSInputStream連接保存此文件第一個數據塊的最近的數據節點。Data從數據節點讀到客戶端，當此數據塊讀取完畢時，DFSInputStream關閉和此數據節點的連接，然后連接此文件下一個數據塊的最近的數據節點。當客戶端讀取完數據的時候，調用FSDataInputStream的close函數。客戶端讀取HDFS中的文件訪問數據流的整個過程如圖3-3所示。
圖 3-3 HDFS中的讀文件數據流的過程
圖3-3中的操作序號1、2、3、4、5表示執行順序，讀取文件的數據流步驟如下：
1） 調用FileSystem的open()打開文件，見序號1:open。
2） DistributedFileSystem使用RPC調用NameNode節點，得到文件的數據塊元數據信息，并返回FSDataInputStream給客戶端，見序號2：get block locations。
3） 客戶端調用stream的read()函數開始讀取數據，見序號3:read。
4） 調用FSDataInputStream直接從DataNode獲取文件數據塊，見序號4、5：read。
5） 讀完文件時，調用FSDataInputStream的close函數，見序號6:close。
HDFS寫數據流
HDFS的寫數據操作，比讀數據復雜一些。讀數據的時候，只需要在多個數據塊文件的選一個讀，就可以了，但是，寫數據需要同時寫到多個數據塊文件上，這就相對比較復雜了。HDFS的寫機制可以通過圖3-4進行簡單描述。
圖3-4 HDFS寫文件基本機制
如圖3-4所描述，數據流從客戶端開始，流經一系列的節點，到達最后一個DataNode。圖3-4中的所有DataNode只需要寫一次硬盤，DataNode1和DataNode2會從socket上接收到數據，直接寫到下個節點的socket上。需要注意的是，如果當前DataNode處于數據流的中間，那么該數據包會被發送到下一個節點。接下來就是處理數據和校驗，并分別將數據包寫到數據塊文件和數據塊元數據文件。如果出錯，拋出的異常會導致receiveBlock關閉相關的輸出流，并終止傳輸。同時，數據校驗出錯還會上報到NameNode上。
最后一個DataNode由于沒有后續節點，PacketResponder的ackQueue每收到一項，表明對應的數據塊已經處理完畢，那么就可以發送成功應答。如果該應答是最后一個包的，PacketResponder會關閉相關的輸出流并提交。如果DataNode有后續節點，那么，它必須等到后續節點成功應答才可以發送應答。
上面描述了HDFS在寫數據時的基本處理機制，從客戶端開始，直到在HDFS上完成寫一個文件的整體數據流程如圖3-5所示。
圖3-5 HDFS寫數據流圖
正如圖3-5所示，首先客戶端調用create()來創建文件，然后DistributedFileSystem同樣使用RPC調用NameNode元數據節點，在文件系統的命名空間中創建一個新的文件。NameNode首先確定文件原來不存在，以及客戶端有創建文件的權限，然后創建新文件。DistributedFileSystem返回DFSOutputStream，客戶端用于寫數據。客戶端開始寫入數據，DFSOutputStream將數據分成塊，寫入data queue。Data queue由Data Streamer讀取，并通知元數據節點分配數據節點，用來存儲數據塊（每塊默認復制3塊）。分配的數據節點放在一個pipeline里。Data Streamer將數據塊寫入pipeline中的第一個數據節點。第一個數據節點將數據塊發送給第二個數據節點。第二個數據節點將數據發送給第三個數據節點。DFSOutputStream為發出去的數據塊保存了ack queue，等待pipeline中的數據節點告知數據已經寫入成功。如果數據節點在寫入的過程中失敗：關閉pipeline，同時將ack queue中的數據塊放入data queue中的開始位置。
