关于Mechademy

Mechademy监控着世界上一些最大的石油、天然气和能源公司的关键资产，包括全球6%的液化天然气产量，其中每次停机事件都可能造成数百万美元的损失。

他们的旗舰平台Turbomechanica将基于物理的涡轮机械模型与领域知识驱动的机器学习相结合，为压缩机、涡轮机和完整制冷列车构建混合数字孪生。这些数字孪生持续协调预期行为与观测行为，检测早期性能退化，并制定修复方案，将正常运行时间提高2-10%，在超过250万马力的设备群中实现约15倍的投资回报率。

挑战：从快速迭代到可扩展诊断

在Mechademy早期，任务很明确：构建一个能够模拟复杂工业资产真实行为并在机器学习和基于物理的引擎之间编排数据的平台，以创建真正的数字孪生。

在那个阶段，优先考虑的是速度和灵活性，而不是完美。重点是能够快速设计复杂的数据结构，这些结构可以表示设备行为并支持诊断假设的开发。目标是收集尽可能多的运营数据并进行实验，学习如何发展能够自动检测具有不同特征和时间模式问题的诊断方法。

基于这种理念，MongoDB完全符合需求。其灵活的文档模型允许在不断变化的数据结构上进行快速迭代，而无需严格的模式约束。结合MERN技术栈，它使团队能够快速行动，快速原型化想法，并专注于数据编排而不是数据库设计。

然而，随着诊断框架的成熟，数据模型本身成为了瓶颈。诊断测试开始需要多分辨率的时间对齐数据：15秒原始流、1分钟聚合数据和每小时汇总数据，具体取决于测试类型。由于MongoDB当时不支持原生时序数据，团队实施了手动分桶策略来模拟时序性能。随着时间的推移，这些变通方法膨胀成了深度嵌套的聚合管道，变得越来越脆弱且运行成本高昂。

曾经快速灵活的系统现在需要不断调优和维护才能保持性能。

扩展瓶颈

挑战不仅仅是架构上的，还包括运营和财务方面。随着诊断工作负载的扩展，MongoDB的资源利用率飙升。即使对于每半小时处理约10,000次测试的小型租户，CPU利用率也保持在95%以上，查询目标经常超过1,000次。

为了跟上需求，Mechademy在短短6-8个月内将集群从M20垂直扩展到M50，但每次升级只能带来有限的缓解空间。每个新的诊断功能都需要更复杂的查询和更高的性能阈值，导致了不可持续的扩展和重新设计循环。

此时，团队面临一个关键决策：继续通过迁移脚本、物化视图和批量汇总来修补架构，或者完全围绕原生时序原则重新设计数据层。

转型：从MongoDB到Tiger Data

迁移到Tiger Data并不是要替换NoSQL，而是将数据基础设施与Mechademy不断发展的使命重新对齐：高效、可靠且大规模地处理海量时序工作负载。

Tiger Cloud恰好提供了平台所需的功能：

• 原生时序支持：超表消除了手动分桶和模式维护，自动按时间和空间分区数据
• 连续聚合：自动汇总提供多分辨率数据，完美适用于具有不同时间范围的诊断测试
• 内置压缩：显著降低存储成本，同时提高查询性能
• 统一的SQL + Postgres熟悉度：使用标准、经过验证的查询语言简化了入门、调试和开发

这次转型还简化了周边架构。Mechademy引入了统一的数据摄取和编排层，使用DLT进行结构化数据加载，使用Celery进行分布式作业调度，使得来自多个来源的传感器数据可以被清理、转换并直接流式传输到Tiger Cloud。从那里，连续聚合和压缩处理数据保留和分辨率，无需手动干预。

曾经脆弱的管道网络变成了一个单一、可预测、自我管理的系统。

结果：从维护负担到可衡量的收益

结果立竿见影且具有变革性。

在曾经需要M50 MongoDB集群的同一租户上，Mechademy现在在相当于M20的TimescaleDB集群上每半小时处理1000万次诊断测试。

CPU和内存利用率保持稳定，维护开销接近于零，压缩显著降低了存储成本。

超表和连续聚合消除了大量的操作复杂性。添加具有新数据分辨率要求的新诊断测试现在只是一个简单的配置更改，而不是新的服务或迁移计划。

影响

• 基础设施成本降低87%
• 工作负载容量增加50倍（从每半小时20万次测试增加到1000万次测试）
• 通过超表和压缩实现近乎零的维护开销
• 统一的事务性+分析性工作负载，无ETL复杂性
• 可预测的性能扩展和极大简化的操作

展望未来

如今，Tiger Data作为Mechademy时序架构的基础，为从实时客户仪表板到大规模分析和诊断的所有功能提供支持。团队继续扩展其对压缩、分层存储和连续聚合的使用，并随着Tiger生态系统的发展探索托管数据湖集成。

从MongoDB到Tiger的转变不仅仅是一次技术迁移。这是一次战略转型。这次迁移使Mechademy能够从管理基础设施转向提供智能，在削减成本和复杂性的同时无缝扩展诊断能力。