关于Azure平台托管数据仓库的建议

Question

我是一个数据仓库开发人员，目前正在研究如何使用Azure平台来托管一个新的数据仓库。

我的经验是使用驻留标准SQL Server数据库的前提服务器，一个用于暂存数据库，一个用于数据仓库。通常，我会为ETL使用SSIS和存储过程的组合，它们运行在调度的SQL服务器代理作业中。

如何在Azure中复制这种设置？存储大小将小于1TB，所以我可以只使用Azure SQL Server数据库而不是Azure SQL数据仓库吗？如果是这样的话，我是否需要使用弹性池选项来分阶段和数据仓库？我将加载到阶段的数据都是在前提条件下的。SSIS是否仍然适合加载到Azure，还是Azure数据工厂更适合？

任何帮助都是非常感谢的！谢谢。

Answer 1

里昂那里有很多好消息。但是，从数据仓库的角度来看，我不会将数据同步用于ETL目的(在Leon提供的链接数据同步中，在“何时使用数据同步”列表中作为“不首选”)。

对于DW来说，Azure DB是一个很好的选择。Azure SQL数据仓库(现在称为Azure Synapse Analytics )是处理DW的一个沉重任务。您真的确定需要这种具有< 1Tb数据的系统吗？我会暂时离开Azure Synaptics，先尝试使用Azure DB。它要便宜得多，如果有必要，你可以稍后再升级。

不过，关于Azure有一点要注意: Azure 不支持数据库上的查询。不过，这不是一个交易的破坏者，所有事情都可以在同一个数据库中处理。我个人使用一个模式来区分分阶段和DW (当然，我也使用DW中的其他模式)。当然，使用单独的数据库并不困难，但在Azure DB中，它们之间的边界要比前提下的SQL Server或其他Azure解决方案(例如托管实例)要深得多。

SSIS仍然是一个选项，但问题是，您使用什么来运行包？有以下几种选择：

• 继续在前提下运行它们(所有的艰苦工作仍在云中完成)
• 从Azure租赁带有Server的VM，将包部署到VM并从VM运行它们
• 使用Data运行SSIS包

所有这些都不是每个用例的完美解决方案。如果运行SSIS是您唯一需要的东西，那么前两个选项会带来相当大的成本。目前，使用Data运行SSIS有点麻烦，但无论如何也是一种选择。

Data本身也是一个很好的选择(我个人还没有尝试过，但我听说过关于它的一些好东西)。如果您使用Data来运行SSIS，那么为什么不首先使用没有SSIS包的Data呢？当然，与SSIS相比，Data有一些限制，这可能是原因之一，但是如果SSIS包足够简单，为什么不尝试一下Data呢？

Answer 2

我建议你使用Azure SQL数据库。它为您提供了多种不同存储的价格层。您可以为您选择最合适的价格等级。Azure SQL数据库还支持基于使用情况的向上/向下扩展。

参考文献：基于DTU的采购模型中的服务层

正如您所说的，我将加载到阶段的数据都在前提条件下。

Azure数据库具有数据同步可以帮助您这样做的特性：

在需要在多个Azure SQL数据库或Server数据库中更新数据的情况下，Data非常有用。以下是数据同步的主要用例：

• 混合数据同步：使用数据同步，您可以在本地数据库和Azure数据库之间保持数据同步，以启用混合应用程序。这种功能可能会吸引正在考虑迁移到云的客户，并希望将他们的一些应用程序放在Azure中。
• 分布式应用程序：在许多情况下，在不同的数据库中分离不同的工作负载是有益的。例如，如果您有一个大型的生产数据库，但是您也需要对这些数据运行一个报告或分析工作负载，那么为这个额外的工作负载创建第二个数据库是很有帮助的。这种方法将对生产工作负载的性能影响降到最低。您可以使用数据同步来保持这两个数据库的同步。
• 全局分布式应用程序：许多业务跨越多个地区，甚至几个国家/地区。为了最大限度地减少网络延迟，最好将您的数据放在靠近您的区域中。有了数据同步，您可以很容易地保持世界各地的数据库同步。

创建SQL数据库时，可以使用许多工具(如数据迁移助理(DMA) )将架构或数据迁移到Azure。

然后在Azure SQL数据库和Server内部建立SQL数据同步，它将帮助同步数据自动每5分钟。

希望这能有所帮助。

Answer 3

如果您想在Azure中开始使用比较便宜的选项，可以使用一个通用SQL数据库和一个Azure database管道，其中包含一些活动。

动态资源缩放ETL

您可以通过发出一个alter数据库语句来扩展数据库，然后转移到您存储的基于proc的ETL。我甚至会使用“主”proc调用维度和事实proc来控制执行流。然后用另一个alter语句缩小数据库。我甚至创建了自己存储的proc来发布这些缩放语句。

您也无法预测何时完成缩放，因此我有一个等待活动。您可以使用一个循环来检查服务目标属性，然后在它完成后继续工作，这样您可能会更加书呆子一点。但等10分钟就更容易了。我只被烧了几次，但剥皮时间更长了。

数据管道活动：

1. 扩大规模，如果成功就继续前进
2. 等大约10分钟，一直向前走
3. 执行ETL，始终执行
4. 缩小规模

弹性查询

您可以使用垂直分区弹性查询跨数据库进行查询。性能不是很好，他们不推荐ETL，但是它会起作用的。要提高性能，请尝试将需要的任何大型表转储到临时表中，然后在本地转换数据。