从 Excel 迁移到 Power BI：分步指南

每个 Power BI 迁移都从 Excel 开始。并不是因为 Excel 是 Power BI 的先决条件，而是因为 Excel 是组织分析知识的所在地。您的财务团队维护的电子表格、您的销售总监每周一构建的数据透视表、您的运营经理在三年的迭代完善中组装的仪表板工作簿 - 这些不仅仅是数据文件。它们对不可替代的业务逻辑、领域知识和分析模式进行编码。在不获取这些机构知识的情况下迁移到 Power BI 会产生技术上先进但分析能力不如其所取代的电子表格的仪表板。

本指南将引导您完成完整的迁移过程：识别 Excel 何时达到其极限、审核您的电子表格组合、将 Excel 公式和模式转换为 Power BI 等效项、构建适当的数据模型、验证结果、并行运行两个系统，最后停用电子表格。我们的目标不是在 Power BI 中复制 Excel，而是解锁 Excel 无法提供的功能，同时保留团队构建的每项分析见解。

要点

• 迁移是一个知识转移项目，而不是技术交换 --- 最困难的部分是捕获复杂电子表格中嵌入的业务逻辑
• VLOOKUP/INDEX-MATCH 模式转换为 Power BI 中正确的数据模型关系，消除查找错误并显着提高性能
• Excel 数据透视表映射到 Power BI 矩阵视觉效果，但 DAX 度量取代了使数据透视变得脆弱的计算字段和项目
• Power Query 取代了手动复制粘贴数据准备工作流程，节省了每个报告周期的时间并消除了人为错误
• 在停用之前并行运行 Excel 和 Power BI 至少一个完整的报告周期 --- 验证每个数字是否匹配
• 从价值最高、最痛苦的电子表格开始，而不是最简单的 --- 证明最困难问题的投资回报率可以建立动力
• 为部门级过渡规划 3-6 个月的迁移时间表，为企业范围规划 6-12 个月的迁移时间表

---

何时迁移：认识 Excel 的局限性

症状

Excel 是一个非凡的工具。对于临时分析、快速计算和小型数据集，没有什么比它更好的了。但组织的发展会以可预测的方式超出 Excel 的分析能力。如果您的团队遇到以下三种或更多症状，则应迁移到 Power BI：

文件大小问题。 超过 50MB 的工作簿的打开、保存和计算速度会变慢。超过 100MB 的工作簿经常崩溃。如果您的团队将单个分析模型拆分为多个文件来管理文件大小，那么您的 Excel 已经无法满足需要。

版本控制混乱。 “Revenue_Report_v3_FINAL_FINAL_revised_Feb.xlsx”不是版本控制。当多人编辑同一电子表格的副本并且没有人确信哪个版本具有正确的数字时，您就会遇到 Excel 无法解决的治理问题。

手动数据刷新。 如果有人每周花费数小时从数据库导出复制数据、将其粘贴到电子表格中、重新运行数据透视表以及通过电子邮件分发更新的文件，那么 Power BI 自动刷新就完全消除了这些时间。

公式脆弱性。 复杂的嵌套公式（IF 内的 IF 内的 VLOOKUP 内的 SUMPRODUCT）难以审计，容易被破坏，并且除了原作者之外的任何人都无法维护。当构建电子表格的人离开组织时，公式逻辑就变成了黑匣子。

可扩展性上限。 Excel 的硬限制为 1,048,576 行。即使在达到该限制之前，超过 100,000 行时性能也会显着下降。如果你的交易数据超过这个阈值，Excel就无法成为你的分析平台。

安全限制。 通过电子邮件发送的 Excel 文件可以转发给任何人。工作表保护被轻易绕过。没有关于谁访问了该文件或他们进行了哪些更改的审计跟踪。对于受监管的行业或敏感的财务数据，这些限制会带来真正的风险。

迁移案例

Power BI 解决了所有这些限制，同时保留了使 Excel 发挥价值的分析功能。它可以处理数亿行的数据集，而不会出现性能问题。它提供集中式、版本控制的报告，每个人都可以通过单个链接访问。计划刷新消除了手动数据准备。 DAX 度量比嵌套 Excel 公式更强大且更易于审核。行级安全性确保每个用户只能看到授权的数据。

