Back to essays

Power Platform · BI · Automation

Power BI DirectLake × Power Apps/Automate：当数据可以自己动手

2026-07-27 14 min read 系列文章 #2 of 3

Audio version · MiniMax TTS · male-qn-jingying

一、从"看数据"到"动数据"的鸿沟

数据进了 OneLake 之后，下一步是什么？

大部分团队会停在这里：Power BI 出了一堆报表，决策层看了两眼，邮件转发，结束。

但真正的价值在报表之外 —— 让业务团队能够直接在数据上动手：

前线销售想现场调价，能不能在手机上 30 分钟搞定？
产品经理要 Launch 新品，能不能不用找数据团队，自己拉数据出报告？
财务发现 GMV 异常，能不能一键开 ticket、@对的人、把流程跑完？

这就是 Power Platform (Power BI + Power Apps + Power Automate) 的真正威力 —— 数据从"被看"变成"被做"。

这篇文章拆解这套组合拳在生产环境的三种典型场景。

二、DirectLake：性能与新鲜度的最优解

在讲场景之前，先说一个关键技术 —— DirectLake。

2.1 Power BI 三种数据模式的对比

Comparison · 3 data modes

Import · DirectQuery · DirectLake

Import Mode

本地缓存

OneLake → ETL → Vertipaq

• 性能最佳

• T+1 刷新

• 占用内存大

• 适合报表

DirectQuery

实时查询

Power BI → DB → result

• 数据实时

• 性能最差

• 查询压数据库

• 实时仪表盘

Focal · DirectLake

直接读 Delta

Power BI ← Delta file

• 性能 ≈ Import

• 新鲜度秒级

• 不 import data

• 决策驾驶舱

DirectLake = Import 性能 + DirectQuery 新鲜度

Fig. 1 · Power BI 三种数据模式对比。Import 性能最佳但 T+1；DirectQuery 实时但性能差；DirectLake = Import 性能 + DirectQuery 新鲜度。DirectLake 是 focal — 这是 2026 年 Power BI 推荐的核心模式。

它的原理很简单：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 方案

Process · Power Apps + Power Automate

Price Copilot 调价审批流程

Step 1

Power Apps

Canvas Form

BP mobile · 移动端

表单字段:

• 产品

• 客户 + 新价格

• 原因 + 影响

Focal · Power Automate

审批流

pa-price-change-001

1. 写 OneLake 调价申请表

2. Teams Card 通知主管

3. Adaptive Card 审批

4. 批准 → BigQuery 更新

5. 通知 BP：调价已生效

6. 触发 Power BI Alert

Output

OneLake

pricing_audit_log

Delta table

append-only

Alert

Power BI Alert

data refresh alert

→ BP / 销售主管

Power Apps 表单提交 → Power Automate 6 步审批 → OneLake Delta 写 → Power BI Alert

Fig. 2 · Price Copilot 调价审批流程。Power Apps Canvas 表单 → Power Automate 6 步审批 → OneLake Delta 写 → Power BI Alert。Power Automate 是 focal — 整个流程的中枢。

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: TextInput
    name: CustomerNumber
    text: "客户编号 (SAP)"

  - type: NumberInput
    name: NewPrice
    min: 0.01
    precision: 4

  - type: Dropdown
    name: Reason
    items: ["续约", "促销", "竞品压价", "客户投诉"]

  - type: Slider
    name: ImpactEstimate
    min: 0; max: 100000
    unit: USD/年

Power Automate 6 步流程

Trigger: Power Apps (V2)
  → SharePoint: Append row (Approval log)
  → Teams: Post Adaptive Card to Sales Director
    → If approved:
      → BigQuery: UPDATE pricing_prod.customer_prices
      → OneLake: Write Delta audit_log
      → Teams: Notify BP (调价已生效)
      → Power BI: Trigger refresh alert
    → If rejected:
      → Teams: Notify BP (原因 + 主管备注)

效果对比：

指标	旧流程	新流程
调价时间	2-3 天	30 分钟
BP 等待	频繁打不通	Teams Card 实时通知
IT 介入	需要每次	零 IT（Power Automate 自动）
审计	邮件抄送	OneLake Delta append-only

3.4 优缺点

✅ 适合

调价 / 审批 / 工单类流程化操作
需要审计留痕（合规行业）
移动端为主（BP / 销售外出）

❌ 不适合

复杂计算（超过 Power Fx 能力）
超大数据量（> 10 万行表单）

四、场景二：产品经理自助 Launch 报告

4.1 痛点

产品经理要 Launch 一款新产品，需要：

3 个相似产品的历史销售数据
目标用户画像
类似产品的 ROI 曲线

过去至少等 3 天（找数据团队 → 拉数 → 跑 analysis → 出报告）。

4.2 方案

Self-service · Power BI + Semantic Model

Product Launch 自助报告

Step 1

Power BI

Semantic Model

PricingDecisionModel

公开数据集

+ 字段元数据

Focal · Self-service

产品经理

自助搭报告

1. 选 Dataset

2. 拖字段

3. 写 insight

4. 钉 Dashboard

5. 分享给 Stakeholder

Stakeholder

Launch 决策

CEO · CFO · CMO

实时访问

