賦能雲HBase備份恢復 百T級別數據量備份恢復支持

  雲HBase發佈備份恢復功能，爲用戶數據保駕護航。對大多數公司來講數據的安全性以及可靠性是很是重要的，如何保障數據的安全以及數據的可靠是大多數數據庫必須考慮的。2016 IDC的報告表示數據的備份（data-protection）和數據恢復（retention）是Nosql的最基礎的需求之一。

爲何須要雲HBase備份恢復？
  咱們但願雲HBase支持備份和恢復功能，主要緣由：

用戶直接訪問操做數據庫，可能存在安全風險；
項目存在合規以及監管的強需求；
對數據庫恢復數據到任意時間點（歸檔到任意時間點）需求；
HBase社區至今沒有release備份恢復功能。
  一、用戶直接訪問數據庫，存在安全風險
​  用戶經過接口直接訪問HBase數據庫，這種狀況下存在安全隱患的機率會比較大。一種可能性是黑客會經過黑客技術入侵數據庫，對用戶的數據進行肆意的「操做」，形成用戶數據沒法訪問，而後進行勒索，參考前段時間的某某某數據庫勒索事件。固然這種case 在阿里雲相關數據庫上是不會發生的，咱們的數據庫有一些安全機制進行守護，且雲HBase本身也有本身的安全機制進行保障。

​  另一種潛在的安全隱患就是：因爲用戶本身的誤操做形成的數據丟失或者數據庫不可訪問，好比咱們以前常常聽到的「某某DBA因爲誤操做，形成數據庫數據被物理刪除，沒法恢復，形成公司損失」等等等消息。

​  上述兩種狀況若是數據有備份的話，能夠把備份的數據恢復回來，便可避免以上風險。

  二、合規以及監管需求
​  這種狀況主要存在於一些特殊的項目中。因爲數據的重要性或其餘緣由，會有監管的部門對數據是否作備份進行合規檢查。好比咱們曾經遇到的汽車行業的某公司，由於其每輛汽車數據的重要性，須要對這些車輛數據作實時備份，且這些數據若是存在大面積丟失則會直接帶來監管審查問題。對於這種有監管需求的項目，備份恢復是必不可少的。

  三、數據庫恢復到任意時間點需求
​  對數據庫的數據歸檔到過去某一時間點也是對備份恢復的一個比較強烈的需求。假如測試腳本意外寫入生產環境下的雲HBase表中，那麼會形成不少無效的數據產生，對於這種過去一段時間存在無效數據，不只佔用存儲空間且不方便刪除的狀況，使用數據庫的PITR能力能夠將數據庫數據作一種「清洗」，將數據恢復到產生無效數據以前。這裏須要說一下，雲HBase的恢復暫時只能支持恢復到過去10天內的時間點，且時間點的精確度是小時級別，暫時不能很精確的細化。

  四、HBase社區至今沒有release備份恢復功能
​  HBase社區官方到如今沒有對外發布過穩定的備份恢復功能，官方建議的備份操做的方式在生產環境是不適合執行的。因此雲HBase提供一個穩定的備份恢復功能彌補了HBase社區在該方面的欠缺，也爲廣大HBase用戶提供了一個選擇。

雲HBase備份恢復：賦能HBase備份恢復能力
​  雲HBase備份恢復的設計之初的目的就是：賦能雲HBase備份恢復的能力、百T級別(起)數據量備份恢復支持、低用戶使用門檻、高性能、低備份成本、支持冷熱分離、兼容HBase2.0/1.x、備份集備份、恢復以及增量備份、時間點恢復等。

​  傳統數據庫備份恢復的能力都是TB級別，在交易等場景下面是足夠的，但面向大數據場景就捉襟見肘了。雲HBase經過垂直整合高壓縮、內核級優化等能力，將備份恢復的量級成功推高百倍以上，作到 百TB級別甚至更高 ，讓客戶在大數據量場景下也無後顧之憂。

​  咱們最終給出以下架構：一種包含了全量（備份集）備份、全量（備份集）恢復、增量（實時）備份、增量（時間點）恢復幾個模塊，接下來就這幾個模塊進行介紹；

備份數據

​  備份數據分爲2部分：開啓備份動做時間點前的存量數據，經過Hfile的形式進行讀取以及備份到目的端；時間點以及之後寫入的實時數據，會以Hlog的形式被讀取以及備份到遠端。這裏備份的遠端默認選擇是OSS，由於其具備11個9的數據可靠性，以及低成本等特色。上述存量數據的備份（備份集備份）會週期性的觸發，暫定週期是一週；實時產生的數據（實時備份）會及時的備份到遠端OSS。OSS上的數據，咱們會相應保留2個週期，這樣作主要是爲了清理冗餘數據。

​  備份數據過程當中，經過調整流量控制，能夠將備份帶來的影響下降到極低的一個程度。不管是備份集備份仍是實時備份，經過failover、takeover等機制，能夠保證即便某些備份進程異常，數據依舊能夠被備份到遠端，這裏能夠承諾作到小時級別的備份精確度。此外備份過程當中，經過將備份數據備份流量均勻分攤到集羣中的各個機器，能夠保證最高的備份效率，經過分佈式的備份進而支持備份規模達到百T甚至更高級別，即只要你敢存，咱們就敢備份。

