Amazon Redshift Serverless 的運算容量 - Amazon Redshift

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

Amazon Redshift Serverless 的運算容量

使用 Amazon Redshift Serverless,您可以自動擴展和縮減運算容量,以符合工作負載需求。運算容量是指分配給 Amazon Redshift Serverless 工作負載的處理能力和記憶體。常見的使用案例包括處理尖峰流量期間、執行複雜的分析,或有效率地處理大量資料。下列術語提供有關設定和管理運算容量的詳細資訊。

RPU

Amazon Redshift Serverless 會以 Redshift 處理單元 (RPU) 為單位來測量資料倉儲的容量。RPU 是用來處理工作負載的資源。

基本容量

此設定會指定 Amazon Redshift 用來為查詢提供服務的基本資料倉儲容量。基本容量會以 RPU 為單位來指定。您能以 Redshift 處理單元 (RPU) 為單位來設定基本容量。一個 RPU 可提供 16 GB 的記憶體。設定較高的基本容量可改善查詢效能,對於會取用大量資源的資料處理任務來說更是如此。Amazon Redshift Serverless 的預設基本容量為 128 個 RPU。您可以使用 AWS 主控台、UpdateWorkgroupAPI 操作或 中的update-workgroup操作,將基本容量設定從 8 個 RPUs 調整為 512 個 RPUs,單位為 8 個 (8,16,24...512) AWS CLI。

使用最小容量 8 個 RPU 時,您現在可以根據效能要求,更彈性地執行更複雜的工作負載。8 個、16 個和 24 個 RPU 的基本 RPU 容量的適用目標是需要少於 128 TB 資料的工作負載。如果您的資料要求大於 128 TB,則必須使用至少 32 個 RPU。如果工作負載的資料表有大量資料行且並行數量較高,建議您使用 32 個以上的 RPU。

可用的基本 RPUs 上限 512 會將最高層級的運算資源新增至您的工作負載。這可提供更大的彈性,以支援高度複雜性的工作負載,並加速載入和查詢資料。

注意

擴充的 1024 基本 RPU 容量上限可在下列使用 AWS 區域:

  • 美國東部 (維吉尼亞北部)

  • 美國東部 (俄亥俄)

  • 美國西部 (奧勒岡)

  • 歐洲 (愛爾蘭)

  • 歐洲 (法蘭克福)

在 512-1024 之間設定基本容量時,可以 32 為單位遞增或遞減 RPUs。

如果您管理更大且更複雜的工作負載,請考慮增加 Redshift Serverless 資料倉儲的大小。較大的倉儲可以存取更多運算資源,讓他們更有效率地處理查詢。請注意,增加工作群組的最大基本 RPU 容量需要額外的可用 IP 地址。如需增加可用 IP 地址需求的詳細資訊,請前往 使用 Amazon Redshift Serverless 時的考量

以下是具有較高基礎容量的一些執行個體很有幫助:

  • 您有複雜的查詢需要很長時間才能執行

  • 您的資料表有大量資料欄。

  • 您的查詢具有大量 JOINs。

  • 您的查詢會從外部來源彙總或掃描大量資料,例如資料湖。

如需 Amazon Redshift Serverless 配額和限制的詳細資訊,請前往 Amazon Redshift Serverless 物件的配額

Amazon Redshift Serverless 容量的考量和限制

以下是 Amazon Redshift Serverless 容量的考量和限制。

  • 8 個或 16 個 RPU 的組態最多可支援 128 TB 的 Redshift 受管儲存容量。如果您要使用超過 128 TB 的受管儲存,則無法降級為少於 32 個 RPU。

  • 編輯工作群組的基本容量,如此可能會取消工作群組上執行的某些查詢。

  • 除非佇列中有查詢,否則 Amazon Redshift Serverless 不會擴展您的 RPUs。Amazon Redshift Serverless 不會擴展您的 RPUs,以回應單一查詢增加的負載。因此,如果目前沒有容量來處理,單一的資源密集型查詢可能會導致您的工作群組耗盡記憶體。確保您的基本容量足以處理您在資料倉儲上執行的任何單一查詢。

AI 驅動的擴展和最佳化

AI 驅動的擴展和最佳化功能可在 Amazon Redshift Serverless 可用的所有 AWS 區域中使用。

