导读

在这个针对数据工程师、数据架构师和云架构师的深入课程中，解锁您的大数据环境的全部潜力，重点介绍Amazon EMR和成本优化策略。全面了解各种成本优化策略，包括集群规模调整、使用Amazon EC2 Spot实例和实施托管扩展。学习Amazon EMR部署模型之间的关键差异，以及如何选择符合您组织特定需求、限制和技术能力的最佳选项。带着可行的见解和实用策略离开，以增强您的大数据工作流程并实现显著的成本节省。

演讲精华

以下是小编为您整理的本次演讲的精华。

2024年亚马逊云科技 re:Invent大会上，一场关于利用Amazon EMR（弹性MapReduce）实现高性价比数据处理的精彩会议吸引了众多关注。亚马逊云科技数据处理工程团队成员Matthew Liam和Roblox公司首席工程师Aaron Fang共同分享了他们在优化数据处理成本的同时保持可扩展性和易用性方面的见解和经验。

Matthew首先全面概述了亚马逊云科技的数据处理和分析服务。这些服务通过开源软件、查询引擎以及构建笔记本、可视化ETL和查询编辑器的工具，为客户提供了广泛访问数据的能力。客户可以利用Apache Spark、Ray和Python等流行框架来转换或准备任何规模的数据。此外，对于实时数据访问，亚马逊云科技提供了Apache Flink和Spark Streaming等流媒体框架。对于需要查询分析的用户，亚马逊云科技提供了SQL引擎如Trino。通过托管的Apache Airflow工作流以及与Amazon SageMaker的无缝集成，可以轻松编排这些多样化的工具和软件，用于数据准备、集成、故障排除、调试和代码生成。

Amazon EMR是亚马逊云科技数据处理和分析服务的关键组成部分。EMR为Apache Spark和Trino提供了性能优化的运行时，使客户能够以最佳的价格/性能比运行大数据和分析工作负载。EMR提供灵活的部署选项，允许客户在EC2上运行EMR、在EKS上运行EMR或以无服务器方式运行。EMR拥有顶尖的安全性，最近支持了Spark上的原生细粒度访问控制，并改进了CSV处理和TLS端点支持。值得注意的是，亚马逊云科技致力于保持最新状态，在开源版本发布后30天内就会在EMR上提供新版本。

Matthew强调了几个利用EMR取得卓越成果的客户成功案例。统一智能平台和Salesforce管理着PB级别的数据湖，并寻求专注于节省成本和提高效率。通过利用EMR使用数百种不同实例类型、现货实例集成和托管扩展的能力，他们能够处理两倍的数据量，同时每月节省了100万美元的成本。

另一个值得关注的例子是Autodesk公司，他们利用洞察力和分析为客户提供更好的解决方案和功能。由于数据是其业务的核心组成部分，Autodesk由于现有平台的可靠性问题而求助于亚马逊云科技。他们需要一个能够满足其可靠性需求并随着预期数据增长而扩展的平台。通过迁移到Amazon EMR，Autodesk实现了30%的成本节约，同时提高了安全性和可靠性。值得注意的是，Autodesk实现了99.8%的可用性，自迁移以来没有遇到任何重大中断或停机。

Matthew强调，任何数据处理平台都有三个关键支柱：可扩展性、专为性能和成本优化而设计的特性以及易用性。他继而深入探讨了Amazon EMR在这些领域的创新，以实现高性价比的数据处理。

在可扩展性方面，Matthew承认客户通常面临三个主要挑战：供应困难，如获取容量、确定在哪些可用区(AZ)供应集群以及确保有足够的IP地址;运营集群并确保其健康状况，包括在运行集群上进行部署而不影响现有工作负载;以及监控和调试，这是一个常见的痛点，因为客户需要及时获得问题通知以及进行根本原因分析的正确工具和可观察性。

在过去几年中，EMR一直专注于通过提供灵活性和代表客户做出决策来简化这些领域。在供应方面，EMR允许在集群供应期间指定多达30种不同的实例类型，并提供多种分配策略。这意味着在供应期间，EMR将评估提供的实例类型，并选择能够提供最佳容量和成本组合的实例类型。

