通过

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

Teradata 可视化效果和报表迁移

  • 项目

本文是一个包含七部分的系列教程的第四部分，提供有关如何从 Teradata 迁移到 Azure Synapse Analytics 的指导。 本文重点介绍可视化效果和报表的最佳做法。

使用 Microsoft 和第三方 BI 工具访问 Azure Synapse Analytics

组织使用一系列商业智能 (BI) 工具和应用程序访问数据仓库和数据市场。 BI 产品的一些示例包括：

  • Microsoft BI 工具，如 Power BI。

  • Office 应用程序，如 Microsoft Excel 电子表格。

  • 来自不同供应商的第三方 BI 工具。

  • 嵌入了 BI 工具功能的自定义分析应用程序。

  • 支持按需 BI 的操作应用程序，方法是在 BI 平台上运行查询和报表，该平台转而查询数据仓库或数据市场中的数据。

  • 交互式数据科学开发工具，例如 Azure Synapse Spark Notebook、Azure 机器学习、RStudio 和 Jupyter Notebook。

如果在数据仓库迁移过程中迁移可视化效果和报表，则 BI 产品生成的所有现有查询、报表和仪表板都需要在新环境中运行。 BI 产品必须在 Azure Synapse 上产生与旧数据仓库环境中的相同结果。

为了在迁移后产生一致的结果，将数据仓库架构和数据迁移到 Azure Synapse 后，所有 BI 工具和应用程序依赖项都必须正常工作。 依赖项包括不太明显的方面，例如访问和安全性。 在解决访问和安全性问题时，请确保：

  • 迁移身份验证，这样用户就可以登录到 Azure Synapse 上的数据仓库和数据市场数据库。

  • 将所有用户迁移到 Azure Synapse。

  • 将所有用户组迁移到 Azure Synapse。

  • 将所有角色迁移到 Azure Synapse。

  • 将所有管理访问控制的授权特权迁移到 Azure Synapse。

  • 迁移用户、角色和特权分配，以便与迁移之前现有数据仓库的设置保持相同。 例如：

    • 分配给角色的数据库对象特权
    • 分配给用户组的角色
    • 分配给用户组和/或角色的用户

访问和安全性是迁移系统中数据访问的重要注意事项，在 Teradata 迁移的安全性、访问和操作中进行了更详细的讨论。

提示

需要首先迁移现有用户、用户组、角色和访问安全特权分配，才能成功迁移报表和可视化效果。

迁移所有必需的数据，以确保在旧环境中查询数据的报表和仪表板在 Azure Synapse 中生成相同的结果。

业务用户期望无缝迁移，不会出现任何意外导致他们对 Azure Synapse 上的迁移系统失去信心。 注意通过良好的沟通来减少用户可能产生的担忧。 用户的期望是：

  • 在查询中直接引用时，表结构保持不变。

  • 在查询中直接引用时，表名和列名保持不变。 例如，生成聚合报表时，BI 工具中对列定义的计算字段不会失败。

  • 历史分析结果保持相同。

  • 在可能的情况下，数据类型应保持相同。

  • 查询行为保持相同。

  • ODBC/JDBC 驱动程序经过测试，以确保查询行为保持不变。

提示

沟通和业务用户的参与对成功至关重要。

如果 BI 工具查询基础数据仓库或数据市场数据库中的视图，迁移后这些视图是否仍能正常工作？ 如果存在特定于旧数据仓库 DBMS 的专有 SQL 扩展，而这些扩展在 Azure Synapse 中没有等效的扩展，则某些视图可能无法正常工作。 如果是这样，你需要了解这些不兼容问题，并找到解决方法。

提示

使用专有 SQL 查询扩展的视图和 SQL 查询可能导致不兼容问题，从而影响 BI 报表和仪表板。

需要测试其他问题，例如跨 DBMS 平台的 NULL 值行为或数据类型变化，以确保计算结果中不存在任何细微的差异。 最大程度地减少这些问题，并采取所有必要的措施，防止业务用户受这些问题影响。 根据旧数据仓库环境，第三方工具有助于隐藏旧环境与新环境之间的差异，使 BI 工具和应用程序不做更改就可以运行。

