帶你讀《HBase原理與實踐》之一：HBase概述

資料庫技術叢書 點選檢視第二章 點選檢視第三章 HBase原理與實踐

胡　争　範欣欣　著

第1章

HBase概述

HBase是目前非常熱門的一款分布式KV（KeyValue，鍵值）資料庫系統，無論是網際網路行業還是其他傳統IT行業都在大量使用。尤其是近幾年随着國内大資料理念的普及，HBase憑借其高可靠、易擴充、高性能以及成熟的社群支援，受到越來越多企業的青睐。許多大資料系統都将HBase作為底層資料存儲服務，例如Kylin、OpenTSDB等。

本章作為全書的開篇，将從HBase的曆史發展、資料模型、體系結構、系統特性幾個方面，向讀者介紹這位主角。

1.1　HBase前生今世

1. HBase曆史發展

要說清楚HBase的來龍去脈，還得從Google當年風靡一時的“三篇論文”—GFS、MapReduce、BigTable說起。2003年Google在SOSP會議上發表了大資料曆史上第一篇公認的革命性論文—《GFS: The Google File System》，之是以稱其為“革命性”是有多方面原因的：首先，Google在該論文中第一次揭示了如何在大量廉價機器基礎上存儲海量資料，這讓人們第一次意識到海量資料可以在不需要任何高端裝置的前提下實作存儲，換句話說，任何一家公司都有技術實力存儲海量資料，這為之後流行的海量資料處理奠定了堅實的基礎。其次，GFS展現了非常超前的設計思想，以至于十幾年之後的今天依然指導着大量的分布式系統設計，可以說，任何從事分布式系統開發的人都有必要反複閱讀這篇經典論文。

2004年，Google又發表了另一篇非常重要的論文—《MapReduce: Simplef?ied Data Processing on Large Clusters》，這篇論文論述了兩個方面的内容，其中之一是MapReduce的程式設計模型，在後來的很多讨論中，人們對該模型褒貶不一，該程式設計模型在之後的技術發展中接受了大量的架構性改進，演變成了很多其他的程式設計模型，例如DAG模型等。當然，MapReduce模型本身作為一種基礎模型得到了保留并依然運作在很多特定領域（比如，Hive依然依賴MapReduce處理長時間的ETL業務）。MapReduce在GFS的基礎上再一次将大資料往前推進了一步，論文論述了如何在大量廉價機器的基礎上穩定地實作超大規模的并行資料處理，這無疑是非常重要的進步。這篇論文無論在學術界還是在工業界都得到了極度狂熱的追捧。原因無非是分布式計算系統可以套用于大量真實的業務場景，幾乎任何一套單機計算系統都可以用MapReduce去改良。

2006年，Google釋出了第三篇重要論文—《BigTable: A Distributed Storage System for Structured Data》，用于解決Google内部海量結構化資料的存儲以及高效讀寫問題。與前兩篇論文相比，這篇論文更難了解一些。這是因為嚴格意義上來講，BigTable屬于分布式資料庫領域，需要讀者具備一定的資料庫基礎，而且論文中提到的資料模型（多元稀疏排序映射模型）對于習慣了關系型資料庫的工程師來說确實不易了解。但從系統架構來看，BigTable還是有很多GFS的影子，包括Master-Slave模式、資料分片等。

這三篇論文在大資料曆史上，甚至整個IT界的發展曆史上都具有革命性意義。但真正讓大資料“飛入尋常百姓家”，是另一個科技巨頭—Yahoo。Google的三篇論文論證了在大量廉價機器上存儲、處理海量資料（結構化資料、非結構化資料）是可行的，然而并沒有給出開源方案。2004年，Doug Cutting和Mike Cafarella在為他們的搜尋引擎爬蟲（Nutch）實作分布式架構的時候看到了Google的GFS論文以及MapReduce論文。他們在之後的幾個月裡按照論文實作出一個簡易版的HDFS和MapReduce，這也就是Hadoop的最早起源。最初這個簡易系統确實可以穩定地運作在幾十台機器上，但是沒有經過大規模使用的系統談不上完美。所幸他們收到了Yahoo的橄榄枝。在Yahoo，Doug上司的團隊不斷地對系統進行改進，促成了Hadoop從幾十台到幾百台再到幾千台機器規模的演變，直到這個時候，大資料才真正在普通公司實作落地。

