支撑700亿数据量的ClickHouse高可用架构实践

讲师介绍：蔡岳毅，携程旅行网酒店研发中心高级研发经理，资深架构师，负责酒店大住宿数据智能平台，商户端数据中心以及大数据的创新工作。

大家好，我是来自携程的蔡岳毅，今天给大家分享 ClickHouse 在我们大数据平台的应用，主要从应用的角度来介绍我们的高可用架构。其实这个百亿，我没太纠结，来之前我查了一下，现在我的平台上面是将近 700 亿数据，压缩前是 8T，存储是压缩后 1.8T。以前我认为大数据要给用户提供更好的体验都要靠分布式的大量铺机器才能换得更好的性能，但 ClickHouse 的出现，改变了我的看法。

今天也是主要分享我们如何合理的利用好 ClickHouse，如何合理的利用硬件资源，根据我们的数据量、应用场景以及合理的架构来支撑我们的数据量和使用场景，为用户提供更好体验的大数据平台。当前根据我们的积累主要是十台物理机的 ClickHouse 支撑，当然，我也评估过数据量再翻个倍，除了 SSD 存储空间需要扩容，CPU 和内存不会成为我们的瓶颈。

我今天主要从这几个方面给大家分享一下 ClickHouse，为什么选择 ClickHouse？我们在实际应用中的一个高可用架构，最后就是给大家介绍 ClickHouse 的一些优点，还有现在 ClickHouse 的一些问题和我们对未来的一些展望规划。

一、为什么选择 ClickHouse

根据实际业务场景需要来选择

1、不固定的查询条件，不固定的汇总维度。

我的数据底层都是基于 Hive，然后我们要给业务提供一个大数据实时计算平台，所以我们的查询条件不固定。比如像酒店，国内、省份、城市、商圈、星级等一堆条件，这样的场景按平时我们用的 SQL 是无法支持的，因为筛选条件太多，我们是不能限制用户必须选择什么条件的，所以 SQL 的索引，左侧原则基本上很难用上。再就是汇总维度，大数据里十个查询至少有八个都可能通过不同方式来 sum 汇总数据，很少有获取明细数据的场景，所以汇总维度也是不固定的。

2、数据量日益增量，每天要更新的数据量也不断增大

我们平台是从近五年开始做的，我们沉淀了各种业务线的报表。其实大家工作中也能发现，我们上线了一个东西无论它价值如何也很难将其下线，所以你必须要去运维它，如果一直沉淀下来，我们的数据量也是越来越大，场景越来越多，维护成本也越来越高。

3、业务场景不断增多，涉及面越来越广。

系统我们是要给各个业务线用的，包括很多都是老板。

4、需要保证高可用并秒出。

如果我们不能保证秒出，那就是我们的技术问题啦。从技术的角度来说，我们要为用户提供一个体验好的产品，也必须要做到秒出。

5、从 SQL、ES、Kylin、Ingite、CrateDB、MongoDB、HBase 不断的研究，实践。

从上面的一些场景，我们研究了很多数据库。

最初我们是用 SQL，2015 年开始做这个平台的时候，其实没有像现在这么多成熟的大数据技术。

大概 2016 年，我开始在部分场景应用 ES，其实这几年 ES 在很多公司里面都有应用，大家也应该比较了解，ES 在搜索上面有很大的优势，速度也是非常快的。特别是对于做大宽表之类的订单查询、搜索产品信息，ES 其实很强，高并发 QPS 上千基本上没问题。

Kylin 也是大数据方面的，其实它是相当于把时间花在它的机器层面提前算好，但是如果我们的维度不固定，建 Cube 的时间会非常长。

Ingite 是内存数据库，我在 2018 年测试过这个数据库，10 台虚拟机是 8 核 24G 内存，性能确实能做到秒级，但是不能支持高并发，并发上来内存就会被打爆，同比 ClickHouse 硬件成本是不划算的，完全基于分布式内存，所以我后面也没有用它。

CrateDB 底层是基于 ES，但 CrateDB 解决了 ES 不能 join 的问题，但是一样的，在高并发的时候一样会把内存打爆，ES 大家应用的时候发现它的语法比较复杂，CrateDB 解决了这个问题，我们可以通过写 SQL 的方式获取数据。

