基于“统一数据源”的PowerBI路径参数化

本文节选自我正在撰写的一本新的PowerBI书籍，书名还没有想好，目录也没有，内容目前也很少。本不打算发出来，但最近遇到了很多小伙伴的一些共性问题，如今天所要讲的路径参数化。路径参数化有很多用途，一个简单的作用是更换数据源时方便快捷，但是由于最近很多小伙伴将PowerBI账号升级为PowerBI+office365，将数据源从本地Excel文件切换到onedrive for business，不知道该怎么方便地在两种“介质”中转换，所以这篇文章提前放出来以飨诸位。

几乎所有关于数据优化方面的文章或者书籍都会提到将路径参数化这一点，本书也不例外，因为这很重要。不过，本节将要提出的一个最新观点是：基于“统一数据源”的路径参数化才是最佳实践。

3.8.1 数据源路径参数化

由于运营了许多社群，我经常收到学员的提问并附上pbix文件和Excel数据文件，我会将它们放在一个单独的文件夹里。此时打开pbix文件一切正常，而一旦要进入 Power Query 中进行一些修改，那么马上会出现报错，如图3.x所示。

图3.x 打开别人发过来的pbix文件进入 Power Query 出现路径报错

想象一下：某个 Power BI 初学者，姑且叫他小王，在某个本该惬意的下午，由于C盘满了，不得不将桌面上的各种文件移动到D盘，其中就包含了制作 Power BI 报告的数据源文件夹，里面有几十张表。那么等小王重新打开 Power BI 并点击主页上的“刷新”后，去茶水间悠然地冲上一杯咖啡，回来一看出现了以上的错误，他陷入了沉思。

解决办法其实有很多，简单说明如下。

• 在 Power Query 中，选中要修改的表，点击右侧“查询设置”→“应用的步骤”→“源”右侧齿轮，修改文件路径。
• 编辑栏可以直接对路径进行修改。
• 打开高级编辑器修改。

不过，以上方式仅适合单个表或者少量的表修改，如果有大量的表，那么就需要做大量的重复工作。想象一下刚才提到的小王，在那个本该惬意的下午，面对着几十张表逐一修改数据源路径，是多么的不惬意。当他好不容易调整完所有的表，并再一次刷新成功时，那杯咖啡早已失去了本来的香甜芬芳，只剩下苦涩。

2个月后，同样的事情再次发生了。这一次移动文件的原因是小王要将做过的几个报表和对应的数据整理集中到一个名为“公司报表”的文件夹里统一管理。咖啡的苦涩再一次涌上心头。

人总是要学聪明的，小王经过一番搜索终于查到可以对文件路径进行参数化。

于是小王进行了如下的操作。

1. 新建参数 点击“管理参数”→“新建参数”，如图3.x所示。

图3.x 新建参数 对参数进行命名、类型设置与当前值设置，如图3.x所示。

图3.x 设置参数

1. 将路径地址修改为参数 找到每一个表的“源”的位置或者打开“高级编辑器”，将文件路径中的对应部分替换成参数方式，如图3.x所示。

图3.x 将文件路径设置为参数

这意味着，小王仍然还要进行一次全部数据表的路径替换。不过，今后如果再有相同的事情发生，小王只需要将参数中的文件夹路径修改为当前的路径，就可以一键实现之前的重复操作了。

其实如果这些表是存储在单个Excel文件的不同sheet里（大量的公司都普遍存在这种操作），那就更方便了，只要点击“数据源设置”→“更改源”，然后将路径改为新的路径，或者调整为参数拼接即可，如图3.x所示。

图3.x 便捷地修改数据源

然而小王没有这么“幸运”，他的每一张表都来自于单独的Excel文件，这也就意味着，他只能挨个表进行设置。好在这“或许”是最后一次了。

如图3.x展示了将路径参数化的示意图。

图3.x 路径参数化

图中明确展示了，有多少张表就需要进行多少次参数化操作过程。