问题不在于是否迁移，而在于何时迁移。答案是：在电子表格故障导致根据错误的数字做出关键业务决策之前。这种失败不是一个是否会发生的问题——在每个依赖复杂电子表格的组织中，这只是一个何时发生的问题。

---

第 1 阶段：电子表格审核和优先级排序

对您的电子表格组合进行编目

打开 Power BI Desktop 之前，对计划迁移的部门中的每个关键业务电子表格进行编目。对于每个电子表格，记录：

优先级矩阵

使用 2x2 矩阵确定电子表格迁移的优先级：

高价值+高痛苦（首先迁移） 这些电子表格支持关键业务决策并导致最多的问题。它们很复杂、更新频繁、维护起来很耗时，并且有错误历史。首先迁移这些可以带来最明显的投资回报率，并为更广泛的迁移建立组织动力。

高价值+低痛苦（迁移第二） 这些电子表格支持重要决策，但相对稳定且维护良好。它们受益于 Power BI 的安全性、分发性和可扩展性，但紧迫性较低，因为它们不会引起活跃的问题。

低价值+高痛苦（评估） 这些会导致问题，但不支持关键决策。考虑是否还需要分析。如果是，则迁移它。如果它已成为无人使用但有人尽职更新的遗留工件，请停用它。

低价值 + 低痛苦（最后迁移或跳过） 少数受众使用的简单、稳定的电子表格。这些可能根本不需要 Power BI。通过 SharePoint 共享的结构良好的 Excel 文件对于某些用例来说完全足够。

优先电子表格的深入分析

对于“首先迁移”类别中的每个电子表格，执行详细分析：

映射数据流。 跟踪每个输入从源到最终输出的过程。原始数据从哪里进入电子表格？应用了哪些变换？哪些细胞向其他细胞提供营养？绘制显示完整管道的数据流程图。

**提取业务规则。**复杂的电子表格将业务规则编码在公式中。根据订单量分配折扣等级的 VLOOKUP。一个嵌套 IF，将应收账款账龄分类为当前、30 天、60 天和 90 天以上的桶。根据人员比例在各部门之间分配共享成本的 SUMPRODUCT。必须识别、记录这些规则并将其转换为 DAX 或 Power Query 逻辑。

**识别隐藏的假设。**电子表格通常包含隐藏在单元格中的硬编码假设，这些假设显然不是计算的一部分：税率、汇率、目标利润率、增长假设。找到这些并决定它们是否应该成为 Power BI 模型中的参数或参考表中的数据驱动值。

---

第二阶段：公式和模式翻译

VLOOKUP 和索引匹配关系

Excel 的 VLOOKUP 是最常用的用于组合不同表中的数据的函数。在 Power BI 中，VLOOKUP 是不必要的，因为正确的数据模型关系会自动处理连接。

Excel 模式：

=VLOOKUP(A2, CustomerTable, 3, FALSE)

这会在 A 列中查找客户 ID，在 CustomerTable 中找到它，然后返回第三列（客户名称）中的值。

Power BI 等效项： 在事实表和客户 ID 列上的客户维度之间创建关系。一旦关系存在，任何包含客户表中的字段和事实表中的度量的视觉对象都会自动解析通过关系的查找。不需要公式。

这不仅仅是语法上的差异——这是一个根本性的改进。当在查找表上方插入行时，Excel 中的 VLOOKUP 会中断；当查找列未排序（近似匹配）时，会返回错误结果；每次工作簿发生更改时，VLOOKUP 都会重新计算（降低性能）。仅在查询时才会对 Power BI 中的关系进行索引、验证和计算。

将数据透视表转换为矩阵视觉效果

Excel 数据透视表直接转换为 Power BI 的矩阵视觉效果。映射很简单：

主要区别：在 Excel 中，计算字段是在数据透视表中定义的，并且很脆弱——更改数据透视表结构可能会破坏它们。在 Power BI 中，度量在数据模型中定义，并且在所有视觉对象中一致地工作，无论视觉对象如何配置。

要计算的 SUMIFS 和 COUNTIFS

Excel 的 SUMIFS 函数对多个条件下的值求和。 DAX 的 CALCULATE 函数更强大，但遵循相同的概念。

Excel：

=SUMIFS(Revenue, Region, "North", Year, 2026, Status, "Closed")

德国DAX指数：