EMR还非常重视支持大型集群，使客户能够运行超过4000个节点的集群，并为这些节点选择500多种不同的实例类型。此外，EMR还投资于改善可见性、更好的调试和监控。在集群供应期间，EMR提供实时供应洞察，如容量不足错误、超时(如果供应或扩展耗时过长)以及可操作的见解，例如某个AZ缺乏足够的IP地址，建议改为在其他AZ中供应。

Matthew深入探讨了AZ和实例选择功能，这是客户面临的一个重大挑战，尤其是在管理数百个集群或单个集群上的数千个节点时。确保有足够的IP地址并避免容量不足错误或供应失败可能会导致工作负载或管道延迟。EMR现有的AZ和实例选择已经为客户做出了许多决策，但仍存在一些差距。例如，在选择AZ时，EMR只会考虑集群的一部分，而不是整个集群容量。此外，在分配策略方面选择也有限，一种用于现货实例，一种用于按需节点。此外，EMR的重试策略相当简单，它会重试一定时间，然后失败。

为了解决这些限制，EMR引入了优先级分配策略，允许客户为不同的实例类型设置优先级。EMR将尽最大努力首先尝试较高优先级的实例，然后再回退到较低优先级的实例。这一功能对于希望首先尝试最新一代实例或已知对其工作负载表现更好的实例，然后再回退到旧一代或其他实例池中的实例类型的用例特别有用。

通过优先级分配策略和其他改进，EMR的新流程涉及选择整个集群的AZ和容量。EMR仍将回退到基本节点(主节点和核心节点)，以确保集群启动，因为客户希望集群先启动再扩展。EMR现在支持各种分配策略，如优先级分配、多样化、低价和容量优化。此外，EMR还包括一项功能，如果没有可用的现货容量，它会在供应期间切换到按需实例。最后，EMR在重试策略方面提供了更多灵活性，允许用户定义重试次数或快速失败。

一旦集群供应并运行，客户必须操作和维护其健康状况。这是另一个挑战，涉及处理硬件故障或替换不健康实例等场景。此外，客户通常难以在不影响当前集群上现有工作负载的情况下进行更改或启动新集群。

EMR简化了许多这些操作，其中一个值得注意的功能是自动替换不健康节点。在大规模运行大型集群时，不健康节点是一个常见问题，可能由于各种原因而发生，如EC2受损节点、应用程序引起的磁盘空间问题或导致实例无响应的网络问题。使用Amazon EMR，所有节点都会持续监控，以确保作业能够成功运行。最糟糕的情况是有一个运行但不执行任何工作的实例，从而导致成本浪费。

如果EMR检测到不健康节点，它会优雅地将该节点退役，并在其位置供应一个新实例，以恢复目标容量。这个流程捕获了代表客户做出的许多决策。例如，EMR一次只退役少量节点，以避免影响集群上运行的作业。EMR还执行检查和平衡，以确保在从不健康节点转移数据之前，剩余的健康节点有足够的存储容量，从而防止产生新的问题。

自发布以来，EMR每月在所有区域替换了110万个节点。这意味着对客户工作负载的影响更小，成本更低，因为客户不再需要由于节点故障而重新运行任务或作业。

在监控和调试方面，EMR去年的创新重点是尽可能快地提供实时警报和事件，使客户能够及时了解集群状态。其次，EMR使与现有可观察性、日志记录和监控解决方案的集成变得简单。第三，EMR提供了托管的Web界面和预构建的仪表板，可轻松访问集群信息和重要指标。

一个具体的例子是EMR如何发出CloudWatch事件和指标。2024年，为了提高可见性，EMR实现了99%的客户可操作见解覆盖率，包括容量不足错误、调整大小超时、各种限制(EBS限制、实例限制)和现货中断。EMR通过构建一个中央控制平面层来实现这一点，内部团队可以在开发新功能时发布自己的指标，这些指标会自动显示在客户的EMR控制台和EventBridge中。

对于有兴趣通过事件驱动架构构建自动化的客户，他们可以利用这些事件。例如，一个容量不足的事件可能会触发并行配置新集群或通知下游团队数据处理可能延迟。对于那些更喜欢交互式体验的人，同样的事件也会显示在亚马逊云科技控制台中。

