本文將對Apache HBase可用的數據備份機制和大量數據的故障恢復/容災機制做簡要介紹。
隨着HBase在重要的商業系統中應用的大量添加，很多企業須要通過對它們的HBase集群建立健壯的備份和故障恢復（backup and disaster recovery, BDR）機制來保證它們的企業（數據）資產。
HBase和Apache Hadoop系統提供了很多內置的機制，能夠高速而輕松的完畢PB級數據的備份和恢復工作。
在這篇文章中，你將會對在HBase中可用的數據備份機制有一個高層次的簡要了解，而且知道多種數據恢復/容災機制。在閱讀了這篇文章之后，你應該能對你的業務須要那種BDR策略有了自己的推斷。
你也應該明確各種機制各自的優缺點（適用於CDH 4.3.0/HBase 0.94.6及更高版本號）。
備份
HBase是一個基於LSM樹（log-structured merge-tree）的分布式數據存儲系統，它使用復雜的內部機制確保數據准確性、一致性、多版本號等。因此。你怎樣獲取數十個region server在HDFS和內存中的存儲的眾多HFile文件、WALs（Write-Ahead-Logs）的一致的數據備份？
讓我們從最小的破壞性，最小的數據占用空間，最小的性能要求機制和工作方式到最具破壞性的逐一講述：
- Snapshots
- Replication
- Export
- CopyTable
- HTable API
- Offline backup of HDFS data
以下的表格提供了一個關於這些方法的高速比較。具體的細節在以下再具體描寫敘述。
Snapshots（快照）
HBase快照功能豐富。有非常多特征，而且創建時不須要關閉集群。
關於snapshot在文章《apache hbase snapshot介紹》中有更具體的介紹。
快照能通過在HDFS中創建一個和unix硬鏈接同樣的存儲文件，簡單捕捉你的hbase表的某一時刻的信息（圖1）。這些快照在幾秒內就能夠完畢，差點兒對整個集群沒有不論什么性能影響。
而且。它僅僅占用一個微不足道的空間。除了在metadata文件里存儲的極少文件夾數據，你的數據不會冗余，快照同意你的系統回滾到（創建快照）那個時刻。當然。你須要恢復快照。
圖1
通過在HBase shell中執行例如以下命令來創建一個表的快照：
hbase(main):001:0> snapshot 'myTable', 'MySnapShot'在運行這條命令之后，你將發如今hdfs中有一些小的數據文件。
在 /hbase/.snapshot/myTable (CDH4) 或者hbase/.hbase-snapshots (Apache 0.94.6.1)，這些文件里存儲着快照信息。
想要恢復數據僅僅須要運行在shell中運行例如以下命令：
hbase(main):002:0> disable 'myTable' hbase(main):003:0> restore_snapshot 'MySnapShot' hbase(main):004:0> enable 'myTable'正如你看到的。恢復快照須要對表進行離線操作。
一旦恢復快照。那不論什么在快照時刻之后做的添加/更新數據都會丟失。
假設你的業務需求是這種：你必須有數據的異地備份，你能夠用exportSnapshot命令賦值一個表的數據到你的本地HDFS或者你選擇的遠程HDFS中。
快照是你的表在某一個時刻的完整圖像。眼下沒有增量快照功能可用。
HBase復制（HBase Relication）
HBase賦值是另外一個負載較輕的備份工具。
文章《HBase復制概述》有對它的具體描寫敘述。
總的來說，賦值被定義為列簇級別，能夠工作在后台而且保證全部的編輯操作在集群復制鏈之間的同步。
復制有三種模式：主->從(master->slave)。主<->主(master<->master)和循環（cyclic）。這樣的方法給你靈活的從隨意數據中心獲取數據而且確保它能獲得在其它數據中心的全部副本。
在一個數據中心發生災難性故障的情況下，client應用程序能夠利用DNS工具，重定向到另外一個備用位置。
復制是一個強大的。容錯的過程。
它提供了“終於一致性”，意味着在不論什么時刻，近期對一個表的編輯可能無法應用到該表的全部副本。可是終於可以確保一致。
注：對於一個存在的表，你須要通過本文描寫敘述的其它方法，手工的拷貝源表到目的表。
復制只在你啟動它之后才對新的寫/編輯操作有效。
表2 集群復制架構圖
導出（Export）
HBase的導出工具是一個內置的有用功能。它使數據非常easy從hbase表導入HDFS文件夾下的SequenceFiles文件。
它創造了一個map reduce任務。通過一系列HBase API來調用集群，獲取指定表格的每一行數據。而且將數據寫入指定的HDFS文件夾中。這個工具對集群來講是性能密集的，由於它使用了mapreduce和HBase clientAPI。
可是它的功能豐富。支持制定版本號或日期范圍。支持數據的篩選，從而使增量備份可用。
以下是一個導出命令的簡單樣例：
hbase org.apache.hadoop.hbase.mapreduce.Export <tablename> <outputdir>一旦你的表導出了，你就能夠復制生成的數據文件到你想存儲的不論什么地方（比方異地/離線集群存儲）。你能夠運行一個遠程的HDFS集群/文件夾作為命令的輸出文件夾參數，這樣數據將會直接被導出到遠程集群。使用這種方法須要網絡。所以你應該確保到遠程集群的網絡連接是否可靠以及高速。
拷貝表（CopyTable）
拷貝表功能在文章《使用CopyTable在線備份HBase》中有具體描寫敘述，可是這里做了主要的總結。和導出功能類似，拷貝表也使用HBase API創建了一個mapreduce任務。以便從源表讀取數據。
不同的地方是拷貝表的輸出是hbase中的還有一個表，這個表能夠在本地集群，也能夠在遠程集群。
一個簡單的樣例例如以下：
hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=testCopy test這個命令將會拷貝名為test的表到集群中的另外一個表testCopy。
請注意，這里有一個明顯的性能開銷，它使用獨立的“puts”操作來逐行的寫入數據到目的表。假設你的表很大。拷貝表將會導致目標region server上的memstore被填滿。會引起flush操作並終於導致合並操作的產生，會有垃圾收集操作等等。
此外，你必須考慮到在HBase上執行mapreduce任務所帶來的性能影響。對於大型的數據集，這樣的方法的效果可能不太理想。
HBase API（比方作為一個java應用）
因為總是這樣使用hadoop。你能夠使用公用的api寫自己定制的client應用程序來直接查詢表格。你也能夠通過mapreduce任務的批量處理優勢，或者自己設計的其它手段。然而，這種方法須要對hadoop開發以及因此對生產集群帶來的影響有深入的理解。
離線備份原生的HDFS數據（Offline Backup of Raw HDFS Data）
最強力的備份機制。也是破壞性最大的一個。
涉及到最大的數據占用空間。
你能夠干凈的關閉你的HBase集群而且手工的在HDFS上拷貝數據。由於HBase已經關閉，所以能確保全部的數據已經被持久化到HDFS上的HFile文件里，你也將能獲得一個最准確的數據副本。
可是，增量的數據差點兒不能再獲得，你將無法確定哪些數據發生了變化。
同一時候也須要注意。恢復你的數據將須要一個離線的元數據由於.META.表將包括在修復時可能無效的信息。這樣的方法須要一個高速的。可信賴的網絡來傳輸異地的數據，假設須要在稍后恢復它的話。
因為這些原因。Cloudera很不鼓舞在HBase中這樣的備份方法。
故障恢復（Disaster Recory）
HBase被設計為一個非常能容忍錯誤的分布式系統，如果硬件失敗非常頻繁。在HBase中的故障恢復通常有下面幾種形式：
- 在數據中心級別的災難性故障，須要切換到備份位置；
- 須要恢復因為用戶錯誤或者意外刪除的數據的之前一個拷貝；
- 出於審計目的，恢復實時點數據拷貝的能力
正如其它的故障恢復計划，業務須要驅動這你怎樣架構而且投入多少金錢。一旦你確定了你將要選擇的備份方案。恢復將有下面幾種類型：
- 故障轉移到備份集群
- 導入表/恢復快照
- 指向HBase在備份位置的根文件夾
假設你的備份策略是這種，你復制你的HBase數據在不同數據中心的備份集群，故障轉移將變得簡單。僅須要使用DNS技術。轉移你的應用程序。
請記住。假設你打算同意數據在停運時寫入你的備份集群，那你須要確保在停運結束后。數據能夠回到主機群。主<->主或循環的復制架構能自己主動處理這個過程。但對於一個主從結構來講。你就須要手動進行干預了。
你也能夠在故障時通過簡單的改動hbase-site.xml的 hbase.root.dir屬性來更改hbase根文件夾，可是這是最不理想的還原選項。由於你復制完數據返回生產集群時，正如之前提到的。可能會發現.META是不同步的。
總結
綜上所述。從某種損失或中斷中恢復數據須要一個精心設計的BDR計划。
強烈建議你徹底明確你的業務需求，然后明確數據准確度/可用性以及故障恢復的最大時間。有了這些知識，你才干更好的選擇滿足這些需求的工具。
選擇工具不過個開始。你應該對你的BDR策略進行大規模測試，以確保它的在你的基礎設施下的功能。
而且，你應該是很熟悉全部的故障恢復步驟。
（翻譯的不是非常好，請如有錯誤之處，請見諒。）
原文地址：http://blog.cloudera.com/blog/2013/11/approaches-to-backup-and-disaster-recovery-in-hbase/
轉載請注明出處：http://blog.csdn.net/iAm333