测试对于可视化效果和报表迁移至关重要。 需要使用一个测试套件和议定的测试数据在两种环境中运行并再次运行测试。 测试工具也很有用，本指南会提到其中的几个工具。 此外，让业务用户参与此迁移的测试工作以保持较高信心，并让他们参与到项目也很重要。

提示

使用可重复测试来确保报表、仪表板和其他可视化效果成功迁移。

你可能正在考虑切换 BI 工具，例如迁移到 Power BI。 用户面临的诱惑是在迁移架构、数据、ETL 处理等的同时进行此类更改。 但是，为了最大程度地降低风险，最好是先迁移到 Azure Synapse，并在一切正常后再进一步进行现代化改造。

如果现有的 BI 工具在本地运行，请确保它们能够通过防火墙连接到 Azure Synapse，以便针对这两种环境运行比较。 或者，如果现有 BI 工具的供应商在 Azure 上提供其产品，你可以在 Azure 上试用这些产品。 这同样适用于在本地运行的、嵌入了 BI 或按需调用 BI 服务器（例如通过请求包含 XML 或 JSON 数据的“无提示报表”）的应用程序。

需要考虑的问题很多，让我们详细地了解一下。

使用数据虚拟化以最大程度地减少迁移对 BI 工具和报表造成的影响

在迁移期间，你可能很想满足长期要求，例如发起业务请求、添加缺失数据或实现新功能。 但是，这些更改可能会影响 BI 工具访问数据仓库，尤其是涉及到数据模型的结构更改时。 如果要采用敏捷数据建模技术或实现结构更改，请在迁移后执行此操作。

最大程度地减少架构更改或其他结构更改对 BI 工具的影响的一种方法是在 BI 工具与数据仓库和数据市场之间引入数据虚拟化。 下图显示了数据虚拟化如何向用户隐藏迁移。

显示如何通过数据虚拟化向用户隐藏迁移的示意图。

数据虚拟化会中断使用自助式 BI 工具的业务用户与要迁移的基础数据仓库和数据市场的物理架构之间的依赖关系。

提示

使用数据虚拟化可以避免迁移过程中业务用户受到结构更改的影响，使他们察觉不到这些更改。 结构更改包括用于优化 Azure Synapse 数据模型的架构更改。

借助数据虚拟化，可以对业务用户隐藏在迁移到 Azure Synapse 期间进行的任何架构更改（例如，为优化性能做的更改），因为他们只能访问数据虚拟化层中的虚拟表。 而且，如果进行结构更改，只需更新数据仓库或数据仓库与任何虚拟表之间的映射。 通过数据虚拟化，用户仍然察觉不到结构变化。 Microsoft 合作伙伴提供了数据虚拟化软件。

确定首先迁移的高优先级报表

将现有报表和仪表板迁移到 Azure Synapse 时，一个重要问题是首先迁移哪些报表和仪表板。 做出的决定由多个因素促成，例如：

  • 使用情况

  • 业务价值

  • 易迁移性

  • 数据迁移策略

以下各节将讨论这些因素。

无论做出何种决策，都必须有业务用户参与，因为他们会生成报表、仪表板和其他可视化效果，并根据这些项的见解做出业务决策。 每个人都可以在以下情况下受益：

  • 无缝迁移报表和仪表板，
  • 以最少的工作量迁移报表和仪表板，以及
  • 将 BI 工具指向 Azure Synapse 而不是旧数据仓库系统，并获取类似报表、仪表板和其他可视化效果。

根据使用量迁移报表

使用情况通常是业务价值的一个指标。 未使用的报表和仪表板显然无助于业务决策或提供当前价值。 如果没有办法找出未使用的报表和仪表板，可以使用几个提供使用情况统计信息的 BI 工具之一。

