1.4.1 ClickHouse用户都有哪些
目前国内ClickHouse社区火爆，很多大厂都在使用ClickHouse。
1.字节跳动
头条行为事件分析平台：有数千个ClickHouse节点，单个集群最多有1200个节点，总数据量达几十PB，原始数据每天增加约300TB。
电商EDMP圈选洞察引擎：使用ClickHouse Bitmap引擎做用户圈选、画像洞察分析，单日数据量达200TB，提供2000亿数据量查询秒级响应。把外部数据源接入引擎贴源层，通过一套统一模型构建流程将数据同步到ClickHouse、Elasticsearch等，然后基于这些计算引擎进行实时圈选预览洞察。
2.腾讯
用于游戏业务统计分析、微信用户分析、内部监控系统、留存分析系统等。例如，腾讯游戏数据化驱动服务平台iData、基于ClickHouse生态的微信实时BI分析看板等。
3.京东
业务离线流量数据分析平台EasyOLAP。EasyOLAP数据源主要为实时JDQ（Kafka Topic）、离线Hive数据。依赖ClickHouse官方JDBC，实时数据支持通过Flink导入，离线数据主要使用Spark job导入。
因为ClickHouse的主要瓶颈体现在并发性能上，即多副本集群多个节点故障会导致业务不可用，所以EasyOLAP选择了多副本和多活集群，启动了多活集群的方案，一份数据推多个集群，架构如图1-20所示。
图1-20 多活集群架构
在统一数据查询服务中，系统根据集群配置分配不同比例将查询下发到各个集群，大小查询分开，点查和批量查询分开，查一天和查一个月的分开，以提升服务整体QPS。
4.携程
日志分析系统。采用多分片、双副本的方式，通过ZooKeeper进行服务器间互相备份，可保障一个分片中的一台服务器宕机时数据不丢失。同时，借助ClickHouse分布式表的特性，实现跨集群搜索。携程有多个IDC，日志分布在不同的IDC。为了避免跨IDC搬迁日志，在每个IDC中都部署一套ClickHouse，然后配置ClickHouse的跨IDC的集群，创建分布式表，实现跨多个IDC数据搜索。
日志分析系统使用gohangout消费数据到ClickHouse。日志数据流如图1-21所示。
图1-21 日志数据流
日志数据写入流程如下。
1）采用轮询的方式写ClickHouse集群的所有服务器，保证数据基本均匀分布。
2）大批次、低频率地写入，减少数据分块（part）数量，减少服务器合并操作次数，避免“Too many parts”异常。通过两个阈值控制数据的写入量和频次，超过10万条记录时写一次或者每30秒写一次。
3）写本地表，不要写分布式表，因为分布式表接收到数据后会将数据拆分成多个part，并转发到其他服务器，引起服务器间网络流量增加、服务器合并的工作量增加，导致写入速度变慢，并且增加了异常的可能性。
4）建表时考虑分区（partition）的设置，之前遇到过有人将分区设置为timestamp，导致插入数据时一直报Too many parts的异常。我们一般以天为单位进行划分。
5）主键和索引的设置、数据的乱序等也会导致写入变慢。
下面是一些最佳实践。
慢查询：通过kill query命令终止慢查询的执行。
kill query命令语法如下：
Too many parts异常：该异常是由写入的part过多，但part的合并速度跟不上产生的速度导致的。导致part过多的主要原因如下：
❑设置不合理；
❑小批量、高频次写ClickHouse；
❑写的是ClickHouse的分布式表；
❑ClickHouse设置的合并线程数太少了。
小贴士：查看合并树表的数据part信息
使用下面的SQL语句可以查看MergeTree表的数据part信息：
输出如下：
无法启动：解决方案主要包括两个方面。
❑文件系统损坏，可以通过修复文件系统解决。
❑某一个表的数据异常导致ClickHouse加载失败，可以删除异常数据后启动，也可以把异常的文件搬到detached目录，等到ClickHouse重启后再挂载文件恢复数据。
在日志系统实际生产环境中，一个集群的日志数据量在100TB左右（压缩前600TB左右），ClickHouse相对Elasticsearch（以下简称ES）占用更少的内存。相比ES，ClickHouse至少可以节省60%的磁盘空间。在查询速度方面，ClickHouse比ES提升了4.4倍到38倍不等，基本解决了原来ES上查询不出来的问题。当然，ClickHouse毕竟不是ES，在很多业务场景中ES仍然不可替代。
携程酒店数据智能平台的整体架构如图1-22所示。
图1-22 携程酒店数据智能平台的整体架构
数据同步流程如图1-23所示。
图1-23 数据同步流程图
通过DataX直接导入ClickHouse。为保证线上的高可用，这里还做了重命名、增量数据更新等操作。
5.快手
ClickHouse on HDFS。ClickHouse作为一款高性能OLAP引擎，广泛应用在快手内部的报表系统、BI系统、用户行为分析、AB测试系统、监控系统等业务领域。随着ClickHouse集群的规模越来越大，原生ClickHouse扩展遇到了瓶颈，并且运维压力也很大。快手实现了ClickHouse on HDFS的架构，实现了计算和存储分离，海量数据的管理依靠成熟的HDFS系统，同时保留了ClickHouse优异的查询计算性能。ClickHouse on HDFS上线之后，可以轻松扩展ClickHouse的集群规模，实现在海量数据下的大规模推广应用。
ClickHouse在快手提供的服务包括支撑留存计算、AB测试、音视频分析、风控预警等。
另外，快手对ClickHouse开源社区贡献了Projection功能。
6.阿里
阿里云提供云数据库ClickHouse分布式实时分析型列式数据库服务（https://www.aliyun.com/product/clickhouse），具有高性能、开箱即用、企业特性支持，可应用于流量分析、广告营销分析、行为分析、人群划分、用户画像、敏捷BI、数据集市、网络监控、分布式服务和链路监控等业务场景。
（1）基于用户日志的多维分析和用户画像分析
基于用户行为日志数据进行多维分析，助力客户实现用户群体行为分析，支撑实时大屏等实时业务监控和实时运营。千亿规模数据分析30秒左右完成，亿级别数据中，95%的查询能5秒内返回。具备高吞吐能力，支撑高峰期每小时百亿日志数据的写入。该用户画像分析平台如图1-24所示。
图1-24 用户画像分析平台
（2）用户圈选和实时精准营销
基于用户的历史标签和实时标签数据进行用户圈选营销，提高客户召回率和DAU。相比传统分析方案，它的聚合分析性能可提升5～10倍，亿级规模大部分查询毫秒级完成。数据写入高效稳定，对比传统ES写入，可以避免OOM问题，写入速度达到50MB/s～200MB/s。用户圈选和实时精准营销平台如图1-25所示。
图1-25 用户圈选和实时精准营销平台
（3）广告投放人群预估和人群画像
基于大规模的多维度用户数据分析，分析广告投放条件命中的人群规模，评估广告投放成本。同时对投放对象进行人群画像，评估投放精准度和目标收益。在线分析广告人群，支持数量预估、画像洞察，亿级用户宽表数据分析秒级完成。广告投放人群预估和人群画像平台如图1-26所示。
图1-26 广告投放人群预估和人群画像平台
7.国外大厂
在国外，Yandex中有数百个节点用于用户单击行为分析，Cloudflare、Spotify等头部公司也在使用。它们对ClickHouse的使用情况如表1-8所示（来自ClickHouse官网）。
表1-8 国外公司对ClickHouse的使用情况
在社区方面，ClickHouse的GitHub Star的数量急剧增加（目前已超过21万）。