发布于: Jun 23, 2022
我们从不同的数据来源获取的数据，如 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 集群填满数据，而是用它来执行高效计算。
1. 中央数据仓库数据湖 (Andes) – Amazon 中几乎所有系统都希望将其数据与其他团队共享，并将其数据发布到该数据湖中。它是一种在 Amazon S3 之上创建的加密存储，数据文件附有元数据。每个数据集都有一次性转储，然后是增量 delta 文件。团队通常通过以下方式使用数据：
- 将数据实际复制到他们自己的 Amazon Redshift 集群中，这对于最经常访问的中小型表而言是非常高效的。
- 利用 Amazon Redshift Spectrum 对存储在数据湖中的数据集运行分析查询。它有助于访问较大的冷数据（通常超过 50TB），从而避免仅仅因为所有空间可能被这些较大的数据文件消耗而扩展您的 Amazon Redshift 集群。
- 利用 Amazon Web Services Glue 目录更新您的团队的 S3 存储桶中的元数据并利用 Amazon EMR 提取数据、应用转换、更改格式并将最终数据存储在 S3 存储桶中，从而通过 Amazon Redshift Spectrum 进一步利用这些数据。当数据集较大且需要在使用之前进行转换时，这种方法就会非常高效。
2. Amazon Redshift 集群 – Amazon Redshift 具有中央架构，非常适合成为所有事实来源的单一位置。但我们之所以管理三个集群，主要是因为我们的报告具有一致的服务等级协议，以便将用户查询体验与中央数据湖摄取流程（资源密集型）进行松耦合。以下是我们需要单独集群的集群特定原因：
- 转储集群：
o 我们的数据源是动态的，处于转换状态并从关系数据源移至非关系数据源；例如，从 Oracle 到 Postgres 或到 DynamoDB。
o 从中央数据湖提取数据并存储在 Amazon Redshift 中的机制也在不断发展，在当前状态下属于资源密集型。
o 我们的数据集市专门针对支付，虽然我们的数据集市中的表名称与中央数据湖表的名称相似，但我们的数据集市数据与中央数据湖数据集并不一样。在将数据导入用户的 Amazon Redshift 集群之前，我们会应用必要的转换并进行筛选。
- 用户集群：我们的内部业务用户希望在公共架构中创建表以进行分析。他们还需要直接访问任何临时分析。大多数用户知晓 SQL，也了解最佳实践，但也有些用户并不了解 SQL，有时候他们的查询未经过优化并会影响其他正在运行的查询，我们的 Amazon Redshift 工作负载管理器 (WLM) 设置能够保护我们的集群免受这些糟糕查询的影响。
- 生产 ETL 集群：我们有严格的服务等级协议，使数据集对数据用户可用。为了最大限度降低系统中运行的糟糕查询的影响，我们设置了用户集群的副本。所有生产转换均在这里进行，输出数据也将复制给用户和生产集群。这样可确保遵守我们向数据业务用户承诺的服务等级协议。
- 近实时的数据摄取 – 推广数据、卡片登记、礼品卡发行等许多应用需要实时收集数据以发现欺诈行为。应用数据存储在 Amazon DynamoDB 中，并启用了 DynamoDB Streams。我们通过 Amazon Web Services 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 中创建、加载、截断/删除表。