之前的项目，核心 DB 用的都是 CK ，说实话，已经有些玩腻了，这一次，我决定把这部分数据，给迁到 Doris ，然后在它身上，做大做强。

（PS：当前 CK 版本为 25.x，Doris 版本为 2.1.2）

根据我以往的经验，以及问过 AI 之后，可行的方案有 3 个：

利用 Doris 的 clickhouse catalog + insert into ... select * from 的方式；

先把 CK 每张表的数据给导出成文件，再利用 Doris 支持的 Broker Load 或者 Stream Load，把数据写入到 Doris 表里；

利用 Spark 引擎，读 CK 里面的每一张表数据，然后写入到 Doris 目标表里。 

其中方案1、2是 AI 跟我都想到的，根据之前的实测经验，方案1最简单且高效，但 bug 最多。

方案2需要分两步走，麻烦一些，但效率也不错，bug 比方案1更少。

方案3是我认为最靠谱，最健壮的方式，也是被我验证了无数次的方案，但因为需要编码，跟额外的计算资源，所以最麻烦。  

那么接下来，我们就逐个验证这些迁移方式(验证1跟2)，看哪个最靠谱？

先说结论：不靠谱。

这里的不靠谱，并不完全不行，而是——对于 CK 的表类型来说，「小本地表」可以，但所有的「分片表」，以及「大本地表」就不行了。

具体玩法是这样的：

首先，在 Doris 创建 CK 的catalog：

CREATE CATALOG `jdbc_clickhouse01` PROPERTIES ("user" = "default","type" = "jdbc","password" = "***","jdbc_url" = "jdbc:clickhouse://192.168.xxx.xxx:8123","driver_url" = "clickhouse-jdbc-0.4.6-all.jar","driver_class" = "com.clickhouse.jdbc.ClickHouseDriver");

然后，切换 catalog ，就可以看到对应的表了。

本来以为这样，就可以很简单的通过 insert into... select * from... 的方式把数据给迁移过去。

然而，在实际验证的时候，这种情况只对「本地小表」有效。

具体多小呢？来看这个：

mysql> select count(*) from local_small_table01;+----------+| count(*) |+----------+|      225 |+----------+1 row in set (0.20 sec)
mysql> insert into internal.doris_db.local_small_table01 select * from `jdbc_clickhouse01`.`ck_db`.target_table01;Query OK, 225 rows affected (0.35 sec){'label':'insert_24c4e07f37914f96_8bcb5272c042236b', 'status':'VISIBLE', 'txnId':'13429378'});

这是可以的。

但同样是本地表，如果数据量再大一些，比如千万级别，就不行了。

关键，连查询都不行：

mysql> select count(*) from `jdbc_clickhouse01`.`ck_db`.local_big_table02;ERROR 1105 (HY000): errCode = 2, detailMessage = (192.168.xxx.xxx)[CANCELLED]UdfRuntimeException: jdbc get block address: CAUSED BY: IndexOutOfBoundsException: Index: 0, Size: 0

至于这个错什么意思，以我现在的水平，确实看不懂(这个表都是些简单字段类型)。

而至于「分片表」，甭管数据量大小，都不行，报的错跟上面一样。

所以目前为止，我只能拿它迁移了几张小表(具体的数据量上限，我没来得及测)。

相比方案 1，这个方案要复杂一些，需要分为 2 步。

先把 CK 的目标表导出成文件。

CK 官网支持的导出文件格式有：CSV、TSV、JSON、Parquet 等。

CK 支持的导出数据格式

但因为导出的数据文件，最终还需要再次写入到 Doris，所以这个格式，还必须得是 Doris 支持导入的。

为了方便，这里优先用 Doris 的 stream load。

Doris 支持的导入数据格式

虽然支持的也比较丰富，但经过我的实测，最简单，性价比最高的导出导入方式是这样的。

CK 端：采用 TSV 的导出方式——也就是 tab 键(\t)分割的 CSV。

比如像这样：

clickhouse-client --query="SELECT * FROM ck_db.ck_big_table FORMAT TSV" > /tmp/ck_big_table.tsv

然后，把这个文件，统一挪到 Doris 的客户端节点。

Doris 端：指定分隔符为 \t，采用 CSV 的导入方式。

比如像这样：

[root@hdp01 ~]# curl --location-trusted -u doris_user:**** -H "label:label01" -H "column_separator:\t" -T ck_big_table.tsv http://192.168.xxx.xxx:8030/api/doris_db/ck_big_table/_stream_load{    "TxnId": 13429556,    "Label": "label01",    "Comment": "",    "TwoPhaseCommit": "false",    "Status": "Success",    "Message": "OK",    "NumberTotalRows": 1406520,    "NumberLoadedRows": 1406520,    "NumberFilteredRows": 0,    "NumberUnselectedRows": 0,    "LoadBytes": 1290174219,    "LoadTimeMs": 11456,    "BeginTxnTimeMs": 1,    "StreamLoadPutTimeMs": 10,    "ReadDataTimeMs": 7769,    "WriteDataTimeMs": 11165,    "CommitAndPublishTimeMs": 279}

这里之所以没用「,」号分割(正规的 csv)，在于某个字段里面的数据，本身就有很多逗号，会导致数据入库的时候产生错乱。

至于为什么没有采用 json 或者其他格式，原因在于——需要在命令行额外添加对应表的 schema，太麻烦(其实也说明 Doris 这块没做好)。

从最终入库效果来看，暂时没发现问题。

而至于效率，无论是 CK 的导出，还是 Doris 的导入，都非常快。

我大概测了一下，1.4kw 的数据量，CK 的导出时间为 2 秒不到。

而 Doris 利用 stream load 的导入，也只有不到 20 秒。

可能有同学会觉得，这样一张一张蚂蚁搬家似的迁移，是不是有点繁琐？

目前对于这种「异构」DB 之间的迁移来说，想要迁移后的效果好，以我的经验来看，确实没有特别高效的，现成的办法(除非你定制开发一个)。

比较保守的做法，就只能是先在 Doris 端，根据 CK 的表结构跟字段类型特点，挨个建对应的表。

然后，再通过 CK catalog + Doris stream load 组合拳的方式，把每张大大小小的表数据，给折腾进去(对于部分复杂字段的表，可能后续还得用上 Spark)。

还是那句话，理论上说行的，真刀真枪玩起来的时候，不一定就真的行，对于这种生产库的数据迁移问题，我就没见过谁，可以用一种「既高效、又简单、还优雅」的方式能一招鲜吃遍天的，大家都是通过「多种策略组合」才能最终把问题搞定。

最后，对于这个 CK 迁移 Doris 的方案，你怎么看？