什么是增量刷新
所谓增量刷新,是指增量刷新数据。一般情况下,在PowerBI或PowerBI Desktop中点击【刷新】按钮,会将数据源的数据全部刷新一遍,如果数据源数据很多,而每次变化的很少,例如只有最近一日发生变化,那这种不问青红皂白就直接全部刷新的方法显然会耗时耗力。很可惜在默认情况下,PowerBI就只支持这种数据刷新方式。
随着2018年5月PowerBI的升级,Premium开始支持真增量刷新,本文来说明目前可以用来在PowerBI中实现增量数据刷新的技巧。
在PowerBI中实现增量刷新,目前有三种方法:
- 用 PowerQuery M 实现增量刷新,该方法有一定限制,属于假增量刷新。
- 用 DAX 实现增量刷新,该方法也有一定限制,属于假增量刷新。
- 用 Power BI Premium 实现增量刷新,该方法也有一定限制,但属于真增量刷新。
数据场景假设
假设这里有不断在更新的订单表,首先加载2011年到2013年数据,而每次数据刷新只刷新2014年数据,以下的方案应该如何实现呢。
用 PowerQuery M 实现增量刷新
用 PowerQuery M 实现增量刷新的核心技巧在于:查询的纵向合并。这里可以节省的时间在于网络传输的时间,方案如下:
- 首先将远程历史数据通过任何查询形式保存在本机。
- 查询本机历史数据再纵向合并远程的增量数据。
这样一来,每次历史数据的获取只是读取本机磁盘的时间,而不再产生网络传输的时间消耗,进而在一定程度上缓解了数据刷新的时间瓶颈问题。
再使用PowerQuery M的纵向合并表查询把几个查询合并成最终结果,完成增量刷新的效果。如下:
其中订单是由其他的订单数据合并而来,对应的PowerQuery M查询如下:
订单 = Table.Combine( { #"订单2011", #"订单2012", #"订单2013", #"订单2014" } )
可以把订单2011~2013的数据置于本地服务器或PC,在刷新时,虽然会全部刷新,但由于数据可以预先置于本地,则可以有效降低数据的网络传输时间。
另外,如果该模型发布到云端,显然都会有网络传输时间,但可以节省的是,数据在PQ中ETL的时间,可以预先将数据用PQ(或其他ETL工具)进行ETL后进行保存。在实际查询时会节省ETL的时间。
当然,这种方法并不是真正意义上的增量刷新,属于利用了PowerQuery或者说ETL可以缓冲数据存储的思想。
用 DAX 实现增量刷新
由于使用PowerQuery的方式实现假增量刷新是数据进入数据模型前,所以仍然要刷新所有数据,因此并没有降低模型对数据的吞吐量。在数据加载进入数据模型之后,我们也可以实现增量刷新的效果,使用DAX的UNION函数将多个表纵向合并即可。对此,我们设计的结构如下:
这里需要将订单2011~2014全部加载进入模型,但可以设置只有订单2014包含在报表刷新中,如下:
这样每次刷新数据的时候,只有最后一组订单数据(订单2014)会被刷新,如下:
用DAX实现合并的函数表达式如下:
这里面最后一行的FILTER一定会让人困惑不解。没错,不要这句也是没问题的,但它是为了解决下面这个问题了准备的。
有伙伴问到:如果一开始订单是正常加载的,那就无法被UNION了。没错,因为订单这个表名已经存在,以后再想UNION是没办法的。这时候可以尝试:
- 将原有订单拆分成增量加载形式。
- 删除加载的订单,此时数据模型会出现大量报错,因为没有了订单这个表。
- 用UNION的方式合成新表并命名为订单,并补足关系,理论上可以修复所有的错误。但在实际实践中,可能并不能修复所有错误,仍然有大量错误存在,这视具体实际情况而定。
因此,这种删除后重新用DAX计算表的方式弥补订单存在风险,务必备份数据。
一种未雨绸缪的做法是,在建模初期就预料到某些表会很大,可能需要增量加载,那可以直接使用计算表,但此时如果只有一个表怎么办,也就是说,必须实现一个表的UNION作为占位符。由于DAX的UNION函数必须至少有两个参数,且这两个参数必须都是列数一样的表,所以使用FILTER的这句技巧实际返回一个空表与前面的表合并,以起到占位符的作用,待有真正需要合并的表的时候,再做替换。
提示
当然,在只有一个表的时候使用计算表可以不用UNION以更加简单。
这样,就使用DAX的UNION实现了增量刷新的效果,并且该效果确实起到了增量加载数据,但根据DAX引擎的原理,整个数据模型会重建,仍需花费时间,这里省去了数据加载的时间,但无法省去模型重建的时间。另外的一个缺陷是,同样的数据在模型中保留了两份。
经过实际测试,该方法确实可以显著降低模型生成的时间,具体情况以实际为准。
用 Power BI Premium 实现增量刷新
Power BI 5月更新的预览功能中,已经给出了Power BI正统实现增量刷新的方法,但就是在Power BI Desktop只是进行设置,实际到Power BI Service的Premium专有容量中再进行实际阶段的增量加载,由于Power BI Premium允许单个数据模型可超过50G且数据存储达到100T(参考:Microsoft Power BI Premium 白皮书),这个量级的数据在本地PC或Power BI Desktop是无法进行的,而Power BI Premium却提供了这样的能力。如果在Power BI Desktop设置好增量刷新,效果如下:
其含义为:
- 将订单表增量刷新
- 存储最后3年的数据行
- 刷新最后1日的数据行
- 在检测到数据更改时触发刷新动作
在Power BI Desktop设计好后,发布的时候会看到:
由于设置了增量刷新,必须发布到含有Premium容量的工作区,否则是无法发布的。
很多伙伴会问,在你自己设置增量刷新的时候,不会成功,会提示这样的错误:
你会发现,无论你怎么设置参数都不对,这里有几个非常重要的细节需要指出:
- 必须在查询编辑中设置参数,且参数的数据类型必须是【日期/时间】,日期型也是不对的。
- 设置的参数必须起名为RangeStart和RangeEnd分别表示时间的开始和结束。参数名用别的也是不对的。
- 对需要增量更新的表,如:订单,让订单日期被上述的两个参数所筛选。
如下:
只有满足了以上设置,增量刷新才会乖乖出来给你用。
这种方法当然是真增量刷新,而且可以应对多达100T的数据存储以及单个100G的数据模型,这个能力非常强大,当然,为此付出的代价就是必须购买5K美金/月起步(注意:是起步,实际以定价估算计算器为准)的Power BI Premium服务。
但如果仔细算一笔账,其实这也并非绝不合理,5K美金/月大致为30000RMB/月,相当于一个IT工程师的月薪,而有了Premium,可以不再需要IT工程师来搭建和维护数据环境,这其实是相当的。而这个环境可以支撑多达100T的数据量级以及单个100G的数据模型,足以应付企业级数据分析需求。
总结
本文整体分析并实际演示了在Power BI中实现数据增量刷新的各种方法以及各自优缺点:
- PQ M 方法:简单且便于维护,但并非真正增量刷新,只能节省网络传输和部分ETL的时间。
- DAX 方法:可以在Power BI模型限制范围内部分降低数据加载时间,但要注意在项目开始引入以便避免后期问题。
- PowerBI Premium方法:终极的数据增量刷新方法,支持多达100T的数据存储以及单个数据模型可以超过50G且每天可以刷新48次,但费用昂贵,属于企业级解决方案。
【本案例包括案例示例文件以及视频详细说明,可订阅获取】