其他功能特性

1.分布式MySQL執(zhí)行引擎

主要目標(biāo)是實現(xiàn)與單機數(shù)據(jù)庫SQL引擎的完全兼容，實現(xiàn)SQL的智能下推，能夠智能分析SQL，解析出那些SQL可以直接下發(fā)，那些SQL需要進行優(yōu)化改造，優(yōu)化成什么樣，以及路由到哪些實例節(jié)點上執(zhí)行，充分發(fā)揮數(shù)據(jù)庫實例的全部能力，減少網(wǎng)絡(luò)之間的數(shù)據(jù)傳輸量，最終對不同實例處理后的少量結(jié)果進行聚合計算返回給應(yīng)用調(diào)用方。這就是分布式SQL引擎的智能下推功能。
分布式引擎的職責(zé)包含SQL解析，優(yōu)化，執(zhí)行和合并四個流程。

支持市面上幾乎所有的語言（具有MySQL訪問能力的），兼容90%以上MySQL語法。

案例分析：
比如一個簡單的AVG操作，對于一些比較初級的分布式數(shù)據(jù)庫模型而言，常見做法是把AVG直接下發(fā)到所有存儲節(jié)點，這樣造成的結(jié)果就是語法兼容，語義不兼容，最終拿到的是錯誤結(jié)果。而DRDS的智能下推引擎，對SQL的語法做充分的語義兼容性適配，針對AVG操作，只能由引擎將邏輯AVG SQL解析優(yōu)化為SUM和COUNT的SQL然后進行下推，由底層的數(shù)據(jù)庫實例節(jié)點完成SUM和COUNT計算，充分利用底層節(jié)點的計算能力，在引擎層將各個存儲節(jié)點的SUM和COUNT結(jié)果聚合計算，最終計算出AVG。

2.在線平滑擴容

在線數(shù)據(jù)擴容的重點在于“在線”兩字，也就是用戶不需要停止業(yè)務(wù)進行割接操作，直接就可以添加新的RDS節(jié)點到集群中，實現(xiàn)無縫的自由擴展。RDRS則將整個擴容過程分為幾個階段，包括全量遷移，增量同步，切換數(shù)據(jù)庫等幾個步驟。數(shù)據(jù)會提前進行搬遷，并進行增量并行同步一段時間，因此，我們可以在非常短的時間內(nèi)（秒級別）完成數(shù)據(jù)庫的最終擴容切換工作，對業(yè)務(wù)沒有影響。

3.小表廣播

在一些大的業(yè)務(wù)表進行了切分后，總會存在一些表的數(shù)據(jù)量不大，更新量也不大的原始信息表。這些表往往會與我們的切分后大表進行join操作，這種操作物理上就會造成分布式j(luò)oin查詢，效率從整體上會比較地下。針對這種分布式j(luò)oin的場景，開發(fā)了OETL專用工具來進行小表廣播，將原信息表的所有數(shù)據(jù)（包括增量更新）全部自動的廣播到大表的機器上，這樣，就可以讓原來的分布式查詢變成單機本地查詢了。

4.全局唯一ID

DRDS sequence功能的目標(biāo)只是為了保證數(shù)據(jù)的全局唯一，雖然基本上是按時間序列獲取的，但并不全局有序。

5.異構(gòu)索引

解決分布式場景下數(shù)據(jù)拆分維度和數(shù)據(jù)查詢使用維度不一致導(dǎo)致的低效問題。

當(dāng)數(shù)據(jù)表被拆分為多個分庫分表時，數(shù)據(jù)在分庫分表的分布規(guī)則就固定了。但是通常數(shù)據(jù)的業(yè)務(wù)使用場景非常復(fù)雜，如果數(shù)據(jù)的查詢維度和數(shù)據(jù)拆分分布的規(guī)則一直，單條SQL會在一個分庫分表上執(zhí)行；如果數(shù)據(jù)的查詢使用維度和數(shù)據(jù)拆分分布的規(guī)格不一致，單條SQL可能在多個分庫分表上執(zhí)行，出現(xiàn)跨庫查詢，跨庫查詢會增加IO成本，查詢效率必然下降。

