你是不是也遇到过这种情况：每次刷新 Power BI 报表，都要等上十几分钟甚至更久，生怕它卡住或超时？更别提刷新时消耗的 CU（容量单位）蹭蹭往上涨，老板问起来还解释不清。
如果你一直在用 Import 模式，那今天这篇内容就是为你准备的。
Fabric 推出后，Direct Lake 模式成了大家口中的“新宠”，但说实话，很多人用它只是因为“它很酷”，并不清楚它到底能解决什么实际问题。今天我们就来聊聊，Direct Lake 真正能帮你省时、省力、省钱的地方。
更快更便宜的“刷新”
先给个结论：Direct Lake 的刷新（官方叫“framing”）几乎是瞬间完成的，消耗的 CU 也微乎其微。
但别急着高兴——它并不是完全替代 Import 模式。你需要先把数据加载到 OneLake 里，然后 Direct Lake 才能直接查询 Lakehouse 中的数据，省去了传统 Import 模式下将数据从源复制到模型中的过程。
关键对比点：
- Import 模式：刷新慢、CU 消耗高，尤其当数据量大的时候
- Direct Lake 模式：刷新快、CU 低，但需要额外在 OneLake 中准备数据（比如建 Gold 层表）
实际上，很多场景下用 Spark 或其他 Fabric 引擎把数据加载到 OneLake 的 Gold 层，比直接做 Import 刷新要更快、更省 CU。比如，加载 2000 万行的事实表，Spark 的成本只有 Import 模式的一半，速度还略快。
当然，这不是绝对的。你要考虑刷新频率、是否用增量刷新、分片策略等。但至少值得你做个测试，看看在你的项目中 Direct Lake 是否真的更优。
更简单的数据准备流程
使用 Direct Lake 模式后，你不需要再在 Power BI 里做复杂的 M 查询或数据清洗。
为什么？因为数据在进入 OneLake 之前，就已经用 Spark、数据流 Gen2 或 Notebook 处理好了。这意味着：
- 开发责任左移：数据工程师在湖里就把活干完了，BI 开发者只需要专注于建模和报表
- 减少 Power BI 专属技能依赖：不需要再学复杂的 M 语言或 Power Query 高级技巧
- 团队协作更清晰：数据工程师和 BI 分析师各司其职，不再互相推诿
举个例子：以前你可能需要在 Power Query 里写一堆合并、分组、筛选的 M 代码，现在这些逻辑可以在 Spark 中用 SQL 或 Python 完成，然后直接加载到 Lakehouse 中。
实时性更强
Direct Lake 的另一个核心优势是：数据延迟更低。
Import 模式下，你必须等刷新完成才能看到最新数据；而 Direct Lake 模式下，只要 OneLake 中的数据更新了，报表就能立刻反映出来。
这对于需要近实时分析的场景（比如监控、运营仪表板）来说，简直是救命稻草。
但也要注意几点
Direct Lake 不是万能的，它也有自己的限制：
- 查询性能可能略低于 Import：特别是当数据量非常大、或者没有做好 VOrder 优化时
- 需要额外的数据准备成本：在 OneLake 中建 Gold 层表也需要时间和 CU
- 不支持所有 DAX 函数：某些高级计算可能无法在 Direct Lake 模式下使用
所以，最佳实践是：根据场景选择合适的模式。
- 如果你的数据量小、刷新频率低、对实时性要求不高，Import 模式依然很香
- 如果你需要频繁刷新、要求低延迟、团队已经具备数据工程能力，Direct Lake 值得投入
国内用户怎么看？
在国内，很多企业还在用 Import 模式，因为 Power BI 的 Capacity 成本不低，而且很多团队缺乏数据工程能力。但如果你已经在用 Fabric，或者正在计划迁移，那 Direct Lake 的优势会越来越明显——尤其是对于那些需要“数据分钟级更新”的业务场景。
一句话总结： Direct Lake 不是要取代 Import，而是给你多一个选择。在刷新效率、数据准备流程和实时性上，它确实能带来实实在在的改进。
