課程簡介

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

解決思路：

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

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

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

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

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

目標(biāo)收益

- 了解一個真實(shí)的MongoDB的應(yīng)用場景，及Change Stream 功能的高級用法
- 了解流處理引擎工作機(jī)制
- 學(xué)習(xí)一個技術(shù)型數(shù)據(jù)中臺落地方案

培訓(xùn)對象

課程內(nèi)容

案例方向

---

智能數(shù)據(jù)分析/企業(yè)級大數(shù)據(jù)架構(gòu)演進(jìn)/流式計(jì)算系統(tǒng)設(shè)計(jì)/數(shù)據(jù)庫的未來

案例背景

---

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

收益

---

- 了解一個真實(shí)的MongoDB的應(yīng)用場景
- 了解流處理引擎工作機(jī)制
- 學(xué)習(xí)一個輕量級數(shù)據(jù)中臺落地方案

解決思路

---

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

在流處理引擎的選擇上，我們選擇了Hazelcast Jet而不是主流的Flink，這個考量更多是從數(shù)據(jù)的時(shí)效，以及方案的部署成本及維護(hù)易用性上。

這里面碰到比較大的坑：
Oracle 日志采集的坑比較多，基本上是一路踩過來
MongoDB 邏輯視圖無法有效使用索引導(dǎo)致性能很低，最后使用固化視圖來解決

結(jié)果

---

使用這個技術(shù)組合，我們在一個客戶的實(shí)時(shí)數(shù)據(jù)中臺項(xiàng)目中取得了很大的成功。在有這個平臺之前，對一個前段業(yè)務(wù)的支撐，后臺團(tuán)隊(duì)需要4-8個星期來提供數(shù)據(jù)接口。在我們的實(shí)時(shí)數(shù)據(jù)平臺啟用后，這個時(shí)間可以縮短到2個星期。我希望能夠把這個工具產(chǎn)品化一下，讓更多的用戶可以來用我們的解決方案。