支撑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表里面去，加一个服务器地址，账号密码就可以了。下图是我们的一个数据同步的流程：

清空A_temp表，将最新的数据从Hive通过ETL导入到A_temp表；将A rename 成A_temp_temp；将A_temp rename成 A；将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的增量数据同步流程

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

清空A_temp表，将最近3个月的数据从Hive通过ETL导入到A_temp表；将A表中3个月之前的数据select into到A_temp表；将A rename 成A_temp_temp；将A_temp rename成 A；将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高可用架构实践"