在上一篇系列文章中，我展示了 Fabric Dataflows Gen2 中的并发设置如何影响包含多个查询的数据流的刷新性能。在这篇帖子中，我们将探讨启用分区计算（Partitioned Compute）后，该设置如何进一步影响单个查询的数据流性能。
在上一篇系列文章中，我展示了 Fabric Dataflows Gen2 中的并发设置如何影响包含多个查询的数据流的刷新性能。在这篇帖子中，我们将探讨启用分区计算（Partitioned Compute）后，该设置如何进一步影响单个查询的数据流性能。
为了验证这一点，我在数据流中创建了一个只有一个查询的数据流，并使用了我今年早些时候发布的那篇文章中的查询版本。这个查询返回一个包含十行的表，并在每行上调用一个内置延迟为 60 秒的函数。
开启分区计算和默认并发设置后刷新此数据流：
刷新该数据流花费了一分钟四十七秒：
通过对比，我们可以看到启用分区计算后，单个查询的数据流刷新性能有了显著提升。这说明了在设计和优化数据流时，不仅要考虑并发设置，还要关注分区计算的使用。
对于国内用户来说，理解并合理利用这些技术可以大大提高日常数据分析的工作效率。
微软正在把 Power Query 连接器的底层驱动从 ODBC 迁到 ADBC，这次轮到 Databricks。适用于 Power BI 和 Microsoft Fabric 的 Databricks ADBC 连接器已正式 GA(Generally Available，正式发布)。
距离上一次九月更新才过去没多久，而且当时还赶上了欧洲 Microsoft Fabric + SQL 社区大会，更新量已经不小。
微软正在对 Amazon Redshift 连接器进行重要升级，底层驱动将从旧版切换至全新的 Amazon Redshift ODBC 2.x。
很多团队一提到 Microsoft Fabric，第一反应就是：F2 这种小容量能干嘛？ 跑个 Demo 都嫌卡，更别说承载一套完整的报表解决方案了。
做 DAX 性能优化的人，看到 `APPROXIMATEDISTINCTCOUNT` 这个新函数，第一反应多半是：终于有办法治 `DISTINCTCOUNT` 这个性能杀手了。 但最近一轮实测下来，结论有点打脸——在某些场景下，近似去重反而比精确去重更慢。
9 月 Power BI 更新后，Import 模式和 Direct Lake 模式的语义模型开始支持 `ApproximateDistinctCount()` 这个 DAX 函数。 我在一个 14 亿行的 Direct Lake 语义模型上做了测试，数据来自纽约出租车样本。
