對技術，我還是抱有敬畏之心的。
Hadoop概述
Hadoop是一個開源分布式雲計算平台，基於Map/Reduce模型的，處理海量數據的離線分析工具。基於Java開發，建立在HDFS上，最早由Google提出，有興趣的同學可以從Google三駕馬車: GFS,mapreduce,Bigtable開始了解起，這里我不詳細介紹了，因為網上的資料實在是太多了。
Hadoop項目的結構如下：
Hadoop中最重要的應該就是HDFS和Mapreduce了，從HDFS講起：
HDFS主要由以下優點：
1）、支持超大文件，一般來說，一個Hadoop文件系統可以輕松的存儲TB、PB級別的數據。
2）、檢測和快速應對硬件故障，在大量通用的廉價硬件構建的集群上，特別是硬件故障很常見，一班的HDFS系統由成百上千台存儲着數據文件的服務器組成，越多的服務器也就意味着高故障率，因此故障檢測和制動恢復就是HDFS的一個設計目標。
3）、流式數據訪問方式，HDFS要處理的數據規模都比較大，應用程序一次需要訪問大量數據，適用於批量處理而非用戶交互式處理數據，HDFS以流式方式訪問數據，注重的是數據的高吞吐量而非訪問速度。 HDFS是建立在最有效的數據處理模式是一次寫多次讀（write-once,read-many-times）的模式的概念之上的，當寫入操作被關閉后，想要往文件里面更新一些內容是不受支持。HDFS存儲的數據集作為hadoop的分析對象。在數據集生成后，長時間在此數據集上進行各種分析。每次分析都將設計該數據集的大部分數據甚至全部數據，因此讀取整個數據集的時間延遲比讀取第一條記錄的時間延遲更重要。（流式讀取最小化了硬盤的尋址開銷，只需要尋址一次，然后就一直讀啊讀。畢竟每一個文件塊都被划分為64M大小了。硬盤的物理構造導致尋址開銷的優化跟不上讀取開銷。所以流式讀取更加適合硬盤的本身特性。當然大文件的特點也更適合流式讀取。與流數據訪問對應的是隨機數據訪問，它要求定位、查詢或修改數據的延遲較小，傳統關系型數據庫很符合這一點）
4）、簡化的一致性模型，大部分的HDFS的數據操縱文件都是一次寫入，多次讀取，一個文件一旦經過創建、寫入和關閉后，一半就不需要修改了，這樣簡單的一致性模型，有利於提供高吞吐量的數據訪問模型。
對於上述設計目標，我們會發現，這些在一些場景中是優勢，但是在默寫情況下，會成為其局限性，主要有以下幾點：
1）、不適合低延遲的數據訪問，HDFS是為處理大規模的數據而生的，主要是為達到高的數據吞吐量而設計的，HDFS為了高吞吐量，可以犧牲低延遲，因此我們不能奢望能夠快速的讀出HDFS里的數據。
如果想在Hadoop上對數據做低延遲或實時的數據訪問，在其上HBase是一個很好的解決方案。但是Hbase是一個NOSQL，即面向列的數據庫。
2）、不能搞笑的存儲大量小文件，在HDFS中，有NameNode(Master)節點來管理文件系統的元數據，已相應客戶端請求返回文件位置等，因此文件數量大小的限制就由NameNode(具體的來說是由其內存大小)來決定；另外，在一次數據訪問中，更多的小文件也意味着更多的磁盤尋址操作，以及更多的文件的打開與關閉的開銷,這會大大降低數據的吞吐量，這都有違HDFS的設計目標，也會給NameNode帶來更大的工作壓力。
3）、不支持多用戶的數據寫入和隨機訪問與修改文件，在一個HDFS寫操作中只能有一個用戶對一個文件寫操作，並且自能通過追加的方式將數據寫到文件末尾，在讀一個文件的時候也只能從文件頭部順序讀取文件數據。
目前HDFS還不支持多個用戶對同一個文件的並發寫操作、隨機訪問和修改數據。
HDFS的架構如下：
Hive的數據管理
好了，說完了上面，說說主線了，Hive,這次預研的主要對象就是它了。前圖已經說明，hive是Hadoop上的數據倉庫基礎架構，這么繞口的東西怎么說比較形象呢？說白了就是：
1 它不是存儲數據的，真正的數據存儲在HDFS上
2 它提供一個類SQL的語言，可以對外提供數據存儲、查詢和分析的接口，總之就是比起直接查Hadoop上的數據，要舒服得多了
如圖：
接下來，從三方面來對Hive的數據管理進行分析：
1 元數據存儲
Hive將元數據存儲在RDBMS中，所以通常你在網上會查到安裝hive需要安裝Mysql數據庫或者其它RDBMS數據庫，就是這么回事，對於元數據不太能理解的朋友可以將它理解成數據的基本信息，但是不包含實際數據。
2 數據存儲
Hive沒有專門的數據存儲格式，也沒有為數據建立索引，其所有數據都存在HDFS中，由於Hadoop是批處理系統，任務是高延遲的，在任務提交和處理過程中也會消耗一些時間成本，所以即時Hive處理的數據集非常小，在執行過程中也會出現延遲現象，這樣，Hive的性能就不能和傳統的Oracle相比了 。另外，Hive不提供數據排序和查詢cache功能，不提供在線事物處理，換句話說，不支持與用戶直接對接，而是適合離線處理。當然也不提供實時的查詢和記錄級的更新。Hive適合的是處理不變的大規模數據集（例如網絡日志）上的批量任務，最大的價值是可擴展性、可延展性、良好的容錯率和低約束的數據輸入格式。
hive架構體系如圖：
其中Thrift是一個類似與ICE的通訊框架。
介紹完以上，相信大家對於Hadoop和hive所適用的場景已經一目了然了，具體用不用，取決於具體的業務場景吧~
如果有下一篇，將是Hadoop集群搭建和hive的實例介紹。