MongoDB 要建一些索引，强依赖左侧原则，当走索引的时候性能确实很好，但我们的搜索条件不固定，无法每次都能靠上索引。

HBase 属于非结构化数据存储的数据库，在实时汇总计算方面也不合适。

ClickHouse 的特点

通过这一系列的实践和对比，最后是在 2018 年 7 月份左右选择了 ClickHouse。我不知道大家对 ClickHouse 的了解有多少，其实它也是这一两年才被国内大部分大厂认可的一个 OLAP 数据库。2018 年我开始在用它的时候，百度上面的资料非常少。它是俄罗斯的一家做搜索引擎的公司开源的列式数据库。

1、优点

1）数据压缩比高，存储成本低。

ClickHouse 最大的特点就是快，其他的比如数据压缩比高、存储成本低等等，所以以前我们有很多的功能埋点都集中在 ES 里面，但是从年初开始到现在应该是把所有的 ES 埋点全部转成 ClickHouse，所以根据 ClickHouse 的数据压缩比，首先就可以评估到我们硬件成本比采用 ES 的方案时它至少降低 60%以上，日志在 ES 和 ClickHouse 上面的查询性能这里就不展开对比。

2）支持常用的 SQL 语法，写入速度非常快，适用于大量的数据更新

它的语法跟 MySQL 比较类似，但是它有一个特点就是它的 join 不能太复杂，A 表 join B 表的时候不能直接 join C 表，需要把 A 表 join B 表的 AS 成一个带别名的临时表以后再去 join C 表，所以它的语法主要还是在 join 上面会比较独特。如果你的查询语句很复杂，你的 join 就会看起来很长，所以查询语句可读性不像 SQL 那么好理解。但是它的写入速度非常快，特别适合于像我们的离线数据每天都是几亿几十亿数据量的更新。官方资料介绍它是按照每秒钟 50-200 兆导入速度。

3）依赖稀疏索引，列式存储，CPU/内存的充分利用造就了优秀的计算能力，并且不用考虑左侧原则

它是依赖稀疏索引，列式存储。我们在去取数据的时候，经常会只取某几个字段，按列存储对 IO 比较友好，减少 IO 的次数，也是在查询速度上一个辅助。再就是它很大程度利用了 CPU，我们都知道 MySQL 是单线程获取数据的，但是 ClickHouse 服务器上面有多少个 CPU，它就会用服务器的一半 CPU 去拉，像我们平时用的 40 核或者 32 核的物理机，基本上拿一半的核去拉数据。当然，这个可以修改配置文件每个 query 用多少 CPU。因为它一个查询需要消耗太多的 CPU，所以在高并发上面是一个短板。当然，我们也不需要考虑什么左侧原则之类的，就算你的查询条件不在索引里面，ClickHouse 的查询一样非常快。

2、缺点

1）不支持事务，没有真正的 update/delete

不支持事务，没有真正的 update/delete，主要还是高并发的短板，所以我们应用都在一些能 Hold 住的场景下。如果对外放在公网，这个 QPS 就可能很难控制，这种场景用 ClickHouse 就要谨慎。

2）不支持高并发，可以根据实际情况修改 qps 相关配置文件

ClickHouse 吃 CPU，可能团队十个人通过执行同一个查询就可以把一台 CPU 40C 的物理机打爆，但是为什么我前面说我们有 700 亿的数据只需要十台物理机就可以扛得住呢？其实我们对 ClickHouse 做了很多保护。

二、ClickHouse 在大数据平台的应用

ClickHouse 在酒店数据智能平台的架构

这是我们实际应用中的架构图，底层数据大部分是离线的，一部分是实时的，离线数据我们现在大概有将近 3000 多个 job 每天都是把数据从 HIVE 拉到 ClickHouse 里面去，实时数据主要是接外部数据，然后批量写到 ClickHouse 里面。我们数据智能平台 80%以上的数据都在 ClickHouse 上面。

