大數據技術原理與應用——分佈式數據庫 HBase

大數據技術原理與應用——分佈式數據庫 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=2¹⁷行，也就是說，一個-ROOT-表可以尋址2¹⁷個.META.表的Region。
• 同理，每個.META.表的Region可以尋址的用戶數據表的Region個數是128MB/1KB=2¹⁷。
• 最終，三層結構可以保存的Region數目是(128MB/1KB)×(128MB/1KB)=2³⁴個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的集羣的壓力也是雙倍的