一、方案背景

現階段部分業務數據存儲在HBase中，這部分數據體量較大，達到數十億。大數據需要增量同步這部分業務數據到數據倉庫中，進行離線分析，目前主要的同步方式是通過HBase的hive映射表來實現的。該種方式具有以下痛點：

需要對HBase表進行全表掃描，對HBase庫有一定壓力，同步數據同步速度慢。

業務方對HBase表字段變更之后，需要重建hive映射表，給權限維護帶來一定的困難。

業務方對HBase表字段的變更無法得到有效監控，無法及時感知字段的新增，對數倉的維護帶來一定的困難。

業務方更新數據時未更新時間戳，導致通過時間戳字段增量抽取時數據缺失。

業務方對表字段的更新新增無法及時感知，導致字段不全需要回溯數據。

基于以上背景，對HBase數據增量同步到數倉的場景，給出了通用的解決方案，解決了以上這些痛點。

二、方案簡述

1. 數據入倉構建流程

2. HBase數據入倉方案實驗對比

分別對以上三種實現方案進行合理性分析。

2.1 方案一

使用HBase的hive映射表。此種方案實現方式簡單，但是不符合數倉的實現機制，主要原因有：

HBase表雖然是Hadoop生態體系的NoSQL數據庫，但是其作為業務方的數據庫，直接通過hive映射表讀取，就類比于直接讀取業務方Mysql中的視圖，可能會對業務方數據庫造成一定壓力，甚至會影響業務的正常運行，違反數倉盡可能低的影響業務運行原則。

通過hive映射表的方式，從實現方式上來講，增加了與業務方的耦合度，違反數倉建設解耦原則。

所以此種方案在此實際應用場景中，是不應該采取的方案。

2.2 方案二

根據業務表中的時間戳字段，抓取增量數據。由于HBase是基于rowKey的NoSQL數據庫，所以會存在以下幾個問題：

需要通過Scan全表，然后根據時間戳(updateTime)過濾出當天的增量，當數據量達到千萬甚至億級時，這種執行效率就很低，運行時長很長。

由于HBase表更新數據時，不像MySQL一樣，能自動更新時間戳，會導致業務方沒有及時更新時間戳，那么在增量抽取數據的時候，會造成數據缺失的情況。

所以此種方案存在一定的風險。

2.3 方案三

根據HBase的timeRange特性(HBase寫入數據的時候會記錄時間戳，使用的是服務器時間)，首先過濾出增量的rowKey，然后根據這些rowKey去HBase查詢對應的數據。這種實現方案同時解決了方案一、方案二的問題。同時，能夠有效監控業務方對HBase表字段的新增情況，避免業務方未及時通知而導致的數據缺失問題，能夠最大限度的減少數據回溯的頻率。

綜上，采用方案三作為實現HBase海量數據入倉的解決方案。

3. 方案選擇及實現原理

基于HBase數據寫入時會更新TimeRange的特性，scan的時候如果指定TimeRange，那么就不需要掃描全表，直接根據TimeRange獲取到對應的rowKey，然后再根據rowKey去get出增量信息，能夠實現快速高效的獲取增量數據。

為什么scan之后還要再去get呢?主要是因為通過timeRanme出來的數據，只包含這個時間范圍內更新的列，而無法查詢到這個rowkey對應的所有字段。比如一個rowkey有name，age兩個字段，在指定時間范圍內只更新了age字段，那么在scan的時候，只能查詢出age字段，而無法查詢出name字段，所以要再get一次。同時，獲取增量數據對應的columns，跟hive表的meta數據進行比對，對字段的變更進行及時預警，減少后續因少同步字段內容而導致全量初始化的情況發生。其實現的原理圖如下：

三、效果對比

運行時間對比如下(單位：秒)：

四、總結與展望

數據倉庫的數據來源于各方業務系統，高效準確的將業務系統的數據同步到數倉，是數倉建設的根本。通過該解決方案，主要解決了數據同步過程中的幾大痛點問題，能夠較好的保證數據入倉的質量問題，為后續的數倉建設打下一個較好的基礎。

另外，通過多次實驗對比，及對各種方案的可行性分析，將數據同步方案同步給一站式大數據開發平臺，推動大數據開發平臺支持基于timeRange的增量同步功能，實現此功能的平臺化、配置化，解決了HBase海量數據入倉的痛點。

同時，除了以上這幾種解決方案之外，還可以嘗試結合Phoenix使用二級索引，然后通過查詢Phoenix表的方式同步到數倉，這個將在后期進行性能測試。