3.1 數(shù)據(jù)同步基礎(chǔ)

?? 源業(yè)務(wù)系統(tǒng)的數(shù)據(jù)類型多種多樣，有來(lái)源于關(guān)系型數(shù)據(jù)庫(kù)的結(jié)構(gòu)化數(shù)據(jù)，如 MySQL Orac le DB2, SQL Server ：也有來(lái)源于非關(guān)系型數(shù)據(jù)庫(kù)的非結(jié)構(gòu)化數(shù)據(jù)，如 Ocean Base HBase Mongo DB 等，這類數(shù)據(jù)通常存儲(chǔ)在數(shù)據(jù)庫(kù)表中：還有來(lái)源于文件系統(tǒng)的結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)，如阿里云對(duì)象存儲(chǔ) oss 、文件存儲(chǔ) NAS 等，這類數(shù)據(jù)通常以文件形式進(jìn)行存儲(chǔ)。數(shù)據(jù)同步需要針對(duì)不同的數(shù)據(jù)類型及業(yè)務(wù)場(chǎng)景選擇不同的同步方式?？偟膩?lái)說(shuō)，同步方式可以分為三種 直連同步 、數(shù)據(jù)文件同步和數(shù)據(jù)庫(kù)日志解析同步。

3.1.1 直連同步

?? 直連同步是指通過(guò)定義好的規(guī)范接口 API 和基于動(dòng)態(tài)鏈接庫(kù)的方式直接連接業(yè)務(wù)庫(kù)，如 BC/JD BC 等規(guī)定了統(tǒng)一規(guī)范的標(biāo)準(zhǔn)接口，不同的數(shù)據(jù)庫(kù)基于這套標(biāo)準(zhǔn)接口提供規(guī)范的驅(qū)動(dòng)，支持完全相同的函數(shù)調(diào)用和 SQL 實(shí)現(xiàn)（見(jiàn)圖 .1 ）。

??這種方式配置簡(jiǎn)單，實(shí)現(xiàn)容易，比較適合操作型業(yè)務(wù)系統(tǒng)的數(shù)據(jù)同步。但是業(yè)務(wù)庫(kù)直連的方式對(duì)源系統(tǒng)的性能影響較大，當(dāng)執(zhí)行大批量數(shù)據(jù)同步時(shí)會(huì)降低甚至拖垮業(yè)務(wù)系統(tǒng)的性能。如果業(yè)務(wù)庫(kù)采取主備策略，則可以從備庫(kù)抽取數(shù)據(jù)，避免對(duì)業(yè)務(wù)系統(tǒng)產(chǎn)生性能影響。但是當(dāng)數(shù)據(jù)量
較大時(shí)，采取此種抽取方式性能較差，不太適合從業(yè)務(wù)系統(tǒng)到數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)的同步。

3.1.2 數(shù)據(jù)文件同步

??數(shù)據(jù)文件同步通過(guò)約定好的文件編碼、大小、格式等，直接從源系統(tǒng)生成數(shù)據(jù)的文本文件，由專門的文件服務(wù)器，如 FTP 服務(wù)器傳輸?shù)侥繕?biāo)系統(tǒng)后，加載到目標(biāo)數(shù)據(jù)庫(kù)系統(tǒng)中。當(dāng)數(shù)據(jù)源包含多個(gè)異構(gòu)的數(shù)據(jù)庫(kù)系統(tǒng)（如 MyS QL Oracle QL Server DB2 等）時(shí)，用這種方式比較簡(jiǎn)單、實(shí)用。另外，互聯(lián)網(wǎng)的日志類數(shù)據(jù)，通常是以文本文件形式存在的，也適合使用數(shù)據(jù)文件同步方式（見(jiàn)圖 3.2）

??由于通過(guò)文件服務(wù)器上傳、下載可能會(huì)造成丟包或錯(cuò)誤，為了確保數(shù)據(jù)文件同步的完整性，通常除了上傳數(shù)據(jù)文件本身以外，還會(huì)上傳一個(gè)校驗(yàn)文件，該校驗(yàn)文件記錄了數(shù)據(jù)文件的數(shù)據(jù)量以及文件大小等校驗(yàn)信息，以供下游目標(biāo)系統(tǒng)驗(yàn)證數(shù)據(jù)同步的準(zhǔn)確性。

??另外，在從源系統(tǒng)生成數(shù)據(jù)文件的過(guò)程中，可以增加壓縮和加密功能，傳輸?shù)侥繕?biāo)系統(tǒng)以后，再對(duì)數(shù)據(jù)進(jìn)行解壓縮和解密 這樣可以大大提高文件的傳輸效率和安全性。

3.1.3 數(shù)據(jù)庫(kù)日志解析同步

??目前，大多數(shù)主流數(shù)據(jù)庫(kù)都已經(jīng)實(shí)現(xiàn)了使用日志文件進(jìn)行系統(tǒng)恢復(fù)，因?yàn)槿?文件信息足夠豐富，而且數(shù)據(jù)格式也很穩(wěn)定，完全可以通過(guò)解析日志文件獲取發(fā)生變更的數(shù)據(jù)，從而滿足增量數(shù)據(jù)同步的需求。

??以O(shè)racle 為例，可以通過(guò)源系統(tǒng)的進(jìn)程，讀取歸檔日志文件用以收集變化的數(shù)據(jù)信息，并判斷日志中的變更是否屬于被收集對(duì)象，將其解析到目標(biāo)數(shù)據(jù)文件中。這種讀操作是在操作系統(tǒng)層面完成的，不需要通過(guò)數(shù)據(jù)庫(kù)，因此不會(huì)給源系統(tǒng)帶來(lái)性能影響。

