Power BI 实现规划：规划和设计内容

注释

本文是 Power BI 实现规划 系列文章的一部分。 本系列重点介绍如何在 Microsoft Fabric 内实现 Power BI 体验。 请参阅 系列简介。

本文帮助你在管理内容生命周期过程中规划和设计内容。 主要面向以下对象：

• 卓越中心（COE）和 BI 团队：负责监督组织中的 Power BI 的团队。 这些团队包括决定如何管理 Power BI 内容的生命周期的决策者。
• 内容创建者和内容所有者：创建要发布到 Fabric 门户的内容以与他人共享的用户。 这些人员负责管理其创建的 Power BI 内容的生命周期。

生命周期管理包括用于处理内容创建到最终停用的过程和做法。 如 本系列第一篇文章中所述，管理 Power BI 内容生命周期对于确保向业务用户交付内容可靠且一致非常重要。

内容生命周期的第一个阶段是规划和设计内容。 通常通过执行 BI 解决方案规划来启动内容生命周期。 你 收集要求 ，以了解并定义解决方案应解决的问题，并到达解决方案设计。 在此规划和设计阶段，你可以做出关键决策，以便为后续阶段做好准备。

下图描绘了 Power BI 内容的生命周期，其中突出显示了规划和设计内容的第一阶段。

注释

有关内容生命周期管理的概述，请参阅本系列的第一篇文章。

小窍门

本文重点介绍与生命周期管理相关的内容规划和设计的关键注意事项和决策。

• 有关如何 有效地规划和设计 Fabric 或 Power BI 解决方案的详细信息，建议阅读 解决方案规划 文章。
• 有关如何 有效地规划 Power BI 迁移的详细信息，建议阅读 Power BI 迁移 系列。

收集要求时，应清楚地描述影响生命周期管理方法的内容的各个方面。 应将这些方面记录为解决方案规划和设计的一部分。

本文中的以下部分介绍了解决方案的关键方面和注意事项，这些方面和注意事项将激励你在规划和设计内容时采用生命周期管理的方法。

识别和描述内容

设计解决方案时，应描述内容是什么、创建内容的人员、谁将支持它，以及此内容对组织而言有多重要。 你应该在收集要求作为你解决方案设计的一部分期间或之后解决这些因素。

注释

与你的要求一样，在开发解决方案时，这些问题的解答可能会发生变化，或者以后在解决方案的生命周期中会发生变化。 回答这些问题后，请在对内容进行更改或随着服务的用户数量增加时，做好定期重新评估它们的准备。

回答以下有关内容的问题，以帮助做出以后的生命周期管理决策。

内容的格式是什么？

内容的类型、范围和复杂性促使你如何管理内容的关键决策。 例如，针对有限受众的报表需要一种不同的生命周期管理方法，而一个语义模型则会被整个组织和多个下游工作流使用。

回答如下问题，帮助你确定要创建的内容类型。

• 预期要创建的项类型以及每个项类型有多少？ 例如，是否会创建数据流或语义模型、报告报表或仪表板等数据项或两者的组合？
• 内容如何传送给内容使用者？ 例如，使用者是否会使用数据项来生成自己的内容，他们是否仅查看集中式报表或两者的组合？
• 内容有多复杂？ 例如，它是一个小原型，还是包含多个业务流程的大型语义模型？
• 你预计内容的规模、范围和复杂性会随着时间推移而增长吗？ 例如，内容将来会包含其他区域或业务区域吗？
• 你期望企业需要此内容多长时间？ 例如，此内容是否支持具有有限时间线的业务的关键计划？

小窍门

请考虑制作体系结构图来描述内容的格式。 可以包括不同的数据源、项类型和内容使用者，以及这些离散组件之间的关系。 体系结构关系图有助于简明地描述内容及其复杂性，并有助于规划其生命周期管理。 可以使用 Fabric 图标 和 Azure 图标 在外部软件中创建这些关系图。 或者，可以使用带有图标和绘图工具的 Azure 关系图来制作这些关系图。

有关此类关系图的示例，请参阅 Power BI 实现规划 使用方案图。

谁将创建和支持内容？

内容创建者的需求、技能和工作流各不相同。 这些因素将影响不同生命周期管理方法的成功。 与小型自助服务创建者团队相比，具有协作的大型中心团队通常需要更复杂的内容生命周期管理。

回答如下问题，帮助你确定谁将创建或支持内容。

