首頁 AWS

AWS - Redshift

簡單比較 Dataware House VS RDB/NoSQL

Relational or NoSQL Database Data Warehouse
Main usage Recording descriptive transactional data Analyzing data over time
Scope Data used by one or more application Whole company’s data
Data Real-time, detailed, row-based records Historical data that is often aggregated
Process method OLTP OLAP
Availability 24/7 or minimum down time Scheduled down time
Optimization goals Create, read, update, and delete single small-sized transactions. Conduct complex analysis queries over large datasets.
Data organization Data is normalized (no data duplication), which results in complex dependent table structures and join queries. Data is denormalized (allowing duplication) to optimize for query response times.
Number of users Thousands to millions Limited

使用 Dataware 做分析的原因

  • 描述性分析 Descriptive analysis - 什麼事件將發生
  • 診斷分析 Diagnostic analysis - 為什麼事件會發生
  • 預測分析 Predictive analysis - 哪些事件有可能發生？
  • 規範分析 Prescriptive analysis - 應該採取什麼措施來防止有害事件的發生？

簡介 AWS Reddshift

實務上要自架一個 Dataware 有非常多的挑戰，特別是能夠 Scale，Redshift 能承受 PB 等級規模的資料

Redshift 特點

  • Amazon Redshift 能夠在處理資料的同時保持大規模一致的效能。
  • Amazon Redshift 透過儲存或存取公司所有相關資料進行分析，消除了資料孤島。
  • Amazon Redshift 降低了整體擁有成本 (TCO)，因為所需的維護和管理工作更少。與大多數傳統資料倉儲解決方案相比，使用 Amazon Redshift 的公司可節省高達 90% 的成本。
  • Amazon Redshift 和 Amazon Redshift Serverless 擁有靈活的基礎設施，使客戶能夠更好地控制基礎設施成本。
  • Amazon Redshift 與其他可用於資料處理的雲端服務整合。
  • Amazon Redshift 具有內建的安全性和合規性功能。

Redshift 架構

當資料達到 PB 或 EB 級時，Redshift 能夠在效能幾乎不下降的情況下進行擴展。 Amazon Redshift 及其與其他 AWS 服務和第三方分析應用程式的整合。

image

Redshift Cluster

Redshift 是個符合 ANSI SQL 的 Dataware house 由 AWS Fully Managed，使用者不用擔心 Dataware 管理任務。如果使用者要對 Dataware house 進行精細控制，他們可以 Provision Redshift Cluster。Redshift Provision Cluster 部署在 Redshift 帳戶和 VPC 中，或是使用者的 VPC 中，這兩種配置都允許 AWS 管理、設定、操作和擴展 Redshift Cluster。使用者仍然需要提供詳細的配置參數。比如 Cluster Node 數量與類型、加密與維護時間。使用者透過在不使用 Cluster 時暫停 Cluster 來控制成本

Redshift Serverless

在一些情境使用者更適合選擇 Redshift Serverless 更有效率更便宜

  • 必須快速啟動的環境，例如用於臨時業務分析的環境
  • 工作負載具有變化且不可預測的運算需求的環境
  • 工作負載為間歇性或零星環境

使用 Amazon Redshift Serverless，無需按叢集付費，而是按每個工作負載查詢付費。這種定價模式意味著客戶只需按使用量付費，從而保持成本可控。 Amazon Redshift Serverless 具有與 Amazon Redshift 整合相同的優勢。對於沒有資料倉儲經驗的客戶，Amazon Redshift Serverless 是不錯的選擇。

Cluster 架構

Redshift 叢集的架構設計為列式、大規模平行、無共用架構 (SNA)。這是一種分散式運算架構，由多個獨立的節點伺服器組成，這些伺服器不共享記憶體和 CPU 等資源。單一節點負責處理請求。這種架構避免了節點之間的爭用。

image

Provisioned cluster deployment and node types

Provisioned cluster 可以部署在 Redshift 託管 VPC 或 AWS 客戶 VPC 中，以提供更強大的控制力。如果使用客戶 VPC，客戶需要先使用 Redshift 服務建立 Redshift 叢集子網路群組。叢集部署在特定可用區的子網路中。如果由於可用區問題導致叢集可用性出現問題，可以將叢集遷移到另一個可用區。多可用區叢集目前處於預覽階段，將以主動-主動配置在每個可用區中部署指定數量的節點。

下列是 Node Type

Dense storage (DS2)

Dense storage (DS2)節點類型用於以極低的價格提供硬碟 (HDD)，從而建立超大型資料倉儲。這些節點目前被標記為舊節點，新的 Redshift 叢集不應使用 DS2 節點類型。

