在具有 750TB 数据的 Amazon Redshift 上运行 Amazon Payments 分析 | AWS 大数据博客

Original URL:https://aws.amazon.com/blogs/big-data/running-amazon-payments-analytics-on-amazon-redshift-with-750tb-of-data/

Amazon Payments 数据工程团队负责进行数据提取、转换和存储超过 750TB 的不断增长的数据集，该团队为全球超过 300 多个企业客户提供这些服务。这些客户包括产品经理、市场营销经理、项目经理、数据科学家、业务分析师和软件开发工程师。他们利用这些数据进行有计划的和即席查询，从而帮助他们做出正确的商业决策。这些数据还用于构建每周、每月和每季度的业务评估指标，供领导团队进行审核。我们为各种消费者支付业务团队提供支持，包括：

Amazon Payment 产品（信用卡、积分购物、亚马逊货币转换器、国际支付产品）
礼品卡
收款体验
Amazon 商业支付。

我们还为机器学习推荐引擎提供支持，该引擎在 Amazon 的付款结账页面为客户推荐最佳支付产品。

旧数据仓库面临的挑战

本部分描述了我们的数据仓库和分析需求之前面临的挑战。随着支付产品的推出并延伸到新的市场，我们的数据量开始呈指数式增长。随后，扩展我们提取、转换和加载过程 (ETL) 面临着严峻的挑战，并给我们带来了数据可用延迟和运营负担增加。以下是我们的数据仓库面临的具体挑战：

当每批数据超过 1000 万时，Upserts 无法很好的扩展。一个关键的消费品目录数据集（记录数超过 65 亿行）经历了超过1000万行标记的越来越频繁的更新。我们在关键客户订单属性数据集也观察到了相似的趋势。
如果我们要分析 6 个月的支付数据，数据聚合要么花费时间较长，要么无法完成。通常情况下，业务负责人希望根据特定属性聚合数据。例如，成功交易数以及按特定卡片类型统计的币值。
共享集群以及由之而来的共享存储与计算造成资源紧缺，并影响其所有用户。每个团队在每个数据仓库中获得大约 100TB 的容量。每个团队可以提供自己的表并与中央数据仓库表连接在一起。集群中任何糟糕的查询均会影响同一集群中的所有其他查询，却又很难确定执行这些糟糕查询的人究竟是谁。
生产表的数量超过 30000 个，在同一集群中存储它们几乎是不可能的。
如果较大表的索引损坏，重建并回填表将会非常复杂且耗时。
我们需要数据库管理员来应用补丁和更新。

使用 Amazon RedShift 作为新的支付数据仓库

我们开始寻求能够满足我们的分析需求，能迅速、可靠且能随未来数据的增长而很好扩展的其他方案。鉴于上述所有问题，中央数据仓库开始将计算层和存储层分离开来，并决定担负起存储负载。它们在 Amazon S3 上创建了一个数据湖，经过加密可存储甚至最机密的关键数据。每个消费者团队均获得了满足其分析需求的计算容量指南。我们的支付团队开始寻求以下优势：

权宜分析。
与 S3 及其他 AWS 服务集成。
经济实惠的存储和计算率。
可进行 ETL 处理。

我们之所以选择 Amazon RedShift，是因为它具有以下功能：

批量上传速度更快。7 亿左右的数据插入仅需 30 分钟左右。
数据的更新插入速度极快。
对具有较少列的数据的数百万数据集进行聚合查询可在几秒钟内返回结果，而其他解决方案需要花费几分钟的时间。
数据库管理员无需费时维护数据库。数据工程师可轻松执行备份、重新拍摄快照以应用到新集群、设置提醒以在出现集群问题时获得提醒，并添加新节点。
能够在 S3 上存储数据。可通过 Spectrum 从多个独立的 Amazon Redshift 集群访问这些数据，并允许用户将 Spectrum 表与在 Amazon Redshift 上本地创建的其他表连接起来。它能够将某些处理分流到 Spectrum 层，同时将数据存储在 S3 上。
能利用 Amazon Redshift 最佳实践设计有关分配键、排序键和压缩的表。因此，查询性能超出了我们的服务等级协议预期。
有效的压缩系数。选择合适的压缩系数可节省超过 40% 到 50% 的空间，这有助于实现更快的查询和高效的存储选项。

数据和存储的来源

我们从不同的数据来源获取的数据，如 PostgreSQL、Amazon DynamoDB 实时流、中央数据仓库数据湖和银行合作伙伴的数据。PostgreSQL 数据库中的数据采用关系格式，而 DynamoDB 则采用键值对形式。我们将键/值数据转化为关系格式并存储在 Amazon Redshift 和 S3 中。最经常访问的数据存储在 Amazon Redshift 中，不经常访问且较大的数据集存储在 S3 中并通过 Amazon Redshift Spectrum 访问。

