手册

在 Fabric lakehouse 中查询包含海量（5亿行以上）数据的 Delta 表，同时实现最佳性能和近实时数据访问。

→使用 Direct Lake 模式的语义模型。

原因: Direct Lake 直接从 OneLake 读取 Parquet 文件，无需数据导入或查询转换。它提供类似于导入模式的性能，同时避免数据重复和刷新延迟。DirectQuery 较慢；导入模式会引入延迟。

将常见的时间智能计算（YTD、QTD、MTD）应用于数十个基本度量值（销售额、利润、数量），而无需创建数百个 DAX 度量值。

→实施一个包含 YTD、QTD 和 MTD 计算项的计算组。

原因: 计算组消除了度量值的激增。它们定义了一组可动态应用于任何选定度量值的通用计算，极大地简化了模型维护。

工作区中的多个语义模型需要共享公共维度表（例如，日期、客户）以确保一致性并减少数据重复。

→创建一个包含共享维度的“核心”语义模型。构建其他“复合”模型，这些模型通过 DirectQuery 连接到核心模型，并通过 Direct Lake/导入模式连接到事实表。

原因: 这种“中心辐射型”架构为维度数据提供单一事实来源。复合模型允许将来自不同源和存储模式的数据组合到一个统一模型中。

事实表具有多个日期列（例如 OrderDate、ShipDate），这些列都必须与单个日期维度表相关联。

→在事实表和日期表之间创建一条活动关系和多条非活动关系。在度量值中使用 `USERELATIONSHIP()` DAX 函数来激活相应的非活动关系。

原因: Power BI 只允许两个表之间存在一条活动关系。此模式允许根据不同的日期角色进行分析，而无需复制维度表。

包含大型事实表（数十亿行）的语义模型刷新时间过长。只有最近 30 天的数据频繁更改。

→在事实表上配置增量刷新。设置参数 `RangeStart` 和 `RangeEnd`。定义一个策略来归档旧数据（例如，存储过去 5 年的数据）并刷新最近的数据（例如，刷新最近 30 天的数据）。

原因: 这通过仅处理包含新数据或更改数据的分区，而不是重新加载整个表，从而显著减少了刷新时间和资源消耗。

一个复杂的 DAX 度量值运行缓慢，因为它在公式中重复计算相同的中间值。

→使用变量 (`VAR`) 一次存储中间计算的结果，然后在 `RETURN` 语句中多次引用该变量。

原因: 变量可以防止引擎在单个度量值执行中多次重新评估相同的逻辑，从而显著提高性能，尤其是在迭代上下文中。

创建一个度量值，用于计算某个值（例如，产品销售额）对更大总计（例如，所有产品销售额）的贡献百分比，同时尊重其他筛选器（如日期）。

→对于类别百分比，使用 `DIVIDE([Sales], CALCULATE([Sales], ALLEXCEPT(Product, Product[Category])))`；对于总计百分比，使用 `CALCULATE([Sales], ALL(Product))`。

原因: `CALCULATE` 结合 `ALL`、`ALLEXCEPT` 或 `REMOVEFILTERS` 允许您修改筛选器上下文，以获取百分比计算的正确分母。

报表需要一个切片器，允许用户选择可视化效果应显示哪个指标（例如“Revenue”、“Cost”、“Profit”）。

→创建一个包含指标名称的非连接表。使用 `SWITCH(SELECTEDVALUE(MetricTable[Metric]), "Revenue", [Total Revenue], "Cost", [Total Cost], ...)` 创建一个 DAX 度量值。

原因: 这种模式（通常使用 Field Parameter）提供了一种动态且用户友好的方式来切换计算，而无需书签或多个视觉对象，使报表更具交互性和简洁性。

企业 BI 团队需要使用专业工具（如 Visual Studio、Tabular Editor、SQL Profiler）来管理、部署和故障排除 Fabric 语义模型。

→为工作区启用 XMLA 读/写终结点。

原因: XMLA 终结点将语义模型公开为标准的 Analysis Services 实例，从而使广泛的高级 BI 和 ALM 工具生态系统能够进行连接，以实现编程访问和复杂的建模任务。

Direct Lake 模型性能缓慢。调查显示它正在回退到 DirectQuery 模式。

→使用 DAX Studio 或 Performance Analyzer 识别导致回退的查询。常见原因包括不支持的 DAX 函数、复杂的 RLS 或未优化/过时的 lakehouse。