• 希望创建此内容的不同个人有多少？ 多个内容创建者会进行协作，还是单个负责创建内容的个人？
• 内容创建者是否熟悉生命周期管理和相关概念，例如版本控制？ 内容创建者是否了解生命周期管理的好处？
• 开发解决方案的内容创建者是否会是部署后支持解决方案的人员？
• 内容创建者或其团队是否有现有的生命周期管理做法来支持现有解决方案？
• 内容创建者当前是否使用 Azure DevOps 等生命周期管理工具？

重要

确保明确记录负责创建内容的人员，并在内容部署到生产环境后支持该内容的人员。 在内容生命周期管理规划中涉及所有这些人员。

内容的重要性是什么？

根据内容对业务的重要性，你将就如何管理内容做出不同的决策。 业务关键内容需要更可靠的内容生命周期管理方法来保护质量并缓解可能的中断。

回答如下问题，帮助你确定内容是否至关重要。

• 此内容对业务有多重要？ 开发这个请求的紧迫性有多高？
• 业务关键决策或行动是否将基于此内容所提供的信息？
• 你期望分发此内容的范围有多广泛（从整个组织到有限的本地团队）？
• 高管或其他战略决策者会依赖此内容来工作吗？
• 此内容的影响是什么？ 例如，如果内容突然不可用，会发生什么业务影响，例如收入损失或业务流程中断？

在充分识别并描述要创建的内容时，接下来应决定内容创建者应如何协作。

确定用户如何使用内容

在 Power BI 中，用户可以使用多种不同的方式来使用内容，包括语义模型和报表。 根据用户访问和使用此内容的方式，你需要对其设计以及开发方式做出不同的决策。 其中一些决策可以极大地改变你如何制作内容，以及花费多少时间和精力。 通常，人们使用模型和报表的方式越不同，记住的注意事项越多，生成的开发成本就越高。

使用和重复使用语义模型

语义模型可以说是 Power BI 和 Fabric 中最重要的项类型，因为用户可以使用许多不同的下游方法和项来使用这些类型。 如果只分发报表，则你将做出截然不同的设计决策，因为用户何时将各种项目连接到模型以执行自己的分析或完成自己的目标。

可以使用以下下游项类型重新使用共享语义模型：

• Power BI

  • 报表
  • 分页报表
  • 记分卡
  • Excel（在 Excel 数据透视表中分析）
  • 语义模型（复合模型）

• Microsoft Fabric

  • 激活器 （以前反射）
  • AI 技能
  • 副驾驶员
  • 探索
  • 指标集
  • 笔记本 （通过 Semantic Link 和 semantic-link-labs 库）

以下部分概述了将语义模型用于其中一些项时的重要注意事项。

注释

仅当启用相关的租户设置时，这些选项中的许多选项才可用。 确保使自己熟悉租户设置，以了解可以使用哪些消费方法在您将发布语义模型的工作区中。 如果这些选项仅限于特定的安全组，请确保确定用户是否属于这些安全组（或应该属于）。

报告

可通过多种不同的方式通过报表与语义模型交互：

• 查看报表。 标准方案，用户在报表中查看分发或与之共享的数据。
• 连接到语义模型并创建新报表。 使用 生成权限，用户可以在 Power BI Desktop 或 Power BI 服务中创建新报表。 此报表与共享语义模型有实时连接。 用户还可以通过使用 DirectQuery 将实时连接报告转换为新的复合语义模型，该模型查询原始数据。
• 从现有报表可视化中创建探索。 借助构建权限，用户还可以选择受支持的视觉对象来探索其数据。 这会创建一个新的浏览项目，允许用户添加字段或更改格式设置。 如果用户符合许可、工作区成员资格和项目权限所需的条件，则可以保存和共享生成的探索结果。
• 个性化报表视觉对象，用户可以在其中更改字段和格式设置。个性化视觉对象 的工作方式类似于浏览，但它只需要读取权限，并且不创建新项。 个性化的可视化还利用用户应用于报表页的所有视角，从而限制用户可以查看和使用的字段。

各种方案会为你的语义模型提供一些需要注意的事项，例如：

