Fabric工程师必懂的五大核心决策框架

1. 这不是“考前冲刺”，而是一次对Fabric工程思维的系统性校准

我是在一个周四下午收到DP-600成绩单的，屏幕右上角显示“823”——比700的及格线高出一截，但远没到满分。那一刻没有狂喜，只有一种沉甸甸的踏实感：过去六周里，我把那些在生产环境里用得顺手、却从未深究过“为什么必须这样”的操作，一条条拆开、重装、再验证。这考试根本不是在考你会不会点鼠标，它是在考你脑子里有没有一张清晰的Fabric架构地图，地图上标着每条路的起点、终点、限速、岔路口和应急出口。

如果你正看着这篇文字，大概率是位有实战经验的Fabric使用者：你建过Lakehouse，跑过Notebook，用Pipeline调度过ETL，Power BI报表也连过Direct Lake。但请先放下这份熟悉感——DP-600的残酷之处在于，它会把你最习以为常的操作，变成一道需要三重逻辑推演的选择题。比如，“当SQL开发团队要对财务数据执行UPDATE操作时，该选Lakehouse还是Warehouse？”答案看似简单，但考试会给你四个选项，其中三个都“能用”，而唯一正确的那个，必须同时满足：符合Microsoft官方架构定义、匹配T-SQL DML能力边界、契合场景中的数据治理要求。这种题目不考记忆，考的是你是否真正内化了Fabric的设计哲学。

我写这篇内容，核心就一个目的：帮你把“会做”升级为“懂为什么这么做”。它不提供速成口诀，不兜售万能题库，更不推荐任何带佣金链接的付费课程。所有内容都来自我亲手踩过的坑、反复验证过的操作、以及翻烂了的微软官方文档。你会发现，文中提到的每一个知识点，背后都有明确的文档出处、可复现的实操步骤、以及我在真实工作流中如何应用它的细节。比如Delta表的OPTIMIZE和VACUUM，我不会只告诉你“前者优化性能，后者清理历史”，而是会带你进Fabric UI，看执行前后文件数量的变化、查询耗时的对比曲线，甚至告诉你在什么数据量级下，手动触发OPTIMIZE比依赖自动优化更有效。这种颗粒度，才是工程实践者真正需要的“干货”。

关键词“Towards AI - Medium”在这里只是原始出处标记，它不定义内容价值。真正有价值的是：当你读完这篇，你能立刻打开自己的Fabric工作区，针对文中提到的五个核心领域（OneLake架构、Direct Lake机制、Delta运维、安全治理、Dataflows Gen2）做一次自我诊断——哪些地方你只是“用过”，哪些地方你已能向新同事清晰解释其设计原理与适用边界。这才是通过DP-600带来的最大收益：它逼你把零散的经验，锻造成可迁移、可传授、可验证的工程能力。

2. 内容整体设计与思路拆解：为什么放弃“全面覆盖”，选择“精准打击”

2.1 考试本质的再认知：从“技能清单”到“决策框架”

备考初期，我犯的最大错误，就是把DP-600当成一份待勾选的技能清单。看到大纲里写着“Implement security, row-level security, and workspace governance”，我就去学所有权限模型；看到“Monitor, troubleshoot, and optimize Fabric workloads”，我就去研究每个监控指标的计算公式。结果呢？两周后第一次模考58%，分数像一盆冰水浇下来。复盘时我才意识到：考试根本不是在检查你“会不会”，而是在检验你“能不能在复杂约束下做出最优决策”。

微软官方公布的技能权重（Implement and manage a Fabric analytics solution: ~35%）不是装饰数字，它是命题组的指挥棒。这意味着，与其花20小时死磕Spark集群内存参数调优（实际考试中几乎不考），不如用5小时彻底吃透“Lakehouse vs Warehouse”的决策树。这个决策树包含三个维度：数据形态（结构化/半结构化/非结构化）、访问模式（读多写少/读写均衡/高频DML）、消费方式（Power BI Direct Lake/External BI工具/API调用）。当这三个维度的答案组合起来，指向的必然是某个特定Fabric组件。考试里的场景题，就是把这三个维度打乱重组，看你能否瞬间匹配。

