1 前言
我在上一篇中介紹了實時集成與離線集成該怎麼選擇，接着介紹一下離線集成中的增量與全量的選擇問題。
要設計方案，我們先分析一下數據產生的方式。我們把音視頻流這種非結構化的數據集成從這裏排除出去，因爲這種音視頻流一般都是專業的廠商和系統來處理。我們圍繞數據分析領域常見的半結構化、結構化數據來看。
結構化和半結構化數據主要來源於各種設備和系統中運行的軟件，包括寫入各種數據庫的數據、服務器中的日誌。如果數據本身可以實時傳輸過來，那麼我們就儘可能採用這種方式，但是實際工作中更多的場合是離線。尤其是項目的一期，更容易使用離線集成。
實時集成就相當於收快遞，需要商家和物流企業先期投入大量建設，才能讓快遞便捷的傳輸到你手裏。而這種什麼都準備好的情況，大部分時候都是企業IT建設相對成熟的情況下才有。
日誌這種文件流，如果採用實時採集，就屬於實時集成範圍。如果離線傳輸，就是傳個文件，本身就沒有太多需要講述的。下面我們就討論下從數據庫中實施離線集成的方法。
2 數據庫的數據
一提到傳統數據庫，就想到了結構化數據。但是數據庫其實可以存儲各種能存儲的下的數據，比如音視頻文件其實可以存儲到LOB類型的二進制大對象字段中。而半結構化數據，可以存儲到string、text、CLOB等字符型二進制大對象字段中。工業控制系統產生的時序數據，也可以存儲到數據庫中。
而數據庫中的數據操作有插入、更新、刪除，不同種類的操作會對集成有影響。
如果要對一個數據庫做全庫的集成，首先要決定哪些表是我們要入倉的。一定不要不經分析就把數據集成到數據倉庫或者數據中臺中。按照維度建模的理念，需要以需求爲導向去構建模型，所以，集成的數據表一定是要明確有需求。這樣我們就能確定一個範圍，而不是全部。
劃定範圍，我們就會遇到非結構化數據入庫的問題，因爲MaxCompute本身是不支持大字段的，最長的字段長度是string，只有8M。至於數據庫的LOB存儲什麼，五花八門，我見過照片、音頻、Word文檔、這些要集成，統統都需要傳輸到OSS，而不是MaxCompute。目前這種數據，還需要單獨開發程序去集成到OSS。
剩下的我們就可以理解爲結構化和半結構化數據了，一般能用string存的下的都可以集成到MaxCompute。例如一些XML、JSON半結構化數據，之前在數據庫是存儲在CLOB類型的字段中的，但是本身並不是超過8M。
接下來我們就需要評估該如何集成數據了-增量還是全量。
3 增量還是全量
回顧之前在實時還是離線的章節總結的集成原則。
集成原則：
1 費用緊張，資源有限，儘可能使用離線集成。
2 批處理數據（主要指源端數據是批量產生，或者雙十一式爆發式產生）集成，儘量走離線。如果確實預算非常充足，資源非常豐富，也可以走實時集成（很多時候，源端都可能扛不住）。
3 交易型數據集成，儘量走實時，如果資源有限可以走離線。
4 大表，例如數據超過200W、存儲超過1G，儘量走實時，這種表一般在業務系統中數量不會超過表數量的20%。離線集成時效性很難滿足要求，當然也不是不行。一般離線集成的表在1-10億這個級別也是可以一戰（與系統資源相關）。再大基本上就很難了，集成時間過久，業務系統沒有足夠的快照空間，事務會報錯，集成就會失敗。
5 小表，例如常年不動的代碼表，10W以下的小表，大概都能在30秒-3分鐘內完成，建議走離線。畢竟實時挺貴，這些小表，還是打包搞過來比較適合。
我們看到我把數據分爲“批處理”、“交易型”、“大表”、“小表”。很明顯，“批處理”和“交易型”是一個對照組，“大表”和“小表”是一個對照組。
先看下什麼是“批處理”，主要是指數據並不是由業務系統的業務事件產生，而是由數據庫或者應用後臺運行的數據運行，其特點是一次操作的數據或者產生的數據是多條（幾萬到數億）記錄。“批處理”操作主要在做後臺數據庫版本發佈的批量運維，夜間批量做數據處理，幾個表關聯生成一張新的表。這種操作瞬時產生大量的數據操作，少則幾萬，多則數億，且發生時間相對短暫。對應的“交易型”則是實時發生，是由實際的業務發生時產生。並不是定時任務和運維人員提交到數據庫的，是由應用提交到數據庫的。
“大表”和“小表”需要畫一條線，根據數據庫系統的能力來評估。一般按照二八原則，或者一九。就是說一般數據庫中90%表都是小表，根據數據庫的規模，可以是10萬也可以是100萬。
1.全量集成
先說大小表，這個比較簡單，一旦劃定了大小表。就可以確定，小表是可以全部使用全量集成的。所以，這個邊界是全量離線集成的邊界。剩下的大表，就困難了。大表的意思就是全量集成不能完成，或者對數據庫的負載過大，搞不定。這部分就需要考慮增量集成了。
2.增量集成
因爲小表全量集成很暴力了，無所謂什麼，都能集成過來。而大表的增量要怎麼獲取呢？真的很難。我有一句總結：沒有一個業務系統的時間戳字段是可信的。大家可以去證明我是錯誤的，我的見識是淺薄的，但是這就是從業十多年的我的見識。
首先，增量集成需要數據庫表不能有物理刪除，這很難實現。即便業務系統在設計之初有這種設計，也難以避免後臺人工運維引入非正常操作問題。
其次，標識數據被更新和插入的時間字段（時間戳）不可信。除了業務系統可能並不更新這個字段外，還同樣存在人工運維引入非正常操作的問題。
3.批處理表的增量集成
即便如此，仍然有表，是可以容易實現增量識別的，而這種表往往還是大表。我們前面提到的“批處理”表就是這種表，因爲這類表是批量寫入的，操作頻次是有限且是批量的（常見的數據交換表也是這種表）。這種表的數據，較爲容易獲得增量。
方法：
- 找到主鍵。因爲增量數據需要與全量合併，所以主鍵非常重要。
- 瞭解數據寫入特徵。數據變動的範圍多大，哪個字段是每日生成新數據的業務日期字段，這關係到增量集成的增量時區範圍多大。例如，會更新當前月的數據，會更新最近N天的數據。
- 瞭解業務。爲什麼會產生這樣的數據，業務是什麼，數據該如何使用。
- 調研數據。從數據中驗證之前得到的信息，是否完全正確，這非常重要。最經常的問題就是數據變動的範圍，與描述不一致。這是因爲調研總是短暫的，而數據不會騙人。例如運行了一個歷史日期的數據，例如過了一個假期才處理問題。
- 事件表的增量集成
還有另外一種表，自然就可以做到增量識別。這類表就是事件型表，這類表只有insert，沒有update和delete。例如刷了一次門禁卡。
到這裏，我其實並沒有解決所有表的集成。我只解決了小表、部分大表（批量表、事件表），這就是現實。大部分時候，我們只能採取加大離線集成的並行度，並忍受數個小時離線集成時長。而離線集成很難解決的這些表的集成，往往也是最適合實時集成的表。這就是我給的答案，離線集成不完美，解決不了我們獲取數據的完整性的問題。
4 總結
全量和增量都是一種選擇，如果表都很小，我們整個庫都可以全量集成。而增量則更多的時候是一種奢望，系統運行的越久，離線增量集成的問題就會暴露的越多。在這個時候，我要說：選擇要大於努力，建議去看看實時集成是不是可以幫助到你。另外一個方面，我們回顧上一章節，實時集成集成小表並不划算，集成批量表會導致進程崩潰。
所以，沒有完美的工具，只有完美的方案。只有針對客戶現場的實際情況，做出最適合客戶的現場方案纔是我們的最終選擇。
本文爲阿里雲原創內容，未經允許不得轉載。