和风网标志

生成数据智能

大数据运用

Amazon 如何使用 Amazon EMR 优化其大批量财务对账流程以实现更高的可扩展性和性能 |亚马逊网络服务

由柏拉图重新发布
由柏拉图重新发布

日期：

浏览次数： 69

会计核算是确保财务报表完整性、准确性的重要步骤。具体来说，公司必须协调 资产负债表 可能包含重大或重大错报的账目。会计师仔细检查账户总账中的每个账户，并验证所列余额是否完整且准确。当发现差异时，会计师会进行调查并采取适当的纠正措施。

作为亚马逊金融科技组织的一部分，我们提供一个软件平台，使亚马逊的内部会计团队能够进行账户对账。为了优化协调过程，这些用户需要高性能转换，能够按需扩展，以及处理从几 MB 到超过 100 GB 的可变文件大小。并不总是能够将数据安装到一台机器上或在合理的时间范围内使用一个程序对其进行处理。这种计算必须足够快地完成，才能提供实用的服务，其中编程逻辑和底层细节（数据分布、容错和调度）可以分离。

通过使用分布式数据处理解决方案，我们可以在多个机器或具有相同功能的线程上跨数据集元素组实现这些同步计算。这鼓励我们重新发明由 AWS 服务提供支持的对​​账服务，包括 亚马逊电子病历 和 Apache Spark 分布式处理框架，它使用 火花。该服务使用户能够在 100 分钟内处理超过 100 GB 的文件，其中包含多达 30 亿笔交易。对账服务已成为数据处理的动力源，现在用户可以无缝地执行各种操作，例如 枢, 注册 （类似于 Excel VLOOKUP 运算）， 算术 操作，和 更多，为协调大量数据集提供通用且高效的解决方案。这一增强证明了通过采用分布式数据处理解决方案所实现的可扩展性和速度。

在这篇文章中，我们将解释如何集成 Amazon EMR 来构建一个高度可用且可扩展的系统，使我们能够运行大容量的财务对账流程。

迁移前的架构

下图展示了我们之前的架构。

我们的遗留服务是用以下构建的 亚马逊弹性容器服务 （Amazon ECS） AWS 法门。我们使用 Python 按顺序处理数据。然而，由于缺乏并行处理能力，我们经常不得不垂直增加集群大小以支持更大的数据集。就上下文而言，处理 5 GB 数据和 50 次操作大约需要 3 小时。该服务配置为水平扩展至五个 ECS 实例，这些实例从以下位置轮询消息： Amazon Simple Queue服务 (Amazon SQS)，它提供转换请求。每个实例配置有 4 个 vCPU 和 30 GB 内存，以允许水平扩展。然而，我们无法扩展其性能容量，因为该过程是连续发生的，从 亚马逊简单存储服务 （Amazon S3）进行处理。例如，要连接两个文件的 VLOOKUP 操作需要在内存中逐块读取这两个文件以获得输出。这成为用户的障碍，因为他们必须等待很长时间才能处理数据集。

作为我们重新架构和现代化的一部分，我们希望实现以下目标：

  • 高可用性 – 数据处理集群应该是高可用的，提供三个9的可用性（99.9%）
  • 生产能力 – 该服务每天应处理 1,500 次运行
  • 潜伏 – 它应该能够在 100 分钟内处理 30 GB 的数据
  • 异质性 – 集群应该能够支持各种工作负载，文件范围从几 MB 到数百 GB
  • 查询并发 – 实现要求能够支持至少10度的并发
  • 作业的可靠性和数据的一致性 – 作业需要可靠且一致地运行，以避免违反服务级别协议 (SLA)
  • 经济高效且可扩展 – 它必须根据工作负载进行扩展，使其具有成本效益
  • 安全性和合规性 – 鉴于数据的敏感性，它必须支持细粒度的访问控制和适当的安全实施
  • 灭菌监测 – 该解决方案必须提供集群和作业的端到端监控

为什么选择亚马逊 EMR

Amazon EMR 是业界领先的云大数据解决方案，使用开源框架（例如，PB 级数据处理、交互式分析和机器学习 (ML)） Apache Spark, 阿帕奇蜂巢及 急板。借助这些框架和相关开源项目，您可以处理数据以用于分析目的和 BI 工作负载。 Amazon EMR 允许您将大量数据转换并移入和移出其他 AWS 数据存储和数据库，例如 Amazon S3 和 Amazon DynamoDB.

