ssis - 创建通用 PowerBI 模型以在多个客户端站点部署和填充

标签 ssis ssas powerbi

我有一个特定行业(例如:房地产、建筑)通用模型,我想构建该模型作为与每个客户进行咨询的起点。据推测,该模型还需要为每个客户端进行一些定制,目前我假设不会将其合并回原始基本模型。每个客户都将以不同的方式存储他们的数据版本(ERP、SQL、Excel、CSV 等)

我的问题与我应该如何构建这个模型、在哪里构建这个模型以及如何填充它有关。是否应该在 PowerBI 桌面中构建模型,然后使用 PowerQuery 附加查询加载数据?或者,是否应该在 SQL Server 中构建模型,并首先填充更传统的 ETL 脚本,然后将其导入 PowerBI?

最佳答案

选择使用 Power BI Desktop 执行 ETL,还是在 SQL Server 中执行 ETL,然后将最终数据导入 Power BI Desktop 取决于 3 个因素:

  1. 便携性。使用 Power BI Desktop 进行 ETL 意味着您的整个解决方案都在 Power BI Desktop 中 - 您不需要任何其他工具来部署解决方案。如果不能保证每个客户端都有相同版本的 SQL Server 和相同的 ETL 工具,那么我不建议构建对此类外部工具的依赖关系。 异常(exception):如果您的客户将构建 ETL,那么您可能希望将客户编写的 ETL 保留在 Power BI Desktop 解决方案之外 - 并且您可能不关心他们使用什么数据库/ETL 解决方案,只要最终结果符合您的要求
  2. 处理能力(或 ETL 的密集程度)。如果 ETL 高度密集并且需要服务器的所有能力来运行,那么 SQL Server/传统 ETL 可能会更好。 Power BI Desktop 中的任何 ETL 都必须在安装 Power BI Desktop 的位置运行。如果这是一台较低规范的计算机,那么密集型 ETL 将比使用传统的基于服务器的 ETL 工具慢得多。
  3. 可维护性。如果您打算继续维护 ETL,那么坚持使用您非常熟悉的工具(例如 Power Query)是比为每个客户端使用不同的外部 ETL 工具更好的计划。但是,如果您的客户要维护 ETL,那么他们可能更喜欢以与他们维护的其他 ETL 相同的方式构建 ETL,并像他们维护的其他 ETL 一样运行。

我想,考虑到您正在与多个客户端合作,可移植性几乎胜过其他一切。您对客户的要求越少越好。

在此决定中,数据的大小并不重要,因为无论如何,所有数据都将导入到 Power BI Desktop 中(正如您在问题中指定的那样)。

如果您选择外部数据库/ETL解决方案,那么自然的下一步就是探索直接查询模式或与多维数据集的实时连接(而不是导入数据) )。这样做的利弊将是您做出决定时要考虑的另一个因素。但是,由于您正在为客户构建解决方案,因此这可能是您无论如何都不希望依赖的另一个工具。

总的来说,根据您的情况(为客户构建解决方案),我会推荐 Power BI Desktop。

对于正在构建内部解决方案的阅读本文的其他人来说,建议不一定相同(并且取决于适用于他们的情况)。

关于ssis - 创建通用 PowerBI 模型以在多个客户端站点部署和填充,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44003454/

相关文章:

sql-server - 如何避免在重新运行加载数据的 SSIS 包时将数据(重复项)重新插入 SQL Server 表?

sql-server - 当 SSIS 从 SSRS 保存 PDF 时,PDF 已损坏

ssas - 处理 MDX 查询的逻辑顺序

ssas - 在 DAX 中优化汇总

powerbi - 标记为日期表似乎毫无意义

powerbi - 卡住添加公式到动态添加的列

c# - SSIS:无法在 DontSaveSensitive 模式下使用 GetSensitiveValue() 访问脚本任务中的敏感参数

c# - 如何在脚本任务中访问 c​​sv 字段

azure - Power BI 架构

sql-server - 错误: The MDX function CURRENTMEMBER failed because the coordinate for the attribute contains a set