亚马逊AWS官方博客

Amazon Devices 如何使用 Serverless Data 无服务器分析实现实时需求和供应预测

每天，Amazon 设备都会处理和分析来自全球运输、库存、容量、供应、销售、营销、生产商和客户服务团队的数十亿个事务。这些数据用于采购设备库存以满足 Amazon 客户的需求。随着数据量同比增长百分比达到了两位数，而且 2021 年 COVID 疫情严重扰乱了全球物流，扩展和生成近实时数据的重要性与日俱增。

本文向您展示了我们如何迁移到在 AWS 上构建的无服务器数据湖，从而自动使用来自多个来源和不同格式的数据。此外，它还为我们的数据科学家和工程师创造了更多机会，使他们能够使用人工智能（AI）和机器学习（ML）服务持续提供数据和分析数据。

挑战和设计问题

我们的传统架构主要使用 Amazon Elastic Compute Cloud（Amazon EC2）从各种内部异构数据来源提取数据，将 REST API 与 Amazon Simple Storage Service（Amazon S3）结合使用来加载数据，并使用 Amazon Redshift 进行进一步的分析和生成采购订单。

我们发现这种方法带来了一些缺陷，因此推动了以下领域的改进：

  • 开发人员速度 – 由于缺乏统一性和架构发现（这是运行时失败的主要原因），开发人员经常需要花时间处理操作和维护问题。
  • 可扩展性 – 大多数这些数据集均在全球范围内共享。因此，我们在查询数据时必须满足缩放限制。
  • 尽可能减少基础设施维护 – 根据数据来源，当前处理跨越多个计算。因此，减少基础设施维护至关重要。
  • 对数据来源变化的响应能力 – 我们当前的系统从各种异构数据存储和服务获取数据。对这些服务的任意更新都需要数月的开发周期。这些数据来源的响应时间对我们的主要利益相关者至关重要。因此，我们必须采用数据驱动型方法来选择高性能架构。
  • 存储和冗余 – 由于数据存储和模型的异构性，存储来自不同业务利益相关者团队的不同数据集颇具挑战性。因此，提供版本控制以及增量和差异数据比较，可以为生成最优计划提供卓越的功能
  • 灵活性和可访问性 – 由于物流的不稳定性，一些业务利益相关者团队需要按需分析数据，并近实时地为采购订单生成最佳计划。这带来了轮询和推送数据的需求，以进行近实时的访问和分析。

实施策略

根据这些要求，我们改变了策略，开始分析每个问题以确定解决方案。在架构上，我们选择了无服务器模型，而数据湖架构行动方针考虑了我们确定的所有架构差距和具有挑战性的功能，这些都包括在改进中。从运营角度来看，我们使用 AWS Glue 为数据摄取设计了新的责任共担模式，而不是使用在 Amazon EC2 上设计的内部服务（REST API）来提取数据。我们还使用 AWS Lambda 进行数据处理。然后，我们选择了 Amazon Athena 作为查询服务。为了进一步优化和提高我们数据使用者的开发人员速度，我们添加了 Amazon DynamoDB 作为存储在数据湖中的不同数据来源的元数据存储。这两个因素决定推动了我们制定的每一项设计和实施决策。

下图展示了此架构

架构

在以下部分中，我们将随着整个处理流，更详细地介绍架构中的每个组件。

用于 ETL 的 AWS Glue

为了满足客户需求，同时支持新业务数据来源的规模，我们极为重视在查询各种数据来源时具有高度的灵活性、可扩展性和响应能力。

AWS Glue 是一种无服务器数据集成服务，可让分析用户轻松地发现、准备、移动和集成来自多个来源的数据。您可以将该服务用于分析、机器学习和应用程序开发。该服务还提供额外的生产力工具和 DataOps 工具，可用于创作、运行作业和实施业务工作流。

使用 AWS Glue，您可以发现并连接到 70 多种不同的数据来源，并在集中式数据目录中管理自己的数据。您可以直观地创建、运行和监控提取、转换、加载（ETL，Extract, Transform, and Load）管道，将数据加载到数据湖中。此外，您可以使用 Athena、Amazon EMR 和 Amazon Redshift Spectrum 立即搜索和查询编目数据。