• 要向用户授予哪些权限，以及管理这些权限的方式。 建议用户在获取 生成权限之前完成培训。
• 您是否会向模型添加视角。 只能在 Power BI Desktop 中使用 TMDL 视图或使用其他第三方工具添加透视。 建议在用户使用个性化视觉对象或复合模型时添加透视。
• 应在模型中隐藏哪些字段，以及是否需要启用表的 IsPrivate TOM 属性以避免表或其子对象显示为建议。 请注意，只能在模型元数据文件（如 .bim 或 .tmdl）上使用外部工具或 Power BI 服务中发布的远程模型来设置 专用 TOM 属性。
• 如何记录模型，以及该文档应包含的内容。 我们建议你制定针对特定用例定制的文档，并包括相关和有用的信息，而不是导出模型元数据（如 DAX 度量值表达式），这通常对最终用户没有用。
• 你如何建议用户在不同方法之间进行选择。

谨慎

向语义模型授予读取或生成权限后，用户可以使用本节中所述的方法查询模型中的任何表或列。 即使未在报表中公开该表、度量值或列，也是如此。 确保始终使用数据安全性保护敏感数据，或将其从模型中排除。 这样，就可以避免无意中向错误的人公开敏感信息。

Excel （在 Excel 数据透视表中分析）

如果用户对模型具有生成权限，则他们还可以 从 Excel 连接到语义模型 ，并使用 Excel 数据透视表中的 MDX 对其进行查询。 当用户希望使用 Excel 来浏览或分析数据本身时，这非常有用。

在 Excel 中使用分析来查询语义模型时，需要考虑以下事项：

• 某些功能（如 字段参数 或 度量动态格式字符串 ）仅适用于 Power BI，而不适用于 Excel。 若要获得类似的结果，需要使用其他方法。
• 在 Excel 中分析需要启用列属性 IsAvailableinMDX 。 如果用户不使用 Excel，则禁用此属性可能会导致性能更小、性能更高的模型。
• 用户无法在语义模型中查看 隐藏列或度量值 ，就像在 Power BI Desktop 中一样（右键单击数据窗格并选择“视图隐藏”）。
• 用户无法在 Excel 中创建自己的度量值或 视觉计算 ，就像在 Power BI Desktop 中使用实时连接时一样。 但是，他们可以引用其他 Excel 单元格和工作表中的数据透视表字段进行自定义计算。
• 经常使用 Excel 进行分析的用户通常需要额外的培训，以了解如何使用该工具。 如果它们需要类似导出的体验，或者表示用于保存数据脱机副本的意向，则情况尤其如此。 考虑对用户进行以下作的培训：
  • 如何刷新数据。
  • 在向数据透视表添加字段 之前 筛选数据。
  • 避免在没有筛选器的情况下进行大型和详细的查询。
  • Power BI Desktop 的性能将优于使用“在 Excel 中分析”功能，因为“在 Excel 中分析”使用 MDX 查询模型，而 Power BI Desktop 使用 DAX 查询模型。
  • 如何避免产生治理或安全风险，同时仍以用户偏好的方式使用 Excel。

Copilot 和人工智能技能

如果用户对模型具有读取权限，则可以使用自然语言通过Copilot探索和提问有关其数据的问题。 或者，他们还可以在 AI 技能中询问有关其数据的数据问题，但与 Copilot 不同，必须先与他们创建和共享此项。

当用户希望使用自然语言与语义模型交互时，模型设计和实现会产生相当大的后果：

• 语言架构： 必须向模型添加同义词和关系，以便相应的英语单词和术语与正确的模型对象相关联。
• 命名约定： 必须使用 AI 友好的英语命名约定。 这意味着应避免重复或过于相似的字段名称、首字母缩略词、符号和缩写，即使它们是组织中的标准。
• 性能： 必须设置列或度量值说明、数据类别等属性，以便 AI 工具可以更好地识别和使用这些字段。
• 隐藏字段： 您需要隐藏那些您不想向 Copilot 公开或者在其响应中使用的字段。

还需要花费额外的精力培训用户：

• Copilot 或 AI 技能能够和不能够做到的事。
• 何时使用 Copilot 或 AI 技能来探索数据，而不是采用其他（非 AI）方法。
• 如何编写有效的提示。
• 如何验证输出。
• 如何排查意外输出的问题。

小窍门

有关优化模型以很好地使用 Copilot 的其他详细提示和注意事项，请参阅以下文章：

• 报表作者和模型使用者的优化
• 更新数据模型以很好地与 Copilot for Power BI 配合使用
• 使用 Copilot 编写 DAX 查询

Copilot 和其他生成式 AI 技术在内容的规划和设计阶段也应了解的重要限制和注意事项：

