從 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 值區，供轉移作業使用。檔案上傳至 Cloud Storage 後，遷移代理程式會從本機檔案系統中刪除這些檔案。
如果您未使用分區欄，就會使用全表格式做為 TPT 擷取的來源。當您使用分區資料欄的 TPT 擷取功能時，代理程式會擷取一組分區。
在這個模式中，遷移代理程式不會限制擷取的檔案在本機檔案系統中所占用的空間量。請確認本機檔案系統的空間大於最大分區或最大資料表的大小，具體取決於您是否指定分區資料欄。
使用 JDBC 驅動程式搭配 FastExport 連線進行擷取。如果可用於擷取檔案的本機儲存空間有限制，或是您無法使用 TPT，請使用這個擷取方法。
在這個模式中，遷移代理程式會將資料表擷取至本機檔案系統中的 AVRO 檔案集合。接著，系統會將這些檔案上傳至 Cloud Storage 值區，供轉移作業使用。檔案上傳至 Cloud Storage 後，遷移代理程式會從本機檔案系統中刪除這些檔案。
在這個模式中，您可以限制 AVRO 檔案在本機檔案系統中使用的空間量。如果超過這個限制，系統會暫停擷取作業，直到遷移代理程式上傳及刪除現有 AVRO 檔案，釋出空間為止。
結構定義識別
您可以透過多種方式定義結構定義。從 Teradata 將資料移轉至 BigQuery 時，BigQuery 資料移轉服務會自動偵測結構定義並進行資料類型對應。您也可以使用轉譯引擎取得資料類型對應項目，或是改為指定自訂結構定義檔案。
預設結構定義偵測
如果您未指定任何結構定義，BigQuery 資料移轉服務會自動偵測 Teradata 來源資料表的結構定義，並在資料移轉期間將資料類型對應至相應的 BigQuery 資料類型。如要進一步瞭解預設資料類型對應項目，請參閱「資料類型」。
使用結構定義的翻譯引擎輸出內容
在將 Teradata 資料表遷移至 BigQuery 的過程中，BigQuery 資料移轉服務會使用 BigQuery 轉譯引擎的輸出內容進行結構定義對應。如要使用這個選項，請確認符合下列先決條件：
- 產生翻譯的中繼資料。執行轉儲工具，產生翻譯的中繼資料，並遵循 Teradata 來源指南。詳情請參閱「產生翻譯和評估的中繼資料」。
- 將產生的中繼資料檔案 (例如
metadata.zip) 上傳至 Cloud Storage 值區。這個值區會做為翻譯引擎的輸入位置。 啟動批次轉譯工作，建立 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 值區可以位於歐盟內的europe-west1比利時區域。 - 如果您的資料集位於單一地區，則 Cloud Storage 值區也必須位於相同地區。舉例來說，如果您的資料集位於
asia-northeast1東京地區，Cloud Storage 值區就不能位於ASIA多地區。
如要進一步瞭解移轉和地區，請參閱「資料集位置和移轉」。
定價
使用 BigQuery 移轉資料不必支付費用。但使用這項服務可能必須支付其他產品 (非 Google) 的使用費用，例如平台輸出資料移轉費用。
- 擷取、上傳至 Cloud Storage 值區以及將資料載入 BigQuery 均為免費。
- 資料上傳至 BigQuery 後，系統「不會」自動將資料從 Cloud Storage 值區刪除。建議您將資料從 Cloud Storage 值區刪除，以免產生額外的儲存空間費用。請參閱 Cloud Storage 定價一文。
- 載入工作適用 BigQuery 的標準配額與限制。
- 系統會套用標準 DML BigQuery 配額與限制，處理增量攝入的更新/插入作業。
- 資料移轉至 BigQuery 之後，即適用標準的 BigQuery 儲存空間和運算計價方式。
- 詳情請參閱我們的轉移定價頁面。
限制
- 系統完全支援一次性隨選轉移作業。增量轉移作業中的 DDL/DML 作業部分支援。
- 在資料傳輸期間，系統會將資料擷取至本機檔案系統的目錄。確認裝置有足夠的可用空間。
- 使用 FastExport 模式進行擷取時，您可以設定要使用的儲存空間上限，並由遷移代理程式強制執行此限制。設定 Teradata 到 BigQuery 的轉移作業時，請在遷移代理程式設定檔中設定
max-local-storage。 - 使用 TPT 擷取方法時，請確認檔案系統有足夠的可用空間，且大於 Teradata 執行個體中最大的資料表分區。
- 使用 FastExport 模式進行擷取時，您可以設定要使用的儲存空間上限，並由遷移代理程式強制執行此限制。設定 Teradata 到 BigQuery 的轉移作業時，請在遷移代理程式設定檔中設定
- BigQuery 資料移轉服務會自動轉換結構定義 (如果您未提供自訂結構定義檔案)，並將 Teradata 資料轉移至 BigQuery。資料會從 Teradata 對應至 BigQuery 類型。
- 檔案上傳至 BigQuery 後，系統「不會」自動將檔案從 Cloud Storage 值區刪除。建議您將資料從 Cloud Storage 值區刪除，以免產生額外的儲存空間費用。請參閱「定價」一節。
- 擷取作業的速度會受到 JDBC 連線的限制。
- 從 Teradata 擷取的資料未加密。請採取適當步驟來限制對本機檔案系統中擷取檔案的存取權，並確認 Cloud Storage 值區受到妥善保護。
- 其他資料庫資源 (例如預存程序、已儲存的查詢、檢視表和使用者定義的函式) 不會轉移，也不在本服務的範圍內。
- 漸進式轉移作業不支援實刪除。增量移轉作業不會將 Teradata 中已刪除的資料列與 BigQuery 保持同步。
後續步驟
- 查看將 Teradata 遷移至 BigQuery 的逐步操作說明。
- 嘗試測試遷移 Teradata 至 BigQuery。