Dense compute (DC2)

Dense compute (DC2) 節點類型用於透過提供快速 CPU、大量 RAM 和 SSD 來建立效能非常高的資料倉儲。

RA3

RA3 節點基於 AWS Nitro 虛擬機器管理程序，使用 Redshift 託管儲存。 AWS 客戶可以使用 RA3 節點進行擴展，並獨立支付運算和儲存費用。

在下列情況下，請考慮選擇 RA3 節點類型：

  • 需要靈活地擴展運算資源，並獨立支付儲存費用。
  • 查詢僅使用總資料的一小部分。
  • 數據量快速增長或預計會快速增長。
  • 需要靈活地僅根據效能需求調整叢集規模。

Serverless 架構

image

Table Design

Row 儲存 VS Col 儲存

在傳統關聯是資料庫，每個 Row 包含欄位的值，資料塊會依序儲存構成整行的每個連續列的值，如果區塊大小比 Record 大小還小，儲存整體紀錄可能用超過一個區塊。如果區塊大小比紀錄大小，儲存可能少於一個區塊，導致沒有效率的使用磁碟空間，基本上資料庫區塊大小是 2 至 32KB

image

使用 Col 存儲，每列的值會依序儲存到磁碟區塊。透過使用 Col 存儲，每個資料塊儲存多行中單一列的值。當記錄進入系統時，Redshift 會透明地將每列的資料轉換為列式儲存。Redshift 使用 1 MB 的區塊大小，這非常高效，並且進一步減少了執行任何資料庫載入或查詢執行過程中的其他操作所需的 I/O 請求數量。這意味著小型和大型寫入的處理成本相同，為了提高效率，大型寫入是首選。另一個結果是，與傳回所有列的行式儲存相比，讀取相同數量的記錄的相同數量的列欄位值所需的 I/O 操作更少。

Compression 壓縮

Col 儲存另一個優勢就是壓縮，因為每一個區塊都儲存相同類型的資料，區塊資料可以用壓縮格式來針對特定的欄位型別。欄位可以獨立的擴張或收縮，當給 Redshift 儲存 2 至 4 次的儲存能力，更多的 Cluster 資料可以藉由 I/O 操作次數來增加查詢效率

Data distribution 資料分布

分散風格是 Table 的屬性指揮資料表的資料如何在 Cluster 輸出入。當大量載入資料到 Table，Redshift 分散 Table 的 Row 到每一個 Compute Node 藉由 Table 的分散風格，當查詢運行，查詢優化器重新分配 Row 到 Compute Node 以執行任何 Join 和 Aggregate。

選擇表格分佈樣式的目的是，透過均勻分佈資料以實現並行處理，最大限度地減少重新分佈步驟的影響，並最大限度地減少查詢處理過程中的資料移動。表格分佈樣式包括 KEY、EVEN、ALL 或 AUTO，在建立表格時指定，預設為 AUTO。

  • KEY - 根據特定欄位值，Leader Node 讓合適的值放在相同的 Node Slice
  • EVEN - Leader Node 分散 Row 根據 Round-robin 方式
  • ALL - 全部的 Table 分散到每個 Node 當 EVEN/KEY 放一部分到每個 Node, ALL 分散確認每個 Row 搭配 Join 讓 Table 參與進來
  • AUTO - 是最佳化分散風格基於資料表資料大小，如果小就用 ALL 如果大就用 KEY 且用 PK 當 Key 更大的話就用 EVEN

Sorted tables 已排序的表

Redshift 區域映射是記憶體中的 Block Metadata，包含每個區塊的最小值和最大值。區域映射的目的是消除不必要的 I/O 操作。

Sorted Tables 的目標是透過提高區域映射的效率並減少 I/O 操作來提高查詢運行速度。排序表允許透過檢查區域映射的最小值和最大值來修剪區塊，從而進行範圍掃描。最佳排序鍵取決於表上使用的查詢模式、業務需求和資料設定檔。

Loading Data

載入大量資料很耗費時間我們提供以下最佳實踐方法

  • Use large data sets
  • Aggregate data before ingesting
  • Use the COPY command
  • Split and compress files
  • Load data in sort key order
  • Use a multi-row insert if the COPY command is not an option
  • Use time-series tables

Querying Data

Redshift Console Query Editor V2

Redshift / Redshift Serverless 都有 Query Editor 可以跑 SQL 查詢，但都推薦使用 V2，V2 可以獨立執行與儲存查詢或是透過 notebook 結合多個查詢

用 Query Editor V2 去連接預配置 Cluster，提供 Cluster/Database 名字，驗證方式等，受信用的使用者可以暫時的產生憑證與帳戶或是使用 Secret Manager