??然后可通過(guò)網(wǎng)絡(luò)協(xié)議，實(shí)現(xiàn)源系統(tǒng)和目標(biāo)系統(tǒng)之間的數(shù)據(jù)文件傳輸。相關(guān)進(jìn)程可以確保數(shù)據(jù)文件的正確接收和網(wǎng)絡(luò)數(shù)據(jù)包的正確順序，并提供網(wǎng)絡(luò)傳輸冗余，以確保數(shù)據(jù)文件的完整性。

??數(shù)據(jù)文件被傳輸?shù)侥繕?biāo)系統(tǒng)后，可通過(guò)數(shù)據(jù)加載模塊完成數(shù)據(jù)的導(dǎo)人，從而實(shí)現(xiàn)數(shù)據(jù)從源系統(tǒng)到目標(biāo)系統(tǒng)的同步（見(jiàn)圖 3.3 ）。

??數(shù)據(jù)庫(kù)日志解析同步方式實(shí)現(xiàn)了實(shí)時(shí)與準(zhǔn)實(shí)時(shí)同步的能力，延遲可以控制在毫秒級(jí)別，并且對(duì)業(yè)務(wù)系統(tǒng)的性能影響也比較小，目前廣泛應(yīng)用于從業(yè)務(wù)系統(tǒng)到數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)的增量數(shù)據(jù)同步應(yīng)用之中。

??由于數(shù)據(jù)庫(kù)日志抽取 般是獲取所有的數(shù)據(jù)記錄的變更（增、刪、改），落地到目標(biāo)表時(shí)我們需要根據(jù)主鍵去重按照日志時(shí)間倒排序獲取最后狀態(tài)的變化情況。對(duì)于刪除數(shù)據(jù)這種變更情況，針對(duì)不同的業(yè)務(wù)場(chǎng)景可以采用一些不同的落地手法。

??我們以具體的實(shí)例進(jìn)行說(shuō)明。如表 3.1 所示為源業(yè)務(wù)系統(tǒng)中某表變更日志流水表。其含義是：存在 條變更日志，其中主鍵為 的記錄有3條變更日志，主鍵為 的記錄有 條變更日志。

??針對(duì)刪除數(shù)據(jù)這種變更，主要有三種方式，下面以實(shí)例 行說(shuō)明。假設(shè)根據(jù)主鍵去重，按照流水倒序獲取記錄最后狀態(tài)生成的表為 delta表。

??第一種方式，不過(guò)濾刪除流水。不管是否是刪除操作， 都獲取同一主鍵最后變更的那條流水。采用此種方式生成的delta表如表3.2所示。

??第二種方式，過(guò)濾最后一條刪除流水，如果同一主鍵最后變更的那條流水是刪除操作，就獲取倒數(shù)第二條流水。采用此種方式生成 delta表如表3.3所示。

??第三種方式，過(guò)濾刪除流水和之前的流水。如果在同一主鍵變更的過(guò)程中有刪除操作，則根據(jù)操作時(shí)間將該刪除操作對(duì)應(yīng)的流水和之前的
流水都過(guò)濾掉。采用 此種方式生成的 delta 表如表 3.4 所示。

??對(duì)于采用哪種方式處理刪除數(shù)據(jù)，要看前端是如何刪除無(wú)效數(shù)據(jù)的。前端業(yè)務(wù)系統(tǒng)刪除數(shù)據(jù)的方式一般有兩種 ：正常業(yè)務(wù)數(shù)據(jù)刪除和手工批量刪除。手工批量刪除通常針對(duì)類似的場(chǎng)景，業(yè)務(wù)系統(tǒng)只做邏輯刪除，不做物理刪除， OBA 定期將部分歷史數(shù)據(jù)直接刪除或者備份到備份庫(kù)。

??一般情況下，可以采用不過(guò)濾的方式來(lái)處理，下游通過(guò)是否刪除記錄的標(biāo)識(shí)來(lái)判斷記錄是否有效。如果明確業(yè)務(wù)數(shù)據(jù)不存在業(yè)務(wù)上的刪除，但是存在批量手工刪除或備份數(shù)據(jù)刪除，例如淘寶商品、會(huì)員等，則可以采用只過(guò)濾最后一條刪除流水的方式，通過(guò)狀態(tài)字段來(lái)標(biāo)識(shí)刪除
記錄是否有效。

??通過(guò)數(shù)據(jù)庫(kù)日志解析進(jìn)行同步的方式性能好、效率高，對(duì)業(yè)務(wù)系統(tǒng)的影響較小。但是它也存在如下一些問(wèn)題：
·

• 數(shù)據(jù)延遲。例如，業(yè)務(wù)系統(tǒng)做批量補(bǔ)錄可能會(huì)使數(shù)據(jù)更新量超出系統(tǒng)處理峰值，導(dǎo)致數(shù)據(jù)延遲。
• 投人較大。采用數(shù)據(jù)庫(kù)日 抽取的方式投入較大，需要在源數(shù)據(jù)庫(kù)與目標(biāo)數(shù)據(jù)庫(kù)之間部署 個(gè)系統(tǒng)實(shí)時(shí)抽取數(shù)據(jù)。
• 數(shù)據(jù)漂移和遺漏。數(shù)據(jù)漂移， 般是對(duì)增量表而言的，通常是指該表的同一個(gè)業(yè)務(wù)日期數(shù)據(jù)中包含前一天或后一天凌晨 附近的數(shù)據(jù)或者丟失當(dāng)天的變更數(shù)據(jù)。這個(gè)問(wèn)題我們將在“數(shù)據(jù)漂移的處理”一節(jié)中詳細(xì)論述。