所以我的整个学习计划，核心逻辑就是“逆向拆解”：先拿到真题或高质量模考题，反向定位出高频考点；再回到官方文档，不是泛读，而是带着问题精读——“这个问题考察的是哪个决策框架？框架里最关键的判断依据是什么？我的实际经验是否与此一致？”这种以题带学的方式，让知识不再是孤立的点，而成为一张有连接、有优先级、有使用场景的网。

2.2 “跳过”不是偷懒，而是战略性的资源聚焦

文中明确列出的五项“可跳过”内容（Spark集群配置、实时分析细节、Power BI可视化、高级DAX、Purview集成），绝非轻视它们的价值，而是基于考试命题规律的理性取舍。举个具体例子：关于Spark配置，微软Learn文档里确实有一页讲“Executor Memory Overhead”，但翻遍所有公开的DP-600考题描述，从未出现过让你计算具体内存值的题目。相反，所有涉及Spark的题目，焦点都在“Notebook中运行PySpark代码时，如何选择合适的计算池类型（Starter/Standard）？”——这考的是对Fabric抽象层的理解，而非底层JVM调优。

这种取舍背后，是我对微软认证体系的长期观察：它考核的是“平台使用者”而非“平台构建者”。Fabric的Spark引擎是黑盒，你只需知道它在哪、怎么调用、何时该换池子；至于盒子内部怎么分配内存，那是Azure Synapse或Databricks工程师的战场。同理，Power BI可视化功能再强大，它属于PL-300（Power BI Data Analyst）的范畴。DP-600的边界非常清晰：你负责把数据准备好、模型建好、权限配好、性能调好，让分析师能用好。至于分析师怎么拖拽图表，不在你的责任田里。

因此，“跳过”清单的本质，是一份《考试ROI（投入产出比）分析报告》。它告诉你：把1小时花在理解Direct Lake的Fallback机制上，可能换来2道题的确定得分；而把1小时花在研究KQL数据库的索引策略上，大概率只是徒增焦虑。这种聚焦，不是降低标准，而是把有限精力，精准投向离及格线最近的那几厘米。

2.3 学习路径的“三阶跃迁”：从认知、到验证、再到内化

我的六周计划，严格遵循“认知→验证→内化”的三阶跃迁模型，每一阶段目标明确，绝不交叉：

• Weeks 1–2（认知筑基）：目标不是记住所有概念，而是建立“微软官方视角”。我强迫自己只用Microsoft Learn作为唯一信息源，哪怕某些描述比社区博客更枯燥。因为考试答案的唯一标准，就是Learn文档里的措辞。例如，Learn文档说“Warehouse provides full T-SQL support including INSERT, UPDATE, DELETE”，那么任何题干中出现“需要UPDATE操作”，答案必然是Warehouse，哪怕你在Lakehouse里用Notebook也能实现类似效果——考试不认“技术可行性”，只认“官方定义”。

• Weeks 3–4（验证闭环）：这是效率最高的阶段。我不再看书，而是打开Fabric免费试用版，针对模考暴露的弱点，构建最小可行实验（MVP）。比如，为搞清“Workspace Roles”，我创建了四个不同角色的测试用户，逐一尝试：Admin能否删除他人发布的语义模型？Contributor能否修改Lakehouse的Schema？Viewer能否看到Pipeline的执行日志？每个操作的结果，我都截图存档，并与Learn文档的权限矩阵表逐条比对。这种“动手即验证”的方式，让抽象的权限规则，变成了屏幕上清晰可见的“允许/禁止”弹窗。

• Weeks 5–6（内化输出）：目标是把知识转化为条件反射。我停止被动接收，转为主动输出：用纯白纸手绘OneLake架构图，标注Lakehouse/Warehouse/OneLake的关系；用Markdown整理“TOP 5易错陷阱”，每条都附上自己编写的模拟题；甚至对着镜子，用3分钟口头解释“Direct Lake Fallback的工作原理”。神经科学证实，主动回忆和费力提取，是巩固长期记忆最有效的方式。当你能不看笔记，流畅讲清楚一个概念，它才算真正属于你。

