一、方案背景

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

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

業(yè)務(wù)方對HBase表字段變更之后，需要重建hive映射表，給權(quán)限維護帶來一定的困難。

業(yè)務(wù)方對HBase表字段的變更無法得到有效監(jiān)控，無法及時感知字段的新增，對數(shù)倉的維護帶來一定的困難。

業(yè)務(wù)方更新數(shù)據(jù)時未更新時間戳，導(dǎo)致通過時間戳字段增量抽取時數(shù)據(jù)缺失。

業(yè)務(wù)方對表字段的更新新增無法及時感知，導(dǎo)致字段不全需要回溯數(shù)據(jù)。

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

二、方案簡述

1. 數(shù)據(jù)入倉構(gòu)建流程

2. HBase數(shù)據(jù)入倉方案實驗對比

分別對以上三種實現(xiàn)方案進行合理性分析。

2.1 方案一

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

HBase表雖然是Hadoop生態(tài)體系的NoSQL數(shù)據(jù)庫，但是其作為業(yè)務(wù)方的數(shù)據(jù)庫，直接通過hive映射表讀取，就類比于直接讀取業(yè)務(wù)方Mysql中的視圖，可能會對業(yè)務(wù)方數(shù)據(jù)庫造成一定壓力，甚至?xí)绊憳I(yè)務(wù)的正常運行，違反數(shù)倉盡可能低的影響業(yè)務(wù)運行原則。

通過hive映射表的方式，從實現(xiàn)方式上來講，增加了與業(yè)務(wù)方的耦合度，違反數(shù)倉建設(shè)解耦原則。

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

2.2 方案二

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

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

由于HBase表更新數(shù)據(jù)時，不像MySQL一樣，能自動更新時間戳，會導(dǎo)致業(yè)務(wù)方?jīng)]有及時更新時間戳，那么在增量抽取數(shù)據(jù)的時候，會造成數(shù)據(jù)缺失的情況。

所以此種方案存在一定的風(fēng)險。

2.3 方案三

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

綜上，采用方案三作為實現(xiàn)HBase海量數(shù)據(jù)入倉的解決方案。

3. 方案選擇及實現(xiàn)原理

基于HBase數(shù)據(jù)寫入時會更新TimeRange的特性，scan的時候如果指定TimeRange，那么就不需要掃描全表，直接根據(jù)TimeRange獲取到對應(yīng)的rowKey，然后再根據(jù)rowKey去get出增量信息，能夠?qū)崿F(xiàn)快速高效的獲取增量數(shù)據(jù)。

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

三、效果對比

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

四、總結(jié)與展望

數(shù)據(jù)倉庫的數(shù)據(jù)來源于各方業(yè)務(wù)系統(tǒng)，高效準(zhǔn)確的將業(yè)務(wù)系統(tǒng)的數(shù)據(jù)同步到數(shù)倉，是數(shù)倉建設(shè)的根本。通過該解決方案，主要解決了數(shù)據(jù)同步過程中的幾大痛點問題，能夠較好的保證數(shù)據(jù)入倉的質(zhì)量問題，為后續(xù)的數(shù)倉建設(shè)打下一個較好的基礎(chǔ)。

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

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