利用 Amazon Redshift 实现高效的电商数据抓取、转换、存储

 

数据仓库和分析需求之前面临的挑战。随着支付产品的推出并延伸到新的市场，我们的数据量开始呈指数式增长。随后，扩展我们提取、转换和加载过程面临着严峻的挑战

 

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

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

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

 

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

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

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

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

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

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

返回上一级 云数据库文章 >>