这种设计，确保了学习不是线性堆砌，而是螺旋上升。每一次验证，都在加固认知；每一次输出，都在深化理解。最终，你面对的不是一堆待背诵的知识点，而是一个随时可调用的、结构化的决策引擎。

3. 核心细节解析与实操要点：五个决定成败的关键领域

3.1 OneLake架构与Lakehouse/Warehouse决策框架：别再凭感觉选

OneLake是Fabric的基石，但很多人把它简单理解为“一个统一存储”。这远远不够。OneLake的本质，是一个元数据驱动的、跨服务的数据虚拟层。它不存储数据本身，而是存储指向数据的指针（URI）和描述数据的元数据（schema、partitioning、statistics）。Lakehouse和Warehouse，都是OneLake之上的逻辑层，它们共享同一份物理数据，但提供了完全不同的访问协议和能力边界。

Lakehouse的核心能力与限制：

• 数据格式：强制使用Delta Parquet，这是性能优化的基础。
• SQL访问：仅通过SQL Analytics Endpoint提供只读T-SQL查询。你可以SELECT * FROM table，但INSERT INTO table VALUES (...)会直接报错。
• DML操作：必须通过Spark/PySpark Notebook或Spark SQL执行。这意味着你需要编写代码，且操作发生在Spark计算层，而非数据库引擎层。
• Power BI连接：首选Direct Lake模式，直接读取Delta文件，零刷新延迟。
• 典型场景：海量日志分析、机器学习特征工程、需要Schema Evolution的物联网数据。

Warehouse的核心能力与限制：

• 数据格式：使用专为T-SQL优化的列式存储（非Delta Parquet）。
• SQL访问：提供完整T-SQL支持，包括INSERT,UPDATE,DELETE,MERGE,CREATE INDEX等所有DML和DDL操作。
• DML操作：原生数据库引擎执行，毫秒级响应，支持事务。
• Power BI连接：支持Direct Lake（读取Warehouse的Delta副本）和DirectQuery（直连Warehouse引擎）。
• 典型场景：传统数仓ETL、财务报表数据更新、需要强一致性保障的交易型分析。

提示：考试最爱的陷阱题，就是混淆“技术上可行”和“架构上正确”。例如：“某团队需每日凌晨更新客户主数据表，要求事务一致性。” 选项里可能有“用Notebook执行Spark SQL UPDATE”。技术上可行，但考试答案一定是“使用Warehouse”。因为Warehouse的设计目标就是承载这类高保真DML，而Notebook更新是绕过架构的“野路子”，不符合微软倡导的最佳实践。

实操验证步骤：

1. 在Fabric工作区创建一个Lakehouse和一个Warehouse，命名分别为LH_Sales和WH_Sales。
2. 向两者导入相同结构的销售数据（约10万行）。
3. 尝试在SQL Analytics Endpoint中对LH_Sales执行UPDATE，记录错误信息；对WH_Sales执行相同UPDATE，记录成功状态。
4. 在Power BI Desktop中，分别用Direct Lake模式连接两者，执行一个包含SUM(SalesAmount)和COUNT(*)的简单查询，记录首次加载时间。
5. 对比结果：LH_Sales的UPDATE失败，WH_Sales成功；Direct Lake连接LH_Sales通常更快（因Delta优化），但连接WH_Sales时，Direct Lake会读取其内部Delta副本，性能差异不大。

这个实验的成本极低（15分钟），但带来的认知颠覆是巨大的：它让你亲手触摸到两个组件的“灵魂差异”，而不是停留在文字描述。

3.2 Direct Lake模式：理解它的优雅，更要敬畏它的边界

Direct Lake被宣传为“Power BI的终极性能方案”，但它的魔力有严格的生效条件。考试不考你如何开启它，而是考你何时它会“失效”，以及失效后会发生什么。

Direct Lake的核心机制：