AWS Glue 使我们能够轻松连接到各种数据存储中的数据，根据需要编辑和清理数据，以及将数据加载到 AWS 预置存储中以获得统一视图。AWS Glue 作业可以按计划或按需调用，从客户的资源和数据湖中提取数据。

这些作业的一些职责如下：

  • 提取源实体并转换为数据实体
  • 扩充数据以包含年、月和日，从而更好地进行编目，并添加快照 ID 以更好地进行查询
  • 为 Amazon S3 执行输入验证和路径生成
  • 根据源系统关联经认证的元数据

来自内部服务的查询 REST API 是我们的核心挑战之一，考虑到尽可能减少基础设施，我们希望在这个项目中使用它们。AWS Glue 连接器帮助我们遵守要求和达成目标。为了从 REST API 和其他数据来源查询数据，我们使用了 PySpark 和 JDBC 模块。

AWS Glue 支持多种连接类型。有关详细信息，请参阅 AWS Glue 中的 ETL 的连接类型和选项。

S3 存储桶作为登录区

我们使用 S3 存储桶作为所提取数据的直接登录区，并对该存储桶进行了进一步处理和优化。

Lambda 作为 AWS Glue ETL 触发器

我们在 S3 存储桶上启用了 S3 事件通知以触发 Lambda，用于进一步对数据进行分区。数据按 InputDataSetName、Year、Month 和 Date 分区。对此数据运行的任何查询处理程序都将仅扫描数据的子集，以更好地优化成本和性能。我们的数据可以使用多种格式存储，例如 CSV、JSON 和 Parquet。

对于我们的大多数使用场景来说，原始数据并不适合用于生成最佳计划，因为它经常有重复或不正确的数据类型。最重要的是，数据有多种格式，但我们可以快速修改数据，并发现使用 Parquet 格式可以显著提高查询性能。在这里，我们使用了 Amazon Athena 十大性能优化技巧中的一个性能提示。

使用 AWS Glue 作业执行 ETL

我们需要更好的数据分隔和可访问性，因此我们选择使用不同的 S3 存储桶来进一步提高性能。我们使用相同的 AWS Glue 作业进一步转换数据并将数据加载到所需的 S3 存储桶中，以及将一部分提取的元数据加载到 DynamoDB 中。

将 DynamoDB 作为元数据存储

现在我们准备好了数据，可供各个业务利益相关者进一步使用。这给我们留下了两个问题：哪些源数据位于数据湖上，以及数据是什么版本。我们选择 DynamoDB 作为我们的元数据存储，它为使用者提供最新的详细信息，以便高效地查询数据。我们系统中的每个数据集都由快照 ID 唯一标识，我们可以从元数据存储中搜索它。客户端使用 API 访问此数据存储。

将 Amazon S3 作为数据湖

为了提高数据质量，我们使用相同的 AWS Glue 作业，将扩充后的数据提取到另一个 S3 存储桶中。

AWS Glue 爬网程序

爬网程序是使我们能够灵敏响应架构变化的“秘诀”。在整个过程中，我们选择让每个步骤尽可能与架构无关，这使得任何架构更改都可以顺利地通过处理，直到抵达 AWS Glue。使用爬网程序，我们可以保持架构上发生的不可知的变化。这帮助我们自动从 Amazon S3 爬取数据并生成架构和表。

AWS Glue Data Catalog

Data Catalog 帮助我们将目录作为数据位置、架构以及 Amazon S3 中的运行时指标的索引进行维护。Data Catalog 中的信息存储为元数据表，其中每个表指定一个数据存储。

使用 Athena 进行 SQL 查询

Athena 是一种交互式查询服务，可使用标准 SQL 轻松分析 Amazon S3 中的数据。Athena 是一种无服务器服务，因此您无需管理任何基础设施，而且只需为所运行的查询付费。我们认为，操作稳定性和提高开发人员速度是我们的关键改进因素。