应用端在查询的时候中间也有缓存的概念，其实所有的数据我都会通过缓存去过一遍，如果说所有的数据都从 ClickHouse 上拿的话，ClickHouse 的高并发是扛不住的。刚开始我用 ClickHouse 的时候，我们几台物理机每天早上 9 点钟的时候 CPU 会拉到很高，如果 CPU 打到百分之六七十的时候，响应时间就会变慢，这个时候会造成排队查询积压，然后就形成恶性循环，服务器可能就被打挂了，查询也进不来了。

针对这种情况我们对于常用的一些查询进行缓存，具体缓存方案后面我们再展开。

ClickHouse 的全量数据同步流程

因为 ClickHouse 在数据同步的时候对 MySQL 的数据同步是很友好的，就类似于 MySQL 里面一个表的数据导到 temp 表里面去，加一个服务器地址，账号密码就可以了。下图是我们的一个数据同步的流程：

1. 清空A_temp表，将最新的数据从Hive通过ETL导入到A_temp表；
2. 将A rename 成A_temp_temp；
3. 将A_temp rename成 A；
4. 将A_ temp_temp rename成 A_tem。

最初我们的 ETL 工具不支持直接从 HIVE 往 ClickHouse 里面导，所以我们是通过 MySQL，然后我们自己写的程序，由 MySQL 往 ClickHouse 导，后面我们有一个 job 一直在轮询检查 insert into 的这个进程是否完成了。

其实全量的数据同步是很简单的，按我们现在的 ETL 工具也可以做的更简单，可以做到不依赖 MySQL 维表维护，不需要程序 job 来做 rename，我们这样只是为了保持统一的技术方案，因为我后面的增量也是用类似的方式。

以前通过 MySQL 导的时候，几千万数据导入 ClickHouse 的时候不是 1 秒就可以导入完成的，每执行一个 insert 的时候会产生一个进程 ID，如果没有执行完，直接 Rename 就会造成数据丢失，数据就不对了，所以必须要有一个 job 在轮询看这边是不是执行完了，只有当 insert 的进程 id 执行完成后再做后面一系列的 rename。

ClickHouse 的增量数据同步流程

因为我们有大量的单表数据量是超过好几亿的，所以每天的更新是尽量往增量的方式去更新，如果大家都全量更新，再好的服务器也会被我们拉挂，所以要尽量的根据增量方式来更新数据。下图是我们增量的数据同步流程：

1. 清空A_temp表，将最近3个月的数据从Hive通过ETL导入到A_temp表；
2. 将A表中3个月之前的数据select into到A_temp表；
3. 将A rename 成A_temp_temp；
4. 将A_temp rename成 A；
5. 将A_ temp_temp rename成 A_tem。

比如说订单业绩数据。因为我们订单比较特殊，比如两个月前的订单状态可能还会发生变化，可能会提前好几个月预定。不像我们购物订单，一个月前的订单状态基本上已经固定下来了，快递、物流的订单两周前的状态基本上也不会发生变化，酒店、机票都会存在提前很长时间预定以及历史订单是否成交这种很久之前的订单状态还会发生变化，这种订单状态变化时间跨度会比较长，所以我们更新的历史数据也会比较多。

我们现在主要是增量更新过去三个月到未来，因为过去三个月的数据变化是基本上可以涵盖大部分，我们会把三个月的数据先导到一个 temp 表里面去，如图上也有一个轮询，一定要轮询检测到最近 3 个月的数据导入完成后，再把正式中三个月以前的数据导到这个 temp 表里面来。这个动作也不是一秒两秒就能执行完的，所以同样有个 job 会轮询，并且这个操作我们实践中也发现了一个隐患。

比如说我们的表里面数据已经有五个亿了，但是我们每天更新最近三个月的三五千万数据量，那另外几个亿的数据需要从正式表导到 temp 表的时候，CPU 和内存都会有波动，这是我一直在想办法解决的一个问题。现在我们的方式就是到第二步就把正式表往 temp 表里面导，后面就是和全量的流程是一样的走完，每天这样循环。

增量的整个流程我觉得挺复杂的，所以我在两周前跟腾讯云的 ClickHouse 团队也有过交流，这种 case 从 ClickHouse 应用的角度暂时没有很好的解决方案，但建议是从业务场景的角度来切割，让不再发生变化的数据沉淀在固定的场景给用户查询，这是一个方案。