• 零拷贝读取：Power BI引擎不加载数据到本地内存，而是通过Arrow Flight协议，直接向OneLake发起请求，读取Delta Parquet文件的元数据（metadata）和所需列的数据块（data pages）。
• 智能Fallback：当查询包含Direct Lake无法处理的操作时（如：CALCULATE(..., ALL('Table'))中的ALL函数、某些复杂的嵌套FILTER、或引用了未发布到Lakehouse的外部表），Power BI会自动切换到DirectQuery模式，将查询下推到Lakehouse/Warehouse的SQL引擎执行。

关键陷阱与性能真相：

• Fallback不是故障，而是特性：很多考生误以为Fallback=失败。恰恰相反，它是Direct Lake健壮性的体现。但问题在于，DirectQuery模式下，查询需要经过SQL引擎解析、优化、执行，再将结果序列化传回Power BI，这个过程比Direct Lake慢3-10倍（取决于查询复杂度）。
• 元数据刷新 ≠ 数据刷新：Direct Lake不需要传统意义上的“数据刷新”，因为数据始终在OneLake。但它需要元数据刷新（Metadata Refresh），即更新Power BI对表结构（columns, data types, partitions）的认知。当Lakehouse中新增一列或修改数据类型时，必须手动触发元数据刷新，否则Power BI会报错“Column not found”。

注意：考试常考“某报表突然变慢，经查发现Direct Lake图标消失”，正确答案永远是“查询中包含了不支持的DAX函数，触发Fallback”。此时解决方案不是重做报表，而是重构DAX，用支持的函数替代（如用REMOVEFILTERS替代ALL）。

实操验证步骤：

1. 创建一个Lakehouse，导入销售数据，并在Power BI中用Direct Lake连接。
2. 构建一个基础报表，仅含SUM(SalesAmount)，确认Direct Lake图标亮起。
3. 在DAX中添加一个计算列：IsHighValue = IF([SalesAmount] > 10000, "Yes", "No")，保存并发布。
4. 观察报表：Direct Lake图标应保持亮起（计算列在模型层，不影响查询）。
5. 修改一个度量值：Total Sales (Fallback) = CALCULATE(SUM('Sales'[SalesAmount]), ALL('Sales'))，保存。
6. 观察报表：Direct Lake图标熄灭，查询变慢。此时打开Performance Analyzer，确认查询模式已变为DirectQuery。
7. 将度量值改为：Total Sales (Direct Lake) = CALCULATE(SUM('Sales'[SalesAmount]), REMOVEFILTERS('Sales'))，图标恢复，性能回归。

这个实验直观展示了DAX函数与Direct Lake兼容性的微妙关系，是备考中性价比最高的实操之一。

3.3 Delta表运维：OPTIMIZE与VACUUM，不是兄弟，是分工明确的搭档

Delta Lake的“自愈”能力是Fabric的亮点，但OPTIMIZE和VACUUM这两个命令，常被混为一谈。考试会用最直白的场景，逼你分清它们的职责。

OPTIMIZE：性能优化的“外科手术”

• 核心任务：合并小文件（small files）。Delta表在频繁写入（尤其是小批量流式写入）后，会产生大量<128MB的小Parquet文件。查询引擎需要打开并扫描数百个文件，I/O开销巨大。
• 执行效果：将多个小文件合并为更大的文件（默认目标大小1GB）。显著减少文件数量，提升查询吞吐量。
• Fabric特有功能：ZORDER BY和V-Order。ZORDER BY按指定列对数据进行物理排序，提升范围查询效率；V-Order是Fabric专属优化，专门针对Power BI Direct Lake的读取模式，将数据按列值分布重新组织，使Direct Lake能更高效地跳过无关数据块。
• 执行方式：OPTIMIZE [table_name] ZORDER BY (column1, column2)或OPTIMIZE [table_name] VORDER BY (column1)。

VACUUM：数据治理的“清洁工”

• 核心任务：清理旧版本文件（old versions）。Delta通过保留事务日志（_delta_log）实现Time Travel，每次UPDATE/DELETE都会生成新版本文件，旧版本文件被标记为“可删除”。
• 执行效果：物理删除超过保留期限（default: 7 days）的旧版本文件，释放OneLake存储空间。
• 关键限制：VACUUM绝不影响查询性能！它只删日志，不碰当前数据文件。试图用VACUUM解决查询慢的问题，是方向性错误。

