我有一个要求，需要在 ADF 管道中的映射数据流与 SQL 存储过程之间进行选择，以实现某些业务场景。现在数据量还不是很大，但后期可能会更大。 业务逻辑有时很复杂，我必须连接多个表、编写子查询、使用 Windows 函数、嵌套 case 语句等。
我的所有业务需求都可以通过 SP 轻松实现，但考虑到它在底层运行 Spark 并且可以根据需要进行扩展，因此稍微倾向于映射数据流。 在 ADF 管道中使用时，ADF 映射数据流是否比 SQL 存储过程更有优势？ 我对映射数据流的一些担忧如下。
- 使用数据流实现复杂逻辑所需的时间要多得多 比存储过程
- 映射数据流的执行时间为 考虑到旋转 Spark 所需的时间，要高得多 集群。
现在，如果我决定在管道中使用 SQL SP，可能会有哪些缺点？ 如果某个时间点数据量快速增长，会不会导致扩展性出现问题？
最佳答案
这是一种意见问题，在 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
关于azure - 在 ADF 管道中映射数据流与 SQL 存储过程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/63905395/