MySQL是世界上最盛行的开源数据库，也是OLTP界的顶流，可是关于OLAP剖析型事务场景的能力太弱。ClickHouse是最近几年数仓OLAP剖析查询范畴的黑马，当红炸子鸡，有意思的是天然兼容MySQL语法。所以许多用户喜爱OLTP放MySQL，OLAP放ClickHouse，中间加一层数据同步，称之为HTAP黄金搭档。
Squids DBMotion是在线数据搬迁SaaS服务，也能够docker run一键式本地化运转。关于MySQL搬迁同步到ClickHouse，供给了结构搬迁/全量初始化/增量同步/数据校验功用支持，并且为实时数据同步供给了精准一致性查询视图。里边一些功用点的设计，能够共享给大家，供参考。
▌全量初始化性能
ClickHouse全量初始化，往往是最耗时的，一般搬迁东西都会选用多线程并发模式去拉取源端数据，然后并发load到方针端，多线程能够是行级并发或表级并发，DBMotion是选用的行级并发，由于假如有一些超大表，表级并发会受限于这些大表，咱们处理的流程大致如下：
- dbmotion核心模块会设定搬迁使命的工作线程数，表数据切片行数split-rows，fetch批次大小等装备
- 每张表，依据总行数，split-rows估算出切片数量，依据PK/唯一键或时间/数据字段，核算每个分片的where鸿沟，终究会获得一张切片list
- 将切片均匀分发给多线程去消费，每个线程负责这个切片的数据拉取和数据装载，直到一切切片都完成
一般咱们切片大小设置为50000行，假如是超小表不足一个切片，这个线程会马上完成，再处理其他切片，通过实践测试，每个线程的处理工作是比较均匀的，吞吐量根本能够打满主机网卡（出产留意流控）。
▌全量断点续传
只说增量需求断点续传，现在全量也要断点续传？其实这个需求是非常合理的，比如说一张表有5千万行，我初始化了4995万行的时分，机器网络抖了下，失败了，就差这5万行了，难道从头来一遍？
写过SQL的知道，游标fetch数据时，你是不知道他具体到了表的哪一行的，从头查询是没法从断点开始的。不过得益于全量切片的并发设计，咱们保存了每一个切片的元数据，关于切片数据同步的行数，状况做了异步刷新。当一个搬迁使命从头运转时，能够只处理失败的切片。由于切片粒度一般是50000行以内，少量失败切片处理起来会非常快，这个根本类似故障的断点续接了。
▌ClickHouse增量同步
MySQL增量数据的获取都是基于binlog event解析，依据他的前印象后印象，凑集同步SQL，中间引进并发线程消费，操控好进展位点，DDL对齐，操作幂等，根本不会有什么问题。可是这套方法换到ClickHouse就很成问题，由于ClickHouse的常用存储引擎是LSM结构的MergeTree，而且是列存储，适合大批量插入，不适合update和delete。
你看他的update句子都是alter xxx update xxx = xxx,这种反常态的语法，骨子里便是要你别更新，别删去。而MySQL的增量数据，便是离散的I/U/D，没法操控的。假如硬套上ClickHouse的DML语法，同步性能是暴差的，也会引起许多无谓的part合并，所以咱们是结合ClickHouse的ReplacingMergeTree处理了这个问题。
- binlog解析的一切数据，无论是u/d/i，都凑集成insert句子，新增版别和event类型两个隐含字段，一切的DML都是以插入方法抵达CK，恰当的积累下批量，性能指标会很不错
- 同一行数据，会由于更新删去而发生多行数据，ReplacingMergeTree的分区合并会自动滤重，保存最新版别的数据，而这个版别号是咱们依照事务操作的次序投进进来的，合乎逻辑
- D类型的数据，DBMotion会有后台使命异步批量处理
- 假如要运用partition分区，需求留意一点，ReplacingMergeTree只能确保一个分区内的合并去重，多分区需求确保分区维度和主键维度的一致性，不然终究结果会是重复的
▌查询一致性
关于上述通过增量同步的表，假如事务需求运用，还是得写段SQL的，重复数据，取其中版别最大的一条，并过滤掉Delete类型的数据。假如每张表你都要套这么大的SQL，会很麻烦，在此DBMotion会自动为同步表供给了查询视图，信任ClickHouse强悍的核算能力，处理这种剖析函数，是so easy的。
▌最快的ClickHouse数据装载姿态
MySQL到CK，只是剖析数据的冰山一角，许多页面、事情、日志、用户行为数据才是最大量的。要知道CK的主业，是依据剖析师的模型跑大SQL，数据装载入库是无可奈何的副业。CK为这个副业也是绞尽脑汁，供给了许多方法。最有意思的当属clickhouse-local，官方文档对这个东西的解释是你无需装置发动clickhouse server端，仅仅用clickhouse-local就能够解析处理本地文件，它和clickhouse server有相同的核心。
咱们能够看看下面的示例：
echo "1\t2023-4-21\n2\t2024-12-04\n3\t2025-9-07"| \clickhouse-local -S "id Int64,thetime String" -N "cktable" -q "CREATE TABLE cklocal (id Int64,thetime Date) ENGINE = MergeTree() \PARTITION BY toYYYYMM(thetime) ORDER BY id;\INSERT INTO TABLE cklocal SELECT id,thetime FROM cktable;" --path /mydir
然后看看/mydir下出现了什么：
# ls -l /mydirtotal 0drwxr-xr-x. 4 root root 34 Apr 20 14:52 datadrwxr-xr-x. 4 root root 150 Apr 20 14:52 metadatadrwxr-xr-x. 3 root root 17 Apr 20 14:52 storedrwxr-xr-x. 2 root root 6 Apr 20 14:52 user_defined
clickhouse-local能够直接将输入数据生成clickhouse server能够识别的数据文件，而这些数据文件挂载到server端，是直接能用的。
依照这个思路，咱们能够将clickhouse-local分发给运用端，由他们事先生成好数据文件。这样算力耗费就涣散在众多的事务机器，而不是服务端。后面再将这些文件，依照一定的规矩上传copy到server端并挂载，然后实现了海量数据的快速装载。
从小编的运用经验看，clickhouse的内功是适当不错的，丰厚的存储引擎，高压缩列存，数据预处理，强壮的功用函数，爆表的性能等等，但外功就不是一般的差劲。运维办理一个多副本，分布式集群还是要花适当的功夫的，数据扩容伸缩也很原始。假如这些短板一向存在，后续被rockstar反超应该不会太久。最后来句硬广：上squids.cn，品全网ZUI贱价数据库云服务，也包括ClickHouse哦！
更多内容请关注“云原生数据库”