• 这是不确定的，这意味着同一上下文上的相同输入可能会生成不同的输出。
• 可以获取低质量或不准确的输出，例如工具幻觉或夸大某些事实的重要性。 Copilot 也可能因遗漏而不正确或不准确，因为遗漏了重要信息。
• 这些工具受训练数据的限制，因此有关更多新信息的问题不太可能产生有用的输出。

谨慎

应降低这些限制和注意事项的风险。 Copilot、AI 技能、LLM 和生成 AI 是新兴技术，因此不应将它们用于自治、高风险或业务关键型流程和决策。 有关详细信息，另请参阅 大型语言模型的安全指南。

分页报表

可以为语义模型编写 DAX 查询，以使用查询结果创建分页报表。 如果用户需要分页报表，并且你打算将语义模型用作数据源，则这是相关的。

计划对语义模型创建分页报表时，可能需要考虑以下几点：

• 如何编写和维护 DAX 查询，例如使用 Power BI Desktop 的 DAX 查询视图或其他第三方工具。
• 您是否需要做出设计决策，以确保语义模型在查询时具有良好的性能，例如将某些数据具体化到模型的列或表中。
• 您是否会使用分页报表视觉对象将分页报表嵌入到您的交互式 Power BI 报表中？
• 如何确保分页报表和其他报表之间没有冗余。
• 应以哪种格式分发分页报表，以及是否需要敏感度标签或数据丢失防护，以保护这些输出免受治理或安全风险的影响。

其他

还有其他使用语义模型的方法。 下面是一些示例：

• 激活器 （以前反射）： 可以使用语义模型自动执行数据警报并触发下游流，例如使用 Power Automate 创建的流。
• 指标集： 可以创建一个指标集，其中包括多个语义模型中的度量值和建议维度。 指标集可以改进用户的数据发现。
• 探索： 除了从报表和 Copilot 输出创建浏览之外，用户还可以从语义模型创建浏览。

报表的分发和共享

根据分发 和共享 Power BI 报表的方式，你将做出不同的设计选择。 例如，跨报表钻取是一项功能，允许用户在同一工作区或应用内的不同报表之间进行导航。 但是，如果嵌入报表或通过发布到 Web 公开共享报表，则无法使用跨报表跳转功能。

其他项目

根据用户如何使用内容和基础数据，可能需要在 Power BI 或 Fabric 中切换到其他项类型。 例如，如果用户想要添加自己的数据和计算，则可将复合模型用于您的语义模型。 或者，可以创建其他集中式数据项，以便在新模型中使用，例如数据流。

确定用户如何使用所做内容后，接下来应决定内容创建者在开发过程中应如何协作。

确定内容创建者应如何协作

随着解决方案的范围和复杂性的增加，多个内容创建者和所有者可能需要协作工作。 创建复杂解决方案时，建议使用有助于构建、管理和支持协作的有效工具。 在生成 Power BI 内容时，可通过多种方式进行协作，例如使用 Microsoft Teams、Azure DevOps 或 GitHub。

小窍门

即使内容创建者独立工作，他们仍然可以使用 Microsoft Teams、Azure DevOps 或 GitHub 等工具来规划和构建工作。 当你计划如何部署内容时，这一点尤其重要，例如，使用来自 Microsoft Teams 文档库的 OneDrive 刷新 或 Azure DevOps 或 GitHub 存储库中的 Git 集成 。

Microsoft Teams

对于更小或更简单的项目，内容创建者可以使用 Microsoft Teams 进行协作。

通过使用 Microsoft Teams，内容创建者在团队和频道中构建其通信、规划和工作。 对于更简单的协作方案，Microsoft Teams 通常是一个不错的选择。 例如，为有限受众生成内容的分散团队可以使用文档库来存储文件和版本控制。 它们还可以使用其他集成工具和服务。

小窍门

建议使用 Microsoft Teams，通过分散式内容交付在 自助服务方案中 促进有效的内容生命周期管理。

若要在 Microsoft Teams 中协作和沟通，请在 Power BI 内容的整个生命周期内使用支持服务。

