通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

针对 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)

此查询使用帮助程序函数 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 中都有直接的等效项。 下表显示了这些数据类型，以及映射它们的推荐方法。

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(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 DATETIME

使用 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 数据工厂可用于从旧版 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 设计方法。

以下部分介绍各种迁移方案，并针对各种用例提出建议。 此流程图汇总了一种方法：

迁移选项和建议的流程图。

第一步始终是生成需要迁移的 ETL/ELT 流程清单。 与其他步骤一样，标准的“内置”Azure 功能可能不要求迁移某些现有流程。 为了进行计划，请务必了解要执行的迁移规模。

在前面的流程图中，决策 1 涉及关于是否迁移到完全 Azure 原生环境的大致决策。 如果要迁移到完全 Azure 原生环境，建议使用 Azure 数据工厂中的管道和活动或 Azure Synapse 管道重新设计 ETL 处理。 如果不是迁移到完全 Azure 原生环境，则决策 2 设计现有第三方 ETL 工具是否已使用。

提示

利用对现有第三方工具的投资来降低成本和风险。

如果已在使用第三方 ETL 工具，特别是如果对技能进行大量投资或有多个现有工作流和计划使用该工具，则决策 3 涉及该工具是否可以高效地支持将 Azure Synapse 作为目标环境。 理想情况下，该工具将包含“本机”连接器，这些连接器可以利用 PolyBase 或 COPY INTO 等 Azure 设施进行最高效的数据加载。 有一种方法可以调用外部进程，例如 PolyBase 或 COPY INTO，并传入相应的参数。 在这种情况下，利用现有技能和工作流，并将 Azure Synapse 作为新的目标环境。

如果决定保留现有第三方 ETL 工具，则在 Azure 环境中（而不是在现有本地 ETL 服务器上）运行该工具并让 Azure 数据工厂处理现有工作流的整体业务流程可能会有好处。 一个特别的好处是需要从 Azure 下载、处理，然后上传回 Azure 的数据更少。 因此，决策 4 涉及是让现有工具按原样运行还是将其移至 Azure 环境以实现成本、性能和可伸缩性方面的好处。

重新设计特定于 Netezza 的现有脚本

如果部分或全部的现有 Netezza 仓库 ETL/ELT 处理流程是由使用特定于 Netezza 的实用工具（例如 nzsql 或 nzload）的自定义脚本处理的，则需要为新的 Azure Synapse 环境重新编码这些脚本。 同样，如果 ETL 流程是使用 Netezza 中的存储过程实现的，那么这些过程也必须重新编码。

提示

要迁移的 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 系统，然后加载到新环境中以填充这些表。 有两种基本方法：

  • 文件提取：通过带有 -o 选项的 nzsql 或通过 CREATE EXTERNAL TABLE 语句将数据从 Netezza 表提取到平面文件，通常为 CSV 格式。 尽可能使用外部表，因为外部表在数据吞吐量方面效率最高。 以下 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 Blob 存储（与目标 Azure Synapse 实例位于同一位置），或使用 PolyBase 或 COPY INTO 直接加载到 Azure Synapse。 将数据从本地存储物理移动到 Azure 云环境的方法取决于数据量和可用的网络带宽。

    Microsoft 提供了多种用于迁移大量数据的选项，包括用于将文件通过网络移动到 Azure 存储的 AzCopy、用于通过专用网络连接批量迁移数据的 Azure ExpressRoute，以及用于将文件移动到物理存储设备，然后交付到 Azure 数据中心进行加载的 Azure Data Box。 有关详细信息，请参阅数据传输。

  • 通过网络直接提取和加载：目标 Azure 环境将数据提取请求（通常通过 SQL 命令）发送到旧版 Netezza 系统以提取数据。 结果通过网络发送并直接加载到 Azure Synapse，而无需将数据放置到中间文件中。 通常，此方案的限制因素在于 Netezza 数据库与 Azure 环境之间的网络连接带宽。 如果数据量非常大，此方法可能不实用。

还有一种利用这两种方法的混合方法。 例如，可以针对较小的维度表和较大的事实数据表样本使用直接网络提取方法，以便在 Azure Synapse 中快速提供测试环境。 而对于大量的历史事实数据表，可以通过 Azure Data Box 使用文件提取和传输方法。

通过 Netezza 还是 Azure 协调？

迁移到 Azure Synapse 时推荐的方法是使用 Azure Synapse Pipelines/Azure 数据工厂和关联的实用工具（例如 PolyBase 或 COPY INTO）来协调从 Azure 环境提取和加载数据的过程，从而实现最有效的数据加载。 此方法利用 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 数据工厂）协调和自动化迁移过程，同时最大程度地降低对 Netezza 系统的影响。

后续步骤

若要详细了解安全访问操作，请参阅本系列中的下一篇文章：Netezza 迁移的安全性、访问权限和操作。