企业官网建设流程全解析

最近几个月，身边越来越多做数据平台的人开始问我同一个问题：微软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的S3+Glue+Redshift+SageMaker，或者选Azure的ADLS+Data Factory+Synapse+Power 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里找半天找不到，其实连接被集中放到了工作区或湖屋的“连接”设置中。

再比如Spark，Fabric里做数据工程的入口不是创建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层销售表能看到大致血缘：

当业务质疑报表数字时，我可以沿着血缘链路逐层查看加工逻辑，并快速判断是上游文件日期缺失，还是中间某一步聚合条件被同事改掉了。没有这套血缘体系，同样的问题往往要花数小时沟通。血缘的真正价值不是让你炫技，而是把“数据会出错”这个工程事实变成可控、可追踪、可解释的流程。

你还能用Purview做更进一步的约束。比如给某个Fabric湖屋表标记“高度机密”敏感度标签后，在Power BI中通过敏感度标签继承，让下钻明细的报表自动带上限制提示或水印。这些动作看起来小，但在合规审计时可以节省大量证明成本。

5. 真实项目里怎么推进：从一个纯粹的Power BI环境迁移到Fabric加Purview

5.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报表”走到“有一套可信数据平台”的状态。