1. 这不是“考前冲刺”而是一次对Fabric工程思维的系统性校准我坐在电脑前点下“Submit”按钮时屏幕右上角显示的分数是827。没有欢呼没有截图发朋友圈只有一阵真实的、带着疲惫的松弛感——不是因为终于解脱了而是因为过去六周里反复推演、亲手验证、甚至推翻重来的那些判断此刻被一个客观数字确认了我对Microsoft Fabric的理解终于从“能干活”升级到了“能讲清底层逻辑、能做合理权衡、能在模糊场景中给出经得起推敲的方案”。这和你手头那份《DP-600官方技能大纲》PDF、或是某家培训机构打包好的“7天速成课”完全不同。它不承诺“包过”也不贩卖焦虑它是一份来自真实战场的工单复盘记录里面记着我第一次模拟考58%时盯着屏幕发呆的尴尬记着我在Lakehouse和Warehouse之间反复横跳、直到深夜在OneLake目录里手动对比Delta文件结构才真正搞懂的顿悟也记着我为搞明白VACUUM到底删的是什么、又为什么不能提升查询速度硬是把Fabric文档里关于Delta事务日志_delta_log的三页技术说明逐字翻译、画了四张流程图的执拗。核心关键词就三个Fabric Analytics Engineer、Conceptual Clarity概念清晰度、Scenario-Based Judgment基于场景的判断力。这不是一场对Power BI拖拽能力或Notebook写代码熟练度的考试而是一场对你是否真正理解Fabric这个平台“设计哲学”的压力测试。它要确认你能否在客户说“我们需要一个能支持实时更新的财务报表”时不假思索地推荐Warehouse而不是凭直觉选Lakehouse它要确认你看到“Direct Lake查询变慢”时第一反应不是去调Power BI的视觉设置而是立刻检查语义模型里有没有触发Fallback到DirectQuery的DAX函数它更要确认你面对“给外部审计员只看销售数据、不看成本数据”这种需求时能准确说出该在OneLake层配置RLS策略而不是在Power BI模型里埋个筛选器完事。适合谁读如果你是已经用Fabric做了半年以上项目、能独立搭Pipeline、建Lakehouse、连Power BI的工程师但每次被问到“为什么这里要用Dataflow Gen2而不是Notebook”、“为什么这个场景下Direct Lake会fallback”时回答得有点含糊、需要临时查文档——那么这篇就是为你写的。它不教你怎么从零开始安装软件而是帮你把那些散落在日常操作缝隙里的“经验直觉”锻造成一套可复用、可解释、可传承的工程方法论。它解决的不是“会不会”的问题而是“为什么这么选才最合理”的问题。这恰恰是所有资深工程师和初级工程师之间那道看不见却真实存在的分水岭。2. 内容整体设计与思路拆解为什么放弃“面面俱到”选择“精准爆破”当我第一次打开微软官方DP-600学习路径看到密密麻麻的模块列表时本能反应是“全学”。毕竟考试大纲里写的清清楚楚“Implement and manage a Fabric analytics solution: ~35%”、“Ingest and transform data: ~25%”……百分比看起来很公平按比例分配时间似乎最稳妥。结果呢第一次模拟考58%分数条像一道刺眼的X光片照出了我知识结构里最致命的空洞——那个占比最高的35%恰恰是我投入精力最少、觉得“反正天天在用肯定没问题”的部分。这就是我整个学习计划最核心的底层逻辑转变从“覆盖知识点”转向“攻克认知盲区”。微软的考试设计非常狡猾它不考你能不能写出一行完美的PySpark代码而是考你能不能在四个看似都合理的架构选项中一眼识别出哪个最契合Fabric的设计原意。这种能力无法通过泛泛阅读文档获得只能通过“暴露弱点—定位根源—亲手验证—建立框架”的闭环来锻造。所以我的六周计划本质上是一个精密的“认知手术”流程。前两周是“诊断期”用微软Learn作为唯一信源不是为了记住所有细节而是为了绘制一张属于自己的“概念地图”。重点标记所有出现“vs”、“when to use”、“architectural decision”这类字眼的段落因为这些地方藏着考试最爱挖坑的“决策点”。比如文档里一句轻描淡写的“Lakehouse is optimized for large-scale, schema-flexible data; Warehouse is optimized for structured, relational workloads with full T-SQL DML”背后就是一道必考题的全部题干。第三、四周是“手术期”完全抛弃书本直接在Fabric试用工作区里开刀。我给自己设定了几个必须亲手完成的“最小可行性实验”第一创建一个同名的Lakehouse和Warehouse用完全相同的原始数据源分别执行INSERT/UPDATE/DELETE操作录屏对比报错信息和执行日志第二在同一个Lakehouse表上分别运行OPTIMIZE带V-Order参数和VACUUM不同retention period用Fabric内置的“Query Performance”面板记录每次查询的毫秒级耗时变化第三新建一个空白Workspace只添加Viewer角色然后尝试分享一个语义模型链接观察对方能访问哪些内容、哪些按钮是灰色的。这些实验耗时不多但每一个都像一把钥匙瞬间打开了之前死记硬背无法理解的概念锁。最后两周是“缝合期”用真题当X光机扫描前期所有实验的成果。我不再满足于知道“OPTIMIZE能提速”而是要精确到“在什么数据量级、什么查询模式下OPTIMIZE带来的性能提升超过15%而VACUUM在此场景下对查询无影响”。这种颗粒度的掌握才是应对考试里那种“A团队发现查询变慢B团队发现存储增长C团队发现历史版本太多”多线索并存的复合型场景题的底气。整个设计思路就是用最短的路径击穿最厚的认知壁垒把“我知道”变成“我确信”。3. 核心细节解析与实操要点五个决定成败的“认知锚点”3.1 OneLake统一底座下的双轨制Lakehouse与Warehouse的本质分野很多工程师包括我最初都把Lakehouse和Warehouse简单理解为“两种不同的数据存储容器”。这是最大的误区。它们真正的区别不在于“存哪里”而在于“谁来管、怎么管、管到什么程度”。它们共享同一个物理底座——OneLake但上面运行着两套截然不同的“操作系统”。Lakehouse的核心是Delta Lake协议。它把数据以Delta Parquet格式存入OneLake所有读写操作都必须遵循Delta的ACID事务规则。这意味着读取可以通过SQL Analytics Endpoint进行T-SQL查询但这是只读的。你看到的SELECT结果本质是Delta引擎在Parquet文件上构建的一层虚拟视图。写入必须通过SparkPySpark/Scala或Notebook执行。INSERT/UPDATE/DELETE这些DML操作最终都会被转换成Delta的事务日志_delta_log中的新条目并生成新的Parquet数据文件。你永远无法像操作传统数据库那样直接在一个连接里执行UPDATE语句。Warehouse的核心是SQL Server引擎。它同样将数据物理存储在OneLake但内部封装了一个高度优化的SQL Server实例。这意味着读取与写入完全支持标准T-SQL语法包括INSERT、UPDATE、DELETE、CREATE INDEX等。它的行为就是一个你熟悉的、关系型的、强Schema的数据仓库。性能特征对于需要频繁更新、复杂JOIN、强一致性保障的OLTP-like负载Warehouse的延迟和吞吐量远超Lakehouse的Delta写入路径。考试陷阱就藏在这里。题目不会问“Lakehouse支持UPDATE吗”而是给你一个场景“一家银行需要每日凌晨批量更新客户账户余额表要求事务强一致且下游报表需在更新后5分钟内可见。应选用哪种Fabric资源” 正确答案是Warehouse。因为Lakehouse的Delta写入虽然最终一致但其“小文件合并”Compaction过程存在微小延迟且UPDATE操作本身在Lakehouse中是低效的需先读取、再计算、再写入新版本。而Warehouse的T-SQL UPDATE是原子操作毫秒级完成。这个判断必须建立在对两者底层引擎差异的深刻理解之上而非简单的功能罗列。提示在Fabric试用工作区里你可以同时创建一个Lakehouse和一个Warehouse用同一份CSV数据源。然后在Warehouse里执行UPDATE [Sales] SET Amount Amount * 1.05 WHERE Year 2024再立刻在Lakehouse里尝试同样的语句——你会得到一个清晰的错误提示这比看一百页文档都管用。3.2 Direct Lake不是“直连”而是一场精密的“协议协商”Direct Lake常被误解为“Power BI直接读OneLake文件”这过于简化了。它实际上是一套由Power BI引擎、Fabric语义模型、OneLake Delta协议三方共同参与的、动态协商的查询执行协议。其核心机制是“三层能力映射”语义层Semantic Layer你的Power BI数据模型.pbix文件定义了表、列、关系、度量值DAX。执行层Execution LayerPower BI引擎分析当前查询例如一个包含SUM、FILTER、CALCULATE的DAX表达式判断其中哪些计算可以“下推”到OneLake的Delta引擎执行。存储层Storage LayerOneLake的Delta引擎接收下推的查询直接在Parquet文件上执行返回聚合后的结果集。只有当整个查询链路的所有环节都支持时Direct Lake才全程生效。一旦某个环节“掉链子”就会触发自动Fallback机制。这个机制是考试高频考点也是生产环境排查性能问题的关键。Fallback的触发条件非常具体DAX函数不支持LOOKUPVALUE、PATHCONTAINS、RANKX在某些上下文中、以及任何涉及跨表复杂计算的CALCULATE嵌套都可能导致部分计算无法下推。数据类型转换在模型中对日期列应用了FORMAT()函数或对数值列进行了非标准的字符串拼接。模型元数据变更当你在Fabric中修改了Lakehouse表的Schema如新增一列但没有在Power BI Desktop中刷新模型元数据此时首次查询会Fallback因为Power BI引擎无法确认新列的物理位置。关键认知是Fallback本身不是错误而是设计的一部分。但它会带来显著的性能差异。Direct Lake查询数据流是Power BI - OneLake (Delta Engine)延迟通常在毫秒级Fallback到DirectQuery后数据流变为Power BI - Fabric SQL Endpoint - OneLake (Delta Engine)多了一层网络跳转和SQL解析延迟可能升至秒级。考试会问“用户报告报表加载缓慢监控显示大量查询Fallback。首要排查步骤是什么” 答案不是“优化DAX”而是“检查语义模型元数据是否与OneLake源表Schema同步”。3.3 Delta表运维OPTIMIZE与VACUUM一对被严重误读的“孪生兄弟”在Lakehouse中数据写入会产生大量小的Parquet文件尤其在流式写入或小批量更新时。这些小文件是查询性能的隐形杀手因为引擎需要打开、读取、合并成百上千个文件才能返回结果。OPTIMIZE和VACUUM正是为此而生但它们的职责有严格分工混淆它们是考场上的高发错误。OPTIMIZE是纯粹的性能优化工具。它的核心动作是“文件合并”File Compaction它扫描指定表的Delta目录识别出所有小于某个阈值默认128MB的小Parquet文件。将这些小文件的内容读取、合并写入一个或多个更大的、更符合列式存储特性的新Parquet文件。在Fabric中OPTIMIZE还集成了V-Order优化。这是一种针对Power BI Direct Lake查询的特殊排序算法它会将Parquet文件内的数据块按照Power BI最常查询的维度如日期、产品ID进行物理重排使得Direct Lake引擎能以极高的IO效率读取所需数据块跳过无关块。这是Fabric独有的、对Direct Lake体验至关重要的增强。VACUUM是纯粹的空间管理工具。它的核心动作是“日志清理”Log CleanupDelta Lake通过事务日志_delta_log维护数据的历史版本支持Time Travel时间旅行查询。_delta_log中的每一条记录都指向一个特定时间点的数据快照。VACUUM的作用就是删除那些“过期”的快照所对应的旧Parquet文件。其清理窗口由RETENTION HOURS参数控制。默认是168小时7天。执行VACUUM TABLE my_table RETAIN 24 HOURS意味着只保留最近24小时内的所有快照更早的快照文件将被永久删除。二者绝不能混用。考试题常设陷阱“Lakehouse表查询响应时间变长应首先执行以下哪项操作” 四个选项分别是A) VACUUM B) OPTIMIZE C) REORGANIZE D) REFRESH。正确答案是B) OPTIMIZE。因为查询变慢的根源是小文件过多而VACUUM对此毫无帮助它只负责清理历史版本不碰当前活跃的数据文件。我曾在一次模拟考中因潜意识里认为“清理变快”两次选错VACUUM痛定思痛后我把这条规则写在了笔记本首页“VACUUM is for space, OPTIMIZE is for speed. Never confuse them.”3.4 Workspace治理从“功能开关”到“权限矩阵”的思维跃迁对于一线工程师Workspace治理常被视为“管理员的事”离开发很远。但DP-600彻底颠覆了这一认知。它要求你把Workspace当作一个完整的、有边界的“安全域”来理解其核心是三层权限体系的叠加。第一层是Workspace角色Role-based Access Control, RBAC。这是最粗粒度的控制决定了用户在Workspace内的“身份”Admin上帝视角可管理所有资源、成员、容量、设置。Member可创建、编辑、删除所有资源Lakehouse, Pipeline, Report但不能管理成员或容量。Contributor可创建、编辑、删除自己拥有的资源但不能删除他人资源也不能管理成员。Viewer只读权限可查看、运行RunPipeline、查看Report但不能编辑任何东西。第二层是Item级权限Item-level Sharing。这是对RBAC的精细化补充允许你绕过Workspace边界直接分享单个资源你可以将一个语义模型.bim文件单独分享给外部审计员而无需给他整个Workspace的Viewer权限。你可以将一个敏感的Lakehouse只授权给特定的Dataflow Gen2而不让它出现在其他人的Lakehouse列表中。这种分享是“邀请制”的被邀请者会收到一个链接点击后即可访问其权限仅限于该单项资源。第三层是Row-Level SecurityRLS的执行层。这是最容易被忽略的致命细节。RLS策略的配置位置和执行位置是分离的配置位置在Power BI Desktop的语义模型中通过“Modeling”选项卡下的“Manage Roles”创建。执行位置取决于连接模式在Import模式下RLS由Power BI服务端引擎在内存中执行过滤。在Direct Lake模式下RLS由OneLake的Delta引擎在数据读取源头执行过滤。这意味着如果一个DAX查询因为Fallback而走DirectQueryRLS策略可能失效或行为异常。考试会深挖这种组合。例如“一个使用Direct Lake的报表配置了RLS策略限制用户只能看到自己部门的数据。用户报告能看到所有部门数据。最可能的原因是” 答案是“该报表中使用了LOOKUPVALUE函数导致查询Fallback到DirectQuery从而绕过了OneLake层的RLS执行。” 这要求你必须将“连接模式”、“DAX函数兼容性”、“RLS执行位置”这三者视为一个不可分割的整体来思考。3.5 Dataflows Gen2超越ETL成为Fabric的“数据路由中枢”Dataflows Gen2常被当作“高级版Power Query”但这大大低估了它的战略地位。在Fabric架构中它是连接所有数据孤岛的“神经中枢”其核心价值在于多目的地写入Multi-Destination Write和查询折叠Query Folding的深度协同。多目的地写入是Gen2的革命性特性。一个Dataflow Gen2作业可以同时将处理后的数据写入三个不同的目标Lakehouse作为原始数据的规范化、清洗后版本供Notebook和Direct Lake消费。Warehouse作为高度聚合、面向报表的星型模型供Power BI DirectQuery或即席分析。Azure Data Lake Storage (ADLS)作为一份“黄金副本”供外部系统如Azure Synapse、机器学习训练直接访问。这种能力让Dataflows Gen2不再是一个孤立的ETL工具而是一个数据分发策略的编排中心。考试会考察你对这种策略的理解“一个企业需要将CRM数据同步至Fabric其中销售明细需供分析师用Notebook探索月度汇总需供高管看板实时展示原始数据需供AI团队训练模型。应如何设计Dataflow” 答案必然是一个Dataflow Gen2配置三个输出——Lakehouse明细、Warehouse汇总、ADLS原始。查询折叠则是性能的生命线。它决定了Dataflow的处理逻辑是在Power Query引擎中执行内存消耗大、速度慢还是被“折叠”回源头数据库执行高效、节省Fabric资源。折叠发生的前提是你使用的Power Query步骤能被源头数据库的查询语言如T-SQL、Spark SQL原生支持。能折叠的操作Filter Rows基于列的简单条件、Reorder Columns、Change Type基础类型、Group By简单聚合。不能折叠的操作Invoke Custom Function自定义函数、Merge Queries尤其是非等值JOIN、Date.StartOfWeek复杂的日期计算、Text.Proper文本格式化。考试陷阱在于“Staging”选项。启用Staging意味着Dataflow会先将中间结果如Filter后的数据暂存到OneLake的一个临时目录然后再进行后续步骤如Merge。这看似增加了IO但在处理超大数据集时它可以避免内存溢出并让后续的、无法折叠的步骤如Merge在OneLake的分布式环境中执行反而比在Power Query内存中执行更快。因此“是否启用Staging”不是一个非黑即白的选择而是一个需要根据数据量、步骤复杂度、可用容量进行权衡的工程决策。4. 实操过程与核心环节实现从“知道”到“做到”的完整闭环4.1 第一周用微软Learn绘制你的“概念地图”而非抄笔记我的第一周没有打开任何一个Fabric工作区也没有写一行代码。我做的唯一一件事是把微软Learn DP-600学习路径的前三个模块Fabric Fundamentals, Lakehouse, Warehouse当作一本“解构手册”来精读。我的目标不是记住所有术语而是找出所有隐藏的“决策点”。具体操作如下准备一个空白的Markdown文档命名为DP600_Concept_Map.md。逐模块阅读遇到以下内容立即停止记录到文档中所有出现“vs”、“compared to”、“differences between”的句子。例如“Lakehouse stores data as Delta Parquet files in OneLake. Warehouse stores data using a SQL Server engine on OneLake.” → 记录为# Lakehouse vs Warehouse | Storage: Delta Parquet vs SQL Server Engine。所有出现“when to use”、“best suited for”、“ideal for”的段落。例如“Use a Warehouse when you need full T-SQL DML support for transactional workloads.” → 记录为# When to use Warehouse | Scenario: Need full T-SQL DML (INSERT/UPDATE/DELETE)。所有带编号的“steps”或“phases”。例如“The lifecycle of a Delta table includes: 1. Write, 2. Optimize, 3. Vacuum, 4. Time Travel.” → 记录为# Delta Lifecycle | 1.Write - 2.Optimize - 3.Vacuum - 4.TimeTravel。对每个记录点强制自己用一句话总结其背后的“为什么”。例如对于“Warehouse支持DML”我的总结是“因为Warehouse底层是SQL Server它原生支持ACID事务而Lakehouse的Delta协议其DML是通过Spark作业模拟的本质是追加新版本日志无法原地更新。”这个过程枯燥但极其有效。一周结束时我的Concept_Map.md已经不再是笔记而是一张清晰的、带有因果关系的思维导图。它让我第一次意识到考试不是在考“是什么”而是在考“在什么条件下为什么选这个而不是那个”。这张图成为了我后续所有实操实验的“导航仪”。4.2 第三周亲手制造“故障”在试错中固化认知第二周的模拟考暴露了我的三大弱点Lakehouse/Warehouse选型、Delta运维、Workspace治理。第三周我关闭了所有文档只打开Fabric试用工作区开始了为期五天的“故障制造”实验。实验一Lakehouse/Warehouse选型实战创建两个同名工作区Test_Lakehouse和Test_Warehouse。使用同一个CSV文件10万行销售数据作为源。在Test_Lakehouse中尝试执行UPDATE Sales SET Amount Amount * 1.1 WHERE ProductID P001。记录错误信息“Operation not supported on Lakehouse tables.”在Test_Warehouse中执行完全相同的SQL。记录成功并在Power BI中连接验证数据已更新。结论当业务逻辑要求“原地修改”时Warehouse是唯一选择。Lakehouse的“不可变性”是其优势也是其边界。实验二OPTIMIZE与VACUUM的“显微镜”观察在Test_Lakehouse中创建一个表Sales_Raw并用Notebook循环插入1000次小批次每次100行数据。这会人为制造大量小文件。运行DESCRIBE DETAIL Sales_Raw记录numFiles文件数和sizeInBytes总大小。执行OPTIMIZE Sales_Raw ZORDER BY (SaleDate, ProductID)。再次运行DESCRIBE DETAIL观察numFiles锐减如从1200降到12sizeInBytes基本不变。执行VACUUM Sales_Raw RETAIN 1 HOURS。再次运行DESCRIBE DETAILnumFiles和sizeInBytes均无变化。结论OPTIMIZE改变文件物理结构VACUUM只清理历史日志。性能提升只来自OPTIMIZE。实验三Workspace角色的“沙盒”测试创建一个新WorkspaceTest_Security只添加一个Viewer角色的测试账号。在该Workspace中创建一个LakehousePublic_Data和一个语义模型Sales_Report.pbix。用Viewer账号登录尝试查看Public_Data的表结构→可以Viewer有读取权限。运行一个Pipeline→可以Viewer有Run权限。编辑Sales_Report.pbix→不可以灰色按钮。分享Sales_Report.pbix给外部邮箱→不可以无Share按钮。结论Viewer角色并非“完全只读”它拥有对Workspace内所有资源的“查看运行”能力但无“编辑分享”能力。这与直觉相悖必须亲手验证。这五天我没有“学会”任何新知识但我把抽象的概念变成了肌肉记忆般的条件反射。当考试中出现类似场景题时我脑中浮现的不是文字定义而是那个红色的错误提示框或是DESCRIBE DETAIL命令返回的精确数字。4.3 第五周用真题做“压力测试”把错题变成知识晶体第四周的模拟考我得了692分距离700只差8分。这8分就是我知识版图上最后的、也是最顽固的几块“浮冰”。第五周我放弃了所有新内容的学习只做一件事把第四周模拟考的每一道错题都还原成一个可执行的Fabric实验。例如错题“一个Dataflow Gen2配置了Staging但用户报告处理时间变长。可能原因” 我的复盘流程是定位知识点这题考的是Staging的适用场景和代价。查阅微软文档找到Dataflows Gen2 Staging的官方说明明确其原理“Staging writes intermediate results to OneLake, trading additional storage for improved reliability and parallelism on large datasets.”设计实验创建一个Dataflow Gen2源为1GB CSV。步骤1Filter Rows简单条件可折叠。步骤2Merge Queries与另一个大表Join不可折叠。首先禁用Staging运行并记录耗时假设为120秒。然后启用Staging运行并记录耗时假设为180秒。最后将源数据增大到5GB重复上述两步。分析结果在1GB数据下禁用Staging更快120s 180s因为Staging的额外IO开销超过了其收益在5GB数据下启用Staging更快200s 350s因为大内存操作失败Staging提供了可靠的中间存储。结论Staging不是“越开越好”而是“数据量越大收益越明显”。再例如错题“Direct Lake报表中一个使用CALCULATE(SUM(Sales[Amount]), FILTER(ALL(Sales), Sales[Year]2024))的度量值查询变慢。根本原因” 我的复盘是定位知识点CALCULATEFILTERALL的组合是典型的无法下推到Delta引擎的DAX模式。设计实验在Power BI Desktop中创建一个简单模型连接到Lakehouse。添加上述度量值。发布到Fabric打开报表。在Fabric Portal的“Monitor”中查看该报表的查询详情确认其执行模式为“DirectQuery”而非“DirectLake”。将度量值改为SUMX(FILTER(Sales, Sales[Year]2024), Sales[Amount])重新发布再查监控。分析结果第一个度量值Fallback第二个度量值保持Direct Lake。结论CALCULATE的复杂上下文切换是Fallback主因SUMX的迭代模式更易下推。这种“错题-实验-结论”的闭环将每一次失分都转化成了一个不可磨灭的知识晶体。它不再是一个需要死记硬背的“正确答案”而是一个刻在你工程直觉里的“决策原则”。5. 常见问题与排查技巧实录那些文档里不会写的“血泪教训”5.1 “我明明按文档做了为什么还是不行”——考试中的“微软语境”陷阱这是所有有实战经验的考生最常踩的坑。你用Fabric做了两年项目对Lakehouse的用法熟稔于心但考试里一道题却让你犹豫不决。原因只有一个你习惯了“我们公司是怎么用的”而考试只认“微软文档里是怎么说的”。最典型的例子是“Workspace Capacity”。在生产环境中我们常常会把F2容量免费试用用于开发把P1/P2用于生产因为P系列有更多CPU、内存和并发能力。这完全正确。但考试问“一个Fabric Trial Workspace提供多少vCore” 文档白纸黑字写着“A trial workspace provides one F2 capacity.” 它不会提“F2在生产中不够用”它只问“提供多少”。如果你脑子里想的是“F2太弱了我们从来不用”你就可能下意识地排除掉“F2”这个正确答案。另一个例子是“Direct Lake的Fallback”。你在项目中为了确保性能会刻意避免使用LOOKUPVALUE所以你对它的Fallback行为印象不深。但考试会问“以下哪个DAX函数最可能导致Direct Lake Fallback” 选项里有SUM、AVERAGE、LOOKUPVALUE、COUNTROWS。LOOKUPVALUE是唯一一个在官方文档中被明确列为“Not supported in Direct Lake”不支持的函数。其他函数都是支持的。这个答案必须从文档中找而不是从你的项目经验中猜。独家避坑技巧在备考的最后两周每天花30分钟专门重读微软Learn路径中所有带“Note”注意、“Important”重要、“Caution”警告标签的灰色方框。这些方框里的内容90%以上都会直接变成考题。把它们抄到你的Concept_Map.md里用加粗标出。这是最高效的“押题”。5.2 “时间不够用”——100分钟40-60题的节奏掌控术100分钟听起来很长但当你面对一道长达15行的场景题描述了一个包含5个角色、3个数据源、2个安全策略的复杂架构时100分钟会飞逝而过。我第一次模拟考就在第35题时发现只剩12分钟慌乱中连错三题。我的节奏方案是“三段式切割”第一阶段0-30分钟快速扫雷。用1.5分钟/题的速度快速过一遍所有题目。遇到30秒内无法确定答案的立刻Flag。目标是完成40题Flag约10-15题。这阶段的目标不是答对而是“清空题库”把所有简单题、确定题拿下为后面留出时间。第二阶段30-75分钟攻坚Flag题。集中火力用2.5-3分钟/题仔细分析Flag题。拿出草稿纸把题干中的关键实体如“Lakehouse A”、“Warehouse B”、“User Role C”和关系如“connects to”、“shares with”、“has RLS on”用箭头画出来。很多题的答案就藏在你画出的这个简易架构图里。第三阶段75-100分钟终极复查。最后25分钟只做两件事1) 检查所有Flag题的选项确认没有因为粗心选错如把“should not”看成“should”2) 快速浏览所有已答题重点看那些你凭“感觉”选的题用最朴素的逻辑再验证一次。例如一道题问“应如何保护敏感PII数据”选项有“A. 启用Workspace加密”、“B. 在OneLake中设置敏感标签”、“C. 在Power BI中设置视觉级筛选”。根据常识B是唯一一个在数据源头OneLake进行保护的选项A是基础设施层C是展示层都不够根本。注意Pearson VUE在线监考系统有一个隐藏功能当你Flag一道题后它的题号会变成黄色。在最后复查时你只需扫一眼屏幕左侧的题号栏所有黄色的题号就是你的“待办清单”无需翻页寻找省下宝贵时间。5.3 “我考了701但感觉没发挥好”——分数报告的深度解读指南考完后你会收到一份详细的分数报告按四大领域Implement Manage, Ingest Transform, Semantic Models, Explore Analyze给出“Above Average”、“Average”、“Below Average”的评级。很多人只看总分忽略了这份报告的巨大价值。我的报告里“Implement and manage a Fabric analytics solution”是“Above Average”而“Implement and manage semantic models”是“Average”。这告诉我我的短板不在宏观架构而在微观的DAX和模型部署细节。于是我立刻回到学习路径精准定位到“Semantic Models”模块下的“DAX Performance Best Practices”和“Deploying Semantic Models to Fabric”两个子章节用一天时间把里面提到的每一个性能反模式如FILTER滥用、CALCULATE嵌套过深都在自己的测试模型中复现、测量、优化。这份报告是你下一次学习的“精准制导地图”。它不会告诉你“DAX学得不好”而是告诉你“在‘Implement and manage semantic models’这个具体领域你的表现是Average”。这意味着你不需要重学整个DAX只需要聚焦在这个领域下微软官方认定的、与考试强相关的那几个子主题。这种基于数据的、颗粒度极细的复盘远比泛泛地“我要多学DAX”高效百倍。6. 资源取舍与个人经验为什么我烧掉了2000元只为买一套“不完美”的题库备考资源我经历了从“广撒网”到“精准捕捞”的痛苦蜕变。初期我下载了所有能找到的PDF、视频、GitHub笔记结果是信息过载大脑一片浆糊。后来我给自己立下铁律所有资源必须服务于一个明确的、可验证的目标。否则一律舍弃。微软Learn唯一不可动摇的基石。它是考试命题的“宪法”。我曾发现一个第三方教程说“Dataflow Gen2的Staging默认开启。” 我立刻去微软Learn查证发现原文是“Staging is disabled by default.” 我毫不犹豫地删掉了那个教程的链接。这个习惯救了我无数次。任何与微软Learn冲突的信息无论来源多么权威一律以Learn