从 2025 年 11 月 1 日起,Amazon Redshift 将不再支持创建新的 Python UDF。如果您想要使用 Python UDF,请在该日期之前创建 UDF。现有的 Python UDF 将继续正常运行。有关更多信息,请参阅博客文章
Amazon Redshift Serverless 的计费
计算容量的计费
您可以通过两种方式购买 Amazon Redshift Serverless 的容量:
您可以同时使用预留和按需资源。但不强制要求您要使用其中哪种方法。
有关详细的定价信息,请参阅 Amazon Redshift 定价
对存储计费
主存储容量按 Redshift 托管式存储 (RMS) 计费。存储按 GB/月计费。存储计费与计算容量的计费是分开的。用于用户快照的存储按标准备份账单费率计费,具体取决于使用套餐。
数据传输成本和机器学习 (ML) 成本单独计费,与预置集群适用相同的费率。跨 AWS 区域的快照复制和数据共享按定价页面上列出的传输费率计费。有关更多信息,请参阅 Amazon Redshift 定价
使用 CloudWatch 可视化使用情况计费
将生成指标 SnapshotStorage
(用于跟踪快照存储使用情况)并发送到 CloudWatch。有关 CloudWatch 的更多信息,请参阅什么是 Amazon CloudWatch?
使用 Amazon Redshift Serverless 免费试用版
Amazon Redshift Serverless 提供免费试用。如果您参加免费试用,则可以在 Redshift 控制台中查看免费试用积分余额,然后在 SYS_SERVERLESS_USAGE 系统视图中检查免费试用使用情况。请注意,免费试用的账单详细信息不会显示在账单控制台中。免费试用结束后,您只能在账单控制台中查看使用情况。有关 Amazon Redshift Serverless 免费试用版的更多信息,请参阅 Amazon Redshift Serverless 免费试用
账单使用注释
-
记录使用情况 - 查询或事务仅在事务完成、回滚或停止后才计量和记录。例如,如果事务运行两天,则在此事务完成后记录 RPU 使用情况。您可以通过查询
sys_serverless_usage
来实时监控正在进行的使用情况。事务记录可能反映为 RPU 使用情况变化,并影响特定小时数和每日使用情况的成本。 -
编写显式事务 - 作为结束事务的最佳实践,这一点很重要。如果您没有结束或回滚未结事务,Amazon Redshift Serverless 将继续使用 RPU。例如,如果您编写一个显式
BEGIN TRAN
,务必具有相应的COMMIT
和ROLLBACK
语句。 -
已取消的查询 - 如果您运行了查询并在查询结束之前将其取消,您仍需要按查询运行时间付费。
-
扩缩 - Amazon Redshift Serverless 实例可以启动扩缩以处理较高负载时段,从而保持一致的性能。您的 Amazon Redshift Serverless 账单同时包括以相同 RPU 费率计算的基本计算和扩展容量。
-
缩减 - Amazon Redshift Serverless 从其基本 RPU 容量纵向扩展以处理负载较高的时期。在某些情况下,在查询负载下降后的一段时间内,RPU 容量可以保持在较高的设置。我们建议您在控制台中设置最大 RPU 小时数,以防止出现意外的成本。
-
系统表 - 查询系统表时,会对查询时间进行计费。
-
Redshift Spectrum - 当您拥有 Amazon Redshift Serverless 并运行查询时,不对数据湖查询单独收费。对于针对 Amazon S3 中存储的数据进行的查询,按事务时间计算,费用与针对本地数据进行的查询相同。
-
联合查询 - 联合查询按特定时间间隔内使用的 RPU 付费,与针对数据仓库或数据湖的查询相同。
-
存储 - 存储单独收费,按 GB/月计费。
-
最低收费 – 计算资源的使用最低收取 60 秒的费用,按秒计费。
-
快照计费 - 快照计费不变。它根据存储空间收费,按每月 GB 的费率计费。您可以按 30 分钟的粒度将数据仓库还原到过去 24 小时内的特定点,无需付费。有关更多信息,请参阅 Amazon Redshift 定价
。
Amazon Redshift Serverless 保持账单可预测性的最佳实践
以下是最佳实践和内置设置,有助于您保持账单一致性。
-
确保结束每个事务。当您使用
BEGIN
开始交易时,务必也要使用END
结束交易。 -
使用最佳实践错误处理来从容地响应错误并结束每个事务。尽量减少未结交易有助于避免不必要地使用 RPU。
-
使用
SESSION TIMEOUT
帮助结束未结事务和空闲会话。它会导致任何保持闲置状态或非活动状态的时间已超过 3600 秒(1 小时)的会话超时。它会导致任何保持打开状态和非活动状态的时间已超过 21600 秒(6 小时)的事务超时。可以为特定用户显式更改此超时设置,例如您希望为长时间运行的查询保持会话打开时。主题 CREATE USER 显示了如何为用户调整SESSION TIMEOUT
。-
在大多数情况下,我们建议您不要延长
SESSION TIMEOUT
值,除非您的用例特别需要。如果会话保持空闲状态并且存在未结交易,则可能会导致在会话关闭之前使用 RPU 的情况。这将导致不必要的成本。 -
Amazon Redshift Serverless 运行查询的最长时间为 86,399 秒(24 小时)。在 Amazon Redshift Serverless 结束与事务关联的会话之前,未结事务的最长不活动时间是六小时。有关更多信息,请参阅 Amazon Redshift Serverless 对象的配额。
-
使用连接池的 Amazon Redshift Serverless 计费
Amazon Redshift Serverless 将所有传入的查询均视为可计费的用户活动,包括连接池发送的轻量级运行状况检查查询。无论查询源自应用程序、JDBC/ODBC 驱动程序还是连接池框架,此行为都适用。每个运行状况检查查询都会触发计算用量,无论查询目的或来源如何,都会产生费用。因此,即使没有实际的用户工作负载在运行,维护开放的连接池也会产生成本。
连接池在应用程序和 Amazon Redshift Serverless 端点之间维护一个持久连接池。为了确保这些连接保持运行状况正常和可用,池化机制通常会定期发送轻量级查询或空查询(例如 SELECT
1
)。这些自动查询用于验证连接状态。
使用连接池时,请考虑以下最佳实践,以最大限度地减少意外费用:
-
可以通过查看和优化连接池配置中的运行状况检查或保持连接查询的频率,来调整运行状况检查频率。
-
通过配置连接池来优化闲置系统设置,以最大限度地减少系统闲置期间不必要的连接流失或后台查询活动。
-
实施应用程序级池化或改进的连接生命周期管理(如果可以减少开销)。
-
禁用心跳或验证查询(如果连接池配置支持这样做)。检查特定的连接字符串参数或配置文件以调整这些设置。
-
微调 TCP 保持连接设置:如果无法禁用驱动程序的内部心跳机制,请在操作系统或应用程序级别调整传输控制协议(TCP)保持连接设置,以解决连接超时问题。有关详细信息,请参阅操作系统、JDBC/ODBC 驱动程序或连接池文档。
-
优化数据库连接池:配置连接池(HikariCP、Apache 数据库连接池)以管理连接并最大限度地减少连接开销。重点关注诸如最大连接数、空闲超时和验证查询等参数(如果需要)。这种优化有助于使 Amazon Redshift Serverless 计算用量与实际工作负载需求保持一致,从而可能降低成本。
使用零 ETL 的 Amazon Redshift Serverless 的成本优化
在 Amazon Redshift Serverless 上运行零 ETL 集成时,要想优化成本,您可以根据工作负载的需求,合理调整环境大小并调整刷新设置。请考虑进行以下调整:
-
在可用于工作负载时,使用 8 RPU 的较低基本 RPU 容量。
-
配置目标 Redshift 实例的 REFRESH_INTERVAL,在新鲜度与成本之间取得平衡。较短的时间间隔可确保近乎实时的更新,但会增加计算成本。对于不太需要即时新鲜度的工作负载(例如报告或历史分析),较长的间隔(5 分钟或更长)可减少费用。要编辑 Redshift 目标 REFRESH_INTERVAL,请参阅 ALTER DATABASE 描述中有关刷新间隔的子句。
-
在摄取零 ETL 数据时,通过并行运行分析工作负载,可尽量提高 Amazon Redshift Serverless 环境的利用率。这可确保将计算容量有效地用于多种业务目的。
-
为了尽可能减少空闲计算资源和优化总拥有成本,请检查您当前的零 ETL 集成,在数据新鲜度并不重要的场景中增加 REFRESH_INTERVAL,同时将 RPU 容量与工作负载需求保持一致。