恢復數據

​  從產品層面來看，若是用戶執行恢復集羣操做的話，雲HBase會將數據恢復到一個全新的集羣。這麼作的目的是，儘量的保證不侵入用戶數據，守護最後一道數據底線，若是數據恢復完成，對於原的集羣，用戶能夠自行處理。

​  數據恢復主要是將用戶的數據，從遠端(默認OSS)進行下載，其中包括存量的Hfile 數據以及增量的Hlog數據兩部分。那麼存量的Hfile數據，經過各個機器均衡下載，並各個機器執行bulkload，保證較快速的將存量數據恢復。對於Hlog 數據，一樣作到分佈式下載，各個機器回放相關的Hlog。經過充分利用各個機器的資源，將恢復速度作到最優。

​  恢復支持備份集恢復以及時間點恢復，若是用戶想恢復到過去某一個具體時間段的數據，那麼在頁面選擇一下相應時間段，點擊恢復便可。

一些指標

​  通過咱們的理論分析以及實際測試（8C32G，8Tx10），給出下列數據指標：

    1. 備份數據量能夠達到百T級別甚至更高；
    2. 備份集備份最長4天，正常狀況遠小於4天；
    3. 備份集恢復最長1天半；
    4. 日誌恢復數據精確度：1hour，最長容忍一小時的數據不許確；

​  上述第4點解釋下：所謂的恢復精確度是若是用戶想要將數據恢復到最新的一個時間點，恢復到的數據存在與需求的最新時間點數據最多一小時的偏差，其餘的恢復是沒問題的，可是實際咱們測試的狀況遠小於這個時間。

​  因爲分佈式備份，同等數據量下備份以及恢復速度是傳統數據庫的數倍。備份數據量、備份/恢復速度會隨着機器數量的擴容而不斷的增大。舉個例子一樣備份2T數據，傳統數據庫若是須要24小時，那麼咱們能夠保證備份速度能夠保證小於等於12小時。

雲HBase和自建的區別
  HBase社區到目前爲止沒有release備份恢復功能，官網只介紹了若是要作備份須要的操做流程參考link，能夠經過export作備份；此外社區有一個分支包含備份恢復功能，見link，但該分支開發好幾年，release時間未知，且版本不穩定；在這裏大概列一下雲HBase備份恢復和自建的區別；

雲HBase 自建HBase
備份恢復操做 操做簡單，點擊按鈕便可 操做複雜，須要手工觸發命令執行
備份過程是否依賴別的組件 依賴產品化組件，可是用戶無感知，無需用戶操做 依賴MapReduce，須要用戶搭建或者部署
最長備份精確度時間保證 1小時 不肯定
是否保證備份進程異常狀況下的數據備份 有 沒有
穩定性 多種數據量下反覆測試，保證穩定性 社區方案，穩定性未知
流量控制 有 export方案無、分支未release方案有
備份目的端數據冗餘 會有必定少許冗餘數據 存在較多冗餘數據
備份時間保證 有最長時間保證 未知
如何進行備份以及恢復
​  備份恢復整個操做流程都是很是簡單的界面化操做，一路點點點既能夠完成整個操做。

執行備份

​  用戶購買完成雲HBase集羣之後在本身的控制檯左側欄會看到「備份與恢復」選項欄，選擇該欄目，而後出現備份恢復相關的選項，第一次執行備份會須要重啓集羣，建議用戶在一個低峯期進行開啓操做，開啓備份操做可能須要幾分鐘，請用戶耐心等待。點擊開啓備份恢復之後，按照對應的選項指導 用戶能夠選擇備份集備份的時間點，選擇完成之後，就會週期性的在這個時刻觸發一次備份集備份，至於實時數據備份在第一次開啓備份的時候就觸發了。

​  完成上述設置之後，咱們整個備份操做便可正常開啓以及執行了。

執行恢復

​  雲HBase的恢復包括備份集恢復以及時間點恢復。備份集恢復即恢復到過去執行的某一次備份集備份的數據，而時間點恢復即用戶能夠選擇某一個特定的時間段（小時級別），而後雲HBase的恢復程序便可將數據恢復到對應的時間點。不管是備份集恢復仍是時間點恢復都是將數據恢復到一個新的集羣。

​  選擇是備份集恢復仍是時間點恢復主要是在控制檯頁面選擇：

​  上述頁面能夠選擇」備份點建立實列「，最後能夠在下述頁面選擇具體的備份狀況：

​  完成如上操做之後，恢復程序開始執行恢復，等數據恢復完成便可。

展望​  後期咱們的備份恢復會進一步深耕，繼續作的更細緻，因爲現階段咱們的備份恢復只能達到集羣級別的備份，那麼接下來須要支持更細粒度的備份和恢復，暫定細化到表級別；此外，咱們還但願備份恢復的精確度能夠下降到秒級別，這個事情也是須要投入精力的；再次對應備份恢復的速度咱們但願能夠再進行優化。