04_HBase_分布式資料庫_note

分布式資料庫HBase

HBase簡介

HBase是BigTable的一個開源實作

BigTable的誕生

* 主要是滿足網際網路搜尋引擎的基本需求
* 用于網頁搜尋
* 用于谷歌大量項目，包括搜尋，地圖，财經，列印
* 還有一些社交網站，視訊共享網站也使用了BigTable
           

為何受到廣泛關注

*  具有非常好的性能，可以支援PB級别的資料
*  具有非常好的可擴充性，用叢集存儲幾千台伺服器完成分布式存儲
           

• HBase:高可靠，高性能，面向列，可伸縮的分布式資料庫，可以存儲非結構化和半結構化的松散資料

  * 水準擴充：允許多台伺服器存儲海量檔案

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

  

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

• Hadoop可以很好地解決大規模資料的離線批量處理問題，但是，受限于Hadoop MapReduce程式設計架構的高延遲資料處理機制，使得Hadoop無法滿足大規模資料實時處理應用的需求
• HDFS面向批量通路模式，不是随機通路模式
• 傳統的通用關系型資料庫無法應對在資料規模劇增時導緻的系統擴充性和性能問題（分庫分表也不能很好解決）
• 傳統關系資料庫在資料結構變化時一般需要停機維護；空列浪費存儲空間
• 是以，業界出現了一類面向半結構化資料存儲和處理的高可擴充、低寫入/查詢延遲的系統，例如，鍵值資料庫、文檔資料庫和列族資料庫（如BigTable和HBase等）
• HBase已經成功應用于網際網路服務領域和傳統行業的衆多線上式資料分析處理系統中

HBase與傳統關系資料庫的差別

1. 資料類型

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

2. 資料操作

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

3. 存儲模式

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

4. 資料索引：

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

5. 資料維護：

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

6. 可伸縮性：

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

HBase通路接口

HBase資料模型

HBase資料模型概述

HBase是一個稀疏、多元度、排序的映射表，這張表的索引是行鍵、列族、列限定符和時間戳

每個值是一個未經解釋的字元串，沒有資料類型

使用者在表中存儲資料，每一行都有一個可排序的行鍵和任意多的列

表在水準方向由一個或者多個列族組成，一個列族中可以包含任意多個列，同一個列族裡面的資料存儲在一起

列族支援動态擴充，可以很輕松地添加一個列族或列，無需預先定義列的數量以及類型，所有列均以字元串形式存儲，使用者需要自行進行資料類型轉換

HBase中執行更新操作時，并不會删除資料舊的版本，而是生成一個新的版本，舊有的版本仍然保留（這是和HDFS隻允許追加不允許修改的特性相關的）

資料模型相關概念

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

資料坐标

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

概念視圖

實體視圖

面向列的存儲

HBase的實作原理

HBase的功能元件

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

    

    開始隻有一個Region，後來不斷分裂

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

    

表和Region

• 每個Region預設大小是100MB到200MB（2006年以前的硬體配置）
  • 每個Region的最佳大小取決于單台伺服器的有效處理能力
  • 目前每個Region最佳大小建議1GB-2GB（2013年以後的硬體配置）
• 同一個Region不會被分拆到多個Region伺服器
• 每個Region伺服器存儲10-1000個Region

  

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

  

  

Region的定位

用戶端通路資料時的“三級尋址”

為了加速尋址，用戶端會緩存位置資訊，同時，需要解決緩存失效問題

尋址過程用戶端隻需要詢問Zookeeper伺服器，不需要連接配接Master伺服器

HBase運作機制

HBase系統架構

1. 用戶端

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

2. Zookeeper伺服器

• Zookeeper是一個很好的叢集管理工具，被大量用于分布式計算，提供配置維護、域名服務、分布式同步、組服務等。
• Zookeeper可以幫助選舉出一個Master作為叢集的總管，并保證在任何時刻總有唯一一個Master在運作，這就避免了Master的“單點失效”問題

  

3. Master

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

• 管理使用者對表的增加、删除、修改、查詢等操作
• 實作不同Region伺服器之間的負載均衡
• 在Region分裂或合并後，負責重新調整Region的分布
• 對發生故障失效的Region伺服器上的Region進行遷移

4. Region伺服器

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

Region伺服器工作原理

1. 使用者讀寫資料過程 
2. 緩存的重新整理
3. StoreFile的合并
           

1. 使用者讀寫資料過程

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

  

  

2. 緩存的重新整理

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

  

3. StoreFile的合并

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

  

Store工作原理

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

HLog工作原理

