我目前正在使用数据工厂构建一个Azure数据湖，并且在获得有关多个数据工厂与一个数据工厂的建议之后。
我目前有一个数据工厂，即从一个EBS实例获取数据，用于企业下的一个特定公司。在未来，虽然可能有其他EBS实例和其他公司（与其他应用程序作为来源）合并到工厂 - 我认为图表可能会有点混乱。
我一直在搜索，我找到了这个网站，建议将所有内容保存在一个数据工厂中，以重用链接服务。我想这是一件好事，但是因为我已经为一个数据工厂编写了构建脚本，所以再次构建链接服务以指向相同的数据湖将非常容易。
https://www.purplefrogsystems.com/paul/2017/08/chaining-azure-data-factory-activities-and-datasets/
只有一个数据工厂实例的优点：
缺点
有没有人在那里获得一些Azure数据工厂的大型部署，它们可能带来数千个数据源，将它们混合在一起并进行转换？有兴趣听听你的想法。
我的建议是只有一个，因为它可以更容易配置多个集成运行时（网关）。如果您决定拥有多个数据工厂，请考虑到pc只能安装1个集成运行时，并且集成运行时只能注册到1个数据工厂实例。
我认为您列出的缺点都是通过命名规则来修复的。如果你将它们命名为：Pipeline_ [数据库名称] [db schema] [表名]，那么找到你想要的管道并不麻烦。
我有一个包含数千个数据集和管道的项目，并且它比小项目更难处理。
希望这有帮助！
我最初同意集成运行时绑定到单个数据工厂是一个限制，但我怀疑它不再或很快不再是一个限制。
在March 13th update to AzureRm.DataFactories中，有一条评论说明“允许在数据工厂之间共享集成运行时”。
我认为这将取决于数据工厂的复杂性以及各种源和目标之间是否存在相互依赖关系。
特别是UI（在V2中更是如此）使得管理大型数据工厂变得容易。
但是，如果选择ARM部署技术，即使是一个非常复杂的数据工厂，数据工厂JSON也很快会变得难以处理。从这个意义上讲，我建议拆分它们。
您当然可以通过将ARM模板分解为嵌套部署，ARM参数化或数据工厂V2参数化，使用SDK直接使用单独的文件来缓解可修复性问题。甚至只是使用UI（现在使用git支持:-)）
也许更重要的是，特别是当你提到来自不同的公司时;它可能听起来像数据不相关，如果不相关 - 是否应该隔离以避免任何编码错误？或者甚至可能为数据工厂分配角色和职责。
另一方面，如果数据是相互关联的，那么将它放在一个数据工厂中会使数据工厂更容易管理数据依赖性并一次性重新运行失败的片。
如果您使用的是ADF v1，那么它会变得混乱。在我们的客户，我们在一个数据工厂中有超过1000个管道。如果你刚刚开始，我建议你看看v2，因为它允许你参数化，并且应该让你的脚本更可重用。
在3月发布之后，您可以链接不同工厂之间的集成运行时。
另一件事是为各种管道和数据集创建不同的文件夹