通常，在通过SSIS的内部部署SQL server ETL工作流中，我们从任何位置将数据加载到暂存表中，然后应用验证和转换将它们加载/合并到下游数据仓库表中。
我的问题是，我们是否应该在Azure上做类似的事情，在Azure SQL数据库中有一组暂存表和下游表，或者使用Azure存储区作为暂存区，并通过ADF将数据从那里移动到最终的下游表中。
尽管看起来很疯狂，但我们也有一个单独的暂存数据库和下游数据库的建议，我们使用ADF在这两个数据库之间移动。
数据移动管道有不同的模型，没有一个是完美的。我将对我看到的常见模式做一些评论，以防对您的应用程序做出决策有所帮助。
对于许多试图暂存数据并创建维度的数据仓库，通常会有一个过程，将原始源数据作为原始数据加载到其他一些数据库/表中，然后将其处理为要插入到事实表和维度表中的格式。由于数据可能延迟到达或数据在晚些时候得到更正，这一过程变得复杂，因此这些系统通常是使用目标事实表上的分区表设计的，以允许重新处理相当于分区的数据(例如一天)，而无需重新处理整个事实表。此外，如果数据本身的形式与您希望在DW中表示它的方式相去甚远，那么该暂存表上的转换过程可能会非常密集。通常在内部部署系统中，这些都在一个单独的数据库(可能在同一SQL Server上)中处理，以将其与生产系统隔离。此外，有时会从原始源数据(CSV文件或类似文件)中重新创建这些暂存表，因此它不是该源材料的记录存储。这允许您考虑在该数据库上使用简单的恢复模式(与完全恢复相比，这减少了日志IO要求和恢复时间)。虽然不是每个DW都对处理后的DW数据使用完全恢复模式(有些DW会将数据双重加载到第二台计算机，因为管道在那里)，但在SQL Server中使用完全恢复加物理日志复制(AlwaysOn Availability Groups)的能力使您能够灵活地在世界其他地区创建数据库的灾难恢复副本。(如果愿意，您也可以在该服务器上进行查询读取扩展)。这个基本模型有一些变体，但许多内部部署系统都有类似的东西。
当您查看SQLAzure时，在考虑如何设置等效模型时，有一些相似之处和一些差异很重要：
- 您可以对所有用户数据库进行完全恢复(但tempdb是简单恢复)。当使用v-core或高级dbs时，您还可以将更改提交到N个副本(如可用性组中)，这相当重要，因为与您自己构建的自定义系统相比，公共云系统中的网络拓扑通常更通用。换句话说，日志提交时间可能比当前系统慢。对于批处理系统来说，这并不一定太重要，但您需要小心使用足够大的批处理大小，这样您就不会在应用程序中一直在网络上等待。考虑到您的暂存表也可能是SQL Azure数据库，您需要意识到它也有仲裁提交，因此您可能需要考虑哪些数据将日复一日地保留(保留在SQL Azure数据库中)，哪些数据可以进入tempdb以降低延迟并在丢失时重新创建
- 目前，SQL Azure中没有数据库内资源治理模型(除了弹性池，它是部分的，针对的用例与DW不同)。因此，拥有一个单独的临时数据库是一个好主意，因为它将生产工作负载与临时数据库中的处理隔离开来。您可以避免嘈杂的邻居问题，因为您的主要生产工作负载会受到要加载的当天数据处理的影响
- 当您为内部部署DW配置机器时，您通常会购买足够大的存储阵列/SAN，以便承载您的工作负载以及可能的许多其他工作负载(整合场景)。SQL Azure中的高级/v-core数据库是用本地SSD设置的(Hyperscale是新添加的，它为您提供了一些跨机器扩展模型，在某些方面有点像SAN)。因此，您需要仔细考虑生产系统和暂存/加载过程所需的IOPS。您可以选择放大/缩小其中的每一个，以更好地管理您的工作负载和成本(不像购买大型存储阵列的CAPEX，后者是预先组成的，然后您调整工作负载以适应它)
- 最后，还有一个SQL DW产品，它的工作方式与SQL Azure有点不同——它针对更大的DW工作负载进行了优化，并具有扩展计算功能，可以向上/向下扩展。根据您的工作负载需求，如果更适合的话，您可能需要将其视为最终的DW目标
要回答您最初的问题-您能在SQL Azure上运行数据加载管道吗？是的，你可以。与您现有的现场体验相比，有一些注意事项，但它会起作用。公平地说，也有人直接从CSV文件或类似文件加载，而不使用暂存表。他们通常不会做那么多的转换，所以YMMV是基于你的需求。
希望能有所帮助。