提示：考试经典陷阱题：“某Lakehouse表查询缓慢，经检查发现存在大量小文件。应执行以下哪项操作？” 选项中必然有VACUUM。正确答案只能是OPTIMIZE。记住这个铁律：小文件→OPTIMIZE；旧版本→VACUUM。

实操验证步骤：

1. 创建一个Lakehouse表sales_delta。
2. 使用Notebook循环插入1000次，每次插入100行数据（模拟小批量写入）。执行后，用DESCRIBE DETAIL sales_delta查看numFiles（文件数）和sizeInBytes（总大小）。
3. 执行VACUUM sales_delta RETAIN 1 HOURS（设置极短保留期）。
4. 再次DESCRIBE DETAIL：numFiles和sizeInBytes几乎不变（因为只删了日志，没动数据文件）。
5. 执行OPTIMIZE sales_delta。
6. 再次DESCRIBE DETAIL：numFiles大幅下降（如从500+降至5），sizeInBytes可能微增（因文件头开销），但查询速度提升明显。
7. 对比执行SELECT COUNT(*) FROM sales_delta的耗时，OPTIMIZE后应快3倍以上。

这个实验成本极低，但能根除你对Delta运维最顽固的认知误区。

3.4 Workspace安全、角色与容量：从“能用”到“合规”的必修课

对于一线工程师，安全常被视为“管理员的事”。但在DP-600中，Workspace安全是权重高达35%的“实施与管理”板块的核心。它考的不是你能否点开设置页，而是你能否在给定业务需求下，设计出最小权限、最大安全的方案。

Workspace角色的精确边界：

• Admin：上帝权限。可管理所有资源、成员、容量、设置。陷阱：考试问“某外包团队需临时访问报表，但不能修改任何数据源”，给Admin角色是严重违规。
• Member：可创建、编辑、删除自己拥有的项目（Lakehouse, Pipeline, Report），可查看所有共享项目。关键点：Member可以删除整个Lakehouse，这是最高风险操作。
• Contributor：可创建、编辑、删除自己拥有的项目，但不能删除他人项目。可查看所有共享项目。这是日常开发最安全的角色。
• Viewer：只能查看和运行已共享的项目，不能创建、编辑、删除任何东西。适合给业务用户、管理层。

Item-Level Permissions：超越Workspace的精细控制Workspace角色是粗粒度的“门禁卡”，Item-Level是“房间钥匙”。你可以让一个Viewer角色的用户，只看到某个特定的语义模型，而对其它所有Lakehouse、Pipeline一无所知。操作路径：在语义模型的“...”菜单中，选择“Manage permissions” → “Share with specific people”。

Row-Level Security (RLS) in Direct Lake：一场跨层的权限接力这是DP-600最具迷惑性的考点。在Import模式下，RLS由Power BI引擎在内存中过滤；在Direct Lake模式下，RLS的执行点前移到了OneLake层。这意味着：

• Power BI发送的查询，会自动附加RLS过滤条件（如WHERE [Region] = 'North'）。
• 如果Lakehouse/Warehouse的SQL引擎能直接执行此过滤（即谓词下推成功），则高效完成。
• 如果过滤条件过于复杂（如涉及UDF、跨表JOIN），SQL引擎无法下推，则Direct Lake会Fallback到DirectQuery，由Power BI引擎在内存中过滤，性能暴跌。

注意：考试会问“为何启用RLS后Direct Lake报表变慢？”，答案必须是“RLS过滤条件无法被SQL引擎下推，导致Fallback”。解决方案是简化RLS规则，或确保其能被谓词下推。

Fabric Capacity：F-SKU与P-SKU的现实意义

• F-SKU（Free/Trial）：免费版，资源受限（CPU、内存、并发数）。适合学习、POC。关键限制：不支持Capacity Autoscale，不支持Premium features（如Git integration, Advanced monitoring）。
• P-SKU（Paid）：付费版，资源充足，支持全部功能。关键考点：当容量超限时，系统会Throttling（限流），即降低计算资源分配，导致Pipeline执行变慢、Notebook响应延迟，但不会删除你的数据或作业。这是微软设计的弹性保障，而非故障。

