ClickHouse自从2016年开源以来，各个大厂纷纷跟进大规模使用。源于ClickHouse 是一款优秀的 OLAP 分析引擎，尤其是在单表分析 、Colocate Join 方面性能表现尤为突出。ClickHouse 之所以在众多的 OLAP 分析引擎中成为佼佼者，主要是因为它具备以下特点：列式存储、LSM-Tree 存储引擎、向量化执行引擎、异步 Merge 和 Mutation 机制、并发 MPP+ SMP 等。
集群部署架构
ClickHouse 不同于 Elasticsearch、HDFS 这类主从架构的分布式系统，它采用多主（无中心）架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。
ClickHouse 借助分片将数据进行横向切分，而分片依赖集群，每个集群由 1 到多个分片组成，每个分片对应了 CH 的 1 个服务节点；分片数量的上限取决与节点数量（1 个分片只能对应 1 个服务节点）。
以四节点实现多分片和双副本为例：
方案一
在每个节点创建一个数据表，作为一个数据分片，使用 ReplicatedMergeTree 表引擎实现数据副本，而分布表作为数据写入和查询的入口。
方案二
在每个节点创建一个数据表，作为一个数据分片，分布表同时负责分片和副本的数据写入工作，它很有可能为写入的单点瓶颈。
方案三
在每个节点创建数据表，作为数据分片，同时也创建两个分布表，每个分布表只管一半的数据（需要借助 ReplicatedMergeTree 引擎）。
方案四
在每个节点创建两个数据表，同一数据分片的两个副本位于不同节点上，实现数据分布与冗余，但是部署复杂度高。
总结
-
CH 的分片与副本功能完全靠配置文件实现，无法自动管理，所以当集群规模较大时，集群运维成本较高。
-
数据副本依赖 ZooKeeper 实现同步，当数据量较大时，ZooKeeper 可能会成为瓶颈。
-
如果资源充足，建议使用方案一，主副本和副副本位于不同节点，以更好地实现读写分离与负载均衡。
-
如果资源不够充足，可以使用方案四，每个节点承载两个副本，但部署方式上略复杂。
企业级应用实践如下：
ClickHouse 在携程酒店的应用（每天十亿级数据更新，秒出查询结果）
携程酒店数据智能平台实践（100亿+数据量，每天50W+查询）
性能提升 400%，ClickHouse 在携程酒店数仓的实践
携程-支撑 700 亿数据量的 ClickHouse 高可用架构实践
最快开源 OLAP 引擎！ClickHouse 在头条的技术演进
趣头条基于 ClickHouse 玩转每天 1000 亿数据量
微博基于 ClickHouse 灵活监控百亿流量下的业务指标
更多精彩内容欢迎关注微信公众号
880
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
