在 Skyeng，我們使用 Amazon Redshift，包括並行擴展，因此我們發現 dotgo.com 創始人 Stefan Gromoll 為 intermix.io 撰寫的這篇文章很有趣。 翻譯完成後，資料工程師 Daniyar Belkhodzhaev 分享了我們的一些經驗。
允許透過向叢集新增節點來進行擴展。 處理峰值請求數量的需要可能會導致節點的過度配置。 並發擴展與添加新節點不同，它根據需要增加運算能力。
Amazon Redshift 並行擴展為 Redshift 叢集提供了額外的容量來處理峰值請求量。 它的工作原理是將請求轉移到後台新的「並行」叢集。 請求根據 WLM 配置和規則進行路由。
並行擴展定價基於具有免費套餐的信用模型。 在免費積分之上，付款是基於並行擴展叢集處理請求的時間。
作者在其中一個內部叢集上測試了並行擴展。 在這篇文章中，他將討論測試結果並提供有關如何開始的提示。
集群要求
若要使用並行擴展，您的 Amazon Redshift 叢集必須滿足以下要求：
- 平台： EC2-VPC；
— 節點類型： dc2.8xlarge、ds2.8xlarge、dc2.large 或 ds2.xlarge；
— 節點數量： 從 2 到 32（不支援單節點叢集）。
可接受的請求類型
並行縮放並不適合所有類型的查詢。 在第一個版本中，它只處理滿足三個條件的讀取請求：
— SELECT 查詢是唯讀的（儘管計劃了更多類型）；
— 查詢未引用具有 INTERLEAVED 排序風格的表；
- 此查詢不使用 Amazon Redshift Spectrum 引用外部表。
要路由到並行擴展集群，請求必須排隊。 此外，符合佇列條件的查詢 ，不會在並行規模叢集上運行。
佇列和 SQA 需要正確的配置 。 我們建議先優化您的 WLM - 這將減少並行擴展的需要。 這很重要，因為並行擴充僅在一定時間內免費。 AWS 聲稱並行擴展將對 97% 的客戶免費，這給我們帶來了定價問題。
並行擴充的成本
AWS 提供了用於平行擴展的信用模型。 每個活動集群 每小時累積積分，每天最多可享有一小時的免費並行擴展積分。
只有當您的並行擴展集群使用量超過您收到的積分金額時，您才需要付費。
成本是按高於免費速率使用的平行叢集的每秒按需速率計算的。 您只需在請求期間付費，每次啟動並行擴展叢集時至少收取一分鐘費用。 每秒點播費率是根據一般定價原則計算的 ，也就是說，它取決於叢集中的節點類型和節點數量。
啟動並行擴展
每個 WLM 佇列都會觸發並行擴展。 前往 AWS Redshift 控制台並從左側導覽功能表中選擇工作負載管理。 從下列下拉式選單中選擇叢集的 WLM 參數組。
您將在每個佇列旁邊看到一個名為「並發擴充模式」的新欄位。 預設為“禁用”。 點擊“編輯”，您可以更改每個隊列的設定。
組態
並行擴展的工作原理是將適當的請求轉送到新的專用叢集。 新叢集與主集群具有相同的大小（類型和節點數量）。
用於平行擴展的預設集群數量為一 (1)，最多可配置十 (10) 個集群。
並行擴展的群集總數可以透過 max_concurrency_scaling_clusters 參數設定。 增加此參數的值會提供額外的冗餘叢集。
監控
AWS Redshift 控制台中也提供了幾個附加圖表。 最大配置並發擴展群集圖表顯示 max_concurrency_scaling_clusters 隨著時間的變化的值。
活動擴展集群的數量顯示在使用者介面的「並發擴展活動」部分：
在「查詢」標籤中，有一列指示查詢是在主集群中還是在平行擴展集群中執行：
無論特定查詢是在主集群中還是透過並行擴展集群執行，它都會儲存在 stl_query.concurrency_scaling_status 中。
值為1表示查詢在平行規模叢集中執行，其他值表示在主叢集中執行。
示例：
並發擴充資訊也儲存在其他一些表格和檢視中，例如 SVCS_CONCURRENCY_SCALING_USAGE。 此外，還有許多目錄表儲存有關並行擴充的資訊。
Результаты
作者於 18 年 30 月 00 日 GMT 大約 29.03.2019:3:20 開始對內部集群中的一個隊列進行並行擴展。於 30 年 00 月 29.03.2019 日大約 XNUMX:XNUMX:XNUMX 將 max_concurrency_scaling_clusters 參數更改為 XNUMX。
為了模擬請求隊列，我們將該隊列的槽數從 15 個減少到 5 個。
下面是 intermix.io 儀表板圖表，顯示減少槽數後運行和排隊的請求數。
我們看到隊列中請求的等待時間增加，最長時間超過了5分鐘。
以下是來自AWS控制台的有關這段時間發生的事情的相關資訊：
Redshift 根據配置啟動了三 (3) 個平行擴充叢集。 儘管我們叢集中的許多請求已排隊，但這些叢集似乎未充分利用。
使用情況圖與擴展活動圖相關：
幾個小時後，作者檢查了隊列，看起來有 6 個請求正在並行運行。 我們也透過使用者介面隨機測試了兩個請求。 我們還沒有檢查當多個並行集群同時處於活動狀態時如何使用這些值。
發現
並行擴展可以減少尖峰負載期間請求在佇列中花費的時間。
根據基本測試的結果，載入請求的情況得到了部分改善。 然而，僅並行擴充並不能解決所有並發問題。
這是由於可以使用並行擴充的查詢類型受到限制。 例如，作者有很多交錯排序鍵的表，而我們大部分的工作量都在寫作上。
儘管並行擴充不是設定 WLM 的通用解決方案，但使用此功能非常簡單明了。
因此，作者建議將它用於 WLM 隊列。 從一個並行叢集開始，透過控制台監控尖峰負載，以確定新叢集是否得到充分利用。
隨著 AWS 增加對其他查詢類型和表的支持，並行擴展應該會逐漸變得越來越有效率。
Skyeng 資料工程師 Daniyar Belkhodzhaev 的評論
Skyeng 也立即註意到了並行擴展的可能性。
該功能非常有吸引力，特別是考慮到 AWS 估計大多數用戶甚至不需要為此支付額外費用。碰巧的是，在 24 月中旬，我們收到了一系列針對 Redshift 叢集的不同尋常的請求。 在此期間，我們經常使用並發擴展（Concurrency Scaling）；有時會增加一個集群，一天 XNUMX 小時不間斷地工作。
這使得即使不能完全解決隊列問題，至少也可以使情況可以接受。
我們的觀察結果與 intermix.io 人員的印象基本一致。
我們也注意到，雖然有請求在佇列中等待，但並非所有請求都會立即轉送到並行叢集。 顯然發生這種情況是因為並行叢集仍然需要時間來啟動。 因此，在短期峰值負載期間，我們仍然有較小的隊列，並且相應的警報有時間觸發。
在擺脫了四月份的異常負載後，我們正如AWS所期望的那樣，進入了偶爾使用模式——在免費規範範圍內。
您可以在 AWS Cost Explorer 中追蹤並行擴充成本。 您需要選擇服務 - Redshift，使用類型 - CS，例如 USW2-CS:dc2.large。您可以閱讀有關俄語價格的更多信息
來源： www.habr.com