Sql 数据库中的暂存表与存储区域

通常，在通过SSI的本地SQL server ETL工作流中，我们从任何位置将数据加载到临时表中，然后应用验证和转换将其加载/合并到下游数据仓库表中

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

---

看起来很疯狂，我们也有一个建议，即使用ADF在单独的暂存数据库和下游数据库之间移动。

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

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

当您查看SQL Azure时，在考虑如何建立等效模型时，存在一些相似之处和一些差异：

您可以对所有用户数据库进行完全恢复（但tempdb是简单恢复）。在使用v-core或premium dbs时，您还可以将更改提交到N个副本（如可用性组），这相当重要，因为与您自己构建的自定义系统相比，公共云系统中的网络拓扑通常更通用。换句话说，日志提交时间可能比当前系统慢。对于批处理系统来说，这不一定太重要，但是您需要小心使用足够大的批处理大小，这样您就不会在应用程序中一直在网络上等待。考虑到您的分级表也可能是一个SQL Azure数据库，您需要知道它也有仲裁提交，因此您可能需要考虑哪些数据将停留在一天一天（停留在SQL Azure DB）中。VS可以进入TEPDB以降低延迟，如果丢失则重新创建。

SQL Azure中目前没有内部db资源治理模型（弹性池除外，弹性池是部分的，针对的是与DW不同的用例）。因此，拥有一个单独的暂存数据库是一个好主意，因为它将生产工作负载与暂存数据库中的处理隔离开来。您可以避免嘈杂的邻居问题，因为您的主要生产工作负载会受到当天要加载的数据处理的影响

当您为本地DW配置计算机时，您通常会购买足够大的存储阵列/SAN，以承载您的工作负载和可能的许多其他工作负载（整合场景）。SQL Azure中的premium/v-core DBs是使用本地SSD建立的（Hyperscale是新添加的，它为您提供了一些跨机器扩展模型，在某些方面有点像SAN）。因此，您需要仔细考虑生产系统和暂存/加载过程所需的IOPS。您可以选择放大/缩小其中每一个，以更好地管理您的工作负载和成本（不同于先购买大型存储阵列，然后调整工作负载以适应它的资本支出）

最后，还有一个SQL DW产品，其工作原理与SQL Azure稍有不同-它针对更大的DW工作负载进行了优化，并具有向上/向下扩展计算的能力。根据您的工作量需求，您可能希望将其视为最终DW目标，如果这是一个更好的匹配。

为了回答您最初的问题，您可以在SQLAzure上运行数据加载管道吗？是的，你可以。与您现有的本地体验相比，有一些警告，但它会起作用。公平地说，也有人只是直接从CSV文件或类似文件加载，而不使用暂存表。通常，他们不会做那么多的转换，所以YMMV会根据您的需要进行调整

---

希望这能有所帮助。

谢谢您详尽的回答。现在我将使用单独的暂存数据库。