GoDaddy 如何通过采用 Amazon EMR Serverless 实现超过 60 的成本降低和 50 的性能提升

关键要点

在这篇文章中，我们重点介绍了 GoDaddy 如何通过采用 Amazon EMR Serverless 实现显著的业务优化，包括： 成本降低超过 60 性能提升 50 开发和测试速度提高五倍 显著减少碳足迹

这是 Brandon Abear、Dinesh Sharma、John Bush、Ozcan Ilikhan 和 Harsh Vardhan Singh Gaur 于 2024 年 3 月 12 日撰写的客座文章。

GoDaddy 为日常企业家提供全方位的帮助和工具，帮助他们在线成功。GoDaddy 拥有超过 2000 万客户，是人们创立想法、构建专业网站、吸引客户和管理工作的地方。

在 GoDaddy，我们以数据驱动的公司而自豪。我们对此的执着追求能够从数据中获取有价值的见解，推动我们的商业决策并确保客户满意。我们的高效承诺不变，并且我们已开展了一项激动人心的计划，以优化我们的批处理作业。在这个过程中，我们提出了一种被称为“七层改进机会”的结构化方法。这一方法论已成为我们追求效率的指导。

在这篇文章中，我们探讨了如何使用 Amazon EMR Serverless 提高操作效率。我们分享了我们的基准测试结果和方法论，并提供了有关 EMR Serverless 与基于固定容量的 Amazon EMR on EC2 瞬态集群在数据工作流上的成本效益的见解，这些工作流是通过 Amazon Managed Workflows for Apache Airflow (Amazon MWAA) 进行编排的。我们分享了 EMR Serverless 的采用策略，特别是在其优势明显的领域。我们的发现显示显著的好处，包括超过 60 的成本降低、50 更快的 Spark 工作负载、开发和测试速度提高五倍，以及显著减少的碳足迹。

背景

在 2020 年底，GoDaddy 的数据平台开启了 AWS 云之旅，将一个包含 800 个节点的数据中心 Hadoop 集群和 25 PB 的数据迁移至 EMR on EC2。这种提升与迁移的方法使我们能够直接比较本地与云环境，确保平滑过渡到 AWS 管道，减少数据验证问题和迁移延迟。

到 2022 年初，我们成功将大数据工作负载迁移至 EMR on EC2。使用 AWS FinHack 计划学到的最佳实践，我们优化了资源密集型作业，将 Pig 和 Hive 作业转换为 Spark，并在 2022 年减少了 2275 的批处理工作负载支出。然而，由于作业数量众多，面临可扩展性挑战。这促使 GoDaddy 开始了一场系统优化之旅，为更可持续和高效的大数据处理奠定了基础。

七层改进机会

在追求操作效率的过程中，我们识别了批处理作业内七个不同的优化机会层，如下图所示。这些层次从精确的代码级别改进到更全面的平台改进。这种多层次的方法已成为我们的战略蓝图，以持续追求更好的性能和更高的效率。

以下是这些层次：

代码优化 专注于优化代码逻辑，以提升性能。这涉及通过选择性缓存、分区和投影修剪、联接优化以及其他作业具体调优实现性能提升。使用 AI 编码解决方案也是这个过程的重要部分。软件更新 更新到最新版本的开源软件，以利用新功能和改进。例如，Spark 3 的自适应查询执行带来显著的性能和成本提升。自定义 Spark 配置 调整自定义 Spark 配置以最大化资源利用、内存和并行性。通过正确设置任务如 sparksqlshufflepartitions、sparksqlfilesmaxPartitionBytes、sparkexecutorcores 和 sparkexecutormemory 等可以实现显著的改进。然而，如果这些自定义配置与具体的 Spark 版本不兼容，可能适得其反。资源供应时间 启动资源如 Amazon Elastic Compute Cloud (Amazon EC2) 上瞬态 EMR 集群所需的时间。尽管某些影响此时间的因素在工程师的控制之外，但识别并解决可优化的因素有助于减少整体供应时间。任务级细粒度扩展 根据任务中每个阶段的需求动态调整资源如 CPU、内存、磁盘和网络带宽。目标是避免固定集群大小导致的资源浪费。工作流中多个任务的细粒度扩展 由于每个任务的资源需求独特，维持固定的资源大小可能会导致对某些任务的不足或过度配置传统上，多任务工作流的集群大小由最大的任务决定。然而，在工作流中动态调整多个任务和步骤的资源，可以实现更具成本效益的实现。平台级别增强 先前层次的增强只能优化特定的作业或工作流。平台改进旨在达到公司级别的效率。我们可以通过多种方式实现这一目标，例如更新或升级核心基础设施、引入新框架、为每个作业配置分配适当的资源、平衡服务使用、优化节省计划和现货实例的使用，或实施其他综合性变化，以提高所有任务和工作流的效率。