如果旧数据仓库已经建立并运行了多年，则很有可能存在数百个甚至数千个报表。 最好编译一份报表和仪表板的清单，并确定它们的业务用途和使用情况统计信息。

对于未使用的报表，请确定是否停用以减少迁移工作。 决定是否停用未使用的报表的一个关键因素是，应确认报表未使用的原因是人们不知道它的存在，还是它没有任何业务价值，或者是它已被另一个报表取代。

根据业务价值迁移报表

仅“使用情况”一个指标并不总是反映业务价值的良好指标。 可能需要仔细考虑报表见解对业务价值做出的贡献。 其中一种方法是评估根据报表做出的每个业务决策的盈利能力和对报表的依赖程度。 但是，对于大多数组织，这些信息不太可能轻易获得。

评估业务价值的另一种方法是查看报表与业务策略的一致性。 由主管制定的业务策略通常会列出需要实现的战略性业务目标 (SBO)、关键绩效指标 (KPI) 和 KPI 目标，以及负责实现这些目标的相关人员。 可以根据报表所贡献的 SBO（例如，减少欺诈、提高客户参与度和优化业务运营）对报表进行分类。 然后，可以优先迁移与高优先级目标关联的报表和仪表板。 这样，初始迁移就可以在战略领域提供业务价值。

评估业务价值的另一种方法是，将报表和仪表板分类为操作性、战术性或战略性层面，以确定它们在哪个业务层面上使用。 SBO 需要所有这些层面的贡献。 了解使用了哪些报表和仪表板、它们在哪个层面使用以及与它们相关联的目标，可以将初始迁移的重点放在高优先级业务价值上。 可以使用以下“业务策略目标”表来评估报表和仪表板。

Level 报表/仪表板名称 业务用途 使用的部门 使用频率 业务优先级
战略性
战术
可运行

借助 Azure 数据目录等元数据发现工具，业务用户可以对数据源进行标记和评级，以丰富这些数据源的元数据，有助于发现和分类。 可以使用报表或仪表板的元数据来帮助理解其业务价值。 如果没有这些工具，无论你是否要迁移，了解报表和仪表板对业务价值的贡献都可能是一项耗时的任务。

根据数据迁移策略迁移报表

如果迁移策略基于首先迁移数据市场，则数据市场迁移顺序将影响首先迁移哪些报表和仪表板。 如果策略基于业务价值，则将数据市场迁移到 Azure Synapse 的顺序将反映业务优先级。 元数据发现工具通过显示哪些数据市场表为哪些报表提供数据，从而帮助你实现策略。

提示

数据迁移策略会影响首先迁移哪些报表和可视化效果。

可能影响报表和可视化效果的迁移不兼容问题

BI 工具通过发出 SQL 查询生成报表、仪表板及其他可视化效果，这些查询访问数据仓库或数据市场中的物理表和/或视图。 将旧数据仓库迁移到 Azure Synapse 时，可能会有多种因素影响报表、仪表板和其他可视化效果的迁移难易程度。 这些因素包括：

  • 环境之间的架构不兼容。

  • 环境之间的 SQL 不兼容。

架构不兼容

在迁移期间，为报表、仪表板和其他可视化效果提供数据的数据仓库或数据市场表中的架构不兼容可以是：

  • 旧数据仓库 DBMS 中的非标准表类型在 Azure Synapse 中没有等效的类型。

  • 旧数据仓库 DBMS 中的数据类型在 Azure Synapse 中没有等效的类型。

在大多数情况下，存在解决不兼容性问题的方法。 例如，可将不受支持的表类型中的数据迁移到具有相应数据类型的标准表中，并按日期/时间列编制索引或分区。 同样，可以在另一种类型的列中表示不受支持的数据类型，并在 Azure Synapse 中执行计算以实现相同结果。

提示

架构不兼容问题包括 Azure Synapse 上不支持的旧式仓库 DBMS 表类型和数据类型。