3.2 阿里數(shù)據(jù)倉(cāng)庫(kù)的同步方式

??數(shù)據(jù)倉(cāng)庫(kù)的特性之一是集成，將不同的數(shù)據(jù)來(lái)源、不同形式的數(shù)據(jù)整合在一起，所以從不同業(yè)務(wù)系統(tǒng)將各類數(shù)據(jù)源同步到數(shù)據(jù)倉(cāng)庫(kù)是一切的開(kāi)始。那么阿里數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)同步有什么特別之處呢？

??阿里數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)同步的特點(diǎn)之一是數(shù)據(jù)來(lái)源的多樣性。在傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)中，一般數(shù)據(jù)來(lái)源于各種類型的關(guān)系型數(shù)據(jù)庫(kù)系統(tǒng)，比如MySQL SQL Server Oracle DB2 等，這類數(shù)據(jù)的共同特點(diǎn)便是高度結(jié)構(gòu)化，易于被計(jì)算機(jī)系統(tǒng)處理。而在大數(shù)據(jù)時(shí)代 ，除了結(jié)構(gòu)化數(shù)據(jù)，還有大量非結(jié)構(gòu)化數(shù)據(jù)，比如 Web 服務(wù)器產(chǎn)生的日志、各類圖片、視頻等。特別是日志數(shù)據(jù)，記錄了用戶對(duì)網(wǎng)站的訪問(wèn)情況，這類數(shù)據(jù)通常直接以文本文件形式記錄在文件系統(tǒng)中，對(duì)于數(shù)據(jù)的分析、統(tǒng)計(jì)、挖掘等各類數(shù)據(jù)應(yīng)用有極大的價(jià)值。

??阿里數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)同步的特點(diǎn)之 則體現(xiàn)在數(shù)據(jù)量上。傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)每天同步的數(shù)據(jù)量一般在幾百 GB 甚至更少，而一些大型互聯(lián)網(wǎng)企業(yè)的大數(shù)據(jù)系統(tǒng)每天同步的數(shù)據(jù)量則達(dá)到 PB 級(jí)別。目前間里巴巴的大數(shù)據(jù)處理系統(tǒng) MaxCompute 的數(shù)據(jù)存儲(chǔ)達(dá)到 EB 級(jí)別，每天需要同步的數(shù)據(jù)量達(dá)到 PB 級(jí)別，這種量級(jí)上的差距是巨大的。

??數(shù)據(jù)源的類型是多樣的，需要同步的數(shù)據(jù)是海量的，那該如何準(zhǔn)確、高效地完成數(shù)據(jù)同步呢？這里就需要針對(duì)不同的數(shù)據(jù)源類型和數(shù)據(jù)應(yīng)用的時(shí)效性要求而采取不同的策略。

3.2.1 批量數(shù)據(jù)同步

??對(duì)于離線類型的數(shù)據(jù)倉(cāng)庫(kù)應(yīng)用，需要將不同的數(shù)據(jù)源批量同步到數(shù)據(jù)倉(cāng)庫(kù)，以及將經(jīng)過(guò)數(shù)據(jù)倉(cāng)庫(kù)處理的結(jié)果數(shù)據(jù)定時(shí)同步到業(yè)務(wù)系統(tǒng)。

??當(dāng)前市場(chǎng)上的數(shù)據(jù)庫(kù)系統(tǒng)種類很多 ，有行存儲(chǔ)的和列存儲(chǔ)的，有開(kāi)源的和非開(kāi)源的，每一種數(shù)據(jù)庫(kù)的數(shù)據(jù)類型都略有不同，而數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)則是集成各類數(shù)據(jù)源的地方，所以數(shù)據(jù)類型是統(tǒng)一的。要實(shí)現(xiàn)各類數(shù)據(jù)庫(kù)系統(tǒng)與數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)之間的批量雙向數(shù)據(jù)同步，就需要先將數(shù)據(jù)轉(zhuǎn)換為中間狀態(tài)，統(tǒng)一數(shù)據(jù)格式。由于這類數(shù)據(jù)都是結(jié)構(gòu)化的，且均支持標(biāo)準(zhǔn)的 SQL 語(yǔ)言查詢，所以所有的數(shù)據(jù)類型都可以轉(zhuǎn)換為字符串類型。因此，我們可以通過(guò)將各類源數(shù)據(jù)庫(kù)系統(tǒng)的數(shù)據(jù)類型統(tǒng) 轉(zhuǎn)換為字符串類型的方式，實(shí)現(xiàn)數(shù)據(jù)格式的統(tǒng)一。

