很多团队一提到 Microsoft Fabric，第一反应就是：F2 这种小容量能干嘛？ 跑个 Demo 都嫌卡，更别说承载一套完整的报表解决方案了。
但 FourMoo 的 Gilbert Quevauvilliers 做了一件反直觉的事——他在 F2 容量上完整搭出了一套端到端报表方案，从数据接入到最终可视化，全程没有升级 SKU。这套架构思路，对预算有限、又想验证 Fabric 落地可行性的国内团队，参考价值不小。
为什么选 F2 而不是 F64？
F2 是 Fabric 的入门级容量，算力和内存都非常有限。正常情况下，大家会直接上 F64 甚至更高，因为那才是「生产级」的起点。
但 Gilbert 的出发点很实际：
- 成本可控：F2 的月成本远低于 F64，适合做 PoC 和小规模生产
- 架构验证：如果架构本身设计得足够精简，小容量反而能逼出最佳实践
- 可平滑扩展：F2 上跑通的方案，后续按需扩容到 F4、F8 甚至更高，架构不用推倒重来
换句话说，F2 不是终点，而是验证架构合理性的最低成本试验场。
完整方案包含哪些环节？
这套报表方案覆盖了 Fabric 的核心工作负载，形成了一条完整链路：
- 数据接入层：通过 Data Pipeline 和 Dataflow Gen2 把源系统数据拉进 OneLake
- 数据存储层：使用 Lakehouse 作为统一的存储底座，Delta 格式落地
- 数据转换层：用 Notebook 做轻量级清洗和建模，避免过度依赖重型计算
- 语义模型层：基于 Direct Lake 模式构建语义模型，绕开传统 Import 模式的刷新瓶颈
- 报表展现层：Power BI 报表直接消费语义模型，实现近实时查询
关键设计取舍
在 F2 这种小容量上，每一个资源决策都会被放大，所以架构上必须做减法。
1. 优先用 Direct Lake，而不是 Import
Direct Lake 直接读取 OneLake 中的 Delta 表，省掉了数据复制和刷新过程，对 F2 的 CU 消耗更友好。这是整套方案能跑起来的关键。
2. 控制数据量级
F2 的内存和计算资源有限，数据表不能无限膨胀。方案中对事实表做了合理的聚合和分区，避免单表过大拖垮整体性能。
3. 转换逻辑尽量下推
能在 Lakehouse 层用 SQL 或 Notebook 完成的转换，就不要留到语义模型里做。语义模型越轻，F2 上的查询响应越快。
4. 刷新策略要克制
小容量下频繁刷新是灾难。方案里对刷新频率做了严格规划，只在必要时触发。
这套方案适合谁？
不是所有场景都该用 F2。这套架构更适合：
- 正在做 Fabric 可行性验证的团队
- 数据量中等、报表用户数不多的中小型业务场景
- 想先跑通架构、再按需扩容的渐进式落地路线
如果你的数据量已经到 TB 级、并发用户上百，那 F2 肯定不够，但这套「精简架构 + Direct Lake + 下推转换」的思路，在大容量上同样成立。
国内用户的启示
国内很多企业上 Fabric 时，卡在的不是技术，而是成本审批。F2 这种小容量起步的方案，正好能解决「先证明价值、再申请预算」的现实问题。
Gilbert 这套架构最大的价值不在于「F2 能跑」，而在于它证明了：Fabric 的落地不一定需要一步到位，架构设计得好，小容量也能撑起完整链路。
真正决定成败的，从来不是 SKU 的大小，而是架构是否足够精简、职责是否划分清晰。