若要识别受架构不兼容问题影响的报表，请针对旧数据仓库的系统目录运行查询，以识别采用不受支持数据类型的表。 然后，可以使用 BI 工具中的元数据识别访问这些表中数据的报表。 有关如何识别对象类型不兼容的详细信息，请参阅 不受支持的 Teradata 数据库对象类型。

提示

查询旧仓库 DBMS 的系统目录以识别与 Azure Synapse 不兼容的架构。

架构不兼容对报表、仪表板和其他可视化效果的影响可能比你想象的要小，因为许多 BI 工具不支持通用性较低的数据类型。 因此，旧数据仓库中可能已经有 CAST 将不受支持的数据类型转换为更泛型类型的视图。

SQL 不兼容

在迁移期间，SQL 不兼容可能会影响应用程序或工具中的任何报表、仪表板或其他可视化效果：

  • 访问的旧式数据仓库 DBMS 视图包含专有 SQL 函数，而这些函数在 Azure Synapse 中没有等效的函数。

  • 发出 SQL 查询，其中包含特定于旧环境的 SQL 方言的专有 SQL 函数，而这些函数在 Azure Synapse 中没有等效的函数。

衡量 SQL 不兼容问题对报表组合的影响

报表组合可能包括嵌入式查询服务、报表、仪表板和其他可视化效果。 不要依赖与这些项关联的文档来衡量 SQL 不兼容对报表组合到 Azure Synapse 迁移的影响。 需要使用更精确的方法来评估 SQL 不兼容的影响。

使用 EXPLAIN 语句查找 SQL 不兼容问题

可以通过查看旧 Teradata 数据仓库中最近 SQL 活动的日志来查找 SQL 不兼容问题。 使用脚本将一组代表性的 SQL 语句提取到文件中。 然后，为每个 SQL 语句添加一个 EXPLAIN 语句前缀，并在 Azure Synapse 中运行这些 EXPLAIN 语句。 执行 EXPLAIN 语句时，Azure Synapse 将拒绝任何包含不受支持的专有 SQL 扩展的 SQL 语句。 使用此方法，你可以评估 SQL 不兼容的程度。

旧数据仓库 DBMS 中的元数据还能帮助你识别不兼容的视图。 如前所述，从适用的日志中捕获一组具有代表性的 SQL 语句，为每个 SQL 语句加上一个 EXPLAIN 语句前缀，并在 Azure Synapse 中运行这些 EXPLAIN 语句，以识别视图中不兼容的 SQL。

提示

通过采集 DBMS 日志文件并运行 EXPLAIN 语句来衡量 SQL 不兼容问题的影响。

测试将报表和仪表板迁移到 Azure Synapse Analytics

数据仓库迁移的一个关键要素是在 Azure Synapse 中测试报表和仪表板，以验证迁移是否有效。 定义一系列测试，并为将要运行的每项测试定义一组所需结果，以验证迁移是否成功。 测试并比较现有和已迁移数据仓库系统中的报表和仪表板，以便：

  • 确定迁移期间所做的任何架构更改是否影响了报表的运行能力、报表结果或相应的报表可视化效果。 架构更改的一个示例是，是否将不兼容的数据类型映射到 Azure Synapse 中支持的等效数据类型。

  • 验证所有用户是否都已迁移。

  • 验证所有角色是否都已迁移，以及是否已将用户分配到这些角色。

  • 验证所有数据访问安全特权是否都已迁移，确保迁移访问控制列表 (ACL)。

  • 确保所有已知查询、报表和仪表板的结果一致。

  • 确保数据和 ETL 迁移完成且未出错。

  • 确保支持数据隐私保护。

  • 测试性能和可伸缩性。

  • 测试分析功能。

提示

测试并优化性能以最大程度地降低计算成本。

有关如何迁移用户、用户组、角色和特权的信息，请参阅 Teradata 迁移的安全性、访问和操作。