North 2026 Closed Revenue =
CALCULATE(
    [Total Revenue],
    DimRegion[Region] = "North",
    DimDate[Year] = 2026,
    DimStatus[Status] = "Closed"
)

DAX 版本更详细，但更强大。每个过滤器参数可以是简单的比较、表函数（如 SAMEPERIODLASTYEAR）或复杂的表达式。与 SUMIFS 不同，CALCULATE 与视觉对象的筛选器上下文交互，因此可以在已按地区和年份筛选的矩阵视觉对象中使用相同的度量，并且它将正确应用顶部的附加筛选器。

IF/嵌套 IF 到 DAX 开关和变量

Excel 中复杂的嵌套 IF 语句是维护的噩梦。经典的老化桶公式：

Excel：

=IF(DaysPastDue<=0,"Current",IF(DaysPastDue<=30,"1-30 Days",IF(DaysPastDue<=60,"31-60 Days",IF(DaysPastDue<=90,"61-90 Days","90+ Days"))))

DAX（作为计算列或度量）：

Aging Bucket =
SWITCH(
    TRUE(),
    [Days Past Due] <= 0, "Current",
    [Days Past Due] <= 30, "1-30 Days",
    [Days Past Due] <= 60, "31-60 Days",
    [Days Past Due] <= 90, "61-90 Days",
    "90+ Days"
)

SWITCH(TRUE()) 按顺序评估条件并返回第一个 TRUE 条件的结果。它比嵌套的 IF 更容易阅读、更容易维护、更容易扩展。

数组公式到 DAX 迭代器

Excel 数组公式（在旧版本中使用 Ctrl+Shift+Enter 输入）跨值数组执行计算。 Power BI 等效项是 DAX 迭代器函数。

Excel（加权平均值）：

{=SUM(Quantity*Price)/SUM(Quantity)}

德国DAX指数：

Weighted Average Price =
DIVIDE(
    SUMX(Sales, Sales[Quantity] * Sales[UnitPrice]),
    SUM(Sales[Quantity])
)

SUMX 迭代 Sales 表中的每一行，将数量乘以单价，并对结果求和。这在逻辑上与 Excel 数组公式相同，但可以扩展到数百万行而不会出现性能问题。

---

第 3 阶段：构建 Power BI 数据模型

从平面文件到星型模式

最常见的 Excel 分析模式是单个平面表格：所有数据都在一张表中，每个属性都有列。客户名称、产品类别、地区、日期、金额——全部集中在一行。这在 Excel 中有效，因为 VLOOKUP 和数据透视表可以处理平面结构。在 Power BI 中，此结构可以正常工作，但不是最佳的。

迁移是一个将数据重组为适当的星型模式的机会。将平板分解为：

事实表： 具有数值（金额、数量、计数）和外键的交易级行。每个事务或事务行一行。

维度表： 独特的描述性实体。每个客户一行。每个产品一行。每个日期一行。在所有事实表之间共享。

这种重组提高了查询性能（VertiPaq 更好地压缩维度列），实现重用（多个事实表共享相同维度），并使模型自记录（架构显示实体如何关联）。

将查找表迁移到维度表

Excel 工作簿通常具有“查找”表——税率、折扣等级、汇率、区域映射、成本中心描述和类似参考数据的参考表。这些直接转换为 Power BI 中的维度表。

将每个查找表导入为 Power BI 中的单独表。在匹配的键列上创建从查找表到事实表的关系。从源数据中删除 VLOOKUP 公式并依赖模型关系。

对于包含业务规则（折扣等级、税级、价目表）的查找表，请考虑规则是否应为：

模型中静态： 导入查找表并仅在规则发生变化时刷新。适用于稳定的参考数据，例如国家/地区列表、货币代码和计量单位换算。

来自数据源的动态： 将查找表连接到业务用户可以更新的数据库或 SharePoint 列表，而无需修改 Power BI 模型。适用于经常变化的参考数据，例如汇率、目标预算和季节性调整。

处理手动数据输入

一些 Excel 电子表格包括手动数据输入——任何源系统中都不存在的预算目标、注释、分类和调整。迁移中必须保留此数据。

处理手动数据的选项：

SharePoint 列表。 将手动数据迁移到 SharePoint 列表。 Power BI 作为数据源连接到列表。业务用户继续在 SharePoint 中编辑数据，Power BI 会在刷新时获取更改。这是结构化手动数据的推荐方法。

