Power BI DirectLake × Power Apps/Automate：当数据可以自己动手
一、从"看数据"到"动数据"的鸿沟
数据进了 OneLake 之后，下一步是什么？
大部分团队会停在这里：Power BI 出了一堆报表，决策层看了两眼，邮件转发，结束。
但真正的价值在报表之外 —— 让业务团队能够直接在数据上动手：
- 前线销售想现场调价，能不能在手机上 30 分钟搞定？
- 产品经理要 Launch 新品，能不能不用找数据团队，自己拉数据出报告？
- 财务发现 GMV 异常，能不能一键开 ticket、@对的人、把流程跑完？
这就是 Power Platform (Power BI + Power Apps + Power Automate) 的真正威力 —— 数据从"被看"变成"被做"。
这篇文章拆解这套组合拳在生产环境的三种典型场景。
二、DirectLake：性能与新鲜度的最优解
在讲场景之前，先说一个关键技术 —— DirectLake。
2.1 Power BI 三种数据模式的对比
┌────────────────────────────────────────────────────────────────────┐
│ │
│ Import Mode DirectQuery DirectLake │
│ ────────── ──────────── ─────────── │
│ │
│ OneLake ──── ETL ────▶ Power BI Power BI │
│ Vertipaq ────────────────▶│
│ 特点： 特点： 直接读 Delta │
│ • 性能最佳 • 数据实时 特点： │
│ • T+1 刷新 • 性能最差 • 性能≈ Import │
│ • 占用内存大 • 查询压数据库 • 新鲜度秒级 │
│ • 适合报表 • 适合实时仪表盘 • 适合决策驾驶舱│
│ │
└────────────────────────────────────────────────────────────────────┘DirectLake = Import 的性能 + DirectQuery 的新鲜度。
它的原理很简单：Power BI 不再 import 数据，而是直接读 OneLake 上的 Delta/Parquet 文件。Delta 写入即查询，数据从源到 BI 报表延迟可以压到秒级。
2.2 DirectLake 的硬性条件
| 条件 | 说明 |
|---|---|
| Fabric Capacity | 必须有 Fabric Premium 或 F Capacity（P SKU 不够） |
| OneLake Delta 格式 | 数据必须是 Delta Lake 格式（不是 CSV） |
| Vertipaq 内存 | 单模型建议 ≤ 30 GB（过大时刷新慢） |
| 语义模型设计 | 字段命名清晰、关系简单，不要超过 50 张表 |
三、场景一：前线 BP 现场调价审批
3.1 痛点
某零售企业的前线 BP 在客户现场发现一个老客户长期下单金额低于标准价。调价流程过去是这样的：
BP 发现问题
│
▼
打电话给主管（经常打不通）
│
▼
发邮件申请（格式不规范经常被打回）
│
▼
主管审批 → 抄送区域经理
│
▼
IT 改系统报价（1-2 天）
│
▼
客户已经流失2-3 天，客户已经走了。
3.2 方案
┌──────────────────────────────────────────────────────────────┐
│ │
│ Power Apps Canvas Power Automate │
│ (BP 移动端) (审批流) │
│ ──────────── ──────────── │
│ ┌──────────┐ 提交 ┌─────────────────────────────┐ │
│ │ 表单： │ ───────▶ │ 1. 写 OneLake 调价申请表 │ │
│ │ • 产品 │ │ 2. Teams Card 通知主管 │ │
│ │ • 客户 │ │ 3. 主管 Adaptive Card 审批 │ │
│ │ • 新价格 │ │ 4. 批准 → 调用 BigQuery 更新 │ │
│ │ • 原因 │ │ 5. 通知 BP：调价已生效 │ │
│ │ • 影响 │ │ 6. 触发 Power BI Alert │ │
│ └──────────┘ └─────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘3.3 关键技术点
Power Apps 表单设计
screen: PricingRequestScreen
controls:
- type: ComboBox
name: ProductPicker
items: |
'LH_BigQuery_Mirror_Products' # Power Apps 直接连 OneLake Delta
fields: ["product_id", "product_name", "current_price"]
displayFields: ["product_name", "current_price"]
- type: ComboBox
name: CustomerPicker
items: 'LH_BigQuery_Mirror_Customers'
filter: 'Region = "Shanghai"' # 数据源预过滤
- type: NumberInput
name: ProposedPrice
validation: |
ProposedPrice >= ProductPicker.Selected.current_price * 0.7
errorMessage: "新价不能低于现价 70%"
- type: Button
name: Submit
onSelect: |
SubmitRequest.Run(
ProductPicker.Selected.product_id,
CustomerPicker.Selected.customer_id,
ProposedPrice.Text,
ReasonDropdown.Selected.value
)3.4 效果
| 指标 | 过去 | 现在 |
|---|---|---|
| 调价周期 | 1-2 天 | 30 分钟 |
| BP 申请等待时间 | 4-6 小时 | 即时 |
| 主管审批路径 | 邮件/电话 | Teams 内 1 键 |
| 客户流失率 | 高 | 显著下降 |
四、场景二：新产品 Launch 自动立项
4.1 痛点
每个新产品 Launch 都要做"市场规模 / 定价 / 风险评估"——过去是分析师手动跑 5 个 SQL、写 1 份 PPT、跨部门协调 3 天。
4.2 方案
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Trigger (Power Automate) │
│ ERP 系统新产品立项单创建 │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ Data Pipeline (Fabric) │ │
│ │ 1. 读 BigQuery 市场规模 / 竞品价 / GMV │ │
│ │ 2. 读 OneLake Monte Carlo 模拟结果 │ │
│ │ 3. 用 Power BI Paginated Report 出 PDF │ │
│ └──────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ Distribution │ │
│ │ • 邮件给管理层（PDF 附件 + OneDrive 链接） │ │
│ │ • Teams 频道通知 │ │
│ │ • 写回 OneLake「Launch_Decisions」表 │ │
│ └──────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘4.3 效果
| 指标 | 过去 | 现在 |
|---|---|---|
| 立项报告耗时 | 1 天 | 1 小时 |
| 数据口径一致性 | 各分析师自己跑 SQL | 统一从模型算 |
| 跨部门协调 | 3-5 次会议 | 邮件 + Teams 自动通知 |
| 历史可追溯 | 散落邮件 | OneLake 集中归档 |
五、场景三：定价异常自动告警
5.1 痛点
GMV 异常下跌时，谁发现？往往是月度复盘时，已经过去 30 天了。
5.2 方案
┌──────────────────────────────────────────────────────────────┐
│ │
│ Power BI Data Alert (每日 09:00) │
│ ──────────────────────── │
│ 条件：任何产品过去 7 天 GMV 跌幅 > 15% │
│ │ │
│ ▼ │
│ Power Automate │
│ ──────────── │
│ 1. 拉相关产品上下文（客户 / 渠道 / 区域） │
│ 2. AI 摘要：发生了什么、影响多大 │
│ 3. 推送到 Teams 渠道 + 邮件给定价团队 │
│ 4. 自动开 ticket #4521 │
│ 5. 通知：@PricingTeam 这款产品需要关注 │
│ │
└──────────────────────────────────────────────────────────────┘5.3 Power BI Alert 配置
data_alert:
name: "GMV 跌幅 > 15%"
semantic_model: PricingDecisionModel
measure: |
GMV_7d_drop_rate =
VAR current = [GMV_Last7Days]
VAR previous = [GMV_Previous7Days]
RETURN DIVIDE(current - previous, previous)
condition: GMV_7d_drop_rate < -0.15
scope: Products (per product)
schedule: daily_09:00
trigger_action: PowerAutomate_Flow_GMVAlert5.4 效果
| 指标 | 过去 | 现在 |
|---|---|---|
| 异常发现时间 | 30 天（月度复盘） | 当日 09:00 |
| 团队响应 | 邮件 + 会议 | Teams 直接处理 |
| ticket 流程 | 手动 | 自动开 |
六、Power Platform 的局限
再好的工具也有边界。Power Apps + Automate 不适合的场景：
❌ 复杂的领域逻辑
如果你的业务规则超过 20 个分支条件，写 Power Automate 就像写意大利面代码。该写代码就写代码（Azure Functions / Logic Apps Standard）。
❌ 高并发写入
Power Apps 每个表单提交触发一个 Flow，1000 个并发写入会撞限流。批量场景用 Fabric Data Factory。
❌ 长期持久状态机
调价审批、合同审批这种多步状态机，建议直接用 Dataverse + Power Automate + 自定义 Workflow，别硬塞 Flow。
❌ 跨租户数据共享
Power Platform 的连接器默认同租户，跨租户要么开 B2B、要么走中间层 API。
七、整体架构：一份语义模型 → 四个消费者
这套方案最值钱的设计原则是 "一份模型多端复用"：
Power BI Semantic Model
"PricingDecisionModel"
│
┌─────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
Power BI Power Apps Copilot Studio
Desktop/Service (前线 App) (AI 问答)
│ │ │
▼ ▼ ▼
决策层周会报表 现场调价 / 数据录入 Teams / Outlook
Paginated Power Automate 智能问答
Report
│
▼
Excel 透视 / 月度归档你维护一份语义模型，4 个场景用。这就是 Power Platform 真正的杠杆 —— 不是单个工具强，是协同强。
八、给数据团队的三条建议
如果你正在评估或已经用 Power Platform，结合生产经验给出三条：
1. 从"决策层"切入，不要从"一线 App"开始
很多团队一开始就做前线 App，结果一线 BP 不会用、用不起来。正确的顺序是：先做决策层报表（管理层用），证明数据可信；再做自动化流程（提效有数字）；最后才是一线 App。
2. 把语义模型当一等公民
模型即接口。模型建不好，所有下游都烂。投入懂业务 + 懂 DAX 的人来建模型，比堆报表更重要。
3. DirectLake 不是银弹
它性能好但对模型设计要求高。如果你的模型超过 50 张表、嵌套关系复杂，先用 Import 跑稳，再考虑 DirectLake。
九、总结
Power BI DirectLake 解决了数据新鲜度和性能的经典矛盾；Power Apps 让业务团队可以动手；Power Automate 把洞察变成动作。
三件套组合起来，让数据团队从"出报表的"变成"业务操作系统设计者"。
下篇预告：《Copilot Studio × Teams / Outlook：让 GenAI 真正落到前线工作流里》
AI 不再是 PPT，而是前线 BP 每天 @ 一个 Bot 就能拿到答案。