hbase和hive的差別是什麼,各自適用在什麼場景中?

比起單機的mysql、oracle有什麼優勢,有沒有什麼劣勢?


這個我先簡單梳理下脈絡,其它的可以參考邵兵的回答或網上搜索更加詳細的資料。

對於hbase當前noSql資料庫的一種,最常見的應用場景就是採集的網頁數據的存儲,由於是key-value型資料庫,可以再擴展到各種key-value應用場景,如日誌信息的存儲,對於內容信息不需要完全結構化出來的類CMS應用等。注意hbase針對的仍然是OLTP應用為主。

對於hive主要針對的是OLAP應用,注意其底層不是hbase,而是hdfs分散式文件系統,重點是基於一個統一的查詢分析層,支撐OLAP應用中的各種關聯,分組,聚合類SQL語句。hive一般只用於查詢分析統計,而不能是常見的CUD操作,要知道HIVE是需要從已有的資料庫或日誌進行同步最終入到hdfs文件系統中,當前要做到增量實時同步都相當困難。

和mysql,oracle完全不是相同的應用場景。這個是結構化資料庫,針對的更多的是結構化,事務一致性要求高,業務規則邏輯複雜,數據模型複雜的企業信息化類應用等。包括互聯網應用中的很多業務系統也需要通過結構化資料庫來實現。所以和hbase,hive不是一個層面的東西,不比較。


先放結論:Hbase和Hive在大數據架構中處在不同位置,Hbase主要解決實時數據查詢問題,Hive主要解決數據處理和計算問題,一般是配合使用。

一、區別:

  1. Hbase: Hadoop database 的簡稱,也就是基於Hadoop資料庫,是一種NoSQL資料庫,主要適用于海量明細數據(十億、百億)的隨機實時查詢,如日誌明細、交易清單、軌跡行為等。
  2. Hive:Hive是Hadoop數據倉庫,嚴格來說,不是資料庫,主要是讓開發人員能夠通過SQL來計算和處理HDFS上的結構化數據,適用於離線的批量數據計算。
  • 通過元數據來描述Hdfs上的結構化文本數據,通俗點來說,就是定義一張表來描述HDFS上的結構化文本,包括各列數據名稱,數據類型是什麼等,方便我們處理數據,當前很多SQL ON Hadoop的計算引擎均用的是hive的元數據,如Spark SQL、Impala等;
  • 基於第一點,通過SQL來處理和計算HDFS的數據,Hive會將SQL翻譯為Mapreduce來處理數據;

二、關係

在大數據架構中,Hive和HBase是協作關係,數據流一般如下圖:

  1. 通過ETL工具將數據源抽取到HDFS存儲;
  2. 通過Hive清洗、處理和計算原始數據;
  3. HIve清洗處理後的結果,如果是面向海量數據隨機查詢場景的可存入Hbase
  4. 數據應用從HBase查詢數據;

以上,如有幫助,別忘了點個贊:)

手擼【您可能感興趣的內容】:

如何用形象的比喻描述大數據的技術生態?Hadoop、Hive、Spark 之間是什麼關係?www.zhihu.com圖標如何創建一個大數據平台?具體的步驟www.zhihu.com圖標


1. Hive中的表是純邏輯表,就只是表的定義等,即表的元數據。Hive本身不存儲數據,它完全依賴HDFS和MapReduce。這樣就可以將結構化的數據文件映射為為一張資料庫表,並提供完整的SQL查詢功能,並將SQL語句最終轉換為MapReduce任務進行運行。 而HBase表是物理表,適合存放非結構化的數據。

2. Hive是基於MapReduce來處理數據,而MapReduce處理數據是基於行的模式;HBase處理數據是基於列的而不是基於行的模式,適合海量數據的隨機訪問。

3. HBase的表是疏鬆的存儲的,因此用戶可以給行定義各種不同的列;而Hive表是稠密型,即定義多少列,每一行有存儲固定列數的數據。

4. Hive使用Hadoop來分析處理數據,而Hadoop系統是批處理系統,因此不能保證處理的低遲延問題;而HBase是近實時系統,支持實時查詢。

5. Hive不提供row-level的更新,它適用於大量append-only數據集(如日誌)的批任務處理。而基於HBase的查詢,支持和row-level的更新。

6. Hive提供完整的SQL實現,通常被用來做一些基於歷史數據的挖掘、分析。而HBase不適用與有join,多級索引,表關係複雜的應用場景。


你可以簡單理解為,hive是文件的視圖,hbase是建了索引的key-value表。


