Microsoft Fabric初体验——概念篇

Fabric出来也有一段时间了，之前搞了试用账户，还没来得及玩就过期了，现在又借来一个号，赶紧体验一把，顺便说说我的理解，仅供参考，不一定对。

刚进主页，显示Fabric作为微软最新缝合怪，由以下几个模块组成：

可以看出来微软是把Power BI和Azure上的ADF、Databricks等资源进行了整合，让不同角色的人员能在同一个位置进行开发。而Power BI只是其中的一部分，并不是说Power BI升级成了Fabric增加了很多功能，所以对于之前只熟悉Power BI的同学不必焦虑也不用卷，毕竟这么多模块不是给一个人用的。

BI框架

通常来说，用Power BI制作一个报表最简单的方式就是拿Power BI Desktop直接连接各个数据源，Power BI本身就是一个集数据抽取、清洗、建模、展现等功能于一体的工具，应付简单需求没有问题。但如果需求稍复杂一些，数据量稍大一些，有些场景可能就无法满足了。例如连接了一个HR系统获取到了公司全部在职人员的花名册，想要做一个每月在职人数历史变化的趋势图，就会发现每次刷新报表只能取到系统中的最新数据，一旦刷新就变了，而历史数据没有保存下来做不出趋势图，所以最好的解决方案就是在数据源和Power BI之间加一个存储层，把历史数据定期存下来。把数据下载另存到Excel这也是一种方案，当然更加专业的方案还是存储到数据库，或者数据仓库。

数据库是一个产品或工具，例如SQL Server、MySQL等，数据仓库是数据库的一种用法或者规范，通常把表分为了维度表事实表，最好是直接拖拉拽就能生成报表，分析用起来怎么方便就怎么设计，而不用过于考虑数据冗余之类的问题。然而在数据仓库中从数据源到维度事实表通常也并不是一步生成的，例如上面提到的抽取HR系统花名册数据时，每次抽取的只是某个时点的状态（表1），需要把多次抽取的结果合并成为一张完整的表（表2）才能得到多个时点组合而成的趋势，而随着时间的积累数据量会越来越大，但报表中只需要展示人数而不需要具体的人员清单时，就可以先对表按照年月等字段聚合（表3），Power BI取数据量较小的聚合表数据以提升性能。

在此过程中会产生出结果表在不同阶段的中间表，这就是数据仓库的分层概念。而且实际情况可能远比以上场景复杂得多，数据量大、数据质量差、数据源种类多等很多问题都可能成为你得到理想格式的数据中间的绊脚石，合理的分层可以帮助我们将复杂问题分解，更清晰的追踪数据血缘关系，并且减少大量重复计算。业内通用的说法会把数仓分为STG->ODS->DWD->DWS->DM等层，具体就不展开讲了，这只是一种规范和方法论，并非强制要求，各人说法不一，但可以确定的是肯定不止一层。

既然有了数仓，从数据源抽取数据就用不了Power Query了，得再有一个专门的ETL工具来负责从数据源到数仓的数据同步以及各种转换任务的调度。数据也不需要在Power Query中清洗了，而是在数据仓库中就提前处理好。所以一个完整的企业级BI解决方案至少包含以下内容：

其中的数据模型部分为可选项，指的是单独部署SSAS或AAS，可以作为数据仓库的一部分，也可以认为是和Power BI一起的。

传统方案Data Warehouse

以上的方案落地还需要具体的产品和技术支撑，在已选定Power BI作为报表工具的前提下，我们还需要选择一套ETL工具+数据仓库组合，当然市面上可选的竞品产品有很多，我们主要还是聚焦在微软的产品方案上，毕竟单一产品不一定每个都最好用，但全家桶一起上一定是地表最强。

本地化的SSIS+SQL Server就不说了，在Azure云端主流的就是把Azure Data Factory（ADF）作为ETL工具负责数据的抽取同步及任务调度，Azure SQL Database作为数据仓库并同时作为存储和计算引擎，数仓中各层的数据转换通过编写存储过程实现，并通过ADF来调用。而Azure中几乎所有资源的活动日志都可以通过名为Azure Monitor（监视器）的服务来监控，例如用户访问记录、服务器负载情况等，并可根据预设的指标触发提醒，发送邮件、Teams消息等。

这一段中只需要了解在Azure上已有Azure Data Factory和Azure Monitor这两个服务，再看一眼开局的第一张图就行。

过渡方案Data Lake

上述方案相当于只是将原先的本地产品搬上了云端，从而带来了高可用、弹性缩放等云端的天然优势以外，没有其他本质区别，数据都存储在结构化的关系型数据库中，并可使用SQL查询。

但随着近年来AI的快速发展，数据增长呈现出了大体量、高性能、多样性等特点，数据已经不是传统意义上存在表里的数字了，视频、音频、图片等格式都可以作为数据，例如以会议录屏作为数据源，通过AI转成文字并整理成会议纪要等场景，于是催生出数据湖（Data Lake）这样更加低成本的分布式存储方案，例如Azure的Data Lake Storage、AWS的S3、阿里云的对象存储OSS等。

