關(guān)于XX業(yè)務(wù)系統(tǒng)數(shù)據(jù)同步方案簡介

1、關(guān)于 XX 業(yè)務(wù)系統(tǒng)數(shù)據(jù)同步方案簡介修訂記錄版本修訂人說明日期目錄1. 概述42. 數(shù)據(jù)分析現(xiàn)狀53. 數(shù)據(jù)同步方案63.1. 理論分析73.1.1. 理論值分析73.1.2. 必要條件93.1.3. 差集計算93.2. 數(shù)據(jù)處理方案113.2.1. 歷史數(shù)據(jù)處理 113.2.2. 過渡性數(shù)據(jù)處理 123.2.3. 常規(guī)數(shù)據(jù)處理 123.3. 數(shù)據(jù)時效性12未知性說明141.概述XX業(yè)務(wù)系統(tǒng)技術(shù)支持人員大部分時間均在進(jìn)行數(shù)據(jù)統(tǒng)計分析，且基本是在正式環(huán)境中進(jìn)行數(shù)據(jù)分析處理，而此舉在實際操作中除會給生產(chǎn)系統(tǒng) 帶來諸多壓力之外，還可能因為操作人員新建大量臨時表時操作失誤而出 現(xiàn)刪表或者刪數(shù)據(jù)的情況。

2、針對上述情況并結(jié)合可視化分析系統(tǒng)的現(xiàn)有使用情況，做本建設(shè)性思 考方案，旨在針對實際問題提出理論上的建設(shè)性方案。2. 數(shù)據(jù)分析現(xiàn)狀XX業(yè)務(wù)系統(tǒng)數(shù)據(jù)分析一直因為數(shù)據(jù)時效性而無法很好的使用Spark集群，且目前已建設(shè)的可視化分析環(huán)境因為歷史數(shù)據(jù)存在被修改的可能性而 導(dǎo)致用之甚少。且當(dāng)前XX業(yè)務(wù)系統(tǒng)集群可視化分析環(huán)境采用按月（月中） 更新、人工拷貝而后轉(zhuǎn)由集群導(dǎo)入的方式，如下圖1所示。正式庫備份庫集群庫圖1 -xx業(yè)務(wù)系統(tǒng)數(shù)據(jù)同步示意圖該方式在實際操作中非常消耗人力、 物力，且集群數(shù)據(jù)利用率極低（XX業(yè)務(wù)系統(tǒng)版集群可視化環(huán)境幾乎沒人使用）3. 數(shù)據(jù)同步方案近期，在處理HBase數(shù)據(jù)同步至HDFS方案時

3、，構(gòu)思如下數(shù)據(jù)更新方案，如圖2所示:近期數(shù)據(jù)圖2 -HBase數(shù)據(jù)遷移理論方案示意圖全量數(shù)據(jù)同理，將HBase替換成XX業(yè)務(wù)系統(tǒng)生產(chǎn)數(shù)據(jù)庫，則會得到下圖 3所示方案示意圖:圖3-XX業(yè)務(wù)系統(tǒng)數(shù)據(jù)遷移理論方案示意圖. 近期數(shù)據(jù)全量數(shù)據(jù)Oracle該方案是采用螞蟻搬家的思路，若在此方案思路使用至XX業(yè)務(wù)系統(tǒng) 數(shù)據(jù)同步中將會使數(shù)據(jù)從一個月的更新周期調(diào)整為一天，從而使集群數(shù)據(jù)更接近實時數(shù)據(jù)，從而為XX業(yè)務(wù)系統(tǒng)日常統(tǒng)計使用Spark集群提供了可能 性。3.1.理論分析前期在XX業(yè)務(wù)系統(tǒng)數(shù)據(jù)同步過程中，一直困擾的問題是XX業(yè)務(wù)系統(tǒng) 數(shù)據(jù)存在被修改的可能性，且修改的數(shù)據(jù)可能是近期也可能是N年前的歷史數(shù)據(jù)。鑒