Amazon Redshift Serverless 提供進階 AI 驅動的擴展和最佳化功能,以滿足各種工作負載需求。資料倉儲可能有下列佈建問題:

  • 資料倉儲可能會過度佈建,以改善資源密集型查詢的效能

  • 資料倉儲的佈建可能不足,以節省成本。

在資料倉儲工作負載的效能和成本之間取得適當的平衡是很困難的,特別是在臨機操作查詢和不斷增加的資料量方面。執行混合工作負載時,包含低和高資源密集型查詢,需要智慧擴展。AI 驅動的擴展和最佳化功能會自動擴展無伺服器運算或 RPUs,以回應資料增長。此功能也有助於將查詢效能維持在目標性價格效能目標內。AI 驅動的擴展和最佳化會在資料量增加時動態配置運算資源,確保查詢持續符合效能目標。AI 驅動的擴展和最佳化可讓服務無縫適應不斷變化的工作負載需求,而不需要手動介入或複雜的容量規劃。

Amazon Redshift Serverless 根據查詢複雜性和資料量等因素,提供更全面且回應靈敏的擴展解決方案。此功能允許最佳化工作負載價格效能,同時保有彈性,以有效率地處理不同的工作負載和不斷增長的資料集。Amazon Redshift Serverless 可以自動對 Amazon Redshift Serverless 端點進行 AI 驅動的最佳化,以滿足您為無伺服器工作群組指定的價格效能目標。如果您不知道要為工作負載設定哪些基本容量,或是工作負載的某些部分可能會受益於更多配置的資源,則此自動定價效能優化特別有用。

範例

如果您的組織通常執行的工作負載只需要 32 個 RPU,但突然引入更複雜的查詢,您可能不知道適當的基礎容量。設定較高的基本容量可產生更好的效能,但也會產生更高的成本,因此成本可能不符合您的預期。Amazon Redshift Serverless 使用 AI 驅動的擴展和資源最佳化功能,可自動調整 RPU 以符合您的價格效能目標,同時為您的組織最佳化成本把關。無論工作負載大小是多少,此自動最佳化都很有效用。如果您有任何數量的複雜查詢,自動最佳化可協助您達成組織的價格績效目標。

注意

價格效能目標是特定於工作群組的設定。不同的工作群組可以有不同的價格績效目標。

為了保持成本的可預測性,請設定允許 Amazon Redshift Serverless 配置給工作負載的最大容量限制。

若要設定價格效能目標,請使用 AWS 主控台。建立無伺服器工作群組時,您必須明確啟用您的價格效能目標。您也可以在建立 Serverless 工作群組之後修改價格效能目標。當您啟用價格效能目標時,預設會設為平衡

編輯工作群組的價格效能目標
  1. 在 Amazon Redshift Serverless 主控台中,選擇工作群組組態

  2. 選擇您要為其編輯價格效能目標的工作群組。選擇效能索引標籤,然後選擇編輯

  3. 選擇價格效能目標,並將滑桿調整為所需的設定。

  4. 選擇 Save changes (儲存變更)。

  5. 若要更新 Amazon Redshift Serverless 可配置給工作負載的 RPUs 數量上限,請選擇工作群組組態區段的限制索引標籤。

您可以使用 Price-performance 目標滑桿來設定所需的成本和效能平衡。透過移動滑桿,您可以選擇下列其中一個選項:

  • 成本最佳化 — 此設定會優先考慮成本節省。Amazon Redshift Serverless 嘗試自動擴展運算容量,這樣做不會產生額外費用。Amazon Redshift Serverless 也會嘗試縮減運算資源以降低成本,可能增加查詢執行時間。

  • 平衡 — 此設定會在效能和成本之間建立平衡。Amazon Redshift Serverless 會擴展效能,並可能導致中等的成本增加或減少。這是大多數 Amazon Redshift Serverless 資料倉儲的建議設定。

  • 效能最佳化:此設定會優先考慮效能。Amazon Redshift 會積極擴展以達成高效能,並可能產生更高的成本。

  • 中繼位置:您也可以將滑桿設定為平衡最佳化之間的兩個中繼位置之一,最佳化效能。如果成本或效能的完整最佳化過於極端,請使用這些設定。

選擇價格效能目標時的考量事項

您可以使用價格效能滑桿,為您的工作負載選擇所需的價格效能目標。AI 驅動的擴展和最佳化演算法會隨著時間從工作負載歷史記錄中學習,並改善預測和決策準確性。

範例

在此範例中,假設查詢需要 7 分鐘,且費用為 7 美元。下圖顯示查詢執行期和成本,無需擴展。

