几乎所有的教程都会告诉你,使用 Power BI 获取数据最简单的方式是从本地excel表中获取,紧接着教你如何从本地文件夹中获取多个文件。
从这一习惯养成的第一天开始,你就为将来某一天的后悔埋下了祸根。
因为不需要太久之后,你就要面临数据刷新、定时刷新、网关配置的问题,此时,如果你看到下面的每一个都需要进行一次凭据的选择:
请问,你作何感想?
尤其是当你每次在本地添加一个新的excel表,保存,发布,等待其自动刷新,但是总是不刷新,找了一圈原因,到数据集这里一看,哦对,需要对新添加的这张表设置凭据。你会不会懊恼不已?
为什么玩转 Power BI 一定需要 Office 365?
最近很多小伙伴看到我的这篇文章后,受到了启发,开始着手将本地文件转移到OneDrive for Business(ODB,需要企业版或教育版,个人版与家庭版不支持)。当然也有不少朋友直接导入数据库了,但是据我的了解,绝大部分(以我接触到的范围来看,是这样)使用powerbi的用户,并没有在使用数据库。
有部分小伙伴已经成功转移,但是也有一些小伙伴仍然感觉无从下手。
今天就再把这个老生常谈的小问题拿出来,抽丝剥茧,以飨读者。
本文分为两大部分:
一是讨论连接ODB上文件的几种方法与优劣对比
二是实现将已有的本地数据源报告切换到ODB数据源,同时不改变模型结构
以下展开。
一、连接ODB上的Excel文件
1、获取文件的路径
两个途径
①在桌面上打开odb中的文件
点击文件
信息
找到“打开文件位置”
右键后点击“复制路径”
https://powerbipro-my.sharepoint.com/personal/xueqian_powerbipro_cn/Documents/powerbi文件夹
添加文件名后得到了文件的完整路径
https://powerbipro-my.sharepoint.com/personal/xueqian_powerbipro_cn/Documents/powerbi文件夹/SingleTable.xlsx
②登录ODB网页
找到相应的文件,点击三个点-详细信息:
点击“更多详细信息”
点击这个位置的复制路径
得到文件路径
https://powerbipro-my.sharepoint.com/personal/xueqian_powerbipro_cn/Documents/powerbi文件夹/SingleTable.xlsx
你会发现这两种办法得到的文件路径是完全一致的。
2、在PowerBI Desktop中获取该文件
两个思路
①ODB中的文件本质上就是个需要登录才能打开的web网页,因此我们可以用web链接器来获取数据
在PowerBI Desktop中,获取数据-web
登录后看到数据已经获取到了,接下来的步骤与从本地获取Excel文件完全一致。
同样地,我们再获取同一个ODB中的另一个文件
简单制作一个可视化对象,保存发布。
到云端查看数据源凭证:
WTF?!
还是需要进行多次凭据的编辑!如果我有几十个文件的话,还是需要进行几十次重复工作!
这显然不是我们想要的
因此,该方法我们可以直接摒弃。
②我们换个思路,该文件是从ODB中获取的,而PowerBI有专门的ODB链接器
选择更多
我们选择SharePoint文件夹
提示让我们输入根URL
也就是截取以上文件路径中的一部分即可
https://powerbipro-my.sharepoint.com/personal/xueqian_powerbipro_cn/Documents/powerbi文件夹/SingleTable.xlsx
我们截取到Documents之前,即:
https://powerbipro-my.sharepoint.com/personal/xueqian_powerbipro_cn
选择Microsoft账户,点击
点击转换数据,发现整个ODB中的文件全都被列出来了,而且不会被文件夹组织。
我们可以通过筛选的方式将特定的文件给找出来
也可以用同样的方法获取其他文件,简单制作后,发布到工作区
我们发现数据源凭据只有一个SharePointlist,这正是我们想要的。
但是这种办法有2个问题:
为了解决这两个问题,我们找到了第三个办法
③使用SharePoint.Contents连接器
首先新建空查询
输入以下代码,并将自己的根URL填写进相应的位置
= SharePoint.Contents(
"不包含子文件夹的根URL",
[ApiVersion="AUTO"]
)
点击编辑凭据
仍然还是点击Microsoft账户并登录
获取数据后我们看到这个列表,找到documents这一行,点击table
展开后得到了ODB中根目录下所有的文件和文件夹结构
这样我们就可以通过点击导航的方式找到对应的文件夹和文件
我们在此处直接将显示根目录的这个查询保存下来,并取消加载,目的是为方便后续查找导入其他文件或文件夹时,可以直接右键此查询点击“引用”
然后在此查询基础上进行后续的操作。
这样,所有ODB中的文件获取都是以这个“ODB根目录”为数据源进行展开。
有朋友说,右键时选择“复制”是不是也可以?
我们可以设想,如果有几十个文件从ODB中获取,如果每一个都进行复制,那么就意味着每一个查询都将直接从ODB中获取一次数据,这是对算力的巨大浪费。
而如果都是“引用”,引擎只会从ODB查询一次。
孰优孰劣,一目了然。
而且通过对比我们发现,SharePoint.Contents比SharePoint.Files获取数据效率高很多,刷新速度要快不少。
我们在之前的文章中阐述过。
慎用SharePoint.Files,在Power BI中更快地刷新Excel文件
同时,SharePoint.Files无法对某个文件夹的所有文件进行获取,而SharePoint.Contents是可以实现的。
综上,我们在实际运用时,都是用SharePoint.Contents来获取ODB的文件
使用步骤我们也再重复一遍:
先获取ODB不包含子文件夹的根URL
再直接创建一个空查询,输入以下内容(替换成自己的URL)即可
= SharePoint.Contents(
"不包含子文件夹的根URL",
[ApiVersion="AUTO"]
)
二、切换本地文件数据源到ODB数据源
如果报告只是创建伊始,我们完全可以新建一个pbix文件从头开始来实现报告的重新制作,或是在原有的报告中删掉之前的表,以旧表名来建一些新表。
然而假设您已经从本地获取了大量的文件或文件夹,并且每一张表都进行了相当多的powerquery预处理,并制作完成了报告的大部分,且各个表之间还建立了错综复杂的关系。
那么,如果还是通过删除表创建新表的操作,会导致大量的重复工作甚至引起极大的关系错乱并导致度量值计算错误,更有甚者会导致报告中表丢失或文件损坏。
因此,我们希望,在从本地文件数据源迁移到ODB数据源的过程中,原来的所有表保持不变,原有的关系结构保持不变,原有的powerquery预处理过程与DAX建模过程都保持不变,即:
不改变模型结构。
而要实现这一点,我们需要仔细观察,认真思考
我们观察以下本地文件数据源的高级编辑器中的所有代码,查询1:
let
源 = Excel.Workbook(File.Contents("D:\\OneDrive - twpbi2022\\powerbi文件夹\\SingleTable.xlsx"), null, true),
表1_Table = 源{[Item="表1",Kind="Table"]}[Data],
删除的顶端行 = Table.Skip(表1_Table,5),
删除的列 = Table.RemoveColumns(删除的顶端行,{"客户名称", "性别", "年龄", "细分", "职业", "行业"}),
更改的类型 = Table.TransformColumnTypes(删除的列,{{"销售额", type number}, {"数量", type number}})
in
更改的类型
然后从“ODB根目录”引用出来一个新的查询,导航到SingleTable这张表并打开其中的"表1",查询2:
let
源 = ODB根目录,
powerbi文件夹 = 源{[Name="powerbi文件夹"]}[Content],
#"SingleTable xlsx" = powerbi文件夹{[Name="SingleTable.xlsx"]}[Content],
#"导入的 Excel 工作簿" = Excel.Workbook(#"SingleTable xlsx"),
表1_Table = #"导入的 Excel 工作簿"{[Item="表1",Kind="Table"]}[Data]
in
表1_Table
注意观察以上两个查询,[Data]之前的部分实现的目的完全一致。
那么,如果我们将“查询2”中的[Data]之前部分替换掉“查询1”中的[Data]之前部分,是不是就可以将数据源进行切换?答案是肯定的。
代码如下。
let
源 = ODB根目录,
powerbi文件夹 = 源{[Name="powerbi文件夹"]}[Content],
#"SingleTable xlsx" = powerbi文件夹{[Name="SingleTable.xlsx"]}[Content],
#"导入的 Excel 工作簿" = Excel.Workbook(#"SingleTable xlsx"),
表1_Table = #"导入的 Excel 工作簿"{[Item="表1",Kind="Table"]}[Data],
删除的顶端行 = Table.Skip(表1_Table,5),
删除的列 = Table.RemoveColumns(删除的顶端行,{"客户名称", "性别", "年龄", "细分", "职业", "行业"}),
更改的类型 = Table.TransformColumnTypes(删除的列,{{"销售额", type number}, {"数量", type number}})
in
更改的类型
而替换的过程直接在“查询1”中进行,替换的结果是“查询1”后续的步骤不发生任何改变,包括加载进模型之后与其他表之间的关系。
这一点尤为重要,即实现了:
不改变模型结构。
最终,经过不懈努力,我们将所有本地文件的数据源全都切换为ODB,重新发布后再到云端查看就会有如下的效果。
总结
本文通过讨论连接ODB文件的三种方式并比较它们的优劣,确定了今后在进行ODB文件获取时使用SharePoint.Contents连接器。在此基础上对原有的本地文件数据源进行切换,同时保证了整个模型的结构不发生改变。
不论从该 ODB 中获取多少个文件或者文件夹,数据源凭证这里永远只有一个,也就说,你只需要在第一次发布报告时配置好,那么以后任何时候再次发布报告,哪怕是发布其他的报告,也都无需再次配置凭据。
有很多公司可能会团队共同维护数据,需要设置共享盘,那么ODB就是一个绝佳的选择,单个用户1T或5T的空间,想必任何数据都可以满足要求。同一个组织内的用户之间通过共享文件和文件夹的方式进行配合实现组织的高效运转。
本文分享自 PowerBI生命管理大师学谦 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!