云数据仓库和数据湖丰富数据、集中信息，并启用强大的分析。 但数据的真正价值在于将见解转化为实际决策和客户体验。 为了实现此目标，必须将干净、可靠的数据从仓库/数据湖转移到操作系统中。 反向 ETL 将数据从数据仓库层（例如 Azure Databricks 中的 Delta Lake 或 Microsoft Fabric）移回作系统。 此迁移步骤允许下游应用使用最新的扩充数据进行实时作分析。 反向 ETL 通过弥合分析和操作之间的差距，实现更好的决策，在释放数据资产的全部潜力方面发挥着至关重要的作用。
Azure Cosmos DB for NoSQL 专为超低延迟、多区域分发和 NoSQL 可伸缩性而设计，非常适合实时应用程序。 使用反向 ETL，可以将 Delta 扩充数据同步到 Azure Cosmos DB，实现实时运营分析。 可以使用此模式推送产品目录、个性化客户信息、定价更新、库存数据和功能建议等数据。 可以将此数据推送到操作数据存储中，使下游应用能够立即做出数据驱动型决策。
实现反向 ETL 的简化体系结构由 Apache Spark 和 Azure Databricks 组成。 此体系结构从 Delta Tables 之类的源提取清理的和扩充的数据，并将数据写回到 Azure Cosmos DB for NoSQL 中的操作存储。
此图包括以下组件：
包含数据的数据源，例如：产品数据、CRM 数据、订单信息和广告信息。
使用 Azure Databricks 或 Microsoft Fabric 等解决方案将数据从原始数据源移动到数据仓库或 Data Lake 以存储和扩充数据的 ETL 工作流。
反向 ETL 工作流：使用 Apache Spark 和 Delta Tables 将扩充的数据迁移到操作数据存储
操作性数据存储（例如用于 NoSQL 的 Azure Cosmos DB），以便在实时应用程序中使用改进的数据。
反向 ETL 过程可实现以下方案：
Real-Time 决策： 应用无需依赖分析师或 SQL 即可访问最新数据。
数据激活：见解会被推送到所需的地方，而不是仅仅停留在仪表板中。
统一真相来源： Delta Lake 充当规范层，可确保系统之间的一致性。
对于功能存储、建议引擎、欺诈检测或实时产品目录等方案，请务必将数据流分为两个阶段。 这些阶段假设你有一个从 Delta Lake 到 Azure Cosmos DB for NoSQL 的反向 ETL 管道。
此图中的阶段包括：
初始加载：初始加载是一次性批处理步骤，用于将增量表中的所有历史数据引入 Azure Cosmos DB for NoSQL。 它通过确保操作数据存储具有完整的历史数据，为反向 ETL 管道奠定基础。 在开始对数据进行增量同步之前，此加载是一个基本步骤。
变更数据捕获 (CDC) 同步：此步骤实现了从 Delta Tables 到 Azure Cosmos DB for NoSQL 的增量性连续更改同步。 启用增量变更数据馈送 (CDF) 后，可以捕获增量表中的更改。 可以实现基于批处理或基于流式处理的变更数据捕获 (CDC) 同步。
可以通过两个选项进行到 Azure Cosmos DB for NoSQL 的 CDC 同步：
批量 CDC 同步：此选项按计划运行（例如，每天或每小时运行一次），并根据自上一个版本或时间戳以来捕获的更改加载数据的增量快照。
提示
请切换到较新的 Azure Cosmos DB 快照，以避免在将大量增量卷从增量表加载到 Azure Cosmos DB for NoSQL 时出现数据不一致的情况。 例如，在写入新容器或使用版本标志时，在完全加载新数据后，将指针翻转到较新的屏幕截图。
流 CDC 同步：此选项以近乎实时的方式持续同步增量更改，使目标系统保持最新状态，且延迟最小。 此选项使用 Apache Spark 结构化流式处理来持续捕获和写入更改。 增量表充当
readChangeData = true的流式传输源，而 Azure Cosmos DB for NoSQL 连接器充当流式传输接收器。提示
指定检查点位置以确保跟踪进度并避免重复写入。
将 Apache Spark 批处理作业与 Azure Cosmos DB for NoSQL 连接器配合使用来执行初始加载步骤。
如果初始负载预计会消耗大量 RU/秒（相对于分配的吞吐量而言），则可以通过切换到标准预配吞吐量来优化引入吞吐量。 具体而言，如果在初始加载过程的大部分持续时间内始终使用每秒最大请求单位数（RU/s），则使用标准预配的吞吐量。 在这种情况下，不要对初始加载步骤使用自动缩放吞吐量。
提示
如果 规范化的 RU 消耗指标 一致为 100%，则指标指示初始负载一致消耗最大自动缩放请求单位（RU）。 此阈值明确指示此方案适用于工作负荷，应使用标准预配吞吐量。
选择最大化并行度的有效分区键。 有关详细信息，请参阅 分区和分区键建议。
规划分区总数以及所有分区的总 RU/秒，以进行大型数据引入。 有关详细信息和指南，请参阅 有关分区和吞吐量的建议。
使用 Apache Spark 吞吐量控制 来限制作业的请求单位（RU）消耗量。 吞吐量控制有助于防止目标运行容器过载。
在 Azure Cosmos DB for NoSQL 中尽可能使用自动缩放吞吐量进行 CDC 同步，因为自动缩放会根据使用情况动态地提高/降低 RU/秒。 自动缩放吞吐量非常适合周期性和尖峰工作负荷，例如计划的 CDC 同步作业。 有关详细信息，请参阅 吞吐量建议。
估计初始数据加载步骤的初始引入持续时间。 有关详细信息和示例，请参阅 吞吐量估算。