大資料技術原理與應用——分布式資料庫 HBase

4.1 概述

4.1.1 從 BigTable 說起

BigTable 是一個分布式存儲系統

BigTable 起初用于解決典型的網際網路搜尋問題

建立網際網路索引

1.爬蟲持續不斷地抓取新頁面，這些頁面每頁一行地存儲到 BigTable 裡

2.MapReduce 計算作業運作在整張表上，生成索引，為網絡搜尋應用做準備

搜尋網際網路

3.使用者發起網絡搜尋請求

4.網絡搜尋應用查詢建立好的索引，從 BigTable 得到網頁

5.搜尋結果送出給使用者

BigTable 是一個分布式資料管理系統

利用谷歌提出的 MapReduce 分布式并行計算模型來處理海量資料

利用谷歌分布式檔案系統 GFS 作為底層資料存儲

采用 Chubby 提供協同服務管理

可以擴充到 PB 級别的資料和上千台機器，具有廣泛應用性、可擴充性、高性能和高可用性等特點

谷歌的許多項目都存儲在 BigTable 中，包括搜尋、地圖、财經、列印、社交網站 Orkut、視訊共享網站 You Tube 和部落格網站 Blogger 等

4.1.2 HBase 簡介

HBase 是一個高可靠、高性能、面向列、可伸縮的分布式資料庫，是谷歌 BigTable 的開源實作，主要用來存儲非結構化和半結構化的松散資料。HBase 的目标是處理龐大的表，可以通過水準擴充的方式，利用廉價計算機叢集處理由超過10億行資料和數百列元素組成的資料表。

HBase 和 BigTable 的底層技術對應關系

資料存儲管理	BigTable	HBase
檔案存儲系統	GFS	HDFS
海量資料處理	MapReduce	Hadoop、MapReduce
協同服務管理	Chubby	Zookeeper

關系資料庫已經流行很多年，并且 Hadoop 已經有了 HDFS 和 MapReduce，為什麼需要 HBase？

Hadoop 可以很好地解決大規模資料的離線批量處理問題，但是，受限于 Hadoop MapReduce 程式設計架構的高延遲資料處理機制，使得 Hadoop 無法滿足大規模資料實時處理應用的需求。

HDFS 面向批量通路模式，不是随機通路模式。

傳統的通用關系型資料庫無法應對在資料規模劇增時導緻的系統擴充性和性能問題（分庫分表也不能很好解決）。

傳統關系資料庫在資料結構變化時一般需要停機維護；空列浪費存儲空間。

随着整個資料規模的不斷增大，我們後來會搭建一個新的優化方案，叫主從複制

4.1.3 HBase 與傳統關系資料庫的對比分析

HBase 與傳統的關系資料庫的差別主要展現在以下幾個方面：

（1）資料類型：關系資料庫采用關系模型，具有豐富的資料類型和存儲方式，HBase 則采用了更加簡單的資料模型，它把資料存儲為未經解釋的字元串。

（2）資料操作：關系資料庫中包含了豐富的操作，其中會涉及複雜的多表連接配接。HBase 操作則不存在複雜的表與表之間的關系，隻有簡單的插入、查詢、删除、清空等，因為 HBase 在設計上就避免了複雜的表和表之間的關系。

（3）存儲模式：關系資料庫是基于行模式存儲的。HBase 是基于列存儲的，每個列族都由幾個檔案儲存，不同列族的檔案是分離的。

（4）資料索引：關系資料庫通常可以針對不同列建構複雜的多個索引，以提高資料通路性能。HBase 隻有一個索引——行鍵，通過巧妙的設計，HBase 中的所有通路方法，或者通過行鍵通路，或者通過行鍵掃描，進而使得整個系統不會慢下來。

（5）資料維護：在關系資料庫中，更新操作會用最新的目前值去替換記錄中原來的舊值，舊值被覆寫後就不會存在。而在 HBase 中執行更新操作時，并不會删除資料舊的版本，而是生成一個新的版本，舊有的版本仍然保留。

（6）可伸縮性：關系資料庫很難實作橫向擴充，縱向擴充的空間也比較有限。相反，HBase 和 BigTable 這些分布式資料庫就是為了實作靈活的水準擴充而開發的，能夠輕易地通過在叢集中增加或者減少硬體數量來實作性能的伸縮。

4.2 HBase 通路接口

類型	特點	場合
Native Java API	最正常和高效的通路方式	适合Hadoop MapReduce作業并行批處理HBase表資料
HBase Shell	HBase的指令行工具，最簡單的接口	适合HBase管理使用
Thrift Gateway	利用Thrift序列化技術，支援C++、PHP、Python等多種語言	适合其他異構系統線上通路HBase表資料
REST Gateway	解除了語言限制	支援REST風格的Http API通路HBase
Pig	使用Pig Latin流式程式設計語言來處理HBase中的資料	适合做資料統計
Hive	簡單	當需要以類似SQL語言方式來通路HBase的時候

4.3 HBase 資料模型

4.3.1 資料模型概述

