手册

在 Medallion 架构中设计初始数据摄取层，以捕获原始源数据。

→以最少的转换和宽松的架构将数据摄取到 Bronze 层。

原因: 保留原始数据保真度，包括格式错误记录，以供重新处理、审计和数据血缘分析。

为 Fabric 工件实施隔离环境和升级流程。

→使用具有独立开发、测试和生产工作区阶段的 Fabric 部署管道。

原因: 提供结构化、安全的机制来测试更改和升级工件，同时不影响生产工作负载。

对生产 Fabric 项目的更改强制执行源代码控制和审批工作流。

→将 Fabric 工作区与 Azure DevOps Git 集成。使用分支策略强制执行拉取请求审查。

原因: 启用版本控制、更改跟踪和强制性同行评审，使数据工程与 DevOps 最佳实践保持一致。

在管道部署期间自动更改特定于环境的连接字符串。

→在部署管道中配置部署规则，为每个阶段参数化数据源连接。

原因: 消除手动部署后配置，减少错误并确保每个环境连接到正确的数据源。

为需要隔离和共享治理的多个业务部门组织工作区。

→为每个业务部门创建单独的工作区，并将它们分组到 Fabric Domains 下。

原因: 工作区提供内容和安全隔离，而 Domains 则支持跨相关工作区的集中治理和发现。

改善数据发现并向业务用户传达数据集的质量。

→将描述和标签应用于 Lakehouse 表，并使用“推荐”（Promoted、Certified）认可标签。

原因: 认可级别建立用户信任，并引导他们找到高质量、精选的数据集用于报告和分析。

确保所有 Fabric 项目的数据分类和保护一致。

→与 Microsoft Purview Information Protection 集成，并为敏感度标签启用下游继承。

原因: 自动将敏感度标签从数据源应用到语义模型和报告等下游工件，从而强制执行安全策略。

确定 Fabric 容量大小调整的主要因素。

→分析工作负载的并发查询执行和计算要求。

原因: Fabric 容量由计算操作（Capacity Units）消耗，而不是数据存储量。并发性和作业复杂性是关键驱动因素。

从 Fabric 快捷方式到外部 ADLS Gen2 帐户提供安全的生产级访问。

→使用具有 Azure AD 身份验证的 Service Principal，并授予其对存储帐户的最小特权 RBAC 角色。

原因: Service Principal 是最安全且可审计的方法，避免了共享帐户密钥或 SAS tokens 的风险。

在 Fabric 中创建 Azure SQL Database 的近实时、只读副本，而不会影响源。

→使用 Fabric Mirroring for Azure SQL Database。

原因: Mirroring 提供低延迟、连续的数据复制到 OneLake 作为 Delta tables，非常适合无需 ETL 开发的实时分析。

与另一个工作区共享数据集或访问外部数据而无需创建副本。

→创建指向源 Lakehouse 表或外部数据位置的 Shortcut。

原因: Shortcuts 充当符号链接，在 OneLake 中提供统一的数据视图，同时避免数据重复、存储成本和同步问题。

将高速流数据与历史批处理数据结合起来进行统一分析。

→使用 Eventstream 进行实时摄取，并使用带有 Delta Lake 表的 Lakehouse 进行统一存储。

原因: Eventstream 处理流式路径，而 Delta Lake 的 ACID 属性使其能够作为流式追加和批处理更新的目标。

在相同的 Lakehouse 数据上启用基于 T-SQL 的分析和基于 Python 的数据科学。

→利用 Lakehouse 自动生成的 SQL analytics endpoint。

原因: Fabric 提供对相同 Delta tables 的双引擎访问：用于 T-SQL 查询的 SQL endpoint 和用于 Notebook 的 Spark engine，无需数据重复。

将来自本地数据源（例如 Oracle、SQL Server）的数据摄取到 Fabric 中。

→安装并配置本地数据网关。

原因: 网关充当安全桥梁，在本地网络和 Fabric 云服务之间中继数据，而不会将源暴露给互联网。

一旦新文件到达 Azure Blob Storage，立即自动处理。

→为数据管道使用存储事件触发器，配置为在 blob 创建事件时触发。

原因: 事件驱动触发器提供更低的延迟，并且比计划轮询更高效，计划轮询可能会丢失数据或不必要地运行。