??阿里巴巴的 DataX 就是這樣 個(gè)能滿足多方向高自由度的異構(gòu)數(shù)據(jù)交換服務(wù)產(chǎn)品。對(duì)于不同的數(shù)據(jù)源， DataX 通過(guò)插件的形式提供支持，將數(shù)據(jù)從數(shù)據(jù)源讀出并轉(zhuǎn)換為中間狀態(tài)，同時(shí)維護(hù)好數(shù)據(jù)的傳輸、緩存等工作。數(shù)據(jù)在 DataX 中以中間狀態(tài)存在， 并在目標(biāo)數(shù)據(jù)系統(tǒng)中將中間狀態(tài)的數(shù)據(jù)轉(zhuǎn)換為對(duì)應(yīng)的數(shù)據(jù)格式后寫(xiě)人。目前 DataX 每天都需要處理2PB 左右的批量數(shù)據(jù)同步任務(wù)，通過(guò)分布式模式，同步完所有的數(shù)據(jù)所需要的時(shí)間一般在 小時(shí)以內(nèi)，有力保障了大數(shù)據(jù)同步的準(zhǔn)確性及高效性（見(jiàn)圖 3.4 ）。

??DataX 采用 Framework+Plugin 的開(kāi)放式框架實(shí)現(xiàn)， Framework 處理緩沖、流程控制、并發(fā)、上下文加載等高速數(shù)據(jù)交換的大部分技術(shù)問(wèn)題，并提供簡(jiǎn)單的接口與插件接人（見(jiàn)圖 3.5 ）。插件僅需實(shí)現(xiàn)對(duì)數(shù)據(jù)處理系統(tǒng)的訪問(wèn)，編寫(xiě)方便，開(kāi)發(fā)者可以在極短的時(shí)間內(nèi)開(kāi)發(fā) 個(gè)插件以快速支持新的數(shù)據(jù)庫(kù)或文件系統(tǒng)。數(shù)據(jù)傳輸在單進(jìn)程（單機(jī)模式）／多進(jìn)程（分布式模式）下完成，傳輸過(guò)程全內(nèi)存操作，不讀寫(xiě)磁盤，也沒(méi)有進(jìn)程間通信，實(shí)現(xiàn)了在異構(gòu)數(shù)據(jù)庫(kù)或文件系統(tǒng)之間的高速數(shù)據(jù)交換。

? Job ：數(shù)據(jù)同步作業(yè)
? Splitter ：作業(yè)切分模塊，將 個(gè)大任務(wù)分解成多個(gè)可以并發(fā)行的小任務(wù)
? Sub-Job ：數(shù)據(jù)同步作業(yè)切分后的小任務(wù)，或稱之為 Task
? Read er ：數(shù)據(jù)讀人模塊，負(fù) 運(yùn)行切分后的小任務(wù)，將數(shù)據(jù)從源系統(tǒng) 載到 DataX
? Channel: eader Writer 通過(guò) hannel 交換數(shù)據(jù)。
? Writer ：數(shù)據(jù) 出模塊，負(fù)責(zé)將數(shù)據(jù)從 DataX 導(dǎo)人目標(biāo)數(shù)據(jù)系統(tǒng)。

實(shí)時(shí)數(shù)據(jù)同步