同源数据

Power BI Semantic Model (公开) → Product Manager 自助搭报告 → Stakeholder Launch 决策

Fig. 3 · Product Launch 自助报告。Power BI 公开 Semantic Model → 产品经理拖拽字段 30 分钟出报告 → 决策层同源数据看。数据团队从"做报告"变成"维护 Semantic Model"。

关键：Semantic Model 设计原则

字段命名 业务友好（不用 snake_case，用 Customer Price 而非 customer_price）
关系清晰 不要超过 50 张表，循环不超过 1 层
度量值 (Measure) 提前定义好（GMV · 客单价 · 复购率），不让 PM 自己写公式
权限行级安全 (RLS) — 一个 PM 只能看自己产品线的

4.3 优缺点

✅ 适合

稳定业务模型（字段定义不会每周变）
PM 团队 SQL / DAX 基础齐
需要快速迭代报告

❌ 不适合

数据源不稳定（每周加字段）
复杂 ML 预测（用 Databricks Notebook 更合适）

五、场景三：财务自动异常 + 工单闭环

5.1 痛点

财务早上打开 Power BI 看到 GMV 异常跌 30%。

过去流程：截图 → 邮件给运维 → 运维找数据团队 → 数据团队查 ETL → 找出问题 → 修复 → 通知。周期 4-12 小时，期间业务已经损失。

5.2 方案

Alert · Data refresh + Power Automate

GMV 异常 — 自动开 ticket + 通知

Trigger

Power BI Alert

"GMV" measure

Daily refresh

Δ vs 7-day avg

Focal · Power Automate

Open Ticket

pa-anomaly-flow

1. Get anomaly context

2. Open Jira ticket

3. @Data Engineer

4. Pin in Teams

Output

Jira + Teams

"[Auto] GMV 异常

-28% 2026-08-10

@data-eng-on-call

Power BI Alert Δ > 25% → Power Automate Open Ticket → Jira + Teams 通知

Fig. 4 · GMV 异常 — 自动开 ticket + 通知。Power BI Alert 触发 → Power Automate 创建 Jira ticket + @Data Engineer + pin in Teams。从 4 小时到 30 秒。

关键配置

// Power BI Alert rule (Semantic Model)
alert_name: "GMV Anomaly"
trigger_condition: |
  measure: GMV
  comparison: 7_day_rolling_avg
  threshold: -25%
  schedule: daily 09:00 CN
notify_via:
  power_automate_flow: pa-anomaly-flow

// Power Automate flow
trigger: Power BI Alert (Custom)
  → Compose: "Anomaly: {{alert_name}} Δ {{delta}}%"
  → Jira: Create Issue
    project: DATA
    type: Bug
    priority: P1
    description: "{{compose_output}}"
  → Teams: Post message in data-eng-oncall
    mention: @data-eng-on-call
  → Teams: Pin message in data-alerts channel

5.3 KPI 跟踪

指标	旧流程	新流程
检测到异常	4-12 小时	30 秒
建 ticket	人工	自动
通知相关人	邮件抄送	Teams @ + pin
数据团队介入	依赖人	直接 @ on-call

六、组合拳的代价

三套 Power Platform 全部用上的月成本（参考 OneLake + Power BI + Power Apps + Power Automate 标准价）：

组件	SKU	月费 (USD)
Fabric Premium F8	8 vCore × 8h/天	$5,300
Power Apps per user	20 用户	$200
Power Automate per flow	3 flow × 标准	$90
Power BI Premium	包含	—
合计		~$5,600 / 月

对一家中型企业（20 个 BP + 10 个 PM + 5 个财务）来说，5,600 美元/月撬动 3 套关键流程，ROI 显著。

七、避坑清单

坑 1：把 Power Apps 当成"低代码版 Jira"

Power Apps 适合数据驱动的轻表单。如果你已经用 Jira 跑流程，别硬搬过去。Power Apps + Power Automate 的核心价值是"数据触发 → 业务动作"形成闭环，不是替代项目管理工具。

坑 2：Power Automate 流设计得太复杂

每个 Flow 超过 30 个 action = 难以调试 + 性能差。拆成多个 Flow + 调用关系，每个 Flow 只做一件事。

坑 3：忽略 DirectLake 切换时数据加载慢

DirectLake 首次打开报表时需要从 OneLake 加载 Delta 文件元数据，第一次 5-10 秒。不是 Import 模式的秒开。要培训用户预期。

坑 4：Power BI 权限规划在最后做

Row-Level Security (RLS) 在 Semantic Model 建好就要规划。不要等上线了再补，那时候改一行可能影响几十个报表。

八、总结：组合拳的真正价值

Power Platform 不是"低代码工具"。它是让数据从"被看"变成"被做"的最后一公里 ——

Power BI：实时看数据（DirectLake）
Power Apps：业务团队自己动数据（不用数据团队）
Power Automate：把数据触发变成业务动作（自动 ticket/通知）

当数据可以从"看"变成"做"，数据团队的角色就从"做报告"变成"维护 Semantic Model + 治理"。这是 2026 年数据团队的最大机会。

下篇预告：《Copilot Studio × Teams / Outlook：让 GenAI 真正落到前线工作流》