层 13 以往的成本降低

迁移至 AWS 云后，我们主要集中于图中所示的前三层的成本优化工作。通过将我们最昂贵的传统 Pig 和 Hive 管道转移到 Spark 并为 Amazon EMR 优化 Spark 配置，我们实现了显著的成本节省。

例如，一个传统的 Pig 作业需 10 小时完成，并且排名前 10 的高成本 EMR 作业之一。通过审核 TEZ 日志和集群指标，我们发现集群的资源过度配置，而大部分运行时间内未得到充分利用。从 Pig 转型到 Spark 更加高效。虽然没有自动化工具进行转换，但进行了手动优化，包括：

减少不必要的磁盘写入，节省序列化和反序列化时间层 1用 Spark 替代 Airflow 的任务并行化，简化 Airflow DAG层 1消除冗余的 Spark 转换层 1从 Spark 2 升级到 Spark 3，使用自适应查询执行层 2解决倾斜联接并优化小维度表层 3

因此，作业成本降低了 95，作业完成时间缩短到 1 小时。然而，这种方法投入大量人力，并且对大量作业没有可扩展性。

层 46 找到并采用正确的计算解决方案

在 2022 年底，在前几层的优化中取得 significant 成就之后，我们的关注转向了剩余的层次。

理解我们批处理的状态

我们使用 Amazon MWAA 在云中大规模编排数据工作流。Apache Airflow 是一个开放源代码工具，用于以编程方式编写、调度和监控被称为工作流workflows的过程和任务序列。在这篇文章中，术语工作流和作业可以互换使用，指代由 Amazon MWAA 编排的任务组成的有向无环图DAG。对于每个工作流，我们有顺序或并行任务，甚至在 createemr 和 terminateemr 任务之间的 DAG 中同时运行这些任务，使用固定的计算容量的瞬态 EMR 集群。即使在优化了一部分负载后，依然有许多未优化的工作流由于过度配置计算资源而未得到充分利用，如下图所示。

魔方加速器免费正版

这突显了静态资源分配的不合理性，促使我们认识到需要动态资源分配DRA系统。在提出解决方案之前，我们收集了大量数据，以充分理解我们的批处理。分析集群步骤时间不包括供应和空闲时间后发现显著洞见：右偏分布中超过一半的工作流在 20 分钟内完成，只有 10 超过 60 分钟。这个分布指导了我们选择快速供应计算解决方案，从而大幅降低工作流运行时间。以下图展示了我们一个批处理账户中 EMR on EC2 瞬态集群的步骤时间不包括供应和空闲时间。

此外，基于工作流的步骤时间不包括供应和空闲时间分布，我们将我们的工作流分为三类：

快速运行：持续 20 分钟或更短中等运行：持续 2060 分钟长时间运行：超过 60 分钟，通常持续数小时或更长时间

我们还需要考虑的是瞬态集群的大量使用，例如安全、作业和成本隔离、以及为特定目的构建的集群。此外，在高峰时段和低利用率时期之间，资源需求变化极大。

我们可以利用 Amazon EC2 上的 EMR 进行受管扩展以获得一定的成本效益，而迁移到 EMR Serverless 看起来成为了我们数据平台更具战略性的方向。除了潜在的成本效益外，EMR Serverless 还提供了诸如一键升级到最新的 Amazon EMR 版本、简化的操作和调试体验、以及在推出后自动升级至最新版本等额外优势。这些特性共同行动简化了大规模运行平台的过程。

评估 EMR Serverless GoDaddy 的案例研究