??對(duì)于日 志類數(shù)據(jù)來(lái)說(shuō)，由于每天的日志是源源不斷 生的，并且分布在不同的服務(wù)器中，有些大型互聯(lián)網(wǎng)公司的服務(wù)器集群有成千上萬(wàn)臺(tái)機(jī)器，所以所產(chǎn)生的日志需要盡快以數(shù)據(jù)流的方式不間斷地同步到數(shù)據(jù)倉(cāng)庫(kù)。 另外，還有 些數(shù)據(jù)應(yīng)用，需要對(duì)業(yè)務(wù)系統(tǒng)產(chǎn)生的數(shù)據(jù)進(jìn)行實(shí)時(shí)處理，比如 貓“雙 ”的數(shù)據(jù)大屏，對(duì)所產(chǎn)生的交易數(shù)據(jù)需要實(shí)時(shí)匯總，實(shí)現(xiàn)秒級(jí)的數(shù)據(jù)刷新。這類數(shù)據(jù)是通過(guò)解析 MySQL binlog日志（相當(dāng)于 Orac le 的歸檔日志）來(lái)實(shí)時(shí)獲得增量的數(shù)據(jù)更新，并通過(guò)消息訂閱模式來(lái)實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)同步的。具體來(lái)說(shuō) ，就是建立 個(gè)日志數(shù)據(jù)交換中心，通過(guò)專門的模塊從每臺(tái)服務(wù)器源源不斷地讀取日志數(shù)據(jù)，或者解析業(yè)務(wù)數(shù)據(jù)庫(kù)系統(tǒng)的 binlog 或歸檔日志，將增量數(shù)據(jù)以數(shù)據(jù)流的方式不斷同步到日志交換中心，然后通知所有訂閱了這些數(shù)據(jù)的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)來(lái)獲取。阿里巴巴的 TimeTunnel (TT ）系統(tǒng)就是這樣的實(shí)時(shí)數(shù)據(jù)傳輸平臺(tái)，具有高性能、實(shí)時(shí)性、順序性、高可靠性、高可用性、可擴(kuò)展性等特點(diǎn)。

??具體來(lái)說(shuō)， TT 是一種基于生產(chǎn)者、消費(fèi)者和 Topic 消息標(biāo)識(shí)的消息中間件，將消息數(shù)據(jù)持久化到 HBase 的高可用、分布式數(shù)據(jù)交互系統(tǒng)。
?生產(chǎn)者 ：消息數(shù)據(jù)的產(chǎn)生端，向 TimeTunnel 集群發(fā)送消息數(shù)據(jù)，就是圖 3.6 中的生產(chǎn) Client
?消費(fèi)者：消息數(shù)據(jù)的接收端，從 TimeTunnel 集群中獲取數(shù)據(jù)進(jìn)行業(yè)務(wù)處理。
? Topic ：消息類型的標(biāo)識(shí)，如淘 acookie 志的 Topic為taobao_acookie 生產(chǎn) Client 和消費(fèi) Client 需要知道對(duì)應(yīng)的Topic 字。
? Broker 模塊 負(fù)責(zé)處理客戶端收發(fā)消息數(shù)據(jù)的請(qǐng)求，然后往HBase 取發(fā)數(shù)據(jù)。

??Time Tunnel 支持主動(dòng)、被動(dòng)等多種數(shù)據(jù)訂閱機(jī)制，訂閱端自動(dòng)負(fù)載均衡，消費(fèi)者自己把握消費(fèi)策略。對(duì)于讀寫(xiě)比例很高的 Topic ，能夠做到讀寫(xiě)分離，使消費(fèi)不影響發(fā)送。同時(shí)支持訂閱歷史數(shù)據(jù)，可以隨意設(shè)置訂閱位置，方便用戶回補(bǔ)數(shù)據(jù)。另外，針對(duì)訂閱有強(qiáng)大的屬性過(guò)濾功能，用戶只需關(guān)心自己需要的數(shù)據(jù)即可。
參考資料：大數(shù)據(jù)技術(shù)之DataX

3.3 數(shù)據(jù)同步遇到的問(wèn)題及解決方案

3.3.1 分庫(kù)分表的處理

??隨著業(yè)務(wù)的不斷增長(zhǎng)，業(yè)務(wù)系統(tǒng)處理的數(shù)據(jù)量也在飛速增加，需要系統(tǒng)具備靈活的擴(kuò)展能力和高并發(fā)大數(shù)據(jù)量的處理能力，目前一些主流數(shù)據(jù)庫(kù)系統(tǒng)都提供了分布式分庫(kù)分表方案來(lái)解決這個(gè)問(wèn)題（見(jiàn)圖 3. ）。但是對(duì)于數(shù)據(jù)同步來(lái)說(shuō)，這種分庫(kù)分表的設(shè)計(jì)無(wú)疑 大了同步處理的復(fù)雜度。試想 下，如果有一個(gè)中間表，具備將分布在不同數(shù)據(jù)庫(kù)中的不同表集成為 個(gè)表的能力，就能讓下游應(yīng)用像訪問(wèn)單庫(kù)單表一樣方便。

??阿里巴巴的 TDDL ( Taobao Distributed Data ayer ）就是這樣一個(gè)分布式數(shù)據(jù)庫(kù)的訪問(wèn)引擎，通過(guò)建立中間狀態(tài)的邏輯表來(lái)整合統(tǒng)一分庫(kù)分表的訪問(wèn)（見(jiàn)圖 3.8 ）。

??TDDL是在持久層框架之下、 JDBC驅(qū)動(dòng)之上的中間件，它與JDBC規(guī)范保持一致，有效解決了分庫(kù)分表的規(guī)則引擎問(wèn)題，實(shí)現(xiàn)了SQL解析、規(guī)則計(jì)算、表名替換、選擇執(zhí)行單元并合并結(jié)果集的功能，同時(shí)解決了數(shù)據(jù)庫(kù)表的讀寫(xiě)分離、高性能主備切換的問(wèn)題，實(shí)現(xiàn)了數(shù)據(jù)庫(kù)配置信息的統(tǒng) 管理。

??JDBC ( Java DataBaseConnectivity java數(shù)據(jù)庫(kù)連接)是一種用于執(zhí)行SQL語(yǔ)句的Java API，可以為多種關(guān)系型數(shù)據(jù)庫(kù)提供統(tǒng)一訪問(wèn)，它是由一組用Java語(yǔ)言編寫(xiě)的類和接口組成的。


參考資料：

• 分庫(kù)分表介紹

• TDDL介紹

3.3.2 高效同步及批量同步

??數(shù)據(jù)同步的方法通常是先創(chuàng)建目標(biāo)表 ，再通過(guò)同步工具的填寫(xiě)數(shù)據(jù)庫(kù)連接、表 段等各種配置信息后測(cè)試完成數(shù)據(jù)同步。這也是 DataX任務(wù)的配置過(guò)程，同步中心對(duì) DataX 進(jìn)行進(jìn) 步封裝，通過(guò)源系統(tǒng)元數(shù)據(jù)降低了數(shù)據(jù)庫(kù)連接、表和字段等信息的配置復(fù)雜度，但在實(shí)際生產(chǎn)過(guò)程中我們?nèi)匀粫?huì)遇到 些問(wèn)題。

• 隨著業(yè)務(wù)的發(fā)展和變化，會(huì)新增大批量的數(shù)據(jù)同步，使用傳統(tǒng)方式每天去完成成百上千的數(shù)據(jù)同步工作，一方面，工作量會(huì)特別大另一方面，相似并且重復(fù)的操作會(huì)降低開(kāi)發(fā)人員的工作熱情。
• 數(shù)據(jù)倉(cāng)庫(kù) 的數(shù)據(jù)源種類特別豐富，遇到不同類型的數(shù)據(jù)源同步就要求開(kāi)發(fā)人員去了解其特殊配置。
• 部分真正 的數(shù)據(jù)需求方，如 Java 開(kāi)發(fā)和業(yè)務(wù)運(yùn)營(yíng)，由于存在相關(guān)數(shù)據(jù)同步的專業(yè)技能門檻，往往需要將需求提交給數(shù)據(jù)開(kāi)發(fā)方來(lái)完成，額外增加了溝通和流程成本。