原因: Direct Lake 有局限性。当查询使用不支持的功能时，它会默默地回退到较慢的 DirectQuery 引擎。识别并修复根本原因（例如，优化 DAX，对 Delta 表运行 OPTIMIZE）是恢复性能的关键。

模型具有多对多关系（例如，通过桥接表连接的销售额和促销）。当按“多”侧筛选时，度量值返回不正确的总计。

→确保关系上的交叉筛选方向（维度 -> 桥接 -> 事实）设置正确（通常为单向）。如果需要，对更复杂的 M2M 计算使用 `TREATAS` 或 `INTERSECT` 等 DAX 函数。

原因: 错误的交叉筛选方向是 M2M 模型中结果不正确的常见原因。虽然双向筛选看似有效，但它通常会导致歧义和重复计数。具有显式 DAX 模式的明确模型更健壮。

针对海量事实表使用 DirectQuery 的复合模型速度缓慢。大多数用户查询都处于聚合级别（例如，按类别划分的月销售额）。

→在导入模式下创建用户定义的聚合表。聚合表应包含按常见查询粒度（月、类别）预汇总的数据。

原因: 查询引擎将尽可能自动将查询重定向到较小的内存中聚合表，从而提供巨大的性能提升。它只会针对需要较低详细级别的查询访问 DirectQuery 源。

在 DAX 中计算复杂的运行总计或移动平均值，而传统基于筛选器的方法性能不佳。

→使用 `WINDOW` 或 `OFFSET` 等 DAX 窗口函数。

原因: 这些函数专门针对排序行集上的位置计算进行了优化。它们通常比依赖大量筛选和上下文转换的旧模式性能更好，语法更简单。

为一家财政年度从 7 月 1 日开始的公司计算年初至今 (YTD) 总计。

→使用 `TOTALYTD` 或 `DATESYTD` 函数以及可选的 `YearEndDate` 参数。示例：`TOTALYTD([Sales], 'Date'[Date], "6/30")`。

原因: 指定年末日期参数是使 DAX 时间智能函数识别自定义财政日历的正确且最简单的方法。

在开发、测试和生产阶段之间提升语义模型，每个阶段都有不同的数据库连接字符串。

→使用带有部署规则的 Fabric 部署管道。

原因: 部署规则自动化了每个环境的数据源连接、参数和其他设置的修改。这避免了部署后手动、易出错的更改。

参考↗

实施去中心化的数据网格架构，其中业务域拥有并管理自己的数据产品。

→创建特定于域的工作区。使用 OneLake shortcuts 实现跨域数据共享和使用，而无需集中数据所有权。

原因: 此模式符合数据网格的域所有权和数据即产品原则。工作区提供了所有权的边界，而 shortcuts 提供了互操作层。

开发团队需要在 Fabric 项（语义模型、报表、notebooks）上进行协作，并使用源代码控制和版本历史记录。

→为 Fabric 工作区配置 Git 集成，将其连接到 Azure DevOps 或 GitHub 存储库。

原因: Git 集成将 Fabric 项定义存储为文本文件（JSON、TMDL），从而实现分支、拉取请求和版本跟踪等标准 DevOps 实践。这对于企业级应用程序生命周期管理 (ALM) 至关重要。

在更改 lakehouse 表之前，工程师必须识别所有受影响的下游报表和语义模型。

→使用 Lineage View 并在 lakehouse 项上选择“Impact analysis”。

原因: 此功能提供所有依赖项的完整自动化视图。它是管理复杂分析环境中变更、防止意外损坏的关键治理工具。

团队需要以基于文本、人类可读的格式对语义模型进行版本控制，这种格式易于比较和合并。

→将 Power BI 文件保存为 Power BI 项目 (.pbip)。这会将模型定义存储为表格模型定义语言 (TMDL) 格式。

原因: TMDL 是一种开发人员友好的格式，它将模型表示为具有独立文本文件（用于表、度量值等）的文件夹结构。这比二进制 .bim 文件更适合基于 Git 的协作和 CI/CD。

实施 Medallion 架构（Bronze、Silver、Gold），并需要在不同层之间访问数据而无需物理数据重复。

→使用 OneLake shortcuts 引用其他 lakehouse 或层中的数据。

原因: Shortcuts 是 OneLake 中的符号链接。它们提供统一的命名空间，并允许在不复制数据的情况下访问数据，这非常适合逻辑数据网格或 Medallion 架构。

