從 Oracle 遷移至 BigQuery
本文件提供高層次指南，說明如何從 Oracle 遷移至 BigQuery。說明基本架構差異，並建議從在 Oracle RDBMS (包括 Exadata) 上執行的資料倉儲和資料超市遷移至 BigQuery 的做法。本文件提供的詳細資料也適用於 Exadata、ExaCC 和 Oracle Autonomous Data Warehouse，因為這些產品都使用相容的 Oracle 軟體。
這份文件適用於想從 Oracle 遷移至 BigQuery，並解決遷移過程中的技術問題的企業架構師、資料庫管理員、應用程式開發人員和 IT 安全專家。
您也可以使用批次 SQL 翻譯大量遷移 SQL 指令碼，或是使用互動式 SQL 翻譯翻譯臨時查詢。兩種工具在預先發布版中均支援 Oracle SQL、PL/SQL 和 Exadata。
遷移前
為確保資料倉儲遷移作業順利進行，請在專案時間表的早期開始規劃遷移策略。如要瞭解如何有系統地規劃遷移作業，請參閱「遷移的內容和方式：遷移作業架構」。
BigQuery 容量規劃
在幕後，BigQuery 中的數據分析吞吐量是以「時段」為單位。BigQuery 運算單元是 Google 專屬的運算能力單位，執行 SQL 查詢時需要使用此單位。
BigQuery 會持續計算查詢執行時所需的運算單元數量，但會根據公平調度器將運算單元分配給查詢。
規劃 BigQuery 運算單元的容量時，您可以選擇下列任一計價模式：
以量計價：在以量計價模式下，BigQuery 會根據處理的位元組數 (資料大小) 收費，因此您只需為執行的查詢付費。如要進一步瞭解 BigQuery 如何判斷資料大小，請參閱「資料大小計算方式」一節。由於運算單元會決定基礎運算容量，您可以根據所需的運算單元數量 (而非處理的位元組數) 支付 BigQuery 使用費。根據預設， Google Cloud 專案的槽數上限為 2,000 個。
以容量為基礎的定價：採用以容量為基礎的定價時，您購買的是 BigQuery 運算單元保留空間 (至少 100 個)，而非為執行的查詢作業所處理的位元組付費。我們建議企業資料倉儲工作負載採用容量定價，因為這類工作負載通常會同時執行許多報表和擷取-載入-轉換 (ELT) 查詢，且這些查詢的使用量是可預測的。
為協助您估算時段，建議您設定使用 Cloud Monitoring 監控 BigQuery，並使用 BigQuery 分析稽核記錄。許多客戶會使用 Looker Studio (例如，請參閱 Looker Studio 資訊主頁的開放原始碼範例)、Looker 或 Tableau 做為前端，以便將 BigQuery 稽核記錄資料視覺化呈現，特別是查詢和專案的空格使用情形。您也可以利用 BigQuery 系統表資料，監控工作和預留作業的空缺使用率。如需範例，請參閱 Looker Studio 資訊主頁的開放原始碼範例。
定期監控及分析您的時段使用率，有助於您估算貴機構在 Google Cloud上成長時需要的總時段數。
舉例來說，假設您一開始預留 4,000 個 BigQuery 運算單元，以便同時執行 100 個中等複雜度的查詢。如果您發現查詢的執行計畫中等待時間過長，且資訊主頁顯示運算單元使用率偏高，這可能表示您需要額外的 BigQuery 運算單元，以便支援工作負載。如果您想透過年度或三年承諾購買運算單元，可以使用 Google Cloud 控制台或 bq 指令列工具開始使用 BigQuery 預留功能。
如對目前的方案和上述選項有任何疑問，請與業務代表聯絡。
Google Cloud的安全防護
以下各節將說明常見的 Oracle 安全控制項，以及如何確保資料倉儲在 Google Cloud環境中保持安全。
身分與存取權管理 (IAM)
Oracle 提供使用者、權限、角色和設定檔，用於管理資源存取權。
BigQuery 會使用 IAM 管理資源存取權，並提供資源和動作的集中存取權管理功能。BigQuery 提供的資源類型包括機構、專案、資料集、資料表和檢視表。在 IAM 政策階層中，資料集是專案的子項資源。資料表會繼承其所屬資料集的權限。
如要授予資源的存取權，請為使用者、群組或服務帳戶指派一或多個角色。機構和專案角色會影響執行工作或管理專案的權限，而資料集角色則會影響存取或修改專案內資料的權限。
IAM 提供以下類型的角色：
- 預先定義角色：用於支援常見用途和存取權控管模式。預先定義角色：針對特定服務提供精細的存取權限，且是由 Google Cloud管理。
基本角色包括擁有者、編輯者和檢視者角色。
自訂角色：根據使用者指定的權限清單，提供精細的存取權限。
當您同時把預先定義角色和基本角色指派給某個使用者時，您授予的權限就是這兩個角色權限的聯集。
資料列層級安全性
Oracle 標籤安全性 (OLS) 可限制逐列存取資料。列層級安全性的主要用途，是限制業務人員對所管理帳戶的存取權。實作資料列層級安全性後，您就能獲得精細的存取權控管機制。
如要在 BigQuery 中實現資料列層級安全防護機制，您可以使用授權的檢視表和資料列層級存取政策。如要進一步瞭解如何設計及實作這些政策，請參閱「BigQuery 資料列層級安全防護機制簡介」。
全磁碟加密
Oracle 提供透明資料加密 (TDE) 和網路加密功能，可用於靜態資料和傳輸中資料的加密。TDE 需要進階安全選項，須另外購買授權。
無論來源或其他條件為何，BigQuery 預設會加密所有靜態和傳輸中的資料，且無法關閉這項功能。此外，BigQuery 也支援客戶管理的加密金鑰 (CMEK)，方便使用者在 Cloud Key Management Service 中控制及管理金鑰加密金鑰。如要進一步瞭解 Google Cloud的加密方式，請參閱「預設的靜態資料加密」和「傳輸中資料加密」。
資料遮蓋和遮蓋
Oracle 在實際應用程式測試中使用資料遮罩和資料遮蓋，可讓您遮蓋 (遮蓋) 從應用程式發出的查詢所傳回的資料。
BigQuery 支援在欄位層級動態資料遮罩功能。您可以使用資料遮罩功能，為群組使用者選擇性隱藏資料欄資料，同時仍允許存取資料欄。
您可以使用機密資料保護功能，在 BigQuery 中找出並遮蓋敏感的個人識別資訊 (PII)。
BigQuery 與 Oracle 的比較
本節將說明 BigQuery 和 Oracle 之間的主要差異。這些重點可協助您找出遷移障礙，並規劃所需的變更。
系統架構
Oracle 和 BigQuery 之間的主要差異之一，在於 BigQuery 是無伺服器雲端 EDW，具有獨立的儲存和運算層，可根據查詢需求進行擴充。由於 BigQuery 無伺服器服務的特性，您不會受到硬體決策的限制；您可以透過預留作業，為查詢和使用者要求更多資源。此外，BigQuery 也不需要設定底層軟體和基礎架構，例如作業系統 (OS)、網路系統和儲存系統 (包括調整和高可用性)。BigQuery 會負責可擴充性、管理和管理作業。下圖說明 BigQuery 儲存空間階層。
瞭解基礎儲存空間和查詢處理架構 (例如儲存空間 (Colossus) 和查詢執行作業 (Dremel) 之間的差異，以及Google Cloud 如何分配資源 (Borg) 等)，有助於瞭解行為差異，並提升查詢效能和成本效益。詳情請參閱 BigQuery、Oracle 和 Exadata 的參考系統架構。
資料和儲存空間架構
資料和儲存結構是任何資料分析系統的重要部分，因為它會影響查詢效能、成本、可擴充性和效率。
BigQuery 會將資料儲存和運算分離，並將資料儲存在 Colossus 中，在 Colossus 中，資料會經過壓縮，並以名為 Capacitor 的資料欄格式儲存。
BigQuery 會使用 Capacitor，直接對壓縮資料運算，不必解壓縮。BigQuery 提供資料集做為最高層級的抽象概念，用於整理資料表的存取權，如上圖所示。結構定義和標籤可用於進一步整理資料表。BigQuery 提供分區功能，可改善查詢效能和成本，並管理資訊生命週期。儲存空間資源會在耗用時分配，並在移除資料或捨棄資料表時取消分配。
Oracle 會以行格式儲存資料，並使用Oracle 區塊格式以區段進行組織。結構定義 (由使用者擁有) 可用於整理資料表和其他資料庫物件。自 Oracle 12c 起，多租戶可用於在單一資料庫例項中建立可插拔資料庫，以便進一步隔離。分區可用於改善查詢效能和資訊生命週期作業。Oracle 為獨立和Real Application Cluster (RAC) 資料庫提供多種儲存空間選項，例如 ASM、作業系統檔案系統和叢集檔案系統。
Exadata 會在儲存體單元伺服器中提供最佳化儲存基礎架構，並讓 Oracle 伺服器透過 ASM 透明地存取這類資料。Exadata 提供混合分欄壓縮 (HCC) 選項，方便使用者壓縮資料表和分區。
Oracle 需要預先配置的儲存空間容量、謹慎的大小設定，以及區段、資料檔案和表格空間的自動遞增設定。
查詢執行和效能
BigQuery 會在查詢層級管理效能和資源配置，以便在成本範圍內盡可能提高效能。BigQuery 會使用許多最佳化功能，例如：
- 記憶體內查詢執行作業
- 以 Dremel 執行引擎為基礎的多層樹狀結構
- 在 Capacitor 中自動最佳化儲存空間
- Jupiter 的總對分頻寬為每秒 1 PB
- 自動調度資源管理功能，提供快速的 PB 規模查詢
BigQuery 會在載入資料時收集資料欄統計資料，並包含診斷查詢計劃 和時間資訊。查詢資源會根據查詢類型及複雜度分配。每個查詢都會使用一些運算單元，這些運算單元由一定數量的 CPU 與 RAM 組成。
Oracle 提供資料統計資料收集工作。資料庫最佳化器會使用統計資料提供最佳執行計畫。索引可能會用於快速查詢資料列和彙整作業。Oracle 也提供記憶體內資料欄儲存庫，可用於記憶體內分析。Exadata 提供多項效能改善功能，例如儲存格智慧掃描、儲存空間索引、快閃快取，以及儲存空間伺服器和資料庫伺服器之間的 InfiniBand 連線。Real Application Clusters (RAC) 可用於達成伺服器高可用性，並使用相同的底層儲存空間，調整需要大量 CPU 運算的資料庫應用程式。
如要使用 Oracle 最佳化查詢效能，請仔細考量這些選項和資料庫參數。Oracle 提供多種工具，例如 Active Session History (ASH)、Automatic Database Diagnostic Monitor (ADDM)、Automatic Workload Repository (AWR) 報表、SQL 監控和調整顧問，以及用於效能調整的 Undo 和記憶體調整顧問。
敏捷數據分析
在 BigQuery 中，您可以讓不同專案、使用者和群組查詢不同專案中的資料集。透過分隔查詢執行作業，自控團隊就能在專案中進行作業，而不會影響其他使用者和專案，因為系統會將其他專案和代管資料集的專案的配額和查詢計費作業分開。
高可用性、備份和災難復原
Oracle 提供 Data Guard 做為災難復原和資料庫複寫解決方案。Real Application Clusters (RAC) 可設定為提供伺服器可用性。Recovery Manager (RMAN) 備份可用於設定資料庫和封存記錄備份，也可用於還原和復原作業。資料庫回溯功能可用於資料庫回溯，將資料庫倒帶至特定時間點。撤銷表格空間保留資料表快照。您可以使用回溯查詢和「as of」查詢子句，根據先前執行的 DML/DDL 作業和復原保留設定，查詢舊的快照。在 Oracle 中，資料庫的完整完整性應在依賴系統中繼資料、取消作業和對應的資料表空間的資料表空間中管理，因為強一致性對 Oracle 備份很重要，且復原程序應包含完整的主資料。如果不需要在 Oracle 中進行時間點復原，您可以設定表格結構定義層級的匯出作業。
BigQuery 是全代管服務，其完整備份功能與傳統資料庫系統不同。您不必考量伺服器、儲存空間失敗、系統錯誤和實體資料毀損問題。BigQuery 會根據資料集位置複製不同資料中心的資料，以盡可能提高可靠性和可用性。BigQuery 多區域功能會在不同區域複製資料，並防範區域內單一區域無法使用。BigQuery 單一區域功能會在同一區域內的不同可用區複製資料。
您可以使用 BigQuery 的時間回溯功能，查詢最多七天的資料表歷史快照，並在兩天內還原已刪除的資料表。您可以使用快照語法 (dataset.table@timestamp) 複製已刪除的資料表 (以便還原資料表)。您可以匯出 BigQuery 資料表中的資料，以滿足其他備份需求，例如還原使用者意外操作的結果。您可以使用現有資料倉儲 (DWH) 系統的備份策略和時間表來備份資料。
批次作業和快照技術可讓 BigQuery 採用不同的備份策略，因此您不必經常匯出未變更的資料表和分區。載入或 ETL 作業完成後，只要備份一個分割區或表格的匯出內容即可。為降低備份成本，您可以在 Cloud Storage 的 Nearline 儲存空間或 Coldline 儲存空間中儲存匯出檔案，並根據資料保留規定，定義生命週期政策，以便在特定時間過後刪除檔案。
快取
BigQuery 提供每位使用者的快取，如果資料沒有變更，查詢結果會快取約 24 小時。如果結果是從快取中擷取，查詢作業不會產生任何費用。
Oracle 提供多種快取，用於儲存資料和查詢結果，例如緩衝快取、結果快取、Exadata Flash Cache 和記憶體內的資料欄儲存庫。
連線
BigQuery 會處理連線管理作業，您不必進行任何伺服器端設定。BigQuery 提供 JDBC 和 ODBC 驅動程式。您可以使用 Google Cloud 主控台或 bq command-line tool 進行互動式查詢。您可以使用 REST API 和 用戶端程式庫，透過程式碼與 BigQuery 互動。您可以直接連結 Google 試算表與 BigQuery，並使用 ODBC 和 JDBC 驅動程式連結至 Excel。如果您想使用電腦用戶端，可以使用 DBeaver 等免費工具。
Oracle 提供監聽器、服務、服務處理常式、多個設定和調整參數，以及共用和專用伺服器，用於處理資料庫連線。Oracle 提供 JDBC、JDBC Thin、ODBC 驅動程式、Oracle 用戶端和 TNS 連線。RAC 設定需要掃描偵聽器、掃描 IP 位址和掃描名稱。
價格和授權
Oracle 會根據資料庫版本和資料庫選項 (例如 RAC、多租戶、Active Data Guard、區隔、記憶體內、Real Application Testing、GoldenGate、Spatial 和 Graph) 的核心計數，收取授權和支援服務費用。
BigQuery 提供彈性的定價選項，可根據儲存空間、查詢和串流資料插入用量收費。BigQuery 提供以容量為準的定價，適用於需要在特定區域預測成本和運算單元容量的客戶。用於串流插入和載入的插槽不會計入專案插槽容量。如要決定要為資料倉儲購買多少個運算單元，請參閱 BigQuery 容量規劃。
此外，如果未修改的資料儲存超過 90 天，BigQuery 也會自動調降一半的儲存空間費用。
標籤
BigQuery 資料集、資料表和檢視可以使用鍵/值組合標記。標籤可用於區分儲存空間費用和內部退款。
監控和稽核記錄
Oracle 提供不同層級和類型的資料庫稽核選項，以及稽核金庫和資料庫防火牆功能，這些功能均須另外授權。Oracle 提供Enterprise Manager 來監控資料庫。
對於 BigQuery，雲端稽核記錄可用於資料存取記錄和稽核記錄，且預設為啟用。資料存取記錄可供 30 天，其他系統事件和管理員活動記錄可供 400 天。如果需要更長的保留時間，您可以按照「 Google Cloud中的安全性記錄分析」一文所述，將記錄匯出至 BigQuery、Cloud Storage 或 Pub/Sub。如果需要與現有的事件監控工具整合，可以使用 Pub/Sub 進行匯出作業，並在現有工具上進行自訂開發，以便讀取 Pub/Sub 中的記錄。
稽核記錄包含所有 API 呼叫、查詢陳述式和工作狀態。您可以使用 Cloud Monitoring 監控運算單元分配情形、查詢中掃描和儲存的位元組，以及其他 BigQuery 指標。您可以使用 BigQuery 查詢計畫和時間軸來分析查詢階段和效能。
您可以使用錯誤訊息表格來排解查詢工作和 API 錯誤。如要區分每個查詢或工作分配的時間段，您可以使用這個公用程式，這對採用容量定價且有多個專案分散在多個團隊中的客戶來說相當實用。
維護、升級和版本
BigQuery 是全代管服務，您不需要進行任何維護或升級作業。BigQuery 不提供不同版本。升級作業會持續進行，且不需要停機或降低系統效能。詳情請參閱「版本資訊」。
Oracle 和 Exadata 要求您進行資料庫和基礎架構層級的修補、升級和維護作業。Oracle 有許多版本，且每年都會推出新的主要版本。雖然新版本可回溯相容，但查詢效能、內容和功能可能會有所變更。
有些應用程式可能需要特定版本，例如 10g、11g 或 12c。進行重大資料庫升級時，請務必謹慎規劃及測試。從不同版本遷移時，可能需要在查詢子句和資料庫物件上進行不同的技術轉換。
工作負載
Oracle Exadata 支援混合工作負載，包括 OLTP 工作負載。BigQuery 是用於資料分析，並非用於處理 OLTP 工作負載。使用相同 Oracle 的 OLTP 工作負載應遷移至Google Cloud中的 Cloud SQL、Spanner 或 Firestore。Oracle 提供其他選項，例如進階分析和空間與圖表。這些工作負載可能需要重新編寫，才能遷移至 BigQuery。詳情請參閱「遷移 Oracle 選項」。
參數和設定
Oracle 提供許多參數，並要求在OS、資料庫、RAC、ASM 和Listener 層級設定和調整參數，以便支援不同的工作負載和應用程式。BigQuery 是完全代管服務，您不需要設定任何初始化參數。
限制與配額
Oracle 會根據基礎架構、硬體容量、參數、軟體版本和授權，設定硬性和軟性限制。BigQuery 針對特定動作和物件設有配額和限制。
BigQuery 配額
BigQuery 是一種平台即服務 (PaaS)，也是雲端大規模並行處理資料倉儲。由於 Google 會管理後端，因此使用者無須介入，即可調整容量。因此，與許多 RDBMS 系統不同，您不需要在使用 BigQuery 之前佈建資源。BigQuery 會根據您的使用模式，以動態方式分配儲存空間和查詢資源。儲存空間資源會在耗用時分配，並在移除資料或捨棄資料表時取消分配。查詢資源會根據查詢類型及複雜度分配。每個查詢都會使用運算單元。系統會使用最終公平性排程器，因此某些查詢可能會在短時間內分配到較高的運算單元數量，但排程器最終會修正這個問題。
在傳統 VM 的角度來看，BigQuery 提供兩者等同的功能：
- 以秒計費
- 以秒計費
為完成這項工作，BigQuery 會執行以下操作：
- 持續部署大量資源，避免需要快速擴充。
- 使用多租戶資源，一次即時分配數秒的大型區塊。
- 根據規模經濟原則，有效率地將資源分配給使用者。
- 只針對您執行的工作收費，而非部署的資源，因此您只需為使用的資源付費。
如要進一步瞭解定價方案，請參閱「瞭解 BigQuery 快速調整和簡易定價」。
結構定義遷移
如要將資料從 Oracle 遷移至 BigQuery，您必須瞭解 Oracle 資料類型和 BigQuery 對應項目。
Oracle 資料類型和 BigQuery 對應
Oracle 資料類型與 BigQuery 資料類型不同。如要進一步瞭解 BigQuery 資料類型，請參閱官方說明文件。
如需 Oracle 和 BigQuery 資料類型的詳細比較，請參閱 Oracle SQL 翻譯指南。
索引
在許多分析工作負載中，會使用資料欄表而非資料列儲存庫。這麼做可大幅增加以資料欄為基礎的作業，並可避免使用索引進行批次分析。BigQuery 也會以資料欄格式儲存資料，因此不需要在 BigQuery 中建立索引。如果分析工作負載需要單一小型資料列存取權，則 Bigtable 會是較佳的替代方案。如果工作負載需要具備強大關聯一致性的交易處理功能，Spanner 或 Cloud SQL 會是更好的替代方案。
總而言之，BigQuery 不提供批次資料分析的索引，也無需使用索引。您可以使用分區或叢集。如要進一步瞭解如何調整及改善 BigQuery 的查詢效能，請參閱最佳化查詢效能簡介。
瀏覽次數
與 Oracle 類似，BigQuery 也允許您建立自訂檢視畫面。不過，BigQuery 中的檢視表不支援 DML 陳述式。
具體化檢視表
在一次寫入、多次讀取類型的報表和工作負載中，Materialized View 通常用於縮短報表顯示時間。
Oracle 提供的物化檢視表，只需建立及維護資料表來保存查詢結果資料集，即可提高檢視表效能。在 Oracle 中，您可以透過兩種方式重新整理具體化檢視表：在提交時和按需重新整理。
BigQuery 也提供具體化檢視表功能。BigQuery 會利用具體化檢視表中的預先運算結果，並盡可能只讀取基礎資料表中的差異變更，以便計算最新結果。
Looker Studio 或其他新型態 BI 工具中的快取功能，也可以提升效能，並免除重複執行相同查詢的必要，進而節省成本。
資料表分區
資料表分區功能廣泛用於 Oracle 資料倉儲。與 Oracle 相反，BigQuery 不支援階層式分區。
BigQuery 實作三種資料表分區，可讓查詢根據分區欄指定述詞篩選條件，以減少掃描的資料量。
- 依擷取時間分區的資料表：根據資料的擷取時間分區的資料表。
- 依資料欄分區的資料表：依據
TIMESTAMP或DATE資料欄分區的資料表。 - 依整數範圍分區的資料表：根據整數資料欄分區的資料表。
如要進一步瞭解 BigQuery 中適用於分區資料表的限制和配額，請參閱分區資料表簡介。
如果 BigQuery 限制會影響已遷移資料庫的功能，請考慮使用區塊劃分，而非分割。
此外，BigQuery 不支援 EXCHANGE PARTITION、SPLIT PARTITION，也不支援將非分區資料表轉換為分區資料表。
分群
叢集功能可協助您有效率地整理及擷取儲存在經常一起存取的多個資料欄中的資料。不過，Oracle 和 BigQuery 在叢集運作最佳的情況有所不同。在 BigQuery 中，如果資料表通常會使用特定資料欄進行篩選和匯總，請使用叢集。您可以考慮將叢集處理應用於從 Oracle 遷移清單分區或索引排序的資料表。
臨時資料表
臨時表經常用於 Oracle ETL 管道。臨時資料表會在使用者工作階段期間儲存資料。這類資料會在工作階段結束時自動刪除。
BigQuery 會使用臨時資料表，擷取未寫入永久資料表的查詢結果。查詢完成後，暫時性資料表最多會保留 24 小時。系統會在特殊資料集中建立資料表，並隨機命名。您也可以建立臨時表格供自己使用。詳情請參閱「臨時資料表」。
外部資料表
與 Oracle 類似，BigQuery 可讓您查詢外部資料來源。BigQuery 支援直接從外部資料來源查詢資料，包括：
- Amazon Simple Storage Service (Amazon S3)
- Azure Blob 儲存體
- Bigtable
- Spanner
- Cloud SQL
- Cloud Storage
- Google 雲端硬碟
建立資料模型
星型或雪花狀資料模型可有效地用於分析儲存空間，通常用於 Oracle Exadata 上のデータ倉儲。
反正規化表格可避免耗時的彙整作業，且在大多數情況下，可為 BigQuery 的分析提供更佳效能。BigQuery 也支援星狀和雪花資料模型。如要進一步瞭解 BigQuery 的資料倉儲設計，請參閱「設計結構定義」。
比較資料列格式和資料欄格式，以及比較伺服器限制和無伺服器資源
Oracle 使用的是資料行格式，其中資料表列會儲存在資料區塊中，因此系統會根據特定資料欄的篩選和匯總，在區塊中擷取不必要的資料欄，以便執行分析查詢。
Oracle 採用共用一切架構，將記憶體和儲存空間等固定硬體資源依附於伺服器。這兩項是許多資料模擬技術背後的兩大力量，這些技術經過改良，可提升儲存空間效率和分析查詢效能。其中包括星型和雪花狀結構定義，以及資料金庫模擬。
BigQuery 使用資料欄式格式儲存資料，且沒有固定的儲存空間和記憶體限制。這個架構可讓您根據讀取和業務需求，進一步去除規格化並設計結構定義，進而降低複雜性，並提升彈性、可擴充性和效能。
去標準化
關聯資料庫正規化的主要目標之一，就是減少資料備援能力。雖然這個模型最適合使用資料列格式的關聯式資料庫，但資料去正規化最適合用於欄式資料庫。如要進一步瞭解在 BigQuery 中反正規化資料和其他查詢最佳化策略的優點，請參閱「反正規化」。
扁平化現有結構定義的技巧
BigQuery 技術結合了資料欄式資料存取和處理、記憶體內儲存空間和分散式處理，提供優質的查詢效能。
設計 BigQuery DWH 結構定義時，在平面資料表結構中建立事實表 (將所有維度表合併為事實表中的單一記錄)，比使用多個 DWH 維度表更能提高儲存空間利用率。除了儲存空間利用率較低之外，在 BigQuery 中使用平面資料表也會導致 JOIN 使用量減少。下圖說明如何扁平化結構定義。
星號結構定義扁平化的範例
圖 1 顯示虛構的銷售管理資料庫，其中包含四個資料表：
- 訂單/銷售表格 (事實資料表)
- 員工資料表
- 門市表
- 客戶表格
銷售資料表的主鍵是 OrderNum，其中也包含其他三個資料表的外鍵。
圖 1：星狀結構定義中的銷售資料範例
範例資料
訂單/事實表內容
| OrderNum | CustomerID | SalesPersonID | 金額 | 位置 |
| O-1 | 1234 | 12 | 234.22 | 18 |
| O-2 | 4567 | 1 | 192.10 | 27 |
| O-3 | 12 | 14.66 | 18 | |
| O-4 | 4567 | 4 | 182.00 | 26 |
員工表格內容
| SalesPersonID | FName | LName | title |
| 1 | Alex | Smith | 銷售助理 |
| 4 | Lisa | 陳 | 銷售助理 |
| 12 | John | 陳 | 銷售助理 |
客戶表格內容
| CustomerID | FName | LName |
| 1234 | Amanda | Lee |
| 4567 | Matt | Ryan |
位置表格內容
| 位置 | 城市 | 城市 | 城市 |
| 18 | Bronx | NY | 10452 |
| 26 | 山景城 | CA | 90210 |
| 27 | 芝加哥 | IL | 60613 |
使用 LEFT OUTER JOIN 查詢資料以便展開
#standardSQL INSERT INTO flattened SELECT orders.ordernum, orders.customerID, customer.fname, customer.lname, orders.salespersonID, employee.fname, employee.lname, employee.title, orders.amount, orders.location, location.city, location.state, location.zipcode FROM orders LEFT OUTER JOIN customer ON customer.customerID = orders.customerID LEFT OUTER JOIN employee ON employee.salespersonID = orders.salespersonID LEFT OUTER JOIN location ON location.locationID = orders.locationID
已扁平化資料的輸出內容
| OrderNum | CustomerID | FName | LName | SalesPersonID | FName | LName | 金額 | 位置 | 城市 | state | 郵遞區號 |
| O-1 | 1234 | Amanda | Lee | 12 | John | 陳 | 234.22 | 18 | 布朗克斯 | NY | 10452 |
| O-2 | 4567 | Matt | Ryan | 1 | Alex | Smith | 192.10 | 27 | 芝加哥 | IL | 60613 |
| O-3 | 12 | John | 陳 | 14.66 | 18 | 布朗克斯 | NY | 10452 | |||
| O-4 | 4567 | Matt | Ryan | 4 | Lisa | 陳 | 182.00 | 26 | 山 查看 |
CA | 90210 |
巢狀和重複欄位
為了從關聯式結構定義 (例如，包含維度和事實資料表的星形和雪花狀結構定義) 設計及建立 DWH 結構定義，BigQuery 會提供巢狀和重複欄位功能。因此，您可以以類似關聯式標準化 (或部分標準化) DWH 結構定義的方式保留關係，而不會影響效能。詳情請參閱效能最佳做法。
如要進一步瞭解巢狀和重複欄位的實作方式，請查看 CUSTOMERS 資料表和 ORDER/SALES 資料表的簡單關聯結構定義。這兩個資料表各自代表一個實體，關係則是使用主鍵和外鍵等鍵定義，並在使用 JOIN 進行查詢時，以資料表之間的連結做為連結。BigQuery 的巢狀和重複欄位可讓您在單一資料表中保留實體之間的相同關係。您可以透過取得所有客戶資料，並為每位客戶巢狀排列訂單資料，實現此功能。詳情請參閱「指定巢狀和重複的欄」。
如要將平面結構轉換為巢狀或重複的結構定義，請按照下列方式巢狀化欄位：
CustomerID、FName、LName已巢狀嵌入名為Customer的新欄位。SalesPersonID、FName、LName已巢狀嵌入名為Salesperson的新欄位。LocationID、city、state、zip code已巢狀嵌入名為Location的新欄位。
OrderNum 和 amount 欄位不會巢狀，因為它們代表的是獨特元素。
您希望架構有足夠的彈性，讓每筆訂單都有多位客戶：一位主要客戶和一位次要客戶。顧客欄位會標示為重複。圖 2 顯示產生的結構定義，其中說明瞭巢狀和重複的欄位。
圖 2：巢狀結構的邏輯表示
在某些情況下，使用巢狀和重複的欄位來去標準化資料並不會提升效能。如要進一步瞭解限制，請參閱「在資料表結構定義中指定巢狀和重複的欄位」一文。
代理鍵
通常會在資料表中識別具有專屬索引鍵的資料列。在 Oracle 中，序列通常用於建立這些鍵。在 BigQuery 中，您可以使用 row_number 和 partition by 函式建立代理鍵。詳情請參閱「BigQuery 和替代鍵：實用方法」。
追蹤變更和記錄
規劃 BigQuery DWH 遷移作業時，請考量緩慢變更的維度 (SCD) 概念。一般來說，SCD 一詞是指在維度資料表中進行變更 (DML 作業) 的程序。
基於多種原因，傳統資料倉儲會使用不同類型來處理資料變更，並在變動緩慢的維度中保留歷來資料。這些類型用途是為了因應先前討論的硬體限制和效率需求。由於儲存空間的費用遠低於運算費用，且可無限擴充，因此如果資料重複可加快 BigQuery 的查詢速度，我們建議您採用資料重複和重複的方式。您可以使用資料快照技術，將整份資料載入新的每日分區。
特定角色和使用者的檢視畫面
如果使用者屬於不同團隊，且只應查看所需的記錄和結果，請使用專屬角色和使用者的檢視畫面。
BigQuery 支援column-和資料列層級的安全防護機制。資料欄層級安全保護措施會透過政策標記或依類型分類的資料，為機密資料欄提供精細的存取權限。列層級安全性，可讓您篩選資料，並根據符合條件的使用者條件，啟用對資料表中特定列的存取權。
資料遷移
本節提供從 Oracle 遷移至 BigQuery 的資料遷移資訊，包括初始載入、變更資料擷取 (CDC) 和 ETL/ELT 工具與方法。
遷移活動
建議您找出適合遷移的用途，分階段執行遷移作業。您可以使用多種工具和服務，將資料從 Oracle 遷移至 Google Cloud。雖然這份清單並未列出所有項目，但確實能讓您瞭解遷移作業的規模和範圍。
從 Oracle 匯出資料：詳情請參閱「初始載入」和「從 Oracle 到 BigQuery 的 CDC 和串流攝入」。ETL 工具可用於初始載入。
資料暫存 (在 Cloud Storage 中)：Cloud Storage 是從 Oracle 匯出資料的建議到達位置 (暫存區)。Cloud Storage 可快速且彈性地擷取結構化或非結構化資料。
ETL 程序：詳情請參閱「ETL/ELT 遷移」一文。
直接將資料載入 BigQuery：您可以透過 Cloud Storage、Dataflow 或即時串流，直接將資料載入 BigQuery。如需轉換資料，請使用 Dataflow。
初始載入
將初始資料從現有的 Oracle 資料倉儲遷移至 BigQuery 的做法，可能與增量 ETL/ELT 管道不同，這取決於資料大小和網路頻寬。如果資料大小只有幾 TB，則可以使用相同的 ETL/ELT 管道。
如果資料最多只有幾 TB，傾印資料並使用 gcloud storage 進行轉移，比起使用 JdbcIO 這類程式輔助資料庫擷取方法，效率會高出許多，因為程式輔助方法可能需要更精細的效能調整。如果資料大小超過幾 TB，且資料儲存在雲端或線上儲存空間 (例如 Amazon Simple Storage Service (Amazon S3))，建議您使用 BigQuery 資料移轉服務。對於大規模傳輸作業 (尤其是網路頻寬受限的傳輸作業)，Transfer Appliance 是實用的選項。
初始載入的限制
規劃資料遷移作業時，請考量下列事項：
- Oracle DWH 資料大小：架構的來源大小會對所選資料傳輸方法造成重大影響，尤其是當資料大小很大 (TB 以上) 時。如果資料大小相對較小，資料移轉程序可以透過較少的步驟完成。處理大規模資料大小會使整體程序更加複雜。
停機時間：決定是否要為遷移至 BigQuery 保留停機時間很重要。為減少停機時間，您可以大量載入穩定的歷來資料，並使用變更資料擷取解決方案，以便在轉移程序期間追蹤變更。
價格：在某些情況下，您可能需要使用第三方整合工具 (例如 ETL 或複製工具)，而這些工具需要額外的授權。
初始資料移轉 (批次)
使用批次方法進行資料轉移，表示資料會在單一程序中一致匯出 (例如，將 Oracle DWH 結構定義資料匯出至 CSV、Avro 或 Parquet 檔案，或匯入至 Cloud Storage 以在 BigQuery 上建立資料集)。ETL/ELT 遷移一文中說明的所有 ETL 工具和概念，都可以用於初始載入作業。
如果您不想使用 ETL/ELT 工具進行初始載入作業，可以編寫自訂指令碼，將資料匯出至檔案 (CSV、Avro 或 Parquet)，然後使用 gcloud storage、BigQuery 資料移轉服務或 Transfer Appliance 將資料上傳至 Cloud Storage。如要進一步瞭解如何調整大數據移轉效能和移轉選項，請參閱「轉移大型資料集」。然後將資料從 Cloud Storage 載入 BigQuery。
Cloud Storage 非常適合處理資料的初始到達網頁。Cloud Storage 是具有高可用性和耐用性的物件儲存空間服務，不限制檔案數量，而且您只需為使用的儲存空間付費。這項服務經過最佳化處理，可與 BigQuery 和 Dataflow 等其他 Google Cloud 服務搭配使用。
從 Oracle 將 CDC 和串流內容攝入至 BigQuery
擷取 Oracle 中的變更資料的方法有很多種，每個選項都有取捨之處，主要在於對來源系統的效能影響、開發和設定需求，以及定價和授權。
記錄式變更資料擷取
Oracle GoldenGate 是 Oracle 推薦用於擷取重做記錄的工具，您可以使用 大數據專用 GoldenGate，將記錄串流至 BigQuery。GoldenGate 需要依 CPU 授權。如需價格資訊，請參閱 Oracle Technology 全球價格表。如果您已取得 Oracle GoldenGate for Big Data 的授權，可以使用 GoldenGate 建立資料管道來傳輸資料 (初始載入)，然後同步處理所有資料變更。
Oracle XStream
Oracle 會將每個提交內容儲存在重做記錄檔中，這些重做檔案可用於 CDC。Oracle XStream Out 是建構在 LogMiner 之上，由 Debezium (截至 0.8 版) 等第三方工具提供，或透過 Striim 等商業工具使用。即使未安裝及使用 GoldenGate，您仍須購買 XStream API 的 Oracle GoldenGate 授權，XStream 可讓您在 Oracle 和其他軟體之間有效地傳播 Streams 訊息。
Oracle LogMiner
LogMiner 不需要特殊授權。您可以使用 Debezium 社群連接器中的 LogMiner 選項。您也可以使用 Attunity、Striim 或 StreamSets 等商業工具，LogMiner 可能會對非常活躍的來源資料庫造成一些效能影響，因此如果變更量 (重做作業的大小) 每小時超過 10 GB，則應謹慎使用，具體取決於伺服器的 CPU、記憶體和 I/O 容量和使用率。
以 SQL 為基礎的 CDC
這是增量 ETL 方法，其中 SQL 查詢會持續輪詢來源資料表，以便根據單調遞增的鍵和保存上次修改或插入日期的時間戳記資料欄，查看是否有任何變更。如果沒有單調遞增的鍵，使用精確度較低 (秒) 的時間戳記資料欄 (修改日期) 可能會導致重複記錄或遺漏資料，這取決於資料量和比較運算子 (例如 > 或 >=)。
為解決這類問題，您可以在時間戳記欄中使用更高的精確度，例如六位小數 (微秒)，這是 BigQuery 支援的最高精確度，或者您也可以根據業務金鑰和資料特性，在 ETL/ELT 管道中新增去重任務。
索引應位於鍵或時間戳記欄，以便提升擷取效能，並減少對來源資料庫的影響。刪除作業是這項方法的一大挑戰，因為應以虛刪除方式在來源應用程式中處理，例如設定已刪除的標記和更新 last_modified_date。另一種解決方案是使用觸發條件，在另一個資料表中記錄這些作業。
觸發條件
您可以在來源資料表上建立資料庫觸發條件，將變更記錄到陰影日誌資料表。日誌資料表可保留整個資料列，以便追蹤每個資料欄的變更，或只保留主鍵和作業類型 (插入、更新或刪除)。接著，您可以使用 以 SQL 為基礎的 CDC 所述的以 SQL 為基礎方法擷取變更資料。使用觸發條件可能會影響交易效能，如果儲存完整資料列，單一資料列的 DML 作業延遲時間會加倍。只儲存主索引鍵可減少這項額外負擔，但在這種情況下，您必須在以 SQL 為基礎的擷取作業中使用原始資料表的 JOIN 運算，這會遺漏中間變更。
ETL/ELT 遷移
在 Google Cloud上處理 ETL/ELT 的方法有很多種。本文件不涵蓋特定 ETL 工作負載轉換的技術指引。您可以根據成本和時間等限制，考慮採用直接移轉方法或重新架構資料整合平台。如要進一步瞭解如何將資料管道遷移至 Google Cloud ，以及其他許多遷移概念，請參閱「遷移資料管道」。
隨即轉移方法
如果現有平台支援 BigQuery，且您想繼續使用現有的資料整合工具，請按照下列步驟操作：
- 您可以保留 ETL/ELT 平台，並在 ETL/ELT 工作中使用 BigQuery 變更必要的儲存階段。
- 如果您也想將 ETL/ELT 平台遷移至 Google Cloud ，可以詢問供應商該工具是否已取得 Google Cloud授權。如果已取得授權，您可以將該工具安裝在 Compute Engine 上，或前往 Google Cloud Marketplace 查看。
如要瞭解資料整合解決方案供應商，請參閱 BigQuery 合作夥伴。
重新架構 ETL/ELT 平台
如果您想重新架構資料管道，強烈建議您考慮使用 Google Cloud 服務。
Cloud Data Fusion
Cloud Data Fusion 是 Google Cloud 上的代管 CDAP，提供圖形介面和許多外掛程式，可用於拖曳及放置和管道開發等工作。Cloud Data Fusion 可用於擷取來自多種不同來源系統的資料，並提供批次和串流複製功能。您可以使用 Cloud Data Fusion 或 Oracle 外掛程式，擷取 Oracle 中的資料。您可以使用 BigQuery 外掛程式將資料載入 BigQuery，並處理結構定義更新作業。
在來源和接收端外掛程式上都沒有定義輸出結構定義，且在來源外掛程式中使用 select * from 來複製新資料欄。
您可以使用 Cloud Data Fusion Wrangler 功能清理及準備資料。
Dataflow
Dataflow 是無伺服器資料處理平台，可自動調整資源，並處理批次和串流資料。如果 Python 和 Java 開發人員想為資料管道編寫程式碼，並且要使用相同的程式碼處理串流和批次工作負載，那麼 Dataflow 會是理想的選擇。使用 JDBC 到 BigQuery 範本，從 Oracle 或其他關聯資料庫中擷取資料，並將資料載入至 BigQuery。
Cloud Composer
Cloud Composer 是 Google Cloud 建構於 Apache Airflow 的全代管工作流程自動化調度管理服務。讓您建立、排程及監控橫跨雲端環境和內部部署資料中心的管道。Cloud Composer 提供可執行多雲端技術的運算子和貢獻，可用於擷取和載入、ELT 轉換和 REST API 呼叫等用途。
Cloud Composer 會使用有向非循環圖 (DAG) 安排及調度工作流程。如要瞭解一般 Airflow 概念，請參閱 Airflow Apache 概念。如要進一步瞭解 DAG，請參閱「編寫 DAG (工作流程)」一文。如需 Apache Airflow 的 ETL 最佳做法範例，請參閱 Airflow 說明文件網站¶ 的 ETL 最佳做法。您可以將該範例中的 Hive 運算子替換為 BigQuery 運算子，並套用相同的概念。
以下程式碼範例是上述圖表中 DAG 範例的高階部分：
default_args = {
'owner': 'airflow',
'depends_on_past': False,
'start_date': airflow.utils.dates.days_ago(2),
'email': ['airflow@example.com'],
'email_on_failure': False,
'email_on_retry': False,
'retries': 2,
'retry_delay': timedelta(minutes=10),
}
schedule_interval = "00 01 * * *"
dag = DAG('load_db1_db2',catchup=False, default_args=default_args,
schedule_interval=schedule_interval)
tables = {
'DB1_TABLE1': {'database':'DB1', 'table_name':'TABLE1'},
'DB1_TABLE2': {'database':'DB1', 'table_name':'TABLE2'},
'DB1_TABLEN': {'database':'DB1', 'table_name':'TABLEN'},
'DB2_TABLE1': {'database':'DB2', 'table_name':'TABLE1'},
'DB2_TABLE2': {'database':'DB2', 'table_name':'TABLE2'},
'DB2_TABLEN': {'database':'DB2', 'table_name':'TABLEN'},
}
start_db1_daily_incremental_load = DummyOperator(
task_id='start_db1_daily_incremental_load', dag=dag)
start_db2_daily_incremental_load = DummyOperator(
task_id='start_db2_daily_incremental_load', dag=dag)
load_denormalized_table1 = BigQueryOperator(
task_id='load_denormalized_table1',
use_legacy_sql=False,
write_disposition='WRITE_TRUNCATE',
allow_large_results=True,
trigger_rule='all_done',
bql='''
#standardSQL
select
t1.*,tN.* except (ID)
from `ingest-project.ingest_db1.TABLE1` as t1
left join `ingest-project.ingest_db1.TABLEN` as tN on t1.ID = tN.ID
''', destination_dataset_table='datamart-project.dm1.dt1', dag=dag)
load_denormalized_table2 = BigQueryOperator(
task_id='load_denormalized_table2',
use_legacy_sql=False,
write_disposition='WRITE_TRUNCATE',
allow_large_results=True,
trigger_rule='all_done',
bql='''
#standardSQL
select
t1.*,t2.* except (ID),tN.* except (ID)
from `ingest-project.ingest_db1.TABLE1` as t1
left join `ingest-project.ingest_db2.TABLE2` as t2 on t1.ID = t2.ID
left join `ingest-project.ingest_db2.TABLEN` as tN on t2.ID = tN.ID
''', destination_dataset_table='datamart-project.dm1.dt2', dag=dag)
load_denormalized_table_all = BigQueryOperator(
task_id='load_denormalized_table_all',
use_legacy_sql=False,
write_disposition='WRITE_TRUNCATE',
allow_large_results=True,
trigger_rule='all_done',
bql='''
#standardSQL
select
t1.*,t2.* except (ID),t3.* except (ID)
from `datamart-project.dm1.dt1` as t1
left join `ingest-project.ingest_db1.TABLE2` as t2 on t1.ID = t2.ID
left join `datamart-project.dm1.dt2` as t3 on t2.ID = t3.ID
''', destination_dataset_table='datamart-project.dm1.dt_all', dag=dag)
def start_pipeline(database,table,...):
#start initial or incremental load job here
#you can write your custom operator to integrate ingestion tool
#or you can use operators available in composer instead
for table,table_attr in tables.items():
tbl=table_attr['table_name']
db=table_attr['database'])
load_start = PythonOperator(
task_id='start_load_{db}_{tbl}'.format(tbl=tbl,db=db),
python_callable=start_pipeline,
op_kwargs={'database': db,
'table':tbl},
dag=dag
)
load_monitor = HttpSensor(
task_id='load_monitor_{db}_{tbl}'.format(tbl=tbl,db=db),
http_conn_id='ingestion-tool',
endpoint='restapi-endpoint/',
request_params={},
response_check=lambda response: """{"status":"STOPPED"}""" in
response.text,
poke_interval=1,
dag=dag,
)
load_start.set_downstream(load_monitor)
if table_attr['database']=='db1':
load_start.set_upstream(start_db1_daily_incremental_load)
else:
load_start.set_upstream(start_db2_daily_incremental_load)
if table_attr['database']=='db1':
load_monitor.set_downstream(load_denormalized_table1)
else:
load_monitor.set_downstream(load_denormalized_table2)
load_denormalized_table1.set_downstream(load_denormalized_table_all)
load_denormalized_table2.set_downstream(load_denormalized_table_all)
上述程式碼僅供示範，無法直接使用。
Dataprep by Trifacta
Dataprep 是一項資料服務，可讓您透過圖表探索、清理及準備結構化與非結構化資料，以便用於分析、報表和機器學習作業。您可以將來源資料匯出至 JSON 或 CSV 檔案，使用 Dataprep 轉換資料，然後使用 Dataflow 載入資料。如需範例，請參閱「使用 Dataflow 和 Dataprep 將 Oracle 資料 (ETL) 匯入 BigQuery」。
Dataproc
Dataproc 是 Google 代管的 Hadoop 服務。您可以使用 Sqoop，將 Oracle 和許多關聯式資料庫中的資料匯出至 Cloud Storage，並以 Avro 檔案格式儲存，然後使用 bq tool 將 Avro 檔案載入至 BigQuery。在 Hadoop 上安裝 CDAP 等 ETL 工具的做法非常常見，這些工具會使用 JDBC 擷取資料，並使用 Apache Spark 或 MapReduce 轉換資料。
資料遷移合作夥伴工具
擷取、轉換及載入 (ETL) 領域中有多家供應商。ETL 市場領導者 (例如 Informatica、Talend、Matillion、Infoworks、Stitch、Fivetran 和 Striim) 已與 BigQuery 和 Oracle 深度整合，可協助擷取、轉換、載入資料，以及管理處理工作流程。
ETL 工具已存在多年，部分機構可能會發現，在信任的 ETL 指令碼中運用現有投資相當方便。BigQuery 合作夥伴網站上列出了部分主要合作夥伴解決方案。Google Cloud 內建公用程式時，您可以選擇合作夥伴工具，這取決於您目前的基礎架構，以及 IT 團隊是否熟悉以 Java 或 Python 程式碼開發資料管道。
商業智慧 (BI) 工具遷移
BigQuery 支援彈性套件，提供可用於報表和分析的商業智慧 (BI) 解決方案。如要進一步瞭解 BI 工具遷移和 BigQuery 整合，請參閱「BigQuery 資料分析功能總覽」。
查詢 (SQL) 翻譯
BigQuery 的 GoogleSQL 支援 SQL 2011 標準，並提供可查詢巢狀和重複資料的擴充功能。所有符合 ANSI 標準的 SQL 函式和運算子都可以使用，只需稍加修改即可。如要進一步瞭解 Oracle 和 BigQuery SQL 語法與函式的差異，請參閱 Oracle 到 BigQuery SQL 翻譯參考資料。
使用批次 SQL 翻譯大量遷移 SQL 程式碼，或使用互動式 SQL 翻譯翻譯臨時查詢。
遷移 Oracle 選項
本節提供架構建議和參考資料，協助您轉換使用 Oracle Data Mining、R 和空間和圖形功能的應用程式。
Oracle Advanced Analytics 選項
Oracle 提供資料探勘、基本機器學習 (ML) 演算法和 R 使用方式的進階分析選項。進階數據分析選項需要授權。您可以根據從開發到大規模生產的不同需求，從 Google AI/ML 產品完整清單中選擇合適的產品。
Oracle R Enterprise
Oracle R Enterprise (ORE) 是 Oracle Advanced Analytics 選項的元件，可將開放原始碼 R 統計程式設計語言與 Oracle 資料庫整合。在標準 ORE 部署作業中，R 會安裝在 Oracle 伺服器上。
如果資料規模非常龐大，或採用倉儲方法，建議您將 R 與 BigQuery 整合，您可以使用開放原始碼 bigrquery R 程式庫，將 R 與 BigQuery 整合。
Google 與 RStudio 合作，讓使用者可以使用該領域的尖端工具。您可以使用 RStudio 存取 TensorFlow 中 BigQuery 模型的 TB 規模資料，並透過 AI 平台大規模執行機器學習模型。在 Google Cloud中，您可以大規模在 Compute Engine 上安裝 R。
Oracle Data Mining
Oracle Data Mining (ODM) 是 Oracle Advanced Analytics 選項的組件，可讓開發人員在 Oracle 上使用 Oracle PL/SQL Developer 建立機器學習模型。
BigQuery ML 可讓開發人員執行多種不同類型的模型，例如線性迴歸、二元邏輯迴歸、多類別邏輯迴歸、k-means 群組和 TensorFlow 模型匯入作業。詳情請參閱「BigQuery ML 簡介」。
轉換 ODM 工作可能需要重寫程式碼。您可以選擇 Google AI 產品，例如 BigQuery ML、AI API (Speech-to-Text、Text-to-Speech、Dialogflow、Cloud Translation、Cloud Natural Language API、Cloud Vision、Timeseries Insights API 等) 或 Vertex AI。
Vertex AI Workbench 可做為數據科學家的開發環境，而 Vertex AI Training 可用於大規模執行訓練和評分工作負載。
空間和圖表選項
Oracle 提供「空間和圖表」選項，可用於查詢幾何圖形和圖表，但必須取得此選項的授權。您可以使用 BigQuery 中的幾何函式，不必額外支付費用或取得授權，也可以在 Google Cloud中使用其他圖表資料庫。
空間
BigQuery 提供地理空間分析函式和資料類型。詳情請參閱「使用 地理空間分析資料」。Oracle Spatial 資料類型和函式可轉換為 地理 BigQuery 標準 SQL 中的函式。地理位置函式不會在標準 BigQuery 定價之上加收費用。
圖表
JanusGraph 是開放原始碼圖形資料庫解決方案，可使用 Bigtable 做為儲存空間後端。如需更多資訊，請參閱「在 GKE 上使用 Bigtable 執行 JanusGraph」。
Neo4j 是另一個圖形資料庫解決方案，以在 Google Kubernetes Engine (GKE) 上執行的 Google Cloud 服務形式提供。
Oracle Application Express
Oracle Application Express (APEX) 應用程式是 Oracle 專屬，因此需要重新編寫。您可以使用 Looker Studio 或 BI 引擎開發報表和資料視覺化功能，而應用程式層級功能 (例如建立及編輯資料列) 則可在 AppSheet 上使用 Cloud SQL 開發，無需編寫程式碼。
後續步驟
- 瞭解如何最佳化工作負載，以便整體提升效能並降低成本。
- 瞭解如何在 BigQuery 中最佳化儲存空間。
- 如需 BigQuery 更新資訊，請參閱版本資訊。
- 參閱 Oracle SQL 翻譯指南。