作者：向師富 轉自：阿里巴巴資料中臺官網

概述資料抽取是指從源資料抽取所需要的資料， 是構建資料中臺的第一步。 資料來源一般是關係型資料庫，近幾年，隨著移動網際網路的蓬勃發展，出現了其他型別的資料來源，典型的如網站瀏覽日期、APP瀏覽日誌、IoT裝置日誌
從技術實現方式來講，從關係型資料庫獲取資料，可以細分為全量抽取、增量抽取2種方式，兩種方法分別適用於不用的業務場景

增量抽取

時間戳方式

用時間戳方式抽取增量資料很常見，業務系統在源表上新增一個時間戳欄位，建立、修改表記錄時，同時修改時間戳欄位的值。 抽取任務執行時，進行全表掃描，透過比較抽取任務的業務時間、時間戳欄位來決定抽取哪些資料。
此種資料同步方式，在準確率方面有兩個弊端：
1、只能獲取最新的狀態，無法捕獲過程變更資訊，比如電商購物場景，如果客戶下單後很快支付，隔天抽取增量資料時，只能獲取最新的支付狀態，下單時的狀態有可能已經丟失。針對此種問題，需要根據業務需求來綜合判定是否需要回溯狀態。
2、會丟失已經被delete的記錄。如果在業務系統中，將記錄物理刪除。也就無法進行增量抽取。一般情況下，要求業務系統不刪除記錄，只對記錄進行打標。

業務系統維護時間戳如果使用了Oracle、DB2等傳統關係型資料庫，需要業務系統維護時間戳欄位，業務系統在更新業務資料時，在程式碼中更新時間戳欄位。此種方法很常見，不過由於需要編碼實現，工作量會變大，有可能會出現漏變更的情形

觸發器維護時間戳典型的關係型資料庫，都支援觸發器。當資料庫記錄有變更時，呼叫特定的函式，更新時間戳欄位。典型的樣例如下：

資料庫維護時間戳MySQL可以自動實現變更欄位的維護，一定程度上減輕了開發工作量。 具體的實現樣例如下：
建立記錄

最終的結果如下：

更新記錄

最終的結果如下，資料庫自動變更了時間戳欄位：

分析MySQL binlog日誌

近幾年，隨著網際網路的蓬勃發展，網際網路公司一般使用MySQL作為主資料庫，由於是開源資料庫，很多公司都做了定製化開發。 其中一個很大的功能點是透過訂閱MySQL binlog日誌，實現了讀寫分離、主備實時同步，典型的示意圖如下：

解析binlog日誌，給資料同步帶來了新的方法，將解析之後結果傳送到Hive/MaxCompute等大資料平臺，實現秒級延時的資料同步。

解析binlog日誌增量同步方式技術很先進，有3個非常大的優點：
資料延時小。在阿里巴巴雙11場景，在巨大的資料量之下，可以做到秒級延時;
不丟失資料，可以捕獲資料delete的情形；
對業務表無額外要求，可以缺少時間戳欄位；

當然，這種同步方式也有些缺點：
技術門檻很高。一般公司的技術儲備不夠，不足以自行完成整個系統搭建。目前國內也僅限於頭部的網際網路公司、大型的國企、央企。不過隨著雲端計算的快速發展，在阿里雲上開放了工具、服務，可以直接實現實時同步，經典的組合是MySQL、DTS、Datahub、MaxCompute；
資源成本比較高，要求有一個系統實時接收業務庫的binlog日誌，一直處於執行狀態，佔用資源較多
業務表中需要有主鍵，以便進行資料排序

分析Oracle Redo Log日誌

Oracle是功能非常強大的資料庫，透過Oracle GoldenGate實時解析Redo Log日誌，並將解析後的結果釋出到指定的系統

全量抽取全量抽取是將資料來源中的表或檢視的資料原封不動的從資料庫中抽取出來，並寫入到Hive、MaxCompute等大資料平臺中，有點類似於業務庫之間的資料遷移。
全量同步比較簡單，常用於小資料量的離線同步場景。不過這種同步方法，也有兩個弊端，與增量離線同步一模一樣：
1.只能獲取最新的狀態
2.會丟失已經被delete的記錄

業務庫表同步策略

同步架構圖從業務視角，可以將離線資料表同步細分為4個場景，總體架構圖表如下：

原則上，在資料上雲這個環節，建議只進行資料映象同步。不進行業務相關的資料轉換工作。從ETL策略轉變為ELT，出發點有3個：
1.機器成本。在庫外進行轉換，需要額外的機器，帶來新的成本；
2.溝通成本。 業務系統的開發人員，也是資料中臺的使用者，這些技術人員對原始的業務庫表很熟悉，如果進行了額外的轉換，他們需要額外的學習其他工具、產品；
3.執行效率。庫外的轉換機器效能，一般會低於MaxCompute、Hadoop叢集，增加了執行時間；
同步過程中，建議全表所有欄位上雲，減少後期變更成本

小資料量表來源資料每日全量更新，採用資料庫直連方式全量抽取，寫入每日/每月全量分割槽表。
日誌型表原始日誌增量抽取到每日增量表，按天增量儲存。因為日誌資料表現為只會有新增不會有修改的情況，因此不需要儲存全量表。
大資料量表資料庫直連方式透過業務時間戳抽取增量資料到今日增量分割槽表，再將今日增量分割槽表merge前一日全量分割槽表，寫入今日全量分割槽表。
小時/分鐘增量表/不定期全量來源資料更新頻率較高，達到分鐘/小時級別，從源資料庫透過時間戳抽取增量資料到小時/分鐘增量分割槽表，將N個小時/分鐘增量分割槽表merge入每日增量分割槽表，再將今日增量分割槽表merge前一日全量分割槽表，寫入今日全量分割槽表。

更多內容詳見阿里巴巴資料中臺官網
阿里巴巴資料中臺團隊，致力於輸出阿里雲資料智慧的最佳實踐，助力每個企業建設自己的資料中臺，進而共同實現新時代下的智慧商業！
阿里巴巴資料中臺解決方案，核心產品：
Dataphin，以阿里巴巴大資料核心方法論OneData為核心驅動，提供一站式資料構建與管理能力；
Quick BI，集阿里巴巴資料分析經驗沉澱，提供一站式資料分析與展現能力；
Quick Audience，集阿里巴巴消費者洞察及營銷經驗，提供一站式人群圈選、洞察及營銷投放能力，連線阿里巴巴商業，實現使用者增長。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。

資料上雲，應該選擇全量抽取還是增量抽取？

相關文章