從 Amazon Redshift 遷移至 BigQuery：總覽
本文件提供從 Amazon Redshift 遷移至 BigQuery 的指引，重點如下：
- 遷移策略
- 查詢最佳化和資料建模的最佳做法
- 疑難排解提示
- 使用者採用指南
本文件的目標如下：
- 為從 Amazon Redshift 遷移至 BigQuery 的機構提供高層面指引，包括協助您重新思考現有的資料管道，以便充分運用 BigQuery。
- 協助您比較 BigQuery 和 Amazon Redshift 的架構，以便您決定如何在遷移期間實作現有功能。這項功能旨在向您展示貴機構可透過 BigQuery 使用的新功能，而非將功能一對一對應至 Amazon Redshift。
本文檔適用於企業架構師、資料庫管理員、應用程式開發人員和 IT 安全專家。這篇文章假設您熟悉 Amazon Redshift。
您也可以使用批次 SQL 翻譯大量遷移 SQL 指令碼，或是使用互動式 SQL 翻譯翻譯臨時查詢。兩項 SQL 轉譯服務都完全支援 Amazon Redshift SQL。
遷移前作業
為確保資料倉儲遷移作業順利進行，請在專案時間表的早期開始規劃遷移策略。這個方法可讓您評估符合需求的 Google Cloud 功能。
處理能力規劃
BigQuery 會使用資料格來評估數據分析的傳輸量。BigQuery 運算單元是 Google 專屬的運算能力單位，執行 SQL 查詢時需要使用此單位。BigQuery 會持續計算查詢執行時所需的運算單元數量，但會根據公平調度器將運算單元分配給查詢。
規劃 BigQuery 運算單元的容量時，您可以選擇下列任一計價模式：
- 以量計價：在以量計價模式中，BigQuery 會按照實際處理的位元組數 (資料大小) 收取費用，因此您只需為執行的查詢付費。如要進一步瞭解 BigQuery 如何判斷資料大小，請參閱「資料大小計算方式」一文。運算單元會決定基礎運算容量，因此您可以根據所需的運算單元數量 (而非處理的位元組數) 支付 BigQuery 使用費。根據預設，所有Google Cloud 專案的運算單元數上限為 2000 個。BigQuery 可能會透過爆發功能提供高於這項限制的運算單元數量，藉此加快查詢速度，但無法保證會爆發。
- 以容量為基礎的定價：採用以容量為基礎的定價時，您購買的是 BigQuery 運算單元保留空間 (至少 100 個)，而非為執行的查詢作業所處理的位元組付費。我們建議企業資料倉儲工作負載採用容量定價，因為這類工作負載通常會同時執行許多報表和擷取-載入-轉換 (ELT) 查詢，且這些查詢的使用量是可預測的。
如要估算運算單元，建議您使用 Cloud Monitoring 監控 BigQuery，並使用 BigQuery 分析稽核記錄。您可以使用 Looker Studio (以下是 Looker Studio 資訊主頁的開放原始碼範例) 或 Looker 來以視覺化方式呈現 BigQuery 的稽核記錄資料，特別是查詢和專案的時間間隔使用情形。您也可以使用 BigQuery 的系統資料表資料，監控工作和預留作業的空缺使用率 (以下是 Looker Studio 資訊主頁的開源範例)。定期監控及分析時段使用率，有助您預估貴機構在 Google Cloud上成長時需要多少時段。
舉例來說，假設您一開始預留 4,000 個 BigQuery 運算單元，以便同時執行 100 個中等複雜度的查詢。如果您發現查詢執行計畫的等待時間很長，且資訊主頁顯示的空白利用率很高，這可能表示您需要額外的 BigQuery 空白，以便支援工作負載。如果您想透過年度或三年承諾購買運算單元，可以使用Google Cloud 主控台或 bq 指令列工具開始使用 BigQuery 預留功能。如要進一步瞭解工作負載管理、查詢執行作業和 BigQuery 架構，請參閱遷移至Google Cloud：深入分析。
Google Cloud的安全防護
以下各節將說明常見的 Amazon Redshift 安全控管機制，以及如何確保資料倉儲在Google Cloud 環境中保持安全。
身分與存取權管理
在 Amazon Redshift 中設定存取權控管功能，需要編寫 Amazon Redshift API 權限政策，並將這些政策附加至 Identity and Access Management (IAM) 身分。Amazon Redshift API 權限可提供叢集層級存取權，但不會提供比叢集更精細的存取權層級。如果您想要更精細地存取資料表或檢視等資源，可以使用 Amazon Redshift 資料庫中的使用者帳戶。
BigQuery 會使用 IAM 來管理資源的存取權，精細程度更高。BigQuery 提供的資源類型包括機構、專案、資料集、資料表、欄和檢視。在 IAM 政策階層中，資料集是專案的子項資源。資料表會繼承其所屬資料集的權限。
如要授予資源的存取權，請將一或多個 IAM 角色指派給使用者、群組或服務帳戶。機構和專案角色會影響執行工作或管理專案的權限，而資料集角色則會影響存取或修改專案內資料的權限。
IAM 提供以下類型的角色：
在 IAM 中，BigQuery 提供資料表層級存取權控管。資料表層級權限可以決定哪些使用者、群組和服務帳戶可以存取資料表或檢視表。您可以授予使用者特定資料表或檢視畫面的存取權，而非完整資料集的存取權。如要取得更精細的存取權，您也可以考慮實作下列一或多項安全機制：
- 資料欄層級存取權控管機制：透過政策標記或依據類型的資料分類方式，對機密資料欄提供精細的存取權。
- 資料欄層級動態資料遮罩：可讓您選擇性地隱藏一組使用者的資料欄資料，同時仍允許存取資料欄。
- 資料列層級安全性：可讓您篩選資料，並根據符合資格的使用者條件，啟用資料表中特定列的存取權。
全磁碟加密
除了身分和存取權管理之外，資料加密功能還可為資料提供額外的防護層。在資料外洩的情況下，加密資料無法讀取。
在 Amazon Redshift 上，預設不會啟用靜態資料和傳輸中資料的加密功能。啟動叢集或修改現有叢集以使用 AWS Key Management Service 加密功能時，必須明確啟用靜態資料加密功能。您也必須明確啟用傳輸中資料的加密功能。
根據預設，BigQuery 會對所有靜態資料和傳輸中的資料進行加密，無論來源或其他條件為何，都無法關閉這項功能。如果您想在 Cloud Key Management Service 中控管及管理金鑰加密金鑰，BigQuery 也支援客戶管理的加密金鑰 (CMEK)。
如要進一步瞭解 Google Cloud中的加密功能，請參閱有關靜態資料加密和傳輸中資料加密的白皮書。
對於在 Google Cloud上傳輸的資料，如果資料移出 Google 或 Google 代理單位控管的實體界限，系統會加密及驗證資料。在這些界線內，傳輸中的資料通常會經過驗證，但不一定會加密。
資料遺失防護
法規遵循要求可能會限制可儲存在Google Cloud上的資料。您可以使用 Sensitive Data Protection 掃描 BigQuery 資料表，以偵測及分類機密資料。如果偵測到機密資料，Sensitive Data Protection 去識別化轉換可遮蔽、刪除或以其他方式隱藏該資料。
遷移至 Google Cloud：基本概念
本節將進一步說明如何使用工具和管道協助遷移作業。
遷移工具
BigQuery 資料移轉服務提供自動化工具，可直接將結構定義和資料從 Amazon Redshift 遷移至 BigQuery。下表列出可協助您從 Amazon Redshift 遷移至 BigQuery 的其他工具：
| 工具 | Purpose |
|---|---|
| BigQuery 資料移轉服務 | 使用這項全代管服務，自動將 Amazon Redshift 資料批次移轉至 BigQuery。 |
| Storage 移轉服務 | 使用這項全代管服務，快速將 Amazon S3 資料匯入 Cloud Storage，並設定資料移轉的週期性時間表。 |
gcloud |
使用這個指令列工具，將 Amazon S3 檔案複製到 Cloud Storage。 |
| bq 指令列工具 | 使用這個指令列工具與 BigQuery 互動。常見的互動包括建立 BigQuery 資料表結構定義、將 Cloud Storage 資料載入資料表，以及執行查詢。 |
| Cloud Storage 用戶端程式庫 | 使用以 Cloud Storage 用戶端程式庫為基礎建構的自訂工具，將 Amazon S3 檔案複製到 Cloud Storage。 |
| BigQuery 用戶端程式庫 | 使用 BigQuery 用戶端程式庫建構的自訂工具，與 BigQuery 互動。 |
| BigQuery 查詢排程器 | 使用這項內建的 BigQuery 功能，安排週期性 SQL 查詢。 |
| Cloud Composer | 使用這個全代管 Apache Airflow 環境，即可調度轉換作業和 BigQuery 載入作業。 |
| Apache Sqoop | 使用 Sqoop 和 Amazon Redshift 的 JDBC 驅動程式提交 Hadoop 工作，從 Amazon Redshift 擷取資料並儲存至 HDFS 或 Cloud Storage。Sqoop 會在 Dataproc 環境中執行。 |
如要進一步瞭解如何使用 BigQuery 資料移轉服務，請參閱「從 Amazon Redshift 遷移結構定義和資料」。
使用管道進行遷移
您可以根據可用的遷移工具，選擇不同的遷移路徑，將資料從 Amazon Redshift 遷移至 BigQuery。雖然本節的清單並未涵蓋所有內容，但可讓您瞭解搬移資料時可用的不同資料管道模式。
如要進一步瞭解如何使用管道將資料遷移至 BigQuery，請參閱「遷移資料管道」。
擷取及載入 (EL)
您可以使用 BigQuery 資料移轉服務，將 EL 管道完全自動化，這項服務可自動將資料表的結構定義和資料從 Amazon Redshift 叢集複製到 BigQuery。如要進一步控管資料管道步驟，您可以使用下列各節所述的選項建立管道。
使用 Amazon Redshift 檔案擷取內容
- 將 Amazon Redshift 資料匯出至 Amazon S3。
使用下列任一選項，將資料從 Amazon S3 複製到 Cloud Storage：
使用下列任一選項，將 Cloud Storage 資料載入 BigQuery：
使用 Amazon Redshift JDBC 連線
使用下列任一 Google Cloud 產品，透過 Amazon Redshift JDBC 驅動程式匯出 Amazon Redshift 資料：
-
- Google 提供的範本：JDBC 到 BigQuery
-
使用 Sqoop 和 Amazon Redshift JDBC 驅動程式，將資料從 Amazon Redshift 擷取至 Cloud Storage
擷取、轉換及載入 (ETL)
如果您想在將部分資料載入 BigQuery 前進行轉換，請按照「擷取和載入 (EL)」一節所述的管道建議操作，在載入 BigQuery 前新增額外步驟來轉換資料。
使用 Amazon Redshift 檔案擷取內容
使用下列任一選項，將資料從 Amazon S3 複製到 Cloud Storage：
使用下列任一選項，將資料轉換並載入至 BigQuery：
使用 Amazon Redshift JDBC 連線
使用「擷取與載入 (EL)」一節所述的任何產品，在將資料載入 BigQuery 前，新增額外步驟來轉換資料。修改管道，在寫入 BigQuery 前加入一或多個轉換資料的步驟。
-
- 複製 JDBC 到 BigQuery 範本程式碼，並修改範本以新增 Apache Beam 轉換。
-
- 使用任何 CDAP 外掛程式轉換資料。
擷取、載入及轉換 (ELT)
您可以使用 BigQuery 本身轉換資料，並使用任何擷取及載入 (EL) 選項將資料載入待用資料表。接著，您可以使用 SQL 查詢來轉換此階段資料表中的資料，並將輸出內容寫入最終正式版資料表。
變更資料擷取 (CDC)
變更資料擷取是用來追蹤資料變更的其中一個軟體設計模式，通常用於資料倉儲系統，這是因為資料倉儲系統是用來整理資料，並追蹤不同來源系統隨著時間經過而產生的資料變更。
資料遷移合作夥伴工具
擷取、轉換及載入 (ETL) 領域中有多家供應商。如需重要合作夥伴和他們提供的解決方案清單，請參閱 BigQuery 合作夥伴網站。
遷移至 Google Cloud：深入分析
請參閱本節，進一步瞭解資料倉儲架構、結構定義和 SQL 方言對遷移作業的影響。
架構比較
BigQuery 和 Amazon Redshift 都採用大規模平行處理 (MPP) 架構。查詢會分散到多個伺服器，以便加快執行速度。就系統架構而言，Amazon Redshift 和 BigQuery 的主要差異在於資料儲存方式和查詢執行方式。在 BigQuery 中，底層硬體和設定會以抽象方式呈現；其儲存空間和運算功能可讓資料倉儲擴充，而您不必進行任何干預。
運算、記憶體和儲存空間
在 Amazon Redshift 中，CPU、記憶體和磁碟儲存空間會透過運算節點綁定在一起，如Amazon Redshift 說明文件中的這張圖表所示。叢集效能和儲存空間容量取決於運算節點的類型和數量，這兩項都必須設定。如要變更運算或儲存空間，您必須透過一項程序 (超過幾個小時，或最多兩天或更久) 變更叢集大小，這項程序會建立全新的叢集並複製資料。Amazon Redshift 也提供 RA3 節點，內含可協助分離運算與儲存空間的受管理儲存空間。RA3 類別中最大的節點，每個節點的受管理儲存空間上限為 64 TB。
從一開始，BigQuery 就不會將運算、記憶體和儲存空間綁在一起，而是分別處理。
BigQuery 運算功能由運算單元定義，運算單元是執行查詢所需的運算能力單位。Google 會管理用於封裝的整個基礎架構，您只需為 BigQuery 工作負載選擇適當的槽數量，即可完成所有工作。請參閱容量規劃，瞭解如何為資料倉儲購買多少個插槽。BigQuery 記憶體是由遠端分散式服務提供，並透過 Google 的 petabit 網路連線至運算單元，所有服務皆由 Google 管理。
BigQuery 和 Amazon Redshift 都使用資料欄式儲存空間，但 BigQuery 會在資料欄式儲存空間上使用變化和進階功能。在資料欄進行編碼時，系統會保留資料的各種統計資料，並在查詢執行期間使用這些資料，以編譯最佳計畫並選擇最有效率的執行階段演算法。BigQuery 會將資料儲存在 Google 的分散式檔案系統中，並自動進行壓縮、加密、複製和分發。這一切都不會影響查詢可用的運算能力。將儲存空間與運算資源區隔開來，即可無縫擴充數十 PB 的儲存空間，且無須額外提供昂貴的運算資源。將運算和儲存空間分開還有許多其他優點。
向上或向下擴充
當儲存空間或運算資源不足時，您必須修改叢集中的節點數量或類型，才能調整 Amazon Redshift 叢集的大小。
調整 Amazon Redshift 叢集大小時，有兩種方法：
- 傳統的調整大小：Amazon Redshift 會建立叢集，並將資料複製到該叢集，這項程序可能需要幾小時的時間，如果資料量龐大，則可能需要兩天或更久的時間。
- 彈性調整大小：如果您只變更節點數量，系統會暫時暫停查詢，並盡可能保持連線。在調整大小作業期間，叢集為唯讀。彈性調整大小通常需要 10 到 15 分鐘，但可能不適用於所有設定。
由於 BigQuery 是平台即服務 (PaaS)，您只需考量要為貴機構預留多少個 BigQuery 運算單元。您可以在保留項目中預留 BigQuery 運算單元，然後將專案指派給這些保留項目。如要瞭解如何設定這些預留項目，請參閱「容量規劃」。
查詢執行
BigQuery 的執行引擎與 Amazon Redshift 相似，兩者都會將查詢分成步驟 (查詢計畫)，執行這些步驟 (盡可能並行執行)，然後重新組合結果。Amazon Redshift 會產生靜態查詢計劃，但 BigQuery 不會，因為 BigQuery 會在查詢執行時動態最佳化查詢計劃。BigQuery 會使用其遠端記憶體服務進行資料洗牌，而 Amazon Redshift 則會使用本機運算節點記憶體進行資料洗牌。如要進一步瞭解 BigQuery 如何儲存查詢計劃不同階段的中繼資料，請參閱「Google BigQuery 中的記憶體內查詢執行作業」。
BigQuery 中的工作負載管理
BigQuery 提供下列工作負載管理 (WLM) 控制項：
- 互動式查詢：會盡快執行 (這是預設設定)。
- 批次查詢會代表您排入佇列，然後在 BigQuery 共用資源集區中出現閒置資源時立即開始。
透過以容量為準的定價進行運算單元保留。您可以動態建立及管理運算單元分層，稱為預留項目，並將專案、資料夾或機構指派給這些預留項目。您可以購買 BigQuery 運算單元承諾 (最少 100 個)，以彈性、每月或每年承諾的方式，盡量降低成本。根據預設，在預留項目中執行的查詢會自動使用其他預留項目中的閒置運算單元。
如下圖所示，假設您購買了 1,000 個運算單元的承諾總容量，用於共用三種工作負載類型：數據科學、ELT 和商業智慧 (BI)。如要支援這些工作負載，您可以建立下列預留：
- 您可以建立具有 500 個運算單元的 ds 保留項目，並將所有Google Cloud 資料科學專案指派給該保留項目。
- 您可以建立具有 300 個運算單元的 elt 保留項目，並將用於 ELT 工作負載的專案指派給該保留項目。
- 您可以建立具有 200 個運算單元的 bi 保留項目，並將連結至 BI 工具的專案指派給該保留項目。
如下圖所示：
您可以選擇將保留項目指派給個別團隊或部門，而非將保留項目分配給貴機構的工作負載 (例如實際作業和測試)，這取決於您的用途。
詳情請參閱「使用保留項目進行工作負載管理」。
Amazon Redshift 的工作負載管理
Amazon Redshift 提供兩種工作負載管理 (WLM) 選項：
- 自動：透過自動 WLM，Amazon Redshift 可管理查詢並行作業和記憶體配置。系統會使用服務類別 ID 100 至 107 建立最多八個佇列。自動 WLM 會判斷查詢所需的資源數量，並根據工作負載調整並行數量。詳情請參閱「查詢優先順序」。
- 手動：相較之下，手動 WLM 需要您指定查詢並行處理和記憶體配置的值。手動 WLM 的預設值為五個查詢的並行作業，且記憶體會平均分配給所有五個查詢。
啟用並行調度功能後，Amazon Redshift 會在您需要處理並行讀取查詢數量增加的情況下，自動增加叢集容量。並行擴充有特定的區域和查詢考量。詳情請參閱「並行調度候選項目」。
資料集和資料表設定
BigQuery 提供多種方式來設定資料和資料表，例如分區、叢集和資料本地性。這些設定可協助您維護大型資料表，並減少查詢的整體資料負載和回應時間，進而提高資料工作負載的運作效率。
分區
分區資料表是一種特殊的資料表，表內劃分多個區段 (稱為分區)，可讓您更容易管理和查詢資料。使用者通常會將大型資料表分割成許多較小的分區，每個分區都包含一天的資料。分區管理是決定 BigQuery 在特定日期範圍內查詢效能和費用的重要因素，因為這有助於 BigQuery 在每次查詢時掃描較少的資料。
BigQuery 有三種資料表分區類型：
- 依擷取時間分區的資料表：根據資料的擷取時間分區的資料表。
- 依資料欄分區的資料表：依據
TIMESTAMP或DATE資料欄分區的資料表。 - 依整數範圍分區的資料表：根據整數資料欄分區的資料表。
以資料欄為基礎的時間分區資料表，可免除需要獨立維護分區認知，以及在已繫結資料欄上進行現有資料篩選的情況。系統會根據資料的值，將寫入以資料欄為基礎的時間分區資料表的資料自動傳送到適當的分區。同樣地，在分區資料欄中使用篩選器的查詢可以減少整體掃描資料量，進而提升按需查詢的效能並降低查詢費用。
BigQuery 的資料欄式分割功能與 Amazon Redshift 的資料欄式分割功能類似，但動機略有不同。Amazon Redshift 會使用以資料欄為基礎的鍵分布方式，盡量將相關資料儲存在相同運算節點中，最終盡可能減少在彙整和彙整期間發生的資料重新排序。BigQuery 將儲存空間與運算資源分開，因此可利用以資料欄為基礎的分區功能，盡可能減少插槽從磁碟讀取的資料量。
一旦資料分割作業讀取磁碟上的資料，BigQuery 就能自動判斷更合適的資料分割方式，並使用 BigQuery 的記憶體內排序服務快速重新分割資料。
詳情請參閱分區資料表簡介一文。
分群和排序鍵
Amazon Redshift 支援將資料表欄指定為複合或交錯排序鍵。在 BigQuery 中，您可以透過叢集資料表，指定複合排序鍵。BigQuery 叢集資料表可改善查詢效能，因為資料表資料會根據資料表結構定義中指定的最多四個資料欄內容自動排序。這些資料欄會用來將相關資料放在相同位置。您指定的分群欄位順序非常重要，因為它會決定資料的排序順序。
叢集處理可以提升某幾種查詢的效能，例如使用篩選子句的查詢，以及匯總資料的查詢。當查詢工作或載入工作將資料寫入叢集資料表時，BigQuery 會使用叢集處理資料欄裡的值自動排序資料。將資料分到 BigQuery 儲存空間中的多個區塊。若您提交的查詢含有會根據叢集處理資料欄篩選資料的子句，BigQuery 便會使用排序過的區塊，不會掃描不需要的資料。
同樣地，當您所提交的查詢會根據叢集處理資料欄中的值匯總資料時，由於排序過的區塊會將含有相似值的資料列並置於相同位置，所以效能也會提升。
請在下列情況下使用分群功能：
- 複合排序索引鍵會在 Amazon Redshift 資料表中設定。
- 您可以針對查詢中的特定資料欄設定篩選或匯總。
同時使用叢集和分區處理時，可依 date、timestamp 或整數資料欄將資料分區，然後依據另一組資料欄建立叢集 (最多可建立四個叢集資料欄)。在此情況下，各分區中的資料是根據用於建立叢集的資料欄值來建立叢集。
在 Amazon Redshift 中指定資料表中的排序鍵時，Amazon Redshift 會根據系統負載，自動使用您自己的叢集運算能力啟動排序作業。如果您想盡快完整排序表格資料 (例如在大量資料載入後)，可能需要手動執行 VACUUM 指令。BigQuery 會自動處理這項排序作業，且不會使用您已分配的 BigQuery 運算單元，因此不會影響任何查詢的效能。
如要進一步瞭解如何使用叢集資料表，請參閱叢集資料表簡介。
發布鍵
Amazon Redshift 會使用分布索引鍵，將資料區塊的位置最佳化，以便執行查詢。BigQuery 不會使用分發鍵，因為它會自動判斷並在查詢執行期間新增查詢計畫中的階段，以改善查詢工作站之間的資料分發狀況。
外部來源
如果您使用 Amazon Redshift Spectrum 查詢 Amazon S3 上的資料，同樣也可以使用 BigQuery 的外部資料來源功能，直接從 Cloud Storage 的檔案查詢資料。
除了查詢 Cloud Storage 中的資料，BigQuery 也提供聯合查詢函式，可直接查詢下列產品：
- Cloud SQL (全代管 MySQL 或 PostgreSQL)
- Bigtable (全代管 NoSQL)
- Google 雲端硬碟 (CSV、JSON、Avro、試算表)
資料本地性
您可以在地區和多地區位置建立 BigQuery 資料集，而 Amazon Redshift 只提供地區位置。BigQuery 會根據要求中參考的資料集，決定執行載入、查詢或匯出工作的位置。請參閱 BigQuery 位置考量事項，瞭解如何處理地區和多地區資料集。
BigQuery 中的資料類型對應
Amazon Redshift 資料類型與 BigQuery 資料類型不同。如要進一步瞭解 BigQuery 資料類型，請參閱官方說明文件。
BigQuery 也支援下列沒有直接 Amazon Redshift 類比的資料類型：
SQL 比較
GoogleSQL 支援 SQL 2011 標準，並提供可查詢巢狀和重複資料的擴充功能。Amazon Redshift SQL 是以 PostgreSQL 為基礎，但有幾項差異，詳情請參閱 Amazon Redshift 說明文件。如要進一步比較 Amazon Redshift 和 GoogleSQL 的語法和函式，請參閱 Amazon Redshift SQL 轉譯指南。
您可以使用批次 SQL 翻譯器，將指令碼和其他 SQL 程式碼從目前的平台轉換至 BigQuery。
遷移後
由於您遷移的腳本並非以 BigQuery 為設計考量，因此可以選擇實作 BigQuery 中可改善查詢效能的技術。詳情請參閱最佳化查詢效能簡介。
後續步驟
- 取得從 Amazon Redshift 遷移結構定義和資料的逐步操作說明。
- 取得使用 VPC 將 Amazon Redshift 遷移至 BigQuery的逐步操作說明。