4、于此實際情況，前期思路一直停留在如何才能以更快速的方式 加載生產(chǎn)數(shù)據(jù)庫中的全量數(shù)據(jù)。且之前提出的偽增量方案由于局限性也不 能很好的解決XX業(yè)務(wù)系統(tǒng)數(shù)據(jù)面臨的實際問題?，F(xiàn)在我們換個思路，如果不能一次性獲取那么大批量的數(shù)據(jù)信息，為何不能采用大量數(shù)據(jù)按時間段切分成很多小塊數(shù)據(jù)的思路來處理？借用Spark Streaming將數(shù)據(jù)按時間切片的思路，將XX業(yè)務(wù)系統(tǒng)數(shù)據(jù) 進(jìn)行切片，將數(shù)據(jù)切分成一個個較小的數(shù)據(jù)塊。如下圖 4所示，可以通過切片將月度數(shù)據(jù)集切分成多個日度數(shù)據(jù)集。月度數(shù)據(jù)集日數(shù)據(jù)圖4 -XX業(yè)務(wù)系統(tǒng)數(shù)據(jù)切片示意圖3.1.1.理論值分析假設(shè)XX業(yè)務(wù)系統(tǒng)數(shù)據(jù)月度更新（包含新增、修改）量平均值為S,且

5、每月天數(shù)按照30日計算，則在對數(shù)據(jù)切片之后，每天需要處理的數(shù)據(jù)量將為Si = 一。若S數(shù)量級的數(shù)據(jù)同步（Oracle至HDFS,不考慮人工數(shù)據(jù)遷移）耗時為T,則Si數(shù)量級的數(shù)據(jù)同步耗時則為 Ti =（,-）（注：此區(qū)間范圍是通 過既往集群數(shù)據(jù)處理總結(jié)所得）。目前海南醫(yī)保智能審核數(shù)據(jù)均來自 XX業(yè)務(wù)系統(tǒng)系統(tǒng)，所以使用海南智能審核數(shù)據(jù)處理耗時來對XX業(yè)務(wù)系統(tǒng)數(shù)據(jù)處理耗時進(jìn)行理論分析存在 一定的參考價值95G HNF dtatjcw住仁ltM俅柱有ETMUd町黠記錄:idfl鈦値拘昭T.jt小IBKjISZEgLTTlE圖5-智能審核月度數(shù)據(jù)處理耗時如上圖5所示，為智能審核系統(tǒng)2018年12月度住院

6、醫(yī)囑明細(xì)1721W 數(shù)據(jù)從數(shù)據(jù)庫通過JDBC方式抽取到HDFS的耗時日志信息。在此我們假定S=1721W,T=1891秒,則理論上將上述數(shù)據(jù)按日切分后，每日需要處理的數(shù)據(jù)量Si=57.36W,處理耗時Ti將在（63秒,630秒）的區(qū)間范圍內(nèi)注：此處處理耗時區(qū)間跨度較大是因為 Spark采用JDBC方式從數(shù)據(jù)源 抽取數(shù)據(jù)的耗時，受被抽取數(shù)據(jù)表的數(shù)據(jù)量、網(wǎng)絡(luò)傳輸速度以及數(shù)據(jù)源物 理磁盤空間等因素所影響，在不同參數(shù)環(huán)境下，同等數(shù)據(jù)量的處理耗時不 盡相同。對于住院醫(yī)囑明細(xì)這類數(shù)據(jù)量大的數(shù)據(jù)表，其日度數(shù)據(jù)處理耗時在63630秒的區(qū)間內(nèi)，且智能審核采取省級數(shù)據(jù)單表存儲而非按地區(qū)分表存儲模式，所以其理論數(shù)據(jù)