实操验证步骤：

1. 创建一个新Workspace，设置为Free Tier。
2. 添加两个用户：UserA（Contributor角色）、UserB（Viewer角色）。
3. UserA创建一个Lakehouselh_test和一个语义模型sm_test。
4. UserA在sm_test中设置RLS规则：[Region] = USERNAME()。
5. UserB登录，尝试在Workspace中查看lh_test（应失败，因Viewer无Lakehouse访问权）；尝试查看sm_test（应成功，因已共享）；尝试运行报表（应只看到自己用户名对应的区域数据）。
6. 切换Workspace为P-SKU，重复步骤5，观察体验差异（主要是性能，非功能）。

这个实验让你亲手体验“权限即代码”的严谨性，远胜于死记硬背角色列表。

3.5 Dataflows Gen2与Query Folding：让数据转换“事半功倍”的底层逻辑

Dataflows Gen2是Fabric中承上启下的枢纽，它连接着各种数据源与Lakehouse/Warehouse。考试不考你如何拖拽字段，而是考你能否预判“我的这个转换操作，会在哪里执行？”

Query Folding：性能的隐形开关

• 定义：当Power Query编辑器中的转换操作（如Filter Rows,Group By,Change Type）能被“折叠”（folded）到源系统（如SQL Server, Azure SQL DB）执行时，这些操作就在源数据库的引擎中完成，只将最终结果集拉回Fabric。这极大减少了网络传输和Fabric计算资源消耗。
• 可折叠操作：绝大多数基础操作（筛选、排序、聚合、类型转换）在支持的源系统上都能折叠。
• 不可折叠操作（Breaking the Fold）：
  • 自定义列（Custom Column）：任何使用#""或let语法的自定义逻辑。
  • 合并查询（Merge Queries）：如果合并的两个表来自不同源，或其中一个源不支持JOIN下推。
  • 某些日期函数：如Date.StartOfWeek()在部分源上不支持。
• 验证方法：在Power Query编辑器中，右键点击任意步骤 → “View Native Query”。如果能看到生成的SQL语句，说明前面所有步骤都已折叠；如果显示“Cannot generate native query”，则折叠在此处中断。

Staging in Dataflows Gen2：空间换时间的权衡

• 开启Staging：Dataflow会将中间结果（如清洗后的数据）先写入OneLake的一个临时位置，再从那里读取进行后续转换。
• 优势：对于大型数据集，避免了多次从源系统拉取全量数据，尤其当后续步骤需要多次引用同一中间结果时。
• 代价：占用额外OneLake存储空间，增加一次写入/读取I/O。
• 考试考点：“某Dataflow处理1TB数据，执行缓慢。已确认源系统性能良好。应如何优化？” 答案是“Enable Staging”，因为它将昂贵的源系统读取，替换为快速的OneLake本地读取。

实操验证步骤：

1. 创建一个Dataflow Gen2，源为一个中等大小的SQL Server表（如Sales）。
2. 添加步骤：Filter Rows（筛选Amount > 1000）→Group By（按Region求和）→Add Custom Column（"HighValue" & Text.From([Sum])）。
3. 右键“Group By”步骤 → “View Native Query”，应看到完整的SQLSELECT Region, SUM(Amount) ... WHERE Amount > 1000 GROUP BY Region，证明前两步已折叠。
4. 右键“Add Custom Column”步骤 → “View Native Query”，应显示错误，证明折叠在此中断。
5. 开启Staging（在Dataflow设置中），重新执行。观察执行日志：第一次执行会显示“Writing to staging location”，后续执行会显示“Reading from staging location”，总耗时下降。

这个实验揭示了Dataflow性能优化的底层逻辑：让计算尽可能靠近数据。这是所有大数据平台的黄金法则。

4. 实操过程与核心环节实现：从零开始的六周可复现计划

4.1 Week 1–2：以微软Learn为唯一信源的认知筑基

核心原则：只读“决策性内容”，跳过“操作性教程”

