共用方式為

Teradata 移轉的資料移轉、ETL 和負載

  • 發行項

本文章是七部分系列的第二部分，提供如何從 Teradata 移轉至 Azure Synapse Analytics 的指引。 本文重點為 ETL 和載入移轉的最佳做法。

資料移轉考量

從 Teradata 移轉資料的最初決策

移轉 Teradata 資料倉儲時，您需要詢問一些資料相關的基本問題。 例如：

  • 是否應該移轉未使用的資料表結構？

  • 將風險和使用者影響降至最低的最佳移轉方法為何？

  • 移轉資料超市時：維持實體或轉成擬？

下一節將討論從 Teradata 移轉的內容中的這些點。

移轉未使用的資料表？

提示

在舊版系統中，資料表在一段時間後變得多餘並不少見，大部分情況下這些並不需要進行移轉。

只移轉現有系統中正在使用的資料表為合理的做法。 未作用中的資料表可以進行封存，而不是移轉，如此一來未來需要時才能使用資料。 最好使用系統中繼資料和記錄檔案，而不是文件來判斷使用中的資料表為何，因為文件可能已過期。

如果啟用，Teradata 系統目錄資料表和記錄會包含可判斷指定資料表上次存取時間的資訊，進而用來決定資料表是否為移轉的候選項目。

以下是一個查詢 DBC.Tables 的範例，提供上次存取和上次修改的日期：

SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName,
LastAlterTimeStamp, AccessCount, LastAccessTimeStamp 
FROM DBC.Tables t
WHERE DataBaseName = 'databasename'

如果記錄已啟用且可存取記錄歷程，則資料表 DBQLogTbl 和相關記錄資料表中提供其他資訊，例如 SQL 查詢文字。 如需詳細資訊，請參閱 Teradata 記錄歷程。

針對使用者將風險和影響降至最低的最佳移轉方法為何？

因為公司可能會想要降低變更對資料倉儲資料模型的影響來改善靈活度，所以經常出現這樣的疑問。 公司通常會在 ETL 移轉期間看到將其資料進一步現代化或轉型的機會。 這種方法的風險較高，因為此方法會同時變更多個因素，因此難以比較舊系統與新系統的成果。 在此進行資料模型變更也可能會影響其他系統的上游或下游 ETL 作業。 基於該風險，最好在資料倉儲移轉之後重新設計此級別。

即使整體移轉過程會刻意變更資料模型，良好的做法仍是將現有的模型依原樣移轉至 Azure Synapse，而不是在新平台上重新設計。 這種方法可將對現有生產系統的影響降到最低，同時可在進行一次性的重新設計工作時，得益於 Azure 平台的效能和彈性延展性。

從 Teradata 移轉時，請考慮在 Azure 內的 VM 中建立 Teradata 環境，作為移轉程序的基石。

提示

即使您未來計畫變更資料模型，一開始也請先依原樣移轉現有的模型。

在移轉過程中使用 VM Teradata 執行個體

從內部部署 Teradata 環境移轉的其中一個方法是利用 Azure 環境，在 Azure 內的 VM 中建立 Teradata 執行個體，並與目標 Azure Synapse 環境共置。 因為 Azure 提供便宜的雲端儲存體和彈性可擴縮性，所以這是可行的。

使用此方法時，如 Teradata Parallel Data Transporter (或如 Attunity Replicate 等第三方資料複製工具) 等標準 Teradata 公用程式可用來有效率地移動需要移轉至 VM 執行個體的 Teradata 資料表子集。 然後，所有移轉工作都可以在 Azure 環境中進行。 這種方法有幾項優點：

  • 初始複寫資料後，移轉工作不會影響來源系統。

  • Azure 環境擁有熟悉的 Teradata 介面、工具和公用程式可供使用。

  • Azure 環境後提供內部部署來源系統和雲端目標系統之間的網路頻寬可用性。

  • Azure Data Factory 等工具能夠高效地呼叫 Teradata Parallel Transporter 等公用程式來快速輕鬆地遷移資料。

  • 移轉流程完全在 Azure 環境中協調和控制。

移轉資料超市時：維持實體或轉成虛擬？

提示

虛擬化資料超市可以節省儲存體和處理資源。

在舊版 Teradata 資料倉儲環境中，通常會建立多個結構化的資料超市，為組織內的特定自助查詢和報表提供良好的效能。 因此，資料超市通常由資料倉儲的子集組成，並包含表單彙總版本的資料，可讓使用者透過 Microsoft Power BI、Tableau 或 MicroStrategy 等容易使用的查詢工具，輕鬆地查詢具有快速回應時間的資料。 此表單通常是維度資料模型。 資料超市的其中一種用法是以可用形式公開資料，即使基礎倉儲資料模型有些不同也是如此，例如資料保存庫。