虽然大规模运行数据处理至关重要，但实现成本和性能优化同样重要。与客户讨论价格-性能时，常见的挑战包括调优的困难、选择合适基础设施的痛苦以及有效管理存储。

在这些领域，EMR专注于自动确定最佳配置和优化组合，以实现最佳价格-性能比。EMR的一项关键创新是为Apache Spark和Trino提供了优化的运行时。根据基于3TB数据的TPC-DS基准测试，EMR的Spark在最新版本中比开源Spark快上3.9倍。EMR Trino在同一基准测试中比开源Trino快2.7倍。值得注意的是，EMR的Spark和Trino运行时都是100%API兼容的，这意味着客户可以在EMR上运行现有的Spark工作负载，而无需进行任何代码或配置更改。

此外，所有这些优化都是默认启用的，并且是自适应的，会根据正在运行的工作负载、正在扫描的数据或正在使用的硬件和基础设施进行调整。

为了说明这一点，Matthew深入探讨了调优主题。众所周知，调优是一个具有挑战性的过程，通常需要为特定工作负载选择一组配置，而这些配置可能不适用于其他工作负载。此外，由于数据不断变化和发展，今天选择的配置可能不是在一个月后运行同一工作负载时的最佳选择。

为了帮助客户解决这一挑战，EMR Spark进行了优化，可以自动处理这些配置选择，以实现最佳价格-性能比。一个例子是shuffle分区。EMR将根据当前运行的工作负载和基础设施，自动尝试确定最佳shuffle分区和并行度。

另一个值得注意的例子是自适应连接选择。当Spark应用程序运行时，可能会出现各种连接类型，如排序合并连接、shuffle哈希连接和广播连接。理想情况下，客户应该提供有关数据的提示，例如要连接的表、它们的大小和连接键。但是，EMR将自动获取这些输入，分析正在扫描的数据、表和连接键，并自动选择最高效的连接类型，以确保工作负载的最佳价格-性能比。

自动调优配置并不是基础设施方面唯一的关注领域。客户面临的一个常见挑战是确保所选硬件充分利用实例，尤其是在处理由混合实例系列和大小组成的大型集群时，这一挑战更加严峻。

为了帮助客户解决这一问题，EMR提供了优化的默认执行器，这些执行器会根据工作负载运行的实例而改变。EMR还包括一个功能，可以动态调整执行器的大小，从而实现最大利用率，而无需为每种使用的实例类型调整执行器大小。

最后是存储交互方面。由于计算和存储在S3中是分离的，因此S3与引擎或应用程序之间的交互至关重要。客户必须考虑诸如S3限制、小文件以及应用程序与存储之间潜在的网络瓶颈等因素。

基于这些考虑，EMR已经投资减少与S3的交互。例如，在可能的情况下，EMR将直接写入S3，而不是执行多操作重命名。此外，EMR会尝试减少需要扫描的数据量，方法是在Spark应用程序阶段进一步下推过滤器。对于需要引入的数据，EMR的目标是尽可能并行化该过程。

其中一个例子是数据预取。使用数据预取，在Spark任务需要运行之前，EMR将使用多余的网络带宽异步预取所有所需数据。这确保了在阶段开始时，数据已经可用，从而无需在当时拉取所有数据。

这只是EMR在提供开箱即用的优化和代表客户进行配置选择以优化价格-性能方面的投资的几个例子。

虽然可扩展性和价格-性能至关重要，但易用性也同样重要。EMR在这一领域的创新专注于处理数据处理所需的无差别繁重工作。这包括确保与编排系统和可观察性解决方案的无缝本机集成。此外，正如Matt在主题演讲中提到的，亚马逊云科技正在努力为所有数据处理、AI和ML需求提供统一的工作室，从而无需将不同的部分拼凑在一起。

Matthew强调的另一个方面是跨不同部署选项的灵活性。客户可以在EC2上的EMR、EKS上的EMR或以无服务器方式运行他们的Spark应用程序。本次会议的重点是对托管缩放所做的改进。

