Moovit通过架构现代化实现33%成本优化

Moovit，隶属于Mobileye（纳斯达克：MBLY），是领先的出行即服务（MaaS）解决方案提供商，也是领先城市出行应用的创造者。Moovit的iOS、Android和Web应用为用户提供智能出行体验，使其能够使用任何公共和共享交通方式到达目的地。公交乘客可以利用移动售票来规划、支付并乘坐公交服务。Moovit于2012年推出，现已在112个国家的超过3500个城市以45种语言为超过17亿用户提供服务。

在这些面向用户的体验背后，是一个处理大量出行、应用和运营数据的数据平台，以支持产品分析、商业智能（BI）、监控和数据科学。随着平台的发展，Moovit需要保持分析工作负载的可靠性和成本效益，同时不拖慢每天依赖最新数据的团队。

多年来，Moovit的Amazon Redshift集群持续增长。它始于不断扩展的DC2节点群，迁移到RA3节点，并多次扩展以跟上数据需求的增长，最终成为其整个数据平台的支柱。

为应对这种增长，Moovit通过构建最佳的多引擎湖仓架构，并将每个工作负载分配到最合适的选项，来转型其数据架构。这次现代化将其Amazon Redshift集群减少了50%，同时建立了一个灵活、多引擎架构，为未来用例做好准备。

在这篇文章中，我们分享Moovit如何获得工作负载模式的可见性、清理不必要的负载、选择要卸载的候选工作负载，并在Amazon EMR Serverless上成功进行概念验证（POC）。Moovit最终在多个引擎之间分配工作负载，构建了一个现代且成本优化的数据平台，结合了预留的Amazon Redshift、Amazon Redshift Serverless和Amazon EMR。

挑战：超越单引擎数据平台

Amazon Redshift引擎处理了各种各样的工作负载，包括：

• 繁重的ETL处理： 从Amazon Simple Storage Service（Amazon S3）摄取原始数据，然后进行复杂的聚合管道（每日运行一次、具有3天回看期的每日用户聚合，以及每周10天回看期的作业）。
• 近实时运营监控： 每20分钟对原始数据执行的查询，用于系统健康仪表板。
• 商业智能报告： Tableau提取和实时仪表板。
• 数据科学工作负载： 探索性分析和模型特征工程。
• 临时分析： 分析师和工程师进行的非经常性查询。

随着业务增长，存储在过去十年中增长了几个数量级，平台也随之扩展。所有这些不同的工作负载在同一个引擎上竞争，并将其推向极限。作业遇到越来越多的排队时间，服务水平协议（SLA）面临风险，添加节点带来的性能提升微乎其微，因此产生了隔离工作负载的需求。

获得可见性：衡量工作负载影响

Moovit的现代化第一个里程碑是在更改任何工作负载之前建立可信的测量基础。团队没有将仓库活动视为一个单一的不透明流，而是实现了自动化查询归因，持续将每个查询按照工作负载所有者和执行上下文进行分类。该分类结合了多个信号：执行查询的用户（用户或服务账户）、可识别的查询签名模式，以及编排框架和调度进程发出的元数据。

这产生了一份历史性的查询级平台使用映射，回答了三个关键问题：谁在产生负载，什么 种类的工作负载在运行，以及每个工作负载在运行时间和资源方面有多昂贵。有了这个基线，团队基于证据而非假设做出卸载决策。这种方法优先考虑最大且最稳定的优化机会，并降低了在缺乏可见性的情况下移动关键业务工作负载的风险。

这些分类和工作负载指标反映在一份Tableau报告中，该报告按分类标签和执行上下文聚合查询活动。该视图暴露了操作维度，如分类、时间粒度、服务类、执行时间桶、卸载标志和样本查询上下文，支持趋势监控和根本原因下钻。

该工作表参数化以支持对相同分组工作负载群体的多种测量模式：总执行时间、执行时间加排队时间、总CPU时间、平均每查询执行时间，以及基于比率的效率视图（执行/CPU和CPU/执行）。这让团队能够比较“按数量算重的”工作负载和“按行为算低效的”工作负载，而无需创建单独工件。