中央数据湖存储了超过 30000 个来自不同团队的表，例如订单、货物和退款。而我们支付团队需要使用该数据湖中约 200 个表格作为源表。之后，我们创建了特定支付产品的数据集市，它既能够满足有计划和一次性数据的需求，又能够满足报表的需求。所有中小型表（小于 50TB）都会从实际存储数据的数据湖直接加载到 Amazon Redshift。大于 50TB 的表不会本地存储在 Amazon Redshift 中，我们会利用 EMR-Hive 将其从数据湖中提取出来，将格式从 tsv 转换为 ORC/Parquet，然后存储在 S3 中。我们以 S3 数据为基础创建 Amazon Redshift Spectrum 表。格式转换缩短了每个分析聚合查询的运行时间，而存储在 S3 上确保我们不会将整个 Amazon Redshift 集群填满数据，而是用它来执行高效计算。

数据架构

不同的组件

中央数据仓库数据湖 (Andes) – Amazon 中几乎所有系统都希望将其数据与其他团队共享，并将其数据发布到该数据湖中。它是一种在 Amazon S3 之上创建的加密存储，数据文件附有元数据。每个数据集都有一次性转储，然后是增量 delta 文件。团队通常通过以下方式使用数据：

将数据实际复制到他们自己的 Amazon Redshift 集群中，这对于最经常访问的中小型表而言是非常高效的。
利用 Amazon Redshift Spectrum 对存储在数据湖中的数据集运行分析查询。它有助于访问较大的冷数据（通常超过 50TB），从而避免仅仅因为所有空间可能被这些较大的数据文件消耗而扩展您的 Amazon Redshift 集群。
利用 AWS Glue 目录更新您的团队的 S3 存储桶中的元数据并利用 Amazon EMR 提取数据、应用转换、更改格式并将最终数据存储在 S3 存储桶中，从而通过 Amazon Redshift Spectrum 进一步利用这些数据。当数据集较大且需要在使用之前进行转换时，这种方法就会非常高效。

Amazon Redshift 集群 – Amazon Redshift 具有中央架构，非常适合成为所有事实来源的单一位置。但我们之所以管理三个集群，主要是因为我们的报告具有一致的服务等级协议，以便将用户查询体验与中央数据湖摄取流程（资源密集型）进行松耦合。以下是我们需要单独集群的集群特定原因：

转储集群：
- 我们的数据源是动态的，处于转换状态并从关系数据源移至非关系数据源；例如，从 Oracle 到 Postgres 或到 DynamoDB。
- 从中央数据湖提取数据并存储在 Amazon Redshift 中的机制也在不断发展，在当前状态下属于资源密集型。
- 我们的数据集市专门针对支付，虽然我们的数据集市中的表名称与中央数据湖表的名称相似，但我们的数据集市数据与中央数据湖数据集并不一样。在将数据导入用户的 Amazon Redshift 集群之前，我们会应用必要的转换并进行筛选。

用户集群：我们的内部业务用户希望在公共架构中创建表以进行分析。他们还需要直接访问任何临时分析。大多数用户知晓 SQL，也了解最佳实践，但也有些用户并不了解 SQL，有时候他们的查询未经过优化并会影响其他正在运行的查询，我们的 Amazon Redshift 工作负载管理器 (WLM) 设置能够保护我们的集群免受这些糟糕查询的影响。
生产 ETL 集群：我们有严格的服务等级协议，使数据集对数据用户可用。为了最大限度降低系统中运行的糟糕查询的影响，我们设置了用户集群的副本。所有生产转换均在这里进行，输出数据也将复制给用户和生产集群。这样可确保遵守我们向数据业务用户承诺的服务等级协议。