您可以針對組織個別業務單位使用不同的資料超市，只允許使用者存取與其相關的特定資料超市，並排除、混淆或匿名敏感性資料，來實作健全的資料安全性。

如果這些資料超市實作為實體資料表，則需要額外的儲存體資源來儲存並進行額外處理，以定期建立和重新整理這些資料。 此外，超市中的資料只會維持在上次重新整理作業時的最新狀態，因此可能不適合高度變動的資料儀表板。

提示

Azure Synapse 的效能和可擴縮性可啟用虛擬化，而不需要犧牲效能。

隨著相對低成本的可調整 MPP 結構問世，例如 Azure Synapse，以及這類結構的固有效能特性，您可能不需要將超市具現化為一組實體資料表，就能提供資料超市功能。 這可藉由透過 SQL 檢視將資料超市有效地虛擬化至主要資料倉儲，或使用 Azure 中的檢視或 Microsoft 合作夥伴視覺效果產品等功能，透過虛擬化圖層來達成。 此方法可簡化或消除額外的儲存體和彙總處理需求，並減少要移轉的資料庫物件總數。

這種方法有另一個潛在優點。 藉由在虛擬化圖層內實作彙總和聯結邏輯，以及透過虛擬化檢視呈現外部報告工具，建立這些檢視所需的處理會「向下推送」到資料倉儲，這通常是在大型資料磁碟區上執行聯結、彙總和其他相關作業的最佳位置。

選擇虛擬資料超市實作而非實體資料超市的主要因素包括：

  • 更敏捷：虛擬資料超市比實體資料表和相關聯的 ETL 程序更容易變更。

  • 擁有權總成本較低：虛擬化實作所需的資料存放區和資料複本較少。

  • 消除用於移轉的 ETL 作業，並簡化虛擬環境中的資料倉儲架構。

  • 效能：雖然實體資料超市過去的效能較好，但現在的虛擬化產品會實作智慧型快取技術來減輕問題。

從 Teradata 移轉資料

了解您的資料

移轉規劃的一部分是詳細了解需要移轉的資料量，因為這可能會影響移轉方法的決策。 使用系統中繼資料來判斷要移轉之資料表內「原始資料」佔用的實體空間。 這裡的「原始資料」表示資料表內資料列所使用的空間量，不包括索引和壓縮等額外負荷。 這特別適用於最大的事實資料表，因為這些資料表通常會組成超過 95% 的資料。

您可以擷取代表性的資料樣本 (例如一百萬列) 到未壓縮的一般 ASCII 資料檔案，以取得要針對指定資料表移轉的資料量精確數目。 然後，使用該檔案的大小來取得該資料表每列的平均原始資料大小。 最後，將該平均大小乘以完整資料表中列的總數，以提供資料表的原始資料大小。 在規劃中使用該原始資料大小。

ETL 移轉考量

關於 Teradata ETL 移轉的初始決策

提示

事先規劃 ETL 移轉的方法，並適時運用 Azure 設施。

針對 ETL/ELT 處理，舊版 Teradata 資料倉儲可能透過 Teradata 公用程式使用自訂建置的指令碼，例如 BTEQ 和 Teradata Parallel Transporter (TPT)，或是 Informatica 或 Ab Initio 等協力廠商 ETL 工具。 有時候，Teradata 資料倉儲會使用經過時間演進的 ETL 和 ELT 方法組合。 規劃移轉至 Azure Synapse 時，您必須判斷在新環境中實作所需 ETL/ELT 處理的最佳方式，同時將相關成本和風險降至最低。 若要深入了解 ETL 和 ELT 處理，請參閱 ELT 與 ETL 設計方法。

下列各節討論移轉選項，並針對各使用案例提出建議。 此流程圖摘要說明一種方法：

Flowchart of migration options and recommendations.

第一個步驟一律是建置需要移轉之 ETL/ELT 程序的詳細目錄。 如同其他步驟，可能會因為標準「內建」Azure 功能而不需要移轉一些現有的程序。 針對規劃，請務必了解要執行的移轉規模。

上述流程圖中，決策 1 與是否要移轉至完全 Azure 原生環境的高層級決策有關。 如果您移至完全 Azure 原生的環境，建議您使用 Azure Data Factory 中的 Pipelines 和活動或 Azure Synapse Pipelines 來重新設計 ETL 處理。 如果您沒有移至完全 Azure 原生環境，則決策 2 表示是否已在使用中現有的協力廠商 ETL 工具。