• Planner：内容所有者可以使用 Planner 创建计划，这些计划用于跟踪任务和范围内容工作。 任务可以描述解决方案中的问题、bug 或功能，以及相应的利益干系人。
• SharePoint：内容创建者可以在Microsoft Teams 文档库或每个频道的连接网站中存储和管理文件。 存储在 SharePoint 中的内容文件可以使用版本控制来帮助跟踪和管理内容更改。 有关使用 SharePoint 跟踪和管理更改的详细信息，请参阅 阶段 2：开发内容和管理更改。
• 审批：内容创建者和所有者可以在审阅后设置和使用工作流来批准内容更改或发布。
• Fabric 和 Power BI：内容创建者和所有者可以从 Microsoft Teams 内访问 Fabric 门户。 在那里，他们可以管理或讨论内容，并将有用的报表添加到 Teams 频道中的选项卡。
• 其他集成：内容创建者可以使用与 Microsoft Teams 集成的其他Microsoft或第三方服务，以最好地满足他们的首选工作流和需求。

建议定义内容创建者应如何使用 Microsoft Teams 进行协作的结构化过程。 确保确定：

• 如何管理对团队和频道的访问权限。
• 谁负责管理团队和频道。
• 如何确定工作范围并将其组织成不同的团队、渠道和计划。
• 内容创建者应如何使用文档库来组织文件和跟踪和管理更改。 例如，如何组织文档库以及内容创建者是否应签入和签出文件。
• 内容创建者是否应使用 OneDrive 刷新 来自动发布 Power BI Desktop （.pbix） 文件。
• 如何解决文件同步冲突。
• 何时存档和删除不再相关的文档库中的文件。

Azure DevOps 或 GitHub Enterprise

内容创建者和所有者还可以使用 Azure DevOps 或 GitHub Enterprise 在中心、有组织的中心进行通信和协作。

注释

Azure DevOps 是一套与 Power BI 和 Fabric 集成的服务，可帮助规划和协调内容生命周期管理。 以这种方式使用 Azure DevOps 时，通常会利用以下服务：

• Azure Repos：允许创建和使用远程 Git 存储库，这是用于跟踪和管理内容更改的远程存储位置。
• Azure Pipelines：允许创建和使用一组自动化任务来处理、测试和将内容从远程存储库部署到工作区。
• Azure 测试计划：允许您设计测试以验证解决方案，并通过 Azure Pipelines 自动执行质量控制。
• Azure Boards：允许使用板将任务和计划作为工作项进行跟踪，以及链接或引用其他 Azure DevOps 服务的工作项。
• Azure Wiki：允许你与其团队共享信息，以理解和参与内容。

通过使用 Azure DevOps 或 GitHub Enterprise，内容创建者使用项目来构建其通信、规划和工作。 此外，内容创建者还可以通过执行 源代码管理、验证和部署，从 Azure DevOps 中协调内容生命周期管理。 源代码管理是管理对内容代码和元数据的更精细更改的过程。

对于更高级的协作方案，Azure DevOps 通常是一个不错的选择，因为有一些支持服务和选项来协调内容创建和部署。

小窍门

我们建议使用 Azure DevOps 来有效管理在 企业场景中 的集中式内容交付的内容生命周期。 使用 Azure DevOps 或类似工具进行协作是较大型或更复杂的方案的首选，而不是使用 Microsoft Teams 或 SharePoint 进行协作。 这是因为有更多的工具和选项可用于促进更可靠的协作和自动化。

建议为内容创建者如何使用 Azure DevOps 进行协作定义结构化过程。 确保确定：

• 工作范围和内容分支的创建方式、命名和使用方式。
• 作者如何对更改进行分组和提交，并使用提交消息对其进行描述。
• 谁负责评审和批准通过pull requests提交的更改。
• 如何解决拉取请求合并冲突以及谁来解决这些冲突。
• 如何将不同分支中的更改合并到单个分支中。
• 如何在部署内容之前测试内容以及执行测试的人员。
• 如何以及何时将更改部署到开发、测试和生产工作区。
• 可以回滚部署的更改或解决方案版本的方式和时间。

GitHub

内容创建者和所有者还可以使用 GitHub （仅限云版本）和 GitHub Enterprise 进行通信和协作。 与 Azure DevOps 类似，GitHub 提供了一个平台，可用于帮助协调和管理 Power BI 或 Fabric 环境的各个方面。

Azure DevOps 和 GitHub 之间的主要区别在于，虽然 Azure DevOps 提供了一套用于管理软件开发生命周期的工具，但 GitHub 主要侧重于托管 Git 存储库、源代码管理和代码协作。 计划使用 Git 集成 部署内容 时，主要使用 GitHub。 此外，可以使用 GitHub 将 公共开源存储库 中的内容同步到工作区。

