美团OCTO万亿级数据中心计算引擎技术解析
美团自研的 OCTO 数据中心（简称 Watt）日均处理万亿级数据量，该系统具备较好的扩展能力及实时性，千台实例集群周运维成本低于10分钟。
本文将详细阐述 Watt 计算引擎的演进历程及架构设计，同时详细介绍其全面提升计算能力、吞吐能力、降低运维成本所采用的各项技术方案。希望能给大家一些启发或者帮助。
一、OCTO数据中心简介
1.1 系统介绍
1.1.1 OCTO系统介绍
OCTO 是美团标准化的服务治理基础设施，目前几乎覆盖公司所有业务的治理与运营。OCTO 提供了服务注册发现、数据治理、负载均衡、容错、灰度发布等治理功能，致力于提升研发效率，降低运维成本，并提升应用的稳定性。OCTO 最新演进动态细节可参考《美团下一代服务治理系统 OCTO2.0 的探索与实践》一文。
1.1.2 OCTO数据中心业务介绍
OCTO 数据中心为业务提供了立体化的数字驱动服务治理能力，提供了多维度的精确时延 TP（Top Percent，分位数，最高支持6个9）、QPS、成功率等一系列核心指标，粒度方面支持秒级、分钟级、小时级、天级，检索维度支持多种复杂查询（如指定调用端 IP + 服务端各接口的指标，指定主机 + 接口的指标等）。这些功能有效地帮助开发人员在复杂的分布式调用关系拓扑内出现异常时，能快速定位到问题，也有助于研发人员全方位掌控系统的稳定性状况。
目前 Watt 承载日均超万亿条数据的10余个维度精确准实时统计。而伴随着数据量的迅猛增长，其整个系统架构也经历了全面的技术演进。
1.1.3 OCTO原架构介绍
OCTO计算引擎在重构之前，也面临诸多的问题，其原始架构设计如下：
- 采集层：每个业务应用实例部署一个采集代理，代理通过将采集数据用批量 RPC 的方式发送给路由节点。
- 路由层：每个路由节点随机收到各服务的数据后，将同一服务的所有数据，用类似 IP 直连的方式通过 RPC 发送到计算层的同一个计算节点。同服务数据汇总到同计算节点才能进行特定服务各个维度的聚合计算。
- 计算层：每个计算节点采用 Akka 模型，节点同时负责分钟、小时、天粒度的数据计算集。每个计算集里面又有10个子计算 actor，每个子计算 actor 对应的是一个维度。采用“先计算指标，再存储数据”的准实时模式。
- 存储层：准实时数据使用 HBase 存储，元数据及较大数据采用 KV 存储（美团内部系统Cellar）及 MySQL 存储。
1.2 问题、目标与挑战
1.2.1 原架构面临的问题
- 计算节点有状态，异常无法自动化迁移。计算层部署的每个节点平均负责200+服务的统计。一个节点 OOM 或宕机时，其管理的200个服务的数据会丢失或波动，报警等依托数据的治理功能也会异常。此外计算节点 OOM 时也不宜自动迁移受影响的服务，需人工介入处理（异常的原因可能是计算节点无法承载涌入的数据量，简单的迁移易引发“雪崩”），每周投入的运维时间近20小时。
- 系统不支持水平扩展。计算节点的压力由其管理的服务调用量、服务内维度复杂度等因素决定。大体量的服务需单独分配高配机器，业务数据膨胀计算节点能力不匹配时，只能替换更高性能的机器。
- 系统整体稳定性不高。数据传输采用 RPC，单计算节点响应慢时，易拖垮所有路由层的节点并引发系统“雪崩”。
- 热点及数据倾斜明显，策略管理复杂。按服务划分热点明显，存在一个服务数据量比整个计算节点200个服务总数多的情况，部分机器的 CPU 利用率不到10%，部分利用率在90%+。改变路由策略易引发新的热点机器，大体量服务数据增长时需要纵向扩容解决。旧架构时人工维护160余个大服务到计算节点的映射关系供路由层使用。
旧架构日承载数据量约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 计算，对资源的消耗非常较大，总结如下：
2.2 系统设计思路
- 解决稳定性问题，思路是（1）将计算节点无状态化（2）基于心跳机制自动剔除异常节点并由新节点承载任务（3）消息队列削峰。
- 解决海量数据计算问题，思路是（1）在线&离线计算隔离，两者的公共子计算前置只计算一次（2）高并发高吞吐能力设计（3）理论无上限的水平扩展能力设计。
- 解决热点问题，思路是（1）优化计算量分配算法，如均衡 Hash（2）理论无上限的水平扩展能力设计。
- 解决水平扩展问题，思路（1）是将单节点无法承载的计算模式改为局部分布式子计算并汇总，但这种方式可能会对数据准确性造成较大影响，数据统计领域精确的分布式分位数才是最难问题，另外多维条件组织对分布式改造也相当不利。（备注：其中在1.2.3第五条有详细的解释）
- 解决海量数据分布式多维精确 TP 计算，采用局部分布式计算，然后基于拓扑树组织数据计算流，在前置的计算结果精度不丢失的前提下，多阶段逐级降维得到所有的计算结果。
2.3 技术方案详细解析
2.3.1 数据流解析
系统根据待统计的维度构建了一棵递推拓扑树，如下图所示。其中黄色的部分代表消息队列（每个矩形代表一个 topic），绿色部分代表一个计算子集群（消费前置 topic 多个 partition，统计自己负责维度的数据指标并存储，同时聚合压缩向后继续发）。除“原始采集数据 topic 外”，其他 topic 和 consumer 所在维度对应数据的检索条件（如标红二级 topic ：主机+接口，代表同时指定主机和接口的指标查询数据），红色箭头代表数据流向。
拓扑树形结构的各个子集群所对应的维度标识集合，必为其父计算集群对应维度标识集合的真子集（如下图最上面链路，“主机+接口+远程服务”3个维度一定包含“主机+接口”两个维度。“主机+接口”两个维度包含“主机”维度）。集群间数据传输，采用批量聚合压缩后在消息队列媒介上通信完成，在计算过程中实现降维。
2.3.2 计算模式解析
下面详细介绍数据拓扑树中分布式子集群的计算模式：
首先，维度值相同的所有数据会在本层级集群内落到同一计算节点。每个计算子集群中的各计算节点，从消息队列消费得到数据并按自身维度进行聚合（前置集群已经按当前集群维度指定分发，所以聚合率很高），得到若干计数卡表（计数卡表即指定维度的时延、错误数等指标与具体计数的映射 Map）。
其次，将聚合后的计数卡表与现有的相同维度合并计算，并在时间窗口存储指标。
若计算集群有后续的子计算集群，则基于后继集群的目标维度，根据目标维度属性做散列计算，并将相同散列码的计数卡表聚合压缩后发到后继 partition。
离线的天级计算复用了三级维度、二级维度的多项结果，各环节前面计算的结果为后面多个计算集群复用，任何一个服务的数据都是在分布式计算。此外，整个计算过程中维护着技术卡表的映射关系，对于 TP 数据来说就是精确计算的，不会失真。
整个计算过程中，前置计算结果会被多个直接及间接后续子计算复用（如三级聚合计算对二级和一级都是有效的），在很大程度上减少了计算量。
2.3.3 关键技术总结
1. 高吞吐 & 扩展性关键设计
- 去计算热点：组织多级散列数据流，逐级降维。
- 降计算量：前置子计算结果复用，分布式多路归并。
- 降网络IO，磁盘IO：优化 PB 序列化算法，自管理 MQ 批量。
- 去存储热点：消除 HBase Rowkey 热点。
- 无锁处理：自研线程分桶的流批处理模型，全局无锁。
- 全环节水平扩展：计算、传输、存储均水平扩展。
2. 系统高可靠、低运维、数据准确性高于5个9关键设计
- 无状态化 + 快速自愈：节点无状态化，宕机秒级感知自愈。
- 异常实时感知：异常节点通过心跳摘除，异常数据迁移回溯。
- 故障隔离容灾：各维度独立隔离故障范围；多机房容灾。
- 逐级降维过程中数据不失真，精确的 TP 计算模式。
3. 提升实时性关键设计
- 流式拓扑模型，分布式子计算结果复用，计算量逐级递减。
- 无锁处理：自研线程分桶的流批处理模型，全局无锁。
- 异常实时监测自愈：计算节点异常时迅速 Rebalance，及时自愈。
- 秒级计算流独立，内存存储。
三、优化效果
- 目前日均处理数据量超万亿，系统可支撑日10万亿+量级并具备良好的扩展能力；秒峰值可处理5亿+数据；单服务日吞吐上限提升1000倍+，单服务可以支撑5000亿数据计算。
- 最大时延从4小时+降低到2min-，秒级指标时延 TP99 达到 6s；平均时延从4.7分+降低到1.5分-，秒级指标平均时延6s。
- 上线后集群未发生雪崩，同时宕机1/3实例2秒内自动化自愈。
- 支持多维度的准实时精确 TP 计算，最高支持到 TP 6个9；支持所有服务所有维度统计。
- 千余节点集群运维投入从周20小时+降低至10分以下。
四、总结
本文提供了一种日均超万亿规模下多维度精确 TP 计算的准实时数据计算引擎方案，适用于在超大规模数字化治理体系建设中，解决扩展性、实时性、精确性、稳定性、运维成本等问题。美团基础研发平台欢迎业界同行一起交流、探讨。
五、作者简介
继东，业祥，成达，张昀，均来自美团基础架构服务治理团队，研发工程师。
引言 美团搜索是美团 App 连接用户与商家的一种重要方式，而排序策略则是搜索链路的关键环节，对搜索展示效果起着至关重要的效果。目前，美团的搜索排序流程为多层排序，分别是粗排、精排、异构排序等 ...