前言
Amazon Redshift 是一款完全託管的 PB 級大規模並行資料倉儲，它操作簡單並且效能高效。它使用標準 SQL 和現有的商業智慧 (BI) 工具來快速、簡單且經濟高效地分析所有資料。如今，Amazon Redshift 已成為使用最廣泛的雲資料倉儲之一。客戶使用 Amazon Redshift 來處理多種型別的大資料工作負載，例如加速現有資料庫環境或用於大資料分析的日誌攝取。
近年來，隨著網際網路產生資料量的顯著增長，一些客戶開始詢問他們應該如何更高效地使用 Amazon Redshift 。為幫助客戶更高效、低成本地使用Amazon Redshift，自其推出以來，亞馬遜雲科技一直對其不斷完善，併發布了大量新特性和功能。例如 Amazon Redshift Spectrum、基於 SSD 的 RA3 節點型別、暫停和恢復叢集、Amazon Redshift 資料共享和 AQUA（高階查詢加速器）等。每項改進和/或新功能都可以提高 Amazon Redshift 的效能和/或降低成本。深入地瞭解以上功能可以幫助您更高效地使用Amazon Redshift。
在本篇部落格中，我們將通過一個案例探討如何使用 Amazon Redshift RA3 節點https://docs.aws.amazon.com/r...、資料共享（data sharing） https://docs.aws.amazon.com/r... 以及暫停和恢復（pause/resume）叢集 https://docs.aws.amazon.com/r... 在本案例的業務場景下來大幅提升Amazon Redshift 叢集的價效比。
首先，讓我們快速回顧一下一些關鍵功能。
Amazon Redshift 的 RA3 節點簡介
適用於 Amazon Redshift 的 Amazon Redshift RA3 節點由新的託管儲存模型提供支援，該模型可以分別優化計算能力和儲存功能。它們利用一些架構改進，包括高頻寬網路、使用由 S3 支援的基於 S3 的本地 SSD 儲存的託管儲存，以及多種高階資料管理技術來優化進出 S3 的資料移動。它們帶來了一些非常重要的功能，其中之一就是資料共享。RA3 節點還具有暫停和恢復的功能，這使客戶可以在不使用叢集時輕鬆暫停叢集以暫停計費。
資料共享（data sharing）簡介
Amazon Redshift 資料共享功能於 2021 年正式推出，它使您可以安全、輕鬆地在 Amazon Redshift 叢集之間共享實時資料以進行讀取。資料共享支援在亞馬遜雲科技 賬戶內跨 Amazon Redshift 叢集進行即時、精細和高效能的資料訪問，而不會產生與資料副本和資料移動相關的複雜性和延遲。資料可以在多個級別共享，包括架構、表、檢視和使用者定義的函式，從而提供精細的訪問控制，可以針對需要訪問資料的不同使用者和企業量身定製。
Example Crop. 的 Amazon Redshift 優化專案
客戶Example crop. 大量使用 Amazon Redshift 作為其大資料分析業務的資料倉儲，他們一直很享受 Amazon Redshift 為其業務帶來的可能性。客戶主要使用Amazon Redshift來儲存和處理用於商業智慧目的的使用者行為資料，最近幾個月資料每天增加約幾百GB，各部門的人員在辦公時間會不停地通過其商業智慧 (BI) 平臺在Amazon Redshift叢集上查詢各種資料。
因為有些資料會被所有工作負載使用，所以Example Crop. 將最主要的4種分析負載在單個 Amazon Redshift 叢集上執行。這4種分析工作負載分別是：
- 來自其商業智慧平臺（BI platform）的查詢：主要在辦公時間被執行的各種查詢。
- 每小時資料ETL ：在每小時的前幾分鐘執行。執行通常需要大約40分鐘。
- 每日資料 ETL ：它每天執行兩次。本負載執行是在辦公時間進行的，原因是運營團隊需要在每天下班之前獲得每日報告。每次執行通常需要5到3個小時。它是資源消耗量第二大的工作負載。
- 每週資料ETL：它在每週日的凌晨執行。這是最耗資源的工作負載。執行時間通常需要3到4個小時。
由於業務和資料量的不斷增長，Example Crop. 的資料分析團隊已經將原有的Amazon Redshift叢集遷移到基於RA3 系列節點的新Amazon Redshift叢集上。因為全部分析工作負載都在一個叢集上執行並且資料量增長很快，為了保證其商業智慧平臺的查詢平均執行時間，Example Crop. 逐步將 Amazon Redshift 叢集的節點數量增加到 12 個。
但是，他們注意到，除了 ETL 任務執行期間會產生一些峰值外，平均 CPU 利用率通常低於 50%，因此資料分析團隊希望和亞馬遜雲科技的技術團隊合作探索在不損失查詢效能的前提下，優化其 Amazon Redshift 叢集效能和成本的解決方案。
由於 CPU 使用率峰值通常出現在執行各類ETL任務期間，因此我們首先想到的方案是將工作負載和相關資料拆分到規模不同的多個 Amazon Redshift 叢集中。通過減少節點總數，我們希望能夠降低客戶的成本。
經過一系列探討我們發現，將不同分析負載拆分到多個Amazon Redshift 叢集的一大障礙是，由於業務需要，多個分析負載經常需要讀取和/或更新資料倉儲中的同一組資料表。在保證高效能的前提下，保證拆分後各個Amazon Redshift叢集的資料一致性是一個挑戰。比如，有些表中的資料需要由ETL 工作負載讀取，並由 BI 工作負載更新，而有些表則相反。因此，如果我們將資料複製到2個Amazon Redshift叢集中，並且僅建立從BI叢集到報告叢集的資料共享，則客戶需要額外設計資料同步流程，在所有Amazon Redshift叢集之間保持資料一致性——由於需要考慮的因素比較多，這可能會變的很複雜。
在進一步深入瞭解客戶工作負載之後，我們發現可以將資料表分為 4 種型別，順著這個思路我們提出了兩叢集雙向資料共享（two-way data sharing）方案。該解決方案的目的是將資源消耗大的ETL工作負載遷移到一個單獨的 Amazon Redshift 叢集——以便我們利用 Amazon Redshift 的暫停和恢復（pause/resume）叢集功能，只在這些ETL負載執行時使用該叢集，從而降低 Amazon Redshift 的執行成本，並且通過雙向資料共享保證2個Amazon Redshift叢集之間的資料一致性，而無需額外構建資料同步流程。
將舊架構單叢集（左），改進為新的兩叢集方案（右）
分解工作負載和資料
由於四種主要工作負載的特點，我們將工作負載分為兩類，即持續執行（long-running）的工作負載和定期執行（periodic-running）的工作負載。
持續執行的工作負載適用於 BI 平臺和每小時 ETL。因為每小時的 ETL 工作負載平均需要大約 40 分鐘才能完成，這意味著即使我們將其遷移到獨立的 Amazon Redshift 叢集並每小時暫停/恢復一次，收益也比較小，因此我們目前將它與BI平臺負載劃分在一起。
定期執行的工作負載為每日 ETL 和每週 ETL。
規劃資料共享
下一步是確定每個類別的所有資料（表）的訪問模式。
對此，我們確定了4種型別的資料表：
- 型別1資料表：只能由持續執行的工作負載讀取和更新。
- 型別2資料表：由持續執行的工作負載讀取和更新，且由定期執行的工作負載讀取，但不更新。
- 型別3資料表：由定期執行的工作負載讀取和更新，且由持續執行的工作負載讀取，但不更新。
- 型別4資料表：只能由定期執行的工作負載讀取和更新。
將所有資料表根據上述4種型別分類後發現，所有資料表都符合4種型別中的一種。因此，我們可以繼續將單個 Amazon Redshift 叢集分為 2 個群集。一個叢集具有 12 個 RA3 節點，命名為 long-running-cluster，用於持續執行的工作負載；另一個叢集具有 20 個 RA3 節點，命名為 periodic-running-cluster，用於週期執行的工作負載。
我們將在 long-running 叢集和 periodic-running 叢集之間建立雙向資料共享。對於上面列出的型別2資料表，我們將在 long-running 叢集（作為生產者/producer）上建立資料共享 L-to-P，並將 periodic-running 叢集設定為使用者（consumer）。對於上面的型別3資料表，我們將在 periodic-running 叢集（作為生產者’/producer’）上建立資料共享 P-to-L，並把 long-running 叢集設定為使用者（consumer’）。
雙向資料共享（Two-way data sharing）架構圖：
long-running 叢集（producer）與 periodic-running 叢集（consumer）共享型別 2 資料表。periodic-running叢集（producer’）與 long-running 叢集（consumer’）共享型別3資料表
跨Amazon Redshift 叢集構建雙向資料共享
首先，讓我們對最初的單個Amazon Redshift 叢集進行快照（snapshot），稍後該叢集將被改造成 long-running-cluster 叢集。
現在，讓我們建立一個具有 20 個 RA3 節點的新 Amazon Redshift 叢集，名字為 periodic-running-cluster，用於週期執行的工作負載，請確認選擇 RA3 型別例項。建立完成後，我們將型別 3 和型別 4 表遷移到該叢集。
1、從 long-running-cluster 叢集共享資料到 periodic-running-cluster 叢集
下一步是建立資料共享 L-to-P。我們可以使用 Amazon Redshift Query Editor V2 https://aws.amazon.com/blogs/... 進行操作。
在 periodic-running-cluster 叢集上，我們執行以下命令得到其 namespace，記為 [periodic-running-cluster]，並記錄下 namespace 的值：
SELECT current_namespace;
左滑檢視更多
然後，在 long-running-cluster 叢集上，我們執行下列queries：
CREATE DATASHARE ltop_share SET PUBLICACCESSIBLE TRUE;
ALTER DATASHARE ltop_share ADD SCHEMA public_long;
ALTER DATASHARE ltop_share ADD ALL TABLES IN SCHEMA public_long;
GRANT USAGE ON DATASHARE ltop_share TO NAMESPACE '[periodic-running-cluster]';左滑檢視更多
注意，請將最後一條 query 中的 [periodic-running-cluster] 替換為前一步記錄的 namespace 值。
然後，我們可以用下列命令驗證資料共享 L-to-P：
SHOW datashares;
左滑檢視更多
驗證資料共享 L-to-P 後，我們通過下列 query 得到 long-running-cluster 的 namespace [long-running-cluster-namespace]，並記錄下 namespace 的值:
SELECT current-namespace;
左滑檢視更多
然後，讓我們回到 periodic-running-cluster 叢集。在 periodic-running-cluster 叢集上，我們執行下列命令載入資料：
CREATE DATABASE ltop FROM DATASHARE ltop_share OF NAMESPACE '[long-running-cluster-namespace]';左滑檢視更多
注意，請將 query 中的 [long-running-cluster] 替換為前一步記錄下的 namespace 值。
然後我們驗證我們能否通過資料共享 L-to-P 讀取工作表資料。
2、從 periodic-running-cluster 叢集共享資料到 long-running-cluster 叢集
建立資料共享 P-to-L
我們在前面的步驟中已經記錄了 long-running-cluster 叢集和 periodic-running-cluster 叢集的 namespaces，後面的步驟中我們將直接使用他們。
在 periodic-running-cluster 上，我們執行下列queries來建立資料共享P-to-L：
CREATE DATASHARE ptol_share SET PUBLICACCESSIBLE TRUE;
ALTER DATASHARE ptol_share ADD SCHEMA public_periodic;
ALTER DATASHARE ptol_share ADD ALL TABLES IN SCHEMA public_periodic;
GRANT USAGE ON DATASHARE ptol_share TO NAMESPACE '[long-running-cluster-namespace]';左滑檢視更多
之後，我們用下面 query 來驗證資料共享 P-to-L 是否建立成功：
SHOW datashares;
左滑檢視更多
在我們驗證了資料共享P-to-L建立成功之後，回到 long-running-cluster 叢集。
在 long-running-cluster 叢集上，我們執行下列命令將資料共享中的資料載入到 long-running-cluster 叢集上：
CREATE DATABASE ptol FROM DATASHARE ptol_share OF NAMESPACE '[periodic-running-cluster-namespace]';左滑檢視更多
然後我們驗證在 long-running-cluster 叢集上是否能通過資料共享 P-to-L 讀取工作表資料。
驗證成功後，雙向資料共享（two-way data sharing）的建立就完成了。
下一步是更新不同工作負載的程式碼，以正確地使用兩個 Amazon Redshift 叢集的endpoints，並進行業務測試。
至此，我們已經將工作負載劃分到兩個 Amazon Redshift 叢集，並在兩個叢集之間成功建立了雙向資料共享。
暫停/恢復periodic-running Amazon Redshift 叢集
現在，我們來更新一下執行每日 ETL 和每週 ETL 工作負載的定時指令碼（可能是 crontab ）。將有兩處更新。
指令碼啟動時，通過叢集ID，呼叫 Amazon Redshift 檢查並恢復叢集 API，以便在恢復（resume）處於暫停狀態的 Amazon Redshift 叢集 periodic-running-cluster。
aws resume-cluster --cluster-identifier [periodic-running-cluster-id]在ETL工作負載完成後，使用叢集 ID 呼叫 Amazon Redshift 暫停叢集 API 以暫停 periodic-running-cluster 叢集。
aws pause-cluster --cluster-identifier [periodic-running-cluster-id]結果
在將工作負載遷移到新架構之後，Example Crop. 資料分析團隊進行了為期一個月左右的測試。
根據測試，所有工作負載的效能都有提高。詳情如下：
- 在 ETL 工作負載執行期間，BI 工作負載的平均效能提高了約 100%。
- 每小時 ETL 工作負載的執行時長縮短了約 50%。
- 每日ETL工作負載持續時間從最長3小時縮短至平均40分鐘。
- 每週ETL工作負載持續時間從最長4小時縮短至平均5小時。
優化期間業務新增資料約10%，但總成本只上升了約13％，並且所有業務都執行正常。
結論和侷限性
根據該專案的情況，在將工作負載分成不同的Amazon Redshift叢集之後，我們有以下發現。
- 首先，BI工作負載的平均效能提高了100％，因為其不再與每日ETL和每週ETL工作負載競爭資源。
- 其次，定期執行的 Amazon Redshift 群集上的 ETL 工作負載的持續時間顯著縮短，因為沒有來自 BI 和每小時 ETL 工作負載的資源競爭，並且該叢集擁有了更多節點（20個）。
- 第三，通過利用 Amazon Redshift RA3 系列的叢集暫停/恢復（pause/resume）功能，在業務資料量新增約10%的情況下，Amazon Redshift 叢集的總體成本僅增加了約 13%。
由此得到的結論是，在該專案中 Amazon Redshift 叢集的價效比至少提高了 70%。
但是，該解決方案存在一些侷限性。
- 首先，要使用 Amazon Redshift 暫停/恢復功能，必須將呼叫 Amazon Redshift 暫停/恢復 API 的程式碼新增到所有在periodic-running-cluster叢集上執行 ETL 工作負載的相關指令碼中或在叢集中配置定時暫停和恢復。
- 其次，Amazon Redshift 叢集需要幾分鐘才能完成暫停/恢復，儘管暫停和恢復過程中不會向客戶計費。
- 第三，Amazon Redshift 叢集的大小無法根據工作負載自動縮減/擴充套件，還需要人工定期調整。
下一步計劃
為了保證系統的穩定執行，本專案中未縮減 long-running-cluster 叢集的節點數量。考慮到該叢集平均 CPU Utilization 並不高，在經過測試後，我們可以嘗試在保證 BI 工作負載和每小時 ETL 工作負載效能的前提下，對該叢集進行 Elastic Resize 操作，將節點數減少，以達到進一步降低成本的目的。
儘管本文中的解決方案在客戶的分析工作負載上實現了顯著的價效比提升，但我認為我們可以進一步簡化 Amazon Redshift 操作，並提高工作負載持續時間的粒度。
Amazon Redshift Serverless 已在 re:Invent 2021 中宣佈開始preview。Amazon Redshift Serverless 可自動預置和智慧地擴充套件資料倉儲容量，為您的所有分析提供一流的效能。您只需按秒為工作負載持續時間內使用的計算資源付費。您可以直接從中受益，而無需對現有的分析和商業智慧應用程式進行任何更改。
因此，Amazon Redshift Serverless 是我們下一步可以嘗試的一項服務。
本篇作者
馬競斌
亞馬遜雲科技解決方案架構師
致力於幫助客戶構建具有優良架構的產品和應用，以及幫助國內客戶出海和海外使用者進入中國。在網際網路行業有超過 14 年的產品研發經驗，在海外工作多年，是 Serverless 和 Infrastructure as Code 的愛好者。