若要将 Git 与 GitHub 集成，必须启用管理员租户设置 ，用户才能将工作区项与 GitHub 存储库同步。

注释

还可以将 Microsoft Teams 与 Azure DevOps 或 GitHub 一起使用，因为可以通过不同的方法来集成这些服务。 例如，可以从 Microsoft Teams 中查看和管理 Azure Boards 并监视 Azure Pipelines 中的事件。

还可以使用此处未提及的其他工具协作和规划内容。 最重要的是，你使用工具和服务来促进协作，并最适合团队的需求和工作方式。

在您决定内容创建者是否以及如何协作之后，接下来应决定存储文件的位置。 其中许多文件将存储在你选择协作的位置。

确定文件存储位置

创建内容时，通常会生成不同类型的文件。 请务必确定存储这些文件的位置，以便可以有效地管理这些文件。

小窍门

将文件存储在供多个团队成员访问并能轻松跟踪更改的位置（称为版本控制）。 此方法可确保团队成员离开或文件丢失不会导致中断。

通常需要存储的文件类型包括：

• 内容文件：包含内容数据或元数据的文件。 包含 .pbix 和 Power BI 项目（.pbip）等数据的内容文件包含敏感信息。 将内容文件存储在安全位置，只有需要访问这些文件的人才能访问。 此外，应将内容文件存储在支持版本控制的位置，例如Microsoft Teams 中的文档库或 Azure DevOps 中的 Git 存储库。 内容文件的示例包括：
  • Power BI Desktop （.pbix） 文件
  • Power BI 项目 （.pbip） 文件
  • Power BI 分页报表 （.rdl） 文件
  • 模型元数据 （.bim 或 .tmdl） 文件
  • 数据流元数据文件（.json）
• 数据源文件：文件被数据项（例如语义模型或者数据流）使用。 内容直接依赖于数据源文件，因此请务必仔细考虑存储位置，因为删除它们将导致数据刷新失败。 此外，这些文件可能包含敏感信息。 因此，将数据源文件存储在安全、可靠且可信的环境中，该环境对其他个人的访问权限有限。 数据源文件的示例可能包括：
  • 结构化数据源，如 Excel 工作簿、Parquet 或 CSV 文件。
  • 半结构化数据源，如 JSON 或 XML 文件。
  • 非结构化数据源，如导入报表中的图像。
• 支持文件：那些辅助内容创建或管理的文件，但不是其正常运行所必需的。 支持文件应存储在支持版本控制的位置，以及其他工具和内容创建者可以访问这些文件的位置。 支持文件的示例可能包括：
  • Power BI 主题 （.json） 文件。
  • Power BI 报表中的图像（.png、.jpg或 .gif）文件。
  • 最佳做法分析器规则（.json）文件。
  • 内容和查询的源代码文件。
  • 自定义可视化效果 （.pbiviz） 文件。
• 模板和文档：有助于创建自助服务内容或描述现有内容的文件。 需要使用这些模板和文档的人员可以轻松访问模板和文档。 模板和文档的示例可能包括：
  • Power BI 模板 （.pbit） 文件。
  • 可视化模板和示例报表。
  • 解决方案设计和文档。
  • 解决方案规划和路线图。
  • 用户请求和解决方案问题。

谨慎

某些内容文件（如 .pbix 和 .pbip 文件）可以包含从数据源导入的敏感数据。 此外，元数据文件还可以包含敏感信息，或者在某些情况下包含数据点。 例如，报表元数据和 .pbit 模板（在某些情况下可以包含列值）。 确保采取必要的预防措施将这些文件存储在安全位置，并练习有效的 数据丢失防护。

可以使用不同的选项来存储文件。 请确保选择适当的位置，具体取决于文件类型、其内容以及其使用方式。

SharePoint Online 或 OneDrive

用于存储文件的常见解决方案是使用 SharePoint 网站。 对于大多数用户而言，SharePoint 被广泛访问，并与 Power BI 和其他 Microsoft 365 应用程序（如 Microsoft Teams）高度集成。 此外，它还具有内置的 版本控制，因此可以方便地存储大多数文件类型。 版本控制允许查看和管理文件的不同保存版本。

在 SharePoint 中存储文件时，请考虑以下几点。

