從 Teradata 遷移至 BigQuery - 總覽
本文提供更多資訊，協助您瞭解使用 BigQuery 資料移轉服務將結構定義和資料從 Teradata 遷移至 BigQuery 時，需要做出的決策。如要瞭解 Teradata 遷移程序簡介，請參閱「從 Teradata 遷移至 BigQuery 簡介」。
從其他平台將資料倉儲遷移至 BigQuery 時，通常需要執行多個步驟，遷移結構定義和資料就是其中之一。如要瞭解一般遷移程序，請參閱「總覽：將資料倉儲遷移至 BigQuery」。
您也可以使用批次 SQL 翻譯大量遷移 SQL 指令碼，或使用互動式 SQL 翻譯翻譯臨時查詢。SQL 翻譯服務完全支援 Teradata SQL。
總覽
您可以搭配使用 BigQuery 資料移轉服務和特殊的遷移代理程式，將結構定義和資料從 Teradata 複製到 BigQuery。遷移代理程式會連線至本機資料倉儲，並與 BigQuery 資料移轉服務通訊，以便將資料倉儲中的資料表複製到 BigQuery。
以下步驟說明遷移程序的流程：
- 下載遷移代理程式。
- 在 BigQuery 資料移轉服務中設定轉移作業。
- 執行移轉工作，將資料倉儲中的資料表結構定義和資料複製到 BigQuery。
- (選用步驟) 使用 Google Cloud 控制台監控轉移工作。
轉移工作設定
您可以視需求設定移轉工作。設定從 Teradata 到 BigQuery 的資料移轉作業前，請先考量下列章節所述的設定選項，然後決定要使用的設定。視您選擇的設定而定，您可能需要先完成一些先決條件，才能開始轉移作業。
對於大多數系統 (尤其是含有大型資料表的系統)，請按照下列步驟操作，以獲得最佳效能：
- 分割 Teradata 資料表。
- 使用 Teradata Parallel Transporter (TPT) 進行擷取。
- 建立自訂結構定義檔案，並設定目標 BigQuery 叢集和分割欄。
這可讓遷移代理程式逐一擷取分割區，這是最有效率的做法。
擷取方法
BigQuery 資料移轉服務支援兩種擷取方法，可將資料從 Teradata 移轉至 BigQuery：
使用 Teradata Parallel Transporter (TPT) tbuild 公用程式。這是我們建議的做法。使用 TPT 通常可加快資料擷取速度。
在這個模式下，遷移代理程式會嘗試使用按分區分配的資料列，計算擷取批次。代理程式會針對每個批次發出並執行 TPT 擷取指令碼，產生一組以管道分隔的檔案。接著，這些檔案會上傳至 Cloud Storage bucket，供轉移作業使用。檔案上傳至 Cloud Storage 後，遷移代理程式會從本機檔案系統中刪除這些檔案。
如果使用 TPT 擷取功能時沒有分區資料欄，系統會擷取整個資料表。使用 TPT 擷取功能搭配分區資料欄時，代理程式會擷取分區集。
在這個模式下，遷移代理程式不會限制擷取檔案在本機檔案系統中占用的空間大小。請確認本機檔案系統的空間大於最大磁碟分割區或最大資料表的大小，視您是否指定分區資料欄而定。
使用 JDBC 驅動程式和 FastExport 連線擷取資料。 如果可供擷取檔案的本機儲存空間有限，或因故無法使用 TPT，請採用這種擷取方法。
在此模式下，遷移代理程式會將資料表擷取到本機檔案系統中的 AVRO 檔案集合。接著，這些檔案會上傳至 Cloud Storage bucket，供轉移作業使用。檔案上傳至 Cloud Storage 後，遷移代理程式會從本機檔案系統刪除這些檔案。
在此模式下，您可以限制本機檔案系統中 AVRO 檔案使用的空間量。如果超過這個上限，系統會暫停擷取作業，直到遷移代理程式上傳並刪除現有的 AVRO 檔案，釋出空間為止。
結構定義識別
您可以透過多種方式定義結構定義。從 Teradata 移轉資料至 BigQuery 時，BigQuery 資料移轉服務會自動偵測結構定義並對應資料型別。您也可以使用轉譯引擎取得資料型別對應，或選擇改為指定自訂結構定義檔案。
預設結構定義偵測
如果未指定任何結構定義設定，BigQuery 資料移轉服務會在資料移轉期間，自動偵測 Teradata 來源資料表的結構定義，並將資料類型對應至相應的 BigQuery 資料類型。如要進一步瞭解預設資料類型對應，請參閱「資料類型」。
使用翻譯引擎輸出內容做為結構定義
將 Teradata 資料表遷移至 BigQuery 時，BigQuery 資料移轉服務會使用 BigQuery 翻譯引擎的輸出內容進行結構定義對應。如要使用這個選項，請確認符合下列先決條件：
- 產生翻譯的中繼資料。執行傾印工具，按照 Teradata 來源指南產生翻譯中繼資料。詳情請參閱「產生翻譯和評估用的中繼資料」。
- 將產生的中繼資料檔案 (例如
metadata.zip) 上傳至 Cloud Storage bucket。這個 bucket 會做為翻譯引擎的輸入位置。 啟動批次翻譯工作，建立 BigQuery 資料移轉服務對應，定義目標 BigQuery 資料表的結構定義。如要瞭解如何執行這項操作，請參閱「建立批次翻譯」。下列範例會指定
target_types = "dts_mapping"，產生 BigQuery 資料移轉服務對應：curl -d "{ \"name\": \"teradata_2_bq_translation\", \"displayName\": \"Teradata to BigQuery Translation\", \"tasks\": { string: { \"type\": \"Teradata2BigQuery_Translation\", \"translation_details\": { \"target_base_uri\": \"gs://your_translation_output_bucket/output\", \"source_target_mapping\": { \"source_spec\": { \"base_uri\": \"gs://your_metadata_bucket/input\" } }, \"target_types\": \"metadata\", } } }, }" \ -H "Content-Type:application/json" \ -H "Authorization: Bearer YOUR_ACCESS_TOKEN" -X POST https://bigquerymigration.googleapis.com/v2alpha/projects/your_project_id/locations/your_location/workflows如要查看批次翻譯工作的狀態，請前往 Google Cloud 控制台，依序點選「BigQuery」->「SQL 翻譯」。完成後，對應檔會儲存在
target_base_uri標記中指定的 Cloud Storage 位置。如要產生權杖，請使用
gcloud auth print-access-token指令或 OAuth 2.0 Playground，並指定https://www.googleapis.com/auth/cloud-platform範圍。在 Teradata 資料轉移設定中，指定儲存上一個步驟中對應檔案的 Cloud Storage 資料夾路徑。BigQuery 資料移轉服務會使用這個對應關係，定義目標 BigQuery 資料表的結構。
自訂結構定義檔案
建議在下列情況下指定自訂結構化資料：
如果您需要擷取表格的重要資訊 (例如分割)，否則這些資訊會在遷移作業中遺失。
舉例來說，增量移轉應指定結構定義檔案，以便將後續移轉作業的資料載入 BigQuery 時，正確地進行分區。如果沒有結構定義檔案，BigQuery 資料移轉服務每次執行移轉作業時，都會使用要移轉的來源資料自動套用資料表結構定義，且所有有關資料分割、叢集、主鍵和變更追蹤的資訊都會遺失。
在資料移轉期間，如需變更資料欄名稱或資料類型。
自訂結構定義檔是描述資料庫物件的 JSON 檔案。結構定義包含一組資料庫，每個資料庫都包含一組資料表，每個資料表又包含一組資料欄。每個物件都有 originalName 欄位，指出 Teradata 中的物件名稱，以及 name 欄位，指出 BigQuery 中的物件目標名稱。
資料欄具有下列欄位：
originalType：表示 Teradata 中的資料欄資料類型type：指出 BigQuery 中資料欄的目標資料類型。usageType：系統使用資料欄的方式相關資訊。支援的用量類型如下：DEFAULT：您可以在一個目標資料表中，使用這個用途類型為多個資料欄加上註解。這個usageType表示資料欄在來源系統中沒有特殊用途。這是預設值。CLUSTERING：您可以在每個目標資料表中，為最多四個資料欄加上這個使用類型註解。分群的資料欄順序取決於自訂結構定義中的資料欄順序。所選資料欄必須符合 BigQuery 叢集作業的限制。如果為同一個資料表指定PARTITIONING欄位，BigQuery 會使用這些資料欄建立叢集資料表。PARTITIONING：每個目標資料表只能使用這個用途類型標註一個資料欄。這個資料欄用於包含tables物件的分區資料表定義。只有TIMESTAMP或DATE資料類型的資料欄才能使用這個用途類型。COMMIT_TIMESTAMP：每個目標資料表只能使用這個用途類型標註一個資料欄。使用這個usageType找出增量更新的更新時間戳記欄。這個資料欄用於擷取自上次移轉作業後建立或更新的資料列。您只能將這個用途類型用於具有TIMESTAMP或DATE資料類型的資料欄。PRIMARY_KEY：您可以使用這個用途類型，為每個目標資料表中的資料欄加上註解。使用這個用途類型將單一資料欄識別為主鍵，或是針對複合鍵，在多個資料欄上使用相同的用途類型，識別資料表的不重複實體。這些資料欄會與COMMIT_TIMESTAMP搭配運作，擷取自上次移轉作業後建立或更新的資料列。
您可以手動建立自訂結構定義檔案 (如下例所示)，也可以在初始化代理程式時，讓遷移代理程式為您產生檔案。
在這個範例中，使用者要遷移 tpch 資料庫中名為 orders 的 Teradata 資料表，該資料表的定義如下：
CREATE SET TABLE TPCH.orders ,FALLBACK ,
NO BEFORE JOURNAL,
NO AFTER JOURNAL,
CHECKSUM = DEFAULT,
DEFAULT MERGEBLOCKRATIO,
MAP = TD_MAP1
(
O_ORDERKEY INTEGER NOT NULL,
O_CUSTKEY INTEGER NOT NULL,
O_ORDERSTATUS CHAR(1) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_TOTALPRICE DECIMAL(15,2) NOT NULL,
O_ORDERDATE DATE FORMAT 'yyyy-mm-dd' NOT NULL,
O_ORDERPRIORITY CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_CLERK CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_SHIPPRIORITY INTEGER NOT NULL,
O_COMMENT VARCHAR(79) CHARACTER SET LATIN CASESPECIFIC NOT NULL)
UNIQUE PRIMARY INDEX ( O_ORDERKEY );
遷移至 BigQuery 時，使用者希望設定結構定義，並進行下列變更：
- 將
O_CUSTKEY欄重新命名為O_CUSTOMERKEY - 將「
O_ORDERDATE」設為分區欄
以下範例為自訂結構定義，可設定這些設定：
{
"databases": [
{
"name": "tpch",
"originalName": "e2e_db",
"tables": [
{
"name": "orders",
"originalName": "orders",
"columns": [
{
"name": "O_ORDERKEY",
"originalName": "O_ORDERKEY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_CUSTOMERKEY",
"originalName": "O_CUSTKEY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_ORDERSTATUS",
"originalName": "O_ORDERSTATUS",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 1
},
{
"name": "O_TOTALPRICE",
"originalName": "O_TOTALPRICE",
"type": "NUMERIC",
"originalType": "decimal",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 8
},
{
"name": "O_ORDERDATE",
"originalName": "O_ORDERDATE",
"type": "DATE",
"originalType": "date",
"usageType": [
"PARTITIONING"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_ORDERPRIORITY",
"originalName": "O_ORDERPRIORITY",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 15
},
{
"name": "O_CLERK",
"originalName": "O_CLERK",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 15
},
{
"name": "O_SHIPPRIORITY",
"originalName": "O_SHIPPRIORITY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_COMMENT",
"originalName": "O_COMMENT",
"type": "STRING",
"originalType": "varchar",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 79
}
]
}
]
}
]
}
隨選或增量移轉
從 Teradata 資料庫執行個體遷移資料至 BigQuery 時，BigQuery 資料移轉服務支援完整移轉 (隨選移轉) 和週期性移轉 (增量移轉)。設定轉移作業時，您可以在排程選項中將轉移作業指定為隨選或增量。
隨選移轉：使用這個模式，將結構定義和資料從 Teradata 完整快照移轉至 BigQuery。
排定時間移轉：使用這個模式執行完整快照，並定期將新的和修改過的資料 (增量資料) 從 Teradata 遷移至 BigQuery。如要進行增量轉移，必須自訂結構定義，並使用下列任一用途註解欄：
- 只使用
COMMIT_TIMESTAMP用量類型註解資料欄：在此移轉中，Teradata 中新增或修改的資料列會附加至 BigQuery 中的資料。BigQuery 資料表中的更新資料列可能會有重複的資料列，包含舊值和新值。 - 使用
COMMIT_TIMESTAMP和PRIMARY_KEY用途類型註解資料欄：在此移轉作業中，系統會附加新資料列，並將修改過的資料列更新至 BigQuery 中的對應資料列。PRIMARY_KEY中定義的資料欄用於維護 BigQuery 中資料的唯一性。 - 結構定義中定義的
PRIMARY_KEY欄不一定要是 Teradata 資料表中的PRIMARY_KEY。可以是任何資料欄，但必須包含不重複的資料。
- 只使用
增量轉移
在增量移轉中，第一次移轉一律會在 BigQuery 中建立資料表快照。後續所有增量移轉作業都會遵循自訂結構定義檔案中定義的註解，詳情請參閱下文。
系統會儲存每次移轉作業的時間戳記。在後續的每次移轉作業中，代理程式都會收到前一次移轉作業的時間戳記 (T1)，以及目前移轉作業的開始時間戳記 (T2)。
初次執行後，遷移代理程式會使用下列每個資料表的邏輯來擷取資料：
- 如果結構定義檔案中的資料表物件沒有使用類型為
COMMIT_TIMESTAMP的資料欄，系統就會略過該資料表。 - 如果資料表有使用類型為
COMMIT_TIMESTAMP的資料欄，系統會擷取時間戳記介於 T1 和 T2 之間的所有資料列，並附加至 BigQuery 中的現有資料表。 - 如果表格有使用類型為
COMMIT_TIMESTAMP的資料欄，以及使用類型為PRIMARY_KEY的資料欄，系統就會擷取時間戳記介於 T1 和 T2 之間的所有資料列。系統會將所有新列附加至 BigQuery 中的現有資料表，並更新修改過的列。
以下是增量轉移的結構定義檔案範例。
僅含 COMMIT_TIMESTAMP 的結構定義
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"DEFAULT"
],
"isRequired": true
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
結構定義包含 COMMIT_TIMESTAMP 和一個資料欄 (Id)，如 PRIMARY_KEY 所示
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": true
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
結構定義，其中 COMMIT_TIMESTAMP 和複合鍵 (ID + 名稱) 為 PRIMARY_KEY
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": true
},
{
"name": "Name",
"originalName": "Name",
"type": "STRING",
"originalType": "character",
"originalColumnLength": 30,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": false
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
下表說明遷移代理程式在增量轉移中，如何處理資料定義語言 (DDL) 和資料操縱語言 (DML) 作業。
| Teradata 作業 | 類型 | 從 Teradata 遷移至 BigQuery 的支援 |
|---|---|---|
CREATE |
DDL | BigQuery 會為資料表建立新的完整快照。 |
DROP |
DDL | 不支援 |
ALTER (RENAME) |
DDL | BigQuery 會為重新命名的資料表建立新的完整快照。先前的快照不會從 BigQuery 刪除。使用者不會收到資料表重新命名的通知。 |
INSERT |
DML | 系統會在 BigQuery 資料表中新增資料列。 |
UPDATE |
DML | 如果只使用 COMMIT_TIMESTAMP，系統會將資料列附加至 BigQuery 資料表，與 INSERT 作業類似。如果同時使用 COMMIT_TIMESTAMP 和 PRIMARY_KEY，系統會更新資料列，類似於 UPDATE 作業。 |
MERGE |
DML | 不支援。請改用 INSERT、UPDATE 和 DELETE。 |
DELETE |
DML | 不支援 |
位置注意事項
Cloud Storage 值區必須位於與 BigQuery 中目的地資料集相容的地區或多地區。
- 如果 BigQuery 資料集位於多地區，則包含要轉移資料的 Cloud Storage 值區必須位於相同多地區，或位於多地區內的位置。舉例來說，如果您的 BigQuery 資料集位於
EU多區域，Cloud Storage bucket 可以位於歐盟境內的europe-west1比利時區域。 - 如果資料集位於單一地區，Cloud Storage 值區就必須位於相同地區。舉例來說，如果您的資料集位於
asia-northeast1東京地區，Cloud Storage 值區就不能位於ASIA多地區。
如要進一步瞭解移轉作業和地區，請參閱「資料集位置和移轉作業」。
定價
使用 BigQuery 移轉資料不必支付費用。不過，使用這項服務可能必須支付其他產品 (非 Google) 的使用費用，例如平台輸出資料移轉費用。
- 擷取、上傳至 Cloud Storage 值區以及將資料載入 BigQuery 均為免費。
- 資料上傳至 BigQuery 後，系統「不」會自動將資料從 Cloud Storage 值區刪除。建議您將資料從 Cloud Storage 值區刪除，以免產生額外的儲存空間費用。請參閱 Cloud Storage 定價一文。
- 載入工作適用標準 BigQuery 配額與限制。
- 標準 DML BigQuery 配額與限制適用於遞增擷取 upsert。
- 資料移轉至 BigQuery 之後，即適用標準的 BigQuery 儲存空間和運算計價方式。
- 詳情請參閱我們的轉移定價頁面。
限制
- 系統完全支援一次性隨選轉移作業。 增量轉移中的 DDL/DML 作業部分支援。
- 資料轉移期間，系統會將資料擷取至本機檔案系統的目錄。確認有足夠的可用空間。
- 使用 FastExport 模式擷取資料時，您可以設定要使用的儲存空間上限，遷移代理程式會嚴格執行這項限制。設定從 Teradata 遷移至 BigQuery 的轉移作業時，請在遷移代理程式的設定檔中設定
max-local-storage。 - 使用 TPT 擷取方法時，請確保檔案系統有足夠的可用空間，大於 Teradata 執行個體中最大的資料表分割區。
- 使用 FastExport 模式擷取資料時，您可以設定要使用的儲存空間上限，遷移代理程式會嚴格執行這項限制。設定從 Teradata 遷移至 BigQuery 的轉移作業時，請在遷移代理程式的設定檔中設定
- BigQuery 資料移轉服務會自動轉換結構定義 (如果您未提供自訂結構定義檔案)，並將 Teradata 資料移轉至 BigQuery。資料會從 Teradata 對應至 BigQuery 類型。
- 檔案載入 BigQuery 後，系統「不」會自動將檔案從 Cloud Storage 值區刪除。將資料載入 BigQuery 後，建議您將資料從 Cloud Storage 值區刪除，以免產生額外的儲存空間費用。請參閱定價。
- 擷取作業的速度會受到 JDBC 連線的限制。
- 從 Teradata 擷取的資料未加密。請採取適當步驟來限制對本機檔案系統中擷取檔案的存取權，並確認 Cloud Storage 值區受到妥善保護。
- 預存程序、已儲存的查詢、檢視表和使用者定義的函式等其他資料庫資源不會轉移，也不屬於這項服務的範圍。
- 增量轉移不支援實刪除。增量移轉不會將 Teradata 中任何已刪除的資料列同步至 BigQuery。
後續步驟
- 取得將 Teradata 遷移至 BigQuery 的逐步操作說明。
- 試試從 Teradata 測試遷移至 BigQuery。