賦能雲HBase備份恢復 百T級別數據量備份恢復支持
為什麽需要雲HBase備份恢復？
??我們希望雲HBase支持備份和恢復功能，主要原因：
用戶直接訪問操作數據庫，可能存在安全風險；
項目存在合規以及監管的強需求；
對數據庫恢復數據到任意時間點（歸檔到任意時間點）需求；
HBase社區至今沒有release備份恢復功能。
??1、用戶直接訪問數據庫，存在安全風險
???用戶通過接口直接訪問HBase數據庫，這種情況下存在安全隱患的概率會比較大。一種可能性是***會通過***技術***數據庫，對用戶的數據進行肆意的“操作”，造成用戶數據無法訪問，然後進行勒索，參考前段時間的某某某數據庫勒索事件。當然這種case 在阿裏雲相關數據庫上是不會發生的，我們的數據庫有一些安全機制進行守護，且雲HBase自己也有自己的安全機制進行保障。
???另外一種潛在的安全隱患就是：由於用戶自己的誤操作造成的數據丟失或者數據庫不可訪問，比如我們之前經常聽到的“某某DBA由於誤操作，造成數據庫數據被物理刪除，無法恢復，造成公司損失”等等等消息。
???上述兩種情況如果數據有備份的話，可以把備份的數據恢復回來，即可避免以上風險。
??2、合規以及監管需求
???這種情況主要存在於一些特殊的項目中。由於數據的重要性或其他原因，會有監管的部門對數據是否做備份進行合規檢查。比如我們曾經遇到的汽車行業的某公司，因為其每輛汽車數據的重要性，需要對這些車輛數據做實時備份，且這些數據如果存在大面積丟失則會直接帶來監管審查問題。對於這種有監管需求的項目，備份恢復是必不可少的。
??3、數據庫恢復到任意時間點需求
???對數據庫的數據歸檔到過去某一時間點也是對備份恢復的一個比較強烈的需求。假如測試腳本意外寫入生產環境下的雲HBase表中，那麽會造成很多無效的數據產生，對於這種過去一段時間存在無效數據，不僅占用存儲空間且不方便刪除的情況，使用數據庫的PITR能力可以將數據庫數據做一種“清洗”，將數據恢復到產生無效數據之前。這裏需要說一下，雲HBase的恢復暫時只能支持恢復到過去10天內的時間點，且時間點的精確度是小時級別，暫時不能很精確的細化。
??4、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的恢復程序即可將數據恢復到對應的時間點。無論是備份集恢復還是時間點恢復都是將數據恢復到一個新的集群。
???選擇是備份集恢復還是時間點恢復主要是在控制臺頁面選擇：
???上述頁面可以選擇”備份點創建實列“，最後可以在下述頁面選擇具體的備份情況：
???完成如上操作以後，恢復程序開始執行恢復，等數據恢復完成即可。
展望
???後期我們的備份恢復會進一步深耕，繼續做的更細致，由於現階段我們的備份恢復只能達到集群級別的備份，那麽接下來需要支持更細粒度的備份和恢復，暫定細化到表級別；此外，我們還希望備份恢復的精確度可以降低到秒級別，這個事情也是需要投入精力的；再次對應備份恢復的速度我們希望可以再進行優化。
賦能雲HBase備份恢復 百T級別數據量備份恢復支持