7、處理耗時會大于分表存儲模式。3.1.2.必要條件在該數(shù)據(jù)同步方案中（圖3所示）,必須確保數(shù)據(jù)源能夠滿足提取近期數(shù) 據(jù)這一必要條件。而這里的 近期數(shù)據(jù)則是近期新增或者修改的數(shù)據(jù)合集。如何確定哪些數(shù)據(jù)是最近新增或者修改的呢？據(jù)前期了解，XX業(yè)務(wù)系統(tǒng)數(shù)據(jù)中大部分業(yè)務(wù)數(shù)據(jù)表存在該條數(shù)據(jù)記錄的更新時間字段。且大部分 數(shù)據(jù)的刪除為邏輯刪除，而非物理刪除。如此一來，在確保沒有人工手動修改數(shù)據(jù)的前提下，就可以通過各表中的更新時間字段來獲取到最近更新 的數(shù)據(jù)信息。注意，這里所取的近期數(shù)據(jù)均取自數(shù)據(jù)庫相關(guān)業(yè)務(wù)表，若業(yè)務(wù)表數(shù)據(jù) 量較大則通過更新時間字段進(jìn)行數(shù)據(jù)篩選提取時，可能會對數(shù)據(jù)表的性能 指標(biāo)造成一定的影響。3

8、.1.3.差集計算如前所述，在該數(shù)據(jù)同步方案中，需要對Oracle提取的最新數(shù)據(jù)集DSnew和HDFS中的全量數(shù)據(jù)集DSaii進(jìn)行差集運算，這里的差集如何定義？+4+id|code|name|age|I i| ooi| 乘三ia|2 0021 孕曲喜 | 211圖6-數(shù)據(jù)集示例如上圖6所示，上面部分為全集數(shù)據(jù) DSaii下面部分為最新數(shù)據(jù)DSnew , 我們可以很清晰的知道code為001、002的兩個數(shù)據(jù)對應(yīng)的name信息被修 改。那么此時如果要將更新后的數(shù)據(jù)替換掉DSall中的原有的數(shù)據(jù)，則需先將DSaii中code為001和002的記錄去掉得到DSmid,并將DSmid寫入HDFS 而后

9、再將DSnew追加寫入，這樣就可以得到最新的全集數(shù)據(jù)了。 在這個過程 中DSmid則被稱之為差集。將DSmid與DSnew共同寫入HDFS,則被稱之為數(shù)據(jù)合并。注：為更好的確保差集計算的準(zhǔn)確性，此處必須確保被計算的數(shù)據(jù)集 存在主鍵字段，否則差集計算可能存在問題。附：Spark差集計算函數(shù)geisiffermaFrapeayPiti Ifa DaiaF . dfa 血如卜料r*p spark 沁rksesjion cALiit uLitfstring Dmsi fame judgeuse if pkLisL size = &： return ijetDif&rOataf raiH dfA df3

10、Ml 4k5lty dfPKs dIA wlect plutriing frvcept dfB itlect ipkStrlrelseHfK - dfA i&lert picMrinq pk和 叫比邛riclfp. vlWp旳Trirjg pJk奮) dHs createCrRepleTenFtfie(5 StscbeiHSt rin tf4 J1Ji PKi. c.r!aleOi?ReipilaceTfiipViwJ$ ifeg川斗 Jh睡f主憑方na的專期楚播屋rar sqlstr ：striftg = SsaLect n* frnn S(sBia5tring_dfA rt imer ja

11、n SbfscfiiBiastringldfFKj s on a.StpkSTrihg = $.lpkStrlng|i pin. fariKhfpk = (fqUtr i f and 気pk v，Spfcp*l reSiDl- spark.tql iqiUtr.spirt citalog dnpTitm(rtlfcs slfschwiiiriing)_afA1!spark catalog d-?d-?713ie-(5-S-(SCheni5itrin|MdHFFK5) res&F32數(shù)據(jù)處理方案由于XX業(yè)務(wù)系統(tǒng)生產(chǎn)數(shù)據(jù)庫存放在電信機(jī)房，而Spark集群部署在公 司內(nèi)網(wǎng)，兩者在網(wǎng)絡(luò)環(huán)境上存在一定隔

12、閡且 XX業(yè)務(wù)系統(tǒng)生產(chǎn)數(shù)據(jù)庫太大 不可能通過網(wǎng)絡(luò)傳輸方式將數(shù)據(jù)一次性傳輸至集群服務(wù)器，所以本方案將 數(shù)據(jù)處理分為三個步驟，即歷史數(shù)據(jù)處理、過渡性數(shù)據(jù)處理及常規(guī)數(shù)據(jù)處3.2.1.歷史數(shù)據(jù)處理即XX業(yè)務(wù)系統(tǒng)過往歷史數(shù)據(jù)，此類數(shù)據(jù)特征為體量大、集群服務(wù)器上不存在該部分?jǐn)?shù)據(jù)（此處假設(shè)集群服務(wù)器不存放任何XX業(yè)務(wù)系統(tǒng)相關(guān)數(shù) 據(jù)）。在對歷史數(shù)據(jù)做處理時，需要將該部分?jǐn)?shù)據(jù)通過現(xiàn)有人工拷貝處理方 式備份至公司內(nèi)網(wǎng)Oracle服務(wù)器，而后再由Spark通過JDBC方式進(jìn)行全 量數(shù)據(jù)抽取處理。322.過渡性數(shù)據(jù)處理由于XX業(yè)務(wù)系統(tǒng)生產(chǎn)數(shù)據(jù)體量大，所以在歷史數(shù)據(jù)處理時，將會出 現(xiàn)耗時相對較久的情況。而此段時間內(nèi)，X