近实时的数据摄取 – 推广数据、卡片登记、礼品卡发行等许多应用需要实时收集数据以发现欺诈行为。应用数据存储在 Amazon DynamoDB 中，并启用了 DynamoDB Streams。我们通过 AWS Lambda 函数和 Amazon Kinesis Data Firehose 使用来自这些流的数据。Kinesis Firehose 将数据传输到 S3，然后提交复制命令以将数据加载到 Redshift 中。我们具有 15 分钟的微批次，以确保这些近实时的数据应用不会用掉所有连接。
Amazon EMR 的备用计算 – 我们通过点击流源接收网站点击数据，每个 Marketplace 一天的数据记录可以高达数十亿条。这些大型数据集至关重要，但却不经常在 Amazon Redshift 上访问。我们决定使用 S3 作为存储选项，并利用 Amazon EMR 应用转换。凭借这种方法，我们确保不会在数据库中填满大量冷数据，与此同时还可以通过 Amazon Redshift Spectrum 访问 S3 上的数据，这提供了相似的查询性能。由于 Amazon Redshift 是一个列式数据库，如果我们选择较少的维度列，它可以极其迅速地进行任何类型的聚合。我们希望我们存储在 S3 上的数据能够具有相似的性能，这一点利用 Amazon EMR 并且将数据格式从 TSV 更改为 ORC 或 Parquet 就可以做到。我们每天在 S3 上创建新分区数据，并对 Amazon Redshift Spectrum 表定义进行刷新以包含新分区数据。业务用户可通过任何 Amazon Redshift SQL 客户端访问这些 Spectrum 表以进行一次性分析或计划任何 ETL 管道。

Schema 管理

我们的生产 schema 存储所有生产表，并且只有平台团队才有权限对其进行更改。我们还提供特定于支付产品的沙箱，产品特定成员可以访问。任何支付数据用户均具有通用公共 schema。他们可以在该 schema 中创建、加载、截断/删除表。

数据库和 ETL 查找

以下是关于我们的 Amazon Redshift 数据库对象的一些有趣事实。

表的数量：
- - 分析生产数据库：6500
  - 分析转储数据库：390

下一节将解释这一需求，并显示关于我们拥有的三个集群中每一个集群的一些统计信息。

转储集群

以下是关于转储数据库的一些统计信息。它存储来自其他团队或中央数据仓库数据湖的所有数据。已对所有表格应用表保留，因为大多数 ELT 下游作业都会查找上次更新的日期，仅提取增量数据并存储在用户和副本数据库中。

用户集群

向业务用户开放，并且可以运行他们的即席查询。
存储业务用户运行分析查询所需的所有表。
用户可以根据他们的需要在他们的模式中创建他们的表。

数据平台集群

数据平台集群存储业务用户集群中存在的所有表，为即席分析创建的表除外。
它主要用于运行与ETL平台相关的生产管道作业。
Amazon S3归档了大多数此类表的整个历史记录，除了点击流数据集之类的快照表。

以下是用户和数据平台集群的一些统计信息。

数据库上的计划 ETL 和查询负载

日提取 ETL 作业的数量：2943
加载的 ETL 作业数：1655

日负载处理总量：1190 亿
日加载总运行时间：11415 分钟

日数据摄取总量：1660 亿
每日日期摄取总运行时间：25585 分钟

数据库上的计划和一次性查询负载

按不同数据库用户显示的数据库每日查询负载。

最佳实践

使用正确的排序键和分配键设计表格：查询性能取决于其扫描的数据量以及连接是否是同区连接。选择正确的排序键能够确保我们不会扫描不需要的数据，而选择正确的分配键能够确保连接的数据存在于同一节点上，并且减少数据在网络上的移动可提升查询性能。有关更多信息，请参阅在Amazon Redshift 上设计表格的最佳实践。

请在编写查询时参阅在 Amazon Redshift 上设计查询的最佳实践。

将较大的文件拆分成较小的文件，使用批量加载而非连续插入，从而更改加载策略。有关更多信息，请参阅 Amazon Redshift 上加载数据的最佳实践。

通过分配正确的运行时间、内存、优先队列等配置相应的工作负载管理设置，以避免系统滥用。有关更多信息，请参阅教程：配置工作负载管理 (WLM) 队列以改进查询处理。

利用 Amazon Redshift Advisor 确定可能需要压缩的表、缺失统计信息的表、未压缩的数据负载，并进一步微调您的 ETL 管道。有关更多信息，请参阅采用 Amazon Redshift Advisor 的建议。

确定最浪费空间的表并经常清空它们。这能够释放浪费的空间，同时提升查询性能。有关更多信息，请参阅对表执行 vacuum 操作。

分析提交到数据库的 SQL 并识别表使用模式和消耗较高的连接。它能够帮助数据工程师预连接这些表，从而创建更多反范式化表，并帮助用户迅速、高效地访问单个表。

小结和后续步骤

Amazon Redshift 集群的总容量为 1.15PB、约 6500 个表、4500 个计划 ETL 运行、一天 13000 个 ETL 查询，解决了支付团队业务用户的几乎全部 ETL 需求。但是，最近的数量增长填满了我们的数据库系统，这超出了我们的预期。接下来我们需要选择更实惠的存储选项：在 S3 上创建数据湖并通过 Amazon Redshift Spectrum 访问它们，这样我们甚至不必担心遇到扩展挑战，而且能提供无缝的用户体验。

亚马逊AWS官方博客