微软Learn的DP-600学习路径（learn.microsoft.com/credentials/certifications/fabric-analytics-engineer-associate）是考试的“宪法”。但它的模块设计并非为备考优化，而是为通用学习设计。我的做法是：带着考试大纲的权重，反向扫描Learn内容。

• Day 1–3：聚焦“Implement and manage a Fabric analytics solution”（35%）

  • 精读模块：“What is Microsoft Fabric?”、“Understand OneLake architecture”、“Compare Lakehouse and Warehouse”。
  • 重点标记：所有出现“when to use X vs Y”、“advantages of X over Y”、“limitations of Y”字样的段落。例如，在“Compare Lakehouse and Warehouse”页面，我会高亮：“Use Warehouse when you need full T-SQL DML support for transactional updates.” 这句话就是一道题的标准答案。
  • 跳过内容：所有“Click here to create your first Lakehouse”的图文教程。这些对考试无直接帮助，实操时自然会。

• Day 4–5：攻克“Ingest and transform data”（25%）

  • 精读模块：“Introduction to Pipelines”、“Work with Dataflows Gen2”、“Use Notebooks for data transformation”。
  • 重点标记：Dataflows Gen2的“Destination options”（Lakehouse/Warehouse/ADLS）、Notebook的“Compute pool types”（Starter/Standard）、Pipeline的“Trigger types”（Scheduled/Event-based）。
  • 制作决策表：用Excel创建一个三列表格：第一列“场景描述”（如“需要将数据写入多个目标”），第二列“可用工具”（Dataflows Gen2），第三列“关键配置”（在Destination设置中勾选多个目标）。

• Day 6–7：启动“Implement and manage semantic models”（20%）

  • 精读模块：“Create and manage semantic models in Fabric”、“Configure Direct Lake mode”、“Apply Row-Level Security”。
  • 重点标记：Direct Lake的“Prerequisites”（必须连接Lakehouse/Warehouse）、RLS的“Security model”（在Semantic Model中定义，而非Workspace中）。
  • 动手：在免费Fabric中，创建一个最简语义模型，仅包含一个表和一个度量值，然后启用Direct Lake。这是为了建立“手感”，而非追求功能。

Week 1结束时的交付物：

• 一份精炼的“Exam Notes”文档（Markdown格式），仅包含我标记的决策性语句，每条不超过30字。
• 一份“TOP 5模糊点”清单，如：“VACUUM的retention period单位是天还是小时？”、“Direct Lake Fallback的具体触发条件有哪些？”。这些问题，将成为Week 3实操的重点。

4.2 Week 3–4：用最小成本构建最大认知的Gap-Filling实验

核心原则：每个实验必须回答一个Week 1提出的“模糊点”，且能在1小时内完成

• Experiment 1：Lakehouse vs Warehouse的DML边界验证

  • 目标：验证“Lakehouse SQL endpoint是否真的不支持UPDATE”。
  • 步骤：
    1. 创建LakehouseLH_Test，导入一个简单表Products（ID, Name, Price）。
    2. 打开SQL Analytics Endpoint，执行SELECT * FROM Products（成功）。
    3. 执行UPDATE Products SET Price = Price * 1.1 WHERE ID = 1（预期失败，得到Operation not supported错误）。
    4. 创建WarehouseWH_Test，导入相同表。
    5. 在Warehouse的SQL endpoint中执行相同UPDATE（成功）。
  • 结论记录：Lakehouse的SQL endpoint是只读API，DML必须走Spark。考试中所有涉及“UPDATE/INSERT”的场景，答案必为Warehouse。

• Experiment 2：Direct Lake Fallback的DAX函数映射

  • 目标：找出哪些DAX函数会触发Fallback。
  • 步骤：
    1. 创建一个语义模型，连接到Week 1的Lakehouse。
    2. 创建度量值Total A = SUM('Sales'[Amount])（Direct Lake正常）。
    3. 创建度量值Total B = CALCULATE(SUM('Sales'[Amount]), ALL('Sales'))（Fallback触发）。
    4. 创建度量值Total C = CALCULATE(SUM('Sales'[Amount]), REMOVEFILTERS('Sales'))（Direct Lake恢复）。
  • 结论记录：ALL()是Fallback高危函数，REMOVEFILTERS()是其安全替代。考试中若见ALL()，立即警惕Fallback可能性。