Dataverse 表。 对于 Dynamics 365 环境，将手动数据存储在 Dataverse 表中。 Power BI 的本机 Dataverse 集成使这一切变得无缝。

假设参数。 对于数字假设（增长率、折扣百分比、税率），Power BI 的假设参数会创建滑块，用户可以在报表中调整这些滑块，而无需修改源数据。

直接输入Power BI（有限）。 Power BI 支持“输入数据”来创建小型静态表。这适用于小型且很少更改的参考数据（100 行以下），但不适用于经常更改的数据。

---

第 4 阶段：Power Query 数据准备

取代手动复制粘贴工作流程

迁移最直接节省的时间来自于自动化每个报告周期进行的手动数据准备。典型的 Excel 工作流程可能如下所示：

1.从ERP系统导出CSV 2.在Excel中打开，删除标题行 3. 将数据复制到报告工作簿中 4. 手动修复日期格式 5.添加客户姓名查找公式 6. 刷新数据透视表 7. 检查错误 8. 通过电子邮件将文件发送给利益相关者

在 Power BI 中，整个工作流程在 Power Query 中实现自动化：

1. Power Query 直接连接到 ERP 数据库（无 CSV 导出）
2. 转换步骤处理标题行、日期格式和数据类型 3.关系取代查找公式 4.定时刷新自动触发
3. 仪表板对于所有利益相关者始终是最新的

第一次构建 Power Query 步骤需要付出努力 --- 与构建原始 Excel 工作簿的努力相当。但随后的每次刷新都会自动发生，无需人工干预。一年多的每周报告，每个工作簿节省了 50 多个小时。

常见的 Power Query 转换

逆透视。 Excel 报告通常将数据透视为宽格式：月份作为列标题，类别作为行。 Power BI 更适合处理高而窄的数据。 Power Query 的 Unpivot 函数将宽表转换为长表：

之前：| Product | Jan | Feb | Mar | 之后：| Product | Month | Revenue |

这是迁移过程中最常见和最有价值的转变之一。 Excel 中的宽表在 Power BI 中成为正确建模的事实表。

附加多个文件。 如果您的 Excel 工作流程涉及打开 12 个每月文件并将它们复制到单个工作表中，Power Query 的合并文件功能会自动执行此操作。将 Power Query 指向一个文件夹，它会自动将该文件夹中的所有文件附加到一个表中。当新的每月文件添加到文件夹时，下次刷新会自动选取它。

数据类型强制。 Excel 对数据类型是宽松的 --- 列可以在同一列中包含数字、文本和日期。 Power BI 需要一致的类型。 Power Query 识别类型不匹配并提供清理它们的工具：替换错误、转换类型或删除有问题的行。

列拆分和合并。 将“全名”列拆分为“名字”和“姓氏”。将“城市”、“州”和“邮政编码”合并到一个“地址”列中。从日期中提取年份。解析产品代码以将类别前缀与商品编号分开。这些需要 Excel 公式的转换成为可重复使用的 Power Query 步骤。

---

第 5 阶段：验证和并行运行

验证框架

在停用任何电子表格之前，请验证 Power BI 报表是否生成相同的结果。这是没有商量余地的。如果数字与他们信任的 Excel 报告不同，用户将立即不信任 Power BI，即使 Power BI 数字实际上是正确的。

构建一个验证工作簿，并排比较关键指标：

调查差异

差异是正常的，也是意料之中的。它们源于：

数据范围不同。 Excel 文件可能在总数中包含取消的订单，而 Power BI 模型将其过滤掉（反之亦然）。协调两个系统之间的过滤标准。

舍入差异。 Excel 和 Power BI 使用不同的浮点精度。由于四舍五入顺序，数千个小数值的总和可能会相差几美分。这是可以接受和预期的。

时间差异。 如果 Excel 文件在上午 8:00 刷新，Power BI 数据集在上午 6:00 刷新，则在上午 6:00 到 8:00 之间记录的事务将出现在其中一个中，而不会出现在另一个中。使用相同的数据快照进行验证。

Excel 中的公式错误。 有时 Power BI 数字是正确的，而 Excel 数字是错误的。迁移通常会发现公式错误，这些错误数月或数年以来一直默默地产生不正确的结果。记录这些发现——它们证明了迁移的价值。

