每日十万亿样本：Databricks超越传统监控基础设施的扩展实践
TL;DR · AI 摘要
Databricks构建了名为Pantheon的自研时序数据库，支撑每日10万亿监控样本，通过分层存储、指标聚合与Lakehouse集成，解决多云高基数场景下的扩展瓶颈。
核心要点
- 自研Pantheon基于Thanos改造，支撑每日10万亿样本与50亿活跃时序，降低云成本数百万美元。
- 引入指标聚合层屏蔽高基数挑战，保留调试能力，避免传统TSDB因标签爆炸而崩溃。
- 结合Lakehouse实现高维调试，将监控指标与数据湖中的日志、事件关联，提升故障根因定位效率。
结构提纲
按章节快速跳转。
Databricks每日处理10万亿监控样本，传统方案无法支撑多云、高基数与高 churn 环境。
基于Thanos改造的自研TSDB，支持跨3大云平台160+实例部署，实现高可用与低成本。
内存-磁盘-对象存储三级架构，兼顾实时查询性能与长期数据存储成本。
通过预聚合与降维减少TSDB负载，保留原始数据用于深度调试，平衡效率与可观察性。
将监控指标与数据湖中的日志、事件关联，实现跨层根因分析与AI辅助排查。
主动修复Thanos边缘问题并回馈社区，形成技术反哺与生态协同。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- Databricks十万亿级监控系统
- 核心架构
- Pantheon TSDB（基于Thanos）
- 分层存储：内存 → 磁盘 → 对象存储
- 关键技术挑战
- 高基数指标（标签爆炸）
- 跨3大云70+区域部署
- Serverless/AI工作负载高 churn
- 创新解决方案
- 指标预聚合层
- Lakehouse深度集成
金句 / Highlights
值得收藏与分享的关键句。
Migrating to Pantheon has allowed us to save millions of dollars in annual cloud costs, while reducing monitoring infrastructure downtime by ~5x and eliminating many sources of manual toil.
We could no longer process and store high-cardinality monitoring data as we always had, but we still aimed to maintain the debugging workflows relied on by engineers.
Enabling highly dimensional troubleshooting with the Databricks lakehouse allows engineers to correlate metrics with logs, traces, and data lineage in a single query.
Our largest instance hosts about 300 million in-memory timeseries and supports nearly 1,000 PromQL queries per second.
标题：每日十万亿样本：在 Databricks 超越传统监控基础设施的扩展之路
来源 URL：http://www.databricks.com/blog/10-trillion-samples-day-scaling-beyond-traditional-monitoring-infra-databricks
发布日期：2026-05-05T19:30:03+0000
Markdown 内容：
过去一年，Databricks 的监控基础设施规模增长了三倍以上，目前实时追踪 50 亿个活跃时间序列，每日摄入超过十万亿个样本。在如此庞大的规模下，我们发现现成的解决方案效率低下，或难以根据我们的需求进行定制。本文将分享我们构建的替代方案：一个可扩展的平台，它融合了开源监控生态系统的最佳实践，并深度集成了针对我们独特需求的定制化功能。
Databricks 的工程师依赖监控系统快速告警问题、自动化扩缩容与回滚，并支持智能故障排查。这些系统必须高度可靠，以确保我们在潜在事故中不会“盲目飞行”。然而，为 Databricks 的规模构建这一基础设施绝非易事：
- 除了可扩展性、可靠性和效率的要求外，我们的系统在全球约 70 个云区域运行，覆盖三大主流云厂商。我们需要在不同云平台乃至单个区域之间实现一致的性能表现。
- 面对如此广泛和多样化的部署，大规模基础设施的运维极易变得不可持续。系统必须尽可能“无人值守”——具备自愈和自扩缩能力，而非依赖值班工程师手动管理每个区域的堆栈，同时仍需为用户提供简洁的接口。
- 随着 Databricks 上无服务器和 AI 工作负载的增长，基础设施的变动率急剧上升，导致指标的基数（cardinality）迅速膨胀。我们已无法像以往那样处理和存储高基数监控数据，但仍需维持工程师依赖的调试工作流。
面对这些挑战，Databricks 旧有的监控栈存在诸多可靠性问题。我们着手构建一个全新的、可靠的平台，以满足工程师的期望。我们已成功解决三个关键问题：
- 构建一个可靠且高效的时间序列数据库（TSDB）
- 引入指标聚合，以保护 TSDB 免受高基数影响
- 利用 Databricks 湖仓实现高维故障排查
Thanos 时间序列数据库
什么是 TSDB？
TSDB 是传统监控系统架构的核心组件。这些专用数据库专为摄入大量时间序列指标数据并支持高 QPS、低延迟的实时读取而设计。它们特别适用于监控查询模式，如告警和仪表板刷新，这些场景需要反复执行相同的查询，并基于最新数据获得闪电般的响应。
Databricks 旧有的 TSDB 是为低一个数量级的规模设计的，近年来已成为我们的主要瓶颈。事实上，整个监控基础设施最大的可靠性问题正是 TSDB 的扩容困难。对许多公司而言，扩容是罕见操作，但鉴于 Databricks 的指数级增长，我们几乎每天都要进行一次。
因此，我们开发了一款名为 Pantheon 的新 TSDB，它是开源 CNCF Thanos 项目的分支。我们已在三大云厂商的所有区域成功部署了超过 160 个 Thanos 实例，总计约 50 亿个内存中活跃时间序列，每日摄入超过十万亿个样本。我们最大的实例托管约 3 亿个内存时间序列，支持每秒近 1000 次 PromQL 查询；同时我们也运行着 3 节点的小型部署，以及介于两者之间的各种规模。由于部署的广度、规模和多样性，我们经常发现 Thanos 的边缘情况和性能优化点，并将这些贡献回馈给开源社区。
迁移到 Pantheon 使我们每年节省数百万美元的云成本，同时将监控基础设施的停机时间减少了约 5 倍，并消除了大量手动运维负担。 下图展示了 Pantheon 的架构，以下章节将解释实现这些成果的关键设计决策。
存储架构
Thanos 的一个关键特性是其分层存储架构。最新时间序列数据保存在内存中，过去 24 小时的数据保存在磁盘上，更早的数据则存于对象存储中。这意味着告警和其他实时查询可以满足严格的性能要求，因为它们通常依赖最新数据。同时，借助对象存储，系统可实现计算与存储的解耦：集群扩容时无需在数据库节点间重新平衡所有历史数据。
这一架构解决了我们的核心瓶颈（扩容），并为 Pantheon 的成本节约奠定了基础。我们还应用了多项其他优化：
- 内存保留策略：我们部署了两组 Receive，分别采用不同的内存保留策略：一组针对持久化服务的长生命周期时间序列，保留两小时样本；另一组针对 Databricks 短生命周期的临时工作负载，仅保留 30 分钟样本。这种划分反映了我们在 Databricks 上观察到的无服务器工作负载生命周期，显著降低了内存占用和云成本，同时保持了数据准确性。
- Receive 组结构：每个组故意设计为三个独立的 Kubernetes StatefulSet，对应三个副本，而非单个大型哈希环。该设计保留了三副本加多数写入的复制机制，同时提供更强的操作与数据隔离性。在发布或节点轮换期间，我们可以并行滚动或重启整个 StatefulSet，而不会破坏多数共识或影响写入可用性，极大简化了日常运维。
- 多租户支持：Pantheon 利用 Thanos 的多租户功能，在不同 Receive 组中托管互不重叠的租户集合。在路由器层，我们通过基于规则的租户归属机制，通过检查指标名称和选定标签推断每个样本的租户。这使得同一写入批次中的样本可路由至不同租户——进而至不同 Receive 组——而无需修改上游客户端。
- 至少一次上传：为在保持正确性的同时进一步优化成本，三个 StatefulSet 中仅有两个将数据块上传至对象存储。这减少了冗余上传流量和云存储成本，同时通过复制和多数共识语义保障数据持久性与一致性。
Pantheon 控制平面
在我们的全球规模下，手动操作、尽力而为的 Kubernetes 自动化或原生 Thanos 行为均不足以胜任。每一次发布、扩缩事件或主机故障都必须安全、自动地处理，且尽量减少人工干预，同时保障多数共识和数据可用性。为此，Pantheon 引入了一个专门构建的控制平面，负责协调 Thanos 组件的生命周期和容量决策。它由三个核心控制器组成：
- 滚动发布操作器（Rollout Operator）：协调三个隔离的 Receive StatefulSet 的发布与扩缩，确保读写操作的多数共识。它通过并行更新 StatefulSet 实现更快的发布，确保任意时刻最多只有一个副本不可用。
- 哈希环控制器（Hashring Controller）：管理哪些 Receive 端点对路由器可见。只有健康且完全就绪的 Pod 才会被加入哈希环，缩容或维护时的移除操作是分阶段进行的。这将流量管理与 Pod 生命周期解耦，防止在动态集群变更时意外破坏多数共识或造成部分路由失效。
- 自动扩缩与自愈控制器（Autoscaling and Self-Healing Controller）：基于 Pantheon 特有的摄入量和资源压力进行集群扩缩，而非依赖通用的 Kubernetes 指标。内置的自愈系统持续检测并修复常见故障模式——如故障主机、过载 Pod 或损坏的 WAL——使系统能在无需人工干预的情况下自我恢复。在我们的规模下，这些自动化机制每周会触发数十次。
基数与聚合
什么是基数？为何它如此重要？
指标所有者常添加节点 ID 或 Pod ID 等标签，以帮助在特定维度上调试问题并更快缓解事故。然而，这引发了一个经典的可观测性挑战：管理基数。一个指标的基数是指其标签所有唯一组合的数量。如果你监控的 Pod 数量增加 10 倍，任何包含 Pod ID 标签的指标基数也会增加 10 倍。基数是 TSDB 的主要扩展因子，现有指标基数的增长会推高成本并加剧 Pantheon 的扩缩压力。
快速增长的基础设施是我们 Databricks 的“幸福烦恼”。随着客户群和产品使用量的显著增长，许多客户近期采用了我们的无服务器计算架构，我们的无服务器计算平台每日启动数千万台虚拟机。随着更多工作负载转向无服务器，我们监控的基础设施变动率更高，这些标识符标签的生命周期也持续缩短。
这导致基数急剧膨胀，侵蚀了 Pantheon 带来的可扩展性与成本收益。因此，我们必须更聪明地决定存储哪些指标数据。这就是“聚合”发挥作用的地方：在摄入阶段丢弃无服务器系统中的昂贵标签，同时仍为服务所有者提供聚合的全 fleet 视图。一套自动化的指标聚合策略使我们成功“弯曲了基数增长曲线”，确保监控基础设施的扩展速度不会快于 Databricks 的其余部分。
聚合架构
在大规模下构建可靠的聚合基础设施极具挑战，因为它是有状态的。管理数百万输入计数器的聚合器必须能正确处理重置——如果某个输入时间序列消失，聚合输出值应持续单调递增，而非下降。当指标分布在多个聚合器之间时，你还必须处理 Pod 重启和负载不均等场景。
这些问题通常通过使用 Kafka 等消息系统进行分区分配和维持历史数据来解决；但在我们的规模下，这成本高昂，并引入了影响实时用例的摄入延迟。另一种方法是在聚合器中存储内存状态，并在聚合器之间重路由指标以遵守分配规则。然而，这会导致聚合器重新部署时数据丢失；在我们聚合基础设施的初始版本中，这种行为使聚合指标对用户几乎无法理解。
为实现无缝运行，我们转而开发了自己的聚合系统，结合了 Telegraf 和 Databricks 的“自动分片器”服务 Dicer。该架构采用智能粘性路由，而非在聚合器之间重路由指标，从而解决了重新部署时的故障模式。结合我们在 Telegraf 上添加的其他优化，我们已将该流水线扩展至最大区域超过 1GB/s 的吞吐量和数千条聚合规则。
这一新的聚合流水线有效成为保护我们 TSDB 的盾牌，使我们能够将高基数指标的摄入量降低 90% 以上，同时仍为工程师提供足够精细的聚合视图用于调试。聚合后的数据被写入 Pantheon，其基数已大幅降低，从而显著减轻了存储和查询压力。我们正在将这一架构推广至更多指标类型，并计划开源 Dicer，以帮助更广泛的社区应对高基数挑战。