PowerBI的活动日志记录了所有用户活动的完整记录，它包含了用户对PowerBI的各种资源（如报表、仪表板、数据集等）所执行的各种操作信息。对于企业合规性、安全监控和使用情况分析来说，活动日志是不可或缺的工具。 通过分析活动日志，就可以很方便的回答关于报表访问相关的问题，比如哪些报表最受欢迎、某个报表的访问用户量及访问趋势等等，也可以知道哪个用户在什么时候导出了数据或分享了报表等等。因此，活动日志对于企业的安全合规管理具有重要的作用。
Excel作为最常用的数据源之一，PowerBI自然也是支持的，但是在PowerBI Report Server上使用Excel等本地文件作为数据源则要更加注意。 因为直接使用Excel的本地文件路径的话，在本地开发中没有问题，但发布到PowerBI Report Server后是识别不了的，需要使用PowerBI Report Server能访问的共享网络路径才行。 PowerBI Report Server不像PowerBI Service，在PowerBI Service中可以通过安装网关来识别本地文件路径，但是PowerBI Report Server是没有网关的，也不支持OAuth验证方法，因此许多需要验证身份的Web路径也不支持，比如SharePoint或OneDrive上的Excel文件等，所以一般只能通过共享网络路径来访问本地文件。 因此，本篇文章将以Excel为例，介绍如何在PowerBI Report Server上使用Excel作为数据源并实现刷新。
虽然PowerBI Report Server上的计划刷新功能并没有次数限制，但如果想实现在数据源的数据更新后立马就触发刷新这种更精细化的控制，那还是做不到的。 但就像PowerBI Server可以通过REST API来刷新报表一样，PowerBI Report Server其实也有提供对应的REST API，因此也可以通过REST API来刷新报表，从而能够将报表刷新集成到ETL数据流等自定义应用的流程中，进而实现所需的功能。 因此，本篇文章将介绍如何通过REST API来刷新PowerBI Report Server上的报表，以实现更精细化的刷新控制。
PowerBI Report Serve就是常说的本地报表服务器，是安装和部署在自己的本地机器上的，很适合数据不能上云的企业使用。由于之前安装的本地报表服务器太久没使用，出了点无法解决的Bug，因此打算重新安装和部署，也借此机会记录一下过程。 注意，本地报表服务器的部署需要用到SQL Server数据库，关于该数据库的安装或部署请自行解决，本篇文章不做介绍。
在PowerBI中，创建不同的图表主要依靠不同的视觉对象，而除了内置的视觉对象之外，还有庞大的第三方视觉对象商店，目前已经有800多个第三方视觉对象。 虽然有PowerBI账号就可以在线导入第三方视觉对象，但是有些视觉对象可能会下架或在更新升级之后需要付费，因此保留一份离线版本的视觉对象文件也是很有必要的。 因此，本篇文章将分享一个第三方视觉对象的爬取工具，以便随时获取最新的视觉对象文件。
在PowerBI中发布报表时，对数据集的大小是有限制的，如果超过了限制就会报错。因此，本篇文章将给出对应的解决方案，以便能正常发布报表，并且不影响发布后的数据完整性。
在面对需要实时数据的场景中，抛开流数据集等特殊方案，常规的PowerBI报表的做法一般都是使用DirectQuery模式来获取数据。因为DirectQuery模式是直接连接到数据源的，报表上的任何计算或查询都会发送到数据源进行处理，然后数据源再把计算好的结果返回到报表，因此DirectQuery模式很适合用于大数据量或实时数据需求的场景。
在使用DirectQuery模式时，所有计算请求都会发送到数据源去计算，然后再把结果返回到PowerBI中显示。这时，如果因为数据源的性能比较慢或因为网络波动等情况，使得数据源返回结果的时间变长，就有可能会导致本地开发的速度变慢。 比如每调整一下度量值代码，或调整切片器、视觉对象所用字段等常用操作时，都需要先等DirectQuery的数据源进行计算，这可能需要很长时间才会有结果出来，就会导致开发节奏一卡一卡的，非常难受。 因此本篇文章将介绍一种方法来解决本地开发时遇到的DirectQuery数据源反应慢的问题，以便提升开发速度。
Dual模式可能很少有人用到，这个模式叫双模式，它集成了Import与DirectQuery的优势，既可以作为Import模式用于性能密集型查询，也可以作为DirectQuery模式用于实时或特定查询需求。主要用于解决混合模型下Import模式的表与DirectQuery模式的表之间的跨岛弱关系所带来的性能问题。
在大数据量且需要实时数据的场景下，使用直连模式（DQ，Direct Query）是比较好的选择，但使用DQ模式时需要格外注意它的一些注意事项，否则很容易就会遇到问题。
本篇文章将介绍一些可能会影响到计算资源的设置，以便解决未达到硬性资源上限时的内存不足的报错。当然，如果已经达到了硬性资源上限，那么怎么设置都是没用的，此时要么就是升级容量，要么就是减少数据量或优化模型的计算逻辑与表达式等。
在2025年9月份的更新中，PowerBI推出了DAX自定义函数功能，允许用户自行创建函数来实现代码重用或逻辑重用，然后可在任何度量值、计算列、计算表或查询等DAX表达式中进行调用，就像使用DAX语言本身的函数一样。
在PowerBI中并没有类似全局变量的东西，如果想在不同的度量值或计算列、计算表、查询等对象中引用同一段代码，那么就只能是把这段代码在每个计算对象中复制粘贴一份。但这样做的话，如果这段代码要进行修改，那么就要修改所有使用到了这段代码的度量值等计算对象，如果数量比较多，则不利于维护。 幸运的是，PowerBI中虽然没有全局变量，但可以借助 明细行表达式(Detail Rows Expression) 来达到同样效果。
前言 在2022年9月左右的更新中，DAX中新增了窗口函数这一个类别，推出了OFFSET、INDEX、WINDOW等窗口函数，并在后续的更新中又新增了新的RANK、ROWNUMBER这两个窗口函数。 窗口函数的出现简化了DAX中原本较复杂的...
本篇文章将继续介绍新出的跨事务任务流功能的应用案例，本次介绍的是在PowerBI报表中接入AI模型，实现实时对话，不仅可以读取报表的数据，并且还支持与切片器联动、更改AI模型、清除聊天上下文等。
关于数据回写的一个应用，即让用户可以在PowerBI报表中自定义备注信息，这个功能在之前的文章中已经分享过实现方案了，但之前的实现方案需要借助第三方的视觉对象，实现起来较复杂，且自由度和用户体验上还是差了一点。
Fabric用户数据函数其实是一个可以在Fabric上托管和运行的自定义API服务，与Azure Functions有点类似。 借助Fabric用户数据函数，可以轻松的根据自身需求来定制和创建API，并可以和Fabric或微软的其他服务集成，这种将整个生态打通所带来的体验是非常强大的。
PowerBI的计算组是一个很强大的功能，它能够批量更改度量值的计算逻辑，并提供了动态数据格式功能，能够帮助我们实现许多技巧，在某些场景下具有不可代替的作用。而在2025年5月18日的更新中，计算组又迎来了一次增强，新增的选择表达式能够对计算组的计算行为进行更精细的控制。
在2024年10月，PowerBI更新了一个名为“值筛选行为”的功能，目的是为了修复Auto-Exists机制中的Bug。但由于海量的报表已经运行在这个Bug的基础之上，影响范围过大，且Bug的行为相对稳定可重复，已经逐渐演变成了一个特殊的特性，所以官方决定不直接修复这个Bug，而是提供了名为“值筛选行为”的功能来间接修复。
在前面介绍自动匹配原理的文章中，有提到Auto-Exists机制本身就存在Bug，那么本篇文章就来探讨一下这个问题，而这个问题其实就是对度量值所处的计值环境的研究。
管理员必看：获取租户级PowerBI活动日志，轻松完成报表访问分析2025-11-22在PowerBI Report Server中使用Excel作为数据源并实现刷新2025-10-31通过REST API刷新PowerBI Report Server上的报表2025-10-29PowerBI Report Server的安装与部署2025-10-29PowerBI视觉对象爬取工具分享2025-10-27解决PowerBI数据集大小过大无法发布的限制2025-10-26借助PowerBI自动页面刷新功能实现大屏报表的实时数据展示2025-10-25巧用Dual存储模式提升DirectQuery模型的本地开发速度2025-10-24使用PowerBI的Dual存储模式优化跨岛弱关系的性能2025-10-24解决PowerBI中DirectQuery模式的100W查询行数限制2025-10-23PowerBI内存不足报错的解决方案2025-10-23PowerBI DAX自定义函数(UDF)的使用与介绍2025-09-27Operation don't support