另外我们自己也尝试过用视图的方式，但视图有个问题是会让查询性能慢 2s 左右，这个是我不能接受的，所以我们现在正在用 REPLACE PARTITION 的方式，但这个涉及到文件操作，执行时间虽然是毫秒，我们还在谨慎的灰度中。

针对 ClickHouse 的保护机制

这个缓存架构是我们对 ClickHouse 集群的一个保护，分为主动和被动。

上图是一个主动缓存架构图。首先大部分数据从 HIVE 往 ClickHouse 里面导，所有数据都是两份或者三份。

我们现在没有用 ClickHouse 自带的分布式。因为 2019 年年初采用分布式遇到过一个问题，就是查 A 节点的时候，要从 B 节点和 C 节点拿数据过来时，这个中间分布式内部会存在一个数据交互，如果 QPS 太高压力足够大的时候一个节点挂掉，可能整个节点都会受到影响。当然，如果你的节点足够多是不用 care 这个问题的。如果分布式只是三到四个节点我们觉得意义并不大，所以我当时就临时把分布式给去掉了。

还有一点考量是分布式需要借助 Zookeeper，ClickHouse 大部分我们都是自运维的，如果我们要保证 ClickHouse 高可用首先要保证 Zookeeper 高可用。

采用这个架构就强依赖 Zookeeper 了，这个时候我们团队运维任务也会相应的增加很多。这个问题我们也跟腾讯云的同事有聊过同样的话题，瓶颈会出现在 Zookeeper，因为每天大量的数据更新会导致 Zookeeper 产生大量的日志，所以我现在完全靠物理机。同一块数据保存在两台或者三台机器上面，然后我们会有一个 job 检测同一个表的数据在几台服务器上是否运行完成，完成后我们的 job 会轮询检查这两台机器上面的数据是不是一致，通过这种方式起到数据监控的作用。如果用分布式集群并且要检测数据的准确性，用同样的方式就需要更多的硬件成本，所以以我们的量级采用单机多份存储我也认为是合理的。

回到缓存上面来，比如针对 A 表建立缓存，我们有个 job 配置某几个 ETL 流程，然后一直在轮询今天是否运行完成，如果完成了我们会针对 A 表会有一个缓存的标志，比如设置一个时间戳，然后外面在应用的时候会获取一个缓存标志的时间戳，构建成为一个新的缓存 key，所以其实我们的缓存大家看上图就知道了。

先拿到缓存的标志中的值，构建成为一个查询缓存的 key，然后查缓存里面有没有数据，如果有则直接从缓存返回数据，如果没有才到 ClickHouse 里面拿数据同时写入缓存，下一次同样的请求就会走缓存了。

其实做大数据产品的人都知道，如果数据产品足够好的情况下，用户默认条件就可以看到他需要的大部分数据，那用户也不会再切查询条件了。根据这个用户习惯，我们会模拟过去 5 天都有访问过某些热点数据的用户，然后根据默认场景为这些用户提前创建一些缓存，这就是我们通常说的主动缓存。

我们主动模拟用户创建缓存后，用户在 9 点钟上班的时候查询的数据大部分就走缓存了，这样既可以提升整体平台的响应时间也可以降低 ClickHouse 的高并发。当然我们不可能 100%拦住用户所有的查询，但根据我们的埋点来看，我们现在整个平台每天有 60 多万的查询量，一半以上都是走缓存了，被动缓存其实与主动缓存类似，主动缓存是我们监控 etl 流程完成后靠 job 来模拟用户创建缓存，被动缓存就完全靠用户。

上图是我们的 CPU 的波动，2018 年刚上线应用的时候，我每天早上 9 点钟之前必须要到公司，因为担心 ClickHouse 服务器扛不住，但是现在我不用担心这个问题了，因为我的缓存机制已经把 ClickHouse 服务器保护的足够好了。

ClickHouse 集群架构

下图这个是我们的 ClickHouse 集群架构，都是虚拟集群。

1、数据读取通过应用程序做负载平衡

因为我的机器是在两个机房，两个机房的作用一个是起到互备，同时起到负载均衡。

2、虚拟集群最少两台机器在不同的机房