Teradata 環境中，可能使用 BTEQ 和 TPT 等 Teradata 特定公用程式，以自訂指令碼來執行部分或所有 ETL 處理。 在此情況下，您的方法應該是經由 Data Factory 重新設計。

提示

利用現有第三方工具的投資來降低成本和風險。

如果已在使用第三方 ETL 工具，尤其是大量投資技能，或數個現有工作流程和排程正在使用該工具，則決策 3 為是否可以有效率地支援 Azure Synapse 作為目標環境的工具。 在理想情況下，此工具會包含「原生」連接器，這些連接器可以利用 PolyBase 或 COPY INTO 等 Azure 設施，以獲得最有效率的資料載入。 有方法可以呼叫外部程序，例如 PolyBase 或 COPY INTO，並傳遞適當的參數。 在此情況下，請利用現有的技能和工作流程，並將 Azure Synapse 作為新的目標環境。

如果您決定保留現有的第三方 ETL 工具，在 Azure 環境 (而不是在現有的內部部署 ETL 伺服器) 內執行此工具可能也有優點，讓 Azure Data Factory 處理現有工作流程的整體協調流程。 其中一個優點，是需要從 Azure 下載、處理，然後上傳回 Azure 的資料較少。 因此，決策 4 是讓現有的工具維持原狀執行，或將其移至 Azure 環境，以達到成本、效能和可擴縮性優勢。

重新設計現有的 Teradata 特定指令碼

如果部分或所有現有的 Teradata 倉儲 ETL/ELT 處理是由利用 Teradata 特定公用程式的自訂指令碼處理，例如 BTEQ、MLOAD 或 TPT，則必須針對新的 Azure Synapse 環境重新編寫指令碼。 同樣地，如果在 Teradata 中使用預存程序實作 ETL 程序，則也必須重新編碼這些程序。

提示

要移轉的 ETL 工作詳細目錄應該包含指令碼和預存程序。

ETL 程序的一些元素很容易移轉，例如，從外部檔案將簡單的大量資料載入暫存表格。 例如，使用 PolyBase 而不是快速載入或 MLOAD，甚至可能將部分程序自動化。 如果匯出的檔案是 Parquet，您可以使用原生 Parquet 讀取器，是比 PolyBase 更快的選項。 包含任意複雜 SQL 和/或預存程序的其他程序部分，將需要更多時間來重新設計。

測試 Teradata SQL 與 Azure Synapse 相容性的其中一個方法，舊是從 Teradata 記錄擷取一些代表性的 SQL 陳述式，然後在這些查詢前面加上 EXPLAIN，接著假設 Azure Synapse 中有類似移轉的資料模型，並在 Azure Synapse 中執行這些 EXPLAIN 陳述式。 任何不相容的 SQL 皆會產生錯誤，而該錯誤資訊可以判斷重新編碼工作的規模。

Microsoft 合作夥伴提供工具和服務，可將 Teradata SQL 和預存程序移轉至 Azure Synapse。

使用第三方 ETL 工具

如上一節所述，在許多情況下，現有的舊版資料倉儲系統將已經由第三方 ETL 產品填入和維護。 如需適用於 Azure Synapse 的 Microsoft 資料整合合作夥伴清單，請參閱資料整合合作夥伴。

從 Teradata 載入資料

從 Teradata 載入資料時可用的選項

提示

第三方工具可以簡化並自動化移轉程序，進而降低風險。

從 Teradata 資料倉儲移轉資料時，需要解決一些與資料載入相關的基本問題。 您必須決定如何將資料實際從現有的內部部署 Teradata 環境移至雲端中的 Azure Synapse，以及哪些工具將用來執行傳輸和載入。 請考慮下列問題，下一節將討論這些問題。

  • 您是否會將資料擷取至檔案，或透過網路連線直接移動資料？

  • 您是否會從來源系統或 Azure 目標環境協調程序？

  • 您將使用哪些工具來自動化和管理程序？

要透過檔案還是網路連線傳輸資料？

提示

了解要移轉的資料磁碟區和可用的網路頻寬，因為這些因素會影響移轉方法決策。

