ClickHouse無疑是目前最火的OLAP解決方案，筆者所在的運維團隊，ClickHouse的數量近兩年增長迅猛。
最近老板安排了一個任務，要求我調研現在MySQL到ClickHouse的同步工具，方便后面將線上的在線OLTP數據實時同步給線下的OLAP ClickHouse，這樣業務人員和運營人員基于它進行統計查詢更直觀快速。
目前，市面上的相關工具和產品，主要分為三類：
ClickHouse原生提供的MySQL同步工具
命令行式的MySQL to ClickHouse同步工具
界面引導式的MySQL to ClickHouse同步工具
ClickHouse 官方提供了MaterializedMySQL的同步復制工具，它會獲取MySQL的binlog，并重放DDL和DML。但是這個特性沒有release，官方文檔用醒目的字體顯示“This is an experimental feature that should not be used in production.”不能用在生產環境中，并且看代碼也有一段時間沒有更新了。
測試結果如下：
在MySQL上創建一個表。
mysql> create database db1; mysql> create table test1 (a INT PRIMARY KEY, b INT);
在ClickHouse上新建MaterializeMySQL的表。
0571-87770835 ## 這里要專門設置以便clickhouse能使用這個特性
ck> set allow_experimental_database_materialize_mysql=1;
## 這里創建連接到user@192.168.1.17:3306/db1的database連接，命名為db1_ck
ck> CREATE DATABASE db1_ck ENGINE = MaterializeMySQL('192.168.1.17:3306', 'db1', 'user', '***');
## 進入db1_ck這個數據庫
ck> use db1_ck;
## 查看db1_ck庫下的表，可以看到test1這個表
ck> show tables;查看test1這個表在ck上的表結構。
ck> show create table test1; CREATE TABLE db1_ck.test1 ( `a` Int32, `b` Nullable(Int32), `_sign` Int8 MATERIALIZED 1, `_version` UInt64 MATERIALIZED 1, INDEX _version _version TYPE minmax GRANULARITY 1 ) ENGINE = ReplacingMergeTree(_version) PARTITION BY intDiv(a, 4294967) ORDER BY tuple(a) SETTINGS index_granularity = 8192
test1表使用的是ReplacingMergeTree引擎，表結構新增了兩個字段_sign和_version作為隱藏字段，用于標識該行是否刪除和版本號。這樣將MySQL的update和delete統一轉換成insert，充分利用ClickHouse快速導入數據、update和delete慢且容易出問題的特性。內部實現原理的細節和好處，我們將在另外一篇文章里面介紹。
在MySQL上操作，看數據會不會同步到ClickHouse上。
mysql> insert into test1 values (1,11),(2,22),(3,33); mysql> update test1 set b=77 where a=1; mysql> delete from test1 where a=2; ck> select * from db1_ck.test1; ┌─a─┬──b─┐ │ 1 │ 77 │ │ 3 │ 33 │ └───┴────┘
可以看到，數據基本都正確地同步到ClickHouse上去了。
這一類是利用命令行來實現MySQL同步到ClickHouse的工具，例如Altinity的clickhouse-mysql-data-reader工具，這個工具也可以實現DML的數據同步。但是安裝和命令行使用太麻煩，而且這個工具2020年就不再更新了，所以此次沒有進一步深入研究。
有獨立的web界面來實現MySQL同步到ClickHouse，用戶體驗更方便。類似的國內產品有很多，從簡單性和穩定性來說，個人偏向于DBMotion。下面就以DBMotion的線上版本為例，介紹一下界面引導式MySQL to ClickHouse的遷移。
遷移任務配置和查看
首先，進入DBMotion的頁面，點擊免費使用。
https://squids.cn/product/dbmotion
登錄DBMotion的任務列表頁面。
https://console.squids.cn/console/transfer
單擊“添加任務”按鈕，進入“源端目標庫配置”。
為方便展示，這里選擇的是在公網ECS上創建的MySQL和ClickHouse。
注意：這里的源庫與目標庫的用戶、權限，建議按照授權語句的要求，在源庫和目標庫新建用戶，否則后面的預檢查和遷移有可能會失敗。遷移完成后，就可以將源端和目標端的用戶刪除。
點擊“測試連接以進行下一步”，進入“遷移選項配置”頁。
這里可以展開選擇你要同步的表，選擇并發數和遷移哪些MySQL的表到目標端。
最后，用戶確認配置并進行預檢查。
這一步可以看到用戶選擇的是哪些內容，而且預檢查會提前發現一些可能導致遷移失敗的問題 。
這個確認頁面內容豐富，涵蓋了源庫、目標庫和要遷移的對象的信息。還會主動預檢查所有可能導致遷移失敗的點，出現問題時會發出提醒，并給出修復建議，是一個比較方便的功能。
能看到新建任務成功，點擊任務就可以進入任務詳情頁面 。
在任務配置頁面，可以看到這次遷移同步任務的源庫、目標庫和遷移對象信息，之前的預檢查信息也可以在這里回顧。
遷移詳情主要包括“對象遷移”、“全量遷移”、“增量遷移”和“數據校驗”。
對象遷移。
以這兩個測試表為例，將對象同步過去的速度是比較快的。對象遷移，DBMotion具體同步的內容，我們看目標庫上的表和數據的時候可以看到。
全量遷移。
兩個表的數據不多，同步的速度較快。
這里每個步驟都有遷移進度、遷移速度、已遷移時間、預計剩余時間，對于遷移的進展和大概需要多少時間，一目了然。
增量遷移。
記錄了同步的binlog位點信息。
數據校驗。
這個功能是其他相關產品沒有的功能，會校驗MySQL和ClickHouse的表和數據。對于需要精確匹配的遷移來說，是一個很實用的功能。
結束遷移。
結束遷移是為了關閉增量，保證遷移完成以后，就可以結束遷移了。
任務日志。
在遷移報錯的時候，用來檢查到底是哪個環節出現了問題。
總體來看，這個操作是比較簡單的。只需要配置好源端、目標端和遷移對象，它就會幫你創建好遷移任務。任務展示頁面也比較清晰明了，同步了哪些內容，數據是否一致都有比較好的展現。
接下來，我們來看它的實際遷移結果。
全量遷移
源庫表結構。
源庫上test_grant1.test1表的表結構如下：
目標庫結構。
遷移完成后，在目標庫里看，DBMotion新建了兩個schema，test_grant1和test_grant1_ck，并分別在這兩個schema下新建了test1_ck表和test1表，對應的表結構如下：
這一步，DBMotion應該是參考ClickHouse原生解決方案MaterializedMySQL來實現的。解釋一下：
test_grant1_ck.test1_ck是ReplacingMergeTree的表，除了a、b兩列以外，還有__version@@和__event_type@@，對應version和sign兩個字段。
為了方便用戶使用，在目標庫上專門新建了test_grant1.test1的視圖，讓用戶查詢的時候，看到的數據和源庫一致。
增量遷移。
我們測試了一下在源庫上做增刪改的操作，在目標庫上查看同步效果，發現同步延遲基本在秒級別，同步的數據也完全一致。
源庫增刪改查。
目標庫查看數據。
這里可以明顯看到，test_grant1_ck.test1_ck中記錄的是源庫做的所有DML操作，通過視圖合并后，test_grant1.test1查詢出來的數據跟源庫一模一樣。
PS：B站上有一個DBMotion的介紹視頻，不喜歡看文字的，可以看這個視頻了解一下它的安裝和使用方式。
總結
MySQL to Clickhouse，目前有ClickHouse原生提供的同步工具、命令行同步工具和界面指引型同步工具。原生的工具暫時不能用在生產環境，命令行工具使用起來比較繁瑣，界面型相對簡單易用。
界面型同步工具中，DBMotion相對比較直觀簡單。
這些工具對DDL、無主鍵表都有一些限制，這些問題我將在另外一篇文章里面詳細描述。
服務電話： 400-678-1800 （周??周五 09:00-18:00）
商務合作： 0571-87770835
市場反饋： marketing@woqutech.com
地址： 杭州市濱江區濱安路1190號智匯中?A座1101室
