简介

ClickHouse是一款优秀的OLAP分析引擎，尤其是在单表分析、Colocate Join方面性能表现尤为突出。ClickHouse之所以在众多的OLAP分析引擎中成为佼佼者，主要是因为它具备以下特点：列式存储、LSM-Tree存储引擎、向量化执行引擎、异步Merge和Mutation机制、并发MPP+ SMP等。

目前，ClickHouse在苏宁大数据的指标和标签的应用较多，从技术层面来看，主要解决的场景有：高基数的数据分析、精确去重、交互式分析、多变模式查询、大宽表分析、时序化数据存储、实时聚合的物化视图等。从业务层面来看，主要应用的场景有：新买家、老买家、复购、留存、实时用户画像、人群包圈选等。而基于ClickHouse的RoaringBitmap方案，保证了以上场景数据分析的实时和高效。

在ClickHouse监控方面，目前市面上提供的可适配方案不多，常用的有Prometheus +Grafana+ClickHouse_Exporter组合的方式，可通过提供的Dashboards来监控集群状况，但需要安装Prometheus和ClickHouse_Exporter，不编译的话还需要安装GO环境和Docker，整个框架过重，成本过高，对个性化的监控也不支持。还有一些其他监控组件如Graphite + Grafana，在这里就不做介绍。我们将ClickHouse融入苏宁全链路监控生态体系，在完善监控体系的同时，也支撑了个性化的监控，进一步拓展了全链路监控平台的深度和广度。

苏宁大数据全链路监控平台

1. 苏宁全链路监控平台介绍

图 2-1 全链路监控架构

苏宁大数据中心数据中台有一整套完善的指标建设体系，包含了指标生命周期管理、指标分析体系以及数据快速可视化平台，数据分析时跨越可视化平台、指标服务平台及OLAP分析引擎三大平台，查询链路较长，如果没有一套完整的全链路监控分析平台，对于定位问题会存在较大的困难。全链路监控整体的设计思想是将页面的每次http请求生成唯一的流水号(serialId)，后续每访问一次指标管理系统，生成唯一的traceId，每次调用OLAP接口生成唯一的olapId，这样就形成1个流水号对应多个traceId，关联对应后续多个olapId，形成一个树状请求，得到一个完整的请求链路。

具体设计如下：

（1）报表设计系统后端针对报表前端的每次请求生成唯一traceId，针对请求的每一步生成层级关系的spanId，并向指标管理系统透传traceId和对应的spanId。

（2）指标管理系统接受请求后，根据梳理的查询权重计算方式生成“查询权重”priority，在报表设计系统的spanId基础上继续生成调用层级关系的spanId，并向OLAP透传traceId和对应的spanId。

（3）Spark RDD实现将Druid、PostGreSQL和ClickHouse中的queryId与Spark worker中的StageID以及JobID关联起来。

（4）OLAP接受请求后，在指标管理系统的spanId基础上继续生成调用层级关系的spanId，并向OLAP引擎层透传traceId和对应的spanId。

（5）OLAP分析引擎层，通过打通traceId和各自分析引擎执行路径的方式，实现跟踪各执行计划、执行路径的耗时。例如，可通过bigQueryId与Druid关联，而PostGreSQL和ClickHouse则可以通过traceId映射到引擎内部的方式进行关联。

2. 如何实现将ClickHouse纳入到全链路监控平台

ClickHouse全链路监控覆盖范围较广，包括：查询涉及到的节点、分片、父查询和子查询的关系、在各个节点的查询耗时、请求内存使用、高峰使用内存、CPU使用数、查询行数、MergeTree使用状况、查询方式（TCP/HTTP）以及参与查询线程数等。

在调用ClickHouse提供服务查询（spark-jdbc）的时候，如何将traceId透传给ClickHouse的query_id呢?

实现全链路监控，主要是通过traceId贯穿整个链路。表system.processes和表system.query_log中的query_id是随机生成的，ClickHouse的query_id支持自定义，可将自定义的query_id映射到系统自生成的query_id上，这样ClickHouse内部的监控就能与全链路打通，具体操作如下：

