罗大伟
摘要:最近两年,国内很多中大型互联网企业都在倡导数字化转型,数据已经成为公司非常重要的资产,可以帮助企业做精准营销和商业决策。监控工具早先是做服务器监测,功能单一,现在已逐步发展为实时智能分析平台:采集请求源头到底层服务所有中间调用环节运行数据。监控平台提供丰富的全端埋点采集、时序指标聚合、报文解析、日志规整、全链路追踪、数据分析、自定义告警、报盘展示等功能。论文详细描述监控平台采集海量埋点明细上报ClickHouse以及埋点明细在监控平台的应用。
关键词:数字化转型;监控平台;ClickHouse
Abstract In the last two years,many medium and large Internet companies in China have been advocating digital transformation. Data has become a very important asset for companies,which can help them make precise marketing and business decisions. The monitoring tool,which started as a single-purpose server monitor,has evolved into a real-time intelligent analysis platform that collects data from the source of the request to all intermediate calls to the underlying service. The monitoring platform provides rich functions such as full-end sensor collection,timing metric aggregation,message parsing,log normalization,full-link tracking,data analysis,custom alarm,dashboard display and so on. The paper describes in detail the monitor platform to collect a large number of sensor details to report to ClickHouse and the application of sensor details in monitoring platform.
Key Words digital transformation,monitor platform,ClickHouse.
1引言
随着移动互联网和物联网时代的到来,微服务与全端产品盛行,企业越来越注重数据精细化治理,怎么从海量数据取提取有效的价值显得越来越重要。感知终端设备最常规做法使用监控工具在终端界面多处埋点,用户访问与操作设备时,埋点事件被触发。后端需要监测微服务与平台各方面运行流转情况,也需要做很多埋点。大批量的埋点明细数据需要供统计分析使用,落库存储需要选择一个简单、高效、适用的存储数据库。
ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)[4]。Yandex.Metric公司使用ClickHouse存储了超过20万亿行的数据,90%的自定义查询能够在1秒内返回[1]。ClickHouse数据表列与列之间由不同的文件保存,存储有较高的压缩比;有多样化的表引擎结构,十分靈活;既支持分区(纵向扩展,利用多线程),又支持分片(横向扩展,利用分布式),将多线程和分布式的技术应用到了极致;同时采用多主架构,规避了单点故障问题。计算机存储系统是一种层次结构,如图1所示,存储媒介距离CPU越近,则访问数据的速度越快,所以利用CPU向量化执行的特性,对于程序的性能提升意义非凡,ClickHouse利用SSE4.2指令集实现向量化执行。
业务系统接入监控埋点被触发有以下特征:
1)埋点事件触发不会再更改;
2)埋点明细字段事先定义类型明确,容易压缩;
3)业务系统多,埋点需求广泛,需要灵活加属性;
4)埋点触发不要求数据的绝对精准记录,不需要事务;
5)埋点数据尤其全埋点,大大高于页面浏览量,埋点触发数据量很大;
这些特征与ClickHouse的使用场景是高度吻合的。Clickhouse使用门槛较低,与mysql语法非常相似,容易上手。
本文重点介绍监控平台采集埋点触发信息后使用ClickHouse存储埋点明细数据表设计,以及埋点明细在监控指标的应用。
2埋点明细设计
对于海量数据的存储,需要很大的容量分布式部署,价格昂贵。ClickHouse数据默认使用LZ4算法压缩,在Yandex.Metrica的生产环境中,数据总体压缩比可以达到8:1(未压缩前17PB,压缩后2PB)。而经过笔者在生产环境几百亿行数据验证,埋点明细数据设计合理,压缩比可达到20:1,极大节省存储成本。
埋点明细基础字段设计如图2所示,其中session_id用于一段时间内用户行为、系统状况的统计。source用于记录埋点数据来源,采集来源主要有:服务端,移动端,Web小程序,数据仓库;微服务依赖的中间件。垂直业务部门系统作为第一级分类。一个垂直部门对应多个系统。系统下有多个微服务应用、手机与PC等前端应用,根据前后端不同的场景需求,建立第二级分类——埋点类型,埋点类型设置有:
1)页面类:移动端、WEB端、小程序页面;
2)接口类:中后台微服务接口,前台HTTP API;
3)事件类:自定义埋点事件被触发。
系统间隔离性比较强,按照系统建库,按照埋点类型建表,埋点明细表基础字段都相同,不同的是埋点分类的特性字段。
明细表PARTITION设置为一天一分区,使用toDate(occur_time)。OrderBy设置为(sensor_no,occur_time),每一个查询sensor_no是必须的where条件,锁定埋点;occur_time作为另一个必需条件,用于选择时间范围,按照ClickHouse存储特性设计能极大缩小范围。TTL设置为6个月过期,超过6个月的数据到数据中心归档。
一张埋点明细表包含基础字段、专有字段、业务自定义字段。基础字段是每一个埋点都包含的,不分系统与应用。专有字段是相同类型埋点都包含,按埋点类型进行区分。页面类/接口类/事件类都有自己的类型特性,比如说页面类有页面名称、页面深度、页面停留时长、上一级页面;接口类有url、method、执行时长、请求与响应长度,需要区分建表更好维护,一张明细表结构如图3所示:
埋点明细表字段个数并不是表定义好之后固定下来的,如图3所示,随着埋点业务属性配置变多,表的自定义字段会逐步增加。如果增加的业务属性已经在同一张明细表中被其他埋点定义,则直接复用,否则添加新列。ClickHouse可快速加列,随着埋点业务迭代,明细表会逐渐变成宽表。
3埋点明细上报流程
监控平台提供的客户端需要安装在应用工程中,才能完成应用内接入監控的工作。客户端采集应用的消息入队列,批量上报到采集消息服务器组中。服务器采集到消息列表经过格式化处理,以JSON形式压入kafka,利用kafka的积压能力存储消息,避免服务器出现问题消息丢失,同时kafka也是高吞吐的[3],传递消息性能很好。
后台消费服务会并发启动多个java线程,每次消费一批kafka消息,将消息处理后存入Redis进行短期聚合;按照埋点配置的指标,结合Redis数据,对齐InfluxDB存入分钟/小时/天级聚的数据。将消息明细按照系统与埋点类型做好分组,匹配好明细字段,批量写入ClickHouse不同的埋点明细表中。埋点明细上送的流程如下图4所示:
明细存储ClickHouse的逻辑会随着业务量的增长而改变。一张埋点明细表中的数据非常庞大,或者埋点存储不均匀,会影响到查询性能。可以指定几个埋点的数据做迁出,形成一张新表。新表放在本机或者外迁,在监控控台中设置埋点的路由。下次采集消息会读取新路由信息,按照新规则来写表。
ClickHouse的架构灵活,支持单节点、单副本、多节点、多副本多种架构[5]。遇到一个埋点的明细数据依然庞大,机器不能满足要求时,可将此表按照分片规则升级为Distributed分布式表,ClickHouse计算引擎利用多台机器的CPU资源来提高性能。
这样的操作会规避流量高峰期,操作前做好副本备份。迁表首先要先做好路由,按照路由逻辑设置双写(同时写原表与新表)。接着来迁移,迁移完成并确认数据无误后在监控控台取消埋点双写,摘除原表写入,最后删除原表已迁出的埋点。
4 Clickhouse在监控指标的应用
InfluxDB是支持时序数据高效读写、压缩存储、实时计算能力的数据库服务,具有成本优势的高性能读、高性能写、高存储率[2]。监控平台使用InfluxDB存储控台埋点配置的指标数据,按照分钟/小时/天级粒度聚合存储数据点Point,有非常好的查询性能,对于Grafana报盘图表展示也很友好。
Point存储包含measurement(指标:相当于一张表),tag(自定义属性)、value(指标值)、timestamp。指标基于埋点配置生成,需要配置聚合方式(在value和tag上求和/平均/总数/方差/中位值等),根据埋点用tag和value配置where过滤条件,按照指标实际需求拿tag做分组配置。InfluxDB指标数据的使用也遇到一些迫切需要解决的业务局限性:
1)指标是从埋点的指标配置成功后的下一分钟才开始聚合,没有历史时序数据,会有不少业务方想在报盘上能看到指标配置前的数据;
2)聚合好的数据准确性缺乏验证机制,如果业务方提出质疑,拿不出有效的证据来证明;
3)随着业务变化,指标也要更改,对已经存在的指标数据,配置更改后已经聚合的往往不准确,失去了本身的价值;
4)埋点下有多个配置好的指标,要根据这多个指标得到复合指标,根据多个指标的tag和value不能覆盖埋点明细全部数据,无法从指标角度快速解决问题。
如图5所示,我们可以从ClickHouse埋点明细数据为出发点,针对业务时序指标现有的几个重要问题,提供指定解决方案。
对于时序指标刚刚建立,历史数据缺失,使用以下的SQL即可拿到历史数据。
-- 以事件明细表为例,做求和聚合运算
-- 56是系统号 event代表事件
SELECT minute,sum(price)
FROM sensor_56_event
WHERE sensor_no=3721 AND
occur_time>=’2021-05-15 00:00:00’ AND
occur_time<’2021-05-16 00:00:00’
GROUP BY minute;
-- hour/date 也可按小时按天聚合通过SQL拿到ClickHouse聚合好的数据分别按天进行推进对齐写入InfluxDB的minute/hour/day的measurement中,完成数据回溯。
业务方对于陡增陡减的指标数据可能会持有怀疑态度,会来问为什么会出现这样的流量变化。为此需要给产品运营提供指标校准功能和短期明细数据在监控控台查阅权限。同时能够对核心指标(牵涉交易、积分等核心业务数据)进行核对校验。为此启动一个监控新服务应用,按照埋点明细的分钟级进行聚合查询,晚5分钟短期回溯校验指标数据,如何出现偏差,上送偏差分钟,供监控开发人员分析与解决问题。
业务场景变了,业务方通过监控控台更改指标配置,之前的数据可用ClickHouse重新聚合。
举个例子。A集群有100台服务器,指标1记录了A集群分钟级平均负载值,B集群有150台服务器,指标2记录了B级群平均负载值。现在要汇总AB平均负载,因为服务器在集群里个数分布并不均匀,不能将负载值相加除以2。新建指标在过滤条件写集群A或者B,的确能解决问题,但是下次需求变了,需要按照机器配置、所属事业部、数据要重新回溯比较麻烦,为此使用ClickHouse的SQL灵活聚合完成这样的复杂场景逻辑更加简单。
SELECT minute,cpu,department,sum(`score`)/ count(*)avg_score
FROM sensor_56_event
WHERE sensor_no=3721 AND
occur_time>=’2021-05-15 00:00:00’ AND
occur_time<’2021-05-16 00:00:00’ AND
cluster IN(‘A’,’B’)
GROUP BY minute,cpu,department;對于更加复杂与海量数据统计时,就超出InfluxDB适用范围了,InfluxDB超过3个以上的tag做分组,数据量大tag(订单号/用户id等)分组查询会比较慢,这样的综合场景可以使用ClickHouse也会遇到查询缓慢的现象。为此需要对复杂的SQL逐段拆解来做物化视图。物化视图相当于中间表,数据会根据主表数据变化写入实际存储中。根据物化视图再组装新SQL,会带来不少性能提升,简化了数据仓库建中间表的步骤。
对于复杂场景的数据分析做系统型精细管理,对ClickHouse表做建模。建立业务需要的分析维度表DIM(往往从离线数仓抽取),经过清洗的明细表DWD,轻度聚合DWD做DWS宽表(多个垂直业务线通用的实时汇总,例如统计当日活动的每个设备明细),个性化维度汇总分析出报表结果的ADS表。基于建模,能更好地完成行为分析、用户画像、漏斗分析等大数据分析需求。
5结语
本文基于监控平台埋点采集与指标聚合现状,设计埋点明细表结构,使用ClickHouse指标统计常见问题,解决了垂直失业部门使用监控工具遇到的各类技术问题,推动了数字化运营在公司的开展。
参考文献:
[1]朱凯 ClickHouse原理解析与应用实践 2020-06 ISBN:9787111654902.
[2]韩健 InfluxDB原理与实战 2020-05 ISBN:9787111651345.
[3]朱忠华 深入理解Kafka:核心设计与实践原理 2019-01 ISBN:9787121359026.
[4]Clickhouse官网中文手册 ©2016–2020 Yandex LLC https://clickhouse.tech/docs/zh/.
[5]云数据库ClickHouse © 2009-2021 Aliyun.com https://help.aliyun.com/document_detail/167449.html
上海汇付数据服务有限公司 上海 200030