解決這個問題的思路還是分布式數(shù)據(jù)庫的一貫原則，讓SQL執(zhí)行在單庫上完成，實際采用的方式就是用“空間換效率”的方案，也就是將同一份數(shù)據(jù)表，冗余存儲多份，按照不同的業(yè)務(wù)使用場景進行拆分，保持拆分維度和使用維度統(tǒng)一，而多份數(shù)據(jù)之間會實時數(shù)據(jù)復(fù)制以解決數(shù)據(jù)一致性問題，這就是“異構(gòu)索引”方案。當(dāng)然異構(gòu)索引表不能無限制濫用，過多的異構(gòu)索引表會影響同步效率，對源數(shù)據(jù)表造成同步壓力。

其他同款中間件

Altas, Vitess, Heisenberg, CDS, DDB， OneProxy等等。

Atlas

Qihoo 360.
Web平臺部基礎(chǔ)架構(gòu)團隊開發(fā)維護的一個基于MySQL協(xié)議的數(shù)據(jù)中間層項目，它是在mysql-proxy 0.8.2版本上對其進行優(yōu)化，增加了一些新的功能特性。
Atlas是一個位于應(yīng)用程序與MySQL之間，它實現(xiàn)了MySQL的客戶端和服務(wù)端協(xié)議，作為服務(wù)端與應(yīng)用程序通訊，同時作為客戶端與MySQL通訊。它對應(yīng)用程序屏蔽了DB的細節(jié)。
Altas不能實現(xiàn)分布式分表，所有的字表必須在同一臺DB的同一個DataBase里且所有的字表必須實現(xiàn)建好，Altas沒有自動建表的功能。

Heisenberg

