一、方案背景

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

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

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

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

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

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

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

二、方案簡(jiǎn)述

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

2. HBase數(shù)據(jù)入倉(cāng)方案實(shí)驗(yàn)對(duì)比

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

2.1 方案一

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

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

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

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

2.2 方案二

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

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

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

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

2.3 方案三

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

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

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

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

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

三、效果對(duì)比

運(yùn)行時(shí)間對(duì)比如下(單位：秒)：

四、總結(jié)與展望

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

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

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

原文地址：https://mp.weixin.qq.com/s/tqC4HCvxhVxOgujWdr1eXg