資料從轉換區進入精選區後，通常會以批次處理方式進行業務轉換，這些區域的資料多屬於暖資料。在 AWS 環境中，暖資料通常儲存在 S3 標準、S3 標準-IA 或 S3 智慧型分層儲存類別。S3 標準提供即時存取，適用於 ETL 和臨時查詢；S3 標準-IA 儲存成本較低，但需支付擷取費用；S3 智慧型分層則根據存取頻率自動在不同層級間行動資料。熱資料則是指需要低延遲、高效能存取的資料，例如商業智慧應用程式和儀錶板資料，通常儲存在 Redshift 或 QuickSight SPICE 中。Redshift 作為高效能資料集市，適用於儲存和查詢大規模結構化和半結構化資料，提供比資料湖更佳的效能和更低的延遲。然而，使用 Redshift 時應避免將其用作交易資料儲存、資料湖或即時資料攝取的目標，也不適合儲存非結構化資料。
將資料載入資料集市
一般而言，經過轉換區的資料仍會進行批次處理，以進行進一步的業務轉換，然後再移至精選區。所有這些區域很可能都屬於暖資料的範疇。
在 AWS 中，暖資料也可以儲存在 Amazon S3 服務中，但最有可能儲存在標準儲存類別中。以下幾種 S3 儲存類別通常用於滿足暖資料需求：
- Amazon S3 標準（S3 標準）：S3 標準儲存類別提供即時存取資料的功能，其效能非常適合 ETL 作業和 Amazon Athena 或 Redshift Spectrum 的臨時 SQL 查詢。使用 S3 標準，成本取決於儲存的資料量，且沒有每 GB 資料擷取成本（雖然有 API GET 呼叫的成本）。
- Amazon S3 標準-不常存取（S3 標準-IA）：此儲存類別提供與 Amazon S3 標準相同的即時存取資料功能，以及相同的快速擷取速度。使用 S3 標準-IA，每 GB 的儲存成本比 S3 標準低，但擷取資料時需要支付每 GB 的成本。此類別中的資料可以直接透過 Glue 作業、Amazon Athena、Redshift Spectrum 等存取。
- Amazon S3 智慧型分層（S3 智慧型分層）：當您不確定資料存取模式時，此儲存類別非常有用。使用智慧型分層，如果資料物件在 30 天內未被存取，則會自動從標準層移至不常存取層。您也可以啟用封存層，在這種情況下，90 天內未被存取的物件將被移至 S3 Glacier，而 180 天內未被存取的物件將被移至 S3 Glacier Deep Archive。
內容解密：
每個儲存類別都有不同的定價計劃。S3 標準的成本取決於儲存和 API 呼叫（put、copy、get 等），而 S3 標準不常存取也有每 GB 資料擷取的成本。S3 智慧型分層沒有每 GB 資料擷取的成本，但每個物件都有少量的監控和自動化成本。有關定價的更多詳細資訊，請參閱 https://aws.amazon.com/s3/pricing/。
當您瞭解資料的存取模式時，您應該選擇 S3 標準或 S3 標準-不常存取類別。但是，如果您不確定資料的存取模式，您應該強烈考慮將資料儲存在 S3 智慧型分層類別中，並允許 Amazon S3 服務根據資料消費者如何存取資料自動在不同類別之間行動資料。
熱資料
熱資料是指對組織的日常分析功能至關重要的資料。這種資料很可能每天被多次存取，並且需要低延遲、高效能的存取。
這種資料的一個例子是商業智慧應用程式（例如 Amazon QuickSight 或 Tableau）使用的資料。例如，這可能是用於顯示不同地點產品製造和銷售的資料。這通常是組織中終端使用者資料消費者以及需要執行複雜資料查詢的業務分析師使用的資料。此資料也可能用於不斷重新整理的儀錶板，提供組織中高階主管使用的關鍵業務指標和 KPI。
在 AWS 中，可以使用多種服務提供對資料的高效能、低延遲存取。其中包括 RDS 資料函式庫引擎、NoSQL DynamoDB 資料函式庫以及 Elasticsearch（用於搜尋全文資料）。然而，從分析的角度來看，熱資料最常見的目標是 Amazon Redshift 或 Amazon QuickSight SPICE（代表超快速、平行、記憶體內計算引擎）：
- Amazon Redshift 是一種超快速的雲端原生資料倉儲解決方案，提供對資料倉儲中儲存的資料的高效能、低延遲存取。
- Amazon QuickSight 是 Amazon 的商業智慧工具，用於建立儀錶板。使用 Amazon QuickSight，您可以選擇從 Amazon Redshift 等來源讀取資料，或直接將資料載入 QuickSight 的記憶體內資料函式庫引擎（SPICE），以獲得最佳的高效能、低延遲存取。
內容解密：
正如我們之前提到的，AWS 為不同的資料型別/溫度提供了專門的儲存引擎。使用哪種引擎的決定通常根據成本與效能之間的權衡。
在許多情況下，資料具有時間敏感性。可能有一個業務應用程式需要報告歷史統計資料、當前趨勢以及過去幾個月資料的縮小檢視。其中一些資料也可能需要頻繁重新整理。這需要資料工程師處理資料、清理和處理，然後將資料的子集載入高效能引擎（如 Amazon Redshift）。
在本章中，我們將重點介紹使用 Amazon Redshift 作為熱資料存取的高效能資料集市。從成本和可擴充套件性的角度來看，資料湖是一個很好的選擇，可以儲存大量資料並作為最終的真實來源。然而，資料倉儲提供了一種應用程式特定的方法來查詢大規模結構化和半結構化資料，具有最佳的效能和最低的延遲。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title Redshift 資料載入與高效能設計
package "AWS 雲端架構" {
package "網路層" {
component [VPC] as vpc
component [Subnet] as subnet
component [Security Group] as sg
component [Route Table] as rt
}
package "運算層" {
component [EC2] as ec2
component [Lambda] as lambda
component [ECS/EKS] as container
}
package "儲存層" {
database [RDS] as rds
database [DynamoDB] as dynamo
storage [S3] as s3
}
package "服務層" {
component [API Gateway] as apigw
component [ALB/NLB] as lb
queue [SQS] as sqs
}
}
apigw --> lambda
apigw --> lb
lb --> ec2
lb --> container
lambda --> dynamo
lambda --> s3
ec2 --> rds
container --> rds
vpc --> subnet
subnet --> sg
sg --> rt
@enduml
此圖示說明瞭AWS中不同型別的資料儲存解決方案，包括用於暖資料的S3儲存類別和用於熱資料的Amazon Redshift和Amazon QuickSight SPICE。暖資料可以根據存取模式和成本需求選擇不同的S3儲存類別，而熱資料則需要高效能和低延遲的存取，通常使用Amazon Redshift或Amazon QuickSight SPICE來實作這一目標。
資料倉儲使用上的反模式探討
在利用資料倉儲進行分析時，有許多良好的實踐方式，但也有一些做法是不建議的。讓我們來看看一些應該避免的資料倉儲使用方式。
將資料倉儲用作交易資料儲存
資料倉儲主要針對線上分析處理（OLAP）查詢進行最佳化，因此不適合用於線上交易處理（OLTP）查詢和應用場景。雖然資料倉儲支援更新或刪除資料，但其設計初衷是針對追加式查詢。此外，像MySQL或PostgreSQL這樣的交易資料函式庫中使用的主鍵和外部索引鍵概念在Redshift中也存在，但這些主要是用於效能最佳化和查詢規劃，而非強制執行。
將資料倉儲當作資料湖使用
資料倉儲透過將高效能儲存直接附加到計算引擎來提升效能。它們能夠擴充套件以儲存大量資料，並且除了支援結構化資料外，也對半結構化資料提供一定程度的支援。然而，資料倉儲需要事先規劃schema和表格結構，並且不適合儲存非結構化資料（如圖片和音訊），同時只支援SQL進行資料查詢和轉換。由於資料倉儲包含計算引擎，其成本相較於將資料儲存在低成本的物件儲存中更高。
相對地，資料湖允許將所有資料儲存在低成本的物件儲存中，並可以在無需事先設計schema結構的情況下攝入資料。還可以直接分析資料集（使用Amazon Athena等工具），並使用多種工具（例如SQL和Spark）轉換資料，然後僅將所需的資料匯入資料倉儲中。
避免在資料倉儲中儲存不必要的資料
資料倉儲應該儲存經過整理的資料集，具有明確定義的schema，並且只儲存需要進行高效能、低延遲查詢的熱資料。
將資料倉儲用於即時、記錄級別的應用場景
資料倉儲最佳化了批次載入資料，不太適合逐條攝入資料。因此，不建議將資料倉儲直接用作大量IoT資料（或其他即時資料來源）的目標。如果需要在Redshift中載入這類別資料，建議先緩衝資料，然後批次載入到Redshift。一個可行的方法是將資料即時傳送到Kinesis Firehose，Kinesis Firehose可以緩衝最多15分鐘的資料，或最多128 MB的資料，以先到者為準。一旦緩衝區滿了，Kinesis就可以指示Redshift載入該批次資料。
儲存非結構化資料
雖然某些資料倉儲（如Amazon Redshift）能夠儲存半結構化資料（如JSON資料），但不應將其用於儲存圖片、影片和其他媒體內容等非結構化資料。在決定將資料儲存在哪裡之前，應考慮哪種資料引擎最適合特定的資料型別。例如，醫療保健FHIR資料具有高度巢狀的JSON結構，儘管可以在Amazon Redshift中儲存和查詢，但可能更適合使用專為該特定資料型別設計的解決方案，如Amazon HealthLake。
Redshift架構審視與儲存探討
在本文中，我們將探討Redshift叢集的架構，以及表格中的資料如何在Redshift節點之間儲存。這種深入的瞭解將有助於您理解並微調Redshift的效能，同時我們也會介紹如何自動化許多影響表格佈局的設計決策。
Redshift架構與節點組態
每個計算節點都包含一定量的計算能力（CPU和記憶體）以及一定量的本地儲存。在組態Redshift叢集時，可以根據計算和儲存需求新增多個計算節點。為了提供容錯能力和改進的永續性，計算節點具有2.5至3倍於所宣告的節點儲存容量。
每個計算節點被分成2、4或16個切片，具體取決於叢集型別和大小。每個切片分配了一部分節點的記憶體和儲存，並作為獨立的工作單元，但與其他切片平行工作。切片儲存大型表格的不同列資料，由長官節點分發。每列的資料以1 MB不可變區塊的形式持久化，每列都可以獨立增長。
資料在切片間的分佈
當使用者對Redshift執行查詢時，長官節點會建立查詢計畫，為每個切片分配工作，然後切片平行執行工作。當每個切片完成其工作後，它會將結果傳回給長官節點進行最終匯總或排序和合併。然而，這意味著查詢的效能取決於最慢的分割槽。
資料分佈解析
在Redshift中，資料的分佈對於查詢效能至關重要。瞭解資料如何在切片間分佈有助於最佳化查詢並提高整體效能。
-- 示例：檢視某個表格的分佈方式
SELECT
slice,
COUNT(*)
FROM
stv_blocklist
GROUP BY
slice;
內容解密：
此查詢用於檢視某個表格在Redshift叢集中的切片間的分佈情況。其中：
stv_blocklist是一個系統表格，用於顯示區塊在切片上的分佈。slice欄位表示資料所在的切片編號。COUNT(*)統計每個切片上的區塊數量。 此查詢幫助我們瞭解資料是否均勻分佈在各個切片上，從而評估查詢效能的潛在瓶頸。
Redshift 架構檢視與儲存深度解析
在 Redshift 的架構中，資料的分佈對於查詢效能具有關鍵性的影響。圖 9.1 展示了資料如何在運算節點上的切片（slice）中分佈。
資料分佈與查詢效能最佳化
在前面的圖表中，我們可以看到 column2 的資料被分散儲存在 Slice1-Disk1、Slice1-Disk2 和 Slice2-Disk1 上。為了提高資料吞吐量和查詢效能，資料應該均勻地分佈在各個切片上，以避免 I/O 瓶頸。如果某個特定表格的大部分資料都儲存在一個節點上，那麼這個節點將承擔大部分的工作負載，從而降低平行處理的效益。
Redshift 支援多種資料分佈樣式，包括 EVEN、KEY 和 ALL，並且可以自動選擇最佳的分佈樣式。所選的分佈樣式決定了某一列中的某一行資料將被儲存在哪個切片上。
JOIN 查詢的最佳化
在進行分析時，JOIN 操作是非常常見的。假設我們有兩個表格：一個是小型維度表（約 2-3 百萬行），另一個是非常大的事實表（可能有數億行）。小型維度表可以輕易地儲存在單一節點的儲存中，而大型事實表則需要跨多個節點分佈。
影響 JOIN 查詢效能的一個重要因素是資料在節點間的洗牌（複製）。為了避免這種情況並最佳化 JOIN 效能，可以將小型維度表儲存在叢集的所有切片上，方法是指定 ALL 分佈樣式。對於較大的表格，可以透過指定 EVEN 分佈樣式，使資料均勻地分佈在所有切片上。
這樣，每個切片都將擁有小型維度表的完整複製，並且可以直接與其所持有的大型事實表的資料子集進行 JOIN 操作，而無需從其他切片洗牌維度資料。
-- 建立小型維度表並指定 ALL 分佈樣式
CREATE TABLE small_dimension_table (
column1 datatype,
column2 datatype
) DISTSTYLE ALL;
-- 建立大型事實表並指定 EVEN 分佈樣式
CREATE TABLE large_fact_table (
column1 datatype,
column2 datatype
) DISTSTYLE EVEN;
內容解密：
DISTSTYLE ALL：將小型維度表儲存在所有切片上，以最佳化 JOIN 查詢效能。DISTSTYLE EVEN：將大型事實表均勻地分佈在所有切片上，以避免 I/O 瓶頸。- 這種分佈策略可以減少資料在節點間的洗牌，從而提高查詢效能。
然而，使用 ALL 分佈樣式會增加儲存空間的使用，並對資料載入效能產生負面影響。另一種最佳化 JOIN 的方法是使用 KEY 分佈樣式，確保需要 JOIN 的資料行儲存在相同的切片上。
KEY 分佈樣式的使用
當需要 JOIN 的兩個表格都很大時，可以使用 KEY 分佈樣式。透過對某個欄位進行雜湊運算，Redshift 可以決定哪一行資料儲存在哪個切片上。例如，如果我們有一個儲存產品資訊的表格和一個儲存銷售資訊的表格，並且經常需要根據 product_id 欄位進行 JOIN 操作，那麼可以根據 product_id 的值來分佈這兩個表格的資料。
-- 建立產品資訊表並指定 KEY 分佈樣式
CREATE TABLE products (
product_id datatype,
product_info datatype
) DISTSTYLE KEY DISTKEY (product_id);
-- 建立銷售資訊表並指定 KEY 分佈樣式
CREATE TABLE sales (
sale_id datatype,
product_id datatype,
sale_info datatype
) DISTSTYLE KEY DISTKEY (product_id);
內容解密：
DISTSTYLE KEY：根據指定的欄位（此例中為product_id）進行雜湊運算，以決定資料行的儲存位置。DISTKEY (product_id)：指定product_id為分佈鍵，確保具有相同product_id的資料行儲存在相同的切片上。- 這種分佈策略可以最佳化 JOIN 查詢的效能，但需要避免在 WHERE 子句中頻繁使用的欄位上使用 KEY 分佈樣式，以防止產生瓶頸。
Zone Maps 與資料排序
查詢傳回結果的時間也受到硬體因素的影響，例如磁碟尋道時間和磁碟存取時間。Redshift 使用 Zone Maps 來減少資料存取延遲。Zone Maps 儲存了每個磁碟區塊的元資料，例如每個欄位的最大值和最小值。根據這些資訊，Redshift 可以跳過讀取不相關的區塊，從而最佳化查詢效能。
Zone Maps 在資料區塊有序時最為有效。在定義表格時，可以選擇性地定義一個或多個排序鍵，以決定資料在區塊內的排序順序。
-- 建立表格並指定排序鍵
CREATE TABLE example_table (
column1 datatype,
column2 datatype,
column3 datatype
) SORTKEY (column1, column2);
內容解密：
SORTKEY (column1, column2)：指定column1和column2為排序鍵，以決定資料在區塊內的排序順序。- 排序鍵可以提高 Zone Maps 的效率，從而最佳化查詢效能。
- 需要根據實際查詢模式選擇合適的排序鍵，以最大化效能提升。
總之，Redshift 的資料分佈和排序策略對於查詢效能具有重要影響。透過選擇合適的分佈樣式和排序鍵，可以顯著提高查詢效能。然而，這些策略的選擇需要根據具體的使用場景和查詢模式進行最佳化。幸運的是，Redshift 提供了自動最佳化的功能，可以簡化這些複雜的設計決策。
高效能資料倉儲設計
設計高效能的資料倉儲時，需要考量多項因素，包括叢集型別與規模、壓縮型別、分配鍵、排序鍵、資料型別和表格限制等。在設計過程中，需要在成本與效能、儲存空間與效能之間進行權衡。業務需求和預算往往會驅動這些決策。
除了基礎設施和儲存的決定外，邏輯架構設計也在最佳化資料倉儲效能上扮演重要角色。通常，這會是一個迭代過程，先從初始的架構設計開始，然後隨著時間推移不斷最佳化，以提升效能。
選擇最佳的Redshift節點型別
Redshift提供了不同型別的節點，每種節點都有不同的CPU、記憶體、儲存容量和儲存型別的組合。主要分為三種節點型別：
- RA3節點：採用託管儲存時，可以將運算和儲存分離，按小時支付運算費用，並根據每月的儲存使用量支付額外費用。儲存空間結合了本地SSD儲存和S3中儲存的資料。
- DC2節點：專為運算密集型工作負載設計，每個節點具有固定容量的本地SSD儲存。DC2節點的運算和儲存是耦合的，也就是說，要增加運算或儲存，都需要新增包含運算和儲存的新節點。
- DS2節點：這是一種舊式的節點，提供運算功能並附加大型硬碟。DS2節點的運算和儲存也是耦合的。
AWS建議，小型資料倉儲（小於1 TB）使用DC2節點，而較大的資料倉儲則使用具備託管儲存的RA3節點。DS2節點型別是一種舊式節點型別，一般不建議在建立新的Redshift叢集時使用。
在控制檯中建立新的Redshift叢集時，可以輸入有關資料大小、資料型別和資料保留期限等資訊，這將為工作負載提供建議的節點型別和數量。
選擇最佳的表格分配樣式和排序鍵
早期Redshift的使用者需要手動選擇每個表格的分配樣式和排序鍵。當Redshift叢集的效能不如預期時，通常是由於分配樣式和/或排序鍵不佳所導致。
因此，Amazon引入了新的功能，使Redshift能夠利用先進的人工智慧方法監控叢集上的查詢，並自動套用最佳的分配樣式和/或排序鍵。在最少查詢次數後的幾個小時內，就可以對表格進行最佳化。
如果建立新表格時未指定特定的分配樣式或排序鍵，Redshift會將這兩個設定都設為AUTO。較小的表格最初會被設定為ALL分配樣式，而較大的表格則會採用EVEN分配樣式。
如果表格最初很小，但隨著時間增長，Redshift會自動將分配樣式調整為EVEN。隨著Redshift分析叢集上的查詢，可能會進一步將表格分配樣式調整為根據KEY的分配樣式。
同樣地，Redshift會分析執行的查詢，以確定表格的最佳排序鍵。這種最佳化的目標是最佳化在表格掃描期間從磁碟讀取的資料區塊。
強烈建議讓Redshift自動管理表格的分配和排序鍵最佳化，但如果有特殊的使用案例，也可以手動組態這些設定。
為欄位選擇正確的資料型別
Redshift表格中的每個欄位都與特定的資料型別相關聯，這確保了欄位符合特定的限制。這有助於規範可以對欄位中的值執行的操作型別。
例如，只有數值資料型別才能執行總和等算術運算。如果需要在定義為字元或字串型別的欄位上執行總和運算，則需要將其轉換為數值型別。這可能會影響查詢效能，因此需要考慮。
Amazon Redshift目前支援大約六種資料型別。下面來看看。
字元型別
字元資料型別相當於程式語言和關聯式資料函式庫中的字串資料型別，用於儲存文字。
主要有兩種字元型別：
CHAR(n)、CHARACTER(n)和NCHAR(n)：這些是固定長度的字元字串，只支援單位元組字元。資料會在結尾加上尾隨空白，以將字串轉換為固定長度。例如，如果將欄位定義為CHAR(8)，則該欄位中的資料將按以下方式儲存：
CHAR(8) “ABC " “DEF "
但是，在查詢過程中，尾隨空白會被忽略。例如，如果查詢上述記錄的長度，則會傳回3，而不是8。同樣，如果查詢表格中與「ABC」相符的記錄，也會忽略尾隨空白並傳回該記錄。
VARCHAR(n)和NVARCHAR(n)：這些是可變長度的字元字串，支援多位元組字元。在建立此資料型別時，為了確定正確的長度，應將每個字元的位元組數與需要儲存的最大字元數相乘。
例如，VARCHAR(8)欄位可以儲存最多8個單位元組字元、4個雙位元組字元或2個四位元組字元。若要計算VARCHAR的n值，請將每個字元的位元組數乘以字元數。
由於此資料型別用於可變長度的字串，因此資料不會以尾隨空白填充。
在決定字元型別時，如果需要儲存多位元組字元，則應始終使用VARCHAR資料型別。例如，歐元符號（€）由3個位元組的字元表示，因此不應儲存在CHAR欄位中。但是，如果資料始終可以使用單位元組字元進行編碼，並且始終具有固定長度，則使用固定寬度的CHAR資料型別。例如，儲存電話號碼或IP位址的欄位就很適合使用CHAR資料型別。