??為了解決上述問(wèn)題，網(wǎng)里巴巴數(shù)據(jù)倉(cāng)庫(kù)研發(fā)了 OneC lick 產(chǎn)品：

• 對(duì)不同數(shù)據(jù)源的數(shù)據(jù)同步配置透明化，可以通過(guò)庫(kù)名和表名唯一定位，通過(guò) IDB 接口獲取元數(shù)據(jù)信息自動(dòng)生成配置信息。
• 簡(jiǎn)化了數(shù)據(jù)同步的操作步驟，實(shí)現(xiàn)了與數(shù)據(jù)同步相關(guān)的建表、配置任務(wù)、發(fā)布、測(cè)試操作一鍵化處理，并且封裝成 Web 接口進(jìn)一步達(dá)到批量化的效果。
• 降低了數(shù)據(jù)同步的技能門檻，讓數(shù)據(jù)需求方更加方便地獲取和使
  用數(shù)據(jù)。

??通過(guò) OneClick 產(chǎn)品，真正實(shí)現(xiàn)了數(shù)據(jù)的一鍵化和批量化同步，一鍵完成 DDL DML 生成、數(shù)據(jù)的冒煙測(cè)試以及在生產(chǎn)環(huán)境中測(cè)試等。因此，阿里巴巴通過(guò)極少的人力投入，實(shí)現(xiàn)了數(shù)據(jù)同步的集中化建設(shè)和管理：改變了之前各數(shù)據(jù)開(kāi)發(fā)人員自行同步帶來(lái)的效率低、重復(fù)同步和同步配置質(zhì)量低下等問(wèn)題，大大降低了數(shù)據(jù)同步成本。

3.3.3 增量與全量同步的合并

??在批量數(shù)據(jù)同步中，有些表的數(shù)據(jù)量隨著業(yè)務(wù)的發(fā)展越來(lái)越大，如果按周期全量同步的方式會(huì)影響處理效率。在這種情況下，可以選擇每次只同步新變更的增量數(shù)據(jù)，然后與上一個(gè)同步周期獲得的全量數(shù)據(jù)進(jìn)行合井，從而獲得最新版本的全量數(shù)據(jù)。

??在傳統(tǒng)的數(shù)據(jù)整合方案中，合并技術(shù)大多采用 merge 方式( update+insert ）：當(dāng)前流行的大數(shù)據(jù)平臺(tái)基本都不支持 update 操作 ，現(xiàn)在我們比較推薦的方式是全外連接（ full outer join) ＋數(shù)據(jù)全量覆蓋重新加載（ insert overwrite ），即如日調(diào)度，則將當(dāng)天的增量數(shù)據(jù)和前一天的全量數(shù)據(jù)做全外連接，重新加載最新的全量數(shù)據(jù)。在大數(shù)據(jù)量規(guī)模下，全量更新的性能比 update 要高得多。此外，如果擔(dān)心數(shù)據(jù)更新錯(cuò)誤問(wèn)題，可以采用分區(qū)方式，每天保持 個(gè)最新的全量版本，保留較短的時(shí)間周期（如 3~7 天）。

??另外，當(dāng)業(yè)務(wù)系統(tǒng)的表有物理刪除數(shù)據(jù)的操作，而數(shù)據(jù)倉(cāng)庫(kù)需要保留所有歷史數(shù)據(jù)時(shí)，也可以選擇這種方式，在數(shù)據(jù)倉(cāng)庫(kù)中永久保留最新的全量數(shù)據(jù)快照 下面我們以淘寶訂單表的具體實(shí)例來(lái)說(shuō)明。

??淘寶交易訂單表，每天新增、變更的增量數(shù)據(jù)多達(dá)幾億條，歷史累計(jì)至今的全量數(shù)據(jù)則有幾百億條，面對(duì)如此龐大的數(shù)據(jù)量，如果每天從業(yè)務(wù)系統(tǒng)全量同步顯然是不可能的 可行的方式是同步當(dāng)天的增量數(shù)據(jù)，并與數(shù)據(jù)倉(cāng)庫(kù)中的前一天全量數(shù)據(jù)合并，獲得截至當(dāng)天的最新全量數(shù)據(jù)（見(jiàn)圖 3.9 ）。

3.3.4 同步性能處理

??數(shù)據(jù)同步任務(wù)是針對(duì)不同數(shù)據(jù)庫(kù)系統(tǒng)之間的數(shù)據(jù)同步問(wèn)題而創(chuàng)建的一系列周期調(diào)度的任務(wù)。在大型的數(shù)據(jù)調(diào)度工作臺(tái)上，每天會(huì)運(yùn)行大量的數(shù)據(jù)同步任務(wù)。針對(duì)數(shù)據(jù)同步任務(wù) 一般首先需要設(shè)定首輪同步的線程數(shù)，然后運(yùn)行同步任務(wù)。

??這樣的數(shù)據(jù)同步模式存在以下幾個(gè)問(wèn)題：

