1

我有一个要求，我需要在 ADF 管道中的映射数据流与 SQL 存储过程之间进行选择，以实现一些业务场景。现在数据量不算太大，但后期可能会变大。业务逻辑有时很复杂，我必须加入多个表、编写子查询、使用 windows 函数、嵌套 case 语句等。

我的所有业务需求都可以通过 SP 轻松实现，但考虑到它在下面运行 spark 并且可以根据需要扩展，因此有点倾向于映射数据流。在 ADF 管道中使用时，ADF 映射数据流是否优于 SQL 存储过程？我对映射数据流的一些担忧如下。

  1. 使用数据流实现复杂逻辑所花费的时间远远超过存储过程
  2. 考虑到启动 spark 集群所需的时间，映射数据流的执行时间要长得多。

现在，如果我决定在管道中使用 SQL SP，有什么缺点？如果数据量在某个时间点快速增长，是否会出现可扩展性问题？

4

2 回答 2

2

这是一个在 stackoverflow 上表现不佳的意见问题，但是您将映射数据流与存储过程进行比较的事实告诉我，您拥有 Azure SQL 数据库（或类似数据库）和Azure 数据工厂（ADF）在你的架构中。

如果您考虑到 Mapping Data Flows 由 Spark 集群支持，并且您已经拥有 Azure SQL DB，那么您真正拥有的是两种类型的计算。那么为什么两者都有呢？在进行连接、嵌套查询等方面，没有什么比 SQL 更好的了。Azure SQL DB 可以轻松地向上和向下扩展（例如，通过其 REST API）——这似乎是您的观点之一。

话虽如此，映射数据流功能强大，并提供了良好的低代码体验。因此，如果您的要求是具有强大转换的低代码，那么它可能是一个不错的选择。请记住，如果您的数据已经在数据库中并且您正在使用 Mapping Data Flows，那么您所做的就是将数据从 SQL 中取出，放到 Spark 集群中，对其进行处理，然后将其推回。这对我来说似乎是重复的，我将映射数据流（和 Databricks 笔记本）保留为我在 SQL 中无法完成的事情，例如高级分析、硬数学、复杂的字符串操作可能是很好的候选者。另一个用例可能是工作卸载，您有意从数据库中卸载工作。请记住同时运行两种类型的计算的成本影响。

我最近还看到一个示例，其中有人使用映射数据流实现了缓慢变化的维度类型 2 (SCD2)，但使用了 20 多个不同的 MDF 组件来实现。这对我来说只是名义上的低代码，复杂性高，难以维护和调试。可以使用MERGESQL 中的单个语句完成相同的过程。

所以我个人的观点是，将映射数据流用于您已经无法使用 SQL 完成的事情，特别是当您的架构中已经有 SQL 数据库时。我个人更喜欢 ELT 模式，使用 ADF 进行编排（不是 MDF），我认为这更易于维护。

您可能会问的其他一些问题是：

  • 你的团队有什么技能？SQL 是一种相当常见的技能。MDF 仍然是低代码但小众。
  • 您的支持团队有哪些技能？当你交出这个时，你打算在 MDF 上训练他们吗？
  • 鉴于上述情况，您如何评价这两种方法的复杂性和可维护性？

HTH

于 2020-09-15T16:52:47.607 回答
0

在管道中使用 SP 的一个缺点是，您的 SP 将直接针对数据库服务器运行。因此，如果您在执行 SP 的同时对数据库运行任何其他查询/事务或作业，您可能会遇到更长的运行时间（取决于查询复杂性、读取的记录等）。随着数据量的增长，这个问题可能会更加复杂。

我们决定在我们的组织中使用 SP，而不是映射数据流。当我们扩大规模时，集群启动时间对我们来说是一个问题。为了解决我之前提到的 SP 的问题，我们错开我们的工作量，并安排作业在非高峰时间运行。

于 2021-11-11T21:35:22.113 回答