乐趣区

关于数据库:微信-x-StarRocks大幅提升复杂维度分析场景高并发查询能力

微信(WeChat)是腾讯公司推出的一款面向智能终端的即时通讯软件。为用户提供聊天、朋友圈、微信领取、公众平台、微信小程序等性能,同时提供生存缴费、直播等服务。微信是全国用户数最多的手机利用,每天有超过 10 亿人应用。服务如此大用户规模的零碎,对于运维的挑战很大。传统的监控伎俩和思维曾经无奈应答如此海量的场景。微信技术架构部在充沛调研之后引入了 StarRocks。StarRocks 凭借其灵便的分桶和物化视图等个性,高效反对了微信多维监控平台的运行。

“作者:仇弈彬,
微信根底监控平台后盾工程师”

微信监控体系背景

微信的监控体系,次要分为三个方面:

框架级监控:自建了一个十分定制化的模块调用关系监控,这部分监控蕴含了模块的调用链、主调、背调、调用的均匀耗时以及失败等。

用户自定义指标监控:多用于用户自助上报业务状况,比方领取、商户的调用失败、微信上报音讯的成功率等。这部分次要有两个平台来实现。一个是固定维度的打点监控 (ID+Key)。用户须要本人去申请一个 ID,并且在 ID 下本人去定义 Key,但这套监控的适用范围比拟无限,只能监控一些比较简单的需要,因为它只有两个维度。另一种是比较复杂的监控需要。比方须要上报每个城市、每个运营商、每个错误码的一些上报状况,这样显然两个维度是无奈满足的,须要引入一套 OLAP 监控体系,也就微信多维监控。

微信外部在建设云原生可观测性平台:次要包含一些 Traces、Metrics、Logs,基于 OpenTelemetry 规范。

本文次要介绍 StarRocks 在微信多维监控平台的利用。

多维监控平台原架构及挑战

微信多维监控平台是一套基于多个维度灵便自助剖析的 OLAP 监控体系。对于微信多维监控平台,次要有以下三个比拟重要的概念。

协定,也就是用户自定义的监控表,它次要蕴含两个重要的信息。一个是维度,是反对分组过滤和聚合的字段。比方监控一些模块的调用状况,那么模块和 API 就是它的维度。另一个是指标,指标能够通过 Sum, Max, Min, Unique Count 等聚合。

视图,基于监控表的维度和指标,能够对它们进行排列组合,排列出各种各样的工夫曲线,从而形成监控视图供业务方进行问题的查问和定位。

异样检测平台,对指标下的一个或多个维度组合的工夫序列曲线,通过算法、阈值、稳定检测数据异样,从而帮忙业务及时收回告警,让业务及时关注本人的指标有没有出现异常。

业务规模

多维监控平台整体业务规模:

协定:3000 多个协定,也就是对应 3000 多个维度表。

数据量 :维度表的原始数据量十分大, 峰值数据达到 33 亿条 /min,3 万亿 / 天

并发量:异样检测平台调用,最高 33w/min 的调用峰值。

业务特点

微信多维监控平台次要面对的业务特点有以下几个特点:

  1. 不须要保留明细数据,数据是根据指标的维度聚合的,只须要一个聚合模型。
  2. 以单表查问为主,也就是说每个协定都是独立的单表,也就是说不存在跨表查问。
  3. 高频查问的模式是比拟固定且容易预测的,一方面须要对若干个维度进行 TopN 的解决,比方一个模块,要对上报量进行 TopN 的操作,求出最大上报量的 3000 个模块,而后进行监控。另一方面是对于若干维度的工夫序列,也就是 GROUP BY time_minute。

基于以上三个特点,需要如下:

  1. 稳固低提早的数据导入能力,因为用户上报的需求量十分多。
  2. 反对聚合模型的 OLAP 引擎。
  3. 单表高并发,因为 OLAP 平台以单表查问为主,所以对单表查问的性能要求较高。并且因为异样检测须要实时的拉取很多维度组合的曲线,进行每分钟的监控解决,所以须要反对高并发。
  4. 依据数据特点设置索引,通过物化视图减速罕用查问。

