微信（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 的调用峰值。
业务特点
微信多维监控平台次要面对的业务特点有以下几个特点：
- 不须要保留明细数据，数据是根据指标的维度聚合的，只须要一个聚合模型。
- 以单表查问为主，也就是说每个协定都是独立的单表，也就是说不存在跨表查问。
- 高频查问的模式是比拟固定且容易预测的，一方面须要对若干个维度进行 TopN 的解决，比方一个模块，要对上报量进行 TopN 的操作，求出最大上报量的 3000 个模块，而后进行监控。另一方面是对于若干维度的工夫序列，也就是 GROUP BY time_minute。
基于以上三个特点，需要如下：
- 稳固低提早的数据导入能力，因为用户上报的需求量十分多。
- 反对聚合模型的 OLAP 引擎。
- 单表高并发，因为 OLAP 平台以单表查问为主，所以对单表查问的性能要求较高。并且因为异样检测须要实时的拉取很多维度组合的曲线，进行每分钟的监控解决，所以须要反对高并发。
- 依据数据特点设置索引，通过物化视图减速罕用查问。
原有架构
监控平台的协定十分多，数据场景也是多种多样。能够按两个维度分为四类：一是以数据量的大小来分，也就是它上报的原始数据量大略有多少。二是每分钟的维度复不简单，就是有多少个维度排列组合。两个维度组合后就有了四种分类，小的维度组合 + 比拟少的数据量，这部分占大多数；小的维度组合 + 大的数据量；维度组合简单 + 少的数据量；维度组合简单 + 大的数据量。面对这些数据场景，此前的架构如下图：
业务通过共享内存，把数据写入共享内存中，而后 Agent 会始终轮询这个共享内存的数据，再异步推给中控的 Proxy，由它进行采样、路由的操作。同时会在预处理层进行数据的预处理、加工等，把预处理后的数据发给长久化的 Kafka 队列。Kafka 队列中一小部分数据会被 Druid 间接生产。大部分的数据，会通过 Flink 进行预聚合，Flink 会以每 6 秒的粒度把明细数据进行聚合，而后从新写回 Kafka 供 Druid 生产。Druid 的数据通过数据层把它的数据查问进去，提供给 Web，后续提供给异样检测做告警解决。
痛点剖析
基于上述四种数据场景，在原有的架构中：
- 简略的维度组合 + 小的数据量，能够用 Druid 间接解决。
- 简略的维度组合 + 大的数据量，比方每分钟协定上报量大于 3000 万，然而它的维度组合也会绝对简略，比方只有 10 万 的维度组合，也能够通过 Flink 对它进行提前的预聚合解决，再导入 Druid。
- 简单的维度组合 + 小的数据量，比方它每分钟有 100 万、1000 万 甚至上亿这种量级的维度组合，间接用 Druid 解决会发现，它的数据查问是十分慢。
- 简单的维度组合 + 大的数据量，现有的伎俩无奈解决这类问题。
微信监控平台作为 Druid 的重度用户，在 Druid 在应用过程中存在的以下的痛点：
- 架构简单，有实时节点、历史节点、查问节点等 6 种不同类型的节点，同时须要依赖 MySQL、ZK、HDFS 等内部组件。
- Druid 只反对单维 RollUp，但没有物化视图概念，导致对于简单的维度，优化伎俩会绝对简单，须要本人去实现一套相似物化视图的成果。业务自行拆字表，并且在业务层匹配子表。
- 不可能自定义数据分区，某些查问场景无奈减速。Druid 是严格的工夫分区，Segment 严格依照工夫存储，也就相当于它的数据会依据工夫聚合在某一两台机上，如果数据诉求对工夫不是很敏感，性能体现会比拟差。
- Druid 对于高基数维度的查问性能差。尽管 Druid 对简略的维度查问性能十分高，并发能力的下限也很高，但对于维度基数比拟大，比方几千万个排列组合，它的慢查问会十分慢。总结下来就是维度复杂度高的场景下，Druid 的查问性能不能满足需要。
因而咱们尝试引入其余的 OLAP 平台。在调研过程中，咱们对 StarRocks 进行了充沛的调研和验证。StarRocks 的劣势有以下四点：
- 同时反对聚合模型和明细模型，监控需要次要以聚合模型为主的，局部明细查问为辅。
- 能够自定义分辨别桶，更容易针对数据特点做针对性优化，从而减速查问性能。
- 领有灵便的物化视图，罕用的大量级查问维度通常是固定的，能够通过物化视图进行聚合，可能晋升整体的查问性能。而且 StarRocks 主动匹配物化视图，无需业务自行通过代码逻辑判断。
- 高并发的查问能力。
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 将来会飞的更高。