至于BigTable，沒有在Yahoo内得到實作，原因不明。一家叫做Powerset的公司，為了高效處理自然語言搜尋産生的海量資料實作了BigTable的開源版本—HBase，并在發展了2年之後被Apache收錄為頂級項目，正式入駐Hadoop生态系統。HBase成為Apache頂級項目之後發展非常迅速，各大公司紛紛開始使用HBase，HBase社群的高度活躍性讓HBase這個系統發展得更有活力。有意思的是，Google在将BigTable作為雲服務對外開放的時候，決定提供相容HBase的API。可見在業界，HBase已經一定程度上得到了廣泛的認可和使用。

2. HBase使用現狀

HBase在國外起步很早，包括Facebook、Yahoo、Pinterest等大公司都大規模使用HBase作為基礎服務。在國内HBase相對起步較晚，但現在各大公司對于HBase的使用已經越來越普遍，包括阿裡巴巴、小米、華為、網易、京東、滴滴、中國電信、中國人壽等公司都使用HBase存儲海量資料，服務于各種線上系統以及離線分析系統，其中阿裡巴巴、小米以及京東更是有着數千台HBase的叢集規模。業務場景包括訂單系統、消息存儲系統、使用者畫像、搜尋推薦、安全風控以及物聯網時序資料存儲等。最近，阿裡雲、華為雲等雲提供商先後推出了HBase雲服務，為國内更多公司低門檻地使用HBase服務提供了便利。

另外，相比其他技術社群，HBase社群非常活躍，每天都會有大量的國内外工程師參與HBase系統的開發維護，大部分問題都能在社群得到快速積極的響應。近幾年，HBase社群中，國内開發者的影響力開始慢慢擴大，在某些功能領域甚至已經占據主導地位。

3.HBase版本變遷

HBase從2010年開始前前後後經曆了幾十個版本的更新，不斷地對讀寫性能、系統可用性以及穩定性等方面進行改進，如圖1-1所示。在這些版本中，有部分版本在HBase的發展曆程中可謂功勳卓著。

圖1-1　HBase版本變遷

0.94.x版本是HBase曆史上第一個相對穩定的生産線版本，國内最早使用HBase的網際網路公司（小米、阿裡、網易等）都曾在生産線上大規模使用0.94.x作為服務版本，即使在目前，依然還有很多公司的業務運作在0.94.x版本，可見0.94.x版本在過去的幾年時間裡是多麼輝煌。

之後的2年時間，官方在0.94版本之後釋出了兩個重要版本：0.96版本和0.98版本，0.96版本實作了很多重大的功能改進，比如BucketCache、MSLAB、MTTR優化等，但也因為功能太多而引入了很多bug，導緻生産線上真正投入使用的并不多。直至0.98版本釋出。0.98版本修複了大量的bug，大大提升了系統可用性以及穩定性。不得不說，0.98版本是目前業界公認的HBase曆史上最穩定的版本之一，也是目前生産線上使用最廣泛的版本之一。

2015年2月，社群釋出了1.0.0版本，這個版本帶來的最大改變是規範了HBase的版本号，此後的版本号都統一遵循semantic versioning語義，如圖1-2所示。

圖1-2　HBase版本規則

比如1.2.6版本中MAJOR版本是1，MINOR版本是2，PATCH是6。不同MAJOR版本不保證功能的相容性，比如2.x版本不保證一定相容1.x版本。MINOR版本表示會新增新的功能，比如1.2.x會在1.1.x的基礎上新增部分功能。而PATCH版本隻負責修複bug，是以可以了解為MAJOR、MINOR相同的情況下，PATCH版本越大，系統越可靠。

在1.0的基礎上官方先後釋出了1.1.x、1.2.x、1.3.x以及1.4.x等多個版本。因為穩定性的原因，并不建議在生産線上使用1.0.0～1.1.2中間的版本。目前，HBase社群推薦使用的穩定版本為1.4.10。

2.x版本是接下來最受期待的一個版本（更新要慎重，請參考社群中的實踐），因為最近一兩年社群開發的新功能都将集中在2.x版本釋出，2.x包含的核心功能特别多，包括：大幅度減小GC影響的offheap read path/write path工作，極大提升系統穩定性的Procedure V2架構，支援多租戶隔離的RegionServer Group功能，支援大對象存儲的MOB功能等。

1.2　HBase資料模型

從使用角度來看，HBase包含了大量關系型資料庫的基本概念—表、行、列，但在BigTable的論文中又稱HBase為“sparse, distributed, persistent multidimensional sorted map”，

即HBase本質來看是一個Map。那HBase到底是一個什麼樣的資料庫呢？

