Hadoop CAP理論
大數據技術原理與應用——概念点弯、存儲扇调、處理、分析與應用
C (強一致性) ：系統(tǒng)在執(zhí)行過某項操作后仍然處于一致的狀態(tài)抢肛。在分布式系統(tǒng)中狼钮，更新操作執(zhí)行成功后所有的用戶都應該讀取到最新的值，這樣的系統(tǒng)被認為具有強一致性捡絮。
A (可用性) ：每一個操作總是能夠在一定的時間內返回結果熬芜，這里需要注意的是“一定時間內”和“返回結果”。
P (分區(qū)容錯性)：分區(qū)容錯性可以理解為系統(tǒng)在存在網絡分區(qū)的情況下仍然可以接受請求(滿足一致性和可用性)福稳。
Hadoop的HDFS只支持數據增加寿弱，而Mapeduce卻進行全局計算啡省，完美地符合了他對數據處理的期望鞋既！
Hadoop也存在某個節(jié)點數據丟失的問題，但隨著流式計算半火，丟失的數據終究會隨著系統(tǒng)的正常而被最終合并，因此數據最終是一致的季俩。
Hadoop不能進行實時計算咋辦钮糖？作者又構建了一套基于Cassandra和ElephantDB的實時數據處理系統(tǒng)。酌住。店归。。搞的無比復雜赂韵！
具體關于分布式系統(tǒng)CAP理論的質疑推薦一個博客和一些參考文獻：
CAP理論
參考資料：
【1】
【2】
【3】
【4】
【5】
【6】
【7】
【8】
Hadoop 組件
核心組件
- HDFS ----Hadoop生態(tài)系統(tǒng)的基礎組件是Hadoop分布式文件系統(tǒng)(HDFS)娱节。HDFS的機制是將大量數據分布到計算機集群上，數據一次寫入祭示，但可以多次讀取用于分析肄满。它是其他一些工具的基礎，例如HBase质涛。
- MapReduce ----Hadoop的主要執(zhí)行框架即MapReduce稠歉，它是一個用于分布式并行數據處理的編程模型，將作業(yè)分為mapping階段和reduce階段(因此而得名)汇陆。開發(fā)人員為Hadoop編寫MapReduce作業(yè)怒炸，并使用HDFS中存儲的數據，而HDFS可以保證快速的數據訪問毡代。鑒于MapReduce作業(yè)的特性阅羹，Hadoop以并行的方式將處理過程移向數據，從而實現快速處理教寂。
其他組件
Hbase ----一個構建在HDFS之上的面向列的NoSQL數據庫捏鱼，HBase用于對大量數據進行快速讀取/寫入。HBase將Zookeeper用于自身的管理酪耕，以保證其所有組件都正在運行导梆。
Zookeeper ----Zookeeper是Hadoop的分布式協(xié)調服務。Zookeeper被設計成可以在機器集群上運行迂烁，是一個具有高度可用性的服務看尼，用于Hadoop操作的管理，而且很多Hadoop組件都依賴它盟步。
Oozie ----一個可擴展的Workflow系統(tǒng)藏斩，Oozie已經被集成到Hadoop軟件棧中，用于協(xié)調多個MapReduce作業(yè)的執(zhí)行却盘。它能夠處理大量的復雜性狰域，基于外部事件(包括定時和所需數據是否存在)來管理執(zhí)行窜觉。
Pig ----對MapReduce編程復雜性的抽象，Pig平臺包含用于分析Hadoop數據集的執(zhí)行環(huán)境和腳本語言(Pig Latin)北专。它的編譯器將Pig Latin翻譯為MapReduce程序序列。
Hive ----類似于SQL的高級語言旬陡，用于執(zhí)行對存儲在Hadoop中數據的查詢拓颓，Hive允許不熟悉MapReduce的開發(fā)人員編寫數據查詢語句，它會將其翻譯為Hadoop中的MapReduce作業(yè)描孟。類似于Pig驶睦，Hive是一個抽象層，但更傾向于面向較熟悉SQL而不是Java編程的數據庫分析師匿醒。
Hadoop HDFS 分布式文件系統(tǒng) 兩大部件
- ** NameNode**
HdFS中主節(jié)點场航，存儲文件的元數據，如文件名廉羔，文件目錄結構溉痢，文件屬性（生成時間，副本個數憋他，文件權限）孩饼，以及每個文件的塊列表和塊所在的DataNode等等。 -
DataNode
在HDFS中存儲文件塊數據竹挡，以及塊數據的校驗和镀娶。
HDFS 讀寫機制
HDFS讀文件數據流
在讀取HDFS的文件時，首先客戶端調用FileSystem的open()函數打開文件揪罕，DistributedFileSystem用RPC調用元數據節(jié)點梯码，得到文件的數據塊信息。對于每一個數據塊好啰，元數據節(jié)點返回保存數據塊的數據節(jié)點的地址轩娶。DistributedFileSystem返回FSDataInputStream給客戶端，用來讀取數據坎怪“瞻樱客戶端調用stream的read()函數開始讀取數據。DFSInputStream連接保存此文件第一個數據塊的最近的數據節(jié)點搅窿。Data從數據節(jié)點讀到客戶端嘁酿，當此數據塊讀取完畢時，DFSInputStream關閉和此數據節(jié)點的連接男应，然后連接此文件下一個數據塊的最近的數據節(jié)點闹司。當客戶端讀取完數據的時候，調用FSDataInputStream的close函數沐飘∮巫客戶端讀取HDFS中的文件訪問數據流的整個過程如圖3-3所示牲迫。
圖 3-3 HDFS中的讀文件數據流的過程
圖3-3中的操作序號1、2借卧、3盹憎、4、5表示執(zhí)行順序铐刘，讀取文件的數據流步驟如下：
1） 調用FileSystem的open()打開文件陪每，見序號1:open。
2） DistributedFileSystem使用RPC調用NameNode節(jié)點镰吵，得到文件的數據塊元數據信息檩禾，并返回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所描述功偿，數據流從客戶端開始盆佣，流經一系列的節(jié)點，到達最后一個DataNode械荷。圖3-4中的所有DataNode只需要寫一次硬盤共耍，DataNode1和DataNode2會從socket上接收到數據，直接寫到下個節(jié)點的socket上吨瞎。需要注意的是痹兜，如果當前DataNode處于數據流的中間，那么該數據包會被發(fā)送到下一個節(jié)點颤诀。接下來就是處理數據和校驗字旭，并分別將數據包寫到數據塊文件和數據塊元數據文件对湃。如果出錯，拋出的異常會導致receiveBlock關閉相關的輸出流遗淳，并終止傳輸拍柒。同時，數據校驗出錯還會上報到NameNode上屈暗。
最后一個DataNode由于沒有后續(xù)節(jié)點斤儿，PacketResponder的ackQueue每收到一項，表明對應的數據塊已經處理完畢恐锦，那么就可以發(fā)送成功應答。如果該應答是最后一個包的疆液，PacketResponder會關閉相關的輸出流并提交一铅。如果DataNode有后續(xù)節(jié)點，那么堕油，它必須等到后續(xù)節(jié)點成功應答才可以發(fā)送應答潘飘。
上面描述了HDFS在寫數據時的基本處理機制，從客戶端開始掉缺，直到在HDFS上完成寫一個文件的整體數據流程如圖3-5所示卜录。
圖3-5 HDFS寫數據流圖
正如圖3-5所示，首先客戶端調用create()來創(chuàng)建文件眶明，然后DistributedFileSystem同樣使用RPC調用NameNode元數據節(jié)點艰毒，在文件系統(tǒng)的命名空間中創(chuàng)建一個新的文件。NameNode首先確定文件原來不存在搜囱，以及客戶端有創(chuàng)建文件的權限丑瞧，然后創(chuàng)建新文件。DistributedFileSystem返回DFSOutputStream蜀肘，客戶端用于寫數據绊汹。客戶端開始寫入數據扮宠，DFSOutputStream將數據分成塊西乖，寫入data queue。Data queue由Data Streamer讀取坛增，并通知元數據節(jié)點分配數據節(jié)點获雕，用來存儲數據塊（每塊默認復制3塊）。分配的數據節(jié)點放在一個pipeline里收捣。Data Streamer將數據塊寫入pipeline中的第一個數據節(jié)點典鸡。第一個數據節(jié)點將數據塊發(fā)送給第二個數據節(jié)點。第二個數據節(jié)點將數據發(fā)送給第三個數據節(jié)點坏晦。DFSOutputStream為發(fā)出去的數據塊保存了ack queue萝玷，等待pipeline中的數據節(jié)點告知數據已經寫入成功嫁乘。如果數據節(jié)點在寫入的過程中失敗：關閉pipeline球碉，同時將ack queue中的數據塊放入data queue中的開始位置蜓斧。