隐藏过滤器。 Excel 数据透视表可能应用了不立即可见的过滤器。检查“报告过滤器”区域以及数据透视表源数据上任何隐藏的手动过滤器。

并行运行周期

并行运行两个系统至少一个完整的报告周期——最好是两个。在此期间：

两个系统均已更新。 Excel 工作簿继续手动刷新。 Power BI 报表会自动刷新。两者都可供用户使用。

用户比较结果。 鼓励用户对照他们信任的 Excel 报告检查 Power BI 报告。让他们报告差异，以便您可以调查并解决它们。

**反馈收集。**收集有关 Power BI 体验的反馈。布局直观吗？正确的指标是否突出？有什么遗漏吗？在 Excel 版本停用之前，根据用户输入迭代 Power BI 设计。

并行运行期间的培训。 使用并行期间进行用户培训。用户可以学习 Power BI 的界面，同时仍然拥有熟悉的 Excel 报表作为安全网。这减少了对过渡的焦虑。

---

第 6 阶段：停用电子表格

退役清单

不要突然停用电子表格。遵循结构化流程：

公布时间表。 在电子表格停用前提前 2-4 周通知用户。传达具体日期和替代它的 Power BI 报告。

存档电子表格。 将 Excel 文件的最终版本移至明确标记的存档文件夹（不是活动报告文件夹）。不要删除它——用户在转换过程中可能需要参考历史数据，并且拥有可用的原始数据可以减少焦虑。

更新文档。 更新引用 Excel 报告的任何标准操作程序、培训材料或流程文档。将引用替换为 Power BI 报表的 URL。

删除对实时版本的访问权限。 如果电子表格位于 SharePoint 或网络共享上，请撤消编辑访问权限，但保留对存档副本的读取访问权限。这可以防止任何人继续更新已弃用的 Excel 版本并创建影子报告系统。

监控 Power BI 采用情况。 跟踪停用后第一个月内替代 Power BI 报告的使用指标。如果使用率显着下降，请调查用户是否已恢复使用电子表格或根本不进行分析（两者都是需要干预的问题）。

处理阻力

一些用户会抵制迁移，他们的担忧值得尊重。常见的反对意见和回应：

“我可以在 Excel 中完成 Power BI 无法完成的事情。” 有时确实如此。 Excel 的临时灵活性（插入注释、手动调整、一次性计算）是无与伦比的。答案是不要将所有内容都强行放入 Power BI 中。让用户继续使用 Excel 进行临时探索。 Power BI 取代了不应手动完成的重复报告，而不是 Excel 擅长的一次性分析。

“我不信任 Power BI 数字。” 这是验证阶段要解决的工作。如果并行运行周期表现出一致的准确性，就会建立信心。如果仍然存在差异，请在退役前解决它们。在信任问题未解决的情况下，切勿退役。

“Power BI 比我的电子表格慢。” 对于小型数据集，Excel 的打开和交互速度确实比 Web 浏览器中的 Power BI 报表更快。承认这种权衡。自动刷新、集中访问和可扩展性抵消了速度差异。对于加载时间至关重要的仪表板，优化 Power BI 报表的性能（减少视觉效果、优化 DAX、使用聚合）。

“我需要为我的团队修改报告。” Power BI 通过工作区权限支持此操作。授予高级用户“贡献者”访问权限，以创建自己的连接到共享数据集的报告。他们获得了所需的定制灵活性，同时底层数据模型保持受管控和一致。

对于计划从 Excel 到 Power BI 迁移的组织，ECOSIRE 的 Power BI 迁移服务 提供结构化迁移支持，包括电子表格审核、公式翻译、数据建模、验证框架和用户培训。我们已将制造、零售、金融和专业服务组织中的数百个关键业务电子表格迁移到 Power BI。

---

迁移后：维持变革

建立自助服务文化

从 Excel 迁移到 Power BI 的最终目标并不是用一种静态报告工具取代另一种工具。它旨在创建一种自助分析文化，让业务用户可以回答自己的问题，而无需等待 IT 部门生成报告。

通过以下方式启用自助服务：

发布共享数据集。 创建受管理、经过认证的数据集，业务用户在构建自己的报告时可以连接到这些数据集。数据集包含经过审查的数据模型、度量和关系。用户在顶部构建视觉效果，无需了解底层数据管道。