Amazon EMR 的一个显着优势在于它有效地利用了 PySpark 的并行处理，这标志着对传统顺序 Python 代码的显着改进。这种创新方法简化了 Apache Spark 集群的部署和扩展，从而实现大型数据集的高效并行化。分布式计算基础设施不仅增强了性能，而且能够以前所未有的速度处理大量数据。 PySpark 配备了库，可促进类似 Excel 的操作 数据框，并且 DataFrame 的更高级别抽象简化了复杂的数据操作，降低了代码复杂性。结合自动集群预置、动态资源分配以及与其他 AWS 服务的集成，Amazon EMR 被证明是一种多功能解决方案，适用于从批处理到 ML 等各种工作负载。即使在节点发生故障的情况下，PySpark 和 Amazon EMR 固有的容错能力也能提高稳健性，使其成为 AWS 上并行数据处理的可扩展、经济高效且高性能的选择。

Amazon EMR 将其功能扩展到基础功能之外，提供各种部署选项来满足不同的需求。无论是 EC2 上的 Amazon EMR, EKS 上的 Amazon EMR, Amazon EMR 无服务器或 AWS Outposts 上的 Amazon EMR，您可以根据具体要求定制您的方法。对于那些为 Spark 作业寻求无服务器环境的人来说，集成 AWS胶水 也是一个可行的选择。除了支持 Spark 等各种开源框架外，Amazon EMR 还提供了选择部署模式的灵活性， 亚马逊弹性计算云 (Amazon EC2) 实例类型、扩展机制和众多节省成本的优化技术。

Amazon EMR 是云中的一股动态力量，为寻求强大大数据解决方案的组织提供无与伦比的功能。其无缝集成、强大的功能和适应性使其成为解决 AWS 上的数据分析和机器学习复杂性不可或缺的工具。

重新设计的架构

下图展示了我们重新设计的架构。

该解决方案根据 API 合同运行，客户可以在其中提交转换配置，定义操作集以及 S3 数据集位置以进行处理。该请求通过 Amazon SQS 排队，然后通过 Lambda 函数定向到 Amazon EMR。此过程启动创建 Amazon EMR 步骤，以便在专用 EMR 集群上实施 Spark 框架。尽管 Amazon EMR 在长期运行的集群的生命周期内可容纳无限数量的步骤，但只能同时运行或挂起 256 个步骤。为了实现最佳并行化，步骤并发度设置为 10，允许 10 个步骤同时运行。如果请求失败，Amazon SQS 死信队列 (DLQ) 保留事件。 Spark 处理请求，将类似 Excel 的操作转换为 PySpark 代码，以实现高效的查询计划。 Resilient DataFrame 将输入、输出和中间数据存储在内存中，优化处理速度，降低磁盘 I/O 成本，增强工作负载性能，并将最终输出传送到指定的 Amazon S3 位置。

我们从两个维度定义 SLA：延迟和吞吐量。延迟定义为针对确定性数据集大小执行一项作业所需的时间以及对数据集执行的操作数量。吞吐量定义为服务在不违反一项作业的延迟 SLA 的情况下可以执行的并发作业的最大数量。服务的整体可扩展性SLA取决于弹性计算资源的水平扩展和单个服务器的垂直扩展的平衡。

由于我们每天必须以最小延迟和高性能运行 1,500 个进程，因此我们选择在 EC2 部署模式上集成 Amazon EMR，并启用托管扩展以支持处理可变文件大小。

EMR 集群配置提供了许多不同的选择：

  • EMR 节点类型 – 主要、核心或任务节点
  • 实例购买选项 – 按需实例、预留实例或 Spot 实例
  • 配置选项 – EMR 实例队列或统一实例组
  • 缩放选项 – 自动缩放 或 Amazon EMR 托管扩展

根据我们的可变工作负载，我们配置了 EMR 实例队列（有关最佳实践，请参阅 值得信赖）。我们还决定使用 Amazon EMR 托管扩展来扩展核心节点和任务节点（有关扩展场景，请参阅 节点分配场景）。最后我们选择了内存优化 AWS 引力子 实例，最多提供 Spark 工作负载的成本降低了 30%，性能提高了 15%.

以下代码提供了我们的集群配置的快照：

Concurrent steps:10