網路上有篇deck,題目為 NoSQL and Big Data Processing - Hbase, Hive and Pig (http://www.cs.kent.edu/~jin/Cloud12Spring/HbaseHivePig.pptx),從 關係型資料庫開始,到 NoSQL, 到 CAP 原理,再到 HBase 和 Hive,基本描述了整個數據存儲的演進路線以及原因。

以下是我個人對這篇deck的整理,和deck的結構基本相同。雖然不能直接回答題主的問題,但相信讀完這個deck之後,這個問題一定可以迎刃而解。

1. RDBMS

讓數據集保持在一台單一的機器上是RDBMS提供ACID特性和豐富查詢模型的最好方式。但數據集變大時,垂直擴展(scaling up)帶來諸多限制。企業慢慢發現,通過增加多節點的伺服器進行橫向擴展(scaling out)是一種更經濟和更可行的方式。DBA們對RDBMS採用的橫向擴展的方法主要有主從複製(Master-slave)、分片(Sharding)。

橫向擴展RDBMS – Master/Slave

  • 利用資料庫的複製或鏡像功能,同時在多台資料庫上保存相同的數據,並且將讀操作和寫操作分開,寫操作集中在一台主資料庫上,讀操作集中在多台從資料庫上。複製過程的速度與系統中的從節點數量成反比。

  • 關鍵的讀取可能不正確,因為寫可能沒有來得及被向下傳播;

  • 大數據集可能會造成問題,因為主節點需要將數據複製到從節點;

橫向擴展RDBMS - Sharding

  • 通常來說,在滿足ACID特性的資料庫中進行擴展是非常難的。基於這個原因,對數據進行擴展,這個資料庫本身就必須擁有簡單的模型,將數據分割為N片,然後在單獨的片中執行查詢。數據分割的單元被稱為「shard」。將N片數據分配個M個DBMS進行操作。DBMS並不會去管理數據片,這需由服務開發者自行完成。

  • 不同的分片方法有:

- 垂直分區(Vertical Partitioning):將不需要進行聯合查詢的數據表分散到不同的資料庫伺服器上。

- 水平分區(sharding/分表) 將同一個表的記錄拆分到不同的表甚至是伺服器上,這往往需要一個穩定的演算法來保證讀取時能正確從不同的伺服器上取得數據。比如,將ZIP codes小於50000的客戶存儲在CustomersEast,將ZIP codes大於或等於50000的客戶存儲在CustomersWest。CustomersEast和CustomersWest就成為兩個分區表。方法有 Range-Based Partitioning, Key or Hash-Based partitioning等。

  • 優點與不足

- 對讀取和寫入都有很好的擴展

- 不透明,應用需要做到可識別分區

- 不再有跨分區的關係/joins

- 跨片參照完整性損失

其他RDBMS擴展方法

  • Multi-Master replication:所有成員都響應客戶端數據查詢。多主複製系統負責將任意成員做出的數據更新傳播給組內其他成員,並解決不同成員間並發修改可能帶來的衝突。

  • INSERT only, not UPDATES/DELETES:數據進行版本化處理。

  • No JOINs, thereby reducing query time:Join的開銷很大,而且頻繁訪問會使開銷隨著時間逐漸增加。非規範化(Denormalization)可以降低數據倉庫的複雜性,以提高效率和改善性能。

  • In-memory databases:磁碟資料庫解決的是大容量存儲和數據分析問題,內存資料庫解決的是實時處理和高並發問題。主流常規的RDBMS更多的是磁碟密集型,而不是內存密集型。

2. NoSQL

NoSQL現在被理解為 Not Only SQL 的縮寫,是對非關係型的資料庫管理系統的統稱(正因為此,人們通常理解 NoSQL 是 anti-RDBMS)。

NoSQL 與 RDBMS 存在許多不同點,

- 最重要的是NoSQL不使用SQL作為查詢語言。

- NoSQL 不需要固定的表模式(table schema),也經常會避免使用SQL的JOIN操作,一般有可水平擴展的特徵。

- NoSQL產品會放寬一個或多個 ACID 屬性(CAP定理)

CAP 理論

CAP理論是數據系統設計的基本理論,目前幾乎所有的數據系統的設計都遵循了這個理論。CAP理論指出,分散式系統只能滿足以下三項中的兩項而不可能滿足全部三項,

  • 一致性(Consistency)(所有節點在同一時間具有相同的數據)

  • 可用性(Availability)(保證每個請求不管成功或者失敗都有響應)

  • 分區容忍性(Partition tolerance)(系統中任意信息的丟失或失敗不會影響系統的繼續運作)

一致性有兩種類型:

- strong consistency – ACID(Atomicity Consistency Isolation Durability):對於關係型資料庫,要求更新過的數據能被後續所有的訪問都看到,這是強一致性。

- weak consistency – BASE(Basically Available Soft-state Eventual consistency )

-- Basically Available - system seems to work all the time (基本可用)

-- Soft State - it doesn"t have to be consistent all the time (不要求所有時間都一致)

-- Eventually Consistent - becomes consistent at some later time (最終一致性)

對於分散式數據系統(scale out),分區容忍性是基本要求,否則就失去了價值。因此只能在一致性和可用性上做取捨,如何處理這種取捨正是目前NoSQL資料庫的核心焦點。幾乎所有的情況都是犧牲一致性而換取高可用性。當然,犧牲一致性,只是不再要求關係資料庫中的強一致性,而是只要系統能達到最終一致性即可。考慮到客戶體驗,這個最終一致的時間窗口,要儘可能的對用戶透明,也就是需要保障「用戶感知到的一致性」。通常是通過數據的多份非同步複製來實現系統的高可用和數據的最終一致性的。

3. HBase

HBase is an open-source, distributed, column-oriented database built on top of HDFS (or KFS) based on BigTable!

按照CAP理論,HBase屬於C+P類型的系統。HBase是強一致性的(僅支持單行事務)。每一行由單個區域伺服器(region server)host,行鎖(row locks)和多版本並發控制(multiversion concurrency control)的組合被用來保證行的一致性。

There are three types of lookups:

  • Fast lookup using row key and optional timestamp.

  • Range scan from region start to end.

  • Full table scan (全表掃描)

Access or manipulate

- Programmatic access via Java, REST, or Thrift APIs.

- Scripting via JRuby.

HBase benefits than RDBMS

- No real indexes

- Automatic partitioning

- Scale linearly and automatically with new nodes

- Commodity hardware

- Fault tolerance

- Batch processing

4. Hive

- Provide higher-level language (HQL, like SQL) to facilitate large-data processing

- Higher-level language 「compiles down」 to Hadoop Map/Reduce jobs

5. Hive + HBase

Reasons to use Hive on HBase:

  • A lot of data sitting in HBase due to its usage in a real-time environment, but never used for analysis

  • Give access to data in HBase usually only queried through MapReduce to people that don』t code (business analysts)

  • When needing a more flexible storage solution, so that rows can be updated live by either a Hive job or an application and can be seen immediately to the other

References

1. Hbase, Hive and Pig: http://www.cs.kent.edu/~jin/Cloud12Spring/HbaseHivePig.pptx

2. Slashdot效應

3. RDBMS vs. NoSQL:反派為什麼會得以存活並發展壯大-CSDN.NET

4. Partition (database)

5. Multi-master replication

6. 內存資料庫的基本原理與應用

7. NoSQL

8. CAP定理

9. 如何「打敗」CAP定理

10. Eventual consistency

11. HBase -
Apache HBase? Home

12. hbase介紹 - 阿里數據平台 alidata.org

13. 細數Google HBase與BigTable區別在哪裡?


簡單的說,HBase是OLTP,Hive是OLAP

比起單機的Oracle和MySQL,好處就是伸縮性好啊

劣勢就是分散式帶來的可用性,一致性,分區容忍性~等問題,以及分散式事務難以實現。


Hive的底層可以是HBase或者HDFS上存儲的文件。

Hive的作用是把HQL翻譯成MapReduce程序,從而減少分析人員每次都要寫冗長Java程序的工作量。單次Hive查詢都需要耗費分鐘級以上的時間(哪怕一個再小的表),因此無法作為web後端的資料庫使用。

HBase可以替代MySQL使用,至少淘寶就是這麼做了。HBase是建造在HDFS基礎上的分散式資料庫,可以支持海量數據(比MySQL高一到兩個量級)的存儲和查詢。還不容易丟失數據。


HBase是一種NoSQL,通常被稱為Hadoop Database,它是開源並基於Google Big Table白皮書,HBase運行在HDFS之上,因此使它具有高度可擴展性,並支持Hadoop map-reduce程序設計模型。HBase有兩種訪問方式:通過行鍵進行隨機訪問;通過map-reduce離線或批訪問。

谷歌曾經面對過一個挑戰的問題:如何能在整個互聯網上提供實時的搜索結果?答案是它本質上需要將互聯網緩存,並重新定義在這樣龐大的緩存上快速查找的新方法。為了達到這個目的,定義如下技術:

  • 谷歌文件系統GFS:可擴展分散式文件系統,用於大型的、分散式的、數據密集型的應用程序。

  • BigTable:分散式存儲系統,用於管理被設計成規模很大的結構化數據:來自數以千計商用伺服器的PB級別的數據。

  • MapReduce:一個程序模型,用於處理和生成大數據集的相關實現。

在谷歌發布這些技術的文檔之後, 不久以後我們就看到了它們的開源實現版本 ,就在2007年,Mike Cafarella發布了BigTable開源實現的代碼,他稱其為HBase,自此,HBase成為Apache的頂級項目,並運行在Facebook,Twitter,Adobe……僅舉幾個例子。

HBase不是一個關係型資料庫,它需要不同的方法定義你的數據模型,HBase實際上定義了一個四維數據模型,下面就是每一維度的定義:

  • 行鍵:每行都有唯一的行鍵,行鍵沒有數據類型,它內部被認為是一個位元組數組。

  • 列簇:數據在行中被組織成列簇,每行有相同的列簇,但是在行之間,相同的列簇不需要有相同的列修飾符。在引擎中,HBase將列簇存儲在它自己的數據文件中,所以,它們需要事先被定義,此外,改變列簇並不容易。

  • 列修飾符:列簇定義真實的列,被稱之為列修飾符,你可以認為列修飾符就是列本身。

  • 版本:每列都可以有一個可配置的版本數量,你可以通過列修飾符的制定版本獲取數據。

HBase Four-Dimensional Data Model

如圖1中所示,通過行鍵獲取一個指定的行,它由一個或多個列簇構成,每個列簇有一個或多個列修飾符(圖1中稱為列),每列又可以有一個或多個版本。為了獲取指定數據,你需要知道它的行鍵、列簇、列修飾符以及版本。當設計HBase數據模型時,對考慮數據是如何被獲取是十分有幫助的。你可以通過以下兩種方式獲得HBase數據:

  • 通過他們的行鍵,或者一系列行鍵的表掃描。

  • 使用map-reduce進行批操作

這種雙重獲取數據的方法使得HBase變得十分強大,典型地,在Hadoop中存儲數據意味著它對離線或批處理方式分析是有益的(尤其是批處理分析),但是,對實時獲取是不必要的。HBase通過key/value存儲來支持實時分析,以及通過map-reduce支持批處理分析。讓我們首先來看實時數據獲取,作為key/value存儲,key是行鍵,value是列簇的集合,如圖2所示。

HBase as a Key/Value Store

如你在圖2中看到的,key是我們所提到過的行鍵,value是列簇的集合。你可以通過key檢索到value,或者換句話說,你可以通過行鍵「得到」行,或者你能通過給定起始和終止行鍵檢索一系列行,這就是前面提到的表掃描。你不能實時的查詢一個列的值,這就引出了一個重要的話題:行鍵的設計。

有兩個原因令行鍵的設計十分重要:

  • 表掃描是對行鍵的操作,所以,行鍵的設計控制著你能夠通過HBase執行的實時/直接獲取量。

  • 當在生產環境中運行HBase時,它在HDFS上部運行,數據基於行鍵通過HDFS,如果你所有的行鍵都是以user-開頭,那麼很有可能你大部分數據都被分配一個節點上(違背了分散式數據的初衷),因此,你的行鍵應該是有足夠的差異性以便分散式地通過整個部署。

你定義行鍵的方式取決於你想怎樣存取那些行。如果你想以用戶為基礎存儲數據,那麼一個策略是利用位元組隊列在HBase中存儲行鍵,所以我們可以創建一個用戶ID的哈希(例如MD5或SHA-1),然後在哈希後面附上時間(long類型)。使用哈希有兩個重點:(1)是它能夠將value分散開,數據能夠分散式地通過簇,(2)是它確保key的長度是一致的,以更加容易在表掃描中使用。

講了足夠多的理論,下面部分向你展示如何搭建HBase環境,並如何通過命令行使用。

你可以從Apache網站下載HBase,HBase團隊推薦你在UNIX/Linux環境下安裝HBase,如果你想在Windows下運行,你需要先安裝Cygwin,並在這上運行HBase。當你下載完這些文件,解壓到硬碟上。此外,你還需要安裝Java環境,如果你還沒有,從Oracle網站下載Java環境。在環境配置中添加名為HBASE_HOME的變數,值為你解壓HBase文件的根目錄,隨後,執行bin文件夾下的start-hbase.sh腳本,它會在下面目錄輸出日誌文件:

$HBASE_HOME/logs/

你可以在瀏覽器中輸入下面URL測試是否安裝正確:

http://localhost:60010

如果安裝正確,你應該看到下面界面。

HBase Management Screen

讓我們開始用命令行操作HBase,在HBase bin目錄下執行下面命令:

./hbase shell

你應該看到如下類似的輸出:

1

2

3

4

5

6

7

HBase Shell; enter "help&" for list of supported commands.

Type "exit&" to leave the HBase Shell

Version 0.98.5-hadoop2, rUnknown, Mon Aug 4 23:58:06 PDT 2014

hbase(main):001:0&>

創建一個名為PageViews的表,並具有名為info的列簇:

1

2

3

4

5

hbase(main):002:0&> create "PageViews", "info"

0 row(s) in 5.3160 seconds

=&> Hbase::Table - PageViews

每張表至少要有一個列簇,因此我們創建了info,現在,看看我們的表,執行下面list命令:

1

2

3

4

5

6

7

8

9

hbase(main):002:0&> list

TABLE

PageViews

1 row(s) in 0.0350 seconds

=&> ["PageViews"]

如你所見,list命令返回一個名為PageViews的表,我們可以通過describe命令得到表的更多信息:

1

2

3

4

5

6

7

8

9

10

11

12

13

hbase(main):003:0&> describe "PageViews"

DESCRIPTION ENABLED

"PageViews", {NAME =&> "info", DATA_BLOCK_ENCODING =&> "NONE", BLOOMFILTER =&> "ROW",

REPLICATION_SCOPE =&> "0", VERSIONS =&> "1", COMPRESSION =&> "NONE true

", MIN_VERSIONS =&> "0", TTL =&> "FOREVER", KEEP_DELETED_CELLS =&> "false",

BLOCKSIZE =&> "65536", IN_MEMORY =&> "false", BLOCKCACHE =&> "true"}

1 row(s) in 0.0480 seconds

Describe命令返回表的詳細信息,包括列簇的列表,這裡我們創建的僅有一個:info,現在為表添加以下數據,下面命令是在info中添加新的行:

1

2

3

hbase(main):004:0> put #039;PageViews#039;, #039;rowkey1#039;, #039;info:page#039;, #039;/mypage#039;

0 row(s) in 0.0850 seconds

Put命令插入一條行鍵為rowkey1的新紀錄,指定在info下的page列,插入值為/mypage的記錄,我們隨後可以通過get命令通過行鍵rowkey1查詢到這條記錄:

1

2

3

4

5

6

7

hbase(main):005:0&> get "PageViews", "rowkey1"

COLUMN CELL

info:page timestamp=1410374788088, value=/mypage

1 row(s) in 0.0250 seconds

你可以看到列info:page,或者更多具體的列,其值為/mypage,並帶有時間戳表明該條記錄是什麼時候插入的。讓我們在做表掃描之前再添加一行:

1

2

3

hbase(main):006:0&> put "PageViews", "rowkey2", "info:page", "/myotherpage"

0 row(s) in 0.0050 seconds

現在我們有兩行記錄了,讓我們查詢出PageViews表的所有記錄:

1

2

3

4

5

6

7

8

9

hbase(main):007:0&> scan "PageViews"

ROW COLUMN+CELL

rowkey1 column=info:page, timestamp=1410374788088, value=/mypage

rowkey2 column=info:page, timestamp=1410374823590, value=/myotherpage

2 row(s) in 0.0350 seconds

如前面所提到的,我們不能查詢本身,但是我們可以對錶進行scan操作,如果你執行scan table命令,它會返回表中所有行,這很有可能不是你想要做的。你可以給出行的範圍來限制返回的結果,讓我們插入一帶有s開頭行鍵的新記錄:

1

hbase(main):012:0&> put "PageViews", "srowkey2", "info:page", "/myotherpage"

現在,如果我增加點限制,想查詢行鍵在r和s之間的記錄,可以使用如下結構:

1

2

3

4

5

6

7

8

9

hbase(main):014:0&> scan "PageViews", { STARTROW =&> "r", ENDROW =&> "s" }

ROW COLUMN+CELL

rowkey1 column=info:page, timestamp=1410374788088, value=/mypage

rowkey2 column=info:page, timestamp=1410374823590, value=/myotherpage

2 row(s) in 0.0080 seconds

這個scan返回了僅有s開頭的記錄,這個類比是基於全行鍵上的,所以rowkey1比r大,所有它被返回了。另外,scan的結果包含了所指範圍的STARTROW,但不包含ENDROW,注意,ENDROW不是必須指定的,如果我們執行相同查詢只給出了STARTROW,那麼我們會得到行鍵比r大的所有記錄。

1

2

3

4

5

6

7

8

9

10

11

hbase(main):013:0&> scan "PageViews", { STARTROW =&> "r" }

ROW COLUMN+CELL

rowkey1 column=info:page, timestamp=1410374788088, value=/mypage

rowkey2 column=info:page, timestamp=1410374823590, value=/myotherpage

srowkey2 column=info:page, timestamp=1410375975965, value=/myotherpage

3 row(s) in 0.0120 seconds


你試著用hive和hbase分別插入和刪除一條記錄(如果可以的話)就能清楚的知道差別了。


對於剛接觸大數據的用戶來說,要想區分Hive與HBase是有一定難度的。本文將嘗試從其各自的定義、特點、限制、應用場景等角度來進行分析,以作拋磚引玉之用。

Hive是什麼?

Apache Hive是一個構建於Hadoop(分散式系統基礎架構)頂層的數據倉庫,注意這裡不是資料庫。Hive可以看作是用戶編程介面,它本身不存儲和計算數據;它依賴於HDFS(Hadoop分散式文件系統)和MapReduce(一種編程模型,映射與化簡;用於大數據並行運算)。其對HDFS的操作類似於SQL—名為HQL,它提供了豐富的SQL查詢方式來分析存儲在HDFS中的數據;HQL經過編譯轉為MapReduce作業後通過自己的SQL 去查詢分析需要的內容;這樣一來,即使不熟悉MapReduce 的用戶也可以很方便地利用SQL 語言查詢、匯總、分析數據。而MapReduce開發人員可以把己寫的mapper 和reducer 作為插件來支持Hive 做更複雜的數據分析。

HBase是什麼?

Apache HBase是運行於HDFS頂層的NoSQL(=Not Only SQL,泛指非關係型的資料庫)資料庫系統。區別於Hive,HBase具備隨即讀寫功能,是一種面向列的資料庫。HBase以表的形式存儲數據,表由行和列組成,列劃分為若干個列簇(row family)。例如:一個消息列簇包含了發送者、接受者、發送日期、消息標題以及消息內容。每一對鍵值在HBase會被定義為一個Cell,其中,鍵由row-key(行鍵),列簇,列,時間戳構成。而在HBase中每一行代表由行鍵標識的鍵值映射組合。Hbase目標主要依靠橫向擴展,通過不斷增加廉價的商用伺服器,來增加計算和存儲能力。

特性

遵從JDBC的Hive不但可以讓具SQL知識的用戶來間接執行MapReduce作業,同時裡面也整合了目前基於SQL的操作工具。不過,由於默認的數據讀取是全表遍歷的,其時間的耗費也不可避免地相對較大。儘管如此,不盡相同的Hive分區方法,其遍歷讀取的數據量也是能夠有所限制的。Hive分區允許對存儲在獨立文件上的數據進行篩選查詢,返回的是篩選後的數據。例如針對日期的日誌文件訪問,前提是該類文件的文件名包含日期信息。

HBase以鍵值對的形式儲存數據。其包含了4種主要的數據操作方式:

添加或更新數據行

掃描獲取某範圍內的cells

為某一具體數據行返回對應的cells

從數據表中刪除數據行/列,或列的描述信息

列信息可用於獲取數據變動前的取值(透過HBase壓縮策略可以刪除列信息歷史記錄來釋放存儲空間)。

限制

Hive不支持常規的SQL更新語句,如:數據插入,更新,刪除。因為其對數據的操作是針對整個數據表的。同時該特點也使得數據查詢用時以數分鐘甚至數小時來進行計算。此外,其MapReduce轉換過程必須遵從預定義的轉換規則。

HBase的數據查詢是有一套屬於自己類似SQL的操作語言的,這個需要一定的學習來掌握。此外,要運行HBase,ZooKeeper是需要配備的。ZooKeeper是一個針對大型分散式系統的可靠協調系統,提供的功能包括:配置維護、名字服務、分散式同步、組服務等。

應用舉例

Hive適用於網路日誌等數據量大、靜態的數據查詢。例如:用戶消費行為記錄,網站訪問足跡等。但是不適用於聯機實時在線查詢的場合。

HBase能在大數據聯機實時查詢場合大展身手。例如:Fackbook就利用其對用戶間的傳送的消息進行聯機實時分析。

小結

Hive與HBase兩者是基於Hadoop上不同的技術。Hive是一種能執行MapReduce作業的類SQL編程介面,Hbase是一種非關係型的資料庫結構。結合這兩者自身的特點,互相結合使用或許能收到相得益彰的效果。例如:利用Hive處理靜態離線數據,利用HBase進行聯機實時查詢,而後對兩者間的結果集進行整合歸併,從而使得數據完整且永葆青春,為進一步的商業分析提供良好支持。


共同點: 1.hbase與hive都是架構在hadoop之上的。都是用hadoop作為底層存儲

區別:

2.Hive是建立在Hadoop之上為了減少MapReduce jobs編寫工作的批處理系統,HBase是為了支持彌補Hadoop對實時操作的缺陷的項目 。

3.想像你在操作RMDB資料庫,如果是全表掃描,就用Hive+Hadoop,如果是索引訪問,就用HBase+Hadoop 。

4.Hive query就是MapReduce jobs可以從5分鐘到數小時不止,HBase是非常高效的,肯定比Hive高效的多。

5.Hive本身不存儲和計算數據,它完全依賴於HDFS和MapReduce,Hive中的表純邏輯。

6.hive借用hadoop的MapReduce來完成一些hive中的命令的執行

7.hbase是物理表,不是邏輯表,提供一個超大的內存hash表,搜索引擎通過它來存儲索引,方便查詢操作。

8.hbase是列存儲。

9.hdfs作為底層存儲,hdfs是存放文件的系統,而Hbase負責組織文件。

10.hive需要用到hdfs存儲文件,需要用到MapReduce計算框架。


個人的理解:

Hive與HBase區別類似於蜜蜂與蜂蜜的區別,不太恰當,但二者差別巨大。共同點可能在於Hive與HBase都是基於HDFS的應用。差別在於,他們不是一個層次的東西。Hive是為了擴展RDBMS而在HDFS上實現的數據倉庫工具,因而他類似於RDBMS也提供了DDL、DML、DQL等查詢語句,這是其最大的特點(之一吧。其查詢執行引擎也同傳統RDBMS不同,這也是較突出的特點)。HBase是為了實現海量數據的高效隨機讀取而在HDFS上實現的KV資料庫,主要特點是列存儲,而Hive是同RDBMS類似的行存儲。因而二者的主要目的不同導致了他們的應用場景非常不同,總結如下:

Hive應用場景

1、數據倉庫,基於HDFS的一個數據倉庫工具,可以查詢和管理PB級別的分散式數據

2、數據分析(數據匯總)

3、非實時分析(日誌分析,文本分析)

4、 數據挖掘(用戶行為分析,興趣分區,區域展示)

HBase應用場景

1、NoSql數據倉庫,基於HDFS的Key-Value資料庫,可同時處理PB級別結構和非結構數據

2、實時分析(大數據實時分析)


看到那麼多照本宣科的解釋,怒答一下:

hbase是個資料庫,NoSQL資料庫

hive是個殼子,針對一系列的存儲,弄出一個SQL的介面出來了

能一樣嗎?能一樣嗎?

hive可以掛接hbase,即針對hbase開放出SQL的介面

hbase可讀寫,提供了自己的API,不用Hive,也能操作HBase

hbase就是個大寫的Key-Value,人家的Value很大很大,多個列拼起來的,所以適合於根據rowkey查找value的場合,其它的場合就是傻乎乎的從頭查到尾啊!

hive默認的掛接HDFS的文本文件,只支持SQL查詢,沒有任何索引,所以也只是傻乎乎的從頭查到尾了


HBase是個基於HDFS的資料庫。Hive是用SQL替代寫MR的編程框架,做Hadoop上會把用戶提交的SQL語句做語法分析,執行計劃等一堆亂七八糟的事後變成MR job提交去跑,返回結果給用戶。不然每次都寫MR很麻煩的,有這個寫個SQL就可以拿到等效的結果,很適合運營童鞋用。當然Hive也有HBase的Connector,用這個Connnector後可以寫SQL查詢HBase的數據而不是HDFS,不過一般不這麼搞。像用SQL on HBase的話,可以用下Phoenix,新手第一次用的感覺會覺得很像是MySQL


Hive 是個ql引擎,hbase是個存儲引擎,沒法對比。

就像mysql, 有個ql引擎解析處理sql語句,另外用innodb,myisam,ndb做數據存儲引擎。

Hive可以用hdfs做存儲,也可以用hbase做數據存儲引擎。

與hive對等的是類似kylin這樣的。


hbase就是一個存儲key-value的大map,hive是一個做統計處理的工具,類似於awk類的。

所以如果你是一條一條讀寫記錄用hbase,如果需要對大量數據做分析統計用hive。


完全不同應用場景吧,HBase 速度比 Hive 快了不知道多少。

HBase 是非關係型資料庫(KV型), 對 key 做索引,查詢速度非常快(相比較 Hive ),適合實時查詢;而Hive是關係型數據結構,適合做後期數據分析。

和單機的MySQL,Oracle比較的話,Hive的優點是可以存儲海量數據,只是查詢速度比較慢。


著作權歸作者所有。

商業轉載請聯繫作者獲得授權,非商業轉載請註明出處。

作者:justinzhang

鏈接:HIVE和HBASE區別 - justinzhang - 博客園

來源:博客園

1. 兩者分別是什麼?

Apache Hive是一個構建在Hadoop基礎設施之上的數據倉庫。通過Hive可以使用HQL語言查詢存放在HDFS上的數據。HQL是一種類SQL語言,這種語言最終被轉化為Map/Reduce. 雖然Hive提供了SQL查詢功能,但是Hive不能夠進行交互查詢--因為它只能夠在Haoop上批量的執行Hadoop。

Apache HBase是一種Key/Value系統,它運行在HDFS之上。和Hive不一樣,Hbase的能夠在它的資料庫上實時運行,而不是運行MapReduce任務。Hive被分區為表格,表格又被進一步分割為列簇。列簇必須使用schema定義,列簇將某一類型列集合起來(列不要求schema定義)。例如,「message」列簇可能包含:「to」, 」from」 「date」, 「subject」, 和」body」. 每一個 key/value對在Hbase中被定義為一個cell,每一個key由row-key,列簇、列和時間戳。在Hbase中,行是key/value映射的集合,這個映射通過row-key來唯一標識。Hbase利用Hadoop的基礎設施,可以利用通用的設備進行水平的擴展。

2. 兩者的特點

Hive幫助熟悉SQL的人運行MapReduce任務。因為它是JDBC兼容的,同時,它也能夠和現存的SQL工具整合在一起。運行Hive查詢會花費很長時間,因為它會默認遍歷表中所有的數據。雖然有這樣的缺點,一次遍歷的數據量可以通過Hive的分區機制來控制。分區允許在數據集上運行過濾查詢,這些數據集存儲在不同的文件夾內,查詢的時候只遍歷指定文件夾(分區)中的數據。這種機制可以用來,例如,只處理在某一個時間範圍內的文件,只要這些文件名中包括了時間格式。

HBase通過存儲key/value來工作。它支持四種主要的操作:增加或者更新行,查看一個範圍內的cell,獲取指定的行,刪除指定的行、列或者是列的版本。版本信息用來獲取歷史數據(每一行的歷史數據可以被刪除,然後通過Hbase compactions就可以釋放出空間)。雖然HBase包括表格,但是schema僅僅被表格和列簇所要求,列不需要schema。Hbase的表格包括增加/計數功能。

3. 限制

Hive目前不支持更新操作。另外,由於hive在hadoop上運行批量操作,它需要花費很長的時間,通常是幾分鐘到幾個小時才可以獲取到查詢的結果。Hive必須提供預先定義好的schema將文件和目錄映射到列,並且Hive與ACID不兼容。

HBase查詢是通過特定的語言來編寫的,這種語言需要重新學習。類SQL的功能可以通過Apache Phonenix實現,但這是以必須提供schema為代價的。另外,Hbase也並不是兼容所有的ACID特性,雖然它支持某些特性。最後但不是最重要的--為了運行Hbase,Zookeeper是必須的,zookeeper是一個用來進行分散式協調的服務,這些服務包括配置服務,維護元信息和命名空間服務。

4. 應用場景

Hive適合用來對一段時間內的數據進行分析查詢,例如,用來計算趨勢或者網站的日誌。Hive不應該用來進行實時的查詢。因為它需要很長時間才可以返回結果。

Hbase非常適合用來進行大數據的實時查詢。Facebook用Hbase進行消息和實時的分析。它也可以用來統計Facebook的連接數。

5. 總結

Hive和Hbase是兩種基於Hadoop的不同技術--Hive是一種類SQL的引擎,並且運行MapReduce任務,Hbase是一種在Hadoop之上的NoSQL 的Key/vale資料庫。當然,這兩種工具是可以同時使用的。就像用Google來搜索,用FaceBook進行社交一樣,Hive可以用來進行統計查詢,HBase可以用來進行實時查詢,數據也可以從Hive寫到Hbase,設置再從Hbase寫回Hive。


Hive不是資料庫,Hive不是資料庫,Hive不是資料庫!!!關鍵問題強調三遍。

Hive就是一種HiveQL(查詢語句)的翻譯工具,將HiveQL翻譯成MapReduce程序,提交到集群去運行。之所以Hive會被誤以為是資料庫,可能是因為它的元資料庫(一般設置為Mysql)的原因。假如現在要把一句HiveQL語句翻譯成MapReduce程序的話,那麼我們肯定需要知道這個HiveQL語句中的表的文件的位置,以及這張表裡面有哪些欄位等信息,這些信息就被存儲在元資料庫中。Hive執行HiveQL語句時,先是從元資料庫中查詢表文件的存儲位置以及欄位信息,然後拿著這些信息作為參數傳給寫好的MapReduce程序,最後提交執行獲取結果。所以,Hive本質來說就是一個HiveQL語句的翻譯工具,主要用於查詢。

而對於HBase,它就是一個資料庫,裡面存放了各種表(為了方便,可以把理解成windows上的Excel)。很明顯,因為是表,所以可以很方便地進行增刪改查的操作。

這裡多說一點,HBase和HDFS之間的關係。HDFS是一種分散式的文件存儲系統,它上面可以存儲各種各樣的文件,例如文本文件、HBase的表文件。即HBase最終是將它的文件存儲在HDFS上面。類似於windows上的資料庫文件最終放在磁碟上面(當然不是很嚴謹,但是這樣好理解些)


看了這麼多回答。比較贊同 ershou 的答案

Hbase 是資料庫,是有實體表的,列式存儲,基於Nosql方式查詢。

而Hive 的目的不是存儲或查詢,可以認為它本身就沒有實體表,只是HDFS上是結構化文件的視圖。。。Hive 一般用於ETL,Hive的SQL本身就可以轉化為MapReduce。所以使用Hive目的,就是方便實現MapReduce程序來做一些ETL的工作。


推薦閱讀:

目前雲計算在醫療上應用的阻礙是什麼?如何在雲存儲里實現醫療信息的安全保障呢?目前的解決方案都是什麼呢?
奇虎宣布360查殺率世界前五,他的技術到底可靠嗎?
如果你有機會發射一顆衛星,你會用它來做什麼?
中國雲計算公司實力和發達國家的雲計算公司差距有多大?服務怎麼樣?
海量數據,分散式計算,並行計算 ,虛擬化與雲計算的關係是怎樣的?

TAG:雲計算 | Hadoop | HBase | Hive | 大數據 |