每一个虚拟集群必须在两个机房里面至少存在一台机器，万一一边机房网络有问题，另外一边的机房来支撑这个查询。

3、数据独立，多写，相互不干扰

我称之为虚拟集群，其实是由我们的程序来创建的集群，程序通过不同集群的连接串会读这两台机器上面的数据。简单的说我们可以通过自己的业务线来分，比如像我们国内的数据可以放在 01、02 的机器上面，海外的可以放在 03、04 的机器上面，其他运营数据可以放在 05、06 的机器上面。

4、灵活创建不同的虚拟集群用于适当的场合

通过这种方式有一个好处就是可以充分利用机器，特别是大数据平时日常工作需要关注的数据与节假日不一样的时候，这个时候要构建一些新的集群，这样比较灵活。

5、随时调整服务器，新增/缩减服务器

可以充分利用服务器资源，而不会因为有新的场景就要申请机器，然后走上线流程，整个过程就会比较长。

采用 ClickHouse 后平台的查询性能

下图这是我们平台的一个查询性能。其实这个图都是 2019 年截的，因为我的平台是 2018 年开始接 ClickHouse，2019 年初我们 PC 版每天超过 15 秒的次数还要上万次，因为那个时候还有一部分场景用的是 SQL Server+ES 的架构。2018 年我们开始用 ClickHouse 的时候，业界基本上没有太多使用案例，我也不敢保证它就是高可用的，所以一开始只能小范围内尝试。到 2019 年的 3、4 月份左右我们开始大范围的替代 SQL Server 和 ES 的架构，大概 5 个月左右完全下线原来的 SQL/ES 服务器强依赖 ClickHouse，所以后面查询响应就非常平稳了，99%控制在 3 秒内。

然后这个图是手机端的响应时间监控，手机端一开始每天超过 2 秒的次数有几百次，经过采用 ClickHouse 的方案后现在每个手机端查询接口超过 2 秒的每天就三五个。

现在我们主要考核指标 PC 版在 3 秒，目前为止 99.6%以上的查询都是 3 秒内查询响应时间。这个整个查询次数，上文讲过每天大概 60 多万，1 秒内的响应时间也有 98%以上；app 考核是 2s，这两点在我们接入 ClickHouse 效果是很明显，但也有一些比较复杂的查询需要 case by case 优化并且大数据的查询性能也需要长期跟进优化。

从另外一个角度我认为这个指标也是我们在大数据技术上的一个沉淀结果，因为对于用户来说他并不知道查询的数据背后有多少亿数据量，多少表在支撑他的一个 query，所以在业务合理的情况下我们不能说因为大数据数据量很大所以我们慢。

ClickHouse 应用小结

下面是我对 ClickHouse 的一些小结

1、数据导入之前要评估好分区字段

ClickHouse 因为是根据分区文件存储的，如果说你的分区字段真实数据粒度很细，数据导入的时候就会把你的物理机打爆。其实数据量可能没有多少，但是因为你用的字段不合理，会产生大量的碎片文件，磁盘空间就会打到底。

2、数据导入提前根据分区做好排序，避免同时写入过多分区导致 clickhouse 内部来不及 Merge

数据导入之前我们做好排序，这样可以降低数据导入后 ClickHouse 后台异步 Merge 的时候涉及到的分区数，肯定是涉及到的分区数越少服务器压力也会越小。

3、左右表 join 的时候要注意数据量的变化

再就是左右表 join 的问题，ClickHouse 它必须要大表在左边，小表在右边。但是我们可能某些业务场景跑着跑着数据量会返过来了，这个时候我们需要有监控能及时发现并修改这个 join 关系。

4、根据数据量以及应用场景评估是否采用分布式

分布式要根据应用场景来，如果你的应用场景向上汇总后数据量已经超过了单物理机的存储或者 CPU/内存瓶颈而不得不采用分布式 ClickHouse 也有很完善的 MPP 架构，但同时你也要维护好你的主 keyboard。

5、监控好服务器的 CPU/内存波动

再就是做好监控，我前面说过 ClickHouse 的 CPU 拉到 60%的时候，基本上你的慢查询马上就出来了，所以我这边是有对 CPU 和内存的波动进行监控的，类似于 dump，这个我们抓下来以后就可以做分析。