参考↗

将现有的、大量使用 T-SQL 的分析工作负载从 Azure Synapse 迁移到 Fabric。

→使用 Fabric Data Warehouse。

原因: Fabric Warehouse 提供完整的 T-SQL 兼容性，是迁移现有 SQL 脚本、存储过程和分析师查询的理想目标，且只需进行最少的更改。Lakehouse SQL 端点具有只读 T-SQL 访问权限，并使用 Spark SQL 进行写入。

摄取和查询高容量、高速率的流式数据（例如 IoT 遥测数据），并实现亚秒级延迟。

→使用 Fabric Eventstream 进行摄取，并使用 KQL Database 进行存储和分析。

原因: 这是 Fabric 中专为流式分析构建的堆栈。KQL (Kusto Query Language) 针对流式数据上的时序分析进行了优化，比面向批处理的 lakehouse 或 warehouse 提供更低的延迟。

实施慢变维度 (SCD) Type 2，以在 lakehouse 中维护维度更改的完整历史记录。

→在 Spark notebook 或管道中使用 `MERGE INTO` 语句。按业务键匹配；`WHEN MATCHED` 更新旧记录（将 `IsCurrent` 设置为 false，`EndDate` 设置为当前时间）；`WHEN NOT MATCHED` 插入新记录。

原因: Delta Lake 的 `MERGE` 操作提供了原子性的 upsert 功能，使其成为在 Fabric lakehouse 中实现 SCD 逻辑的标准且最有效的方式。

以近实时方式将数据从操作数据库（例如 Azure SQL DB）复制到 Fabric lakehouse 进行分析。

→使用 Fabric Mirroring。

原因: Mirroring 是 Fabric 中内置的低延迟、低影响的变更数据捕获 (CDC) 解决方案。它自动将数据和架构更改复制到 OneLake 作为 Delta 表，消除了对复杂 ETL 管道的需求。

将来自 API 的复杂、嵌套 JSON 数据摄取并转换为扁平化的结构化 Delta 表。

→使用 PySpark notebook。使用 `from_json` 等函数解析架构，并使用 `explode` 将数组展平为行。

原因: PySpark 提供了最强大、最灵活的工具，用于以编程方式处理复杂且不断演进的 JSON 结构，远远超出了标准复制活动的 capabilities。

从企业防火墙后面的本地 SQL Server 数据库将数据摄取到 Fabric 中。

→在本地网络中的服务器上安装并配置本地数据网关。将该网关作为数据源添加到 Fabric 中。

原因: 网关充当安全桥梁，在 Fabric 云服务和本地数据源之间中继查询和数据，而无需打开入站防火墙端口。

由于积累了许多小型数据文件，对大型、频繁更新的 Delta 表的查询性能已下降。

→运行 `OPTIMIZE` 命令以将小文件压缩成大文件。可以选择在频繁筛选的列上使用 `ZORDER BY` 以协同定位相关数据。

原因: 数量更少、体积更大的文件对于 Spark 读取效率更高。Z-ordering 改进了数据跳过功能，允许查询读取更少的数据。这是 Delta 表的关键维护任务。

将流式时序数据聚合到固定的、不重叠的时间间隔中（例如，每 5 分钟每个传感器的平均温度）。

→使用带有 `summarize` 运算符和 `bin()` 函数的 KQL 查询。示例：`SensorData | summarize avg(temperature) by sensor_id, bin(timestamp, 5m)`。

原因: `bin()` 函数是 KQL 中用于将事件分组到固定时间桶（翻转窗口）进行聚合的标准、高度优化的方法。

Dataflow Gen2 刷新速度很慢。数据源是关系数据库，例如 Azure SQL。

→查看 Power Query 编辑器中的转换步骤，以确保查询折叠处于活动状态。重新排序或修改步骤以最大化折叠。

原因: 查询折叠将转换逻辑推回到源数据库中，作为单个本机查询执行。这比将所有原始数据拉入数据流引擎并在内存中进行转换效率高得多。

Spark notebook 正在对一个非常大的事实表（数十亿行）和一个小型维度表（数千行）执行缓慢的联接。

→通过提供提示（`spark.sql.functions.broadcast`）或让优化器根据统计信息进行选择来使用广播联接。

原因: 广播将整个小表发送到每个执行器节点。这避免了昂贵的“shuffle”操作，其中大表的数据必须重新分区并通过网络发送，从而显著提高了性能。