EMR以前支持托管缩放，提供了一种无需操作的方法。客户会定义最大值、最小值以及核心节点和现场节点的数量，EMR会处理其余部分。许多客户赞赏其简单性，并取得了很好的效果，有些工作负载在启用此功能后节省了高达60%的成本。

当前的优化针对SLA敏感型工作负载进行了高度优化，这意味着在扩大规模时，EMR会优先考虑性能，并尽快提供尽可能多的容量，以避免扩大规模成为工作负载的瓶颈。在缩小规模方面，EMR会更加保守，等到作业完全完成后再决定是否缩小规模，并且一旦安全就会积极缩小规模。

虽然这种方法适用于许多工作负载，但在某些情况下会导致利用率不足。例如，对于涉及大量短期任务的峰值工作负载，到EMR扩大规模时，部分或全部这些任务可能已经完成，因此配置的实例就变得不必要了。同样，在缩小规模方面，客户希望保留实例作为即将到来的工作负载的热池，而不是积极地缩小规模。

为了支持这些用例，EMR推出了高级缩放。通过高级缩放，客户现在可以更灵活地定义他们的意图，无论是优化成本还是优化性能，Amazon EMR都会根据指定的意图自动调整缩放算法。

例如，如果优化成本，扩大规模的行为可能会更加保守，扩大到一定百分比，并评估已配置的节点是否足够，或者是否需要进一步扩大规模。在缩小规模方面，它会更加积极，一旦确定不再需要实例，就会快速关闭实例，因为重点是优化利用率和成本。

相反，如果优化性能，扩大规模的行为将类似于当前的方法，旨在尽快提供尽可能多的容量。缩小规模的过程会更加渐进，以避免影响工作负载，并迫使客户重新运行任何任务或应用程序。

高级缩放只是一个例子，但总体主题是尽可能自动化，以减少管理数据处理平台的操作开销。

在介绍了可扩展性、价格-性能和易用性方面的创新之后，Matthew探讨了客户如何在实践中利用这些创新，以及需要考虑的因素和最佳实践。

讨论的第一个主题是如何从成本和易用性的角度选择最佳EMR部署模型。如前所述，EMR可以部署在EC2、EKS或以无服务器方式部署，具成本效益的选择取决于多个因素。为了理解这一点，Matthew研究了EMR的定价结构。

在所有EMR部署模型中，都有EC2成本和服务成本。可能还有其他成本，如存储和网络，但在此讨论中，重点是这两个组成部分。EMRon EC2和EMRon EKS是基于集群的部署模型，它们会产生EC2成本，因为EC2实例在客户的账户中运行，遵循基于实例大小的标准小时定价模式。任何适用的折扣，如现场实例或节省计划，都会在此应用。

EMRServerless完全在亚马逊云科技的账户中运行，因此没有EC2成本。对于EMR服务成本，对于EMRon EC2，定价结构类似于EC2，基于实例大小的小时费率，通常约为EC2成本的25%。对于EMRon EKS和EMRServerless，定价模型是基于消耗的，取决于应用程序使用的总vCPU和内存。

为了更好地理解成本影响，Matthew提供了一个成本示例。假设一个Spark应用程序使用25个r5.4xlarge实例运行并完成，集群利用率为80%，运行时间为3小时。

在EMRon EC2方面，计算相对简单:将实例数量(包括主节点在内的26个)乘以运行时间和EC2和EMR的小时费率，得到大约98美元的成本。

在无服务器端，由于一切都在亚马逊云科技的账户中运行，因此没有EC2成本。对于服务成本，需要考虑vCPU和内存的总使用量。在这种情况下，80%的利用率持续3小时，考虑总集群容量，乘以80%和3小时，得到大约960个vCPU和7，600GB内存。将这些值代入vCPU和内存的每小时费率，无服务器端的成本约为95美元。

关键要点是，在比较按小时定价模型与按消耗定价模型(如EKS和无服务器)时，利用率是一个关键因素。在这个例子中，如果工作负载利用率为50%而不是80%，EC2成本将保持不变，因为它不依赖于使用情况 - 仍需支付每小时费率。但是，无服务器成本将大幅降低到大约60或70美元。

