關于XX業(yè)務系統(tǒng)數據同步方案簡介

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

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

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

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

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

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

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

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

9、再將DSnew追加寫入，這樣就可以得到最新的全集數據了。 在這個過程 中DSmid則被稱之為差集。將DSmid與DSnew共同寫入HDFS,則被稱之為數據合并。注：為更好的確保差集計算的準確性，此處必須確保被計算的數據集 存在主鍵字段，否則差集計算可能存在問題。附：Spark差集計算函數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數據處理方案由于XX業(yè)務系統(tǒng)生產數據庫存放在電信機房，而Spark集群部署在公 司內網，兩者在網絡環(huán)境上存在一定隔

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

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

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