• 分布式環境必須要考慮系統出錯。HBase采用HLog保證系統恢複
• HBase系統為每個Region伺服器配置了一個HLog檔案，它是一種預寫式日志（Write Ahead Log）
• 使用者更新資料必須首先寫入日志後，才能寫入MemStore緩存，并且，直到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實際應用中的性能優化方法

行鍵（Row Key）

• 行鍵是按照字典序存儲，是以，設計行鍵時，要充分利用這個排序特點，将經常一起讀取的資料存儲到一塊，将最近可能會被通路的資料放在一塊。
• 舉個例子：如果最近寫入HBase表中的資料是最可能被通路的，可以考慮将時間戳作為行鍵的一部分，由于是字典序排序，是以可以使用Long.MAX_VALUE timestamp作為行鍵，這樣能保證新寫入的資料在讀取時可以被快速命中。

  

InMemory

建立表的時候，可以通過HColumnDescriptor.setInMemory(true)将表放到Region伺服器的緩存中，保證在讀取的時候被cache命中。

Max Version

建立表的時候，可以通過HColumnDescriptor.setMaxVersions(int maxVersions)設定表中資料的最大版本，如果隻需要儲存最新版本的資料，那麼可以設定setMaxVersions(1)。

Time To Live

建立表的時候，可以通過HColumnDescriptor.setTimeToLive(int timeToLive)設定表中資料的存儲生命期，過期資料将自動被删除，例如如果隻需要存儲最近兩天的資料，那麼可以設定setTimeToLive(2 * 24 * 60 * 60)。

HBase性能監視

- Master-status(自帶)
- Ganglia
- OpenTSDB
- Ambari
           

Master-status

• HBase Master預設基于Web的UI服務端口為60010，HBase region伺服器預設基于Web的UI服務端口為60030.如果master運作在名為master.foo.com的主機中，mater的首頁位址就是http://master.foo.com:60010，使用者可以通過Web浏覽器輸入這個位址檢視該頁面
• 可以檢視HBase叢集的目前狀态

Ganglia

• Ganglia是UC Berkeley發起的一個開源叢集監視項目，用于監控系統性能

  

OpenTSDB

• OpenTSDB可以從大規模的叢集（包括叢集中的網絡裝置、作業系統、應用程式）中擷取相應的metrics并進行存儲、索引以及服務，進而使得這些資料更容易讓人了解，如web化，圖形化等

  

Ambari

• Ambari 的作用就是建立、管理、監視 Hadoop 的叢集

  

在HBase之上建構SQL引擎

1. Hive整合HBase

Hive與HBase的整合功能從Hive0.6.0版本已經開始出現，利用兩者對外的API接口互相通信，通信主要依靠hive_hbase-handler.jar工具包(Hive Storage Handlers)。由于HBase有一次比較大的版本變動，是以并不是每個版本的Hive都能和現有的HBase版本進行整合，是以在使用過程中特别注意的就是兩者版本的一緻性。

2. Phoenix

Phoenix由Salesforce.com開源，是建構在Apache HBase之上的一個SQL中間層，可以讓開發者在HBase上執行SQL查詢。

建構HBase二級索引

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-BiuvKM31-1585360080178)(img/construct_2degree_index.png)]

• 原生的HBase産品隻有一個針對行健的索引,通路HBase表中的行，隻有三種方式：
  • 通過單個行健通路
  • 通過一個行健的區間來通路
  • 全表掃描

    

• 使用其他産品為HBase行健提供索引功能：[原理：采用HBase0.92版本之後引入Coprocessor特性]

  

  • Hindex二級索引
  • HBase+Redis
  • HBase+solr
• Coprocessor建構二級索引
  • Coprocessor提供了兩個實作：endpoint和observer，endpoint相當于關系型資料庫的存儲過程，而observer則相當于觸發器
  • observer允許我們在記錄put前後做一些處理，是以，而我們可以在插入資料時同步寫入索引表

    • 優點：

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

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

      

Hindex二級索引

Hindex 是華為公司開發的純 Java 編寫的HBase二級索引，相容 Apache HBase 0.94.8。目前的特性如下：

• 多個表索引
• 多個列索引
• 基于部分列值的索引

HBase+Redis

• Redis+HBase方案
• Coprocessor建構二級索引
• Redis做用戶端緩存
• 将索引實時更新到Redis等KV系統中，定時從KV更新索引到HBase的索引表中

  

Solr+HBase

Solr是一個高性能，采用Java5開發，基于Lucene的全文搜尋伺服器。同時對其進行了擴充，提供了比Lucene更為豐富的查詢語言，同時實作了可配置、可擴充并對查詢性能進行了優化，并且提供了一個完善的功能管理界面，是一款非常優秀的全文搜尋引擎。

HBase程式設計實踐

詳情參見http://dblab.xmu.edu.cn/blog/588-2/