實際上，從邏輯視圖來看，HBase中的資料是以表形式進行組織的，而且和關系型資料庫中的表一樣，HBase中的表也由行和列構成，是以HBase非常容易了解。但從實體視圖來看，HBase是一個Map，由鍵值（KeyValue，KV）構成，不過與普通的Map不同，HBase是一個稀疏的、分布式的、多元排序的Map。接下來，筆者首先從邏輯視圖層面對HBase中的基本概念進行介紹，接着從稀疏多元排序Map這個視角進行深入解析，最後從實體視圖層面說明HBase中的資料如何存儲。

1.2.1　邏輯視圖

在具體了解邏輯視圖之前有必要先看看HBase中的基本概念。

• table：表，一個表包含多行資料。
• row：行，一行資料包含一個唯一辨別rowkey、多個column以及對應的值。在HBase中，一張表中所有row都按照rowkey的字典序由小到大排序。
• column：列，與關系型資料庫中的列不同，HBase中的column由column family（列簇）以及qualif?ier（列名）兩部分組成，兩者中間使用":"相連。比如contents:html，其中contents為列簇，html為列簇下具體的一列。column family在表建立的時候需要指定，使用者不能随意增減。一個column family下可以設定任意多個qualif?ier，是以可以了解為HBase中的列可以動态增加，理論上甚至可以擴充到上百萬列。
• timestamp：時間戳，每個cell在寫入HBase的時候都會預設配置設定一個時間戳作為該cell的版本，當然，使用者也可以在寫入的時候自帶時間戳。HBase支援多版本特性，即同一rowkey、column下可以有多個value存在，這些value使用timestamp作為版本号，版本越大，表示資料越新。

• cell：單元格，由五元組（row, column, timestamp, type, value）組成的結構，其中type表示Put/Delete這樣的操作類型，timestamp代表這個cell的版本。這個結構在資料庫中實際是以KV結構存儲的，其中（row, column, timestamp, type）是K，value字段對應KV結構的V。

  圖1-3是BigTable中一張示例表的邏輯視圖，表中主要存儲網頁資訊。示例表中包含兩行資料，兩個rowkey分别為com.cnn.www和com.example.www，按照字典序由小到大排列。每行資料有三個列簇，分别為anchor、contents以及people，其中列簇anchor下有兩列，分别為cnnsi.com以及my.look.ca，其他兩個列簇都僅有一列。可以看出，根據行com.cnn.www以及列anchor:cnnsi.com可以定位到資料CNN，對應的時間戳資訊是t9。而同一行的另一列contents:html下卻有三個版本的資料，版本号分别為t5、t6和t7。

圖1-3　HBase邏輯視圖

總體來看，HBase的邏輯視圖是比較容易了解的，需要注意的是，HBase引入了列簇的概念，列簇下的列可以動态擴充；另外，HBase使用時間戳實作了資料的多版本支援。

1.2.2　多元稀疏排序Map

使用關系型資料庫中表的概念來描述HBase，對于HBase的入門使用大有裨益，然而，對于了解HBase的工作原理意義不大。要真正了解HBase的工作原理，需要從KV資料庫這個視角重新對其審視。BigTable論文中稱BigTable為"sparse, distributed, persistent multidimensional sorted map"，可見BigTable本質上是一個Map結構資料庫，HBase亦然，也是由一系列KV構成的。然而HBase這個Map系統卻并不簡單，有很多限定詞—稀疏的、分布式的、持久性的、多元的以及排序的。接下來，我們先對這個Map進行解析，這對于之後了解HBase的工作原理非常重要。

大家都知道Map由key和value組成，那組成HBase Map的key和value分别是什麼？和普通Map的KV不同，HBase中Map的key是一個複合鍵，由rowkey、column family、qualif?ier、type以及timestamp組成，value即為cell的值。舉個例子，上節邏輯視圖中行"com.cnn.www"以及列"anchor:cnnsi.com"對應的數值"CNN"實際上在HBase中存儲為如下KV結構：

{"com.cnn.www","anchor","cnnsi.com","put","t9"} -> "CNN"

同理，其他的KV還有：

{"com.cnn.www","anchor","my.look.ca","put","t8"} -> "CNN.com"

{"com.cnn.www","contents","html","put","t7"} -> "..."

{"com.cnn.www","contents","html","put","t6"} -> "..."

{"com.cnn.www","contents","html","put","t5"} -> "..."

{"com.example.www","people","author","put","t5"} -> "John Doe"

