反向提取、转换和使用 Azure Cosmos DB for NoSQL 加载 （ETL）

云数据仓库和数据湖丰富数据、集中信息，并启用强大的分析。 但数据的真正价值在于将见解转化为实际决策和客户体验。 为了实现此目标，必须将干净可靠的数据从仓库/数据湖转移到操作系统中。 反向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 表等源中提取清理和扩充的数据，并将数据写回到 Azure Cosmos DB for NoSQL 中的作存储。

此图包括以下组件：

• 包含数据的数据源，例如：产品数据、CRM 数据、订单信息和广告信息。

• ETL 工作流将数据从原始数据源移动到data warehouse或 data lake，以使用 Azure Databricks 或 Microsoft Fabric 等解决方案来存储和扩充数据。

• 反向 ETL 工作流，使用 Apache Spark 和 Delta 表将扩充数据迁移到操作型数据存储

• 操作数据存储 例如 Azure Cosmos DB for NoSQL，以便在实时应用程序中使用扩充的数据。

反向 ETL 过程可实现以下方案：

• 实时决策：应用无需依赖分析师或 SQL 即可访问最新数据。

• 数据激活： 见解被推送到需要的地方，而不仅仅是停留在仪表板中。

• 统一真相来源： Delta Lake 充当规范层，可确保系统之间的一致性。

数据引入阶段

对于功能存储、建议引擎、欺诈检测或实时产品目录等方案，将data flow分为两个阶段非常重要。 这些阶段假设你有一个从 Delta Lake 到 Azure Cosmos DB for NoSQL 的反向 ETL 管道。

此图中的阶段包括：

1. Initial load：初始加载是一次性批处理步骤，用于将所有历史数据从 Delta 表导入到用于 NoSQL 的 Azure Cosmos DB。 它通过确保运营数据存储具有完整的历史数据，为您的反向 ETL 管道奠定基础。 在开始对数据进行增量同步之前，此加载是一个基本步骤。

2. Change 数据捕获（CDC）同步：此步骤执行从 Delta 表到 Azure Cosmos DB for NoSQL 的连续增量同步。 启用 Delta 更改数据馈送（CDF）后，可以捕获 Delta 表中的更改。 可以实现基于批处理或基于流式传输的更改数据捕获（CDC）同步。

CDC 可以通过两个选项同步到 Azure Cosmos DB for NoSQL：

• Batch 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）。 此阈值明确指示此方案适用于工作负荷，应使用标准预配吞吐量。

• 选择最大化并行度的有效分区键。 有关详细信息，请参阅 分区和分区键建议。

• 为大规模数据引入预先规划所有分区的总数以及所有分区的总请求单位/秒。 有关详细信息和指南，请参阅 有关分区和吞吐量的建议。

• 使用 Apache Spark 吞吐量控制 来限制作业的请求单位（RU）消耗量。 吞吐量控制有助于防止目标容器过载。

• 在 Azure Cosmos DB 的 NoSQL 环境中进行 CDC 同步时，应尽可能使用自动缩放吞吐量，因为它会根据使用情况动态增加/减少 RU/秒。 自动缩放吞吐量非常适合定期和突发的工作负荷，如计划的 CDC 同步作业。 有关详细信息，请参阅 吞吐量建议。

• 估算最初数据加载步骤中的数据引入持续时间。 有关详细信息和示例，请参阅 吞吐量估算。

后续步骤