对于决策，CPU时间被用作主要影响指标，因为它最能代表持续的计算压力。执行时间、排队时间、查询计数归一化和工作负载管理分段被视为次要证据，以区分：

• 计算重但健康的工作负载
• 受队列约束的工作负载
• 高频率/低成本工作负载
• 嘈杂或分类较弱、需要先进行归因清理的工作负载

使用这个框架，优先级划分变得系统化：首先提高分类覆盖率，然后按CPU贡献对工作负载进行排名，再用队列和工作负载管理（WLM）信号进行验证，最后为每个工作负载选择行动路径（优化SQL、重新调度、隔离、停用或转移到另一引擎）。

下图展示了仪表板小部件的一个示例（按查询的CPU时间）。

图1：按查询的CPU时间，突出显示最消耗资源的查询及其使用模式

清理：减少不必要的数据仓库负载

对于长期运行的数据平台，大多数情况下工作负载会不断积累，其中一些在某个时间点会变得无关紧要。例如，一个报表被创建并定时运行，但几年后它变得无关紧要，但由于没有人禁用它，它仍然在运行。普遍地指明这些工作负载以减少不必要的负载很重要，但在进行任何重大的架构更改或迁移之前更为关键。在迁移任何工作负载之前，Moovit 首先减少了不必要的仓库负载。

团队：

• 移除了仍然消耗集群资源的未使用进程。
• 尽可能减少不必要的频率：有些作业的运行频率高于下游消费者需要的频率。
• 审查了工作负载管理护栏，以验证资源分配与实际优先级相匹配。

这个清理阶段是迁移的先决条件。通过首先移除浪费，团队验证了最终选择用于卸载的工作负载确实是繁重的，而不仅仅是未优化或不必要的。

不再相关的进程消耗了总 CPU 时间的大约 7%，并在优化工作开始之前被移除。

工作负载选择：选择要卸载的内容

在清楚地了解工作负载模式后，Moovit 面临一个常见的决策点：继续扩展现有的 Redshift 集群，还是重新架构转向多引擎方法。团队评估了两条主要路径：

1. 使用 Redshift 多集群和数据共享进行重新架构：识别可以从资源隔离中受益的工作负载，然后在多个 Redshift 集群之间重新分配处理和查询，结合无服务器和预置选项。这将跨用途优化的集群重新分配负载，并通过更好的资源利用可能节省成本。
2. 使用专用引擎进行重新架构：识别可以从替代处理框架中受益的工作负载，并将它们卸载到更合适的引擎。这将减轻 Amazon Redshift 的压力，同时构建更灵活、成本效益更高的架构。

Moovit 决定两者都做，因为虽然有些工作负载从卸载中受益，但其他工作负载从隔离的 Amazon Redshift 计算中受益。

测量数据揭示了一个主要的卸载候选者：原始数据聚合管道。该工作负载将原始数据从 Amazon S3 加载到 Amazon Redshift，然后执行繁重的会话化和聚合转换。原始表仍用于临时和探索性分析，但定期的生产消费者主要依赖聚合输出，使得这些转换成为卸载的强有力候选者。

概念验证：使用 Spark SQL 卸载到 EMR Serverless

确定了目标工作负载后，Moovit 启动了一个 POC，使用Amazon EMR Serverless 和 Spark SQL。选择 EMR Serverless 是由几个因素驱动的：

• Spark SQL 兼容性： 现有的 Redshift SQL 逻辑可以以最小的更改移植到 Spark SQL 语法。
• 无服务器简单性： 在评估阶段没有集群管理的开销。
• 数据湖原生： 处理可以直接在 Amazon S3 中的数据上进行。

POC 定义了量化的成功标准，在五个或更多连续运行中测量：

• 运行时间减少： 选定管道的转换部分减少大于或等于 40%。
• Amazon Redshift 成本降低： Redshift RA3 计算减少 30% 以上，且剩余工作负载没有性能下降。
• 数据质量对等： 在冻结的对等窗口内，Spark 和 Amazon Redshift 输出在行数、不同用户和所有发布的指标上完全匹配。