至此，讀者對HBase中資料的存儲形式有了初步的了解，在此基礎上再來介紹多元、稀疏、排序等關鍵詞。

• 多元：這個特性比較容易了解。HBase中的Map與普通Map最大的不同在于，key是一個複合資料結構，由多元元素構成，包括rowkey、column family、qualif?ier、type以及timestamp。
• 稀疏：稀疏性是HBase一個突出特點。從圖1-3邏輯表中行"com.example.www"可以看出，整整一行僅有一列（people:author）有值，其他列都為空值。在其他資料庫中，對于空值的處理一般都會填充null，而對于HBase，空值不需要任何填充。這個特性為什麼重要？因為HBase的列在理論上是允許無限擴充的，對于成百萬列的表來說，通常都會存在大量的空值，如果使用填充null的政策，勢必會造成大量空間的浪費。是以稀疏性是HBase的列可以無限擴充的一個重要條件。
• 排序：構成HBase的KV在同一個檔案中都是有序的，但規則并不是僅僅按照rowkey排序，而是按照KV中的key進行排序—先比較rowkey，rowkey小的排在前面；如果rowkey相同，再比較column，即column family:qualif?ier，column小的排在前面；如果column還相同，再比較時間戳timestamp，即版本資訊，timestamp大的排在前面。這樣的多元元素排序規則對于提升HBase的讀取性能至關重要，在後面讀取章節會詳細分析。
• 分布式：很容易了解，構成HBase的所有Map并不集中在某台機器上，而是分布在整個叢集中。

1.2.3　實體視圖

與大多數資料庫系統不同，HBase中的資料是按照列簇存儲的，即将資料按照列簇分别存儲在不同的目錄中。

列簇anchor的所有資料存儲在一起形成：

列簇contents的所有資料存儲在一起形成：

列簇people的所有資料存儲在一起形成：

1.2.4　行式存儲、列式存儲、列簇式存儲

為什麼HBase要将資料按照列簇分别存儲？回答這個問題之前需要先了解兩個非常常見的概念：行式存儲、列式存儲，這是資料存儲領域比較常見的兩種資料存儲方式。

行式存儲：行式存儲系統會将一行資料存儲在一起，一行資料寫完之後再接着寫下一行，最典型的如MySQL這類關系型資料庫，如圖1-4所示。

圖1-4　行式存儲

行式存儲在擷取一行資料時是很高效的，但是如果某個查詢隻需要讀取表中指定列對應的資料，那麼行式存儲會先取出一行行資料，再在每一行資料中截取待查找目标列。這種處理方式在查找過程中引入了大量無用列資訊，進而導緻大量記憶體占用。是以，這類系統僅适合于處理OLTP類型的負載，對于OLAP這類分析型負載并不擅長。

列式存儲：列式存儲理論上會将一列資料存儲在一起，不同列的資料分别集中存儲，最典型的如Kudu、Parquet on HDFS等系統（檔案格式），如圖1-5所示。

圖1-5　列式存儲

列式存儲對于隻查找某些列資料的請求非常高效，隻需要連續讀出所有待查目标列，然後周遊處理即可；但是反過來，列式存儲對于擷取一行的請求就不那麼高效了，需要多次IO讀多個列資料，最終合并得到一行資料。另外，因為同一列的資料通常都具有相同的資料類型，是以列式存儲具有天然的高壓縮特性。

列簇式存儲：從概念上來說，列簇式存儲介于行式存儲和列式存儲之間，可以通過不同的設計思路在行式存儲和列式存儲兩者之間互相切換。比如，一張表隻設定一個列簇，這個列簇包含所有使用者的列。HBase中一個列簇的資料是存儲在一起的，是以這種設計模式就等同于行式存儲。再比如，一張表設定大量列簇，每個列簇下僅有一列，很顯然這種設計模式就等同于列式存儲。上面兩例當然是兩種極端的情況，在目前體系中不建議設定太多列簇，但是這種架構為HBase将來演變成HTAP（Hybrid Transactional and Analytical Processing）系統提供了最核心的基礎。

1.3　HBase體系結構

HBase體系結構借鑒了BigTable論文，是典型的Master-Slave模型。系統中有一個管理叢集的Master節點以及大量實際服務使用者讀寫的RegionServer節點。除此之外，HBase中所有資料最終都存儲在HDFS系統中，這與BigTable實際資料存儲在GFS中相對應；系統中還有一個ZooKeeper節點，協助Master對叢集進行管理。HBase體系結構如圖1-6所示。

圖1-6　HBase體系結構

1. HBase用戶端

