美团OCTO万亿级数据中心计算引擎技术解析

   日期:2024-11-07     作者:caijiyuan       评论:0    移动:http://oml01z.riyuangf.com/mobile/news/2315.html
核心提示:2020年 第14篇美团自研的 OCTO 数据中心(简称 Watt)日均处理万亿级数据量,该系统具备较好的扩展能力及实时性,千台实例集群周

2020年 第14篇

美团OCTO万亿级数据中心计算引擎技术解析

美团自研的 OCTO 数据中心(简称 Watt)日均处理万亿级数据量,该系统具备较好的扩展能力及实时性,千台实例集群周运维成本低于10分钟。

本文将详细阐述 Watt 计算引擎的演进历程及架构设计,同时详细介绍其全面提升计算能力、吞吐能力、降低运维成本所采用的各项技术方案。希望能给大家一些启发或者帮助。

一、OCTO数据中心简介

1.1 系统介绍

1.1.1 OCTO系统介绍

OCTO 是美团标准化的服务治理基础设施,目前几乎覆盖公司所有业务的治理与运营。OCTO 提供了服务注册发现、数据治理、负载均衡、容错、灰度发布等治理功能,致力于提升研发效率,降低运维成本,并提升应用的稳定性。OCTO 最新演进动态细节可参考《》一文。

1.1.2 OCTO数据中心业务介绍

OCTO 数据中心为业务提供了立体化的数字驱动服务治理能力,提供了多维度的精确时延 TP(Top Percent,分位数,最高支持6个9)、QPS、成功率等一系列核心指标,粒度方面支持秒级、分钟级、小时级、天级,检索维度支持多种复杂查询(如指定调用端 IP + 服务端各接口的指标,指定主机 + 接口的指标等)。这些功能有效地帮助开发人员在复杂的分布式调用关系拓扑内出现异常时,能快速定位到问题,也有助于研发人员全方位掌控系统的稳定性状况。

目前 Watt 承载日均超万亿条数据的10余个维度精确准实时统计。而伴随着数据量的迅猛增长,其整个系统架构也经历了全面的技术演进。

1.1.3 OCTO原架构介绍

OCTO计算引擎在重构之前,也面临诸多的问题,其原始架构设计如下:

1.2 问题、目标与挑战

1.2.1 原架构面临的问题

旧架构日承载数据量约3000亿,受上述缺陷影响,系统会频繁出现告警丢失、误告警、数据不准、数据延迟几小时、服务发布后10分钟后才能看到流量等多种问题。此外,数据体量大的服务也不支持部分二级维度的数据统计。

1.2.2 新架构设计的目标

基于上述问题总结与分析,我们新架构整体的目标如下:

1.2.3 新架构面临的挑战

在日计算量万亿级别的体量下,实现上述挑战如下:

1. 数据倾斜明显的海量数据,数据指标的维度多、指标多、时间窗口多,服务间体量差异达百万倍。

2. TP分位数长尾数据是衡量系统稳定性最核心的指标,所有数据要求非采样拟合,实现多维度下精确的分布式TP数据。

3. 架构具备高稳定性,1/3节点宕机不需人工介入。

4. 每年数据膨胀至2.4倍+,计算能力及吞吐能力必须支持水平扩展。

5. TP 数据是衡量服务最核心的指标之一,但在万亿规模下,精确的准实时多维度分布式 TP 数据是一个难题,原因详细解释下:

常规的拆分计算后聚合是无法计算精确TP数据的,如将一个服务按 IP(一般按 IP 划分数据比较均匀)划分到3个子计算节点计算后汇总,会面临如下问题:

二、计算引擎技术设计解析

2.1 方案选型

大数据计算应用往往基于实时或离线计算技术体系建设,但Flink、Spark、OLAP等技术栈在日超万亿级别量级下,支持复杂维度的准实时精确 TP 计算,对资源的消耗非常较大,总结如下:

2.2 系统设计思路

2.3 技术方案详细解析

2.3.1 数据流解析

系统根据待统计的维度构建了一棵递推拓扑树,如下图所示。其中黄色的部分代表消息队列(每个矩形代表一个 topic),绿色部分代表一个计算子集群(消费前置 topic 多个 partition,统计自己负责维度的数据指标并存储,同时聚合压缩向后继续发)。除“原始采集数据 topic 外”,其他 topic 和 consumer 所在维度对应数据的检索条件(如标红二级 topic :主机+接口,代表同时指定主机和接口的指标查询数据),红色箭头代表数据流向。

拓扑树形结构的各个子集群所对应的维度标识集合,必为其父计算集群对应维度标识集合的真子集(如下图最上面链路,“主机+接口+远程服务”3个维度一定包含“主机+接口”两个维度。“主机+接口”两个维度包含“主机”维度)。集群间数据传输,采用批量聚合压缩后在消息队列媒介上通信完成,在计算过程中实现降维。

2.3.2 计算模式解析

下面详细介绍数据拓扑树中分布式子集群的计算模式:

首先,维度值相同的所有数据会在本层级集群内落到同一计算节点。每个计算子集群中的各计算节点,从消息队列消费得到数据并按自身维度进行聚合(前置集群已经按当前集群维度指定分发,所以聚合率很高),得到若干计数卡表(计数卡表即指定维度的时延、错误数等指标与具体计数的映射 Map)。

其次,将聚合后的计数卡表与现有的相同维度合并计算,并在时间窗口存储指标。

若计算集群有后续的子计算集群,则基于后继集群的目标维度,根据目标维度属性做散列计算,并将相同散列码的计数卡表聚合压缩后发到后继 partition。

离线的天级计算复用了三级维度、二级维度的多项结果,各环节前面计算的结果为后面多个计算集群复用,任何一个服务的数据都是在分布式计算。此外,整个计算过程中维护着技术卡表的映射关系,对于 TP 数据来说就是精确计算的,不会失真。

整个计算过程中,前置计算结果会被多个直接及间接后续子计算复用(如三级聚合计算对二级和一级都是有效的),在很大程度上减少了计算量。

2.3.3 关键技术总结

1. 高吞吐 & 扩展性关键设计

2. 系统高可靠、低运维、数据准确性高于5个9关键设计

3. 提升实时性关键设计

三、优化效果

四、总结

本文提供了一种日均超万亿规模下多维度精确 TP 计算的准实时数据计算引擎方案,适用于在超大规模数字化治理体系建设中,解决扩展性、实时性、精确性、稳定性、运维成本等问题。美团基础研发平台欢迎业界同行一起交流、探讨。

五、作者简介

继东,业祥,成达,张昀,均来自美团基础架构服务治理团队,研发工程师。

 
特别提示:本信息由相关用户自行提供,真实性未证实,仅供参考。请谨慎采用,风险自负。

举报收藏 0打赏 0评论 0
 
更多>同类最新资讯
0相关评论

相关文章
最新文章
推荐文章
推荐图文
最新资讯
点击排行
{
网站首页  |  关于我们  |  联系方式  |  使用协议  |  隐私政策  |  版权隐私  |  网站地图  |  排名推广  |  广告服务  |  积分换礼  |  网站留言  |  RSS订阅  |  违规举报  |  鄂ICP备2020018471号