ClickHouse-client --port 1***5 --time --format=Null --query="select count() from aggr_member" --query_id="suning20200706“ echo 'select count() from aggr***member' | curl 'http://localhost:8**3/?query_id=suning2020&query=' --data-binary @-

ClickHouse慢查询监控

1. 实时慢查询监控

图 3-1 实时慢查询监控

父节点查询ID(initial_query_id)是从上游系统传入的traceId，此次查询的所有子查询均可根据traceId获取，可以实时分析某次查询在集群中各个节点的状态，其中包括查询query_id的父子关系及对应的节点信息、各个节点的查询脚本、查询耗时、读取的行数、请求使用的内存、高峰使用的内存、参与查询的线程数、user、ProfileEvents、Settings等。

图 3-2 单次查询内存/CPU/MergeTree/耗时TOPN监控

图3-2 展示各集群中的慢查询TOPN、单次查询内存使用TOPN、单次查询CPU使用数TOPN、MergeTree耗时TOPN，支持对超过预期阈值的查询进行告警。

2. 历史慢查询监控

图3-3 历史慢查询监控

（1）ClickHouse默认的情况下query_log表是未开启的状态，必须将其开启，修改配置文件users.xml，路径为/etc/clickhouse-server/，新增配置项<log_queries>1</log_queries>，当查询日志服务器参数log_queries=1时，ClickHouse才会创建此表。

（2）每个查询在query_log表中会创建一条或两条记录，具体取决于查询的状态：

如果查询执行成功，则会分别创建事件类型为1和2的两条记录；
如果在查询处理期间发生错误，则会分别创建事件类型为1和4的两条记录；
如果在查询启动之前发生错误，则会创建事件类型为3的单条记录。

（3）表query_log中的记录，存储的是历史查询在集群中的各个节点的状态，其中包括查询query_id的父子关系及对应的节点信息、各个节点的查询脚本、查询开始时间、查询日期、查询时间、查询耗时、查询行数、查询结果的字节大小、请求使用的内存、高峰使用的内存、参与查询的线程数、堆栈跟踪以及查询异常信息等。

3. MergeTree监控

图3-4 MergeTree基础表引擎

MergeTree表中数据存储在Part中，当插入数据的时候，会将数据创建在一个新的Part中，Part的数量代表着提交的频率。后台会进行异步的Merge过程，将小的Part进行合并，并且会相对均衡的平衡好合并速度和Part数量的关系。对于每个Part均会生成一个索引文件，索引文件存储的是每个索引块数据主键的value值。对于MergeTree的监控，主要监控MergeTree的异常情况，根据异常信息进行告警。

4. 慢查询归因分析

通过以上的监控，可以快速定位出慢查询。导致慢查询的原因可能有很多，可以从如下几个方面进行分析：

1）判断查询的数据是否存在page cache中，从page cache获取数据速度远高于磁盘。

2）高基数的聚合或排序对查询效率影响较大，JOIN操作时应将小表放右边，分区字段不宜过多，导入数据时候最好对数据进行事先排序。

3）影响性能最关键的指标是CPU和内存，CPU超过70%则可能会出现大范围的查询超时。另外需要关闭虚拟内存，否则物理内存和虚拟内存可能会进行数据交换，从而导致查询变慢。

4）ClickHouse对高并发支持不太友好，需要对单个查询的资源加以限制，否则会影响当前其它查询的执行效率。

以上是常规的慢查询原因分析，而有些复杂、高基数的查询可通过巧妙的设计方式，达到高效查询的目标。我们在基于ClickHouse计算会员新买家、老买家数、复购、留存等场景的时候发现，如果用会员ID进行HASH分片后再做RoaringBitmap计算，最后再将每个分片的计算结果汇总，其执行效率将提高数倍。另外在计算纯新买家和次新买家的时候，通过在子查询中使用ClickHouse-CTE的WITH方式，同样可以达到实时、高效的查询目标。

ClickHouse集群状态监控

1. 集群、节点状态监控

可对集群、节点的查询状态进行监控，如成功次数、异常次数和失败次数，并且根据设定的阈值对失败或超时的查询进行预警。同时可对各个节点的连接数、CPU使用率、内存使用率、FileOpen、根分区使用率以及最大分区使用率进行监控。

2. 集群、节点、分片QPS和连接数监控

