简介这是一份面向微软PL-300认证考试的PDF备考资料内容基于2024年8月最新考纲与出题趋势整理适合正在准备MCP、微软云认证以及Power BI Data Analyst认证的考生使用。资源共1个PDF文件压缩包约25.54MB主体为高仿真实战题集覆盖HOTSPOT拖拽题、单项选择题等主流题型并围绕Power BI存储模式选择、DirectQuery与Dual模式的适用场景、Dataverse连接器、数据刷新策略、模型性能优化等核心考点展开。每道题目均提供正确答案及官方文档参考链接便于读者在刷题的同时理解底层原理快速定位自身薄弱环节。目前已有142人学习下载。对于想在短时间内熟悉PL-300真实考题风格、巩固微软数据分析认证知识体系的考生来说这份资料可以直接用于考前冲刺、模拟自测和查漏补缺实用性强。1. PL-300 不是背题是拆 Power BI 建模链路PL-300 是微软 Power BI Data Analyst 方向的认证考试挂在 MCP 认证体系之下。这份 2024 年 8 月版的题库 PDF 是典型的真题回忆风格Hotspot、Drag Drop、多选和单选混排每题后面附着官方文档链接与社区投票分布。它有个容易被低估的价值题干里写满了 refresh requirements、表结构约束和数据分布描述这些约束比标准答案更值钱。真实接 BI 项目时没人会告诉你哪张表该用 Import、哪张该走 DirectQuery全是自己根据刷新频率和视觉性能妥协出来的。这份题库适合准备 PL-300 的人也适合想快速摸一遍 Power BI 建模边界的在职分析师把题当需求文档拆而不是当判断题背。2. 存储模式选型从 refresh requirements 反推 Import、DirectQuery 与 Dual2.1 先把刷新频率翻译成数据延迟约束题库第一道 Hotspot 题给了四条刷新要求Customer 每天刷新、Date 三年一次、Sales 近实时、SalesAggregate 每周一次。这四条不是摆设它们决定了每张表可接受的最大延迟。Import 是整表缓存一次刷新一次全量适合延迟容忍度高的低频表DirectQuery 不缓存视觉交互时实时查源库适合需要秒级新鲜度的场景Dual 则把选择权交给查询上下文同一张表某些查询走缓存某些查询直连数据源。做这类题只知道三种模式的字母含义不够。隐藏约束在于混合存储模式下DirectQuery 表与 Import 表之间只能建立 limited relationship也就是 Power BI 界面里的虚线关系。虚线关系不能双向过滤跨模式计算时性能会明显劣化。所以答案里 Customer、Date 两张维度表全部选 Dual不是巧合而是为了同时兼容 DirectQuery 的 Sales 表和 Import 的 SalesAggregate 表让模型不裂成两半。2.2 三种存储模式的性能特征对比模式是否缓存查询路径刷新依赖典型场景Import是只读缓存按计划刷新低频维度、聚合表、复杂 DAXDirectQuery否实时请求源库依赖源库性能近实时大事实表Dual两者皆可由查询上下文决定刷新计划和源库都影响跨 Import/DirectQuery 的维度表Dual 的运行时判断逻辑大致是查询上下文里同时出现 DirectQuery 表和 Dual 表时Dual 表以 DirectQuery 方式参与上下文里只有 Import 表和 Dual 表时Dual 表走缓存。这带来一个工程陷阱Dual 并不是「永远最快」你在建模阶段无法断言某次查询一定命中缓存。我一般会在报表发布前用 DAX Studio 逐页看 Server Timings确认高频页面没有意外打到源库而不是等业务方投诉加载慢。2.3 逐表拆解为什么是 Dual、DirectQuery、ImportCustomer 要每日刷新说明数据在处理变化但它主要承担维度筛选量级通常可控。为什么不选 Import因为 Sales 是 DirectQueryCustomer 若是纯 Import两者关系会退化成 limited relationship跨模式过滤时视觉加载反而变慢。Dual 让 Customer 跟随 Sales 的查询上下文走同一条路径关系保持完整同时保留每日刷新的缓存副本。Date 三年才刷一次数据几乎静态理论上 Import 最优。但 Date 也是 Sales 的过滤维度同样面临 limited relationship 问题。选 Dual 之后Date 在与 Sales 同框的视觉对象里直连源库在只关联 Import 表的页面里走缓存。这里有个细节Date 表通常只有几千行即使每次走 DirectQuery开销也可控所以这个选择的风险很低。Sales 选 DirectQuery 的原因最直接近实时意味着源库数据分钟级变化全量 Import 会逼着模型十几分钟刷一次成本高且跟不上业务。DirectQuery 把查询下推到 SQL 数据库代价是 DAX 的一部分函数不可用时间智能类函数在 DirectQuery 下会被限制因为 SQL 无法等价翻译。这个限制在题目里没写但实际开发中是最常见的报错来源。如果 Sales 选 Dual 也一样危险近实时刷新要求查询必须直达数据源Dual 的缓存路径基本用不上反而引入行为不确定性。SalesAggregate 选 Import 是最反直觉也最好记的一条聚合表的存在意义就是牺牲新鲜度换性能。如果聚合表也走 DirectQuery用户点一次切片器就实时聚合一次等于没建。每周刷新一次的 Import 聚合表让所有视觉交互只面对缓存数据这才是题干里「minimize the load times of visuals」的真正落点。2.4 用 DMV 验证当前模型的存储模式选择题背完真正要练的是在自己的模型里看懂现状。DAX Studio 或 SSMS 连上 Power BI 模型后执行下面这条 DMVSELECT [Name], [StorageMode] FROM $SYSTEM.TMSCHEMA_TABLES返回结果里 StorageMode 一列会直接显示每张表是 Import、DirectQuery 还是 Dual。如果模型里维度表与事实表之间出现虚线关系图标第一反应去查这两张表的 StorageMode通常是一边 Import 一边 DirectQuery。把维度表改成 Dual 再刷新虚线关系会恢复为实线。这个操作在 Tabular Editor 里只是改一个属性但很多人做模型半年都没意识到关系虚线意味着什么。提示Dual 不是万能选项。如果一张维度表行数很大又总与 DirectQuery 表一起出现在切片器里它每次都会直连源库反而让源库压力翻倍。合理做法是把大维度表拆成常用属性与明细属性两张表常用属性保持 Dual。3. Power Query 合并与追加Join Kind 是怎么决定数据完整性的3.1 Merge 和 Append先分清「加列」还是「加行」PL-300 题库里 Power Query 相关题占了接近三分之一。第一类高频问题是「两张表要合在一起用 Merge 还是 Append」。判断标准其实很机械目标是往每行后面补字段比如 Customer 表要带上 City、State/Region、Country这是 Merge横向扩展目标是把两个结构相同的表按行堆叠比如两个 Azure SQL 数据库的 Customer 表合成一张这是 Append纵向扩展。方向判断错后面所有步骤都白做。另一个区分点是关系语义Merge 会引入表之间的关联与匹配键Append 假设两张表已经语义统一只是物理上分开存储。3.2 一次标准的双表合并M 语言的参数拆解用题目里 Customer 和 Address 的例子在 Power Query 里做 Merge生成的核心 M 代码长这样let Merge1 Table.NestedJoin( Customer, // 左表 {AddressID}, // 左表匹配键 Address, // 右表 {AddressID}, // 右表匹配键 Addr, // 新列名右表以嵌套表形式挂进来 JoinKind.Inner // 使用内连接 ), Expand1 Table.ExpandTableColumn( Merge1, Addr, {City, State/Region, Country}, {City, State/Region, Country} ) in Expand1Table.NestedJoin 的参数顺序固定左表、左表键、右表、右表键、嵌套列名、连接类型。注意它不会直接把右表字段展开到顶层而是先以嵌套表形式放进一个新列所以下一步必须用 Table.ExpandTableColumn 把需要的列提出来。Expand 第三个参数写原列名第四个参数写展开后的新列名两边数量要一致。实际项目里 Address 可能有十五列不要用 Select All 全展开只挑 City、State/Region、Country减少进入数据模型的列数后续步骤的引用成本也低。列名映射最好直接写明确避免后续步骤里引用列名时还得回头找。3.3 Inner、Left Outer 到底怎么选题目 #6 的三表合并是 Power Query 题里最典型的一类。Product、ProductSubCategory、ProductCategory 三级结构题干给了两个条件每个 Product 一定有 SubCategory但不是每个 SubCategory 都有 Category。对应答案第一段合并用 Inner因为不会丢行第二段合并用 Left Outer因为要保留 SubCategory 全部行右侧 Category 没有匹配就填空。这里最能看出一个人是否真的理解 JoinInner 和 Left Outer 的区别不在性能而在数据完整性语义。选 Inner 的前提是确认左表每一行都能命中右表选 Left Outer 的前提是确认左表有行在右表找不到匹配且这些行必须保留。合并顺序对性能也有明显影响。先用 Inner 把 Product 和 ProductSubCategory 压成一张小表再和 ProductCategory 做 Left Outer中间数据集行数最小。反过来先做 Left Outer 再 Inner第一段就把中间表撑大整个查询的耗时和内存占用都会上去。我一般把这个顺序当经验记先做能缩小行数的连接再做会保留空值的连接。Join Kind保留逻辑适用前提Inner两边键都匹配才保留左表每一行都必然命中右表Left Outer保留左表所有行右表无匹配填空左表可能有行在右表找不到匹配3.4 追加两张同构表还要让模型变瘦两个 SQL 数据库各有一张 Customer合并方式选 Append Queries as New生成的底层函数是 Table.Combinelet CombinedCustomers Table.Combine({ 数据库A_Customer, // 第一个数据源导出的查询 数据库B_Customer // 第二个数据源导出的查询 }) in CombinedCustomersTable.Combine 要求两张表列名一致按列名匹配而不是按位置。数据类型也必须统一一边是整数一边是文本合并后整列会变成文本后面还要用 Change Type 拉回来。题目的第二个要求是 minimize the size of the data model做法是回到查询列表把 数据库A_Customer 和 数据库B_Customer 这两个源查询都右键取消勾选 Enable Load。它们只作为中间数据参与最终查询计算不再单独进模型。注意取消 Enable Load 不等于取消刷新调度刷新时它们依然会执行只是结果不占模型内存。这个细节是很多把模型做到几百 MB 才回头优化的分析师容易漏掉的一步。3.5 合并后去重与列类型确认题目 #9 补充了另外一个场景两个 Sheet 里的产品合并到一列且不能有重复值。在 Merge 或 Append 完成之后去重用 Power Query 界面上的 Remove Duplicates生成的 M 函数是 Table.Distinct。这里要注意去重键的范围只对目标列去重而不是对整行去重。如果两张表除了产品名还有其他属性列整行去重不会生效必须先把列裁剪到只剩产品名或者用 Table.Distinct 的第二个参数指定作用列。这个操作顺序错误会导致最终表里重复项还在排查时很难发现。4. 连接器选型与数据接入Dataverse、SharePoint、CSV 三个高频考点4.1 Dataverse 是 Power Apps 在 Teams 里的数据落点Power BI 报告要连接一个完全托管在 Teams 里的 Power Apps 应用选哪个连接器题库给的正确答案是 Dataverse。这题表面是考 connector 记忆背后是数据生态逻辑Teams 里的 Power Apps 默认运行在 Power Platform 环境业务数据存在 Dataverse也就是之前的 Common Data Service。Microsoft Teams Personal Analytics 是分析个人 Teams 行为数据的连接器数据模式与项目管理不匹配SQL Server 是自建或独立数据库的接入方式题干里没提到任何 SQL 连接串选它是凭空猜测。提示看到题目描述里出现「应用由 Power Apps 开发」优先在 Power Platform 分类下找连接器。Dataverse 是默认答案除非题干明确提到外部 SQL Server 或其他数据库。4.2 SharePoint folder 与 Excel workbook 是两种维护成本题目 #3 说 Excel 文件放在 SharePoint 文件夹里要新建报告且最小化开发。选项里同时出现 Excel workbook 和 SharePoint folder 时标准选择是 SharePoint folder。原因有两点第一文件夹连接器会把文件夹内所有文件连同子文件夹信息拉出来你可以在 Power Query 里按 Folder Path 过滤第二配合 Combine 功能同构 Excel 文件会被合并成一个表后续有新报表文件放进同一个文件夹刷新时自动纳入。Excel workbook 连接器需要写死文件路径新增文件等于改数据源维护成本高。实际操作时在 Power BI Desktop 里选 Get Data → SharePoint folder粘贴站点 URL认证方式选组织账户。连接成功后 Navigator 里看到的是文件清单包括文件名、Folder Path、扩展名、访问时间。此时点 Combine Transform 会基于第一个文件推断结构把同构文件合并之后在查询里按 Folder Path 过滤就能只保留目标库的文件。Combine Load 是一键到底适合确定文件夹里没有脏文件的场景只要目录结构稍微复杂我的习惯都是先进 Transform 看一眼。判断点SharePoint folderExcel workbook新文件自动纳入是否需手动改路径同构多文件合并支持 Combine单文件适合场景报表文件持续投放单份稳定工作簿4.3 CSV 时间字段直接换类型是个坑题目 #10 的 Logged 列格式是 2018-12-31 at 08:59。很多人第一反应是 Change Type 成 Date但 CSV 文件本身没有数据类型导入时整列是文本。直接把含 at 的字符串改成 DatePower BI 会在转换阶段报错或把整列置为 null。正确做法是先拆分Transform → Split Column → By Delimiter分隔符填 at 取最左侧部分再对新列做 Date 类型转换。let Source Csv.Document(File.Contents(complaints.csv)), Split Table.SplitColumn( Source, Logged, Splitter.SplitTextByDelimiter( at , QuoteStyle.Csv), 2 ) in SplitSplitter.SplitTextByDelimiter 第三个参数 2 表示拆成两段第一段是日期第二段是时间。拆完之后再把第一列类型改成 Date。这个坑点在真实项目里很常见运维系统导出的 CSV时间字段总是带奇怪的分隔符正确顺序永远是「先拆分再定型」而不是直接改类型。题目里的另一种解法是提取前 11 个字符本质和按分隔符拆分等价只是实现路径不同。4.4 Combine Transform 与 Combine Load 的取舍题目 #8 的场景是 SharePoint Online 有多个文档库其中一个库放同构的制造报表 Excel要求只加载制造报表库。如果直接 Combine Load系统会把站点里所有匹配的 Excel 都并进来万一其他文档库里有同结构但对不上业务口径的文件数据就脏了。正确做法是先选 Combine Transform进入 Power Query 编辑器后按 Folder Path 过滤只留目标库路径再加载。这步能省掉后面大量清洗工作。我的习惯是涉及批量文件接入时永远先进编辑器除非你能拍胸脯说文件夹里只有目标文件。5. 用一道 DRAG DROP 题验证自己的决策链5.1 把题目翻译成数据假设题库 #6 的三表合并是一道拉分题。拿到题先不急着选把它转换成两个问题Product 到 ProductSubCategory 是「一定有」还是「可能有」关系SubCategory 到 ProductCategory 是「一定有」还是「可能有」关系。题干原文分别是 every product has a subcategory 和 not every subcategory has a parent category。前者决定 Inner后者决定 Left Outer。这个翻译步骤如果每次做 Power Query 题都保留比背答案有效得多。PL-300 作为 MCP 认证里的 Power BI 核心科目这类 Drag Drop 题考的就是你在真实数据面前能不能快速判断数据完整性。5.2 验证工具与文档对照第二章里用 DMV 验证过的存储模式在 DAX Studio 的 Server Timings 页面能看到每次查询中哪些表命中 VertiPaq 缓存、哪些走了 DirectQuery。我一般用它验证 Dual 表的实际行为同一个视觉对象切片器条件不同执行计划里显示的模式会变化。这个验证结论反过来可以指导模型设计。遇到不确定的 Join 类型不用猜把题干里的表结构抽两条样例数据在 Power Query 里分别跑一遍 Inner 和 Left Outer结果一眼就清楚了。5.3 一套可落地的错题复盘清单做错的 Hotspot 题先查微软官方 storage mode 文档再在测试模型里改一遍存储模式用 DMV 对比前后关系图标变化。Merge 相关的 Drag Drop 题手动造两条样例数据在 Power Query 里试做不同 Join Kind把差异截图或注释留档。连接器题答错去 Get Data 面板看候选连接器的描述文本重点关注「平台」和「数据所在环境」关键词。刷新策略题换算成时间窗口这个数据源多久变化一次模型能容忍多久延迟答案自然浮出来。遇到选项里有 Disable Load记住它和「不刷新」的区别禁用的是加载不是执行。做错不丢人丢人的是第二次做错同样的题还不去动一次手。本文还有配套的精品资源点击获取 PL-300备考与Power BI实战：存储模式、查询合并与连接器选型解析
简介这是一份面向微软PL-300认证考试的PDF备考资料内容基于2024年8月最新考纲与出题趋势整理适合正在准备MCP、微软云认证以及Power BI Data Analyst认证的考生使用。资源共1个PDF文件压缩包约25.54MB主体为高仿真实战题集覆盖HOTSPOT拖拽题、单项选择题等主流题型并围绕Power BI存储模式选择、DirectQuery与Dual模式的适用场景、Dataverse连接器、数据刷新策略、模型性能优化等核心考点展开。每道题目均提供正确答案及官方文档参考链接便于读者在刷题的同时理解底层原理快速定位自身薄弱环节。目前已有142人学习下载。对于想在短时间内熟悉PL-300真实考题风格、巩固微软数据分析认证知识体系的考生来说这份资料可以直接用于考前冲刺、模拟自测和查漏补缺实用性强。1. PL-300 不是背题是拆 Power BI 建模链路PL-300 是微软 Power BI Data Analyst 方向的认证考试挂在 MCP 认证体系之下。这份 2024 年 8 月版的题库 PDF 是典型的真题回忆风格Hotspot、Drag Drop、多选和单选混排每题后面附着官方文档链接与社区投票分布。它有个容易被低估的价值题干里写满了 refresh requirements、表结构约束和数据分布描述这些约束比标准答案更值钱。真实接 BI 项目时没人会告诉你哪张表该用 Import、哪张该走 DirectQuery全是自己根据刷新频率和视觉性能妥协出来的。这份题库适合准备 PL-300 的人也适合想快速摸一遍 Power BI 建模边界的在职分析师把题当需求文档拆而不是当判断题背。2. 存储模式选型从 refresh requirements 反推 Import、DirectQuery 与 Dual2.1 先把刷新频率翻译成数据延迟约束题库第一道 Hotspot 题给了四条刷新要求Customer 每天刷新、Date 三年一次、Sales 近实时、SalesAggregate 每周一次。这四条不是摆设它们决定了每张表可接受的最大延迟。Import 是整表缓存一次刷新一次全量适合延迟容忍度高的低频表DirectQuery 不缓存视觉交互时实时查源库适合需要秒级新鲜度的场景Dual 则把选择权交给查询上下文同一张表某些查询走缓存某些查询直连数据源。做这类题只知道三种模式的字母含义不够。隐藏约束在于混合存储模式下DirectQuery 表与 Import 表之间只能建立 limited relationship也就是 Power BI 界面里的虚线关系。虚线关系不能双向过滤跨模式计算时性能会明显劣化。所以答案里 Customer、Date 两张维度表全部选 Dual不是巧合而是为了同时兼容 DirectQuery 的 Sales 表和 Import 的 SalesAggregate 表让模型不裂成两半。2.2 三种存储模式的性能特征对比模式是否缓存查询路径刷新依赖典型场景Import是只读缓存按计划刷新低频维度、聚合表、复杂 DAXDirectQuery否实时请求源库依赖源库性能近实时大事实表Dual两者皆可由查询上下文决定刷新计划和源库都影响跨 Import/DirectQuery 的维度表Dual 的运行时判断逻辑大致是查询上下文里同时出现 DirectQuery 表和 Dual 表时Dual 表以 DirectQuery 方式参与上下文里只有 Import 表和 Dual 表时Dual 表走缓存。这带来一个工程陷阱Dual 并不是「永远最快」你在建模阶段无法断言某次查询一定命中缓存。我一般会在报表发布前用 DAX Studio 逐页看 Server Timings确认高频页面没有意外打到源库而不是等业务方投诉加载慢。2.3 逐表拆解为什么是 Dual、DirectQuery、ImportCustomer 要每日刷新说明数据在处理变化但它主要承担维度筛选量级通常可控。为什么不选 Import因为 Sales 是 DirectQueryCustomer 若是纯 Import两者关系会退化成 limited relationship跨模式过滤时视觉加载反而变慢。Dual 让 Customer 跟随 Sales 的查询上下文走同一条路径关系保持完整同时保留每日刷新的缓存副本。Date 三年才刷一次数据几乎静态理论上 Import 最优。但 Date 也是 Sales 的过滤维度同样面临 limited relationship 问题。选 Dual 之后Date 在与 Sales 同框的视觉对象里直连源库在只关联 Import 表的页面里走缓存。这里有个细节Date 表通常只有几千行即使每次走 DirectQuery开销也可控所以这个选择的风险很低。Sales 选 DirectQuery 的原因最直接近实时意味着源库数据分钟级变化全量 Import 会逼着模型十几分钟刷一次成本高且跟不上业务。DirectQuery 把查询下推到 SQL 数据库代价是 DAX 的一部分函数不可用时间智能类函数在 DirectQuery 下会被限制因为 SQL 无法等价翻译。这个限制在题目里没写但实际开发中是最常见的报错来源。如果 Sales 选 Dual 也一样危险近实时刷新要求查询必须直达数据源Dual 的缓存路径基本用不上反而引入行为不确定性。SalesAggregate 选 Import 是最反直觉也最好记的一条聚合表的存在意义就是牺牲新鲜度换性能。如果聚合表也走 DirectQuery用户点一次切片器就实时聚合一次等于没建。每周刷新一次的 Import 聚合表让所有视觉交互只面对缓存数据这才是题干里「minimize the load times of visuals」的真正落点。2.4 用 DMV 验证当前模型的存储模式选择题背完真正要练的是在自己的模型里看懂现状。DAX Studio 或 SSMS 连上 Power BI 模型后执行下面这条 DMVSELECT [Name], [StorageMode] FROM $SYSTEM.TMSCHEMA_TABLES返回结果里 StorageMode 一列会直接显示每张表是 Import、DirectQuery 还是 Dual。如果模型里维度表与事实表之间出现虚线关系图标第一反应去查这两张表的 StorageMode通常是一边 Import 一边 DirectQuery。把维度表改成 Dual 再刷新虚线关系会恢复为实线。这个操作在 Tabular Editor 里只是改一个属性但很多人做模型半年都没意识到关系虚线意味着什么。提示Dual 不是万能选项。如果一张维度表行数很大又总与 DirectQuery 表一起出现在切片器里它每次都会直连源库反而让源库压力翻倍。合理做法是把大维度表拆成常用属性与明细属性两张表常用属性保持 Dual。3. Power Query 合并与追加Join Kind 是怎么决定数据完整性的3.1 Merge 和 Append先分清「加列」还是「加行」PL-300 题库里 Power Query 相关题占了接近三分之一。第一类高频问题是「两张表要合在一起用 Merge 还是 Append」。判断标准其实很机械目标是往每行后面补字段比如 Customer 表要带上 City、State/Region、Country这是 Merge横向扩展目标是把两个结构相同的表按行堆叠比如两个 Azure SQL 数据库的 Customer 表合成一张这是 Append纵向扩展。方向判断错后面所有步骤都白做。另一个区分点是关系语义Merge 会引入表之间的关联与匹配键Append 假设两张表已经语义统一只是物理上分开存储。3.2 一次标准的双表合并M 语言的参数拆解用题目里 Customer 和 Address 的例子在 Power Query 里做 Merge生成的核心 M 代码长这样let Merge1 Table.NestedJoin( Customer, // 左表 {AddressID}, // 左表匹配键 Address, // 右表 {AddressID}, // 右表匹配键 Addr, // 新列名右表以嵌套表形式挂进来 JoinKind.Inner // 使用内连接 ), Expand1 Table.ExpandTableColumn( Merge1, Addr, {City, State/Region, Country}, {City, State/Region, Country} ) in Expand1Table.NestedJoin 的参数顺序固定左表、左表键、右表、右表键、嵌套列名、连接类型。注意它不会直接把右表字段展开到顶层而是先以嵌套表形式放进一个新列所以下一步必须用 Table.ExpandTableColumn 把需要的列提出来。Expand 第三个参数写原列名第四个参数写展开后的新列名两边数量要一致。实际项目里 Address 可能有十五列不要用 Select All 全展开只挑 City、State/Region、Country减少进入数据模型的列数后续步骤的引用成本也低。列名映射最好直接写明确避免后续步骤里引用列名时还得回头找。3.3 Inner、Left Outer 到底怎么选题目 #6 的三表合并是 Power Query 题里最典型的一类。Product、ProductSubCategory、ProductCategory 三级结构题干给了两个条件每个 Product 一定有 SubCategory但不是每个 SubCategory 都有 Category。对应答案第一段合并用 Inner因为不会丢行第二段合并用 Left Outer因为要保留 SubCategory 全部行右侧 Category 没有匹配就填空。这里最能看出一个人是否真的理解 JoinInner 和 Left Outer 的区别不在性能而在数据完整性语义。选 Inner 的前提是确认左表每一行都能命中右表选 Left Outer 的前提是确认左表有行在右表找不到匹配且这些行必须保留。合并顺序对性能也有明显影响。先用 Inner 把 Product 和 ProductSubCategory 压成一张小表再和 ProductCategory 做 Left Outer中间数据集行数最小。反过来先做 Left Outer 再 Inner第一段就把中间表撑大整个查询的耗时和内存占用都会上去。我一般把这个顺序当经验记先做能缩小行数的连接再做会保留空值的连接。Join Kind保留逻辑适用前提Inner两边键都匹配才保留左表每一行都必然命中右表Left Outer保留左表所有行右表无匹配填空左表可能有行在右表找不到匹配3.4 追加两张同构表还要让模型变瘦两个 SQL 数据库各有一张 Customer合并方式选 Append Queries as New生成的底层函数是 Table.Combinelet CombinedCustomers Table.Combine({ 数据库A_Customer, // 第一个数据源导出的查询 数据库B_Customer // 第二个数据源导出的查询 }) in CombinedCustomersTable.Combine 要求两张表列名一致按列名匹配而不是按位置。数据类型也必须统一一边是整数一边是文本合并后整列会变成文本后面还要用 Change Type 拉回来。题目的第二个要求是 minimize the size of the data model做法是回到查询列表把 数据库A_Customer 和 数据库B_Customer 这两个源查询都右键取消勾选 Enable Load。它们只作为中间数据参与最终查询计算不再单独进模型。注意取消 Enable Load 不等于取消刷新调度刷新时它们依然会执行只是结果不占模型内存。这个细节是很多把模型做到几百 MB 才回头优化的分析师容易漏掉的一步。3.5 合并后去重与列类型确认题目 #9 补充了另外一个场景两个 Sheet 里的产品合并到一列且不能有重复值。在 Merge 或 Append 完成之后去重用 Power Query 界面上的 Remove Duplicates生成的 M 函数是 Table.Distinct。这里要注意去重键的范围只对目标列去重而不是对整行去重。如果两张表除了产品名还有其他属性列整行去重不会生效必须先把列裁剪到只剩产品名或者用 Table.Distinct 的第二个参数指定作用列。这个操作顺序错误会导致最终表里重复项还在排查时很难发现。4. 连接器选型与数据接入Dataverse、SharePoint、CSV 三个高频考点4.1 Dataverse 是 Power Apps 在 Teams 里的数据落点Power BI 报告要连接一个完全托管在 Teams 里的 Power Apps 应用选哪个连接器题库给的正确答案是 Dataverse。这题表面是考 connector 记忆背后是数据生态逻辑Teams 里的 Power Apps 默认运行在 Power Platform 环境业务数据存在 Dataverse也就是之前的 Common Data Service。Microsoft Teams Personal Analytics 是分析个人 Teams 行为数据的连接器数据模式与项目管理不匹配SQL Server 是自建或独立数据库的接入方式题干里没提到任何 SQL 连接串选它是凭空猜测。提示看到题目描述里出现「应用由 Power Apps 开发」优先在 Power Platform 分类下找连接器。Dataverse 是默认答案除非题干明确提到外部 SQL Server 或其他数据库。4.2 SharePoint folder 与 Excel workbook 是两种维护成本题目 #3 说 Excel 文件放在 SharePoint 文件夹里要新建报告且最小化开发。选项里同时出现 Excel workbook 和 SharePoint folder 时标准选择是 SharePoint folder。原因有两点第一文件夹连接器会把文件夹内所有文件连同子文件夹信息拉出来你可以在 Power Query 里按 Folder Path 过滤第二配合 Combine 功能同构 Excel 文件会被合并成一个表后续有新报表文件放进同一个文件夹刷新时自动纳入。Excel workbook 连接器需要写死文件路径新增文件等于改数据源维护成本高。实际操作时在 Power BI Desktop 里选 Get Data → SharePoint folder粘贴站点 URL认证方式选组织账户。连接成功后 Navigator 里看到的是文件清单包括文件名、Folder Path、扩展名、访问时间。此时点 Combine Transform 会基于第一个文件推断结构把同构文件合并之后在查询里按 Folder Path 过滤就能只保留目标库的文件。Combine Load 是一键到底适合确定文件夹里没有脏文件的场景只要目录结构稍微复杂我的习惯都是先进 Transform 看一眼。判断点SharePoint folderExcel workbook新文件自动纳入是否需手动改路径同构多文件合并支持 Combine单文件适合场景报表文件持续投放单份稳定工作簿4.3 CSV 时间字段直接换类型是个坑题目 #10 的 Logged 列格式是 2018-12-31 at 08:59。很多人第一反应是 Change Type 成 Date但 CSV 文件本身没有数据类型导入时整列是文本。直接把含 at 的字符串改成 DatePower BI 会在转换阶段报错或把整列置为 null。正确做法是先拆分Transform → Split Column → By Delimiter分隔符填 at 取最左侧部分再对新列做 Date 类型转换。let Source Csv.Document(File.Contents(complaints.csv)), Split Table.SplitColumn( Source, Logged, Splitter.SplitTextByDelimiter( at , QuoteStyle.Csv), 2 ) in SplitSplitter.SplitTextByDelimiter 第三个参数 2 表示拆成两段第一段是日期第二段是时间。拆完之后再把第一列类型改成 Date。这个坑点在真实项目里很常见运维系统导出的 CSV时间字段总是带奇怪的分隔符正确顺序永远是「先拆分再定型」而不是直接改类型。题目里的另一种解法是提取前 11 个字符本质和按分隔符拆分等价只是实现路径不同。4.4 Combine Transform 与 Combine Load 的取舍题目 #8 的场景是 SharePoint Online 有多个文档库其中一个库放同构的制造报表 Excel要求只加载制造报表库。如果直接 Combine Load系统会把站点里所有匹配的 Excel 都并进来万一其他文档库里有同结构但对不上业务口径的文件数据就脏了。正确做法是先选 Combine Transform进入 Power Query 编辑器后按 Folder Path 过滤只留目标库路径再加载。这步能省掉后面大量清洗工作。我的习惯是涉及批量文件接入时永远先进编辑器除非你能拍胸脯说文件夹里只有目标文件。5. 用一道 DRAG DROP 题验证自己的决策链5.1 把题目翻译成数据假设题库 #6 的三表合并是一道拉分题。拿到题先不急着选把它转换成两个问题Product 到 ProductSubCategory 是「一定有」还是「可能有」关系SubCategory 到 ProductCategory 是「一定有」还是「可能有」关系。题干原文分别是 every product has a subcategory 和 not every subcategory has a parent category。前者决定 Inner后者决定 Left Outer。这个翻译步骤如果每次做 Power Query 题都保留比背答案有效得多。PL-300 作为 MCP 认证里的 Power BI 核心科目这类 Drag Drop 题考的就是你在真实数据面前能不能快速判断数据完整性。5.2 验证工具与文档对照第二章里用 DMV 验证过的存储模式在 DAX Studio 的 Server Timings 页面能看到每次查询中哪些表命中 VertiPaq 缓存、哪些走了 DirectQuery。我一般用它验证 Dual 表的实际行为同一个视觉对象切片器条件不同执行计划里显示的模式会变化。这个验证结论反过来可以指导模型设计。遇到不确定的 Join 类型不用猜把题干里的表结构抽两条样例数据在 Power Query 里分别跑一遍 Inner 和 Left Outer结果一眼就清楚了。5.3 一套可落地的错题复盘清单做错的 Hotspot 题先查微软官方 storage mode 文档再在测试模型里改一遍存储模式用 DMV 对比前后关系图标变化。Merge 相关的 Drag Drop 题手动造两条样例数据在 Power Query 里试做不同 Join Kind把差异截图或注释留档。连接器题答错去 Get Data 面板看候选连接器的描述文本重点关注「平台」和「数据所在环境」关键词。刷新策略题换算成时间窗口这个数据源多久变化一次模型能容忍多久延迟答案自然浮出来。遇到选项里有 Disable Load记住它和「不刷新」的区别禁用的是加载不是执行。做错不丢人丢人的是第二次做错同样的题还不去动一次手。本文还有配套的精品资源点击获取