Matthew随后转向来自Roblox的Aaron Fang，他分享了他们实现高效数据处理的历程。Aaron首先提供了Roblox规模的背景信息，提到游戏只是他们平台的一个方面，还包括通信、购物、娱乐、学习等。截至2022年第三季度，Roblox拥有8890万日活跃用户，计20.7亿小时的参与时间，以及290万开发者。

Aaron概述了议程，包括他们数据平台的规模、从最初采用EMR到目前状态的历程、批处理平台的高级架构概览，以及关注DevOps和基础设施方面，包括成本考虑。

虽然Aaron无法提供确切数字，但他通过表示Roblox目前在S3数据湖中存储了数百PB的数据，每月增加数十PB，给出了规模的概念。他们的内部服务每天产生万亿个事件，并且有数万个活跃管道在运行。

Aaron随后概述了Roblox的批处理架构。所有从数据中心生成的数据都被摄取到S3中。虽然他们有两个以上的数据中心，但为简单起见，图中只显示了两个。在右侧，显示了一个典型的开源平台，使用Apache Airflow编写管道。Roblox使用EMR进行处理，将数据写回S3。对于仪表板、BI和特定查询，他们使用Apache Superset，对于运行时间较短(少于一分钟)的查询，他们通常运行Trino。

回顾Roblox的EMR历程，Aaron分享说，在2016年，他们设置了一个3节点共享的EMR集群，大约有100个节点。当时，有人会在需要处理时启动EMR集群，处理完后关闭。

快进到2020年Aaron加入公司时，他们仍然使用相同的3节点共享集群设置，但正在运行数千个节点。Aaron需要解决的问题是如何扩展EMR以运行所有管道，因为他们无法在现有设置上运行所有管道。到那时，EMR集群从不关闭，管道24/7运行，UTC 0时负载最重。

为了扩展，Roblox从共享集群设置过渡到基于团队的方法，将集群按团队划分。然而，这带来了新的挑战，因为一些团队的工作负载差异很大，难以配置EMR以高效运行混合工作负载。解决方案是按工作负载类型扩展，将高级管道、需要快速响应的仪表板工作负载和回填管道分开，以防止相互干扰。

虽然这种方法看似直接，但它导致EMR集群激增，从2-4个集群增加到30、40、50、70甚至80个集群。虽然手动配置少量集群的EMR相对容易，但管理如此多的集群变得具有挑战性，成本也开始上升。

为了解决这个问题，Roblox开发了内部工具，确保所有EMR集群之间没有配置偏差。这些工具允许自动配置，在某些情况下，还允许内部用户自行配置EMR集群。此外，Roblox为EMR实施了蓝/绿部署，将其视为部署微服务。

Aaron提供了一个简化的图表，说明了他们的蓝/绿部署流程。在任何给定时间，可能都有两个副本的工作负载类型EMR集群。例如，从绿色集群开始，该框中的所有内容都被视为EMR部署的一部分，包括额外的组件，如用于私有VPC子网(具有不可路由IP)的ELB、用于在集群之间轻松切换的Route 53，以及用于仪表板、指标、日志和警报的CloudWatch。

当需要进行配置更改时，Roblox会创建一个新的蓝色集群，以避免影响现有管道。然后，他们将少量流量引导到新集群，以验证设置。一旦确认无误，他们将100%的流量重定向到新集群，允许绿色集群耗尽所有管道，这可能需要数小时。管道耗尽后，绿色集群将被删除。如果出现任何问题，他们可以恢复到旧的绿色集群。

在建立了扩展EMR的工具之后，下一个重点是了解和优化成本。Roblox在几个层面分析成本:组织层面(汇总所有Amazon账户的成本)、集群层面(使用团队名称标记集群以便于归因)、作业估算(了解单个管道的成本)以及为用户提供门户以评估其效率和管道成本。

作业成本估算虽然不是一门精确的科学，但旨在提供作业成本的高级近似值。Roblox的作业主要受内存限制，因此他们关注消耗的内存和作业运行时间，这可以从YARN资源管理器获得。关键指标是“内存秒数”，表示消耗的总内存(以MB为单位)乘以作业运行时间(以秒为单位)。将此与平均实例成本(因为Roblox运行多种实例类型)相结合，可以得到合理的估算值。虽然不精确，但这种方法允许用户在继续运行管道时比较成本。