• 有些數(shù)據(jù)同步任務(wù)的總線程數(shù)達(dá)不到用戶設(shè)置的首輪同步的線程數(shù)時(shí)，如果同步控制器將這些同步線程分發(fā)到 PU 較繁忙的機(jī)器上，將導(dǎo)致這些同步任務(wù)的平均同步速度非常低，數(shù)據(jù)同步速度非常慢。
• 用戶不清楚該如何設(shè)置首輪同步的線程數(shù)，基本都會(huì)設(shè)置成一個(gè)固定的值，導(dǎo)致同步任務(wù)因得不到合理的 PU 資源而影響同步效率。
• 不同的數(shù)據(jù)同步任務(wù)的重要程度是不一樣的，但是同步控制器平等對(duì)待接收到的同步線程，導(dǎo)致重要的同步線程因得不 CPU資源而無(wú)法同步。

??上述數(shù)據(jù)同步模式存在的幾個(gè)問(wèn)題導(dǎo)致的最終結(jié)果是數(shù)據(jù)同步任務(wù)運(yùn)行不穩(wěn)定。
??針對(duì)數(shù)據(jù)同步任務(wù)中存在的問(wèn)題，阿里巴巴數(shù)據(jù)團(tuán)隊(duì)實(shí)踐出了一套基于負(fù)載均衡思想的新型數(shù)據(jù)同步方案。該方案的核心思想是通過(guò)目標(biāo)數(shù)據(jù)庫(kù)的元數(shù)據(jù)估算同步任務(wù)的總線程數(shù)，以及通過(guò)系統(tǒng)預(yù)先定義的期望同步速度估算首輪同步的線程數(shù)，同時(shí)通過(guò)數(shù)據(jù)同步任務(wù)的業(yè)務(wù)優(yōu)先級(jí)決定同步線程的優(yōu)先級(jí)，最終提升同步任務(wù)的執(zhí)行效率和穩(wěn)定性。
??具體實(shí)現(xiàn)步驟如下:

• 用戶創(chuàng)建數(shù)據(jù)同步任務(wù)，并提交該同步任務(wù)。根據(jù)系統(tǒng)提前獲知及設(shè)定的數(shù)據(jù)，估算該同步任務(wù)需要同步的數(shù)據(jù)量、平均同步速度、首輪運(yùn)行期望的線程數(shù)、需要同步的總線程數(shù)。
• 根據(jù)需要同步的總線程數(shù)將待同步的數(shù)據(jù)拆分成相 等數(shù)量的數(shù)據(jù)塊，一個(gè)線程處理 個(gè)數(shù)據(jù)塊，并將該任務(wù)對(duì)應(yīng)的所有線程提交至同步控制器。
• 同步控制器判斷需要同步的總線程數(shù)是否大于首輪運(yùn)行期望的線程數(shù)，若大于，則跳轉(zhuǎn)至 若不大于，則跳轉(zhuǎn)至。
• 同步控制器采用多機(jī)多線程的數(shù)據(jù)同步模式，準(zhǔn)備該任務(wù)第一輪線程的調(diào)度，優(yōu)先發(fā)送等待時(shí)間最長(zhǎng)、優(yōu)先級(jí)最高且同 任務(wù)的線程。
• 同步控制器準(zhǔn)備一定數(shù)據(jù)量（期望首輪線程數(shù)－總線程數(shù)）的虛擬線程，采用單機(jī)多線程的數(shù)據(jù)同步模式 ，準(zhǔn)備該任務(wù)相應(yīng)實(shí)體線程和虛??擬線程的調(diào)度，優(yōu)先發(fā)送等待時(shí)間最長(zhǎng)、優(yōu)先級(jí)最高且單機(jī) PU 剩余資源可以支持首輪所有線程數(shù)且同 任務(wù)的線程，如果沒(méi)有滿足條件的機(jī)器，則選擇 CPU 剩余資源最多的機(jī)器進(jìn)行首輪發(fā)送。
• 數(shù)據(jù)任務(wù)開(kāi)始同步，并等待完成。
• 數(shù)據(jù)任務(wù)同步結(jié)束。

3.3.5 數(shù)據(jù)漂移處理

??通常我們把從源系統(tǒng)同步進(jìn)人數(shù)據(jù)倉(cāng)庫(kù)的第一層數(shù)據(jù)稱為 ODS或者staging 層數(shù)據(jù)，阿里巴巴統(tǒng)稱為 ODS 。數(shù)據(jù)漂移是 ODS 數(shù)據(jù)的一個(gè)頑疾，通常是指 ODS 表的同一個(gè)業(yè)務(wù)日期數(shù)據(jù)中包含前一天或后一天凌晨附近的數(shù)據(jù)或者丟失當(dāng)天的變更數(shù)據(jù)。

??由于 ODS 需要承接面向歷史的細(xì)節(jié)數(shù)據(jù)查詢需求，這就需要物理落地到數(shù)據(jù)倉(cāng)庫(kù)的 ODS 表按時(shí)間段來(lái)切分進(jìn)行分區(qū)存儲(chǔ) ，通常的做法是按某些時(shí)間戳字段來(lái)切分，而實(shí)際上往往由于時(shí)間戳字段的準(zhǔn)確性問(wèn)題導(dǎo)致發(fā)生數(shù)據(jù)漂移。

??通常，時(shí)間戳字段分為四類：