原有架构

监控平台的协定十分多,数据场景也是多种多样。能够按两个维度分为四类:一是以数据量的大小来分,也就是它上报的原始数据量大略有多少。二是每分钟的维度复不简单,就是有多少个维度排列组合。两个维度组合后就有了四种分类,小的维度组合 + 比拟少的数据量,这部分占大多数;小的维度组合 + 大的数据量;维度组合简单 + 少的数据量;维度组合简单 + 大的数据量。面对这些数据场景,此前的架构如下图:

业务通过共享内存,把数据写入共享内存中,而后 Agent 会始终轮询这个共享内存的数据,再异步推给中控的 Proxy,由它进行采样、路由的操作。同时会在预处理层进行数据的预处理、加工等,把预处理后的数据发给长久化的 Kafka 队列。Kafka 队列中一小部分数据会被 Druid 间接生产。大部分的数据,会通过 Flink 进行预聚合,Flink 会以每 6 秒的粒度把明细数据进行聚合,而后从新写回 Kafka 供 Druid 生产。Druid 的数据通过数据层把它的数据查问进去,提供给 Web,后续提供给异样检测做告警解决。

痛点剖析

基于上述四种数据场景,在原有的架构中:

  • 简略的维度组合 + 小的数据量,能够用 Druid 间接解决。
  • 简略的维度组合 + 大的数据量,比方每分钟协定上报量大于 3000 万,然而它的维度组合也会绝对简略,比方只有 10 万 的维度组合,也能够通过 Flink 对它进行提前的预聚合解决,再导入 Druid。
  • 简单的维度组合 + 小的数据量,比方它每分钟有 100 万、1000 万 甚至上亿这种量级的维度组合,间接用 Druid 解决会发现,它的数据查问是十分慢。
  • 简单的维度组合 + 大的数据量,现有的伎俩无奈解决这类问题。

微信监控平台作为 Druid 的重度用户,在 Druid 在应用过程中存在的以下的痛点:

  1. 架构简单,有实时节点、历史节点、查问节点等 6 种不同类型的节点,同时须要依赖 MySQL、ZK、HDFS 等内部组件。
  2. Druid 只反对单维 RollUp,但没有物化视图概念,导致对于简单的维度,优化伎俩会绝对简单,须要本人去实现一套相似物化视图的成果。业务自行拆字表,并且在业务层匹配子表。
  3. 不可能自定义数据分区,某些查问场景无奈减速。Druid 是严格的工夫分区,Segment 严格依照工夫存储,也就相当于它的数据会依据工夫聚合在某一两台机上,如果数据诉求对工夫不是很敏感,性能体现会比拟差。
  4. Druid 对于高基数维度的查问性能差。尽管 Druid 对简略的维度查问性能十分高,并发能力的下限也很高,但对于维度基数比拟大,比方几千万个排列组合,它的慢查问会十分慢。总结下来就是维度复杂度高的场景下,Druid 的查问性能不能满足需要。

因而咱们尝试引入其余的 OLAP 平台。在调研过程中,咱们对 StarRocks 进行了充沛的调研和验证。StarRocks 的劣势有以下四点:

  1. 同时反对聚合模型和明细模型,监控需要次要以聚合模型为主的,局部明细查问为辅。
  2. 能够自定义分辨别桶,更容易针对数据特点做针对性优化,从而减速查问性能。
  3. 领有灵便的物化视图,罕用的大量级查问维度通常是固定的,能够通过物化视图进行聚合,可能晋升整体的查问性能。而且 StarRocks 主动匹配物化视图,无需业务自行通过代码逻辑判断。
  4. 高并发的查问能力

StarRocks 性能测试

选型过程中咱们应用了平台实在的数据和场景对 StarRocks 的各项能力进行了测试。

数据导入能力测试

测试过程中应用实在的线上数据,通过应用 Kafka RoutineLoad 导入 JSON 数据格式。

机器配置:单机 48 物理核,超线程 96 核 (8255C),192G 内存,16T NVMeSSD;5 台机。