• Experiment 3：OPTIMIZE/VACUUM的性能对比

  • 目标：量化二者对查询性能的影响。
  • 步骤：
    1. 创建Lakehouse表perf_test，用Notebook循环插入1000次，每次100行。
    2. 记录SELECT COUNT(*) FROM perf_test的初始耗时（假设为12.5秒）。
    3. 执行VACUUM perf_test RETAIN 1 HOUR，再次执行COUNT查询（耗时仍为12.5秒）。
    4. 执行OPTIMIZE perf_test，再次执行COUNT查询（耗时降至3.2秒）。
  • 结论记录：VACUUM不优化性能，OPTIMIZE是解决小文件问题的唯一手段。考试中“性能优化”题，答案必为OPTIMIZE。

• Experiment 4：Workspace Role的最小权限验证

  • 目标：验证Contributor角色是否真的不能删除他人Lakehouse。
  • 步骤：
    1. 用Admin账号创建两个用户：UserA（Contributor）、UserB（Contributor）。
    2. UserA创建LakehouseLH_A。
    3. UserB登录，尝试在Workspace中找到LH_A并点击“Delete”（按钮应为灰色，或点击后提示“Permission denied”）。
  • 结论记录：Contributor角色是开发者的安全基线，Admin角色应严格限制。

Week 4结束时的交付物：

• 一份详细的“实验日志”，包含每个实验的步骤截图、执行结果、耗时数据、以及一句总结性结论。
• 更新后的“Exam Notes”文档，将实验结论融入其中，形成“理论+实证”的双重确认。

4.3 Week 5–6：用真题驱动的深度复习与肌肉记忆训练

核心原则：不做新题，只做错题；不求多，只求透

• Practice Exam Strategy：

  • 来源：仅使用三个来源——微软官方免费Practice Assessment、一个付费题库（用于补充题量）、以及我自己从Learn文档中提炼的“伪题”（如：“根据Learn文档第X页，Warehouse的T-SQL支持范围是？”）。
  • 流程：
    1. 计时模拟：严格按100分钟完成，使用Pearson VUE的在线监考界面（可提前下载安装）。
    2. 即时标记：对所有不确定的题目，立即标记（Flag），不纠结。
    3. 深度复盘：这是最耗时也最有价值的一步。对每一道错题或标记题：
       • Step 1：定位知识源：翻开Learn文档，找到对应章节。
       • Step 2：重读定义：不是扫一眼，而是逐字阅读微软的原话。
       • Step 3：重构场景：用自己的话，把这个知识点，放进一个新的、合理的业务场景里，写成一道新题。
       • Step 4：反向验证：用新题去考自己，确保能答对。

• Example of Deep Review：

  • 错题：“Which Fabric item supports full T-SQL DML operations including UPDATE and DELETE?”
  • Step 1：定位到Learn文档“Compare Lakehouse and Warehouse”。
  • Step 2：重读原文：“Warehouse provides full T-SQL support, including INSERT, UPDATE, DELETE, and MERGE statements.”
  • Step 3：重构新题：“A financial reporting team needs to correct erroneous entries in their daily sales ledger. Which Fabric component should they use to execute the UPDATE statement?”
  • Step 4：自答：“Warehouse”，并确认理由与原文一致。

• Final Week的“Light Review”：

  • Day 1–3：只看自己写的“Exam Notes”和“实验日志”，不看任何外部资料。
  • Day 4：重做微软官方Practice Assessment，目标不是刷分，而是确认所有知识点都已内化。
  • Day 5–6：彻底休息。整理考试设备（摄像头、麦克风、网络），清空桌面，打印准考证。大脑需要空白，才能在考场上高速运转。

Week 6结束时的交付物：

• 一份“错题本”，包含所有错题的原题、正确答案、Learn文档出处、以及我自己重构的新题。
• 一份“信心清单”，列出5个