• 數(shù)據(jù)庫(kù)表中用來(lái)標(biāo)識(shí)數(shù)據(jù)記錄更新時(shí)間的時(shí)間戳字段（假設(shè)這類字段叫 modified time ）。
• 數(shù)據(jù)庫(kù)日志中用來(lái)標(biāo)識(shí)數(shù)據(jù)記錄更新時(shí)間的時(shí)間戳字段·（假設(shè)這類宇段叫 log_time）。
• 數(shù)據(jù)庫(kù)表中用來(lái)記錄具體業(yè)務(wù)過(guò)程發(fā)生時(shí)間的時(shí)間戳字段 （假設(shè)這類字段叫 proc_time）。
• 標(biāo)識(shí)數(shù)據(jù)記錄被抽取到時(shí)間的時(shí)間戳字段（假設(shè)這類字段叫extract time）。

??理論上，這幾個(gè)時(shí)間應(yīng)該是 致的，但是在實(shí)際生產(chǎn)中，這幾個(gè)時(shí)間往往會(huì)出現(xiàn)差異，可能的原因有以下幾點(diǎn)：

• 由于數(shù)據(jù)抽取是需要時(shí)間的， extract_ti me 往往會(huì)晚于前三個(gè)時(shí)間。
• 前臺(tái)業(yè)務(wù)系統(tǒng)手工訂正數(shù)據(jù)時(shí)未更新 modified_time。
• 由于網(wǎng)絡(luò)或者系統(tǒng)壓力問(wèn)題， log_time 或者 modified_time 會(huì)晚于proc time。

??通常的做法是根據(jù)其中的某 個(gè)字段來(lái)切分 ODS 表，這就導(dǎo)致產(chǎn)生數(shù)據(jù)漂移。下面我們來(lái)具體看下數(shù)據(jù)漂移的幾種場(chǎng)景。

• 根據(jù) extract_ti me 來(lái)獲取數(shù)據(jù)。這種情況數(shù)據(jù)漂移的問(wèn)題最明顯。
• 根據(jù) modified_time 限制。在實(shí)際生產(chǎn)中這種情況最常見(jiàn)，但是往往會(huì)發(fā)生不更新 modified time 而導(dǎo)致的數(shù)據(jù)遺漏，或者凌晨時(shí)間產(chǎn)生的??數(shù)據(jù)記錄漂移到后一天。
• 根據(jù) log_time 限制。由于網(wǎng)絡(luò)或者系統(tǒng)壓力問(wèn)題， log time 會(huì)晚于proc_time ，從而導(dǎo)致凌晨時(shí)間產(chǎn)生的數(shù)據(jù)記錄漂移到后一天。例如，??在淘寶“雙 l l ”大促期間凌晨時(shí)間產(chǎn)生的數(shù)據(jù)量非常大，用戶支付需要調(diào)用多個(gè)接口，從而導(dǎo)致 log time 晚于實(shí)際的支付時(shí)間。
• 根據(jù) proc_time 限制。僅僅根據(jù) proc_time 限制，我們所獲取的ODS 表只是包含一個(gè)業(yè)務(wù)過(guò)程所產(chǎn)生的記 ，會(huì)遺漏很多其他過(guò)程的變化記錄，這違背了 ODS 和業(yè)務(wù)系統(tǒng)保持 致的設(shè)計(jì)原則。

??處理方法主要有以下兩種：
( 1 ）多獲取后一天的數(shù)據(jù)
??既然很難解決數(shù)據(jù)漂移的問(wèn)題，那么就在 ODS 每個(gè)時(shí)間分區(qū)中向前、向后多冗余 些數(shù)據(jù)，保障數(shù)據(jù)只會(huì)多不會(huì)少，而具體的數(shù)據(jù)切分讓下游根據(jù)自身不同的業(yè)務(wù)場(chǎng)景用不同的業(yè)務(wù)時(shí)間 proc time 來(lái)限制但是這種方式會(huì)有一些數(shù)據(jù)誤差，例如 個(gè)訂單是當(dāng)天支付的，但是第二天凌晨申請(qǐng)退款關(guān)閉了該訂單，那么這條記錄的訂單狀態(tài)會(huì)被更新，下游在統(tǒng)計(jì)支付訂單狀態(tài)時(shí)會(huì)出現(xiàn)錯(cuò)誤。

（2）通過(guò)多個(gè)時(shí)間戳字段限制時(shí)間來(lái)獲取相對(duì)準(zhǔn)確的數(shù)據(jù)文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-824575.html

• 首先根據(jù) log_time 分別冗余前一天最后 15 分鐘的數(shù)據(jù)和后一天凌晨開(kāi)始 15 分鐘的數(shù)據(jù)，并用 modified time 過(guò)濾非當(dāng)天數(shù)據(jù)，確保數(shù)據(jù)不會(huì)因?yàn)橄到y(tǒng)問(wèn)題而遺漏。
• 然后根據(jù) log_time 獲取后一天 15 分鐘的數(shù)據(jù) 針對(duì)此數(shù)據(jù)，按照主鍵根據(jù) log_time 做升序排列去重。因?yàn)槲覀冃枰@取的是最接近當(dāng)天記錄變化的數(shù)據(jù)（數(shù)據(jù)庫(kù)日志將保留所有變化的數(shù)據(jù)，但是落地到 DS 表的是根據(jù)主鍵去重獲取最后狀態(tài)變化的數(shù)據(jù)）。
• 最后將前兩步的結(jié)果數(shù)據(jù)做全外連接，通過(guò)限制業(yè)務(wù)時(shí)間proc_time 來(lái)獲取我們所需要的數(shù)據(jù)。

到了這里，關(guān)于大數(shù)據(jù)之路——數(shù)據(jù)同步（第三章）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！