我是Azure Data Lake Storage的新手，目前正在接受数据工厂方面的培训。我有开发人员的背景，所以我现在不喜欢"工具"开发方法。我真的不喜欢到处都要设置这些设置和创建对象。我更喜欢一种代码方法，它允许我们将逻辑与服务分离(不喜欢保存发布内容(，通过滚动或导航到项目中的不同对象来查看所有内容，更容易查看源代码控制中的差异等。因此，我发现了这个Micrososft的文件系统SDK，它似乎是数据工厂的替代品：https://azure.microsoft.com/en-us/blog/filesystem-sdks-for-azure-data-lake-storage-gen2-now-generally-available/
你使用这种方法的经验是什么？这是一个好的选择吗？有没有一种方法可以在数据工厂中运行SDK代码？这样我们就可以利用日程安排和触发器了？我想我在找优点/缺点。
谢谢
好吧，文档引用了几个SDK，其中一个是.Net SDK，标题是
使用.NET(或Python或Java等(管理Azure Data Lake Storage Gen2 中的目录、文件和ACL
因此，SDK只允许您管理文件系统。不支持触发器、管道、数据流和批次。为此，您必须坚持使用Azure数据工厂。
关于此：
我不喜欢开发的"工具"方法
我不想告诉你，但不管你喜不喜欢，世界都在朝着这个方向发展。以逻辑应用程序为例。Azure数据工厂并不针对核心开发人员，而是满足了像数据工程师这样处理大型数据集的人员的需求。我已经很高兴它能很好地与git集成。是的，在定义汇和源时会有一些开销，但它们可以跨管道重复使用。
如果你真的想使用代码，请尝试Azure Databricks。看看这个问答；A也是。
TL；DR：FileSystem SDK不是一个替代方案。
构建和管理Azure数据湖的Azure数据工厂的以代码为中心的替代方案是Spark。通常是Azure Databricks或Azure Synapse Spark。