尽可能将测试自动化，使每项测试均可重复，并支持采用一致的方法来评估测试结果。 自动化非常适合用于已知的常规报表，可以通过 Azure Synapse 管道或 Azure 数据工厂业务流程进行管理。 如果已经有了一套用于回归测试的测试查询，则可以使用现有测试工具来自动化迁移后的测试。

提示

最佳做法是生成自动测试套件，使测试可重复。

即席分析和报表更具挑战性，需要编译一组测试，以验证迁移前后的相同报表和仪表板是否一致。 如果不一致，那么在迁移测试期间能够在原始系统和迁移后的系统中比较元数据世系就变得至关重要。 这种比较可以突出差异，并在难以通过其他方式检测时，精准确定差异发生的位置。

提示

利用比较元数据世系的工具来验证结果。

分析世系以了解报表、仪表板和数据之间的依赖关系

了解世系是成功迁移报表和仪表板的关键因素。 世系是显示已迁移数据的行程的元数据，因此可以从报表或仪表板一路跟踪其路径，直到返回数据源。 世系显示数据从点到点的移动方式、在数据仓库和/或数据市场中的位置，以及在哪些报表和仪表板中使用。 世系可以帮助你了解数据在通过不同数据存储（如文件和数据库、不同 ETL 管道）并进入报表时发生的情况。 当业务用户可以访问数据世系时，它可以提高信任度、培养信心并实现更明智的业务决策。

提示

能够访问从报表一直到数据源的元数据以及数据世系对于验证迁移的报表是否正常工作至关重要。

在多供应商数据仓库环境中，BI 团队中的业务分析师可以绘制数据世系。 例如，如果为 ETL、数据仓库和报表使用不同的供应商，并且每个供应商都有自己的元数据存储库，则确定报表中特定数据元素的来源可能既困难又耗时。

提示

在迁移期间，自动收集元数据并在多供应商环境中显示端到端世系的工具非常有用。

若要从旧数据仓库无缝迁移到 Azure Synapse，在比较每个环境生成的报表和仪表板时，请使用端到端数据世系来证明同类迁移。 若要显示端到端数据行程，需要从多个工具捕获和集成元数据。 可以访问支持自动化元数据发现和数据世系的工具可帮助你识别重复的报表或 ETL 流程，还可帮助你查找依赖于已过时、有问题或不存在的数据源的报表。 可以使用此信息减少迁移的报表和 ETL 流程数。

还可以将 Azure Synapse 中报表的端到端世系与旧环境中同一报表的端到端世系进行比较，以检查迁移期间是否无意中造成了任何差异。 需要测试和验证迁移是否成功时，这种类型的比较非常有用。

数据世系可视化不仅可以减少迁移过程的时间、工作量和错误，还可以实现更快的迁移。

使用可以比较世系的自动化元数据发现和数据世系工具，可以验证 Azure Synapse 中已迁移数据生成的报表是否以旧环境中的相同方式生成。 此功能还有助于确定：

  • 需要迁移哪些数据，以确保在 Azure Synapse 中成功执行报表和仪表板。

  • 已执行并且应执行哪些转换来确保在 Azure Synapse 中成功执行。

  • 如何减少重复报表。

自动化元数据发现和数据世系工具大大简化了迁移过程，因为它们可以帮助企业更好地了解其数据资产，以及需要将哪些资产迁移到 Azure Synapse 才能实现可靠的报表环境。

多个 ETL 工具提供端到端世系功能，因此，如果计划将其与 Azure Synapse 一起使用，请检查现有 ETL 工具是否具有该功能。 Azure Synapse 管道或数据工厂都支持在映射流中查看世系的功能。 Microsoft 合作伙伴还提供了自动化元数据发现、数据世系和世系比较工具。

将 BI 工具语义层迁移到 Azure Synapse Analytics

某些 BI 工具提供所谓的语义元数据层。 该层简化了业务用户对数据仓库或数据市场数据库中基础物理数据结构的访问。 语义元数据层通过提供高级对象（如维度、度量值、层次结构、计算指标和联接）来简化访问。 这些高级对象使用业务分析师所熟悉的业务术语，并映射到数据仓库或数据市场中的物理数据结构。

