问题描述
我有一个需求，我需要在ADF管道中的“映射数据流”与“ sql存储过程”之间进行选择，以实现一些业务场景。现在的数据量还不是很大，但是稍后可能会更大。 业务逻辑有时很复杂，我将不得不连接多个表，编写子查询，使用Windows函数，嵌套的case语句等。
我所有的业务需求都可以通过SP轻松实现，但是考虑到数据流在下面运行并可以按需扩展，因此它倾向于映射数据流。 在ADF管道中使用ADF映射数据流时，它在sql存储过程方面是否占上风？ 我对映射数据流的一些担忧如下。
- 使用数据流实现复杂逻辑所花费的时间更多 比存储过程
- 映射数据流的执行时间为 考虑到旋转火花所需的时间要高得多 集群。
现在，如果我决定在管道中使用sql SP，那么可能会有什么缺点？ 如果数据量在某个时间点快速增长，可伸缩性是否会出现问题？
解决方法
这是一个意见问题，在stackoverflow上往往不太好，但是您正在将“映射数据流”与存储的procs进行比较的事实告诉我您具有Azure SQL数据库（或类似版本） 体系结构中的Azure数据工厂（ADF）。
如果考虑映射数据流由Spark群集支持的事实，并且您已经拥有Azure SQL DB，那么您真正拥有的是两种类型的计算。那么为什么两者都有呢？在执行连接，嵌套查询等方面，没有什么比SQL更好的了。AzureSQL DB可以轻松地进行缩放（例如，通过其REST API），这似乎是您的要点之一。
话虽如此，映射数据流功能强大并且提供了很好的低代码体验。因此，如果您的要求是具有功能强大的转换的低代码，那么这将是一个不错的选择。请记住，如果您的数据已经存在于数据库中，并且您正在使用“映射数据流”，那么您所做的就是将数据从SQL中取出，放入Spark集群中，进行处理，然后再将其向下推。在我看来，这似乎是重复的，我保留了Mapping Data Flows（和Databricks笔记本）用于我在SQL中无法完成的事情，例如高级分析，硬数学，复杂的字符串操作可能是不错的选择。另一个用例可能是工作卸载，您故意要从数据库中卸载工作。只需记住同时运行两种类型的计算的成本含义即可。
最近我还看到一个示例，其中有人使用“映射数据流”实现了一个缓慢变化的维类型2（SCD2），但使用了20多种不同的MDF组件来实现。这只是我的低代码，具有很高的复杂性，难以维护和调试。使用SQL中的单个MERGE语句可以完成相同的过程。
因此，我个人的观点是，将Mapping Data Flows用于无法使用SQL完成的事情，尤其是当您的体系结构中已经有SQL数据库时。我个人更喜欢ELT模式，使用ADF进行编排（不是MDF），我认为这样更易于维护。
您可能会问的其他一些问题是：
- 您的团队具备哪些技能？ SQL是一项相当普通的技能。 MDF仍然是低代码但小众。
- 您的支持团队有哪些技能？移交给您时，您打算在MDF上对其进行培训吗？
- 鉴于上述情况，您如何评价这两种方法的复杂性和可维护性？
HTH