我们进一步优化了查询 Athena 的流程，这样用户可以插入值和查询，通过创建以下对象，从 Athena 获取数据：

  • 一个 AWS Cloud Development Kit（AWS CDK）模板，用于创建 Athena 基础设施；以及 AWS Identity and Access Management（IAM）角色，用于从任何账户访问数据湖 S3 存储桶和 Data Catalog
  • 一个库，使客户端可以提供 IAM 角色、查询、数据格式和输出位置，用于启动 Athena 查询，并获取在所选存储桶中运行的查询的状态和结果。

查询 Athena 的过程分为两步：

  • StartQueryExecution – 这将启动查询运行并获取运行 ID。用户可以提供输出位置用于存储查询输出。
  • GetQueryExecution – 这会获取查询状态，因为运行是异步的。成功后，您可以在 S3 文件中或通过 API 查询输出。

用于开始运行查询和获取结果的辅助程序方法在库中提供。

数据湖元数据服务

此服务为自定义开发，以 REST API 的形式与 DynamoDB 交互，用于获取元数据（数据集名称、快照 ID、分区字符串、时间戳和数据的 S3 链接）。发现架构后，客户端使用 Athena 作为查询处理程序来查询数据。

由于所有数据集的快照 ID 均已分区，因此联接查询不会导致全表扫描，只会在 Amazon S3 上进行分区扫描。我们使用 Athena 作为查询处理程序，因为它易于使用，我们无需管理查询基础设施。以后，如果我们觉得还需要更多的功能，可以使用 Redshift Spectrum 或 Amazon EMR。

小结

Amazon 设备团队使用 AWS Glue 迁移到数据湖架构后发现了巨大的价值，使得多个全球业务利益相关者能够以更有效的方式摄取数据。团队因而能够使用合适的业务逻辑，近实时地分析不同的数据集，从而制定最佳计划，下达设备采购订单，以便解决供应链、需求和预测的问题。

从运营角度来看，这项投资已经开始获得回报：

  • 它标准化了我们的摄取、存储和检索机制，节省了数据载入时间。在实施该系统之前，一个数据集需要 1 个月的时间才能载入。得益于新架构，我们能够在不到 2 个月的时间内载入 15 个新数据集，将我们的敏捷性提高了 70%。
  • 它消除了扩展瓶颈，创建了一个可以快速扩展到数千个运行实例的同构系统。
  • 该解决方案添加了架构和数据质量验证，在接受任何输入之前需要进行验证，并在发现数据质量违规时拒绝这些输入。
  • 它简化了对数据集的检索，同时面向未来的模拟和反向测试使用场景，支持需要带版本控制的输入。这将使模型的启动和测试变得更加简单。
  • 该解决方案创建了一个通用基础设施，可以轻松扩展到 DIAL 中在数据摄取、存储和检索使用场景方面遇到类似问题的其他团队。
  • 我们的运营成本下降了近 90%。
  • 我们的数据科学家和工程师可以高效地访问该数据湖以进行其他分析，并以预测方法作为面向未来的契机，为采购订单制定准确的计划。

这篇博文中的步骤可帮助您计划使用 AWS 托管服务构建类似的现代数据策略，以便从不同来源提取数据，自动创建元数据目录并在数据湖和数据仓库之间无缝共享数据，以及在出现编排数据工作流程失败时创建警报。

关于作者

avinash_kolluriAvinash Kolluri 是 AWS 的高级解决方案架构师。他的职责范围包括 Amazon Alexa 和 Devices，负责设计架构和设计现代化分布式解决方案。他爱好的工作是在 AWS 上构建经济实惠且高度可扩展的解决方案。闲暇时间他喜欢烹饪各式菜谱和旅行。

vipulVipul Verma 是 Amazon.com 的一位高级工程师。自 2015 年以来，他一直在 Amazon 工作，通过直接影响和改善 Amazon 客户生活的技术来解决现实世界中的挑战。在闲暇时间，他喜欢滑雪。