数据管道编排多个活动。一个活动可能会失败，但后续的独立活动仍应运行，并且整体失败应被记录。

→配置活动依赖项。无论结果如何都应运行的活动应在“Completion”条件下依赖于上一个活动。

原因: 这允许构建健壮的并行执行路径。您可以为“Succeeded”和“Failed”条件创建单独的分支，以实现自定义日志记录或通知逻辑。

一个管道，用于从具有 `last_modified` 时间戳的源递增加载数据。

→实施水印模式。存储上次成功运行的 `max(last_modified)`。在下次运行时，查询源以获取 `last_modified` 大于存储水印的记录。

原因: 这是从提供修改时间戳的源进行增量加载的最有效模式，确保只处理新的或更新的数据，从而最大限度地减少数据传输和计算。

分析 IoT 数据的实时流，以检测传感器读数中异常的峰值或谷值。

→在 Eventhouse/KQL Database 中的 KQL 查询中使用 `series_decompose_anomalies()` 函数。

原因: 这个内置的 KQL 函数专门用于时序异常检测。它自动将序列分解为季节性、趋势和残差分量，以识别具有统计意义的异常值，所需手动配置最少。

需要在不移动数据的情况下，在一个 T-SQL 查询中联接来自 Warehouse、Lakehouse 和镜像 Azure SQL Database 的数据。

→在从 Warehouse 或 Lakehouse SQL 终结点运行的查询中使用三部分命名约定 (`database.schema.table`)。使用快捷方式引用镜像数据库。

原因: Fabric 提供了一个统一的查询引擎，可以使用单个 SQL 语句访问同一工作区中不同 Fabric 项的数据，从而实现数据虚拟化。

数据流需要处理一个文件，其中某些行可能无效。整个流不应失败；有效行应被加载，无效行应被记录。

→在 Power Query 中，添加一个步骤来验证行并创建“IsValid”列。然后，从该点创建两个引用查询：一个筛选 `IsValid = true` 以加载到目标，另一个筛选 `IsValid = false` 以加载到错误日志。

原因: 此模式通过拆分数据流提供健壮的错误处理。它防止少数不良行停止整个过程，并提供清晰的机制来审计数据质量问题。

实施行级安全性 (RLS)，其中用户只能看到与其身份对应的数据（例如，销售经理只能看到他们负责的门店）。

→创建一个将用户映射到数据实体的安全表。在 RLS 角色中，使用 DAX 筛选表达式，例如 `[ManagerEmail] = USERPRINCIPALNAME()`。

原因: 动态 RLS 具有可伸缩性。它采用数据驱动的方法，而不是为每个人或实体创建静态角色。`USERPRINCIPALNAME()` 正确解析 Azure AD 身份。

对特定用户组隐藏敏感列或整个表（例如“Salary”），同时允许他们访问语义模型的其余部分。

→定义安全角色，并使用 Tabular Editor 等外部工具配置对象级安全性 (OLS)，将表/列权限设置为“无”。

原因: OLS 提供对模型元数据可见性的精细控制。与筛选行的 RLS 不同，OLS 隐藏整个对象。它必须通过 XMLA 端点进行配置。

用户报告 Fabric 中性能缓慢和节流。管理员需要识别根本原因。

→使用 Fabric Capacity Metrics 应用程序。

原因: 此应用程序提供对容量单位 (CU) 消耗、节流事件以及按工作负载类型（例如语义模型查询、数据流刷新）划分的资源使用情况的详细见解。它是性能监控和容量规划的主要工具。

强制执行数据分类策略，其中报表和仪表板自动继承其所连接的语义模型的敏感度标签。

→启用租户设置以实现敏感度标签的下游继承。

原因: 这自动化了数据治理，确保应用于数据源的保护（例如“高度机密”）在所有下游内容上得到一致执行，从而降低数据泄露的风险。

在 Fabric Warehouse 中，普通用户应看到被掩盖的 PII 数据（例如 `XXX-XX-1234`），而特权用户应看到完整的、未被掩盖的数据。

→在 Warehouse 中的敏感列上应用动态数据掩码 (DDM)。向特权用户角色授予 `UNMASK` 权限。

原因: DDM 是一种数据库级别的安全功能，它根据用户权限实时编辑数据。它在不要求单独视图或数据副本的情况下保护敏感数据。