图 4-1 集群、节点、分片QPS监控

图 4-2 集群、节点、分片连接数监控

ClickHouse的计算和存储是一体式的，并未做资源隔离，为了提高系统的并发能力，可以将数据保存为多个副本，每个副本部署到不同的节点上，再通过Chproxy路由到不同的节点进行查询。为了保证集群的持续稳定、可用，需要对单个查询的资源以及集群最大支持的并发进行限制，具体方式如下：

1）集群同时支持的最大并发连接数可通过Max_Concurrent_queries来设置，默认为100。

2）一个查询在单台服务上最大使用的内存可通过Max_memory_usage来设置。

3）单个节点上所有查询的最大内存限制是可通过Max_memory_usage_for_all_queries来设置。

4）单次查询的最长执行时间可通过Max_execution_time来设置。

3. 集群、节点、分片可用性监控

具体可以通过HTTP API监视服务器的可用性来实现。通过HTTP GET请求后，如果服务器可用，则返回200 OK，否则返回异常消息。此处需要有个告警配置监控项，一旦监测到节点不可用，可及时通知相关技术人员进行维护，其中告警信息可通过短信、邮件等方式进行推送。

4. 全链路Replicas Delay监控

图 4-3 Replicas Delay监控

（1）Random分布式随机选取副本有四种算法：

Random：选取副本的默认方式，该算法主要是通过计算副本的错误数量，查询发送到出错最少的副本，但这种算法没有考虑到服务节点是否相邻的场景。
In order：选取副本的方式是根据配置中指定的顺序。
First or random：选择集合中第一个副本，如果第一个副本不可用，则随机进行副本选择。
Nearest hostname：每隔5分钟计算副本的错误数量，如果副本的错误数量最少，则将查询发送给它。

（2）副本允许的最长延迟时间，可通过参数max_replica_delay_for_distributed_queries来设置；副本的延迟时间，可以使用HTTP resource /replicas-delay来查询，不延迟则返回200 OK，延迟则返回和默认时间的差距。

5. 全链路Chproxy监控信息

图 4-4 ClickHouse Manger工作流程

ClickHouse的Http代理和负载均衡器是Chproxy，苏宁通过ClickHouse Manger来管理Chproxy组件的启动、停止、滚动升级以及监控，并通过ZK向Chproxy 同步配置数据。ClickHouse集群可以部署多个Chproxy实例，客户端连接ClickHouse集群的代理服务后，通过对查询SQL解析，智能的进行负载均衡。同时，Chproxy也支持水平扩展。

Chproxy能监控到的重点指标有：集群请求队列大小、远程客户端连接数、查询总请求数、取消请求数、被拒绝请求数、缓存命中情况、集群和节点健康状态等，苏宁全链路监控平台可对上述重点指标进行监控。

全链路监控的优势和展望

全链路监控平台拓展了我们监控系统能力的深度和广度，同时为ClickHouse的资源隔离和服务化提供了参考。全链路监控平台目前已经将数据应用层、SparkSQL解析层、OLAP路由加速层以及数据加速层全部贯穿，用户发起的请求在各个阶段的耗时一目了然。我们能把各个OLAP分析引擎内部执行的耗时，通过统一的queryId纳入到苏宁全链路监控平台，形成一条完整的执行耗时监控链路。各阶段预设的超时预警，会在第一时间通知相关责任人，这种方式对问题定位、主动预警都起到了重要的作用，同时给监控运维带来了极大的便利。

在OLAP路由层，我们已经对接了Druid、Elasticsearch、PostGreSQL以及ClickHouse分析引擎，后续我们将对接其它更多的OLAP分析引擎，如Doris、Dremio和RocksDB等，同时我们也将持续细化、分析各引擎内部执行阶段的耗时情况，对全链路监控能力进行更进一步的优化提升。

作者介绍：

范东，苏宁科技集团大数据中心资深架构师，在OLAP、OLTP领域有着深厚的技术积累。目前主要负责数据中台和数据工具平台的架构设计及性能调优工作，在数据中台、数据集成开发工具、数据资产、数据质量和数据治理等方面拥有丰富的实战经验。

创作场景

苏宁基于 ClickHouse 的大数据全链路监控实践