Power BI 数据流：集中数据准备

每个 Power BI 环境最终都会出现相同的问题：数十个报告，每个报告的“相同”数据准备逻辑的版本略有不同。在销售仪表板中以一种方式清理和标准化客户数据，在营销报告中略有不同，在执行摘要中也有所不同。当源系统发生变化时——重命名列、添加新区域——单独更新每个报告是维护的噩梦。

Power BI 数据流通过将数据准备从单个报表文件 (Power BI Desktop .pbix) 移动到 Power BI 服务中的共享集中层来解决此问题。任何开发人员都可以在数据流中编写一次逻辑，并获得一致的结果。本指南涵盖数据流架构、实施模式以及使数据流成为受管理的 Power BI 环境基础的高级功能。

要点

• 数据流将 Power Query ETL 逻辑集中在 Power BI 服务中，消除了报告之间的重复
• 数据流生成多个报告从单一来源使用的标准化实体（表）
• 链接实体允许数据流引用其他数据流中的表，从而实现分层架构
• 计算实体在 Premium 数据流引擎内对链接实体执行转换
• Microsoft Fabric 中的 Dataflow Gen2 通过暂存和输出目标扩展了数据流
• AI 洞察（高级）将 ML 模型应用于数据流输出 - 异常检测、情绪分析、关键短语提取
• 数据流的增量刷新使大型转换输出保持最新状态，而无需完全重新处理
• 数据流治理通过工作区权限控制谁可以创建、编辑和使用数据流

---

为什么存在数据流

要理解数据流，可视化它们解决的问题会很有帮助。

没有数据流（常见模式）：

• 开发人员 A 构建报表 1，连接到 Salesforce，编写 40 个 Power Query 步骤来清理和转换数据
• 开发人员 B 构建报表 2，也连接到 Salesforce，编写 38 个类似的 Power Query 步骤（略有不同）
• 开发人员 C 构建报告 3，相同来源，45 个步骤
• Salesforce API 凭据存储在三个不同的文件中
• “客户细分”分类逻辑以三种略有不同的方式实现
• 当API发生变化时，需要更新三个文件
• 所有三个报告都针对 Salesforce API 运行自己的计划刷新

使用数据流：

• 数据工程师使用 40 个 Power Query 步骤构建一个数据流
• 报告 1、2 和 3 都连接到数据流实体作为其数据源
• 一份 API 凭证、一份转换逻辑、一份计划刷新
• 当API更改时，更新一个数据流

这是基本的价值主张：数据流是源系统和消费报告之间的 ETL 层。

---

数据流架构模式

精心设计的数据流架构遵循类似于数据仓库奖章架构的分层模式：

青铜层（暂存数据流）：通过最小的转换从源系统中提取数据 - 重命名列、修复类型、过滤明显无效的记录。该层以标准化格式捕获原始数据。

银层（核心数据流）：应用业务逻辑 — 计算派生字段、应用参考数据查找、删除重复记录、应用特定于组织的业务规则。该层生成每个业务实体的规范表示。

黄金层（报告数据流或语义模型）：特定分析用例的聚合和结构数据 - 预先计算的聚合、特定于报告的度量、时间段计算。

在 Power BI 中，链接实体连接这些层：银牌数据流使用链接实体引用铜牌数据流中的实体。 Gold 层引用 Silver 实体。报告连接到黄金层实体。

这种架构意味着：如果源系统发生变化，只有铜级数据流需要更新。白银的业务逻辑和黄金的报告结构保持稳定。

---

创建您的第一个数据流

数据流是在 Power BI 服务（而不是 Power BI Desktop）中创建的。导航到工作区 → 新建 → 数据流。

数据流编辑环境是 Power Query Online — 本质上与 Power BI Desktop 相同的 Power Query 界面，但在浏览器中运行并在 Microsoft 的云基础设施中执行。

第 1 步：定义数据源

单击“添加新实体”→ 选择连接器。所有 Power BI Desktop 连接器都可在数据流中使用，此外还有一些云本机连接器（Azure 数据工厂集成等）。

对于 SQL Server 源：

Server: your-server.database.windows.net
Database: YourDatabase
Authentication: Organizational account or service principal

第 2 步：编写转换查询