• HBase是一個稀疏、多元度、排序的映射表，這張表的索引是行鍵、列族、列限定符和時間戳
• 每個值是一個未經解釋的字元串，沒有資料類型
• 使用者在表中存儲資料，每一行都有一個可排序的行鍵和任意多的列
• 表在水準方向由一個或者多個列族組成，一個列族中可以包含任意多個列，同一列族裡面的資料存儲在一起
• 列族支援動态擴充，可以很輕松地添加一個列族或列，無需預先定義列的數量以及類型，所有列均以字元串形式存儲，使用者需要自行進行資料類型轉換
• HBase中執行更新操作時，并不會删除資料舊的版本，而是生成一個新的版本，舊有的版本仍然保留（這是和HDFS隻允許追加不允許修改的特性相關的）

4.3.2 資料模型相關概念

• 表：HBase采用表來組織資料，表由行和列組成，列劃分為若幹個列族
• 行：每個HBase表都由若幹行組成，每個行由行鍵（row key）來辨別
• 列族：一個HBase表被分組成許多“列族”（Column Family）的集合，它是基本的通路控制單元
• 列限定符：列族裡的資料通過列限定符（或列）來定位
• 單元格：在HBase表中，通過行、列族和列限定符确定一個“單元格”（cell），單元格中存儲的資料沒有資料類型，總被視為位元組數組byte[]
• 時間戳：每個單元格都儲存着同一份資料的多個版本，這些版本采用時間戳進行索引（更新的時候，舊的版本仍然保留，新的版本會通過時間戳來進行區分）

  

4.3.3 資料坐标

• HBase中需要根據行鍵、列族、列限定符和時間戳來确定一個單元格，是以，可以視為一個“四維坐标”，即[行鍵，列族，列限定符，時間戳]

  

4.3.4 概念視圖

4.3.5 實體視圖

4.3.6 面向列的存儲

4.4 HBase的實作原理

4.4.1 HBase功能元件

• HBase的實作包括三個主要的功能元件：

  　——（1）庫函數：連結到每個用戶端

  　——（2）一個Master主伺服器

  　——（3）許多個Region伺服器

• 主伺服器Master負責管理和維護HBase表的分區資訊，維護Region伺服器清單，配置設定Reigion，負載均衡
• Region伺服器負責存儲和維護配置設定給自己的Region，處理來自用戶端的讀寫請求
• 用戶端并不是直接從Master主伺服器上讀取資料，而是在獲得Region的存儲位置資訊後，直接從Region伺服器上讀取資料
• 用戶端并不依賴Master，而是通過Zookeeper來獲得Region位置資訊，大多數用戶端甚至從來不和Master通信，這種設計方式使得Master負載很小

4.4.2 表和Region

• 開始隻有一個Region，後來不斷分裂
• Region拆分操作非常快，接近瞬間，因為拆分之後的Region讀取的仍然是原存儲檔案，直到“合并”過程把存儲檔案異步地寫到獨立的檔案之後，才會讀取新檔案

  

  

• 每個Region預設大小是100MB到200MB（2006年以前的硬體配置）

  　- 每個Region的最佳大小取決于單台伺服器的有效處理能力

  　- 目前每個Region最佳大小建議1GB-2GB（2013年以後的硬體配置）

• 同一個Region不會被分拆到多個Region伺服器
• 每個Region伺服器存儲10-1000個Region

  

4.4.3 Region的定位

• 中繼資料表，又名.META.表，存儲了Region和Region伺服器的映射關系
• 當HBase表很大時，.META.表也會被分裂成多個Region
• 根資料表，又名-ROOT-表，記錄所有中繼資料的具體位置
• -ROOT-表隻有唯一一個Region，名字是在程式中被寫死的
• Zookeeper檔案記錄了-ROOT-表的位置

  

• 為了加快通路速度，.META.表的全部Region都會被儲存在記憶體中

• 假設.META.表的每行（一個映射條目）在記憶體中大約占用1KB，并且每個Region限制為128MB，那麼，上面的三層結構可以儲存的使用者資料表的Region數目的計算方法是：

  　(-ROOT-表能夠尋址的.META.表的Region個數)×（每個.META.表的Region可以尋址的使用者資料表的Region個數）

• 一個-ROOT-表最多隻能有一個Region，也就是最多隻能有128MB，按照每行（一個映射條目）占用1KB記憶體計算，128MB空間可以容納128MB/1KB=217行，也就是說，一個-ROOT-表可以尋址217個.META.表的Region。
• 同理，每個.META.表的Region可以尋址的使用者資料表的Region個數是128MB/1KB=217。
• 最終，三層結構可以儲存的Region數目是(128MB/1KB)×(128MB/1KB)=234個Region

4.5 HBase 運作機制

4.5.1 HBase系統架構

1.用戶端

　- 用戶端包含通路HBase的接口，同時在緩存中維護着已經通路過的Region位置資訊，用來加快後續資料通路過程

2.Zookeeper伺服器

　- Zookeeper可以幫助選舉出一個Master作為叢集的總管，并保證在任何時刻總有唯一一個Master在運作，這就避免了Master的“單點失效”問題

