MongoDB + 流處理引擎: 快速構建一個實時數(shù)據(jù)中臺

案例背景:
大中型企業(yè)在最近30年的信息化過程中，構建了大量基于如Oracle，SQLServer等關系型數(shù)據(jù)庫業(yè)務系統(tǒng)。這些數(shù)據(jù)庫在處理更大量或者更高并發(fā)的時候已經凸顯了老一代技術的瓶頸，另外，關系模型的固定結構在更大程度上也是企業(yè)創(chuàng)新的一大阻力。一種比較主流的解決方案就是實時數(shù)倉，在不改變已有系統(tǒng)的前提下，將數(shù)據(jù)從已有的關系型數(shù)據(jù)庫實時同步到分布式數(shù)據(jù)倉庫，在一個新的數(shù)據(jù)平臺上為新的業(yè)務做數(shù)據(jù)支撐。

解決思路：

- 使用MongoDB，一個高性能分布式數(shù)據(jù)庫，而不是性能遲緩，架構臃腫的Hadoop大數(shù)據(jù)
- 使用實時的流處理引擎來進行從Oracle/MySQL到MongoDB的數(shù)據(jù)實時同步及處理
- 使用Tapdata的流程可視化工具來降低流處理的使用成本

這個過程中我們遇到的挑戰(zhàn)：
Oracle 數(shù)據(jù)庫日志實時采集的一系列坑
MongoDB的邏輯視圖無法有效使用索引

使用這個技術組合，我們在一個客戶的實時數(shù)據(jù)中臺項目中取得了很大的成功，比較如下：

建設前：
業(yè)務數(shù)據(jù)散落在數(shù)十套單獨的系統(tǒng)內，依賴大量的存儲過程和定制腳本進行數(shù)據(jù)打通
對一個前端業(yè)務的支撐，后臺團隊需要4-8個星期來提供一個數(shù)據(jù)接口
銷售看板需要通過大量的程序進行匯總來自9個不同系統(tǒng)的訂單數(shù)據(jù)，在第2天才能形成

建設后：
統(tǒng)一的實時數(shù)據(jù)平臺，接入了來自于10多套訂單系統(tǒng)的數(shù)據(jù)及商品庫存數(shù)據(jù)
簡單接口1天，相對復雜的接口1個星期
秒級更新的全局實時銷售看板