适用于：✅Microsoft Fabric 中的 SQL 数据库
本文介绍如何在 Fabric 中使用 SQL 数据库作为基于 Fabric 的数据资产中的 反向 ETL 目标。 它提供体系结构指南、作模式和实现注意事项，用于将特选数据从分析源（如 Microsoft Fabric 数据仓库或 Fabric Lakehouse）移动到 Fabric 中的 SQL 数据库，供应用程序、API 和实时体验使用。
什么是 Fabric 中的反向 ETL？
许多客户在创建 提取、转换、加载（ETL） 流程以将原始作数据转换为可用于业务报告的更精细的分析数据方面投入了大量时间和精力。 ETL 过程的最终结果通常是一个供报表层（如 Power BI）访问的分析存储，例如数据仓库或 Lakehouse。 此体系结构很好地为业务用户提供服务，但报告相对静态，见解只能通过人工干预来派生。 通过使用 反向 ETL，可以将转换后的数据馈送回作系统，以便应用程序和代理能够实时从此分析的数据中获取见解。 反向 ETL 将数据从分析存储中的事实和维度推送到服务层中，可以在其中通过 GraphQL 等终结点或通过 TDS（表格数据流） 查询直接访问数据。
虽然可以将运营应用程序直接连接到仓库或 Lakehouse，但这些数据存储是专为分析工作负载而设计的。 作数据存储（如 Fabric 中的 SQL 数据库）旨在支持事务查询，并为作工作负荷提供更好的性能和可伸缩性。 操作数据库还可以选择使用矢量嵌入和附加元数据进一步丰富数据，以方便矢量和混合搜索以及检索扩充生成（RAG）。
- 在此模式中， 仓库 或 湖屋 仍然是记录分析系统。
- Fabric 中的 SQL 数据库 充当一种作存储，可提供低延迟、优化索引、严格的数据和关系约束，以及应用程序团队预期的 SLA。
常见的反向 ETL 目标
常见的反向 ETL 目标通常表示特选的高价值数据切片，运营系统可以在进行最少转换的情况下消费。 这些目标旨在提供对受信任数据的低延迟访问，同时保留分析层中应用的业务逻辑。 示例包括：
- 客户和用户数据 （例如，会话活动、功能使用情况和交互等参与指标）
- 销售和营销数据 （例如，评分指标，如购买倾向、参与评分、转换可能性）
- 作和事务数据 （例如，库存级别、订单状态和交货时间等订单和库存数据）
- AI/ML 派生数据 （例如个性化产品建议、预测分数（如流失风险或追加销售倾向或情绪分析）
数据移动机制
该过程首先定义源数据、设置目标，然后选择数据移动机制。 选择以下一个或多个机制，将数据从分析存储移动到 Fabric 中的 SQL 数据库。
小窍门
一般情况下，请使用：
- 用于简单复制和计划任务加载的管道。
- 数据流 Gen2，用于低代码转换。
- 用于复杂和大规模处理的 Spark（包括机器学习）。
- 可用的跨元素 T-SQL来维持以 SQL 为中心的操作，例如，将 SQL 数据库中的表联接到仓库或 SQL 分析端点中的表。
| 机制 | 何时使用 | 优势 | 考虑 |
|---|---|---|---|
| Fabric 数据管道 | 需要托管且可重复执行的数据复制操作（批处理或微批处理） | 一流集成;支持水印和存储过程 | 并发；在加载时扩展 SQL 数据库 |
| 数据流 Gen2 | 需要低代码数据转换和增强的进程逻辑 | 商业友好；支持列形状调整和清理 | 大规模数据量的吞吐量较低；需要规划分区 |
| Spark （笔记本/作业） | 需要复杂代码驱动的转换和大规模的重新塑造 | 完全代码控制;高效的 Delta 读取;JDBC 写入支持 | 身份验证和批处理;避免大型事务 |
| 跨项 T-SQL 查询 | 需要在 Fabric 项目之间进行数据库内的 SQL 操作 | 最小管道设施;SQL 原生支持;易于调度 |
参考体系结构：在 Fabric 中将反向 ETL 导入 SQL 数据库
Fabric 中反向 ETL 的参考体系结构汇集了将精心整理的分析数据投入使用所需的基本构建模块。 它演示如何通过转换层将数据从受信任的分析源流向结构化 SQL 数据库。 运营数据库作为下游系统的接口。 此模式可确保应用程序、API 和报告工具可以访问低延迟、高质量的数据，而不会影响记录分析系统的完整性。
此流的核心组件包括：
- 源： Fabric 数据仓库 或 Lakehouse （Delta）中的特选数据集。
- 转换：使用 管道、 数据流 Gen2、 Spark 或 跨项 T-SQL 应用的反向 ETL 转换。
- 目标： Fabric 中 具有定义的登陆、历史记录（可选）、隔离和服务架构的 SQL 数据库。
- 使用者：通过 GraphQL 或 TDS、API 和 Power BI 的应用程序进行实时仪表板和报告。
Components
将 Fabric 中的 SQL 数据库用作反向 ETL 目标的常规流中涉及以下组件。
服务和着陆模式
- 将源数据映射到 Fabric 中的 SQL 数据库的相应着陆架构。
- （可选）维护架构
history，以便实现可审核性。 - 使用
quarantine架构处理拒绝项（数据质量问题）。 - 定义一个
serving模式，适用于下游使用，包含适当的约束和索引。
统筹
- 使用 管道、数据流或 Spark 作业在 Fabric 中安排传输。
- 使用内置计划配置节奏、开始时间和时区。
- 通过 Fabric 门户或 API 调度 Spark Notebooks。
- 在 Fabric 监控中心监控端到端运行。
消耗
- 使用客户端库（如 ADO.NET 等）通过 GraphQL 终结点或 T-SQL 通过 TDS 公开数据。
- 直接通过 Fabric 中的 SQL 数据库生成 Power BI 仪表板和可视化效果。
治理和安全性
- 使用 Microsoft Entra ID 进行身份验证和授权。
- 合并 Fabric 工作区角色权限 和 SQL 权限 ，以便进行精细控制。
- （可选）为静态数据加密配置 客户管理的密钥 。
- 使用 专用链接审核传输中数据的访问和安全。
应用程序服务
在 SQL 数据库中策展和刷新数据后，将重点转移到为操作用户提供快速可靠的访问。 在此上下文中， 应用程序服务 意味着通过低延迟接口公开受信任的数据集，这些接口与新式应用程序模式保持一致。
将数据登陆并刷新到 Fabric 中的 SQL 数据库中后：
- 若要为作工作负荷提供服务，请通过 GraphQL 终结点或 TDS 协议公开数据，以便通过 ADO.NET 和其他客户端库使用。 例如，提供产品信息、供应链或客户服务用例。
- 将数据集与 Power BI 配对，以提供实时仪表板和自助服务分析。
针对布料的注意事项
Fabric 中的 SQL 数据库使用与 Azure SQL 数据库 相同的 SQL 数据库引擎，并通过 Fabric 门户进行控制、保护、计费和作。 它还提供将存储在 Microsoft OneLake 中的 Delta/Parquet 文件进行内置镜像的功能，可以通过 SQL 分析终结点进行访问。 由于它位于 Microsoft Fabric 环境中，因此在创建设计时需要考虑以下几点：
- 功能一致性：Fabric 中的 SQL 数据库正在与 Azure SQL 数据库趋同。 验证所需的特定 功能 ，以确保适合用途，并监视 路线图更新。
- 安全模型：Fabric 中的 SQL 数据库仅使用 Microsoft Entra ID 身份验证。 相应地规划管道、数据流和 Spark 作业的标识。
- 复制：Fabric 中的 SQL 数据库自动将只读数据复制到 OneLake。 此同步对于报告和分析需求非常有用，而数据库仍可用于读/写作工作负荷。