在Azure数据工厂中使用SQL存储过程与数据块

Question

我要求每天使用ADF管道将多达500k条记录写入Azure SQL DB。 我将简单的计算作为可以在SQL存储过程活动中执行的数据转换的一部分。我还观察到Databricks笔记本电脑经常使用，尤其是。由于可扩展性的优势。但是，在转换，管理身份验证等之后，存在将文件放置在另一个位置的开销活动，除非绝对需要，否则我想避免任何过度设计。 我已经测试了SQL Stored Proc，并且它对于大约5万条记录（尚未进行大容量测试）非常有效。

但是我仍然想知道这两个选项之间的一般建议，尤其是。来自经验丰富的Azure或数据工程师。 谢谢

Answer 1

作为经验丰富的（以前的）DBA，数据工程师和数据架构师，我看不到Databricks在这种情况下增加了什么。您可能需要扩展的这一体系结构是INSERTs的目标，即Azure SQL数据库，即使需要，也可以轻松地通过门户或REST API手动扩展。如果需要调整插入，请考虑使用诸如加载到堆和分区切换之类的技术。

向架构中添加其他组件然后处理数据的开销必须是值得的，再加上在数据库运行的同时分解Spark集群的额外成本。

Databricks是一个出色的工具，并具有许多很好的用例，例如高级数据转换（即您无法使用SQL进行的操作），机器学习，流式传输等。看看这个免费资源的一些想法：

https://databricks.com/p/ebook/the-big-book-of-data-science-use-cases

Answer 2

我不确定是否有足够的信息提出可靠的建议。数据的来源是什么？为什么ADF是解决方案的一部分？这是每天50万行还是连续不断？您要加载到暂存表中，然后使用SPROC将数据移动并转换到另一个表中吗？

这里有一些想法：

1. 如果数据操作是SQL到SQL [对于源和接收器都意味着相同的SQL实例]，则使用存储过程。这样可以使您与金属保持紧密接触，并且性能最佳。如果计算负担确实很复杂，那就是个例外，但是在这里看来情况并非如此。

2. 通常来说，从ADF调用数据块的唯一原因是，如果您已经具备该专业知识并且已经有资源来支持它。

由于ADF是故事的一部分，因此在两种情况之间存在中间立场-数据流。数据流是对数据块的低代码抽象。它们是飞行中数据转换的理想选择，并且在高负载下表现出色。您无需创作或部署笔记本，也不必管理Data Bricks配置。他们是ADF管道中的一等公民。