数据库与存储区中的登台表

Question

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

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

看起来很疯狂，我们还提出了一个建议，要使用ADF在它们之间建立单独的登台数据库和下游数据库。

Answer 1

执行数据移动管道的模型有很多，没有一个是完美的。我将对常见的模式进行一些评论，以防万一有助于您对应用程序进行决策。

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

当您查看SQL Azure时，在考虑如何建立等效模型时有一些相似之处和重要区别：

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

要解决您的原始问题-您可以在SQL Azure上运行数据加载管道吗？是的你可以。与您在本地的现有经验相比，有一些警告，但是它可以起作用。公平地说，也有人直接从CSV文件或类似文件中加载而不使用暂存表。通常他们不做很多转换，因此YMMV根据您的需求。

希望有帮助。