HBase用戶端（Client）提供了Shell指令行接口、原生Java API程式設計接口、Thrift/REST API程式設計接口以及MapReduce程式設計接口。HBase用戶端支援所有常見的DML操作以及DDL操作，即資料的增删改查和表的日常維護等。其中Thrift/REST API主要用于支援非Java的上層業務需求，MapReduce接口主要用于批量資料導入以及批量資料讀取。

HBase用戶端通路資料行之前，首先需要通過中繼資料表定位目标資料所在RegionServer，之後才會發送請求到該RegionServer。同時這些中繼資料會被緩存在用戶端本地，以友善之後的請求通路。如果叢集RegionServer發生當機或者執行了負載均衡等，進而導緻資料分片發生遷移，用戶端需要重新請求最新的中繼資料并緩存在本地。

2. ZooKeeper

ZooKeeper（ZK）也是Apache Hadoop的一個頂級項目，基于Google的Chubby開源實作，主要用于協調管理分布式應用程式。在HBase系統中，ZooKeeper扮演着非常重要的角色。

• 實作Master高可用：通常情況下系統中隻有一個Master工作，一旦Active Master由于異常當機，ZooKeeper會檢測到該當機事件，并通過一定機制選舉出新的Master，保證系統正常運轉。
• 管理系統核心中繼資料：比如，管理目前系統中正常工作的RegionServer集合，儲存系統中繼資料表hbase:meta所在的RegionServer位址等。
• 參與RegionServer當機恢複：ZooKeeper通過心跳可以感覺到RegionServer是否當機，并在當機後通知Master進行當機處理。
• 實作分布式表鎖：HBase中對一張表進行各種管理操作（比如alter操作）需要先加表鎖，防止其他使用者對同一張表進行管理操作，造成表狀态不一緻。和其他RDBMS表不同，HBase中的表通常都是分布式存儲，ZooKeeper可以通過特定機制實作分布式表鎖。

3. Master

Master主要負責HBase系統的各種管理工作：

• 處理使用者的各種管理請求，包括建表、修改表、權限操作、切分表、合并資料分片以及Compaction等。
• 管理叢集中所有RegionServer，包括RegionServer中Region的負載均衡、RegionServer的當機恢複以及Region的遷移等。
• 清理過期日志以及檔案，Master會每隔一段時間檢查HDFS中HLog是否過期、HFile是否已經被删除，并在過期之後将其删除。

4. RegionServer

RegionServer主要用來響應使用者的IO請求，是HBase中最核心的子產品，由WAL(HLog)、BlockCache以及多個Region構成。

• WAL(HLog)：HLog在HBase中有兩個核心作用—其一，用于實作資料的高可靠性，HBase資料随機寫入時，并非直接寫入HFile資料檔案，而是先寫入緩存，再異步重新整理落盤。為了防止緩存資料丢失，資料寫入緩存之前需要首先順序寫入HLog，這樣，即使緩存資料丢失，仍然可以通過HLog日志恢複；其二，用于實作HBase叢集間主從複制，通過回放主叢集推送過來的HLog日志實作主從複制。
• BlockCache：HBase系統中的讀緩存。用戶端從磁盤讀取資料之後通常會将資料緩存到系統記憶體中，後續通路同一行資料可以直接從記憶體中擷取而不需要通路磁盤。對于帶有大量熱點讀的業務請求來說，緩存機制會帶來極大的性能提升。
• BlockCache緩存對象是一系列Block塊，一個Block預設為64K，由實體上相鄰的多個KV資料組成。BlockCache同時利用了空間局部性和時間局部性原理，前者表示最近将讀取的KV資料很可能與目前讀取到的KV資料在位址上是鄰近的，緩存機關是Block（塊）而不是單個KV就可以實作空間局部性；後者表示一個KV資料正在被通路，那麼近期它還可能再次被通路。目前BlockCache主要有兩種實作—LRUBlockCache和BucketCache，前者實作相對簡單，而後者在GC優化方面有明顯的提升。
• Region：資料表的一個分片，當資料表大小超過一定門檻值就會“水準切分”，分裂為兩個Region。Region是叢集負載均衡的基本機關。通常一張表的Region會分布在整個叢集的多台RegionServer上，一個RegionServer上會管理多個Region，當然，這些Region一般來自不同的資料表。

一個Region由一個或者多個Store構成，Store的個數取決于表中列簇（column family）的個數，多少個列簇就有多少個Store。HBase中，每個列簇的資料都集中存放在一起形成一個存儲單元Store，是以建議将具有相同IO特性的資料設定在同一個列簇中。

