你知道吗？在 Fabric Dataflows Gen2 中，如果你的数据流包含多个查询，则可以在刷新时选择如何并行评估这些查询。本文将探讨如何进行这一设置，并分析其可能带来的性能提升。 我们从基础知识开始。我创建了一个包含十个查询的数据流，每个查询在一分钟后返回一个一列一行的表。
你知道吗？在 Fabric Dataflows Gen2 中，如果你的数据流包含多个查询，则可以在刷新时选择如何并行评估这些查询。本文将探讨如何进行这一设置，并分析其可能带来的性能提升。
我们从基础知识开始。我创建了一个包含十个查询的数据流，每个查询在一分钟后返回一个一列一行的表。使用 #table 函数生成表格而无需连接数据源，并采用该博客中的代码添加延迟，确保只有在刷新时才应用延迟（通过此方法）。每个查询的结果都加载到 Fabric 仓库中。
我使用默认设置刷新了数据流，在最近运行中发现整个流程花费了2分钟9秒。每个单独的查询耗时大约1分钟10秒至1分30秒，这与调优数据流时通常看到的10-30秒执行超时相吻合。我又进行了两次刷新，分别用时1分32秒和3分38秒。这些结果表明并发度是可变的，有时候所有查询可以并行评估，有时候只能部分并行。
我打开了数据流，在选项对话框中的 Scale 页签中勾选了“限制并发评估次数”复选框，并将滑块设置为1：
接下来，我再次刷新数据流。结果发现整个流程的用时缩短到了约1分25秒。
通过这种方式，你可以更好地控制并发度并优化性能。
微软正在把 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 语义模型上做了测试，数据来自纽约出租车样本。
