您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
基于ClickHouse的大数据全链路监控平台实践
 
作者: 范东
  652  次浏览      50
 2021-7-2
 
编辑推荐:
本文主要介绍苏宁全链路监控平台设计,如何将 ClickHouse 纳入全链路监控平台,ClickHouse 集群状态监控,全链路监控的优势和展望,希望对您的学习有所帮助。
本文来自于搜狐网,由Alice编辑、推荐。

简介

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,形成一个树状请求,以此得到一个完整的请求链路。

具体设计如下:

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

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

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

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

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 历史慢查询监控

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

每个查询在 query_log 表中会创建一条或两条记录,具体取决于查询的状态:

如果查询执行成功,则会分别创建事件类型为 1 和 2 的两条记录;

如果在查询处理期间发生错误,则会分别创建事件类型为 1 和 4 的两条记录;

如果在查询启动之前发生错误,则会创建事件类型为 3 的单条记录;

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

3、MergeTree 监控

图 3-4 MergeTree 基础表引擎

MergeTree 表中数据存储在 Part 中,当插入数据的时候,会将数据创建在一个新的 Part 中,Part 的数量代表着提交的频率。后台会进行异步的 Merge 过程,将小的 Part 进行合并,并且会相对均衡的平衡好合并速度和 Part 数量的关系。

对于每个 Part 均会生成一个索引文件,索引文件存储的是每个索引块数据主键的 value 值。对于 MergeTree 的监控,主要监控 MergeTree 的异常情况,根据异常信息进行告警。

4、慢查询归因分析

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

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

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

影响性能最关键的指标是 CPU 和内存,CPU 超过 70% 则可能会出现大范围的查询超时。另外需要关闭虚拟内存,否则物理内存和虚拟内存可能会进行数据交换,从而导致查询变慢;ClickHouse 对高并发支持不太友好,需要对单个查询的资源加以限制,否则会影响当前其它查询的执行效率。

以上是常规的慢查询原因分析,而有些复杂、高基数的查询可通过巧妙的设计方式,达到高效查询的目标。

在基于 ClickHouse 计算会员新买家、老买家数、复购、留存等场景的时候发现,如果用会员 ID 进行 HASH 分片后再做 RoaringBitmap 计算,最后再将每个分片的计算结果汇总,其执行效率将提高数倍。

另外在计算纯新买家和次新买家的时候,通过在子查询中使用 ClickHouse-CTE 的 WITH 方式,同样可以达到实时、高效的查询目标。

三、ClickHouse 集群状态监控

1、集群、节点状态监控

可对集群、节点的查询状态进行监控,如成功次数、异常次数和失败次数,并且根据设定的阈值对失败或超时的查询进行预警。

同时可对各个节点的连接数、CPU 使用率、内存使用率、FileOpen、根分区使用率以及最大分区使用率进行监控。

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

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

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

ClickHouse 的计算和存储是一体式的,并未做资源隔离,为了提高系统的并发能力,可以将数据保存为多个副本,每个副本部署到不同的节点上,再通过 Chproxy 路由到不同的节点进行查询。

为了保证集群的持续稳定、可用,需要对单个查询的资源以及集群最大支持的并发进行限制,具体方式如下:

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

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

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

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

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

具体可以通过 HTTP API 监视服务器的可用性来实现。通过 HTTP GET 请求后,如果服务器可用,则返回 200 OK,否则返回异常消息。

此处需要有个告警配置监控项,一旦监测到节点不可用,可及时通知相关技术人员进行维护,其中告警信息可通过短信、邮件等方式进行推送。

4、全链路 Replicas Delay 监控

图 4-3 Replicas Delay 监控

Random 分布式随机选取副本有四种算法:

Random:选取副本的默认方式,该算法主要是通过计算副本的错误数量,查询发送到出错最少的副本,但这种算法没有考虑到服务节点是否相邻的场景;

In order:选取副本的方式是根据配置中指定的顺序;

First or random:选择集合中第一个副本,如果第一个副本不可用,则随机进行副本选择;

Nearest hostname:每隔 5 分钟计算副本的错误数量,如果副本的错误数量最少,则将查询发送给它。

副本允许的最长延迟时间,可通过参数 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 等,同时我们也将持续细化、分析各引擎内部执行阶段的耗时情况,对全链路监控能力进行更进一步的优化提升。

   
652 次浏览       50
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训
最新课程计划
 
最新文章
大数据平台下的数据治理
如何设计实时数据平台(技术篇)
大数据资产管理总体框架概述
Kafka架构和原理
ELK多种架构及优劣
最新课程
大数据平台搭建与高性能计算
大数据平台架构与应用实战
大数据系统运维
大数据分析与管理
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
北京 Python及数据分析
神龙汽车 大数据技术平台-Hadoop
中国电信 大数据时代与现代企业的数据化运营实践
更多...