6、数据存储磁盘尽量采用 SSD

数据存储尽量用 SSD，因为我之前也开始用过机械硬盘，机械硬盘有一个问题就是当你的服务器要运维以后需要重启，这个时候数据要加载，我们现在单机数据量存储有超过了 200 亿以上，这还是我几个月前统计的。这个数据量如果说用机械硬盘的话，重启一次可能要等上好几个小时服务器才可用，所以尽量用 SSD，重启速度会快很多。

当然重启也有一个问题就是说会导致你的数据合并出现错乱，这是一个坑。所以我每次维护机器的时候，同一个集群我不会同时维护几台机器，我只会一台一台维护，A 机器好了以后会跟它的备用机器对比数据，否则机器起来了，但是数据不一定是对的，并且可能是一大片数据都是不对的。

7、减少数据中文本信息的冗余存储

要减少一些中文信息的冗余存储，因为中文信息会导致整个服务器的 IO 很高，特别是导数据的时候。

8、特别适用于数据量大，查询频次可控的场景，如数据分析、埋点日志系统

对于它的应用，我认为从成本角度来说，就像以前我们有很多业务数据的修改日志，大家开发的时候可能都习惯性的存到 MySQL 里面，但是实际上我认为这种数据非常适合于落到 ClickHouse 里面，比落到 MySQL 里面成本会更低，查询速度会更快。

三、ClickHouse 当前存在的问题和规划

需要解决的问题：

1、部分场景下内存泄漏

现在我们遇到的一些问题是当你服务器上面的数据存储超过你的服务器内存时，会存在内存泄漏。但每天就掉一点点，比如说 128g 内存可能 2-3 个月时间可用内存只有 60%左右，但是这个还是在我用 2018 年的版本时候。我们现在也正在灰度升级到今年的 20.9 的版本，看似还是没有解决。

2、历史数据更新的 CPU 消耗问题。

3、死锁问题

我们每天大量的数据更新后为了减少用户端使用的影响，我们都是通过 rename 的方式，但对于有些查询并发比较高的表 rename 的时候会存在死锁的情况，这个在 20.9 的版本中已修复。

建议性问题：

1、如何保证高优先级的表在服务器维护后第一时间投入生产应用的问题?

对于 ClickHouse 一个建议性的问题就是服务器重启以后，如果服务器上面的数据量过大，可能要很久的数据加载，重新整理文件后服务器才可用，所以这个我跟俄罗斯研发团队有过沟通，让表分级，高优先级的表先启动，可以早点让服务器起来后投入生产应用，后面的表可以通过 lazy 的方式加载。

新功能的实践：

1、20.9 的新版支持订阅 MySQL 的 binlog 方式同步数据

新功能的时间包括现在有订阅 MySQL 的 binlog 方式同步数据方式，这个我们发现最近几个版本都有在修复一些 bug，所以暂时没有应用，但如果这个做好了是可以用于更多的场景，也可以更好的接入实时数据。

2、查看执行计划

以前的版本只能到服务器上看执行日志，但这个比较费劲，现在可以像 SQL 一样直接看执行计划了。

Q&A

Q1：蔡老师您好，我们还没用，但是我前期调研了一下。我就发现有两个问题：第一个，比如在对比的时候，跟 ES 比，ClickHouse 不支持高并发，不知道这样对比结果对不对？

A1：对，ClickHouse 应用场景一定是在 QPS 控制得住的情况下，如果放在外网控制不住，那 ClickHouse 一台 40 核的 128G 的物理机，可以靠十个人手点把服务器点挂。

Q2：80%以上的业务都用 ClickHouse 您介绍的，但是您还用 Hive，是不是那边又存了一份数据？

A2：是这样，比如数据仓库团队会负责每天把生产数据同步到仓库，后面有一个 DM 团队专门做数据整理，每个业务线的数据做一些逻辑，或做一些沉淀的主题表或者宽表，我们团队负责把我们用到的数据同步到我的 ClickHouse 里面来。因为我的应用不可能直接调 Hive，应用程序直接调 Hive 大家都知道很慢或者基于其他 spark，presto 从性能或者高可用上不能达到我的要求，但 ClickHouse 可以解决这个问题，所以我们用到的数据是 Hive 上有一份，ClickHouse 中也有一份。