Power Query 界面呈现熟悉的内容：应用步骤、公式栏和预览。完全按照 Power BI Desktop 中的方式构建转换逻辑 - 筛选行、重命名列、与引用表合并、应用自定义逻辑。

对于客户数据标准化查询：

let
    Source = Sql.Database("server", "db"),
    Customers = Source{[Schema="dbo", Item="Customers"]}[Data],
    FilteredActive = Table.SelectRows(Customers, each [Status] = "Active"),
    RenamedColumns = Table.RenameColumns(FilteredActive, {
        {"cust_id", "CustomerID"},
        {"cust_nm", "CustomerName"},
        {"seg_cd", "SegmentCode"}
    }),
    SegmentLookup = Table.Join(
        RenamedColumns, "SegmentCode",
        SegmentDefinitions, "Code",
        JoinKind.LeftOuter
    ),
    RemovedDuplicates = Table.Distinct(SegmentLookup, {"CustomerID"})
in
    RemovedDuplicates

步骤 3：配置刷新计划

设置数据流刷新计划（高级版中每天最多 48 次，专业版中每天最多 8 次）。数据流刷新针对源运行转换查询，并将结果写入由 Power BI 管理的 Azure Data Lake Gen2 存储。

步骤 4：将报告连接到数据流

在 Power BI Desktop 中：获取数据 → Power Platform → Power BI 数据流 → 导航到工作区 → 选择实体。该报告连接到数据流实体的存储输出，而不是源系统。

---

链接和计算实体（高级）

链接实体允许一个数据流引用另一数据流中的实体。 This is how the layered architecture described above is implemented.

创建链接实体： 在白银数据流→新建实体→链接其他数据流中的实体→选择青铜实体。

链接实体在白银数据流中显示为指向青铜数据流输出的虚拟表。您可以在链接实体之上添加其他转换步骤 - 这些附加步骤在数据流引擎中执行，而不是在源中执行。

计算实体是应用了附加 Power Query 转换的链接实体。它们在 Premium 数据流引擎的内存处理中执行，而不是在源中执行，为大型数据集上的复杂转换提供了显着的性能优势。

主要区别：

• 没有 Premium：链接实体引用其他数据流的数据，但所有处理都在针对源的查询时发生
• 使用 Premium（计算实体）：链接实体的转换使用缓存数据（而不是源数据）在 Power BI 的分析引擎中运行 — 复杂转换的速度显着加快

这对于在源处运行成本高昂（跨大型表、聚合、窗口函数的联接）但需要在数据到达报告之前进行的转换特别有价值。

---

数据流的增量刷新

与数据集一样，数据流支持增量刷新以仅处理新的和更改的记录，而不是在每个周期重新加载所有数据。

要求：

• 高级工作空间
• 源查询中的日期时间列
• 数据流查询中定义的 RangeStart 和 RangeEnd 参数

配置与数据集增量刷新相同：定义参数、在查询中应用日期过滤器、在实体上配置增量刷新策略。数据流引擎创建覆盖历史窗口的分区，并在每个周期仅刷新最近的窗口。

数据流的增量刷新在以下情况下最有价值：

• 转换的计算成本很高，您不想在未更改的历史数据上重新运行它们
• 由于表大小较大，源查询速度很慢，限制查询窗口会大大减少获取时间
• 存储成本很重要——增量分区允许历史数据保持存储而无需重新查询

对于大多数中小型数据流（低于 1000 万行），完全刷新更简单且足够。当刷新时间超过 30-60 分钟时，增量刷新就变得很重要。

---

数据流中的 AI 见解（高级）

Power BI Premium 数据流包括 AI Insights - 可直接在 Power Query Online 中使用的预构建机器学习功能。

可用的人工智能功能：

这些函数在 Power Query 编辑器中作为自定义列转换进行调用。 customer_comments 列上的情绪评分步骤：

= Table.AddColumn(Source, "Sentiment", each
    TextAnalytics.SentimentScore([CustomerComment]),
    type number
)

AI功能在后台调用Azure认知服务；结果（从 0 到 1 的情绪分数）显示为新列。这可以丰富数据集，而无需单独的数据科学管道。

---

数据流治理和安全

作为中央数据准备层，数据流需要治理控制来确保质量并防止未经授权的更改。

