[[347889]]

Maxwell是開(kāi)源產(chǎn)品,相比Canal的體量也小很多，綜合考慮下，在短期內(nèi)選擇了Maxwell.

從快速上手到功能支持，算是一個(gè)總體支持還不錯(cuò)的產(chǎn)品，也讓技術(shù)調(diào)研和迭代進(jìn)度進(jìn)展相對(duì)快了很多。

一般說(shuō)要比較，基本都會(huì)拿出這幅圖來(lái)(數(shù)據(jù)帶有主觀特點(diǎn)，僅供參考)，因?yàn)榭紤]到bootstrap是個(gè)硬性需求，所以這部分的功能考量也是一個(gè)重要權(quán)衡。

最近在做數(shù)據(jù)庫(kù)到大數(shù)據(jù)流轉(zhuǎn)的過(guò)程中發(fā)現(xiàn)了Maxwell的一些問(wèn)題和改進(jìn)點(diǎn)：

1)Maxwell的服務(wù)管理模式目前只支持start模式，如果要停止只能采用手工kill的方式，相對(duì)粗暴一些，當(dāng)然和作者交流，可以使用信號(hào)處理的方式來(lái)間接實(shí)現(xiàn)。

2)Maxwell的核心配置是對(duì)于同步對(duì)象的過(guò)濾，可以支持正則等模式，如果過(guò)濾規(guī)則較為復(fù)雜，或者后期不斷的調(diào)整，每次調(diào)整都需要重新啟動(dòng)Maxwell服務(wù)，沒(méi)有類似reload的模式。

3)對(duì)于DDL變更，如果Maxwell的初始化已完成，服務(wù)已啟動(dòng)，在后續(xù)創(chuàng)建一張表的時(shí)候，Maxwell會(huì)把變更記錄至`schemas`表中維護(hù)版本變更記錄，在已有的元數(shù)據(jù)表中`tables`和`columns`里面就沒(méi)有這些信息了，對(duì)于后端的服務(wù)解析表結(jié)構(gòu)會(huì)帶來(lái)一些偏差(DDL的變更配置會(huì)有相應(yīng)的JSON)

1.問(wèn)題定位

這些問(wèn)題算起來(lái)大多是建議，不算是致命問(wèn)題，所以整體的進(jìn)度依然可以繼續(xù)推進(jìn)，但是最近在做了幾張大表的同步之后發(fā)現(xiàn)了一些數(shù)據(jù)問(wèn)題。

1)bootstrap的時(shí)間比較長(zhǎng)，查看Maxwell相關(guān)監(jiān)控，整體的數(shù)據(jù)吞吐量在800條/秒左右，好像是達(dá)到了整個(gè)同步的瓶頸，同步一張200多萬(wàn)數(shù)據(jù)的表需要1個(gè)小時(shí)左右，相對(duì)比較長(zhǎng)，我們?cè)诮诘臏y(cè)試中，幾張千萬(wàn)級(jí)的大表如果串行初始化，差不多得2-3個(gè)小時(shí)，實(shí)在是太長(zhǎng)了。

2)同步數(shù)據(jù)的時(shí)間字段值存在差異，這也是在中端(maxwell規(guī)劃為中端服務(wù))和后端(Flink,Kudu規(guī)劃為后端)在做數(shù)據(jù)比對(duì)中發(fā)現(xiàn)的，bootstrap的數(shù)據(jù)比對(duì)結(jié)果幾乎沒(méi)有相同的，也就意味是bootstrap在數(shù)據(jù)方面存在一些潛在問(wèn)題，所以整個(gè)事情輪盤到了Maxwell的bootstrap部分。

查看代碼邏輯，著實(shí)讓我一驚，這個(gè)問(wèn)題目前僅在bootstrap的環(huán)節(jié)出現(xiàn)，比如數(shù)據(jù)的時(shí)間字段值為：

但是經(jīng)過(guò)邏輯處理后，會(huì)有時(shí)區(qū)的計(jì)算，會(huì)自動(dòng)補(bǔ)上時(shí)區(qū)的差異。

現(xiàn)在的問(wèn)題已經(jīng)不是初始化帶來(lái)的性能隱患，而是數(shù)據(jù)質(zhì)量出現(xiàn)了侵入性，導(dǎo)致數(shù)據(jù)看起來(lái)錯(cuò)亂。

對(duì)于這個(gè)問(wèn)題，分析的重點(diǎn)就是時(shí)區(qū)的處理差異，本來(lái)想這個(gè)改動(dòng)應(yīng)該很小，沒(méi)想到調(diào)試和環(huán)境集成著實(shí)花了不少功夫。

2.問(wèn)題修正

對(duì)于時(shí)區(qū)的數(shù)據(jù)差異，主要在于datetime數(shù)據(jù)類型存在時(shí)區(qū)差異，目前差距在13個(gè)小時(shí)。

查看Maxwell的代碼類SynchronousBootstrapper：

經(jīng)過(guò)調(diào)試，需要改動(dòng)的代碼邏輯范圍是基于函數(shù)setRowValues：

可以修改為：

改動(dòng)之后，整個(gè)bootstrap的邏輯經(jīng)過(guò)調(diào)試和反復(fù)測(cè)試就正常了。

