最近几个月身边越来越多做数据平台的人开始问我同一个问题微软Fabric和Purview到底怎么配合这两个名字总被放到一起提但一个看起来像数据仓库/湖仓平台一个看起来像数据治理工具好像谁都能解释两句真到落地的时候又谁都说不清楚。我自己在帮企业做架构升级的过程中也反复被类似的痛点卡住辛辛苦苦把数据搬进湖仓、把报表跑通可一旦业务方问“这张表到底能不能给第三方用”“这个指标是哪个环节算出来的”没有一套治理底座的平台随时可能暴雷。这篇文章我就以实际落地视角把微软Fabric和Purview这对组合拆开揉碎讲清楚看完你至少能回答三个问题它们各自解决什么、为什么必须配合着看以及从现有Power BI/Synapse环境迁过来第一步应该做什么。1. Fabric和Purview放到一起才看懂微软的数据平台蓝图1.1 我为什么把它们看成“上下两层”很多人会陷入一个误区微软Fabric和Purview是两款并列的独立产品选哪个看你需要。真把产品结构摸一遍你会发现它们根本不是并列关系而是一套完整平台里的上下两层。Fabric更像一个整合后的数据分析底座。从数据接入、湖屋存储、数据仓库、实时分析到Power BI报表微软Fabric把过去要单独采购和运维的ADF、Synapse、Data Lake、Power BI等能力重新包装成一套统一的SaaS化平台。你购买的是Fabric容量容量然后把工作区挂到容量上就能在里面建湖屋、写Spark任务、跑SQL、做报表。存储和计算都在一个租户体系内被管理起来理念上更接近“一站式数据云”。Purview则处在这个底座之上扮演治理、合规和目录的角色。你可以在Purview里登记数据源、扫描元数据、打敏感度标签、追踪数据血缘甚至让标签反向触发Microsoft 365的保护动作。它并不是用来替代数仓或报表的而是告诉数据平台里每一个使用方你这张表从哪来属于谁敏感等级多高能不能被下游任务引用。如果把Fabric比喻成一整栋精装修的数据大楼Purview就是大楼里的门禁系统、图纸归档和消防巡查。楼盖得再漂亮没有这套中层管理机制业务侧是不敢随便入住的。1.2 它们拼出来的是一个什么样的现代化数据栈把Fabric和Purview放在一起看你能大致得到一条非常接近“现代化数据栈”的链路存储层用OneLake统一收拢所有湖上数据计算层用湖屋和仓库分别处理加工报表层靠Power BI语义模型服务业务分析治理层则由Purview负责元数据、敏感度和血缘。过去企业自建这套东西可能会选AWS的S3GlueRedshiftSageMaker或者选Azure的ADLSData FactorySynapsePower BI。问题是如果全部自己拼装每一层之间都有版本兼容、权限打通、故障排查的成本。Fabric的SaaS化思路把这些基本能力收进同一个环境用户在界面上创建的每一个“湖屋”数据项、发布的每一个“语义模型”天然共享同一套存储和元数据底座。这是它比传统PaaS拼装更有吸引力的地方。但要提醒一句Fabric解决的是数据分析链路的问题它不负责解决“这个数据是否合规、下游是否越权使用”。这也是为什么微软把Purview和Fabric绑得这么紧。从Power BI到Fabric的数据资产全部可以纳入Purview的扫描体系用统一的敏感度标签管理。换句话说你的数据栈从开发到消费的中间必须有Purview这个控制面参与才算闭环。这篇文章适合谁看如果你正在给企业设计湖仓架构或者你是Power BI重度用户想理解Fabric迁移收益亦或是数据治理工程师在发愁如何给Fabric和传统数据源建设统一目录下面的内容都值得花十分钟过一遍。2. Fabric的本质一个容量加一套OneLake替换掉你的“数据平台全家桶”2.1 容量Fabric计费与运行的基本单元刚接触Fabric的人最先撞上的概念就是Capacity容量。这和你过去买VM、买Synapse SQL池按DWU计费的习惯非常不一样。Fabric里的容量更像一个固定的资源额度创建容量时可以选择F2到F2048等一系列SKU数字越大可用计算资源越多。你把工作区挂载到这个容量上后里面跑的任何任务Spark作业、SQL查询、Power BI刷新都会消耗这个容量的CU计算单位。我见过不少从Azure Synapse迁移过来的团队第一反应是找我打听Fabric里的“节点”怎么选。实际上你不用管节点只要理解你的工作负载对CU的要求。Fabric容量本质上是一套共享的资源池所有组件都从这个池子里取计算能力这也是它定价模型的核心。你使用F2这种小容量做开发体验是可以的但想同时跑起多个Spark Notebook可能很快会出现容量过载和任务排队。如果对标过去Power BI Premium的P1容量可以直接参考F64这一档两者在性能量级和成本上大致对齐。需要特别提醒的是Fabric容量和OneLake存储是分开计费的。很多人买完容量就以为数据存储也全包了实际上OneLake里的数据是单独按存储量和冗余策略收钱的。容量不启动、任务不执行时你的数据依然静静躺在其中存储计费不会停。这个概念如果不提前建立月底看到账单时很容易吓一跳。我自己的习惯是先按报表刷新和Spark任务估算CU消耗预留出一定缓冲再用Azure成本管理设置预算告警。2.2 OneLake与工作区让数据湖、数仓、BI共用一个底座OneLake是Fabric在存储层最重要的设计它不是再造一个独立的对象存储而是把Fabric所有工作区的数据统一到一个虚拟湖中。底层基于Azure Data Lake Storage的格式但对用户屏蔽了传统ADLS存储账户、容器、路径的复杂度。你在Fabric里建湖屋本质上是在OneLake里开辟一个逻辑空间湖屋里自动分成Tables和Files两类区域Tables用来存放被注册为Delta格式的受管表Files则放原始文件或临时文件。OneLake最值得关注的能力是Shortcuts快捷方式。过去你从ADLS加载数据到数仓通常要走ETL复制一份物理存储。有了Shortcuts你可以直接在一个湖屋里以逻辑路径引用另一个存储位置的数据甚至能跨工作区、跨湖引用。数据物理上只有一份查询时可以通过不同湖屋的语义层进行访问这对避免数据冗余和数据不一致问题极有帮助。在Fabric中建数据仓库时你会接触到一个容易混淆的点湖屋会自动附带一个SQL分析端点这个端点能让你用SQL查询湖屋Tables里的数据但它是只读的。如果业务要求通过SQL任务创建视图、做数据转换、管理权限正确的选择是再创建一个Fabric数据仓库Warehouse它是独立的SQL计算和元数据对象。很多新手把湖屋的SQL分析端点当成正式数仓来用等到需要写物化视图或者细粒度权限的时候才会卡住。2.3 那些“找不到”的组件从ADF/Synapse到Fabric的思维切换从一个老套的Azure数据栈进入Fabric最大的阻力不是技术而是找不到过去熟悉的入口。比如在Fabric数据工厂的Pipeline里过去Data Factory的Linked Service概念被弱化了取而代之的是统一的连接Connection管理。你以前可能习惯在ADF里为每个SQL数据库建Linked Service然后在Fabric里找半天找不到其实连接被集中放到了工作区或湖屋的“连接”设置中。再比如SparkFabric里做数据工程的入口不是创建Azure Databricks工作区而是在数据工程体验中启动Notebook或Spark作业定义。默认会拉起一套Spark计算并绑定到当前容量你不用去配置集群大小只需要选择运行时的环境。这种设计习惯上的变化要求团队做一次思维切换从“我自己管集群、管网络、管扩展”到“我只描述业务逻辑计算资源由容量统一调度”。我在企业落地过程中通常建议先从一条非核心业务链路开始试水比如把一个财报维度表从Synapse搬进Fabric湖屋把原有报表连过去跑懂全流程后再扩大。不要试图一周内把所有ADF和Power BI数据流全部迁移否则碰到的全是“过去习惯”带来的认知摩擦而不是产品能力本身的问题。3. Purview不只是在打标签数据地图和血缘才是它最值钱的部分3.1 从Azure Purview到Microsoft Purview功能版图发生了什么很多老用户记忆中的Purview还是那个叫Azure Purview的数据治理类产品主要功能是扫数据源、建立元数据目录。但在微软的统一布局中这个产品已经并入了更大的Microsoft Purview品牌底下既包含数据地图、数据目录、数据血缘这些治理能力也包含从Microsoft 365合规中心迁入的敏感信息保护、数据防泄漏、审计等功能。这个演变带来一个很现实的困扰如果你直接用Microsoft Purview门户可能会看到好几个功能模块有些面向合规官有些面向数据工程师。如果你只关注数据资产治理一定要先找到数据地图Data Map和目录Data Catalog相关的入口不要被庞大的合规界面吓退。反过来如果你的需求是锁定敏感文档、控制外发那么数据防泄漏和数据生命周期管理才是重点。很多企业把两者混为一谈买完许可证后对着门户不知从哪儿点起就是因为没有先划分清楚自己到底要治理的是“数据”还是“内容”。对我来说Purview对数据平台团队最有价值的部分仍然是老三样元数据扫描、数据目录和血缘追踪。合规相关的能力当然重要但它更多由安全团队从Microsoft 365侧驱动。数据架构师在集成Fabric和Purview时第一优先级是把技术元数据和业务数据目录搭起来。3.2 数据地图把散落的元数据收拢成一张可检索的网Purview的数据地图功能靠扫描器工作。你可以在Purview中注册需要治理的数据源支持范围包括常见的SQL Server、Azure SQL、Azure Data Lake Storage、Synapse也包括Power BI和Fabric这类分析类资源。注册后扫描器会周期性读取元数据比如表结构、列名、文件路径、最近修改时间并把结果组织成可检索的数据资产。真实项目里我见过不少团队以为建好数据地图就是把连接器加上、扫描一次就完事。实际上扫描完只是开始。你需要把成千上万张扫描出来的表通过集合Collection的方式划分为业务域再为高价值的数据资产补充描述、所有者、认证状态等业务元数据。这样业务用户在搜索时才能快速区分“财务部金蝶数据源里的销售明细表”和“数据团队测试用的临时表”。Purview的目录搜索能力只有在这些整理动作扎实之后才能发挥效率。另一个容易忽略的点是扫描频率。不要一股脑给所有数据源都设置每日全量扫描。对于超大数据库频繁扫描会增加源端压力对于日更表每天扫一次通常就够。根据数据源业务等级分别设计扫描规则是高效率治理团队的基本功。这套方法论和产品无关但在Purview里效果尤其明显。3.3 血缘追踪为什么必须结合报表链路才有意义如果只做元数据目录和标签Purview的价值很容易被低估。让我真正觉得这个产品不能缺的是它的数据血缘能力。所谓血缘就是你能在图谱里看到某个报表指标从原始表到加工表、再到语义模型的一整条链路。过去做数据平台出了问题最痛苦的是反向定位业务反应昨天报表数据不对到底是最上游的文件格式变了、数仓任务算错了、还是Power BI度量逻辑写错了没有血缘基础设施团队只能靠问人、翻脚本、对时间。Purview采集到血缘后你直接展开某个Fabric湖屋表可以看到上游数据如何流入下游又影响了哪些数据流、数据集和报表。血缘要发挥价值不建议只盯着数据库表之间关系。对业务分析师而言更关心的是Power BI报表上的每个指标是否能追溯到底层表。因此我建议在Fabric里建设数据时严格遵守分层命名比如bronze/silver/gold并在Purview中形成“源系统、加工层、语义层、报表层”血缘链路描述。血缘图上的节点越规范后续做影响分析和故障回溯就越轻松。反过来如果表名千奇百怪pipeline名称随意命名血缘图大概率乱成一团最终被团队弃用。4. Fabric湖屋接入Purview端到端数据治理的完整闭环4.1 把Fabric数据源注册到Purview的配置路径这里给出实际操作中最常走的路线。登录Microsoft Purview门户后进入数据地图相关的管理界面试图注册数据源。定位到Microsoft Fabric需要选择是注册整个Fabric租户还是特定资源。Fabric作为租户级数据源通常扫描范围是当前Microsoft 365租户下所有Fabric工作区。授权时建议使用独立的安全组或服务主体完成认证避免使用某个个人账号防止员工离职后扫描失效。你还需要把扫描结果规划到对应的Purview集合中。比如我可以建一个“生产环境-财务域”的集合把Fabric中财务相关的湖屋和仓库映射到这个集合内。Purview的权限体系基于集合建立数据查看者只能浏览自己集合下的资产这样能有效避免目录混乱和数据越权查看的风险。扫描开始后Purview会读取Fabric里湖屋的Tables、数据仓库的表或视图以及部分定义元数据。根据Fabric资产规模和扫描设置的不同首次扫描可能需要一些时间。微软也在不断丰富扫描器对Fabric各种数据项的覆盖程度所以当你发现某些Fabric对象没有被扫出来时先检查Fabric对象类型是否在技术支持范围内再检查Purview权限配置不要直接判定产品不成熟。4.2 从数据湖到BI报表的一条完整血缘实例我给你一个我在真实项目中复现过的例子。假设业务是销售分析原始文件每天落到ADLS里Fabric数据工厂Pipeline把它们从文件中抽取到Lakehouse的bronze区随后一批SQL任务或者Spark任务把数据加工成gold层的销售汇总表再建一个语义模型给Power BI报表消费。在Fabric和Purview连通之后Purview里展开gold层销售表能看到大致血缘血缘节点存放位置作用ADLS源文件外部存储账户/容器原始交易数据落地数据复制活动Fabric Data Factory Pipeline从ADLS读取并写入湖屋Lakehouse bronze.ordersFabric Lakehouse Tables原始数据第一份托管副本数据加工任务Fabric SQL或Spark任务清洗与聚合Warehouse gold.salesFabric Warehouse面向分析的标准汇总事实表语义模型Sales ModelFabric/Power BI语义模型定义度量与维度关联Power BI报表销售日报Power BI报表业务查看与下钻分析当业务质疑报表数字时我可以沿着血缘链路逐层查看加工逻辑并快速判断是上游文件日期缺失还是中间某一步聚合条件被同事改掉了。没有这套血缘体系同样的问题往往要花数小时沟通。血缘的真正价值不是让你炫技而是把“数据会出错”这个工程事实变成可控、可追踪、可解释的流程。你还能用Purview做更进一步的约束。比如给某个Fabric湖屋表标记“高度机密”敏感度标签后在Power BI中通过敏感度标签继承让下钻明细的报表自动带上限制提示或水印。这些动作看起来小但在合规审计时可以节省大量证明成本。5. 真实项目里怎么推进从一个纯粹的Power BI环境迁移到Fabric加Purview5.1 先理清现状再动刀盘点资源、报表和数据敏感等级很多企业不是从零开始而是已经用了Power BI两年数据源包括Azure SQL、本地SQL Server、Excel甚至第三方SaaS。这种情况下直接买Fabric容量并尝试把所有数据导入容易把自己搞得筋疲力尽。更稳妥的路线是把现有资源先完整盘点一遍。建议把Power BI工作区列表导出来识别哪些报表还在高频使用哪些早就没人打开。重点迁移高频核心报表历史遗留报表可以保留在旧容量直到自然淘汰。然后梳理数据源清单给每个数据源标上业务域、更新频率、是否包含个人信息三项基本属性。这一步不需要引入复杂工具Excel加业务访谈就可以。这样做的好处是你在为Purview设计集合和敏感度标签时有了输入依据而不是等Fabric里几百张表扫出来后才手忙脚乱地补元数据。我甚至建议在开始Fabric付费容量之前先完成这份清单。宁可花两周盘点也不要急着买容量。5.2 容量迁移细节与预算评估关于Fabric容量的预算我通常给客户算一笔账。如果原Power BI环境使用一个P1容量对标到Fabric里就是F64容量。迁移后原有Power BI工作区下的所有数据集、报表可以继续使用不需要重新开发。这是最平滑的迁移路径。接下来需要评估的是你是否想在Fabric里跑比报表刷新更重的任务比如大范围Spark数据清洗和实时分析。这些任务会额外消耗同一个容量池里的CU。如果你沿用F64容量但数据加工任务非常多容量会在某些时刻出现明显延迟。建议初期预留每天的CU监控观察峰值期再判断是优化作业调度还是升级容量等级。不同规模对应参考F64适合原先P1负载F128对应更大的P2负载如果只有零散开发需求可以从F2或F4试起但要接受Spark任务在极小容量下运行缓慢的现实。每个区域价格不同实际金额可以用官方计算器查询这里重点提醒的是避免出现“买了大容量却只用来存数据”的浪费。你可以让工作区不挂到任何可运行容量上它依然能保存配置和数据只是无法正常调度任务。这个概念很适合做开发和测试的隔离。5.3 上线后的治理运营节奏把技术链路打通只是第一步真正决定成败的是日常运营节奏。建议按下面节奏推进第一周开通Fabric试用容量把所有核心Power BI工作区优先挂到Fabric容量上验证报表表现。第二周在Fabric中建一个湖屋迁移两到三条高价值数据源跑通湖屋加Warehouse的加工流程。第三周注册Purview把Fabric整体扫描纳入数据地图建立基础集合。第四周为最核心的财务和客户表补业务元数据、敏感度标签并开启周期扫描。接下来进入常态运营阶段每周检查一次血缘采集是否正常每月对照新发布的工作区微调集合。Purview和Fabric都支持较完善的自动能力但自动不等于无人看护。没有专人负责清理过期扫描、处理扫描异常治理体系会在一两个季度后逐步失真最终被业务同事遗忘。6. 我踩过和见过的坑以及你会问的几个基础问题6.1 权限模型Fabric数据访问与Purview数据目录千万不要混淆这是我在项目里见到最多的问题之一。Fabric有自己的权限体系包括工作区角色、湖屋或Warehouse的数据权限、OneLake的数据访问角色。Purview的集合角色则是另一套体系数据目录阅读者可以在Purview里搜索到这张表的存在看到它的schema甚至查看血缘图但这不代表他能直接在Fabric中查询该表的数据。反过来也一样你在Fabric中被授予了某工作区的查看权限Purview目录里不一定能看到对应资产。两套权限在架构上本来就不是一回事使用时不要假设“看到即访问”。如果企业要做严格的权限审计需要把Purview里的目录可见范围与Fabric的数据访问策略分别记录并确认数据安全策略定义在哪一层。最常见的隐患是数据科学家有Fabric湖屋写权限却没有Purview集合阅读权限导致他无法读到表的上下游信息。这个痛点在多人协作团队中会约束Fabric平台本身的易用性。6.2 容量消耗为什么比预期高Fabric的容量设计很容易让人产生“买了一个大池子随便用”的错觉。实际跑起来后你会发现Spark启动本身就会消耗一定CU任务是优先级高或频繁失败重试时CU消耗会被明显放大。另一个常见消耗点是Power BI的数据流和数据集刷新它们同样计算在同一个容量池中。我踩过一个很典型的坑用Power Query数据流每天早上高频刷新十几个中间表。过去Power BI Premium容量下还能应付迁移到Fabric容量后数据流刷新与几个Spark任务撞在同一个时段导致报表刷新延迟。排查过程让人抓狂因为任务都是独立成功的只是共享容量池被挤爆了。后来通过错峰调度、把高频数据流改造为增量刷新的数据工厂管道容量占用才降下来。给你的建议是上线第一个月一定要开启Fabric容量指标监控把每天的CU消耗趋势保存下来。看到消耗峰值明显超过可用容量时先优化任务调度不必急着升级容量。6.3 是不是所有数据都必须纳入Purview扫描按理说治理覆盖面越广越好但实际项目中我不建议把数据源一次性全部注册扫描。Purview扫描器会访问源系统并定期拉取元数据如果对象数量极大或者扫描规则设置不当可能对源库造成压力。比较务实的做法是先扫描高价值业务域财务、销售、客户、人力。测试库、临时备份和日志文件可以暂时不扫或者放低扫描频率。对同一个数据源也可以通过定义Scan Rule Set选择要扫描的对象类型。比如只扫表结构不扫数据内容或者只扫物化视图不扫存储过程。这套精细化配置能让你在成本、覆盖率和源端性能三者之间找到平衡。6.4 如果你还没有用Fabric现在迈出的第一步可以很小有些读者看完文章可能会觉得这个组合太庞大迟迟不敢动手。我的建议很简单先从Power BI现有环境开一个免费的Fabric试用容量把自己日常使用的一个工作区挂上去看看报表表现是否有变化。然后在Fabric里手动创建一个湖屋把一份测试Excel或CSV复制进去创建一份简单的语义模型。再开Purview把这个湖屋注册进去跑一次扫描观察血缘和目录效果。整个过程不需要改生产架构却能让你对容量消耗、术语命名、权限体会直观建立起来。走完这一步你会发现原来很多顾虑来自陌生感而不是复杂性。微软Fabric和Purview的能力边界虽然还在快速扩展但它们提供的核心价值已经非常清晰Fabric把数据工程和分析的门槛往下拉了一大截Purview则把数据资产变成可解释、可管控、可追溯的组织资源。两者配合起来企业才有可能从“有很多BI报表”走到“有一套可信数据平台”的状态。