我不确定是否有足够的信息来提供可靠的建议。数据的来源是什么？为什么ADF是解决方案的一部分？这是每天一次的50万行还是一个恒定的流？您是否加载到一个Staging表，然后使用存储过程将数据移动和转换到另一个表？
以下是一些想法：
1.如果数据操作是SQL到SQL [意味着源和接收器的SQL示例相同]，则使用存储过程。这可以让你保持接近金属，并将执行最好的。一个例外是，如果计算负载真的很复杂，但这里似乎不是这样。
1.一般来说，从ADF调用Data Brick的唯一原因是您已经拥有该专业知识并且已经存在支持它的资源。
由于ADF是故事的一部分，因此在两个场景之间存在一个中间地带-数据流。数据流是对数据块的低代码抽象。它们是飞行中数据转换的理想选择，在高负载下表现出色。您无需创作或部署笔记本，也无需管理Data Bricks配置。他们是ADF管道中的一等公民。

作为一名经验丰富的（前）DBA、数据工程师和数据架构师，我看不出Databricks在这种情况下会增加什么。您可能需要扩展的这部分架构是INSERTs的目标，即Azure SQL数据库，它非常容易通过门户或REST API手动扩展，如果需要的话。如果需要调优插入，请考虑诸如装入堆和分区切换之类的技术。
在架构中添加额外组件然后通过数据的开销必须是值得的，再加上在数据库运行的同时旋转Spark集群的额外成本。
Databricks是一个非常好的工具，有很多很好的用例，例如高级数据转换（即你不能用SQL做的事情），机器学习，流等等。看看这个免费的资源，了解一些想法：
https://databricks.com/p/ebook/the-big-book-of-data-science-use-cases

尽管这个问题是在三年前提出的，但我想分享我的个人经验，因为我的项目目前正处于从存储过程到数据库的转变中。
这里的用例是每次运行处理约150万个条目，并在将其上传到SQL Server之前进行一些最小的转换。
决策驱动因素是：

• 波动环境下的可维护性：存储过程代码已经存在了很多年，并且完成了它们的工作。问题是，它是由一个专门的SQL数据库管理员/工程师编写和维护的，他离开了项目，因此离开了存储过程的内部。对于新的开发人员（不是SQLMaven）来说，很难理解发生了什么，因为代码很混乱，并且分布在几个存储过程中。
• 标准化：实际上有多个ETL管道，部分在存储过程中实现，部分以另一种定制的方式实现。Databricks的希望是能够在一个单一的真理来源中编排所有的管道。
• 版本控制：有了数据库上的存储过程，基本上任何人都可以在不被注意的情况下进行更改，也可以选择返回到以前的状态。
• 可测试性：也没有单元测试或任何其他测试可以帮助理解其中实现的业务逻辑或验证业务逻辑。

我认为，如果不使用Databricks，我们也可以通过一些努力来实现这一切，但是那里的工具确实有助于建立一个维护和更高质量的ETL管道。
此外，它还将通过准备好新的基础设施，使项目能够用于未来的业务案例。
实际上，在这个项目中，我们觉得迁移到Databricks的开销是值得的，因为它有一个更透明，高质量和可维护的解决方案。