• 组织：确保保持一致和逻辑结构，以便查找特定文件非常简单。 对文件使用良好的命名规范、将文件组织到文件夹中，并将与正在进行的项目不再相关的文件归档。
• OneDrive 刷新：可以将已发布的语义模型或报表 链接到 存储在 SharePoint 或 OneDrive for work 或 school 站点中的 .pbix 文件。 使用此方法，你不再需要发布语义模型才能使更改生效。 相反，更改将在自动 OneDrive 刷新后显示，这发生在每小时一次。 虽然方便，但请注意，这种方法附带了一些 注意事项和挑战。 一旦事情发生，就不容易逆转。
• 预览报表：在 SharePoint 中，无需安装 Power BI Desktop 或在本地下载 .pbix 文件即可 查看 Power BI 报表 。 以这种方式打开报表时，它们将显示在 浏览器中。 此功能可以是从 Fabric 门户查看报表的便捷替代方法。 默认情况下，它在 Fabric 租户设置中处于启用状态。

小窍门

使用 Microsoft Teams 进行协作时，请考虑将文件存储在频道文档库中。 此方法可帮助集中处理文件并促进协作。

请考虑在 SharePoint 中存储以下文件类型。

• 模板和文档：没有现有存储解决方案时，在 SharePoint 中存储模板和文档。 SharePoint 非常适合这些文件，因为您可以授予对其他人的访问权限并管理文件，而无需复杂的设置或进程。
• 支持文件：没有现有存储解决方案时，在 SharePoint 中存储支持文件。 但是，某些支持文件（如 Power BI 主题 .json 报表文件）可能更好地存储在版本控制系统中，以便查看和管理保存的更改。
• 内容文件：当内容对业务不重要或无法访问 Azure Repos 等远程存储库时，请将内容存储在 SharePoint 中。
• 数据源：仅当数据源的大小和复杂性较低时，才将其存储在 SharePoint 中。 使用 SharePoint 存储数据源文件时，请保持纪律性。 考虑其他可能的替代方案，如 OneLake。

谨慎

不要使用 SharePoint 作为适当的数据体系结构的替代方法。 虽然在 SharePoint 中存储数据源文件在某些有限的方案中可能很方便，但当你拥有更大、更复杂的数据源或需要较低的数据延迟时，此方法不会缩放。

警告

不要使用个人文件系统或个人 OneDrive 帐户来存储文件。 如果所有者离开组织，这些文件将不再可用。

OneLake

如果你有 Fabric 容量，OneLake 是存储数据源文件的一个不错的选择。 可以使用 OneLake 文件资源管理器将文件 上传到 OneLake 或 将其同步 到 OneLake，这些文件可以 转换为表 ，以便在 Power BI 等下游工作负荷中使用。 对于较大或定期更新的数据源，可以使用 Fabric 数据工厂 或其他使用 Azure Data Lake Storage （ADLS） Gen2 API 或 Azure 存储Python SDK 的应用程序自动将文件加载到 OneLake。

谨慎

类似从 OneLake 上传或下载文件的操作 会消耗 Fabric 容量单位。 应 监视容量指标 并采取措施，以避免因大型文件不必要的移动而导致的容量紧张。

此外，使用 OneLake 文件资源管理器的用户访问的文件容易受到 意外更改或丢失的影响。 建议避免将 OneLake 文件资源管理器用于业务关键型解决方案。

警告

OneLake 文件资源管理器具有几个重要的 限制和注意事项。 例如，OneLake 不支持对文件（如 SharePoint 或 OneDrive）进行版本控制。 在决定存储文件的位置时，请考虑到这些注意事项和限制。

小窍门

在 OneLake 中存储数据时，请考虑启用 业务连续性和灾难恢复（BCDR）， 以降低数据丢失的风险。 启用 BCDR 后，数据将重复并存储在两个不同的地理区域中，具体取决于 Azure 的标准区域配对。

远程存储库

内容创建者可以在开发期间定期将工作从本地计算机提交并保存到 远程存储库（例如 Azure Repos 或 GitHub Git 存储库）。 远程存储库包含最新版本的内容或支持文件，并且可供整个开发团队访问。 通常，远程存储库能够提供比使用 Teams、SharePoint 或 OneDrive 更高级的生命周期管理方法。 这是因为通过使用远程存储库，内容创建者可以从更复杂的选项中受益，以协作处理文件，或跟踪和管理文件更改。 例如，内容创建者可以在远程存储库的自己的分支上工作以进行更改，并在准备就绪时请求将这些更改合并到主分支。