克服初始性能挑战

第一次 POC 尝试暴露了重大挑战。早期具有 100 个执行器的 Spark 作业耗时约 4 小时，远远超过了 Amazon Redshift 上 30-40 分钟的基线。除了原始性能外，团队还遇到了内存压力、Spark 和 Amazon Redshift 输出之间的数据对等差距，以及两个引擎之间细微的 SQL 行为差异。

团队系统地诊断并解决了这些问题：

1. 执行计划分析：审查 Spark 执行计划揭示了次优的查询模式，导致了过多的数据混洗。
2. 查询重写：重写特定的 SQL 构造以符合 Spark 的分布式处理模型，包括将大的整体逻辑拆分为分阶段转换。
3. 减少或重写昂贵的 DISTINCT 模式：识别并消除不必要的 DISTINCT 操作，这些操作造成了沉重的混洗压力。

应用这些优化后，执行时间从 4 小时下降到大约 10 分钟，所需的执行器减少到少于 50 个，超过了原始性能。

验证：在切换前确保数据对等

在任何工作负载转移到生产环境之前，Moovit 实施了严格的验证过程。新的 Spark 输出与之前的 Amazon Redshift 输出在多个维度上进行了比较：

• 行数：确保没有数据丢失或重复。
• 不同用户：验证实体级别的完整性。
• 指标对等：所有发布的业务指标都匹配。
• 每日趋势：时间序列模式保持一致。
• 行级检查：抽查个别记录的正确性。

只有在多个连续运行中所有验证检查一致通过后，团队才继续对每个工作负载进行切换。

进入生产：扩展工作负载卸载

随着 POC 成功展示了性能提升和成本节省，Moovit 逐步将更多工作负载从 Amazon Redshift 迁移到 EMR：

• 重聚合作业： 主要的每日和每周聚合管道完全转移到 EMR。
• 数据转换阶段： 以前消耗 Redshift 计算的预处理步骤转移到 Spark，只有最终的聚合结果加载回 Amazon Redshift 供 BI 消费。
• 每周批处理工作负载：大型批处理作业，此前在周末处理窗口期间会造成资源争用。

过渡采用了循序渐进的方法：每个工作负载单独迁移，并在停用 Redshift 上运行的等效作业之前，通过数据质量验证确认一致性。

其他优化：Redshift Serverless、工作负载隔离以及 Amazon EC2 上的 Amazon EMR

除了 EMR 卸载之外，Moovit 还实施了进一步的架构改进，以隔离工作负载并优化成本。

Amazon Redshift 规模调整：迭代式集群优化

在成功卸载并隔离繁重工作负载后，Moovit 着手调整 Redshift 集群的规模。团队没有一次性调整大小，而是使用弹性大小调整，每次减少两个节点来逐步缩减集群。在每一步中，他们都验证了：

• 现有 BI 工作负载保持可接受的性能。
• 队列等待时间保持在 SLA 阈值之内。
• 在峰值负载下未观察到工作负载降级。

这种迭代方法将风险降至最低，并使团队能够自信地找到最佳的集群规模。

使用 Redshift Serverless 进行工作负载隔离

Amazon Redshift 仍然是提供策展 BI 数据的首选引擎。然而，并非所有 Amazon Redshift 工作负载都需要预置容量：

• 临时分析师查询： 移至 Redshift Serverless，通过数据共享将不可预测的工作负载与预置集群隔离。
• 数据科学工作负载： 过渡到 Redshift Serverless，以便灵活探索而不影响生产。

这种通过 Redshift Serverless 实现的工作负载隔离提供了资源分离，而无需额外的预置容量。该架构现在使用数据共享在预置集群和 Serverless 集群之间提供统一视图。

运营隔离优化

