作者：向師富 轉(zhuǎn)自：阿里巴巴數(shù)據(jù)中臺官網(wǎng)
https://dp.alibaba.com
概述數(shù)據(jù)抽取是指從源數(shù)據(jù)抽取所需要的數(shù)據(jù)， 是構(gòu)建數(shù)據(jù)中臺的第一步。 數(shù)據(jù)源一般是關(guān)系型數(shù)據(jù)庫，近幾年，隨著移動互聯(lián)網(wǎng)的蓬勃發(fā)展，出現(xiàn)了其他類型的數(shù)據(jù)源，典型的如網(wǎng)站瀏覽日期、APP瀏覽日志、IoT設(shè)備日志
從技術(shù)實現(xiàn)方式來講，從關(guān)系型數(shù)據(jù)庫獲取數(shù)據(jù)，可以細分為全量抽取、增量抽取2種方式，兩種方法分別適用于不用的業(yè)務(wù)場景
用時間戳方式抽取增量數(shù)據(jù)很常見，業(yè)務(wù)系統(tǒng)在源表上新增一個時間戳字段，創(chuàng)建、修改表記錄時，同時修改時間戳字段的值。 抽取任務(wù)運行時，進行全表掃描，通過比較抽取任務(wù)的業(yè)務(wù)時間、時間戳字段來決定抽取哪些數(shù)據(jù)。
此種數(shù)據(jù)同步方式，在準確率方面有兩個弊端：
1、只能獲取最新的狀態(tài)，無法捕獲過程變更信息，比如電商購物場景，如果客戶下單后很快支付，隔天抽取增量數(shù)據(jù)時，只能獲取最新的支付狀態(tài)，下單時的狀態(tài)有可能已經(jīng)丟失。針對此種問題，需要根據(jù)業(yè)務(wù)需求來綜合判定是否需要回溯狀態(tài)。
2、會丟失已經(jīng)被delete的記錄。如果在業(yè)務(wù)系統(tǒng)中，將記錄物理刪除。也就無法進行增量抽取。一般情況下，要求業(yè)務(wù)系統(tǒng)不刪除記錄，只對記錄進行打標。
業(yè)務(wù)系統(tǒng)維護時間戳如果使用了Oracle、DB2等傳統(tǒng)關(guān)系型數(shù)據(jù)庫，需要業(yè)務(wù)系統(tǒng)維護時間戳字段，業(yè)務(wù)系統(tǒng)在更新業(yè)務(wù)數(shù)據(jù)時，在代碼中更新時間戳字段。此種方法很常見，不過由于需要編碼實現(xiàn)，工作量會變大，有可能會出現(xiàn)漏變更的情形
觸發(fā)器維護時間戳典型的關(guān)系型數(shù)據(jù)庫，都支持觸發(fā)器。當數(shù)據(jù)庫記錄有變更時，調(diào)用特定的函數(shù)，更新時間戳字段。典型的樣例如下：
數(shù)據(jù)庫維護時間戳MySQL可以自動實現(xiàn)變更字段的維護，一定程度上減輕了開發(fā)工作量。 具體的實現(xiàn)樣例如下：
創(chuàng)建記錄
最終的結(jié)果如下，數(shù)據(jù)庫自動變更了時間戳字段：
近幾年，隨著互聯(lián)網(wǎng)的蓬勃發(fā)展，互聯(lián)網(wǎng)公司一般使用MySQL作為主數(shù)據(jù)庫，由于是開源數(shù)據(jù)庫，很多公司都做了定制化開發(fā)。 其中一個很大的功能點是通過訂閱MySQL binlog日志，實現(xiàn)了讀寫分離、主備實時同步，典型的示意圖如下：
解析binlog日志，給數(shù)據(jù)同步帶來了新的方法，將解析之后結(jié)果發(fā)送到Hive/MaxCompute等大數(shù)據(jù)平臺，實現(xiàn)秒級延時的數(shù)據(jù)同步。
解析binlog日志增量同步方式技術(shù)很先進，有3個非常大的優(yōu)點：
1.數(shù)據(jù)延時小。在阿里巴巴雙11場景，在巨大的數(shù)據(jù)量之下，可以做到秒級延時;
2.不丟失數(shù)據(jù)，可以捕獲數(shù)據(jù)delete的情形；
3.對業(yè)務(wù)表無額外要求，可以缺少時間戳字段；
當然，這種同步方式也有些缺點：
1.技術(shù)門檻很高。一般公司的技術(shù)儲備不夠，不足以自行完成整個系統(tǒng)搭建。目前國內(nèi)也僅限于頭部的互聯(lián)網(wǎng)公司、大型的國企、央企。不過隨著云計算的快速發(fā)展，在阿里云上開放了工具、服務(wù)，可以直接實現(xiàn)實時同步，經(jīng)典的組合是MySQL、DTS、Datahub、MaxCompute；
2.資源成本比較高，要求有一個系統(tǒng)實時接收業(yè)務(wù)庫的binlog日志，一直處于運行狀態(tài)，占用資源較多
3.業(yè)務(wù)表中需要有主鍵，以便進行數(shù)據(jù)排序
Oracle是功能非常強大的數(shù)據(jù)庫，通過Oracle GoldenGate實時解析Redo Log日志，并將解析后的結(jié)果發(fā)布到指定的系統(tǒng)
全量抽取全量抽取是將數(shù)據(jù)源中的表或視圖的數(shù)據(jù)原封不動的從數(shù)據(jù)庫中抽取出來，并寫入到Hive、MaxCompute等大數(shù)據(jù)平臺中，有點類似于業(yè)務(wù)庫之間的數(shù)據(jù)遷移。
全量同步比較簡單，常用于小數(shù)據(jù)量的離線同步場景。不過這種同步方法，也有兩個弊端，與增量離線同步一模一樣：
1.只能獲取最新的狀態(tài)
2.會丟失已經(jīng)被delete的記錄
原則上，在數(shù)據(jù)上云這個環(huán)節(jié)，建議只進行數(shù)據(jù)鏡像同步。不進行業(yè)務(wù)相關(guān)的數(shù)據(jù)轉(zhuǎn)換工作。從ETL策略轉(zhuǎn)變?yōu)镋LT，出發(fā)點有3個：
1.機器成本。在庫外進行轉(zhuǎn)換，需要額外的機器，帶來新的成本；
2.溝通成本。 業(yè)務(wù)系統(tǒng)的開發(fā)人員，也是數(shù)據(jù)中臺的用戶，這些技術(shù)人員對原始的業(yè)務(wù)庫表很熟悉，如果進行了額外的轉(zhuǎn)換，他們需要額外的學(xué)習(xí)其他工具、產(chǎn)品；
3.執(zhí)行效率。庫外的轉(zhuǎn)換機器性能，一般會低于MaxCompute、Hadoop集群，增加了執(zhí)行時間；
同步過程中，建議全表所有字段上云，減少后期變更成本
小數(shù)據(jù)量表
來源數(shù)據(jù)每日全量更新，采用數(shù)據(jù)庫直連方式全量抽取，寫入每日/每月全量分區(qū)表。
日志型表
原始日志增量抽取到每日增量表，按天增量存儲。因為日志數(shù)據(jù)表現(xiàn)為只會有新增不會有修改的情況，因此不需要保存全量表。
大數(shù)據(jù)量表
數(shù)據(jù)庫直連方式通過業(yè)務(wù)時間戳抽取增量數(shù)據(jù)到今日增量分區(qū)表，再將今日增量分區(qū)表merge前一日全量分區(qū)表，寫入今日全量分區(qū)表。
小時/分鐘增量表/不定期全量
來源數(shù)據(jù)更新頻率較高，達到分鐘/小時級別，從源數(shù)據(jù)庫通過時間戳抽取增量數(shù)據(jù)到小時/分鐘增量分區(qū)表，將N個小時/分鐘增量分區(qū)表merge入每日增量分區(qū)表，再將今日增量分區(qū)表merge前一日全量分區(qū)表，寫入今日全量分區(qū)表。
更多內(nèi)容詳見阿里巴巴數(shù)據(jù)中臺官網(wǎng)
https://dp.alibaba.com阿里巴巴數(shù)據(jù)中臺團隊，致力于輸出阿里云數(shù)據(jù)智能的最佳實踐，助力每個企業(yè)建設(shè)自己的數(shù)據(jù)中臺，進而共同實現(xiàn)新時代下的智能商業(yè)！
阿里巴巴數(shù)據(jù)中臺解決方案，核心產(chǎn)品：
Dataphin，以阿里巴巴大數(shù)據(jù)核心方法論OneData為內(nèi)核驅(qū)動，提供一站式數(shù)據(jù)構(gòu)建與管理能力；
Quick BI，集阿里巴巴數(shù)據(jù)分析經(jīng)驗沉淀，提供一站式數(shù)據(jù)分析與展現(xiàn)能力；
Quick Audience，集阿里巴巴消費者洞察及營銷經(jīng)驗，提供一站式人群圈選、洞察及營銷投放能力，連接阿里巴巴商業(yè)，實現(xiàn)用戶增長。
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
新聞名稱：數(shù)據(jù)上云，應(yīng)該選擇全量抽取還是增量抽??？
本文URL：
http://weahome.cn/article/pgcgji.html
重慶分公司
重慶分公司
