Share via

Netezza 移轉的資料移轉、ETL 和載入

  • 發行項

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

資料移轉考量

從 Netezza 移轉資料的初始決策

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

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

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

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

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

移轉未使用的資料表？

提示

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

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

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

以下是在指定時間範圍內尋找特定資料表使用量的範例查詢：

SELECT FORMAT_TABLE_ACCESS (usage),
  hq.submittime
FROM "$v_hist_queries" hq
  INNER JOIN "$hist_table_access_3" hta USING
(NPSID, NPSINSTANCEID, OPID, SESSIONID)
WHERE hq.dbname = 'PROD'
AND hta.schemaname = 'ADMIN'
AND hta.tablename = 'TEST_1'
AND hq.SUBMITTIME > '01-01-2015'
AND hq.SUBMITTIME <= '08-06-2015'
AND
(
  instr(FORMAT_TABLE_ACCESS(usage),'ins') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'upd') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
)
AND status=0;

| FORMAT_TABLE_ACCESS | SUBMITTIME
----------------------+---------------------------
ins                   | 2015-06-16 18:32:25.728042
ins                   | 2015-06-16 17:46:14.337105
ins                   | 2015-06-16 17:47:14.430995
(3 rows)

此查詢會使用 helper 函式 FORMAT_TABLE_ACCESS，以及 $v_hist_table_access_3 檢視尾端的數字，以比對安裝的查詢歷程記錄版本。

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

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

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

從 Netezza 移轉時，現有的資料模型通常已適合依現狀移轉至 Azure Synapse。

提示

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

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

提示

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

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

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

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

提示

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

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

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

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

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

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

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

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

從 Netezza 移轉資料

了解您的資料

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

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

Netezza 資料類型對應

提示

評估不支援的資料類型在準備階段的影響。

大部分的 Netezza 資料類型在 Azure Synapse Analytics 中都有直接的對等用法。 下列資料表顯示這些資料類型，以及對應這些資料類型的建議方法。

Netezza 資料類型 Azure Synapse 資料類型
bigint bigint
BINARY VARYING(n) VARBINARY(n)
BOOLEAN BIT
BYTEINT TINYINT
CHARACTER VARYING(n) VARCHAR(n)
CHARACTER(n) CHAR(n)
日期 DATE(date)
DECIMAL(p,s) DECIMAL(p,s)
DOUBLE PRECISION FLOAT
FLOAT(n) FLOAT(n)
INTEGER INT
INTERVAL Azure Synapse Analytics 目前不支援 INTERVAL 資料類型，但可以使用 DATEDIFF 等時態性函數來計算。
MONEY MONEY
NATIONAL CHARACTER VARYING(n) NVARCHAR(n)
NATIONAL CHARACTER(n) NCHAR(n)
NUMERIC(p,s) NUMERIC(p,s)
REAL REAL
SMALLINT SMALLINT
ST_GEOMETRY(n) Azure Synapse Analytics 目前不支援如 ST_GEOMETRY 的空間資料類型，但資料可以儲存為 VARCHAR 或 VARBINARY。
TIME TIME
TIME WITH TIME ZONE DATETIMEOFFSET
timestamp 日期時間

使用 Netezza 目錄資料表中的中繼資料來判斷是否要移轉這些資料類型中的任何一種，然後在此移轉方案中允許執行。 此類型查詢的 Netezza 中的重要中繼資料檢視如下：

  • _V_USER：使用者檢視會提供 Netezza 系統中使用者的相關資訊。

  • _V_TABLE：資料表檢視會包含在 Netezza 效能系統中建立的資料表的清單。

  • _V_RELATION_COLUMN：關聯資料行系統目錄檢視包含資料表中可用的資料行。

  • _V_OBJECTS：物件檢視會列出 Netezza 中可用的不同物件，例如資料表、檢視、函式等等。

例如，此 Netezza SQL 查詢會顯示資料行和資料行類型：

SELECT
tablename,
  attname AS COL_NAME,
  b.FORMAT_TYPE AS COL_TYPE,
  attnum AS COL_NUM
FROM _v_table a
  JOIN _v_relation_column b
  ON a.objid = b.objid
WHERE a.tablename = 'ATT_TEST'
AND a.schema = 'ADMIN'
ORDER BY attnum;

TABLENAME | COL_NAME    | COL_TYPE             | COL_NUM
----------+-------------+----------------------+--------
ATT_TEST  | COL_INT     | INTEGER              | 1
ATT_TEST  | COL_NUMERIC | NUMERIC(10,2)        | 2
ATT_TEST  | COL_VARCHAR | CHARACTER VARYING(5) | 3
ATT_TEST  | COL_DATE    | DATE                 | 4
(4 rows)

可以修改查詢來搜尋所有資料表，以尋找不支援的資料類型的任何項目。

Azure Data Factory 可用來從舊版 Netezza 環境移動資料。 如需詳細資訊，請參閱 IBM Netezza 連接器。

第三方廠商提供工具和服務來自動化移轉，包括如先前所述的資料類型的對應。 此外，已在 Netezza 環境中使用的第三方 ETL 工具，例如 Informatica 或 Talend，可以實作所有必要的資料轉換。 下一節會探索現有第三方 ETL 程序的移轉。

ETL 移轉考量

關於 Netezza ETL 移轉的初始決策

提示

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

針對 ETL/ELT 處理，舊版 Netezza 資料倉儲可以使用自訂建置的指令碼，其使用 Netezza 公用程式 (例如 nzsql 和 nzload)，或第三方 ETL 工具 (例如 Informatica 或 Ab Initio)。 有時候，Netezza 資料倉儲會使用經過時間演進的 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 工具。

提示

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

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

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

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

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

提示

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

ETL 程序的一些元素很容易移轉，例如，從外部檔案將簡單的大量資料載入暫存表格。 例如，使用 PolyBase 而不是 nzload，甚至可能將部分程序自動化。 包含任意複雜 SQL 和/或預存程序的其他部分流程，將需要更多時間來重新設計。

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

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

使用第三方 ETL 工具

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

從 Netezza 載入資料

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

提示

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

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

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

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

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

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

提示

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

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

  • 檔案擷取：將資料從 Netezza 資料表擷取為一般檔案 (通常是 CSV 格式)，透過 nzsql 搭配 -o 選項或透過 CREATE EXTERNAL TABLE 陳述式。 盡可能使用外部資料表，因為這是資料輸送量最有效率的方式。 下列 SQL 範例會透過外部資料表建立 CSV 檔案：

    CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',')
AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;

    如果您要將資料匯出至本機 Netezza 主機上掛接的檔案系統，請使用外部資料表。 如果您要將資料匯出至已安裝 JDBC、ODBC 或 OLEDB 的遠端機器，則您的 "remotesource odbc" 選項是 USING 子句。

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

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

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

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

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

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

從 Netezza 或 Azure 進行協調？

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

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

可以使用哪些工具？

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

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

摘要

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

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

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

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

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

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

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

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

下一步

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