首先Hive的底層首先是MR,是屬於批處理處理時間相對較長，不屬於實時讀寫。在其架構上HBase和Hive有很大的區別.

　　架構介紹：

　　Hive架構

　　–(1)用戶接口主要有三個：CLI，Client 和 WUI。其中最常用的是CLI，Cli啟動的時候，會同時啟動一個Hive副本。Client是Hive的客戶端，用戶連接至HiveServer。在啟動 Client模式的時候，需要指出Hive Server所在節點，並且在該節點啟動Hive Server。 WUI是通過瀏覽器訪問Hive。

　　–(2)Hive將元數據存儲在數據庫中，如mysql、derby。Hive中的元數據包括表的名字，表的列和分區及其屬性，表的屬性(是否為外部表等)，表的數據所在目錄等。

　　–(3)解釋器、編譯器、優化器完成HQL查詢語句從詞法分析、語法分析、編譯、優化以及查詢計劃的生成。生成的查詢計劃存儲在HDFS中，並在隨後有MapReduce調用執行。

　　–(4)Hive的數據存儲在HDFS中，大部分的查詢、計算由MapReduce完成(包含*的查詢，比如select* from tbl不會生成MapRedcue任務)。

　　HBase 架構

　　Client

　　包含訪問HBase的接口並維護cache來加快對HBase的訪問

　　Zookeeper

　　保證任何時候，集群中只有一個master

　　存貯所有Region的尋址入口。

　　實時監控Region server的上線和下線信息。並實時通知Master

　　存儲HBase的schema和table元數據

　　Master

　　為Region server分配region

　　負責Region server的負載均衡

　　發現失效的Region server並重新分配其上的region

　　管理用戶對table的增刪改操作

　　RegionServer

　　Region server維護region，處理對這些region的IO請求

　　Region server負責切分在運行過程中變得過大的region

　　Memstore 與 storefile

　　一個region由多個store組成，一個store對應一個CF(列族)

　　store包括位於內存中的memstore和位於磁盤的storefile寫操作先寫入memstore，當memstore中的數據達到某個閾值，hregionserver會啟動flashcache進程寫入storefile，每次寫入形成單獨的一個storefile

　　當storefile文件的數量增長到一定閾值後，系統會進行合並(minor、major compaction)，在合並過程中會進行版本合並和刪除工作(majar)，形成更大的storefile

　　當一個region所有storefile的大小和數量超過一定閾值後，會把當前的region分割為兩個，並由hmaster分配到相應的regionserver服務器，實現負載均衡

　　客戶端檢索數據，先在memstore找，找不到再找storefile

　　– HBase能提供實時計算服務主要原因是由其架構和底層的數據結構決定的，即由LSM-Tree(Log-Structured Merge-Tree) +HTable(region分區) + Cache決定——客戶端可以直接定位到要查數據所在的HRegion server服務器，然後直接在服務器的一個region上查找要匹配的數據，並且這些數據部分是經過cache緩存的。

　　–前面說過HBase會將數據保存到內存中，在內存中的數據是有序的，如果內存空間滿了，會刷寫到HFile中，而在HFile中保存的內容也是有序的。當數據寫入HFile後，內存中的數據會被丟棄。

　　–多次刷寫後會產生很多小文件，後臺線程會合並小文件組成大文件，這樣磁盤查找會限制在少數幾個數據存儲文件中。HBase的寫入速度快是因為它其實並不是真的立即寫入文件中，而是先寫入內存，隨後異步刷入HFile。所以在客戶端看來，寫入速度很快。另外，寫入時候將隨機寫入轉換成順序寫，數據寫入速度也很穩定。

　　–而讀取速度快是因為它使用了LSM樹型結構，而不是B或B+樹。磁盤的順序讀取速度很快，但是相比而言，尋找磁道的速度就要慢很多。HBase的存儲結構導致它需要磁盤尋道時間在可預測範圍內，並且讀取與所要查詢的rowkey連續的任意數量的記錄都不會引發額外的尋道開銷。比如有5個存儲文件，那麽最多需要5次磁盤尋道就可以。而關系型數據庫，即使有索引，也無法確定磁盤尋道次數。而且，HBase讀取首先會在緩存(BlockCache)中查找，它采用了LRU(最近最少使用算法)，如果緩存中沒找到，會從內存中的MemStore中查找，只有這兩個地方都找不到時，才會加載HFile中的內容，而上文也提到了讀取HFile速度也會很快，因為節省了尋道開銷。

　　–如果快速查詢(從磁盤讀數據)，hbase是根據rowkey查詢的，只要能快速的定位rowkey,就能實現快速的查詢，主要是以下因素：

　　1、hbase是可劃分成多個region,並且到達一定界限會將region橫向切分

　　2、鍵是排好序的

　　3、按列存儲的

　　–列如：能快速找到行所在的region(分區)，假設表有10億條記錄，占空間1TB,分列成了500個region,1個region占2個G.最多讀取2G的記錄，就能找到對應記錄;

　　–其次，是按列存儲的，其實是列族，假設分為3個列族，每個列族就是666M，如果要查詢的東西在其中1個列族上，1個列族包含1個或者多個HStoreFile，假設一個HStoreFile是128M，該列族包含5個HStoreFile在磁盤上.剩下的在內存中。

　　然後，排好序了的，你要的記錄有可能在最前面，也有可能在最後面，假設在中間，我們只需遍歷2.5個HStoreFile共300M。

　　最後，每個HStoreFile(HFile的封裝)，是以鍵值對(key-value)方式存儲，只要遍歷一個個數據塊中的key的位置，並判斷符合條件可以了。一般key是有限的長度，假設跟value是1:20(忽略HFile其他快，只需要15M就可獲取的對應的記錄，按照磁盤的訪問100M/S，只需0.15秒。加上塊緩存機制(LRU原則)，會取得更高的效率。

　　實時查詢，可以認為是從內存中查詢，一般響應時間在1秒左右。HBase的機制是將數據先寫入到內存中(緩存Buffer中)，當數據量達到一定的量(如128M)，產生溢寫磁盤操作，在內存中，是不進行數據的更新或合並操作的，只增加數據，這使得用戶的寫操作只要進入內存中就可以立即返回，保證了HBaseI/O的高性能。

?

HBase相對Hive查詢速度快的對比