数据源(线上实在数据):导入速度是 5kw/min,均匀 1KB/ 条(JSON)。

测试过程:先把数据先导入 Kafka,积攒肯定工夫再启动生产,有助于压测 StarRocks 最大接入能力。

次要配置:routine_load_task_consume_second = 30;routine_load_task_timeout_second = 60;max_batch_rows = 20,000,000;desired_concurrent_number = 5。

测试后果:StarRocks 的体现还是十分优良的。通过上图能够看到,数据源导入量大略是 5000 万 /min,但实际上 StarRocks 的生产能力能够达到 2.1 亿 /min,这个数据远高于 Kafka 的写入速度,也完全符合咱们对数据接入能力的要求。

StarRocks 和 Druid 的查问测试比照

机器配置:单机 48 物理核,超线程 96 核(8255C),192G 内存,16T NVMeSSD;5 台机。

基数:高基数维度协定是维度排列基数(排除工夫维)1.15kw。

版本:StarRocks 1.18.1;Druid 0.20.0。

低并发测试后果

StarRocks 和 Druid 在低并发环境下,选取 4 个工夫序列 SQL 和 4 个一般维度 TopN SQL。每次查问进行 5 次,取平均值。对于优化方面,Druid 会全维度建设 RollUp,StarRocks 会建设物化视图。
整体体现如上表,能够看到有 7 个在低并发环境下 StarRocks 是优于 Druid 的,而这部分的数据特点就是维度比较复杂。针对于一个慢查问,也就是对于它高基维度分桶下的 TopN 查问,StarRocks 体现十分优异:5s 实现,Druid 须要 20s 左右。所以,在低并发环境下,StarRocks 的性能绝对于 Druid 有比拟大的晋升。

高并发测试后果

StarRocks 和 Druid 在高并发环境下,还是之前的 8 个 SQL,别离采纳 16 和 32 并发的状况去测试整体的 QPS 和均匀耗时,数据如上表。咱们能够看到在 16 次查问中,StarRocks 12 次均匀耗时优于 Druid,而且 16 次测试中,StarRocks 的 10 次 QPS 测试高于 Druid,2 个慢查问 Druid 和 StarRocks 都无奈在高并发环境下实现。

论断:对于简单协定,StarRocks 凭借着灵便的分桶和物化视图等个性,在绝对高并发环境下体现出了高于 Druid 的性能。同时咱们也发现 StarRocks 的并发能力和 CPU 强相干,CPU 使用率过高性能会升高,Druid 绝对会更稳固。

通过测试,比照 StarRocks 与 Druid 的优劣势。

StarRocks 在微信监控中的成绩

当初在微信监控体系中,整体的架构如上图。在计算和存储层,StarRocks 和 Druid 同时作为平台的存储和计算引擎。

目前 StarRocks 在微信多维监控平台,对于简单维度的协定剖析场景体现出了强于 Druid 的性能。所以咱们曾经将局部维度简单协定的实时计算和存储从 Druid 迁徙至 StarRocks,总体迁徙了 9 个协定,笼罩了微信领取、视频号、微信搜一搜、微信平安等产品。

StarRocks 接入的数 据量峰值曾经达到了 7kw/min,600 亿 / 天 的原始数据。通过 StarRocks,协定的均匀查问耗时 从 1200ms 优化到了 500ms 左右 ,对于慢查问的耗时, 从 20s 优化到了 6s

总结与瞻望

在微信多维监控平台,领有数以千计的数据源,每个数据源都有各自的特点。在实践中,Druid 和 StarRocks 在不同的场景下都各有千秋。StarRocks 的优良性能帮忙咱们解决了很多在原有 Druid 架构体系下较难解决的问题。将来咱们也会继续保留这两个 OLAP 引擎作为咱们的主力存储和计算引擎,同时咱们也会积极探索 StarRocks 在更多场景下的利用。

后续咱们冀望 StarRocks 在高并发,CPU 高负载的场景有进一步的性能晋升。将来公布的存储和计算拆散版本,也会在零碎稳定性上带来更大的改良。咱们置信 StarRocks 将来会飞的更高。

退出移动版