EMR Serverless 是一种 Amazon EMR 的无服务器选项，消除了在运行 Apache Spark 和 Apache Hive 等大数据框架时配置、管理和扩展集群的复杂性。通过 EMR Serverless，企业可以享受许多好处，包括成本效益、更快的供应、简化的开发者体验，以及提高对可用区故障的弹性。

认识到 EMR Serverless 的潜力，我们进行了全面的基准研究，使用真实的生产工作流。该研究旨在评估 EMR Serverless 的性能和效率，同时为大规模实施创建采用计划。结果非常鼓舞人心，显示 EMR Serverless 能够有效处理我们的工作负载。

基准测试方法

我们根据总步骤时间不包括供应和空闲时间将数据工作流分为三类：快速运行020 分钟、中等运行2060分钟和长时间运行超过 60 分钟。我们分析了 EMR 部署类型Amazon EC2 与 EMR Serverless对两个关键指标的影响：成本效益和总运行时间的加速，这作为总体评估标准。虽然我们没有正式测量易用性和弹性，但在评估过程中考虑了这些因素。

评估环境的基本步骤如下：

准备数据和环境：从每个作业类别中选择三到五个随机生产作业。实施所需调整以防止与生产产生干扰。运行测试：在几天或通过多次迭代中运行脚本以收集精确且一致的数据点。使用 EMR on EC2 和 EMR Serverless 进行测试。验证数据和测试运行：验证输入和输出数据集、分区和行统计，以确保数据处理相同。收集指标并分析结果：收集测试相关的指标。分析结果以获取见解和结论。

基准测试结果

我们的基准测试结果显示，在运行时间加速和成本效益方面，三类作业的所有结果都有显著改善。快速作业的改善最为明显，直接得益于更快的启动时间。例如，在固定计算容量的 EMR on EC2 瞬态集群上运行的数据工作流包括集群供应和关闭的 20 分钟在 EMR Serverless 上的完成时间仅为 10 分钟，提供了更短的运行时间和成本效益。整体而言，向 EMR Serverless 的转变在各职位之间显示了可观的性能提升和成本降低，见下图。

历史上，我们花了更多时间微调我们的长时间运行工作流。有趣的是，我们发现针对这些作业的现有自定义 Spark 配置在 EMR Serverless 中并不总能良好转换。在结果不显著的情况下，通常会舍弃与执行器核心相关的现有 Spark 配置。通过让 EMR Serverless 自主管理这些 Spark 配置，我们常常观察到改善。下图展示了 EMR Serverless 与 EMR on EC2 比较时每个作业的平均运行时间和成本改进。

以下表格展示了相同工作流在不同 Amazon EMR 部署选项EMR on EC2 和 EMR Serverless上的结果比较。

指标EMR on EC2EMR ServerlessEMR on EC2 vs EMR Serverless总运行成本 582 26055总运行时间分钟5340394026供应时间分钟1020005供应成本 119步骤时间分钟382039163步骤成本 430空闲时间分钟480EMR 版本标签emr690Hadoop 发行版Amazon 333Spark 版本Spark 330Hive/HCatalog 版本Hive 313 HCatalog 313作业类型Spark

AWS Graviton2 在 EMR Serverless 中的性能评估

在看到 EMR Serverless 对我们工作负载的令人信服的结果后，我们决定进一步分析 AWS Graviton2arm64架构在 EMR Serverless 中的性能。AWS 在 EMR Serverless 上对 Spark 工作负载进行了 基准测试，显示出 27 的整体性价比提升。

为了更好地理解集成的好处，我们对 GoDaddy 的生产工作负载进行了研究，并观察到在处理一系列作业时，使用 Graviton2 时的价格性能提升达到了 238。有关此研究的更多细节，请参见 GoDaddy 基准测试结果：在 EMR Serverless 上使用 AWS Graviton2 的 Spark 工作负载比以往提高了多达 24 的性价比。

EMR Serverless 的采用策略

我们通过部署环的分阶段推出战略，实施 EMR Serverless，确保系统集成。这个逐步的方法让我们能够验证改进，并在必要时停止进一步的 EMR Serverless 采用。它不仅作为早期发现问题的安全网，也