Amazon Redshift Serverless Autoscaling 的範例查詢圖表。

指定的查詢可能會以幾種不同的方式擴展,如下所示。根據您選擇的價格效能目標,AI 驅動的擴展會預測查詢如何抵消效能和成本,並相應地進行擴展。選擇不同的滑桿選項會產生下列結果:

Amazon Redshift Serverless Autoscaling 的範例查詢圖表。
  • 成本最佳化 - 使用成本最佳化選項,您的資料倉儲會擴展有利的選項,以降低成本。在上述範例中,超線性擴展方法示範了此行為。只有在可根據擴展模型預測以經濟實惠的方式完成擴展時,才會發生擴展。如果擴展模型預測無法針對指定的工作負載進行成本最佳化擴展,則資料倉儲將無法擴展。

  • 平衡 — 使用平衡選項,系統在平衡成本和效能考量的同時擴展,並可能降低成本的有限。Balanced 選項會執行超線性、線性和可能的子線性工作負載擴展。

  • 效能最佳化:使用效能最佳化選項,除了先前改善效能的方法之外,系統也會擴展規模,即使成本較高,而且可能不會與執行時間改善成正比。透過效能最佳化,系統會盡可能執行超線性擴展、線性擴展和子線性擴展。滑桿位置越接近效能最佳化位置,Amazon Redshift Serverless 就越允許子線性擴展。

設定 Price-Performance 滑桿時,請注意下列事項:

  • 您可以隨時變更價格效能設定,但工作負載擴展不會立即變更。隨著系統了解目前的工作負載,擴展會隨著時間而變更。我們建議監控無伺服器工作群組 1-3 天,以驗證新設定的影響。

  • 價格效能滑桿選項最大容量最大 RPU 小時可一起運作。最大容量最大 RPU 小時是限制 Amazon Redshift Serverless 允許資料倉儲擴展的最大 RPUs,以及 Amazon Redshift Serverless 允許資料倉儲使用的最大 RPU 小時的控制項。無論價格效能目標設定為何,Amazon Redshift Serverless 一律遵守和強制執行這些設定。

監控資源自動擴展

您可以透過下列方式監控 AI 驅動的 RPU 擴展:

  • 在 Amazon Redshift 主控台上檢閱使用的 RPU 容量圖表。

  • 在 CloudWatch ComputeCapacity Workgroup中監控 AWS/Redshift-Serverless 和 下的指標。

  • 查詢 SYS_QUERY_HISTORY 檢視。提供特定查詢 ID 或查詢文字以識別期間。使用此時段查詢 SYS_SERVERLESS_USAGE 系統檢視以尋找 compute_capacity值。compute_capacity 欄位顯示查詢執行期間擴展的 RPUs。

使用下列範例來查詢SYS_QUERY_HISTORY檢視。將範例值取代為您的查詢文字。

select query_id,query_text,start_time,end_time, elapsed_time/1000000.0 duration_in_seconds from sys_query_history where query_text like '<query_text>' and query_text not like '%sys_query_history%' order by start_time desc

執行下列查詢,查看 期間如何從 compute_capacity擴展start_timeend_time。將下列查詢end_time中的 start_time和 取代為上述查詢的輸出:

select * from sys_serverless_usage where end_time >= 'start_time' and end_time <= DATEADD(minute,1,'end_time') order by end_time asc

如需使用這些功能的step-by-step說明,請參閱在 Amazon Redshift Serverless 中設定監控、限制和警示,以保持成本可預測。

使用 AI 驅動擴展和最佳化時的考量事項

使用 AI 驅動的擴展和最佳化時,請考慮下列事項:

  • 對於需要 32 到 512 Base RPU 的 Amazon Redshift Serverless 現有工作負載,建議使用 Amazon Redshift Serverless AI 驅動的擴展和最佳化,以獲得最佳結果。我們不建議在少於 32 個基本 RPU 或超過 512 個基本 RPU 工作負載使用此功能。

  • 價格效能目標會自動最佳化工作負載,但結果可能有所不同。我們建議您長期使用此功能,以便系統可以透過執行代表性工作負載來了解您的特定模式。

  • AI 驅動的擴展和最佳化會使用最佳時間,根據在 Amazon Redshift Serverless 執行個體上執行的工作負載,將最佳化套用至 Serverless 工作群組。

若要深入了解 AI 驅動最佳化和資源擴展,請觀看以下影片。