CloudCanal x OceanBase 資料遷移同步優化

簡述

CloudCanal 去年支援 OceanBase 資料遷移同步能力後，随着使用使用者增多以及問題回報，近期對該能力進行了一輪較大規模的優化。

本篇文章簡要介紹這些優化點，以及未來該能力的演進方向。

優化點

大幅提升同步性能

CloudCanal 目前使用 OceanBase LogProxy 做增量資料訂閱，使用方式相對簡單明了。

@Override
public void notify(LogMessage message) {
    try {
        ParsedEntry entry = msgConvertor.convertMsgToEntry(message);

        if (entry == null) {
            return;
        }

        instance.getEventStore().put(entry);
    } catch (Exception e) {
        String msg = "parse ob msg failed.msg:" + ExceptionUtils.getRootCauseMessage(e);
        log.error(msg, e);
        throw new LogProxyClientException(ErrorCode.E_PARSE, msg);
    }
}           

消息解析對性能影響相對小，攢批 和 對端寫入方式 影響更大。

攢批方面，我們将變更事件寫入記憶體隊列後，按照 個數/容量門檻值(increBatchSize) 或 逾時時間(fetchFromBrokerTimeoutMs) 刷出，提升批量寫入的粒度。

對端寫入方式，根據不同資料源，我們采用了 batch 、multisql 、 并行 、 upsert 等技術提升寫入效率。

統一各類表全量掃描方式

全量資料掃描 是 CloudCanal 全量資料遷移(或資料初始化)重要組成部分，需滿足 性能優秀（2KB/record,>= 100k records 掃描速率）、可斷點續傳、可預測進度、表相容性好 的要求。

其中前三者是業務要求，最後一種是盡可能滿足前三者的前提下，做到更多表的相容。

CloudCanal 碰到的"表"包含以下類型 - 關系型資料庫 - 無/單/多主鍵 - 各種類型主鍵(整型/浮點/日期/二進制等) - 差異值主鍵(有/無符号，null值/空值，超長值) - 各種類型分區 - 差異資料量(1萬，100萬，1000萬，1億，10億，100億) - 實體表/視圖/臨時表 - 消息中間件 - 各種命名規範 - 無/有分區 - 順序/非順序 - 文檔資料庫 - 規範/非規範(schemaless) - 無/有行業規範格式(ObjectId) - 緩存資料庫 - 搜尋引擎

CloudCanal 全量資料掃描主要面向關系型資料庫，性能要求、斷點續傳能力、進度預測能力都基于主鍵展開。

此次優化，我們做了如下幾方面工作，統一了掃描邏輯，并且讓無/單/多主鍵、各種類型主鍵、分區表都可斷點續傳 - 以主鍵、分區作為斷點續傳位點 - 掃描語句加入分區指定(如有)、元組比較(單/多主鍵)、按元組排序、指定分頁數等部分 - 對比位點最大值、掃描行數方式判定掃描是否結束

此外，各個資料源可根據自身差異性，可擴充掃描語句、最大最小位點值擷取邏輯、連結自定義(設定逾時等)、執行語句上下文自定義(設定fetchSize等)。

支援全局索引表

全局二級索引（GLOBAL）對分布式資料庫有着非常重要的作用，它讓原本 多分區資料檢索 操作 弱化成單分區檢索，加速不同次元點查響應，提升 QPS。

對于 OceanBase 對端寫入，CloudCanal 預設采用關系型資料庫 INSERT IGNORE/ON DUPLICATE KEY UPDATE 規避主鍵/唯一鍵沖突。

但是對于帶有 GLOBAL 索引的表，OceanBase 不支援 INSERT IGNORE 操作，是以此次優化，我們寫入 OceanBase 的 INSERT 操作預設改為 ON DUPLICATE KEY UPDATE (REPLACE)。

異構 DDL 同步轉換優化

從異構資料庫同步 DDL 到 OceanBase，我們優化成白名單模式。

如 MySQL 到 OceanBase DDL 同步，預設支援 - ALTER TABLE xxx ADD/DROP/MODIFY COLUMN - CREATE INDEX - RENAME TABLE

優化同時去除了 ALTER TABLE xxx CHANGE COLUMN、AFTER/BEFORE 等 OceanBase 現階段不支援的語句。

此項能力随着 OceanBase 産品能力的進化而不斷豐富。

解決時間戳自更新問題

對于類似 gmt_create datetime/timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 時間字段定義，當源端該字段值變化區間小于時間精度（被程式判定未變化），并且寫入對端并非采用 upsert 方式（精确字段更新），那麼該字段資料将不一緻。

CloudCanal 在精确字段更新模式下，預設将時間字段置為更新狀态，確定将源端值帶到對端，解決不一緻的問題。

演進方向

OceanBase 商業級增量元件相容

OceanBase 商業版 OMS 的資料訂閱能力有别于目前社群版的 LogProxy，如 OceanBase 官方逐漸擴大其使用面，CloudCanal 将第一時間跟進相容。

更快的資料校驗和訂正能力

分布式資料庫相對單機資料庫，單表資料量大幅度增加（億級表相當常見），資料校驗和訂正性能相比資料初始化，更加依賴資料掃描的性能，為此，CloudCanal 将開放 單表分片/分區并行掃描 的能力。

更強的結構遷移和 DDL 同步能力

大表 通用/特殊化分區 是常見操作，目前 CloudCanal 對表分區的結構遷移并未有效支援，這種分區的結構遷移，對于同構資料庫相當必要。後續，我們将提供 分區資訊的結構遷移。

更多的資料源生态支援

以 OceanBase 為源端資料遷移同步，目前支援 MySQL、StarRocks、OceanBase、Kafka 對端，我們希望後續如 Redis、ElasticSearch、Doris、Hudi 等資料源也能加入到這個目标資料源中。

總結

本文主要介紹了 CloudCanal 在過去一段時間對 OceanBase 資料遷移同步能力的優化,進而是這個能力具備更強的性能、更好的相容性、更加穩定的資料遷移同步表現。