在数据湖中，数据可以任意格式的文件形式存储，你就可以理解成一个性能超好、超级便宜、无限容量且具有冗余备份机制的网盘文件夹，你可以把任意结构化的数据（例如csv，通常是parquet等），半结构化的数据（例如嵌套多层结构的json），非结构化的数据（例如视频、音频等）全部统统丢到数据湖里，这样就解决了数据存储的问题。但随之而来的问题，数据都不存在数据库了，怎么快速查询出我要的结果呢？又如何管理好这些数据资产呢？

所以这时候就还需要一个计算引擎，来创建元数据层，映射到数据湖中的文件。例如创建了一张表，表中的字段名、字段类型、键列等元数据依然创建在计算引擎端，依然可以通过在计算引擎中使用SQL语句查询出结果，但是数据却存在于数据湖中，从而实现了存储与计算分离。

这里所需要的计算引擎，微软自己也有解决方案，在SQL Server或者Azure Synapase中都可以通过PolyBase技术引入外部数据，勉强实现了湖仓一体。但数据以文件形式存储，文件毕竟是文件，数据质量和可靠性难以保障。

先进方案Delta Lake

有一个公司和产品叫做Databricks，是Spark的商业版，专门和各大云厂商合作搞云原生大数据，几年前就在Azure上推出Azure Databricks服务，当然还有Databricks on AWS等。这个Azure Databricks不是微软的产品，但是可以很好的和Azure Data Factory以及Azure Data Lake Storage等服务配合使用，下图演示了一个从本地数据源上微软云的完整BI架构图。

Databricks有非常多独有的优势，例如支持Python、Scala、R、SQL等种语言，可以支持机器学习、可以处理数据还可以画图，可以让多种角色的人在同一个界面中工作（现在又被拿来当作Fabric的宣传口号了），并且数据湖、表、字段、机器学习模型、笔记本这些都在一个地方处理了自然就方便管理了，可以使用Unity Catelog进行统一的数据资产治理。

而数据湖也升级成了Delta Lake，数据存储的格式为专属的delta格式，相比于parquet格式提供了事务日志、版本控制等功能提供更好的可靠性，同时还支持增量数据、流式数据的处理。

如此多的优势带来的那必然是价格不菲，相对于普通Azure SQL数据库来说。Azure Databricks主要的收费机制是背后的计算群集，开机的时候会收费，当跑代码处理数据时自动开机，跑完任务一段时间会自动关机。所以一般T+1每天更新一次的非实时数仓中，一般设置每天凌晨开始跑任务，跑完数仓刷新完后数据就导入到Power BI了，报表已经能看了，所以这时候Databricks就可以自动关机以节省不必要的费用，关机也不会影响看报表，每天开一小时和24小时常开的费用差别还是蛮大的。

Databricks作为当今最先进的湖仓一体的Lakehouse，可以作为强大的计算引擎，也可以作为独立的数据仓库对外提供数据，可以使用SQL查询湖仓中的数据，或是用Power BI连接湖仓制作报表。但由于上述节约成本的原因，群集一旦关机了基本上除了看notebook中的代码以外做不了任何事，运行不了代码、查询不了数据也刷新不了报表，即使有任务调起会自动开机，也还是需要等待5分钟左右的开机时间。

所以就有了另一种计算资源叫做SQL Warehouse，区别于通用计算群集包含的完整功能，SQL Warehouse是一种无服务器计算资源，不能够运行notebook或是使用除SQL外的其他语言，而是更加专注于数据仓库本身的查询功能，具有更低的成本和几乎秒开的启动速度。也就是说，两种计算群集，闲时都关机，当每天开始跑批处理数据时，通用计算资源自动开机，跑完所有任务自动关机，数据一直更新进了Power BI；当后续还有查询数仓数据或是刷新报表的请求时，自动启动秒开SQL Warehouse，查询出结果。

创新方案OneLake

上面说了这么多Databricks，这和Fabric到底有啥关系？

这是因为Databricks在22年将核心技术Delta Lake完全开源了，所以Fabric正是基于Databricks的Delta Lake技术，在换壳之后结合自家产品做了融合。而我作为Fabric的初学者，也正在尝试以Databricks的使用经验来对比理解Fabric。

再次回头看第一张图，基本上都能找到对应关系：

模块名称	对标原产品	功能描述
Power BI	Power BI	数据建模、报表可视化
Data Factory	Azure Data Factory	数据抽取、任务调度
Data Activator*	Azure Monitor	监控和警报
Synapse Data Engineering	Azure Databricks主要功能	使用notebook编写代码，处理湖仓中的数据
Synapse Data Science*	Azure Databricks中的机器学习	机器学习，试验、训练模型
Synapse Data Warehouse	Azure Databricks中的SQL Warehouse	以数据仓库的体验使用T-SQL查询湖仓中的数据
Synapse Real-Time Analytics*	Azure Databricks中的流式处理	流式数据处理，实时数仓

其实核心的功能也还是ETL+数仓+Power BI。当然除了移植和融合之前已有的技术外，微软还是加入了很多创新的功能和概念的，例如把湖仓和OneDrive结合推出了OneLake的概念，可以使用快捷方式在不移动数据的前提下连接数据，可以跨工作区跨订阅甚至能跨云。新增的Direct Lake模式，可以直接基于OneLake生成Power BI报表，但性能却不弱于导入模式，兼具了导入模式和直连模式的优点。