工作区权限控制谁可以创建和编辑数据流。数据流创建需要贡献者或管理员访问工作区。使用者（连接到数据流的报表开发人员）仅需要查看者访问权限。这种角色分离可确保青铜层和白银层中的业务逻辑由授权数据工程师维护。

认证将数据流标记为经中央机构批准。经过认证的数据流在 Power BI Desktop 的数据源选择器中突出显示，引导报表开发人员访问权威的、受管理的数据源，而不是从头开始构建自己的数据源。

敏感度标签 将 Microsoft Purview 信息保护标签应用于包含敏感数据的数据流。包含 PII 的数据流会收到“机密”标签，该标签会级联到使用该数据流的任何报告。

Power BI 管理门户中的数据沿袭 显示从源 → 数据流 → 数据集 → 报表的流程。当源系统发生变化时，数据沿袭有助于识别所有可能受影响的下游报告。

监视数据流刷新：Power BI 的管理门户显示数据流刷新历史记录、持续时间和失败。通过 Power Automate 针对失败的数据流刷新设置警报可确保立即捕获数据新鲜度问题，而不是在用户报告陈旧数据时才发现。

---

数据流与数据仓库

数据流并不是专用数据仓库的替代品——它们是一个补充。了解各自适合的位置可以防止架构错误。

具有成熟数据工程实践的组织应使用数据仓库作为主要转换和存储层，将数据流作为 Power BI 特定逻辑的可选轻量级转换。没有数据工程资源的组织通常会发现数据流足以满足他们的需求，而无需单独的仓库。

---

常见问题

Power BI 数据流和 Power BI 数据集有什么区别？

数据流是 ETL/数据准备层 - 它们提取、转换数据并将其作为表（实体）存储在 Azure Data Lake 中。数据集（语义模型）是分析层——它们在存储的数据之上定义度量、层次结构、关系和安全性。常见模式：数据流准备和存储干净数据→从数据流导入数据集并添加分析逻辑→报告连接到数据集。它们在架构中扮演不同的角色。

我需要 Power BI Premium 才能使用数据流吗？

Power BI Pro 工作区提供基本数据流。 Premium（或 Fabric）添加了计算实体、AI 见解、增量刷新和增强的性能。对于大多数中小型组织来说，Pro-tier 数据流就足够了。当转换量很大、需要丰富 AI 或需要增量刷新时，高级功能就变得很重要。

我可以将非 Power BI 工具连接到数据流数据吗？

是的。 Power BI 数据流以 CDM（通用数据模型）格式将其输出存储在 Azure Data Lake Gen2 中。拥有 Premium 或 Fabric 的组织可以将数据流配置为使用自己的 Azure Data Lake 帐户，从而使其他工具（Azure Synapse Analytics、Azure Databricks、Python、Tableau）可以访问 parquet 文件。这种“自带湖”配置在 Premium 和 Fabric 工作区中可用。

数据流如何处理数据源凭证管理？

数据流中的数据源凭据存储在 Power BI 服务中并由工作区管理员管理。这是对报告级凭据的改进 - 不再是每个报告开发人员都将凭据存储在其 .pbix 文件中，而是针对数据流集中管理凭据。建议对自动化生产数据流使用服务主体（Azure AD 应用程序）身份验证，而不是在用户离开组织时过期的个人用户凭据。

数据流可以调用REST API或非标准数据源吗？

是的。数据流使用与 Power BI Desktop 相同的 Power Query 连接器生态系统，包括通过 Web 连接器、自定义连接器（.mez 文件）和函数连接器的 REST API 连接器。可以在数据流中定义自定义 M 函数以封装 API 逻辑。复杂的 API 分页、身份验证流和速率限制都可以在数据流环境中的 Power Query 中处理。

---

后续步骤

数据流是可扩展、受管控的 Power BI 分析环境的基础。尽早投资正确的数据流架构可以防止数百个互不关联的报告以及重复的、不一致的数据准备逻辑带来的技术债务。

ECOSIRE 的 Power BI 数据建模服务 包括数据流架构设计、分层铜-银-金数据准备模式的实现以及治理配置。联系我们以评估您当前的环境并设计适合您的组织的数据流策略。