美团自研的OCTO数据中心(简称Watt )每天处理1万亿级数据量，该系统具有良好的扩展能力和实时性，千个实例集群的每周运输成本不足10分钟。
本文详细阐述了Watt计算引擎的演化历史和结构设计，同时详细介绍了为全面提高计算能力、吞吐量能力，降低运输成本而采用的各项技术方案。 希望大家能给予启发和帮助。
一、OCTO数据中心简介
1.1 系统介绍
1.1.1 OCTO系统介绍
OCTO是美国团体标准化的服务管理基础设施，目前几乎涵盖了公司所有业务的管理和运营。 OCTO提供服务注册发现、数据管理、负载平衡、容错、灰度发布等管理功能，致力于提高研发效率、降低运输成本、提高APP的稳定性。 OCTO最新进展动态详情可参考《美团下一代服务治理系统 OCTO2.0 的探索与实践》文。
1.1.2 OCTO数据中心业务介绍
OCTO数据中心为业务提供立体化数字驱动服务管理能力，提供多维精确延迟TP (顶级，分位数，最多6个9 )、QPS、成功率等一系列核心指标，在粒度上支持秒级、分级、时间级、日级搜索维度中多种复杂查询)例如支持调用方IP服务端各接口的指标并指定主机的这些功能，在复杂的分布式调用关系拓扑中开发者发生异常时，可以有效地快速识别问题，帮助开发者识别系统
目前，Watt是每天承载1万亿件以上数据的10多个维度的准确准实时统计。 随着数据量的迅猛增长，整个系统体系结构也经历了全面的技术演进。
1.1.3 OCTO原架构介绍
OCTO计算引擎在重构前也面临着很多问题，原始体系结构的设计如下。
采集层:为每个业务APP应用实例配置收集代理，将收集到的数据通过批量RPC发送到路由节点。
路由层:在每个路由节点随机接收了每个服务的数据之后，通过RPC将同一服务的所有数据发送到计算层的同一计算节点，如IP直接连接。 该服务数据聚合到该计算节点，允许对特定服务的各个维进行聚合计算。
计算层:各计算节点采用Akka模型，节点同时负责分、时、日粒度的数据计算集。 每个计算集中还有10个子计算加速器，每个子计算加速器对应一个维。 采用“计算指标后保存数据”的准实时模式。
存储层:准实时数据使用HBase存储，元数据和比较大数据使用KV存储(美团内部系统Cellar )和MySQL存储。
1.2 问题、目标与挑战
1.2.1 原架构面临的问题
计算节点有状态，异常无法自动化迁移计算层配置各节点平均负责200个服务的统计。 如果一个节点OOM或宕机，它管理的200台服务器将会丢失或波动数据，基于报警等数据的治理功能也会异常。 另外，计算节点OOM时也不应该自动迁移受影响的服务，需要人工干预处理(异常的原因可能是计算节点不能承载流入的数据量，简单的迁移容易引起“雪崩”)，周
系统不支持水平扩展计算节点的压力取决于管理的服务呼叫量、服务中的维度复杂性等因素。 大多数量的服务需要分别分配高性能的机器，当业务数据膨胀导致计算节点能力不匹配时，只能更换更高性能的机器。
系统整体稳定性不高由于采用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 计算的准实时数据计算引擎方案，适用于在超大规模数字化治理体系建设中，解决扩展性、实时性、精确性、稳定性、运维成本等问题。美团基础研发平台欢迎业界同行一起交流、探讨。
五、作者简介
继东，业祥，成达，耍酷的手套，均来自美团基础架构服务治理团队，研发工程师。
---------- END ----------
招聘信息
美团基础架构团队诚招高级、资深技术专家，Base 北京、上海。我们致力于建设美团全公司统一的高并发高性能分布式基础架构平台，涵盖数据库、分布式监控、服务治理、高性能通信、消息中间件、基础存储、容器化、集群调度等基础架构主要的技术领域。欢迎有兴趣的同学投送简历到 tech@meituan.com（邮件标题注明：美团基础架构团队）。
也许你还想看
美团下一代服务治理系统 OCTO2.0 的探索与实践
美团大规模微服务通信框架及治理体系OCTO核心组件开源
美团容器平台架构及容器技术实践