1 前言
“世上無難事，只要不集成。”
數據中臺開發階段的前期工作，最困難就是數據集成了。剛開始數據建模做的好壞，業務做的好壞，似乎都有情可原，但是數據集成不上來，一切業務遠景就如地基不牢的高樓隨時都可能傾覆。
從之前的項目經驗來看，數據加工的建模方法和SQL語言都是較爲標準化的，在項目中與阿里雲第一次合作的夥伴和客戶對於數據集成的學習和掌握都是較爲困難。尤其是之前沒有類似需要數據集成系統的企業，對數據集成工作的理解不是過於簡單，就是過於擔憂，又或者過於嚴苛。究其原因，還是對數據集成工作做什麼都不瞭解，進而有很多誤解。
2 DataWorks的數據集成
早年DataWorks是隻有離線集成，沒有實時集成的功能，因爲其定位主要是基於MaxCompute的離線開發平臺。但是這幾年在面向DataOps的發展上，定位已經是全能的大數據開發平臺，可以基於多種引擎做數據開發。例如holo這種實時數倉的產品。所以，實時數據集成也是箭在弦上，終於做了一些對應的功能，作爲一個資深用戶還是很驚喜。
但是目前從實際使用上來看，實時集成功能雖然彌補了功能上的缺陷，但是與離線集成的強大比起來，還是有所欠缺。
首先是驚喜的部分。實時數據集成的直接構建了一鍵同步的功能，把複雜的配置實時同步任務，歸檔到log表，然後從Log表又merge到全量表的所有邏輯都包含在內了，真的實現了一步獲得數據。從實際使用上來看，客戶和夥伴學習配置一個實時數據集成任務與學習配置一個離線任務的成比起來更低。大部分人一次就配置成功，獲得感很強。從資深用戶的角度看，這種強大的整合能力也讓實際運維的任務變得非常少，可以大大減輕開發人員的工作量，簡直是夢想的彼岸。之前在一個部委大型項目上，我們的數據集成表高達幾十萬，每天調度運行的任務都是以十萬計，無效運維壓力山大。
然後是欠缺的部分。從實際使用上來看，單個一鍵同步任務所承載的任務數量還是需要限制。整合雖然帶來了好處，屏蔽了細節，但是任務太多在一起局部異常會影響全局，影響範圍也會變大。再就是目前實時集成並沒有緩衝的機制，再遇到源端數據庫批量處理的時候，比較容易進程異常，需要針對性的調整內存參數後纔可以恢復，也影響了數據產出的時效。再就是目前實時集成在混合雲只支持oracle和mysql這兩種數據庫，支持的數據庫種類還是非常的少。
3 實時集成就可以解決全部問題
我敢相信，在設計之初，開發人員一定是想用實時集成替代離線集成，因爲相比離線集成實時集成更加完美。而且，我在之前的文章中也講過真實的集成場景，實時數據集成一定是主流，離線集成應該是輔助。
數據本身就是實時產生的，沒有哪個原始數據不是實時產生的，只有後續的數據處理過程纔可能離線。所以，本質上來說，原始的數據都是實時的，只有實時集成才能提供更高時效的數據用於數據分析。
以最常用的數據庫實時集成爲例。數據庫記錄了業務系統的操作型數據，業務系統本身就是實時在變化的。網頁日誌記錄了網頁訪問的信息，這個過程產生的數據也是實時的。音視頻數據流也是實時產生並且存儲傳輸的。
那麼離線數據是怎麼來的呢？離線數據只是實時在變化的數據在某個時點的一個切片。我們在做離線集成的時候，其實是向數據源端發起了一個某個時點數據的訪問請求。例如向某個數據庫提交了一個SQL，數據庫會返回提交這個時點數據表的一個時點切片。這只是這個數據庫表的某個時點狀態，過了這個時點再提交，數據表返回就可能不同。
實時集成就像接了一個石油管道，石油會源源不斷的從數據源流到數據中臺中去。但是這個管道投資是巨大的，如果管道中的油一直都是滿載的傳輸還可以，實際上的數據產生更像是變幻莫測的天氣，白天熱晚上冷，偶爾颳風下雨，偶爾氣候災害。所以，實時集成也有自己的缺陷。
相比之下離線集成佔用管道的時間是短暫的，但是都是滿載的，效率上會更高。
實時集成的主要缺陷就是投資大，缺乏靈活性。爲實時集成配置的資源不可以按照最小評估，必須按照最高的去評估。不管是傳統的OGG這種歷史長達幾十年的產品，還是DataWorks這種新秀，都是會經常遇到突發的數據洪流導致進程崩潰。很多DBA或者數據庫從業人士，一提到OGG就都頭大，運維複雜壓力大，穩定性也是差強人意。個人認爲這主要還是因爲成本效率的問題，經濟划算的去運行，就得接受部分情況下的異常。
那麼是什麼原因導致的異常呢？一般來說，很少是因爲業務系統本身的原因，因爲大部分交易型系統不是雙十一那種場景，數據庫系統一般都被用來做與人相關的處理，本身就是離散的。我遇到的100%的數據庫實時集成問題的原因無外乎兩種，一種是後臺運維批量更新，另外一種是後臺批量數據處理（存儲過程出個報表，做批量計算）。所以本質的原因是：數據庫沒有做交易型的業務，去做了批量型系統。在遇到這種場景，實時同步就會很崩潰，因爲大部分時候都是乖乖寶，但是突然就變身了綠巨人，一下子就可以把實時同步進程搞崩潰。而且，這種情況，因爲有人的參與，變得不可預測。
4 要爲你的系統做出選擇
談到這裏，你就知道應該怎麼做了。交易型可預測的部分做實時，因爲實時簡單可靠，運維起來容易。不可預測的批量運維，和批量數據處理應該走離線，因爲這兩種操作本身就是一種離線處理。
再就是經濟性，如果不考慮成本，那其實可以儘可能全搞成實時，我用超大的資源浪費來滿足各種不可預測的異常，來保障我的運轉。就像我們國家的春運，是不是要把系統設計成春運不堵車的模式，還是設計成平時不堵車的模式，還是看夠不夠豪。
而我們做一般的小項目還是要考量一下的，下面是總結：
| 方案 | 交易發生類型 | 集成成本 |
| 實時集成 | 實時 | 高 |
| 離線集成 | 離線/實時 | 低 |
集成原則：
1-費用緊張，資源有限，儘可能使用離線集成。
2-批處理數據（主要指源端數據是批量產生，或者雙十一式爆發式產生）集成，儘量走離線。如果確實預算非常充足，資源非常豐富，也可以走實時集成（很多時候，源端都可能扛不住）。
3-交易型數據集成，儘量走實時，如果資源有限可以走離線。
4-大表，例如數據超過200W、存儲超過1G，儘量走實時，這種表一般在業務系統中數量不會超過表數量的20%。離線集成時效性很難滿足要求，當然也不是不行。一般離線集成的表在1-10億這個級別也是可以一戰（與系統資源相關）。再大基本上就很難了，集成時間過久，業務系統沒有足夠的快照空間，事務會報錯，集成就會失敗。
5-小表，例如常年不動的代碼表，10W以下的小表，大概都能在30秒-3分鐘內完成，建議走離線。畢竟實時挺貴，這些小表，還是打包搞過來比較適合。
就到這裏了，我爲什麼寫這麼多集成的文章，真的很頭疼。我每年都要給新的夥伴和客戶教集成，每次還總能遇到新問題，把我搞的很狼狽。雖然集成看起來好像簡單，但是真正客戶化的把集成方案設計好，真的還是需要下一番功夫。
本文爲阿里雲原創內容，未經允許不得轉載。