提供模板。 为用户可以复制和自定义的常见报告类型（销售仪表板、运营记分卡、财务摘要）创建入门模板。模板增强了设计的一致性，同时为用户提供了创作自由。

每月举办培训课程。 针对特定主题的简短而集中的课程（1 小时）：“如何构建条形图”、“如何创建切片器”、“如何使用钻取”。使用组织的实际数据，保持会议的实用性和实践性。

维护卓越中心。 一个小团队（2-3 人）担任内部 Power BI 专家。他们维护共享数据集，提供最佳实践指导，审查和认证报告，并及时了解 Power BI 的每月功能版本。

持续改进

迁移不是一次性事件。 Power BI 每月发布新功能。您的业​​务需求不断变化。数据源发生变化。您今天构建的报告明天需要更新。

安排对 Power BI 环境进行季度审查：

**使用情况分析。**哪些报告被大量使用？哪些是未使用的？投资前者；使后者退休。

性能审查。 刷新时间是否增加？视觉渲染速度慢吗？在性能下降到用户停止使用仪表板之前进行优化。

功能采用。 用户是否正在利用新的 Power BI 功能？是否存在可以增加价值但尚未被采用的功能（人工智能视觉、快速洞察、目标跟踪）？

反馈集成。 不断收集用户反馈并将其集成到您的开发待办事项中。最好的分析环境是由每天使用它们的人塑造的，而不是由构建它们的团队塑造的。

---

常见问题解答

从 Excel 到 Power BI 的典型迁移需要多长时间？

单个电子表格迁移（一本复杂的工作簿到一份 Power BI 报告）需要 2-4 周的时间，包括分析、开发、验证和并行运行。部门级迁移（为一个团队服务 5-15 个电子表格）需要 3-6 个月。企业范围内的迁移（跨多个部门的数十个电子表格）需要 6-12 个月，包括治理设置、培训和变更管理。开发工作很少成为瓶颈——验证、培训和采用比构建报告需要更长的时间。

迁移到 Power BI 后我还能使用 Excel 吗？

绝对地。 Power BI 和 Excel 相辅相成。使用 Power BI 进行定期报告、共享仪表板和受治理的分析。使用 Excel 进行临时分析、一次性计算和数据探索。 Power BI 甚至允许您将数据导出到 Excel 进行进一步分析，并使用“在 Excel 中分析”将 Excel 直接连接到 Power BI 数据集，为您提供两全其美的优势。

我的 Excel 宏和 VBA 代码会发生什么情况？

VBA 宏不会转换为 Power BI。如果您的电子表格依赖宏进行数据转换（清理、格式化、组合文件），请将其替换为 Power Query 步骤。如果宏驱动用户界面行为（自定义按钮、表单对话框），请评估 Power BI 的本机交互模型（切片器、钻取、书签）是否提供等效功能。对于与外部系统交互的宏（发送电子邮件、写入数据库），请将其替换为由 Power BI 数据警报触发的 Power Automate 流。

我是否需要为每个迁移的 Excel 用户获取 Power BI 许可证？

未必。 Power BI 许可取决于用户访问内容的方式，而不是他们之前的 Excel 使用情况。如果您将报表发布到高级容量工作区，查看者只需要一个免费的 Power BI 帐户。如果您使用 Pro 工作区，则每个查看者都需要 Pro 许可证（10 美元/用户/月）。对于报表创建者数量较少而查看者数量较多的组织来说，高级容量更具成本效益。首先将您的 Excel 用户分类为创建者（需要 Pro 或 PPU）与查看者（需要 Pro 或可以免费使用 Premium），以准确建模成本。

如何处理手动数据输入且不在任何数据库中的电子表格？

仅存在于电子表格中的手动数据需要一个新家。最好的选择通常是 SharePoint 列表 --- 它提供了一个结构化的多用户数据输入界面，Power BI 可以将其连接为数据源。对于使用 Dynamics 365 的组织，Dataverse 表通过更紧密的 Power BI 集成达到相同的目的。对于很少更改的小型参考数据（100 行以下），Power BI 的“输入数据”功能会直接在模型中创建静态表。关键原则是，手动数据应输入到专为数据输入而设计的系统（SharePoint、Dataverse、简单的 Web 表单）中，并由 Power BI 作为数据源使用，而不是输入到 Power BI 本身。