powerbi - 如何通过共享数据集架构的管道促进模型和报告

Question

我正在尝试优化我公司的共享数据集代码升级程序。我怀疑我们做错了什么。

我们在云中使用 PBI（不是 Report Server），共享容量（不是 Premium）。我们的部署“管道”由 4 个阶段组成：Dev、Test、UAT 和 Prod。所有 4 个阶段都指向生产数据库。我们有单独的 PBI 应用程序工作区来代表这些阶段中的每一个。我们通过将 pbix 文件放入与 SharePoint 文档库（实际上，每个管道阶段有 1 个库）同步的 OneDrive 文件夹中来发布我们的 pbix 文件。SharePoint 自动将这些文件持久保存到 PBI 服务中（即，SharePoint 文档库和 PBI 服务应用程序工作区之间的 1:1 对应关系）。

我们有一些生成数据集的“模型”pbix 文件（没有视觉效果，只有模型）。我们有很多从这些数据集中使用的“报告”pbix 文件。有时，我们需要更新模型 pbix 文件和受影响的报告 pbix 文件。对于这种情况，我们发现通过堆栈提升代码的过程非常繁琐。例如，对于这种情况下从 UAT 到 Prod 的代码提升，过程如下所示：

1. 在我们的本地计算机上，将 UAT 模型文件放入 Prod OneDrive 文件夹（几乎无需等待时间即可与 Prod SharePoint 文档库同步）

2. 等待新的 Prod 模型文件（当前 UAT 模型文件）从 Prod SharePoint 文档库持久保存到 Prod PBI 服务应用程序工作区（通常等待时间为 15 分钟）

3. 在 Prod PBI 服务应用程序工作区中手动刷新模型文件的数据集（因为模型数据将从我们的本地机器继承旧数据）（刷新可能需要大约一个小时）

4. 在我们的本地机器上，将 UAT 报告文件的数据集更新为 Prod（转换数据 \ 数据源设置 \ 在 Prod PBI 应用程序工作区中选择模型数据集）

5. 在我们的本地计算机上，将 UAT 报告文件放入 Prod OneDrive 文件夹

6. 等待新的 Prod 报告文件从 Prod SharePoint 文档库持久保存到 Prod PBI 服务应用程序工作区（同样，大约 15 分钟）

7. 更新 Prod PBI 应用程序

七个步骤对于仅 1 个阶段来说还不错。但是，当按我们的目标阶段数量（即 3 个）缩放时，这将成为一个非常缓慢的过程。因此，这似乎不对。

这应该怎么做？或者，如何优化？（可以肯定的是，我们不会升级到高级版，也不会授予测试人员/消费者对应用工作区的访问权限——仅授予应用。）

标签： powerbi