3.性能問(wèn)題的取舍和修正

當(dāng)然在這個(gè)之外，也做了一些細(xì)小的改進(jìn)。

第一個(gè)問(wèn)題就是bootstrap的性能問(wèn)題，之前看似乎是有瓶頸，吞吐量在800左右就上不去了，對(duì)此我做了如下的改進(jìn)：

1).bootstrap的一個(gè)基本原理就是select * from xxxx order by id;這種使用模式，如果表數(shù)據(jù)量比較大，其實(shí)order by的部分看起來(lái)是走了主鍵，該子句會(huì)強(qiáng)制走全索引掃描，但是整體的效果反而不是全表掃描，所以我就干脆去除了邏輯中的order by子句。

整個(gè)邏輯的改造也很輕量：

private ResultSet getAllRows(String databaseName, String tableName, Table table, String whereClause, 
        if ( pk != null && !pk.equals("") ) { 
            sql += String.format(" order by %s", pk); 
        } 

2).去除了寫入數(shù)據(jù)后的sleep 1毫秒

進(jìn)一步分析代碼，發(fā)現(xiàn)bootstrap中吞吐量的瓶頸是其中一個(gè)詭異的sleep 1的處理，根據(jù)初步分析，可能考慮到bootstrap的任務(wù)會(huì)產(chǎn)生大量數(shù)據(jù)，對(duì)于帶寬和負(fù)載壓力較大，通過(guò)sleep的方式能夠做到降速，整體可控。

另外對(duì)于bootstrap的日志統(tǒng)計(jì)中會(huì)包括同步的數(shù)據(jù)條數(shù)，這個(gè)指標(biāo)值目前的依賴度不高，而且數(shù)據(jù)校驗(yàn)的工作目前會(huì)先停止Slave再進(jìn)行數(shù)據(jù)比對(duì)

性能提升和改進(jìn)，在3-5倍左右，所以這個(gè)部分的邏輯我們可以根據(jù)實(shí)際情況取舍，在我們的流傳設(shè)計(jì)中，數(shù)據(jù)都是基于Slave端進(jìn)行流轉(zhuǎn)的，所以不會(huì)對(duì)主庫(kù)造成沖擊，改動(dòng)的這個(gè)部分的邏輯也很輕巧，注釋掉sleep(1)即可。

public void performBootstrap(BootstrapTask task, AbstractProducer producer, Long currentSchemaID) throws Exception { 
               producer.push(row); 
               Thread.sleep(1); 
               ++insertedRows; 

改動(dòng)后經(jīng)過(guò)測(cè)試和對(duì)比，發(fā)現(xiàn)性能好了很多，最多的時(shí)候能有6000多，同樣的初始化不到15分鐘左右就全部搞定了。

這樣一些細(xì)小的改進(jìn)也給我們帶來(lái)了一些成就感，后續(xù)的數(shù)據(jù)同步規(guī)模繼續(xù)擴(kuò)大，也沒(méi)有再反饋過(guò)數(shù)據(jù)質(zhì)量的問(wèn)題，當(dāng)然在這個(gè)基礎(chǔ)上還有一些工作需要細(xì)化。

4.后續(xù)對(duì)于bootstrap方向的改進(jìn)

1)使用分片的思路來(lái)完善bootstrap

提高數(shù)據(jù)提取的效率，對(duì)于千萬(wàn)級(jí)以上的大表數(shù)據(jù)抽取，可以按照區(qū)間分段來(lái)提取(需要考慮到數(shù)據(jù)的變更和寫入的影響)，目前的邏輯過(guò)于僵硬。

private ResultSet getAllRows(String databaseName, String tableName, Table table, String whereClause, 
                                Connection connection) throws SQLException { 
       Statement statement = createBatchStatement(connection); 
       String pk = table.getPKString(); 
       String sql = String.format("select * from `%s`.%s", databaseName, tableName); 
       if ( whereClause != null && !whereClause.equals("") ) { 
           sql += String.format(" where %s", whereClause); 
       } 
       if ( pk != null && !pk.equals("") ) { 
           sql += String.format(" order by %s", pk); 
       } 
       return statement.executeQuery(sql); 
   } 

2)數(shù)據(jù)字典索引優(yōu)化

Maxwell數(shù)據(jù)字典的優(yōu)化，目前的數(shù)據(jù)字典中，部分SQL執(zhí)行頻率較高，但是從數(shù)據(jù)庫(kù)層面來(lái)看是全表掃描，這些細(xì)節(jié)的地方還需要進(jìn)一步調(diào)整。

比如如下的SQL語(yǔ)句：

>>explain select * from bootstrap where is_complete = 0 and client_id = 'dts_hb30_130_200_maxwell003' and (started_at is null or started_at <= now()) order by isnull(started_at), started_at asc, id asc; 

基于業(yè)務(wù)場(chǎng)景的改進(jìn)和調(diào)整，也讓我們通過(guò)真實(shí)場(chǎng)景的落地，更好的擁抱開(kāi)源，并在一定程度上能夠回饋和反哺。

本文轉(zhuǎn)載自微信公眾號(hào)「楊建榮的學(xué)習(xí)筆記」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系楊建榮的學(xué)習(xí)筆記公眾號(hào)。