DB 与存储区中的暂存表

Question

通常在通过 SSIS 的本地 SQL 服务器 ETL 工作流中，我们将任何地方的数据加载到暂存表中，然后应用验证和转换将它们加载/合并到下游数据仓库表中。

我的问题是我们是否应该在 Azure 上做类似的事情，在 Azure SQL 数据库中我们有一组暂存表和下游表，或者使用 azure 存储区域作为暂存区，并通过 ADF 将数据从那里移动到最终下游表中。

虽然看起来很疯狂，但我们还提出了一个单独的暂存数据库和下游数据库的建议，我们使用 ADF 在它们之间移动。

Answer 1

数据移动管道有不同的模型，没有一种是完美的。我将对我看到的常见模式进行一些 cmets，以帮助您对您的应用程序做出决定。

对于许多您尝试暂存数据并创建维度的数据仓库，通常有一个过程，您将原始源数据作为原始数据加载到其他一些数据库/表中，然后将其处理为您想要的格式插入事实和维度表。该过程很复杂，因为您可能有数据延迟到达或数据在稍后的一天被更正，因此这些系统通常在设计时使用目标事实表上的分区表，以允许重新处理具有分区价值的数据（例如一天），而不必重新处理整个事实表。此外，如果数据本身的形式与您希望在 DW 中表示它的方式相去甚远，那么该临时表上的转换过程可能会很密集。通常在本地系统中，这些在单独的数据库（可能在同一个 SQL Server 上）中处理，以将其与生产系统隔离。此外，有时这些临时表可以从原始源数据（CSV 文件或类似文件）重新创建，因此它不是该源材料的记录存储。这允许您考虑在该数据库上使用简单恢复模式（与完全恢复相比，这减少了 Log IO 要求和恢复时间）。虽然并非每个 DW 都对已处理的 DW 数据使用完全恢复模式（有些会双重加载到第二台机器，因为管道在那里），但在 SQL Server 中使用完全恢复和物理日志复制（AlwaysOn 可用性组）的能力为您提供在世界不同地区创建数据库灾难恢复副本的灵活性。 （如果您愿意，也可以在该服务器上进行查询读取横向扩展）。这个基本模型有一些变化，但是很多本地系统都有这样的东西。

当您查看 SQL Azure 时，在考虑如何设置等效模型时，有一些相似之处和一些不同之处：

1. 您已对所有用户数据库进行完全恢复（但 tempdb 处于简单恢复状态）。在使用 v-core 或高级 dbs 时，您还可以对 N 个副本（例如在可用性组中）的更改进行仲裁提交，这很重要，因为与您的自定义系统相比，您通常在公共云系统中拥有更通用的网络拓扑建立自己。换句话说，日志提交时间可能比您当前的系统慢。对于批处理系统，它不一定很重要，但是您需要小心使用足够大的批处理大小，这样您就不会在应用程序中一直在网络上等待。鉴于您的临时表也可能是 SQL Azure 数据库，您需要注意它也具有仲裁提交，因此您可能需要考虑哪些数据将每天保留（保留在 SQL Azure DB 中）与. 它可以进入 tempdb 以降低延迟，如果丢失则重新创建。
2. 目前在 SQL Azure 中没有数据库内资源治理模型（除了弹性池，它是部分的并且针对与 DW 不同的用例）。因此，拥有一个单独的暂存数据库是一个好主意，因为它将生产工作负载与暂存数据库中的处理隔离开来。您可以避免嘈杂的邻居问题，因为您的主要生产工作负载会受到当天要加载的数据处理的影响。
3. 当您为本地 DW 配置机器时，您通常会购买足够大的存储阵列/SAN，以便您可以托管您的工作负载和可能的许多其他工作负载（整合方案）。 SQL Azure 中的高级/v-core 数据库设置有本地 SSD（超大规模是新增功能，它为您提供了一些跨机器横向扩展模型，在某些方面有点像 SAN）。因此，您需要考虑生产系统和暂存/加载过程所需的 IOPS。您可以选择放大/缩小其中的每一个，以更好地管理您的工作负载和成本（与购买大型存储阵列的 CAPEX 不同，后者是预先构建的，然后您调整工作负载以适应它）。
4. 最后，还有一个 SQL DW 产品，其工作方式与 SQL Azure 略有不同 - 它针对更大的 DW 工作负载进行了优化，并且具有横向扩展计算能力，并且能够向上/向下扩展。根据您的工作负载需求，您可能希望将其作为您的最终 DW 目标，如果这更合适的话。

回答您最初的问题 - 您可以在 SQL Azure 上运行数据加载管道吗？是的你可以。与您现有的本地体验相比，有一些注意事项，但它会起作用。公平地说，还有一些人直接从 CSV 文件或类似文件中加载，而不使用临时表。通常他们不会做那么多的转换，所以 YMMV 根据你的需要。

希望对您有所帮助。