azure - 在 ADF 管道中映射数据流与 SQL 存储过程

Question

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

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

1. 使用数据流实现复杂逻辑所需的时间要多得多比存储过程
2. 映射数据流的执行时间为考虑到旋转 Spark 所需的时间，要高得多集群。

现在，如果我决定在管道中使用 SQL SP，可能会有哪些缺点？如果某个时间点数据量快速增长，会不会导致扩展性出现问题？

Answer 1

这是一种意见问题，在 stackoverflow 上效果不佳，但您将映射数据流与存储过程进行比较的事实告诉我，您拥有 Azure SQL 数据库(或类似数据库)并且 架构中的 Azure 数据工厂 (ADF)。

如果您考虑到映射数据流由 Spark 集群支持这一事实，并且您已经拥有 Azure SQL DB，那么您真正拥有的是两种类型的计算。那么为什么两者都要呢？在执行连接、嵌套查询等方面，没有什么比 SQL 更好的了。Azure SQL DB 可以轻松地扩展和缩小(例如通过其 REST API)——这似乎是您的观点之一。

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

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

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

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

• 您的团队拥有哪些技能？ SQL 是一项相当常见的技能。 MDF 仍然是低代码但小众的。
• 您的支持团队拥有哪些技能？当你把这个交给你时，你会用中密度纤维板培训他们吗？
• 鉴于上述情况，您如何评价这两种方法的复杂性和可维护性？

HTH