　- Zookeeper是一個很好的叢集管理工具，被大量用于分布式計算，提供配置維護、域名服務、分布式同步、組服務等。

3.Master

　主伺服器Master主要負責表和Region的管理工作：

　- 管理使用者對表的增加、删除、修改、查詢等操作

　- 實作不同Region伺服器之間的負載均衡

　- 在Region分裂或合并後，負責重新調整Region的分布

　- 對發生故障失效的Region伺服器上的Region進行遷移

4.Region伺服器

　- Region伺服器是HBase中最核心的子產品，負責維護配置設定給自己的Region，并響應使用者的讀寫請求

4.5.2 Region伺服器工作原理

1.使用者讀寫資料過程

2.緩存的重新整理

3.StoreFile的合并

1.使用者讀寫資料過程

• 使用者寫入資料時，被配置設定到相應Region伺服器去執行
• 使用者資料首先被寫入到MemStore和Hlog中
• 隻有當操作寫入Hlog之後，commit()調用才會将其傳回給用戶端
• 當使用者讀取資料時，Region伺服器會首先通路MemStore緩存，如果找不到，再去磁盤上面的StoreFile中尋找

  

  

2.緩存的重新整理

• 系統會周期性地把MenStore緩存裡的内容刷寫到磁盤的StoreFile檔案中，清空緩存，并在Hlog裡面寫入一個标記
• 每次刷寫都生成一個新的StoreFile檔案，是以，每個Store包含多個StoreFile檔案
• 每個Region伺服器都有一個自己的HLog檔案，每次啟動都檢查該檔案，确認最近一次執行緩存重新整理操作之後是否發生新的寫入操作；如果發現更新，則先寫入MemStore，再刷寫到StoreFile，最後删除舊的Hlog檔案，開始為使用者提供服務

3.StoreFile的合并

• 每次刷寫都生成一個新的StoreFile，數量太多，影響查找速度
• 調用Store.compact()把多個合并成一個
• 合并操作比較耗費資源，隻有數量達到一個門檻值才啟動合并

  

4.5.3 Store工作原理

• Store是Region伺服器的核心
• 多個StoreFile合并成一個
• 單個StoreFile過大時，又觸發分裂操作，1個父Region被分裂成兩個子Region

  

4.5.4 HLog工作原理

• 分布式環境必須要考慮系統出錯。HBase采用HLog保證系統恢複
• HBase系統為每個Region伺服器配置了一個HLog檔案，它是一種預寫式日志（Write Ahead Log）
• 使用者更新資料必須首先寫入日志後，才能寫入MenStore緩存，并且，直到MemStore緩存内容對應的日志已經寫入磁盤，該緩存内容才能被刷寫到磁盤
• Zookeeper會實時檢測每個Region伺服器的狀态，當某個Region伺服器發生故障時，Zookeeper會通知Master
• Master首先會處理該故障Region伺服器上面遺留的HLog檔案，這個遺留的HLog檔案中包含了來自多個Region對象的日志記錄
• 系統會根據每條日志記錄所屬的Region對象對HLog資料進行拆分，分别放到相應Region對象的目錄下，然後，再将失效的Region重新配置設定到可用的Region伺服器中，并把與該Region對象相關的HLog日志記錄也發送給相應的Region伺服器
• Region伺服器領取到配置設定給自己的Region對象以及與之相關的HLog日志記錄以後，會重新做一遍日志記錄中的各種操作，把日志記錄中的資料寫入到MemStore緩存中，然後，重新整理到磁盤的StoreFile檔案中，完成資料恢複
• 共用日志優點：提高對表的寫操作性能；缺點：恢複時需要分析日志

HBase 應用方案

HBase在實際應用中的性能優化方法

HBase怎麼檢測性能

HBase之上如何建構SQL引擎和HBase二級索引

• Hive：從Hive 0.6.0版本開始就已經具備了和HBase的整合功能，它們的接口互相通信就可以實作對HBase的通路
• Phoenix：是知名的SaaS服務供應商Salesforce的産品。這個Salesforce.com公司開源了一個項目叫Phoenix，它是建構在Apache HBase之上的一個SQL中間層通過這麼一個産品允許開發者HBase上執行SQL查詢

建構HBase二級索引

• 二級索引，又叫輔助索引
• 關系資料庫中，可以對學号字段建立 主索引primary key，然後對姓名和成績字段建構多個輔助索引或者二級索引
• 關系資料庫當中支援這種索引方式

  

  

  怎麼利用特性去建構二級索引

  Coprocessor提供了兩個實作：endpoint和observer

• endpoint相當于關系型資料庫的存儲過程，而observer就相當于觸發器
• observer允許我們在記錄put前後做一些處理，是以，而我們可以在插入資料時同步寫入索引表

  

優點：

• 非侵入性：引擎建構在HBase之上，既沒有對HBase進行任何改動，也不需要上層應用做任何妥協

缺點

• 每插入一條資料需要向索引表插入資料，即耗時是雙倍的，對HBase的叢集的壓力也是雙倍的