QuickSight 到 Power BI 的迁移：完整的企业框架 (2025)

从 Amazon QuickSight 过渡到 Microsoft Power BI 的综合指南

战略原理和平台比较

迁移 BI 平台的决定是一项重大的战略任务。从 Amazon QuickSight 过渡到 Microsoft Power BI 是从以 AWS 为中心的云原生服务向深入嵌入更广泛的 Microsoft 生态系统的综合分析平台的转变。一个重要的发现是这条路径缺乏自动迁移工具，使得该过程主要是手动工作，专注于细致的重建。

功能比较表：QuickSight 与 Power BI

交互式 TCO 场景分析

这两个平台的定价理念根本不同。使用下面的按钮可了解不同组织场景的预计年度总拥有成本 (TCO)。此分析包括许可证、估计的基础设施和数据出口费用。

小团队
中级
大型企业

迁移框架：分阶段方法

成功的迁移需要结构化、有条理的方法。我们建议采用基于 Microsoft 经过验证的方法的分阶段框架，该框架针对 QuickSight 到 Power BI 过渡的具体挑战而量身定制。

第一阶段：迁移前评估和规划

整个项目的基础。这是主要的风险评估活动，从一般意图转向具体的、数据驱动的计划。主要活动包括：

• 库存资产：对所有分析、仪表板、数据集、计算字段和安全规则进行编目。区分 Direct Query 和 SPICE 数据集。
• 分析使用情况：利用 QuickSight 指标来确定高影响力、关键业务报告的优先级。数据驱动的优先级是关键。
• 合理化和退休：正式淘汰多余、过时或未使用的资产。这减少了迁移范围和未来的混乱。
• 定义范围：为每项资产选择“直接迁移”（复制）或“现代化”（重新设计）方法。现代化是首选。
• 组建团队：定义项目经理、数据架构师、DAX 开发人员、BI 开发人员和业务分析师的角色。

第 2 阶段：概念验证 (POC) 和解决方案设计

POC 阶段旨在解决未知问题、验证假设并尽早降低风险。它应该对最重要的架构差异进行压力测试。

• 选择 POC 候选人：选择 2-3 个不同复杂程度（简单、复杂数据模型、计算量大）的仪表板来测试不同的挑战。
• 设计目标架构：完成 Power BI 工作区策略、数据网关配置（例如，在 EC2 实例上）和语义模型方法（共享与单独）。
• 执行POC：手动重建报告以验证可行性、完善工作量估计并收集性能基线。
• 目前的调查结果：与利益相关者共享结果、完善的计划和风险评估，以确保完整迁移的最终批准。

第三阶段：技术执行与重建

此阶段涉及解构 QuickSight 资产并在 Power BI 以模型为中心的范例中重建它们的详细技术工作。这包括数据层迁移、语义模型重建、DAX 转换和表示层重建。

第 4 阶段：迁移后运营和优化

该项目不会在部署时结束。此阶段对于确保准确性、性能、信任和广泛的用户采用至关重要，最终实现 QuickSight 的受控和完全退役。

数据层迁移：连接到 AWS 源

与现有 AWS 数据源建立可靠、高性能且安全的连接是一个基础步骤，由于跨云架构，会对性能和成本产生重大影响。

连接到 Amazon Redshift

Power BI 为 Redshift 提供了成熟的本机连接器。关键决策涉及连接模式和安全性。

• 连接模式：选择之间进口（最佳性能，将数据加载到 Power BI）和直接查询（实时数据，性能取决于Redshift）。一般建议进口。
• 网关配置：Power BI 数据网关（理想情况下安装在与 Redshift 位于同一 VPC 中的 Windows EC2 实例上）需要从 Power BI 服务进行数据刷新和 DirectQuery。
• 安全：配置 Microsoft Entra ID (Azure AD) 单点登录以实现无缝、安全的身份验证。

连接到 Amazon S3

Power BI 缺乏用于查询 S3 中文件的直接本机连接器。推荐的方法是使用中介服务。

推荐模式：使用 AWS Athena

AWS Athena 允许您对 S3 中的文件运行标准 SQL 查询。然后，Power BI 可以直接连接到 Athena，像传统数据库一样处理您的 S3 数据。这是最强大且可扩展的模式。

