美团网■美团OCTO万亿级数据中心计算引擎技术解析( 二 ) |技术|美好，一直在身边|MySQL|

旧架构日承载数据量约3000亿，受上述缺陷影响，系统会频繁出现告警丢失、误告警、数据不准、数据延迟几小时、服务发布后10分钟后才能看到流量等多种问题。此外，数据体量大的服务也不支持部分二级维度的数据统计。
1.2.2 新架构设计的目标
基于上述问题总结与分析，我们新架构整体的目标如下：

高吞吐、高度扩展能力。具备20倍+的水平扩展能力，支持日10万亿数据的处理能力。
数据高度精确。解决节点宕机后自愈、解决数据丢失问题。
高可靠、高可用。无计算单点，所有计算节点无状态；1/3计算节点宕机无影响；具备削峰能力。
延时低。秒级指标延迟TP99<10s；分钟指标延迟TP99<2min 。

1.2.3 新架构面临的挑战
在日计算量万亿级别的体量下，实现上述挑战如下：
1. 数据倾斜明显的海量数据，数据指标的维度多、指标多、时间窗口多，服务间体量差异达百万倍。
2. TP分位数长尾数据是衡量系统稳定性最核心的指标，所有数据要求非采样拟合，实现多维度下精确的分布式TP数据。
3. 架构具备高稳定性， 1/3节点宕机不需人工介入。
4. 每年数据膨胀至2.4倍+ ，计算能力及吞吐能力必须支持水平扩展。
5. TP 数据是衡量服务最核心的指标之一，但在万亿规模下，精确的准实时多维度分布式 TP 数据是一个难题，原因详细解释下：
常规的拆分计算后聚合是无法计算精确TP数据的，如将一个服务按 IP（一般按 IP 划分数据比较均匀）划分到3个子计算节点计算后汇总，会面临如下问题：

假设计算得出 IP1 的 TP99 是100ms、QPS 为50；IP2 的 TP99 是10ms、QPS 为50；IP3 的 TP99 是1ms ， QPS为50 。那么该服务整体 TP99 是（100ms x 50 + 10ms x 50 + 1ms x 50）/ (50 + 50 + 50) = 37ms吗？并非如此，该服务的真实 TP99 可能是 100ms ，在没有全量样本情况下无法保证准确的TP值。
假设不需要服务全局精确的时延 TP 数据，也不可以忽略该问题。按上述方式拆分并合并后，服务按接口维度计算的 TP 数据也失去了准确性。进一步说，只要不包含 IP 查询条件的所有 TP 数据都失真了。分位数这类必须建立在全局样本之上才能有正确计算的统计值。

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

本文插图
【美团网■美团OCTO万亿级数据中心计算引擎技术解析】
2.2 系统设计思路

解决稳定性问题，思路是（1）将计算节点无状态化（2）基于心跳机制自动剔除异常节点并由新节点承载任务（3）消息队列削峰。
解决海量数据计算问题，思路是（1）在线&离线计算隔离，两者的公共子计算前置只计算一次（2）高并发高吞吐能力设计（3）理论无上限的水平扩展能力设计。
解决热点问题，思路是（1）优化计算量分配算法，如均衡 Hash（2）理论无上限的水平扩展能力设计。
解决水平扩展问题，思路（1）是将单节点无法承载的计算模式改为局部分布式子计算并汇总，但这种方式可能会对数据准确性造成较大影响，数据统计领域精确的分布式分位数才是最难问题，另外多维条件组织对分布式改造也相当不利。（备注：其中在1.2.3第五条有详细的解释）
解决海量数据分布式多维精确 TP 计算，采用局部分布式计算，然后基于拓扑树组织数据计算流，在前置的计算结果精度不丢失的前提下，多阶段逐级降维得到所有的计算结果。
- 上一页
- 1
- 2
- 3
- 4
- 下一页