Moovit 还通过重新平衡预置集群上的WLM优先级来优化工作负载隔离。由于 ETL 队列主要处理来自 Amazon S3 的原始数据加载（在繁重的聚合操作移至 Spark 后，这不再是瓶颈），因此降低了其优先级。与此同时，随着大多数人类用户移至 Redshift Serverless，预置 Redshift 上为 Tableau 服务工作负载的优先级被调高，以保持仪表板性能的可预测性。最终结果是：预置 Redshift 容量减少了 50%。

过渡到 EC2 上的 EMR

EMR Serverless 在 POC 阶段被证明是高效的：它允许快速迭代，而无需集群管理开销。然而，对于长期的周期性生产工作负载，Moovit 转向了EC2 上的 EMR，以更好地适应其生产成本和基础设施模式，并利用现有的计算预留。

EMR 部署选项之间的过渡无需任何应用程序代码更改，这展示了 EMR 部署选项的灵活性。

AI 辅助的 SQL 转换

此外，Moovit 还使用了 AI 辅助开发工具 Claude Code 和 Cursor 来加速部分 SQL 转换过程。这些工具帮助工程师识别 Redshift SQL 和 Spark SQL 之间的语法差异、建议重写并调试迁移问题，而验证和生产批准仍由工程师审查。

结果：现代多引擎架构

架构现代化带来了可衡量的成果：

• 集群规模缩减： Redshift 集群规模缩减至初始容量的 50%。
• 性能提升： 关键聚合作业在 EMR 上运行更快、更稳定（p90 执行时间减少 50%）。
• 工作负载隔离： 任何单一工作负载类型都无法通过资源争用影响其他工作负载。
• 数据管道总成本降低 33%： 集群缩减、向 EMR 过渡以及高效使用 Serverless 所带来的综合节约。
• 未来灵活性： 多引擎架构为额外用例提供了路径，而无需进行架构更改。

下图比较了过渡前后聚合作业的性能。

图 2：过渡前后聚合作业的执行时间

图 3：过渡前后按百分位数划分的作业执行挂钟时间

最终架构将每个工作负载分配给最适合它的引擎：

经验教训

Moovit 的现代化之旅为类似的架构转型提供了几个关键见解：

1. 先测量再行动：建立基线指标和自动分类对于识别真正的卸载候选者至关重要。如果没有细粒度的工作负载级测量，团队就无法确定哪些具体流程正在耗尽集群资源。
2. 迁移前先清理：首先减少不必要的负载，确保迁移工作针对真正繁重的工作负载，而不是简单的未优化或未使用的进程。
3. 小 SQL 更改，影响巨大：从 Redshift SQL 迁移到 Spark SQL 只需相对较小的语法调整。核心业务逻辑保持不变，大多数转换直接翻译，只需极少的重构。
4. 针对引擎进行优化：如果不进行优化，将 SQL 查询移植到 Spark 上，某些工作负载的初始效果会很差。了解 Spark 的分布式执行模型并针对其进行优化，对于实现目标性能至关重要。
5. 严格验证：多维数据一致性检查（行数、不同用户数、指标、每日趋势和行级抽查）使团队有信心进行切换，而不会出现数据质量回退。
6. 在EMR选项之间移动很简单：EMR Serverless被证明在快速启动和评估Spark方面非常高效。当Moovit需要迁移到EC2上的EMR以使用现有预留时，过渡无需更改应用程序代码。
7. 迭代集群规模调整：Moovit没有一次性调整，而是使用弹性调整逐步减少Redshift集群（每次两个节点），在每一步验证性能后再继续。

结论

展望未来，作为另一个潜在的优化，Moovit将评估新的Amazon Redshift RG实例用于预置集群，提供高达2.2倍的价格性能，价格比RA3低30%，由AWS Graviton提供支持。

更广泛的启示是，AWS提供了多个专用引擎，可以用于单一数据平台。在Moovit的案例中，最大的改进来自于将每个工作负载分配给最适合它的引擎：Amazon Redshift用于策展的分析服务，Redshift Serverless用于隔离的探索性工作负载，以及Amazon EMR用于对Amazon S3中的数据进行大规模转换。这种架构为Moovit提供了基础，随着数据量的增长和新的分析用例的出现，可以进行未来的优化和灵活性调整。