-- Step 1: In AWS Athena, define the table over your S3 data.
CREATE EXTERNAL TABLE my_s3_data (
    order_id INT,
    customer_name STRING,
    order_date DATE,
    sales_amount DECIMAL(10,2)
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde'
LOCATION 's3://your-bucket-name/your-data-folder/';

-- Step 2: In Power BI Desktop, use the "Get Data" -> "Amazon Athena" connector.
-- Power BI can then run standard SQL against this table.
-- SELECT * FROM my_s3_data;
                

其他图案：对于较小的任务，可以在 Power BI 中使用 Python 脚本（使用 boto3）。对于企业 ETL，AWS Glue 或 Azure 数据工厂等工具可以将数据从 S3 移动到 Azure 本机存储（例如 Azure SQL 数据库），以获得最佳性能。

语义模型和表示层

这个过程不是直接转换，而是重新实现。重点从 QuickSight 以可视化为中心的方法转移到 Power BI 强大的以模型为中心的范例。首先构建可扩展的模型，然后生成报告。

DAX 转换指南：QuickSight 到 Power BI

将 QuickSight 计算字段转换为 DAX 是技术上最具挑战性的任务。直接的、一对一的翻译几乎是不可能的。使用下面的搜索来查找常见 QuickSight 模式的 DAX 等效项。

视觉映射和增强

重建视觉效果是现代化的一个机会。不要只是复制；利用 Power BI 的卓越功能增强用户体验。

治理和安全复制

技术执行的最后一步是复制安全模型。 Power BI 的框架更加集成和强大，依赖于工作区和 DAX 驱动的安全规则。

映射用户和组

QuickSight 组映射到 Power BI 工作区角色。最佳实践是使用 Microsoft 365 或 Azure AD 安全组来控制工作区成员身份，而不是分配单个用户。

• QuickSight 组→Power BI 工作区角色（管理员、成员、贡献者、查看者）。
• 将安全组分配给这些角色以实现可扩展的管理。

转换行级安全性 (RLS)

QuickSight RLS 使用将用户映射到数据值的规则文件。 Power BI RLS使用DAX直接在数据模型中实现，更加强大和动态。

RLS 迁移步骤：

1. 从 QuickSight 中提取用户到数据的映射规则。
2. 在 Power BI Desktop 中，转到建模 → 管理角色并创建一个新角色（例如“区域经理”）。
3. 为角色编写 DAX 过滤器表达式。动态模式是最佳实践。
4. 发布到 Power BI 服务并将用户/组分配给角色。

-- Example: Dynamic RLS DAX Expression
-- This expression on the 'Sales' table filters it based on the region
-- assigned to the logged-in user in a separate 'UserPermissions' table.

[Region] = LOOKUPVALUE(
    'UserPermissions'[Region],
    'UserPermissions'[UserEmail],
    USERPRINCIPALNAME()
)
                

迁移后：验证、采用和停用

重建最后一个报告时，迁移项目并未结束。此阶段对于确保解决方案准确、高性能、可信和广泛采用至关重要。

交互式验证和 UAT 检查表

推动用户采用

针对性培训

针对不同的用户角色制定不同的培训路径。 “消费者”需要学习如何与报表交互，而“创造者”则需要有关 Power BI Desktop、数据建模和 DAX 的更深入培训。

赋能冠军

从业务部门中识别热情的高级用户。为他们提供高级培训，让他们能够提供同行支持并充当新平台的倡导者。

系统退役：受控的日落

最后一步是正式停用旧版 Amazon QuickSight 环境。必须对此进行规划和控制，以实现成本节约并消除用户困惑。使用此交互式清单来跟踪进度。

主要挑战和战略建议

认识到主要挑战是缓解这些挑战的第一步。组织应预见并计划应对以下障碍。

常见的迁移陷阱

手动重建势在必行

缺乏自动化工具意味着每个仪表板、数据模型和计算都必须从头开始重建。低估人工工作量是导致时间安排和成本超支的最常见原因。

计算和逻辑翻译复杂度

QuickSight的功能和Power BI的DAX之间的概念差距是最大的技术风险。简单的函数到函数映射是不够的，而且常常是不正确的。

跨云性能和成本损失

当 Power BI (Azure) 查询 AWS 中的数据时，网络延迟和 AWS 数据出站费用是重大挑战。这必须在架构中明确解决。

分析师的结论性建议

1. 投资模型优先的方法

专注于设计强大、集中的 Power BI 语义模型。这是可扩展、可管理且高性能的 BI 生态系统的基础。

2. 获得先进的 DAX 和数据建模专业知识

认识到将复杂的业务逻辑转换为高性能 DAX 需要专业技能。这项投资是降低技术风险的最重要因素。

3.拥抱现代化，而不仅仅是复制

将迁移视为合理化和改进组织分析组合的战略机会。抵制执行简单的“提升和转移”的诱惑。