提示

某些 BI 工具提供语义层，用于简化业务用户对数据仓库或数据市场中物理数据结构的访问。

在进行数据仓库迁移时，可能会强制更改列名或表名。 例如，在 Teradata 中，表名可以包含“#”。 在 Azure Synapse 中，“#”只可用作表名的前缀，用于表示临时表。 在 Teradata 中，TEMPORARY TABLES 的名称中不一定包含“#”，但在 Synapse 中必须包含该字符。 在这种情况下，可能需要重新执行一些操作来更改表映射。

若要在多个 BI 工具之间实现一致性，请使用位于 BI 工具和应用程序与 Azure Synapse 之间的数据虚拟化服务器创建通用语义层。 在数据虚拟化服务器中，对高级对象（如维度、度量值、层次结构和联接等）使用通用数据名。 这样，可以一次性配置所有内容（包括计算字段、联接和映射），而无需在每个工具中配置。 然后，将所有 BI 工具指向数据虚拟化服务器。

提示

使用数据虚拟化创建通用语义层，以保证 Azure Synapse 环境中所有 BI 工具之间的一致性。

通过数据虚拟化，可以在所有 BI 工具之间保持一致，并中断 BI 工具和应用程序与 Azure Synapse 中基础物理数据结构之间的依赖关系。 Microsoft 合作伙伴可以帮助你在 Azure 中实现一致性。 下图显示了数据虚拟化服务器中的通用词汇，其中演示了如何通过多个 BI 工具查看通用语义层。

包含与数据虚拟化服务器相关的通用数据名称和定义的示意图。

结论

在直接迁移数据仓库迁移中，大多数报表、仪表板和其他可视化效果都可以轻松迁移。

在从旧环境迁移过程中，旧数据仓库或数据市场表中的数据可能会以不受支持的数据类型存储。 或者，你可能会发现包含专有 SQL 的旧数据仓库视图在 Azure Synapse 中没有等效视图。 如果是这样，则需要解决这些问题，以确保成功迁移到 Azure Synapse。

不要依赖于用户维护的文档来确定问题所在的位置。 而是使用 EXPLAIN 语句，因为它们是识别 SQL 不兼容的一种快速、实用的方法。 重新处理不兼容的 SQL 语句以便在 Azure Synapse 中实现等效功能。 此外，使用自动化元数据发现和世系工具了解依赖项、查找重复报表，并确定依赖于已过时、可疑或不存在的数据源的无效报表。 使用世系工具比较世系，以验证在旧数据仓库环境中运行的报表是否在 Azure Synapse 中以相同方式生成。

不要迁移你不再使用的报表。 BI 工具使用情况数据可帮助确定哪些报表未使用。 对于确实想要迁移的报表、仪表板和其他可视化效果，请迁移所有用户、用户组、角色和特权。 如果使用业务价值来推动报表迁移策略，请将报表与战略性业务目标和优先级相关联，以帮助确定报表见解对特定目标的贡献。 如果要逐个迁移数据市场，请使用元数据来确定哪些报表依赖于哪些表和视图，以便你可以就首先迁移哪些数据市场做出明智的决策。

提示

尽早识别不兼容问题以衡量迁移工作的范围。 迁移用户、组角色和特权分配。 仅迁移已使用并且对业务价值有贡献的报表和可视化效果。

在迁移过程中，数据仓库或数据市场的数据模型可能会发生结构更改。 请考虑使用数据虚拟化保护 BI 工具和应用程序免受结构更改的影响。 借助数据虚拟化，可以使用通用词汇来定义通用语义层。 通用语义层保证了在新的 Azure Synapse 环境中所有 BI 工具和应用程序之间存在一致的通用数据名称、定义、指标、层次结构和联接。

后续步骤

若要详细了解如何最大程度地减少 SQL 问题，请参阅本系列教程的下一篇文章：最大程度地减少 Teradata 迁移的 SQL 问题。