當然使用者也可以用 SQL Client 來連接 Redshift Cluster，也可以用 Redshift Data API 連接資料庫資料像是 Lambda,SageMaker notebooks 與 Cloud9

Semistructured Data

消化與儲存半結構資料在 Redshift 中使用 Super Data Type 與 PartiQL，可以整合 SQL/No-SQL 資料來源，也能提供良好的分析在關聯/半結構資料上。Redshift 提供兩種形式的半結構資料支援

  • SUPER data type
    • 需要 insert/update 一小部分的 JSON 資料並且要有很少的延遲
  • Redshift Spectrum
    • 可預設到的查詢效能，複雜的查詢支援，簡易使用的使用包含 Schema/Schemaless 資料

Query data in datalake

Redshift Spectrum 可以查詢 S3 的資料不需要將資料載入到 Redshift table，使用外部 data catalog 像是 Glue 支援 Parquet,ORC,RCFile,TextFile,SequenceFile,RegexSerde,OpenCSV,AVRO

當資料 Schema 用 Glue Data Catalog 註冊且啟用 Lake Formation 可以被 Redshift 存取

Redshift Spectrum 放置在獨立於 Redshift Cluster Server 上，Spectrum 將許多運算密集任務（像是 Predicate filtering 與 Aggregation）推送到 Redshift Spectrum 層。此外 Spectrum 還能智慧擴展，充分利用大規模並行處理。

使用者可以按一到多個 Row 對外部表健行 Parition 透過分區消除來優化查詢效能。可以用 Redshift Database Query 和連接外部資料表

使用者可以從多個 Redshift Cluster 存取外部表，並從相同 AWS 區域中的任何 Cluster 查詢 S3 資料。當 S3 檔案更新，該資料可提供 AWS Regoin 任何 Cluster 查詢。

自動效能微調

Redshift 使用基於機器學習的自動優化方案調整效能

分析 Table

使用 Redshift 計劃者需要更新 metadata 去計劃有效率的查詢。他們會用 ANALYZE 指令來更新。這個範圍是整個資料庫或是一張表有限度的欄位

預設 Redshift 持續監控工作負載的改變且資料在背景自動分析操作，使用者也可以手動執行 ANALYZE 指令。當 COPY 指令是用來載入資料到 Redshift Table，ANALYZE 指令會在完成後載入。

完成消化資料最佳實踐是執行 ANALYZE 指令在欄位上用 WHERE 收集查詢後的資料

自動 VACUUM DELETE

當資料被 Redshift 刪除，服務是邏輯上刪掉。VACUUM 指令將會刪除 row 並且標記成刪除然後重新排序剩下的資料。這個指令結果是儲存空間被重新分配，metadata 的順序也被更新

自動 Table 優化

Redshift 會持續掃描工作負載以及監控之藥，Redshift 使用者可以提到推薦的分散模式與排序 Key，使用者也可以允許 Redshift 使用推薦自動排序與分散 Key 藉由過往的工作負載

自動 Col 壓縮

ENCODE AUTO 是表預設當表設置成 ENCODE AUTO Redshift 會自動管理壓縮編碼所有欄位，使用者可以複寫 ENCODE AUTO 藉由指定編碼欄位，Redshift 將會指定其他欄位如下

  • Col 被定義 Sort key 且被已派 Raw 壓縮
  • Col 被定義成 Boolean, Real/Double Precision 會被指派 Raw 壓縮
  • Col 被定義成 Smallint,Interger,BigInt,Decimal,Date,Timestamp,Timestampz 資料型別會被指定成 AZ64 壓縮
  • Col 被定義成 Char/Varchar 型別會被指定成 LZO 壓縮

工作負載管理

Redshift Workload Management(WLM),使用者可以彈性的管理優先權在工作負在短缺的時候，快速執行查詢不會因為 Long Query 卡在 Queue 裡面

當執行 Query,WLM 指派第一個在 Queue 的 Query 基於 WLM 指派規則

  1. 如果使用者是 Superuser 去執行一個 superuser label query 就會被指派到 superuser queue
  2. 如果使用者是 UserGroup List 或跑一個 List Query Group Label 將會被指派的 First Matching Queue
  3. 如果查詢沒有符合的規則就會被指派到預設 Queue

Redshift Advisor

去提升效能並節省預配置 Redshift 成本，Redshift Advisor 提供特別的推薦，Advisor 開發是客制化且藉由分析效能與指標推薦的結果，這些推薦攸關到相關的操作與 Cluster 設定。去幫助優化這先 Advisor 會進行推薦排名藉由影響力的大小

更新於