每個Store由一個MemStore和一個或多個HFile組成。MemStore稱為寫緩存，使用者寫入資料時首先會寫到MemStore，當MemStore寫滿之後（緩存資料超過門檻值，預設128M）系統會異步地将資料f?lush成一個HFile檔案。顯然，随着資料不斷寫入，HFile檔案會越來越多，當HFile檔案數超過一定門檻值之後系統将會執行Compact操作，将這些小檔案通過一定政策合并成一個或多個大檔案。

5. HDFS

HBase底層依賴HDFS元件存儲實際資料，包括使用者資料檔案、HLog日志檔案等最終都會寫入HDFS落盤。HDFS是Hadoop生态圈内最成熟的元件之一，資料預設三副本存儲政策可以有效保證資料的高可靠性。HBase内部封裝了一個名為DFSClient的HDFS用戶端元件，負責對HDFS的實際資料進行讀寫通路。

1.4　HBase系統特性

1. HBase的優點

與其他資料庫相比，HBase在系統設計以及實際實踐中有很多獨特的優點。

• 容量巨大：HBase的單表可以支援千億行、百萬列的資料規模，資料容量可以達到TB甚至PB級别。傳統的關系型資料庫，如Oracle和MySQL等，如果單表記錄條數超過億行，讀寫性能都會急劇下降，在HBase中并不會出現這樣的問題。
• 良好的可擴充性：HBase叢集可以非常友善地實作叢集容量擴充，主要包括資料存儲節點擴充以及讀寫服務節點擴充。HBase底層資料存儲依賴于HDFS系統，HDFS可以通過簡單地增加DataNode實作擴充，HBase讀寫服務節點也一樣，可以通過簡單的增加RegionServer節點實作計算層的擴充。
• 稀疏性：HBase支援大量稀疏存儲，即允許大量列值為空，并不占用任何存儲空間。這與傳統資料庫不同，傳統資料庫對于空值的處理要占用一定的存儲空間，這會造成一定程度的存儲空間浪費。是以可以使用HBase存儲多至上百萬列的資料，即使表中存在大量的空值，也不需要任何額外空間。
• 高性能：HBase目前主要擅長于OLTP場景，資料寫操作性能強勁，對于随機單點讀以及小範圍的掃描讀，其性能也能夠得到保證。對于大範圍的掃描讀可以使用MapReduce提供的API，以便實作更高效的并行掃描。
• 多版本：HBase支援多版本特性，即一個KV可以同時保留多個版本，使用者可以根據需要選擇最新版本或者某個曆史版本。
• 支援過期：HBase支援TTL過期特性，使用者隻需要設定過期時間，超過TTL的資料就會被自動清理，不需要使用者寫程式手動删除。
• Hadoop原生支援：HBase是Hadoop生态中的核心成員之一，很多生态元件都可以與其直接對接。HBase資料存儲依賴于HDFS，這樣的架構可以帶來很多好處，比如使用者可以直接繞過HBase系統操作HDFS檔案，高效地完成資料掃描或者資料導入工作；再比如可以利用HDFS提供的多級存儲特性（Archival Storage Feature），根據業務的重要程度将HBase進行分級存儲，重要的業務放到SSD，不重要的業務放到HDD。或者使用者可以設定歸檔時間，進而将最近的資料放在SSD，将歸檔資料檔案放在HDD。另外，HBase對MapReduce的支援也已經有了很多案例，後續還會針對Spark做更多的工作。

2. HBase的缺點

任何一個系統都不會完美，HBase也一樣。HBase不能适用于所有應用場景，例如：

• HBase本身不支援很複雜的聚合運算（如Join、GroupBy等）。如果業務中需要使用聚合運算，可以在HBase之上架設Phoenix元件或者Spark元件，前者主要應用于小規模聚合的OLTP場景，後者應用于大規模聚合的OLAP場景。
• HBase本身并沒有實作二級索引功能，是以不支援二級索引查找。好在針對HBase實作的第三方二級索引方案非常豐富，比如目前比較普遍的使用Phoenix提供的二級索引功能。
• HBase原生不支援全局跨行事務，隻支援單行事務模型。同樣，可以使用Phoenix提供的全局事務模型元件來彌補HBase的這個缺陷。

可以看到，HBase系統本身雖然不擅長某些工作領域，但是借助于Hadoop強大的生态圈，使用者隻需要在其上架設Phoenix元件、Spark元件或者其他第三方元件，就可以有效地協同工作。