亚马逊AWS官方博客
配置和优化 Amazon Athena 联合 Amazon Redshift 查询性能
Original Link: https://aws.amazon.com/cn/blogs/big-data/configure-and-optimize-performance-of-amazon-athena-federation-with-amazon-redshift/
本文主要介绍如何配置 Amazon Athena与AWS Lambda 及Amazon Redshift联合查询，同时遵循性能优化注意事项以保证良好的使用体验。
对于在 Amazon Simple Storage Service (Amazon S3)当中使用数据湖，并选择Amazon Redshift作为数据仓库的用户朋友，大家可能希望将二者集成起来以构建lake house。lake house能够将数据湖与数据仓库无缝加以集成。当您需要使用Amazon Redshift数据仓库查询数据湖时，则可使用Amazon Redshift Spectrum以实现数据湖与数据仓库间的统一协调。但需要强调的是，对于以下两种在数据内使用Athena并访问Amazon Redshift存储数据的场景下，目前尚不存在简单易行的实现方法：
- 团队A在Amazon S3中建立数据湖，同时使用Athena。团队A需要访问归团队B所有的Amazon Redshift集群内的数据。
- 分析师使用Athena对数据湖进行分析查询，且需要以敏捷而灵活的方式、在不将数据移动至Amazon S3数据湖的前提下，对Amazon Redshift数据仓库内的数据进行访问。
在以上场景下，Athena联合Amazon Redshift允许您无缝访问Amazon Redshift数据仓库中的数据，不必等待将数据移动至Amazon S3数据湖的复制过程，从而消除了此类作业的管理开销。
在本文中，我们将逐步进行配置，了解如何使用Lambda设置Athena联合体系以访问Amazon Redshift中的数据。大家还将了解如何对交互式TPC-DS查询及即席TPC-DS查询进行性能基准分析，并了解联合使用场景下的各项性能优化注意事项与最佳实践。
解决方案概述
所谓数据联合，是指使用单一接口将数据集成至另一数据存储中的功能。下图所示，为通过将Lambda与联合数据源相集成，建立起Athena联合数据架构。
Athena是一项交互式查询服务，可帮助用户通过标准SQL轻松分析Amazon S3中的存储数据。Athena具备无服务器特性，因此用户无需管理任何基础设施，只需根据实际运行的查询数量与规模付费。指向Amazon S3内的数据、定义架构，而后使用标准SQL，即可快速执行查询操作。
Lambda可帮助您在无需配置或管理服务器的前提下运行代码。大家几乎能够面向任意应用程序类型运行代码，无需进行任何管理操作，且服务仅在代码运行期间进行计费。
Amazon Redshift是一套专为云环境设计的PB级别数据仓库。Amazon Redshift已经成为当前人气最高、速度最快的云数据仓库方案。将其与您的数据湖集成之后，其性能表现可达任何其他数据仓库的三倍，而成本可低至其他云数据仓库的75%。
下图所示，为截至本文撰稿时，AWS无服务器应用程序存储库中的全部可用数据源连接选项。
AWS无服务器应用程序存储库是一套面向无服务器应用程序的托管代码库，可帮助您轻松存储并共享各类可复用应用程序，以前所未有的强大方式轻松组建及部署无服务器架构。
您也可以在AWS无服务器应用程序存储库之外，创建适合实际需求的自定义连接程序。
先决条件
在开始本轮演练之前，我们首先使用AWS Secrets Manager为Amazon Redshift登录ID与密码创建secret。
- 在Secrets Manager控制台中，选择 Secrets。
- 选择 Store a new secret。
- 为您的Amazon Redshift集群选择凭证，而后设置用户名与密码。
- 选择您希望使用的集群。
- 在Secret name部分，为您的secret输入一条名称。请使用 AthenaJDBCFederation 前缀以便后续查找。
- 其余字段皆保留默认设置，而后选择 Next。
- 完成secret创建。
设置S3存储桶
在Amazon S3控制台上，创建一个供Lambda使用的新S3存储桶与子文件夹。在本文中，我们使用 myworkspace0009/athenafederation名称。
使用Amazon Redshift配置Athena联合
要使用Amazon Redshift配置Athena联合，请完成以下操作步骤：
- 在AWS Serverless Application Repository当中, 选择 Available applications。
- 在搜索字段内，输入 athena federation。
- 选择
- 在Application settings部分，提供以下详细信息：
- Application name – AthenaRedshiftConnector
- SecretNamePrefix – AthenaJdbcFederation
- SpillBucket – myworkspace0009/athenafederation
- JDBCConnectorConfig – Redshift://jdbc:Redshift://<YourAmazon Redshift1Hostname>:5439/<DBName>?user=sample2&password=sample2
- DisableSpillEncyption – False
- LambdaFunctionName – rstpcds30
- SecurityGroupID – Amazon Redshift部署所在的安全组ID
- SpillPrefix – 保留默认值
- Subnetids – 使用Amazon Redshift运行所在的子网，以逗号分隔
- 选择 I acknowledge复选框。
- 选择 Deploy。
在后续步骤中，我们将为Amazon S3配置Amazon Virtual Private Cloud (Amazon VPC)端点，以允许Lambda向Amazon S3写入联合查询结果。
- 在Amazon VPC控制台上, 选择 Endpoints。
- 选择 Create endpoint。
- 为您的端点选择VPC。
- 根据您的安全要求，进行必要的安全选项更改。
- 选择 Create endpoint。
使用 Athena运行联合查询
要开始运行联合查询，您需要完成以下步骤：
- 在Athena控制台上, 选择 Workgroups。
- 如果没有显示名为 AmazonAthenaPreviewFunctionality的工作组，请创建一个。
目前此项功能尚在预览阶段，在发布通用版本后，您将无需使用此工作组名称。
- 使用 lambda:rstpcds30对Amazon Redshift内的表运行查询。
Athena查询性能比较
部分客户要求我们就Athena中的查询与联合查询进行性能比较，同时提供全面的说明性操作指导。在本节中，我们将使用TPC-DS 3 TB标准数据集执行即席与交互式查询操作。通过比较二者的性能，大家可以建立对Amazon Redshift运行联合查询时的基本性能预期。
在以下测试中，我们将3 TB TPC-DS数据集保存在Amazon S3数据湖当中，以Parquet格式进行压缩，并由Athena提供分区与服务支持。在另一方面，我们将同一套3 TB TPC-DS数据集保存在运行有四个RA3.4XL节点的Amazon Redshift集群之上。
下表对这套数据集的情况做出总结：
| 数据集 | 表大小（记录数量） |
| store_sales | 86亿条 |
| customer | 3000万条 |
| customer_address | 1500万条 |
| customer_demographics | 192万条 |
| item | 36万条 |
| date_dim | 73000条 |
| store | 1350条 |
在本次演练中，我们运行以下四项测试：
- T1 – 以非联合方式在Athena中运行的查询。全部表数据存储在Amazon S3之内。
- T2 – 以联合方式在Athena运行的、指向Amazon Redshift的查询。所有表数据存储在Amazon S3内，只有store_sales事实表存储在Amazon Redshift内。
- T3 – 以联合方式在Athena运行的、指向Amazon Redshift的查询。所有表数据存储在Redshift内。
- T4 – 以非联合方式在Amazon Redshift中运行的查询。所有表与数据存储在Redshift内。
下图所示，为部分即席及交互TPC-DS查询的性能结果。
在上图中，由于Lambda设定有900秒的超时限制，因此所有T3查询都在900秒处发生超时，如粉红色参考线所示。这是因为store_sales事实数据的运行负载过高，需要将相关数据转移回Athena。
下图删除了T3测试的相关数据，保证为其他测试结果提供更好的直观比较效果。
需要注意的是，T1与T2之间的查询性能几乎保持一致，而T4查询的运行速度明显更快。
Amazon Redshift在延迟表现方面优于Athena，因此如果您需要在分析查询当中获得Athena无法实现的低延迟SLA（服务水平协议），请优先选择Amazon Redshift。
下图所示，为Amazon S3中T1与T2测试的扫描数据，我们可以由此大体看出其查询性能与联合查询相比为何没有明显差异。
在T2联合查询方面，相较于扫描整个维度表，我们只需要对Amazon Redshift中的少量维度数据进行过滤并将其移动至Athena。这也是部分即席及交互查询的典型特征。
可以看到，TPC-DS查询场景下的T1与T2性能基本相当，因为需要传输回Athena的数据量极低。大家可以在多项即席与交互查询用例中看到类似的结果，这是因为其只需要通过有限的维度扫描一小部分维度数据。由于接入Amazon Redshift的Lambda实例设定有900秒超时限制，因此建议大家尽量减少查询操作所返回的数据量。虽然Athena会使用多个Lambda实例并发运行联合查询，但大家需要保证Amazon Redshift WLM队列中拥有足够的处理空位，借此缩短队列等待时长。例如，在以上部分查询当中，会有20项Lambda实例同时接入Amazon Redshift。
性能最佳实践与重要注意事项
在考虑使用Athena联合Amazon Redshift查询时，建议大家考虑以下最佳实践：
- Athena联合方案特别适合使用谓词过滤的查询操作，期间各谓词会被下放至Amazon Redshift。配合查询中的过滤条件与范围限制，即可避免执行全表扫描。
- 如果您的SQL查询需要从Amazon Redshift向Athena返回大量数据（可能导致查询超时或性能降低），请通过Redshift将查询中的大表转移至Amazon S3数据湖。
- 星型建模是Amazon Redshift中的一种常见数据模型。在星形建模模型当中，大型事实表将被转移至数据湖内，而维度表则继续保留在Amazon Redshift当中。一旦大型表导致性能降低或查询超时，建议大家将这些表转移至数据湖内。
- 在运行联合查询时，Athena会启动多项Lambda函数，并导致数据库连接数量激增。因此，您需要监控Amazon Redshift WLM队列中的空位以避免长时间排队。另外，大家也可以在Amazo Redshift集群上使用并发扩展以扩大队列容量。
总结
在本文中，我们探讨了如何使用Lambda配置并使用Athena联合AmazonRedshift功能。现在，您无需等待从Amazon Redshift数据仓库到Amazon S3的数据转移流程，也不再需要负担查询的日常维护工作。您也可以使用本文中介绍的最佳实践与注意事项，最大程度减少Amazon Redshift传出的数据量，借此提升性能表现。结合本文演练部分使用的TPC-DS基准查询，只要关注查询编写质量，联合查询与直接查询的性能将基本保持一致！