一、 Hive的歷史價值
1， 大數據因Hadoop而知名，而Hadoop又因Hive而實用。Hive是Hadoop上的Killer Application，Hive是Hadoop上的數據倉庫，同時Hive兼具有數據倉庫中的存儲和查詢引擎。而Spark SQL是一個更加出色和高級的查詢引擎，並不提供存儲功能。所以Spark SQL無法取代Hive，在現在企業級應用中Spark SQL+Hive成爲了業界使用的大數據最爲高效和流行的趨勢。
2，Hive是Facebook推出的，主要是爲了讓不懂java的工程師也能通過SQL來駕馭Hadoop集羣進行數據分佈式數據的多維度分析，甚至你可以只通過Web界面來直接操作Hive；
3，Hive的核心是把自己的SQL語言即HQL翻譯成MapReduce代碼，然後交給Hadoop集羣執行，也就是說Hive本身是一個單機版本的軟件！！！
4， 由於是用過寫SQL來完成業務需求的，所以相對於編程MapReduce而言，非常的簡單和靈活，能夠非常輕易的滿足業務的需要和多變的場景；
5， Hive幾乎存在於一切使用大數據的公司中！
二、 Hive的架構設計
1，Hive的架構圖如下：
2， 可以通過很多的方式連接到Hive中，Hive安裝時只需在一臺機器上安裝。
3, Metastore（Hive中有哪些數據庫，哪些表，表中有哪些列及其數據類型）；Hive的元數據，默認存儲在Derby中，但是Derby只支持單用戶，所以一般情況下使用MySQL數據庫來存儲Hive的元數據。
4， Hive要操作的數據本身由Hive的配置文件來決定，生產環境下該數據位於HDFS上（其實也就是HDFS上的普通文件，只不過安裝Hive的方式進行組織）；
5，從Hive的角度看，數據就是一張張表，我們操作就是基於SQL的多維度查詢Table 。
6，人們一直努力用Hive來取代傳統的數據倉庫（伸縮性，擴展性），但是以失敗告終！因爲Hive太慢了。所以業界目前趨勢上的黃金組合是使用Hive（數據倉庫的存儲引擎）+Spark SQL(分佈式分析計算查詢引擎)
7，HQL會被Hive解釋優化，並生成查詢計劃，一般情況下而言查詢計劃會被轉化成MapReduce任務。但是型如select * from table 不會轉化爲MapReduce任務。
8，Hive沒有索引（類似於傳統數據庫中的索引）！！
索引是標準的數據庫技術，hive 0.7版本之後支持索引。Hive提供有限的索引功能，這不像傳統的關係型數據庫那樣有“鍵(key)”的概念，用戶可以在某些列上創建索引來加速某些操作，給一個表創建的索引數據被保存在另外的表中。 Hive的索引功能現在還相對較晚，提供的選項還較少。但是，索引被設計爲可使用內置的可插拔的java代碼來定製，用戶可以擴展這個功能來滿足自己的需求。 當然不是說有的查詢都會受惠於Hive索引。用戶可以使用EXPLAIN語法來分析HiveQL語句是否可以使用索引來提升用戶查詢的性能。像RDBMS中的索引一樣，需要評估索引創建的是否合理，畢竟，索引需要更多的磁盤空間，並且創建維護索引也會有一定的代價。 用戶必須要權衡從索引得到的好處和代價。