从以分页形式返回数据的 REST API 中提取所有记录。

→在 Copy 活动中，配置 REST 连接器的内置 pagination 规则。或者，使用 Until 或 ForEach 循环和变量来管理页面令牌。

原因: 自动遍历所有 API 页面，直到检索到所有数据，处理动态下一页链接或偏移量。

实现缓慢变化维度 Type 2 逻辑或处理变更数据捕获 (CDC) 流。

→使用带有 `WHEN MATCHED` 和 `WHEN NOT MATCHED` 子句的 Delta Lake MERGE 操作。

原因: MERGE 提供原子 upsert（更新/插入/删除）功能，这是在 SCD2 模式中维护历史记录的基础操作。

将包含嵌套对象数组的 DataFrame 列转换为单独的行。

→在 PySpark Notebook 中对数组列应用 `explode()` 函数。

原因: `explode()` 是用于取消嵌套数组的标准 Spark 函数，为数组中的每个元素创建一个新行。

在有状态流式聚合（例如，窗口计数）中处理延迟到达的数据。

→在 Spark Structured Streaming 查询的事件时间列上配置 watermark。

原因: Watermarking 定义了引擎等待延迟数据的时间阈值，防止状态无限增长，同时确保正确性。

从具有时间戳列但没有 CDC 的源系统执行增量数据加载。

→实现 high-watermark 模式。存储上次运行的最大时间戳，并在下次运行中使用它来过滤源。

原因: 这是一种高效且常见的模式，用于仅提取新的或更新的记录，而无需全表扫描的开销或正式 CDC 的要求。

管道活动由于瞬态网络问题或源系统负载而间歇性失败。

→配置活动的重试策略，包括指定的重试次数和指数退避间隔。

原因: 通过自动重试失败的操作，为管道构建弹性，通常无需手动干预即可解决瞬态问题。

摄取和查询高容量、低延迟的遥测或日志数据，用于实时探索性分析。

→将数据摄取到 Eventhouse 中，并使用 Kusto Query Language (KQL) 进行查询。

原因: Eventhouse（基于 Azure Data Explorer 构建）和 KQL 专为高性能时间序列和日志分析而设计。

创建单个可重用管道，以加载数十个共享相同转换逻辑的表。

→使用元数据驱动的方法。将源/目标信息存储在控制表中，并使用 ForEach 活动进行迭代并将参数传递给通用子管道。

原因: 此模式具有高度可扩展性和可维护性，避免了为每个表创建单独管道的重复和管理开销。

优化从 SQL Server 等关系数据库获取数据的 Dataflow Gen2 的性能。

→设计可折叠的转换。在 Power Query 编辑器中验证 query folding 状态。

原因: Query folding 将转换逻辑下推到源数据库引擎，这比将所有数据拉入 Spark engine 进行转换的性能要显著更高。

查询表在过去特定时间点的状态，用于审计或从意外更新中恢复。

→在查询中使用带有 `VERSION AS OF` 或 `TIMESTAMP AS OF` 的 Delta Lake time travel 功能。

原因: Delta Lake 本身会对每个事务进行版本控制，允许进行时间点查询，而无需手动快照或备份。

强制实施行级安全性 (RLS)，使用户只能看到与其区域或部门对应的数据。

→在 semantic model 中使用 DAX 表达式实施 RLS 规则。

原因: semantic model 是强制执行 RLS 等业务规则的集中式推荐层。逻辑根据用户身份动态应用。

防止一组用户查看表中的敏感列（例如，薪水、PII）。

→在 semantic model 或 warehouse 中实施 Column-Level Security (CLS)。

原因: CLS 提供精细控制，限制指定用户角色对特定列的访问，从而保护共享表中的敏感数据。

在具有高性能要求的大型 Lakehouse 数据集上构建 Power BI 报告。

→使用 DirectLake 模式创建 semantic model。

原因: DirectLake 通过将数据加载到内存中来提供 Import 模式的性能，但通过直接从 OneLake 中的 Delta 文件读取，避免了数据重复。

提高具有高级摘要的报告的查询性能并减少容量消耗。

→在 semantic model 中创建和配置 aggregation 表。