13、X業(yè)務(wù)系統(tǒng)生產(chǎn)庫將會源源不斷 的產(chǎn)生新的數(shù)據(jù)信息，此時在歷史數(shù)據(jù)同步至HDFS，需對此段過渡期的數(shù) 據(jù)進(jìn)行批量處理，即使用該同步方案思路將近N天的數(shù)據(jù)同步至HDFS，以此來確保HDFS與XX業(yè)務(wù)系統(tǒng)生產(chǎn)數(shù)據(jù)庫的數(shù)據(jù)一致性問題。3.2.3.常規(guī)數(shù)據(jù)處理在過渡性數(shù)據(jù)處理完成后，后續(xù)處理即為常規(guī)處理，即按日從XX業(yè)務(wù)系統(tǒng)正式庫抽取最新數(shù)據(jù)，而后同步至HDFS,從而得到最新的數(shù)據(jù)信息。33數(shù)據(jù)時效性如前所述該方案采用按日同步的方式， 理論而言HDFS上的數(shù)據(jù)與XX業(yè)務(wù)系統(tǒng)正式數(shù)據(jù)庫時差為1天。然而此處的1天在不同語境及處理方式由于Spark集群對數(shù)據(jù)分析采用的是基于數(shù)據(jù)模型的分析方式，即用戶 在進(jìn)行數(shù)

14、據(jù)分析前需對原始數(shù)據(jù)進(jìn)行加工處理。如此一來，數(shù)據(jù)處理的耗 時將為數(shù)據(jù)導(dǎo)入和模型生成的耗時總和。根據(jù)最近一次（2019年1月3日）XX業(yè)務(wù)系統(tǒng)數(shù)據(jù)模型生成情況來 看，當(dāng)前數(shù)據(jù)量下XX業(yè)務(wù)系統(tǒng)所有模型生成耗時為2.4小時，而且后續(xù)會 隨著業(yè)務(wù)量的增加而耗時更久，所以 此處假設(shè)模型生成耗時為3小時。為確保工作人員能夠在上午8點開始正常使用Spark集群進(jìn)行數(shù)據(jù)相關(guān) 統(tǒng)計分析，則在除去模型生成的3小時耗時外，若從0點計時則會有5小 時的時長用以進(jìn)行數(shù)據(jù)的同步處理。然而，據(jù)前期對接XX業(yè)務(wù)系統(tǒng)所了解的情況，在0點之后XX業(yè)務(wù)系統(tǒng)系統(tǒng)將有大量批量任務(wù)需要執(zhí)行，數(shù) 據(jù)庫壓力很大，若在此時段進(jìn)行數(shù)據(jù)抽取處理，則會對XX業(yè)務(wù)系統(tǒng)正式數(shù)據(jù)庫的正常