而小王之所以会如此折腾，主要是因为没有遵循“统一数据源”操作原则。

3.8.2 统一数据源的路径参数化

关于统一数据源的操作，我们曾在第 2 章行了具体的阐述，总的原则是先获取本地路径的目录、ODB对应文件夹目录或是数据库的根目录，然后通过引用目录的方式分别获取各个表，如图3.x所示。

图3.x 统一数据源模式

由于数据源只有一个，即使要修改路径也只需要修改这一个，因此是否创建参数来代替路径其实没有那么重要了。

（要注意，我们所说的“只有一个”，指的是从本地获取大量文件时，统一从根目录获取，即将来的“数据源凭据”中对应本地文件的只有一个。而如果一个模型同时从本地和数据库获取数据，那么也就意味着要分别从两个位置建立根目录，然后分别引用，且“数据源凭据”至少应该包含两个。）

让我们接着说小王的故事。

几个月之后，小王的公司批量采购了Microsoft 365许可，要统一使用OneDrive for Business（ODB）进行文件共享协作，并且为了性能的提升，公司要求小王将本地文件数据源统一替换为从ODB获取，即我们在第 2.2 节中所介绍的内容。

小王望着刚刚冲好的咖啡，再一次陷入了沉思。

此时我们就发现路径的参数化存在着一定的局限性。因为参数化只是对本地路径的修改有效，而不能直接将本地路径替换为ODB路径或者数据库连接。

试问正在读本书的阁下，应该如何应对？

其实如果我们将视线从单独的文件路径移开，从宏观上去看待整个流程，再对比普通的路径参数化过程，我们会发现参数化的根本意义所在：实现多张表进行数据源统一切换。

而对于这几张数据表而言，它们都是从“根目录查询”引用而来，也就是说，可以将这几张表之前的所有步骤都看成是广义的“路径”，如图3.x所示。

图3.x 基于“统一数据源”的路径参数化

一旦思想得到了解放，我们就可以突破“将本地路径从C盘切换到D盘”这样狭义上的数据源切换，实现从本地文件路径切换到ODB数据源、切换到数据库中、从MySQL数据库切换到SQL server数据库这样广义的数据源切换，即数据存储介质的切换。这种感觉，就如同“御剑飞升，游行天地之间”。

这就是“统一数据源”的意义所在。

这就是为什么本节开头，我们要讲：基于“统一数据源”的路径参数化才是最佳实践。

接下来，让我们一起体验“御剑飞行”的修炼过程。

3.8.3 广义数据源切换

小王按照以上“统一数据源”的原则对模型进行了修改。所有文件都存储在"D:\公司报表”这个文件夹下，通过Folder.Contents函数获取根目录文件夹的查询，并取消加载，其他所有表都是对该表的引用，如图3.x所示。

图3.x 本地数据源的文件与文件夹显示

接下来，他将整个文件夹上传到ODB中，并使用第2.2节中的SharePoint.Contents获取ODB中的对应目录，得到如图3.x所示。

图3.x ODB目录

仔细观察以上两个查询的结果，不能说很像，简直就是一模一样。

接下来的操作就太简单了，可以直接打开“查询1”的高级编辑器，将所有代码直接复制粘贴到“公司报表”的高级编辑器中，并将“查询1”删除，如图3.x所示。

图3.x 数据源切换后的根目录显示与高级编辑器代码

在此过程中，其他所有表没有任何操作，也没有任何变化。当然，模型结构也不会发生任何变化。

一切就在这么悄无声息中改变了，然而又好像什么都没变。

同样的方法可以实现将数据源从MySQL切换到SQL Server。

本节通过定义“统一数据源”，提出了广义的数据源切换的概念，将以往的存储介质内的路径切换，转变到可以在不同的存储介质之间轻松便捷地切换数据源。再重复一次，实现这一切的根本前提是：统一数据源。

数据源的切换还有诸多妙用，让我们接着“御剑飞行”！