眾所周知，MySQL 的用戶群體很大，為了能夠增強數據的實時性，很多解決方案會利用 binlog 將數據寫入到 ClickHouse。

為了能夠監聽 binlog 事件，我們需要用到類似 canal 這樣的第三方中間件，這無疑增加了系統的復雜度。

在不久的將來，這一現狀可能會發生改觀。因為目前，編號 10851 的 PR 進入了 review 階段。

(https://github.com/ClickHouse/ClickHouse/pull/10851)

該 PR 將為 ClickHouse 帶來原生消費 binlog 日志的能力，是不是王炸功能?

這次是新增了一個名為 MaterializeMySQL 的 database 引擎，該 database 能映射到 MySQL 中的某個 database，并自動在 ClickHouse 中創建對應的 ReplacingMergeTree。

MaterializeMySQL 同時支持全量和增量同步，在 database 創建之初會全量同步 MySQL 中的表和數據，之后則會通過 binlog 進行增量同步。

MaterializeMySQL database 為其所創建的每張 ReplacingMergeTree 自動增加了 _sign 和 _version 字段。

其中，?_version 用作 ReplacingMergeTree 的 ver 版本參數，每當監聽到 insert、update 和 delete 事件時，在 databse 內全局自增。而?_sign 則用于標記是否被刪除，取值 1 或者 -1。

目前 MaterializeMySQL 支持如下幾種 binlog 事件:

MYSQL_WRITE_ROWS_EVENT

_sign?= 1，_version?++

MYSQL_DELETE_ROWS_EVENT

_sign?= -1，_version?++

MYSQL_UPDATE_ROWS_EVENT

新數據?_sign = 1

MYSQL_QUERY_EVENT

支持 CREATE TABLE 、DROP TABLE 、RENAME TABLE等。

雖然該 PR 目前還沒有被 merge 到主線，但是我已忍不住想要嘗鮮，接下來就讓我們一睹它的芳容吧。

首先準備一個 MySQL 實例

#拉取鏡像docker pull mysql:5.7.31#運行鏡像docker?run?-p?3306:3306?--name?mysql5.7?-v?{your-path}/mysql/conf:/etc/mysql?-v?{your-path}/mysql/logs:/logs?-v?{your-path}/mysql/data:/var/lib/mysql?-e?MYSQL_ROOT_PASSWORD=root?-d?mysql:5.7.31

確保?MySQL 開啟了 binlog 功能，且格式為 ROW

#conf/my.cnfserver-id=1# Uncomment the following if you want to log updateslog-bin=mysql-bin# binary logging format - mixed recommended#binlog_format=mixedbinlog_format=ROW

現在開始測試，首先在?MySQL 中創建數據表并寫入數據

CREATE TABLE `t_organization` (`id` int(11) NOT NULL AUTO_INCREMENT,`code` int NOT NULL,`name` text DEFAULT NULL,`updatetime` datetime DEFAULT NULL,PRIMARY KEY (`id`),UNIQUE KEY (`code`))?ENGINE=InnoDB;INSERT?INTO?t_organization?(code,?name,updatetime)?VALUES(1000,'Realinsight',NOW());INSERT?INTO?t_organization?(code,?name,updatetime)?VALUES(1001,'Realindex',NOW());INSERT INTO t_organization (code, name,updatetime) VALUES(1002,'EDT',NOW());

繼續創建第二張表

CREATE TABLE `t_user` (`id` int(11) NOT NULL AUTO_INCREMENT,`code` int,PRIMARY KEY (`id`))?ENGINE=InnoDB;INSERT?INTO?t_test?(code)?VALUES(1);

現在輪到 ClickHouse 這邊了，創建??MaterializeMySQL?數據庫

CREATE DATABASE test_binlog ENGINE = MaterializeMySQL('127.0.0.1:3306','htap','root','root');

其中 4 個參數分別是 MySQL地址、databse、username 和 password。

執行之后可以觀察一下它執行日志

2020.07.2020.07.29 01:29:53.571991 [ 868116 ] {} executeQuery: (internal) /*Materialize MySQL step 1: execute MySQL DDL for dump data*/ EXTERNAL DDL FROM MySQL(test_binlog, htap) CREATE TABLE `t_organization` ( `id` int(11) NOT NULL AUTO_INCREMENT, `code` int(11) NOT NULL, `name` text, `updatetime` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `code` (`code`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf82020.07.29?01:29:53.577595?[?868116?]?{}??executeQuery:?(internal)?/*?Rewritten?MySQL?DDL?Query?*/?CREATE?TABLE?test_binlog.t_organization?(`id`?Int32,?`code`?Int32,?`name`?Nullable(String),?`updatetime`?Nullable(DateTime),?`_sign`?Int8,?`_version`?UInt64)?ENGINE?=?ReplacingMergeTree(_version)?PARTITION?BY?intDiv(id,?4294967)?ORDER?BY?(code,?id)

可以看到，ClickHouse dump 出了 MySQL 的表結構，并將其轉換成了 ReplacingMergeTree。

在這個過程中，不僅各字段的數據類型進行了映射，還多出了?_sign 和 _version 兩個字段。

MySQL 表的?PRIMARY KEY?作為了?ReplacingMergeTree?的?PARTITION?BY，并且按照類型大小除以1000整除;

MySQL 表的? PRIMARY KEY 同時也作為了 ReplacingMergeTree 的 ORDER BY，如果 MySQL 表中還有 UNIQUE KEY (此例中的 code 字段)，它也會一同被加入到 ORDER BY。

現在我們查詢 ClickHouse 的?test_binlog 數據庫

use test_binlog;show?tables;┌─name───────────┐│ t_organization ││ t_user │└────────────────┘

MySQL 的表已經被同步過來了，接著試試查詢數據

select * from t_organization;SELECT *FROM t_organization┌─id─┬─code─┬─name────────┬──────────updatetime─┐│ 1 │ 1000 │ Realinsight │ 2020-07-28 17:29:47 │└────┴──────┴─────────────┴─────────────────────┘┌─id─┬─code─┬─name──────┬──────────updatetime─┐│ 2 │ 1001 │ Realindex │ 2020-07-28 17:29:48 │└────┴──────┴───────────┴─────────────────────┘┌─id─┬─code─┬─name─┬──────────updatetime─┐│ 3 │ 1002 │ EDT │ 2020-07-28 17:29:49 │└────┴──────┴──────┴─────────────────────┘3 rows in set. Elapsed: 0.032 sec.

接下來進一步測試 binlog 的同步功能。

首先在 MySQL 中修改數據:

update t_organization set name = CONCAT(name,'-v1') where id = 1

查看 ClickHouse 日志會發現 binlog 監聽事件:

=== UpdateRowsEventV2 ===Timestamp: 1595958048Event Type: 31Server ID: 1Event Size: 93Log Pos: 20454Flags: 0Schema: htapTable: t_organizationRow[0]: (1, 1000, 'Realinsight', 1595928587)Row[1]: (1, 1000, 'Realinsight-v1', 1595928587)

查詢?ClickHouse 的數據表:

select?*?from?t_organization;┌─id─┬─code─┬─name───────────┬──────────updatetime─┐│ 1 │ 1000 │ Realinsight-v1 │ 2020-07-28 17:29:47 │└────┴──────┴────────────────┴─────────────────────┘┌─id─┬─code─┬─name──────┬──────────updatetime─┐│ 2 │ 1001 │ Realindex │ 2020-07-28 17:29:48 │└────┴──────┴───────────┴─────────────────────┘┌─id─┬─code─┬─name─┬──────────updatetime─┐│ 3 │ 1002 │ EDT │ 2020-07-28 17:29:49 │└────┴──────┴──────┴─────────────────────┘

可以看到 id = 1的數據被修改了。

現在再次回到 MySQL，嘗試刪除數據:

DELETE FROM t_organization where id = 2

回到 ClicKHouse，同樣會發現 DeleteRows?的 binlog 監聽事件:

=== DeleteRowsEventV2 ===Timestamp: 1595958230Event Type: 32Server ID: 1Event Size: 60Log Pos: 20744Flags: 0Schema: htapTable: t_organizationRow[0]: (2, 1001, 'Realindex', 1595928588)

查詢 ClickHouse的?t_organization:

select * from t_organization;SELECT *FROM t_organization┌─id─┬─code─┬─name───────────┬──────────updatetime─┐│ 1 │ 1000 │ Realinsight-v1 │ 2020-07-28 17:29:47 │└────┴──────┴────────────────┴─────────────────────┘┌─id─┬─code─┬─name─┬──────────updatetime─┐│ 3 │ 1002 │ EDT │ 2020-07-28 17:29:49 │└────┴──────┴──────┴─────────────────────┘

id = 2 的數據被刪除了。

這是怎么實現的呢? ?在剛才的查詢中增加 _sign 和 _version 虛擬字段，一切將會真相大白。

select?*,_sign,_version?from?t_organization?order?by?_sign?desc,_version?descSELECT*,_sign,_versionFROM t_organizationORDER BY_sign DESC,_version DESC┌─id─┬─code─┬─name───────────┬──────────updatetime─┬─_sign─┬─_version─┐│ 1 │ 1000 │ Realinsight-v1 │ 2020-07-28 17:29:47 │ 1 │ 2 │└────┴──────┴────────────────┴─────────────────────┴───────┴──────────┘┌─id─┬─code─┬─name────────┬──────────updatetime─┬─_sign─┬─_version─┐│ 1 │ 1000 │ Realinsight │ 2020-07-28 17:29:47 │ 1 │ 1 ││ 2 │ 1001 │ Realindex │ 2020-07-28 17:29:48 │ 1 │ 1 ││ 3 │ 1002 │ EDT │ 2020-07-28 17:29:49 │ 1 │ 1 │└────┴──────┴─────────────┴─────────────────────┴───────┴──────────┘┌─id─┬─code─┬─name──────┬──────────updatetime─┬─_sign─┬─_version─┐│ 2 │ 1001 │ Realindex │ 2020-07-28 17:29:48 │ -1 │ 3 │└────┴──────┴───────────┴─────────────────────┴───────┴──────────┘5 rows in set. Elapsed: 0.048 sec.

在查詢時，對于已經被刪除的數據，ClickHouse 會自動重寫 SQL，將?_sign = -1 的數據過濾掉;

對于修改的數據，則自動重寫 SQL，為其增加 FINAL 修飾符。

select?*?from?t_organization等同于select?* from?t_organization?final where _sign = 1

在 20.5 版本中，final 查詢已經支持多線程，性能有很大的提升。

大家應該會發現，目前在 ReplacingMergeTree 中被刪除的數據只是被過濾掉了，并沒有物理刪除。經與作者大神 zhang2014 咨詢，將來會通過類似 GC 的思路通過另外的線程定期刪除 _sign = -1 的數據。

這項功能如果被 merge 進主線，無疑會增強 ClicKHouse 更加自動化的屬性。

如果這篇文章對你有幫助，歡迎點贊、轉發、在看三連擊 :)

歡迎大家掃碼關注我的

公眾號和視頻號

:

ClickHouse的秘密基地

nauu的奇思妙想

往期精彩推薦:

總結

以上是生活随笔為你收集整理的clickhouse 增量更新_ClickHouse王炸功能即将来袭?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。