Roblox开发了一个自动化报告，为团队提供效率评分，解决存储和计算浪费问题。对于存储浪费，他们解析S3日志，识别生成但从未读取的数据集，并将此浪费归因于负责的管道。对于计算浪费，他们利用Airflow的作业调度数据，将成功之前的失败作业尝试次数视为浪费。

目的是让团队了解自己的支出和效率，如果他们的运营效率不佳，就可以深入挖掘并确定需要改进的领域。

在能够扩展并了解成本的情况下，Aaron讨论了Roblox的节省成本措施。一些明显的措施包括启用S3智能分层，以便在90天后自动将不常访问的数据移至较低成本层，以及从gp2切换到gp3 EBS卷以获得更好的性能和成本。

关于现货与按需实例，Aaron提到，由于Roblox的管道通常运行时间较长，使用现货实例最终由于处理中断的开销而成本更高。因此，他们更多地专注于优化按需使用情况。

为不需要单独工作负载类型的团队合并集群，并利用亚马逊云科技计算节省计划来满足最低计算使用量，也有助于节省成本。

根据Aaron的说法，最有趣的两个节省成本的措施是作业自动调优和集群自动调优。由于有数万个管道，手动调优每个管道是不可能的，因此Roblox实施了作业自动调优，以确保不浪费资源。

对于作业自动调优，Roblox让新管道运行三次，收集每次Spark作业运行的指标。在第四次运行时，系统会确定配置是否已优化。常见的调整包括减少执行器内存分配(通常由于从其他作业复制而设置过高)以及在任务运行时间少于2-3分钟时减少执行器数量(表明执行器数量过多)。自动调优过程是连续的，如果发生任何故障，系统会恢复到旧配置，以避免中断。

Aaron最喜欢的主题是集群自动调优，他称之为解决EMR托管自动缩放的激进缩放行为。虽然托管自动缩放可以在9-55秒内响应(而普通自动缩放的检查间隔为5分钟)，但Roblox希望避免过度扩缩。

集群调优器的目标是使可用内存和分配内存线在监控图上保持接近，尽可能长时间地将集群保持在最大容量。它通过监控应用程序挂起和容器挂起等指标来实现这一点，从而创建背压。当这些指标达到某些阈值时，集群调优器会指定一个新的托管自动缩放配置，根据背压级别增加或减少目标容量。这种方法帮助Roblox在EMR成本上节省了大量资金。

Aaron提到，亚马逊云科技最近宣布的高级自动缩放功能可能会实现类似于Roblox集群自动调优方法的结果。

总结来说，Aaron强调了自动化部署工具、作业和集群自动调优以及为团队提供效率和成本可见性的重要性。这些措施与前面概述的努力相结合，帮助Roblox节省了大约30-35%的整体EMR成本。

Matthew随后总结了本次会议的关键学习和收获:

1.           始终使用最新的EMR版本，以从最新的性能改进和优化中获益。

2.           使用实例集群跨越尽可能多的实例类型，以获得最佳容量和成本效果。

3.           如果您希望优先尝试最新一代实例或已知对您的工作负载表现更好的实例，请使用优先分配策略功能。

4.           如果您需要在优化成本或性能之间寻求平衡，或找到一个中间地带，请考虑使用高级托管缩放。

5.           在评估不同的EMR部署选项(EC2、EKS、无服务器)时，基于成本考虑，利用率是一个关键因素。

6.           对于现货实例，请尝试在同一集群上混合使用按需和现货，以获得按需的稳定性和现货的成本节约。

7.           具有低任务运行时间的Spark应用程序通常在现货节点上更有效，因为与长时间运行的任务相比，重新运行短任务的成本较低，长时间运行的任务可能不适合使用现货，因为存在中断的可能性。

总之，本次会议为在Amazon EMR上实现高性价比的数据处理提供了宝贵见解，涵盖了可扩展性、性能优化、易用性以及Roblox的实践经验。亚马逊云科技将继续创新EMR，使客户能够在优化成本和通过自动化简化操作的同时，大规模处理数据。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。