导语 | ClickHouse是俄罗斯开源的OLAP数据库，以彪悍的性能著称。开源5年以来，以性能优异、简单易用的特点，吸引了大量的用户群体。本文是对腾讯云ClickHouse研发负责人彭健老师在腾讯云开发者社区沙龙online的分享整理，帮助大家进一步理解ClickHouse的彪悍性能。
一、 QQ音乐PB级数据实时分析带来的挑战
腾讯公司内部有很多业务使用 ClickHouse，比较典型的就是QQ音乐。QQ音乐在使用 ClickHouse 之前，用的是基于 Hive 构建的离线数仓，当时遇到了很多问题，主要在于以下三个方面：
第一是实效性低。基于 Hive 仅仅可以做到 T 1 定时报表的分析，但实效性对音乐服务是至关重要的，所以分析的结果随着时间的推移价值也是降低的。
第二是易用性低。数据分析需求来源于产品、运营、市场等多个方面，基于传统的数仓分析门槛高，产品运营市场人员无法进行自主分析，需要把任务提交给数据开发人员做排期。
第三是流程效率低，需求需要经过排期、沟通、建模、分析、可视化流程等，以周级别的时间落地，分析结果非常不及时。
相信很多朋友工作中都会遇到类似的问题。所以QQ音乐最终选择了ClickHouse集群，集群的现状是近万核的规模、PB 级的存储，十万亿级别的记录量，每天过千亿级的数据入库，包括实时流水、中间表的计算等等。绝大部分查询请求是数秒内完成、部分查询请求在十秒内完成。
使用ClickHouse带来的业务价值，一方面是实时性，复杂的分析查询通常是秒级完成，比如营收分析、多口径业务指标、给老板看的大盘指标、易用性的分析等。
另一方面是易用性，利用 Superset 可以自主制作各种报表，在Superset 过万的图标中，超过一半是由产品、研发、运营、财务等非数据同学创建的。
二、 腾讯云ClickHouse在QQ音乐的实战经验
在整个使用和运维过程中，我们也积累了很多经验，如下：
1. 合理规划Zookeeper的集群配置
ClickHouse 集群数据量的增长，给 ZooKeeper 集群造成的负载也成正比增长，在并发写入量较大的情况下，ZooKeeper 的处理能力跟不上，集群的性能也会急剧下降。所以在整个运维过程中，如果集群数据规模超过 TB 级别，建议采用具有 SSD 盘的设备。
2. 数据幂等写入
ClickHouse 的集群是按 Shard 分布的，在向 ClickHouse 导入数据的过程中，难免会遇到失败或者超时的情况，这时需要重试写入动作。
但这个动作经常会遇到数据不一致的情况，导入数据和原始表中数据有不一致的地方。这是因为重试的时候由于负载均衡的设置问题、链接路由的问题，导致在多个 Shard 出现重复的写入。为了避免这种情况，在重试的时候要在相同的 Shard 上写入。
3. 合理规划表分区数
官方有个建议，分区数量不要超过一千。通常这个分区数对大部分业务场景都够用，过多分区数量会导致查询性能的降低。
通常可以将数据按天、按月做分区，根据具体情况来操作。腾讯云的内部用户也有按 ID 进行分区，但这样会导致分区数量非常多，整个查询如果设计多个 ID 会降低整体的查询效率，这也是需要注意的地方。
4. 读写分离
频繁的数据写入请求会消耗大量的 CPU、内存、网卡资源，同时 ClickHouse 后台线程也会进行数据合并的操作，占用线程。通常数据在其他平台准备好批量入库时，如果遇到线上查询，二者会相互影响形成恶性循环，导致集群的不可用。
在 QQ 音乐运维过程中经常会遇到这样的问题，最终找到比较好的解决方案就是读写分离，借助临时集群，预先将准备好的数据在临时集群中构建、写入，等待 Merge 完成后 AB 切换，或者通过数据拷贝的方式将数据复制到在线集群的服务器上，做到读写分离。
这样操作后带来的好处是，数据的写入不会影响线上的查询，或者是把影响降到最低。
5. 跨表查询的本地化
ClickHouse 集群分布式查询通常采用 GLOBAL IN/GLOBAL JOINS 类似的词语，这些词句的性能相对比较低，使用后再查询时会生成临时表，并跨节点读取数据，从而降低查询速度，也会占用更多的内存，甚至导致查询失败。
这部分的经验就是合理的组织数据，使用本地化的 IN/JOINS 代替。具体来说，如果数据没有进行合理的组织，那在每一个 Shard 上的数据会随机分布，导致在跨节点时造成数据的损耗。
如果对数据进行合理的组织，比如根据数据的 UN、VID 将相同 ID 的数据写入到相同的 Shard 中，结果是等效的，但可以极大的提升性能，将复杂的操作编程定型化的操作。
三、 常见 ClickHouse 实时分析场景剖析
首先，我们看一下 ClickHouse 擅长处理哪些数据：
- 擅⻓处理良好结构化的流式数据、或不可改变的事件流 (SCHEMA 固定，数据追加)；
- 擅⻓执行灵活的实时报表查询(秒级查询，无需预过多预处理，AD-HOC)；
- 不应当作OLTP数据库使用(无事物，very heavy UPDATEs)；
- 不应当作KV存储系统使用；
- 不应当作文档存储系统使用 (官方建议单条数据不宜超过100kB)。
下面，我们通过几个例子，一步一步说明 ClickHouse 典型的应用场景。
1. 物化视图
第一个场景是物化视图的应用。假设有一张明细表 users_online，这个表描述了某一款 APP 用户登录时间以及在上面停留时长的明细数据。
如果我需要频繁的查询这个用户登录的平均总时长以及一天中登录的总次数，就可以通过 ClickHouse 物化视图来完成。
ClickHouse 的物化视图和传统的物化视图有一些区别，传统的物化视图是查询的状态，但 ClickHouse 视图物化视图做了进一步的改进，当所关联的明细表上数据发生变化，通过物化视图可以直接更新到目标表。
因此，通常会把物化视图配合聚合引擎使用，比如在创建物化视图时，我们选择了聚合引擎。当创建完成后，可以在视图中查询数据已经计算完成的数据。这样带来的优势是，当有非常多同类查询时，可以通过预聚合以空间换时间的办法节约查询时间。
物化视图的原理是比较简洁的，相当于设置了一个触发。当在明细表中插入数据便会触发物化视图后台的关联，进行预聚合计算，并将计算结果存储在目标表里。这里需要注意的是创建物化视图的时候没有关联目标表，便会创建一个隐藏的表，当然也可以自主指定。
2. AggregatingMergeTree
除了物化视图的功能以外，ClickHouse 也提供了各种比较专用的表引擎。其中最著名最有特色的表引擎是 AggregatingMergeTree。
假如在上述的例子中，我们不光要查询用户上线的次数、时长，还要计算最早、最晚上线的时间、每次上线平均的时长，对于这种聚合的查询就需要用专门的聚合引擎来做。
这里我们也会用到物化视图。首先创建一个目标表存储我们需要预聚合的变量、字段，然后通过 ClickHouse 提供的大量聚合函数完成常用的聚合分析，创建物化视图将目标表、明细表关联起来，创建完成后可将存量数据导入，导入后查询会发现这些数据已经做了预聚合。整个过程非常迅速，时间也非常短暂。
我们在创建视图时会用到一个聚合函数，在查询时用的是另一个函数，两个函数是同一个函数的两个不同面、或者是用于不同的阶段。
在导入存量数据后，明细表会有增量数据，比如通过 Kafka 或者一些其他途径，将数据源源不断的用增量方式写到明细表中。这个时候后台会自动通过聚合计算将数据保存为中间状态，这样任何时候去查询聚合表都会有非常快的速度，这也是典型的空间换时间的策略。
这背后的原理，我们用 duration 来举例。原始数据都是可见的，但在聚合表中是个二进制的中间状态保存，是不可读的。如果要查询聚合数据的明细状态，就要用到 Merge 函数。
3. Aggregate Function
第三个场景是聚合函数的应用。ClickHouse 提供了大量的聚合函数，这里我们用 BitMap 来举例。
在传统的数据分析中，会经常遇到广告投放和用户画像的场景，在这些场景中，我们通常要根据一定条件找出用户的标签或者更新一些投放标签。
假设我们有一张上图左侧的明细表，表中有登陆的明细和一个额外的 page_id，也就是登录的时候访问了哪些 id。接着，我们模拟向其中插入7月29日、7月30日两天的数据。
接着要做一件事 —— 查询用户存留，查询这个平台上昨天登录和今天登录的日存留。常规可能会采取 JOIN 的方法，直接找到第一天、第二天的数据，但这样带来的问题是 JOIN、COUNT DISTINCT 都很慢，并且很容易 OOM。
那么如果用聚合函数 BitMap 来做的话，会是什么样的呢？
在 ClickHouse 提供的聚合函数中，有一种是 groupBitmap 函数，它可以提供一个位图，我们要做的就是将数据聚合到这个位图中。
比如我们为 7 月 29 日创造一个位图，有用户的登录对应的是 1、如果没有就是 0，7 月 30 日也如此。如果我们需要查询两天都在线的存留，就要对两个 Bitmap 进行 and 操作。
首先使用聚合引擎创建聚合表，导入历史数据，接着创建一个物化视图将明细表聚合表关联起来。物化视图在这里还有一个作用，可以做表间的数据移动，当有新的数据明细表数据不断上报的时候会自动做聚合。
接下来我们可以查看聚合表里数据，如图所示，7 月 29 日有 50 个用户，7 月 30 日我们模拟插入了 60 个用户，然后用聚合函数做运算，再求其积数，这样就得出连续两天登录的用户数量。整个位运算非常迅速，节约内存的效果也很显著。
我们做过一个简单的测试，在亿级别用户的情况下，一个位图使用的内存不会超过 50M。通常简单的 128G 服务器就可以进行支撑计算。这就是聚合函数的优势，计算速度快、资源消耗小。
这里我们再补充一个例子，看看 Bitmap 在广告投放中是怎么做的。
通常广告投放有一个明细表、用户表，会给用户打各种标签，比如年龄、性别、职业以及各种属性，我们会把这些标签存储在数据里，那么在 ClickHouse 如何用 Bitmap 解决呢？
首先，我们为每个标签创建一个 Bitmap，如果某个用户具备这样的属性，他对应的用户 ID 在 Bitmap 会置为 1，这个动作可以用物化视图在后台自动从明细表中配合聚合引擎一起工作，用户没有更多的干涉和开发工作。
这里我们有两类标签，一类是字符串形式描述的，比如性别、职业；一种是年龄，用整型来描述，简单创建两个表。
接着，我们会导入一些数据，这个过程和之前的例子是类似的。
假设已经有了相关数据，我们现在要在广告投放中圈出这样一群人：性别女、工程师，年龄超过 20 岁。
首先，我们要找到 3 个标签的 Bitmap，然后再求积数。如果想不求积数看出 ID，也有工具函数可以把 ID 打印出来，这个过程是非常迅速的。核心的思想就是找到标签对应的 Bitmap，根据条件做各种逻辑运算，完成人群筛选和广告的标签投放。
四、ClickHouse 原理 & 性能调优
目前在腾讯云上有很多 ClickHouse 的用户，也积累了大量运维的操作，这些操作我们非常愿意分享给大家，也愿意和大家一起交流，共同推动社区的发展。
它的核心部分是计算引擎、存储引擎，大致有以下的特点：
- INSERT 操作是原则的；
- SELECT 操作异常快；
- 支持主索引/二级索引；
- INSERT/SELECT 相互不影响；
- 后台合并数据；
- 主键不唯一。
这是一个典型的 OLAPMergeTree 的数据结构，在 NoSQL 中应用的非常广泛。当有新数据写入时，快速形成一个小的数据分片。数据在分片内部是有序的，在后台会通过后台的限制不断的将小的、有序的分片合并成更大的、有序的分片，并不断的进一步的合并。
为什么要合并呢？因为对 OLAP 引擎来说如果要提高查询效率，数据有序是非常必要的。但同时有另一个矛盾，数据按时间进入是无序的，如果每次写入数据都要进行全表的排序，代价是非常昂贵的，为了避免这种情况，选择 RSM 的结构是非常的合理。
我们可以简单创建一个表，看一下后台的运行过程。
首先在三个字段插入一千条数据。我们可以看到，后台每个表都对应一个目录，每次插入也会形成独立的文件夹，这个文件夹一般称为 parts 目录。
整个数据是通过分区构成，每个表中的数据根据定义进行分区，每一个分区有自己独立的文件夹，在一个分区内部数据通常是按 parts 构成，会随着后台的 Merge 不断的聚合，有些会无效，有些会被删除。parts 内部的数据是按列式存储的，每一列会形成一个单独的文件。
这里我们定义的表有三个字段 —— duration、user_id、when，有主线的索引文件，每个字段除了二进制的数据文件也有 mark 文件。
具体的索引是怎么工作的呢？首先创建表时会直接指定字段，生成稀疏的索引，这个索引目前是可以按固定行数生成索引，或者是按照固定的数据量生成一个索引。
其次是 marks 文件。marks 文件和索引文件在行数上是对齐的，它会标记两个 opset。第一个会标记数据文件，主键索引的数据在数据文件中的 opset；第二个因为数据是压缩存储的，解压后的 opset 通过主索引文件和 marks 文件可以很容易定位到对应的数据。
当有查询的时候，可以先通过主索引文件进行二分查找，找到对应行，因为行是对齐的，所以很容易找到 marks 中对应的文件，找到读取的数据。
具体的流程是根据查询条件确定 index 行数，然后找到 marks 文件，再切片分发给线程组。因为整个 ClickHouse 是为了提高查询性能，后面是有线程组的，所以查询时用了大量的 CPU。有些线程执行完会从其他的线程队列中调取一些任务过来，线程开始读取对应的数据，其他的也会处理。
我们举个例子。
比如我们在 user_online 中查询 user_id 大于 8192 小于 15000 的数据，我们只读取相应的字段，在主索引文件中找到对应的覆盖这个 ID 的行数，找到 duration 对应的文件内容，这个文件就会标记出在数据文件中的位置。
在后台，会不断的有 parts 被合并。因为不断有数据写入，每次写入会形成 parts。parts 内部有序，但 parts之间是无序的，我们会不断的将其进行有序化，加速查询，同时在 Merge 过程中，有些存储引擎会做其他的动作，比如删除数据等。
接下来我们看一下 ClickHouse 的性能调优。
我们在云上的很多客户，在创建集群的时候不太清楚自己需要什么样的配置，我们就会给出建议，通常有两类节点、部署两类进程。一类是 ClickHouse 的进程，一类是 ZK 的进程。
在 ClickHouse 进程中，CPU 的主频越高越好，通常建议使用 32 以上的机型，内存越大越好，一般每个线程分配 2GB 内存差不多就够了，当然越大的内存加速就会越明显。
磁盘通常普通的 HDD 磁盘都可以，RAID 方面 RAID-5、RAID-10 或者 RAID-50 都可以。如果查询数据量大、延迟要求比较低的话，使用 SSD/NVME 这些高速设备是最好的。
因为 ZK 节点不能混布，如果混布会出现很多的问题，比如相互影响导致集群无法工作，如果数据量在 TB 级别的时候，会选择一个 SSD 盘之类的高速设备。
我们整理了一些基础的参数：
- lmax_threads: 查询使用的线程数量，默认为核数一半；
- lmax_memory_usage: 单次查询允许使用的内存量；
- lmax_memory_usage_for_all_users：ClickHouse 进程允许使用的内存量, 通常需要考虑为 OS 预留内存；
- lmax_bytes_before_external_group_by: GROUP BY 操作使用内存超过该阈值后， 数据会写入磁盘，建议设置为 max_memory_usage/2；
- lmax_concurrent_queries: 最大并发数限制；
- lmax_bytes_before_external_sort: order by 排序溢写磁盘阈值；
- lbackground_pool_size: 后台线程组 。
在使用层面也有一些建议：
- 避免全表扫描 -查询是需要指定分区 -避免使用 SELECT * -GROUP BY 需要指定 LIMIT 子句
- 常用请求使用物化视图预计算， 例如监控⻚面，报表大盘等
- 关联查询时慎用 JOIN，可以考虑优先使用 IN 解决
- JOIN 查询有损性能 -小表在右 -减少参与 JOIN 运算的数据量 (无谓词下推)
- 数据写入 -避免小批次写入 -批量写入数据中不宜包含过多分区 -适当调大后台 merge 线程数 background_pool_size
- 分布式表提供查询，代理 本地表提供数据写入
- 合理规划ZK集群配置以及参数调整建议 -数据规模在 TB 级别，建议使用 SSD 磁盘 -开启自动清理数据功能
- 为用户设置配额
下面我们讲一下查询方面的优化。最简单的来说，对于一条 SQL 语句，我们要看它的延迟，如果延迟的结果不一样，我们就会通过日志和其他的方式来看，哪些数据被扫描了、扫描了多少数据、用到内存多少、有没有写出到磁盘、使用了哪些条件，甚至可以查看执行计划，这些就是查询优化常规的步骤。
最新版本的 ClickHouse，已经提供了 explain 命令，可以看整个查询的执行计划，这样查询语句合理不合理都可以再次调整，比以前方便很多，以前通过日志后台看，这对很多的其他开发者是不太友好的。
五、 腾讯云ClickHouse现状与规划
腾讯云是在今年 4 月份发布了 ClickHouse服务，提供了分钟级别的企业级 ClickHouse 服务，支持秒级监控触达、灵活的配置管理，这些云上必要的功能。
预计在 8 月份会支持弹性伸缩能力，灵活增加减少计算节点，这对用户很必要，根据业务做弹性伸缩。也提供数据自均衡服务，这是腾讯云特有的服务，目前社区对这块支持的工具比较完善，但是运维成本比较高。我们计划把它自动化，做成简单的按钮点击后就可以完成数据自动搬迁的功能。
预计在今年 Q4 ，我们会发布一个性能增强版，这个版本会解决 ZK 性能评级。ZK 是整个集群中比较重要的终端瓶颈，当 ZK 有问题时集群会无法写入数据。同时也会集成 COS，方便用户解决 COS 层的数据。还有其他的 feature 也在规划中，会随着比较合适的节奏会释放出来。
参考资料：
[1] https://github.com/ClickHouse/ClickHouse
[2] https://github.com/ClickHouse/clickhouse-presentations
[3] https://cloud.tencent.com/developer/article/1637840
六、Q&A
Q：ClickHouse的优缺点？
A：ClickHouse 是一个技术相对简单，对于 Hadoop 的依赖比较小，目前就是依赖Zookeeper 进行数据容灾方面的依赖。它的性能非常强悍，底层是用 C 实现的，我们知道C 是编译型语言，没有像“Hadoop”大量用“JAVA”中间使用虚拟机从而带来的性能损耗。
第二方面 ClickHouse 整个技术用得比较激进，各种先进的技术都会快速的拿来验证，如果适用就继续用、如果不适用就快速的换，社区更新、迭代得比较快，所以发版频率非常高。
整个使用门槛非常低，支持 SQL ，虽然它的 SQL 有些特别，但是很容易理解，数据分析人员或者是没有特别多的开发背景，学习成本很低。
它的缺点是整个社区时间比较短，开源到现在时间并不长，积累使用经验并不多，随着云化后会积累大量的使用经验，也乐意把经验分享给大家，弥补这方面的不足。
Q：自动故障转移切换时如何做？
A：ClickHouse 是支持数据容灾的，可以配置多副本。整个数据级分为多个 Shard，每个 Shard 内部可以分多个副本，可以指定两副本、三副本，对不重要的数据指定一副本，通常用两副本用磁盘做 RAID-50 就足够了，如果出现一个副本所在机器不可用，其他的副本就会去支撑读写，副本间可以看做是完全均等没有差异的，如果整个 Shard 所有的机器都宕机了，整个集群是可以继续提供读写服务的，只是读会出现部分数据缺失，这部分数据等机器恢复会自动的回来，这是故障切换。
Q：单次查询允许打开文件数，有这个参数吗？
A：在配置文件中是没有这个设置的，但是系统层面为这个进程把这个FD打开，设置更大的FD。
Q：什么样的数据需要存在 COS 上？
A：COS是腾讯云提供的一个大容量、高性能的对象存储，广泛应用于大数据的技术栈中。我们很多用户的数据在 COS 上，COS 上也沉淀大量的数据，如果这个数据能够被 ClickHouse 分析将为用户带来很大的价值，我们也会做一些工作把数据链路打通，也是在规划中。
Q：数据量大、分区多时，重启ClickHouse很慢，有什么优化建议吗？
A：确实会出现这个问题，数据量比较大时重启比较慢，特别是 IO 带宽比较低的情况下，如果有特别重要的表，这表必须要快速的写，建议先把节点上不重要的表先给 move 要其他的目录，先把这个表写入，之后再把其他的表加入。
Q：当并发的写入数据请求数比较多时，ClickHouse会报错，会有什么配置优化建议？
A：首先要评估整个集群的负载是否达到了上限，如果达到建议先扩容，如果没有达到还出现这样的情况就看写入方式是否合理。
首先尽量大批次的写入，写入的 QPS 官方建议是 1 到 2，以一秒钟写一个、两个的频度写入，每次写入的数据尽量多，比如 64K/条，一定是大批量。
第三个点是操作层面写入的数据一定要做好预处理，如果是用 GBDC 自己手写写入，每一个 insert 中包含的数据分区尽量是同一个分区、不要跨分区。配置层面建议调大后台的 Merge 限制数，这些都无法解决的话，可能要观察整个系统的 LWait ，通常是磁盘开关瓶颈的问题，如果这样情况就要去做磁盘的升级。
还有一种方案，就是 QQ 音乐做的读写分离，当写请求和读请求分离开，不需要历史数据可以做 AB 切换的方式上线数据，如果需要历史数据，可以通过工具把新创建好的数据拷贝过去的方式，降低对写请求的影响。
Q：ClickHouse是否存在丢数据的情况？
A：这个问题是大家担心的情况，大家对数据完整性要求非常高，如果绝对来说肯定会存在这样的情况，整个机房机器全坏了、所有的集群所有节点磁盘都坏了，那肯定会出现丢数据的情况。通常这样的小概率事件就不会考虑了。
ClickHouse 有内在的机制允许数据做多副本，可以配置两副本、三个副本，通常是三副本已经足够了，但大多数情况建议用两副本，后面一些数据可以备份到 COS 上去，查询的请求可以购买一些计算节点，通过计算节点访问 COS 中的数据，COS 数据可以提供很高的可靠性。
Q：ZooKeeper 性能瓶颈是如何优化的？
A：ZooKeeper稳定性与可靠性对ClickHouse集群至关重要。从一下几个方面考虑：
- 建议数据规模超过TB级别，采用SSD盘的机器部署ZK集群；
- ZK配置上，要确保及时清理不需要的数据
- 腾讯云ClickHouse服务会降低对ZK的依赖，敬请期待。
Q：物化视图和 MergeTree 表存储一样的数据，查询性能有区别吗？
A: 性能上没有区别，如果物化视图没有关联目标表，系统会创建一个隐藏的目标表，通过show tables命令也是可见的。查询数据最终会落到关联的目标表上。在这个上下文中，物化视相当于传统数据库中的触发器。
Q：在数据量上30亿的情况下，一般选择什么规格的机器比较好？
A: 选择机器类型，要综合你的查询情况。例如，如果你查询数据量都比较少，就不需要太多机器。在腾讯云上，我们建议采用大数据机型或者高IO机型。
Q：在深度分页的场景下，ClickHouse 应该如何做？
A: 总体而言，复杂查询情况，尽量减少查询所需读取的数据量。使用索引，以及预聚合等加速查询。
Q：两个亿行级别的表关联查询，怎么写高效？
A: QQ音乐的例子可以借鉴，能否对数据合理组织，让数据的逻辑分片和ClickHouse的分片一致，从而将GLOBAL IN/JOINs 操作转为节点内的IN/JOINs操作。
Q：ClickHouse在哪些数据场景下更有优势呢？宽表多的场景呢？
A: ClickHouse 删除处理结构化的流式数据，例如 事件数据，监控数据，日志数据等。ClickHouses非常适合处理宽表场景。在具体使用过程中，也建议尽量使用宽表。
Q：MySQL 读写太慢了，迁移到 ClickHouse 是不是就会解决了？
A: 可能还需要了解具体的场景，如果你的业务需要有事物支持，那么ClickHouse无法支持。除此，ClickHouse 在性能方面具有非常明显的优势。
Q：Docker 容器中的 ClickHouse能用于生产吗?
A: 可以的。据我了解到，腾讯公司内部有不少业务部门的ClickHouse集群部署在容器中。
Q：ClickHouse 8123 端口 Read timed out 怎么优化呢？
A: 从2个方面来看：
- ClickHouse进程所在机器负载情况如何，网卡，网卡，磁盘是否已出现瓶颈。
- 在客户端，在适当调整Timeout值后，仍然出现超时，可以看看客户端所在机器负载情况，以及到ClickHouse机器的网络状况。
Q：大的历史表（T级别）方便存 ClickHouse吗，存了后可以快速读写吗？
A: 有不少工具都可以用于将历史数据写入到ClickHouse中。例如可以使用物化视图将数据从KAFKA导入到ClickHouse, 可以使用 clickhouse-mysql-data-reader
将MYSQL数据库中的作存量、 增量导入。也可以使用JDBC 将其他数据源数据导入，例如 https://github.com/ClickHouse/clickhouse-jdbc。
数据导入到ClickHouse后，大部分查询相比HIVE，SPARKSQL而言，具有非常明显的性能优势。在QQ音乐的案例里，他们绝大部分查询响应时间是小于1s的。
Q：如果做了用户资源的配置，超出配额会产生什么现象，拒绝连接还是查询变慢？
A: 抛出异常。