Baidu.
其優(yōu)點：分庫分表與應(yīng)用脫離，分庫表如同使用單庫表一樣，減少db連接數(shù)壓力，熱重啟配置，可水平擴容，遵守MySQL原生協(xié)議，讀寫分離，無語言限制，mysqlclient, c, java都可以使用Heisenberg服務(wù)器通過管理命令可以查看，如連接數(shù)，線程池，結(jié)點等，并可以調(diào)整采用velocity的分庫分表腳本進行自定義分庫表，相當(dāng)?shù)撵`活。
（開源版已停止維護）

CDS

JD. Completed Database Sharding.
CDS是一款基于客戶端開發(fā)的分庫分表中間件產(chǎn)品，實現(xiàn)了JDBC標(biāo)準(zhǔn)API，支持分庫分表，讀寫分離和數(shù)據(jù)運維等諸多共，提供高性能，高并發(fā)和高可靠的海量數(shù)據(jù)路由存取服務(wù)，業(yè)務(wù)系統(tǒng)可近乎零成本進行介入，目前支持MySQL, Oracle和SQL Server.
(架構(gòu)上和Cobar，MyCAT相似，直接采用jdbc對接，沒有實現(xiàn)類似MySQL協(xié)議，沒有NIO,AIO，SQL Parser模塊采用JSqlParser, Sql解析器有：druid>JSqlParser>fdbparser.)

DDB

豬場. Distributed DataBase.
DDB經(jīng)歷了三次服務(wù)模式的重大更迭：Driver模式->Proxy模式->云模式。

數(shù)據(jù)增量訂閱與消費

基于數(shù)據(jù)庫增量日志解析，提供增量數(shù)據(jù)訂閱&消費，目前主要支持了mysql.
有關(guān)數(shù)據(jù)增量訂閱與消費的中間件回顧一下：

Canal

Canal架構(gòu)圖：

說明：

instance模塊：

說明：一臺機器下部署一個canal，一個canal可以運行多個instance(通過配置destinations等), 一般情況下一個client連接一個instance（每個instance可以配置standby功能）, 可以多個client連接同一個instance，但是同一時刻只能有一個client消費instance的數(shù)據(jù)，這個通過zookeeper控制。

數(shù)據(jù)庫同步

Otter

背景：alibaba B2B因為業(yè)務(wù)的特性，賣家主要集中在國內(nèi)，買家主要集中在國外，所以衍生出了杭州和美國異地機房的需求，同時為了提升用戶體驗，整個機房的架構(gòu)為雙A，兩邊均可寫，由此誕生了otter這樣一個產(chǎn)品。

otter第一版本可追溯到04~05年，此次外部開源的版本為第4版，開發(fā)時間從2011年7月份一直持續(xù)到現(xiàn)在，目前阿里巴巴B2B內(nèi)部的本地/異地機房的同步需求基本全上了otter4。

基于數(shù)據(jù)庫增量日志解析，準(zhǔn)實時同步到本地機房或異地機房的mysql/oracle數(shù)據(jù)庫，一個分布式數(shù)據(jù)庫同步系統(tǒng)。

工作原理

原理描述：

Otter的作用

單機房復(fù)制示意圖

說明：
- 數(shù)據(jù)On-Fly, 盡可能不落地，更快的進行數(shù)據(jù)同步。（開啟node load balance算法, 如果Node節(jié)點S+ETL落在不同的Node上，數(shù)據(jù)會有個網(wǎng)絡(luò)傳輸過程）
- node節(jié)點可以有failover/loadBalancer.

SETL

S: Select
為解決數(shù)據(jù)來源的差異性，比如接入canal獲取增量數(shù)據(jù)，也可以接入其他系統(tǒng)獲取其他數(shù)據(jù)等。

E: Extract

T: Transform

L: Load

類似于數(shù)據(jù)倉庫的ETL模型，具體可為數(shù)據(jù)join，數(shù)據(jù)轉(zhuǎn)化，數(shù)據(jù)加載。

跨機房復(fù)制示意圖

數(shù)據(jù)涉及網(wǎng)絡(luò)傳輸，S/E/T/L幾個階段會分散在2個或者更多Node節(jié)點上，多個Node之間通過zookeeper進行協(xié)同工作（一般是Select和Extract在一個機房的Node, Transform/Load落在另一個機房的Node）
node節(jié)點可以有failover/loadBalancer。(每個機房的Node節(jié)點，都可以是集群，一臺或者多臺機器)

More:

異地雙活數(shù)據(jù)架構(gòu)基礎(chǔ)設(shè)施DRC

所謂DRC，就是Data Replication Center的縮寫，數(shù)據(jù)復(fù)制中心。這種復(fù)制是同步的，支持異構(gòu)的，高可用的（有嚴(yán)格容災(zāi)系統(tǒng)，實時性好），支持訂閱分發(fā)的。項目期初是為了淘寶異地容災(zāi)而成立的，用于數(shù)據(jù)庫之間主備同步，后來采用這套技術(shù)方案衍生出了DRC-TAIR, DRC-DUMP等項目。

所謂異地雙活主要關(guān)注兩件事，一個數(shù)據(jù)同步，一個數(shù)據(jù)分發(fā)。

到底怎樣的應(yīng)用會需要異地的雙活？比較常見的場景有三個：

DRC支持讀取集團MySQL, RDS, OceanBase, HBase, Oracle等多種不同的數(shù)據(jù)源的實時增量數(shù)據(jù)，支持寫入數(shù)據(jù)庫、MetaQ, ODPS等多種存儲媒介.

以前在一個城市做雙機房主備，兩個機房是數(shù)據(jù)對等的，寫入是隨機分布，然后通過主備HA進行數(shù)據(jù)同步。這樣機房對等的思路會導(dǎo)致業(yè)務(wù)增長、數(shù)據(jù)增長只能通過兩個機房不停堆機器來解決。另一方面，如果整個城市斷電，那么雙活就成了雙死。下一個思路是做跨城市，早期常用的做法是一個城市寫，另一個城市冷備，就是晚上做同步，但這就意味著白天如果發(fā)生了什么事兒，這一天的數(shù)據(jù)就比較危險。另一個思路是兩個城市多寫，數(shù)據(jù)落兩邊，這樣的問題是應(yīng)用調(diào)用次數(shù)頻繁的話，如果調(diào)用異地數(shù)據(jù)多來那么一兩次，整個應(yīng)用的延時就很長。這個思路再進一步發(fā)展，就是做單元內(nèi)封閉以減少異地調(diào)用，這就涉及到業(yè)務(wù)上的改造。

順著這個思路，阿里的異地雙活重點做了幾件事。一個是熱插拔，可以做到在業(yè)務(wù)高峰時增加節(jié)點，高峰過了把增加的節(jié)點關(guān)閉。做到這個的一個關(guān)鍵是流量實時切換 ，DRC可以在20秒以內(nèi)把一個單元（region）的流量遷移到另一個單元。另一個是數(shù)據(jù)實時恢復(fù)，就是通過一定的冗余設(shè)計，一旦一個單元掛掉了，可以在另一個單元做全量恢復(fù)。

異地多活在數(shù)據(jù)方面的挑戰(zhàn)是非常大的。雙十一期間，交易會激增，所以交易鏈路做了單元化。交易鏈路的數(shù)據(jù)分為三個維度：買家、賣家、商品。買家之間通常沒有太多交叉，天然的適應(yīng)這種隔離，而且賣家對延遲的敏感度非常高，所以按照賣家維度切分，在單元內(nèi)封閉，而賣家和商品都是在中心寫入。

數(shù)據(jù)方面的兩個核心要求：

雙單元的同步架構(gòu)有兩種：
一種是讀寫分離的方式，中心寫，單元讀。單元需要的數(shù)據(jù)如果沒有從中心及時同步過來，或者同步錯了，那有問題這段時間的交易會全部收到影響。這里的核心是，保證秒級延遲，同時保證一致性。（JD的多中心交易系統(tǒng)就采用了這種方式）

第二種同步架構(gòu)是單元封閉的方式。中心和單元各有寫入，我們通過冗余是的中心和單元隨時可以各自接管。（類似Otter）

這里的關(guān)鍵是：

Otter與DRC的區(qū)別：
- Otter是阿里B2B的產(chǎn)品，DRC是阿里技術(shù)保障團隊的產(chǎn)品
- Otter是針對MySQL的，DRC可以支持多種類型的數(shù)據(jù)源
- DRC從業(yè)務(wù)上進行了劃分，可以實現(xiàn)單元內(nèi)封閉，Otter的實現(xiàn)不涉及業(yè)務(wù)，而是在純數(shù)據(jù)庫層打通的技術(shù)
- Otter是雙寫，DRC是中心寫、分中心讀，或者都部分寫，相互同步。
- Otter所處的網(wǎng)絡(luò)環(huán)境較DRC差，解決一致性問題也較復(fù)雜（基于trusted source的單向環(huán)回的補救，基于時間交集的補救），DRC有兩種實現(xiàn)方式，具體參考上面。

異地多活中DRC的核心能力就是在低延遲，一致性和高可用。

JD多中心交易系統(tǒng)

JD. 多中心交易系統(tǒng)。

JD數(shù)據(jù)復(fù)制中間件考察和借鑒了開源社區(qū)的實現(xiàn)，例如Databus、Canal/Otter、OpenReplicator等，解析部分使用了Canal的DBSync。

多中心交易本質(zhì)上是一個更大的分布式系統(tǒng)，交易流程中依賴和產(chǎn)生的數(shù)據(jù)和服務(wù)有不同的特點，必然涉及到數(shù)據(jù)分區(qū)、路由、復(fù)制、讀寫一致性、延遲等分布式領(lǐng)域的常見問題。

其中，數(shù)據(jù)一致性是電商網(wǎng)站需要面臨的首要問題，越是流量增大的時候越要保證數(shù)據(jù)更新的即時性和準(zhǔn)確性。在多中心之間需要同步賣家數(shù)據(jù)和商品數(shù)據(jù)，如果同步的延時太長，買家、賣家都不可接受。比如，賣家改了價格或庫存，用戶不能過很久才看到。同樣，數(shù)據(jù)正確性也是很大的挑戰(zhàn)，賣掉的商品能夠及時減少，退貨的商品能夠及時增加。這都時刻考驗著后端系統(tǒng)和數(shù)據(jù)庫平臺的健壯性。

除了數(shù)據(jù)一致性之外，如何保證路由規(guī)則的一致性也是關(guān)鍵性的問題。從技術(shù)角度來說，要保障單一用戶從登錄到訪問服務(wù)、到訪問數(shù)據(jù)庫，全鏈路的路由規(guī)則都是完全一致的。如果路由錯誤，看到的數(shù)據(jù)不正確，也會影響到最終用戶的體驗。

架構(gòu)

系統(tǒng)包括一個主中心和多個分中心，主中心與分中心之間通過數(shù)據(jù)總線交換數(shù)據(jù)。數(shù)據(jù)流向中，主數(shù)據(jù)(商品數(shù)據(jù)、商家數(shù)據(jù)、用戶數(shù)據(jù)等)的流向從主中心通過數(shù)據(jù)總線實時同步到分中心，分中心只讀；而交易數(shù)據(jù)(訂單數(shù)據(jù))的流向從分中心實時同步到主中心；在故障時，會從分中心轉(zhuǎn)移到主中心。

在這個系統(tǒng)中，有多處體現(xiàn)分流的概念。首先，買家訪問京東網(wǎng)站下單時，會被優(yōu)先分流到附近的交易中心；其次，根據(jù)交易系統(tǒng)的特點，接單前（包括購物車、結(jié)算頁等），多中心交易按用戶維度分流，如下圖所示。用戶登錄時，查詢用戶與區(qū)域的映射關(guān)系表（類似你是哪個片區(qū)的），標(biāo)識此用戶屬于哪個分中心，并保存標(biāo)識到cookie中，然后將用戶路由到指定的分中心。用戶訪問其他系統(tǒng)，如購物車和結(jié)算頁時，從cookie中讀取標(biāo)識，重定向到相應(yīng)分中心頁面。

通過分流，將用戶分配到相應(yīng)的分中心，一方面響應(yīng)速度快，用戶體驗更好，不用跨地域訪問數(shù)據(jù)中心了；另一方面，每個中心服務(wù)一定數(shù)量的用戶，水平擴展性好，也能支撐更大的交易規(guī)模了。當(dāng)然，多數(shù)據(jù)中心不能盲目干活，還考慮到容災(zāi)備份的問題。（支付寶光纖事件）

交易系統(tǒng)包括應(yīng)用和數(shù)據(jù)部分，應(yīng)用部分是無狀態(tài)的，就是說，這些工作是無差別的，一臺服務(wù)器出問題，我換一臺服務(wù)器來處理就是了，較容易實現(xiàn)多機房多活。但是數(shù)據(jù)不一樣，多中心交易本質(zhì)上是一個更大的分布式系統(tǒng)，必然涉及到數(shù)據(jù)分區(qū)、路由、復(fù)制、讀寫一致性、延遲等分布式領(lǐng)域的常見問題。

另外，交易流程中依賴和產(chǎn)生的數(shù)據(jù)和服務(wù)有不同的特點。比如商品、促銷和價格、庫存的讀服務(wù)，我們可以將之稱為基礎(chǔ)主數(shù)據(jù)，它們在用戶下單流程中是無法分區(qū)的，否則無法實現(xiàn)單機房內(nèi)流量閉環(huán)，也就是說，不能因為分區(qū)數(shù)據(jù)的不一致，導(dǎo)致同一用戶在單一流程中看到不同的數(shù)據(jù)（假如你加入購物車時是促銷20塊，結(jié)賬是25塊，你會不會表情扭曲？）而商品、促銷和價格的寫服務(wù),是給采銷、第三方POP商家應(yīng)用調(diào)用的，這種業(yè)務(wù)場景的可用性目標(biāo)，主機房部署和冷備模式即可滿足，而且業(yè)務(wù)人員的操作流程會抵消寫復(fù)制延遲。

簡單來說，數(shù)據(jù)的問題表現(xiàn)在以下幾個方面：一、 如何保證數(shù)據(jù)的即時性和準(zhǔn)確性，多中心之間需要同步賣家數(shù)據(jù)和商品數(shù)據(jù)，如果同步的延時太長,買家、賣家都不可接受，由于是異地部署，最好延時能控制在1秒內(nèi)。比如，賣家改了價格或庫存，用戶不能過很久才看到。同樣，數(shù)據(jù)正確性也是很大的挑戰(zhàn),因為數(shù)據(jù)故障跟應(yīng)用層故障不一樣，應(yīng)用出故障了，可能只影響用戶訪問；數(shù)據(jù)寫錯了無法恢復(fù)。2、如何保證路由規(guī)則的一致性，要保障這個用戶從進來到訪問服務(wù)，到訪問數(shù)據(jù)庫，全鏈路的路由規(guī)則都是完全一致的；如果路由錯誤，看到的數(shù)據(jù)不正確。

從同城雙機房的分布轉(zhuǎn)變?yōu)楫惖囟鄼C房的分布，給數(shù)據(jù)同步帶來了新的挑戰(zhàn)，因此如何設(shè)計數(shù)據(jù)總線也是項目能否實現(xiàn)的關(guān)鍵因素。京東的多中心交易系統(tǒng)通過數(shù)據(jù)總線JingoBus進行快速數(shù)據(jù)交換，同步性能是mysql的3倍以上，而且可用性高，架構(gòu)靈活。其中，全新的總線設(shè)計解決了多中心交易跨機房的數(shù)據(jù)庫復(fù)制和多數(shù)據(jù)源間的數(shù)據(jù)異構(gòu)同步等難題，實現(xiàn)了高性能、低延時、健壯的數(shù)據(jù)同步機制。

如圖所示，數(shù)據(jù)總線主要分Relay、Snapshot和Replicator三部分構(gòu)成，其中Relay從來源數(shù)據(jù)庫抽取事務(wù)日志，并對Replicator提供日志訂閱服務(wù)，角色上相當(dāng)于Mysql Slave IO Thread。Snapshot從Relay訂閱所有事務(wù)日志，寫入持久存儲作為快照，同時向Replicator提供批量日志訂閱服務(wù)，角色上相當(dāng)于Mysql Slave Relay Log。Replicator：事務(wù)日志的消費端，從Relay或Snapshot拉取事務(wù)日志將事務(wù)日志按配置的一致性應(yīng)用到目標(biāo)數(shù)據(jù)庫，角色上相當(dāng)于Mysql Slave SQL Thread。(參考下面MySQL主備復(fù)制原理圖)

正常情況下，Replicator直接連接Relay，消費Relay內(nèi)存隊列中的事務(wù)日志。但有些情況下，因為網(wǎng)絡(luò)抖動、目標(biāo)庫的負(fù)載過高等因素，可能導(dǎo)致Replicator相對Relay落后很多。另外，當(dāng)新的消費端加入同一數(shù)據(jù)源的訂閱者時，新消費端有冷啟動的問題。為了避免重新從數(shù)據(jù)源做全量快照，Snapshot作為Relay的一個特殊消費端，通過一種高吞吐的消費方式，從Relay源源不斷的消費在線事務(wù)日志，通過對事務(wù)日志的有效處理，最終保存了數(shù)據(jù)源的一份一致快照(Consistent Snapshot)，即包括了數(shù)據(jù)源庫表中每一行的最新狀態(tài)的快照，同時保留了一段比Relay buffer更舊的事務(wù)日志(Log Store)。由此看來，數(shù)據(jù)總線作為一個數(shù)據(jù)層的通用CDC組件，對于多中心交易項目以及異步復(fù)制場景提供了整體解決方案，奠定了項目的核心內(nèi)容。

跨數(shù)據(jù)庫（數(shù)據(jù)源）遷移

yugong

去Oracle數(shù)據(jù)遷移同步工具。定位：數(shù)據(jù)庫遷移（目前主要支持Oracle->mysql/DRDS）

08年左右，阿里巴巴開始嘗試MySQL的相關(guān)研究，并開發(fā)了基于MySQL分庫分表技術(shù)的相關(guān)產(chǎn)品，Cobar/TDDL(目前為阿里云DRDS產(chǎn)品)，解決了單機Oracle無法滿足的擴展性問題，當(dāng)時也掀起一股去IOE項目的浪潮，愚公這項目因此而誕生，其要解決的目標(biāo)就是幫助用戶完成從Oracle數(shù)據(jù)遷移到MySQL上，完成去IOE的第一步.

概述

整個數(shù)據(jù)遷移過程，分為兩個部分：

過程描述：

Oracle全量基于JDBC拉取數(shù)據(jù)，增量基于物化視圖來實現(xiàn)。

架構(gòu)

說明：

自定義數(shù)據(jù)轉(zhuǎn)換

如果要遷移的Oracle和mysql的表結(jié)構(gòu)不同，比如表名，字段名有差異，字段類型不兼容，需要使用自定義數(shù)據(jù)轉(zhuǎn)換。如果完全相同則可以跳過。

整個數(shù)據(jù)流為：DB->Extractor->DataTranslator->Applier->DB, 本程序預(yù)留DataTranslator接口（僅支持Java），允許外部用戶自定義數(shù)據(jù)處理邏輯。比如：

運行模式介紹

1.MARK模式（MARK）

開啟增量日志模式，如果是Oracle就是創(chuàng)建物化視圖（materialized view）。

2.CLEAR模式（CLEAR）

清理增量日志的幾率，如果是Oracle就是刪除物化視圖

3.全量模式（FULL)

全量模式，顧名思議即為對源表進行一次全量操作，遍歷源表所有的數(shù)據(jù)后，插入目標(biāo)表.

全量有兩種處理方式：

4.增量模式（INC）

全量模式，顧名思議即為對源表增量變化的數(shù)據(jù)插入目標(biāo)表，增量模式依賴記錄日志功能.

目前增量模式的記錄日志功能，是通過oracle的物化視圖功能。

5.自動模式(ALL)

自動模式，是對全量+增量模式的一種組合，自動化運行，減少操作成本.

自動模式的內(nèi)部實現(xiàn)步驟：

6.對比模式(CHECK)

對比模式，即為對源庫和目標(biāo)庫的數(shù)據(jù)進行一次全量對比，驗證一下遷移結(jié)果. 對比模式為一種可選運行，做完全量/增量/自動模式后，可選擇性的運行對比模式，來確保本次遷移的正確性.

DataX

DataX是一個在異構(gòu)的數(shù)據(jù)庫/文件系統(tǒng)之間高速交換數(shù)據(jù)的工具，實現(xiàn)了在任意的數(shù)據(jù)處理系統(tǒng)(RDBMS/Hdfs/Local filesystem）之間的數(shù)據(jù)交換。

目前成熟的數(shù)據(jù)導(dǎo)入導(dǎo)出工具比較多，但是一般都只能用于數(shù)據(jù)導(dǎo)入或者導(dǎo)出，并且只能支持一個或者幾個特定類型的數(shù)據(jù)庫。

這樣帶來的一個問題是，如果我們擁有很多不同類型的數(shù)據(jù)庫/文件系統(tǒng)(Mysql/Oracle/Rac/Hive/Other…)，并且經(jīng)常需要在它們之間導(dǎo)入導(dǎo)出數(shù)據(jù)，那么我們可能需要開發(fā)/維護/學(xué)習(xí)使用一批這樣的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader/mysqldumper…)。而且以后每增加一種庫類型，我們需要的工具數(shù)目將線性增長。(當(dāng)我們需要將mysql的數(shù)據(jù)導(dǎo)入oracle的時候，有沒有過想從jdbcdump和dbloader上各掰下來一半拼在一起到?jīng)_動？)這些工具有些使用文件中轉(zhuǎn)數(shù)據(jù)，有些使用管道，不同程度的為數(shù)據(jù)中轉(zhuǎn)帶來額外開銷，效率差別很非常大。很多工具也無法滿足ETL任務(wù)中常見的需求，比如日期格式轉(zhuǎn)化，特性字符的轉(zhuǎn)化，編碼轉(zhuǎn)換。另外，有些時候，我們希望在一個很短的時間窗口內(nèi)，將一份數(shù)據(jù)從一個數(shù)據(jù)庫同時導(dǎo)出到多個不同類型的數(shù)據(jù)庫。DataX正是為了解決這些問題而生。

設(shè)計理念

為了解決異構(gòu)數(shù)據(jù)源同步問題，DataX將復(fù)雜的網(wǎng)狀的同步鏈路變成了星型數(shù)據(jù)鏈路，DataX作為中間傳輸載體負(fù)責(zé)連接各種數(shù)據(jù)源。當(dāng)需要接入一個新的數(shù)據(jù)源的時候，只需要將此數(shù)據(jù)源對接到DataX，便能跟已有的數(shù)據(jù)源做到無縫數(shù)據(jù)同步。

DataX在阿里巴巴集團內(nèi)被廣泛使用，承擔(dān)了所有大數(shù)據(jù)的離線同步業(yè)務(wù)，并已持續(xù)穩(wěn)定運行了6年之久。目前每天完成同步8w多道作業(yè)，每日傳輸數(shù)據(jù)量超過300TB。

框架設(shè)計

DataX本身作為離線數(shù)據(jù)同步框架，采用Framework+plugin架構(gòu)構(gòu)建。將數(shù)據(jù)源讀取和寫入抽象稱為Reader/Writer插件，納入到整個同步框架中。

DataX框架內(nèi)部通過雙緩沖隊列、線程池封裝等技術(shù)，集中處理了高速數(shù)據(jù)交換遇到的問題，提供簡單的接口與插件交互，插件分為Reader和Writer兩類，基于框架提供的插件接口，可以十分便捷的開發(fā)出需要的插件。比如想要從oracle導(dǎo)出數(shù)據(jù)到mysql，那么需要做的就是開發(fā)出OracleReader和MysqlWriter插件，裝配到框架上即可。并且這樣的插件一般情況下在其他數(shù)據(jù)交換場合是可以通用的。

核心架構(gòu)

DataX3.0 開源版本支持單機多線程模式完成同步作業(yè)運行，這里按一個DataX作業(yè)生命周期的時序圖，從整體架構(gòu)設(shè)計非常簡要說明DataX各個模塊相互關(guān)系。

核心模塊介紹：

DataX調(diào)度流程：

舉例來說，用戶提交了一個DataX作業(yè)，并且配置了20個并發(fā)，目的是將一個100張分表的mysql數(shù)據(jù)同步到odps里面。 DataX的調(diào)度決策思路是：
1. DataXJob根據(jù)分庫分表切分成了100個Task。
2. 根據(jù)20個并發(fā)，DataX計算共需要分配4個TaskGroup。
3. 4個TaskGroup平分切分好的100個Task，每一個TaskGroup負(fù)責(zé)以5個并發(fā)共計運行25個Task。