原因: 查询预聚合数据比扫描完整详细表的速度显著更快，消耗的资源更少，从而优化用户体验和成本。

减少仅最新数据发生变化的大型 semantic model 的刷新时间并降低资源使用率。

→在 semantic model 的大型事实表上配置 incremental refresh policy。

原因: 这将数据分区并仅刷新最新的分区，避免了不变的历史数据的昂贵完全重新加载。

由于流式摄取产生大量小文件，Delta 表的查询性能下降。

→对 Delta 表运行 `OPTIMIZE` 命令。

原因: `OPTIMIZE` 将小文件压缩成更少、更大的文件。这显著提高了读取性能，因为查询引擎需要打开的文件更少。

提高对一个大型 Delta 表的查询性能，该表经常通过非分区、高基数列进行筛选。

→对频繁筛选的列运行带有 `ZORDER BY` 子句的 `OPTIMIZE`。

原因: Z-Ordering 将相关数据并置在文件中，允许查询引擎使用数据跳过读取更少的数据，从而显著加快筛选查询。

优化 Power BI 报告查询 Fabric Lakehouse 中 Delta tables 的读取性能。

→确保 Delta tables 上启用了 V-Order 优化。

原因: V-Order 是 Fabric 特有的写入时优化，通过改进压缩和数据排序来增强 Power BI 引擎的读取性能。

从由于更新和删除而积累了大量历史记录的 Delta 表中回收存储空间。

→对表运行 `VACUUM` 命令。

原因: `VACUUM` 物理删除表中不再引用且早于保留期的数据文件，从而降低存储成本。

优化超大事实表和小型维度表之间的 Spark join。

→通过提供提示 (`broadcast()`) 将小表发送到所有 executor 来使用 broadcast join。

原因: Broadcasting 避免了大型表的昂贵且网络密集型 shuffle 操作，这是大规模 join 中的主要性能瓶颈。

Spark join 操作缓慢或失败，因为某个键值的数据量过大（data skew）。

→实施“salting”技术：为倾斜值添加随机键，将其分布到更多分区中，然后进行 join 和聚合。

原因: Salting 手动分解倾斜分区，使工作负载能够在所有 executor 上平衡，并防止 OOM 错误或长时间运行的任务。

Spark Notebook 作业运行速度慢于预期，原因不明。

→使用可从监控中心访问的 Spark UI 分析有向无环图 (DAG)、阶段持续时间以及任务详细信息。

原因: Spark UI 提供查询执行的详细物理视图，使您能够查明数据倾斜、磁盘溢出或低效 shuffle 等瓶颈。

Spark 作业在 driver node 上因 OutOfMemoryError 失败，即使 executor 内存很大。

→检查代码中是否存在 `.collect()` 或 `.toPandas()` 等操作，这些操作会将大量分布式数据拉取到 driver node 的内存中。

原因: driver 有自己的内存限制。将大型 DataFrame 收集到 driver 是导致 OOM 错误的常见反模式；请改用分布式操作。

识别哪些工作区、报告或管道在 Fabric 容量中消耗最多的计算资源。

→安装并分析 Fabric Capacity Metrics 应用。

原因: 此应用按工作区、项目类型和特定操作提供 Capacity Unit (CU) 随时间消耗的详细分类，从而实现有针对性的优化和成本分析。

对 Fabric 工作区内的所有活动实施集中式、长期审计和监控。

→在 Fabric 管理设置中，配置工作区的诊断设置，将日志流式传输到 Azure Log Analytics 工作区。

原因: 为所有审计和操作日志提供强大、可查询和长期的存储，从而实现高级监控、警报和合规性报告。

降低具有可预测非活动周期（例如，夜间、周末）的 Fabric 容量的运营成本。

→实施自动化（例如，通过 API 和 Azure Automation）以在非工作时间暂停容量，并在工作时间前恢复。

原因: 容量计算是主要的成本驱动因素。暂停容量会停止 CU 计费，从而在空闲期间提供显著的成本节省。

必须监控关键数据管道，并且在失败时需要立即通知运营团队。

→在 Fabric Monitoring Hub 中配置警报，或使用 Data Activator 监控管道状态并触发通知。

原因: 主动警报确保快速检测和解决故障，最大限度地减少数据停机时间并降低对业务用户的影响。