在 Azure Synapse 中建立要移轉的資料庫資料表之後，您可以將資料移出舊版 Teradata 系統，並將這些資料表填入到新的環境中。 有兩個基本方法：

  • 檔案擷取：從 Teradata 資料表擷取資料到一般檔案，通常是以 CSV 格式、透過 BTEQ、快速匯出或 Teradata 平行傳輸器 (TPT)。 盡可能使用 TPT，因為其資料輸送量最有效率。

    這種方法需要空間才能放置擷取的資料檔案。 (如果有足夠的儲存體) 該空間可能是 Teradata 來源資料庫的本機位置，或是遠端存放在 Azure Blob 儲存體。 在本機寫入檔案時可達到最佳效能，因為這能避免網路負荷。

    若要將儲存體和網路傳輸需求降到最低，最好使用 gzip 之類的公用程式來壓縮擷取的資料檔案。

    擷取之後，一般檔案可以移至 (與目標 Azure Synapse 執行個體共置的) Azure Blob 儲存體，或使用 PolyBase 或 COPY INTO 直接載入 Azure Synapse。 實際將資料從本機內部部署儲存體移至 Azure 雲端環境的方法，取決於資料量和可用的網路頻寬。

    Microsoft 提供不同的選項來移動大量資料，包括 AZCopy 可將檔案跨網路移至 Azure 儲存體、Azure ExpressRoute 可透過私人網路連線移動大量資料，以及將檔案移至實體儲存體裝置的 Azure 資料箱，然後傳送至 Azure 資料中心以進行載入。 如需詳細資訊，請參閱資料傳輸。

  • 透過網路直接擷取和載入：目標 Azure 環境通常會透過 SQL 命令將資料擷取要求傳送至舊版 Teradata 系統以擷取資料。 結果會透過網路傳送，並直接載入 Azure Synapse，而不需要將資料放入中繼檔案。 此案例中的限制因素通常是 Teradata 資料庫與 Azure 環境之間的網路連線頻寬。 針對非常大型的資料量，這種方法可能不實用。

還有使用這兩種方法的混合式方法。 例如，您可以針對較小的維度資料表和較大的事實資料表範例使用直接網路擷取方法，快速在 Azure Synapse 中提供測試環境。 針對大量歷程記錄資料表，您可以使用 Azure 資料箱擷取和傳輸檔案。

從 Teradata 或 Azure 協調？

移至 Azure Synapse 的建議方法是使用 Azure Synapse Pipelines 或 Azure Data Factory 協調從 Azure 環境擷取和載入資料，以及 PolyBase 或 COPY INTO 等相關公用程式，以取得最有效率的資料載入。 此方法會利用 Azure 功能，並提供簡單的方法建置可重複使用的資料載入管線。

此方法的其他優點包括在資料載入程序期間，降低對 Teradata 系統的影響，因為管理和載入程序是在 Azure 中執行，而且能夠使用中繼資料驅動資料載入管線將程序自動化。

可以使用哪個工具？

資料轉換和移動的工作是所有 ETL 產品的基本功能。 如果其中一個產品已在現有的 Teradata 環境中使用，則使用現有的 ETL 工具可能會簡化從 Teradata 將資料移轉至 Azure Synapse 的程序。 此方法假設 ETL 工具支援 Azure Synapse 作為目標環境。 如需支援 Azure Synapse 工具的詳細資訊，請參閱資料整合合作夥伴。

如果您使用 ETL 工具，請考慮在 Azure 環境中執行此工具，以受益於 Azure 雲端效能、延展性和成本，並在 Teradata 資料中心釋出資源。 另一個優點是減少雲端與內部部署環境間的資料移動。

摘要

總而言之，針對將資料和相關的 ETL 程序從 Teradata 移轉至 Azure Synapse，我們的建議如下：

  • 事先規劃以確保成功移轉作業。

  • 針對要儘快移轉的資料和程序建立詳細詳細目錄。

  • 使用系統中繼資料和記錄檔，以準確了解資料和程序使用方式。 請勿依賴文件，因為文件可能會過時。

  • 了解要移轉的資料磁片區，以及內部部署資料中心與 Azure 雲端環境間的網路頻寬。

  • 請考慮在 Azure VM 中使用 Teradata 執行個體作為從舊版 Teradata 環境卸載移轉的基石。

  • 利用標準「內建」Azure 功能，將移轉工作負載降至最低。

  • 識別並了解在 Teradata 和 Azure 環境中擷取和載入資料最有效率的工具。 請在程序各階段使用適當的工具。

  • 使用 Azure 設施，例如 Azure Synapse Pipelines 或 Azure Data Factory，協調並自動化移轉程序，同時將對 Teradata 系統的影響降到最低。

下一步

若要深入了解安全性存取作業，請參閱本系列中的下一篇文章：Teradata 移轉的安全性、存取和作業。