一、方案背景
現階段部分業務資料儲存在HBase中，這部分資料體量較大，達到數十億。大資料需要增量同步這部分業務資料到資料倉儲中，進行離線分析，目前主要的同步方式是通過HBase的hive對映表來實現的。該種方式具有以下痛點：
-
需要對HBase表進行全表掃描，對HBase庫有一定壓力，同步資料同步速度慢。
-
業務方對HBase表欄位變更之後，需要重建hive對映表，給許可權維護帶來一定的困難。
-
業務方對HBase表欄位的變更無法得到有效監控，無法及時感知欄位的新增，對數倉的維護帶來一定的困難。
-
業務方更新資料時未更新時間戳，導致通過時間戳欄位增量抽取時資料缺失。
-
業務方對錶欄位的更新新增無法及時感知，導致欄位不全需要回溯資料。
基於以上背景，對HBase資料增量同步到數倉的場景，給出了通用的解決方案，解決了以上這些痛點。
二、方案簡述
2.1 資料入倉構建流程
2.2 HBase資料入倉方案實驗對比
分別對以上三種實現方案進行合理性分析。
2.2.1 方案一
使用HBase的hive對映表。此種方案實現方式簡單，但是不符合數倉的實現機制，主要原因有：
-
HBase表雖然是Hadoop生態體系的NoSQL資料庫，但是其作為業務方的資料庫，直接通過hive對映表讀取，就類比於直接讀取業務方Mysql中的檢視，可能會對業務方資料庫造成一定壓力，甚至會影響業務的正常執行，違反數倉儘可能低的影響業務執行原則。
-
通過hive對映表的方式，從實現方式上來講，增加了與業務方的耦合度，違反數倉建設解耦原則。
所以此種方案在此實際應用場景中，是不應該採取的方案。
2.2.2 方案二
根據業務表中的時間戳欄位，抓取增量資料。由於HBase是基於rowKey的NoSQL資料庫，所以會存在以下幾個問題：
-
需要通過Scan全表，然後根據時間戳（updateTime）過濾出當天的增量，當資料量達到千萬甚至億級時，這種執行效率就很低，執行時長很長。
-
由於HBase表更新資料時，不像MySQL一樣，能自動更新時間戳，會導致業務方沒有及時更新時間戳，那麼在增量抽取資料的時候，會造成資料缺失的情況。
所以此種方案存在一定的風險。
2.2.3 方案三
根據HBase的timeRange特性（HBase寫入資料的時候會記錄時間戳，使用的是伺服器時間），首先過濾出增量的rowKey，然後根據這些rowKey去HBase查詢對應的資料。這種實現方案同時解決了方案一、方案二的問題。同時，能夠有效監控業務方對HBase表欄位的新增情況，避免業務方未及時通知而導致的資料缺失問題，能夠最大限度的減少資料回溯的頻率。
綜上，採用方案三作為實現HBase海量資料入倉的解決方案。
2.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表的方式同步到數倉，這個將在後期進行效能測試。
作者：vivo網際網路大資料團隊-Tang Xicheng