请考虑将以下文件类型存储在远程存储库中。

• 模板和文档：使用 Azure DevOps 等相关服务管理项目时，将模板和文档存储在远程存储库中。
• 支持文件：当一个支持文件可用于轻松跟踪和管理更改时，将支持文件存储在远程存储库中。
• 内容文件：在对业务至关重要时，将内容存储在远程存储库中，或者你打算与其他开发人员协作处理同一内容。 远程存储库非常适合跟踪内容更改和促进协作。

小窍门

使用远程存储库时，强烈建议将 Power BI 报表和语义模型存储为 Power BI Desktop 项目（.pbip）文件， 而不是 .pbix 文件。 这是因为保存的更改无法在 .pbix 文件中标识。

此外，请考虑对报表使用 Power BI 增强型报表格式（PBIR）。 PBIR 格式可确保报表元数据更易于读取，这使得跟踪和管理源代码管理中的更改更容易。 此外，可以通过编程工具（如 语义链接实验室）更轻松地管理使用此格式的报表，该库是可在 Fabric 笔记本中使用的 Microsoft Python 库。

无文件：在 Fabric 门户中创建的内容

内容创建者可以直接在 Fabric 门户中创作内容。 在这种情况下，他们通常不直接处理内容文件。 通常，仅当无法在其他位置创建项类型（如数据流、仪表板或记分卡）时，才应在 Fabric 门户中创作内容。 当无法访问 Windows 计算机时，还可以在 Fabric 门户中创作报表和语义模型，因此无法使用 Power BI Desktop。 有关详细信息，请参阅 用户工具和设备。

谨慎

在 Fabric 门户中创建的某些内容无法下载为文件。 例如，在 Fabric 门户中创建的报表无法下载为 .pbix 文件。

在 Fabric 门户中创作内容时，应改用 Fabric API 或 Git 集成 来备份 内容定义。 当您备份内容的定义时，如果该内容被意外删除或无意中更改，则可以减少混乱。 如果内容被意外删除或更改，则可以使用备份替换它。

清单 - 规划和设计内容时，关键决策和作包括：

• 执行解决方案规划：收集 业务要求 和技术 要求 ，以充分了解内容将解决的问题，以及设计此内容如何解决问题。
• 确定将创建内容的人员：根据各个内容创建者的工作流、技能和需求，可能需要不同的生命周期管理方法。
• 确定多个内容创建者是否需要协作：确保协作内容创建者使用的是支持版本控制（如 .pbip 文件）的文件类型。
• 确定内容创建者如何协作：确定协作有多复杂。 此外，决定如何促进此协作，例如使用 Microsoft Teams、Azure DevOps 或 GitHub。
• 确定内容格式：确定 Power BI 语义模型和报表是否由 .pbix 或 .pbip 文件（或模型的其他格式（如 .bim 或 .tmdl）组成，以及报表是否使用 PBIR 格式。
• 确定内容使用方式：评估用户如何处理数据。 确定需要创建哪些项类型来支持使用，以及用户是否需要只读权限，还是生成对基础语义模型或其他数据项的权限。 如果用户确实需要生成权限，请尽早确定他们将如何使用语义模型，以及如何有效地训练它们来执行此作。
• 设置协作工具：确保对解决方案或项目执行必要的首次设置。 通过这些工具制定有关如何管理协作的关键决策。
• 在 SharePoint 或 OneLake 中存储数据源文件：在 SharePoint 中存储小型简单数据源文件。 否则，请改用 OneLake 或 ADLSGen2（如果可用）。
• 在 SharePoint、Microsoft Teams 或 Git 存储库中存储内容和支持文件：对于更简单、较小的项目，如果组织了 SharePoint，并且你练习良好的访问管理，则对大多数文件使用 SharePoint。 对于较大的环境或需要并行协作时，请考虑在 GitHub 或 Azure DevOps 中使用 Git 存储库，这将提供内容更改的详细可见性。
• 在 Microsoft Teams 或 SharePoint 中存储模板和文档：这些模板和文档适用于用户社区。 确保模板和文档易于其他人查找、使用和理解。
• 开发和部署计划：若要结束此第一阶段，请执行具体规划， 以解决关键领域 并 进行初始设置。 例如，建立工具和测试数据源连接。

相关内容

在本系列的下一篇文章中，了解如何在管理内容生命周期过程中开发内容和管理更改。