Q3：明白了，就是其实数据集包括数据处理还是都在 Hive 层处理的对吧？

A3：对，我们都是将 Hive 数据通过 ETL 同步到应用端来的。

Q4：这个 ClickHouse 同步 MySQL 的 binlog 是多久同步一次？

A4：ClickHouse 比较适合于批量写，这个时间间隔可以设置的，之前准备尝试的，后面发现每个月的新版本都有在更新相关的 bug，所以暂停测试了，等稳定一点后我们准备测试；

Q5：ClickHouse 主机重启的时候会导致数据错乱，我们实际上在测试一些业务场景，在尝试用 ClickHouse。但是这个问题我不知道重启之后为什么会数据错乱？原因是什么？

A5：是这样的，ClickHouse 我们用了两年多了，根据我们的经验发现，如果是这个机器上面的数据少，只有六七十 G 的时候，重启是没问题的。但是数据如果超过 100G，它的文件合并可能会有问题。当然我也没有具体去测试多大的数据文件是瓶颈，这个问题我反馈给了俄罗斯的研发团队，但现在应该还没有很好的解决方案。

Q6：我们是从 Oracle 里面导一些批量文件固定格式，但是发现一个问题就是我们在往里导 ClickHouse 的时候，它的数据是不一致的，会差一些数据，但是它导入过程中也不会报错，所以这个问题我一直不知道怎么去排查或者怎么处理。

A6：你是从 Oracle 直接同步到 ClickHouse 里面来是吧？

Q7：不是同步，是按照 CSV、平面文件，再通过别的方式导进去，但是它丢数据。

A7：这个问题我还真没有遇到过,如果丢数据我这里也会很容易发现，你的模式与我不同的是中间多了一个 CSV 中转，这个我不建议，CSV 有各种分隔符分数据的方法，可能某些数据中包含一些特殊字符，你也不可能打开 CSV 一行一行检查，所以我建议你跳过 CSV 的中转，如果自己测试弄一些数据从 CSV 我觉得可以，投入生产不建议走 CSV 中转；因为我这里每天也有两千多用户都在用我这个平台，我的数据同时存在多份，如果丢数据我们监控是很容易发现的，但是从来没有遇到过丢数据这个问题。

Q8：有可能是不是我的导出来的数据质量的一个问题？

A8：这个你要看一下日志，导数据的时候也会有日志，你要看 ClickHouse 内部的日志。我在社区里面也没有看到过谁说导数据的时候会有丢数据的情况。

不建议你用 CSV，因为它会中转，你完全不知道中转的时候会做什么事情，导致文件中的数据行数可能变了。

Q9：这种情况哪种方式更好一些？

A9：其实 ClickHouse 支持从 MySQL 同步过去，也支持走程序的方式批量写入或者 spark etl 写入，有很多种写入方式，但是我不建议中间是通过 CSV 中转这种方式去做。

Q10：MySQL 我们在尝试创建一个类似的 MySQL 引擎的 ClickHouse 表的时候，我就发现它的时间会很长，我也不太好评估这一个 SQL 下去会跑多久。

A10：一开始我们也不是通过 ETL 流程往 ClickHouse 上面导数据，也是先写到 MySQL 里面，通过程序的 job。因为你知道，它其实就相当于在 MySQL 上面把一个表导到另外一个表，只是加了一个服务器的 ip 上去，然后加上账号密码，其实很简单。但是我们以前都用这种方式，几千万不会有问题，只是说瓶颈就会压到你的 MySQL 服务器上面，几千万上亿的数据是否能从 MySQL 服务器上取出来，大量的数据读取会对 MySQL 服务器造成很大的压力，所以后来我们 ETL 工具支持后我全部切走断开了对 MySQL 的依赖，每个数据你要评估数据源是什么，可以有很多种写入 ClickHouse 的方式。

本文转载自：DBAplus 社群（ID：dbaplus）

原文链接：支撑700亿数据量的ClickHouse高可用架构实践