Power BI 是微软推出的商业智能(BI)与数据可视化平台,由桌面设计器 Power BI Desktop、云端服务 Power BI Service、本地部署组件 Power BI Report Server 及嵌入式分析 SDK 组成。它将「数据获取与清洗、语义建模、可视化分析、发布共享、权限管控、定时刷新」整合为一条完整链路:业务分析师用桌面版拖拽完成从 Excel、SQL Server、API 等数百种数据源的接入,用 DAX(微软为度量值设计的公式语言,用于定义复杂的业务计算)建立指标体系,再一键发布到云端,由 IT 统一配置行级安全(RLS,按用户身份过滤数据行)与刷新计划。与传统 Excel 手工报表相比,Power BI 以「单一语义模型(统一管理表、关系和度量值的数据层)+ 统一权限 + 自助分析」解决口径分散、版本混乱、刷新靠人的问题;与纯代码方案相比,它把 BI 全流程的操作门槛降到业务人员可直接使用,同时又通过 XMLA(工业标准的分析接口协议)、REST API 和 Microsoft Fabric 集成向工程师开放扩展能力。本文按「安装配置 → 快速上手 → 核心能力 → 生产部署 → 选型对比」组织,并附常见误区、面试题与学习资源,读完即可开始构建第一个报表并规划企业级部署。
掌握 Power BI 是 AI 从业者从数据处理走向业务交付的必备技能:你能用语义模型统一数据口径,用 DAX 表达复杂业务规则,并通过 REST API 与 Fabric 将分析能力嵌入到应用和 AI 工作流中。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Power BI:从手工报表到企业级自助分析
传统企业在报表环节的典型痛点是:数据散落在 Excel、ERP、数据库和第三方系统中,业务人员每天手工复制粘贴、用 VLOOKUP 拼接、再通过邮件反复传递版本;IT 部门则需要为每张报表单独开发,需求排队以周为单位,导致「报表出来时业务已经不需要了」。更严重的是口径不统一——同一个「销售额」,财务、销售、管理层各有一套算法,开会时对不上数,决策建立在不一致的数据之上。
Power BI 用一条流水线解决上述问题:Power Query(内置的数据清洗引擎)负责从多源获取与转换数据,语义模型统一表和度量值的口径,可视化让业务人员拖拽生成图表,发布到云端后由 IT 统一配置 RLS 权限、敏感度标签、定时刷新和审计日志。业务人员不再等 IT 排期,可以基于统一授权的数据自行探索;IT 则把管控收回到模型层,做到「数据一处管理、口径全局一致」。此外,Power BI 不是孤立的报表工具,它与 Office 365、Azure、Teams 和 Microsoft Fabric 深度集成,并能通过 REST API 嵌入到自研应用。
与同类工具的气质差异在于:Tableau 强在视觉探索自由度和图形表现力,但建模能力弱于 Power BI;FineBI 强在中国式报表和私有化部署;而 Power BI 的核心竞争力是「语义层 + 微软生态」,DAX 的表达能力和 XMLA 开放性是它的护城河。
安装与环境配置:3 步就绪
步骤一,安装 Power BI Desktop。Power BI Desktop 仅支持 Windows;Mac 用户通过浏览器使用 Power BI Service,或在虚拟机/远程桌面中运行桌面版。推荐通过 Microsoft Store 搜索「Power BI Desktop」安装(自动更新),或从官网下载安装包手动安装(安装后仍需从内置入口检查更新)。已配置 winget 的 Windows 10/11 可直接用命令行安装。
步骤二,登录与基础配置。首次启动后使用 Microsoft 账号登录即可使用桌面版的全部建模功能;免费账号的报表只能保存在「我的工作区」并供个人查看,要发布到共享工作区、配置计划刷新和 Copilot,需要 Power BI Pro、Premium Per User(PPU)或 Fabric 容量许可。在「文件 → 选项和设置 → 选项 → 区域设置」中确认语言和时区,避免日期与货币格式错乱。
步骤三,验证安装。启动桌面版后,进入「文件 → 帮助 → 关于」查看版本号,正常应显示 2025-05 版(2.144.x)或更高;在「文件 → 帮助」中可点击「检查更新」确认已是最新月度版本。用下面的命令完成 winget 安装与验证:
# 方式一:winget 安装(Windows 10/11)winget install --id Microsoft.PowerBI --accept-package-agreements # 方式二:Microsoft Store 搜索 “Power BI Desktop” 点击获取 # 验证已安装版本winget list --id Microsoft.PowerBI
快速上手:30 分钟发布第一个报表
最小可用流程是「导入数据 → 清洗 → 建模 → 画图 → 发布」,全程在桌面版图形界面中完成,不需要写一行代码。第一次操作建议使用一个 Excel 文件(一张订单明细表 + 一张产品表)作为数据源,流程如下:
1. 获取数据:打开 Power BI Desktop,在「主页 → 获取数据」中选择「Excel」,选中文件后勾选需要的工作表并点击「加载」。需要连接 SQL Server、CSV、网页或 API 时,同样从该入口选择对应连接器。
2. 清洗数据:在「主页 → 转换数据」进入 Power Query 编辑器,删除空行、修正列数据类型、重命名列;需要把产品表关联到订单表时,用「合并查询」按产品 ID 做关联。完成点击「关闭并应用」把数据加载进模型。
3. 建立模型:进入「模型」视图,检查表间关系线是否自动建立;若没有,把订单表的「产品 ID」拖动到产品表的「产品 ID」上。在「建模 → 新建表」中创建日期表:日期表 = CALENDAR(DATE(2024,1,1), DATE(2025,12,31))。
4. 定义度量值:在「报表」视图右键订单表,选择「新建度量值」,输入总销售额 = SUM('订单明细'[金额]),按回车即建成第一个指标。
5. 拖拽可视化:在右侧「可视化」窗格选择柱状图,把「日期表」的日期拖到 X 轴、把「总销售额」度量值拖到 Y 轴,拖动生成图表;在「格式」窗格中设置标题与颜色。
6. 发布与共享:保存为 .pbix 文件后点击顶部「发布」,选择目标工作区;进入 Service 后可在工作区中打开报表、创建仪表板并向同事分享,再到数据集设置中配置每日计划刷新。
结果说明:以上 6 步即完成一个「按日期看销售额」的可交互报表,发布后同事通过浏览器即可查看。进阶技巧:用 DAX 计算组减少重复度量值;数据集开启 XMLA 读端点后用 Tabular Editor 批量管理模型;在 PPU/Fabric 容量中启用 Copilot 辅助编写 DAX 和生成报表摘要。
核心能力详解:4 大支柱
支柱一,Power Query 数据获取与清洗。内置 M 语言(Power Query 使用的函数式转换语言)驱动,提供数百个数据连接器,覆盖 Excel、SQL Server、SAP、Azure、网页和各类 API。支持合并(按列关联)、追加(按行拼接)、分组、透视、自定义列与条件列等操作,所有清洗步骤都以「步骤」形式记录,刷新时自动重放,保证 ETL(数据抽取、转换、加载的流程)可重复、可审计,是最适合 AI 工程师做数据预处理的入口。
支柱二,语义模型与 DAX。Power BI 的核心资产是语义模型——一套包含表、关系、度量值和 RLS 规则的数据层。DAX 是其计算语言,最重要的函数是 CALCULATE(修改筛选上下文并对表达式重新求值),配合时间智能函数(如 TOTALYTD 计算年初至今累计)能表达绝大多数业务规则。度量值(Measure)在查询时按筛选上下文动态计算、不占存储;计算列(Calculated Column)在刷新时逐行固化、占用模型内存,能用度量值实现的就不要建计算列。
支柱三,可视化与交互分析。默认提供柱状图、漏斗图、地形图等上百种原生视觉对象,并可从 AppSource 安装自定义视觉。报表支持书签(保存页面快照)、钻取(点击进入明细页)、工具提示(悬停显示附加信息)等交互方式;Q&A 自然语言查询让用户用中文直接提问生成图表,Copilot 可生成 DAX、摘要与叙事分析。桌面版还支持 Python/R 脚本视觉,发布到 Service 后需要配置个人网关才能运行。
支柱四,共享、部署与嵌入。报表以工作区为共享单元,通过应用(App)统一分发;部署管道(Deployment Pipelines)提供开发、测试、生产三阶段发布流程;Power BI Report Server 支持把报表部署到隔离内网;XMLA 端点和 REST API 允许外部工具与程序读写数据集;分页报表(基于 SQL Server Reporting Services 渲染引擎的像素级精确报表格式)面向财务对账单、发票等固定版式场景。
生产部署与监控:从上线到运维
部署方式一,标准上云发布。桌面版开发完成后发布到工作区,用部署管道划分开发、测试、生产三套工作区,测试通过后再向生产推送;正式环境通过「设置 → 计划刷新」配置数据刷新(Pro 每数据集每日最多 8 次,Fabric 容量/PPU 最多 48 次),数据量大的场景评估增量刷新。基于 Fabric 容量承载的工作区在许可调整后可支持免费许可证用户查看,配置前先核对官方许可文档。
部署方式二,本地与混合部署。本地 SQL Server 或文件共享作为数据源时,必须在 Windows 服务器上安装「本地数据网关」(On-premises Data Gateway),云端刷新请求经该网关安全访问内网数据源。完全不能出网的环境可部署 Power BI Report Server(需要 SQL Server 企业版带软件保障的授权),在本地门户中管理 PBIX 报表与分页报表。
部署方式三,嵌入式分析。在 Fabric 容量中把语义模型发布为共享数据集,通过 Power BI REST API 获取嵌入令牌(Embed Token),把报表渲染进自研 SaaS 产品;嵌入令牌按用户身份应用 RLS 过滤,实现多租户隔离。这种方式适合 ISV 为客户提供报表看板,减少自研可视化层的工作量。
可观测性方面:在 Service 中查看数据集「刷新历史」定位刷新失败;用 Microsoft Purview 审计日志追踪访问与导出行为;下载 Fabric 容量指标应用(Capacity Metrics App)监控 CPU 与内存过载;桌面版用「性能分析器」逐项查看每个视觉对象的查询耗时,配合 DAX Studio 定位慢查询。
<p class=“para-label“>避坑清单:</p><ul class=”dash-list”><li>免费许可证只能在「我的工作区」使用,无法发布到共享工作区,共享至少需要 Pro;规划架构前先确认许可证矩阵,避免开发完无法分发。</li><li>本地数据源在云上定时刷新必须部署本地数据网关,并确保网关所在服务器能出网访问 443 端口,否则刷新记录会持续失败。</li><li>计算列会在刷新时固化为模型列并占用内存,能用度量值实现的业务规则不要建计算列,否则模型膨胀会拖慢整个报表。</li><li>桌面版的预览功能(含部分 Copilot 能力)发布到 Service 后可能不可用或行为不同,上线前必须在目标容量环境中实测一遍。</li><li>导入模式会一次性全量加载数据,字段过多或基数过高会显著降低刷新与查询速度,应裁剪列、降低粒度并评估增量刷新方案。</li></ul>
| 维度 | Power BI | Tableau | FineBI(帆软) | Looker Studio |
|---|---|---|---|---|
| 定位 | 微软生态一体化的企业 BI 平台 | 专注可视化探索的 BI 平台 | 国内企业级自助分析与中国式报表 | 谷歌系免费云端报表工具 |
| 部署模式 | 桌面 + SaaS(Service)+ 本地(Report Server) | 桌面 + 服务器/云(Tableau Cloud) | 私有化部署为主,也提供 SaaS | 纯云 SaaS,无本地版 |
| 数据建模 | 语义模型 + DAX,建模能力最强 | 轻量建模,以可视化探索为核心 | 语义层 + 类 SQL 自助建模 | 基本无强建模,依赖数据源处理 |
| 可视化能力 | 原生视觉丰富,可扩展 | 图形自由度与视觉表现力最强 | 图表模板适合国内报表场景 | 图表基础,模板化输出 |
| 协同与权限 | 工作区 + RLS + 敏感度标签 + 审计 | 站点与项目级权限较细 | 角色/数据权限精细,支持血缘 | 基于谷歌账号分享,权限较简单 |
| 成本与定价 | 免费桌面版,Pro 约 10 美元/人/月,容量另计 | Creator 约 75 美元/人/月,企业版更高 | 按年按模块授权,需商务询价 | 免费,数据源主要限谷歌生态 |
| 生态集成 | Office 365/Azure/Fabric/Teams 深度集成 | 第三方数据源与云厂商适配广 | 国内数据库、ERP、钉钉/企微、信创适配 | Google 生态(BigQuery/GA4) |
| 适合谁 | 微软存量客户、需要强模型与 RLS 管控的企业 | 重视视觉和探索分析的团队 | 国内政企信息化、中国式报表与信创 | 中小团队、谷歌生态用户的轻量报表 |
选型建议:已有 Microsoft 365 或 Azure 投入、需要统一语义模型与行级安全的企业优先选 Power BI;重视可视化表现力与研究型探索分析选择 Tableau;在国内政企信息化、信创环境且需要复杂中国式报表时选 FineBI;临时性轻量分析、以 Google 数据源为主时用 Looker Studio 成本最低。
版本迭代
Power BI 从 2015 年公开预览起步,主线为「桌面工具 → 商用订阅 → 企业容量(Premium)→ 语义模型开放(XMLA)→ 并入 Microsoft Fabric」。桌面端保持月度更新节奏,2023 年 5 月 Microsoft Fabric 发布后,Premium 容量统一收编为 Fabric 容量,功能重心转向 Copilot 驱动的自然语言分析。截至 2025 年 5 月,最新稳定版为桌面版 2025-05 月度更新(2.144.x)(截至训练数据,可能已有更新版本)。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| 公开预览版 | 2015-07 | Power BI 首次公开预览 | 上线 Power BI Desktop 与云服务,支持 Excel 与网页数据源、Q&A 自然语言查询 |
| 1.0 正式版 | 2016-07 | 商用正式发布 | 企业级安全合规、Office 365 深度集成、Power BI Pro 按用户订阅 |
| Premium 容量版 | 2017-06 | Power BI Premium 发布 | 推出独立云容量、分页报表与本地数据网关,支撑企业级大数据集 |
| 2.83(2021-05) | 2021-05 | XMLA 端点开放 | 数据集支持 XMLA 读写,第三方建模工具(Tabular Editor 等)可直连管理 |
| 2.120(2023-05) | 2023-05 | 并入 Microsoft Fabric | Premium 容量演进为 Fabric 容量,OneLake 统一数据存储,Copilot 预告 |
| 2.144(2025-05) | 2025-05 | 月度更新延续 | 截至本稿可确认的最新稳定版,按每月固定节奏发布功能与预览项 |
版本主线反映 Power BI 从个人报表工具走向企业级数据平台的路径——建模能力(DAX、XMLA、语义模型)和云原生集成(Fabric、OneLake)持续加强,月度更新的重点在连接器、可视化与 Copilot 预览功能的增量,性能与容量能力由所在容量层(Pro/PPU/Fabric 容量 SKU)决定。行业评测方面,Power BI 多年入选 Gartner 分析与商业智能平台魔力象限领导者象限。选型建议:预算有限且需要微软生态与自助建模能力时 Pro 足够;大规模数据集、分页报表与嵌入分析应规划 Fabric 容量或 PPU。
AI 应用场景
场景一:企业财务与经营分析报表中心
阶段:数据接入与建模、可视化分析、报表自动化
解决的问题:财务月结报表依赖 Excel 手工汇总,30 余张表口径分散、合并且耗时长。Power BI 用 Power Query 统一清洗多系统数据,用语义模型固化「销售额、毛利、回款」等口径,RLS 按事业部隔离数据,替代每日手工合并与邮件传递。
具体案例:某零售企业把月结分析周期从约 3 天压缩到半天以内,报表全部迁移到工作区统一管理;财务团队在报表视图用 Q&A 直接提问「华东区本月毛利率环比」,无需再请 IT 临时加工。
场景二:Copilot 驱动的对话式分析
阶段:自然语言查询、DAX 生成、报表叙事摘要
解决的问题:业务人员不熟悉 DAX 语法,写一个环比度量值往往要等 IT 支持。在启用 Copilot 的 PPU/Fabric 容量环境中,业务用户用自然语言描述需求,Copilot 生成 DAX、回答数据问题并输出摘要,将「提需求 → 等排期」的流程变为即时对话。
具体案例:销售分析团队在 Power BI 会话中直接提问「本季度按区域销售额环比」,Copilot 自动生成度量值与柱状图;报表摘要功能把每周周报的解读文字从耗时 1 小时缩短到几分钟。
场景三:SaaS 产品内的嵌入式分析
阶段:语义模型共享、嵌入 API、多租户权限隔离
解决的问题:SaaS 服务商自研报表模块成本高且迭代慢。通过 Power BI REST API 获取嵌入令牌,把报表渲染进自家产品页面,按当前登录用户应用 RLS 过滤,实现租户级数据隔离,一套模型服务所有客户。
具体案例:某 ISV 为每个客户租户建立独立数据集并统一嵌入一套报表框架,相比此前按客户定制开发,报表相关研发量减少约 60%,新客户开通报表由按周交付变为当天完成。
常见误区
误区Power BI 不就是把 Excel 里的图表做得更好看一点吗?我日常用 Excel 就够了,没必要单独学一个工具。
正解Power BI 是完整的 BI 平台,包含数据获取(Power Query)、语义建模(DAX + 关系 + RLS)、可视化、云发布共享、定时刷新、分页报表与嵌入式分析全链路。Excel 是个人计算工具,Power BI 是面向组织和团队的分析资产底座,两者定位完全不同。
为何常见:Power BI 桌面版界面和 Excel 相似(功能区、表格、图表),新手接触到的第一个功能也是「获取数据」,容易把它归类为 Excel 的增强插件。
误区DAX 就是 SUM、IF、VLOOKUP 换个写法,我会 Excel 公式就会写 DAX,写完数字对不上再说。
正解DAX 是上下文驱动语言,核心是行上下文(Row Context)和筛选上下文(Filter Context)的区别。SUMX、CALCULATE 等函数会修改或遍历上下文,直接在合计行、交叉表里套用 Excel 思维会算出错误结果;DAX 的学习重点是上下文而不是函数语法。
为何常见:DAX 函数名(SUM、IF、COUNT)与 Excel 高度相似,但计算引擎完全不同,这种「长得像」的错觉让新手跳过上下文概念直接上手。
误区我把 PBIX 发到 Power BI Service 上了,数据应该每天自动更新吧,不用再管了。
正解发布只上传了当前数据快照,后续更新必须显式配置:在数据集「设置 → 计划刷新」中设置频率;若数据源在本地(如内网 SQL Server),还需要部署本地数据网关;免费版和 Pro 对每日刷新次数有限制。
为何常见:云服务给人的直觉是「联网即最新」,实际上刷新是独立于发布的调度任务,本地数据源还存在安全访问通道问题。
误区公司已经买了 Power BI Pro,我在界面里为什么找不到 Copilot?是不是我的版本不对?
正解Copilot in Power BI 要求 PPU 或 Premium/Fabric 容量承载的工作区,且需租户管理员在管理门户中开启 Copilot 与 AI 功能开关,同时确认数据所在区域已上线该服务。Pro 许可证只是访问共享工作区的基础条件,不等于自动获得 Copilot。
为何常见:Copilot 入口出现在部分容量环境的报表中,而许可说明分散在文档各处,业务用户容易把「功能存在」误解为「所有授权都包含」。
误区把数据库里所有字段、所有历史明细全部导进 Power BI 模型,这样想分析什么都有,性能慢就升级机器。
正解Power BI 使用内存列式引擎,模型体积、列基数和字段数直接决定刷新与查询性能。正确做法是只保留报表需要的列与聚合粒度、建立合理的星型模型、避免高基数列作为维度,大数据量采用 DirectQuery(查询直达数据源的模式)或增量刷新。
为何常见:「数据越多越全」符合日常文件管理直觉,用户难以感知内存分析引擎对列数和基数的敏感度,问题往往在上线后才暴露。
面试题
Q1. Power BI Desktop 的正确安装入口是?
- A.Microsoft Store 或官网安装包← 正确答案
- B.命令行执行 pip install 安装
- C.任意第三方网盘下载安装
- D.手机应用商店自动安装程序
答案:A。Power BI Desktop 的官方安装渠道是 Microsoft Store 和官网下载页(也支持 winget 命令安装);不存在 pip 安装包,第三方网盘来源存在安全风险,桌面版不支持手机应用商店安装。
Q2. Power Query 中将两张结构相同的表按行拼接使用?
- A.合并查询(Merge)关联多列
- B.追加查询(Append)纵向拼接← 正确答案
- C.分组依据(Group By)聚合计算
- D.转置(Transpose)行列互换
答案:B。追加查询(Append)将两张结构相同的表按行堆叠,等效于 SQL 的 UNION;合并查询(Merge)是按列关联的 JOIN 操作;分组依据用于聚合,转置用于行列互换,三者都不是纵向拼接。
Q3. 在 Power BI Desktop 中连接外部数据的入口是?
- A.“主页—获取数据”选择数据源← 正确答案
- B.“视图—报表主题”调整样式
- C.“帮助—关于”查看版本信息
- D.“建模—新建度量值”定义指标
答案:A。获取数据位于主页功能区,覆盖 Excel、SQL Server、CSV、网页与 API 等数百种连接器;报表主题、版本信息和新建度量值分别属于展示、诊断和建模功能,不承担数据接入职责。
Q4. DAX 函数 CALCULATE 的核心作用是?
- A.将文本值转换为日期或时间格式
- B.修改筛选上下文并对表达式求值← 正确答案
- C.对列去重后排序并返回新表
- D.在 Power Query 中完成数据清洗
答案:B。CALCULATE 是 DAX 中最核心的函数,用于在一个修改后的筛选上下文中计算表达式,例如计算「剔除某分类后的总销售额」。类型转换、去重排序是其他函数的工作,CALCULATE 也不存在于 Power Query。
Q5. Power BI 的行级安全(RLS)配置位置在?
- A.报表页面的书签与导航设置中
- B.语义模型上的 DAX 角色筛选器← 正确答案
- C.可视化图表格式窗格的安全项中
- D.数据网关连接字符串中的账号配置
答案:B。RLS 是在语义模型中通过「管理角色」定义 DAX 筛选规则实现的,例如 [区域] = USERPRINCIPALNAME(),对所有基于该数据集创建的报表统一生效,而不是在报表页或图表层面配置。
Q6. 本地 SQL Server 定时刷新到云端必须部署?
- A.本地数据网关以桥接云与内网← 正确答案
- B.独立 VPN 专线连接微软数据中心
- C.一套 SharePoint 服务器用于中转
- D.无需任何组件,开通即可自动刷新
答案:A。本地数据网关是 Power BI Service 与内网数据源之间的安全桥接组件,云端计划刷新通过网关向本地数据库发起查询;VPN、SharePoint 不是官方方案,且内网数据源没有网关时刷新必然失败。
Q7. 关于度量值与计算列的区别,正确的是?
- A.度量值在刷新时一次性固化为表列
- B.度量值按报表筛选上下文动态求值← 正确答案
- C.计算列可实时响应切片器的筛选
- D.计算列只能在度量值内部被引用
答案:B。度量值在查询时根据当前筛选上下文动态计算,不占模型存储;计算列在数据刷新时逐行计算并固化为模型列,无法感知切片器等报表交互。固化列是计算列的特点而非度量值,因此 A、C 错误。
Q8. 以下哪些是企业级共享 Power BI 报表的官方方式?
- A.发布到工作区并配置行级安全控制← 正确答案
- B.部署到本地 Power BI Report Server← 正确答案
- C.以 CSV 附件定时发送给邮件列表
- D.通过嵌入 API 集成到自研业务系统← 正确答案
答案:ABD。发布工作区加 RLS、部署到 Report Server、通过嵌入 API 集成都是官方企业级分发方式。C 错误:Power BI 邮件订阅发送的是报表页或分页报表的静态快照,不是 CSV 附件。
Q9. 以下哪些做法可以改善大型语义模型的性能?
- A.裁剪模型中冗余列并降低数据粒度← 正确答案
- B.一次性全量导入所有业务明细数据
- C.大数据量采用增量刷新策略分批加载← 正确答案
- D.为每个图表单独创建一个独立数据集
答案:AC。Power BI 的内存列式引擎对列数和基数敏感,裁剪列、降低粒度能显著减少模型体积;增量刷新按分区分批加载,降低单次刷新压力。B 会膨胀模型,D 会造成数据集碎片化,两者都会恶化性能。
Q10. 关于 Import 与 DirectQuery 两种连接模式,说法正确的是?
- A.Import 模式将数据缓存到内存列式引擎← 正确答案
- B.DirectQuery 查询直达源且不占模型内存← 正确答案
- C.Import 模式完全无法使用行级安全功能
- D.DirectQuery 下部分 DAX 函数受源库限制← 正确答案
答案:ABD。Import 模式把数据加载进内存列式引擎,查询快但占用模型内存;DirectQuery 每次查询实时直达数据源、不占模型内存,但 DAX 函数能力受底层数据库(如 SQL Server 的查询能力)限制。RLS 在 Import 模式下完全支持,因此 C 错误。