EMR Managed Scaling:
minimumCapacityUnits: 64
maximumCapacityUnits: 512
maximumOnDemandCapacityUnits: 512
maximumCoreCapacityUnits: 512

Master Instance Fleet:
r6g.xlarge
- 4 vCore, 30.5 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units

Core Instance Fleet:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Task Instances:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

性能

通过迁移到 Amazon EMR，我们能够实现能够处理各种数据集的系统性能，范围从低至 273 B 到高达 88.5 GB p99 491 秒（约 8 分钟）。

下图说明了处理的各种文件大小。

下图显示了我们的延迟。

为了与顺序处理进行比较，我们获取了两个包含 53 万条记录的数据集，并相互运行 VLOOKUP 操作以及其他 49 个类似 Excel 的操作。新服务中的处理时间为 26 分钟，而旧服务中的处理时间为 5 天。这一改进在性能方面比之前的架构提高了近 300 倍。

需要考虑的事项

考虑此解决方案时请记住以下几点：

  • 调整集群大小 – 尽管 Amazon EMR 可调整大小，但调整集群大小也很重要。如果集群规模过小，则适当调整规模可以缓解集群缓慢的情况；如果集群规模过大，则可以减轻较高的成本。为了预测这些问题，您可以计算工作负载所需的节点数量和类型。
  • 并行步骤 – 并行运行步骤允许您运行更高级的工作负载、提高集群资源利用率并减少完成工作负载所需的时间。一次允许运行的步骤数是可配置的，并且可以在集群启动时以及集群启动后的任何时间进行设置。当多个作业在单个共享集群中运行时，您需要考虑并优化每个作业的 CPU/内存使用情况。
  • 基于作业的临时 EMR 集群 – 如果适用，建议使用基于作业的瞬态 EMR 集群，该集群可提供卓越的隔离性，验证每个任务是否在其专用环境中运行。这种方法优化了资源利用率，有助于防止作业之间的干扰，并提高整体性能和可靠性。瞬态特性可实现高效扩展，为不同的数据处理需求提供强大且隔离的解决方案。
  • EMR 无服务器 – 如果您不想处理集群的管理和操作，EMR Serverless 是理想的选择。它允许您使用 EMR Serverless 中提供的开源框架轻松运行应用程序，从而提供简单、无忧的体验。
  • Amazon EKS 上的 EMR – EKS 上的 Amazon EMR 提供了独特的优势，例如更快的启动时间和改进的可扩展性，解决了计算容量挑战，这对 Graviton 和 Spot 实例用户特别有利。包含更广泛的计算类型可以提高成本效率，从而实现量身定制的资源分配。此外，多可用区支持提供了更高的可用性。这些引人注目的功能为管理大数据工作负载提供了强大的解决方案，并在各种计算场景中提高了性能、成本优化和可靠性。

结论

在这篇文章中，我们解释了 Amazon 如何使用 Amazon EMR 优化其大批量财务对账流程，以实现更高的可扩展性和性能。如果您有一个依赖垂直扩展来处理其他请求或数据集的单体应用程序，那么将其迁移到 Apache Spark 等分布式处理框架并选择 Amazon EMR 等托管服务进行计算可能有助于缩短运行时间，从而降低交付率SLA 还可能有助于降低总拥有成本 (TCO)。

当我们针对这一特定用例采用 Amazon EMR 时，我们鼓励您在数据创新之旅中探索更多可能性。考虑评估 AWS Glue 以及其他动态 Amazon EMR 部署选项（例如 EMR Serverless 或 EKS 上的 Amazon EMR），以发现适合您独特使用案例的最佳 AWS 服务。数据创新之旅的未来蕴藏着令人兴奋的可能性和进步，有待进一步探索。

作者简介

吉尚·赫特拉帕尔 是亚马逊的高级软件开发工程师，他开发基于云计算无服务器架构的金融科技产品，负责公司的 IT 一般控制、财务报告以及治理、风险和合规性控制。

萨克蒂·米什拉 是 AWS 的首席解决方案架构师，他帮助客户实现数据架构现代化并定义端到端数据策略，包括数据安全性、可访问性、治理等。 他也是这本书的作者 使用 Amazon EMR 简化大数据分析. 工作之余，Sakti 喜欢学习新技术、看电影和与家人一起参观地方。

现货图片

最新情报

现货图片

版权所有@ 2024 Plato Technologies Inc.