概述
客户通过将数据仓库托管在 Snowflake(在 AWS 中)上对其进行了现代化改造,并选择 Power BI(在 Azure 中)作为他们的单一报告/分析平台。 他们曾经拥有多个报告/分析平台,如 QlikView、Tableau 和 Power BI,但将它们整合到一个平台上使运营和管理变得更加容易。 这种架构也给Snowflake和Power BI带来了性能挑战和成本上升,也阻碍了它们实现Self Data Service。 客户希望降低 Power BI 和 Snowflake 的成本,并解决为业务用户提供自助数据服务时的一些架构问题。
所确定的一些挑战如下。
- 由于成本问题,当前架构不支持自数据服务。 开发人员创建大部分报告/仪表板,业务用户需要 IT 团队的帮助来进行任何更改。
- 由于 Power BI 和 Snowflake 集成而导致的报告/仪表板性能问题。 在某些情况下,数据通过互联网跨数据中心传输以获取任何报告/仪表板,从而增加了延迟/性能问题。
- 随着采用率的增加,Snowflake + Power BI 的成本也随之增加。
为了缓解上述挑战,在 Microsoft Fabric 上的 Snowflake 和 Power BI 之间创建语义层是一种可能的解决方案,为用户提供自助数据服务。 Microsoft Fabric 上的语义层将使用镜像功能近乎实时地从 Snowflake 复制基表。 从 Snowflake 复制基表后,将使用 Fabric 聚合数据、计算度量、KPI/指标的数据工程功能创建并发送给业务用户。 对于业务用户来说,在 Power BI 中自行创建报表/仪表板将更像是拖放对象的体验。 Power BI 将使用 “直接湖模式” Fabric 的查询功能通过在 Power BI 中创建报告来获得相同的性能/速度 “导入模式”。
资源:
当前架构
客户在 Snowflake (Finmart 2.0) 上有一个数据仓库,该仓库接收来自 SAP HANA(包含财务数据)以及各种 Excel 和 csv 文件的数据源。 Snowflake 上的数据以简单结构存储在基表中,很少或没有数据建模,也没有任何计算度量、聚合等。导入数据时,所有建模(星型架构)和任何聚合、计算都在 Power BI 引擎中进行从基表到 Power BI 中制作的星型架构结构。 当前的架构给 Power BI 带来了问题,并阻止客户创建自助数据服务架构。
对查询进行建模的另一种方法是使用从 Power BI 到 Snowflake 数据仓库的基于组合的方法。
以下是上述架构的一些优缺点:
优点
- Power BI 可以使用详细/原始数据创建显示聚合/计算度量的报告和仪表板。 数据来自一个位置,该位置存储来自 SAP HANA 和其他一些源的过去和当前数据。
缺点
- 自助数据服务不可用,因为必须导入、建模、聚合和转换数据才能为业务用户制作报告/仪表板。
- 不同云/数据中心上的不同数据服务。 SAP HANA、Snowflake(AWS 云)、Power BI(Azure 云)。
- Power BI 报表在导入模式和直接查询模式下都有延迟。
- 由于使用多个平台且每个平台都有自己的存储库,因此很难创建数据沿袭。
- 通过网络移动的数据有其自身的成本和安全问题。
- 每个查询的出口费用。
提议的以 Fabric 作为语义层的架构
一种可能的架构是使用 Snowflake Mirroring 在 Microsoft Fabric 中构建语义层。 以下是在 Fabric 中创建语义层的步骤。
- 使用 Microsoft Fabric Snowflake 镜像功能在 Fabric 中镜像 Snowflake 数据库。 Fabric 中的镜像是一种低成本、低延迟的统包解决方案。 一旦您的操作数据源设置为镜像,数据将不断复制到 OneLake 中以供分析使用。 借助 OneLake 中查询表格式的最新数据,您现在可以使用 Fabric 中的所有不同服务,例如使用 Spark 运行分析、执行笔记本、数据工程、通过 Power BI 报表进行可视化等等。
- 每个镜像雪花都有一个自动生成的 SQL Analytics 端点,该端点在镜像过程创建的增量表之上提供丰富的分析体验。 用户可以访问熟悉的 T-SQL 命令,这些命令可以定义和查询数据对象,但不能操作数据,因为它是只读副本。
- 使用 Microsoft Fabric 中的数据工程,从镜像数据库读取数据并构建聚合表和星型架构模型以供可视化层直接使用。
- 使用 Power BI 的 Direct Lake Query 功能在 Fabric 中的基础表和聚合表之上创建报告和仪表板。
资源:
优点
- 所有报告数据(基础+聚合)都集中在一处,满足任何报告要求。
- 数据在一处可用、建模(例如星型模式)、关键指标/KPI,以便随时访问。 业务用户可以通过将数据元素拖放到 Power BI Canvas 中来获取数据即服务。
- 数据可近乎实时地访问。
- Fabric 还整合了 Power BI,它具有 Power BI Co-pilot 和 ChatGPT 等可处理数据的功能,这将帮助他们进一步提供数据即服务。
- 改进了数据沿袭,数据从源到聚合再到 Power BI 全部存储在一个位置,这也将能够应用更好的安全策略。
- Azure 中的一项服务和一项成本,即“MS Fabric”。
缺点
- 语义层创建需要从 Snowflake 到 MS Fabric 的数据复制。
- 需要处理的附加平台层。
织物与雪花共存 3 年的成本效益
Fabric 作为 Snowflake 和 Power Bi 之间的语义层不仅有助于提高报告和仪表板的整体性能,还有助于优化成本。 以下是成本效益计算器,可用于计算指示性成本节省。 TCO 计算器中提供的数字只是一个示例。 请确保根据您的情况输入相关数字。 预期成本节省可在 30-40% 之间,具体情况因实施方案而异。
织物与雪花共存 3 年的成本效益 |
||||||
第一年 |
第二年 |
第三年 |
||||
当前架构成本(Snowflake + PBI)($)/月 |
建议的架构成本(Snowflake + PBI + Fabric)($)/月 |
当前架构成本(Snowflake + PBI)($)/月 |
建议的架构成本(Snowflake + PBI + Fabric)($)/月 |
当前架构成本(Snowflake + PBI)($)/月 |
建议的架构成本(Snowflake + PBI + Fabric)($)/月 |
|
雪花+AWS |
20万美元 |
150,000 美元 |
30万美元 |
150,000 美元 |
40万美元 |
20万美元 |
AWS 出口成本(Azure 中的 PBI 导入) |
10,000 美元 |
10,000 美元 |
10,000 美元 |
10,000 美元 |
10,000 美元 |
10,000 美元 |
Azure 中的 Power BI 成本 |
$44,000 |
$44,000 |
$57,200 |
$44,000 |
$74,360 |
$44,000 |
Azure 中的结构成本 |
0 |
$8,400 |
$0 |
$8,400 |
$0 |
$8,400 |
总成本 |
$254,000 |
$212,400 |
$367,200 |
$212,400 |
$484,360 |
262,400 美元 |
当前架构的 3 年总成本 |
1,105,560 美元 |
拟议架构的 3 年总成本 |
$687,200 |
成本效益 |
$418,360 |
成本效益 (%) |
38% |
与此同时,为了尝试 Fabric, 注册一个免费试用版。
1714004807
#Microsoft #Fabric #作为语义层与 #Power #和 #Snowflake #共存
2024-04-04 16:04:28