Snowflake 的結構定義偵測和對應
本指南說明從 Snowflake 轉移資料至 BigQuery 時,如何定義結構定義。您可以使用 BigQuery 資料移轉服務自動偵測結構定義和資料類型對應,也可以使用轉譯引擎手動定義結構定義和資料類型。
啟用自動預設結構定義偵測功能
Snowflake 連接器可自動偵測 Snowflake 資料表結構定義。如要使用自動結構定義偵測功能,請在設定 Snowflake 轉移作業時,將「翻譯輸出內容 GCS 路徑」欄位留空。
下表顯示 Snowflake 連接器如何將 Snowflake 資料類型對應至 BigQuery:
- 下列資料類型會在 BigQuery 中對應為
STRING:TIMESTAMP_TZTIMESTAMP_LTZOBJECTVARIANTARRAY
- 下列資料類型會在 BigQuery 中對應為
TIMESTAMP:TIMESTAMP_NTZ
所有其他 Snowflake 資料類型都會直接對應至 BigQuery 中的對等類型。
使用翻譯引擎輸出內容手動定義結構定義
將 Snowflake 資料表遷移至 BigQuery 時,Snowflake 連接器的 BigQuery 資料移轉服務會使用 BigQuery 遷移服務翻譯引擎進行結構定義對應。
如要手動定義結構定義 (例如覆寫特定結構定義屬性),您可以產生中繼資料,然後執行翻譯引擎。
限制
系統會先以 Parquet 資料格式從 Snowflake 擷取資料,再載入至 BigQuery:
- 系統不支援下列 Parquet 資料類型:
TIMESTAMP_TZ、TIMESTAMP_LTZ- 詳情請參閱「評估 Snowflake 資料」。
系統不支援下列 Parquet 資料類型,但可以轉換:
TIMESTAMP_NTZOBJECT、VARIANT、ARRAY
執行翻譯引擎時,請使用全域類型轉換設定 YAML 覆寫這些資料類型的預設行為。
設定 YAML 可能類似下列範例:
type: experimental_object_rewriter global: typeConvert: datetime: TIMESTAMP json: VARCHAR
- 系統不支援下列 Parquet 資料類型:
必要服務帳戶權限
在 Snowflake 移轉中,服務帳戶會用於從指定 Cloud Storage 路徑中的翻譯引擎輸出內容讀取資料。您必須授予服務帳戶 storage.objects.get 和 storage.objects.list 權限。
建議服務帳戶與建立移轉設定和目的地資料集的 Cloud de Confiance by S3NS 專案 屬於同一個專案。如果服務帳戶位於 Cloud de Confiance by S3NS 的專案與建立 BigQuery 資料移轉的專案不同,則必須啟用跨專案服務帳戶授權。
詳情請參閱「BigQuery IAM 角色和權限」。
手動定義結構定義對應
您可以按照下列步驟手動定義結構定義對應:
- 為 Snowflake 執行
dwh-migration-tool。詳情請參閱「產生翻譯和評估用的中繼資料」。 - 將產生的
metadata.zip檔案上傳至 Cloud Storage bucket。翻譯引擎會將metadata.zip檔案做為輸入內容。 執行批次翻譯服務,並將
target_types欄位指定為metadata。詳情請參閱「使用 Translation API 翻譯 SQL 查詢」。- 以下是為 Snowflake 執行批次翻譯的指令範例:
curl -d "{ \"name\": \"sf_2_bq_translation\", \"displayName\": \"Snowflake to BigQuery Translation\", \"tasks\": { string: { \"type\": \"Snowflake2BigQuery_Translation\", \"translation_details\": { \"target_base_uri\": \"gs://sf_test_translation/output\", \"source_target_mapping\": { \"source_spec\": { \"base_uri\": \"gs://sf_test_translation/input\" } }, \"target_types\": \"metadata\", } } }, }" \ -H "Content-Type:application/json" \ -H "Authorization: Bearer TOKEN" -X POST https://bigquerymigration.googleapis.com/v2alpha/projects/project_id/locations/location/workflows- 您可以在 BigQuery 的 SQL 翻譯頁面中查看這項指令的狀態。
批次翻譯工作的輸出內容會儲存在
gs://translation_target_base_uri/metadata/config/中。
自訂結構定義檔案
建議您指定自訂結構定義,以便擷取資料表的重要資訊 (例如主鍵),否則這些資訊可能會在遷移過程中遺失。舉例來說,進行增量移轉時,建議您指定自訂結構定義檔案,這樣後續移轉的資料載入 BigQuery 時,就能正確分割。如果沒有結構定義檔案,BigQuery 資料移轉服務會使用要轉移的來源資料自動套用資料表結構定義,因此主鍵和變更追蹤的所有資訊可能會遺失。
如果必須在資料轉移期間變更資料欄名稱或資料類型,自訂結構定義也很有幫助。
自訂結構定義檔是描述資料庫物件的 JSON 檔案。結構定義包含一組資料庫,每個資料庫都包含一組資料表,每個資料表又包含一組資料欄。每個物件都有 originalName 欄位,指出 Snowflake 中的物件名稱,以及 name 欄位,指出 BigQuery 中的物件目標名稱。
資料欄具有下列欄位:
originalType:表示 Snowflake 中的資料欄資料類型type:指出 BigQuery 中資料欄的目標資料類型。usageType:系統使用資料欄的方式相關資訊。支援的用量類型如下:DEFAULT:您可以在一個目標資料表中,使用這個用途類型註解多個資料欄。DEFAULT用途類型表示資料欄在來源系統中沒有特殊用途。這是預設值。PRIMARY_KEY:您可以使用這個用途類型,為每個目標資料表中的資料欄加上註解。使用PRIMARY_KEY用途類型將單一資料欄識別為主鍵,如果是複合鍵,則在多個資料欄上使用相同用途類型,識別資料表的不重複實體。這些資料欄會與COMMIT_TIMESTAMP搭配運作,擷取自上次移轉作業後建立或更新的資料列。
以下範例顯示自訂結構定義檔案,可將 my_db 資料庫中名為 orders 的 Snowflake 資料表移轉至 BigQuery,並將 O_ORDERKEY 資料欄重新命名為 ORDERKEY,以及將 O_ORDERSTATUS 識別為主鍵。
{ "databases": [ { "name": "my_db", "originalName": "my_db", "tables": [ { "name": "orders", "originalName": "orders", "columns": [ { "name": "ORDERKEY", "originalName": "O_ORDERKEY", "type": "INT64", "originalType": "NUMERIC", "usageType": [ "PRIMARY_KEY" ], "isRequired": true, "originalColumnLength": 4 }, { "name": "O_ORDERSTATUS", "originalName": "O_ORDERSTATUS", "type": "STRING", "originalType": "VARCHAR", "usageType": [ "DEFAULT" ], "isRequired": true, "originalColumnLength": 1 } ] } ] } ] }